Capítulo 17 — Arquitetura de Segurança e Identidade

17.1 Objetivo do Capítulo

Este capítulo estabelece as diretrizes técnicas de segurança, identidade e proteção de dados da Plataforma de Relacionamento Digital com o Cidadão.

Segurança não é uma camada adicionada ao final do desenvolvimento — participa de todas as fases: arquitetura, design, desenvolvimento, build, testes, deploy, operação, resposta a incidentes e evolução contínua. A plataforma adota segurança por projeto, defesa em profundidade e menor privilégio como princípios fundamentais.

17.2 Princípios Arquiteturais de Segurança

1. Zero Trust — nenhuma requisição é confiável apenas por origem de rede;
2. Deny by default — o que não é explicitamente permitido é negado;
3. Menor privilégio — cada identidade tem apenas o acesso estritamente necessário;
4. Necessidade de conhecimento — dados são acessíveis apenas por quem precisa para a finalidade definida;
5. Defesa em profundidade — múltiplos controles independentes, sem ponto único de falha de segurança;
6. Identidade explícita — toda entidade que acessa a plataforma tem identidade verificada;
7. Autorização contextual — considera identidade, tenant, perfil, recurso, operação e escopo;
8. Isolamento multi-tenant — dados, configurações e operações de um tenant são impermeáveis a outro;
9. Minimização de dados — coletados e processados apenas os dados necessários à finalidade declarada;
10. Proteção desde a concepção — Privacy by Design e Privacy by Default;
11. Rastreabilidade e auditabilidade — toda ação sensível é rastreável;
12. Gestão centralizada de segredos — credenciais nunca em código, configuração versionada ou bundle;
13. Criptografia em trânsito e em repouso — dados sensíveis protegidos em movimento e armazenados;
14. Automação de controles — segurança integrada ao pipeline, não manual;
15. Detecção e resposta — monitoramento contínuo com capacidade de resposta a incidentes.

17.3 Modelo Zero Trust

A plataforma adota Zero Trust como modelo arquitetural. O princípio central:

Nenhuma requisição é considerada confiável apenas por sua origem de rede.

Estar na mesma rede, no mesmo cluster, no mesmo datacenter ou na nuvem da PRODEMGE não constitui autorização implícita.

Fluxo Zero Trust em toda operação:

Request
    │
Verify Identity         → quem é o solicitante?
    │
Validate Credentials    → a credencial é válida e não expirada?
    │
Resolve Tenant Context  → a qual tenant pertence essa operação?
    │
Evaluate Authorization  → o solicitante tem a permissão para esta ação?
    │
Evaluate Resource Scope → o recurso pertence ao tenant do contexto?
    │
Execute
    │
Audit (quando exigido)

17.4 Domínios de Identidade

A plataforma diferencia categorias de identidade com tratamentos distintos:

Um cidadão autenticado não é um usuário administrativo. Um serviço técnico não é um usuário humano. Uma integração externa não usa credenciais de um operador.

17.5 IAM Próprio

O IAM próprio é responsável pela gestão de identidade interna da plataforma, suportando:

• cadastro e ciclo de vida de tenants;
• usuários com credenciais locais;
• políticas de senha e expiração;
• bloqueio e inativação;
• recuperação de acesso por fluxo seguro (sem exposição de informações sobre existência da conta);
• MFA conforme política do tenant;
• sessões com expiração e revogação;
• emissão de tokens de acesso;
• perfis, papéis e permissões;
• vínculos usuário-tenant-unidade;
• federação de identidade (GOV.BR);
• auditoria de autenticação.

O modelo de dados central:

Tenant
  │
  ├── Users ────────── Credentials
  │                         │
  │                    Authentication
  │                      Policies
  ├── Roles
  │     │
  │     └── Permissions
  │
  └── UserTenantMembership
          │
          ├── User
          ├── Role(s)
          └── Organizational Scope

A existência de um usuário no IAM não concede automaticamente acesso a todos os tenants — o vínculo é explícito e pode ter data de início, término, perfis e escopo organizacional.

17.6 Integração com GOV.BR

O GOV.BR atua como provedor de identidade federada para cidadãos. O fluxo segue OpenID Connect com Authorization Code + PKCE:

Cidadão seleciona "Entrar com GOV.BR"
    │
