Serviço de Logs de Auditoria em Nuvem: Arquitetura e Valor para Usuários

32K+ Cobertura em 30 dias MWS Cloud 123,63 Classificação 63 768 Assinantes Assinar tsaanstu Há 47 minutos Serviço de Logs de Auditoria em Nuvem: Arquitetura e Valor para Usuários Simples 14 min 1.6K Blog da empresa MWS Cloud Desenvolvimento de nuvens públicas * Segurança da Informação * Armazenamento de Dados * Administração de Servidores * Visão geral À primeira vista, a tarefa parece simples: é preciso registrar um evento e fornecer uma interface para visualizá-lo. Mas, na prática, há muitas soluções de engenharia interessantes por trás disso: como selecionar eventos, armazená-los, dimensionar o sistema e não perder dados em caso de falha. E como tornar o serviço útil tanto para especialistas em segurança da informação quanto para usuários comuns. Olá! Sou Vladimir Atasunts, chefe da Security Services na MWS Cloud Platform. Neste artigo, falarei sobre o serviço de logs de auditoria — uma ferramenta básica da nuvem para controlar ações com recursos e analisar alterações na infraestrutura. Analisarei: por que exatamente esse serviço é necessário e quais cenários de uso ele prevê; como ele se parece do ponto de vista do modelo de produto; quais requisitos foram a base do projeto do sistema; como o ciclo de vida do evento se refletiu na arquitetura e de quais componentes ela consiste. Vamos passo a passo — de cenários de negócios à implementação técnica. O que é um serviço de logs de auditoria Vamos começar com um exemplo simples. Imagine que você é um administrador de um espaço em nuvem. De manhã, você criou uma máquina virtual. À noite, você volta — e algo aconteceu com ela: alguém adicionou núcleos, alguém a desligou. Há colegas na equipe, muitos acessos, mais ações ainda. Há perguntas básicas: o que exatamente aconteceu e quem fê-lo? A resposta a isso é dada pelos logs de auditoria. Logs de auditoria são um registro de: qual ação foi executada; quem executou a ação; quando isso aconteceu; e como tudo terminou (sucesso ou erro). Essas informações permitem que você restaure a sequência de eventos e entenda o que estava acontecendo na infraestrutura. Agora, vamos falar sobre os principais consumidores do serviço — em nossa opinião, são especialistas em segurança da informação: engenheiros de segurança da informação, analistas, arquitetos, equipes SOC. Para eles, esta é uma ferramenta de trabalho para cumprir os requisitos regulatórios, monitorar eventos de segurança e analisar incidentes post-factum. Ao mesmo tempo, os logs de auditoria são importantes não apenas para a segurança da informação. Eles também são usados por engenheiros que precisam entender rapidamente a causa das alterações na infraestrutura — por exemplo, quem e por qual ação parou o cluster ou alterou a configuração do recurso. Para nós, como uma nuvem, além de usuários externos, também há consumidores internos — a equipe que desenvolve essa nuvem. É importante para nós entender o que está acontecendo dentro da infraestrutura: para análise, para cumprir os requisitos internos, para investigar incidentes e para diagnóstico operacional. Na verdade, usamos a mesma ferramenta para as mesmas tarefas que nossos usuários: para ver as alterações, rastrear ações suspeitas e entender os problemas mais rapidamente. Visão do produto: modelo básico do serviço de logs de auditoria Hoje, o serviço de logs de auditoria é um must-have para qualquer nuvem. Essas soluções existem para provedores ocidentais, asiáticos e russos. Não reinventamos a roda: analisamos as abordagens existentes, escolhemos o modelo mais maduro e o adaptamos às realidades russas, nossa arquitetura e cenários de produtos. Na forma mais simples, a tarefa do serviço é a seguinte: há muitos fontes de eventos na nuvem, e eles precisam ser coletados em algum lugar e armazenados em algum lugar. Internamente, chamamos isso de armazenamento comum — um armazenamento geral onde os eventos de toda a nuvem fluem. As nuances começam mais tarde — quando você precisa dar aos usuários acesso gerenciado a esses eventos. Para isso, introduzimos duas entidades separadas — um coletor e um armazenamento. Coletor (Collector). Necessário para que o usuário possa controlar quais eventos coletar. Permite selecionar de todo o volume de eventos disponíveis apenas aqueles que realmente interessam ao usuário. No Google Cloud, um recurso semelhante é chamado Sink. Exemplo de cenário — os eventos de criação de máquinas virtuais não são importantes para o usuário, mas a exclusão de uma VM ou cluster Kubernetes é crítica. Armazenamento (Storage). Um recurso no qual os eventos caem após a filtragem. É ele quem é responsável por onde os dados serão armazenados ou para onde serão descarregados. Decidimos deliberadamente destacar o armazenamento em uma entidade separada e não combiná-lo com o coletor. O coletor é responsável pela seleção de eventos, e o armazenamento é responsável por seu armazenamento ou carregamento posterior. Essa separação oferece flexibilidade: você pode desenvolver de forma independente a lógica de roteamento de eventos e os métodos de armazenamento. Por meio da configuração do coletor, o usuário pode primeiro escolher o armazenamento de dados no armazenamento de logs de auditoria e, se desejar, após algum tempo, mudar o armazenamento para um sistema externo. No Google Cloud, o análogo é chamado log bucket, mas não gostamos da interseção com a entidade S3 bucket do serviço Object Storage — armazenamento compatível com S3 da plataforma MWS Cloud, por isso simplificamos a nomenclatura. Requisitos para o projeto do sistema do serviço de logs de auditoria Ao iniciar o desenvolvimento do projeto do sistema, nos baseamos em requisitos técnicos, cenários de negócios e no modelo de produto. Na arquitetura da nuvem, separamos o Control Plane e o Data Plane. O Control Plane é responsável por armazenar a configuração de objetos, implementar a API e o modelo de recursos. O Data Plane é responsável por executar ações. Por exemplo, o Control Plane salva a configuração da máquina virtual e a transfere para o Data Plane, que já cria a VM. Eventos de auditoria podem ser gerados em ambos os níveis. Abaixo, consideraremos os requisitos para o projeto do serviço — de técnicos à necessidade de um armazenamento centralizado. Requisitos técnicos Para entender o que está acontecendo na infraestrutura, os eventos precisam ser gerados, entregues e armazenados de forma confiável. Tínhamos os seguintes requisitos: Alta performance de gravação . O fluxo de eventos é grande e está em constante crescimento. No início, estabelecemos uma meta de 100k RPS. Para uma nuvem jovem, este é um número sério, mas queríamos construir a arquitetura com uma margem. Performance de leitura adequada . O usuário não deve esperar cinco minutos até que os eventos sejam carregados. Especialmente no cenário de investigação de incidentes, onde você tem que constantemente filtrar e refinar a seleção. Não fixamos um SLA rígido, mas nos concentramos em segundos em uma solicitação típica — idealmente, cerca de cinco. Em casos complexos com grande profundidade de armazenamento, as solicitações podem levar dezenas de segundos, mas este é um cenário atípico. Escala e baixo custo de armazenamento . Há muitas fontes de eventos: muitos serviços, ainda mais recursos do usuário, ainda mais usuários. Todos estão fazendo algo. Ao mesmo tempo, esses dados precisam ser armazenados por muito tempo, por exemplo, para fins de conformidade. Isso significa que a solução deve fornecer baixo custo de armazenamento. Alta confiabilidade . Considerando os requisitos acima, o serviço deve fornecer um fluxo contínuo de gravação de eventos, estar pronto para problemas de infraestrutura e crescimento inesperado da carga, e ser facilmente escalável. Modelo de recursos A próxima etapa é projetar o modelo de recursos do serviço e entender como os objetos interagirão entre si. Evento , o objeto principal. Pode haver muitos deles. O evento contém todas as informações necessárias: quem, o quê, quando e em qual recurso fez. Armazenamento . Já escrevi sobre isso, mas é importante registrar as características aqui. O Storage pode ter uma limitação de volume — ou pode não ter. Depende das necessidades do cliente. Você também pode limitar o período de armazenamento. Por exemplo: no máximo 10 GB por 10 dias. Coletor — determina quais eventos devem ser coletados e para qual armazenamento eles devem ser enviados. Com o modelo de recursos do próprio serviço, descobrimos — agora precisamos entender como ele se encaixa no modelo de nuvem. O primeiro contêiner de recursos que o usuário encontra é a organização . É importante entender que eventos também podem ocorrer nesse nível. Por exemplo, adicionar um usuário também é um evento que queremos registrar. Abaixo está o projeto — o principal contêiner de trabalho para usuários. É dentro do projeto que as máquinas virtuais, clusters Kubernetes são implantados, e nossos armazenamentos e coletores também são criados. Há também um cenário de descarregamento para armazenamento externo. Por exemplo, no Object Storage de nossa nuvem. Esta é uma opção bastante simples, e nós a suportamos. Modelo de recursos. Cenário básico A necessidade de um armazenamento centralizado Agora, vamos considerar uma opção mais complexa. Vamos imaginar um grande cliente com uma dúzia de projetos. Criar um armazenamento separado em cada projeto e lidar com eles é inconveniente. É muito mais lógico ter um armazenamento centralizado único, onde os eventos de todos os projetos fluirão e, se necessário, do nível da organização. Por exemplo, você pode criar um projeto de segurança separado — o condicional Project Sec — e colocar um armazenamento comum nele. Eventos de outros projetos serão enviados para lá. O acesso a este projeto pode ser concedido apenas à equipe de segurança, que está envolvida em monitoramento e análise. Do ponto de vista do modelo de recursos, este é o mesmo armazenamento , apenas mais eventos entram nele. Ao mesmo tempo, surge a questão do acesso entre projetos. Nem todo coletor pode ler eventos em um projeto vizinho ou escrever em um armazenamento de outra pessoa. Portanto, o coletor tem uma característica adicional — uma conta de serviço, em nome da qual as operações de leitura e gravação são executadas. Isso permite que você delimite corretamente o acesso. A lógica é semelhante ao Object Storage: apenas quem tem direitos pode escrever. Modelo de recursos. Cenário entre projetos Mapeamento do ciclo de vida do evento na arquitetura do serviço de logs de auditoria Ao desenvolver a arquitetura, dividimos o ciclo de vida do evento em quatro etapas: Geração. Coleta e entrega. Armazenamento. Acesso. Geração de eventos Tudo começa com a geração. Alguém deve informar ao serviço que um evento ocorreu. E você precisa fazer isso em um formato único e com um conjunto completo de dados — não são dois ou três campos, mas uma quantidade bastante grande de informações. Como a infraestrutura não é monolítica e consiste em muitos serviços, cada um deles deve ser capaz de gerar e transferir eventos. Na fase de projeto do sistema, decidimos implementar nossa própria biblioteca — na verdade, um SDK, que os serviços da nuvem conectam. Poderíamos, por exemplo, seguir o caminho clássico com a API REST e enviar eventos diretamente. Mas a decisão foi influenciada pelas características de nossa infraestrutura. Trabalhamos no Kubernetes, os serviços são implantados em vários clusters. Falhas, problemas de rede e reinicializações de nós são possíveis. Precisamos minimizar o impacto dessas situações na qualidade do serviço. Enviar eventos de forma síncrona é uma má opção. Se, no momento em que o usuário cria uma máquina virtual, houver um problema com a rede no nível da infraestrutura da nuvem e o serviço começar a repetir o registro de auditoria periodicamente, o usuário terá que esperar. Envio em segundo plano sem bufferização também é um risco. Ao reiniciar o nó, o evento pode ser perdido. Como resultado, escolhemos uma abordagem com gravação local de eventos em disco. O serviço, por meio da biblioteca, grava o evento em um arquivo, e um componente separado lê esses arquivos e envia os dados ainda mais. Assim, separamos a operação do usuário da entrega da rede. A biblioteca encapsula toda essa lógica — os serviços não precisam implementá-la sozinhos. Coleta e entrega de eventos Após a geração de eventos, surge a próxima tarefa — coletar dados de diferentes clusters e entregá-los a um único armazenamento. Não temos um cluster e não temos um serviço. Os serviços são distribuídos, os clusters são isolados uns dos outros, e os eventos são gerados em todos os lugares. É importante coletar cuidadosamente todo esse fluxo em um só ponto e, ao mesmo tempo, não sobrecarregar o sistema. Consideramos diferentes opções para organizar a fila. Inclusive, pensamos em nossa própria implementação, analisamos soluções clássicas e não típicas, mas, no final, paramos no Kafka. Ele nos permitiu: acumular o fluxo de eventos de todos os clusters; construir um modelo de consumo controlado; garantir alta performance de gravação. Armazenamento de eventos Agora era preciso decidir onde e como armazenar os dados. Lembramos de dois requisitos principais: baixo custo de armazenamento e alta performance de gravação. Ficou imediatamente claro que armazenar tudo em discos locais é caro. Portanto, já na fase de projeto do sistema, tomamos a decisão de construir o armazenamento em cima do Object Storage de nossa nuvem. Então começou a escolha da ferramenta. O primeiro candidato foi o ClickHouse — uma ferramenta familiar e compreensível com suporte para armazenamento compatível com S3 e um ecossistema maduro. Ele permite construir tabelas usando o Object Storage, no entanto, no cenário clássico de auto-gerenciamento, o ClickHouse copia os dados para o disco, o que não correspondia ao nosso objetivo de abandonar os discos. Também consideramos a replicação de cópia zero, onde principalmente metadados, e não os próprios dados, são sincronizados entre as réplicas, mas no momento do nosso projeto do sistema, este modo na documentação foi marcado como “não pronto para produção”. Não quisemos arriscar. Em seguida, olhamos para o Apache Iceberg. É importante entender que o Iceberg não é um banco de dados completo, mas uma camada de gerenciamento de dados tabulares em cima do Object Storage. Ele define como armazenar arquivos, como manter metadados e como garantir a consistência. A arquitetura do Iceberg pode ser condicionalmente dividida em quatro componentes. O primeiro é o próprio Object Storage, onde os arquivos de dados estão localizados. Escolhemos o formato Parquet — colunar, conveniente e bem suportado. O segundo é o catálogo de metadados. Ele armazena informações sobre tabelas, versões e relações entre arquivos. Consideramos várias opções e, no final, escolhemos Nessie — em nossa opinião, no momento do projeto da arquitetura, este era o catálogo mais maduro e conveniente para cenários de produção. O terceiro são os serviços de manutenção de tabelas. Estes são processos que excluem arquivos desatualizados, combinam arquivos pequenos em arquivos maiores e atualizam metadados. Isso é importante tanto para economizar espaço quanto para desempenho. Para essas tarefas, usamos o Spark — uma ferramenta comprovada que é adequada para manutenção em segundo plano de tabelas e processamento de dados no Iceberg. O quarto é o mecanismo para executar consultas que funciona com dados e metadados de tabelas Iceberg. Aqui, consideramos três opções: Trino, StarRocks e ClickHouse. Escolhemos StarRocks, explicarei os motivos mais tarde. Trino — um mecanismo de consulta poderoso e maduro com suporte para Iceberg e ferramentas de manutenção de tabelas. Mas ele tem uma característica arquitetônica: o coordenador não é escalável imediatamente. Existem soluções, mas são bastante complexas. StarRocks — um banco de dados analítico completo que pode funcionar em cima do Iceberg e é bem escalável. Em sua arquitetura, há nós de front-end que planejam a execução da solicitação e nós de computação que a executam. Se houver falta de recursos, a arquitetura permite adicionar horizontalmente os nós necessários. ClickHouse, apesar da simpatia pela ferramenta, no momento do projeto da arquitetura não forneceu o conjunto de operações que precisávamos em cima do Iceberg para implementar o pipeline completo. Como resultado, paramos no StarRocks. Acesso do usuário aos dados A etapa final do ciclo de vida do evento é fornecer ao usuário acesso conveniente aos dados. Para isso, temos o Control Plane, escrito em Kotlin. Ele implementa a API, suporta o modelo de recursos e permite que você execute consultas com os filtros especificados. O usuário interage com este nível. Dentro do Control Plane, ele se refere ao mecanismo de consulta e retorna o resultado. Talvez, no futuro, adicionemos nossa própria linguagem de consulta — por analogia com a forma como isso é implementado no Google. Por enquanto, nos limitamos a filtros e recursos de pesquisa predefinidos. Arquitetura do serviço de logs de auditoria: implementação na prática Como escrevi acima, a arquitetura do serviço reflete o ciclo de vida do evento. Abaixo, contarei como ela se parece na prática e de quais componentes ela consiste. Geração de eventos de auditoria Como mencionei acima, temos uma biblioteca com a qual os serviços registram eventos de auditoria. O backend, que vive no Kubernetes, conecta essa biblioteca, gera eventos e os grava em disco. Implementamos a biblioteca para as principais linguagens de nossa nuvem — principalmente para Kotlin e Go. Além da funcionalidade básica “gravar evento”, fornecemos um middleware, que pode ser conectado ao Control Plane no nível dos manipuladores de solicitações. O middleware coleta automaticamente a maior parte dos dados necessários para auditoria. O serviço só precisa transferir a parte específica: qual recurso, qual operação e como ela foi concluída. Os eventos são gravados em um arquivo em um diretório no disco, conectado via HostPath. Então surge a tarefa de ler corretamente esses dados e enviá-los ainda mais. Para o processamento correto de arquivos nos quais a gravação está ativa, implementamos um serviço separado, condicionalmente chamado logrotate (este é nosso próprio componente, apenas com o mesmo nome do utilitário conhecido). Este componente, junto com a biblioteca, remove os arquivos do modo de gravação e os marca como prontos para processamento posterior. Depois disso, os arquivos podem ser retirados para coleta. O logrotate é implantado como um DaemonSet em todos os clusters, portanto, ele atende a todos os serviços. Arquitetura do serviço de logs de auditoria. Geração de eventos Coleta e arquivamento de dados locais O próximo componente é um serviço que lê os arquivos preparados e os envia ainda mais. Chamamos esse serviço de coletor. Ele executa duas tarefas: Envia os dados ainda mais no pipeline. Salva dados compactados em um arquivo local temporário. Por que você precisa de um arquivo local? A resposta é confiabilidade. Teoricamente, a rede pode cair por uma ou duas horas. Nessa situação, os eventos não devem ser perdidos. Portanto, o arquivo local armazena os dados até que sejam entregues com sucesso ao armazenamento de destino. O problema óbvio é que o arquivo não é infinito. Portanto, desde o início do desenvolvimento do serviço, configuramos métricas e alertas e monitoramos o consumo do arquivo para evitar que ele transborde. Os coletores também são executados como DaemonSet em todos os clusters. Como resultado, todos os coletores enviam dados para o Kafka para processamento posterior. Arquitetura do serviço de logs de auditoria. Coleta local de dados Fila de eventos Kafka no pipeline de coleta de eventos é o ponto central de agregação. Depois disso, a etapa de processamento começa, que é dividida em duas partes: descarregamento externo; gravação interna em nosso armazenamento. Dividimos deliberadamente esses fluxos. Não queríamos primeiro escrever eventos no armazenamento interno e, em seguida, lê-los de lá para envio externo. Isso criaria carga desnecessária e aumentaria o atraso. É mais fácil e mais eficiente enviar dados diretamente do Kafka. Descarregamento externo de dados O exportador externo lê dados do Kafka. Então o seguinte acontece: Os eventos são agrupados por projetos e organizações. O exportador se refere ao Control Plane via API interna. Recebe informações sobre os coletores que trabalham com esses projetos e organizações. Determina: quais eventos devem ser deixados; para onde descarregá-los; em nome de qual conta de serviço executar a operação. Depois disso, o exportador descarrega os dados no armazenamento externo configurado pelo usuário. Aqui, pensamos em confiabilidade e fornecemos cenários ruins, por exemplo: problemas com a rede; conta de serviço configurada incorretamente; bucket removido pelo usuário. Portanto, salvamos os dados em armazenamento temporário e implementamos um mecanismo de reenvio dentro de um determinado período de tempo. Arquitetura do serviço de logs de auditoria. Descarregamento externo de dados Armazenamento interno de dados O exportador interno (Iceberg Exporter) também lê dados do Kafka. Ele implementa dois cenários: Gravar o conjunto completo de eventos para necessidades internas no Common Storage. Gravar em armazenamentos de usuários. Como Common Storage, usamos o mesmo armazenamento que fornecemos aos usuários. A única diferença é a configuração: para armazenamento interno, um coletor diferente e outros parâmetros de armazenamento são usados. Arquitetura do serviço de logs de auditoria. Armazenamento interno Arquitetura do serviço de logs de auditoria. Esquema completo Abaixo, contarei sobre algumas das características de nosso armazenamento interno de dados: Camada para trabalhar com Iceberg. Ao gravar no Iceberg, há uma característica importante: você pode executar apenas um commit por vez em uma tabela. Se dois processos tentarem fazer commit em paralelo, um deles falhará e você terá que reler os arquivos e remontar os manifestos. Para evitar esse problema, adicionamos uma camada agregadora, que chamamos de Coordinator. Ele acumula dados por um determinado intervalo (por exemplo, dois minutos) e executa um único commit. Este é uma espécie de coordenador de gravação. Armazenamento dentro do Iceberg. Dentro de nosso armazenamento Iceberg, o armazenamento do usuário é, na verdade, uma tabela separada. Consideramos outras opções: usar view; modelo combinado (tabela comum + view para cada armazenamento). Mas ambas as opções não funcionaram. E aqui está o porquê: views dão pior desempenho; o modelo combinado é mais difícil de implementar e dificulta o controle do volume de dados. A tabela acabou sendo a solução mais simples e previsível. Além disso, como na fase de exportação já sabemos a quais coletores os eventos pertencem e em quais armazenamentos eles devem cair, a gravação nas tabelas pode ser frequentemente executada em paralelo — se estas forem tabelas diferentes. A camada de agregação é necessária apenas nos casos em que vários coletores escrevem em um armazenamento. Limitações e desempenho de leitura. Lembre-se, um dos requisitos é desempenho de leitura adequado. Eventos podem ser muitos, profundidade de armazenamento — grande. Tecnicamente, é difícil garantir alto desempenho em grandes volumes. Portanto, a abordagem do produto entra em jogo aqui. O armazenamento tem duas características: volume máximo; tempo máximo de armazenamento. Na infraestrutura de grandes empresas, dezenas de GB podem ser preenchidos muito rapidamente — isso é inconveniente. Portanto, decidimos não limitar o volume. Mas limitamos o período de armazenamento — 30 dias. De acordo com nossas pesquisas, isso é suficiente para implementar os principais cenários: investigações, diagnósticos, monitoramento. Se o armazenamento mais longo for necessário, o usuário pode configurar o upload para o Object Storage e construir análises por conta própria. Para armazenamentos internos, fornecemos uma interface de visualização. Para uploads externos (Object Storage e outras direções futuras), a interface de visualização não é fornecida — inclusive devido aos requisitos de desempenho. O que no final O serviço de logs de auditoria é um componente importante da nuvem, uma ferramenta básica para controlar e analisar eventos. “Ver logs” é uma necessidade simples e compreensível do usuário, mas há um trabalho grande e bastante interessante de projeto por trás disso: transferir o ciclo de vida do evento para a arquitetura do serviço e escolher as soluções ideais para cada um de seus componentes. O serviço continuará a se desenvolver. Agora, os logs de auditoria estão disponíveis em Preview — o serviço é fornecido gratuitamente e destina-se a testar e se familiarizar com seus recursos. Nos planos imediatos — upload de eventos entre projetos, conexão de novos serviços como fontes de logs de auditoria, integração com SIEM via um Collector separado, bem como o desenvolvimento da interface e filtros mais flexíveis na UI. Tente o serviço e compartilhe seu feedback conosco na comunidade MWS Cloud Platform . Tags: cloud mwscloudplatform mws cloud logs de auditoria Hubs: Blog da empresa MWS Cloud Desenvolvimento de nuvens públicas Segurança da Informação Armazenamento de Dados Administração de Servidores 0 0 0 32K+ Cobertura em 30 dias MWS Cloud Site 2 Karma Vladimir Atasunts @tsaanstu Usuário Assinar O fluxo Backend está disponível 24 horas por dia, 7 dias por semana, graças ao suporte de amigos do Habr Habr Cursos para desenvolvedores backend PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor — reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Backend Comentar Melhor do dia Semelhante