Oracle Enterprise Landing Zone v2 Architecture

One of the key components of OELZ v2 is the network architecture and its segmentation. With adoption of OELZ v2, you can have a highly segregated, functional environment to securely deploy your workloads. A key component of the network architecture is the use of hub-and-spoke architecture. OELZ v2 provides two distinct hub-and-spoke architectures (one for the production environment and one for non-production environments) that are isolated from each other.

In OCI, the hub-and-spoke architecture is a network design pattern in which a central hub network is connected to multiple spoke networks. The hub network is typically used for shared resources, such as security appliances and core services, while the spoke networks are used for individual workloads or applications.

The hub-and-spoke architecture deployed within OELZ v2 can provide several benefits, including:

1. Isolation: Each spoke is its own compartment, which provides an additional layer of isolation and security for resources. This allows for better management and control over access to resources and limits the blast radius of any security incident.
2. Scalability: Spokes can be added or removed as needed to support different use cases or teams. This allows for a flexible and scalable architecture that can adapt to changing business needs.
3. Networking: A hub provides a central point for all network traffic to flow through, which simplifies the overall network architecture and improves security. Resources in different spokes can communicate with each other over the hub-and-spoke network without having to traverse the internet.
4. Resource Management: Each spoke can be managed and administered independently, which allows for better resource allocation and more efficient use of resources. It also lets different teams or business units manage their own resources, with the ability to have different access to control and management.
5. Cost Optimization: By centralizing certain resources in the hub, such as VPN gateways and load balancers, it can be more cost-effective to manage them.
6. Governance: By having a central hub, it is much easier to apply governance rules and policies across the whole infrastructure, and to get a clear view of all the resources and activity in your enterprise.

This architecture is flexible, so depending on requirements, some components in the hub, such as the load balancer, can be moved to the spoke.

In OELZ v2, the hub network is created using a virtual cloud network (VCN) in the Network Shared Infrastructure compartment in each environment. The spoke networks are created in each Application compartment, using VCN attachment through a dynamic routing gateway (DRG). This allows the spoke networks to access the shared resources in the hub network while maintaining their isolation.

Overall, the hub-and-spoke architecture is a flexible and scalable design pattern that you can use to build complex network architectures in OCI. This is one of the main reasons OELZ v2 provides a pre-configured environment ready to use within minutes.

Key areas of OELZ v2 are monitoring and logging resources for the architecture. These areas are particularly important within IT governance and operations for each enterprise, and are critical for maintenance and security of your OCI environment.

Monitoring and logging in OELZ v2 help you understand the performance and availability of your cloud resources and applications. They can also help you to identify and troubleshoot issues and maintain compliance with regulatory requirements.

By monitoring your resources, you can ensure they're performing as expected, and that they have sufficient capacity to meet the demands of your applications. This can help you optimize your cloud environment's performance and cost efficiency.

Logging lets you record events and activities in your cloud environment. This can be useful in areas such as auditing, debugging, and analyzing trends.

To support multiple environments, the landing zone deploys two isolated environments:

• Production environment: Environment for your production workloads
• Non-production environment: Environment for your development or other workloads

Each environment is isolated in different ways:

• Each environment has a separate identity domain. Users are isolated in a single environment, and non-production users don't have access to production resources.
• Each environment has its own hub-and-spoke network.
• Each environment has its own Cloud Guard target.
• Each environment has a separate logging and monitoring configuration.

The separation of environments allows you to securely deploy production workloads and non-production workloads without having to worry about accessing resources from a different environment.

In addition to using default environments, you can deploy additional environments if needed by using the Environments module. The additional environments have the same isolation as the other environments.

Use OCI Identity and Access Management (IAM) to control access to your cloud resources in OCI.

The landing zone creates IAM groups and policies that control access to the resources created by the landing zone. Optionally, you can federate with your organization's Microsoft Active Directory implementation.

We recommend that you create one or more break-glass users during deployment, especially if you're using federation. Break-glass users are administrators who have emergency access to all OCI services and resources in the tenancy.

Federating with Microsoft Active Directory

With OELZ v2, you can optionally federate with Microsoft Active Directory.

Use the same group names in OCI as you use for Microsoft Active Directory. To do this, pass the Microsoft Active Directory group names as variables to the OELZ v2 Terraform module. The groups are created by the landing zone and mapped to your Microsoft Active Directory groups.

For more information about federating with Microsoft Active Directory, see Federating with Microsoft Active Directory.

OELZ v2 includes a set of pre-built policies and guardrails that help ensure your OCI environment has a strong foundation for achieving security compliance goals. The security controls implemented in OELZ v2 include recommendations that can help you attain CIS 1.2 compliance Level 1.

