Common OCI Security Misconfigurations

Most security incidents on any cloud are not the result of a clever attack against a well built estate. They are the result of a misconfiguration that quietly opened a door and stayed open. A bucket set to public when it should have been private, a policy that granted far more than the workload needed, a database reachable from the internet because a test rule was never removed. None of these require sophistication to exploit. They require only that someone looks, and on the public internet someone always eventually looks. This guide walks through the misconfigurations we see most often on OCI estates, why each one happens, and the deliberate practice that prevents it.

The reason these mistakes are worth cataloguing is that they are predictable. The same handful of categories account for the large majority of real exposure, year after year, across organisations of every size. If you know the list and check against it deliberately, you remove most of your risk before an attacker ever arrives. That is the whole argument for posture management, covered in our posture management guide, and it starts with knowing what to look for.

Overly permissive IAM policies

The single most common and most damaging category is identity. Policies that grant manage all resources to a broad group, administrator access handed out for convenience and never revoked, service accounts with far more reach than the task in front of them needs. Each of these turns a single compromised credential into a path across the whole tenancy. The fix is least privilege applied consistently, the discipline covered in our IAM policies guide, where every policy grants the narrowest set of verbs on the narrowest set of resources that the workload genuinely requires. The reason this misconfiguration is so common is that broad grants are the path of least resistance under time pressure, and nobody ever comes back to tighten them once the workload is running.

Public exposure that was never intended

The second category is network exposure. Object storage buckets set to public visibility, databases with public endpoints, compute instances with open security rules that should have been scoped. These happen because public is sometimes the quickest way to make something work during development, and the temporary state becomes permanent. The defence is twofold. First, scope network access tightly using the model in our NSGs versus security lists guide, so nothing is reachable that does not need to be. Second, enforce a baseline through a security zone, covered in our security zones guide, so that the platform itself refuses to create a public database in a compartment that is supposed to be private.

The misconfigurations we see most

Detection and logging gaps

A subtler but serious category is the absence of the things that would tell you something went wrong. Cloud Guard not running across the relevant compartments, audit logging disabled or retained for too short a period, no alerting on the events that matter. These gaps do not open a door by themselves, but they mean that when a door does open you have no way to know. Our Cloud Guard guide and our audit logging guide cover how to close them. The point is that detection is not optional infrastructure you add later. It is the difference between an incident you contain in an hour and one you discover months after the fact.

Data protection assumptions

The final common category is assuming data protection is handled when it was never actually decided. Encryption is on by default on OCI, which is good, but whether you manage your own keys is a decision that is often left at the default without anyone making it. Sensitive data stores left reachable from broad networks. Backups configured but never tested. Our data encryption guide covers the deliberate version. The recurring theme across every category in this guide is the same. The misconfiguration is rarely a mistake of action. It is a mistake of omission, a decision nobody made, a check nobody ran.

Preventing the predictable

Because these misconfigurations are predictable, they are also preventable in a systematic way. The work is to scan for them continuously rather than rely on anyone remembering, and to enforce the safe state through guardrails so the unsafe state cannot be created in the first place. That is exactly the posture management discipline in our posture management guide, and it ties back to the full model in our complete security guide. We run this kind of review and remediation for clients through our OCI security service, and the common thread is always the same. The dangerous configuration is the one nobody is looking at.

Why misconfigurations cluster

It is worth understanding why the same handful of categories recur, because the reason points to the fix. Misconfigurations are not random. They cluster around the moments when speed beats care, when a workload is being stood up under deadline, when a problem needs solving right now, when a temporary state is created with every intention of tightening it later and then nobody does. The broad policy, the public bucket, the open rule, all of them are the fast path under pressure, and the fast path becomes permanent because revisiting working infrastructure is nobody's priority once it works. This means the cure is structural rather than personal. You do not fix it by asking people to be more careful. You fix it by making the unsafe state hard to create and the drift easy to detect.

This is also why a one time clean up never holds. You can sweep an estate today and remove every broad grant and every public bucket, and within months new ones will have appeared, created by the same pressures that created the originals. The only durable answer is continuous, the posture management approach in our posture management guide, where scanning runs constantly and guardrails through security zones refuse the unsafe configuration at creation time. The mistake is treating misconfiguration as an event to be remediated rather than a tendency to be managed.

Catching drift over time

An estate that is secure at go live does not stay secure on its own. Every change carries the possibility of introducing a new gap, and over months and years those small changes accumulate into drift away from the baseline you started with. Catching drift is the ongoing half of the job, and it depends on the visibility that Cloud Guard and audit logging provide. The pattern that works is to establish a known good baseline, enforce as much of it as possible through guardrails, and continuously detect and review the rest, so that drift is surfaced and corrected before it becomes exposure. An estate without this is secure only by luck, and luck is not a security control.