Monitorando a integridade de entrada do aplicativo para resiliência
Para aumentar a resiliência da infraestrutura, configure o monitoramento da integridade de entrada do aplicativo para seus aplicativos críticos. Você pode receber um alerta quando ocorrer um incidente afetado. Este artigo descreve como configurar a pasta de trabalho de integridade de entrada do aplicativo para monitorar interrupções nos logins dos usuários.
Você pode configurar alertas com base na pasta de trabalho de integridade de entrada do aplicativo. Esta pasta de trabalho permite que os administradores monitorem solicitações de autenticação para aplicativos em seus locatários. Ele fornece os seguintes recursos principais:
- Configure a pasta de trabalho para monitorar todos ou aplicativos individuais com dados quase em tempo real.
- Configure alertas para alterações de padrão de autenticação para que você possa investigar e responder.
- Compare as tendências ao longo de um período de tempo. Semana após semana é a configuração padrão da pasta de trabalho.
Nota
Veja todas as pastas de trabalho disponíveis e os pré-requisitos para usá-las em Como usar pastas de trabalho do Azure Monitor para relatórios.
Durante um evento afetante, duas coisas podem acontecer:
- O número de entradas para um aplicativo pode cair abruptamente quando os usuários não conseguem entrar.
- O número de falhas de início de sessão pode aumentar.
Pré-requisitos
- Um locatário do Microsoft Entra.
- Um usuário atribuiu pelo menos a função de Administrador de Segurança .
- Um espaço de trabalho do Log Analytics em sua assinatura do Azure para enviar logs para logs do Azure Monitor. Saiba como criar um espaço de trabalho do Log Analytics.
- Logs do Microsoft Entra integrados com logs do Azure Monitor. Saiba como integrar os logs de entrada do Microsoft Entra com o Azure Monitor Stream.
Configurar a pasta de trabalho de integridade de entrada do aplicativo
Para acessar pastas de trabalho no portal do Azure, selecione Microsoft Entra ID, selecione Pastas de trabalho.
As pastas de trabalho aparecem em Uso, Acesso Condicional e Solução de Problemas. A pasta de trabalho de integridade de login do aplicativo aparece na seção Integridade . Depois de usar uma pasta de trabalho, ela pode aparecer na seção Pastas de trabalho modificadas recentemente.
Você pode usar a pasta de trabalho de integridade de entrada do aplicativo para visualizar o que está acontecendo com seus logins. Como mostrado na captura de tela a seguir, a pasta de trabalho apresenta dois gráficos.
Na captura de tela anterior, há dois gráficos:
- Utilização horária (número de utilizadores bem-sucedidos). Comparar o número atual de usuários bem-sucedidos com um período de uso típico ajuda você a identificar uma queda no uso que pode exigir investigação. Uma taxa de uso bem-sucedida pode ajudar a detetar problemas de desempenho e utilização que a taxa de falha não consegue detetar. Por exemplo, quando os usuários não conseguem acessar seu aplicativo para tentar entrar, há uma queda no uso, mas sem falhas. Consulte a consulta de exemplo para esses dados na próxima seção deste artigo.
- Taxa de falha horária. Um pico na taxa de falhas pode indicar um problema com seus mecanismos de autenticação. As medidas de taxa de falha só aparecem quando os usuários podem tentar autenticar. Quando os usuários não conseguem obter acesso para fazer a tentativa, não há falhas.
Configurar a consulta e os alertas
Você cria regras de alerta no Azure Monitor e pode executar automaticamente consultas salvas ou pesquisas de log personalizadas em intervalos regulares. Você pode configurar um alerta que notifica um grupo específico quando a taxa de uso ou falha excede um limite especificado.
Use as instruções a seguir para criar alertas por e-mail com base nas consultas refletidas nos gráficos. Os scripts de exemplo enviam uma notificação por e-mail quando:
- O uso bem-sucedido cai em 90% em relação à mesma hora dois dias atrás, como mostrado no exemplo de gráfico de uso horário anterior.
- A taxa de falha aumenta em 90% em relação à mesma hora dois dias atrás, como mostrado no exemplo de gráfico de taxa de falha horária anterior.
Para configurar a consulta subjacente e definir alertas, conclua as etapas a seguir usando a consulta de exemplo como base para sua configuração. A descrição da estrutura da consulta aparece no final desta seção. Saiba como criar, exibir e gerenciar alertas de log usando o Azure Monitor em Gerenciar alertas de log.
Na pasta de trabalho, selecione Editar , conforme mostrado na captura de tela a seguir. Selecione o ícone de consulta no canto superior direito do gráfico.
Exiba o log de consultas conforme mostrado na captura de tela a seguir.
Copie um dos seguintes scripts de exemplo para uma nova consulta Kusto.
Cole a consulta na janela. Selecione Executar. Procure a mensagem Concluído e os resultados da consulta, conforme mostrado na captura de tela a seguir.
Realce a consulta. Selecione + Nova regra de alerta.
Configure as condições de alerta. Conforme mostrado na captura de tela de exemplo a seguir, na seção Condição , em Medição, selecione Linhas da tabela para Medida. Selecione Contagem para Tipo de agregação. Selecione 2 dias para Granularidade de agregação.
- Linhas da tabela. Você pode usar o número de linhas retornadas para trabalhar com eventos como logs de eventos do Windows, Syslog e exceções de aplicativos.
- Tipo de agregação. Pontos de dados aplicados com Count.
- Granularidade de agregação. Este valor define o período que trabalha com Frequência de avaliação.
Em Alert Logic, configure os parâmetros conforme mostrado na captura de tela de exemplo.
- Valor limite: 0. Este valor alerta sobre quaisquer resultados.
- Frequência da avaliação: 1 hora. Este valor define o período de avaliação como uma vez por hora para a hora anterior.
Na seção Ações, defina as configurações conforme mostrado na captura de tela de exemplo.
- Selecione Selecionar grupo de ações e adicione o grupo para o qual deseja receber notificações de alerta.
- Em Personalizar ações, selecione Alertas por email.
- Adicione uma linha de assunto.
Na seção Detalhes, defina as configurações conforme mostrado na captura de tela de exemplo.
- Adicione um nome de Subscrição e uma descrição.
- Selecione o grupo de recursos ao qual você deseja adicionar o alerta.
- Selecione a gravidade padrão.
- Selecione Ativar após a criação se quiser que ele entre em operação imediatamente. Caso contrário, selecione Silenciar ações.
Na seção Revisão + criação, defina as configurações conforme mostrado na captura de tela de exemplo.
Selecione Guardar. Insira um nome para a consulta. Para Salvar como, selecione Consulta. Em Categoria, selecione Alerta. Novamente, selecione Salvar.
Refine suas consultas e alertas
Para modificar as suas consultas e alertas para obter a máxima eficácia:
- Teste sempre os alertas.
- Modifique a sensibilidade e a frequência do alerta para receber notificações importantes. Os administradores podem ficar insensíveis a alertas e perder algo importante se receberem muitos.
- Nos clientes de email do administrador, adicione o e-mail do qual os alertas chegam à lista de remetentes permitidos. Essa abordagem evita notificações perdidas devido a um filtro de spam em seus clientes de e-mail.
- Por design, as consultas de alerta no Azure Monitor só podem incluir resultados das últimas 48 horas.
Scripts de amostra
Consulta Kusto para aumento na taxa de falha
Na consulta a seguir, detetamos taxas de falha crescentes. Conforme necessário, você pode ajustar a proporção na parte inferior. Representa a variação percentual no tráfego na última hora em comparação com o tráfego de ontem no mesmo horário. Um resultado de 0,5 indica uma diferença de 50% no tráfego.
let today = SigninLogs
| where TimeGenerated > ago(1h) // Query failure rate in the last hour
| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")
// Optionally filter by a specific application
//| where AppDisplayName == **APP NAME**
| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate
| project TimeGenerated, failureRate = (failure * 1.0) / ((failure + success) * 1.0)
| sort by TimeGenerated desc
| serialize rowNumber = row_number();
let yesterday = SigninLogs
| where TimeGenerated between((ago(1h) – totimespan(1d))..(now() – totimespan(1d))) // Query failure rate at the same time yesterday
| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")
// Optionally filter by a specific application
//| where AppDisplayName == **APP NAME**
| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate at same time yesterday
| project TimeGenerated, failureRateYesterday = (failure * 1.0) / ((failure + success) * 1.0)
| sort by TimeGenerated desc
| serialize rowNumber = row_number();
today
| join (yesterday) on rowNumber // join data from same time today and yesterday
| project TimeGenerated, failureRate, failureRateYesterday
// Set threshold to be the percent difference in failure rate in the last hour as compared to the same time yesterday
// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.
| extend day = dayofweek(now())
| where day != time(6.00:00:00) // exclude Sat
| where day != time(0.00:00:00) // exclude Sun
| where day != time(1.00:00:00) // exclude Mon
| where abs(failureRate – failureRateYesterday) > 0.5
Consulta Kusto para queda no uso
Na consulta a seguir, comparamos o tráfego da última hora com o tráfego de ontem ao mesmo tempo. Excluímos sábado, domingo e segunda-feira porque esperamos grande variabilidade no tráfego do dia anterior ao mesmo tempo.
Conforme necessário, você pode ajustar a proporção na parte inferior. Representa a variação percentual no tráfego na última hora em comparação com o tráfego de ontem no mesmo horário. Um resultado de 0,5 indica uma diferença de 50% no tráfego. Ajuste esses valores para se adequar ao seu modelo de operação de negócios.
Let today = SigninLogs // Query traffic in the last hour
| where TimeGenerated > ago(1h)
| project TimeGenerated, AppDisplayName, UserPrincipalName
// Optionally filter by AppDisplayName to scope query to a single application
//| where AppDisplayName contains "Office 365 Exchange Online"
| summarize users = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr) // Count distinct users in the last hour
| sort by TimeGenerated desc
| serialize rn = row_number();
let yesterday = SigninLogs // Query traffic at the same hour yesterday
| where TimeGenerated between((ago(1h) – totimespan(1d))..(now() – totimespan(1d))) // Count distinct users in the same hour yesterday
| project TimeGenerated, AppDisplayName, UserPrincipalName
// Optionally filter by AppDisplayName to scope query to a single application
//| where AppDisplayName contains "Office 365 Exchange Online"
| summarize usersYesterday = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr)
| sort by TimeGenerated desc
| serialize rn = row_number();
today
| join // Join data from today and yesterday together
(
yesterday
)
on rn
// Calculate the difference in number of users in the last hour compared to the same time yesterday
| project TimeGenerated, users, usersYesterday, difference = abs(users – usersYesterday), max = max_of(users, usersYesterday)
| extend ratio = (difference * 1.0) / max // Ratio is the percent difference in traffic in the last hour as compared to the same time yesterday
// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.
| extend day = dayofweek(now())
| where day != time(6.00:00:00) // exclude Sat
| where day != time(0.00:00:00) // exclude Sun
| where day != time(1.00:00:00) // exclude Mon
| where ratio > 0.7 // Threshold percent difference in sign-in traffic as compared to same hour yesterday
Criar processos para gerenciar alertas
Depois de configurar consultas e alertas, crie processos de negócios para gerenciar os alertas.
- Quem monitoriza o livro e quando?
- Quando ocorrem alertas, quem os investiga?
- Quais são as necessidades de comunicação? Quem cria as comunicações e quem as recebe?
- Quando ocorre uma interrupção, quais processos de negócios se aplicam?
Próximos passos
Saiba mais sobre pastas de trabalho