Oracle Enterprise Landing Zone v1 Architecture

Resiliency

A resilient cloud architecture helps you to avoid single points of failure for your cloud-based workloads.

At the infrastructure level, OCI provides physical and logical resources to help you design for resiliency, such as regions, availability domains, and fault domains.

Resiliency depends on the nature, architecture, and implementation of the workloads that you plan to deploy in OCI. For best practices, see Resilience and Continuous Availability of Oracle Cloud Infrastructure Services and Platform FAQ and Best practices for designing reliable and resilient cloud topologies.

Security

OELZ v1 follows these best practices for security design principles:

• Design to mitigate attacks
  • Limit permissions based on requirements
  • Enforce network segmentation
• Leverage cloud-native security controls
• Use identity as primary access control
• Accountability
• Embrace automation
• Focus on information protection
• Design for resilience
  • Ongoing vigilance
  • Defense in depth
  • Defense at edge
  • Least privilege
• Assume zero trust

For more information, see the security design principles in Best practices framework for Oracle Cloud Infrastructure.

Example Compartment Structure

If you wanted to deploy three workloads in OCI: a finance application, a human resources (HR) application, and a marketing application, the first step is to deploy the OELZ v1 modules, which create the foundation of your environment.

After you deploy the core infrastructure components, you run the OELZ v1 - Workload Expansion stack for your first workload, the finance application. You configure the relevant parameters and naming conventions according to your organization's policies. Then, you're ready to migrate the application.

For the remaining applications, you perform the same process of running the OELZ v1 - Workload Expansion stack and defining the relevant parameters needed for each application. When you're ready, you can migrate each application to the relevant environment.

This process gives you complete control and isolation over each application. The workload compartments can share common infrastructure resources such as identity domains, FastConnect, Cloud Guard targets, and so on.

Non-Federated Setup

For non-federated users, OELZ v1 creates IAM groups and policies. For information about the IAM groups created by OELZ v1, see IAM Policies and Groups.

Federating with Microsoft Active Directory

With OELZ v1, 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 v1 Terraform module. The groups are created by the landing zone and mapped to your Microsoft Active Directory groups.

The following diagram shows the Microsoft Active Directory federation that OELZ v1 supports.

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

IAM Policies

For information about the IAM policies created by OELZ v1, see IAM Policies and Groups.

Subnets

OELZ v1 creates public and private subnets within the VCN.

• Subnet-Public: Public subnet to host all internet-facing servers and resources, including load balancers. This subnet must be secured with the correct Cloud Guard recipes and other security features described in Security.
• Subnet-Shared Services: Private subnet to host all common or shared services that your organization uses. Depending on your applications, you must create security lists to allow the network traffic between servers in your cloud tenancy (east and west traffic) to enter and exit this subnet. Create security lists during deployment of your workloads.
• Subnet Bastion Service: Private subnet to host the Bastion service. Bastion provides restricted and time-limited access to target resources that don't have public endpoints. Configuring bastions is important to ensure that your organization's cloud administrators can access resources that reside in private subnets.
• Subnet - <Workload>: Deployed only with the OELZ v1 - Workload Expansion stack. This is a private subnet that you should use to host all resources needed by a specific workload, with the exception of databases. You can create multiple subnets, one for each workload.
• Subnet - <Workload> - Database Services: Deployed only with the OELZ v1 - Workload Expansion stack. This is a private subnet to host database resources for your applications. You can create multiple subnets, one for each workload's database resources.

Gateways

OELZ v1 creates the gateways that your applications might need to connect with OCI services and the internet, plus the basic components to control access.

• Internet gateway: Virtual router that connects the edge of the VCN with the internet to allow direct connectivity to the internet. OELZ v1 creates an internet gateway and the following components:

  • Security lists: Virtual firewalls that let you control ingress and egress traffic. OELZ v1 creates a security list associated with the internet gateway. The actual ingress and egress rules depend on your workloads and the traffic that you want to allow. Configure the ingress and egress rules when you move your workloads to OCI.

    Note: OELZ v1 creates stateful security lists. If you have a public-facing application or load balancer that requires you to support a large number of connections, we recommend that you create stateless security lists. For more information, see Stateful Versus Stateless Rules.

  • Route table: Used to map the traffic of a VCN from subnets through gateways to external destinations. OELZ v1 creates a route table associated with the internet gateway. You must create rules in the route table to allow necessary traffic to go to the internet gateway. The rules created depend on your workloads.

• Network Address Translation (NAT) gateway: Gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections. OELZ v1 creates a NAT gateway for the landing zone deployment. It also creates a route table and route rule to route traffic from each of your workload compartments. The actual route rules created depend on your workloads. Create the rules when you move your workloads to OCI.
• Private endpoints: Private IP address within your VCN that you can use to access a service within OCI. OELZ v1 creates private endpoints to access the following OCI services: Autonomous Database, Streaming, Data Safe, Data Catalog, Analytics Cloud, and Data Flow. We recommend that you use private endpoints if your workloads need to connect with any of these services.
• Service gateway: Lets cloud resources without public IP addresses privately access Oracle services without the traffic going over the internet. OELZ v1 creates a service gateway. You must create service CIDR labels, route rules, and security rules for the service gateway when you move your workloads to OCI. The configuration depends on your workloads.

Connectivity

With OELZ v1, you can optionally configure dynamic routing gateways (DRGs) using Site-to-Site VPN or FastConnect.

