Sync: add container security notes

wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md

@@ -0,0 +1,54 @@
+---
+title: "CTP Topic 21 Supply Chain Security in Micro Focus"
+type: source
+tags:
+  - Security
+  - Supply-Chain
+  - CTP
+  - CI/CD
+  - DevSecOps
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-21-supply-chain-security-in-micro-focus]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 软件供应链安全的新方法与安全观念的根本转变
+- 问题域：软件供应链攻击防御、CI/CD 安全、SDL 第五支柱建设
+- 方法/机制：供应链安全纳入 SDL 五大支柱；保护 CI 过程（构建环境/自动化服务器）和 CD 过程（交付系统）完整性；防止黑客在构建环节篡改二进制文件
+- 结论/价值：从"99% 关注研发安全"转向全生命周期安全防护；强调 CI/CD 供应链完整性是云转型的基础保障
+
+## Key Claims（用中文描述）
+- Micro Focus 通过 Shlomi Ben-Hur 提出：软件供应链安全必须成为 SDL（安全开发生命周期）的第五大支柱
+- SolarWinds 事件证明：黑客通过渗透构建过程注入恶意代码，利用合法更新渠道感染下游客户
+- Micro Focus 内部存在极高的工具多样性（17 种不同 SCM 工具），为建立统一安全基准带来巨大挑战
+- 安全观念转变：从过去 99% 关注研发安全（如代码扫描、渗透测试）转向全生命周期安全防护
+
+## Key Quotes
+> "在当前的云转型背景下，软件供应链安全已成为企业安全战略的重中之重" — Shlomi Ben-Hur，Micro Focus 产品安全小组
+
+> "SolarWinds 攻击事件证明，黑客可以通过渗透构建过程注入恶意代码，利用合法更新渠道感染大量下游客户" — 视频核心案例
+
+## Key Concepts
+- [[Supply Chain Security（供应链安全）]]：指支持产品开发、构建及交付的所有组件和流程，包括开发环境、CI/CD 工具链及分发系统
+- [[SolarWinds Hack]]：一次著名的供应链攻击事件，黑客通过在软件构建阶段注入木马，利用合法更新渠道感染了大量下游客户
+- [[CI/CD Security]]：持续集成与持续交付的安全，旨在保护构建服务器、制品库和交付渠道不被未经授权的访问或篡改
+- [[SDL（Security Development Lifecycle）]]：软件安全开发生命周期，Micro Focus 将供应链安全纳入其 13 个安全轨道中的第 5 轨道
+- [[Executive Order on Cybersecurity]]：美国总统发布的关于加强国家网络安全的行政命令，直接推动了软件行业对供应链透明度和安全性的重视
+- [[Lateral Movement]]：横向移动，指黑客在进入受害者网络后，利用获取的权限在系统内部寻找更高价值目标的过程
+
+## Key Entities
+- [[Micro Focus]]：企业，正在大规模向 AWS 云端和 SaaS 模式迁移，产品安全小组主讲供应链安全
+- [[Shlomi Ben-Hur]]：Micro Focus 产品安全小组，主讲本次会议
+- [[SolarWinds]]：发生重大供应链安全事件的软件公司，攻击事件成为行业警示案例
+- [[GitHub Enterprise]]：Micro Focus 使用的 17 种 SCM 工具之一
+
+## Connections
+- [[CTP Topic 9 CI/CD with Gruntwork]] ← related_to ← [[CTP Topic 21 Supply Chain Security]]
+- [[Security Development Lifecycle (SDL) Deep Dive]] ← extends ← [[CTP Topic 21 Supply Chain Security]]
+- [[Cloud Transformation Programme Overview]] ← context ← [[CTP Topic 21 Supply Chain Security]]
+- [[DevOps Tooling Standardization]] ← related_to ← [[CTP Topic 21 Supply Chain Security]]
+
+## Contradictions
+- 暂无发现内容冲突。该来源主要介绍供应链安全理念，未与其他页面存在直接冲突。

wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md

