Conheça o Gerenciamento de Eventos de somente leitura do Amazon Eventbridge

Esta postagem foi escrita por Pawan Puthran, especialista principal TAM, Serverless, e Heeki Park, arquiteto de soluções principal Serverless

A AWS anunciou o suporte para eventos de gerenciamento somente para leitura no Amazon EventBridge. Esse recurso permite que os clientes criem respostas ricas baseadas em eventos a partir de qualquer ação realizada na infraestrutura da AWS para detectar vulnerabilidades de segurança ou identificar atividades suspeitas quase em tempo real. Agora você pode obter informações sobre todas as atividades em todas as suas contas da AWS e responder a esses eventos conforme apropriado.

Visão geral

O EventBridge é um barramento de eventos serverless usado para separar produtores e consumidores de eventos. As regras determinam os alvos posteriores que recebem e processam os eventos, e o EventBridge roteia os eventos de acordo.

O EventBridge permite que os clientes monitorem, auditem e reajam, quase em tempo real, às mudanças em seus ambientes da AWS por meio de eventos gerados pelo AWS CloudTrail para chamadas de API da AWS. O CloudTrail registra ações realizadas por um usuário, uma função ou um serviço da AWS como eventos em uma trilha. Os eventos incluem ações realizadas no Console de Gerenciamento da AWS, na Interface da Linha de Comando (CLI) da AWS e nos SDKs e APIs da AWS.

Anteriormente, somente chamadas de API de mudança eram publicadas do CloudTrail para o EventBridge para alterações no plano de controle. Os eventos para chamadas de API de mudança incluem aqueles que criam, atualizam ou excluem recursos. As mudanças no plano de controle também são chamadas de eventos de gerenciamento. O EventBridge agora suporta chamadas de API sem alteração ou somente leitura para eventos de gerenciamento sem custo adicional. Isso inclui aqueles que listam, obtêm ou descrevem recursos.

Os eventos do CloudTrail no EventBridge permitem que você crie respostas ricas orientadas por eventos a partir de qualquer ação realizada na infraestrutura da AWS em tempo real. Anteriormente, clientes e parceiros costumavam usar um modelo de pesquisa para iterar sobre um lote de logs do CloudTrail dos buckets do Amazon S3 para detectar problemas, tornando a resposta mais lenta. O lançamento de eventos de gerenciamento somente para leitura permite que você detecte e corrija problemas quase em tempo real e, assim, melhore a postura geral de segurança.

Habilitando eventos de gerenciamento somente para leitura

Você pode começar a receber eventos de gerenciamento somente para leitura se um CloudTrail estiver configurado em sua conta e se o seletor de eventos desse CloudTrail estiver configurado com ReadWriteType de All ou ReadOnly. Isso garante que os eventos de gerenciamento somente para leitura sejam registrados no CloudTrail e depois passados para o EventBridge.

Por exemplo, você pode receber um alerta se uma conta de produção listar recursos de um endereço IP fora da sua VPC. Outro exemplo pode ser se uma entidade, como um principal (usuário raiz da conta da AWS, função do IAM ou usuário do IAM), chamar as APIs ListInstanceProfilesForRole ou DescribeInstances sem nenhum registro prévio disso. Um agente mal-intencionado pode usar credenciais roubadas para realizar esse reconhecimento para encontrar credenciais mais valiosas ou determinar as capacidades das credenciais que ele possui.

Para habilitar eventos de gerenciamento somente para leitura com uma regra do EventBridge, além dos eventos de mutação existentes, use o novo estado ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS ao criar a regra.

Resources:
  SampleMgmtRule:
    Type: 'AWS::Events::Rule'
    Properties:
      Description: 'Example for enabling read-only management events'
      State: ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS
      EventPattern:
        source:
          - aws.s3
        detail:
          - AWS API Call via CloudTrail
      Targets:
        - Arn: 'arn:aws:sns:us-east-1:123456789012:notificationTopic'
          Id: 'NotificationTarget'

Você também pode criar uma regra em um barramento de eventos para especificar uma ação de API específica usando o atributo eventName na chave de detalhes:

aws events put-rule --name "SampleTestRule" \
--event-pattern '{"detail": {"eventName": ["ListBuckets"]}}' \
--state ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS --region us-east-1

Cenários e casos de uso comuns

A seção a seguir descreve alguns cenários em que você pode configurar as regras do EventBridge e realizar ações em eventos de gerenciamento sem mutação ou somente para leitura.

