CyberCureMe – We Secure Every Cloud with Elastyx | AI-Powered Cloud Security Posture Management

Why Oracle Cloud Security Matters#

While AWS and Azure dominate the market share conversation, Oracle Cloud Infrastructure (OCI) runs some of the most critical enterprise workloads on the planet. When your ERP, financials, HR, and supply chain all run on Oracle Fusion — a misconfiguration isn't just a security finding, it's a business-stopping event.

Yet Oracle Cloud security expertise is rare. Most cloud security teams know AWS IAM inside out but couldn't explain an OCI compartment policy to save their lives. This guide fixes that.

OCI Security Architecture#

Compartment Design

OCI's compartment model is its greatest security feature — and its most misunderstood. Think of compartments as AWS accounts within an organization, but with policy inheritance:

bash

# Create a security compartment
oci iam compartment create \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "Security" \
  --description "Security tools and audit resources"

# Create network compartment
oci iam compartment create \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "Network" \
  --description "VCNs, DRG, load balancers"

# Policy: Only network admins manage VCNs
oci iam policy create \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "NetworkAdminPolicy" \
  --statements '["Allow group NetworkAdmins to manage virtual-network-family in compartment Network", "Allow group NetworkAdmins to manage load-balancers in compartment Network"]'

# Policy: Security team reads everything, manages security tools
oci iam policy create \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "SecurityTeamPolicy" \
  --statements '["Allow group SecurityTeam to read all-resources in tenancy", "Allow group SecurityTeam to manage cloud-guard-family in compartment Security", "Allow group SecurityTeam to manage vss-family in compartment Security"]'

Cloud Guard — OCI's Native CSPM

Cloud Guard is OCI's built-in security monitoring. It uses detector recipes (what to look for) and responder recipes (what to do about it):

bash

# Enable Cloud Guard
oci cloud-guard configuration update \
  --reporting-region us-ashburn-1 \
  --status ENABLED

# List available detector recipes
oci cloud-guard detector-recipe list \
  --compartment-id ocid1.tenancy.oc1..root \
  --display-name "OCI Configuration Detector Recipe"

# Clone and customize a detector recipe
oci cloud-guard detector-recipe create \
  --compartment-id ocid1.compartment.oc1..security \
  --display-name "Custom-Security-Detector" \
  --source-detector-recipe-id ocid1.cloudguarddetectorrecipe.oc1..default \
  --detector-rules '[{
    "detectorRuleId": "BUCKET_IS_PUBLIC",
    "details": {
      "isEnabled": true,
      "riskLevel": "CRITICAL",
      "condition": {}
    }
  }]'

# Create a responder recipe (auto-remediate public buckets)
oci cloud-guard responder-recipe create \
  --compartment-id ocid1.compartment.oc1..security \
  --display-name "Auto-Remediate-Public-Resources" \
  --source-responder-recipe-id ocid1.cloudguardresponderrecipe.oc1..default \
  --responder-rules '[{
    "responderRuleId": "MAKE_BUCKET_PRIVATE",
    "details": {
      "isEnabled": true
    }
  }]'

Key Cloud Guard detectors to enable:

Detector	Risk Level	What It Catches
BUCKET_IS_PUBLIC	Critical	Public Object Storage buckets
VCN_SECURITY_LIST_ALLOWS_ALL	High	Overly permissive security lists
INSTANCE_HAS_PUBLIC_IP	Medium	Compute instances with public IPs
DB_SYSTEM_NOT_IN_PRIVATE_SUBNET	High	Databases in public subnets
USER_HAS_API_KEYS	Medium	API keys on user accounts (use instance principals instead)
MFA_NOT_ENABLED	Critical	Users without MFA

Vulnerability Scanning Service (VSS)

bash

# Create a host scan recipe
oci vulnerability-scanning host scan-recipe create \
  --compartment-id ocid1.compartment.oc1..security \
  --display-name "Weekly-Host-Scan" \
  --port-settings '{"scanLevel": "STANDARD"}' \
  --agent-settings '{"scanLevel": "STANDARD", "scanTriggerType": "SCHEDULED"}'

# Create scan target for all compute in app compartment
oci vulnerability-scanning host scan-target create \
  --compartment-id ocid1.compartment.oc1..application \
  --display-name "App-Tier-Scan" \
  --host-scan-recipe-id ocid1.vssrecipe.oc1..xxx \
  --target-compartment-id ocid1.compartment.oc1..application

OCI Bastion Service

Never SSH directly to instances. Use Bastion for audited, time-limited sessions:

bash

# Create a bastion
oci bastion bastion create \
  --bastion-type STANDARD \
  --compartment-id ocid1.compartment.oc1..security \
  --target-subnet-id ocid1.subnet.oc1..private \
  --name "secure-bastion"

# Create a managed SSH session (time-limited)
oci bastion session create-managed-ssh \
  --bastion-id ocid1.bastion.oc1..xxx \
  --target-resource-id ocid1.instance.oc1..xxx \
  --target-os-username opc \
  --session-ttl-in-seconds 1800 \
  --key-type PUB \
  --ssh-public-key-file ~/.ssh/id_rsa.pub

Fusion SaaS Security#

The Fusion Security Model

Role Design Best Practices

Fusion uses a role hierarchy: Job Roles → Duty Roles → Privileges. Never assign privileges directly to users.

Role Type	Purpose	Example
Job Role	Maps to actual job function	Accounts Payable Manager
Abstract Role	Cross-functional access	Employee, Line Manager
Duty Role	Specific business function	Process AP Invoices
Data Role	Controls data visibility	View Own Business Unit Only

Segregation of Duties (SoD) Controls

Critical SoD conflicts to monitor in Fusion Financials:

Create Supplier + Approve Payment — Classic fraud vector
Create Journal Entry + Post Journal — Financial statement manipulation
Create Purchase Order + Receive Goods — Procurement fraud
Manage User Access + All Business Functions — Super-user risk

bash

# Use Fusion Security Console to check SoD
# Navigation: Setup and Maintenance > Security Console > Roles
# Run: Segregation of Duties Analysis Report
# Or via REST API:
curl -u admin:password \
  "https://your-fusion.fa.us2.oraclecloud.com/hcmRestApi/resources/latest/roles?q=RoleName%20like%20'%25Payable%25'" \
  -H "Content-Type: application/json"

Business Object Auditing — Step by Step

This is where most organizations fail. Fusion generates millions of transactions — you need selective, targeted auditing.

Step 1: Enable Audit at Application Level

Navigate to: Setup and Maintenance → Manage Audit Policies

Enable auditing for these critical business objects:

Business Object	Events to Audit	Why
Suppliers	Create, Update, Delete	Vendor fraud detection
Invoices	Create, Approve, Cancel, Void	Payment fraud
Journal Entries	Create, Post, Reverse	Financial manipulation
Purchase Orders	Create, Approve, Close	Procurement fraud
User Role Assignment	Grant, Revoke	Access control changes
Bank Accounts	Create, Update	Payment routing changes
Customer Records	Create, Update	Revenue recognition

Step 2: Configure Granular Audit Attributes

For each business object, select which attributes to audit (don't audit everything — performance impact):

Supplier: Name, Tax ID, Payment Method, Bank Account, Status
Invoice: Amount, Supplier, Approval Status, Payment Terms
Journal: Amount, Account, Period, Source, Category

Step 3: Access Audit Reports

bash

# Fusion Audit Report via BI Publisher
# Navigation: Tools > Reports and Analytics > Shared Folders > Financials
# Report: "Audit Report" or create custom using:
# View: FND_AUDIT_CHANGES_V (contains all audited changes)

# Via REST API — query audit events
curl -u admin:password \
  "https://your-fusion.fa.us2.oraclecloud.com/fndAuditRestApi/audit/records?finder=AuditFinder;EventType=UPDATE,BusinessObjectName=Suppliers&limit=100" \
  -H "Content-Type: application/json"

Step 4: Stream Audit to External SIEM

Export Fusion audit data to your SIEM (Splunk, Sentinel, Chronicle):

bash

# Use OIC to extract audit logs and push to SIEM
# OIC Integration Flow:
# 1. Schedule trigger (every 15 min)
# 2. Invoke Fusion Audit REST API
# 3. Transform to CEF/JSON format
# 4. Push to SIEM webhook/HEC endpoint

OIC Integration Security#

Oracle Integration Cloud (OIC) is the bridge between OCI IaaS and Fusion SaaS. It's also a massive attack surface if misconfigured.

OIC Security Best Practices

bash

# 1. Use service accounts, not personal accounts for integrations
# Create a dedicated integration user in IDCS
oci iam user create \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "svc-oic-fusion" \
  --description "Service account for OIC-Fusion integrations"

# 2. Apply least-privilege: only needed Fusion roles
# Grant only: Integration Specialist, specific REST API roles

# 3. Enable OIC audit logging
# Navigate: OIC Console > Settings > Audit
# Enable: Connection audit, Integration audit, Agent audit

# 4. Restrict OIC agent connectivity
# Use private agents — never expose OIC endpoints publicly
# Deploy agents in private subnets with no internet access

Integration Flow Security Checklist

Control	Status	Priority
All connections use OAuth 2.0 (not basic auth)	Required	Critical
Sensitive data mapped through OIC is not logged	Required	High
Private agents deployed in private subnets	Required	High
Integration error notifications go to security team	Recommended	Medium
Connection credentials rotated every 90 days	Required	High
IP allowlisting on Fusion for OIC source IPs	Recommended	Medium
Data encryption in-flight (TLS 1.2+)	Required	Critical

IDCS / OCI IAM Federation#

bash

# Configure SAML federation with corporate IdP
# Step 1: Create Identity Provider in OCI IAM
oci iam identity-provider create-saml2 \
  --compartment-id ocid1.tenancy.oc1..root \
  --name "Corporate-ADFS" \
  --description "Federation with on-premises Active Directory" \
  --metadata-url "https://adfs.company.com/FederationMetadata/2007-06/FederationMetadata.xml" \
  --product-type ADFS

# Step 2: Map IdP groups to OCI groups
oci iam idp-group-mapping create \
  --identity-provider-id ocid1.saml2idp.oc1..xxx \
  --idp-group-name "Cloud-Admins" \
  --group-id ocid1.group.oc1..cloudadmins

# Step 3: Enforce MFA via IDCS Sign-On Policy
# IDCS Console > Security > Sign-On Policies > Add
# Condition: All users accessing Fusion
# Action: Require MFA (TOTP or FIDO2)

Compliance Mapping#

OCI/Fusion Control	ISO 27001	SOC 2	NIST 800-53
Compartment isolation	A.8.31	CC6.1	AC-4
Cloud Guard monitoring	A.8.16	CC7.2	SI-4
Business object auditing	A.8.15	CC4.1	AU-2, AU-3
IDCS MFA enforcement	A.8.5	CC6.1	IA-2
Bastion session recording	A.8.15	CC6.2	AC-17
Fusion SoD controls	A.5.3	CC6.3	AC-5
OIC connection encryption	A.8.24	CC6.7	SC-8
VSS vulnerability scanning	A.8.8	CC7.1	RA-5

Security Hardening Checklist#

#	Control	Layer	Priority
1	Enable Cloud Guard on all compartments	OCI	Critical
2	No public subnets for databases	OCI	Critical
3	Enable MFA for all IDCS users	Identity	Critical
4	Configure SoD policies in Fusion	Application	High
5	Enable business object auditing	Application	High
6	Deploy OIC agents in private subnets	Integration	High
7	Rotate all API keys every 90 days	Identity	High
8	Enable VSS scanning weekly	OCI	Medium
9	Use Bastion for all SSH access	OCI	Medium
10	Configure WAF for public-facing apps	OCI	Medium
11	Stream all audit logs to SIEM	Monitoring	Medium
12	Review Fusion role assignments quarterly	Application	Medium

Elastyx monitors OCI posture alongside AWS, Azure, and GCP — giving you unified visibility into compartment policies, Cloud Guard findings, and Fusion security configurations through a single dashboard.

Securing Oracle Cloud: OCI Infrastructure + Fusion Applications — The Complete Blueprint

Why Oracle Cloud Security Matters#

OCI Security Architecture#

Compartment Design

Cloud Guard — OCI's Native CSPM

Vulnerability Scanning Service (VSS)

OCI Bastion Service

Fusion SaaS Security#

The Fusion Security Model

Role Design Best Practices

Segregation of Duties (SoD) Controls

Business Object Auditing — Step by Step

OIC Integration Security#

OIC Security Best Practices

Integration Flow Security Checklist

IDCS / OCI IAM Federation#

Compliance Mapping#

Security Hardening Checklist#

Skip the manual work. Let Elastyx do this continuously.