SEC10-BP05 Provisionar acesso previamente

Verifique se os respondedores a incidentes têm o acesso correto pré-provisionado na AWS para reduzir o tempo de investigação necessário até a recuperação.

Práticas comuns que devem ser evitadas:

Nível de risco exposto se esta prática recomendada não for estabelecida: Médio

Orientação para implementação

A AWS recomenda reduzir ou eliminar a dependência de credenciais de longa duração sempre que possível, dando preferência a credenciais temporárias e a mecanismos de escalação de privilégios just-in-time. As credenciais de longa duração são propensas a riscos de segurança e aumentam a sobrecarga operacional. Para a maioria das tarefas de gerenciamento, bem como para as tarefas de resposta a incidentes, recomendamos implementar a federação de identidades junto com a escalação temporária para acesso administrativo. Nesse modelo, um usuário solicita elevação para um nível de privilégio superior (como um perfil de resposta a incidentes) e, considerando que ele seja elegível para a elevação, a solicitação é enviada a um aprovador. Se a solicitação for aprovada, o usuário receberá um conjunto de credenciais da AWS temporárias que podem ser usadas para concluir suas tarefas. Quando essas credenciais expirarem, o usuário deverá enviar uma nova solicitação de elevação.

Recomendamos usar a escalação de privilégio temporária para a maioria dos cenários de resposta a incidentes. A maneira correta de fazer isso é usar o AWS Security Token Service e políticas de sessão para definir o escopo do acesso.

Há cenários em que as identidades federadas não estão disponíveis, como:

Nos casos anteriores, deve haver um acesso emergencial de "vidro quebrado" configurado para permitir a investigação e a correção rápida de incidentes. Recomendamos usar um usuário, grupo ou perfil com as permissões apropriadas para realizar tarefas e acessar recursos da AWS. Use as credenciais de usuário-raiz somente para realizar tarefas que exijam as credenciais de usuário-raiz. Para verificar se os respondedores de um incidente têm o nível de acesso correto à AWS e a outros sistemas relevantes, recomendamos provisionar previamente contas dedicadas. As contas exigem acesso privilegiado e devem ser estritamente controladas e monitoradas. As contas devem ser criadas com os privilégios mínimos exigidos para realizar as tarefas necessárias e o nível de acesso deve ser baseado nos playbooks criados como parte do plano de gerenciamento de incidentes.

Como prática recomendada, utilize perfis e usuários dedicados e com propósito específico. Escalar temporariamente o acesso de usuários ou perfis por meio da adição de políticas do IAM não deixa claro qual é o acesso que os usuários tinham durante o incidente, e há um risco de que os privilégios escalados não sejam revogados.

É importante remover o máximo de dependências possível para verificar se o acesso pode ser obtido com o maior número possível de cenários de falha. Como forma de auxiliar esse processo, crie um playbook para verificar se os usuários de resposta a incidentes são criados como usuários em uma conta de segurança dedicada e não são gerenciados por nenhuma solução de autenticação única (SSO) ou federação existente. Cada respondedor individual deve ter sua própria conta nomeada. A configuração da conta deve aplicar uma política de senha forte e autenticação multifator (MFA). Se os playbooks de resposta a incidentes só exigem acesso ao AWS Management Console, o usuário não deve ter chaves de acesso configuradas e deve ser proibido explicitamente de criar chaves de acesso. Isso pode ser configurado com políticas do IAM ou políticas de controle de serviços (SCPs), conforme mencionado nas Práticas recomendadas de segurança da AWS para SCPs do AWS Organizations Os usuários não devem ter privilégios além da capacidade de assumir perfis de resposta a incidentes em outras contas.

Durante um incidente, talvez seja necessário conceder acesso a outros indivíduos internos ou externos para apoiar a investigação, a correção ou as atividades de recuperação. Nesse caso, use o mecanismo do playbook mencionado anteriormente, e deve haver um processo para verificar se qualquer acesso adicional foi revogado imediatamente após a conclusão do incidente.

