Oracle Enterprise Landing Zone v1 Implementation
Use Oracle Enterprise Landing Zone (OELZ) v1 to deploy a secure cloud environment that's ready for you to launch new projects and workloads in Oracle Cloud Infrastructure (OCI).
Important: This reference architecture provides an enterprise-scale architecture and deployment that includes designs for governance, security segmentation, and separation of duties. See How Do I Decide Which Landing Zone to Use?
Prerequisites
Before you launch OELZ v1, prepare the following information.
- Tag values for the CostCenter and GeoLocation tags. Every resource that is created by the landing zone stack is tagged with the values that you provide.
- A name for the parent compartment. The parent compartment is the top-level organizational compartment that is created by the landing zone.
- Names for one or more workload compartments under the parent compartment.
- Email addresses for one or more break-glass users. Break-glass users have emergency access to all OCI resources.
- CIDR block for the allowlist on the bastion.
- CIDR blocks for the following subnets created within the virtual cloud network (VCN):
- Shared
- Bastion
How to Deploy
Install OELZ v1 by using the OCI Console, Resource Manager, or the OCI Terraform provider.
The Terraform template is available in GitHub: https://github.com/oracle-quickstart/oci-enterprise-scale-baseline-landing-zone
Terraform Modules
OELZ v1 is composed of multiple Terraform modules. Each module is written to work together in a stack.
The following information lists the modules in OELZ v1.
| Module | Description |
|---|---|
| Compartments | Contains submodules for creating the compartment structure for OELZ v1. These compartments include the parent compartment and compartments for security, networking, and workloads. |
| Budget | Builds a compartment-level budget alarm based on a threshold that you define. The budget is valid for everything that resides under the parent compartment. This module is optional. |
| Virtual cloud network (VCN) | Builds and configures all network-related resources, including a VCN, subnets, gateways, security lists, and routing rules. This module also configures optional dynamic routing gateways (DRGs), using either Site-to-Site VPN or OCI FastConnect. |
| Identity and access management (IAM) |
Creates nearly all required policies and groups. A submodule creates accounts for emergency access, called break-glass users. In some cases, if permissions are related to a specific feature, an IAM policy might be created in a different module. For example, if Oracle Cloud Guard is used, the related IAM policies are created in the Cloud Guard submodule. |
| Security | Implements VCN flow logs, Cloud Guard, OCI Audit logs, and the OCI Bastion service. |
Knowing the contents of each module can help you understand how to scale and operate the stack.
In the top-level directory, each module has a module-variables.tf file that defines the module's variables, a module.tf file that creates the module's resources, and a subdirectory that is named after the module and contains the submodules. For example, the compartments module includes a compartments-variables.tf file, a compartments.tf file, and a subdirectory named compartments.
Tags
OELZ v1 includes a set of free-form tags that are applied to resources created within the template. Each resource is given a default assigned value for the Description tag. The values that you define when you create the OELZ v1 stack propagate to the CostCenter and GeoLocation tags.
IAM Policies and Groups
OCI Identity and Access Management (IAM) lets you control who has access to specific cloud resources and what type of access a group of users has.
OELZ v1 provisions IAM groups with established roles and access levels. Each IAM group is referenced in IAM policies that grant access to the associated resources. All groups belong to the parent compartment. Each policy belongs to the compartment that is closest to the resource that it controls access to.
The OELZ v1 stack provisions the groups and IAM policies listed in the following information. To override the default group names, update the Terraform variables when you create the stack. For example, you can rename groups to fit your organizational structure or to map with a federated identity service.
| Group | Policy Name | Description |
|---|---|---|
| Virtual-Network-Admins | OCI-LZ-VCNAdminPolicy | Network administrators can manage all network resources in the network compartment. |
| Security-Admins | OCI-LZ-SecurityAdmins | Security administrators can manage and use encryption keys to encrypt resources. With this access, you can view resources in the OCI Vault service, which manages user keys and secrets. Security administrators can also manage Bastion resources, which let you connect to hosts and subnets in the VCN. Access for security administrators is within the security compartment. |
| Platform-Admins | OCI-LZ-Platform-Admins | Platform administrators manage all cost, billing, and budget related resources. |
| IAM-Admins | OCI-LZ-IAM-Admins | IAM administrators can manage groups, dynamic groups, and policies. IAM administrators should also be able to manage users and groups permissions with IDP. With this access, you can manage users and their credentials including API keys and auth tokens. |
| Ops-Admins | OCI-LZ-Ops-Admins | Ops administrators can manage alarms, metrics, and topics. |
The following diagram shows the IAM groups and policies that are created by OELZ v1.
Optionally, you can add additional users to the groups that are created.
To add users to groups
- Open the navigation menu and click Identity & Security. Under Identity, click Users. A list of the users in your tenancy is displayed.
- Locate the user in the list.
- Click the user. The user's details are displayed.
- Click Groups.
- Click Add User to Group.
- Select the group from the drop-down list, and then click Add.
You can also manage user membership in groups through the API, SDKs, CLI, or Terraform.
Cloud Guard
Use Cloud Guard to monitor and manage the security of your cloud resources.
Usage and Best Practices
Cloud Guard is a cloud-native service that helps you monitor, identify, achieve, and maintain a strong security posture on Oracle Cloud. Use the service to examine your OCI resources for security weakness related to configuration, and your OCI operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration.
To use Cloud Guard, define target resources that you want Cloud Guard to monitor. Then, use Oracle-managed or user-managed detector recipes (sets of rules) to examine the resources and activities in the target, and to identify problems.
The reporting region for Cloud Guard is set to your tenancy's home region by default. The reason is that when Cloud Guard is already enabled in your tenancy and the reporting region is not the home region, Cloud Guard needs to be disabled and then reenabled, which adds unnecessary complexity. Cloud Guard can detect events in the region where OELZ v1 is deployed, even if the reporting region is different. If necessary, you can manually change the reporting region. For more information, see Getting Started with Cloud Guard.
When you provision Cloud Guard resources using the OELZ v1 stack, the target is all resources within the parent compartment. OELZ v1 includes two Oracle-managed recipes, OCI Configuration Detector Recipe and OCI Activity Detector Recipe. These detector recipes perform checks and identify potential security problems on your resources.
Optionally, you can create your own responder recipes and rules. Responders are structured in a similar way to detectors. A responder is an action that Cloud Guard can take when a detector has identified a problem. Each responder uses a responder recipe with rules that define the action or set of actions to take in response to a problem that a detector has identified. The available actions are resource-specific.
Enabling or Disabling Cloud Guard
To enable Cloud Guard at the tenancy level, in the OELZ v1 stack, set the variable cloud_guard_configuration_status to ENABLE. To disable the service, set the variable to DISABLE.
Cloning Cloud Guard Recipes
You can clone detector recipes to fine-tune the set of detector recipes available to use in your environment. Only a member of the CloudGuardArchitect group can clone recipes.
Cloud Guard IAM Policies
The IAM policies in the following information are provisioned with Cloud Guard. You might need to add users to specific IAM groups to allow them to access and manage Cloud Guard resources.
| Policy Name | Description |
|---|---|
| OCI-LZ-Cloud-Guard-Policy |
Configures permissions for Cloud Guard to access tenancy resources:
|
| OCI-LZ-Scanning-Service-Policy |
Configures permissions for the OCI Vulnerability Scanning service to access resources in the parent compartment:
|
Cloud Guard Target
Target name: OCI-LZ-Cloud-Guard-Target
In the OELZ v1 stack, a user-managed Cloud Guard target is deployed. The target resource ID is the parent compartment and all resources within it. The target uses two Oracle-managed detector recipes.
Vulnerability Scanning Host Scan Recipe
Host scan recipe name: OCI-LZ-Scanning-Service-Recipe
In the OELZ v1 stack, a user-managed host scan recipe for Vulnerability Scanning is deployed into the security compartment. The agent, the port scanning level, and the scan schedule are configured in Terraform.
Vulnerability Scanning Host Scan Target
Host scan target name: OCI-LZ-Scanning-Service-Target
In the OELZ v1 stack, a user-managed host scan target for Vulnerability Scanning is deployed into the security compartment. This resource uses the Vulnerability Scanning host scan recipe that is created by the stack. The target resource ID is the parent compartment and all resources within it.
Emergency Break Glass Users
Users in the break-glass user group are administrators who have emergency access to all OCI services and resources in the tenancy. The users in this group must enable multi-factor authentication.
Resources
The landing zone stack provisions the following IAM resources for break-glass users:
- Default username: break_glass_user_<number>
- Default group name: Administrators
- Default policy: OCI-LZ-Admin-TenantAdminPolicy
The break-glass IAM policy contains the following statement:
Allow group <administrator_group_name> to manage all-resources in tenancy where request.user.mfaTotpVerified='true'.
Usage
The OELZ v1 stack provisions users in the break-glass group using the break_glass_user_email_list variable. To create multiple break-glass users, provide multiple valid Email addresses for this list variable.
After break-glass users are provisioned, the system sends a password reset Email to each user to grant access to their account. When a break-glass user signs in to the Console, they can view their membership in groups by reviewing their user settings.
Each break-glass user must enable multi-factor authentication (MFA).
To enable MFA for your user account
Prerequisite: You must install a supported authenticator app on the mobile device you intend to register for MFA.
In the upper-right corner of the Console, open the Profile menu, and then select User Settings. Your user details are displayed.
Click Enable Multi-Factor Authentication.
Scan the QR code displayed in the dialog with your mobile device's authenticator app.
Note: If you close the browser, or if the browser crashes before you can enter the verification code, you must generate a new QR code and scan it again with your app. To generate a new QR code, click the Enable Multi-Factor Authentication button again.
In the Verification Code field, enter the code displayed on your authenticator app.
Click Enable.
Your mobile device is now registered with the IAM service and your account is enabled for MFA. Every time you sign in, you are prompted for your username and password first. After you provide the correct credentials, you are prompted for a TOTP code generated by the authenticator app on your registered mobile device. You must have your registered mobile device available every time you sign in to OCI.
After MFA is enabled for a break-glass account, the account can be used to manage the tenancy through the API, SDKs, CLI, or the Console.
Bastion
The Bastion service provides restricted and time-limited access to cloud resources without public-facing endpoints.
There are two types of bastion sessions, managed SSH and port forwarding. The type of bastion session depends on the target resource.
- Managed SSH sessions simplify SSH access to native Oracle Linux images running the Oracle Cloud Agent software.
- Port forwarding creates a secure connection between a specific port on the client machine and a specific port on the target resource.
Resources
The OELZ v1 stack creates a bastion named LZBastion and a subnet named OCI-LZ-Bastion-<region_key>-subnet. The subnet and bastion are attached to the default VCN residing in the network compartment.
The stack doesn't provision bastion sessions. You can create bastion sessions after the bastion has been provisioned.
Usage
To deploy or update the bastion module using Resource Manager, provide the required values listed in the following information.
| Field | Variable Name | Description |
|---|---|---|
| Bastion Subnet CIDR Block | bastion_subnet_cidr_block | CIDR block for the bastion subnet. |
| Bastion Client CIDR Block Allowlist | bastion_client_cidr_block_allow_list | A list of address ranges in CIDR notation that the bastion is allowed to connect to. |
After the bastion has been provisioned, you can create bastion sessions using the API, SDKs, CLI, or the Console.
For more information about bastions, see Bastion.
Monitoring
OELZ v1 includes modules for notification topics, alarms, and subscriptions. By default, this includes notifications for security, budget, and networking resources.
The notification recipient can be configured using the corresponding input variables for email endpoints.
| Field | Variable Name | Description |
|---|---|---|
| Security Admin Emails | security_admin_email_endpoints | Notifications for creating, updating, and deleting security resources. |
| Budget Admin Emails | budget_admin_email_endpoints | Notifications for creating, updating, and deleting budget resources. |
| Network Admin Emails | network_admin_email_endpoints | Notifications for creating, updating, and deleting network resources. |
Budgets
OELZ v1 includes an optional budget module.
To enable the budgets feature when deploying or updating the stack using Resource Manager, select the option for Budget Alerting, and then provide the following required values.
| Field | Variable Name | Description |
|---|---|---|
| Budget Amount | budget_amount | Monthly budget |
| Budget Alert Rule Threshold | budget_alert_rule_threshold | Alerting threshold for spend |
| Budget Alert Rule Recipient | budget_alert_rule_recipients | Email address to receive budget alerts |
The budget that is created applies to the parent compartment.
For more information about budgets, see Budgets Overview.
Global Resources Control
OELZ v1 includes a global resources control through a variable flag deploy_global_resources. The default is set to true to deploy all resources.
Important: If you need to extend the landing zone to another region, set the deploy_global_resources flag to false to avoid resource conflict at the tenancy level.
Global resources include:
- Cloud Guard service and related policies
- Audit logging and related policies
- VCN Flow Logs and related policies
- Groups and corresponding policies