Cloud Adoption Framework Landing Zone

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 on 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

The CAF Landing Zone follows 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

Say that you want to deploy three workloads on OCI: a finance application, a human resources (HR) application, and a marketing application.

The first step is to deploy the Enterprise Scale Baseline Landing Zone modules, which create the foundation of your environment.

After you deploy the core infrastructure components, you run the 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 Workload Expansion stack and defining the relevant parameters needed for each application. When you are ready, you can migrate each application into 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, the CAF Landing Zone creates IAM groups and policies. For information about the IAM groups created by the CAF Landing Zone, see IAM Policies and Groups.

Federating with Microsoft Active Directory

With the Enterprise Scale Baseline Landing Zone, you can optionally federate with Microsoft Active Directory.

Use the same group names in Oracle Cloud Infrastructure as you use for Active Directory. To do this, pass the Active Directory group names as variables to the Enterprise Scale Baseline Landing Zone Terraform module. The groups will be created by the landing zone and mapped to your Active Directory groups.

The following diagram shows the Microsoft Active Directory federation supported by the Enterprise Scale Baseline Landing Zone.

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

IAM Policies

For information about the IAM policies created by the CAF Landing Zone, see IAM Policies and Groups.

Subnets

The CAF Landing Zone creates public and private subnets within the VCN.

• Subnet-Public: A 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, as described in Security.

• Subnet-Shared Services: A 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/west traffic) to enter and exit this subnet. Create security lists during the deployment of your workloads.

• Subnet Bastion Service: A 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 Workload Expansion stack. A private subnet that you should use to host all resources that are 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 Workload Expansion stack. A private subnet to host database resources for your applications. You can create multiple subnets, one for each workload's database resources.

Gateways

The CAF Landing Zone creates the gateways that your applications might need to connect with Oracle Cloud Infrastructure services and the internet, plus the basic components to control access.

• Internet gateway: A virtual router that connects the edge of the VCN with the internet to allow direct connectivity to the internet. The CAF Landing Zone creates an internet gateway, and the following components along with the internet gateway:

  • Security lists: Security lists are virtual firewalls that let you control ingress and egress traffic. The CAF Landing Zone creates a security list associated with the internet gateway. The actual ingress and egress rules will 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: The CAF Landing Zone creates stateful security lists. If you have a public-facing application or load balancer that requires you to support a very large number of connections, we recommend that you create stateless security lists. For more information, see Stateful Versus Stateless Rules.

  • Route table: Route tables are used to map the traffic of a VCN from subnets through gateways to external destinations. The CAF Landing Zone creates a route table that is 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 will depend on your workloads.

• Network Address Translation (NAT) gateway: A NAT gateway gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections. The CAF Landing Zone 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 will depend on your workloads. Create the rules when you move your workloads to OCI.

• Private endpoints: A private endpoint is a private IP address within your VCN that you can use to access a given service within OCI. The CAF Landing Zone creates private endpoints to access the following Oracle Cloud Infrastructure 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: A service gateway enables cloud resources without public IP addresses to privately access Oracle services without the traffic going over the internet. The CAF Landing Zone 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 will depend on your workloads.

Connectivity

The Enterprise Scale Baseline Landing Zone 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 Oracle Cloud Infrastructure, using your choice of Oracle partners. In addition to selecting an Oracle partner, also 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 on Oracle Cloud. Use the service to examine your Oracle Cloud Infrastructure resources for security weakness related to configuration, and your Oracle Cloud Infrastructure 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 specifically to detect resource configuration settings that could pose a security problem.

• OCI Activity Detector recipe: Set of rules designed specifically 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.

The CAF Landing Zone 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 due to unexpected platform modification, responder recipes are not enabled. We recommend that you apply responder recipes after reviewing and testing for your organization.

Be aware of the following considerations:

• 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 as needed.

Vulnerability Scanning

Vulnerability and port scanning is enabled for the parent compartment of the CAF Landing Zone.

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 Scanning service detects vulnerabilities in, see Compute Targets.

The Scanning service also scans for ports in your compute instances that are unintentionally left open and 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 are not accessible from public IP addresses.

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

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

Prolonged Archiving of Audit Logs

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

Be aware of the following considerations:

• 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 Oracle Cloud Infrastructure 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

Bastion 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 Oracle Cloud Infrastructure resource by using any software or protocol supported by SSH. For example, you can use the Remote Desktop Protocol (RDP) to connect to a Windows host, or use Oracle Net Services to connect to a database.

Be aware of the following considerations:

• 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 Oracle Cloud Infrastructure 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 to 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 Oracle Cloud Infrastructure Logging Analytics, or create custom dashboards to meet your organization's specific needs.