@@ -0,0 +1,51 @@
+---
+title: "CTP Topic 24 Micro Focus Product Privacy Framework"
+type: source
+tags:
+  - Privacy
+  - Compliance
+  - Product-Privacy
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 产品隐私框架（Product Privacy Framework）在云转型计划中的应用
+- 问题域：法律合规要求（GDPR/CCPA）与技术实现之间的鸿沟
+- 方法/机制：通过 PSAC（产品安全顾问委员会）与法律顾问合作，将复杂法律条款翻译为约 110 项低级别技术要求；通过五类需求（架构类/文档类/法律类/实现类/SAS运营类）和成熟度模型（0-4级）评估产品隐私合规状态
+- 结论/价值：结构化解决产品团队合规压力，统一《产品隐私设置文档》确保客户获得一致的隐私信息参考
+
+## Key Claims（用中文描述）
+- PSAC 与法律顾问合作，将晦涩法律条文翻译为约 110 项具体技术要求
+- 该隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一
+- 框架将合规要求分为五种类型：架构类（侧重 PII 数据流分析）、文档类、法律类、实现类和 SAS 运营类
+- 通过成熟度模型（0-4 级）和"蜘蛛图"直观展示产品隐私指标（KPI）的合规现状与目标
+- 最终产出标准化《产品隐私设置文档》，确保客户消费不同产品时获得一致的隐私信息参考
+
+## Key Quotes
+> "随着 GDPR 和 CCPA 的生效，产品团队面临严峻的合规压力。然而，法律条文通常晦涩难懂，研发人员难以将其直接转化为技术需求。" — Shlomi Ben-Hur，Micro Focus PSAC
+
+## Key Concepts
+- [[STLC (Security Development Life Cycle)]]：安全开发生命周期，Micro Focus 产品开发的基础框架，包含 13 个安全和隐私轨道
+- [[PII (Personally Identifiable Information)]]：个人身份识别信息，隐私保护的核心对象
+- [[GDPR]]：欧盟《通用数据保护条例》，该隐私框架主要遵循的国际隐私监管标准
+- [[CCPA]]：《加州消费者隐私法案》，该隐私框架主要遵循的国际隐私监管标准
+- [[Data Controller vs. Data Processor]]：数据控制者与数据处理者，法律术语，明确 Micro Focus 与客户在数据处理中的各自责任
+- [[Anonymization & Pseudonymization]]：匿名化与去标识化，隐私框架中要求的技术手段
+- [[Product Privacy Settings Document]]：产品隐私设置文档，标准化模板用于向客户披露产品如何收集、存储和处理 PII
+- [[Maturity Model（成熟度模型）]]：0-4 级评估模型，用于衡量产品在不同隐私维度上的合规成熟度
+
+## Key Entities
+- [[Micro Focus]]：产品安全小组（PSAC）所在公司，主导该隐私框架的制定
+- [[Shlomi Ben-Hur]]：Micro Focus 产品安全小组（PSAC）成员，本次会议主讲人
+
+## Connections
+- [[Micro Focus Security Development Life Cycle (STLC) Overview]] ← extends ← [[ctp-topic-24-micro-focus-product-privacy-framework]]
+- [[ctp-topic-24-micro-focus-product-privacy-framework]] ← depends_on ← [[Cloud Transformation Programme Objectives]]
+- [[SaaS Operations and Compliance]] ← extends ← [[ctp-topic-24-micro-focus-product-privacy-framework]]
+
+## Contradictions
+- （暂无发现与现有 Wiki 内容的冲突）

wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 49 Container Lifecycle Hardening Standards"
+type: source
+tags: [Container, Security, Hardening, CTP, Kubernetes, Docker]
+sources: []
+last_updated: 2026-04-24
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 产品安全小组（Product Security Group）制定的容器镜像构建阶段（Building）安全加固标准，提供 11 条可操作的安全实践指南。
+- 问题域：容器镜像构建安全——如何避免引入已知漏洞、敏感信息和错误配置到容器化工作负载中。
+- 方法/机制：围绕 11 条安全标准逐条说明背景风险（Why）和缓解措施（How），辅以 Kubernetes YAML 配置示例演示。
+- 结论/价值：为容器镜像构建提供标准化安全基线，配合 Demo 直观展示配置效果，是 [[DevSecOps]] 实践在容器层面的具体落地。
+
+## Key Claims（用中文描述）
+- Micro Focus 基础镜像（Micro Focus Base Image）比开源默认镜像更安全——经过安全配置，内置非 root 和非特权（non-root and non-privileged）设置，避免开源默认镜像中的已知漏洞。
+- 引入 Init 系统（如 [[tini]] / [[tini Init System]]）可防止僵尸进程（Zombie Process）耗尽系统资源——Demo 展示了 [[tini]] 在 Kubernetes 环境中阻止僵尸进程的效果。
+- 将容器根文件系统设为只读（readOnlyRootFilesystem: true）可阻止攻击者篡改文件系统——Demo 展示了设置该标志后容器内无法创建未授权文件。
+- 使用 [[Kubernetes Secrets]] 替代将敏感信息硬编码在镜像中——敏感数据应在运行时从 Secret 管理机制获取，而非构建时嵌入镜像。
+- [[emptyDir Volume]] 用于临时文件系统比主机路径更安全——数据随 Pod 删除自动清理，防止敏感信息残留。
+- 每个容器仅运行单一应用——防止单个应用被攻陷后干扰同一容器中其他应用的进程。
+- 设置 automountServiceAccountToken: false 禁用 Kubernetes API 自动挂载——限制被攻陷容器对集群 API 的访问范围，降低权限提升风险。
+- 使用私有服务账号（Private Service Account）配合精确的 Namespace Role 和 Role Binding——替代默认服务账号，遵循最小权限原则。
+- 避免使用 hostNetwork 和 hostPort——防止端口冲突和维护网络隔离，减少容器逃逸攻击面。
+
+## Key Quotes
+> "If one application is compromised process in one application can interfere with the process of other application in the same container." — Ashish, Product Security Group, 说明为何容器应运行单一应用
+> "Use micro focus base image which are configured to be secure with non and trust weighted components." — Ashish, 说明 Micro Focus 基础镜像的安全配置特性
+> "teeny prevents zombie processes in Kubernetes." — Ashish, 演示 [[tini]] Init 系统在 Kubernetes 中的作用
+
+## Key Concepts
+- [[Container Lifecycle Hardening]]：容器全生命周期安全加固，涵盖构建（Build）、部署（Deploy）、运行（Run）三个阶段。本视频聚焦构建阶段。
+- [[tini Init System]]：轻量级 Init 系统，用于容器内正确处理信号和收割僵尸进程，与 [[tini]] 同义。
+- [[Kubernetes RBAC]]：基于角色的访问控制，通过 Role/RoleBinding/Namespace 机制实现最小权限服务账号管理。
+- [[Kubernetes Secrets]]：Kubernetes Secret 对象，用于在运行时向容器安全传递敏感信息（如密码、API 密钥），而非将其嵌入镜像。
+- [[Pod Security Context]]：Pod 安全上下文，定义 Pod 级别的安全设置（如 readOnlyRootFilesystem、automountServiceAccountToken）。
+- [[emptyDir Volume]]：Kubernetes emptyDir 卷类型，挂载临时文件系统，数据随 Pod 生命周期自动清理。
+- [[Container Image Scanning]]：镜像漏洞扫描，通过自动化工具识别镜像中的已知安全漏洞并提供修复建议。
+- [[Kubernetes RBAC]]：Role-Based Access Control，基于角色的访问控制，用于限制 Service Account 对 Kubernetes API 的访问权限。
+
+## Key Entities
+- [[Ashish]]：Micro Focus Product Security Group 成员，本视频主讲人，负责介绍容器生命周期安全加固标准。
+- [[Micro Focus]]：企业软件公司，拥有自己的容器基础镜像仓库和安全加固标准体系。
+- [[Product Security Group]]：Micro Focus 产品安全小组，制定容器安全标准和最佳实践。
+- [[Kubernetes]]：容器编排平台，是本视频所有安全配置的实施环境。
+- [[tini]]：容器 Init 系统开源项目，解决容器内僵尸进程和信号转发问题。
+
+## Connections
+- [[ctp-topic-21-supply-chain-security-in-micro-focus]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：供应链安全与容器镜像安全同属 [[DevSecOps]] 范畴，供应链安全关注 CI/CD 过程完整性，容器安全关注镜像内容安全。
+- [[DevSecOps]] ← extends ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：容器镜像加固是 DevSecOps 在容器领域的具体实践，DevSecOps 强调安全左移（Shift-Left）。
+- [[ctp-topic-70-eks-deployment-using-iac]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 部署的容器运行时安全配置与本视频的镜像构建标准互补，共同构成容器全生命周期安全。
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 可靠性最佳实践中的 Pod 安全配置与本视频标准一致。
+
+## Contradictions
+- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 hostNetwork 配置存在潜在冲突：
+  - 冲突点：Topic 39 中提到 Pod 规范设置 `hostNetwork: true` 以访问内部 Micro Focus 网络和外部资源。
+  - 当前观点（Topic 49）：应避免使用 hostNetwork 以维护网络隔离和防止端口冲突。
+  - 对方观点（Topic 39）：在受限 Lab Landing Zone 网络环境下，hostNetwork 是打通混合网络的必要手段。
+  - 说明：两者的差异源于场景不同——Topic 39 针对的是 IP 地址池不足的受限 Lab 环境，是特例；Topic 49 是通用安全最佳实践，适用于大多数生产场景。

wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md

@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)"
+type: source
+tags: [Security, CSPM, 3LoD, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management]]
+
+## Summary（用中文描述）
+- 核心主题：Three Lines of Defence（3LoD）安全治理框架在企业云安全中的落地，以及 Cloud Security Posture Management（CSPM）工具的选型与实践
+- 问题域：企业安全组织架构职责不清、多云账户安全配置碎片化、缺乏统一的云安全态势可视化和合规视图
+- 方法/机制：
+  - 3LoD 框架：明确业务单元（一线）→ 集团职能部门（二线）→ 审计（三线）的安全责任分层
+  - CSPM 集中化：将多账户、多云（AWS/Azure/GCP）的安全配置错误统一汇聚到单一平台
+  - Cloud Guard 选型：基于 POC 对比两家供应商后选定，核心功能包括态势管理、资产管理、网络配置可视化、事件管理和威胁情报
+  - 云架构设计原则：云无关（agnostic）、可复用、跨云适用
+- 结论/价值：3LoD 框架为安全组织提供了清晰的职责边界，CSPM 工具使安全团队能够主动发现和修复云配置偏差，从被动响应转向主动防御
+
+## Key Claims（用中文描述）
+- 3LoD 框架经 ELT 批准后成为组织统一的安全治理模型，解决了此前安全团队和政策碎片化的问题
+- 第一线（业务单元）负责在其业务范围内实施和管理安全控制
+- 第二线（集团职能部门）负责制定政策、事件响应和网络安全工具，作为第一线的顾问
+- 第三线（审计）确保第一线和第二线合规，向业务提供保障
+- CSPM 解决多云账户管理碎片化问题，提供统一的合规框架视图（ CIS、NIST、ISO）和自定义策略能力
+- Cloud Guard 在 POC 后被选中，核心功能包括态势管理、资产管理、网络配置可视化、事件管理和身份管理
+- 新账户在创建流程中即被纳入 Cloud Guard，确保全面覆盖和相关规则集的自动应用
+
+## Key Quotes
+> "The three lines of defense model was approved by ELT mid-year and serves as the organization's go-to model." — Coyote, Head of Enterprise Application Security
+
+> "The previous fragmented security models with multiple security teams and policies led to an audit that recommended a better framework for clear roles and responsibilities." — Coyote, Head of Enterprise Application Security
+
+> "Cloud security posture management addresses siloed management and the lack of a central view of public cloud security posture, which led to incidents and prolonged response times." — Coyote, Head of Enterprise Application Security
+
+## Key Concepts
+- [[Three Lines of Defence（3LoD）]]：企业安全治理框架，将安全职责分为三层——业务单元（一线）、集团职能部门（二线）、审计（三线），为组织提供清晰的安全责任边界
+- [[Cloud Security Posture Management（CSPM）]]：云安全态势管理工具，通过持续监控和评估云配置，发现偏差并提供修复建议，支持 CIS、NIST、ISO 等合规框架
+- [[Cloud Guard]]：该组织选定的 CSPM 工具，通过 POC 对比两家供应商后确定，核心功能涵盖态势管理、资产管理、网络配置可视化、事件管理和威胁情报
+- [[Security Governance（安全治理）]]：通过 3LoD 框架和 CSPM 工具相结合，实现从被动响应到主动防御的转变
+
+## Key Entities
+- [[Coyote]]：Enterprise Application Security 负责人（Head of），主讲本次 CTP Topic 52，推动 3LoD 框架落地和 CSPM 选型
+
+## Connections
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← depends_on ← [[3 Lines of Defence（3LoD）Framework CSPM]]
+  - 两者同属云安全领域，Topic 10 聚焦标签化安全控制，3LoD 聚焦安全组织架构和 CSPM 工具
+- [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015]] ← extends ← [[3 Lines of Defence（3LoD）Framework CSPM]]
+  - GIS Security Policies 提供企业级安全策略体系，3LoD 定义了安全治理的组织架构层，两者互补
+- [[ctp-topic-55-aws-firewall-manager]] ← extends ← [[Cloud Security Posture Management（CSPM）]]
+  - Firewall Manager 提供安全组策略集中化管理，CSPM（Cloud Guard）提供云配置合规评估，两者共同构成云安全防护体系
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/ctp-topic-55-aws-firewall-manager.md

@@ -0,0 +1,49 @@
+---
+title: "CTP Topic 55 AWS Firewall Manager"
+type: source
+tags: [AWS, Firewall-Manager, Security, CTP, Landing-Zones]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践
+- 问题域：跨多个 Landing Zone（RLABS、R&D、SAS、CAT）管理安全策略的复杂性，Checkpoint Firewall 无法覆盖的流量安全问题
+- 方法/机制：通过 Firewall Manager 账户创建安全组策略，使用 AWS Config + Lambda 触发事件自动修复，结合 RAM 共享前缀列表实现跨账户规则同步
+- 结论/价值：集中化管理、缩短安全策略部署时间、解决 QALIS 等共享服务扫描问题；支持 WAF 规则统一管理
+
+## Key Claims（用中文描述）
+- Firewall Manager 可跨多个 Landing Zone 统一部署基线安全组策略，解决多环境安全策略不一致问题
+- 三种安全策略类型：通用安全组（附加基线允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持自动修复）、清理未使用冗余安全组
+- Firewall Manager 账户独立于任何 Landing Zone，支持跨 Landing Zone 部署
+- RAM 前缀列表机制可跨账户轻松共享和更新安全组规则
+
+## Key Quotes
+> "We have gone through these policies and we come up with some baseline security groups." — 团队审查现有策略后制定基线安全组
+> "RAM is like it's a tool available within this AWS where you can specify or you can share your AWS resources to any other account that you wanted to specify." — RAM 用于跨账户资源共享
+> Demo 演示：在 Firewall Manager 账户创建通用安全组策略后，关联的 playground 账户中已存在的 EC2 实例和新启动的 EC2 实例均自动附加了安全组；删除策略后安全组自动从实例移除
+
+## Key Concepts
+- [[Security-Group]]：AWS 安全组，作为实例级别的有状态防火墙规则；Firewall Manager 三种策略均围绕安全组展开
+- [[Prefix-List]]：前缀列表，用于跨账户共享和更新安全组规则；通过 RAM 共享
+- [[Auto-Remediation]]：自动修复，Firewall Manager 策略可自动修复不合规的安全组规则
+- [[WAF-Rules-Management]]：Firewall Manager 还支持集中管理 WAF 规则，允许产品团队在基线规则上追加额外规则集
+
+## Key Entities
+- [[AWS-Firewall-Manager]]：AWS Firewall Manager 是集中配置防火墙规则和安全规则的管理服务，支持跨组织和账户的统一安全策略部署
+- [[Landing-Zones]]：AWS Landing Zones，Grand Torque 存在 RLABS、R&D、SAS、CAT 多个 Landing Zone，各有不同的安全要求
+- [[QALIS]]：产品账户实例扫描服务，通过 Firewall Manager 解决跨账户扫描的网络可达性问题
+- [[Checkpoint-Firewall]]：原有防火墙方案，存在安全组规则过于宽松的问题，无法完全覆盖通过公网子网的流量
+
+## Connections
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← relates_to ← [[ctp-topic-55-aws-firewall-manager]]
+- [[ctp-topic-37-secrets-certificates-management]] ← same_domain ← [[ctp-topic-55-aws-firewall-manager]]（均属于 07_Security 类别）
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_security ← [[ctp-topic-55-aws-firewall-manager]]
+
+## Contradictions
+- 与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint Firewall 方案关系：
+  - 冲突点：Checkpoint Firewall 原有安全组规则过于宽松，新方案引入 Firewall Manager 基线安全组
+  - 当前观点：Firewall Manager 补充 Checkpoint，提供更细粒度的安全组基线控制
+  - 对方观点：Checkpoint 作为网络边界防火墙，Firewall Manager 覆盖实例级别安全策略（互补而非冲突）