Plataforma inicia Authorization Request com code_challenge (PKCE)
    │
GOV.BR autentica o cidadão
    │
GOV.BR retorna Authorization Code
    │
Plataforma troca o code por tokens (com code_verifier)
    │
Plataforma valida: issuer, audience, assinatura, expiração, nonce, state, redirect_uri
    │
Plataforma resolve identidade interna por identificador estável do GOV.BR
    │
Plataforma emite sessão própria

A plataforma nunca armazena a senha GOV.BR. A autorização interna é sempre responsabilidade da plataforma — a autenticação GOV.BR confirma identidade, não concede permissões.

A vinculação da identidade GOV.BR à identidade interna usa identificador estável do provedor (não nome ou e-mail mutável).

17.7 OAuth 2.0 e Tokens

17.7.1 Grants Permitidos

• Authorization Code + PKCE para clientes públicos (React Native, SPA React quando aplicável);
• Authorization Code para clientes confidenciais com segredo gerenciado;
• Client Credentials para fluxos service-to-service.

Grants obsoletos (Implicit, Resource Owner Password) não são utilizados.

17.7.2 Access Tokens

Tokens de acesso contêm apenas o necessário: issuer, audience, subject, expiração, escopo ou claims essenciais. Dados pessoais completos, documentos e informações extensas de negócio não são incluídos.

Quando JWT é utilizado, o resource server valida obrigatoriamente: assinatura, issuer, audience, expiração, algoritmo permitido (sem aceitar none). A validação usa bibliotecas consolidadas — implementação manual de validação criptográfica é vedada.

17.7.3 Sessões Web

A estratégia de sessão Web (cookie seguro com token opaco vs. token JWT em memória) é definida por ADR-079, considerando proteção contra XSS, CSRF e storage seguro no contexto do navegador.

17.7.4 React Native

Aplicativos React Native usam Authorization Code + PKCE. Tokens são armazenados em armazenamento seguro do dispositivo (Keychain no iOS, EncryptedSharedPreferences ou Keystore no Android). Tokens nunca são armazenados em AsyncStorage sem criptografia.

17.8 Autenticação Multifator (MFA)

MFA é aplicado conforme classificação do acesso:

Step-up authentication eleva o nível de autenticação durante a sessão para operações específicas de maior risco, sem exigir novo login completo.

17.9 Modelo de Autorização

17.9.1 RBAC Base

RBAC (Role-Based Access Control) organiza perfis e permissões:

Permissões granulares (ex.: REQUEST_READ, REQUEST_SUBMIT)
    │
Agrupadas em Roles (ex.: ATENDENTE, GESTOR_OPERACIONAL)
    │
Atribuídas a Usuários no contexto do Tenant
    │
Aplicadas com Escopo (tenant, unidade, tipo de recurso)

Permissões nomeadas por recurso e operação (REQUEST_READ, WORKFLOW_ADMIN) — nunca nomes genéricos como ADMIN ou USER sem escopo.

17.9.2 RBAC + Autorização por Recurso (BOLA)

Para operações em recursos específicos, o RBAC é complementado pela verificação de que o recurso pertence ao tenant do contexto:

Usuário tem permissão REQUEST_READ?     (RBAC)
    │
Request.tenantId == TenantContext.tenantId?  (BOLA)
    │
Usuário tem escopo de unidade compatível?    (ABAC contextual)
    │
Autorizado

O passo de BOLA não é opcional. O ID do recurso na URL não é evidência de autorização.

17.9.3 ABAC Contextual

ABAC (Attribute-Based Access Control) complementa o RBAC em operações contextuais: acesso a manifestações de ouvidoria com confidencialidade, acesso a dados pessoais sensíveis, operações com scope de unidade organizacional específica.

17.9.4 Segregação de Funções

Funções incompatíveis são separadas. Exemplos: quem aprova serviços no catálogo não é a mesma pessoa que os publica; quem acessa trilha de auditoria não é quem gerou as entradas analisadas; administrador de plataforma e administrador de tenant têm escopos distintos.

17.10 Tenant Context na Segurança

17.10.1 Estabelecimento

O Tenant Context é derivado de identidade autenticada e seus vínculos — nunca aceito de parâmetro enviado pelo cliente como único fator:

Authenticated Subject
    │
Identity / Membership
    │
Requested Tenant Context (se o header X-Tenant-Id for enviado)
    │
