火山引擎 Landing Zone 建设方案

1. 方案概述与建设目标

本方案面向公有云多账号治理场景，目标是在火山引擎企业组织下建立一套标准化、可扩展、可持续运营的 Landing Zone。 它不是单一资源集合，而是一套围绕组织结构、账号体系、统一身份、审计留痕、网络底座与财务边界构建的治理框架， 用于支撑后续业务账号接入、权限控制、成本治理和平台运营。

2. 核心治理域设计

2.1 组织与账号架构方案

目标账号架构围绕企业组织分层展开，重点体现管理账号、根组织、顶层 OU、Applications 子 OU 以及各核心账号的落位关系。 其中治理账号集中落在 `Platform` OU，业务账号按环境落在 `Applications` OU 的子层级中。

组织节点与账号用途说明

2.2 企业财务方案

企业财务方案是针对多账号提供的云上跨账号商务与履约（资金、发票、账单）一体化管理体系。 通过关联管理，以企业视角统筹云上资源使用，实现统一出账、统一结算与集中资金管理。

• 财务托管（本方案默认）：将所有成员账号的账单、发票、结算和合同优惠统一托管给企业管理账号（Management account）。成员账号的资源消耗直接由管理账号统一出账和支付，最大化降低各业务团队的分散结算负担。
• 财务管理（可选模式）：仅进行信控划拨、优惠共享和代开发票。成员账号仍保持独立出账和结算。适用于需要保持强财务独立性的子公司或跨实体企业。
• 成本分摊与可见性：无论采用哪种模式，均可通过组织单元（OU）结构和资源标签（Tag）体系，实现按部门、项目或环境（Dev/Staging/Prod）的成本多维分摊核算，提供精细化的成本运营数据。

2.3 员工身份权限方案

基于统一的身份与访问管理机制，建立企业级的登录入口与精细化的权限管控体系。

• 人员主路径标准化：员工统一通过企业 IdP 接入云身份中心，再映射为各目标账号内的角色访问控制台；如需调用 API / SDK，优先通过 STS 获取临时凭证，无需在成员账号中为人员保留长期密钥。
• 程序身份与人员解耦：应用、自动化脚本和 CI/CD 等程序主体使用账号内的程序身份（如 IAM User）进行编程访问；长期 AK / SK 仅保留给确有需要的程序场景，并应独立托管、定期轮换。
• 统一身份与最小特权：以企业自有 IdP 为唯一身份源，通过 SSO 接入云身份中心后集中分配权限集。相同身份可映射到多个账号，并在不同业务账号或环境中按职责分离（SoD）和最小特权（Least Privilege）获得权限。
• 集中生命周期治理：人员入职、调岗或离职时，只需在身份中心完成一次变更，即可同步收敛其在各成员账号中的访问权限，减少离职残留账号和跨账号权限失管风险。

预置权限集总览

在底座身份阶段（03-identity）会统一创建以下 5 个权限集，命名与火山引擎系统策略一致；只有 AdministratorAccess 会自动分配到管理员用户，并下发到管理账号与核心账号列表，其它权限集供后续在 account-factory baseline 中按需绑定到具体人员或用户组。下表为静态总览，便于快速理解；权限集的权威说明与实时分配状态以 03-identity 阶段输出的 permission_set_catalog 为准。

2.4 审计日志归集方案

满足企业安全合规要求，实现全网操作行为的统一审计与安全事件的集中留痕。

• 组织级统一采集：由管理账号在组织层开启并配置组织级跟踪，统一采集现有及未来新增成员账号的操作日志与 API 调用记录，避免逐账号重复配置与漏配。
• 控制面与归档面分离：通过委派管理机制将云审计管理职责收敛到 Log archive 账号，同时将日志集中归集到独立的 TOS 日志归档桶，清晰区分“谁管理”和“谁存储”。
• 集中留存与防篡改：归档日志所在的 Log archive 账号应实行严格访问控制，与业务账号隔离，确保审计数据长期留存、不可篡改，并满足等保或行业合规要求。

