Illustrative EU-based Organization Case Study

While the details of the various features are informative, it is helpful to illustrate the implementation of environments with examples. In the examples below, we introduce the concept of a sub-SC user.

A sub-SC user has the following characteristics:

• Directly related to the customer entity by either organization or treaty and has a governmental or commercial relationship with the customer entity.
• Contained fully within the EU and is subject to at least the same data protection and sovereignty requirements as the customer entity itself.
• They are not simply organizational groups within the customer itself but are entities in their own right. This could be a government division or a subsidiary of a commercial corporate entity. They might have a superset of requirements around data protection and classification but cannot drop below the minimum requirements of the customer entity itself. For example, if an example customer maintained a set of compartments and resources for itself but provided sub-SC users with access, the customer would maintain control over the resources deployed by the sub-SC user in accordance with the sub-SC user's particular legal framework.

This case study uses a hypothetical situation where the customer wants to provide a set of cloud services to a set of subsidiary organizations or sub-SC users, including the ability for those sub-SC users to host their own services that interact with the global services provided by the customer itself. The customer would control the tenancy in terms of costs, assignment of compartments within the overall tenancy, and the creation of global groups for the management of the tenancy. However, each sub-SC would have their own environment that is defined by compartment spaces that they "own" and are fully controlled by their user base and they provide via an identity domain. Within the child or "root" compartments of each sub-SC, additional compartments can be created and resources deployed.

The sub-SC compartments would be exclusive to each sub-SC user, with no other sub-SC user having visibility to the compartment structure, resources, or activities of other sub-SC users. Audit logs and other auditing and compliance activities occur at the customer level but are made visible to each identity domain—filtered by their individual "root" compartment and restricted based on their identity membership for visibility. This would allow both the customer and the individual sub-SC user to audit for cost, compliance, and threat detection independently. Resources created would be at the discretion of both the customer (for their own compartments) and each sub-SC user and could be restricted by OCI Compartment Quotas and Budgets features in EU Sovereign Cloud.

Sample Security Model

The security model for this example is illustrated in the diagram below:

Description of the illustration iam-security-model.png

iam-security-model-oracle.zip

Here, the customer establishes a tenancy and builds both a set of compartments for their own use (the "Division" compartments) and a set of base compartments for use by each sub-SC member. As each sub-SC user signs up to use resources within the tenancy, an identity domain would be created around the specific upper-level compartment created for the sub-SC user. The sub-SC user could then federate their own user base to their individual identity domain and allocate permissions independent of those allocated by the customer. These domains could operate as quasi-independent entities, with relationships that are defined based on joint agreement.

Data Protection Use Case

The sub-SC user would have several non-exclusive options for initiating data protection using EU Sovereign Cloud. First would simply be to use the existing data protection model illustrated above. The sub-SC identity domain is transitory across the tenancy as a whole; in other words, since the identity domain is a tenancy-wide resource, access options are available in both regions based on the policies established for the tenancy as a whole.

Compartments also follow this model. This allows each sub-SC user to perform data replication by using the individual resources created within their own compartments—across two data regions—to act as replication targets or sources. This allows the use of active/active and active/passive models of data protections, depending on the ability of individual applications deployed by the sub-SC and the RTO/RPO tolerance of those that cannot work in active/active. Data protection would be independent and isolated from the view of other sub-SC users. It would be observable by the customer that provides the baseline services by virtue of the fact that the replication exists, but not by observing the data itself. Backup and/or snapshot services are available for use by the sub-SC user (in the case of Block Storage and Object Storage) and would be localized to the Identity Domain/Compartment of each sub-SC user—inaccessible by other sub-SC users.

Alternatively, each sub-SC user could use third-party or local (within the physical boundaries of the sub-SC environment) resources as data protection targets. This would be accomplished by the establishment of private FastConnect or CPE VPN connections to compartment(s) within the control of the sub-SC-user. The data connection would be completely isolated from the other sub-SC user and from the customer as each connection point would exist exclusively within the Identity Domain/Compartment structure of the sub-SC user itself. This model would allow the protection and extraction of data back to either a third party, outside of the control of the customer, to a local data repository located within the physical confines of the sub-SC environment, or a combination thereof, depending on the needs of the individual sub-SC user.

Description of the illustration security_structure_overview.png

security_structure_overview-oracle.zip