SEC03-BP03 Estabelecer processo de acesso de emergência - Framework Well-Architected da AWS
Orientação para implementação Recursos

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 são federados na nuvem usando um provedor de identidades centralizado (SEC02-BP04) para gerenciar suas workloads. 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 workloads implantadas na 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 identidades está disponível, mas a configuração na AWS foi modificada ou expirou.

  • Pré-crie os recursos necessários para o processo de acesso de emergência (SEC10-BP05). Por exemplo, crie previamente a Conta da AWS de acesso de emergência com usuários e perfis do IAM e os perfis do IAM entre contas em todas as contas da workload. 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 das APIs do ambiente de gerenciamento da AWS (usadas para criar e modificar recursos da AWS) que podem estar indisponíveis em caso de emergência. Além disso, ao pré-criar recursos do IAM, não é necessário considerar possíveis atrasos devido a consistência eventual.

  • Inclua processos de acesso de emergência como parte dos planos de gerenciamento de incidentes (SEC1-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.

  • Implemente mecanismos robustos de registro em log, monitoramento e alerta para o processo e os mecanismos de acesso de emergência. Gere logs de auditoria detalhados para todas as tentativas bem-sucedidas e fracassadas de obter acesso de emergência. Correlacione a atividade com eventos de emergência contínuos do sistema de gerenciamento de incidentes e inicie alertas quando as ações ocorrerem fora dos períodos esperados ou quando a conta de acesso de emergência for usada durante as operações normais. A conta de acesso de emergência só deve ser acessada durante emergências, pois os procedimentos de quebra de vidro podem ser considerados uma backdoor. Integre-se à sua ferramenta de gerenciamento de eventos e informações de segurança (SIEM) ou AWS Security Hub para relatar e auditar todas as atividades durante o período de acesso de emergência. Ao retornar às operações normais, alterne automaticamente as credenciais de acesso de emergência e notifique as equipes relevantes.

  • 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 (REL13-BP03).

Modo de falha 1: o provedor de identidades usado para federação na AWS não está disponível

Conforme descrito em SEC02-BP-04 Confiar em um provedor de identidade federado, recomendamos confiar em um provedor de identidades centralizado para federar os usuários de sua força de trabalho e conceder acesso a Contas da AWS. Você pode federar em várias Contas da AWS na organização da AWS usando o Centro de Identidade do IAM ou federar em Contas da AWS individuais usando o 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, é possível fornecer um processo de acesso de emergência para um pequeno grupo de administradores acessar as Contas da AWS a fim de realizar tarefas essenciais que não podem esperar até que seus provedores de identidades centralizados estejam online novamente. Por exemplo, seu provedor de identidades fica indisponível por quatro 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 a fim de obter acesso à Conta da AWS de produção específica e fazer as alterações necessárias.

O processo de acesso de emergência depende de uma Conta da AWS de acesso de emergência pré-criada usada exclusivamente para acesso de emergência e tem recursos da AWS (como perfis e usuários do IAM) 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 perfis do IAM de acesso de emergência com permissões para assumir perfis entre contas nas Contas da AWS que exigem acesso de emergência. Esses perfis do IAM são pré-criados e configurados com políticas de confiança que confiam nos perfis do IAM da conta de emergência.

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

  • É possível pré-criar um conjunto de usuários do IAM para seus administradores de emergência na conta de acesso de emergência com senhas fortes e tokens de MFA associados. Esses usuários do IAM têm permissões para assumir os perfis do IAM que permitem o acesso entre contas à Conta da AWS 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 token MFA, muda para o perfil do IAM de acesso de emergência na conta de emergência e, por fim, para o perfil do IAM de acesso de emergência na conta da workload para realizar a ação de alteração de emergência. A vantagem dessa abordagem é que cada usuário do IAM é atribuído a um administrador de emergência, e é possível saber qual usuário fez login analisando os eventos do CloudTrail. A desvantagem é que você precisa manter vários usuários do IAM com as respectivas senhas de longa duração e tokens de MFA associados.

  • É possível usar o usuário-raiz da Conta da AWS de emergência para entrar na conta de acesso de emergência, assumir o perfil do IAM para acesso de emergência e assumir o perfil entre contas na conta da workload. Recomendamos definir uma senha forte e vários tokens de MFA para o usuário-raiz. Também recomendamos armazenar a senha e os tokens de MFA em um cofre de credenciais corporativo seguro que imponha autenticação e autorização fortes. Você deve proteger a senha e os fatores de redefinição de tokens de MFA: defina o endereço de e-mail da conta como uma lista de distribuição de e-mail monitorada pelos administradores de segurança na 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 identidades na AWS foi modificada ou expirou

Para permitir que os usuários de sua força de trabalho sejam federados nas Contas da AWS, é possível configurar o Centro de Identidade do IAM com um provedor de identidades externo ou criar um provedor de identidades do IAM (SEC02-BP04). Normalmente, você os configura importando um documento XML de metadados SAML fornecido pelo provedor de identidades. O documento XML de metadados inclui um certificado X.509 correspondente a uma chave privada que o provedor de identidades usa para assinar as declarações SAML.

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

Nesse evento de emergência, você pode fornecer aos seus administradores de identidade acesso à AWS para resolver os problemas de federação. Por exemplo, seu administrador de identidade usa o processo de acesso de emergência para fazer login na Conta da AWS de acesso de emergência, muda para um perfil na conta de administrador do Centro de Identidade e atualiza a configuração do provedor de identidades externo importando o documento XML de metadados SAML mais recente do provedor de identidades 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 interrupção do Centro de Identidade do IAM ou da Região da AWS, recomendamos definir uma configuração que possa ser usada para conceder acesso temporário ao AWS Management Console.

O processo de acesso de emergência usa a federação direta do provedor de identidades no IAM em 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 uma Conta da AWS dedicada aos processos de acesso de emergência. Crie previamente os recursos do IAM necessários na conta, como perfis ou usuários do IAM e, opcionalmente, provedores de identidades do IAM. Além disso, crie previamente perfis do IAM entre contas nas Contas da AWS da workload com relacionamentos de confiança com os perfis do IAM correspondentes na conta de acesso de emergência. É possível usar o AWS CloudFormation StackSets com AWS Organizations para criar esses recursos nas contas-membro da sua organização.

  • Crie políticas de controle de serviços (SCP) do AWS Organizations para negar a exclusão e a modificação dos perfis do IAM entre contas nas Contas da AWS-membro.

  • Ative o CloudTrail para a Conta da AWS de acesso de emergência e envie os eventos da trilha a um bucket central do S3 em sua Conta da AWS de coleção de logs. Se você estiver usando o AWS Control Tower para configurar e controlar seu ambiente de várias contas da AWS, todas as contas que você criar usando o AWS Control Tower ou inscrever no AWS Control Tower terão o CloudTrail ativado por padrão e serão enviadas a um bucket do S3 em uma Conta da AWS de arquivo de log dedicado.

  • Monitore a atividade da conta de acesso de emergência criando regras do EventBridge que correspondam ao login do console e à atividade da API pelos perfis do IAM 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 identidades usado para federar na AWS não está disponível; Modo de falha 2: a configuração do provedor de identidades na AWS foi modificada ou expirou

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

    • Utilizar usuários do IAM: crie previamente os usuários do IAM com senhas fortes e dispositivos MFA 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 dispositivos físicos de MFA ao usuário-raiz e armazene os dispositivos em locais que possam ser acessados rapidamente pelos membros de 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, na Conta da AWS de acesso de emergência, crie um provedor de identidades do IAM para ativar a federação direta de SAML a partir do provedor de identidades.

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

  • Crie perfis do IAM 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: