How the Oracle OCI Proactively protect the customer workload in cloud from day one?

Current Challenge

Customer Engineer responsible for provisioning cloud resources might not be aware or not well trained for how to use the best security configuration as part of their cloud implementation. If the security is not follow during the starting phase then it always become very difficult to address later during the the cloud go live and often it became the reactive approach. The proactive approach to address the security from starting were missing in many CSP providers.

Oracle is helping to shift more of the security responsibilities from the customer to the cloud provider. 

Oracle OCI Gen2 Cloud built from ground level Built In Security Always On with Zero Trust Security Model

Oracle Security Zones

A service that helps ensures customers implement Oracle’s best practices for security by enforcing them from the start and removing the chance of configuration drift or someone violating them later. This brings clarity regarding what is needed to meet their security needs and removes guesswork from the equation when it comes to implementation.

Security Zones let you be confident that your resources in Oracle Cloud Infrastructure, including Compute, Networking, Object Storage, and Database resources, comply with Oracle security principles.

Access the Security Zone in OCI

Security zone An association between a compartment and a security zone recipe. Resource operations in a security zone are validated against all policies in the recipe.                                          

Security zone recipe A collection of security zone policies.

Security zone policy A security requirement for resources in a security zone.

When you create and update resources in a security zone, OCI validates these operations against the list of policies defined in the security zone recipe.

High Level Proposed Architecture

Creating Security Zone

Your tenancy has a predefined recipe named “Maximum Security Recipe”, which includes all available security zone policies. Oracle manages this recipe and you can’t modify it.

In general, security zone policies align with these security principles:

  1. Resources can’t be moved from a security zone to a standard compartment because it might be less secure
  2. Data in a security zone can’t be copied to a standard compartment because it might be less secure.
  3. All the required components for a resource in a security zone must also be located in a security zone. Resources that are not in a security zone might be vulnerable. For example, a compute instance in a security zone can’t use a boot volume that is not in a security zone.
  4. Resources in a security zone must not be accessible from the public internet.
  5. Resources in a security zone must be encrypted using customer-managed keys.
  6. Resources in a security zone must be regularly and automatically backed up.
  7. Resources in a security zone must use only configurations and templates approved by Oracle.

A security zone policy differs from an IAM policy in the following ways:

  • Administrators create IAM policies to grant users the ability to manage certain resources in a compartment.
  • A security zone policy ensures that these management operations comply with the Oracle maximum security architecture and best practices.
  • A security zone policy is validated regardless of which user is performing the operation.
  • A security zone policy denies certain actions; it doesn’t grant capabilities.
  • Administrators can’t create, modify, or disable security zone policies.

Verify the Security Zone

  1. You can’t create the bucket without customer managed keys.

It is suggesting you to follow the workflow to create secure bucket.

2. You can’t create the public bucket in security zone.

3. You can’t move the bucket from security zone to standard compartment.

4. You can’t add Internet Gateway in Security zone

Reference Architecture

OCI Documentation

Thank you for visiting this blog.

Disclaimer : The views expressed on this blog are my own and do not reflect the views of the companies I work, The opinions give by visitors on this site are there own opinions.


How to protect your application servers or containers in Cloud?

Most of the industry have compliance and regulations from Government or Standard authority that very from industry to industry for maintain the security standard as part of their application services delivery to the end user and so the Security is the crucial decision factor before go live the application in most of the industry today.

I have seen the customers to validate the security issues in their app server image and application packages or build before they go live for production, Traditionally customer relaying on security scanning tools like Nessus, OpenVAS, OpenSCAP, Nmap, Wireshark, Metasploit, but the real challenges for customer start when they have large scale deployment and overhead to keep them operating to meet the Security SLA. Also With cloud world the more and more responsibility raised on the customer head.

Vulnerability scanning is a common compliance requirement (e.g., NIST 800-53 Rev.4 FISMA) for customers and a recommended security best practice for all organizations.


Customers face challenges with scanning due to:

1. Disjointed vulnerability scanning tools— often, customers will buy or license multiple tools for scanning instances, containers, and applications. The total cost can add up, leaving customers to choose between cost and security.

2. Lots of manual processes to correct vulnerabilities—Customers must deploy, configure, and upgrade agents on their fleets, with large operational pain, and the potential for misconfiguration due to human error.

