SEC03-BP05 Definir barreiras de proteção de permissões para sua organização - Pilar de segurança
Orientação para implementaçãoRecursos

SEC03-BP05 Definir barreiras de proteção de permissões para sua organização

Use barreiras de proteção de permissões para reduzir o escopo das permissões disponíveis que podem ser concedidas a entidades principais. A cadeia de avaliação da política de permissões inclui suas grades de proteção para determinar as permissões efetivas de uma entidade principal ao tomar decisões de autorização.  Você pode definir barreiras de proteção usando uma abordagem baseada em camadas. Aplique algumas barreiras de proteção de maneira abrangente em toda a organização e outras de forma detalhada às sessões de acesso temporário.

Resultado desejado: você obtém um isolamento claro dos ambientes usando Contas da AWS sparapdpas.  As políticas de controle de serviços (SCPs) são usadas para definir barreiras de proteção de permissões em toda a organização. As barreiras de proteção mais amplas são definidas nos níveis hierárquicos mais próximos da raiz da sua organização e as barreiras de proteção mais rígidas são definidas mais perto do nível das contas individuais.

Quando aceitas, as políticas de recursos definem as condições que uma entidade principal deve satisfazer para obter acesso a um recurso. As políticas de recursos também abrangem o conjunto de ações permitidas, quando apropriado. Os limites de permissão são impostos às entidades principais que gerenciam as permissões da workload, delegando o gerenciamento de permissões aos proprietários de workload individuais.

Práticas comuns que devem ser evitadas:

  • Criar Contas da AWS-membro dentro de uma organização da AWS, mas não usar SCPs para restringir o uso e as permissões disponíveis para suas credenciais de raiz.

  • Atribuir permissões com base em privilégio mínimo, mas não colocar barreiras de proteção no conjunto máximo de permissões que podem ser concedidas.

  • Confiar na base de negação implícita do AWS IAM para restringir as permissões, confiando que as políticas não concederão uma permissão explícita indesejada.

  • Executar vários ambientes de workload na mesma Conta da AWS e confiar em mecanismos como VPCs, tags ou políticas de recursos para impor limites de permissão.

Benefícios de implementar esta prática recomendada: as barreiras de proteção de permissões ajudam a criar confiança de que permissões indesejadas não podem ser concedidas, mesmo quando uma política de permissão tenta fazer isso.  Isso pode simplificar a definição e o gerenciamento de permissões, reduzindo o escopo máximo das permissões que precisam ser consideradas.

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

Orientação para implementação

Recomendamos usar uma abordagem baseada em camadas para definir barreiras de proteção de permissões para sua organização. Essa abordagem reduz sistematicamente o conjunto máximo de permissões possíveis à medida que camadas adicionais são aplicadas. Isso ajuda você a conceder acesso com base no princípio de privilégio mínimo, reduzindo o risco de acesso indesejado devido à configuração incorreta de alguma política.

A primeira etapa para estabelecer barreiras de proteção de permissões é isolar workloads e ambientes em Contas da AWS separadas. As entidades principais de uma conta não podem acessar recursos em outra conta sem permissão explícita para fazer isso, mesmo quando as duas contas estão na mesma organização da AWS ou na mesma unidade organizacional (UO). Você pode usar UOs para agrupar contas que deseja administrar como uma única unidade.   

A próxima etapa é reduzir o conjunto máximo de permissões que você pode conceder às entidades principais nas contas-membro da sua organização. Você pode usar políticas de controle de serviço (SCPs) para essa finalidade, as quais podem ser aplicadas a uma UO ou a uma conta. As SCPs podem impor controles de acesso comuns, como restringir o acesso a determinadas Regiões da AWS, ajudar a impedir a exclusão de recursos ou desabilitar ações de serviço possivelmente arriscadas. As SCPs que você aplica à raiz da sua organização afetam apenas as contas-membro, mas não a conta de gerenciamento.  As SCPs regem apenas as entidades principais da sua organização. As SCPs não regem entidades principais externas à sua organização que estão acessando seus recursos.

Se você estiver usando o AWS Control Tower, poderá aproveitar os controles e as zonas de pouso como base para as barreiras de proteção de permissões e ambiente de várias contas. As zonas de pouso fornecem um ambiente básico seguro e pré-configurado com contas separadas para diferentes workloads e aplicações. As barreiras de proteção impõem controles obrigatórios sobre segurança, operações e conformidade por meio de uma combinação de políticas de controle de serviços (SCPs), regras do AWS Config e outras configurações. No entanto, ao usar barreiras de proteção e zonas de pouso do Control Tower com as SCPs personalizadas da organização, é crucial seguir as práticas recomendadas descritas na documentação da AWS para evitar conflitos e garantir a governança adequada. Consulte a orientação do AWS Control Tower para o AWS Organizations a fim de obter recomendações detalhadas sobre o gerenciamento de SCPs, contas e unidades organizacionais (OUs) em um ambiente do Control Tower.

Ao aderir a essas diretrizes, você pode aproveitar com eficácia as barreiras de proteção e zonas de pouso do Control Tower e as SCPs personalizadas, ao mesmo tempo em que mitiga possíveis conflitos e garante a governança e o controle adequados sobre seu ambiente de várias contas da AWS.

Outra etapa é usar políticas de recursos do IAM para definir o escopo das ações disponíveis que você pode realizar nos recursos por elas governados, juntamente com quaisquer condições que o diretor interino deva atender. Isso pode ser tão amplo quanto permitir todas as ações, desde que a entidade principal faça parte da sua organização (usando a chave de condição PrincipalOrgID), ou tão granular quanto permitir apenas ações específicas de um perfil do IAM específico. É possível adotar uma abordagem semelhante com as condições das políticas de confiança de perfis do IAM.  Se uma política de confiança de recursos ou perfis nomear explicitamente uma entidade principal na mesma conta que o perfil ou o recurso por ela governado, essa entidade principal não precisará de uma política do IAM anexada que conceda as mesmas permissões.  Se a entidade principal estiver em uma conta diferente da conta do recurso, ela precisará de uma política do IAM anexada que conceda essas permissões.

Muitas vezes, uma equipe de workload quer gerenciar as permissões exigidas pela workload em questão.  Isso, por sua vez, pode exigir que a equipe crie políticas de permissão e perfis do IAM.  É possível capturar o escopo máximo de permissões que a equipe pode conceder em um limite de permissão do IAM e associar esse documento a um perfil do IAM que a equipe pode usar para gerenciar seus perfis do IAM e permissões.  Essa abordagem pode proporcionar à equipe a flexibilidade para concluir o trabalho e, ao mesmo tempo, reduzir os riscos de acesso administrativo ao IAM.

Uma etapa mais granular é implementar técnicas de gerenciamento de acesso privilegiado (PAM) e gerenciamento de acesso elevado temporário (TEAM).  Um exemplo de PAM é exigir que as entidades principais realizem a autenticação multifator antes de executar ações privilegiadas.  Para obter mais informações, consulte Configuração de acesso à API protegido por MFA. O TEAM exige uma solução que gerencie a aprovação e o período durante o qual uma entidade principal pode ter acesso elevado.  Uma abordagem é adicionar temporariamente a entidade principal à política de confiança de perfis referente a um perfil do IAM que tenha acesso elevado.  Outra abordagem é, em operação normal, reduzir o escopo das permissões concedidas a uma entidade principal por um perfil do IAM usando uma política de sessão e, em seguida, suspender temporariamente essa restrição durante o período aprovado. Para saber mais sobre as soluções validadas pela AWS e por parceiros selecionados, consulte Acesso elevado temporário.

Etapas de implementação

  1. Isole workloads e ambientes em Contas da AWS separadas.

  2. Use SCPs para reduzir o conjunto máximo de permissões que podem ser concedidas às entidades principais nas contas dos membros da sua organização.

    1. Ao definir SCPs para reduzir o conjunto máximo de permissões que podem ser concedidas às entidades principais nas contas dos membros da sua organização, você pode escolher entre uma abordagem de lista de permissões ou listas de negação. A estratégia da lista de permissões especifica explicitamente o acesso permitido e bloqueia implicitamente todos os outros acessos. A estratégia da lista de negação especifica explicitamente o acesso não permitido e permite todos os outros acessos por padrão. Ambas as estratégias têm suas vantagens e desvantagens, e a escolha apropriada depende dos requisitos específicos e do modelo de risco de sua organização. Para obter mais detalhes, consulte Estratégia para usar SCPs.

    2. Além disso, analise os exemplos de políticas de controle de serviços para entender como construir SCPs de forma eficaz.

  3. Use políticas de recursos do IAM para reduzir o escopo e especificar as condições das ações permitidas nos recursos.  Use condições nas políticas de confiança de perfis do IAM para criar restrições aos perfis assumidos.

  4. Atribua limites de permissão do IAM a perfis do IAM que as equipes de workload podem usar para gerenciar perfis e permissões do IAM de suas próprias workloads.

  5. Avalie as soluções de PAM e TEAM com base em suas necessidades.

Recursos

Documentos relacionados:

Exemplos relacionados:

Ferramentas relacionadas: