Melhor desempenho e segurança monitorando logs, métricas e muito mais

No artigo anterior desta série — The Everything Guide to Data Collection in DevSecOps — discutimos a importância da coleta de dados. Neste artigo, exploraremos a função do monitoramento na observabilidade, especialmente no que se refere à segurança, desempenho e confiabilidade.

O monitoramento é essencial para detectar problemas e discrepâncias à medida que ocorrem na produção e permite que as equipes de DevSecOps identifiquem e resolvam os problemas antes que causem danos graves. O monitoramento de degradações de desempenho ou atividades suspeitas pode resultar em alertas e respostas automáticas para isolar possíveis problemas ou ataques.

Neste artigo, veremos o monitoramento em detalhes, forneceremos vários casos de uso e práticas recomendadas e discutiremos como o monitoramento pode melhorar especificamente a segurança, o desempenho e a confiabilidade por meio da observabilidade.

Qual é o papel do monitoramento na observabilidade?

Em um sistema observável, coletamos dados de logs, métricas e rastreamentos distribuídos. E enquanto para sistemas muito pequenos você pode navegar manualmente e pesquisar os logs, visualizar as métricas como gráficos e rastrear através de diagramas mostrando como o tráfego flui pelo sistema para identificar problemas - em escala, isso não é suficiente. Você precisa de monitoramento, um processo automatizado que fique de olho nesses dados e o alerte adequadamente. (Para um tratamento mais detalhado sobre a diferença entre monitoramento e observabilidade, você pode conferireste recurso .)

Em uma empresa, você precisa de maneiras automatizadas de filtrar, agregar, enriquecer e analisar todos esses dados. As empresas também precisam de formas automatizadas de agir quando algo incomum é detectado. A resposta automatizada pode notificar a equipe responsável ou até mesmo tomar medidas corretivas diretamente.

Em outras áreas, como a medicina, monitorar os sinais vitais dos pacientes é uma atividade fundamental, que salva vidas. O monitoramento de sistemas de software é muito semelhante e até usamos a mesma metodologia ao realizar verificações de integridade e discutir a integridade de diferentes componentes.

Chega de teoria, vamos ver alguns exemplos concretos de monitoramento.

Casos de uso de monitoramento para observabilidade

Aqui estão alguns casos de uso típicos que aproveitam o monitoramento:

• Os aplicativos da Web são uma parte importante de muitos sistemas distribuídos de grande escala e a chave para o sucesso dos negócios que priorizam o digital. O monitoramento de aplicativos conteinerizados do Kubernetes ou simplesmente os logs do servidor da web para uma aparência excessiva de códigos de erro (como 4xx ou 5xx ) pode ajudar uma equipe a resolver problemas de desempenho e confiabilidade antes que se tornem problemas significativos.
• No nível da infraestrutura, é importante monitorar a CPU, a memória e o armazenamento de seus servidores. Como a maioria das empresas, você provavelmente está usando dimensionamento automático para que seu sistema possa alocar mais capacidade. Os logs da plataforma são capturados quando há alterações nos recursos, como quando eles são provisionados, desprovisionados ou reconfigurados. No entanto, monitorar essas métricas e logs de recursos pode ajudá-lo a garantir que você esteja trabalhando dentro das cotas e limites e pode ajudar sua organização quando se trata de planejamento e orçamento de recursos.
• Os armazenamentos de dados estão no centro da maioria dos sistemas de grande escala. Se seus dados forem perdidos, corrompidos ou indisponíveis, você terá uma situação séria em mãos. Para acompanhar seus dados, você precisa monitorar conexões de banco de dados, métricas de duração de consulta, espaço em disco, backups e taxas de erro. Você também deve entender seus armazenamentos de dados e definir alertas quando observar valores fora do intervalo esperado, como consultas lentas, alta taxa de erros ou pouco espaço em disco. Você também pode configurar o log para seus bancos de dados para capturar conexões, consultas e alterações em campos ou tabelas. Monitorar os logs do banco de dados pode ajudá-lo a detectar não apenas onde você pode melhorar seu desempenho e confiabilidade, mas também a segurança se operações maliciosas (ou não intencionais) estiverem sendo executadas.