2.5 企业网络方案

构建安全、高效、可扩展的云上网络底座，规范不同账号、不同环境之间的网络互联与隔离边界。

• 枢纽式网络底座：在 Network 账号中集中部署中转路由器（TR）作为跨账号互联枢纽，由其统一承担路由收敛；中心 VPC 是接入对象之一，而非 TR 的容器或内部组件。
• 统一公网出向：在 Network 账号中集中预置 NAT 网关与 EIP，作为标准的共享公网出向（Egress）通道，收敛企业的公网访问边界。
• 委派资源共享管理：为避免由管理账号长期直接操作共享单元，先在企业组织中将资源共享服务的委派管理员授权给 Network 账号，使网络共享能力的管理职责收敛到网络账号。
• 通过资源共享预置接入入口：由 Network 账号以资源所有者身份先创建并持有 TR 共享单元，仅在网络底座阶段完成共享能力预置和 TR 资源关联，不在此阶段把共享范围一次性扩展到整个组织。
• 跨账号统一接入：后续每个新业务账号在账号工厂 baseline 中被逐个加入该共享单元，再通过标准化的跨账号接入方式连接到共享 TR；这样既保留统一接入路径，也避免对未启用账号预先放开共享范围。
• 按需互通与边界隔离：本地数据中心可通过云专线或 IPsec VPN 接入网络枢纽，再由统一路由策略决定与中心 VPC、业务 VPC 的互通范围，避免默认全互通带来的横向移动风险。

2.6 账号工厂与基线方案

在 Landing Zone 底座搭建完成后，可通过账号工厂（Account Factory）按统一规则持续创建新账号，并在账号创建完成后按需为该账号补充标准化基线配置。 当前能力聚焦于“创建账号”这一主流程，以及账号创建后的 baseline 选择、现场创建和应用，不将其扩展描述为独立的通用模板平台。

• 主流程始终是创建账号：账号工厂首先负责新账号创建，并在创建过程中同步完成账号的目标 OU 落位、财务关系挂接和基础标签写入，确保新账号在进入组织后立即具备基本治理属性。
• baseline 是可选增强项：baseline 不是账号创建前置条件，而是账号创建完成后的标准配置包。用户可以选择仅创建账号，也可以继续选择已有 baseline、现场创建 baseline，再按确认节奏应用到目标账号。
• 当前能力边界清晰：当前提供内置的基础预置模块，用于把新业务账号纳入既有共享网络范围、接入企业网络底座或下发通用配置；其中网络类 baseline 会复用 05-network 已交付的共享网络与中心路由能力。如有企业自定义扩展需求，也可挂载客户自定义 Terraform 模块纳入同一条 baseline 应用流程。
• 分步驻停而非整链路直推：账号创建、baseline 选择或创建、baseline 应用都会按“说明 -> 准备 -> 确认 -> 执行 -> 总结”的节奏推进，不会默认把所有动作一次性自动执行到底。

3. 实施范围、计划与确认机制

3.1 实施边界

• 本次方案聚焦 Landing Zone 治理底座，不包含具体业务系统、应用中间件或业务流量迁移内容。
• 本次方案不默认覆盖所有账号工厂、客户自定义基线或个性化扩展模块，后续如需扩展可在既有底座上继续建设。
• 本次方案不以“重建现网”为目标，已存在且符合标准的组织结构或资源将优先复用。
• 具体资源数量和结果以实际执行时的现网状态与权限条件为准。

3.2 落地原则

3.3 实施计划与结果交付

本次实施完成后，将自动生成一份《Landing Zone 建设结果报告》，汇总实际落地的组织结构、账号关系、身份能力、日志目标与网络底座结果，便于对照本方案确认最终实施情况。

3.4 启动前确认事项

• 已理解本次将建设的是标准化 Landing Zone 治理底座，而不是完整业务系统交付。
• 已接受本方案中的目标架构、建设边界与各项治理域设计。