Baseline Governance Lifecycle

Organize Resources

Whether you provision single or multiple applications, make sure you organize the resources for growth, flexibility, and accountability that is required to maintain control in the tenancy.

Organize resources based on the following:

Compartments: A compartment having a specific recipe for an organization
Resource Location: A region based on where the target audience is located
Resource Isolation: Appropriate network controls such as Virtual Cloud Network (VCN) and Subnet

Compartment Design

The following image shows you an example of how you can organize your resources in compartments to achieve certain outcomes.

Description of the illustration oci-governance-compartment-design.png

Each organization can use a compartment structure recipe specific to the outcomes they require. You can use the available predefined templates as a foundation to build your organizations structure. The OCI CIS Landing Zone provides a broad compartment structure template covering Network, Security, Applications, and Database resources. You can extend the compartment structure to add separate child compartments to various applications or for different lifecycle environments (Dev, Test, Prod). Get the CIS Landing Zone template images here.

Hierarchical Compartments Model

Defines at what policies you must define at different levels of the compartment hierarchy beginning at the Root level.

Root level

Define IAM policies

Level 1

Define network, shared-security, app-dev, and database policies

Level 2

Define Prod, Non-Prod, prototype policies:

Network: Network family
- Prod and Non: Prod VCN and Prod Subnets
Shared-security: KMS, Logging, Notifications, Vaults
App-Dev: OS buckets, Boot and Block Volume, FSS
- Prod: Prod OAC, OIC, FAW
- Prototype: All prototype services
Database: Prod AWD, Non-Prod ADW

Developing an effective compartment design is essential in building a governance model. Compartment design can be changed at any time to align when business or process changes occur in your organization. In addition, resources provisioned in OCI can be moved from one compartment to another.

Resource Geographic Location

You must create resources in a geographic region and select the region based on where the target audience is. An application for European customers must reside in a data center in the European region. Within a region, application resources should be spread across availability domains and fault domains to achieve the highest availability. For every resource or workload, you must choose the appropriate region based on several criteria.

Resource Network Isolation

You can't use compartments to isolate resources. You can isolate resources using networking controls. You must organize resources in different VCNs and Subnets to isolate resources. Include resources belonging to the same application in the same VCN and resources from different applications in different VCNs. If two applications need to communicate with each other, you can either share a VCN or pair the two VCNs.

Govern Resource Identity

Establishing identity of an employee is essential for effective resource governance.

Description of oci-identity-governance.png follows

Description of the illustration oci-identity-governance.png

Identity Governance Scenario

When a new hire joins an organization, the HR system creates a user identity and provisions a set of centralized and policy-based identities and their entitlements. The new user gets default access to certain resources and applications known as birth-right entitlement provisioning. Then, depending on the user's organization, group, and role, the user is given access to additional applications and entitlements.

The user can request additional entitlements that go through an approval process to get themselves assigned to those entitlements. When the user retires or leaves the organization, the identity is deprovisioned. If the same user is rehired in the organization, the user can usually claim the same identity but can have different entitlements depending on the group or role they were hired in.

Identity in the Cloud

Description of oci-identity-cloud.png follows

Description of the illustration oci-identity-cloud.png

Oracle offers unified identity across IaaS, PaaS, and SaaS using Oracle Cloud Infrastructure Identity and Access Management (IAM). The unified identity to connect all the OCI IaaS and PaaS services have native integrations with OCI IAM. They use OCI IAM both as a user store and a login service. However, SaaS services on OCI, including Fusion SaaS services, integrate with OCI IAM using SCIM 2.0 and SAML standards. Customers can also integrate PaaS services with SaaS using IAM OAuth. They can integrate Oracle Cloud with on-premises or third-party cloud using open standards like SCIM 2.0, SAML, and OIDC.

The unified identity service streamlines the user onboarding and offboarding processes. When a user account is created or removed from the HR system, OCI IAM creates or removes the user account from all Oracle services. The OCI IAM service can also facilitates user account creation and removal from third-party cloud services.

OCI IAM provides a single source of truth for identities in Oracle Cloud. Customers can leverage IAM audit logs to see who has access to cloud systems or resources. They can also run security threat modeling to detect unauthorized access and take corrective measures.

Govern Resource Access

OCI has a deny-by-default security posture. When a tenancy is provisioned, no user other than the tenancy administrator user can access any resources in OCI.

Tenancy administrators can create policies to grant permissions to groups of users on resources within compartments or the tenancy. The following are some sample IAM policies that you can use as a starting point for the compartment structure proposed in the Compartment section.

