SEC10-BP05 Acesso pré-provisionado

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

Práticas comuns que devem ser evitadas:

• Uso da conta raiz para a resposta a incidentes.

• Alterar contas de usuário existentes.

• Manipulando IAM permissões diretamente ao fornecer elevação de just-in-time privilégios.

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

Orientação para implementação

AWS recomenda reduzir ou eliminar a dependência de credenciais de longa duração sempre que possível, em favor de credenciais temporárias e just-in-timemecanismos de escalonamento de privilégios. 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:

• Interrupção relacionada a um provedor de identidades (IdP) comprometido.

• Erro de configuração ou erro humano causando uma falha no sistema de gerenciamento de acesso federado.

• Atividade maliciosa, como um evento distribuído de negação de serviço (DDoS) ou indisponibilidade de renderização do sistema.

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 que você use um usuário, grupo ou função com as permissões apropriadas para realizar tarefas e acessar AWS recursos. Use as credenciais de usuário-raiz somente para realizar tarefas que exijam as credenciais de usuário-raiz. Para verificar se as equipes de resposta a incidentes têm o nível correto de acesso AWS e outros sistemas relevantes, recomendamos o pré-provisionamento de 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. A escalada temporária do acesso de usuários ou funções por meio da adição de IAM políticas não deixa claro qual acesso os usuários tiveram durante o incidente e corre o risco de os privilégios aumentados não serem 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. Para apoiar isso, crie um manual 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 meio de nenhuma solução existente de federação ou login único ()SSO. Cada respondedor individual deve ter sua própria conta nomeada. A configuração da conta deve impor uma política de senha forte e autenticação multifatorial ()MFA. Se os manuais de resposta a incidentes exigirem apenas acesso ao AWS Management Console, o usuário não deve ter as chaves de acesso configuradas e deve ser explicitamente proibido de criar chaves de acesso. Isso pode ser configurado com IAM políticas ou políticas de controle de serviços (SCPs), conforme mencionado nas Melhores Práticas de AWS Segurança para AWS Organizations SCPs. 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 funções de resposta a incidentes pode ser monitorado e auditado adequadamente, é essencial que as IAM contas criadas para essa finalidade não sejam compartilhadas entre indivíduos e que não sejam usadas, a Usuário raiz da conta da AWS menos que sejam necessárias para uma tarefa específica. Se o usuário raiz for necessário (por exemplo, o IAM acesso a uma conta específica não estiver disponível), use um processo separado com um manual disponível para verificar a disponibilidade das credenciais e do token de login do usuário raiz. MFA

Para configurar as IAM políticas para as funções de resposta a incidentes, considere usar o IAMAccess Analyzer para gerar políticas com base em AWS CloudTrail registros. 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. Talvez você queira criar uma IAM política separada para cada manual para 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 IAMfunções dedicadas de resposta a incidentes em outras Contas da AWS. Essas funções devem ser configuradas para serem assumidas apenas pelos usuários na conta de segurança, e a relação de confiança deve exigir que o responsável pela chamada tenha se autenticado usando. MFA As funções devem usar IAM políticas de escopo restrito para controlar o acesso. Certifique-se de que todas as AssumeRole solicitações para essas funções estejam registradas CloudTrail e alertadas e que todas as ações tomadas usando essas funções sejam registradas.

É altamente recomendável que as IAM contas e as IAM funções sejam claramente nomeadas para permitir que sejam facilmente encontradas nos CloudTrail registros. Um exemplo disso seria nomear as IAM contas <USER_ID>-BREAK-GLASS e as IAM funçõesBREAK-GLASS-ROLE.

CloudTrailé usado para registrar API atividades em suas AWS contas e deve ser usado para configurar alertas sobre o uso das funções 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 a CloudWatch métrica da Amazon filter-to-filter em AssumeRole eventos relacionados à IAM função 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 respondente precise acessar sistemas que não estão diretamente protegidos peloIAM. Isso pode incluir instâncias do Amazon Elastic Compute Cloud, bancos de dados Amazon Relational Database Service ou plataformas software-as-a-service (SaaS). É altamente recomendável que, em vez de usar protocolos nativos, como SSH ouRDP, AWS Systems Manager Session Managerseja usado para todo o acesso administrativo às EC2 instâncias da Amazon. Esse acesso pode ser controlado usandoIAM, 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 acessar bancos de dados e ferramentas de terceiros, recomendamos armazenar as credenciais de acesso AWS Secrets Manager e conceder acesso às funções de respondente a incidentes.

Por fim, o gerenciamento das IAM contas 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:

• Gerenciando o acesso elevado temporário ao seu AWS ambiente

• AWS Guia de resposta a incidentes de segurança

• AWS Elastic Disaster Recovery

• AWS Systems Manager Incident Manager

• Definindo uma política de senha de conta para IAM usuários

• Usando a autenticação multifatorial (MFA) em AWS

• Configurando o acesso entre contas com MFA

• Usando o IAM Access Analyzer para gerar políticas IAM

• Melhores práticas para políticas AWS Organizations de controle de serviços em um ambiente com várias contas

• Como receber notificações quando as chaves de acesso root da sua AWS conta são usadas

• Crie permissões de sessão refinadas usando políticas gerenciadas IAM

Vídeos relacionados:

• Automatizando a resposta a incidentes e a análise forense em AWS

• DIYguia para runbooks, relatórios de incidentes e resposta a incidentes

• Prepare-se e responda a incidentes de segurança em seu ambiente AWS

Exemplos relacionados:

• Laboratório: Configuração AWS da conta e usuário raiz

• Laboratório: Resposta a incidentes com AWS console e CLI