The Center for Internet Security, Inc. (CIS) is a non profit organization that is community driven. The organization is responsible for CIS Controls and CIS Benchmarks global best practices for securing IT systems and data. The goal of CIS is to prevent and mitigate new cyber threats that are identified in the industry. For many OCI customers, this has been a go-to benchmark that guides architecture for helping to secure workloads in OCI. Because we recognize the importance of adhering to best practice guidance from both OCI teams and the industry, OCI landing zones continue to implement support for CIS Benchmarks.

For a list of security controls that are included in OELZ v2, see CIS 1.2 Level 1 Security Controls.

The OELZ v2 Landing Zone module assembles the landing zone. The module creates the entire landing zone by invoking the other modules.

OELZ v2 deploys two isolated environments, as shown in the Architecture Overview diagram.

This module invokes the environment module twice, each for a distinct isolated environment:

• Environment module: Module for creating the production environment
• Environment module: Module for creating the non-production environment

This module is also responsible for creating the landing zone parent compartment. The module doesn't deploy any other resources, and relies on the environment module for the deployment of an environment.

The Environment module aggregates the other modules into a single environment. It uses the following modules to compose an isolated environment in the landing zone:

• Compartments module
• Budget and Tagging module
• Identity module
• Network module
• Security module
• Monitoring module
• Logging module

The Environment module doesn't create any additional resources on its own. Instead, the module aggregates the other functional modules.

Use compartments to organize and isolate your resources to make it easier to manage and secure access to them.

OELZ v2 creates a compartment structure for your organization. Control access to compartments by creating policies that specify what actions groups of users can take on the resources in those compartments. The following diagram shows the compartment structure created by the landing zone.

The compartments module only creates the compartment structure for a single environment, which includes the following compartments:

• L2 - Environment: Encapsulating compartment for an environment
• L3 - Shared infrastructure: Compartment containing the shared infrastructure
  • L4: Network: Compartment that holds the hub component of the network
  • L4 Security: Compartment that holds the security and identity components
• L3 - Workload: Compartment that holds a spoke connecting to the hub
• L3 Logging: Compartment that holds a bucket to store the log files from the environment
• L3 Backup: Backup compartment that contains the configuration and state file

Budget and tagging are key components to achieve strong governance within OELZ v2. Budgeting and tagging are important in OELZ v2 because they help you manage and optimize the cost of your cloud resources, and manage your resources more effectively in OCI.

Budgeting allows you to set limits on your cloud spending, and to receive notifications when your usage approaches or exceeds those limits. This can help you avoid unexpected charges and better control cloud costs.

Tagging allows you to assign metadata to your cloud resources, such as tags that represent the purpose, owner, or environment of those resources. You can then use tags to organize and manage your resources and to track cloud costs by tag. For example, you might use tags to track the costs of different projects or departments, or to identify resources that are eligible for discounts or credits.

During deployment, you have the opportunity to enable or disable budget and tagging for each environment. For more information about tagging best practices, see Best Practices for Using Tags to Manage Costs, Operations, and Governance (oracle.com) and FinOps best practices for Oracle Cloud Infrastructure | CloudWorld 2022 - YouTube.

The main components are:

• Budget module

  • (Optional) One budget per environment. If the feature is enabled, budget scope is: L2- Environment compartment.

• Tagging module

  • (Optional) One tag namespace per environment created in the L2- Environment compartment. If the feature is enabled: tag Environment, tag Cost Center, and tag Geo Location.

The identity module creates and configures an identity domain in an environment in the landing zone.

To isolate access between resources, groups are created with policies for restricting access to certain resources.

• Network Admin: User group with access to your environment's network resources
• SecOps Admin: User group with access to your environment's security related resources
• Identity Admin: User group that can manage the identity related resources
• Platform Admin: User group with access to usage reports and that can manage budgets
• Ops Admin: User group with access to your environment's metrics, events, and alerts
• Log Admin: User group with access to the your environment's logs

The Logging module implemented by OELZ v2 uses the following OCI services and features to help your organization meet security policy and compliance requirements:

• Vault (Key Management)
• Logging
• Object Storage Buckets
• Streaming
• Events
• Service Connector Hub

Log Archiving Storage Bucket (Optional)

An optional immutable storage bucket is deployed by default to archive logs and events within the defined retention period, according to what you input. OELZ v2 is deployed with a one-day retention duration to facilitate environment cleanup. Revise this duration to comply with the retention requirements of your organization's security policies.

Default Log Group

