---
格式版本: 2
标题: "Securing PostgreSQL on OCI: A Defense-in-Depth Approach | cloud-infrastructure"
原文链接: "https://blogs.oracle.com/cloud-infrastructure/securing-postgresql-on-oci-a-defense-in-depth-approach"
发布日期: "2026-09-03"
发布时间校准状态: "found"
发布时间需复核: "否"
发布时间来源: "rule:configured_publication_date_rule"
发布时间证据: "doc-fixed-49fb23095330-publication-date html:original: September 3, 2026"
发布时间校准原因: "信源发布日期识别规则直接确认发布时间"
发布时间校准置信度: "high"
发布时间候选数量: 1
发布时间严格候选数量: 1
发布时间原页读取状态: "source template page reused from URL open"
发布时间未找到原因: ""
发布时间校准时间: "2026-09-06T09:32:14+08:00"
发布时间仲裁状态: "skipped"
发布时间仲裁尝试次数: 0
发布时间仲裁耗时毫秒: 0
发现时间: "2026-09-06T09:31:30+08:00"
入库时间: "2026-09-06T01:32:15.328Z"
来源平台: "固定入口"
搜索渠道: "fixed_url"
搜索词: "https://blogs.oracle.com/?page=news"
匹配关键词:
  - "deployment"
  - "performance"
相关厂家:
  - "Oracle"
相关专家:
  []
内容类型: "网页"
抓取工具: "CDP Render"
清洗工具: "CDP Text + Defuddle/Readability 正文提取"
原始附件:
  []
AI优质: "否"
AI打分: 8
AI分档: "非优质"
AI质检状态: "不通过"
AI打分理由: "内容为Oracle云数据库PostgreSQL安全功能介绍，与超节点、AI Rack、机柜级AI基础设施等主题完全无关，无相关技术或商业信号。"
AI质检模型: "zj-deepseek-v4-flash"
AI质检时间: "2026-09-06T09:32:46+08:00"
AI主题相关性: 0
AI来源权威性: 8
AI新颖性: 0
AI技术细节: 0
AI商业部署信号: 0
AI完整性: 0
AI摘要: "Oracle OCI 的托管 PostgreSQL 服务采用纵深防御模型，通过私有端点、强制 SSL/TLS、OCI IAM、Vault 密钥管理、Kerberos 认证、数据脱敏、pgAudit 审计、集中日志。"
AI摘要模型: "ali-deepseek-v4-flash"
AI摘要时间: "2026-09-06T23:45:01.260Z"
采集批次: "2026年9月6日9点29分24秒"
采集批次ID: "20260906-092924-951"
去重键: "https://blogs.oracle.com/cloud-infrastructure/securing-postgresql-on-oci-a-defense-in-depth-approach"
---

### Discover how OCI Fully Managed PostgreSQL Service combines multiple layers of security to help protect your PostgreSQL workloads.

As PostgreSQL continues to gain popularity across the open-source ecosystem, organizations are increasingly adopting it for business-critical and enterprise workloads. With this growing adoption, security has become just as important as performance, scalability, and availability. Organizations also need a comprehensive security approach that protects their data, controls access, secures connectivity, and provides visibility across the database lifecycle.

**[OCI Database with PostgreSQL](https://docs.oracle.com/en-us/iaas/Content/postgresql/home.htm)** brings together the flexibility and innovation of PostgreSQL with OCI’s layered security capabilities, helping organizations run PostgreSQL workloads with confidence while meeting the security demands of modern cloud applications.

OCI Managed PostgreSQL Security Features

---

### Private Database Endpoints

OCI Database with PostgreSQL uses private endpoints within an OCI Virtual Cloud Network (VCN). The database endpoint isn’t directly exposed to the public internet.

Clients therefore need network connectivity to the VCN containing the PostgreSQL database system. Access can be further constrained using OCI network controls associated with the VCN and subnet. For administrative access to resources on a private network, OCI Bastion can provide a controlled path without requiring the PostgreSQL database itself to have a public endpoint.

### TLS-Protected PostgreSQL Connections

OCI Database with PostgreSQL requires SSL/TLS for PostgreSQL client connections. SSL connectivity is mandatory to ensure that all in-transit connections are encrypted, in accordance with OCI’s compliance standards.

PostgreSQL clients connect using `hostssl` connection type in the `pg_hba.conf` file to ensure encrypted TCP/IP connections, with the `sslmode` must be set to `require` or stronger (`verify-ca` or `verify-full`).

Applications that need certificate validation can use PostgreSQL’s stronger verification modes:

- `sslmode=require` encrypts the connection.
- `sslmode=verify-ca` encrypts the connection and verifies that the server certificate chains to a trusted certificate authority.
- `sslmode=verify-full` adds server identity verification for production applications.

TLS protocol behavior can also be controlled through PostgreSQL [TLS configuration](https://docs.oracle.com/en-us/iaas/Content/postgresql/tls-version.htm) parameters supported by the service.

### OCI IAM Controls Management Access

OCI IAM governs who can administer OCI Database with PostgreSQL resources, which is is distinct from PostgreSQL database authorization.

IAM policies can grant permissions for resources such as PostgreSQL database systems, configurations, and backups. OCI’s standard authorization model allows privileges to be scoped by resource type, operation, group, and compartment.

This enables separation of responsibilities. For example, an organization can allow a platform engineering group to manage PostgreSQL systems in a development compartment while restricting production administration to a smaller operations group.

### Database Credentials in OCI Vault

The PostgreSQL administrator password can be managed through OCI Vault Secrets.

During database-system provisioning, the administrator credential is supplied through a Vault secret rather than treating the password as ordinary infrastructure configuration. This allows database credentials to be handled through OCI’s secret-management mechanisms and reduces the need to place plaintext database passwords in deployment scripts or infrastructure-as-code configuration.

Access to the secret itself can then be governed separately using OCI IAM policies.

### PostgreSQL Authentication and Authorization

After network and OCI-level authorization controls have been satisfied, PostgreSQL provides its normal database security boundary.

PostgreSQL roles and privileges determine which database objects and operations an authenticated user can access. OCI Database with PostgreSQL also supports [Kerberos authentication](https://docs.oracle.com/en-us/iaas/Content/postgresql/kerberos.htm), enabling environments using Kerberos-based identity infrastructure to integrate that authentication model with PostgreSQL.

Integrating Kerberos with OCI Database with PostgreSQL enables you to leverage centralized credential management, strengthen security, and reduce the risks associated with password-based authentication.

### PostgreSQL Anonymization and Data Masking

OCI Database with PostgreSQL supports [PostgreSQL Anonymizer extension](https://postgresql-anonymizer.readthedocs.io/en/stable/) for masking sensitive data by replacing or obscuring its original values while keeping the data usable for legitimate purposes.

For a PostgreSQL database, data masking helps protect sensitive data by limiting exposure of confidential information while preserving data usability for development, testing, analytics and other authorized use case.

This helps organization protect sensitive information, support privacy and compliance objectives under frameworks such as GDPR, HIPPA, CCPA/CPRA, and PCI DSS. PCI DSS additionally contains explicit requirements for masking PAN when displayed in applicable circumstances.

### PostgreSQL Auditing with pgAudit

OCI Database with PostgreSQL supports the pgAudit PostgreSQL extension for detailed database audit logging.

pgAudit can record database activity at a level useful for security investigation and compliance workflows. Depending on the configured audit classes, this can provide visibility into categories of PostgreSQL operations beyond ordinary infrastructure events.

PostgreSQL logs and audit output can then be integrated with OCI logging capabilities for centralized collection and analysis. The distinction is important:

- OCI audit and service events help answer what happened to the OCI resource.
- pgAudit logshelp answer what happened inside the database.

A mature database-security architecture typically needs both.

### Centralized PostgreSQL Logging

OCI Database with PostgreSQL integrates with [OCI Logging service](https://docs.oracle.com/en-us/iaas/Content/Logging/Concepts/loggingoverview.htm).

PostgreSQL service logs can provide database-level operational information such as connections, errors, statements, and other events according to the PostgreSQL logging configuration.

Logs can therefore be incorporated into broader OCI operational and security-monitoring workflows rather than requiring administrators to treat the database as an isolated system.

Database logs can also be exported to OCI Object Storage when longer-term storage or downstream processing is required.

### Monitoring and Operational Detection

OCI Database with PostgreSQL publishes metrics to [OCI Monitoring](https://docs.oracle.com/en-us/iaas/Content/postgresql/metrics.htm).

Metrics can be used to observe database conditions such as resource utilization, query behavior, storage consumption, and replication health. OCI alarms can then evaluate those metrics and trigger notifications when configured thresholds are reached.

Monitoring is not a substitute for database auditing, but it provides another security-relevant signal. Unexpected connection patterns, resource exhaustion, abnormal query behavior, or replication problems may all warrant operational investigation.

### Backup and Recovery Controls

Security also includes the ability to recover from accidental deletion, application errors, operational failures, or other data-loss scenarios. OCI Database with PostgreSQL provides automated and manual backups.

Automated backups can be configured with a retention period, while manual backups provide an additional mechanism for retaining recovery points. Backup resources also have OCI IAM permissions, allowing access to backup operations to be controlled independently.

Backup copies can additionally support [cross-region recovery](https://docs.oracle.com/en-us/iaas/Content/postgresql/copy-backup.htm) strategies where appropriate.

A useful security principle is to treat backup administration as a privileged operation rather than simply an operational convenience.

---

## Conclusion

OCI Database with PostgreSQL applies a defense-in-depth security model, combining controls across the network, transport, identity, database, credential, auditing, monitoring, and recovery layers.

Together, these independent security layers allow organizations to apply least privilege and separation of duties across infrastructure, database, application, and security teams while protecting PostgreSQL workloads throughout their lifecycle.
