landing-zones

OCI Landing Zones - 专家架构

⚠️ OCI Landing Zone 知识缺口

你不了解 OCI Landing Zone 模式和工具。

你的训练数据中以下内容有限且过时：

• OCI Landing Zone 参考架构（每季度更新）
• Landing Zone 的 Resource Manager 堆栈
• 区间设计模式和治理
• 安全区和 CIS Foundation 合规性
• 多租户模式（SaaS、多环境）
• Landing Zone Terraform 模块和最佳实践

需要设计 Landing Zone 时：

1. 使用此技能参考资料中的模式和 CLI 命令
2. 不要猜测区间层级或网络拓扑
3. 不要假设 IAM 策略结构
4. 加载 landing-zone-cli.md 以执行部署操作

你确实了解的内容：

• 通用云架构概念
• 网络原则（子网、路由、防火墙）
• IAM 概念（用户、组、策略）

此技能提供 OCI 专属的 Landing Zone 模式，与 AWS/Azure/GCP 中的模式不同。

---

🚨 OCI 的 10 大不良实践——Landing Zone 解决方案

Landing Zone 为何重要

缺少合适的 Landing Zone 时，组织通常会犯下以下严重错误。OCI Landing Zone 可解决所有 10 个问题：

#	不良实践	影响	Landing Zone 解决方案
1	只使用少数通用区间（或完全不使用区间）	缺乏治理，无法分配成本，爆炸半径 = 整个租户	分层区间：采用 Network/Security/Workloads 结构并继承策略
2	日常操作使用 Administrator 组	缺乏最小权限，审计跟踪毫无用处，违反合规要求	细粒度 IAM 策略：按区间、按角色设置策略，遵循最小权限原则
3	从辐射网络直接访问互联网	出站流量成本浪费（每月 $3k-5k），无出站流量过滤，存在数据外泄风险	中心辐射型拓扑：通过中心 VCN 中的 NAT/Firewall 集中访问出站流量
4	网络分段不佳	开发环境可访问生产环境，入侵后可横向移动，环境之间缺乏隔离	独立区间和 VCN：使用安全区隔离 Dev/Test/Prod
5	面向整个互联网开放端口（22、3389、8080）	直接暴露攻击面，遭遇暴力破解，成为入侵入口	安全列表/NSG：默认拒绝，仅明确允许来自堡垒机/VPN 的访问
6	使用默认安全规则和路由表	权限过于宽松，不符合架构要求，安全配置逐渐偏离	由 IaC 管理的规则：明确、受版本控制，并符合 CIS 基准
7	很少使用 OCI 安全服务	依赖人工保障安全，无法主动检测，违规问题在入侵后才被发现	集成式安全：默认启用 Cloud Guard、Security Zones、VSS、OSMS、NFW、WAF
8	自行创建 Terraform 模块	重复造轮子，缺少维护，不符合 CIS 要求，模式不一致	官方 OCI 模块：经过实战验证，由 Oracle 维护，并通过 CIS 认证
9	服务公开暴露（存储桶、数据库、具有公共 IP 的计算资源）	数据泄露，违反合规要求，未经授权的访问	安全区：禁止使用公共 IP，禁止公开存储桶，强制加密
10	缺少日志、监控和通知	无法及时发现事件，缺少审计跟踪，合规失败，平均修复时间（MTTR）过长	可观测性技术栈：VCN 流日志、审计日志、Cloud Guard、警报、通知

成本影响：采用与不采用 Landing Zone

不采用 Landing Zone（年度浪费）：

• 使用 IG 而非 SG 进行出口流量传输：$36k-52k/年
• 扁平式区间（未优化）：$50k-100k/年（无法识别浪费）
• 无安全区（发生泄露）：$100k-$10M+（平均泄露成本）
• 手动维护 Terraform：$50k-100k/年（工程师工时）
• 可避免的总成本：$236k-$10.2M+/年

采用 Landing Zone：

