Compute Enclave Security Features

Identity Provider Security Features

Companies commonly use an identity provider (IdP) to manage user login/passwords and to authenticate users for access to secure websites, services and resources. A tenancy administrator can federate with a supported IdP so that employees can use their existing login and password with the Oracle Private Cloud Appliance Compute Web UI.

Oracle Private Cloud Appliance supports the following Security Assertion Markup Language (SAML) 2.0 compliant identity providers:

Microsoft Active Directory via Active Directory Federation Services

The following conditions apply to the use of Identity Providers with Oracle Private Cloud Appliance:

Users can only access the Compute Web UI - A federated user is not managed within the Oracle Private Cloud Appliance Identity and Access Management (IAM) framework. As a result, they cannot have API keys added for use of the OCI CLI or manage preferences.
Group mappings between given Active Directory groups to Oracle Private Cloud Appliance must be made for federated users to have authorization to do operations within the Compute Web UI.
Multifactor authentication to the Oracle Private Cloud Appliance Compute Web UI is only available via an Identity Provider.

For cases where the Identity Provider uses self-signed certificates, additional steps must be taken to add the Certificate Authority (CA) trust information to the Oracle Private Cloud Appliance prior to adding the IdP. To add the CA information, an appliance administrator will need to:

Access a management node on the Oracle Private Cloud Appliance using the management node root account.
Distribute the CA X.509 certificate to the management nodes using the tools included on the management node.

For more information, see the "Verifying Identity Provider Self-Signed Certificates" section of the Oracle Private Cloud Appliance Administrator Guide

Oracle makes the following recommendations with respect to Identity Providers in the tenancies:

Use federation to manage authentication to the Compute Web UI if a supported Identity Provider is available.
Create an administrators group within the compute tenancy that maps to the federated IdP administrator group and ensure a federated user is assigned to the IdP administrator group.
Only use the local (non-federated) tenancy administrator for emergency purposes, such as:
- Change the local (non-federated) administer password to an extremely complex password.
- Escrow the local (non-federated) password to a safe location.
- Restrict the federated IdP administrator group from modifying the local Administrators and the local Administrator group.
- Periodically monitor the audit logs for illicit use of the local administrator account(s) and check for attempts at unauthorized actions.
- Consider rotating the locally defined administrator's password and re-escrowing periodically and/or immediately after use.

For an overview of support for Identity Providers see the Identity and Access Management Overview chapter of the Oracle Private Cloud Appliance Concepts Guide.

For an overview of federating a tenancy with Microsoft Active Directory see the "Federating with Microsoft Active Directory" section of the Oracle Private Cloud Appliance User Guide.

IAM Security Features

Oracle Private Cloud Appliance Identity and Access Management (IAM) provides authentication of local users and authorization to resources. IAM facilitates organizational principles that aid with security management such as:

Compartments - Collections of related resources (such as cloud networks, compute instances, or block volumes) that can be accessed by groups that have been given permission by a tenancy administrator.
Groups - Collections of users that have similar requirements for authorizations (users can be in multiple groups).
Resources - Objects (such as compute instances, block volumes, users, and so on) created using the various Oracle Cloud Infrastructure services.
Tags - Metadata in the form of keys and values that are added to resources
Tenancy - The root compartment that holds all resources, including additional compartments.

A security policy specifies the types of access a group defined in IAM has to resources at the specified aggregation level (Tenancy, Compartment, or Service) that can be further refined with information about tags.

For more information about policies in general, see the "Managing Policies" section in the Identity and Access Management chapter of the Oracle Private Cloud Appliance User Guide.

An end goal of a tenancy administrator is to achieve the principle of least privilege:

Enable users to achieve what their role requires with resources and privileges required for their role.
Disallow users from accessing resources or accessing resources with privileges that are not necessary for their role.
Enable ease of administration to add and remove resources and privileges to a user or user group.

To achieve the principle of least privilege, use a combination of tenancy-use organizational concepts and security policy management techniques.

When designing and maintaining the tenancy:

The root compartment, tenancy, offers central control and visibility for tenancy-wide administrators, while also allowing the tenancy to be subdivided to meet the needs of the teams.
Compartments provide an effective mechanism to group tenancy resources based on their access privileges and authorize groups of users to access the compartments on as needed basis. For example, a compartment can be created to include all resources belonging to a business unit, and authorize only members of the business unit to access the compartment. Similarly, a group's access to a compartment can be revoked quickly when they do not need it anymore.
Keep the following in mind with compartments and resource assignments:
- Every resource belongs to a compartment.
- A resource can be reassigned to a different compartment after creation.
- A compartment can be deleted after creation.
Resource tags provide a way to logically aggregate resources distributed across multiple compartments. For example, tenancy resources can be tagged as test or production depending on their use.

For more information about resource tags (free-form and defined tags), see the "Creating and Managing Compartments" section in the Identity and Access Management chapter, and the Resource Tag Management chapter of the Oracle Private Cloud Appliance User Guide.

When managing users in a tenancy:

Create an IAM user for everyone in the customer organization who needs access to resources. Do not share user accounts, especially those with administrative accounts. Using distinct users enables easier enforcement of least privilege access for each user, and captures helps track actions in audit logs.
The recommended unit of administration is IAM groups, making it easier to manage and keep track of security permissions (as opposed to individual users). Create groups with permissions to do commonly needed tasks (for example, network administration, volume administration), and assign users to these groups on an as-needed basis. IAM permissions can be used to give a group access to resources across multiple compartments in a tenancy.
Periodically review membership of IAM users in IAM groups, and remove users from groups they do not need access to anymore. Using group membership to manage user access scales well with increasing number of users.
Deactivate IAM users who do not need access to tenancy resources. Deleting an IAM user removes the user permanently. You can temporarily deactivate an IAM user by doing the following:
- Rotate the user password and throw it away.
- Remove all tenancy permissions of the user by removing membership from all groups.

