 |
Hoje tenho o prazer de apresentar políticas de controle de recursos (RCPs) – uma nova política de autorização gerenciada no AWS Organizations que pode ser usada para definir o máximo de permissões disponíveis em recursos em toda a sua organização. Eles são um tipo de controle preventivo que ajuda a estabelecer um perímetro de dados em seu ambiente AWS e restringir o acesso externo a recursos em escala. Aplicados centralmente nas organizações, os RCPs proporcionam às equipes centrais de governança e segurança a confiança de que o acesso aos recursos em suas contas da AWS está em conformidade com as diretrizes de controle de acesso da organização.
Os RCPs estão disponíveis em todas as regiões comerciais da AWS e, no lançamento, os seguintes serviços são suportados: Serviço de armazenamento simples da Amazon (Amazon S3), Serviço de token de segurança da AWS (AWS STS), Serviço de gerenciamento de chaves da AWS (AWS KMS), Serviço de fila simples da Amazon (Amazon SQS)e Gerenciador de segredos da AWS.
Não há custos adicionais para ativar e usar RCPs.
Como elas são diferentes das políticas de controle de serviço (SCPs)?
Embora de natureza semelhante, os RCPs complementam políticas de controle de serviço (SCPs)mas eles funcionam de forma independente.
As políticas de controle de serviço (SCPs) permitem limitar as permissões concedidas aos principais da sua organização, como funções do AWS Identification and Entry Administration (IAM). Ao restringir essas permissões centralmente nas organizações, você pode restringir o acesso a serviços da AWS, recursos específicos e até mesmo sob quais condições os principais podem fazer solicitações em várias contas da AWS.
Os RCPs, por outro lado, permitem limitar as permissões concedidas aos recursos da sua organização. Como você implementa RCPs centralmente nas organizações, você pode impor controles de acesso consistentes aos recursos em várias contas da AWS. Por exemplo, você pode restringir o acesso aos buckets S3 em suas contas para que eles possam ser acessados apenas por entidades principais que pertencem à sua organização. Os RCPs são avaliados quando seus recursos estão sendo acessados, independentemente de quem está fazendo a solicitação da API.
Tenha em mente que nem SCPs nem RCPs concedem quaisquer permissões. Eles definem apenas as permissões máximas disponíveis para entidades principais e recursos em sua organização. Você ainda precisa conceder permissões com políticas do IAM apropriadas, como políticas baseadas em identidade ou em recursos.
As cotas para SCPs e RCPs são completamente independentes umas das outras. Cada RCP pode conter até 5.120 caracteres. Você pode ter até cinco RCPs anexados à raiz da organização, a cada UO e conta, e pode criar e armazenar até 1.000 RCPs em uma organização.
Como começar
Para começar a usar RCPs você deve primeiro habilitá-los. Você pode fazer isso usando o console do Organizations, um SDK da AWSou usando o Interface de linha de comando da AWS (AWS CLI). Certifique-se de usar a conta de gerenciamento Organizações ou um administrador delegado, pois essas são as únicas contas que podem ativar ou desativar tipos de política.
Certifique-se de estar usando Organizações com o “todos os recursos”Opção. Se você estiver usando o “Recursos de faturamento consolidado”Modo, então você precisa migrar para usar todos os recursos antes de ativar RCPs.
Para usuários do console, primeiro acesse o console do Organizations. Escolher Políticas e você deverá ver a opção para ativar Políticas de controle de recursos.
Depois que os RCPs forem ativados, você notará no Políticas de controle de recursos página que uma nova política chamou RCPFullAWSAccess agora está disponível. Esta é uma política gerenciada pela AWS que é automaticamente criada e anexada a todas as entidades da sua organização, incluindo a raiz, cada UO e conta da AWS.
Esta política permite que todos os principais executem qualquer ação contra os recursos da organização, o que significa que até você começar a criar e anexar seus próprios RCPs, todas as suas permissões IAM existentes continuarão a operar como antes.
É assim que parece:
Criando um RCP
Agora estamos prontos para criar nosso primeiro RCP! Vejamos um exemplo.
Por padrão, os recursos da AWS não permitem acesso a entidades externas; os proprietários de recursos devem conceder explicitamente esse acesso configurando suas políticas. Embora os desenvolvedores tenham flexibilidade para definir políticas baseadas em recursos de acordo com as necessidades de seus aplicativos, os RCPs permitem que as equipes centrais de TI mantenham o controle sobre as permissões efetivas nos recursos de sua organização. Isso garante que, mesmo que os desenvolvedores concedam acesso amplo, as identidades externas ainda terão acesso restrito de acordo com os requisitos de segurança da organização.
Vamos criar um RCP para restringir o acesso aos nossos buckets S3 para que apenas os principais da nossa organização possam acessá-los.
No Políticas de controle de recursos página, escolha Criar política que o levará à página onde você pode criar uma nova política.
Vou chamar esta política EnforceOrgIdentities. Recomendo que você insira uma descrição clara para que seja fácil entender à primeira vista o que esta política faz e marcá-la adequadamente.
A próxima seção é onde você pode editar sua declaração de política. Substituo o modelo de política pré-preenchido pelo meu:
Aqui está o documento de política JSON completo:
Vamos decompô-lo:
Versão – Este é um elemento padrão e obrigatório das políticas IAM. A AWS mantém compatibilidade com versões anteriores, portanto, usar a versão mais recente, atualmente 17/10/2012, não viola as políticas existentes, mas permite que você use recursos mais recentes.
Declaração – Uma matriz que pode conter um ou mais objetos de instrução. Cada um desses objetos de instrução outline uma única permissão ou conjunto de permissões.
Sid – Este é um campo opcional que pode ser útil para gerenciamento de políticas e solução de problemas. Ele precisa ser exclusivo dentro do escopo deste documento de política JSON.
Efeito – Como você deve se lembrar anteriormente, por padrão, temos um RCP que permite acesso a cada principal, ação e recurso da AWS anexado a cada entidade em nossa organização. Portanto, você deve usar Deny para aplicar restrições.
Principal – Para um RCP, este campo deve ser sempre definido como "*". Use o campo Condição se quiser que esta política se aplique apenas a entidades de segurança específicas.
Ação – Especifica o serviço AWS e as ações às quais esta política se aplica. Nesse caso, queremos negar todas as interações com o Amazon S3 se elas não atenderem às nossas diretrizes de controle de acesso.
Recurso – Especifica os recursos aos quais o RCP se aplica.
Doença – Uma coleção de condições que serão avaliadas para determinar se a política deve ser aplicada ou não para cada solicitação.
É importante lembrar que todas as condições devem ser avaliadas como verdadeiras para que o RCP seja aplicado. Neste caso, estamos aplicando duas condições:
1. A solicitação foi feita por um diretor externo?
"StringNotEqualsIfExists":
{
"aws:PrincipalOrgID": "(MY ORG ID)"
}Esta condição primeiro verifica se a chave aws:PrincipalOrgID está presente na solicitação. Caso contrário, essa condição será avaliada como verdadeira sem avaliação adicional.
Se existir, ele compara o valor com o ID da nossa organização. Se o valor for o mesmo, ele será avaliado como falso, o que significa que o RCP não será aplicado porque todas as condições devem ser avaliadas como verdadeiras. Este é o comportamento pretendido porque não queremos negar acesso aos principais dentro da nossa organização.
No entanto, se o valor não corresponder ao ID da nossa organização, isso significa que a solicitação foi feita por um principal externo à nossa organização. A condição é avaliada como verdadeira, o que significa que o RCP ainda pode ser potencialmente aplicado, desde que a segunda condição também seja avaliada como verdadeira.
2. A solicitação vem de um serviço AWS?
"BoolIfExists":
{
"aws:PrincipalIsAWSService": "false"
}Esta condição testa se a solicitação contém uma chave especial chamada aws:PrincipalIsAWSService que é injetado automaticamente no contexto da solicitação para todas as solicitações de API assinadas e é definido como verdadeiro quando se origina de um serviço da AWS, como AWS CloudTrail gravando eventos em seu bucket S3. Se a chave não estiver presente, esta condição será avaliada como true.
Se existir, então comparará o valor com o que declaramos em nossa declaração. Neste caso, estamos testando se o valor é igual a false. Se for, então voltamos true já que isso significaria que a solicitação não foi feita por um serviço da AWS e ainda poderia ter sido feita por alguém de fora da nossa organização. Caso contrário, voltamos false.
Em outras palavras, se a solicitação não tiver origem em um principal de nossa organização e não tiver origem em um serviço da AWS, o acesso ao bucket S3 será negado.
Esta política é apenas um exemplo e você deve adaptá-la para atender aos seus objetivos comerciais e de segurança exclusivos. Por exemplo, você pode querer personalizar esta política para permitir o acesso de seus parceiros de negócios ou restringir o acesso aos serviços da AWS para que eles possam acessar seus recursos somente em seu nome. Ver Estabelecendo um perímetro de dados na AWS: permitir que apenas identidades confiáveis acessem os dados da empresa para mais detalhes.
Anexando um RCP
O processo de anexar um RCP é semelhante ao de um SCP. Conforme mencionado anteriormente, você pode anexá-lo à raiz da sua organização, a uma unidade organizacional ou a contas específicas da AWS dentro da sua organização.
Depois que o RCP for anexado, as solicitações de acesso aos recursos afetados da AWS deverão estar em conformidade com as restrições do RCP. Recomendamos que você teste exaustivamente o impacto que o RCP tem nos recursos das suas contas antes de aplicá-lo em escala. Você pode começar anexando RCPs a contas de teste individuais ou UOs de teste.
Vendo isso em ação
Agora criei e anexei meu RCP, então estou pronto para vê-lo na prática! Vamos supor que um desenvolvedor anexou uma política baseada em recursos a um bucket S3 em nossa organização e concedeu explicitamente acesso a identidades em uma conta externa:
Os RCPs não impedem que os usuários salvem políticas baseadas em recursos que sejam mais permissivas do que o RCP permite. Porém, o RCP será avaliado como parte do processo de autorização, como vimos anteriormente, portanto a solicitação por identidades externas será negada de qualquer maneira.
Podemos provar isso tentando acessar o bucket com esta conta externa, desta vez a partir da AWS CLI:
Dimensionando a implantação de RCPs em seu ambiente
Até agora, vimos como podemos gerenciar RCPs usando o console. No entanto, para gerenciamento de controle em larga escala, você deve considerar configurá-los como infraestrutura como código e certificar-se de que eles estejam integrados aos pipelines e processos existentes de integração contínua e entrega contínua (CI/CD).
Se você usar Torre de controle AWSvocê poderá implantar controles baseados em RCP além de controles baseados em SCP. Por exemplo, você pode usar o AWS Management Tower para implantar um RCP semelhante ao que criamos no exemplo anterior, que impede que entidades externas acessem buckets S3 em nossa organização. Isto garante que os RCPs sejam aplicados de forma consistente aos recursos em contas gerenciadas, simplificando e centralizando a governança do controle de acesso em escala.
Além disso, semelhante aos SCPs, o AWS Management Tower também oferece suporte à detecção de desvios para RCPs. Se um RCP for modificado ou removido fora do AWS Management Tower, você será notificado sobre o desvio e receberá etapas para correção.
Conclusão
As políticas de controle de recursos (RCPs) oferecem gerenciamento centralizado sobre o máximo de permissões disponíveis para recursos da AWS em sua organização. Junto com os SCPs, os RCPs ajudam você a estabelecer centralmente um perímetro de dados em todo o seu ambiente AWS e evite acessos não intencionais em grande escala. SCPs e RCPs são controles independentes que permitem atingir um conjunto distinto de objetivos de segurança. Você pode optar por habilitar apenas SCPs ou RCPs ou usar os dois tipos de política juntos para estabelecer uma linha de base de segurança abrangente como parte do modelo de segurança de defesa profunda.
Para saber mais, consulte Políticas de controle de recursos (RCPs) no Guia do usuário do AWS Organizations.