Dossiê — E2 (ambiente dedicado alugado e isolado)
Fonte: auditoria "Manus AI" (2026-09-01), seção 3, entregável E2. Veredito da auditoria: Não comprovado — a infraestrutura dedicada e isolada existe, mas a auditoria não recebeu evidência documental (termo do provedor, residência de dados, política de destruição).
Este dossiê separa o que já é comprovável pelo repo/infra (fatos preenchidos) do que falta evidência documental (template a preencher).
1. O que a auditoria exige (E2)
Dedicação, residência de dados, isolamento do provedor, acessos privilegiados, snapshots e destruição.
2. Fatos comprováveis pelo repo/infra (já preenchidos)
2.1 Topologia do ambiente dedicado
O ambiente de produção do small-pine ("Chatsubo") é uma VM FreeBSD dedicada com jails VNET, alcançada publicamente por um gateway WireGuard Vultr e com o cluster de inferência (Enverge) em um provedor separado.
| Componente | Endereço / host | Papel |
|---|---|---|
| Chatsubo (prod-machine) | chatsubo.ianfernandez.tec.br | VM FreeBSD dedicada, host dos jails |
| SSH de gestão | 64.176.23.125 | entrada SSH do prod-machine (Vultr) |
| Gateway WireGuard | 216.238.118.15 | relay público Vultr (wg0 gestão / wg1 workload) |
| Enverge Slurm login | 35.189.126.228 | cluster de inferência (GPU) |
Fonte:
~/dev-machine/ansible/group_vars/prod_machine/vars.yml(chatsubo_public_host,chatsubo_public_relay_ipv4,small_pine_enverge_login_ip),group_vars/dev_machine/vars.yml(wrkflw_prod_machine_ssh_host).
2.2 Isolamento de rede (jails VNET + PF)
Cada serviço roda numa jail VNET com bridge/epair próprio e CIDR dedicado, disjunto do dev_machine. O small-pine só alcança os peers de egress nomeados (allowlist), nada mais.
| Jail | Bridge/epair | CIDR |
|---|---|---|
| small-pine | bridge0/epair0 | 172.31.100.0/24 |
| kafka | bridge1/epair1 | 172.31.101.0/24 |
| qdrant | bridge2/epair2 | 172.31.102.0/24 |
| datomic | bridge3/epair3 | 172.31.103.0/24 |
| Slurm Stage-1 | bridge9 | 172.31.110.0/24 |
Fonte:
prod_machine/vars.yml(bloco de comentário do topo +small_pine_egress_peers),pf-management.conf.j2.
2.3 Snapshots / backup
| Mecanismo | O que faz |
|---|---|
zfs-backup | snapshots ZFS semanais idle-gated para o segundo disco, AES-256-GCM |
backup-encryption-migration | migra datasets legados não-criptografados → criptografados |
security-updates | system-snapshot.sh antes de qualquer mudança de pacote |
Fonte:
deployer/services/zfs-backup/role/meta/main.yml,deployer/services/backup-encryption-migration/role/templates/backup-encryption-migrate.sh.j2,deployer/services/security-updates/role/tasks/main.yml.
2.4 Acessos privilegiados
- Escalação de privilégio não-interativa para produção
(ansible_become_password referenciado do vault, nunca em texto plano).
access-safetyrole valida que oansible_userestá emwheele na lista
de operadores antes de qualquer mudança.
- Chaves SSH de operadores do relay Vultr mantidas em
vultr_relay_access.yml (lista explícita, não aberta).
Fonte:
prod_machine/vars.yml(topo),roles/access-safety/tasks/main.yml,group_vars/dev_machine/vultr_relay_access.yml.
3. Template de evidência a preencher (fatos fora do repo)
Os itens abaixo não estão no repo — são documentos/termos que só o proprietário da infra pode fornecer. Cada linha é um campo a preencher com o documento ou o fato correspondente.
| # | Item exigido (E2) | Evidência a anexar | Status |
|---|---|---|---|
| 1 | Termo do provedor (dedicação) | contrato/termo do provedor da VM Chatsubo (Azure) e do gateway (Vultr) atestando que o recurso é dedicado ao NeoTek | ⬜ a preencher |
| 2 | Residência de dados | região/datacenter onde residem os dados (Azure region da VM, Vultr region do gateway, GCP region do Enverge) | ⬜ a preencher |
| 3 | Isolamento do provedor | evidência de que o provedor não tem acesso administrativo ao conteúdo (chaves de criptografia em posse do NeoTek, não do provedor) | ⬜ a preencher |
| 4 | Política de destruição | procedimento documentado de destruição/limpeza dos dados ao fim do contrato (ex.: zfs destroy + wipe dos discos) | ⬜ a preencher |
| 5 | Retenção de snapshots | política de retenção dos snapshots ZFS (quantos, por quanto tempo) | ⬜ a preencher |
| 6 | Inventário de acessos privilegiados | lista atual de quem tem acesso root/operator à VM e ao gateway (além do que está em vultr_relay_access.yml) | ⬜ a preencher |
4. Conclusão
A implementação do ambiente dedicado e isolado está comprovada pelo repo (jails VNET com CIDRs disjuntos, PF allowlist, backup ZFS criptografado, escalação não-interativa). O que falta para fechar o aceite de E2 é a evidência documental da seção 3 — termo do provedor, residência de dados, política de destruição — que é um gap de *evidência*, não de *implementação*.
Próximo passo: preencher a tabela da seção 3 com os documentos/termos do provedor e a política de destruição, e anexá-los ao pacote de validação (E10).
5. Anexo — E1 (escopo e governança)
Em 2026-09-03 o
DOSSIER-MVP-V1-e1-e2-e10-e11.mdfoi removido: ~70% era índice dos dossiês dedicados; a parte própria dele (E1) está preservada aqui.
5.1 Estado real de E1 (fonte: auditoria "Manus AI" 2026-09-01, §3)
O que a auditoria exige: dossiê aprovado, matriz de papéis, classificação do corpus, métricas de sucesso.
| Item exigido | Onde está | Estado |
|---|---|---|
| Matriz de papéis | config.clj:178 ::roles-config (operator/admin/user/teste) + ::users (ianffcs/pcms/ctni.teste) | ✅ existe no código, mas não como documento de governança aprovado |
| Classificação do corpus | owner pinha/dev-machine (docs, kb, ADRs, código) — ingest-pinha-corpus.clj | ✅ implícita no seed, não documentada como classificação |
| Métricas de sucesso | — | ❌ ausente |
| Dossiê aprovado | — | ❌ ausente |
Gap: a matriz de papéis e a classificação do corpus existem no código mas não foram promovidas a um documento de governança assinado. Falta um docs/governance-mvp-v1.md que consolide papéis, classificação e métricas.
5.2 Padrão comum dos entregáveis não-código (E1/E2/E10/E11)
A implementação existe no repo/infra, mas a evidência documental não foi produzida ou enviada à auditoria:
| Entregável | Implementação | Evidência |
|---|---|---|
| E1 (governança) | matriz de papéis + classificação no código | ❌ documento aprovado ausente |
| E2 (ambiente) | VM dedicada + jails + backup | ⏳ seções 2–3 deste dossiê |
| E10 (baseline) | tooling de benchmark + dashboard prontos | ⏳ dossiê dedicado (DOSSIER-MVP-V1-e10-baseline.md) |
| E11 (operação) | deploy/verify/backup reproduzíveis | ⏳ dossiê dedicado (DOSSIER-MVP-V1-e11-operacao.md) |