AWS Organizations e service control policies

O time de segurança pede uma promessa: nenhuma conta da empresa pode desligar o CloudTrail. Você poderia escrever uma política do IAM negando cloudtrail:StopLogging e anexá-la a todo role das 40 contas. Ela funcionaria até o primeiro administrador de conta, que tem AdministratorAccess, removê-la.

Essa é a lacuna. Dentro de uma conta, o administrador está no topo da árvore, e tudo que você escreve ali ele reescreve. Uma promessa que se sustenta precisa de um ponto de controle acima da conta, de dono que o administrador local não consegue passar por cima. O AWS Organizations é esse ponto de controle, e uma service control policy é como você escreve a promessa.

O tópico anterior terminou na ordem de avaliação de uma requisição. Duas daquelas portas, SCPs e RCPs, são esta lição.

O formato de uma organização

Uma organização é uma árvore de contas AWS com um único root no topo. Sob o root você cria organizational units (OUs), e OUs aninham dentro de outras OUs. Contando o root e as contas na base, a hierarquia vai a 5 níveis.

Existem exatamente 2 tipos de conta:

• A conta de gerenciamento é a que criou a organização. Ela anexa políticas, cria e convida contas, designa administradores delegados e paga a fatura de todo mundo. Esse papel não pode ser transferido para outra conta depois.
• Toda outra conta é uma conta membro. Uma conta membro pertence a exatamente uma organização por vez.

Contas entram de 2 formas: a conta de gerenciamento as cria diretamente, ou convida uma conta avulsa que já existe, e o dono precisa aceitar. O convite roda como um handshake, termo que você só encontra usando a CLI ou a API, onde convites são objetos com tipos como INVITE e ENABLE_ALL_FEATURES.

Uma escolha de configuração decide se esta lição vale para você. Uma organização roda com o conjunto consolidated billing, que entrega uma fatura única e nada além disso, ou com all features, que acrescenta políticas e integrações de serviço. SCPs, RCPs e toda integração de serviço entre contas exigem all features. Subir de consolidated billing significa que cada conta membro convidada precisa aceitar um handshake aprovando a mudança.

A conta de gerenciamento não é governada

Este é o fato que molda todo desenho multi-conta: SCPs não têm efeito nenhum sobre usuários ou roles da conta de gerenciamento.

Não é efeito reduzido. É nenhum. Um SCP anexado ao root vale para toda OU e toda conta membro abaixo e pula a conta de gerenciamento por completo. O mesmo vale para RCPs e para os recursos que moram nela.

A consequência é a recomendação padrão da AWS: mantenha cargas de trabalho, dados e usuários do dia a dia fora da conta de gerenciamento. Tudo que vive ali está fora de todo guardrail que você escrever. Quando ainda assim é preciso trabalhar em nome da organização, designe um administrador delegado, que é uma conta membro comum registrada para administrar um serviço específico ou para gerenciar as políticas da organização. Administradores delegados são convenientes, mas repare na armadilha: um administrador delegado é uma conta membro, então SCPs valem para ele. Ter a confiança de gerenciar o Config da organização não levanta os guardrails da conta que faz esse gerenciamento.

O que um SCP é, e o que ele não é

Um SCP parece quase idêntico a uma política do IAM. Mesmos elementos Version, Statement, Effect, Action, Resource, Condition, mesmo JSON.

E se comporta de forma completamente diferente em um ponto que decide a maioria das questões de prova: um SCP não concede permissão nenhuma. Ele define o máximo de permissões disponíveis para usuários e roles IAM em contas membro. As permissões continuam vindo de políticas de identidade e de recurso, e a permissão efetiva é a interseção.

Leia isso como uma equação que você aplica sob pressão:

o que um principal de fato consegue fazer
  = (o que o SCP permite)
  E (o que a política de identidade permite)
  E (o que o permissions boundary permite, se existir um)

Os dois lados do modo de falha saem daí. Um usuário com AdministratorAccess sob um SCP que nunca menciona S3 não toca no S3. Um usuário sem política nenhuma do IAM sob um SCP que permite todo serviço não faz nada. O SCP é o teto, e um teto sem chão deixa você em pé no chão mesmo.

Uma regra extra quando entram boundaries: se um permissions boundary e um SCP se aplicam ao mesmo tempo, o boundary, o SCP e a política de identidade precisam permitir a ação. Três interseções, nenhuma união.

Como SCPs herdam: um Allow precisa de todo nível, um Deny precisa de um