Create policies to allow compartment admins to manage all resources in the respective compartment.

Allow group security_admin to manage all resources in compartment Shared_Security:Prod
Allow group security_admin to manage all resources in compartment Shared_Security:NonProd
Allow group network_admin to manage network-family-resources in compartment Network
Allow group database_admin to manage database-family-resources in compartment Database
Allow group appdev_admin to manage instance-family-resources in compartment App-Dev

Create policies for compartment admins to use shared resources from other compartments.

Allow group appdev_admin to use network-family-resources in compartment Network
Allow group appdev_admin to use database-family-resources in compartment Database
Allow group database_admin to use network-family-resources in compartment Network
Allow group database_admin to use vaults in compartment Shared_Security

Create policies for auditors and other read-only user groups to read all resources in the tenancy.

Allow group auditors to read all resources in tenancy
Allow helpdesk-users to inspect all resources in tenancy
Allow group announcement_readers_group to read announcements in tenancy

You can also use tags to define IAM policies. You can write a policy to scope access based on the tags applied to a resource using conditions and a set of tag variables. You can control access based on a tag that exists on the requesting resource (group, dynamic group, or compartment) or the target of the request (resource or compartment). The first three sample access policies use requesting resource tags and the last two sample access policies use target resource tags.

Allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project= 'Prod'
Allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'

You start with three high-level roles for every workload that you onboard.

Service admin
Service developer
Service viewer

Create baseline policies for each role to manage, use, read, and inspect permissions to service instances. You can create policies to give users permission on shared resources to the service administrator. For example, for the Analytics service, you can create the following policies:

Service admin role

Allow group Analytics-admin to manage analytics-instances in compartment App-Dev
Allow group Analytics-admin to manage analytics-instance-work-requests in compartment App-Dev
Allow group Analytics-admin to use network-family-resources in compartment Network
Allow group Analytics-admin to use autonomous-databases in compartment Database

Service developer role

Allow group Analytics-developer to use analytics-instances in compartment App-Dev
Allow group Analytics-developer to use analytics-instance-work-requests in compartment App-Dev

Service viewer role

Allow group Analytics-viewer to read analytics-instances in compartment App-Dev
Allow group Analytics-viewer to read analytics-instance-work-requests in compartment App-Dev

You can begin the process with these or similar policies and extend the policy model with every new service that you onboard.

Govern Resource Cost

When transitioning from a CapEx model, where many costs are fixed at the implementation of a project, to an OpEx model, where costs scale up and down with the usage of the system, you often require cost management tools to understand, control, and communicate these cloud costs within your organization.

Oracle provides tools that enable you to govern your organization’s spending and optimize expenditures.

Predict: Set and manage cloud budgets
Control: Prevent overspending
Visibility: Ensure accurate cost tracking across departments and projects and analyze which departments, services, and projects are contribute to cloud usage over time
Optimize: Get granular usage details for invoice reconciliation and identify areas to optimize costs
Extend: Identify areas to extend usage where necessary

Cost Management

You can use one of these two approaches to control costs.

Create financial budgets for every team/group of resources and tack usage against those budgets and alert the team administrator if the usage exceeds the budget or is about to exceed the budget.
Create a limit or quota for every service instance. If a team tries to create more instances than the allocated quota, then the request will fail.

The second approach is restrictive and prevents cost overrun, while the first approach requires manual intervention if the usage exceeds the assigned budget. Compartment trees aggregate budgets and quotas, so child compartments share the total aggregate budget or quota set on the parent.

For example, if compartment Data Science has a budget of $2000, child compartments of DEV and TST share that global budget and will be restricted if either of them exceeds that limit.

Cost Tracking

You can use a budget to set soft limits on the OCI spending by setting cost-tracking tags or by compartments (including the root compartment) You can track all the spending in that cost-tracking tag or for that compartment and it's children. You can also set alerts on budgets to inform management when they exceed the budget. You can view all budgets and spending limits on the OCI Console.

The system evaluates all budget alerts every hour in most regions and every four hours in the Ashburn (IAD). To see the last time a budget was evaluated, review the details for a budget. You will see fields that show the current spend, the forecast and the Spent in Period field showing you the period over which the budget was evaluated. When a budget alert triggers, the recipients configured in the budget alert receive an email.

You can install and use the OCI Cost Governance and Performance Insights Solution app from Oracle Cloud Marketplace linked in the Explore More section.

Cost Control

You can control costs in OCI by limiting the number of service instances created using service limits and compartment quotas.

