Lab 43 — Multi-conta: OU, SCP e Control Tower

# Nao apaga nada. So pergunta: "esta role poderia apagar cadencia-prod?"
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/OperacaoCadencia \
  --action-names rds:DeleteDBInstance \
  --resource-arns arn:aws:rds:us-east-1:111122223333:db:cadencia-prod \
  --query "EvaluationResults[0].EvalDecision" --output text

# Na conta unica de hoje: "allowed". A policy que foi escrita para cobrir
# "qualquer banco de dev" cobre tambem "qualquer banco que comece com cadencia-".

{
  "eventSource": "rds.amazonaws.com",
  "eventName": "DeleteDBInstance",
  "awsRegion": "us-east-1",
  "errorCode": "AccessDenied",
  "errorMessage": "User: arn:aws:sts::333333333333:assumed-role/Operador/sessao is not authorized to perform: rds:DeleteDBInstance with an explicit deny in a service control policy",
  "requestParameters": {
    "dBInstanceIdentifier": "cadencia-prod"
  },
  "recipientAccountId": "333333333333"
}

# organizacao.tf — a arvore que uma SCP precisa para existir

resource "aws_organizations_organization" "cadencia" {
  # SCP so existe no modo "ALL" (todos os recursos habilitados). No modo de
  # faturamento consolidado (CONSOLIDATED_BILLING, o padrao de quem so queria
  # juntar a fatura de duas contas) a API de policy nem aceita anexar SCP —
  # e a mudanca de modo, uma vez feita, nao tem caminho de volta.
  feature_set = "ALL"

  enabled_policy_types = [
    "SERVICE_CONTROL_POLICY",
  ]

  # Habilita a integracao de servico com Control Tower, Identity Center e
  # CloudTrail organizacional. Sem isto, cada um desses servicos so enxerga
  # a propria conta, nao a arvore inteira.
  aws_service_access_principals = [
    "controltower.amazonaws.com",
    "sso.amazonaws.com",
    "cloudtrail.amazonaws.com",
  ]
}

resource "aws_organizations_organizational_unit" "nao_producao" {
  name      = "Não-Produção"
  parent_id = aws_organizations_organization.cadencia.roots[0].id
}

resource "aws_organizations_organizational_unit" "producao" {
  name      = "Produção"
  parent_id = aws_organizations_organization.cadencia.roots[0].id
}

# NAO crie a conta-membro com `aws_organizations_account` direto quando o
# Control Tower administra a landing zone: a conta nasceria fora do radar do
# Account Factory, sem os guardrails detectivos nem os baselines que o
# Control Tower normalmente aplica no provisionamento. O caminho certo e o
# Account Factory (console ou o produto do Service Catalog que ele publica) —
# ou, em escala maior, o Account Factory for Terraform (AFT), fora do escopo
# deste laboratorio de duas contas.

output "ou_producao_id" {
  value       = aws_organizations_organizational_unit.producao.id
  description = "id da OU onde a SCP deste modulo e anexada"
}

# scp-producao.tf — o teto. Ele nao concede nada; so recorta o que o IAM concede.

data "aws_iam_policy_document" "nega_destrutivo_prod" {
  # A policy padrao FullAWSAccess continua anexada: uma SCP e uma politica
  # ADICIONAL de Deny, ela nao substitui a permissiva que a AWS anexa por
  # padrao a toda OU nova.
  statement {
    sid    = "NegaExclusaoDeBancoEmProducao"
    effect = "Deny"
    actions = [
      "rds:DeleteDBInstance",
      "rds:DeleteDBCluster",
      "rds:DeleteDBSnapshot",
      "rds:DeleteDBClusterSnapshot",
    ]
    # Resource "*" aqui e decisao, nao preguica: o objetivo e negar a ACAO em
    # qualquer banco desta OU, sem depender de alguem lembrar de incluir o
    # ARN de cada instancia nova na lista. Restringir por Resource exigiria
    # atualizar a SCP a cada banco criado — o oposto de um teto confiavel.
    resources = ["*"]

    # A saida de emergencia: uma role de nome fixo, so para o incidente raro
    # que exige apagar mesmo. Sem isto, o proprio time de plataforma fica
    # preso pela propria trava — e a resposta previsivel sob pressao e
    # desanexar a SCP inteira, o que remove a protecao de tudo que ela cobria.
    condition {
      test     = "StringNotLike"
      variable = "aws:PrincipalArn"
      values   = ["arn:aws:iam::*:role/QuebraVidroProducao"]
    }
  }

  statement {
    sid    = "NegaSairDaOrganizacao"
    effect = "Deny"
    actions   = ["organizations:LeaveOrganization"]
    resources = ["*"]
    # Sem isto, uma conta-membro pode se autorremover da organizacao — e
    # levar consigo a unica fronteira que este laboratorio constroi.
  }
}