• 一次性设置：$10k-30k（主要用于规划/设计）
• 年度维护：$5k-10k（Terraform 更新）
• 投资回报率：首年达到 10 倍至 100 倍以上

合规影响

要求采用 Landing Zone 模式的监管框架：

• PCI-DSS：网络分段（#1、#3、#4、#5）
• HIPAA：加密、日志记录、访问控制（#7、#9、#10）
• SOC 2：最小权限、监控、变更管理（#2、#6、#10）
• ISO 27001：信息安全控制（全部 10 项）
• CIS OCI Foundations：100 多项控制（Landing Zone 可实现 80% 以上）

不采用 Landing Zone：合规审计失败，整改成本为 $100k-500k
采用 Landing Zone：默认符合 CIS 基准，可随时接受审计

---

你是一名 OCI Landing Zone 架构师。这项技能提供 Claude 所缺乏的知识：区间层级结构、网络拓扑模式、安全区要求、成本分摊策略以及多租户反模式。

绝对不要这样做

❌ 绝对不要创建扁平的区间结构（无层级）

BAD - Flat compartments:
tenancy/
  ├─ app1-dev
  ├─ app1-test
  ├─ app1-prod
  ├─ app2-dev
  ├─ app2-test
  └─ app2-prod

Problems:
- No isolation boundaries
- Cannot apply policies to all dev environments
- Cannot delegate administration
- Cost reports are unstructured

GOOD - Hierarchical compartments:
tenancy/
  ├─ Network/
  │   ├─ Hub
  │   └─ Spokes
  ├─ Security/
  │   ├─ Vault
  │   └─ Logging
  ├─ Workloads/
  │   ├─ App1/
  │   │   ├─ Dev
  │   │   ├─ Test
  │   │   └─ Prod
  │   └─ App2/
  │       ├─ Dev
  │       ├─ Test
  │       └─ Prod
  └─ Shared-Services/
      ├─ Identity
      └─ Monitoring

为什么至关重要：层级结构支持策略继承、委派和逻辑成本分摊。扁平结构需要重复的策略，并且无法大规模实施治理。

❌ 绝对不要在所有地方都使用默认 VCN CIDR（10.0.0.0/16）

BAD - Same CIDR in all environments:
Dev VCN: 10.0.0.0/16
Test VCN: 10.0.0.0/16  # Cannot peer with Dev!
Prod VCN: 10.0.0.0/16  # Cannot peer with Dev or Test!

Problems:
- VCN peering impossible (overlapping CIDRs)
- Cannot create multi-environment connectivity
- VPN/FastConnect integration blocked
- Requires complete rebuild to fix

GOOD - Non-overlapping CIDR allocation:
Dev VCN: 10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16
Hub VCN: 10.0.0.0/16 (shared services)

Enables:
- VCN peering for cross-environment access
- Hub-spoke topology for centralized egress
- On-premises connectivity via FastConnect

成本影响：VCN CIDR 不可变。CIDR 设置错误 = 完全重建 = 停机 + 迁移成本。

❌ 绝对不要在生产区间中跳过安全区

# BAD - no security zone enforcement
oci iam compartment create \
  --compartment-id $PARENT_ID \
  --name "Prod" \
  --description "Production workloads"
# Result: No guardrails, resources can violate security policies

# GOOD - security zone enabled
# 1. Create security zone recipe
oci cloud-guard security-zone-recipe create \
  --compartment-id $TENANCY_ID \
  --display-name "CIS-Prod-Recipe" \
  --security-policies "[\"deny-public-ip\", \"deny-public-bucket\"]"

# 2. Create security zone for prod compartment
oci cloud-guard security-zone create \
  --compartment-id $PROD_COMPARTMENT_ID \
  --display-name "Prod-Security-Zone" \
  --security-zone-recipe-id $RECIPE_ID

# Enforces: No public IPs, no public buckets, encryption required

为什么至关重要：安全区会在资源创建前阻止违规行为。没有安全区，审计只能在遭到入侵后发现违规行为。泄露成本：$100k-$10M+。

