O blog da AWS
Nove práticas recomendadas de segurança do AWS Security Hub
O AWS Security Hub é um serviço de segurança e conformidade que se tornou disponível em 25 de junho de 2019. Ele fornece uma ampla visibilidade do seu status de segurança e conformidade em várias contas da AWS, em um único painel por região. O serviço ajuda você a monitorar as configurações críticas para garantir que suas contas da AWS permaneçam seguras, permitindo que você observe e reaja rapidamente a qualquer alteração no seu ambiente.
O AWS Security Hub agrega, organiza e prioriza as descobertas de segurança de serviços da AWS com suporte — isto é, o Amazon GuardDuty, o Amazon Inspector e o Amazon Macie na ocasião da publicação desta postagem — e de várias soluções de segurança de parceiros da AWS. O AWS Security Hub também gera suas próprias descobertas, com base em verificações de conformidade e de configuração automatizadas, em nível de recursos e de conta, usando regras do AWS Config vinculadas a serviços e outras técnicas analíticas. Essas verificações ajudam a manter suas contas da AWS em conformidade com os padrões e as práticas recomendadas do setor, como o padrão AWS Foundations do CIS (Center for Internet Security).
Nesta postagem, indicarei nove práticas recomendadas para ajudar você a usar o AWS Security Hub da maneira mais eficaz possível.
1. Usar o script Laboratórios da AWS para ativar o Security Hub em todas as suas contas da AWS em todas as regiões e estabelecer sua hierarquia existente de mestre/membro do Amazon GuardDuty
Como prática recomendada, você deve monitorar continuamente todas as regiões em todas as suas contas da AWS em busca de comportamentos não autorizados ou configurações incorretas, até mesmo em regiões que não são muito utilizadas. A AWS já recomenda que você faça isso ao usar os serviços de monitoramento, como o AWS Config e o AWS CloudTrail. Eu recomendo habilitar o Security Hub em todas as regiões disponíveis nas suas contas da AWS.
Além disso, você também pode convidar outras contas da AWS para habilitar o Security Hub e compartilhar descobertas com a sua conta da AWS. Se você enviar um convite e ele for aceito pelo proprietário da outra conta, sua conta do Security Hub será designada como a conta mestra, e todas as contas do Security Hub associadas se tornarão suas contas-membro. Os usuários da conta mestra poderão visualizar as descobertas do Security Hub das contas-membro.
Para simplificar essas configurações, você pode utilizar o script Laboratórios da AWS, disponível no GitHub, que fornece um guia passo a passo para automatizar esse processo. Esse script permite habilitar (e desabilitar) o AWS Security Hub simultaneamente em uma lista de contas da AWS associadas e adicionar essas contas em massa para que elas se tornem membros do seu Security Hub. Ele envia convites da conta mestra e aceita convites automaticamente em todas as contas-membro. Para executar o script, você deve ter os IDs de contas da AWS e os endereços de e-mail raiz das contas da AWS que deseja convidar como membros do seu Security Hub. (Observe que você só deve compartilhar seu endereço de e-mail raiz e o ID da conta com contas da AWS confiáveis. Visite a página de práticas recomendadas do IAM para saber mais sobre como manter protegido o acesso às suas contas da AWS).
Por padrão, a associação de mestre/membros do Security Hub é independente dos relacionamentos que você estabeleceu entre as suas contas do Amazon GuardDuty ou do Amazon Macie e outras contas associadas. Se você tiver uma hierarquia de mestre/membros existente no GuardDuty ou no Macie, poderá exportar essa lista de contas para um arquivo CSV e usá-la com o script. Por exemplo, no GuardDuty, use a API ListMembers para exportar o ID da conta da AWS e o e-mail de todas as contas-membro, da seguinte maneira:
aws guardduty list-members --detector-id <Detector ID> --query "Members[].[AccountId, Email]" --output text | awk '{print $1 "," $2}'
A saída do comando acima será seus IDs de contas-membro do GuardDuty e seus endereços de e-mail raiz correspondentes, um por linha, e separados por uma vírgula, conforme mostrado abaixo:
12345678910,abc@example.com 98765432101,xyz@example.com
2. Habilitar o AWS Config em todas as contas e regiões da AWS e deixar a verificação padrão do AWS CIS Foundations habilitada
Quando você habilita o Security Hub em qualquer região, as verificações padrão do AWS CIS são habilitadas por padrão. Eu recomendo deixá-las habilitadas, pois elas são medidas de segurança importantes e aplicáveis a todas as contas da AWS.
Para executar a maioria dessas verificações, o Security Hub usa regras do AWS Config vinculadas a serviços. Por causa disso, você deve certificar-se de que o AWS Config esteja ativado e gravando todos os recursos com suporte, incluindo recursos globais, em todas as contas e regiões nas quais o Security Hub está implantado. Você não é cobrado pelo AWS Config por essas regras vinculadas a serviços. Você é cobrado apenas com base no modelo de preços do Security Hub.
3. Usar políticas do IAM específicas e gerenciadas para diferentes tipos de usuários do Security Hub
Você pode optar por permitir que um grande grupo de usuários acesse ações de Lista e Leitura do Security Hub, o que permitirá que eles visualizem suas descobertas de segurança. No entanto, você deve permitir que apenas um pequeno grupo de usuários acesse ações de Gravação do Security Hub. Isso permitirá que apenas usuários autorizados arquivem, resolvam ou corrijam as descobertas.
Você pode usar políticas gerenciadas da AWS para dar aos seus funcionários as permissões necessárias para começar. Essas políticas já estão disponíveis na sua conta e são mantidas e atualizadas pela AWS. Para conceder permissão mais granular aos usuários do Security Hub, eu recomendo que você crie as suas próprias políticas gerenciadas pelo cliente. Uma ótima maneira de começar com isso é importar uma política gerenciada da AWS existente. Dessa forma, você sabe que a política está inicialmente correta, e tudo o que você precisa fazer é personalizá-la para o seu ambiente.
A AWS categoriza cada ação de serviço em um dos cinco níveis de acesso com base na função de cada ação: Lista, Leitura, Gravação, Gerenciamento de permissões ou Marcação. Para determinar que nível de acesso incluir nas políticas do IAM que você atribui aos usuários, é possível visualizar o resumo de políticas, navegando do Console do IAM até Policies e selecionando qualquer política gerenciada pelo Console do IAM ou gerenciada pela AWS. Em seguida, na página Summary, sob a guia Permissions, selecione Policy summary (consulte a Figura 1). Para obter mais detalhes e exemplos de classificação de níveis de acesso, consulte Noções básicas sobre resumos de nível de acesso dentro de resumos de políticas.
Figura 1: Resumo da política gerenciada da AWS AWSSecurityHubReadOnlyAccess
4. Usar tags para controles de acesso e alocação de custos
Um recurso SecurityHub::Hub representa a implementação do serviço do AWS Security Hub por região na sua conta da AWS. O Security Hub permite atribuir metadados ao seu recurso SecurityHub::Hub na forma de tags. Cada tag é uma string de caracteres que consiste em uma chave definida pelo usuário e um valor de chave opcional que facilita a identificação e o gerenciamento dos recursos da AWS no seu ambiente.
Você pode controlar as permissões de acesso usando tags no seu recurso SecurityHub::Hub. Por exemplo, você pode permitir que um grupo de entidades do IAM de desenvolvedor gerencie e atualize somente os recursos SecurityHub::Hub que têm a chave de tag developer associada a eles. Isso pode ajudá-lo a restringir o acesso aos seus recursos SecurityHub::Hub de produção, permitindo que os seus desenvolvedores continuem testando em seus ambientes de desenvolvedor.
Para obter mais informações sobre as condições com base em tags compatíveis que você pode usar com as APIs do Security Hub, consulte Chaves de condições para o AWS Security Hub. Observe que, ao usar as condições com base em tags para o controle de acesso, você deve definir quem pode modificar essas tags.
Para facilitar a categorização e o rastreamento dos custos da AWS, você também pode ativar tags de alocação de custos. Isso ajuda a organizar os custos de recursos SecurityHub::Hub. A AWS gera um relatório de alocação de custos como um arquivo CSV, com seu uso e custos agrupados de acordo com suas tags ativas. Você pode aplicar marcas que representem categorias de negócios (como centros de custo, nomes de aplicativos ou ambientes de projeto) para organizar seus custos.
Para obter mais informações sobre categorias de marcação comumente usadas e estratégias de marcação efetivas, leia mais sobre Estratégias de marcação da AWS.
5. Integrar e habilitar seus produtos de segurança existentes (com 34 integrações hoje e mais ainda por vir)
Inúmeras ferramentas podem ajudá-lo a entender a postura de segurança e conformidade das suas contas da AWS, mas elas geram seu próprio conjunto de descobertas, muitas vezes em diferentes formatos. O Security Hub normaliza as descobertas.
Com o Security Hub, as descobertas geradas por provedores integrados (serviços de terceiros e serviços da AWS) são ingeridas usando um formato de descobertas padrão, o que elimina a necessidade de as equipes de segurança converterem os dados. Atualmente, você pode integrar 34 provedores de descobertas para importar e/ou exportar descobertas com o Security Hub. Alguns produtos de parceiros, como o PagerDuty, o Splunk e o Slack, podem receber descobertas do Security Hub, embora não gerem descobertas.
Se você quiser adicionar um produto de parceiro de terceiros ao seu ambiente da AWS, poderá escolher o link Purchase na página Integrations do console do Security Hub e navegar até o AWS Marketplace. Após a compra, escolha o link Configure para navegar até instruções passo a passo para instalar o produto e configurar sua integração com o Security Hub. Em seguida, escolha Enable integration integração para criar uma assinatura de produto na sua conta para esse provedor de terceiros (consulte a Figura 2).
Depois de habilitar uma assinatura, uma política de recurso é automaticamente anexada a ela. A política de recursos define as permissões necessárias para o Security Hub aceitar e processar as descobertas do produto. Você também pode habilitar a assinatura por meio da API e do CloudFormation.
Figura 2: integrando um provedor de descobertas de parceiro com o Security Hub
6. Criar manuais de correção personalizados usando o Amazon CloudWatch Events, documentos de Automação do AWS Systems Manager e o AWS Step Functions para resolver automaticamente as descobertas que não exigem intervenção humana
O Security Hub envia automaticamente todas as descobertas ao Amazon CloudWatch Events. Essa integração ajuda você a automatizar sua resposta a incidentes de ameaça, permitindo tomar ações específicas usando documentos de Automação do AWS Systems Manager, o OpsItems e o AWS Step Functions. Usando essas ferramentas, você pode criar seu próprio plano de tratamento de incidentes. Isso permitirá que sua equipe de segurança se concentre no fortalecimento da segurança dos seus ambientes da AWS em vez de remediar as descobertas atuais.
Figura 3: criando uma regra do CloudWatch Events para enviar resultados correspondidos do Security Hub a destinos específicos
7. Criar ações personalizadas para enviar uma cópia de uma descoberta do Security Hub a um recurso interno ou externo à sua conta da AWS, permitindo opções adicionais de visibilidade e remediação para essa descoberta
Devido à sua integração com o CloudWatch Events, você pode usar o Security Hub para criar ações personalizadas que enviarão descobertas específicas a sistemas de emissão de tickets, bate-papo, e-mail ou remediação automatizada. Ações personalizadas também podem ser enviadas aos seus próprios recursos da AWS, como o AWS Systems Manager OpsCenter, o AWS Lambda ou o Amazon Kinesis, permitindo que você realize sua própria remediação ou captura de dados relacionada à descoberta.
Para uma visão detalhada dessa arquitetura, além de exemplos específicos de como implementar ações personalizadas, consulte Como integrar ações personalizadas do AWS Security Hub com o PagerDuty e Como habilitar ações personalizadas no AWS Security Hub.
Além disso, o Security Hub oferece a opção de escolher o SDK da AWS específico de uma linguagem, para que você possa usar ações personalizadas para resolver descobertas programaticamente. Abaixo, vou demonstrar como você pode implementar isso usando o AWS Lambda e o SDK da AWS para Python (Boto3). No meu exemplo, vou remediar a descoberta gerada pelo Security Hub para verificação CIS 2.4, “Garantir que as trilhas do CloudTrail estejam integradas ao Amazon CloudWatch Logs”. Para esse passo a passo, suponho que você tenha as permissões necessárias do AWS IAM para trabalhar com o Security Hub, o CloudWatch Events, o Lambda e o AWS CloudTrail.
Figura 4: fluxo de dados compatível com a remediação de descobertas do Security Hub usando ações personalizadas
Como mostra a figura 4:
- Quando descobertas na verificação CIS 2.4 forem geradas no Security Hub, este as enviará ao CloudWatch Events usando as ações personalizadas que descreverei abaixo.
- O CloudWatch Events enviará essas descobertas a uma função do Lambda que foi configurada como o destino.
- A função do Lambda utilizará um script Python para verificar se a descoberta foi gerada na verificação CIS 2.4. Em caso positivo, a função do Lambda identificará a trilha do CloudTrail afetada e a configurará com o CloudWatch Logs para monitorar os logs da trilha.
Pré-requisitos
- Você deve configurar uma Função do IAM para o AWS CloudTrail para assumir que ele possa entregar eventos ao seu grupo de logs do CloudWatch Logs. Para obter mais informações sobre como fazer isso, consulte a documentação do AWS CloudTrail. Vou chamar essa função de função do CloudTrail.
- Para implantar a função do Lambda, você deve configurar uma função do IAM para essa função do Lambda assumir. Vou chamar essa função de função de execução do Lambda. A amostra de política a seguir inclui as permissões que você atribuirá a ela para este exemplo. Substitua <CloudTrail_CloudWatchLogs_Role> pela função do CloudTrail criada na etapa anterior. Dependendo do seu caso de uso, você pode restringir ainda mais essa política do IAM para “conceder menos privilégios”, o que é uma prática recomendada do IAM.
Implantação da solução
- Crie uma ação personalizada no AWS Security Hub e associe-a a uma regra do CloudWatch Events que você configura para as descobertas do Security Hub. Siga as instruções descritas no guia do usuário do Security Hub para conhecer as etapas exatas para isso.
- Crie uma função do Lambda, o que concluirá a remediação automática das descobertas do CIS 2.4:
a. Abra o console do Lambda e selecione Create function.
b. Na próxima página, escolha Author from scratch.
c. Em Basic information, insira um nome para sua função. Para Runtime, selecione Python 3.7.
Figura 5: atualizando informações básicas para criar a função do Lambda
d. Em Permissions, expanda Choose or create an an execution role.
e. Em Execution role, selecione o menu suspenso e altere a configuração para Use an existing role.
f. Em Existing role, selecione a função de execução do Lambda_execution_role criada anteriormente e depois selecione Create function.
Figura 6: atualizando informações básicas e permissões para criar a função do Lambda
g. Exclua o código de função padrão e cole o código que eu forneci abaixo:
import json, boto3
cloudtrail_client = boto3.client('cloudtrail')
cloudwatchlogs_client = boto3.client('logs')
iam_client = boto3.client('iam')
role_details = iam_client.get_role(RoleName='<CloudTrail_CloudWatchLogs_Role>')
def lambda_handler(event, context):
# First off all, let us see if the JSON sent by CWE has any Security Hub findings.
if 'detail' in event.keys() and 'findings' in event['detail'].keys() and len(event['detail']['findings']) > 0:
print("There are some findings. Let's check them!")
print("Number of findings: %i" % len(event['detail']['findings']))
# Then we need to filter out the findings. In this code snippet, we'll handle only findings related to CloudTrail trails for integration with CloudWatch Logs.
for finding in event['detail']['findings']:
if 'Title' in finding.keys():
if 'Ensure CloudTrail trails are integrated with CloudWatch Logs' in finding['Title']:
print("There's a CloudTrail-related finding. I can handle it!")
if 'Compliance' in finding.keys() and 'Status' in finding['Compliance'].keys():
print("Compliance Status: %s" % finding['Compliance']['Status'])
# We can skip compliant findings, and evaluate only the non-compliant ones.
if finding['Compliance']['Status'] == 'PASSED':
continue
# For each non-compliant finding, we need to get specific pieces of information so as to create the correct log group and update the CloudTrail trail.
for resource in finding['Resources']:
resource_id = resource['Id']
cloudtrail_name = resource['Details']['Other']['name']
loggroup_name = 'CloudTrail/' + cloudtrail_name
print("ResourceId for the finding is %s" % resource_id)
print("LogGroup name: %s" % loggroup_name)
# At this point, we can create the log group using the name extracted from the finding.
try:
response_logs = cloudwatchlogs_client.create_log_group(logGroupName=loggroup_name)
except Exception as e:
print("Exception: %s" % str(e))
# For updating the CloudTrail trail, we need to have the ARN of the log group. Let's retrieve it now.
response_logsARN = cloudwatchlogs_client.describe_log_groups(logGroupNamePrefix = loggroup_name)
print("LogGroup ARN: %s" % response_logsARN['logGroups'][0]['arn'])
print("The role used by CloudTrail is: %s" % role_details['Role']['Arn'])
# Finally, let's update the CloudTrail trail so that it sends logs to the new log group created.
try:
response_cloudtrail = cloudtrail_client.update_trail(
Name=cloudtrail_name,
CloudWatchLogsLogGroupArn = response_logsARN['logGroups'][0]['arn'],
CloudWatchLogsRoleArn = role_details['Role']['Arn']
)
except Exception as e:
print("Exception: %s" % str(e))
else:
print("Title: %s" % finding['Title'])
print("This type of finding cannot be handled by this function. Skipping it…")
else:
print("This finding doesn't have a title and so cannot be handled by this function. Skipping it…")
else:
print("There are no findings to remediate.") h. Depois de colar o código, substitua <CloudTrail_CloudWatchLogs_Role> pela sua função do CloudTrail e selecione Save para salvar sua função do Lambda.
Figura 7: editando o código do Lambda para substituir a função correta do CloudTrail
3. Acesse o console do CloudWatch e selecione Rules no painel de navegação à esquerda.
a. Na lista de regras do CloudWatch visível, selecione a regra que você criou na Etapa 1 desta implantação de solução.
b. Em seguida, selecione Actions no canto superior direito da página e escolha Edit.
c. Na página Etapa 1: Create rule, em Targets, escolha Lambda function e selecione a função do Lambda criada na Etapa 2.
d. Selecione Configure details.
e. Na página Etapa 2: Configure rule details, selecione Update rule.
Figura 8: adicionando sua função do Lambda criada como destino para a regra do CloudWatch
4. A configuração agora está concluída, e você pode testar sua regra. Acesse o console do AWS Security Hub e selecione Compliance standards no painel de navegação.
a. Em seguida, selecione CIS AWS Foundations.
Figura 9: página Padrões de conformidade no console do Security Hub
b. Procure a regra 2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs e selecione-a.
Figura 10: localizando a verificação CIS 2.4 no console do Security Hub
c. Se você tiver deixado as verificações CIS padrão do AWS Security Hub habilitadas (junto com o serviço AWS Config na mesma região) e se você tiver trilhas do CloudTrail nessa região que ainda não estão configuradas para entregar eventos ao CloudWatch Logs, verá uma descoberta de baixa gravidade com um status de conformidade Failed.
d. Selecione a descoberta com falha marcando a caixa de seleção e escolhendo o botão Actions.
e. Por fim, no menu suspenso, selecione a ação personalizada que você criou na Etapa 1 para enviar a descoberta ao CloudWatch Events. O CloudWatch Events enviará a descoberta à sua função do Lambda, que você configurou como o destino da regra na etapa 3. A função do Lambda identificará automaticamente a trilha do CloudTrail afetada e configurará o grupo de logs do CloudWatch Logs para você. O grupo de logs terá o mesmo nome que sua trilha para fins de identificação. Você pode modificar o código para atender ainda mais às suas necessidades.
Observação: pode haver um atraso antes que o status de conformidade do recurso corrigido seja alterado. Depois que o CIS AWS Foundations Standard for habilitado, o Security Hub executará as verificações dentro de 2 horas. Depois disso, as verificações serão executadas automaticamente uma vez a cada 24 horas.
Figura 11: descobertas geradas na verificação CIS 2.4 no console do Security Hub
8. Personalizar seus insights usando os “insights gerenciados” padrão como modelos e usá-los para priorizar recursos e descobertas para atuação
Um “insight” do Security Hub é uma coleção de descobertas relacionadas às quais um ou mais filtros do Security Hub foram aplicados. Insights podem ajudá-lo a organizar suas descobertas e a identificar riscos de segurança que precisam de atenção imediata.
O Security Hub oferece vários insights gerenciados (padrão). Você pode usá-los como modelos para novos insights e modificá-los dependendo do seu caso de uso. Você pode salvar essas consultas modificadas como novos insights personalizados, para garantir uma visibilidade ainda maior das suas contas da AWS. Consulte a documentação para obter instruções passo a passo sobre como criar insights personalizados.
Figura 12: criando um insight personalizado do Security Hub
9. Usar a avaliação gratuita para avaliar quais podem ser os seus custos
O Security Hub oferece uma avaliação gratuita de 30 dias para todas as contas e regiões da AWS. A avaliação é uma boa maneira de calcular quanto o Security Hub custará, em média, para monitorar ameaças e conformidade nos seus ambientes. Você pode visualizar uma estimativa, navegando no console do Security Hub até Settings e depois até Usage (consulte a Figura 13).
Figura 13: estimando os custos do seu Security Hub
Conclusão
O AWS Security Hub permite que você tenha mais visibilidade do status de segurança e conformidade dos seus ambientes da AWS. Usando as práticas recomendadas do Security Hub discutidas aqui, as equipes de segurança podem dedicar mais tempo à correção e recuperação de incidentes, em vez de à detecção e à organização de incidentes. O Security Hub passou pela certificação HIPAA, ISO, PCI e SOC. Para saber mais sobre o Security Hub, consulte a documentação do AWS Security Hub.
Se você tiver comentários sobre esta postagem, envie-os na seção Comentários abaixo. Se você tiver alguma dúvida sobre algo nesta postagem, inicie um novo tópico no Fórum do AWS Security Hub ou entre em contato com o AWS Support.
Quer receber mais notícias de Segurança da AWS? Siga-nos no Twitter.
Ketan Srivastava
Ketan é um engenheiro de suporte de nuvem na AWS. Ele aprecia o fato de que, na AWS, há sempre tantas oportunidades de construir as coisas melhor para os nossos clientes e aprender com essas oportunidades. Fora do trabalho, ele toca MOBAs e viaja para novos lugares com sua esposa. Ele tem um mestrado em Ciências pelo Rochester Institute of Technology.