Detectando chamadas anômalas da API GetSecretValue do Secrets Manager

Considere a equipe de segurança da sua organização que deseja uma notificação sempre que as chamadas da API GetSecretValue para o AWS Secrets Manager forem feitas por meio da CLI. Eles podem então investigar se essas chamadas são feitas por entidades externas à organização ou por um usuário não autorizado e tomar medidas corretivas para negar tais solicitações.

Quando o aplicativo chama a API getSecretValue para recuperar os segredos por meio de uma CLI, ele gera um evento como este:

{
    "version": "0",
    "id": "d3368cc1-e6d6-e4bf-e58e-030f03b6eae3",
    "detail-type": "AWS API Call via CloudTrail",
    "source": "aws.secretsmanager",
    "account": "111111111111",
    "time": "2023-11-08T19:58:38Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "eventVersion": "1.08",
        "userIdentity": {
            "type": "IAMUser",
            "principalId": "AAAAAAAAAAAAA",
            "arn": "arn:aws:iam:: 111111111111:user/USERNAME"
            // ... additional detail fields
        },
        "eventTime": "2023-11-08T19:58:38Z",
        "eventSource": "secretsmanager.amazonaws.com",
        "eventName": "GetSecretValue",
        "awsRegion": "us-east-1",
        "userAgent": "aws-cli/2.13.15 Python/3.11.4 Darwin/22.6.0 exe/x86_64 prompt/off command/secretsmanager.get-secret-value"
        // ... additional detail fields
    }
}

Você define o seguinte padrão de evento na regra para filtrar eventos recebidos para consumidores específicos. Este exemplo também usa o filtro curinga lançado recentemente para correspondência de eventos.

{
    "source": [
        "aws.secretsmanager"
    ],
    "detail-type": [
        "AWS API Call via CloudTrail"
    ],
    "detail": {
        "eventName": [
            "GetSecretValue"
        ],
        "userAgent": [
            {
                "wildcard": "aws-cli/*"
            }
        ]
    }
}