Observe que o monitoramento envolve muito mais do que definir uma condição simples (como “mais de cinco consultas INSERT ao banco de dados de orders em dois minutos”) e disparar um alerta quando essa condição for atendida. A sazonalidade pode estar em jogo, com padrões de uso que causam picos em determinados momentos do dia, semana ou ano. O monitoramento eficaz que detecta comportamentos inesperados leva em consideração o contexto e pode reconhecer tendências com base em dados anteriores.

Esse tipo de monitoramento, principalmente quando implementado com uma ferramenta que combina observabilidade, monitoramento e segurança em escala, pode ser imensamente eficaz, como neste estudo de caso da Sumo Logic e da Infor, onde a Infor conseguiu economizar 5.000 horas de tempo gasto em incidentes.

Como o monitoramento contribui especificamente para melhorar o desempenho e a confiabilidade?

O monitoramento melhora o desempenho e a confiabilidade de um sistema, detectando problemas antecipadamente para evitar a degradação. Os problemas de desempenho geralmente se tornam problemas de disponibilidade e confiabilidade. Isso é especialmente verdadeiro na presença de tempos limite. Por exemplo, suponha que um aplicativo atinja o tempo limite após 60 segundos. Devido a um problema de desempenho recente, muitas solicitações demoram mais de 60 segundos para serem processadas. Todas essas solicitações agora falharão e o aplicativo agora não é confiável.

Uma prática recomendada comum para lidar com isso é monitorar os quatro sinais de ouro de qualquer componente no caminho crítico de serviços e aplicativos de alta prioridade: latência, tráfego, erros e saturação.

Latência

Quanto tempo leva para processar uma solicitação? Observe que a latência de solicitações bem-sucedidas pode ser diferente de solicitações com falha. Qualquer aumento significativo na latência pode indicar a degradação do desempenho do sistema. Por outro lado, qualquer diminuição significativa pode ser um sinal de que algum processamento foi ignorado. De qualquer forma, o monitoramento chamará a atenção para o possível problema.

Tráfego

O monitoramento do tráfego fornece uma compreensão da carga geral em cada componente. O tráfego pode ser medido de diferentes maneiras para diferentes componentes. Por exemplo:

• API REST: o número de solicitações
• Um serviço de back-end: a profundidade de uma fila
• Um componente de processamento de dados: o total de bytes de dados processados.

Um aumento no tráfego pode ser devido ao crescimento orgânico dos negócios, o que é bom. No entanto, também pode apontar para um problema em um sistema upstream que gera mais tráfego do que antes.

Erros

Um aumento nas taxas de erro de qualquer componente afeta diretamente a confiabilidade e a utilidade do sistema. Além disso, se as opções com falha forem desativadas automaticamente, isso pode levar a um aumento no tráfego e, posteriormente, a problemas de desempenho.

Saturação

Dos recursos disponíveis, quanto o serviço ou aplicativo está gastando? Isso é o que o monitoramento de saturação informa. Por exemplo, se um disco estiver cheio, um serviço que grava logs nesse disco falhará em todas as solicitações subsequentes. Em um nível superior, se um cluster Kubernetes não tiver espaço disponível em seus nós, novos pods ficarão pendentes e não agendados, o que pode levar a problemas de latência.

Como você percebe, os quatro sinais dourados estão relacionados entre si. Os problemas geralmente se manifestam em vários sinais.

Como o monitoramento contribui especificamente para melhorar a segurança?

Embora qualquer problema de integridade do sistema possa impactar direta ou indiretamente a segurança, existem algumas ameaças diretas que o monitoramento pode ajudar a detectar e mitigar.

