Melhores Práticas de Segurança

A segurança de produção do PostgreSQL é um conjunto de regras de rede, TLS, SCRAM, funções de menor privilégio e evidências de auditoria. Estas regras se aplicam em RDS, Patroni auto-hospedado e Postgres serverless igualmente.

Como Usar Esta Lista

Valide antes do lançamento em produção e após qualquer incidente de credencial ou acesso a dados
Emparelhe com Noções Básicas de Segurança para contexto de modelo de ameaças
Trate senhas de superusuário compartilhadas como uma falha automática na revisão

A - Rede e Transporte

Porta 5432 não pública para a internet. Grupos de segurança / firewall permitem apenas sub-redes de aplicativos.
hostssl para funções remotas em pg_hba. Rejeite hostnossl de CIDRs de aplicativos.
Clientes usam sslmode=verify-full com CA do provedor. Não apenas require em produção.
TLS leste-oeste considerado quando o modelo de ameaças da VPC inclui movimento lateral.
Bastion ou VPN para acesso administrativo humano. Sem psql de produção direto de laptops sem jump host.

B - Autenticação e Funções

SCRAM-SHA-256 para funções de senha. Refaça quaisquer verificadores md5 restantes.
Nenhum runtime de aplicativo com superusuário. Administradores de "break-glass" são indivíduos nomeados.
Uma função por serviço / unidade de implantação. Nenhum usuário app compartilhado entre 12 microsserviços.
REVOKE ALL ON DATABASE ... FROM PUBLIC em novos bancos de dados. Concessões padrão não são seguras.
Função de migração apenas para DDL em CI. Funções de runtime não podem CREATE ou DROP.
Rotação de senha no desligamento e trimestralmente para conformidade. Segredos gerados pelo Vault.

C - Autorização e Dados

RLS habilitado para esquema compartilhado multi-tenant. Políticas testadas com casos negativos.
search_path fixo por função. Previne sequestro de objetos.
Extensões apenas da lista de permissões. Sem CREATE EXTENSION não confiável em produção.
Tabelas PII com colunas minimizadas. Analistas recebem visualizações sem campos sensíveis.
Injeção SQL prevenida apenas por meio de consultas parametrizadas. Nenhuma concatenação de strings em "escape hatches" de ORM.

D - Auditoria e Conformidade

Conexão e desconexão registradas. Retenção centralizada de no mínimo 90 dias.
DDL registrado (log_statement = ddl ou pgaudit). A derivação de esquema é relevante para a segurança.
pgaudit ou equivalente em dados regulamentados. Escopo ajustado para evitar inundações de logs.
Simulação forense trimestral. "Quem leu a tabela X no mês passado?" respondido com evidências.
Criptografia em repouso verificada no código de infraestrutura. RDS criado criptografado; snapshots com suporte a KMS.

E - Operações

Patches aplicados dentro do SLA do fornecedor. Existe um runbook de resposta a CVE.
Backups criptografados e restauração testada. Dump roubado é inútil sem chaves.
Segredos não em git ou camadas de contêiner. Segredos K8s/SSM com rotação.
Credenciais de staging não podem alcançar produção. Clusters e limites IAM separados.
Runbook de incidentes inclui etapas de revogação de credenciais. Pré-escrito, não inventado durante SEV.

FAQs

Segurança mínima viável para startup?

Rede privada, TLS, SCRAM, função de aplicativo sem superusuário, instância gerenciada criptografada, registro de conexão.

Como eu imponho em CI?

Verificações de política do Terraform para StorageEncrypted, sqlfluff em migrações, sem URLs de produção em manifestos de staging.

O trabalho do grupo de segurança está feito?

Não. DBAs ainda possuem funções, extensões e auditoria. O perímetro da nuvem é necessário, mas não suficiente.

Réplica de leitura compartilhada para BI?

Função somente leitura; caminho de rede com as mesmas regras TLS; filtros de linha via visualizações ou RLS.

Quando o superusuário é aceitável?

Instalação de extensão, recuperação principal, "break-glass". Nunca em variáveis de ambiente de implantação de aplicativos.

A ordem do pg_hba importa?

Sim. A primeira linha correspondente vence. Coloque reject/hostssl específicos antes de regras amplas.

Segurança vs. desempenho?

TLS e SCRAM são baratos. pgaudit amplo de read é caro - escopo-lo.

Sidecar de contêiner para credenciais?

Preferível a incorporar DSN na imagem. Rotacione reiniciando a implantação com uma nova versão do segredo.

Mapeamento de conformidade?

Mapeie cada caixa de seleção para o ID de controle na matriz SOC2/HIPAA; armazene capturas de tela de evidências na ferramenta GRC.

Por onde começar após uma violação?

Rotacione todas as funções que tocaram nos dados afetados, preserve os logs, habilite pgaudit expandido e, em seguida, determine a causa raiz.

Relacionados

Noções Básicas de Segurança - modelo de ameaças
Configuração SSL/TLS - configuração TLS
Autenticação SCRAM - autenticação de senha
pgaudit e Registro de Conformidade - escopo de auditoria
Criptografia em Repouso - criptografia de disco

Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.

Melhores Práticas de Segurança

Como Usar Esta Lista

Valide antes do lançamento em produção e após qualquer incidente de credencial ou acesso a dados
Emparelhe com Noções Básicas de Segurança para contexto de modelo de ameaças
Trate senhas de superusuário compartilhadas como uma falha automática na revisão

A - Rede e Transporte

Porta 5432 não pública para a internet. Grupos de segurança / firewall permitem apenas sub-redes de aplicativos.
hostssl para funções remotas em pg_hba. Rejeite hostnossl de CIDRs de aplicativos.
Clientes usam sslmode=verify-full com CA do provedor. Não apenas require em produção.
TLS leste-oeste considerado quando o modelo de ameaças da VPC inclui movimento lateral.
Bastion ou VPN para acesso administrativo humano. Sem psql de produção direto de laptops sem jump host.

B - Autenticação e Funções

SCRAM-SHA-256 para funções de senha. Refaça quaisquer verificadores md5 restantes.
Nenhum runtime de aplicativo com superusuário. Administradores de "break-glass" são indivíduos nomeados.
Uma função por serviço / unidade de implantação. Nenhum usuário app compartilhado entre 12 microsserviços.
REVOKE ALL ON DATABASE ... FROM PUBLIC em novos bancos de dados. Concessões padrão não são seguras.
Função de migração apenas para DDL em CI. Funções de runtime não podem CREATE ou DROP.
Rotação de senha no desligamento e trimestralmente para conformidade. Segredos gerados pelo Vault.

C - Autorização e Dados

RLS habilitado para esquema compartilhado multi-tenant. Políticas testadas com casos negativos.
search_path fixo por função. Previne sequestro de objetos.
Extensões apenas da lista de permissões. Sem CREATE EXTENSION não confiável em produção.
Tabelas PII com colunas minimizadas. Analistas recebem visualizações sem campos sensíveis.
Injeção SQL prevenida apenas por meio de consultas parametrizadas. Nenhuma concatenação de strings em "escape hatches" de ORM.

D - Auditoria e Conformidade

Conexão e desconexão registradas. Retenção centralizada de no mínimo 90 dias.
DDL registrado (log_statement = ddl ou pgaudit). A derivação de esquema é relevante para a segurança.
pgaudit ou equivalente em dados regulamentados. Escopo ajustado para evitar inundações de logs.
Simulação forense trimestral. "Quem leu a tabela X no mês passado?" respondido com evidências.
Criptografia em repouso verificada no código de infraestrutura. RDS criado criptografado; snapshots com suporte a KMS.

E - Operações

Patches aplicados dentro do SLA do fornecedor. Existe um runbook de resposta a CVE.
Backups criptografados e restauração testada. Dump roubado é inútil sem chaves.
Segredos não em git ou camadas de contêiner. Segredos K8s/SSM com rotação.
Credenciais de staging não podem alcançar produção. Clusters e limites IAM separados.
Runbook de incidentes inclui etapas de revogação de credenciais. Pré-escrito, não inventado durante SEV.

FAQs

Segurança mínima viável para startup?

Rede privada, TLS, SCRAM, função de aplicativo sem superusuário, instância gerenciada criptografada, registro de conexão.

Como eu imponho em CI?

Verificações de política do Terraform para StorageEncrypted, sqlfluff em migrações, sem URLs de produção em manifestos de staging.

O trabalho do grupo de segurança está feito?

Não. DBAs ainda possuem funções, extensões e auditoria. O perímetro da nuvem é necessário, mas não suficiente.

Réplica de leitura compartilhada para BI?

Função somente leitura; caminho de rede com as mesmas regras TLS; filtros de linha via visualizações ou RLS.

Quando o superusuário é aceitável?

Instalação de extensão, recuperação principal, "break-glass". Nunca em variáveis de ambiente de implantação de aplicativos.

A ordem do pg_hba importa?

Sim. A primeira linha correspondente vence. Coloque reject/hostssl específicos antes de regras amplas.

Segurança vs. desempenho?

TLS e SCRAM são baratos. pgaudit amplo de read é caro - escopo-lo.

Sidecar de contêiner para credenciais?

Preferível a incorporar DSN na imagem. Rotacione reiniciando a implantação com uma nova versão do segredo.

Mapeamento de conformidade?

Mapeie cada caixa de seleção para o ID de controle na matriz SOC2/HIPAA; armazene capturas de tela de evidências na ferramenta GRC.

Por onde começar após uma violação?

Rotacione todas as funções que tocaram nos dados afetados, preserve os logs, habilite pgaudit expandido e, em seguida, determine a causa raiz.

Relacionados

Noções Básicas de Segurança - modelo de ameaças
Configuração SSL/TLS - configuração TLS
Autenticação SCRAM - autenticação de senha
pgaudit e Registro de Conformidade - escopo de auditoria
Criptografia em Repouso - criptografia de disco

Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.

Melhores Práticas de Segurança

Buscar na documentação

Melhores Práticas de Segurança