OCI generates service logs for supported services. You can enable or disable logging for each supported service. The OELZ v2 default setting is to enable and store all service logs. For more information, see Service Logs.

Streams & Events

OCI Streaming is used for real-time ingestion of high-volume data streams. It can be used where data is continually produced and published sequentially, for instance, with log events. OELZ v2 uses the Streaming service with OCI events. OCI services generate events that provide notifications when there are any resource changes in your environment.

For more information, see:

• Services Event Types
• Streaming
• Events

Service Connector Hub

Many organizational security policies stipulate a common archiving system should be made available for storing systems, applications, security, and event logging. The Service Connector Hub service is used to ship all audit logs, service logs, and service events to object storage so that it's available for operational review.

For more information, see Archiving Logs to Object Storage.

The Monitoring module lets you monitor resources and receive the correct alerts in case of issues with your OELZ v2 components and OCI tenancy. It provides a starting point for administrators to tweak the operational model.

Services in OCI provide metrics and events that can be monitored through the metrics dashboard. In addition, alerts can be created based on certain queries of the metrics and events. To organize the alerts, topics are created that group certain alerts. In the landing zone, these topics are defined according to the severity of the alert (critical and warning). Different topics are also created according to the compartment and environment.

Example: PRD-Network, NPRD-Security and PRD-workload, and so on.

Each topic has different monitoring rules assigned to it for each environment. To avoid excessive costs and many messages, OELZ v2 deployment disables these alerts by default. Based on your operational model, you can enable the relevant alerts from the Console.

The monitoring structure contains the following elements:

• Monitor Alert Channels through creating Notification Topics (such as PRD-Network-Critical, NPRD-Security-Warning) and subscription (such as email).
• Monitor OCI service incidents and action required from OCI maintenance by subscribing to Console Announcements.
• Monitor Cloud Guard status (such as problemthresholdreached) by subscribing to Cloud Guard events.
• Monitor Vulnerability Scanning and Cloud Guard detected problems by subscribing to Cloud Guard events.
• Enable metrics-based monitoring of Network, Security, Logging and Workload compartments by creating sample alarm rules for the deployed service metrics namespaces.

Enable OCI Logging Analytics for reporting through Log Explorer and Dashboards:

• Enable Logging Analytics at the tenancy level.
• Ingest logs (such as Default Log Group and Audit Logs) into Logging Analytics by way of service connectors.

Operational Model

To organize alerts, multiple alerts are put in meaningful groups for a compartment admin to subscribe to.

• Workload X admin of a specific environment: Receives alerts for the specific workload.
• Security admin of a specific environment: Receives alerts for all resources in the Security compartment (Bastion, Vulnerability Scanning, and so on), in addition to security related notifications from Cloud Guard.
• Network admin of a specific environment: Receives alerts for all resources in the Network compartment (Network HUB, DRG, and FastConnect).
• Identity admin of a specific environment: Receives alerts related to IAM.
• Platform admin of a specific environment: Receives alerts related to Budgets.

Messages are also grouped into Notification Topics according to severity (Critical and Warning) for each environment and compartment (Network, Security, and Workload). See Managing Topics and Managing Subscriptions.

By default, a single Email address is used for all alert groups; however it's possible to overwrite these values in the Console to send each notification topic to a different Email address.

Monitoring Rules

OELZ v2 creates many monitoring rules that can trigger alerts. These are disabled by default. You can enable the rules that apply to your operational needs from the Console.

For a complete list of events and alerts, see Oracle Enterprise Landing Zone v2 Configuration.

The Network module includes two main functional modules. The first module is the hub-and-spoke module that deploys a hub-and-spoke network allowing the different workloads to interconnect. The second module is the Network Extension module, which extends connectivity with the on-premises network, in addition to using the hub-and-spoke created. By default, OELZ v2 deploys the hub-and-spoke module in the " L2 - OCI-ELZ-<Environment Name>" compartment (for PROD and NON-PROD).

The Network Extension module is an optional module. It can only be deployed in the production environment. As a result, it's shared between the production and non-production environments.

The following information describes the main components for the hub-and-spoke module.

For the hub, the components are:

• A VCN that hosts the different subnets of the HUB deployed in the L4 - Network compartment.
• A public subnet to host all internet-facing servers and resources, including load balancers and web servers. This subnet must be secured with the correct Cloud Guard recipes and other security features described in Security module.
• A private subnet to host all common or shared services that your environment uses, such as network virtual appliance and internal jump box server.
• A DRG that enables routing between the VNC hub and other application VCNs (spokes), deployed in the L4 - Network compartment.
• An optional internet gateway that allows traffic between the public subnets in a VCN and the public internet, deployed in the L4 - Network compartment.
• An optional NAT gateway that enables private resources in a VCN to access hosts on the internet without exposing the resources to incoming internet connections, deployed in the L4 - Network compartment.
• An optional service gateway that provides access from a VCN to other services, such as OCI Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric, and never traverses the internet. The gateway is deployed in the L4 - Network compartment.