Tenant Validation
    │
Effective Tenant Context

A plataforma rejeita: tenant inexistente, tenant inativo, vínculo inexistente, vínculo inativo, contexto incompatível com o recurso.

17.10.2 Propagação

O Tenant Context é propagado entre serviços via headers internos confiáveis. Serviços receptores confiam nesses headers apenas quando a requisição vem de componente interno autenticado — nunca quando vêm diretamente da Internet.

Em mensagens RabbitMQ, o tenantId é campo obrigatório do envelope e validado pelo consumidor antes de processar o payload.

17.11 Comunicação Entre Serviços

17.11.1 Service-to-Service Authentication

Serviços nunca aceitam requisições de outros serviços sem autenticação. As estratégias avaliadas: tokens de serviço com escopo limitado e expiração curta; mTLS com certificados por workload.

17.11.2 mTLS

mTLS é avaliado para comunicação entre componentes de alta criticidade. O certificado de cada workload constitui sua identidade no transporte. mTLS não substitui autorização de negócio — é controle de transporte, não de aplicação.

17.11.3 Workload Identity

Workloads possuem identidade própria. Credenciais compartilhadas entre serviços são evitadas. Quando a infraestrutura homologada suportar, workload identity substitui credenciais estáticas de serviço:

Workload
    │
Platform Identity
    │
Short-Lived Credential
    │
Target Service

Credenciais técnicas que forem necessárias têm: owner, finalidade, escopo, expiração/rotação, armazenamento seguro e rastreabilidade. Credencial sem owner identificado é tratada como não conformidade.

17.12 TLS e Certificados

TLS é obrigatório em toda comunicação de rede contendo autenticação, dados pessoais, documentos ou informações operacionais. Versões obsoletas (TLS 1.0, TLS 1.1) e cipher suites inseguros são desabilitados.

Certificados possuem inventário com: subject/serviço, emissor, ambiente, finalidade, expiração, responsável e mecanismo de renovação. Alertas antecipam o vencimento — expiração de certificado não é descoberta apenas após indisponibilidade. Renovação é automatizada quando o ambiente suporta.

17.13 Gestão de Segredos

Segredos são mantidos em mecanismo centralizado e controlado. Incluem: credenciais de banco, credenciais RabbitMQ, chaves de API, secrets OAuth, chaves de integração e material criptográfico.

Segredos nunca estão em:

• repositório Git (incluindo histórico);
• Dockerfile ou imagem de container;
• README ou documentação versionada;
• application.yml com valores reais;
• bundle da aplicação React ou React Native.

A rotação de segredos é suportada sem downtime. A estratégia considera o período de transição quando o componente dependente não pode trocar credencial instantaneamente. O bootstrap de identidade do workload para acessar o cofre de segredos é resolvido por workload identity ou mecanismo equivalente — não por outra credencial estática em arquivo de configuração.

17.14 Criptografia

17.14.1 Em Trânsito

TLS obrigatório. mTLS avaliado para serviços internos críticos. Chaves efêmeras para Perfect Forward Secrecy. Cipher suites configurados conforme política institucional.

17.14.2 Em Repouso

Dados sensíveis em repouso são criptografados conforme classificação. Chaves gerenciadas por KMS, HSM ou mecanismo corporativo aprovado — nunca hardcoded. O acesso às chaves é separado do acesso aos dados quando aplicável.

17.14.3 Em Nível de Aplicação

Campos de alta sensibilidade (dados de saúde, documentos identificadores, dados financeiros) podem requerer criptografia no nível da aplicação, adicional à criptografia de disco, quando o risco justificar e a política definir.

17.15 Segurança de APIs

17.15.1 OWASP API Top 10

A plataforma implementa controles para as principais vulnerabilidades de APIs:

• BOLA (Broken Object Level Authorization) — verificação de ownership do recurso pelo tenant;
• Broken Authentication — validação de token em toda requisição, sem bypass por rota;
• Broken Object Property Level Auth — filtro dos campos retornados conforme perfil;
• Unrestricted Resource Consumption — rate limiting e limites de payload;
• Broken Function Level Auth — autorização de endpoint por permissão explícita;
• Server Side Request Forgery (SSRF) — validação de URLs em chamadas externas, allowlist;
• Security Misconfiguration — headers de segurança, CORS restritivo, métodos HTTP explícitos;
• Injection — validação e sanitização de toda entrada, uso de prepared statements;
• Improper Inventory Management — catálogo de APIs com estado ativo/depreciado;
• Unsafe Consumption of APIs — validação das respostas de integrações externas.