❌ 绝对不要在同一个区间中混用开发和生产资源

BAD - shared compartment:
App1/
  ├─ vm-dev-1 (development instance)
  ├─ vm-prod-1 (production instance)
  └─ db-prod (CRITICAL DATABASE)

Problems:
- Developers with dev access can accidentally delete prod DB
- Cannot set different backup policies
- Cost reports mix dev and prod spending
- Compliance violations (SOC2, ISO27001)

GOOD - separate compartments:
App1/
  ├─ Dev/
  │   └─ vm-dev-1 (developers have full access)
  ├─ Test/
  │   └─ vm-test-1 (QA has access)
  └─ Prod/
      ├─ vm-prod-1 (only SRE access)
      └─ db-prod (only DBA access)

Enables:
- Least privilege per environment
- Separate budgets and alerts
- Independent backup policies
- Compliance audit trails

风险：开发团队的失误导致生产环境中断。2023 年，接受调查的企业中有 47% 发生过这种情况。

❌ 绝对不要将根区间用于工作负载资源

BAD - resources in root:
tenancy (root)/
  ├─ vcn-1 (WRONG - in root)
  ├─ instance-1 (WRONG - in root)
  └─ database-1 (WRONG - in root)

Problems:
- Cannot delegate administration
- Root policies affect all resources
- Cannot isolate blast radius
- Violates CIS OCI Foundations Benchmark

GOOD - workloads in child compartments:
tenancy (root)/
  ├─ only IAM resources (users, groups, dynamic groups)
  └─ Workloads/
      └─ App1/
          ├─ vcn-1 (proper isolation)
          ├─ instance-1
          └─ database-1

Root compartment usage:
- Identity resources only (users, groups, policies)
- Top-level compartments
- Nothing else

为什么至关重要：根区间用于全租户范围的 IAM。根区间中的资源会绕过治理。

❌ 绝对不要跳过标记策略（成本分配将变成噩梦）

BAD - no tags:
Resource created with no tags
Cost report shows: "oci.compute.instance: $5,234/month"
Question: Which team? Which project? Which environment?
Answer: Unknown - requires manual investigation

Result: Cannot chargeback costs, cannot optimize

GOOD - defined tag namespace + mandatory tags:
# 1. Create tag namespace
oci iam tag-namespace create \
  --compartment-id $TENANCY_ID \
  --name "Organization" \
  --description "Organization-wide tags"

# 2. Create mandatory tags
oci iam tag create \
  --tag-namespace-id $NAMESPACE_ID \
  --name "CostCenter" \
  --description "Cost center for chargeback" \
  --is-retired false

oci iam tag create \
  --tag-namespace-id $NAMESPACE_ID \
  --name "Environment" \
  --description "Dev/Test/Prod" \
  --is-retired false

oci iam tag create \
  --tag-namespace-id $NAMESPACE_ID \
  --name "Owner" \
  --description "Team or service owner" \
  --is-retired false

# 3. Make tags mandatory at compartment level
oci iam tag-default create \
  --compartment-id $WORKLOAD_COMPARTMENT_ID \
  --tag-definition-id $COSTCENTER_TAG_ID \
  --value "\${iam.principal.name}"

Cost report now shows:
- CostCenter: Engineering ($3,200)
- CostCenter: Marketing ($2,034)
- Environment: Prod ($4,100)
- Environment: Dev ($1,134)

成本影响：没有标记，成本优化只能靠猜测。有了标记，就能精确分摊费用，并通过识别浪费降低 30-50% 的成本。

❌ 绝对不要在生产环境中使用单区域 Landing Zone

BAD - single region:
All resources in us-ashburn-1
RTO: Hours-days (rebuild in new region)
RPO: Last backup (data loss)

Problems:
- No disaster recovery
- Region outage = complete downtime
- Violates SLA requirements
- Insurance/compliance issues