Anexar uma política no root, em uma OU ou em uma conta é fácil. Prever o resultado em uma árvore de 4 níveis é onde as pessoas erram, porque Allow e Deny viajam de formas diferentes.

Para uma permissão ser permitida, um Allow explícito precisa existir em todo nível do caminho direto do root, passando por cada OU, até a própria conta. Falta um, a conta é negada. A avaliação de SCP nega por padrão: tudo que não é explicitamente permitido em todo nível fica negado.

Para uma permissão ser negada, um único Deny em qualquer ponto desse caminho já basta. Root, qualquer OU no meio do caminho, ou a própria conta.

Trabalhe um exemplo. O root tem FullAWSAccess. A Production OU tem uma política customizada permitindo só ec2:* e cloudwatch:*. A Account B, dentro da Production, tem FullAWSAccess anexado diretamente. Um usuário da Account B carrega AdministratorAccess e chama s3:ListBucket.

Negado. O root permite S3 e a conta permite S3, mas a Production OU nunca permitiu, e a cadeia rompeu ali. Repare no que isso significa na prática: o Allow mais estreito do caminho define o teto de tudo abaixo dele. Coloque uma allow list no root e ela governa a organização inteira em silêncio, não importa o que cada OU anexe embaixo.

Agora o caso espelhado. O root tem FullAWSAccess. A Sandbox OU tem FullAWSAccess mais uma política negando s3:*. A Account A e a Account B estão as duas na Sandbox e não têm política própria relacionada ao S3. As duas ficam sem S3. Nenhuma das contas fez nada errado, e nenhuma consegue resolver isso localmente.

Essa assimetria é o desenho inteiro. Denies servem para controles que precisam valer amplamente, porque anexar um bem no alto cobre tudo abaixo. Allows servem para definir uma superfície permitida, e são frágeis, porque todo nível precisa colaborar.

FullAWSAccess, e o jeito mais silencioso de quebrar uma organização

Quando você habilita SCPs, a AWS anexa uma política gerenciada chamada FullAWSAccess ao root, a toda OU e a toda conta. Ela permite todas as ações em todos os recursos. OUs e contas novas recebem a política automaticamente ao serem criadas.

Ela existe só por causa da regra de allow acima. Sem um Allow em todo nível nada funciona, então a AWS pré-anexa um allow geral para que o modelo de negar por padrão não te tranque para fora no primeiro dia.

O que produz o modo de falha que vale nomear: remover o FullAWSAccess sem anexar um allow substituto quebra toda conta abaixo daquele ponto. Toda chamada de API falha, e a mensagem de erro aponta para um SCP, não para nada dentro da conta. Não existe caixa de confirmação que te segure. Se você remover no root, a organização inteira para.

A armadilha vizinha: desabilitar o tipo de política SCP em um root remove todos os SCPs de todas as entidades daquele root, e essas anexações não são recuperáveis. Reabilitar te devolve um quadro limpo com apenas o FullAWSAccess de volta, e você reanexa tudo na mão.

Allow list ou deny list

Duas estratégias, e a prova espera que você reconheça qual delas um cenário está descrevendo.

Deny lists são o caso comum, e a maioria dos exemplos publicados assume uma, e é por isso que dizem em letra miúda "você também precisa do FullAWSAccess anexado". As statements deles só subtraem, então sem um allow em algum ponto do caminho elas subtraem de nada.

Uma observação que a documentação faz de forma explícita: depender só de statements de allow e do modelo de negar por padrão ainda pode produzir acesso indesejado, porque um Allow amplo em um nível não desfaz outro mais amplo em outro ponto do caminho. Denies são a ferramenta mais afiada.

Um guardrail trabalhado