Service limits help manage the maximum number of resources that can be provisioned in a tenancy, region, availability domain, and compartment. These soft limits restrict provisioning resources which may exceed the limits defined. Only authorized users can request these service limits to be increased or decreased. Service limits enable you to limit the maximum number of service instances of a particular service in a region, availability domain, and compartment.

Compartment quotas are policies that allow administrators to allocate resources with a high level of flexibility by giving tenancy and compartment administrators better control over how resources are consumed in OCI. Compartment quotas are similar to service limits, except service limits are set by Oracle. Compartment quotas are set by administrators using policies that allow them to allocate resources with a high level of flexibility.

Observe and Monitor Resources

You must observe and monitor your resources to ensure the governance model is working to meet your organizational goals.

Cloud Security Posture Management

Cloud Guard is an OCI service that helps you monitor and maintain a strong security posture on Oracle Cloud. Cloud Guard has three essential elements.

Target is a resource to monitor
Detector recipes are recipes to detect problems
Once problems are detected, responder recipes respond to those problems. The response can be a notification or corrective action.

Cloud Guard detects security configuration issues with OCI resources. Based on the probable impact of the issues, it assigns a risk score to the problems. You can monitor aggregated risk scores of the tenancy from the Cloud Guard dashboard. The following are recommendations for using Cloud Guard:

Cloud guard is a free service and the best practice is to activate Cloud Guard for all the compartments.
Customize Cloud Guard recipes to define custom risk scores and response action for problems detected.
Choose to exclude some compartments from making resources available in certain other compartments. For example, if you exclude the Development compartment it can provide you the flexibility to be able to create resources that are not allowed in production compartments.

Cloud Guard supports an allowlist which is a list of exceptions to Cloud Guard policies. For example, if a Cloud Guard policy is set to deny any public object store buckets. If you need to create public bucket for a legitimate use case then you can add explicitly the OCID of the public bucket to the allowlist.

Security Logging

The ability to centrally log all the actions on every cloud resource and be able to audit them in a cloud ecosystem ensures a successful cloud implementation. You can additionally use network flow logs and some of the application logs to detect anomalous behavior. Security and Compliance teams can automate notifications or corrective measures of any undesired incident. Allowing quick actions can alleviate any breaches and threats.

Dashboards and reports based on monitoring, auditing, and logging data can keep the team updated and focused on resolving problems before they become a disaster. You can do the following by setting up security logging:

Aggregate audit logs, which are turned on by default in OCI, in log groups to monitor them using Logging Analytics.
Enable network flow logs to detect suspicious network activity.
Enable service logs for all the services that support service logs. Ensure you choose appropriate log groups while enabling service logs.
Use the interactive visualizations in Logging Analytics to analyze the data. Using the cluster feature to reduce millions of log entries down to a small set of interesting log signatures makes it easy to review the logs.
Use the link feature of logging analytics to analyze logs in a transaction to identity anomalous patterns using the grouped view.

If you use a third-party SIEM solution, you can integrate it with OCI using the OCI streaming service and service connector.

Implement Baseline Governance

Oracle recommends using the Secure Landing Zone to implement resource organization (compartment structure) and resource access governance.

In addition to creating a tenancy structure and access policies, baseline governance also requires you to enable other security features like Cloud Guard, Audit, and Logging.

You should also create a tagging structure and cost governance structure as recommended in the following sections.

Tagging

The Tag Namespace in the following table is Cost-Management.

Tag-Key	Sample Key-Value	Description
Name	-	-
CostCenterID	ERP-US, ERP-UK	Project code name

The Tag Namespace in the following table is Operations.

Tag-Key	Sample Key-Value	Description
Environment	Prod, Non-Prod	Lifecycle environment
AppName	Finance, HR	Business unit
AppCI	-	-
OProjectName	Finance-EBS, Finance-ERP	-
Business Owner	`ABC.someone@example.com`	-
SystemCustodian	`ABC.someone@example.com`	-
IT SupportGrp	`ABC.someone@example.com`	-
OS	LIN, WIN	-
Maintenance	Group1, Group2, Group3	-
Impact	Low, Medium, High	Blast radius across organization

The Tag Namespace in the following table is Govn-Security.

Tag-Key	Sample Key-Value	Description
InfoClass	Public, Internal, Sensitive	-
NetTrustLevel	Corporate (3) / Vendor DMZ (2) / Internet DMZ (1) / Firewall	-
Criticality	T1, T2, T3, T4	Tier 1: Most Critical Tier 2: Critical Tier 3: Non-Critical Business workload Tier 4: Non-Critical IT workload