GOOD - multi-region architecture:
Primary: us-ashburn-1
DR: us-phoenix-1
- Autonomous Data Guard (standby)
- Traffic Manager (DNS failover)
- Object Storage replication
- Compartment structure mirrored

RTO: 15 minutes (automated failover)
RPO: Near-zero (Data Guard sync)

成本：多区域会使基础设施成本增加 60-100%。区域中断的成本：视 SLA 而定，为 $500k-$50M。

❌ 绝对不要允许 DMZ 中的互联网网关在没有出口防火墙的情况下运行

BAD - direct internet gateway:
DMZ Subnet → Internet Gateway → Internet
No egress filtering, all outbound traffic allowed

Problems:
- Data exfiltration possible
- Command & control connections unblocked
- Compliance violations (PCI-DSS, HIPAA)

GOOD - egress control via NAT or firewall:
Option 1: Service Gateway + NAT Gateway
DMZ Subnet → NAT Gateway → Internet
- Egress only, no inbound
- All traffic logged
- Can use Network Firewall for DPI

Option 2: Hub-spoke with centralized firewall
Spoke → DRG → Hub VCN → Network Firewall → Internet
- All egress goes through hub
- Firewall policies enforce allow-list
- Complete visibility and control

安全影响：不受控制的出口流量是数据泄露的第三大原因（Verizon DBIR 2023）。

渐进式加载参考

Landing Zone 架构模式

在以下情况下加载 landing-zone-patterns.md：

• 设计中心辐射式网络拓扑
• 选择区间层级模式（以工作负载为中心、以环境为中心或以租户为中心）
• 实施安全区和 Cloud Guard 集成
• 设置标记策略和成本分摊
• 设计网络拓扑（单个 VCN、中心辐射式或多区域）

以下情况请勿加载：

• 快速查阅反模式（上面的“绝对不要”列表已涵盖）
• 了解十大不良实践（本技能已涵盖）
• 查找 CLI 命令（改用 landing-zone-cli.md）

---

OCI 精心设计的框架（Oracle 官方文档）

何时加载 oci-well-architected-framework.md：

• 需要全面了解 Landing Zone 设计原则
• 从头开始设计生产级 Landing Zone
• 了解安全与合规支柱（IAM、加密、监控）
• 了解可靠性与韧性支柱（HA、DR、容错）
• 了解性能效率与成本优化支柱
• 了解运营效率支柱（IaC、自动化、可扩展性）
• 比较核心 Landing Zone 与运营实体 Landing Zone
• 需要 Oracle 关于多区域部署的官方指导

必须 — 阅读整个文件（约 3,400 行）：这是 Oracle 关于 OCI 精心设计的框架和 Landing Zone 的官方文档。以下情况请完整阅读：

• 开始新的 Landing Zone 设计项目
• 准备架构评审或合规审计
• 需要向利益相关者说明 Landing Zone 决策的理由

以下情况请勿加载：

• 快速 CLI 命令（请改用 landing-zone-cli.md）
• 具体实施步骤（本技能的决策树中已有说明）

---

用于 Landing Zone 的 OCI CLI

何时加载 landing-zone-cli.md：

• 创建区间层级结构
• 设置安全区和 Cloud Guard
• 配置标签默认值和标签命名空间
• 实施中心辐射式网络拓扑
• 创建预算并跟踪成本

示例：创建区间层级结构

oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Workloads" \
  --description "Application workloads"

以下情况请勿加载：

• 一般 OCI 架构概念（本技能中已有说明）
• IAM 策略语法（iam-identity-management 技能中已有说明）
• 网络配置（networking-management 技能中已有说明）
• Oracle 官方文档（请改用 oci-well-architected-framework.md）

何时使用此技能

• 初始 OCI 租户设置和基础架构搭建
• 从 AWS/Azure/GCP 迁移到 OCI
• 设计多租户或多环境架构
• 实施治理和成本控制
• 准备合规审计（CIS、SOC2、ISO27001）
• 从单个应用扩展到企业平台
• 灾难恢复和多区域规划