Skip to main content

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 attempts

Risk Level

High

Address

Compliance, Security

Compliance 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

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.

1. Identify the affected Autonomous Database

  1. Sign in to the OCI Console.
  2. In the top-left menu, go to Observability & Management → Cloud Guard (if you are using Cloud Guard for monitoring).
  3. Go to Cloud Guard → Problems.
  4. Filter by:
    • Resource Type: Autonomous Database
    • Or Detector Rule / Problem Type that mentions “Network Autonomous Database Should Have ACL Restrictions”.
  5. Note the Compartment, Region, and Database name of each affected instance.
(If you are not using Cloud Guard, go directly to the Autonomous Database list in step 2 below and check your publicly accessible ADBs manually.)

2. Open the Autonomous Database configuration

  1. In the top-left menu, go to Oracle Database → Autonomous Database.
  2. Select the Region and Compartment you noted.
  3. Click the name of the affected Autonomous Database.

3. Ensure the DB is not wide-open to the public

  1. 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.
  2. Click More Actions → Edit (or Edit button depending on UI layout).
  3. 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.
(Exact labels can differ slightly by region / console version, but you’re looking for options to restrict access and configure an IP ACL.)

4. Configure the Access Control List (ACL)

  1. In the IP Access Control List (ACL) section:
    • Click Add IP Address / CIDR.
  2. 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).
  3. Avoid broad ranges like 0.0.0.0/0 or /0 CIDRs (they defeat the purpose of ACLs).
  4. Remove any existing entries that are too broad (e.g., 0.0.0.0/0).
  5. Click Save Changes / Update.

5. If using Private Endpoint – restrict at the VCN level

If your Autonomous Database is configured with a Private Endpoint:
  1. Note the VCN and subnet used for the private endpoint on the DB details page.
  2. Go to Networking → Virtual Cloud Networks → select the VCN → Subnets → choose the subnet.
  3. 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.
This provides an additional network-layer restriction alongside the DB ACL.

6. Verify remediation and monitoring

  1. 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.
  2. 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.
Below is how to enforce ACL restrictions on an OCI Autonomous Database (Network/Monitoring rule) using the OCI CLI.Assumptions:
  • You already have oci configured with correct tenancy/region.
  • The Autonomous Database currently has a public endpoint without ACL (open).

1. Identify the Autonomous Database

Note: In the output, confirm:
  • "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>
Create a JSON array of the CIDRs, for example:

3. Enable ACL and Set Whitelisted IPs (CLI)

Run an update on the Autonomous Database:
If your CLI version uses --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

You should see:

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.
If you want to script this remediation (e.g., for all non-compliant DBs in a compartment), loop over the 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.
To remediate “OCI Network Autonomous Database should have ACL restrictions” using Python, you need to:
  1. Identify Autonomous Databases with public access but no ACLs.
  2. Enable ACLs (access control) and apply an approved IP list via the OCI Python SDK.
  3. (Optional) Run this regularly as a monitoring/remediation job.
Below is a concise, end‑to‑end approach.

1. Prerequisites

  1. Install SDK:
  2. Config file (~/.oci/config) with at least:
  3. IAM Policy for your user/group:

2. Logic to Detect Misconfigured Autonomous Databases

Criteria (typical):
  • is_data_guard_enabled irrelevant; focus on:
  • is_access_control_enabled == False OR is_access_control_enabled == True but whitelisted_ips is empty.
  • And the DB has public endpoint: private_endpoint == None.
You can tune this logic as needed.

3. Python Script: Monitor and Remediate

Adjust:
  • COMPARTMENT_OCID
  • ALLOWED_IPS to 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:
  1. Go to Autonomous Database in OCI Console.
  2. Open the target DB → Network Access.
  3. Ensure it uses public endpoint only if needed.
  4. Enable Access Control List.
  5. Add allowed CIDR blocks / IPs.
  6. Save changes.
Let me know your exact environment (Compartments, regions, desired IP policy) if you want the script adjusted to be safer (e.g., only log misconfigurations, dry‑run mode, per‑tag filtering).
Substitute:
  • OCID_OF_COMPARTMENT with the compartment OCID of the Autonomous Database.
  • ADB_NAME with your database name.
  • ALLOWED_CIDR_1 / ALLOWED_CIDR_2 with 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_2 with your actual subnet and NSG OCIDs.
Changing 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.