Multicloud para bancos: como separar core, dados e trilha de auditoria

Introdução

A consulta "multicloud para bancos" não pede uma lista de produtos. Pede um desenho em que o core não conversa com a conta de experimento, o dado fica na região combinada com o regulador e a trilha de auditoria sobrevive a quem tem a chave de administrador.

Eu vi esse problema em outra escala, no data center: core, satélite e agente. O core decide. O satélite executa perto da carga. O agente só devolve status. Em banco, a nuvem repete o mesmo erro de quem junta tudo numa conta só: produção, homologação e o laboratório de dados no mesmo papel IAM.

Este artigo é o desenho que eu uso quando o ambiente é regulado. Não é um projeto de um banco específico. É a separação mínima para a conta não virar um diretório compartilhado.

O custo dessa separação entra depois, no artigo de FinOps multi-cloud. Aqui o assunto é fronteira.

Três planos, três contas

Core. Mora o ledger, a autenticação e a fila de pagamento. Não mora notebook de ciência de dados nem prova de conceito.

Dados. Mora a réplica analítica e o data lake da região aprovada. Não mora cópia "rápida" em outra região para testar um painel.

Auditoria. Mora CloudTrail, logs de acesso e evidência de mudança. Não mora a mesma conta que cria e apaga recurso.

A conta de auditoria não desenvolve. Ela só recebe log. Quem opera o core não tem s3:DeleteObject nesse bucket. Quem faz a prova de conceito não tem rota até o core.

Se o core ainda está em UNIX, ele continua onde está. HP-UX, Solaris e AIX não "migram para multicloud" porque a diretoria pediu três logos. O que sai para a nuvem é o que tem dono, região e restore testado. O restante fica no artigo de administração UNIX.

Travar a região na raiz da organização

O controle que impede um analista de subir um bucket em outra região é uma SCP, não um acordo de equipe. O exemplo abaixo nega tudo fora de sa-east-1, com exceção dos serviços globais. Sem o NotAction, a política também trava IAM e a organização inteira.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegion",
      "Effect": "Deny",
      "NotAction": [
        "iam:",
        "organizations:",
        "route53:",
        "cloudfront:",
        "support:",
        "sts:"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["sa-east-1"]
        }
      }
    }
  ]
}

aws organizations create-policy \ --name DenyOutsideSaEast1 \ --type SERVICE_CONTROL_POLICY \ --content file://deny-region.json

aws organizations attach-policy \ --policy-id p-abc123 \ --target-id ou-bancos-workloads

ou-bancos-workloads é a OU das contas de aplicação, não a conta de gerenciamento. A conta de gerenciamento fica de fora dessa SCP. Senão você se tranca.

No Azure o equivalente é uma policy de allowedLocations na management group, não uma convenção no nome do resource group.

A trilha que o administrador não apaga

Log na mesma conta que produz o log não é auditoria. O bucket nasce com Object Lock e a trilha escreve de outra conta.

aws s3api create-bucket \ --bucket bank-audit-logs \ --region sa-east-1 \ --create-bucket-configuration LocationConstraint=sa-east-1 \ --object-lock-enabled-for-bucket aws s3api put-object-lock-configuration \ --bucket bank-audit-logs \ --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 365 } } }' aws cloudtrail create-trail \ --name bank-audit \ --s3-bucket-name bank-audit-logs \ --is-multi-region-trail

aws cloudtrail start-logging --name bank-audit

COMPLIANCE impede até o root de apagar o objeto antes do prazo. É isso que diferencia trilha de pasta compartilhada. A evidência de mudança do dia a dia, no formato que a ISO pede, está no artigo de governança.

Rede: o core não enxerga o laboratório

Peering entre a VPC de produção e a VPC de experimento é o atalho que desfaz a separação acima. O caminho que eu aceito é outro:

O core publica só o que o plano de dados precisa, por endpoint privado, não por IP público.
A conta de laboratório não tem rota para a subnet do core.
O salto de administração passa por um bastion na conta de auditoria, com sessão registrada.

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values="$VPC_CORE" \
  --query "RouteTables[].Routes[?DestinationCidrBlock=='10.80.0.0/16']"

Se esse comando devolver rota para a faixa do laboratório, a separação é só no organograma. Tira a rota antes de discutir ferramenta de FinOps.

O que fica de fora de propósito

Multicloud para banco não começa por Kubernetes em três provedores. Começa por região, conta e log imutável. Três clusters federados, sem essas três coisas, multiplicam o lugar onde o dado vaza e a fatura cresce sem dono.

Quando a fronteira existe, aí sim vale otimizar o que sobra: IP órfão, storage quente e Savings Plan. Isso já está escrito, com comando, no artigo de FinOps.