3. Large volume of alerts with a high false positive rate—Vulnerability reports can overwhelm customers with “noise”. Too many false positive findings will cause customers to get lost in the volume or get accustomed to it. As a result, this can reduce the time to resolution for critical issues or even worse, these critical issues can go unacknowledged.

Vulnerability Scanning Service

Oracle Cloud Infrastructure Vulnerability Scanning Service (OCI VSS) is simple, prescriptive, and tightly integrated with the OCI platform. VSS is available to all OCI customers that have paid accounts at no additional cost. The scanning platform includes default plugins and engines for instance and container scanning.

The Scanning service can identify several types of security issues in your compute instances :

  • Ports that are unintentionally left open might be a potential attack vector to your cloud resources, or enable hackers to exploit other vulnerabilities.
  • OS packages that require updates and patches to address vulnerabilities
  • OS configurations that hackers might exploit
  • Industry-standard benchmarks published by the Center for Internet Security (CIS).

The Scanning service checks hosts for compliance with the section 5 (Access, Authentication, and Authorization) benchmarks defined for Distribution Independent Linux.

The Scanning service can scan individual compute instances, or it can scan all compute instances within a compartment and its subcompartments. If you configure the Scanning service at the root compartment, then all compute instances in the entire tenancy are scanned.

The Scanning service detects vulnerabilities in the following platforms:

  1. Oracle Linux
  2. CentOS
  3. Ubuntu
  4. Windows (no CIS benchmarks)

Oracle Vulnerability Scanning Service helps improve your security posture in Oracle Cloud by routinely checking hosts for potential vulnerabilities. The service generates reports with metrics and details about these vulnerabilities

High Level Architecture

Key Service Concept

Scan Recipe

Scanning parameters for a type of cloud resource, including what information to examine and how often.


One or more cloud resources that you want to scan using a specific recipe. Resources in a target are of the same type, such as compute instances.

Host Scan

Metrics about a specific cloud resource that was scanned, including the vulnerabilities that were found, their risk levels, and CIS benchmark compliance. The Scanning service uses a host agent to detect these vulnerabilities

Port Scan

Open ports that were detected on a specific cloud resource that was scanned. The Scanning service can detect open ports using a host agent, or using a network mapper that searches your public IP addresses

Vulnerabilities Report

Information about a specific type of vulnerability that was detected in one or more targets, like a missing update for an OS package.

Integration with Cloud Guard

You can view security vulnerabilities identified by the Scanning service in Cloud Guard. Cloud Guard alerting can help customers reduce the time from detection to remediation.

Access the Service from OCI Console

Configure the VSS for your tenancy or specific compartment

Create Compute Resource

Result & Remediate

Reference Resources


Reference architecture

OCI Documentation

Thank you for visiting this blog.

Disclaimer : The views expressed on this blog are my own and do not reflect the views of the companies I work, The opinions give by visitors on this site are there own opinions.

Quick Start for OCI Vault

Historically customer store master encryption keys and secrets in Server configuration files or in code. As we all know that “Data Is the New Oil of the Digital Economy”. In cloud world customer have choice to choose the best option to secure their data and that is why cloud is more secure platform than on-premises.

In this article we will focus on the overview of service – OCI Vault, the types of offering based on the use case, key capabilities and how to use the Vault with various OCI services.

The Vault service helps you centrally manage the encryption keys that protect your data and the secret credentials that you use to access resources. Vaults securely store master encryption keys and secrets that you might otherwise store in configuration files or in code.

It lets you to centrally manage and control use of keys and secrets across a wide range of OCI services and applications. OCI Vault is a secure, resilient managed service that lets you focus on your data encryption needs without worrying about time-consuming administrative tasks such as hardware provisioning, software patching, and high availability.

Key Management uses hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification, to protect your keys. You can create master encryption keys protected either by HSM or software. With the HSM- protected keys, all the cryptographic operations and storage of keys are inside the HSM. With the software-protected keys, your encryption keys are stored and processed in software, but are secured at rest with a root key from HSM.

The following key management capabilities are available when you use the Vault service.

  • Create your own encryption keys that protects your data
  • Bring your own keys
  • Rotate your keys
  • Support for cross-region backup and restore for your Keys
  • Constrain permissions on keys using IAM policies
  • Integration to OCI internal services: Oracle Autonomous Database, Exadata Databases (without Oracle Data Guard enabled),Oracle Block Storage, Oracle File storage, Oracle Object Storage, Streaming and Container engine for Kubernetes

High Level Vault Service Integration Architecture

Get Started with Vault

1. Ensure that the limits for your tenancy allow for creation of the Vault type you intend to create.

2. Ensure that Oracle Identity and Access Management (IAM) policies have been created for the user account to have the necessary permissions to create a Vault. See IAM Policy Reference to construct a statement.

3. You first create a Vault by selecting Security from the Oracle Cloud Infrastructure Console, and then Vault.

Create a Vault and select from one of the two available Vault types that best fits your isolation and processing requirements:

  1. Virtual Private Vault: Chose a Virtual Private Vault if you require increased isolation on the HSM and dedicated processing of encrypt/decrypt operations.
  2. Vault (Default): Choose the default Vault if you are willing to accept a moderate isolation (multitenant partition in HSM) and shared processing for encrypt/decrypt operations.

4. Create the [Master Encryption] Key(s) inside your Vault. Master encryption keys can have one of two protection modes: HSM or software.

  • A master encryption key protected by an HSM is stored on an HSM and cannot be exported from the HSM. All cryptographic operations involving the key also happen on the HSM.
  • A master encryption key protected by software is stored on a server and can be exported from the server to perform cryptographic operations on the client instead of on the server. While at rest, the software-protected key is encrypted by a root key on the HSM.

5. Ensure that IAM policies for the service or entity calling Vault has the necessary permissions.

Example: allow service objectstorage-us-ashburn-1 to use keys in compartment

Use the key(s):

  • With native Oracle Cloud Infrastructure storage: When creating storage (bucket, file, volume), mark with “ENCRYPT USING CUSTOMER-MANAGED KEYS”, then select the Vault and the Master Encryption Key. Data in that bucket/volume/file storage will be encrypted with a data encryption key wrapped with the Master Encryption Key in Vault.
  • With crypto operations, using Command Line Interface (CLI) as an example: oci kms crypto encrypt –key-id –plaintext
  • Crypto operations are available in SDK and API as well. For more details, see Overview of Vault in the documentation.

6. Monitor your usage of operations with metrics in the console and Monitoring service. See the metrics and dimensions

Using Keys

You can directly submit data to Key Management APIs to encrypt and decrypt using your master encryption keys stored in the Vault.

Also, you can encrypt your data locally within your applications and OCI services using a method known as Envelope encryption.

With envelope encryption, you generate and retrieve Data Encryption Keys (DEK) from Key Management APIs. DEKs are not stored or managed in Key Management service but are encrypted by your Master Encryption Key. Your applications can use DEK to encrypt your data and store the encrypted DEK along with the data. When your applications want to decrypt the data, you should call decrypt to Key Management API on the encrypted DEK to retrieve the DEK. You can the decrypt your data locally with the DEK.

Key Management supports sending up to 4 KB of data to be encrypted directly. In addition, envelope encryption can offer significant performance benefits. When you encrypt data directly with Key Management APIs, it must be transferred over the network. Envelope encryption reduces the network load since only the request and delivery of the much smaller DEK go over the network. The DEK is used locally in your application or encrypting OCI service, avoiding the need to send the entire block of data.

OCI Offer two choice of Encryption for customer while provisioning the resources

Oracle Managed is the default encryption for many OCI services. Oracle Managed means data will be encrypted at rest with an encryption key whose lifecycle management is controlled by Oracle. Customers who don’t want to manage or access their encryption keys and are looking for an easiest way to protect all their data stored in OCI can choose Oracle Managed encryption.

Customer-Managed encryption is offered by OCI Vault—Key Management service where the customer controls and manages the keys that protect their data. In addition, customers who require elevated security and FIPS 140-2 Level 3 protection to meet compliance choose Customer Managed as the encryption keys are stored in hardware security modules (HSMs).

Create Resource with OCI Vault

For more information, see OCI Documentation 

Reference OCI Vault FAQ

Thank you for visiting this blog.

Disclaimer : The views expressed on this blog are my own and do not reflect the views of the companies I work, The opinions give by visitors on this site are there own opinions.