17.15.2 Validação de Entrada

Toda entrada é validada: tipos, formatos, tamanho, caracteres permitidos. A validação acontece no backend — a validação de frontend é experiência de usuário, não controle de segurança.

17.15.3 Security Headers

APIs HTTP respondem com headers de segurança: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY quando aplicável, Content-Security-Policy nas aplicações Web. Upload de arquivos retorna Content-Type validado pelo backend, nunca pelo nome fornecido pelo cliente.

17.16 Segurança de Aplicações Web (React)

17.16.1 Content Security Policy

CSP restringe origens de scripts, estilos, imagens e frames. Inline scripts são evitados. eval() é proibido. A política é definida e testada por ambiente.

17.16.2 XSS

Saída renderizada pelo React é sanitizada. Uso de dangerouslySetInnerHTML é proibido sem revisão de segurança explícita. Conteúdo gerado por usuário ou por IA é sempre tratado como dado, nunca como markup.

17.16.3 CSRF

A estratégia de proteção CSRF é alinhada ao mecanismo de autenticação. Tokens em headers (Authorization: Bearer) não são vulneráveis ao CSRF clássico de cookies. Quando cookies são usados, SameSite e CSRF tokens são aplicados.

17.16.4 Source Maps

Source maps não são expostos em produção. O código-fonte do bundle não é acessível por terceiros.

17.17 Segurança do Aplicativo Mobile (React Native)

• Tokens armazenados em secure storage do dispositivo (Keychain / EncryptedSharedPreferences);
• Authorization Code + PKCE para autenticação (sem Implicit Flow);
• Certificate pinning avaliado para comunicação com APIs críticas;
• WebViews com conteúdo externo são isoladas com javaScriptEnabled: false quando possível;
• Dados sensíveis não são armazenados em logs do dispositivo;
• Secrets nunca são embutidos no bundle distribuído;
• O backend não confia no aplicativo como segredo — autorização é sempre server-side.

17.18 Segurança do RabbitMQ

• Cada serviço tem credenciais específicas com permissões mínimas (apenas as exchanges e filas necessárias);
• TLS em toda comunicação com o broker;
• RabbitMQ não é exposto publicamente;
• Credenciais gerenciadas pelo cofre de segredos;
• O payload das mensagens não transporta dados pessoais além do necessário ao processamento;
• O tenant no envelope é validado pelo consumidor antes de processar;
• Replays de DLQ são operações autenticadas, autorizadas e auditadas;
• Testes de isolamento multi-tenant em mensageria são parte da suíte de segurança.

17.19 Segurança do Redis

• Redis não é exposto publicamente;
• Acesso restrito por rede e por autenticação;
• Chaves tenant-aware garantem namespace isolado por tenant;
• Dados pessoais em cache são minimizados;
• Sessões em Redis (quando utilizadas) têm expiração e política de revogação;
• Fail-closed para caches de controle de segurança (autorização, rate limiting).

17.20 Segurança do GED

• Download de documento exige autorização re-validada no momento do acesso (não apenas no upload);
• A URL de download não é pública ou compartilhável sem token de autorização;
• Upload passa por pipeline de validação: formato, tamanho, tipo MIME verificado pelo conteúdo (não pela extensão), quarentena antes de disponibilizar;
• Documentos são classificados por sensibilidade; acesso é restrito por perfil e finalidade;
• Documentos enviados a componentes de IA são explicitamente autorizados por política do tenant.

17.21 Segurança do Data Lake

• Acesso ao Data Lake é restrito por perfil e finalidade — não há acesso genérico;
• Datasets possuem metadados de segurança: classificação, owner, tenant, finalidade, retenção;
• Queries analíticas respeitam contexto de tenant — um analista do tenant A não acessa partições do tenant B;
• Dados pessoais em datasets são minimizados antes da ingestão quando possível;
• Integração com Data Lake MG transporta apenas datasets autorizados;
• Backups do Data Lake têm controle de acesso e criptografia.

17.22 Segurança de IA