The above guidance on managing tenancy users changes slightly with IdP integration. Please note that:

Cooperation with the IdP administrator to add and remove groups directly from a user is required.
Group management rules still apply.

For more information on OCI CLI usage for IAM management, see the Identity and Access Management chapter in the Oracle Private Cloud Appliance User Guide.

Creating Service-level Administrators for Least Privilege

To implement the security principle of least privilege, groups can be created to administer individual services, with users being added to one or more of the service administrator roles. For example, network administrators need administrative (manage) access only to VCN resources, and not to other resources. A compute administrator may need compute privileges, but their work often also involves storage and volumes, requiring additional administration privileges. The following example shows policies that break administration into the more granular scope, allowing administrators to allocate and deallocate service-level authorizations.

First, a set of groups are created using the CLI commands (the same actions can be done with the GUI):

oci iam group create --name TenancyAdmin --description "Tenancy administrators"
oci iam group create --name VolumeAdmin --description "Volume admins includes block volumes)"
oci iam group create --name NetworkAdmin --description "Network admins (VCNs, subnets, etc...)"
oci iam group create --name StorageAdmin --description "Storage administrators (Object storage)"
oci iam group create --name InstanceAdmin --description "Instance admins (compute instances, etc.)"

These groups have no users at creation. There are also no security policies associated with the groups at this time.

Next, a set of policies are created that enable the various groups to administer the services:

oci iam policy create --name ServiceAdministratorPolicies --description "Policies for svc admin" 
  --statements '["Allow group TenancyAdmin to manage all-resources in tenancy", 
  "Allow group VolumeAdmin to manage volume-family in tenancy", 
  "Allow group NetworkAdmin to manage virtual-network-family in tenancy", 
  "Allow group StorageAdmin to manage object-family in tenancy", 
  "Allow group InstanceAdmin to manage instance-family in tenancy"]'

Once these groups and policies are in place, a local user can be added and removed from service-level administration duties across the entire tenancy quickly and efficiently:

oci iam group add-user --group-id ocid1.group.<id> --user-id ocid1.user.<id>
oci iam group remove-user --group-id ocid1.group.<id> --user-id ocid1.user.<id>

Break tenancies up into compartments to support multiple project, environments, or other organizational structures. The guidance to create service level administration groups can be quickly adapted to creating service level administration groups for a compartment.

For example, if there is a compartment named "HR" to support the Human Resources cloud, choose a group name such as HRNetworkAdmin.

Then adapt the policy statements appropriately to use the HR compartment rather than the tenancy:

"Allow group HRNetworkAdmin to manage virtual-network-family in compartment HR"

Creating Security Auditors

Not all tasks require active management of resources. Compliance auditors are tasked with examining cloud resources and assessing access to the resources. The following policy allows users in the group InternalAuditors to inspect (list) all resources in a tenancy:

"Allow group InternalAuditors to inspect all-resources in tenancy"

Alternatively, auditors may have specific roles to play. The following policy statement allows users in group UserAuditors to inspect just users and groups.

"Allow group UserAuditors to inspect users in tenancy"
"Allow group UserAuditors to inspect groups in tenancy"

If you want to create an auditor group that can only inspect VCN firewalls in the tenancy, then use the following policy:

"Allow group FirewallAuditors to inspect security-lists in tenancy"

You can constrain the policies in all these policy examples to a compartment by specifying compartment <name> (where <name> is the compartment name) in the policy.

Restricting the Ability to Change Tenancy Administrator Group Membership

Members in the group Administrators can manage all resources in a tenancy. Membership of the Administrators group is controlled by users in the group. Usually, it's convenient to have a group to create and add users in the tenancy, but restrict them from making changes to the Administrators group membership. The following example creates a group UserAdmins to do this.

"Allow group UserAdmins to inspect users in tenancy"
"Allow group UserAdmins to inspect groups in tenancy"

"Allow group UserAdmins to use users in tenancy where target.group.name!='Administrators'"
"Allow group UserAdmins to use groups in tenancy where target.group.name!='Administrators'"

The third and fourth policy statements allow UserAdmins to add users and groups using APIs (UpdateUser, UpdateGroup) to all groups in the tenancy except the Administrators group. However, because target.group.name!='Administrators' is not related to the list and get APIs (ListUsers, GetUser, ListGroups, and GetGroup), these APIs will fail without other commands. So you must explicitly add inspect in the first and second policy statements to allow UserAdmins to get user and group membership information.

Preventing Deletion or Updating of Security Policies

The following example creates a group PolicyAdmins to be able to create and list security policies created by tenancy administrators, but not delete or update them:

"Allow group PolicyAdmins to use policies in tenancy" 
"Allow group PolicyAdmins to manage policies in tenancy where request.permission='POLICY_CREATE'"

The second security policy statement explicitly allows POLICY_CREATE permission, but not POLICY_DELETE and POLICY_UPDATE.

Preventing Administrators from Accessing or Altering User Credentials

Some compliance requirements need separation of duties, especially where user credential management functionality is separated from tenancy management. In this case, you can create two administration groups, TenancyAdmins and CredentialAdmins.

TenancyAdmins can perform all tenancy management functions except user credential management, and CredentialAdmins can manage user credentials.

TenancyAdmins can access all APIs except those that list, update, or delete user credentials. CredentialAdmins can only manage the user credentials.

To establish these administration groups, use the following:

"Allow group TenancyAdmins to manage all resources in tenancy
 where all {request.operation!='ListApiKeys',
            request.operation!='ListAuthTokens',
            request.operation!='ListCustomerSecretKeys',
            request.operation!='UploadApiKey',
            request.operation!='DeleteApiKey',
            request.operation!='UpdateAuthToken',
            request.operation!='CreateAuthToken',
            request.operation!='DeleteAuthToken',
            request.operation!='CreateSecretKey',
            request.operation!='UpdateCustomerSecretKey',
            request.operation!='DeleteCustomerSecretKey'}"
"Allow group CredentialAdmins to manage users in tenancy
 where any {request.operation='ListApiKeys',
            request.operation='ListAuthTokens',
            request.operation='ListCustomerSecretKeys',
            request.operation='UploadApiKey',
            request.operation='DeleteApiKey',
            request.operation='UpdateAuthToken',
            request.operation='CreateAuthToken',
            request.operation='DeleteAuthToken',
            request.operation='CreateSecretKey',
            request.operation='UpdateCustomerSecretKey',
            request.operation='DeleteCustomerSecretKey'}"

File Storage Service Security Features

The Oracle Private Cloud Appliance File Storage Service provides a durable, scalable, secure, enterprise-grade network file system. With the service, a user with proper authorization can create and manage file systems that can be accessed from compute instances in a Virtual Cloud Network (VCN).

The File Storage Service:

Supports NFSv3, v4, v4.1, and SMB
Encrypts data on disk using Advanced Encryption Standard (AES) 128-bit algorithm.
Allows periodic snapshots of the file system to be taken (see the "Managing Snapshots" section of the Oracle Private Cloud Appliance User Guide).
Supports a variety of NFS export options to manage client access and use.
Uses VCN and Network Security Groups to manage client access to shares.

Administrators can use the File Storage Service as long as they have authorization through a security policy such as:

Resource Type Family: file-family
Resource Types: file-systems, mount-targets, export-sets

If a group FileAdmin exists, a policy that would grant them authorization to manage all aspects of the File Storage Service would be:

"Allow group FileAdmin to manage file-family in tenancy"

Because data storage is a critical function of any system, it may be useful to create a second group for users that allows them to create file systems, but does not allow accidental deletion of file systems. For example, if there is a group FileUsers, then the following policy statements could be added to limit their access:

"Allow group FileUsers to manage file-systems in tenancy 
       where request.permission!='FILE_SYSTEM_DELETE'" 
"Allow group FileUsers to manage mount-targets in tenancy 
       where request.permission!='MOUNT_TARGET_DELETE'" 
"Allow group FileUsers to manage export-sets in tenancy 
       where request.permission!='EXPORT_SET_DELETE'"

For more ways to manage access to the File Storage Service, see the "Managing Policies" section in the Identity and Access Management chapter of the Oracle Private Cloud Appliance User Guide.

For a description of how to manage access to file system, including how to restrict access or allow access, from clients, see the section "Controlling Access to File Storage" in the File System Storage chapter of the Oracle Private Cloud Appliance User Guide.

Object Store Security Features

The Oracle Private Cloud Appliance Object Storage service stores and provides access to large amounts of unstructured data of any content type. Content stored in object storage can be accessed from within the Compute Enclave by compute instances as well as from the data center through the domain of the Oracle Private Cloud Appliance.

The Object Storage service:

Encrypts data on disk (at rest) using Advanced Encryption Standard (AES) 128-bit algorithm. Encryption is on by default and cannot be turned off. The encryption keys are themselves encrypted with a master encryption key.
Data in transit between customer clients (for example, SDKs and CLIs) and Object Storage public endpoints is encrypted with TLS 1.2 by default.
Data integrity is facilitated by a checksum generated for each uploaded object and, for multi-part uploads, a checksum generated for each part.
Objects can have revokable pre-authenticated requests built with varying authorization levels.
Object versioning is available to retain changes to objects.
Write-once Read-many (WORM) retention rules can be set to ensure an object retains its original contents.
Users that are authenticated to the Oracle Private Cloud Appliance have the ability to manage the Object Storage service and resources that are managed within the security policy framework.

For more details on using the above features, see the "Object Storage" section in the Oracle Private Cloud Appliance User Guide

Security Recommendations

Assign least privileged access for IAM users and groups to resource types in object-family (such as objectstorage-namespaces, buckets, and objects). For example, the inspect verb gives the least privilege. The inspect verb lets you check to see if a bucket exists (HeadBucket) and list the buckets in a compartment (ListBucket). The manage verb gives all permissions on the resource. You can create IAM security policies to give appropriate bucket and object access to various IAM groups.

For more information about IAM verbs and permissions for Object Storage buckets and objects, see Details for Object Storage, Archive Storage, and Data Transfer.

For users without IAM credentials, we recommend that you use pre-authenticated requests (PARs) to give time-bound access to objects or buckets.

Pre-Authenticated Requests

Pre-authenticated requests provide a mechanism to give access to objects and buckets without requiring the client or user to log into the Oracle Private Cloud Appliance. As a result, objects and buckets can be used without an IAM user defined on the Oracle Private Cloud Appliance.

An IAM user with appropriate privileges for accessing objects creates a URL that grants time-bound access to objects. For more information on these grants, see the Oracle Cloud Infrastructure information on Using Pre-Authenticated Requests. Please note that:

The creator of a pre-authenticated request must have PAR_MANAGE permission and the appropriate IAM permissions for the access type that you are granting. You can create a pre-authenticated request that grants read, write, or read/write access to one of the following:
- All objects in the bucket.
- A specific object in the bucket.
- All objects in the bucket that have a specified prefix.
For requests that apply to multiple objects, you can also decide whether you want to let users list those objects.
Pre-authenticated request accesses to a bucket are logged in Audit logs. Pre-authenticated request accesses to an object are logged in Service logs.

Important:

The unique URL provided by the system when you create a pre-authenticated request is the only way a user can access the request target. Copy the URL to durable storage. The URL is displayed only at the time of creation, is not stored in Object Storage, and cannot be retrieved later.

Data Durability and Integrity

The Object Storage service provides a variety of ways to ensure data remains consistent and intact once stored. Please note that:

Data loss can be minimized by preventing inadvertent deletes by an authorized user or malicious deletes:
- Use object versioning to automatically create an object version each time a new object is uploaded, an existing object is overwritten, or when an object is deleted.
- Give BUCKET_DELETE and OBJECT_DELETE permissions to a minimum set of IAM users and groups. Grant delete permissions only to tenancy and compartment administrators.
Write once read many (WORM) compliance requires that objects cannot be deleted or modified. Use retention rules to achieve WORM compliance. Retention rules are configured at the bucket level and are applied to all individual objects in the bucket. You cannot update, overwrite, or delete objects or object metadata until the retention rule is deleted (indefinite rule) or for the duration specified (time-bound rules).

For an independent assessment of the Object Storage retention rules feature's ability to meet regulatory requirements for record management and retention, see Cohasset Associate's SEC 17a-4(f), FINRA 4511(c), CFTC 1.31(c)-(d) and MiFID II Compliance Assessment.
Objects are stored in a ZFS file system with a SHA-256 checksum to avoid phantom reads and detect invalid data returned from devices.

In addition to facilities provided for durability, Object Storage provides mechanisms to ensure data integrity:

A checksum is provided for all objects uploaded to Object Storage. The checksum can be used in two ways:
- To verify that the object stored is the object that was uploaded
- To verify that the object retrieved is the one that was originally stored
Multipart uploads are used by the Object Storage service for efficiency and resiliency on large object uploads. In a multipart upload, a large object is broken up into smaller parts by specifying a part size in MiB. Each part is uploaded separately. Object Storage then combines all the parts to re-create the original object. If any of the parts fail to upload, only the failed parts need to be retried for upload, not the entire object. In a multipart upload, checksum values are computed for each part of the upload, and a single checksum is computed over all of the individual checksum values to get the checksum value reported by the object upload. To verify the value returned for a multipart upload, follow the same process for offline checksum calculation.

Using the checksum returned when the object is stored, the contents of the object can be verified when it is downloaded again or against the original object to verify uploaded object correctness.

Operating systems have a variety of tools for checksum verification. The checksum returned by an object upload (or viewing an object in the bucket) is a Base-64 encoded value. This value may have to be converted to hexadecimal depending on the tools used for checksum comparison.

Networking Security Features

VCN Feature	Security Description
Public and private subnets	A VCN can be partitioned into subnets. Subnets are specific to an availability domain. Instances inside private subnets cannot have public IP addresses. Instances inside public subnets can optionally have public IP addresses at your discretion.
Security rules	Security rules provide stateful and stateless firewall capability to control network access to your instances. To implement security rules in your VCN, you can use network security groups (NSGs) or security lists. For more information, see Comparison of Security Lists and Network Security Groups.
Gateways	Gateways let resources in a VCN communicate with destinations outside the VCN. The gateways include: Internet gateway: For internet connectivity (for resources with public IP addresses in public subnets). NAT gateway: For internet connectivity without exposing the resources to incoming internet connections (for resources in private subnets). Dynamic routing gateway (DRG): For connectivity to your data center network. Service gateway: For private connectivity to Oracle services such as Object Storage. Local peering gateway (LPG): For connectivity to a peered VCN in the same region.
Route table rules	Route tables control how traffic is routed from your VCN's subnets to destinations outside the VCN. Routing targets can be VCN gateways or a private IP address in the VCN.
IAM polices for virtual-network-family	IAM policies specify access and actions permitted by IAM groups to resources in a VCN. For example, IAM polices can give administrative privileges to network administrators who manage the VCNs, and scoped-down permissions to normal users.

Oracle recommends that you periodically monitor Oracle Cloud Infrastructure Audit logs to review changes to VCN network security groups, security lists, route table rules, and VCN gateways.

Network Segmentation: VCN Subnets

Using multiple subnets within a VCN to deploy compute instances is a common strategy for controlling access to the data center network. To do this:

Formulate a tiered subnet strategy for the VCN, to control network access. A common design pattern is to have the following subnet tiers:
1. Public subnet for externally accessible hosts such as NAT instances, intrusion detection (IDS) instances, and web application servers
2. Private subnet for internal hosts such as databases
No special routing is required for the instances in the different subnets to communicate. However, you can control the types of traffic between the different tiers by using the VCN's network security groups or security lists.
Instances in the private subnet only have private IP addresses and can be reached only by other instances in the VCN. Oracle recommends that you place security-sensitive hosts (DB systems, for example) in a private subnet, and use security rules to control the type of connectivity to hosts in a public subnet. In addition to VCN security rules, configure host-based firewalls such as iptables or firewalld for network access control, as a defense-in-depth mechanism.
You can add a service gateway to your VCN to enable DB systems in the private subnet to directly back up to Object Storage without the traffic traversing the data center network. You must set up the routing and security rules to enable that traffic. For more information for bare metal or virtual machine DB systems, see VCN and Subnets in the Base Database section of the Oracle Cloud Infrastructure documentation. For more information for Oracle Exadata DB systems, see Network Setup for Exadata Cloud Infrastructure Instances.

VCN Security Rules and Security Lists

VCN security involves creating and using rules that are gathered into security lists or network security groups (NSGs). The rules can be stateful or stateless. Stateful rules presume various things about an instance interaction. For example, a stateful rule that applies to a request to an instance assumes that there will be a response and automatically allows this response. In contrast, stateless rules do not presume anything about any interactions. There are just messages from one instance to another, and the stateless rules apply to everything regardless of what has gone before. Stateful rules require overhead processing to track states that stateless rules do not. Instances with heavy and widely varied traffic, such as web sites, should use stateless rules where possible to minimize system loads.

Note:

Care is needed when creating stateless and stateful rules. When a message appears that fits both stateful and stateless rule criteria, the stateless rule is applied. This results in responses being blocked to requests that seemingly should be allowed.

Your VCN might have subnets that use the default security list. Do not delete any of the list's default security rules unless you've first confirmed that resources in your VCN do not require them. Otherwise, you might disrupt your VCN's connectivity.

Keep in mind that:

A security rule is stateful by default, but can also be configured to be stateless. A common practice is to use stateless rules for high-performance applications. In a case where network traffic matches both stateful and stateless security lists, the stateless rule takes precedence. For more information about configuring VCN security rules, see Security Rules for the Oracle Cloud Infrastructure.
To prevent unauthorized access or attacks on Compute instances, Oracle recommends that you use a VCN security rule to allow SSH or RDP access only from authorized CIDR blocks rather than leave them open to the internet (0.0.0.0/0). For additional security, you can temporarily enable SSH (port 22) or RDP (port 3389) access on an as-needed basis using the VCN API UpdateNetworkSecurityGroupSecurityRules (if you're using network security groups) or UpdateSecurityList (if you're using security lists). For more information about enabling RDP access, see To enable RDP access in Creating an Instance for the Oracle Cloud Infrastructure. For performing instance health checks, Oracle recommends that you configure VCN security rules to allow ICMP pings. For more information, see Rules to Enable Ping Oracle Cloud Infrastructure.

VCN network security groups (NSGs) and security lists enable security-critical network access control to Compute instances, and it is important to prevent any unintended or unauthorized changes to NSGs and security lists. To prevent unauthorized changes, Oracle recommends that you use IAM policies to allow only network administrators to make NSG and security list changes.

The default security list for a VCN comes without stateless rules: all the default security list rules are stateful. In most cases, the default rules should be changed to allow only inbound traffic from authorized subnets.

The default stateful security list rules are:

Stateful ingress: Allow TCP traffic on destination port 22 (SSH) from authorized source IP addresses and any source port. This rule makes it easy for you to create a new cloud network and public subnet, launch a Linux instance, and then immediately use SSH to connect to that instance without needing to write any security list rules yourself.
Stateful ingress: Allow ICMP traffic type 3 code 4 from authorized source IP addresses. This rule enables your instances to receive Path MTU Discovery fragmentation messages.
Stateful ingress: Allow ICMP traffic type 3 (all codes) from your VCN's CIDR block. This rule makes it easy for your instances to receive connectivity error messages from other instances within the VCN.
Stateful egress: Allow all traffic. This allows instances to initiate traffic of any kind to any destination. Notice that this means the instances with public IP addresses can talk to any internet IP address if the VCN has a configured internet gateway. And because stateful security rules use connection tracking, the response traffic is automatically allowed regardless of any ingress rules.

Note:

The default security list does not include a rule to allow Remote Desktop Protocol (RDP) access. If you're using Microsoft Windows images, make sure to add a stateful ingress rule for TCP traffic on destination port 3389 from authorized source IP addresses and any source port.

The default security list does not include a rule to allow ping requests. If you plan to ping an instance, ensure that the instance's applicable security list includes an additional stateful ingress rule to specifically allow ICMP traffic type 8 from the source network you plan to ping from. To allow ping access from the data center, use 0.0.0.0/0 for the source. Note that this rule for pinging is separate from the default ICMP-related rules in the default security list. Do not remove those rules.

If you decide to use stateless security rules to allow traffic to and from endpoints outside the VCN, it's important to add a security rule that allows ingress ICMP traffic type 3 code 4 from source 0.0.0.0/0 and any source port. This rule enables your instances to receive Path MTU Discovery fragmentation messages. This rule is critical for establishing a connection to your instances. Without it, you can experience connectivity issues.

Instances can send and receive UDP traffic. In some cases, UDP packets might be fragmented on links with smaller MTU sizes. If a UDP packet is too large for the connection size limit, it is fragmented. However, only the first fragment from the packet contains the protocol and port information. If the security rules that allow this ingress or egress traffic specify a particular port number (source or destination), then the fragments after the first one are dropped. If you expect your instances to send or receive large UDP packets, set both the source and destination ports for the applicable security rules to ALL (instead of a particular port number).

On their own, security lists define a set of security rules that applies to all the VNICs in an entire subnet. To use a given security list with a particular subnet, you associate the security list with the subnet either during subnet creation or later. A subnet can be associated with a maximum of five security lists. Any VNICs that are created in that subnet are subject to the security lists associated with the subnet.

Controlling Traffic with Network Security Groups

Security list rules can be gathered into Network Security Groups (NSGs) to make application of sets of rules easier to a grouping of VNICs. NSGs let you define a set of security rules that apply to a group of VNICs of your choice (or the VNICs' parent resources such as load balances or DB systems). The VNICs that belong to a set of Compute Enclave instances that all have the same security posture can use an NSG to apply a set of rules.

To use a given NSG, you add the VNICs of interest to the group. Any VNICs added to that group are subject to that group's security rules. A VNIC can be added to a maximum of five NSGs.

Important:

Oracle recommends using NSGs instead of security lists because NSGs let you separate the VCN's subnet architecture from your application security requirements.

However, you can use both security lists and NSGs together if you want. In fact, there is no requirement to use NSGs. Also, NSGs are not supported by all types of Oracle Private Cloud Appliance services.

Currently, the following types of parent resources support the use of NSGs:

Compute instances: When you create an instance, you can specify one or more NSGs for the instance's primary VNIC. If you add a secondary VNIC to an instance, you can specify one or more NSGs for that VNIC. You can also update existing VNICs on an instance so that they are in one or more NSGs.
Mount targets: When you create a mount target for a file system, you can specify one or more NSGs. You can also update an existing mount target to use one or more NSGs.
DNS resolver endpoint: When you create an endpoint for a private DNS resolver, you can specify one or more NSGs. You can also update an existing endpoint to use one or more NSGs.

For resource types that do not support NSGs, continue to use security lists to control traffic in and out of those parent resources.

Working with NSGs is a three-step process:

Create an NSG.
Add security rules to the NSG.
Add parent resources (or more specifically, VNICs) to the NSG. You can do this when you create the parent resource, or you can update the parent resource and add it to one or more NSGs. When you create a Compute instance and add it to an NSG, the instance's primary VNIC is added to the NSG. Separately, you can create secondary VNICs and optionally add them to NSGs.

You must remove all VNICs from an NSG before deleting an NSG.

Secure Connectivity for VCN Gateways

VCN gateways provide external connectivity (internet, on-premises, or peered VCN) to VCN hosts. See the table at the start of the Networking Security Features section of this guide for a list of the type of gateways. Oracle recommends that you use an IAM policy to allow only network administrators to create or modify VCN gateways.

Carefully consider allowing internet access to any instances. For example, you don't want to accidentally allow internet access to sensitive database instances. In order for an instance in a VCN to be publicly accessible from the internet, you must configure the following VCN options:

The instance must be in a VCN public subnet.
The VCN containing the instance must have an internet gateway enabled and configured to be the routing target for outbound traffic.
The instance must have a public IP address assigned to it, either for an internet gateway to a public subnet (for instances with public IPs), or for a Network Address Translation (NAT) Gateway to a private subnet (for instances with private IPs).
The VCN security list for the instance's subnet must be configured to allow inbound traffic from 0.0.0.0/0, but for the specific destination port and IP protocol only. Or if you're using network security groups (NSG), the instance must be in an NSG that allows that traffic.

For more information about VCN gateway security, see the "Network Security" section in the Oracle Private Cloud Appliance Concepts Guide

DNS Security Features

DNS zones and records are critical for accessibility of web properties. Incorrect updates or unauthorized deletions could result in outage of services, accessed through the DNS names. Oracle recommends that you limit IAM users who can modify DNS zones and records.

Oracle Private Cloud Appliance DNS uses DNSSEC. DNSSEC has vulnerabilities that are discussed at the externalk site on DNSSEC Vulnerabilities.

VCN Security Policy Examples

Here are three examples of security policies for VCNs:

Allow Users to Only View Security Lists
- Your network administrators are the personnel who should have the ability to create and manage network security groups and security lists.
- The first line in the following example policy allows the NetworkUsers group to view security lists and their contents. This policy does not let the group create, attach, delete, or modify security lists.
- The second line lets the NetworkUsers group view the security rules in NSGs, and also view what VNICs and parent resources are in NSGs. The second line does not let the NetworkUsers group change the security rules in NSGs.
```
"Allow group NetworkUsers to inspect security-lists in tenancy"
"Allow group NetworkUsers to use network-security-groups in tenancy"                                    
```
Prevent Users from Creating External Connection to the Internet
- In some cases, you might need to prevent users from creating external internet connectivity to their VCN. In the following example policy, the NetworkUsers group is prevented from creating an internet gateway.
```
"Allow group NetworkUsers to manage internet-gateways in tenancy 
where request.permission!='INTERNET_GATEWAY_CREATE'"
```

Prevent Users from Updating DNS Records and Zones

In the following example policy, the NetworkUsers group is prevented from deleting and updating DNS zones and records.

"Allow group NetworkUsers to manage dns-records in tenancy
 where all {request.permission!='DNS_RECORD_DELETE', 
            request.permission!='DNS_RECORD_UPDATE'}"

"Allow group NetworkUsers to manage dns-zones in tenancy
 where all {request.permission!='DNS_ZONE_DELETE', 
            request.permission!='DNS_ZONE_UPDATE'}"

Useful CLI Commands for VCN Security

In all the following examples, the environment variables $C and $VCN are set to compartment OCID and VCN OCID, respectively.

List open security lists in a VCN

# list open (0.0.0.0/0) security lists in VCN $VCN in compartment $C 
oci network security-list list -c $C --vcn-id $VCN | grep "source" | grep "\"0.0.0.0/0\""

List gateways in a VCN

# list all internet gateways in VCN $VCN in compartment $C 
oci network internet-gateway list -c $C --vcn-id $VCN 
# list all DRGs in compartment $C 
oci network drg list -c $C 
# list all local peering gateways in vcn $VCN in compartment $C 
oci network local-peering-gateway list -c $C --vcn-id $VCN

List route table rules in a VCN

# list route table rules in VCN $VCN in compartment $C 
oci network route-table list -c $C --vcn-id $VCN

Compute Service Security Features

The core feature of the compute service are compute instances and related resources such as instance configurations, instance pools, and custom images. The compute service relies on several services: block volume for boot images and volume expansion, networking for connectivity and object storage for image import.

You should:

Apply restrictive, least privilege access, IAM policies and techniques for block volumes, networks and object storage. This is critical to prevent malicious use of custom images and preventing compute instances from network access and being accessed.
Apply restrictive, least privilege access to the compute service to prevent changes to configuration and deployed resources.

To prevent inadvertent or malicious termination of critical instances (for example, production instances), Oracle recommends that you give INSTANCE_DELETE permissions to a minimal set of groups. Give DELETE permissions only to tenancy and compartment administrators. For instance policy examples, see the Instance Security Policy Examples section of this guide

Instance Metadata Access Control

Instance metadata (located at http://169.254.169.254) provides predefined instance information, such as OCID and display name, and custom fields. Oracle recommends that you limit instance metadata access to privileged users on the instance. The following example shows how to use iptables to restrict instance metadata access to the root user.

iptables -A OUTPUT -m owner ! --uid-owner root -d 169.254.169.254 -j DROP

Instances use link local addresses to access the instance metadata service (169.254.169.254:80), DNS (169.254.239.254:53), and NTP (169.254.169.254:123). You can use host-based firewalls, such as iptables, to ensure that only the root user is authorized to access these IPs. Make sure these operating system firewall rules are not altered.

Instance Network Access Control

There are a variety of best practices for Oracle Linux compute instances that should be followed. Similar restrictions are available on other operating system types.

Security Recommendation	Configuration sshd_config	Comments
Use public-key logins only	PubkeyAuthentication yes	Periodically review SSH public keys in the `~/.ssh/authorized_keys` file
Disable password logins	PasswordAuthentication no	Mitigates password brute-force attacks
Disable root logins	PermitRootLogin no	Prevents root privileges for remote logins
Change SSH port to a non-standard port number	Port <port-number>	(Optional) Verify the change does not break applications using port 22 for SSH.

In addition:

Harden secure shell (SSH) on all instances. The following table shows some SSH security recommendations. SSH configuration options can be set in the sshd_config file (located at /etc/ssh/sshd_config in Linux).
Use secure SSH private keys to access instances and to prevent inadvertent disclosures. For more information about creating an SSH key pair and configuring an instance with the keys, see Managing Key Pairs on Linux Instances.
To limit instance access to authorized IP addresses, use VCN network security groups or security lists. Fail2ban is an application that blocklists IP addresses involved in brute-force sign-in attempts (that is, too many failed attempts to sign in to an instance). By default, Fail2ban inspects SSH accesses, and you can configure it to inspect other protocols. For more information about Fail2ban, see fail2ban on GitHub.
In addition to VCN network security groups and security lists, use host-based firewalls, such as iptables and firewalld, to restrict network access to instances by controlling ports, protocols, and packet types. Use these firewalls to prevent potential network security attack reconnaissance, such as port scanning and intrusion attempts. Custom firewall rules can be configured, saved, and initialized on every instance boot.

The following example shows commands for iptables:
```
# save iptables rules after configuration 
sudo iptables-save > /etc/iptables/iptables.rules 
# restore iptables rules on next reboot 
sudo /sbin/iptables-restore < /etc/iptables.rules 
# restart iptables after restore 
sudo service iptables restart            
```

Instance Entropy

Instances have random number generators whose output is fed into the entropy pools used by the operating system to generate random numbers. In Linux instances, /dev/random is non-blocking and should be used for security applications requiring random numbers. You can use the following commands to check the throughput and quality of the random numbers generated by /dev/random before using the output in applications.

# check sources of entropy 
sudo rngd -v 
# enable rngd, if not already 
sudo systemctl start rngd 
# verify rngd status 
sudo systemctl status rngd 
# verify /dev/random throughput and quality using rngtest 
cat /dev/random | rngtest -c 1000

Host Security Hardening and Patching

Establish a baseline for security hardening of Linux and Microsoft Windows images running on instances. For more information about security hardening of Oracle Linux images, see Tips for Hardening an Oracle Linux Server. The Center for Internet Security Benchmarks provides a comprehensive set of operating system security hardening benchmarks for various distributions of Linux and Microsoft Windows Server.

Keep instance software up to date with security patches. Oracle recommends that you periodically apply the latest available software updates to your instances.

Caution:

Only install patches from the pca* channels. Manually updating the appliance using other channels and other methods is not supported. Security and other updates to OL7 will come through the pca* channels. For more information, see Configure Your Environment for Patching in the Oracle Private Cloud Appliance Administrator Guide.

For Oracle Linux images, check the yum and dnf configuration and make sure that repositories and software streams can be reached from the VCN.

Update the compute instance. For more information on software updates for Oracle Linux 7 and Oracle Linux 8, see (Getting Started with Oracle Linux Yum Server).

If a new image needs to be created based on an updated instance, see the section "Creating an Image from an Instance" in the Compute Images chapter of the Oracle Private Cloud Appliance User Guide.

Instance Security Logging and Monitoring

Various security-related events are captured in log files on each compute instance. Oracle recommends that you periodically review these log files to detect any security issues. In Oracle Linux, the log files are located in /var/log. Some security-relevant log files and their locations are listed in the following table.

Log File or Directory	Description
`var/log/secure`	Authorization log showing failed and successful sign ins.
`var/log/audit`	Auditd logs capturing system calls issued, `sudo` attempts, user sign-ins, and so on. `ausearch` and `aureport` are two tools used to query auditd logs.
`var/log/yum.log`	Lists packages installed or updated on instances with yum.
`var/log/cloud-init.log`	During instance boot, cloud-init can run user-provided scripts as a privileged user. For example, `cloud-init` can introduce SSH keys. Oracle recommends that you review the `cloud-init` logs for any unrecognized commands.

Instance Security Policy Examples

In all the following examples, the policies are scoped to a tenancy. However, by specifying a compartment name, they can be scoped down to specific compartment in a tenancy.

Restrict Users Ability to Delete Instances

The following example allows the InstanceUsers group to launch instances, but not to delete them.

"Allow group InstanceUsers to manage instance-family in tenancy
 where request.permission!='INSTANCE_DELETE'"
"Allow group InstanceUsers to use volume-family in tenancy"
"Allow group InstanceUsers to use virtual-network-family in tenancy"

Restrict Ability to Use Instance Console

For security compliance reasons, some customers do not want to expose the instance console to users in their tenancy. The following policy example restricts ability to create or read from consoles.

"Allow group InstanceUsers to manage instance-console-connection in tenancy
 where all {request.permission!= INSTANCE_CONSOLE_CONNECTION_READ, 
            request.permission!= INSTANCE_CONSOLE_CONNECTION_CREATE}"

Block Volume Security Features

There are two types of volumes: block volumes and boot volumes. Block volumes allow instance storage capacity to be expanded dynamically. A boot volume contains the image used to boot a compute instance.

The IAM service groups the family of related volume resource types into a combined resource type called volume-family.

In addition, block volumes:

Are encrypted on disk (at rest) using Advanced Encryption Standard (AES) 128-bit algorithm. Encryption is on by default and cannot be turned off. The encryption keys are themselves encrypted with a master encryption key.
Volumes can be further encrypted using tools like dm-crypt, veracrypt, and Bit-Locker.
Users that are authenticated to the Oracle Private Cloud Appliance have the ability to manage volumes and to manage resources within the security policy framework.

Assign least privilege access for IAM users and groups to resource types in volume-family. The resource types in volume-family are volumes, volume-attachments, and volume-backups.

Block Volume Data Durability

Block volumes are stored in a ZFS file system with a SHA-256 checksum to avoid phantom reads and detect invalid data returned from devices.

To minimize loss of data due to inadvertent deletes by an authorized user or malicious deletes, Oracle recommends giving VOLUME_DELETE, VOLUME_ATTACHMENT_DELETE and VOLUME_BACKUP_DELETE permissions to a minimum possible set of IAM users and groups. DELETE permissions should be given only to tenancy and compartment administrators.

To minimize loss of data due to deletes or corruption, Oracle recommends that you make periodic backups of volumes. Oracle Cloud Infrastructure allows automated scheduled backups. For more information about scheduled backups, see Policy-Based Backups.

Block Volume Security Policy Examples

Prevent Delete of Volumes

The following example policy allows group VolumeUsers to perform all actions on volumes and backups, except deleting them:

"Allow group VolumeUsers to manage volumes in tenancy
 where request.permission!='VOLUME_DELETE'"
"Allow group VolumeUsers to manage volume-backups in tenancy
 where request.permission!='VOLUME_BACKUP_DELETE'"

If VolumeUsers can't detach volumes from instances, you can add the following policy to the previous example:

"Allow group VolumeUsers to manage volume-attachments in tenancy
 where request.permission!='VOLUME_ATTACHMENT_DELETE'"

Encrypting Non-root Volumes with dm-crypt

dm-crypt is a kernel-level encryption mechanism (part of Linux device mapper framework) to provide encrypted volumes. It encrypts data passed from the filesystem (for example, ext4 and NTFS ), and stores it on a storage device in Linux Unified Key Setup (LUKS ) format. The encrypted volumes can be stored on a complete disk, disk partition, logical volume, or a file-backed storage created using loopback devices. cryptsetup is the user-level utility used to manage dm-crypt, and used to encrypt partitions and files. dm-crypt uses the Linux crypto APIs for encryption routines.

To encrypt the volume:

Attach block storage volume to an instance (for example, /dev/sdb).
Format /dev/sdb for LUKS encryption. Enter LUKS passphrase when prompted. The passphrase is used to encrypt the LUKS master key used for encrypting the volume.
```
cryptsetup -y luksFormat /dev/sdb
```
Verify that the LUKS formatting is successful.
```
cryptsetup isLuks /dev/sdb && echo Success
```
Get encryption information about the device.
```
cryptsetup luksDump /dev/sdb
```
Get LUKS UUID of the device. The UUID value is used to configure the /etc/crypttab.
```
cryptsetup luksUUID /dev/sdb
```
Create a LUKS container with device name, dev_name. This also creates a device node, /dev/mapper/<dev_name>.
```
cryptsetup luksOpen /dev/sdb <dev_name>
```
Get information about the mapped device.
```
dmsetup info <dev_name>
```
Format the device node as ext4 filesystem.
```
sudo mkfs -t ext4 /dev/sdb 
```

Mount the device node.

mount /dev/mapper/<dev_name> /home/encrypt_fs

Add an entry to /etc/crypttab.
```
<dev_name> UUID=<LUKS UUID of /dev/sdb> none
```
All the files copied to /home/encrypt_fs are encrypted by LUKS.
Add a keyfile to an available keyslot of the encrypted volume. This keyfile can be used to access the encrypted volume.
```
dd if=/dev/urandom of=$HOME/keyfile bs=32 count=1
chmod 600 $HOME/keyfile
cryptsetup luksAddKey /dev/sdb ~/keyfile
```
Verify the encryption status of files.
```
cryptsetup status /home/encrypt_fs
```

Unmount after you're finished.

umount /home/encrypt_fs
cryptsetup luksClose <dev_name>

To access the encrypted volume:

cryptsetup luksOpen /dev/sdb <dev_name> --key-file=/home/opc/keyfile
mount /dev/mapper/<dev_name> /home/encrypt_fs

If you lose the keyfile, or if the keyfile or passphrase gets corrupted, you can't decrypt the encrypted volume.

Oracle recommends that you store durable copies of the keyfile on an on-premises host.

Remote Mounting of dm-crypt Encrypted Data Volumes

The following steps assume that the keyfile is on an on-premises host (SRC_IP) and that <OCI_SSH_KEY> is the SSH private key of the instance.