Secure your Oracle Cloud surface
Compartment policies granting manage on all-resources, public buckets, and unrotated API signing keys. We don’t connect to Oracle Cloud to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Oracle Cloud goes wrong
Oracle Cloud goes wrong through policy language: a statement granting manage all-resources reads innocuously and grants almost everything.
- Policies granting manage all-resources at tenancy or compartment scope
- Object Storage buckets with public visibility enabled
- Security lists and NSGs permitting 0.0.0.0/0 to management ports
- API signing keys issued to users and never rotated
- Audit retention configured below your own evidence requirement
[02] What We Secure
What we watch, catch and fix on Oracle Cloud
On Oracle Cloud we parse policy statements into effective permissions, so what a policy actually grants is visible rather than inferred from its wording.
- Policy statements parsed to show effective permissions rather than intent
- Compartment structure reviewed as a blast-radius boundary, which is what it actually is
- Public bucket detection tied to data classification
- Signing key age and ownership tracked per user
- Audit configuration monitored as a control, not assumed
[03] Where It Lands
Where Oracle Cloud lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On Oracle Cloud specifically
On Oracle Cloud, we correct bucket visibility and network rules, and drive key rotation. Compartment and policy restructuring we scope and project-manage, since it reshapes access for everyone.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Oracle Cloud FAQs
What OCI access does Konfirmity need?
Konfirmity needs we use a dedicated user in a scoped group with read-only policies at tenancy level, authenticated by an API signing key we rotate on a schedule. Read access is sufficient for inventory, policy analysis and audit review. Remediation is granted separately per action.
How do you treat compartments?
As blast-radius boundaries, which is what they actually are. Konfirmity maps your compartment structure and reports where a policy crosses it, because a compartment that everyone can manage provides isolation on the org chart and none in practice.
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Kubernetes
Terraform