Você pode criar uma regra que corresponda a uma combinação dessas propriedades do evento. Nesse caso, você está combinando aws.secretsmanager como fonte, AWS API Call via CloudTrail como detail-type, getSecretValue como detail.eventName e padrão curinga em detail.userAgent para aws-cli/*. Você pode filtrar detail.userAgent com um curinga para capturar eventos provenientes de um determinado aplicativo ou usuário.

Em seguida, você pode rotear esses eventos para um destino, como um stream do Amazon CloudWatch Logs, para registrar a alteração. Você também pode encaminhá-los para o Amazon SNS para serem notificados por meio de assinatura de e-mail. Como alternativa, você pode roteá-los para uma função do AWS Lambda na qual você executa uma lógica de negócios personalizada.

Criação de uma regra do EventBridge para eventos de gerenciamento somente para leitura

Crie uma regra no barramento de eventos padrão usando o novo estado ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS.

aws events put-rule --name "monitor-secretsmanager" \
--event-pattern '{"source": ["aws.secretsmanager"], "detail-type": ["AWS API Call via CloudTrail"], "detail": {"eventName": ["GetSecretValue"], "userAgent": [{ "wildcard": "aws-cli/*"} ]}}' \
--state ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS --region us-east-1

Detalhes da regra

Configure um alvo. Nesse caso, o serviço de destino é o CloudWatch Logs, mas você pode configurar qualquer um dos destinos compatíveis.

aws events put-targets --rule monitor-secretsmanager --targets Id=1,Arn=arn:aws:logs:us-east-1:ACCOUNT_ID:log-group:/aws/events/getsecretvaluelogs --region us-east-1

Detalhes do alvo

Em seguida, você pode usar o CloudWatch Log Insights para pesquisar e analisar dados de log usando a sintaxe de consulta do CloudWatch Log Insights, na qual você pode recuperar o usuário que realizou essas chamadas.

Identificação de comportamentos suspeitos de exfiltração de dados

Considere a equipe de segurança ou de perímetro de dados que deseja proteger os dados que residem nos buckets do Amazon S3. A equipe exige notificações sempre que são feitas chamadas de API para listar buckets do S3 ou para listar objetos do S3.

Quando um usuário ou aplicativo chama a API ListBuckets para descobrir os buckets disponíveis, ele gera o seguinte evento do CloudTrail:

{
    "version": "0",
    "id": "345ca690-6510-85b2-ff02-090493a33cf1",
    "detail-type": "AWS API Call via CloudTrail",
    "source": "aws.s3",
    "account": "111111111111",
    "time": "2023-11-14T17:25:30Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "eventVersion": "1.09",
        "userIdentity": {
            "type": "IAMUser",
            "principalId": "principal-identity-uuid",
            "arn": "arn:aws:iam::111111111111:user/exploited-user",
            "accountId": "111111111111",
            "accessKeyId": "AAAABBBBCCCCDDDDEEEE",
            "userName": "exploited-user"
        },
        "eventTime": "2023-11-14T17:25:30Z",
        "eventSource": "s3.amazonaws.com",
        "eventName": "ListBuckets",
        "awsRegion": "us-east-1",
        "sourceIPAddress": "11.22.33.44",
        "userAgent": "[aws-cli/2.13.29 Python/3.11.6 Darwin/22.6.0 exe/x86_64 prompt/off command/s3api.list-buckets]",
        "requestParameters": {
            "Host": "s3.us-east-1.amazonaws.com"
        },
        "readOnly": true,
        "eventType": "AwsApiCall",
        "managementEvent": true
        // additional detail fields
    }
}

Nesse cenário, você pode criar uma regra do EventBridge correspondente para aws.s3 para o campo de origem e listBuckets para o eventName.

{
    "source": [
        "aws.s3"
    ],
    "detail-type": [
        "AWS API Call via CloudTrail"
    ],
    "detail": {
        "eventName": [
            "ListBuckets "
        ]
    }
}

No entanto, listar objetos por si só pode ser apenas o começo de uma possível tentativa de exfiltração de dados. Talvez você também queira verificar se há ListObjects ou ListObjectsV2 como a próxima ação, seguida por um grande número de chamadas da API GetObject. Você pode criar a seguinte regra para corresponder a essas ações.

{
    "source": [
        "aws.s3"
    ],
    "detail-type": [
        "AWS API Call via CloudTrail"
    ],
    "detail": {
        "eventName": [
            "ListObjects",
            "ListObjectsV2",
            "GetObject"
        ]
    }
}

Você poderia encaminhar essas informações de registro para sua solução central de registro de segurança ou usar modelos de aprendizado de máquina de detecção de anomalias para avaliar esses eventos e determinar a resposta apropriada a esses eventos.

Configurando o roteamento de eventos entre contas e regiões

Você também pode criar regras para receber eventos somente de leitura para várias contas ou entre regiões para centralizar seus eventos da AWS em uma região ou uma conta da AWS para fins de auditoria e monitoramento. Por exemplo, capture todos os eventos de carga de trabalho de várias regiões no eu-west-1 para relatórios de conformidade.

Exemplo de conta cruzada para barramento de eventos padrão e barramento de eventos personalizado

Para fazer isso, crie uma regra usando o novo estado ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS no barramento padrão da conta de origem ou da região, visando um barramento de eventos padrão ou um barramento de eventos personalizado da conta ou região de destino. Você também deve garantir que tenha uma regra configurada com ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS para poder invocar os destinos na conta ou região de destino.

Configuração entre regiões para eventos somente para leitura do CloudTrail

Conclusão

Este blog mostra como os clientes podem criar respostas avançadas baseadas em eventos com o suporte recém-lançado para eventos somente para leitura. Agora você pode observar eventos como possíveis sinais de atividades de reconhecimento e exfiltração de dados de qualquer ação realizada na infraestrutura da AWS quase em tempo real. Você também pode usar a funcionalidade entre regiões e entre contas para entregar os eventos somente para leitura em uma conta ou região centralizada da AWS, aprimorando a capacidade de auditoria e monitoramento em todos os seus ambientes da AWS.

Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.

Este conteúdo é uma tradução do Blog original em inglês (link aqui)

Biografia dos autores

Autor

Eric Johnson é um Principal Developer Advocate na AWS.

Biografia do tradutor

Phelipe Fabres é arquiteto de soluções sênior para o segmento de Startups e iniciou sua jornada na AWS em 2020 ajudando clientes em suas jornadas na nuvem. Além disso, Phelipe é parte da comunidade Serverless na AWS e já apresentou sobre o assunto em diversos eventos, como o AWS Summit São Paulo e o AWS re:Invent.

Biografia do revisor

Cristiano Scandura é arquiteto de soluções sênior na AWS.

O blog da AWS