Os controles de segurança de IA são complementares aos definidos no Capítulo 16 e são resumidos aqui sob a perspectiva de segurança:

• o AI Gateway é a única fronteira de entrada para capacidades de IA — nenhum serviço de negócio chama provedores diretamente;
• isolamento de tenant em bases vetoriais, configurações e quotas é estrutural e testado;
• prompt injection e indirect prompt injection são tratados como riscos arquiteturais com controles em múltiplas camadas;
• a autorização de ações transacionais nunca é delegada ao LLM — o backend valida independentemente;
• dados pessoais são minimizados antes de enviados a modelos; redaction é aplicado conforme política;
• logging de IA não inclui prompts integrais com dados pessoais — apenas metadados técnicos e identificadores;
• política de dados por provedor é verificada antes de enviar dados classificados;
• excessive agency é prevenida por Tool Registry com escopo restrito e confirmação humana para ações sensíveis.

17.23 Proteção de Dados Pessoais e LGPD

17.23.1 Papéis Contratuais

Conforme a Cláusula Décima Sétima da Minuta de Contrato (Anexo VII):

• PRODEMGE = Controladora (Art. 5º, VI da LGPD);
• Parceira = Operadora (Art. 5º, VII da LGPD).

A Parceira trata dados pessoais segundo os ditames e interesses da PRODEMGE, em conformidade com a LGPD. Incidentes de segurança com violação de dados pessoais são notificados imediatamente à PRODEMGE pelo e-mail lgpd@prodemge.gov.br. Solicitações de titulares são notificadas à PRODEMGE em até 3 dias úteis (Art. 17.6 do Contrato).

17.23.2 Privacy by Design

Proteção de dados participa da concepção. Para cada capacidade ou dado novo:

• É realmente necessário coletar esse dado?
• Qual é a finalidade específica?
• Qual é o dado mínimo para essa finalidade?
• Quem pode acessar e com qual escopo?
• Por quanto tempo é retido?
• Em quais sistemas é replicado (cache, índice, vetores, Data Lake, IA)?
• Existe base legal definida?

17.23.3 Privacy by Default

Configurações padrão favorecem menor exposição:

• novo dataset não é automaticamente disponível à IA;
• nova classe de documento não é automaticamente pública;
• novo tenant não tem acesso a analytics de outros tenants;
• novo campo de formulário não é indexado automaticamente para busca sem definição.

A ampliação de acesso é sempre explícita, não implícita.

17.23.4 Classificação de Dados

Dados pessoais sensíveis (Art. 5º, II da LGPD) possuem marcação adicional e controles específicos.

17.23.5 Minimização

Serviços consomem apenas dados necessários à finalidade. O Communication Service que envia uma notificação recebe: referência ao destinatário, canal, template e parâmetros autorizados — não o perfil completo do cidadão.

17.23.6 Inventário de Tratamentos

A plataforma fornece metadados técnicos para o inventário de tratamentos: domínio, dado, finalidade, sistema, integração, retenção e consumidores. O inventário jurídico e de privacidade é governado pelas áreas responsáveis na PRODEMGE.

17.23.7 Direitos dos Titulares

A arquitetura suporta a localização e o tratamento de dados de um titular quando a governança determinar atendimento de direito aplicável (acesso, correção, exclusão, portabilidade). O catálogo de dados permite responder onde os dados do titular estão.

17.23.8 Propagação de Exclusão

Exclusão de dados pessoais segue workflow rastreável que alcança todas as cópias:

Solicitação de exclusão autorizada
    │
Exclusão no banco operacional do domínio
    │
Remoção no índice de busca
    │
Remoção no vector store
    │
Invalidação no cache
    │
Ação no Data Lake conforme política de retenção
    │
Evidência de conclusão registrada

Consistência eventual é aceita entre as etapas. Backups históricos são tratados conforme política de retenção e backup — a exclusão imediata de todas as cópias históricas pode não ser tecnicamente compatível, o que é endereçado pela política de proteção de dados em backup.

17.23.9 Anonimização

Remoção de nome e CPF não garante anonimização. A análise considera: combinação de atributos residuais, unicidade do registro, dados auxiliares disponíveis e possibilidade razoável de reidentificação. A anonimização é avaliada técnica e juridicamente.

17.24 Auditoria de Segurança

17.24.1 Trilha de Auditoria

