PostgreSQL — Detalhamento e Regras de Gestão e Governança
Código: HORUS-DAT-GOV-001 Versão: 2.0 — 2026-10-05 Escopo: Diretrizes de organização, operação, migração de sistemas legados e governança dos bancos de dados PostgreSQL dos Sistemas do DTIC — atuais e futuros. Contexto: O PostgreSQL é o banco de dados operacional padrão dos Sistemas do DTIC. Sistemas legados (ex.: SQL Server) podem ser migrados progressivamente para ele.
Resumo Executivo
O PostgreSQL é o destino dos dados de sistemas legados quando estes são migrados. A estratégia de migração não é um lift-and-shift: os dados são reorganizados em um modelo padronizado (ver Doc 05), com schemas por domínio de negócio quando aplicável e padrões modernos de nomenclatura, auditoria e governança.
Este documento especifica como o banco é organizado, como é operado e quem decide o quê.
1. Organização do Banco
1.1 Separação por domínio
Cada sistema define o seu database. Dentro dele, a separação por domínio de negócio é feita por schemas, não por databases adicionais — padrão PostgreSQL idiomático e compatível com ferramentas de CDC e observabilidade. Sistemas com um único domínio podem usar um único schema de negócio. O dado mestre reside no schema mdm do banco do sistema dono da entidade (Doc 06, REG-CM-04). Um sistema pode originar dado mestre consumido por outros, via API do dono; o banco corporativo, na mesma instância do banco do Horus HAB, hospeda as entidades de nível corporativo.
Database: {sistema}
│
├── Schema: {dominio_a} ← domínio de negócio
├── Schema: {dominio_b} ← domínio de negócio
├── Schema: {dados_mestres} ← dados mestres compartilhados entre domínios (quando houver)
├── Schema: seguranca ← IAM / RBAC (quando aplicável)
└── Schema: auditoria ← logs de mudanças, trilha de auditoria
1.2 Responsável por schema
Cada schema tem um gestor técnico que aprova DDL e é notificado em mudanças, e um gestor de negócio:
| Schema | Gestor técnico | Gestor de negócio |
|---|---|---|
| Dados mestres compartilhados | Arquiteto de Dados | Coordenação de TI |
| Domínio de negócio | Arquiteto de Dados | Gerência do domínio |
| Segurança / IAM | Arquiteto de Dados | Coordenação de TI |
| Auditoria | Arquiteto de Dados | (somente leitura para negócio) |
2. Configuração e Infraestrutura
2.1 Hospedagem recomendada
| Parâmetro | Valor recomendado | Justificativa |
|---|---|---|
| Provedor | Cloud SQL for PostgreSQL (GCP) | Consistência com a infraestrutura GCP do DTIC |
| Versão PostgreSQL | Versão major mais recente com suporte vigente no Cloud SQL; revisar a cada ciclo anual | O PostgreSQL não tem designação LTS: cada versão major tem suporte de 5 anos — evitar versões próximas do fim de suporte |
| Região | southamerica-east1 (São Paulo) | Mesma região dos datasets BQ e dos serviços Cloud Run |
| Tier inicial | Dimensionar conforme o volume do sistema (referência: db-custom-4-16384, 4 vCPU, 16 GB RAM) | Ponto de partida; revisar periodicamente e após cargas de migração |
| HA | Regional (standby automático em zona distinta) | RTO < 1 minuto em falha de zona |
| IP | Privado (sem IP público) | Acesso somente via Private Service Connect |
| Rede | VPC do sistema | Mesma VPC dos serviços Cloud Run e das demais instâncias Cloud SQL do sistema |
| Storage | SSD (pd-ssd), com autoscale habilitado | Performance de I/O para cargas de migração |
2.2 Connection pooling
Todas as aplicações devem conectar ao PostgreSQL via PgBouncer em modo transaction pooling. Conexões diretas ao banco são permitidas apenas para o Arquiteto de Dados e pipelines de ETL.
| Parâmetro PgBouncer | Valor |
|---|---|
pool_mode | transaction |
max_client_conn | 500 |
default_pool_size | 20 por usuário/database |
server_idle_timeout | 600s |
2.3 Parâmetros PostgreSQL recomendados
shared_buffers = 4GB # 25% da RAM
effective_cache_size = 12GB # 75% da RAM
work_mem = 64MB # por operação de sort/hash
maintenance_work_mem = 512MB # para VACUUM e criação de índice
max_connections = 200 # PgBouncer cuida do pool externo
wal_level = logical # necessário para CDC / replicação
max_wal_senders = 5
wal_keep_size = 1GB
log_min_duration_statement = 1000 # loga queries > 1s
auto_explain.log_min_duration = 2000 # EXPLAIN automático para queries lentas
No Cloud SQL, estes parâmetros são configurados como database flags da instância (nem todos são editáveis); os valores acima são referência de dimensionamento.
3. Gestão de Acesso e IAM
3.1 Roles (papéis de banco)
O PostgreSQL usa o sistema de roles nativo. Nunca conceder permissões diretamente a usuários — sempre via role.
| Role | Permissões | Quem usa |
|---|---|---|
{sistema}_app | SELECT, INSERT, UPDATE em tabelas de domínio — a exclusão é lógica (Doc 05, Seção 3.3); DELETE apenas em tabelas de staging. Sem DDL. | Aplicação do sistema (service account) |
{sistema}_readonly | SELECT em todos os schemas de domínio. Sem auditoria. | Analistas, pipelines BQ de leitura |
{sistema}_etl | SELECT, INSERT, UPDATE em schemas de staging e bronze. Sem DELETE em produção. | Pipelines de ETL/migração |
{sistema}_admin | Perfil administrativo restrito ao Arquiteto de Dados (no Cloud SQL o nível máximo é cloudsqlsuperuser; não há superusuário real). Não usado por aplicações. Concessão administrativa temporária exige prazo, registro e revisão. | Arquiteto de Dados |
{sistema}_audit | SELECT apenas em schema auditoria. | Time de segurança / auditoria interna |
-- Criação das roles (executar uma vez):
CREATE ROLE {sistema}_app NOLOGIN;
CREATE ROLE {sistema}_readonly NOLOGIN;
CREATE ROLE {sistema}_etl NOLOGIN;
CREATE ROLE {sistema}_audit NOLOGIN;
CREATE ROLE {sistema}_admin NOLOGIN;
-- Grant por schema (exemplo; substituir {sistema} e {schema}):
GRANT USAGE ON SCHEMA {schema} TO {sistema}_app, {sistema}_readonly, {sistema}_etl;
GRANT SELECT ON ALL TABLES IN SCHEMA {schema} TO {sistema}_readonly, {sistema}_etl;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA {schema} TO {sistema}_app;
-- Aplicar para tabelas criadas no futuro:
ALTER DEFAULT PRIVILEGES IN SCHEMA {schema}
GRANT SELECT, INSERT, UPDATE ON TABLES TO {sistema}_app;
ALTER DEFAULT PRIVILEGES IN SCHEMA {schema}
GRANT SELECT ON TABLES TO {sistema}_readonly;
Em tabelas com
id_legado, os privilégios de{sistema}_appe{sistema}_readonlysão concedidos por coluna (Seção 6.4).
3.2 Usuários de serviço
| Usuário | Role atribuída | Uso |
|---|---|---|
sa_{sistema}_app@{projeto}-prod.iam | {sistema}_app | Aplicação do sistema em produção |
sa_{sistema}_etl@{projeto}-prod.iam | {sistema}_etl | Pipelines de migração e ETL |
sa_bq_reader@{projeto}-prod.iam | {sistema}_readonly | Pipelines BigQuery (leitura CDC) |
sa_{sistema}_app@{projeto}-hom.iam | {sistema}_app | Aplicação do sistema em HOM |
sa_mdm_api@{projeto}-prod.iam | corporativo_app | API de cadastro mestre do sistema dono (exemplo); única com escrita no schema mdm do banco |
Nenhum usuário de serviço tem login interativo. Acesso ao Cloud SQL via IAM Database Authentication (não senha em plaintext).
3.3 Acesso humano
- Arquiteto de Dados: acesso via Cloud SQL Auth Proxy + MFA obrigatório
- Desenvolvedores: acesso a HOM apenas, via Cloud SQL Auth Proxy. Nunca acesso direto a PROD.
- Acesso de emergência a PROD: aprovação do Coordenação de TI + registro em
auditoria.acesso_emergencia
3.4 Acesso às tabelas de dados mestres
- Os nomes de serviço e de role deste documento (
mdm-api,sa_mdm_api,corporativo_app) são exemplos e não representam um serviço real. - Somente a API de cadastro mestre do sistema dono (no exemplo,
corporativo_app) temINSERTeUPDATEno schemamdmdo banco. Os demais sistemas não têm role nesse schema e consomem o dado pela API (Doc 06, REG-CM-17). postgres_fdwentre bancos é permitido apenas para ETL e Arquiteto de Dados, em leitura, pelas roles{sistema}_etle{sistema}_admin. Nunca por aplicação.- A conciliação de órfãos (Doc 06, REG-CM-19) roda como job agendado com role de leitura e gera o alerta da Seção 5.1.
4. Backup e Recuperação
4.1 Política de backup
| Tipo | Frequência | Retenção | Responsável |
|---|---|---|---|
| Backup automático (Cloud SQL) | Diário (janela: 02h–04h BRT) | 30 dias | GCP automático |
| Point-in-Time Recovery (PITR) | Contínuo (WAL archiving) | 7 dias | GCP automático |
| Export manual (pg_dump) | Semanal (sexta-feira) | 90 dias | Arquiteto de Dados |
| Export pré-migração | Antes de qualquer migration de risco | Indefinido | Arquiteto de Dados |
4.2 RTO e RPO
| Cenário | RTO | RPO |
|---|---|---|
| Falha de zona (Cloud SQL HA) | < 1 minuto | < 5 segundos |
| Corrupção de dados com PITR | < 4 horas | Segundos a poucos minutos (arquivamento contínuo de logs); recuperação possível até 7 dias atrás |
| Desastre total de região | < 24 horas | Último backup diário |
Não há réplica nem backup fora de
southamerica-east1: a soberania nacional dos dados prevalece sobre a redução de RPO e RTO em desastre de região (RNF-08, Doc 02). Os backups usam localização restrita asouthamerica-east1, e o RPO desse cenário é o do último backup diário.
4.3 Teste de restore
O Arquiteto de Dados executa restore de teste trimestralmente em ambiente isolado, validando:
- Integridade do backup mais recente
- Tempo de restore dentro do RTO definido
- Consistência dos dados após restore (contagem de linhas por tabela principal)
5. Monitoramento
5.1 Alertas obrigatórios (Cloud Monitoring)
| Métrica | Threshold | Ação |
|---|---|---|
| CPU utilization | > 80% por 5 min | Investigar queries lentas |
| Disk usage | > 70% | Planejar expansão de storage |
| Active connections | > 150 (75% do max_connections) | Verificar pool PgBouncer |
| Replication lag | > 30s | Investigar standby |
| Query duration (log) | > 5s | Analisar e otimizar query |
| Failed login attempts | > 10 em 5 min | Alerta de segurança |
| Retenção de WAL por slot de replicação | Crescimento contínuo ou disco > 70% | Verificar slots inativos (CDC parado) |
Idade de transação (xid) / risco de wraparound | Acima do limite definido pelo Arquiteto de Dados | Investigar autovacuum e transações longas |
| Crescimento de tabelas grandes | Desvio da tendência | Avaliar retenção e particionamento (Doc 05, Seção 6.5) |
| Ids órfãos de dado mestre (conciliação, Doc 06, REG-CM-19) | Qualquer ocorrência | Investigar o vínculo e corrigir na origem |
| Taxa de erro ou latência da API de Cadastro Mestre fora da meta (Doc 01, Seção 6) | Consumo acelerado do orçamento de erro | Investigar a API e o banco do sistema dono |
5.2 Queries de monitoramento operacional
-- Conexões ativas por usuário:
SELECT usename, count(*), state
FROM pg_stat_activity
GROUP BY usename, state
ORDER BY count DESC;
-- Tabelas com mais bloqueios:
SELECT relation::regclass, mode, granted, count(*)
FROM pg_locks
GROUP BY relation, mode, granted
ORDER BY count DESC;
-- Queries mais lentas (top 10):
SELECT query, calls, total_exec_time/1000 AS total_s,
mean_exec_time/1000 AS mean_s, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;
-- Tabelas sem VACUUM recente:
SELECT schemaname, tablename, last_autovacuum, last_autoanalyze, n_dead_tup
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;
6. Estratégia de Migração de Sistemas Legados
6.1 Princípios da migração
- Não é lift-and-shift. Os dados chegam no modelo padronizado do PG, não com os schemas e nomenclaturas do sistema de origem.
- Migração por domínio, não por sistema. Cada schema PG é preenchido quando o domínio está pronto para ir ao ar.
- Validação antes de desligar o legado. O sistema legado continua operando durante o período de migração/validação, por no mínimo 30 dias de operação paralela sem inconsistências de conciliação.
- Legado como fonte, PG como destino. Nunca escrever de volta no SQL Server a partir do PG.
6.2 Fases de migração por domínio
A ordem segue a dependência entre domínios: infraestrutura, dados mestres compartilhados, segurança/IAM, domínios de negócio (na ordem de suas dependências) e, por fim, integração e comunicação. Cada sistema registra o seu cronograma em plano próprio, neste formato:
| Fase | Domínio | Schema PG | Origem (legado) | Dependências |
|---|---|---|---|---|
| 0 | Infraestrutura base | Schemas criados vazios | — | Banco PG provisionado |
| 1 | Dados mestres compartilhados (quando houver) | {dados_mestres} | Tabelas de origem | Decisão de dono do dado mestre |
| 2 | Segurança / IAM | seguranca | Tabelas de origem | Dados mestres populados |
| 3…n | Domínios de negócio | {dominio} | Tabelas de origem | Dados mestres e segurança |
| n+1 | Comunicação | {dominio} | Tabelas de origem | Domínios anteriores |
6.3 Processo de migração por fase
Para cada fase, o Arquiteto de Dados e o time de dados executam:
1. Análise de volume e dependências (query no SQL Server legado)
2. Criação das tabelas PG via migration
3. Script de extração e transformação (ETL) SQL Server → PG
- Mapear colunas do legado para colunas PG (De-Para)
- Aplicar mascaramento LGPD para HOM
- Converter tipos: VARCHAR → TEXT, DATETIME → TIMESTAMPTZ, BIT → BOOLEAN
4. Carga inicial em HOM → validação com gestores de negócio
5. Carga em PROD → validação final
6. Ativação dos pipelines CDC (BigQuery Bronze)
7. Período de operação paralela (legado + PG) — mínimo 30 dias
8. Desativação do módulo legado
6.4 Mapeamento de tipos SQL Server → PostgreSQL
| SQL Server | PostgreSQL | Observação |
|---|---|---|
INT IDENTITY | UUID DEFAULT uuidv7() | Gerar novo UUID (v7); guardar ID original em coluna id_legado |
NVARCHAR(n) | VARCHAR(n) ou TEXT | Usar TEXT quando o tamanho é variável/indefinido |
DATETIME, DATETIME2 | TIMESTAMPTZ | Sempre com timezone; converter para UTC |
BIT | BOOLEAN | Direto |
DECIMAL(p,s) | NUMERIC(p,s) | Direto |
MONEY | NUMERIC(19,4) | Nunca usar FLOAT para valores monetários |
UNIQUEIDENTIFIER | UUID | Direto |
IMAGE, VARBINARY | Referência para o armazenamento de objetos (GCS), registrada em tabela de arquivos | Binários não são armazenados no PG |
XML | JSONB ou coluna TEXT | Avaliar caso a caso |
Coluna
id_legado: toda tabela migrada deve ter uma colunaid_legado TEXTpara armazenar o ID original do SQL Server durante o período de transição.
Governança da coluna id_legado
- Acesso restrito: a coluna é visível apenas para as roles
{sistema}_etle{sistema}_admin. A role{sistema}_appnão recebe privilégio sobre ela. Como o privilégio de tabela cobre todas as colunas, nas tabelas comid_legadoa migration que cria a coluna fazREVOKEdo privilégio de tabela de{sistema}_appe{sistema}_readonlye concedeGRANTpor coluna, semid_legado. - Expurgo: a coluna é removida após a desativação do legado, cumprido o checklist abaixo:
- Mínimo de 30 dias de operação paralela sem inconsistências de conciliação.
- Backup completo pré-expurgo arquivado em classe de armazenamento de longa retenção (Coldline).
- Parecer técnico do Arquiteto de Dados.
- Homologação formal pelo Comitê de Dados (Seção 8.1).
- Execução do DDL:
ALTER TABLE {schema}.{tabela} DROP COLUMN id_legado;.
Unicidade com soft delete: constraint UNIQUE clássica impede a reativação de registro excluído logicamente. Em toda tabela migrada com soft delete, a unicidade de chave de negócio usa índice único parcial (Doc 05, Seção 6.4):
CREATE UNIQUE INDEX uq_{entidade}_{coluna} ON {schema}.{tabela} ({coluna}) WHERE fl_excluido = FALSE;
-- Exemplo de coluna de rastreabilidade de migração:
ALTER TABLE processos
ADD COLUMN id_legado TEXT,
ADD COLUMN dh_migracao TIMESTAMPTZ,
ADD COLUMN ds_migrado_por TEXT;
COMMENT ON COLUMN processos.id_legado IS
'ID original no legado ({sistema_legado}.{tabela}.{coluna}). Remover após o desligamento do legado.';
7. Schema de Auditoria
O schema auditoria registra toda operação de escrita no banco, criando trilha de auditoria imutável.
7.1 Estrutura
CREATE SCHEMA IF NOT EXISTS auditoria;
CREATE TABLE auditoria.log_operacao (
id_log UUID PRIMARY KEY DEFAULT uuidv7(),
nm_schema TEXT NOT NULL,
nm_tabela TEXT NOT NULL,
tp_operacao TEXT NOT NULL CHECK (tp_operacao IN ('INSERT','UPDATE','DELETE','EVENTO_SEGURANCA')),
id_registro UUID, -- PK do registro afetado
js_antes JSONB, -- estado antes (UPDATE/DELETE)
js_depois JSONB, -- estado depois (INSERT/UPDATE)
nm_usuario_banco TEXT NOT NULL, -- usuário PG
id_usuario UUID, -- usuário da aplicação (via contexto da transação)
nr_ip_origem INET,
dh_registro TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- Índices para queries de auditoria:
CREATE INDEX idx_log_tabela ON auditoria.log_operacao (nm_schema, nm_tabela, dh_registro DESC);
CREATE INDEX idx_log_registro ON auditoria.log_operacao (id_registro, dh_registro DESC);
CREATE INDEX idx_log_usuario ON auditoria.log_operacao (id_usuario, dh_registro DESC);
O log cresce a cada escrita auditada: definir retenção e avaliar particionamento por
dh_registro(Doc 05, Seção 6.5); se a tabela for particionada, a PK passa a ser composta porid_logedh_registro. Para a trilha ser de fato imutável, revogarUPDATE,DELETEeTRUNCATEsobre ela de todas as roles de aplicação.
7.2 Trigger de auditoria (aplicar em tabelas críticas)
O único argumento do trigger é o nome da coluna PK. As colunas a mascarar não são informadas à mão: a função as obtém do catálogo, a cada operação, a partir dos COMMENT ON COLUMN que começam por LGPD:RESTRITO ou LGPD:SIGILOSO (Doc 05, Seção 3.4). O valor delas é gravado como [RESTRITO] em js_antes e js_depois, para que o log registre que o campo foi alterado sem guardar o dado pessoal. A classificação no comentário é, assim, a única fonte da regra de mascaramento.
CREATE OR REPLACE FUNCTION auditoria.fn_registrar_operacao()
RETURNS TRIGGER AS $$
DECLARE
v_antes JSONB;
v_depois JSONB;
v_id UUID;
v_col TEXT;
BEGIN
IF TG_OP IN ('UPDATE','DELETE') THEN v_antes := to_jsonb(OLD); END IF;
IF TG_OP IN ('UPDATE','INSERT') THEN v_depois := to_jsonb(NEW); END IF;
v_id := (COALESCE(v_depois, v_antes) ->> TG_ARGV[0])::UUID;
-- Mascara as colunas cujo COMMENT começa por LGPD:RESTRITO ou LGPD:SIGILOSO
FOR v_col IN
SELECT a.attname::TEXT
FROM pg_attribute a
WHERE a.attrelid = TG_RELID AND a.attnum > 0 AND NOT a.attisdropped
AND col_description(a.attrelid, a.attnum) ~ '^LGPD:(RESTRITO|SIGILOSO)'
LOOP
IF v_antes ? v_col THEN v_antes := jsonb_set(v_antes, ARRAY[v_col], '"[RESTRITO]"'); END IF;
IF v_depois ? v_col THEN v_depois := jsonb_set(v_depois, ARRAY[v_col], '"[RESTRITO]"'); END IF;
END LOOP;
INSERT INTO auditoria.log_operacao (
nm_schema, nm_tabela, tp_operacao, id_registro,
js_antes, js_depois, nm_usuario_banco, id_usuario, nr_ip_origem, dh_registro
) VALUES (
TG_TABLE_SCHEMA, TG_TABLE_NAME, TG_OP, v_id,
v_antes, v_depois,
current_user,
NULLIF(current_setting('app.usuario_id', true), '')::UUID,
NULLIF(current_setting('app.ip_origem', true), '')::INET,
NOW()
);
RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql;
-- Aplicação: só a PK; as colunas restritas vêm dos COMMENT
CREATE TRIGGER tg_after_pessoas_audit
AFTER INSERT OR UPDATE OR DELETE ON mdm.pessoas
FOR EACH ROW EXECUTE FUNCTION auditoria.fn_registrar_operacao('id_pessoa');
Como o mascaramento deriva dos comentários, coluna restrita criada depois é mascarada assim que recebe o
COMMENT ON COLUMNde classificação, sem alterar o trigger. Coluna com dado pessoal sem o comentárioLGPD:não é mascarada; por isso o comentário é item obrigatório do checklist de modelagem (Doc 05, Seção 9). O log de auditoria nunca guarda dado pessoal restrito em claro e só é lido pela role{sistema}_audit.
O usuário da aplicação deve ser informado dentro da transação, com
SELECT set_config('app.usuario_id', '<uuid>', true)(equivalente aSET LOCAL); o mesmo vale paraapp.ip_origem, com o IP do cliente informado pela aplicação. Nunca usarSETde sessão: ele vaza entre clientes no PgBouncer em transaction pooling (Seção 2.2).
Em produção, é proibido desativar triggers de auditoria (ex.:
session_replication_role = replica) em manutenção manual.
Tabelas obrigatórias para auditoria: todas as do schema
mdm(Doc 06, REG-CM-16), as de dados mestres compartilhados, as de identidade e permissão (usuários e permissões) e qualquer tabela que contenha dados LGPD Restrito ou Sigiloso.
7.3 Retenção de logs de auditoria
| Dados | Retenção no PG | Retenção no BQ / arquivo |
|---|---|---|
Logs operacionais (auditoria.log_operacao) | 2 anos | 5 anos (exportado para BQ) |
| Logs de acesso de emergência | 5 anos | 10 anos |
Logs de acesso ao banco (pg_log) | 90 dias | 1 ano |
7.4 Eventos de segurança
Eventos que não são escrita em tabela (ex.: sessão por Passkey) entram na mesma trilha com tp_operacao = 'EVENTO_SEGURANCA', por função SECURITY DEFINER — a role {sistema}_app não tem acesso direto ao schema auditoria:
CREATE OR REPLACE FUNCTION auditoria.fn_registrar_evento_seguranca(
p_id_usuario UUID, p_ds_evento TEXT, p_nr_ip_origem INET DEFAULT NULL)
RETURNS VOID AS $$
INSERT INTO auditoria.log_operacao
(nm_schema, nm_tabela, tp_operacao, js_depois, nm_usuario_banco, id_usuario, nr_ip_origem)
VALUES ('seguranca', 'eventos', 'EVENTO_SEGURANCA',
jsonb_build_object('ds_evento', p_ds_evento), current_user, p_id_usuario, p_nr_ip_origem);
$$ LANGUAGE sql SECURITY DEFINER SET search_path = auditoria, pg_catalog;
REVOKE ALL ON FUNCTION auditoria.fn_registrar_evento_seguranca(UUID, TEXT, INET) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION auditoria.fn_registrar_evento_seguranca(UUID, TEXT, INET) TO {sistema}_app;
8. Governança de Dados
8.1 Comitê de dados
O Comitê de Dados é o fórum decisório para questões de governança. Reúne-se mensalmente (ou sob demanda para decisões urgentes).
| Papel | Responsabilidade no comitê |
|---|---|
| Arquiteto de Dados | Presidência técnica; proposta de padrões |
| Coordenação de TI | Aprovação de infraestrutura e custos |
| Representante de cada domínio | Validação de regras de negócio do domínio |
| DPO (Encarregado LGPD) | Aprovação de mudanças que envolvam PII |
8.2 Decisões que passam pelo comitê
- Definição ou mudança de dono de dado mestre
- Criação de novo schema (novo domínio)
- Classificação LGPD de nova categoria de dado
- Mudança na política de backup ou retenção
- Aprovação de acesso de terceiros ao banco
- Desativação de sistema legado
8.3 Catálogo de dados
Todo dado no banco deve estar registrado no catálogo de dados corporativo:
| Elemento | Onde documentar | Responsável |
|---|---|---|
| Tabelas e colunas | Comentários COMMENT ON TABLE/COLUMN no próprio banco | Desenvolvedor + Arquiteto |
| Classificação LGPD | COMMENT ON COLUMN com prefixo LGPD: | Desenvolvedor + DPO |
| Linhagem (origem dos dados) | Documento de modelo de dados do sistema (atualizado a cada migração) | Arquiteto de Dados |
| Metadados BQ | Campo description nos datasets e tabelas BQ | Time de dados |
| Classificação PII / Policy Tags (BQ e Postgres) | Google Cloud Knowledge Catalog — Tag Templates de PII e Policy Tags (ver Doc 05, Seção 7.4) | DPO + Arquiteto de Dados |
8.4 Maturidade dos dados — níveis de qualidade
Toda tabela é classificada em um dos níveis abaixo. O nível é registrado no comentário da tabela.
| Nível | Critério | Uso permitido |
|---|---|---|
| Bronze | Dado bruto, sem validação. Pode ter erros da fonte. | Apenas para ETL interno. Nunca expor em BQ Gold ou API. |
| Silver | Dado limpo, tipado, deduplicado. Sem lógica de negócio. | Pipelines analíticos e joins internos. |
| Gold | Dado validado, com lógica de negócio aplicada, aprovado pelos gestores. | Dashboards, APIs públicas, relatórios oficiais. |
COMMENT ON TABLE processos IS
'Processos do sistema. Nível: Gold. Fonte: {sistema_legado}.{tabela}. Migrado: fase {n}.';
9. Decisões Pendentes de Governança
As decisões que bloqueiam etapas da migração devem ser registradas com responsável e prazo, e resolvidas antes do início da fase que bloqueiam. Categorias recorrentes:
| Decisão | Bloqueia | Responsável |
|---|---|---|
| Dono do dado mestre compartilhado (qual sistema é autoritativo por atributo) | Fase de dados mestres | Coordenação de TI + DPO |
| Estratégia de identidade e SSO (manter módulo próprio ou migrar para IdP externo) | Fase de segurança | Coordenação de TI + Gestores |
| Fonte autoritativa quando há mais de um sistema ou geração para o mesmo domínio | Fase do domínio | Gerência do domínio |
| Repositório e dono de dados financeiros ou de integração | Fase de integração | Coordenação de TI |
| Política de mascaramento de PII para HOM | Antes da primeira carga em HOM | DPO + Time de dados |