• Site-to-Site VPN: A site-to-site IPSec connection between your on-premises network and your VCN. Provide the IP address of your customer-premises equipment (CPE) to the landing zone Terraform module. Also provide the static routes for the IPSec connection.
• FastConnect: A dedicated, private connection between your data center and OCI, using your choice of Oracle partners. In addition to selecting an Oracle partner, provide the following information:
  • FastConnect routing policy
  • Virtual circuit bandwidth shape
  • Virtual circuit cross connect mapping - customer Border Gateway Protocol (BGP) peering
  • Virtual circuit cross connect mapping - Oracle BGP peering
  • Virtual circuit customer autonomous system number (ASN)

Cloud Guard

Use Cloud Guard to manage the security of your cloud resources in alignment with Oracle best practices.

Cloud Guard is a cloud-native service that helps customers monitor, identify, achieve, and maintain a strong security posture in the 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.

Use Oracle-managed recipes as the baseline starting point. Available recipes include:

• OCI configuration detector recipe: Set of rules designed to detect resource configuration settings that could pose a security problem.
• OCI activity detector recipe: Set of rules designed to detect actions on resources that could pose a security problem.
• Responder recipe: Defines the action or set of actions to take in response to a problem that a detector has identified.

OELZ v1 implements security best practices monitoring by enabling Cloud Guard at the tenancy level. It also enables security posture monitoring of the parent compartment by using Oracle-managed configuration detector recipes and activity detector recipes.

Note: To avoid potential application outages from unexpected platform modification, responder recipes aren't enabled. We recommend that you apply responder recipes after reviewing and testing them for your organization.

Consider the following information:

• Your Cloud Guard administrator should review the detector recipes and customize the scope with conditional groups as needed.
• Before enabling the responder recipes and related policies, your Cloud Guard administrator should review them with the stakeholders of any existing applications.
• You can create customer-managed responder recipes and detector recipes by cloning Oracle-managed recipes.

Vulnerability Scanning

Vulnerability and port scanning is enabled for the parent compartment of OELZ v1.

Vulnerability Scanning helps improve your security posture by routinely checking your cloud resources for potential vulnerabilities.

For information about the vulnerability sources and the platforms that the service detects vulnerabilities in, see Compute Targets.

The service also scans for ports in your compute instances that are unintentionally left open, might be a potential attack vector to your cloud resources, or enable hackers to exploit other vulnerabilities.

• A network mapper searches your public IP addresses for open ports.
• Agent-based scanning checks for open ports that aren't accessible from public IP addresses.

Your administrator can extend Vulnerability Scanning to the tenancy level by defining a scan target at the root compartment with a standard recipe.

Important: Because Windows scanning doesn't include Open Vulnerability and Assessment Language (OVAL) data, we recommend that you do not rely solely on Vulnerability Scanning to ensure your Windows instances are up to date and secure.

Prolonged Archiving of Audit Logs

Use retention rules to preserve OCI Audit logs for long-term data governance, regulatory compliance, and legal hold requirements.

Consider the following information:

• By default, Audit logs are retained for 365 days. If your organization needs to meet compliance or other requirements, you can optionally archive Audit logs for a longer length of time by saving them in immutable storage written to OCI Object Storage and Archive Storage buckets with locked, time-bound retention rules.
• You should deploy immutable Audit log archiving only when there is a strong business need to keep Audit logs for longer than the retention period.
• Review (or unlock) the retention rule within 14 days before it is locked.
  • Locking a retention rule is an irreversible operation. Not even a tenancy administrator can delete a locked rule.
  • There is a mandatory 14-day delay before a rule is locked. This delay lets you thoroughly test, modify, or delete the rule or the rule lock before the rule is permanently locked.
  • A rule is active at the time of creation. The lock only controls whether the rule itself can be modified. After a rule is locked, only increases in the duration are allowed.
  • Object modification is prevented and the rule can only be deleted by deleting the bucket. A bucket must be empty before it can be deleted.
  • To avoid difficulties in cleaning up your testing environment, consider using a short retention period in non-production environments, such as one day.
• By default, Oracle manages the keys that encrypt the Object Storage or Archive Storage buckets. If you want greater control over the lifecycle and use of your encryption keys, you can choose a key from a vault that you have access to. For more information, see Overview of Vault.
• After the audit log bucket is created, you can manually enable the write access logs to meet the Center for Internet Security (CIS) Oracle Cloud Infrastructure Benchmark.
• You can integrate logs with third-party security information and event management (SIEM) solutions using the Service Connector Hub and Streaming services. For examples, see Oracle Cloud Infrastructure logging plugin for Splunk and Move logs from Oracle Cloud Infrastructure into IBM QRadar.

Bastion

The Bastion service provides secured, session-based access to resources without public endpoints.

Bastions let authorized users connect from specific IP addresses to target resources using Secure Shell (SSH) sessions. When connected, users can interact with the target OCI resource by using any software or protocol supported by SSH. For example, you can use the Microsoft Remote Desktop Protocol (RDP) to connect to a Windows host, or use Oracle Net Services to connect to a database.

Consider the following information:

• A bastion is associated with a single virtual cloud network (VCN). You cannot create a bastion in one VCN, and then use it to access target resources in a different VCN.
• Bastions, like most OCI resources, are subject to service limits. Request a service limit increase if needed, and consider subcompartments for your bastions as an alternative.

VCN Flow Logs

Use VCN Flow Logs to view details about traffic that passes through your VCN.

VCN Flow Logs help you audit traffic and troubleshoot your network controls. After you enable VCN Flow Logs, they record traffic for the virtual network interface cards (VNICs) attached to compute instances in the subnet.

Your operational teams can use the predefined VCN Flow Logs dashboard in OCI Logging Analytics, or create custom dashboards to meet your organization's specific needs.