A trilha de auditoria é imutável. Ações auditadas incluem: autenticação e falhas de autenticação, alteração de perfil e permissão, acesso a dado sensível ou confidencial, alteração de serviço ou processo, decisão sobre solicitação, download de documento, alteração de configuração de tenant, operações de IA com dados sensíveis, replays de DLQ, exportações, operações administrativas privilegiadas.

17.24.2 Separação de Responsabilidades de Log

• Logs operacionais — para diagnóstico de aplicação (OpenTelemetry, structured logging);
• Traces — para rastreamento distribuído de requisições;
• Auditoria — para conformidade e responsabilidade, com imutabilidade.

As três categorias não se misturam. Um log operacional não é trilha de auditoria. A ausência de log de diagnóstico não pode ser compensada por uma consulta na trilha de auditoria.

17.24.3 Logs Seguros

Logs nunca contêm: senhas, tokens completos, refresh tokens, secrets, documentos integrais, prompts completos com dados sensíveis. Dados pessoais em logs são minimizados. Identificadores técnicos são usados para correlação.

17.24.4 Eventos de Segurança Catalogados

Eventos monitorados para detecção: múltiplas falhas de autenticação seguidas de sucesso (credential stuffing), acesso a recurso de tenant diferente do contexto (BOLA attempt), alteração de perfil em horário atípico, acesso administrativo incomum, taxa de chamadas de IA acima do normal, tentativas de prompt injection detectadas.

17.25 Detecção e Resposta a Incidentes

17.25.1 Monitoramento de Segurança

Alertas são configurados para: falhas de autenticação acima do threshold, circuit breaker de integração aberto, DLQ com mensagens acumulando, tentativas de acesso cruzado entre tenants, expiração de certificado iminente, secrets acessados por workload não autorizado.

17.25.2 Resposta a Incidentes

A plataforma possui runbooks para categorias de incidente: comprometimento de credencial, vazamento de dados entre tenants, acesso não autorizado a dados pessoais, violação de dados pessoais (com notificação à PRODEMGE e via lgpd@prodemge.gov.br), disponibilidade de serviço crítico, cross-tenant RAG retrieval.

17.25.3 Incidente de Dados Pessoais

A notificação de incidente com violação de dados pessoais segue o prazo contratual (imediato à PRODEMGE). A arquitetura suporta: identificação rápida do escopo do incidente, contenção (kill switch, revogação de tokens), evidência da extensão, notificação e registro.

17.26 DevSecOps — Segurança no Pipeline

A segurança é integrada ao pipeline de entrega, não executada apenas por revisão manual:

17.26.1 Security Gates

Vulnerabilidades críticas e altas bloqueiam o pipeline automaticamente. O processo de exceção é formal, documentado e com responsável definido.

17.26.2 Testes de Segurança Específicos da Plataforma

• Suíte de isolamento multi-tenant — testa que dados de um tenant não são retornados por requisições de outro;
• Suíte de autorização negativa — testa que operações sem permissão retornam 403, não dados parciais;
• Testes de BOLA — verifica que recursos de outros tenants retornam 404 ou 403;
• Testes de RAG cross-tenant — verifica que busca semântica não retorna conteúdo de outro tenant.

17.27 Matriz de Autenticação

17.28 Decisões Confirmadas

1. Zero Trust como modelo arquitetural — nenhuma confiança implícita por origem de rede;
2. IAM próprio gerencia tenants, usuários, perfis, permissões e sessões;
3. GOV.BR é o provedor de identidade federada para cidadãos (OpenID Connect);
4. PKCE é obrigatório para clientes públicos (React Native, SPA);
5. Tenant Context é derivado de identidade autenticada, nunca de parâmetro isolado do cliente;
6. BOLA é verificado em toda operação de recurso específico;
7. Segregação de funções é aplicada a perfis administrativos críticos;
8. Segredos são gerenciados por cofre centralizado; nunca em Git ou bundle;
9. TLS é obrigatório em toda comunicação de rede com dados sensíveis;
10. Rotação de segredos é suportada sem downtime;
11. SAST, SCA e container scanning são obrigatórios no pipeline;
12. PRODEMGE é controladora; Parceira é operadora conforme Cláusula 17 do Contrato;
13. Incidentes de dados pessoais são notificados imediatamente à PRODEMGE via lgpd@prodemge.gov.br;
14. Privacy by Design e Privacy by Default participam da concepção de toda capacidade;
15. Propagação de exclusão alcança banco, cache, índices, vetores e Data Lake;
16. Trilha de auditoria é imutável e separada de logs operacionais.

