Fortova lockupFortovaORACLE CLOUD SECURITY

Practice

How we secure an Oracle estate.

Oracle Cloud security isn't a list of settings. It is an identity model, a governance and controls framework, a tenancy architecture, an integration standard and a set of AI guardrails that have to agree with each other. We design them together, put them in place with your team, and prove the result.

What we secure

Five areas, designed as one.

Each area is a service in its own right, and each depends on the others: an agent needs an identity, an integration needs a control, and a control needs evidence.

The seven phases

In order, every time.

The phases say what gets delivered and in what sequence. Each one puts controls in place, and each one leaves something your team keeps and runs.

  1. Phase 0

    Intake and documentation review

    We read your existing documentation from the outside. We do not assess your infrastructure-as-code as if it were the tenancy: code states intent, and drift between intent and reality is where findings live. We assess what is running.

  2. Phase 1

    Current-state capture

    A diagram of the tenancy as it is: compartment structure, networking, identity domains, integration topology. It becomes the shared picture for every later conversation and the anchor diagram for everything that follows. We seed it from your intended design and mark every area to verify; verification turns drawing into correction.

  3. Phase 2

    Baseline and posture

    The CIS OCI Foundations Benchmark script is run against the tenancy and the report kept as the "before". Cloud Guard is enabled and its findings are worked to resolution. After remediation the benchmark runs again. The before-and-after pair is the proof of value.

  4. Phase 3

    Identity, access and governance

    Fusion and OCI IAM configuration is reviewed and designed together: SSO on the default identity domain with SAML for user authentication, a breakglass account on the published Oracle pattern, IAM policies brought to the CIS standard, SoD-based administrator groups, group-membership-based access, least privilege throughout. In Fusion, roles are designed by persona, segregation-of-duties and sensitive-access rules are defined, and Risk Management and Compliance is set up to watch them continuously.

  5. Phase 4

    Integration, extension and AI security

    Every PaaS integration is inventoried: Oracle Integration Cloud, Visual Builder, functions and APIs. OAuth is enforced as the standard; Basic authentication survives only with a documented review and exception sign-off. Fusion integrations run on confidential OAuth clients, one client per connection. AI Agent Studio agents and external model calls are inventoried the same way and held to the same standard: an owned identity, least-privilege tool access, data controls and logging.

  6. Phase 5

    Monitoring, logging and SIEM

    Logs leave the tenancy through the Kafka-compatible streaming endpoint and Connector Hub into your SIEM, whichever consumer you run. Alarms and notifications are set for critical events, such as an identity-domain administrator role assigned directly to a user.

  7. Phase 6

    Supplier Portal and external access

    External users are set up on the current Oracle pattern: employees federate through the corporate identity provider, suppliers sign in directly with native MFA on OCI IAM, and no separate external identity domain is created. The domain that is never built is a license and a running cost you never carry.

What you keep

Documented as it's built.

Everything we design is written down as it goes into your environment, so your team can run it and an auditor can check it. No binder arrives at the end: working artifacts are shared early, tested against your estate and kept current.

  • Current-state tenancy diagram
  • CIS benchmark reports, before and after
  • Cloud Guard posture and resolutions
  • Identity, SSO and breakglass design
  • IAM policy set to the standard
  • Integration inventory and authentication standard
  • SIEM and logging architecture
  • Alarm and notification baseline
  • Supplier Portal pattern
  • Fusion role, segregation-of-duties and RMC design
  • AI governance policy and agent inventory
  • Numbered findings register, F-01 onward

Operating rules

How the work moves.

The phases are the product. So is the way they are delivered.

Nothing claimed that isn't verified

Every recommendation is checked against Oracle's documentation before it reaches you, or turned into a named test. "We will confirm this in testing" is diligence, not uncertainty.

Answers you can keep

A question gets a matrix, a runbook or a one-page answer, not a long email thread. Your team ends up with reference material instead of reply-all noise.

Your administrators run the tooling

Read-only scans run in your tenancy, by your people, from the published source. We never ask for elevated access to run a benchmark. A practice that recommends least privilege should not want it.

Findings tracked from day one

Findings are numbered from the first issue we see, before any scan completes. Every pain point your team already has is a candidate finding and a line in the findings register.

Decisions made together

Recommendations are shared ahead of time and decided in a working session, with an owner for every follow-up. Sensitive topics get their own conversation.

Clear weekly status

What was completed and what comes next, itemized by workstream, every week. Progress is visible as it happens, not saved up for a big reveal.

Start with an architecture review.

The first phases as a focused engagement: the estate as it runs, the baseline, prioritized findings and a roadmap for the rest.

Start with an architecture reviewTalk to us