resource "aws_organizations_policy" "nega_destrutivo_prod" {
  name        = "nega-acoes-destrutivas-producao"
  description = "Teto para a OU Producao: nega exclusao de banco e saida da organizacao, mesmo com IAM AdministratorAccess"
  type        = "SERVICE_CONTROL_POLICY"
  content     = data.aws_iam_policy_document.nega_destrutivo_prod.json
}

resource "aws_organizations_policy_attachment" "producao" {
  policy_id = aws_organizations_policy.nega_destrutivo_prod.id
  target_id = aws_organizations_organizational_unit.producao.id
  # Anexada na OU, nao na conta: toda conta que entrar aqui no futuro herda
  # a trava sem exigir um passo manual extra que alguem pode esquecer.
}

# identity-center.tf — o que o IAM concede, e por que ele pode continuar igual

data "aws_ssoadmin_instances" "this" {}

resource "aws_ssoadmin_permission_set" "operador" {
  name             = "Operador"
  instance_arn     = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  session_duration = "PT4H"
  # O MESMO permission set e atribuido nas duas contas. E o ponto do
  # laboratorio: a diferenca de comportamento entre elas vem da SCP anexada
  # na OU, nao de uma policy IAM diferente por ambiente.
}

resource "aws_ssoadmin_managed_policy_attachment" "operador_rds" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/AmazonRDSFullAccess"
  permission_set_arn = aws_ssoadmin_permission_set.operador.arn
  # Sim, FullAccess — de proposito. O laboratorio prova que a SCP contem o
  # dano mesmo quando o IAM e generoso, que e o cenario realista: ninguem
  # reaudita todo permission set toda semana.
}

resource "aws_ssoadmin_account_assignment" "operador_nao_producao" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.operador.arn
  principal_id       = var.grupo_engenharia_id
  principal_type     = "GROUP"
  target_id          = var.conta_nao_producao_id
  target_type        = "AWS_ACCOUNT"
}

resource "aws_ssoadmin_account_assignment" "operador_producao" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.operador.arn
  principal_id       = var.grupo_engenharia_id
  principal_type     = "GROUP"
  target_id          = var.conta_producao_id
  target_type        = "AWS_ACCOUNT"
}

// VerificadorFronteira/Program.cs — prova a fronteira sem tocar em dado real
//
// Chama iam:SimulatePrincipalPolicy nas duas contas, para a MESMA acao, e
// imprime lado a lado. Segundo a documentacao da AWS, o simulador avalia SCP
// com logica "consciente do servico" — por isso o resultado diverge entre as
// contas sem nenhuma chamada destrutiva de verdade ter sido executada.

using Amazon.IdentityManagement;
using Amazon.IdentityManagement.Model;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

var acoes = new List<string> { "rds:DeleteDBInstance", "rds:DeleteDBCluster" };

var contas = new[]
{
    new { Nome = "Não-Produção", RoleArn = Ambiente("ROLE_NAO_PRODUCAO") },
    new { Nome = "Produção",     RoleArn = Ambiente("ROLE_PRODUCAO") },
};