Cost Governance

In the OCI Console, use the Tag Namespaces UI under Governance and do the following:

Define a tag key named CostManagement.CostCenterID and enable it for cost tracking.
Assign a key tag value of Finance for the Finance cost center CostManagement.CostCenterID = "Finance" to specific resources.
Assign a key tag value of IT for the IT cost center "IT" (CostManagement.CostCenterID = "IT") to other resources.

Use the Create Budget UI under Tenancy to create budgets

Create a budget for resources tagged CostManagement.CostCenterID = Finance.
Create another budget for resources tagged CostManagement.CostCenterID = IT.
Configure alerts to notify the recipients using email if costs exceed the predefined budget or the forecast exceeds a set threshold.

You can create a budget for a compartment specific to a tag value. For example, a monthly budget of $500 is allocated to all resources in a project with a Tag Key value of IT in the Cost-Management/Finance Tag Namespace and CostCenterID Tag Key. You can also configure the budget to start on a particular day of the month to align with business requirements. You can then configure it to send alerts to ABC.someone@company.com when the actual spend amount reaches 80 percent of the $500 budget.

Every OCI service has default service limits enforced. You can update the default service limits using the Limits, Quotas, and Usage UI based on your workload. These limits can be set to align with approved boundaries or budgets according to the needs required by those groups.

Control Cost

Create compartment quotas for every compartment in OCI. The following examples show how to create compartment quotas.

The following example sets the quota for VM.Standard2 and BM.Standard2 compute series to 240 OCPUs (cores) in each AD on compartment App-Dev in the US West (Phoenix) region:
```
set compute-core quota standard2-core-count to 240 in compartment App-Dev where request.region = us-phoenix-1
```
The next example shows you how to create an allowlist and set every quota in a family to zero and then explicitly allocate resources:
```
zero compute-core quotas in tenancy set compute-core quota standard2-core-count to 240 in tenancy
```

This example shows you how to limit creating dense I/O compute resources to only one region:

zero compute-core quotas /*dense-io*/ in tenancy set compute-core quota /*dense-io*/ to 48 in tenancy where request.region = us-phoenix-1

You can clear quotas by using an unset statement, which removes the quota for a resource. Any limits on this resource will now be enforced using the service limits set:
```
zero compute-core quotas in tenancy unset compute-core quota standard2-core-count in tenancy
```

Cost Analysis and Reporting

Cost Analysis and Reporting are two services available to monitor costs and validate that cost control measures are working.

The Cost Analysis tool enables you to analyze how your Oracle Cloud credits are being spent and how consumption compares to your commitment amount. You can use the dashboard to view the spending by service or department, using the compartment or cost-tracking tag and trend lines. This helps you understand how your spending patterns are changing and can help you focus on reducing cost. You can perform cost analysis for a given tag key similar to with budgets.

You can choose specific report types to be run for certain periods and factors. In addition, grouping these reports based on the compartment, tagging, or other group values enables granular reporting for chargeback or analysis.

Usage and Cost Report

Usage reports enable you to gain insights into your billing or create custom billing applications. The reports contain one record per resource. For example, an instance, DB system, or Object Storage bucket per hour with metadata and tags.

A cost report is a comma-separated value (CSV) file similar to a usage report and includes cost columns. The report can be used to obtain a breakdown of your invoice line items at resource-level granularity. As a result, you can optimize your OCI spending and make more informed cloud spending decisions.

Usage reports indicate the quantity of what is consumed. Cost reports indicate the cost of resource consumption. When combined with your rate card, usage reports drive scenarios such as:

Invoice reconciliation
Custom reporting
Cross-charging
Cost optimization
Resource inventory

In addition to enabling new billing scenarios, usage reports provide transparency into how the billing system works. Usage reports can indicate how and where rounding occurs within the usage report and how resources that existed for less than an hour were billed.

Deploy

The Terraform code for this solution is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

Deploy by using Oracle Cloud Infrastructure Resource Manager:
1. Click
  If you aren't already signed in, enter the tenancy and user credentials.
2. Review and accept the terms and conditions.
3. Select the region where you want to deploy the stack.
4. Follow the on-screen prompts and instructions to create the stack.
5. After creating the stack, click Terraform Actions, and select Plan.
6. Wait for the job to be completed, and review the plan.
  To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.
7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
Deploy by using the Terraform CLI:
1. Go to GitHub.
2. Download or clone the code to your local computer.
3. Follow the instructions in the README.