The main components for the spoke are:

• A VCN that hosts the different subnets of the spoke, deployed in the L3 - Workload compartment.
• Three private subnets to host all components of your application using different tiers, such as Web, App, and DB.
• VCN attachments connected to the DRG of the HUB.
• Optional NAT gateways that enable private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections. The gateways are deployed in the L3 - Workload compartment.
• An optional service gateway that provides access from a VCN to other services, such as Object Storage. Traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet. The gateway is deployed in the L3 - Workload compartment.

Note: If you need to publish your web servers using OELZ v2, a public load balancer must be deployed within the public subnet in the hub (L4 - Network Compartment). As endpoints, the load balancer must have the web servers in the subnet that are part of the L3 - Workload compartment. Since connectivity is already configured by way of the hub-and-spoke architecture, you only need to change the security lists associated with the subnets to enable traffic between the load balancer and the endpoints.

The Network Extension module consists of two sub-modules that you can use for deploying a Site-to-Site VPN in each environment instead of sharing FastConnect between environments.

The main components for the VPN module are:

• Customer Premises Equipment (CPE) deployed in the L4 - Network compartment, so traffic can flow between your on-premises network and VCN.
• An IPsec connection.

For general information about the parts of a VCN, see Networking.

For information about IPsec VPNs, see Site-to-Site VPN.

For a list of CPE devices Oracle has verified, see Verified CPE Devices.

By using this module, during deployment you can decide to create a Site-to-Site VPN for each environment to continue to have separate traffic.

The main components of the FastConnect module are:

• A Fast Connect circuit dedicated, private connection between your data center and OCI, using your choice of Oracle partners and deployed in the L4 - Network compartment.
• A Remote Peering Connections (RPC) attachment, which is a peer for the DRGs of the two environments created during OELZ v2 deployment.

Using this module, you can deploy a FastConnect circuit by sharing it between environments. Consider the FastConnect service is generally more expensive than a Site-to-Site VPN.

If you need other FastConnect circuits after deployment, you can create more. You need to change the route table set during deployment. When enabling this module, environments continue to be separated as traffic is allowed or denied by the security lists applied to each subnet.

The security lists implemented during OELZ v2 deployment are CIS 1.2.0 compliant, so all incoming traffic is blocked, except the ICMP protocol. For more information, see CIS Oracle Cloud Infrastructure Benchmark (cisecurity.org)

OCI is a security-first cloud service that helps organizations reduce the risk of security threats for cloud workloads by putting customer data security and privacy first. This is achieved through the automation of security operations with simple, prescriptive, and integrated cloud-native security capabilities built into the OCI platform. Oracle helps you easily adopt OCI services and secure your cloud infrastructure, data, and applications.

OELZ v2 further supports Oracle's security-first cloud strategy tenets as follows:

• Security should be simple and easy to use, deploy, and operate.
• Security tools should offer guidance to help customers achieve strong security more easily.
• Security should be integrated and automated, reducing manual security tasks and human errors.
• Cloud security should be economically attractive, improving the cost of securing cloud workloads.

The following OCI services are implemented by OELZ v2 to help your organization meet your security policy and compliance requirements:

• Cloud Guard
• Vulnerability Scanning
• Vault (Key Management)
• Bastion
• Network Firewall

Cloud Guard

Cloud Guard is the OCI native security service that helps you monitor, identify threats and configuration issues, achieve a strong security posture, and maintain compliance with security policies. When issues are detected, Cloud Guard can recommend, assist, or execute corrective actions based on how you configure Cloud Guard to respond.

OELZ v2 enables Cloud Guard services by default, and uses your organization tenancy home region as the reporting region. Cloud Guard is used with VSS detector recipes. The following default Oracle-managed detector recipes are enabled to provide a strong and secure baseline for your OCI environment:

• Configuration detector recipe: Set of rules designed to detect resource configuration settings that could pose a security problem.

• Threat detector recipe: Set of rules designed to detect rogue user activity and high-risk activity based on Oracle Threat Intelligence Service.

• Activity detector recipe: Set of rules designed to detect actions on resources that could pose a security problem.

  These recipes can be used as the default Oracle-managed versions, or you can clone these recipes and use them to provide a strong baseline and further customize the recipes based on your requirements.