17.29 Benefícios da Arquitetura de Segurança

• identidade centralizada com suporte a IAM próprio e GOV.BR sem acoplamento;
• isolamento multi-tenant validado em todas as camadas: dados, cache, mensageria, IA e Data Lake;
• autorização contextual que considera tenant, perfil, recurso e operação;
• defesa em profundidade com controles independentes em API Gateway, serviço e banco;
• proteção de dados desde a concepção com Privacy by Design e Privacy by Default;
• DevSecOps integrado ao pipeline com security gates automáticos;
• rastreabilidade ponta a ponta com trilha imutável e AI Request ID;
• resiliência a compromissos parciais — comprometimento de um serviço não concede acesso irrestrito;
• base para atendimento às obrigações da LGPD e da Cláusula 17 do Contrato.

17.30 Riscos e Mitigações

17.31 Decisões Arquiteturais

17.32 Rastreabilidade com o Anexo III

• Bloco 1 — Relacionamento e Atendimento: autenticação de cidadãos (IAM + GOV.BR); autorização por perfil; Tenant Context em todas as interações.
• Bloco 2 — BPM: autorização de tarefas por perfil e unidade; auditoria de decisões de processo; segregação de funções entre modelador e executor.
• Bloco 3 — Gestão Documental: autorização no download; pipeline de quarentena no upload; classificação documental; controle de acesso a documentos sensíveis.
• Bloco 4 — Dados e Inteligência: segurança do Data Lake com partições por tenant; isolamento vetorial; política de dados enviados a provedores de IA; redaction.
• Bloco 5 — Integração: autenticação por integração (GOV.BR, SEI!MG, MG API); credenciais no cofre; TLS em todas as chamadas externas.
• Bloco 6 — Infraestrutura, Segurança e Governança: Zero Trust, mTLS, gestão de segredos, DevSecOps, SBOM, assinatura de artefatos, trilha de auditoria imutável, LGPD, Privacy by Design.

17.33 Considerações Finais

A segurança da Plataforma de Relacionamento Digital com o Cidadão é estruturada sobre Zero Trust, defesa em profundidade, menor privilégio e isolamento multi-tenant. O IAM próprio e a integração com GOV.BR proveem identidade verificada para todos os tipos de usuário. O Tenant Context derivado de identidade garante que a segregação entre órgãos seja estrutural — não apenas por filtro de aplicação. A integração de segurança ao pipeline pelo DevSecOps garante que vulnerabilidades sejam detectadas antes de chegarem à produção.

A conformidade com a LGPD é suportada tecnicamente pela arquitetura: Privacy by Design e Privacy by Default orientam a concepção de toda capacidade; a propagação de exclusão cobre todas as camadas onde dados pessoais podem residir; a trilha de auditoria imutável suporta rastreabilidade e resposta a incidentes nos termos da Cláusula 17 do Contrato.

17.34 Controle de Versão

17.35 Rastreabilidade PRODEMGE

• [ANX-III] — Bloco 6 (Infraestrutura, Segurança e Governança) coberto integralmente; contribuições aos Blocos 1 a 5 conforme seção 17.32.
• [ANX-IV] — Capacidades técnicas de autenticação, autorização, multi-tenancy seguro, criptografia, DevSecOps e proteção de dados.
• [ANX-V] — Sustentabilidade: segurança integrada ao ciclo de desenvolvimento, rotação de segredos sem downtime, pipeline de segurança automatizado, testes de isolamento como parte da suíte de regressão.
• [ANX-VII] Cláusula 17 — Arquitetura alinhada aos papéis de controladora (PRODEMGE) e operadora (Parceira); suporte técnico à notificação de incidentes; mecanismos de propagação de exclusão e inventário de tratamentos.
• [PNR] — Plano de Negócio Referencial: plataforma segura, com controle de acesso por perfil, auditoria, conformidade com LGPD e integração com GOV.BR.
• [EDITAL] — Edital CP001/2026: plataforma com arquitetura de segurança por projeto, isolamento multi-tenant e proteção de dados pessoais dos cidadãos.