AI is expanding what businesses can build and automate, while helping attackers discover and exploit weaknesses faster.
To help customers strengthen their cloud environments, Oracle is releasing 18 new Cloud Guard detectors. These checks identify exposed databases, unnecessary access paths, weak connections and missing recovery protections. Correcting these findings reduces opportunities for data theft and improves recovery from destructive attacks.

Protect the complete path

Protecting data takes more than securing the login to the database. A database also needs restricted network access and enhanced data security measures. Its connections need strong encryption, its credentials and sharing links need a clear purpose, and backups are always needed. 

Use these findings to restrict database access to the networks and applications that need it. The outcome is fewer opportunities to use stolen credentials directly from outside your environment.

Cloud Guard detectors:

Autonomous Database without a private endpoint 

Flags Autonomous Databases without private endpoints. Configure private connectivity and test DNS and client access before removing the old path. A missing private endpoint alone does not prove public exposure. 

Publicly accessible Autonomous Database 

Flags public exposure. Restrict permitted sources or use a private endpoint to limit connection attempts, including those using stolen credentials. Verify access settings; this finding does not prove data theft. 

Publicly accessible MySQL DB System 

Flags public-subnet, internet-gateway and permissive network settings. Verify actual reachability and restrict access to approved application sources. A public subnet alone does not prove a reachable public endpoint. 

Make database recovery an explicit setting

Access controls cannot prevent every destructive mistake or compromised administrator. Three detectors check MySQL deletion protection and automatic backups for MySQL and PostgreSQL.

Enable deletion protection to guard against removing a DB System. Enable backups, confirm they succeed and test restoration. The benefit is a recovery option when data is lost or damaged, rather than discovering during an outage that no usable backup exists. These checks do not establish backup immutability or replace restore testing.

Cloud Guard detectors:

MySQL deletion protection turned off 

Flags MySQL DB Systems without deletion protection. Enable it to guard against system deletion. It does not prevent destructive SQL or replace backups; review access controls; to change protection settings. 

MySQL automatic backups turned off 

Flags MySQL systems without automatic backups. Enable a schedule and retention period, verify successful backups and test restoration. Enabled backups alone do not establish immutability or recovery readiness. 

PostgreSQL automatic backups turned off 

Flags PostgreSQL systems without automatic backups.

Strengthen connections and narrow network access

Four load balancer detectors check weak TLS protocols and prohibited predefined cipher suites on both listener and backend connections. Addressing them strengthens the connections your applications need, including the often-overlooked connection behind the load balancer.

Two security-list detectors flag non-public ports open to all sources and unrestricted outbound destinations. Tighten these rules to reduce unnecessary access to services and limit where a compromised workload can send data. Check all applicable rules so another permissive rule does not leave the same path open.

Cloud Guard detectors:

Weak TLS on a load balancer listener 

Flags listener policies allowing protocols below TLS 1.2. Check client compatibility, then remove obsolete versions to prevent their negotiation. 

Prohibited cipher suites on a load balancer listener 

Flags prohibited predefined listener cipher suites. Review the prohibited list and select an approved stronger suite. Custom suites require separate review. 

Weak TLS on a load balancer backend 

Flags backend SSL policies allowing protocols below TLS 1.2 (or no SSL). Update the policy and test backend connectivity.

Prohibited cipher suites on a load balancer backend

Flags prohibited predefined backend cipher suites. Select an approved stronger suite and test compatibility. Review custom suites separately; the detector does not evaluate them. 

Non public ports open to all sources

Reduces your attack surface by flagging security-list access to non-public ports from all sources. Customers should restrict source CIDRs and ports to required traffic.

Outbound security list access to all destinations 

Flags unrestricted outbound destinations. Identify dependencies, then allow only required destinations and test connectivity. This limits potential data-exfiltration paths but does not assess traffic to allowed destinations. 

These six checks help you keep required connections protected and unnecessary connections closed.

Remove unnecessary ways to access data

These IAM detectors identify users able to create auth tokens, customer secret keys or database credentials. A fourth flags pre-authenticated requests (PAR) on Object Storage buckets: sharing URLs that grant access to anyone holding the link. These all help you implement the principle of least privilege.

Keep user capabilities and links only where there is a business need. Remove unnecessary existing credentials, disable unused creation capabilities and expire sharing links promptly. This reduces the access routes you must protect—and the credentials and links you may need to revoke during an incident.

