docs:add infra guidelines-infrastructure-AtomGit

已合并

docs:add infra guidelines #57

gcw_u8HHrTWX创建于 4月28日从gcw_u8HHrTWX/infrastructure： master 合入到 Ascend/infrastructure： master

docs:add infra guidelines #57

已合并

gcw_u8HHrTWX创建于 4月28日

从gcw_u8HHrTWX/infrastructure master合入到Ascend/infrastructure master

共 2 个文件变更+243-0

Adocs/figures/基础设施服务需求设计流程.png+0-0

Ainfra-sdlc-guidelines.md+243-0

@@ -0,0 +1,243 @@
	1	+# 社区基础设施软件开发生命周期治理与安全规范V1.0
	2	+
	3	+## 1. 概述
	4	+
	5	+本规范定义了社区基础设施软件在开发生命周期内的治理要求。核心目标是通过深度集成安全与质量门禁，构建安全可靠的社区基础设施平台。
	6	+
	7	+***
	8	+
	9	+## 2. 适用范围
	10	+
	11	+本规范适用于社区基础设施网站前后台系统，不包括独立于社区网站之外单独发布的软件工具包。
	12	+
	13	+## 3. 核心原则
	14	+
	15	+在基础设施的全生命周期中中，必须始终遵循以下安全原则：
	16	+
	17	+* 纵深防御原则 \(Defense in Depth\): 绝不依赖单一安全机制。通过多层独立的保护措施（如网络过滤、身份验证、系统加固），确保即使一层失效，其他层仍能提供保护。
	18	+
	19	+* 最小特权原则 \(Least Privilege\): 任何主体（用户、程序、系统）仅被授予完成其任务所必需的最低权限，且仅在必要的时间段内生效。
	20	+
	21	+* 默认安全原则 \(Secure by Default\): 软件与基础设施在交付时应处于最安全状态。非必要功能默认关闭，不安全的协议默认禁用，权限默认拒绝。
	22	+
	23	+* 失效安全原则 \(Fail\-safe Defaults\): 当系统发生异常、崩溃或认证服务中断时，应自动进入“安全锁定”状态，而非开放访问或泄露数据。
	24	+
	25	+* 最小化攻击面 \(Minimize Attack Surface\): 通过减少公开接口、剥离冗余组件、关闭监听端口，尽可能降低攻击者可触达的切入点。
	26	+
	27	+* 零信任架构 \(Zero Trust\): 不再信任“内网”或“私有云”边界。任何访问请求，无论来源何处，都必须经过持续的验证、授权和加密。
	28	+
	29	+* 职责分离 \(Separation of Duties\): 将关键任务的操作权、审批权与审计权分配给不同的维护者，防止单点账号沦陷或内部恶意操作导致全局破坏。
	30	+
	31	+* 透明度与可追溯性 \(Transparency & Traceability\): 所有的操作必须是可观察、可追溯且不可篡改的，确保“谁、何时、做了什么”都有清晰的凭证。
	32	+
	33	+## 4. 全生命周期规范 \(Lifecycle Standards\)
	34	+
	35	+说明：
	36	+
	37	+* 【MUST】：必须执行，不达标则阻断
	38	+
	39	+* 【SHOULD】：推荐执行，不达标需Infra Sig确认
	40	+
	41	+### 4.1 规划阶段 \(Planning & Governance\)
	42	+
	43	+核心：基线确立与风险预判。
	44	+
	45	+#### 1. 【MUST】需求管理：必须通过需求管理平台跟踪需求，由社区基础设施产品经理负责收集、分析和管理需求。
	46	+
	47	+* 详细描述：所有新增功能或架构调整必须首先在需求平台创建正式任务单。产品经理（PM）需对需求的合理性进行初步分析，并根据安全定级识别潜在的合规风险。未经PM确认的需求禁止进入后续阶段。
	48	+* 原因：
	49	+ 基础设施的复杂性源于非受控的需求蔓延。强制需求管理确保了所有开发活动都具备明确的业务目标与社区授权，能够从源头拦截不合理、不安全或与社区治理目标相悖的预研行为，防止“隐形功能”绕过安全监管点，从而降低基础设施的整体受攻击面。
	50	+
	51	+### 4.2 需求分析与设计阶段 \(Design & Architecture\)
	52	+
	53	+核心：默认安全与隔离设计。
	54	+
	55	+#### 1. 【MUST】隐私影响及合规评估：涉及个人数据的服务必须执行隐私合规评估和在隐私声明中添加对应隐私条款。
	56	+
	57	+* 详细描述：针对采集和处理个人信息的行为执行隐私影响评估，确保个人数据在隐私声明中有相应的隐私描述。
	58	+
	59	+* 原因：数据违规采集面临严重的合规风险。前置评估能识别法律风险点，防止因敏感信息泄露导致的法律诉讼与社区信誉受损。
	60	+
	61	+#### 2. 【MUST】机密分发流程：严禁在设计文档中披露明文凭证（Secrets)。
	62	+
	63	+* 详细描述：方案设计文档禁止包含真实的 API Key、密码或私钥。
	64	+
	65	+* 原因：文档的非受控流转易导致次生泄露。确保机密不出现在静态文档中，是防止生产凭据外泄的基础要求。
	66	+
	67	+#### 3. 【MUST】最小权限设计：明确每个服务账号和组件运行最小权限。
	68	+
	69	+* 详细描述：明确每个组件所需的最小权限集，严格限制特权账户（root）的使用，默认拒绝所有额外请求。
	70	+
	71	+* 原因：权限过度授予会扩大单点失陷后的损失。最小权限确保组件被攻破后，攻击者因权限受限无法在内网横向移动。
	72	+
	73	+#### 4. 【SHOULD】限流方案：对于社区核心模块，应当设计系统级限流策略，防止基础设施被突发流量冲垮。
	74	+
	75	+* 详细描述：对于社区核心模块，组织应当流量阈值、过载保护或限流逻辑，确保异常流量下核心功能可用。
	76	+
	77	+* 原因：可用性是安全的核心之一。方案确保系统遭遇异常负荷或小规模 DDoS 时能优雅降级，维持基础设施底座的基本可用。
	78	+
	79	+### 4.3 开发编码阶段 \(Development\)
	80	+
	81	+核心：工具化门禁与代码完整性。
	82	+
	83	+#### 1. 【MUST】分支保护：默认分支必须设置保护分支，如master、main发布分支需通过PR合入。
	84	+
	85	+* 详细描述：代码仓库的默认分支必须开启保护机制。禁止包括管理员在内的任何角色直接推送代码。所有变更必须通过Pull
	86	+ Request（PR）发起，且需满足“人工审核通过”与“自动化流水线（扫描、测试）通过”双重条件方可合入。
	87	+
	88	+* 原因：默认分支承载核心业务逻辑，直接推送极易引入未经核实的故障或漏洞。通过强制PR合入，可利用代码评审拦截缺陷，并依托自动化检测屏蔽风险代码，确保核心代码库的质量与审计记录的完整性。
	89	+
	90	+#### 2. 【MUST】贡献CLA：社区开源贡献者必须签署CLA，确保源码来源合法。
	91	+
	92	+* 详细描述：贡献者在社区提交代码前，必须在线签署协议，确认其提交的代码是原创的或已获得授权。未签署协议的 PR（合并请求）禁止合入。
	93	+
	94	+* 原因：授权不明是开源项目的法律风险源。CLA 明确了知识产权归属，防止恶意开发者利用版权争议勒索社区，确保合入源码无版权瑕疵。
	95	+
	96	+#### 3. 【MUST】 SAST自动化：流水线集成静态安全扫描工具，进行安全编码和漏洞扫描。
	97	+
	98	+* 详细描述：代码仓库的 CI/CD 流水线必须集成静态分析工具。在 PR
	99	+ 创建及代码合入等关键节点，自动扫描安全编码规范及常见漏洞。未通过安全扫描或存在未修复高危漏洞的变更，流水线必须强制阻断。
	100	+
	101	+* 原因：人工审计难以覆盖高频迭代中的所有缺陷。通过自动化扫描可在开发早期拦截安全风险，防止漏洞与敏感信息进入保护分支。这能显著降低后期修复成本，保障基础设施源码的安全性与合规性。
	102	+
	103	+#### 4. 【MUST】密钥扫描机制：建立敏感信息（Secrets）扫描机制，严禁凭证硬编码。PR阶段实时和全量定时扫描并包含硬编码凭证的提交,存在密钥自动阻断PR。
	104	+
	105	+* 详细描述：代码仓库必须建立敏感信息扫描机制。在 PR 提交阶段执行实时增量扫描，并对全量分支执行周期性定时扫描。扫描范围涵盖API
	106	+ 密钥、访问令牌、私钥、密码等硬编码凭证。若识别到敏感信息，流水线必须自动阻断 PR 合入，要求开发者通过环境变量或密钥管理服务进行整改。
	107	+
	108	+* 原因：硬编码凭证极易被自动化工具抓取并导致严重的系统入侵或数据泄露。通过“实时拦截+定期回溯”的双重机制，能从源头阻断凭证流向代码库，降低基础设施的受攻击面，确保核心敏感资产的安全。
	109	+
	110	+#### 5. 【SHOULD】漏洞监测：组织必须使用工具监测三方库漏洞,高危漏洞阻断构建，并建立SCA软件成分清单便于漏洞排查。
	111	+
	112	+* 详细描述：
	113	+ 组织必须部署软件成分分析（SCA）工具，对项目所有直接与传递依赖进行持续监测。在构建及依赖更新时自动触发扫描，识别到高危漏洞应阻断构建流程。同步建立并维护软件物料清单（SBOM），记录所有依赖的指纹、版本及层级关系，确保漏洞风险可追溯。
	114	+
	115	+* 原因：三方组件是供应链安全最脆弱的环节。自动化监测能防止已知漏洞随产物发布；SBOM清单则提供了清晰的资产地图，在爆发零日漏洞时能实现快速定位，显著缩短应急响应周期。
	116	+
	117	+### 4.4 测试验证阶段 \(Verification\)
	118	+
	119	+核心：深度验证与隔离审计。
	120	+
	121	+#### 1. 【SHOULD】人工逻辑渗透：重大版本的安全相关需求，建议针对鉴权、签名验证等最核心代码由Infra SIG组织进行一次**人工
	122	+**渗透。
	123	+
	124	+* 详细描述：重大版本发布或涉及鉴权、签名验证、数据加解密等核心功能的改动，应当组织以攻击者视角进行人工
	125	+ 渗透测试。重点针对自动化工具难以识别的业务逻辑缺陷、绕过风险及深层漏洞进行人工挖掘。
	126	+
	127	+* 原因：自动化安全工具在处理复杂的业务逻辑组合与设计层面的防御缺陷时存在局限性。引入专家级人工渗透测试，能有效查漏补缺，确保系统最核心的安全机制在真实攻击场景下依然稳固，是提升高等级资产防御深度的必要补充。
	128	+
	129	+#### 2. 【SHOULD】漏洞跟踪：组织应建立漏洞修复跟踪表,确保所有漏洞均完成修复。
	130	+
	131	+* 详细描述：应当通过统一的漏洞管理平台或跟踪表，对已识别的安全漏洞进行全过程管理。明确记录每个漏洞的状态（待修复、修复中、已验证）、修复责任人及截止时间，并定期复核挂账漏洞，确保所有风险项均得到闭环处理。
	132	+
	133	+* 原因：零散的漏洞信息极易导致修复工作的遗漏或无限期推迟。通过建立系统化的跟踪机制，可以为漏洞治理提供可追溯、可审计的完整证据链，确保已知安全隐患被切实消除，防止因管理疏漏导致漏洞被恶意利用。
	134	+
	135	+### 4.5 发布与部署阶段 \(Release & Deployment\)
	136	+
	137	+核心：可信部署与平滑变更。
	138	+
	139	+#### 1. 【MUST】自动化流水线：生产变更严禁手工操作，必须通过受控的持续交付（CD）流水线。
	140	+
	141	+* 详细描述：所有生产环境变更严禁通过非自动化方式手动执行。必须通过统一管控的持续交付（CD）流水线完成，流水线执行需基于最小权限原则分配触发权限，且所有操作须关联变更记录以支持全流程追溯。
	142	+
	143	+* 原因：手工操作存在高概率的人为失误风险，且难以保证环境一致性与操作可重复性。通过受控的CD流水线可实现变更过程的标准化与透明化，利用内置校验机制拦截非合规操作，并提供完整的审计轨迹能力，有效降低变更风险。
	144	+
	145	+#### 2. 【MUST】敏感配置分离注入：生产凭证在部署瞬时通过安全加密信道注入，严禁落盘或硬编码到部署脚本。
	146	+
	147	+* 详细描述：生产环境敏感配置需存储在专用密钥管理系统。部署时，通过加密通道在瞬时将配置注入目标服务内存，严禁将其硬编码至代码、脚本或配置文件中，且禁止以日志、缓存或临时文件等形式落盘存储。
	148	+
	149	+* 原因：敏感凭证硬编码或落盘是导致数据泄露与非法访问的高风险源。通过“全程不落地”的注入方式，可从源头切断泄露路径，结合权限管控与审计机制，确保配置访问受控且可追溯，保障关键资产安全。
	150	+
	151	+#### 3. 【MUST】发布审计日志完整性：验证发布过程中的所有关键动作是否已成功生成不可抵赖的记录。
	152	+
	153	+* 详细描述：发布过程中的关键操作（如代码部署、环境变更、门禁人工干预等）必须自动生成审计日志。记录需涵盖操作者、时间戳及具体动作，并存储于受控环境，确保日志一旦生成无法被篡改或删除。
	154	+
	155	+* 原因：完整的审计日志是事后追溯安全事件、定位问题根源和满足合规要求的核心依据。通过确保记录的不可抵赖性，可以有效防止操作责任的推诿，在发生安全事故时提供真实可靠的证据链，保障社区基础设施的透明度与可审计性。
	156	+
	157	+### 4.6 运维与监控阶段 \(Operations & Monitoring\)
	158	+
	159	+核心：持续观测与自动闭环。
	160	+
	161	+#### 1. 【MUST】应急响应链路：确立项目紧急联系方式并在社区官网隐私声明中明确。
	162	+
	163	+* 详细描述：隐私声明中需明确紧急联系方式，确保具备即时响应用户诉求的能力。
	164	+
	165	+* 原因：响应速度决定了事故的爆炸半径。预设链路确保在危机时刻能迅速集结专家，避免因联络受阻导致损失扩大。
	166	+
	167	+#### 2. 【MUST】 MFA 强控：社区基础设施云平台账号必须强制开启多因子认证。
	168	+
	169	+* 详细描述：涉及基础设施云平台账号，必须强制启用多因子认证（MFA）。认证因子应至少包含“知识因素（密码）”与“拥有因素（如手机APP
	170	+ 动态口令 TOTP、短信/邮件验证码、或移动端推送确认）”的组合。必须从系统层面配置强制策略，禁止任何未开启 MFA的账号具有超级管理员权限。
	171	+
	172	+* 原因：静态密码在当前的威胁环境下极易通过暴力破解、撞库、社会工程学或第三方服务泄露而被获取。实施 MFA
	173	+ 能够确保即使攻击者掌握了用户的首层凭证，也无法在没有第二因子的情况下接管账号。这是保护基础设施不受非授权变更、防范身份冒用导致的代码注入及资源破坏最核心的防御手段。
	174	+
	175	+#### 3. 【MUST】全链路监控告警：建立覆盖网络、OS、应用逻辑及业务指标的联动监控体系。
	176	+
	177	+* 详细描述：构建从底层基础设施到应用业务层的全栈监控，确保及时识别基础设施异常状态。
	178	+
	179	+* 原因：单点监控无法识别协同攻击。全链路联动能显著缩短平均检测时间（MTTD），通过多维度数据关联识别攻击路径，降低安全事故造成的损失。
	180	+
	181	+#### 4. 【MUST】态势感知对接：必须分析WAF、主机和服务审计等日志,建立异常行为模型。
	182	+
	183	+* 详细描述：汇总WAF、系统登录、SSH 操作及 API 调用日志至统一平台。通过行为分析识别暴力破解、异常时间登录及敏感文件篡改等威胁特征。
	184	+
	185	+* 原因：日志碎片化会掩盖隐蔽渗透。行为建模能从海量数据中捕捉潜伏迹象，将防御能力从被动拦截提升为主动威胁发现。
	186	+
	187	+#### 5. 【MUST】审计日志：日志必须实时同步至具备一次写入多次读取特性的存储，并满足审计存储时长要求。
	188	+
	189	+* 详细描述：日志必须同步至独立的、支持一次写入多次读取特性特性的存储，且日志留存时间满足至少7天。
	190	+
	191	+* 原因：入侵者通常会尝试抹除攻击痕迹。不可篡改的日志确保存储了完整的证据链，使安全团队能进行有效的威胁狩猎和事故溯源。
	192	+
	193	+#### 6. 【MUST】人员异动权限及时清理：维护者异动时及时撤销所有管理权限。
	194	+
	195	+* 详细描述：权限系统（IAM/Git）与基础设施SIG成员信息联动。当成员异动时，需在定期及时注销其账号及关联的所有特权。
	196	+
	197	+* 原因：权限回收滞后是内部失控的主要诱因。即时清理机制可消除“僵尸账户”风险，防止前成员或残留凭证被恶意利用。
	198	+
	199	+#### 7. 【SHOULD】常态化演练：定期进行安全应急模拟演练，确保应急预案有效。
	200	+
	201	+* 详细描述：周期性举行演练。模拟极端场景（数据删除、数据泄露）验证团队危机响应效率。
	202	+
	203	+* 原因：静态预案无法保证危机下的有效性。通过实战演练能发现配置盲区和流程断点，确保基础设施的业务连续性。
	204	+
	205	+#### 8. 【SHOULD】资产盘点：应对组织资产定期盘点，清理闲置的残留资源。
	206	+
	207	+* 详细描述：定期盘点域名、公网 IP、容器镜像及代码仓。清理长期闲置资源、过期测试环境的节点。
	208	+
	209	+* 原因：每一项被遗忘的资产都是潜在突破口。盘点能消除“影子资产”，确保所有暴露在网络中的资源均处于治理体系监控之下。
	210	+
	211	+## 5. 关键技术门禁 \(Security Gates\)
	212	+
	213	+\| 准出节点 \| 强制条件 \(Must\-Pass Items\) \|
	214	+\|----------\|---------------------------\|
	215	+\| 设计阶段 \| 所有 Critical 风险已制定缓解方案。 \|
	216	+\| 开发阶段 \| SAST、SCA 、密钥扫描通过。 \|
	217	+\| 测试阶段 \| 安全测试通过无高危漏洞遗留。 \|
	218	+\| 发布阶段 \| 产物签名验证通过，功能验证符合预期。 \|
	219	+
	220	+## 6. 异常豁免流程 \(Exemption Process\)
	221	+
	222	+若因业务极度紧急无法执行上述流程，必须：
	223	+
	224	+1. 书面申请：描述未达标项及风险影响，并通过邮件申请。
	225	+
	226	+2. 双重审批：需Inra SIG技术责任人和Infra SIG安全责任人审批通过。
	227	+
	228	+3. 限期整改：豁免期不超过 180 天，到期需重新评估。
	229	+
	230	+***
	231	+
	232	+## 7. 试运行计划 \(Trial Run Plan\)
	233	+
	234	+时间范围：26/04/01 - 26/12/31（共9个月）
	235	+
	236	+时间分配建议：
	237	+
	238	+\| 阶段 \| 时间段 \| 主要任务 \|
	239	+\|------\|--------\|----------\|
	240	+\| 准备期 \| 26/04/01 - 26/04/30 (1个月) \| 规范宣贯、工具链配置、团队培训 \|
	241	+\| 试行期 \| 26/05/01 - 26/08/31 (4个月) \| 按规范执行新流程，记录问题与反馈 \|
	242	+\| 优化期 \| 26/09/01 - 26/11/30 (3个月) \| 根据试行反馈调整规范细节 \|
	243	+\| 定稿期 \| 26/12/01 - 26/12/31 (1个月) \| 完成规范正式版本发布，全面转入常态化运行 \|