• Qualquer anomalia, como uso excessivo de CPU ou alto volume de solicitações, pode ser um invasor tentando causar falhas de segmentação, realizar mineração ilegal de criptografia ou iniciar um ataque DDoS no sistema.
• Um número incomum de pacotes atingindo portas incomuns pode ser um ataque de batida de porta .
• Um alto número de erros 401 (erros de autenticação) com nomes de usuário válidos e senhas inválidas pode ser um ataque de dicionário.
• Um alto número de erros 403 (acesso proibido) pode ser uma escalação de privilégio por um invasor usando uma conta comprometida.
• Cargas inválidas para APIs públicas, resultando em um aumento de 400 erros, podem ser um invasor tentando travar maliciosamente seus aplicativos da Web voltados para o público.
• Um download de grandes quantidades de dados ou de quaisquer dados confidenciais fora do horário comercial pode ser um ataque de exfiltração por parte de um funcionário comprometido ou de um insider desonesto.

Melhores práticas de monitoramento para melhorar o desempenho e a segurança

Um sistema é feito de múltiplos componentes, mas é mais do que a soma de suas partes. Em um nível básico, você deve monitorar cada componente do seu sistema (pelo menos nos caminhos críticos) para os quatro sinais de ouro . O que isso significa na prática?

• Observando as principais métricas
• Estabelecendo as faixas métricas para operação normal
• Definindo alertas quando os componentes se desviam do intervalo aceitável

Você também deve prestar muita atenção às dependências externas . Por exemplo, se você executar na nuvem ou se integrar a um provedor de serviços terceirizado, deverá monitorar os endpoints públicos dos quais depende e definir alertas para detectar problemas. Se um terceiro estiver inoperante ou seu desempenho for degradado, isso pode causar uma falha em cascata em seu sistema.

Não é possível ter componentes 100% confiáveis. No entanto, o monitoramento pode ajudá-lo a criar um sistema confiável a partir de componentes não confiáveis, detectando problemas com os componentes — tanto internos quanto externos — e substituindo-os ou degradando graciosamente o serviço . Por exemplo, se você estiver executando seu sistema em uma configuração de várias zonas e houver um problema em uma zona, o monitoramento poderá detectar isso e acionar o reencaminhamento (manual ou automaticamente) de todo o tráfego para outras zonas.

Por segurança, os quatro sinais também podem ser indicadores auxiliares de um compromisso . Esse é especialmente o caso, por exemplo, se você observar um aumento no dispositivo de endpoint ou nas CPUs de carga de trabalho na nuvem ou um aumento no número de tentativas de login com falha. No entanto, o monitoramento de segurança deve ser muito deliberado, pois você lida com adversários mal-intencionados. Você deve definir o serviço de ataque de cada componente e de todo o sistema e garantir que as informações coletadas sejam suficientes para detectar problemas . Por exemplo, para detectar a exfiltração de dados, você pode monitorar os endereços IP e a quantidade de dados enviados para fora de sua rede interna por diferentes aplicativos e serviços. Se você não tiver esses dados, ficará cego para essa metodologia de ataque.

Implementando uma Estratégia de Monitoramento

Depois de configurar sua coleta de dados, você pode seguir as etapas abaixo para implantar uma estratégia de monitoramento robusta e eficaz.

1. Identificar ativos críticos.

Você já realizou um inventário abrangente de todos os seus ativos como parte da coleta de dados. Agora, sua tarefa é identificar os ativos críticos que devem ser monitorados de perto para prevenir e mitigar desastres. É fácil dizer “basta monitorar tudo”, mas há custos a serem considerados com o monitoramento. Monitorar e gerar alertas para seus ambientes de preparação e desenvolvimento ou serviços experimentais pode sobrecarregar seus engenheiros de forma desnecessária. Alertas frequentes às 3 da manhã para problemas insignificantes causarão fadiga de alerta, prejudicando a motivação de sua equipe para resolver um problema quando ele realmente importa.

2. Atribua um proprietário para cada ativo crítico.

Depois de identificar os ativos críticos, você precisa de um proprietário claro para cada um. O proprietário pode ser uma pessoa ou uma equipe. No caso de uma pessoa, certifique-se de identificar também um substituto. Também é importante manter a propriedade dos ativos à medida que as pessoas ingressam e saem da organização ou mudam para outras funções e equipes.

3. Defina alertas para ativos críticos.

Em última análise, sua estratégia de monitoramento viverá ou morrerá com base em como você define alertas para ativos que não estão íntegros ou potencialmente comprometidos. Você precisa entender o que é normal para cada ativo.