These checks flag enabled credential capabilities, not issued or stolen credentials. Check integration dependencies before removing existing credentials and disabling unused capabilities; disabling creation does not revoke existing credentials. 

Cloud Guard detectors:

Users able to create auth tokens 

Flags users able to create auth tokens. Remove unused tokens and disable unneeded capability to reduce unnecessary authentication routes. 

Users able to create customer secret keys 

Flags users able to create customer secret keys, including for the Object Storage S3 Compatibility API. Retain documented integration needs; remove unnecessary keys and disable unused capability. 

Users able to create database credentials 

Flags users able to create database credentials. Confirm integration needs, remove unused credentials and disable unnecessary capability to reduce additional database access routes. 

Pre authenticated requests on Object Storage buckets 

Flags any bucket PAR, including legitimate links. Review ownership, scope and expiry; remove unnecessary requests and keep others short-lived. Anyone holding the URL gets its permitted access, even to a private bucket. 

These findings identify access that needs review; they do not prove that credentials were created or stolen.

Keep workload foundations under control

An unapproved image can bypass your hardening process while an unsupported Kubernetes version can leave a cluster outside its supported maintenance window.

The Compute image and OKE version detectors expose that drift. Rebuild from approved images and keep clusters on supported versions. You gain a more consistent, maintainable foundation for protecting application data, alongside ongoing patching and vulnerability management.

Cloud Guard detectors:

Compute resources using unsanctioned images 

You specify the compartment for sanction images and Cloud Guard flags unapproved Compute or supported OKE node-pool images. Rebuild from approved images or authorize legitimate exceptions through change control. Approval does not replace malware scanning or patching. 

OKE clusters on unsupported Kubernetes versions 

Flags OKE clusters outside the supported Kubernetes version window. Upgrade to a supported version and check API, add-on and node-pool compatibility. Control-plane upgrades alone do not update every workload. 

Put the detectors to work

We recommend that you test the available checks in one OCI Configuration Detector Recipe, confirm the target covers its resources, and assign findings to the owners who can fix them.  

Enable the baseline

Cloud Guard detectors are service-side rules, not software agents to install on each workload. A recipe is the native bundle. Use one user-managed configuration recipe so the 18 checks can be reviewed together, alongside any existing configuration checks you need to retain. Customers clone recipes; they do not create Oracle-managed recipes.

Before starting, enable Cloud Guard and its prerequisites, and confirm your administrator can read recipes, manage a user-managed recipe and mange the intended target. We recommend that you start in a staging or test environment before deploying to a production compartment.

Console Instructions

  1. Open the OCI Web Console and navigate to Cloud Guard
  2. Open Recipes.
    • Find the OCI Configuration Detector Recipe (Oracle Mange) select Clone from the Actions menu.
    • Give it a proper name (e.g. CG Data Protectors) & description, leave the Recipe compartment and Recipe fields alone (as it what you are cloning).  
    • Select the appropriate administration compartment in the Compartment drop down box and select the Clone button.
    • Click on the Recipes menu, find your newly created recipe (CG Data Protectors), and open it.
    • Open the Detector Rules tab
    • In the search bar click on Status, and select Disabled from the list to show the disabled rules.
    • Enable all the needed rules (and you can select all) by selecting the disabled rules, then click Action Enable.  (or you can do it one by one by clicking the … menu and enable)
    • You should see a confirmation screen and once ready click Enable.
  3. Now we need to apply this newly edited recipe to a target that is associated with a compartment.
  4. A compartment may only have 1 recipe assigned to it.
  5. You can either assign to an existing target (and replace its current recipe)
  6. Select the Create New Target button.
    1. Give it a name & description
    1. Pick the compartment to apply this to
    1. Select Next
    1. Select the Detection Recipe we just created (Configuration detector recipe -<Recipe Name>, e.g. Martin-BLOG)
    1. You can leave Instance Security recipe and Container security recipe blank.
    1. Select Next
    1. Review the recipe
    1. Select Create
  7. The new recipe is now defined and applied to your target compartment.
  8. Cloud Guard problems will appear within 24 hours.

Summary

We’ve described a set of 18 new Cloud Guard detectors that help protect the data in your tenancy by alerting on insecurely configured cloud resources. These create alerts if your critical resources are directly exposed to the internet, your databases are configured insecurely, that the load balancers are using weak ciphers, that users have credentials that pose risk, and if your compute instances or OKE clusters are running unsanctioned images or versions. We encourage you to deploy these new Cloud Guard detectors in your tenancy.