> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# OCI Network Autonomous Database Should Have ACL Restrictions

### 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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.
      </Accordion>

      <Accordion title="Using CLI">
        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

        ```bash theme={null}
        # Option A: List all ADBs in a compartment
        oci db autonomous-database list \
          --compartment-id <compartment_ocid> \
          --all

        # Option B: If you already know the OCID, just show it
        oci db autonomous-database get \
          --autonomous-database-id <autonomous_database_ocid>
        ```

        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:

        ```bash theme={null}
        ALLOWED_IPS='["203.0.113.10/32", "198.51.100.0/24"]'
        ```

        ***

        ## 3. Enable ACL and Set Whitelisted IPs (CLI)

        Run an update on the Autonomous Database:

        ```bash theme={null}
        oci db autonomous-database update \
          --autonomous-database-id <autonomous_database_ocid> \
          --is-access-control-enabled true \
          --whitelisted-ips "${ALLOWED_IPS}"
        ```

        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:

        ```bash theme={null}
        oci db autonomous-database update \
          --autonomous-database-id <autonomous_database_ocid> \
          --is-access-control-enabled true \
          --whitelisted-ips '["203.0.113.10/32", "198.51.100.0/24"]'
        ```

        ***

        ## 4. Verify the Configuration

        ```bash theme={null}
        oci db autonomous-database get \
          --autonomous-database-id <autonomous_database_ocid> \
          --query "data.{isAccessControlEnabled:is-access-control-enabled, whitelistedIps:whitelisted-ips}" \
          --raw-output
        ```

        You should see:

        ```json theme={null}
        {
          "isAccessControlEnabled": true,
          "whitelistedIps": [
            "203.0.113.10/32",
            "198.51.100.0/24"
          ]
        }
        ```

        ***

        ## 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.
      </Accordion>

      <Accordion title="Using Python">
        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:**
           ```bash theme={null}
           pip install oci
           ```

        2. **Config file (`~/.oci/config`)** with at least:
           ```ini theme={null}
           [DEFAULT]
           user=ocid1.user.oc1..xxxx
           fingerprint=xx:xx:xx:xx
           key_file=/path/to/oci_api_key.pem
           tenancy=ocid1.tenancy.oc1..xxxx
           region=us-ashburn-1
           ```

        3. **IAM Policy** for your user/group:
           ```text theme={null}
           allow group <group-name> to manage autonomous-database-family in tenancy
           ```

        ***

        ## 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.

        ```python theme={null}
        import oci

        # === CONFIG ===
        PROFILE = "DEFAULT"
        COMPARTMENT_OCID = "ocid1.compartment.oc1..xxxx"
        # Replace with your approved IP ranges
        ALLOWED_IPS = [
            "203.0.113.0/24",   # example range
            "198.51.100.10/32"  # example single IP
        ]

        def main():
            # Load config
            config = oci.config.from_file("~/.oci/config", PROFILE)

            # Clients
            db_client = oci.database.DatabaseClient(config)

            # List Autonomous Databases in compartment
            response = oci.pagination.list_call_get_all_results(
                db_client.list_autonomous_databases,
                compartment_id=COMPARTMENT_OCID
            )

            for adb in response.data:
                # Skip private endpoint ADBs – ACL on public endpoint is irrelevant
                if adb.private_endpoint:
                    continue

                # Check ACL status
                is_acl_enabled = getattr(adb, "is_access_control_enabled", None)
                whitelisted_ips = getattr(adb, "whitelisted_ips", None) or []

                needs_fix = (
                    is_acl_enabled is False or
                    is_acl_enabled is None or
                    len(whitelisted_ips) == 0
                )

                if not needs_fix:
                    continue

                print(f"[REMEDIATE] Autonomous DB: {adb.display_name} ({adb.id})")

                # Merge existing IPs (if any) with desired ALLOWED_IPS, avoid duplicates
                new_acl_ips = sorted(set(whitelisted_ips + ALLOWED_IPS))

                update_details = oci.database.models.UpdateAutonomousDatabaseDetails(
                    is_access_control_enabled=True,
                    whitelisted_ips=new_acl_ips
                )

                # Call update
                update_resp = db_client.update_autonomous_database(
                    autonomous_database_id=adb.id,
                    update_autonomous_database_details=update_details
                )

                print(f"  -> ACL enabled. New whitelisted IPs: {new_acl_ips}")
                print(f"  -> Work request id: {update_resp.headers.get('opc-work-request-id')}")

        if __name__ == "__main__":
            main()
        ```

        ***

        ## 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).
      </Accordion>

      <Accordion title="Using Terraform">
        ```hcl theme={null}
        resource "oci_database_autonomous_database" "example" {
          # Existing required arguments (examples – replace with your actual values)
          compartment_id = "OCID_OF_COMPARTMENT"
          db_name        = "ADB_NAME"
          cpu_core_count = 1
          data_storage_size_in_tbs = 1
          admin_password = "CHANGE_ME_Complex#123"
          db_workload    = "OLTP"

          # Network ACL restriction: only allow specific client networks to connect
          # Replace ALLOWED_CIDR_1/2 with the specific CIDR blocks or IPs that should have access.
          whitelisted_ips = [
            "ALLOWED_CIDR_1", # e.g. "203.0.113.0/24"
            "ALLOWED_CIDR_2", # e.g. "198.51.100.10/32"
          ]

          # Optional: additionally restrict using Network Security Groups on a private endpoint
          # (uncomment and set these only if your DB is using a private endpoint / subnet)
          # subnet_id = "OCID_OF_SUBNET_FOR_PRIVATE_ENDPOINT"
          # nsg_ids   = [
          #   "OCID_OF_NSG_1",
          #   "OCID_OF_NSG_2",
          # ]
        }
        ```

        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.
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>