foreach (var conta in contas)
{
    // Assume a role NA CONTA ALVO — o simulador roda com as credenciais
    // dessa conta, entao ele enxerga a SCP que se aplica especificamente a
    // ela, e nao a de outra conta da organizacao.
    using var sts = new AmazonSecurityTokenServiceClient();
    var assumida = await sts.AssumeRoleAsync(new AssumeRoleRequest
    {
        RoleArn         = conta.RoleArn,
        RoleSessionName = "verificador-fronteira",
    });

    using var iam = new AmazonIdentityManagementServiceClient(
        assumida.Credentials.AccessKeyId,
        assumida.Credentials.SecretAccessKey,
        assumida.Credentials.SessionToken);

    var resposta = await iam.SimulatePrincipalPolicyAsync(new SimulatePrincipalPolicyRequest
    {
        PolicySourceArn = conta.RoleArn,
        ActionNames     = acoes,
        // Recurso curinga: o alvo da prova e o TETO da conta, nao um banco
        // especifico. Para provar contra um recurso real, troque por um ARN.
        ResourceArns    = new List<string> { "*" },
    });

    Console.WriteLine($"— {conta.Nome} —");
    foreach (var resultado in resposta.EvaluationResults)
    {
        // EvalDecision vem como "allowed", "explicitDeny" ou "implicitDeny".
        // Na conta de Producao, espera-se explicitDeny — a SCP se
        // manifestando, mesmo que a role tenha AmazonRDSFullAccess.
        Console.WriteLine($"  {resultado.EvalActionName}: {resultado.EvalDecision}");
    }
}

static string Ambiente(string nome) =>
    Environment.GetEnvironmentVariable(nome)
    ?? throw new InvalidOperationException($"defina a variável {nome} com o ARN da role a testar");

# Provas 2 e 3: crie DUAS instancias RDS descartaveis, uma por conta, so para o
# teste -- t3.micro, sem Multi-AZ, sem snapshot final. NAO aponte para um banco
# que tenha dado de verdade.

# ── Prova 2: sucede em Nao-Producao ──────────────────────────────────────────
aws rds delete-db-instance --db-instance-identifier teste-fronteira \
  --skip-final-snapshot --profile nao-producao
# Esperado: "DBInstanceStatus": "deleting"

# ── Prova 3: falha em Producao, com o MESMO comando ──────────────────────────
aws rds delete-db-instance --db-instance-identifier teste-fronteira \
  --skip-final-snapshot --profile producao
# Esperado: erro AccessDenied mencionando "service control policy"

# ── Prova 4: a tentativa negada e auditavel na conta que nao operou a chamada ─
aws cloudtrail lookup-events --profile log-archive \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteDBInstance \
  --query "Events[?contains(CloudTrailEvent, 'AccessDenied')]"

# ── Prova 5: a conta de gestao esta fora do alcance, de proposito ────────────
aws iam simulate-principal-policy --profile gestao \
  --policy-source-arn arn:aws:iam::111100002222:role/AdministradorGestao \
  --action-names rds:DeleteDBInstance \
  --resource-arns "*" --query "EvaluationResults[0].EvalDecision" --output text

# 1. Remova as atribuicoes do Identity Center ANTES de mexer em conta ou OU --
#    senao ficam referencias soltas para um alvo que deixou de existir.
aws sso-admin delete-account-assignment \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn "$PERMISSION_SET_ARN" \
  --principal-id "$GRUPO_ID" --principal-type GROUP \
  --target-id "$CONTA_PRODUCAO_ID" --target-type AWS_ACCOUNT

# 2. Apague as instancias RDS descartaveis das provas 2 e 3, se ainda existirem.
aws rds describe-db-instances --profile nao-producao \
  --query "DBInstances[?DBInstanceIdentifier=='teste-fronteira']" --output table

# 3. Desanexe e apague a SCP.
terraform destroy -target=aws_organizations_policy_attachment.producao
terraform destroy -target=aws_organizations_policy.nega_destrutivo_prod

# 4. As OUs so sao removidas se estiverem VAZIAS -- sem conta e sem OU filha.
#    Mova ou fece as contas primeiro.
terraform destroy -target=aws_organizations_organizational_unit.nao_producao
terraform destroy -target=aws_organizations_organizational_unit.producao

# 5. O fechamento de conta-membro tem processo e prazo proprios da AWS -- nao e
#    instantaneo, e a reversao e limitada. So feche uma conta que voce tem certeza
#    de que nao vai precisar mais.
aws organizations close-account --account-id "$CONTA_NAO_PRODUCAO_ID"

# 6. Prova final: nenhuma SCP customizada sobrando em nenhuma OU.
aws organizations list-policies --filter SERVICE_CONTROL_POLICY \
  --query "Policies[?AwsManaged=='false'].Name" --output table