# Orientação para sessão paralela: infra de PRODUÇÃO (Fase 3 + Fase 0.2/0.3) Data: 2026-07-07. Este documento orienta uma sessão do Claude Code dedicada a criar o ambiente de produção do Monetarie ENQUANTO a sessão principal executa a Fase 1 (higiene de código) no mesmo repositório. As duas frentes são independentes por design: a higiene valida em HML e as imagens são promovidas por digest depois; a infra é um estado Terraform novo que não toca em nada de HML. ## Comando para colar na sessão paralela ``` Você é a sessão de INFRA DE PRODUÇÃO do Monetarie, paralela à sessão de higiene de código (Fase 1). Leia, nesta ordem: 1. docs/handoff/2026-07-07-fase3-infra-prod-orientacao-sessao-paralela.md (este documento) 2. docs/handoff/2026-07-07-subida-producao-handoff.md (contexto geral) 3. docs/plans/2026-07-07-subida-producao-monetarie-design.md (design, seções 3 e 9) 4. docs/plans/2026-07-07-subida-producao-monetarie-plano.md (FASE 0 e FASE 3, com gates) 5. CLAUDE.md da raiz (regras absolutas, wrapper awsmon, topologia HML de referência) Escopo: FASE 3 completa (Tasks 3.1 a 3.5) + FASE 0.2 (acessos de rede 10.50) + FASE 0.3 (truststore ICP-Brasil) + abertura/cobrança do chamado RTM da FASE 0.1 (PKCS#11). FORA do escopo: qualquer deploy de serviço em produção (Fase 6), bootstrap de dados (Fase 4), qualquer edição de código de produto, qualquer recurso de homologação. Trabalhe num git worktree separado (instruções na seção 2 deste documento). ``` ## 1. Divisão de trabalho entre as duas sessões | Frente | Sessão | Observação | |---|---|---| | Fase 1 (higiene, ondas 1.2 a 1.11) | principal | edita core/apps, core/backend, pix, spb | | Fase 2 (trilhas de auditoria) | principal | depois da Fase 1 | | Fase 0.1 (spike PKCS#11 HSM prod) | paralela ABRE E COBRA o chamado RTM | é espera externa; a prova técnica pode ser feita por qualquer sessão quando a RTM responder | | Fase 0.2 (acessos de rede 10.50) | paralela | depende de um host na VPC 10.50 (subir o OpenVPN prod cedo ajuda) | | Fase 0.3 (truststore ICP-Brasil) | paralela | certs locais neste Mac; arquivos de repo disjuntos da Fase 1 | | Fase 3 (Terraform env=prod) | paralela | escopo principal desta orientação | | Fases 4, 5 e 6 (bootstrap, certs no HSM, deploy+eco) | decididas quando a Fase 1 fechar | o deploy final é gate da sessão principal; NÃO deployar serviço em prod nesta sessão | ## 2. Coordenação git (obrigatório, evita colisão entre as sessões) 1. Trabalhe num worktree separado, nunca na working tree principal: `git worktree add /Users/luizpenha/monetarie-infra-prod main` e opere só lá. 2. Só commite arquivos de `infra/aws/greenfield/**` e `docs/**`. Nenhum arquivo de `core/`, `pix/`, `spb/` (código de produto é território da sessão principal). 3. Antes de cada push: `git pull --rebase origin main` (a sessão principal também commita em main, um commit por onda). 4. Prefixo de commit: `infra(prod): ...` ou `docs(infra-prod): ...`. 5. Nunca commitar tfvars com segredo, chave privada, senha ou UID de HSM (regra #10). Segredos só em Secrets Manager `monetarie/prod/*`. ## 3. Regras absolutas (herdam do CLAUDE.md, reforçadas para produção) - AWS somente conta `990933657879`, região `sa-east-1`, profile `vulcimonetarie` (o profile default resolve para OUTRA conta). Use o wrapper `awsmon`. - ADOTAR a VPC de produção existente `vpc-0da523dbdbac50b5d` (`monbank-rtm-prod`, 10.50.0.0/16, subnets `monbank-rtm-prod-1a/1b/1c` = 10.50.1/2/3.0/24) via data sources, padrão idêntico ao da 10.45 de HML. NÃO criar VPC. NÃO tocar em recursos da Lerian (bastion, rotas, TGW, SGs alheios) nem em QUALQUER recurso de homologação. - Estado Terraform NOVO e isolado (backend/workspace próprio, `env=prod`). O plan da Task 3.1 deve mostrar adoção da VPC e ZERO mudança em recursos existentes. - TigerBeetle EXATAMENTE `ghcr.io/tigerbeetle/tigerbeetle:0.17.3` (regra #8), cluster de 3 nós EC2, 1 por AZ, EBS dedicado por nó, `--addresses` dos peers; `TB_POOL_SIZE=3` ficará nas task-defs (Fase 6, fora desta sessão). - NATS JetStream 3 nós (HML roda 1; produção é 3, streams com replica=3). - Aurora PostgreSQL `17.9` (NÃO a 16 de HML), bancos `mon_*`, Serverless v2. - Redis/ElastiCache espelhando HML. Uma CMK KMS por domínio (core, pix, spb, npc, sta, clst). - ECR: mesmos repositórios; imagens de produção serão promovidas POR DIGEST das validadas em HML (nunca rebuild às cegas). Nesta sessão não se promove imagem nenhuma. - Zona privada `monetarie.internal` de PRODUÇÃO com hosts `-p` (ou equivalente). NÃO reusar os hosts `-h` de HML. Não usar `.local`. Não recriar `spi`; nomes RSFN corretos: `dict`, `dict-np`, `icom`, `icom-sec`, `arq` (variante prod). - MQ de produção: `172.31.1.50` (o de HML era `172.31.2.50`). Canal e porta a confirmar na Fase 0.2 (em HML a porta real do SPB01 era 1514, não 1414). - HSM de produção: endpoint RTM de produção (NÃO o `-hml`, NUNCA `:6443`), configurado por env. UIDs e credenciais só em `monetarie/prod/*`. - Flags de negócio nascem no estado seguro: ENVIO BACEN desabilitado até o eco assinado da Fase 6.2 (que não é desta sessão). ## 4. Tarefas e gates (detalhe canônico no plano, FASE 0 e FASE 3) ### 4.1 Task 3.1: estado Terraform prod isolado + data sources da VPC 10.50 Novo backend/workspace `prod` sobre `infra/aws/greenfield/`, `terraform.tfvars` de prod (env, CIDR/subnets 10.50, endpoints RTM/HSM/MQ/RSFN de produção, sem segredos). GATE: `terraform init` + `terraform plan` coerente, adotando a VPC, sem tocar HML. O plan é revisado ANTES de qualquer apply. Guarde o plan como evidência. ### 4.2 Task 3.2: Aurora PG 17.9, Redis, KMS, ECR GATE: apply do bloco de dados; endpoints resolvem; sem recurso órfão. ### 4.3 Task 3.3: NATS 3 nós GATE: 3 nós Online, streams criadas com replica=3. ### 4.4 Task 3.4: TigerBeetle cluster 3 nós (0.17.3, 1 por AZ) Generalizar o módulo atual de 1 nó para 3 réplicas. GATE: quorum formado, conta de teste criada e lida. Atenção ao gotcha de HML: `terraform apply` já tentou arrastar replace do TigerBeetle; em produção o cluster TB nasce novo, mas confira que o plan não toca o TB de HML. ### 4.5 Task 3.5: ALB interno, Route 53 privada, VPC endpoints, OpenVPN, RSFN resolver Espelhar HML com valores prod (zona de produção, hosts `-p`). Subir o OpenVPN prod CEDO desbloqueia a Fase 0.2. GATE: plan limpo; hosts internos resolvem. ### 4.6 Fase 0.2: matriz de acessos da origem 10.50 De um host na 10.50 (EC2 OpenVPN prod ou task de teste): HSM prod 443, MQ `172.31.1.50` (CONNECT + auth de canal), RSFN direto (DICT/ICOM/ARQ), DNS RSFN via resolver. GATE: matriz preenchida (CONNECT + auth por serviço). Bloqueio vira chamado RTM com evidência (padrão do dossiê #331997). Lembrete: o whitelist #331997 já cita 10.50.0.0/16, mas em HML a liberação foi parcial e por porta; provar porta a porta. ### 4.7 Fase 0.3: truststore ICP-Brasil de produção Montar a cadeia completa (Raiz Brasileira v5/v10/v11/v12, AC SERPRO SSLv1, AC SERPRO Final SSL, CSPB-1/CSPB-6, AC VALID SPB v5) e validar com `openssl verify -CAfile` os 8 certs: 4 nossos em `~/Desktop/Certificados Prod/` (PIA P003, PIC P002, 2x SPB P001) e 4 peers BACEN em `~/Downloads/` (PIA-P515, PIC-P514, SPB-P060, MES-P061). Commit SÓ da cadeia pública (PEM de CAs) nos paths do plano (Task 0.3). Chave privada não existe em disco (fica no HSM) e nada sensível entra no repo. ATENÇÃO validade: SPB-P060 e MES-P061 vencem em 2026-09-01. ### 4.8 Fase 0.1: chamado RTM do PKCS#11 (abrir e cobrar) Abrir formalmente com a RTM: endpoint do HSM de produção, exposição PKCS#11/KMIP para assinatura (PIA) e mTLS (PIC), procedimento de locate-all dos UIDs. É o caminho crítico do go-live PIX. Registrar número do chamado e respostas neste repositório em `docs/reports/` (sem segredos). ## 5. O que esta sessão NÃO faz (fica para o fechamento conjunto) - Nenhum `ecs update-service`, task-def ou deploy de serviço em produção. - Nenhuma migration, seed ou criação de admin (Fase 4). - Nenhuma importação de cert no HSM nem teste de assinatura (Fase 5, depende da 0.1). - Nenhuma promoção de imagem ECR. - Nenhum ENVIO BACEN. ## 6. Critério de pronto e sinalização de volta Ao concluir (ou ao bloquear em dependência RTM), escrever `docs/reports/2026-07-07-fase3-infra-prod-status.md` com: recursos criados (IDs), gates provados (plan/apply/health), matriz de acessos da 0.2, resultado do openssl da 0.3, número e estado do chamado RTM da 0.1, e pendências. Commitar e pushar. A sessão principal lê esse relatório antes de iniciar as Fases 4/5/6.