Para verificar se o uso de perfis de resposta a incidentes pode ser monitorado e auditado corretamente, é essencial que as contas de usuário do IAM criadas para esse fim não sejam compartilhadas entre indivíduos e que o Usuário raiz da conta da AWS não seja utilizado, a menos que isso seja necessário para uma tarefa específica. Se o usuário-raiz for necessário (por exemplo, quando o acesso do IAM a uma conta específica estiver indisponível), use um processo separado com um playbook disponível para verificar a disponibilidade das credenciais de início de sessão e do token de MFA do usuário-raiz.

Para configurar as políticas do IAM para os perfis de resposta a incidentes, considere usar o IAM Access Analyzer para gerar políticas com base em logs do AWS CloudTrail. Para fazer isso, conceda acesso de administrador ao perfil de resposta a incidentes em uma conta de não produção e execute as etapas descritas nos playbooks. Concluído o processo, uma política que permita somente as ações realizadas pode ser criada. Essa política pode ser então aplicada a todos os perfis de resposta a incidentes em todas as contas. Você pode criar uma política do IAM separada para cada playbook a fim de facilitar o gerenciamento e a auditoria. Exemplos de playbook podem incluir planos de resposta para ransomware, violações de dados, perda de acesso à produção, entre outros cenários.

Use as contas de resposta a incidentes para assumir perfis do IAM de resposta a incidentes dedicados em outras Contas da AWS Esses perfis também devem ser configurados para poder ser assumidos somente por usuários na conta de segurança, e o relacionamento de confiança deve exigir que a entidade principal que está fazendo a chamada seja autenticada com MFA. Os perfis devem usar políticas do IAM com escopo estritamente definido para controlar o acesso. Certifique-se de que todas as solicitações de AssumeRole para esses perfis sejam registradas em log no CloudTrail e acionem alertas, e que quaisquer ações realizadas usando esses perfis sejam registradas em log.

É altamente recomendável que as contas do IAM e os perfis do IAM sejam claramente nomeados para permitir que sejam encontrados com facilidade nos logs do CloudTrail. Um exemplo disso seria nomear as contas do IAM como <USER_ID>-BREAK-GLASS e os perfis do IAM como BREAK-GLASS-ROLE.

O CloudTrail é usado para registrar a atividade da API em suas contas da AWS e deve ser usado para configurar alertas sobre o uso dos perfis de resposta a incidentes. Consulte a publicação do blog sobre como configurar alertas quando as chaves-raiz são usadas. As instruções podem ser modificadas para configurar o filtro métrico do Amazon CloudWatch para filtrar eventos AssumeRole relacionados ao perfil do IAM de resposta a incidentes:

{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }

Como é provável que os perfis de resposta a incidentes tenham um alto nível de acesso, é importante que esses alertas sejam transmitidos a um grupo amplo e que as atitudes necessárias sejam tomadas rapidamente.

Durante um incidente, é possível que um respondedor possa exigir acesso a sistemas que não são protegidos diretamente pelo IAM. Isso pode incluir instâncias do Amazon Elastic Compute Cloud, bancos de dados do Amazon Relational Database Service ou plataformas de software como serviço (SaaS). É altamente recomendável que, em vez de usar protocolos nativos, como SSH ou RDP, o AWS Systems Manager Session Manager seja usado para todo o acesso administrativo às instâncias do Amazon EC2. Esse acesso pode ser controlado usando o IAM, que é seguro e auditado. Talvez também seja possível automatizar partes de seus playbook usando documentos de execução de comandos do AWS Systems Manager, o que pode reduzir os erros do usuário e melhorar o tempo de recuperação. Para acesso aos bancos de dados e a ferramentas de terceiros, recomendamos armazenar as credenciais de acesso no AWS Secrets Manager e conceder acesso aos perfis de respondedores a incidentes.

Por fim, o gerenciamento das contas do IAM de resposta a incidentes deve ser adicionado aos seus processos de Joiners, Movers e Leavers e revisado e testado periodicamente para verificar se somente o acesso pretendido é permitido.

Recursos

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados: