About OCI Architecture and Best Practices
EU Sovereign Cloud provides the following unique capabilities to OCI customers:
- Data protection via service protection and data replication
- Access models via virtual networking
- Security Models via IAM
- Auditing compliance modeling and governance
Each of these models provides specific mechanisms that taken in totality offer customers the capabilities to strengthen the sovereignty of their cloud environment.
Data Protection
Data protection within EU Sovereign Cloud is approached from several different perspectives:
- Access: Limiting access to data in order to prevent unauthorized use.
- Intra-EU data replication: Establishing copies of data in two different physical locations (regions) while remaining within the boundaries of the EU.
- Replication path does not leave the EU: The replication connection between regions is completely contained within the EU—data transmission between EU Sovereign Cloud regions occurs across a dedicated backbone established for EU Sovereign Cloud and does not leave the EU during transit.
- Local encryption keys: Data storage and encryption are managed either by EU Sovereign Cloud generated keys maintained within the EU, or with customer provided keys. Customer provided keys are stored within a key management service (KMS) that physically resides within the EU, and is completely controlled by the customer.
- Local certificate authorities: With OCI Certificates service, tenants can perform all actions associated with certificate issuance and management. This includes the import of third-party root certificate authority (CA) that can be distributed internally to resources within EU Sovereign Cloud, without traversing the internet. These certificates can then be applied to SSL and other uses to establish strong, locally-verifiable encryption between sites.
Get Started with Data Protection
To get started with data protection methods, do the following:
- Use Oracle Cloud Stacks to build standardized infrastructure in two EU Sovereign Cloud data regions.
- Build a cross-region link for the infrastructure using Dynamic Routing Gateways (DRGs) to connect region networks together securely.
- Establish replication between both sites using tools such as Data Guard, Object Storage Cross-Region replication, and application-based replication tools to protect data hosted in EU Sovereign Cloud.
- Build an OCI Vault inside EU Sovereign Cloud for critical secrets and keys and replicate the Vault to the second data region.
- Upload certificates to the OCI Certificates service and use the service endpoint for certificate loading and validation.
Replicate Data to Another Location
One of the most common strategies to ensure data protection is to replicate data to another location for long-term storage by using a hot/warm site.
Ideally, replication occurs over a link that is as direct as possible to the source and could be used for both data protection and inter-site communications to optimize the cost of the link. In the case of the EU, the data link itself should not have a path that allows the data to leave the EU.
Description of the illustration mad-fra-region.png
EU Sovereign Cloud offers data protection mechanisms and OCI services that can help you meet data replication and transit requirements. Oracle has established the EU Sovereign Cloud data regions with service parity that allows you to mirror the implementation of both storage and applications. Storage and applications can be replicated to the other EU Sovereign Cloud data region over a dedicated backbone link, with confidence that the capabilities and available services are the same. This dedicated backbone is also used for management traffic between the EU Sovereign Cloud regions and a large portion of the bandwidth is available for tenant use within EU Sovereign Cloud. In all cases the customer data traffic that flows over this backbone is both isolated from other realms and regions that are not part of EU Sovereign Cloud.
Encrypt Data
The OCI Vault service provides this feature. Vault can be implemented either as a multi-tenant software-based KMS or as a dedicated HSM modules. In either case, Vault is exclusively located within the EU Sovereign Cloud realm, and Oracle has no ability to access keys or secrets stored within either the software vault or dedicated HSM. Data encryption activities are also located exclusively within EU Sovereign Cloud, with each region maintaining its own independent Vault implementation. The key encryption algorithms that OCI Vault supports include the Advanced Encryption Standard (AES), the Rivest-Shamir-Adleman (RSA) algorithm, and the elliptic curve digital signature algorithm (ECDSA). Customers can create and use AES symmetric keys and RSA asymmetric keys for encryption and decryption or use RSA or ECDSA asymmetric keys for signing digital messages.
Encrypt Connections to Data Consumers
It is also important to consider not only the encryption of data at rest, but also the ability to encrypt connections to consumers of data, particularly over protocols such as HTTPS.
In many instances, x.509 certificates are handled either through external sources or via dedicated servers that generate local certificates for use internally. EU Sovereign Cloud offers the OCI Certificates service that enables customers to create local certificates for internal and external applications, import third-party certification bundles for distribution, and manage the certifications installed in the service, such as key rotation. All tasks associated with managing certificates (addition, rotation, deletion, and so on) can be done from a central service that is entirely located within EU Sovereign Cloud.
Integrate with OCI Load Balancer
Access Model
The mechanisms already built into the OCI architecture also enable EU Sovereign Cloud to provide effective network packet filtering, access controls, directed connectivity, and ultimately an effective way of limiting access to deployed resources and applications only to network addresses located in the EU.
Get Started with Access Model
To get started quickly implementing an access model, do the following:
- Implement a virtual cloud network (VCN) design using a defense in depth approach. Only use public subnets in the VCN when needed for external access.
- Build a DMZ to filter traffic using public and private subnets.
- Use the OCI Network Firewalls (NFW) service to control and monitor access to critical subnets, including all public ones.
- Build Security Lists per subnet to restrict intra-subnet access.
- Implement Network Security Groups (NSGs) at each instance/endpoint to tightly control the source of access.
- Enable VCN Flow Logs periodically to audit traffic.
- Implement the OCI domain name system (DNS) to control address resolution and to filter undesirable DNS domains without affecting accepted ones.
- Use point connections, such as FastConnect and CPE Configuration, to establish administrative backhauls that do not use the public internet.
Use Security Lists, Network Security Groups and Network Firewalls
The capabilities of native OCI services such as Network Firewall (NFW), Security Lists (SL), and Network Security Groups (NSG), combined with Virtual Cloud Network (VCN) flow logs, provide strong mechanisms to both prevent and detect accesses from non-EU origination points.
One of the primary methods to ensure that EU-specific ranges of public IP addresses have access to resources is by using a combination of SLs, NSGs and the NFW. By way of background, all access to instances/resources attached to OCI subnets is "deny all" by default. This policy also prevents instances on the same subnet from intercommunicating. Access must be explicitly granted to initiate and respond to connections by resources within a particular subnet or across subnets in the VCN. The primary way of accomplishing this is through SLs. These are subnet-level definitions of allowed connectivity one can specify by protocol, port, and CIDR range. Connections that fall outside of the defined ranges are silently dropped. NSGs accomplish some of the same tasks but are applied at the virtual NIC (VNIC) layer and not to the subnet as a whole. By using a combination of SLs and NSGs, a EU Sovereign Cloud customer can create a restricted zone of access to resources that accepts only addresses from specified EU public IP ranges. If the customer extends those limits to individual resources, such as Load Balancers, Compute instances, Bastions, and so on, a targeted access pattern can be implemented to meet the needs of the organization. Lastly, the NSGs and SLs are bidirectional, meaning that both internal and external connectivity rules can be established independently of one another. With this feature, even if an inbound connection is made, either by design or by a misconfiguration of the inbound rules, the external connection still needs to be allowed in order for the full session to be established.
Implement a "Front Door" to Resources on VCNs
EU Sovereign Cloud also offers a Palo Alto-based Network Firewall service that allows implementation of a variety of services and restrictions as a "front door" to resources found on VCNs, such as:
- Stateful network filtering
Stateful network filtering creates stateful network filtering rules that allow or deny network traffic based on the source IP (IPv4 and IPv6), destination IP (IPv4 and IPv6), port, and protocol.
- Custom URL and FQDN filtering
Custom URL and FQDN filtering restricts ingress and egress traffic to a specified list of fully qualified domain names (FQDNs), including wild cards and custom URLs.
- Intrusion Detection and Prevention (IDPS)
Intrusion Detection and Prevention (IDPS) monitors your network for malicious activity and blocks suspicious network traffic from reaching the internal network.
- SSL inspection
SSL inspection decrypts and inspects TLS-encrypted traffic with ESNI support for security vulnerabilities. Encrypted Server Name Indication (ESNI) is a TLSv1.3 extension that encrypts the Server Name Indication (SNI) in the TLS handshake.
- Intra-VCN subnet traffic inspection
Intra-VCN subnet traffic inspection routes traffic between two VCN subnets through a network firewall.
- Inter-VCN traffic inspection
Inter-VCN traffic inspection routes traffic between two VCNs through a network firewall.
Description of the illustration access-model-arch.png
- The NFW rejects the connection based on the ruleset defined by the customer and the connection attempt is logged.
- The NFW accepts the connection and routes the connection to the appropriate instance in the protected subnet. The SL allows this connection from this subnet, and the NSG on the instance has a rule that allows connections from the NFW.
- The instance in subnet A attempts a connection to an instance. While the SL allows connections from subnet A, the instance's NSG prevents the connection.
- The instance in subnet A attempts another connection to a different instance. Here, both the SL and the NSG allow the connection
- The instance in subnet B attempts a connection to an instance. The subnet B has not been granted access to the protected subnet, so no connection is allowed, regardless of the instance's NSG.
Control and Determine Appropriate Name Resolution
Additionally, the ability to control and determine appropriate name resolution sources is a mechanism that can determine connectivity and provide name resolution and relay in a deterministic manner to defined DNS endpoints.
The EU Sovereign Cloud environment inherits the OCI DNS service, allowing you to tightly control both endpoints used within EU Sovereign Cloud, as well as the sources to which requests are forwarded. OCI DNS service accomplishes this by splitting the DNS listener endpoint from the forwarder, with a rules engine embedded between the two. This allows you to define set rules on the direction of DNS requests, potentially to different forwarders based on the domain requested. The request for domain lookups determined to be outside of the ruleset or the selection of multiple forwarders that point to different DNS sources, depending on the outcome of the rules engine, will return NX_DOMAIN response for purposeful null redirects. Customers can be very deliberate on the DNS resolution response of both internal EU Sovereign Cloud and external EU Sovereign Cloud and provide a filtering mechanism.
Description of the illustration valid-vs-invalid-dns-request.png
Provide EU Sovereign Cloud Customers Less Restricted Access to the Environment
EU Sovereign Cloud customers might need to have less restricted access to the environment than the public consumers of the services provided by EU Sovereign Cloud tenancy owners. This type of access is accomplished by the same direct connection types found in the OCI public cloud.
- FastConnect
FastConnect is a direct multiprotocol label switching (MPLS) link to EU Sovereign Cloud Points of Presence. These links are not shared with any other consumer of EU Sovereign Cloud and are dedicated to the particular tenancy to which they are assigned
- Customer Premises Equipment (CPE)
CPE is a VPN connectivity model for customers to implement lower bandwidth, remote office-style private connectivity to EU Sovereign Cloud without having to invest in the infrastructure required for the dedicated MPLS links.
These access features allow users of EU Sovereign Cloud to create "walled gardens" of resources for use exclusively within the EU, as shown here:
Description of the illustration walled-garden.png
The NFW provides the first-level access detection, rejection and logging support, with the SLs providing a second-level restriction on access to resources within a particular subnet. The NSGs further restrict access on a resource-by-resource basis. Both the SLs and the NSGs can have bidirectional rulesets that would restrict the outbound IP address/port ranges. However, in this particular case, data, maintenance, and administration would be provided to the tenant resource via the FastConnect connection, which is also limited by the SLs and NSGs. The rulesets defined within both features would also apply to the connections over the FastConnect. Resolution of outbound connections, either for initiation or to validate domain membership of inbound connections, is performed via a combination of DNS listeners/forwarders that point to specific DNS resolution sources. Together, these features allow for the creation of a public-facing, controlled access service portal, with data management and maintenance performed "out of band" and limited to the EU.
Security Model
OCI uses the Identity and Access Management (IAM) service to provide security around management "of the cloud". IAM focuses on ensuring that operators of tenancies within a particular realm can be limited in their actions within the tenancy.
Get Started with the Security Model
To get started with the security model, do the following:
- Build security access models to “manage the cloud” versus those required to “manage within the cloud”. Create a small number of trusted users in Identity and Access Management (IAM) for management of the cloud.
- Implement identity federation to unify organizational access. Use separate groups for EU Sovereign Cloud within the federation to limit access to EU-based persons.
- Keep identities unique between EU Sovereign Cloud and non-EU Sovereign Cloud IAM accounts. This cuts down on administrator confusion when administering environments.
- Create OCI compartments for provisioned resources based on functional and organizational boundaries.
- Build Identity Domains for sub-organizations to self-administer their local environments.
- Create a “sub-sovereign cloud” (sub-SC) environment with Cloud Guard to monitor IAM policies.
About the Security Model
Description of the illustration security_structure_overview.png
security_structure_overview-oracle.zip
IAM only spans the realm in which the tenancy itself exists. In this particular case, EU Sovereign Cloud operates within a single realm currently consisting of regions physically located within the EU. As such, any accounts created within EU Sovereign Cloud tenancies can only operate on the management of resources within the realm itself and can only operate on resources within the EU. User accounts have no context outside of the realm and, even if a user has identical user credentials in another realm, there is no inbound context within EU Sovereign Cloud.
EU Sovereign Cloud cloud operation accounts are completely isolated within the realm. The combination of OCI’s realm architecture, EU resident support and operations, and the EU legal entity structure natively enforce the isolation of the EU Sovereign Cloud realm. No additional end-user configuration is required to ensure that EU Sovereign Cloud operates independently from other OCI realms.
Description of the illustration iam-2-user.png
IAM offers both local accounts, maintained within the realm, and federated accounts that are either tied to Identity Cloud Service (IDCS) or other SAML2 federation mechanisms. Access to the deployment and management components of your EU Sovereign Cloud tenancy can be tightly controlled and only allow those accounts vetted as EU-based to manage the environment. Also, since this is a federated account management system, the same federation used for EU Sovereign Cloud can be used for access to the compute resources deployed within the tenancy. This means creating a unified environment where a fully auditable access method can be deployed to both the management "of the cloud" and the resources "in the cloud".
Description of the illustration idp-vs-iam.png
In addition to the federated account capabilities, EU Sovereign Cloud provides the ability to create identity domains (ID) within the tenancy. An ID is essentially the partitioning of the IAM space, with a secondary set of designated administrators who do not have visibility into the upper layer of the domain and can create their own set of access policies and control their own resources. The upper-level owner of the tenancy can still influence control over overall resource and IAM administration. Combining the ID with an upper-level (non-root) compartment would allow the members of an ID to create a complete environment that has no knowledge of any of the environments surrounding it. With this set of tools, an organization within the EU could create what we will call a "sub-SC" environment. That is, an environment that maintains the properties of the original tenancy, but allows for the creation of a secondary environment with its own policies and restrictions on membership.
The concept of the sub-SC is described further in the illustrative case studies below. The sub-SC environment can also be limited, controlled, and audited by implementing Cloud Guard in the tenancy. When applied in this situation, Cloud Guard can prevent compartments assigned to a particular sub-SC and controlled by a set of users defined within an identity domain from performing actions that would either be counter to ensuring the continued protection of hosted data and/or performing actions that would violate security policies within the environment. In addition to Cloud Guard, EU Sovereign Cloud offers Security Zones, which provide templated, compartment-targeted policy sets that can be uniformly applied. Security Zones can be, and frequently are, implemented to augment the Cloud Guard configurations.
The state, content, and EU Sovereign Cloud service inventory are not advertised in any way outside of the realm.
Auditing and Governance
EU Sovereign Cloud features and capabilities provide active measures to ensure that EU-based personnel manage the environment and that data is protected and remains within the EU. However, without mechanisms to review those measures and document compliance, providing assurances to outside entities is difficult.
Get Started with Auditing and Governance
To get started with auditing and governance activities, do the following:
- Use the OCI Audit service to monitor and generate enforcement actions of governance and compliance models.
- Implement the OCI Logging Analytics service to perform advanced analytics against the data generated by the OCI Audit service.
- Build policies using Threat Intelligence and Cloud Guard to proactively prevent actions and access by unwanted actors.
- Use the OCI Tagging service to create a tag namespace to correspond with organizational structure and/or cost models. Tag all resources with key/value pairs from the namespaces for audit and/or chargeback.
- Set up quotas within tenancies and Compartments to prevent runaway resource consumption.
- Use the OCI Budgets and Cost Analysis services to predict, monitor, and control costs.
About Services and Features for Monitoring Adherence to Your Data Sovereignty Requirements
OCI offers additional services and features customers can use to monitor adherence to your organization's data sovereignty requirements. Cost controls and management can be used as a tool to audit compliance with resource spend, detect threats, and ensure that tenancies remain within established specifications.
- Audit
OCI Audit records the time, source, target and type of action for OCI services available in EU Sovereign Cloud. Activities such as compute instance creation, VCN operations, and others are logged for designated individuals to monitor and audit the environment you have set up in EU Sovereign Cloud.
- Logging Analytics
This feature allows the customer to take logs gathered by using the Audit service and create different views and visualizations in order to meet organizational requirements. Logs from other sources can also be ingested to provide a complete view of the environment for full auditing and analysis.
- Threat Intelligence (with Cloud Guard)
Threat Intelligence takes input from various sources and manages the data to provide actionable guidance for threat detection and prevention in Cloud Guard and other OCI services. Cloud Guard allows you to implement standardized actions ("recipes") that can proactively respond to potential threats.
- Tagging
While the previous entries are active mechanisms to prevent, detect, and act on active threats, other elements of auditing and compliance focus on tracking utilization and cost. EU Sovereign Cloud provides mechanisms to assign tags to resources upon provisioning and to fix the value(s) and format of the tags prior to assignment. These tags can be queried against through the API, reported on in cost tracking and billing, and acted upon by using IAM policies associated with specific resources and instances. Use Tagging to assign multiple tags to the same resource and look at the consumption of resources from multiple perspectives. For instance, a compute resource may have a tag indicating the general use of the resource, a group using the resource (for example, development), a cost center for the resource, or any other dimensions that might be of interest.
- Compartment Quotas
You can set resource quotas based on the compartment in which the resource is located. Quotas can limit the number and/or scope of the resource defined in the quota definition to a particular compartment, region, or AD.
- Budgets
Budgets are a tool that allows customers to set up alerts based on a current spend limit, a predictive spend ceiling, or both, based on the intent of the alert. Base budget alerts on cost-tracking tags, the compartment, the resource, or both.
- Cost Analysis
The Cost Analysis tool helps you break down current consumption costs across dimensions. View costs through a combination of vectors such as tenancy, EU Sovereign Cloud region, compartments, and resource tags, as well as on specific resources, services, and SKUs consumed. Reports can be filtered down to individual resources when applicable. You can also forecast future usage based on past consumption patterns using this tool. The data is extensible to dashboards and accessible via APIs. You can also schedule a cost report to run on a regular cadence and deliver the results to an Object Store bucket. These reports can be stored for historical reference and exported to a data warehouse for long-term trend analysis and processing.