• Responder recipe: Defines the action or set of actions to take in response to a problem that a detector has identified.

  We recommend that you don't enable the responder recipe because of changes made during pre-production activities. The responder recipe should be enabled after completing a thorough review and testing.

If needed, Cloud Guard results can be pushed to third-party SIEM, such as Splunk HTTP Event Collector (HEC) via OCI SDK.

For more information, see OCI Cloud Guard.

Vulnerability Scanning

Vulnerability Scanning can be scheduled to check hosts and detect open ports and container images for vulnerabilities. The default Oracle detector recipes are used for scanning compute resources and the public port. These default recipes provide a foundational security posture baseline based on Oracle and industry security best practices.

Note: Vulnerability Scanning isn't compliant with PCI DSS requirements. OCI supports the use of Qualys agents, which can be integrated with Vulnerability Scanning.

For more information, see Vulnerability Scanning.

Vault (Key Management)

OCI Vault is a cloud-native encryption management service used in the landing zone to store and manage master encryption keys and secrets that are used to secure your OCI resources, and also used to encrypt your logs.

This OELZ v2 landing zone defaults to VIRTUAL. A master encryption key (MEK) AES 256 is generated by default as part of your landing zone deployment. The MEK is used to encrypt your log object storage buckets. You can choose to bring your own key (BYOK) and import key material from your on-premises or third-party cloud environments. In addition, OCI can provide a Hardware Security Module (HSM) dedicated vault service as an option.

For more information, see Vault (Key Management).

Bastion

The landing zone deployment uses the Bastion service, which provides restricted and time-limited access to target resources that don't have public endpoints. The service allows privileged users to connect from specified IP addresses to target resources over Secure Shell (SSH).

When connected through Bastion, you can interact with the target OCI resource by using any software or protocol supported by SSH. For example, you can use Microsoft Remote Desktop Protocol (RDP) to connect to a Windows host or use Oracle Net Services to connect to a database. The Bastion service is associated with a single VCN with a limit of five bastions per region.

For more information, see OCI Bastion.

Network Firewall

Oracle Cloud Infrastructure (OCI) Network Firewall is a managed Next-Generation Firewall (NGFW) and Intrusion detection and Prevention service (IDS/IPS) that is powered by Palo Alto Networks®. It is an OCI cloud-native service feature now available in the Oracle Enterprise Landing Zone (OELZ) package. OELZ now offers simple setup and deployment of the OCI Network Firewall service, which gives you visibility into traffic entering your cloud environment (North-South) and traffic between subnets (East-West). This OELZ implementation will deploy a reference Hub and Spoke Network Architecture with a Network Firewall in the Hub.

For more information, OELZ Network Firewall.

The Workload Expansion module deploys the resources for an empty workload. The module deploys the following resources:

• Compartment
• Network (spoke)
• Logging
• Monitoring
• policies and workload group

Compartment

One workload compartment is created in the L3 - Workload compartment.

Network (Spoke)

The main components of the Spoke module are:

• VCN: Hosts the different subnets of the spoke. Deployed in the L3 - Workload compartment.
• Three private subnets: Hosts all components of your application using different tiers such as Web, App, and DB.
• VCN Attachments: Connected to the dynamic routing gateway (DRG) of the hub.
• Network Address Translation (NAT) gateways: (Optional) Enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections. Deployed in the L3 - Workload compartment.
• Service gateway: (Optional) Provides access from a virtual cloud network (VCN) to other services, such as OCI Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet. Deployed in the L3 - Workload compartment.

Logging

The Logging service is applied at the Landing Zone Home compartment level. All logs from the workload expansion are captured.

Monitoring

Similar to the default workload, the monitoring structure contains the following elements:

• Monitor alert channels. Create notification topics (Workload-Critical, Workload-Warning) and subscription (such as email).
• Monitor OCI service incidents and action required from OCI maintenance by subscribing to Console announcements.
• Monitor Cloud Guard status (such as problemthresholdreached) by subscribing to Cloud Guard events.
• Monitor VSS and Cloud Guard detected problems by subscribing to Cloud Guard events.
• Enable metrics-based monitoring of Network, Security, Logging, and Workload compartments by creating sample alarm rules for the deployed service metrics namespaces.

Policies and Workload Group

Three admin groups are created in the workload expansion:

• workload admin group: User group that has access to the workload related resources inside your environment.
• application admin group: User group that has access to the application (volume family, object, file, instance, and so on) resources inside your environment.
• database admin group: User group that has access to the database resources inside your environment.