Multi-party approval da AWS para Organizations

Multi-party approval é um recurso do AWS Organizations que bloqueia um conjunto predefinido de operações de alto risco até que um quórum de humanos nomeados as aprove por um canal separado. Um único conjunto de credenciais, mesmo válido, deixa de conseguir puxar o gatilho sozinho. O solicitante inicia a ação, uma approval team separada a revisa em um portal dedicado, e a operação só executa quando o approval threshold do time é atingido.

Este é o princípio dos "quatro olhos" aplicado na camada da API, e não em um runbook ou em uma mensagem de Slack. Ele fecha a distância entre "temos uma política que diz que duas pessoas precisam assinar" e "a plataforma se recusa fisicamente a prosseguir sem duas assinaturas."

O que isso é de fato

O Multi-party approval (MPA) fica dentro do AWS Organizations e depende do IAM Identity Center para as identidades humanas. Você define uma approval team, um conjunto de aprovadores extraídos da sua fonte de identidade, e anexa um approval threshold: o número mínimo dessas pessoas que precisam dizer sim antes que uma protected operation possa executar.

Em seguida você marca operações específicas como protected. A partir daí, quem invocar uma protected operation não recebe um resultado imediato. Recebe uma solicitação pendente. O MPA envia e-mail a cada aprovador do time, cada aprovador abre o approval portal, revisa a solicitação e aprova ou nega. Uma vez atingido o threshold, a operação do chamador original tem permissão para prosseguir. A aprovação é o portão, não um aviso depois do fato.

O vocabulário

Approval team: um grupo nomeado de aprovadores, sustentado por usuários do IAM Identity Center.
Approval threshold: quantos aprovadores precisam aprovar. Um time de três com threshold de dois significa que quaisquer dois deles desbloqueiam a ação.
Protected operation: a ação específica que você colocou atrás do portão.
Approval portal: a superfície separada onde os aprovadores revisam e respondem. É deliberadamente apartada da sessão de console que fez a solicitação.

Como o fluxo funciona

O processo tem três passos, e a separação entre eles é o ponto central.

Solicitação. Um usuário (ou um chamador automatizado) invoca uma protected operation. Em vez de executar, a AWS cria uma sessão de aprovação e notifica o time.
Sessão de aprovação. Os aprovadores recebem um e-mail com um link, abrem o portal e veem exatamente o que está sendo solicitado, por quem e contra qual recurso. Aprovam ou negam de forma independente.
Execução. Quando as aprovações atingem o threshold, a operação executa. Se a sessão expirar ou o threshold nunca for atingido, a operação nunca acontece.

O solicitante não pode aprovar a própria solicitação de dentro da própria sessão. A aprovação acontece em uma superfície diferente, atrelada a identidades diferentes. É isso que torna um token de sessão roubado ou um role de CI comprometido insuficiente por si só.

Por que importa para a segurança

O valor não está no e-mail nem no portal. Está em que o controle vive abaixo da aplicação, na plataforma, onde um único principal comprometido não consegue contorná-lo.

Elimina o ponto único de comprometimento

A maioria dos incidentes catastróficos na nuvem se resume a uma identidade com alcance excessivo: uma chave de longa duração vazada, um admin vítima de phishing, um role de automação com escopo amplo demais. Para o punhado de operações capazes de arruinar a sua semana, o MPA transforma "uma credencial comprometida" em "você também precisa subverter N humanos independentes ao mesmo tempo." Essa é uma classe de ataque diferente.

Aplica a separação de funções na API

A separação de funções costuma morar em um documento de compliance e morrer na prática, porque nada impede um engenheiro apressado de fazer as duas metades de uma alteração sensível. O MPA move a regra para o control plane. A plataforma, e não a boa vontade, exige a segunda assinatura.

É um freio contra ransomware e insiders destrutivos

O playbook destrutivo clássico é apagar os backups primeiro, depois os dados. Se as operações que apagam ou alteram seus pontos de recuperação protegidos ficam atrás de um quórum, um atacante que controla uma identidade não consegue destruir silenciosamente a sua última linha de recuperação. O mesmo freio se aplica a um insider insatisfeito com acesso legítimo.

Produz uma trilha de auditoria que você consegue defender

Toda protected operation passa a carregar um registro de quem a solicitou, quem a aprovou e quando. Para SOC 2, ISO 27001, PCI DSS ou uma revisão pós-incidente interna, "me mostre as aprovações dessa ação" vira uma consulta em vez de um trabalho de arqueologia.

Onde se encaixa, e onde não

Use Multi-party approval quando	Dispense quando
A operação é rara, de alto raio de impacto e irreversível	A operação é frequente e precisa de execução imediata
Você roda AWS Organizations com IAM Identity Center	Você roda contas isoladas sem Organizations ou Identity Center
Você precisa de aprovação distribuída para compliance ou Zero Trust	O risco não justifica o overhead de gerenciar times e fluxos
Você quer proteger a exclusão ou alteração de backups de último recurso	Você precisa de automação que roda sem supervisão, sem humano no laço

O MPA é um bisturi, não uma manta. Coloque-o nas operações em que um passo errado é irrecuperável: destruir cofres de backup logicamente isolados, desmontar guardrails no nível da organização, apagar pontos de recuperação. Não o coloque em operações que seu time roda quarenta vezes por dia, ou você treinará todo mundo a carimbar aprovações no automático, o que é pior do que não ter controle algum.

Modos de falha a planejar

Disponibilidade dos aprovadores. Se o seu threshold é dois e só há duas pessoas no time, uma única viagem de férias pode travar uma emergência legítima. Dimensione o time maior que o threshold e mantenha a lista atualizada.
Tensão com break-glass. Um incidente real pode precisar da protected operation rápido. Decida com antecedência como alcançar os aprovadores fora do horário, e ensaie isso, antes da noite em que importa.
Fadiga de aprovação. Proteja coisas demais e os aprovadores param de ler. O controle degrada para um clique reflexo. Mantenha a lista de protegidos curta e genuinamente de alto risco.
Dependência da fonte de identidade. O MPA se apoia no IAM Identity Center. Se ele estiver mal configurado ou indisponível, o seu caminho de aprovação também estará. Ele pertence ao seu planejamento de resiliência, não fora dele.

O recado

O Multi-party approval é um dos poucos controles da AWS que muda a matemática para o atacante em vez de apenas levantar um alerta. Para o pequeno conjunto de operações em que um único erro ou uma única credencial roubada é catastrófico, um portão de quórum é a diferença entre um incidente e um desastre. Aplique-o de forma estreita, monte as approval teams adequadamente e ensaie o caminho de break-glass.

Leia isto a seguir

AWS S3 New Feature: Re-encryption without Movement, sobre como a AWS está empurrando mais controles de segurança para a camada da plataforma.
When the Cloud Sneezes, the World Catches a Cold, sobre raio de impacto e por que proteger as operações irreversíveis vale o atrito.

Construindo sistemas agênticos que carregam credenciais da AWS? O mesmo raciocínio de quórum se aplica a ações autônomas, veja as field notes em ercan.ai. Para consultoria em AWS, segurança em nuvem e governança de plataforma, comece em ercanermis.com.