Se você estiver monitorando métricas, definir “normal” significa associar um atributo (como a utilização da CPU) a um intervalo de valores (como “50%-80%”). A banda normal pode mudar dinamicamente com o negócio e pode variar em diferentes momentos e diferentes locais. Em alguns casos, você pode ter apenas tetos ou pisos. Ao definir intervalos normais, você cria alertas para notificar um proprietário de ativo quando seu ativo está operando fora do intervalo normal.

Se você estiver monitorando logs, os alertas geralmente são definidos com base no resultado de determinadas consultas de log (como "número de erros 404 registrados em todos os serviços de API nos últimos cinco minutos") satisfazendo ou falhando uma condição (como "é menos de 10”). As ferramentas de gerenciamento e análise de logs podem ajudar.

4. Defina runbooks para cada alerta.

Quando um alerta crítico dispara, o que você faz? O que você não quer fazer é tentar descobrir sua estratégia no local, enquanto os clientes estão tuitando sobre os produtos não confiáveis de sua empresa e a administração está em pânico.

Um runbook é uma receita de etapas fáceis de seguir que você prepara e testa com antecedência para ajudá-lo a coletar informações adicionais (por exemplo, quais painéis examinar e quais scripts de linha de comando executar para diagnosticar a causa raiz) e mitigar ações (por exemplo, implantar a versão anterior do aplicativo). Seu runbook deve ajudá-lo a identificar rapidamente o problema para um problema específico e identificar a melhor pessoa para lidar com isso.

5. Configure um processo de plantão.

Você tem proprietários, alertas e runbooks. Frequentemente, os alertas não são específicos o suficiente para serem mapeados diretamente para os proprietários. A melhor prática é designar engenheiros de plantão para diferentes áreas da empresa. Esse engenheiro de plantão receberá o alerta, seguirá o runbook, examinará o painel e tentará entender a causa raiz. Se eles não conseguirem entender ou resolver o problema, eles o encaminharão ao proprietário. Lembre-se de que esse processo pode ser complicado; muitas vezes, um problema ocorre devido a uma cadeia de falhas que exige que várias partes interessadas colaborem para resolver o problema.

6. Mova-se para a autocura.

Runbooks são ótimos, mas manter runbooks complexos e treinar engenheiros de plantão para segui-los exige muito esforço. E, no final, seu processo de correção ainda depende de um ser humano lento e sujeito a erros. Se o seu runbook não estiver atualizado, segui-lo pode piorar a crise.

Teoricamente, um runbook pode ser executado programaticamente. Se o runbook disser: "quando o alerta X dispara, o processo Y deve reiniciar", um script ou programa pode receber uma notificação do alerta X e reiniciar o processo Y. O mesmo programa pode monitorar o processo Y após a reinicialização, garantir que tudo esteja bem, e eventualmente gerar um relatório do incidente - tudo sem acordar o engenheiro de plantão. Se a ação de autocorreção falhar, o engenheiro de plantão poderá ser contatado.

7. Estabeleça um processo post mortem.

A autocura é incrível, no entanto, um grama de prevenção vale um quilo de cura, então é melhor prevenir problemas em primeiro lugar. Cada incidente é uma oportunidade para aprender e possivelmente prevenir toda uma classe de problemas. Por exemplo, se ocorrerem vários incidentes porque o código com erros segue para a produção, uma lição dos post-mortems de incidentes pode ser melhorar os testes na preparação. Se a resposta do engenheiro de plantão a um alerta for muito lenta ou se o runbook estiver desatualizado, isso pode sugerir que a equipe deva investir em algumas práticas de autocorreção.

Conclusão

O monitoramento é uma parte crucial da observabilidade em geral e da observabilidade para segurança em particular. É impraticável em grande escala para os humanos “apenas olhar de vez em quando” para vários painéis e gráficos para detectar problemas. Você precisa de um conjunto completo de práticas de resposta a incidentes que incluem identificação de proprietários, configuração de alertas, escrita de runbooks, automação de runbooks e configuração de processos de plantão e processos post mortem.

Tenha um ótimo dia!