A promessa sobre o CloudTrail da abertura, escrita direito:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectAuditAndComplianceServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/OrgSecurityBreakGlass"
        }
      }
    },
    {
      "Sid": "KeepAccountsInTheOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Três coisas estão trabalhando aqui.

Os valores de Sid não são decoração. Quando uma chamada é negada por um SCP, a mensagem de erro nomeia o tipo de política, e identificadores legíveis encurtam a conversa que vem depois.

A condição ArnNotLike abre uma exceção para um role de break-glass em cada conta, usando o curinga na posição do ID da conta. Este é o comportamento de operador negado da lição anterior: aws:PrincipalArn está presente em toda requisição, então a condição faz uma comparação honesta e a exceção se comporta como escrita. Se algum dia você montar uma exceção sobre uma chave que pode estar ausente, lembre que um operador negado devolve true para chave ausente, e o deny dispararia em requisições que você nunca quis cobrir.

organizations:LeaveOrganization é a statement que as pessoas esquecem. Uma conta que consegue sair da organização sai de baixo de todo guardrail que você escreveu.

Anexe isso no root como deny list, ao lado do FullAWSAccess, e vale para toda conta membro. Não para a conta de gerenciamento.

O que SCPs não conseguem restringir

Mesmo dentro de contas membro, uma lista curta fica fora do controle dos SCPs:

• Qualquer coisa que a conta de gerenciamento faça.
• Qualquer coisa feita com as permissões de uma service-linked role. Service-linked roles são como serviços AWS agem em seu nome, e SCPs não conseguem estreitá-las.
• Registrar o plano Enterprise Support como usuário root.
• Funcionalidade de trusted signer para conteúdo privado do CloudFront.
• Configurar DNS reverso para um servidor de email do Lightsail ou uma instância EC2 como usuário root.
• Um punhado de serviços relacionados à AWS fora da superfície normal de API, incluindo o Amazon Mechanical Turk.

Os 2 primeiros importam para a prova. O resto é trivia que você reconhece sem decorar.

RCPs: a mesma ideia, mirando recursos

Um SCP limita o que os seus principals podem fazer. Isso deixa um buraco: uma bucket policy em uma das suas contas pode conceder acesso a uma conta de fora, e nenhum SCP toca nessa requisição, porque quem chama não é gerenciado pela sua organização.

Uma resource control policy fecha esse buraco. RCPs limitam o máximo de permissões disponíveis para recursos em contas membro, seja lá quem for o chamador. Mesmo formato de JSON, mesma regra de nunca conceder, mesmo comportamento de interseção, mesma exceção da conta de gerenciamento, mesma imunidade para service-linked roles.

A divisão por palavra-chave é confiável. Um cenário sobre restringir as suas pessoas é SCP. Um cenário sobre restringir quem alcança os seus dados, especialmente quando aparece um principal externo, é RCP.

Teste antes de anexar

A AWS diz isso em negrito na documentação, e vale virar hábito: não anexe um SCP novo direto no root. Crie uma OU de teste, mova contas para dentro dela aos poucos, e observe.

Duas ferramentas te dizem o que a política quebraria antes de ela quebrar:

• Dados de último acesso, visíveis por entidade da organização ou por política no console do IAM quando você está logado com credenciais da conta de gerenciamento. Eles mostram quais serviços os principals de uma conta de fato tentaram usar, que é como você troca um palpite sobre a allow list por evidência.
• CloudTrail, para uso em nível de API e, depois do fato, para os erros de AccessDenied que a política nova produzir.

O modo de falha que você está evitando não é sutil: um erro de SCP não degrada uma carga de trabalho, ele remove um serviço de todas as contas abaixo do ponto de anexação de uma vez só.

Dicas para a prova

• "Um SCP não concede permissões" é a frase mais cobrada sobre este serviço. Um principal sem política de identidade não tem acesso, diga o SCP o que disser.
• Um SCP sem nenhum Allow aplicável nega. Ele não é só uma lista de denies.
• Allow precisa de todo nível a partir do root. Deny precisa de um nível em qualquer ponto. Se um cenário te leva por uma hierarquia, percorra o caminho duas vezes, uma para cada regra.
• Um cenário em que "o administrador da conta tem AdministratorAccess mas a chamada falha mesmo assim" com Organizations mencionado é questão de SCP.
• SCPs nunca afetam a conta de gerenciamento nem service-linked roles. Afetam sim o usuário root da conta membro e as contas de administrador delegado.
• Remover o FullAWSAccess sem substituto é como organizações quebram. Se a questão descreve falha total em uma OU logo depois de uma mudança de política, procure o allow que falta.
• Allow list significa serviços AWS novos bloqueados até você editar o SCP. Deny list significa permitidos no dia do lançamento.
• Principal externo no cenário, ou "só identidades da minha organização podem acessar estes dados", aponta para RCP, não para SCP.
• SCPs e RCPs exigem all features habilitado. Consolidated billing sozinho significa que nenhum dos dois está disponível.

A regra de decisão para levar: pergunte se o controle precisa sobreviver a um administrador local. Se sim, ele fica acima da conta, em um SCP ou RCP, e você aceita a granularidade grossa que vem junto. Se não, uma política do IAM ou um permissions boundary dentro da conta é mais barato e mais fácil de mudar. Guardrails respondem o que é possível dentro de uma conta. A próxima lição responde a outra metade, que é como uma pessoa consegue uma sessão logada em 40 contas sem 40 conjuntos de credenciais.