SEC03-BP03 Estabelecer processo de acesso de emergência - Pilar de segurança
Orientação para implementação Recursos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

SEC03-BP03 Estabelecer processo de acesso de emergência

Crie um processo que permita acesso emergencial às suas workloads no caso improvável de um problema com seu provedor de identidades centralizado.

Crie processos para diferentes modos de falha que poderiam resultar em um evento de emergência. Por exemplo, em circunstâncias normais, os usuários da sua força de trabalho se federam na nuvem usando um provedor de identidade centralizado (SEC02-BP04) para gerenciar suas cargas de trabalho. No entanto, se o provedor de identidades centralizado falhar ou a configuração da federação na nuvem for modificada, talvez os usuários de sua força de trabalho não consigam se federar na nuvem. Um processo de acesso de emergência permite que administradores autorizados acessem seus recursos de nuvem por meios alternativos (como uma forma alternativa de federação ou acesso direto do usuário) para corrigir problemas com sua configuração de federação ou workloads. O processo de acesso de emergência é usado até o mecanismo normal de federação ser restaurado.

Resultado desejado:

  • Você definiu e documentou os modos de falha que são considerados uma emergência: considere suas circunstâncias normais e os sistemas dos quais seus usuários dependem para gerenciar suas workloads. Pense em como cada uma dessas dependências pode falhar e causar uma situação de emergência. Talvez você considere as perguntas e as práticas recomendadas do pilar Confiabilidade úteis para identificar modos de falha e arquitetar sistemas mais resilientes para minimizar a probabilidade de falhas.

  • Você documentou as etapas que devem ser seguidas para confirmar uma falha como emergência. Por exemplo, é possível exigir que os administradores de identidade confiram o status de seus provedores de identidade primário e de reserva e, se nenhum dos dois estiver disponível, declarar um evento de emergência por falha do provedor de identidades.

  • Você definiu um processo de acesso de emergência específico de cada tipo de modo de emergência ou falha. Ser específico pode reduzir a tentação de seus usuários de abusar de um processo geral para todos os tipos de emergência. Seus processos de acesso de emergência descrevem as circunstâncias em que cada processo deve ser usado e, inversamente, as situações em que o processo não deve ser usado e apontam para processos alternativos que podem ser aplicados.

  • Seus processos são bem documentados com instruções detalhadas e playbooks que podem ser seguidos com rapidez e eficiência. Lembre-se de que um evento de emergência pode ser um momento estressante para os usuários e eles podem estar sob extrema pressão de tempo. Portanto, desenvolva o processo para ser o mais simples possível.

Práticas comuns que devem ser evitadas:

  • Você não tem processos de acesso de emergência bem documentados e bem testados. Os usuários não estão preparados para uma emergência e seguem processos improvisados quando um evento de emergência ocorre.

  • Seus processos de acesso de emergência dependem dos mesmos sistemas (como um provedor de identidades centralizado) que seus mecanismos de acesso normais. Isso significa que uma falha desse sistema pode afetar os mecanismos de acesso normal e de emergência e prejudicar sua capacidade de se recuperar da falha.

  • Seus processos de acesso de emergência são usados em situações não emergenciais. Por exemplo, os usuários muitas vezes utilizam de forma indevida os processos de acesso de emergência, pois acham mais fácil fazer alterações diretamente do que enviá-las por meio de um pipeline.

  • Seus processos de acesso de emergência não geram logs suficientes para auditar os processos, ou os logs não são monitorados para alertar sobre o possível uso indevido dos processos.

Benefícios de implementar esta prática recomendada:

  • Com processos de acesso de emergência bem documentados e testados, é possível reduzir o tempo gasto pelos usuários para responder e resolver um evento de emergência. Isso pode resultar em menos tempo de inatividade e maior disponibilidade dos serviços fornecidos aos seus clientes.

  • É possível rastrear cada solicitação de acesso de emergência e detectar e alertar sobre tentativas não autorizadas de uso indevido do processo para eventos não emergenciais.

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

Orientação para implementação

Esta seção fornece orientação para criar processos de acesso de emergência para vários modos de falha relacionados às cargas de trabalho implantadas AWS, começando com uma orientação comum que se aplica a todos os modos de falha e seguida por uma orientação específica com base no tipo de modo de falha.

Orientação comum para todos os modos de falha

Pense no seguinte ao projetar um processo de acesso de emergência para um modo de falha:

  • Documente as pré-condições e as suposições do processo: quando o processo deve ou não ser usado. Isso ajuda a detalhar o modo de falha e documentar suposições, como o estado de outros sistemas relacionados. Por exemplo, o processo do Modo de Falha 2 pressupõe que o provedor de identidade esteja disponível, mas a configuração ativada tenha sido AWS modificada ou tenha expirado.

  • Pré-crie os recursos necessários para o processo de acesso de emergência (SEC10-BP05). Por exemplo, pré-crie o acesso de emergência Conta da AWS com IAM usuários e funções e as funções entre contas em todas as contas IAM de carga de trabalho. Isso verifica se esses recursos estão prontos e disponíveis quando um evento de emergência ocorre. Ao pré-criar recursos, você não depende do plano de AWS controle APIs (usado para criar e modificar AWS recursos) que pode estar indisponível em uma emergência. Além disso, ao pré-criar IAM recursos, você não precisa considerar possíveis atrasos devido à eventual consistência.

  • Inclua processos de acesso de emergência como parte de seus planos de gerenciamento de incidentes (SEC10-BP02). Documente como os eventos de emergência são acompanhados e comunicados a outras pessoas na organização, como equipes de colegas, sua liderança e, quando aplicável, externamente a seus clientes e parceiros de negócios.

  • Defina o processo de solicitação de acesso de emergência no sistema de fluxo de trabalho de solicitação de serviço existente, caso haja um. Normalmente, esses sistemas de fluxo de trabalho permitem criar formulários de admissão para coletar informações sobre a solicitação, rastrear a solicitação em cada estágio do fluxo de trabalho e adicionar etapas de aprovação automatizadas e manuais. Relacione cada solicitação a um evento de emergência correspondente acompanhado no sistema de gerenciamento de incidentes. Ter um sistema uniforme para acessos de emergência permite que você acompanhe essas solicitações em um único sistema, analise as tendências de uso e melhore os processos.

  • Verifique se os processos de acesso de emergência só podem ser iniciados por usuários autorizados e exigem aprovações dos colegas ou da gerência do usuário, conforme apropriado. O processo de aprovação deve operar de forma eficaz dentro e fora do horário comercial. Defina como as solicitações de aprovação permitirão aprovadores secundários se os aprovadores primários não estiverem disponíveis e forem encaminhadas para a cadeia de gerenciamento até serem aprovadas.

  • Verifique se o processo gera logs e eventos de auditoria detalhados para tentativas bem-sucedidas e fracassadas de obter acesso de emergência. Monitore o processo de solicitação e o mecanismo de acesso de emergência para detectar uso indevido ou acessos não autorizados. Correlacione a atividade com eventos de emergência contínuos do sistema de gerenciamento de incidentes e alerte quando as ações ocorrerem fora dos períodos esperados. Por exemplo, você deve monitorar e alertar sobre atividades na Conta da AWS de acesso de emergência, pois ela nunca deve ser usada em operações normais.

  • Teste os processos de acesso de emergência periodicamente para verificar se as etapas estão claras e garantir o nível correto de acesso com rapidez e eficiência. Seus processos de acesso de emergência devem ser testados como parte das simulações de resposta a incidentes (SEC10-BP07) e dos testes de recuperação de desastres (-BP03). REL13

Modo de falha 1: o provedor de identidade usado para federar AWS não está disponível

Conforme descrito em SEC02-BP04 Confie em um provedor de identidade centralizado, recomendamos confiar em um provedor de identidade centralizado para federar os usuários da sua força de trabalho aos quais conceder acesso. Contas da AWS Você pode federar para vários Contas da AWS em sua AWS organização usando o IAM Identity Center ou pode federar para indivíduos Contas da AWS usando. IAM Nos dois casos, os usuários da força de trabalho se autenticam com seu provedor de identidades centralizado antes de serem redirecionados a um endpoint de login da AWS para SSO.

No caso improvável do provedor de identidades centralizado não estar disponível, os usuários da sua força de trabalho não poderão se federar nas Contas da AWS nem gerenciar as workloads. Nesse evento de emergência, você pode fornecer um processo de acesso de emergência para um pequeno grupo de administradores acessarem Contas da AWS para realizar tarefas críticas que não podem esperar até que seus provedores de identidade centralizados estejam online novamente. Por exemplo, seu provedor de identidade fica indisponível por 4 horas e, durante esse período, você precisa modificar os limites superiores de um grupo do Amazon EC2 Auto Scaling em uma conta de produção para lidar com um aumento inesperado no tráfego de clientes. Seus administradores de emergência devem seguir o processo de acesso de emergência para obter acesso à produção específica Conta da AWS e fazer as alterações necessárias.

O processo de acesso de emergência depende de um acesso de emergência pré-criado Conta da AWS que é usado exclusivamente para acesso de emergência e tem AWS recursos (como IAM funções e IAM usuários) para apoiar o processo de acesso de emergência. Durante as operações normais, ninguém deve acessar a conta de acesso de emergência, e você deve monitorar e alertar sobre o uso indevido dessa conta (para receber mais detalhes, consulte a seção Orientação comum anterior).

A conta de acesso de emergência tem IAM funções de acesso de emergência com permissões para assumir funções entre contas Contas da AWS que exijam acesso de emergência. Essas IAM funções são pré-criadas e configuradas com políticas de confiança que confiam nas IAM funções da conta de emergência.

O processo de acesso de emergência pode usar uma das seguintes abordagens:

  • Você pode pré-criar um conjunto de IAMusuários para seus administradores de emergência na conta de acesso de emergência com senhas e MFA tokens fortes associados. Esses IAM usuários têm permissões para assumir as IAM funções que, então, permitem o acesso entre contas ao Conta da AWS local onde o acesso de emergência é necessário. Recomendamos criar o menor número possível de usuários e atribuir cada um a um único administrador de emergência. Durante uma emergência, um usuário administrador de emergência entra na conta de acesso de emergência usando sua senha e código de MFA token, alterna para a IAM função de acesso de emergência na conta de emergência e, finalmente, muda para a IAM função de acesso de emergência na conta de carga de trabalho para realizar a ação de alteração de emergência. A vantagem dessa abordagem é que cada IAM usuário é atribuído a um administrador de emergência e você pode saber qual usuário fez login analisando os eventos. CloudTrail A desvantagem é que você precisa manter vários IAM usuários com suas senhas e MFA tokens de longa duração associados.

  • Você pode usar o usuário Conta da AWS raiz de acesso de emergência para entrar na conta de acesso de emergência, assumir a IAM função de acesso de emergência e assumir a função entre contas na conta de carga de trabalho. Recomendamos definir uma senha forte e vários MFA tokens para o usuário root. Também recomendamos armazenar a senha e os MFA tokens em um cofre seguro de credenciais corporativas que imponha autenticação e autorização fortes. Você deve proteger os fatores de redefinição de senha e MFA token: defina o endereço de e-mail da conta como uma lista de distribuição de e-mail monitorada pelos administradores de segurança da nuvem e o número de telefone da conta como um número de telefone compartilhado que também seja monitorado pelos administradores de segurança. A vantagem dessa abordagem é que há um conjunto de credenciais de usuário-raiz para gerenciar. A desvantagem é que, como se trata de um usuário compartilhado, vários administradores podem fazer login como usuário-raiz. Você deve fazer auditoria dos eventos de log do cofre corporativo para identificar qual administrador fez check-out da senha do usuário-raiz.

Modo de falha 2: a configuração do provedor de identidade AWS ativada foi modificada ou expirou

Para permitir que os usuários da sua força de trabalho se federem Contas da AWS, você pode configurar o IAM Identity Center com um provedor de identidade externo ou criar um IAM provedor de identidade (SEC02-BP04). Normalmente, você os configura importando um XML documento de SAML metadados fornecido pelo seu provedor de identidade. O XML documento de metadados inclui um certificado X.509 correspondente a uma chave privada que o provedor de identidade usa para assinar suas declarações. SAML

Essas configurações no AWS lado esquerdo podem ser modificadas ou excluídas por engano por um administrador. Em outro cenário, o certificado X.509 importado AWS pode expirar e um novo metadado XML com um novo certificado ainda não foi importado. AWS Ambos os cenários podem interromper a federação AWS para os usuários da sua força de trabalho, resultando em uma emergência.

Nesse evento de emergência, você pode fornecer acesso aos seus administradores de identidade AWS para corrigir os problemas de federação. Por exemplo, seu administrador de identidade usa o processo de acesso de emergência para entrar no acesso de emergência Conta da AWS, muda para uma função na conta de administrador do Identity Center e atualiza a configuração do provedor de identidade externo importando o XML documento de SAML metadados mais recente do seu provedor de identidade para reativar a federação. Após a federação ser corrigida, os usuários da sua força de trabalho continuarão usando o processo operacional normal para federar em suas contas da workload.

Você pode seguir as abordagens detalhadas no Modo de falha 1 anterior para criar um processo de acesso de emergência. É possível conceder permissões de privilégio mínimo aos seus administradores de identidade a fim de acessar somente a conta de administrador do Centro de Identidade e realizar ações no Centro de Identidade nessa conta.

Modo de falha 3: interrupção do Centro de Identidade

No caso improvável de uma Central de IAM Identidades ou Região da AWS interrupção, recomendamos que você defina uma configuração que possa ser usada para fornecer acesso temporário ao AWS Management Console.

O processo de acesso de emergência usa a federação direta do seu provedor de identidade para IAM uma conta de emergência. Para obter detalhes sobre o processo e as considerações de design, consulte Configurar o acesso de emergência ao AWS Management Console.

Etapas de implementação

Etapas comuns para todos os modos de falha

  • Crie um Conta da AWS dedicado aos processos de acesso de emergência. Pré-crie os IAM recursos necessários na conta, como IAM funções ou IAM usuários e, opcionalmente, provedores de IAM identidade. Além disso, pré-crie IAM funções entre contas na carga de trabalho com relações de confiança Contas da AWS com as IAM funções correspondentes na conta de acesso de emergência. Você pode usar AWS CloudFormation StackSets with AWS Organizations para criar esses recursos nas contas dos membros da sua organização.

  • Crie políticas de controle de AWS Organizations serviço (SCPs) para negar a exclusão e modificação das IAM funções entre contas no membro. Contas da AWS

  • Ative CloudTrail o acesso de emergência Conta da AWS e envie os eventos da trilha para um bucket central do S3 em sua coleção Conta da AWS de registros. Se você estiver usando AWS Control Tower para configurar e controlar seu ambiente de AWS várias contas, todas as contas que você cria usando AWS Control Tower ou nas AWS Control Tower quais se inscreve são CloudTrail ativadas por padrão e enviadas para um bucket do S3 em um arquivo de log dedicado. Conta da AWS

  • Monitore a atividade da conta de acesso de emergência criando EventBridge regras que correspondam ao login do console e à API atividade das IAM funções de emergência. Envie notificações ao seu centro de operações de segurança quando ocorrerem atividades fora de um evento de emergência contínuo acompanhado no sistema de gerenciamento de incidentes.

Etapas adicionais para o Modo de Falha 1: O provedor de identidade usado para federar não AWS está disponível e o Modo de Falha 2: a configuração do provedor de identidade ativada foi AWS modificada ou expirou

  • Crie previamente recursos de acordo com o mecanismo escolhido para acesso de emergência:

    • Usando IAM usuários: pré-crie os IAM usuários com senhas fortes e MFA dispositivos associados.

    • Utilizar o usuário-raiz da conta de emergência: configure o usuário-raiz com uma senha forte e armazene a senha no seu cofre de credenciais corporativo. Associe vários MFA dispositivos físicos ao usuário raiz e armazene os dispositivos em locais que possam ser acessados rapidamente pelos membros da sua equipe de administradores de emergência.

Etapas adicionais para o Modo de falha 3: interrupção do Centro de Identidade

  • Conforme detalhado em Configurar o acesso de emergência ao AWS Management Console, no acesso de emergência Conta da AWS, crie um provedor de IAM identidade para habilitar a SAML federação direta do seu provedor de identidade.

  • Crie grupos de operações de emergência no IdP sem membros.

  • Crie IAM funções correspondentes aos grupos de operações de emergência na conta de acesso de emergência.

Recursos

Práticas recomendadas do Well-Architected relacionadas:

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados: