More Info:
Autonomous Database instances should have network access restrictions such as ACL whitelists or Network Security Groups. Unrestricted public access exposes the database to unauthorized connection attemptsRisk Level
HighAddress
Compliance, SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- HIPAA
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- Reserve Bank of India (RBI) Cyber Security Framework
- Reserve Bank of India (RBI) Master Direction – Information Technology Framework
- SOC2
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Using Console
Using Console
Below are console-based steps to remediate the “OCI Network Autonomous Database Should Have ACL Restrictions” issue by configuring Access Control Lists (ACLs) on your Autonomous Database so it’s not open to the internet.
If you share whether the DB is using a public endpoint or private endpoint and which client types connect (apps in OCI, on-prem, internet users, etc.), I can give you a precise example ACL and matching VCN/NSG rules.
1. Identify the affected Autonomous Database
- Sign in to the OCI Console.
- In the top-left menu, go to Observability & Management → Cloud Guard (if you are using Cloud Guard for monitoring).
- Go to Cloud Guard → Problems.
- Filter by:
- Resource Type:
Autonomous Database - Or Detector Rule / Problem Type that mentions “Network Autonomous Database Should Have ACL Restrictions”.
- Resource Type:
- Note the Compartment, Region, and Database name of each affected instance.
2. Open the Autonomous Database configuration
- In the top-left menu, go to Oracle Database → Autonomous Database.
- Select the Region and Compartment you noted.
- Click the name of the affected Autonomous Database.
3. Ensure the DB is not wide-open to the public
- On the DB details page, look at:
- Network Access or Access Type:
- If you see “Allow secure access from everywhere” or similar, that’s effectively open.
- Network Access or Access Type:
- Click More Actions → Edit (or Edit button depending on UI layout).
- Under Network Access:
- Prefer Private Endpoint access only (inside a VCN) OR
- If using public endpoint, enforce ACLs:
- Select “Restricted access”, “IP Access Control List (ACL)”, or equivalent wording.
4. Configure the Access Control List (ACL)
- In the IP Access Control List (ACL) section:
- Click Add IP Address / CIDR.
- Add only the trusted network sources:
- Specific public IPs of:
- Your corporate office egress IP.
- Your VPN / bastion host.
- Specific application servers.
- Or narrow CIDR blocks (e.g.,
203.0.113.10/32,198.51.100.0/24).
- Specific public IPs of:
- Avoid broad ranges like
0.0.0.0/0or/0CIDRs (they defeat the purpose of ACLs). - Remove any existing entries that are too broad (e.g.,
0.0.0.0/0). - Click Save Changes / Update.
5. If using Private Endpoint – restrict at the VCN level
If your Autonomous Database is configured with a Private Endpoint:- Note the VCN and subnet used for the private endpoint on the DB details page.
- Go to Networking → Virtual Cloud Networks → select the VCN → Subnets → choose the subnet.
- Check Security Lists or Network Security Groups (NSGs):
- Ensure ingress rules allow DB ports (usually 1522) only from:
- Required application subnets.
- Required on-prem networks over VPN / FastConnect.
- Remove any rules with source = 0.0.0.0/0 for the DB port.
- Ensure ingress rules allow DB ports (usually 1522) only from:
6. Verify remediation and monitoring
- From Cloud Guard → Problems, recheck the problem after the next evaluation cycle:
- The “Network Autonomous Database Should Have ACL Restrictions” problem should move to Resolved once ACLs are in place.
- Optionally, test connectivity:
- From an allowed IP or VCN: confirm you can connect to the Autonomous Database.
- From a non-allowed IP (e.g., local machine not in ACL): confirm connection is denied.
If you share whether the DB is using a public endpoint or private endpoint and which client types connect (apps in OCI, on-prem, internet users, etc.), I can give you a precise example ACL and matching VCN/NSG rules.
Using CLI
Using CLI
Below is how to enforce ACL restrictions on an OCI Autonomous Database (Network/Monitoring rule) using the OCI CLI.Assumptions:
Note: In the output, confirm:
If your CLI version uses
If you get a validation error, you may need to provide it inline as JSON:
You should see:
If you share your current
- You already have
ociconfigured with correct tenancy/region. - The Autonomous Database currently has a public endpoint without ACL (open).
1. Identify the Autonomous Database
"isPublic": true"isAccessControlEnabled": false(or no/empty"whitelistedIps")
2. Decide the ACL (authorized IPs / CIDRs)
Determine which IPs/networks are allowed to access the DB, e.g.:- Single IP:
203.0.113.10/32 - Office network:
198.51.100.0/24 - VPN:
<your_vpn_cidr>
3. Enable ACL and Set Whitelisted IPs (CLI)
Run an update on the Autonomous Database:--whitelisted-ips directly (most current versions do), the above is correct.If you get a validation error, you may need to provide it inline as JSON:
4. Verify the Configuration
5. (Optional) Integrate with OCI Cloud Guard / Monitoring
If this misconfiguration is flagged by Cloud Guard:- After applying the ACL, re-run the Cloud Guard detector or wait for the next evaluation cycle.
- Confirm the “Network Autonomous Database Should Have ACL Restrictions” finding is cleared.
list output and run the update command on each.If you share your current
oci db autonomous-database get output (redacted), I can tailor the exact CLI flags/JSON for your environment.Using Python
Using Python
To remediate “OCI Network Autonomous Database should have ACL restrictions” using Python, you need to:
- Identify Autonomous Databases with public access but no ACLs.
- Enable ACLs (access control) and apply an approved IP list via the OCI Python SDK.
- (Optional) Run this regularly as a monitoring/remediation job.
1. Prerequisites
-
Install SDK:
-
Config file (
~/.oci/config) with at least: -
IAM Policy for your user/group:
2. Logic to Detect Misconfigured Autonomous Databases
Criteria (typical):is_data_guard_enabledirrelevant; focus on:is_access_control_enabled == FalseORis_access_control_enabled == Truebutwhitelisted_ipsis empty.- And the DB has public endpoint:
private_endpoint == None.
3. Python Script: Monitor and Remediate
Adjust:COMPARTMENT_OCIDALLOWED_IPSto your approved CIDR/IP list.
4. How This Fits “Networking Monitoring”
- Run this script:
- As a scheduled job (e.g., OCI Functions + Events, or cron on a bastion) to continuously monitor and enforce ACLs.
- Or integrate with your Cloud Guard findings: trigger this script when a “ADB without ACL” detector fires.
- Logging output to a central place (Object Storage, Logging service) lets you monitor which ADBs were remediated.
5. Summary of Manual Remediation Steps (Console)
If you need the equivalent manual steps:- Go to Autonomous Database in OCI Console.
- Open the target DB → Network Access.
- Ensure it uses public endpoint only if needed.
- Enable Access Control List.
- Add allowed CIDR blocks / IPs.
- Save changes.
Using Terraform
Using Terraform
OCID_OF_COMPARTMENTwith the compartment OCID of the Autonomous Database.ADB_NAMEwith your database name.ALLOWED_CIDR_1/ALLOWED_CIDR_2with the specific IPs/CIDRs that should be allowed.- (If using the commented network bits)
OCID_OF_SUBNET_FOR_PRIVATE_ENDPOINT,OCID_OF_NSG_1,OCID_OF_NSG_2with your actual subnet and NSG OCIDs.
whitelisted_ips to introduce ACL restrictions is an in-place update and should not force replacement of the Autonomous Database instance; switching from public to private endpoints or changing subnet_id may require replacement and should be planned carefully.For verification, terraform plan should show an update to the existing oci_database_autonomous_database resource with whitelisted_ips changing from its prior value (likely [] or null) to the new restricted list, and no destroy/create cycle for that resource unless you also change endpoint/subnet settings.
