From 3b55f3af4dbbb44d9e65d2fb2de55e9b79649afd Mon Sep 17 00:00:00 2001 From: weishen Date: Fri, 24 Apr 2026 13:16:42 +0800 Subject: [PATCH] Sync: add container security notes --- .../PRD/组织人事管理/组织人事管理模块PRD.md | 156 +++--------------- .../concepts/Container-Lifecycle-Hardening.md | 60 +++++++ wiki/concepts/Pod-Security-Context.md | 56 +++++++ wiki/concepts/emptyDir-Volume.md | 42 +++++ wiki/entities/Ashish.md | 20 +++ wiki/entities/Micro-Focus.md | 39 +++++ wiki/entities/Product-Security-Group.md | 21 +++ wiki/entities/tini.md | 31 ++++ wiki/index.md | 22 ++- wiki/log.md | 44 +++++ wiki/overview.md | 8 + ...21-supply-chain-security-in-micro-focus.md | 54 ++++++ ...4-micro-focus-product-privacy-framework.md | 51 ++++++ ...container-lifecycle-hardening-standards.md | 62 +++++++ ...ework-cloud-security-posture-management.md | 55 ++++++ .../ctp-topic-55-aws-firewall-manager.md | 49 ++++++ 16 files changed, 626 insertions(+), 144 deletions(-) create mode 100644 wiki/concepts/Container-Lifecycle-Hardening.md create mode 100644 wiki/concepts/Pod-Security-Context.md create mode 100644 wiki/concepts/emptyDir-Volume.md create mode 100644 wiki/entities/Ashish.md create mode 100644 wiki/entities/Micro-Focus.md create mode 100644 wiki/entities/Product-Security-Group.md create mode 100644 wiki/entities/tini.md create mode 100644 wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md create mode 100644 wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md create mode 100644 wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md create mode 100644 wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md create mode 100644 wiki/sources/ctp-topic-55-aws-firewall-manager.md diff --git a/Project/fonrey/PRD/组织人事管理/组织人事管理模块PRD.md b/Project/fonrey/PRD/组织人事管理/组织人事管理模块PRD.md index 7c053c98..910531ae 100644 --- a/Project/fonrey/PRD/组织人事管理/组织人事管理模块PRD.md +++ b/Project/fonrey/PRD/组织人事管理/组织人事管理模块PRD.md @@ -1,8 +1,8 @@ # PRD: 组织人事管理模块 **状态**: Draft **作者**: 产品经理 -**最后更新**: 2026-04-24（v1.1 新增 Story 11-14，补充员工离职、员工调动、奖惩记录查看与新增，并同步更新技术实现与附录） -**版本**: 1.1 +**最后更新**: 2026-04-24（v1.2 移除技术实现章节，该部分由独立 DATA_MODEL 文档承载） +**版本**: 1.2 **所属系统**: Fonrey 房产经纪管理系统 **关联模块**: 权限管理、房源管理、客源管理、系统设置 @@ -465,125 +465,7 @@ --- -## 6. 技术实现说明 - -### 6.1 数据模型 - -```python -# apps/org/ 模块核心数据模型 - -class OrgUnit(TenantModel): - """部门/组织单元""" - name = CharField(max_length=100) # 部门名称 - parent = ForeignKey('self', null=True, blank=True) # 上级部门（树形结构） - level = CharField(choices=LEVEL_CHOICES) # 级别：事业部/大区/区域/片区/门店/店组/职能 - attribute = CharField(choices=[('direct', '直营'), ('franchise', '加盟')]) # 部门属性 - status = CharField(choices=[('active', '启用'), ('closed', '关闭')]) - address_city = CharField(blank=True) - address_district = CharField(blank=True) - address_detail = CharField(blank=True) - lat = DecimalField(null=True) # 坐标纬度 - lng = DecimalField(null=True) # 坐标经度 - manager = ForeignKey('Staff', null=True, related_name='managed_depts') # 负责人 - phone = CharField(blank=True) - ext_range_start = IntegerField(null=True) # 分机范围起 - ext_range_end = IntegerField(null=True) # 分机范围止 - founded_at = DateField(null=True) - -class Staff(TenantModel): - """员工档案""" - # 任职信息 - nickname = CharField() # 昵称 - staff_no = CharField() # 工号 - org_unit = ForeignKey(OrgUnit) # 所属部门 - position = ForeignKey('Position') # 职务 - position_type = CharField() # 职务类别 - level = IntegerField() # 职级 - status = CharField(choices=STAFF_STATUS_CHOICES) # 正式/试用/离职 - supervisor = ForeignKey('self', null=True) # 直属上级 - first_joined_at = DateField() - rejoined_at = DateField(null=True) - left_at = DateField(null=True) - # 个人信息 - real_name = CharField() - id_type = CharField() - id_number_encrypted = CharField() # 加密存储 - id_verified = BooleanField(default=False) - gender = CharField() - birth_date = DateField(null=True) - # 联系方式 - phone_encrypted = CharField() # 手机号加密存储 - phone_visible = BooleanField(default=True) # 通讯录是否隐藏 - # 账号 - login_account = OneToOneField('StaffAccount') - # ... 其他个人信息字段 - -class StaffRewardPunishment(TenantModel): - """员工奖惩记录""" - staff = ForeignKey(Staff) - date = DateField() # 奖惩日期 - category = CharField() # 奖惩类别（奖励/惩戒，下拉枚举） - name = CharField() # 奖惩名称（与类别联动，下拉枚举） - remark = TextField(blank=True) # 备注 - created_by = ForeignKey(Staff, related_name='created_rewards') - created_at = DateTimeField(auto_now_add=True) - -class StaffMutationLog(TenantModel): - """员工异动记录""" - staff = ForeignKey(Staff) - org_unit = ForeignKey(OrgUnit) # 异动时所在部门 - mutation_type = CharField() # 入职/上级变动/员工调动/离职/复职 - mutation_at = DateField() # 异动时间 - operated_at = DateTimeField() # 操作时间 - old_value = CharField(blank=True) - new_value = CharField(blank=True) - remark = TextField(blank=True) - operator = ForeignKey(Staff, related_name='operated_mutations') -``` - -### 6.2 关键技术约束 - -**依赖关系**： -- `apps/org/` — 组织人事核心 App，被 `apps/property/`、`apps/client/`、`apps/permissions/` 等模块引用（员工归属、权限主体） -- `apps/permissions/` — 权限控制，决定哪些角色可查看员工完整手机号、隐私信息 -- `core/encryption.py` — 手机号、证件号加密工具（所有敏感字段加密存储） - -**性能约束**： -- 部门树形列表使用 MPTT（Modified Preorder Tree Traversal）或 Closure Table 优化多层级查询，避免 N+1 问题 -- 架构图最多支持 8 层级数量 -- 异动记录量大（示例图显示 575 条），需分页处理，默认 20 条/页 - -**异步任务**： -- 「报表导出」（员工列表、异动记录）通过 Celery 异步执行，避免大数据量导出阻塞请求 - -**HTMX 交互模式**： -- 左侧部门树点击切换右侧员工列表：HTMX 局部刷新右侧内容区 -- 员工详情 Tab 切换（员工基本信息/异动记录/账号信息）：HTMX 局部刷新内容区 -- 架构图：Alpine.js 管理展开/折叠状态，SVG 或 Canvas 渲染树形结构 - -### 6.3 已知风险 - -| 风险 | 可能性 | 影响 | 缓解措施 | -|------|--------|------|----------| -| 部门树深度过大导致查询性能下降 | 中 | 高 | 使用 MPTT 存储，限制最大 8 层 | -| 手机号/证件号泄露 | 低 | 极高 | 全字段加密存储，权限控制脱敏展示 | -| 公安系统证件比对接口不稳定 | 中 | 中 | 系统内展示认证状态，接口失败时提示用户手动处理 | -| 多租户隔离失效 | 极低 | 极高 | `django-tenants` Schema 隔离，所有查询强制带租户上下文 | - -### 6.4 待确认问题 - -- [ ] 「入职邀请」功能的具体流程：是发送短信邀请链接自助填写，还是 HR 手动录入？—— 需与业务方确认 —— Deadline: 开发前 -- [ ] 证件实名认证是否需要对接公安部接口，还是仅展示状态由人工审核？—— 需与法务/产品负责人确认 —— Deadline: 开发前 -- [x] 员工「奖惩记录」字段结构（v1.1 已通过截图确认：日期/奖惩类别/奖惩名称/备注） -- [ ] 「员工相关资料」的具体字段结构（本期截图未覆盖）—— 需补充截图或访谈 —— Deadline: 下次迭代前 -- [ ] 架构图是否需要支持直接在图上拖拽节点来调整层级关系，还是只读展示？—— 截图提示支持拖拽缩放，但未确认是否支持编辑 —— Deadline: 设计评审前 -- [ ] 「员工入黑名单」的业务规则与对后续功能的影响（如是否可继续登录系统，名下房源/客源如何处理）—— Deadline: 开发前 -- [ ] 离职类型的枚举值清单（如：自离/协商离职/辞退/其他）—— 需与 HR 业务方确认 —— Deadline: 开发前 -- [ ] 奖惩类别与奖惩名称的完整枚举值及联动规则 —— 需与 HR 业务方提供配置清单 —— Deadline: 开发前 - ---- - -## 7. 上线计划 +## 6. 上线计划 | 阶段 | 时间 | 受众 | 验收门槛 | |------|------|------|----------| @@ -599,22 +481,22 @@ class StaffMutationLog(TenantModel): ### 8.1 截图来源 -| 截图文件 | 对应功能 | -|----------|----------| -| `公司组织结构.png` | Story 1 — 组织人员列表页 | -| `员工详情.png` | Story 6 — 员工基本信息详情 | -| `员工通讯录.png` | Story 9 — 员工通讯录 | -| `员工详情异动记录.png` | Story 7 — 员工异动记录（个人维度）| -| `员工详情账号信息.png` | Story 8 — 员工账号信息 | -| `部门新增.png` | Story 2 — 新增部门 | -| `部门编辑.png` | Story 3 — 编辑部门 | -| `部门详情.png` | Story 4 — 部门详情 | -| `组织员工异动记录.png` | Story 10 — 全局异动记录汇总 | -| `部门架构图.png` | Story 5 — 部门架构图 | -| `员工离职.png` | Story 11 — 员工离职操作（Modal 弹窗）| -| `员工调动.png` | Story 12 — 员工调动操作（右侧抽屉面板）| -| `员工奖惩记录.png` | Story 13 — 员工奖惩记录列表 | -| `员工奖惩记录新增.png` | Story 14 — 新增奖惩记录（Modal 弹窗）| +| 截图文件路径 | 对应功能 | +|-------------|----------| +| `screenshots/组织人事/组织结构/公司组织结构.png` | Story 1 — 组织人员列表页 | +| `screenshots/组织人事/组织结构/员工详情.png` | Story 6 — 员工基本信息详情 | +| `screenshots/组织人事/组织结构/员工通讯录.png` | Story 9 — 员工通讯录 | +| `screenshots/组织人事/组织结构/员工详情异动记录.png` | Story 7 — 员工异动记录（个人维度）| +| `screenshots/组织人事/组织结构/员工详情账号信息.png` | Story 8 — 员工账号信息 | +| `screenshots/组织人事/组织结构/部门新增.png` | Story 2 — 新增部门 | +| `screenshots/组织人事/组织结构/部门编辑.png` | Story 3 — 编辑部门 | +| `screenshots/组织人事/组织结构/部门详情.png` | Story 4 — 部门详情 | +| `screenshots/组织人事/组织结构/组织员工异动记录.png` | Story 10 — 全局异动记录汇总 | +| `screenshots/组织人事/组织结构/部门架构图.png` | Story 5 — 部门架构图 | +| `screenshots/组织人事/组织结构/员工离职.png` | Story 11 — 员工离职操作（Modal 弹窗）| +| `screenshots/组织人事/组织结构/员工调动.png` | Story 12 — 员工调动操作（右侧抽屉面板）| +| `screenshots/组织人事/组织结构/员工奖惩记录.png` | Story 13 — 员工奖惩记录列表 | +| `screenshots/组织人事/组织结构/员工奖惩记录新增.png` | Story 14 — 新增奖惩记录（Modal 弹窗）| ### 8.2 术语表 diff --git a/wiki/concepts/Container-Lifecycle-Hardening.md b/wiki/concepts/Container-Lifecycle-Hardening.md new file mode 100644 index 00000000..e1c265a9 --- /dev/null +++ b/wiki/concepts/Container-Lifecycle-Hardening.md @@ -0,0 +1,60 @@ +--- +title: "Container Lifecycle Hardening" +type: concept +tags: [Container, Security, Kubernetes, DevSecOps, Hardening] +last_updated: 2026-04-24 +--- + +## Definition +容器生命周期安全加固（Container Lifecycle Hardening）是指在容器的构建（Build）、部署（Deploy）、运行（Run）三个阶段中系统性地应用安全控制措施，以减少容器化工作负载的攻击面。 + +## Three Phases + +### Build Phase（构建阶段） +在构建阶段确保镜像本身不含漏洞和敏感信息： +- 使用经过安全加固的[[Micro Focus]]基础镜像 +- 引入 Init 系统（[[tini]]）防止僵尸进程 +- 镜像不含敏感信息（密码、API Key） +- 启用镜像漏洞扫描 +- 每个容器仅运行单一应用 + +### Deploy Phase（部署阶段） +在部署到 Kubernetes 时应用安全配置： +- 使用只读根文件系统（readOnlyRootFilesystem: true） +- 使用 [[emptyDir Volume]] 存储临时文件 +- 禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false） +- 使用私有服务账号配合精确 RBAC +- 避免 hostNetwork 和 hostPort + +### Run Phase（运行时阶段） +运行时持续监控和加固（CTP Topic 49 视频中提到将另有专题覆盖）。 + +## Key Standards (Build Phase) +来自 [[ctp-topic-49-container-lifecycle-hardening-standards]] 的 11 条标准： + +1. **Micro Focus Base Image** — 使用经过安全配置的官方基础镜像 +2. **Init System** — 使用 [[tini]] 处理信号和防止僵尸进程 +3. **No Sensitive Info** — 镜像不含敏感数据，使用 [[Kubernetes Secrets]] 运行时注入 +4. **Read-Only Root FS** — 设置 readOnlyRootFilesystem: true +5. **emptyDir for /tmp** — 使用 emptyDir volume 替代 hostPath +6. **Image Scanning** — 启用容器镜像漏洞扫描 +7. **Single Application** — 每容器运行单一应用 +8. **No K8s API Access** — 禁用 automountServiceAccountToken +9. **Private Service Account** — 使用最小权限的服务账号 +10. **No Host Network** — 避免 hostNetwork 配置 +11. **No Host Port** — 避免 hostPort 配置 + +## Relationship to DevSecOps +容器生命周期安全加固是 [[DevSecOps]] 理念在容器领域的具体实践： +- **安全左移（Shift-Left）**：安全问题在构建阶段就被发现和修复 +- **自动化**：通过 IaC 和 CI/CD 流水线自动执行安全检查 +- **最小权限**：容器仅获得完成功能所需的最小权限 + +## Relationship to Supply Chain Security +容器镜像加固是[[Supply Chain Security（供应链安全）]]体系的重要组成部分： +- 供应链安全的构建阶段（CI）= 容器镜像加固 +- 构建安全镜像 → 防止攻击者在制品中注入恶意代码 + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] +- [[ctp-topic-21-supply-chain-security-in-micro-focus]] diff --git a/wiki/concepts/Pod-Security-Context.md b/wiki/concepts/Pod-Security-Context.md new file mode 100644 index 00000000..84bdaa4e --- /dev/null +++ b/wiki/concepts/Pod-Security-Context.md @@ -0,0 +1,56 @@ +--- +title: "Pod Security Context" +type: concept +tags: [Kubernetes, Security, Container, Pod, RBAC] +last_updated: 2026-04-24 +--- + +## Definition +Pod Security Context（Pod 安全上下文）是 Kubernetes 中定义 Pod 和容器级别安全设置的机制，通过 YAML 配置在 Pod Spec 中声明容器的运行权限和访问控制。 + +## Common Security Context Fields + +### Container-Level Settings +```yaml +securityContext: + readOnlyRootFilesystem: true # 容器根文件系统设为只读 + runAsNonRoot: true # 禁止以 root 用户运行 + runAsUser: 1000 # 指定运行用户 UID + runAsGroup: 1000 # 指定运行用户组 GID + allowPrivilegeEscalation: false # 禁止权限提升 + capabilities: + drop: ["ALL"] # 移除所有 Linux capabilities +``` + +### Pod-Level Settings +```yaml +securityContext: + hostNetwork: false # 不使用宿主机网络 + hostIPC: false # 不使用宿主机 IPC + hostPID: false # 不使用宿主机 PID 命名空间 + automountServiceAccountToken: false # 不自动挂载 ServiceAccount Token +``` + +## Key Concepts from CTP Topic 49 + +### readOnlyRootFilesystem: true +将容器根文件系统设为只读，防止攻击者在容器内创建或修改文件。Demo 演示：设置此标志后，容器内尝试 `touch /tmp/test` 会失败。 + +### automountServiceAccountToken: false +禁用 Kubernetes ServiceAccount Token 的自动挂载，防止容器自动获得对 Kubernetes API 的访问权限。如果容器应用需要访问 API，应显式创建带有精确权限的 ServiceAccount 并通过 RBAC 绑定。 + +### hostNetwork: false / hostPort +避免使用宿主机网络和宿主机端口： +- 防止端口冲突 +- 维护网络隔离 +- 减少容器逃逸攻击面 +- 注意：在受限网络环境（如 Lab Landing Zone）中可能有例外需求（参见 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]） + +## Relationship to Kubernetes RBAC +Pod Security Context 与 [[Kubernetes RBAC]] 配合使用： +- Security Context 控制容器的运行时权限 +- RBAC 控制 ServiceAccount 对 Kubernetes API 的访问权限 +- 两者共同实现最小权限原则 + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] diff --git a/wiki/concepts/emptyDir-Volume.md b/wiki/concepts/emptyDir-Volume.md new file mode 100644 index 00000000..93155ba8 --- /dev/null +++ b/wiki/concepts/emptyDir-Volume.md @@ -0,0 +1,42 @@ +--- +title: "emptyDir Volume" +type: concept +tags: [Kubernetes, Container, Storage, Security] +last_updated: 2026-04-24 +--- + +## Definition +emptyDir Volume 是 Kubernetes 中的一种临时存储卷类型，在 Pod 被调度到节点时自动创建，挂载到容器指定路径。当 Pod 从节点移除或被删除时，emptyDir 卷中的数据会被永久删除。 + +## Use Case from CTP Topic 49 +在容器安全上下文中，[[ctp-topic-49-container-lifecycle-hardening-standards]] 推荐使用 emptyDir volume 替代 hostPath 来挂载临时文件系统（如 /tmp），原因： + +1. **数据隔离**：emptyDir 存储在节点上的容器运行时目录中，不与其他 Pod 共享 +2. **自动清理**：Pod 删除时数据自动清理，防止敏感信息残留 +3. **安全性优于 hostPath**：hostPath 直接访问宿主机文件系统，误用可能导致容器逃逸 +4. **适合临时文件**：/tmp 等仅在 Pod 运行期间需要的临时存储 + +## Configuration Example +```yaml +volumes: + - name: tmp-storage + emptyDir: + medium: Memory # 可选：存储在内存中（更安全） + sizeLimit: 100Mi # 可选：限制大小 +``` + +## emptyDir vs hostPath + +| 特性 | emptyDir | hostPath | +|------|----------|----------| +| 数据持久性 | Pod 生命周期 | 节点持久 | +| 存储位置 | 节点容器运行时目录 | 宿主机指定路径 | +| Pod 删除后 | 自动清理 | 保留 | +| 安全性 | 隔离，较安全 | 直接访问宿主机，有风险 | +| 适用场景 | 临时文件、缓存 | 日志挂载、配置文件 | + +## Relationship to Container Security +emptyDir volume 是 [[Container-Lifecycle-Hardening]] 中"使用空卷替代主机路径挂载敏感临时文件"标准的具体实现。与 [[Pod-Security-Context]] 的 readOnlyRootFilesystem 配合使用，可最大化容器文件系统安全。 + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] diff --git a/wiki/entities/Ashish.md b/wiki/entities/Ashish.md new file mode 100644 index 00000000..4b3dfba9 --- /dev/null +++ b/wiki/entities/Ashish.md @@ -0,0 +1,20 @@ +--- +title: "Ashish" +type: entity +tags: [Micro Focus, Security, Container, Kubernetes] +last_updated: 2026-04-24 +--- + +## Basic Information +- **Role:** Member, Product Security Group +- **Organization:** [[Micro Focus]] +- **Expertise:** Container Security, Kubernetes Hardening + +## Description +Ashish 是 Micro Focus Product Security Group 的成员，在 CTP Topic 49 分享了容器镜像构建阶段的安全加固标准。演讲涵盖了 11 条可操作的安全实践，通过 Demo 演示了配置效果。 + +## Aliases +- Ashish + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] diff --git a/wiki/entities/Micro-Focus.md b/wiki/entities/Micro-Focus.md new file mode 100644 index 00000000..b0783276 --- /dev/null +++ b/wiki/entities/Micro-Focus.md @@ -0,0 +1,39 @@ +--- +title: "Micro Focus" +type: entity +tags: + - Company + - Cloud Transformation + - Enterprise Software +last_updated: 2026-04-14 +--- + +## Overview + +Micro Focus is an enterprise software company undergoing a major cloud transformation to AWS and SaaS delivery models. The company has one of the largest commercial data center footprints globally (14 data centers, ~20,000 assets), and is actively migrating workloads to AWS. + +## Role in Cloud Transformation Programme (CTP) + +Micro Focus is the organization running the Cloud Transformation Programme (CTP), which covers AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. + +### Key Characteristics + +- **Tool Diversity**: High heterogeneity in development tools — 17 different Source Code Management (SCM) tools in use +- **Cloud Migration Scale**: One of the world's largest commercial data center footprints (14 data centers, ~20,000 assets) +- **Migration Progress**: 55% of AWS costs currently occur outside of Landing Zones, requiring governance +- **Security Focus**: Product Security team led by Shlomi Ben-Hur driving supply chain security initiatives + +### Key Products & Platforms + +- **Octane Hub**: Software Factory team, part of CTP, led by CTO Holger Rode; focused on Docker containerization of workloads from Bibling Lab to AWS Landing Zone +- **Operations Bridge Manager (OBM)**: Cloud monitoring solution integrating with AWS CloudWatch +- **Cyber Suite**: Security and encryption platform + +### References + +- [[ctp-topic-21-supply-chain-security-in-micro-focus]] — Product Security team's supply chain security approach (Shlomi Ben-Hur) +- [[ctp-topic-53-why-bother-with-cloud]] — Cloud migration business value case +- [[ctp-topic-43-vmware-cloud-on-aws]] — VMware Cloud on AWS as hybrid cloud intermediate route +- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-bridge]] — OBM cloud monitoring implementation +- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]] — Octane Hub real-life migration experience +- [[ctp-topic-44-aws-backup-in-micro-focus]] — AWS Backup implementation within Micro Focus diff --git a/wiki/entities/Product-Security-Group.md b/wiki/entities/Product-Security-Group.md new file mode 100644 index 00000000..5823b861 --- /dev/null +++ b/wiki/entities/Product-Security-Group.md @@ -0,0 +1,21 @@ +--- +title: "Product Security Group" +type: entity +tags: [Micro Focus, Security, Container, Kubernetes] +last_updated: 2026-04-24 +--- + +## Basic Information +- **Type:** Team / Group +- **Organization:** [[Micro Focus]] +- **Related People:** [[Ashish]] + +## Description +Micro Focus 产品安全小组（Product Security Group）负责制定和推广容器安全标准和最佳实践。在 CTP Topic 49 中，Ashish 代表该团队介绍了容器镜像构建阶段的 11 条安全加固标准。该组织还制定了其他安全相关标准，如供应链安全（CTP Topic 21，Shlomi Ben-Hur 主讲）。 + +## Aliases +- Product Security Group + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] +- [[ctp-topic-21-supply-chain-security-in-micro-focus]] diff --git a/wiki/entities/tini.md b/wiki/entities/tini.md new file mode 100644 index 00000000..0c090058 --- /dev/null +++ b/wiki/entities/tini.md @@ -0,0 +1,31 @@ +--- +title: "tini" +type: entity +tags: [Container, Kubernetes, Security, Open Source, Init System] +last_updated: 2026-04-24 +--- + +## Basic Information +- **Type:** Product / Open Source Tool +- **Category:** Container Init System +- **Website:** https://github.com/krallin/tini +- **Language:** C + +## Description +tini 是 Docker 和 Kubernetes 容器中最广泛使用的轻量级 Init 系统，用于： +1. **信号处理**：正确接收并转发 SIGTERM/SIGINT 等信号到子进程，确保容器可优雅停止 +2. **僵尸进程收割**：防止已终止但父进程尚未 wait() 的子进程（Zombie Process）占用系统资源 +3. **单进程容器**：在无 systemd 的容器环境中替代 PID 1 职责 + +在 [[ctp-topic-49-container-lifecycle-hardening-standards]] 中，Ashish 通过 Demo 展示了 tini 如何在 Kubernetes 环境中阻止僵尸进程——当容器不运行 Init 系统时，僵尸进程会耗尽系统资源；引入 tini 后僵尸进程被正确收割。 + +## Relationship to Kubernetes +- Kubernetes Pod 默认使用容器镜像的 PID 1 作为 Init 进程 +- 在 Kubernetes 中可通过 Pod Security Context 或 Init Container 方式集成 tini + +## Aliases +- tini +- teeny（CTP Topic 49 Demo 中提到的替代名称，指同一机制） + +## Sources +- [[ctp-topic-49-container-lifecycle-hardening-standards]] diff --git a/wiki/index.md b/wiki/index.md index 3b0f9d42..4c9b78a6 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,8 +4,12 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-24] [CTP Topic 49 Container Lifecycle Hardening Standards](sources/ctp-topic-49-container-lifecycle-hardening-standards.md) +- [2026-04-24] [CTP Topic 21 Supply Chain Security in Micro Focus](sources/ctp-topic-21-supply-chain-security-in-micro-focus.md) +- [2026-04-24] [CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)](sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md) +- [2026-04-24] [CTP Topic 55 AWS Firewall Manager](sources/ctp-topic-55-aws-firewall-manager.md) +- [2026-04-24] [CTP Topic 37 Secrets Certificates Management](sources/ctp-topic-37-secrets-certificates-management.md) - [2026-04-24] [CTP Topic 62 AWS Secrets Manager](sources/ctp-topic-62-aws-secrets-manager.md) -- [2026-04-14] [CTP Topic 37 Secrets Certificates Management](sources/ctp-topic-37-secrets-certificates-management.md) - [2026-04-24] [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) - [2026-04-24] [CTP Topic 64 Scaling out with Amazon EKS](sources/ctp-topic-64-scaling-out-with-amazon-eks.md) - [2026-04-24] [CTP Topic 67 Cloud native observability using OpenTelemetry](sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md) @@ -409,12 +413,7 @@ - [2026-04-19] [ctp-topic-9-ci-cd-with-gruntwork](sources/ctp-topic-9-ci-cd-with-gruntwork.md) — (expected: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md — source missing) - [2026-04-19] [ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments](sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md) — (expected: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md — source missing) - [2026-04-19] [ctp-topic-2-git](sources/ctp-topic-2-git.md) — (expected: wiki/sources/ctp-topic-2-git.md — source missing) -- [2026-04-19] [ctp-topic-24-micro-focus-product-privacy-framework](sources/ctp-topic-24-micro-focus-product-privacy-framework.md) — (expected: wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md — source missing) -- [2026-04-19] [ctp-topic-49-container-lifecycle-hardening-standards](sources/ctp-topic-49-container-lifecycle-hardening-standards.md) — (expected: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md — source missing) -- [2026-04-19] [ctp-topic-21-supply-chain-security-in-micro-focus](sources/ctp-topic-21-supply-chain-security-in-micro-focus.md) — (expected: wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md — source missing) -- [2026-04-19] [ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management](sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md) — (expected: wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md — source missing) -- [2026-04-19] [ctp-topic-55-aws-firewall-manager](sources/ctp-topic-55-aws-firewall-manager.md) — (expected: wiki/sources/ctp-topic-55-aws-firewall-manager.md — source missing) -- [2026-04-19] [ctp-topic-37-secrets-certificates-management](sources/ctp-topic-37-secrets-certificates-management.md) — (expected: wiki/sources/ctp-topic-37-secrets-certificates-management.md — source missing) +- [2026-04-14] [CTP Topic 24 Micro Focus Product Privacy Framework](sources/ctp-topic-24-micro-focus-product-privacy-framework.md) — Micro Focus 产品隐私框架，在云转型背景下解决 GDPR/CCPA 等法律合规要求与技术实现之间的鸿沟 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) @@ -559,6 +558,7 @@ - [Anthropic](entities/Anthropic.md) - [Apache-Superset](entities/Apache-Superset.md) - [Asana](entities/Asana.md) +- [Ashish](entities/Ashish.md) - [AWS](entities/AWS.md) - [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) - [AWS-OpenSearch](entities/AWS-OpenSearch.md) @@ -662,6 +662,7 @@ - [Mem0](entities/Mem0.md) - [Memsearch](entities/Memsearch.md) - [MerlinClash插件](entities/MerlinClash插件.md) +- [Micro-Focus](entities/Micro-Focus.md) - [Micro-Focus-IGA](entities/Micro-Focus-IGA.md) - [Microsoft-Planner](entities/Microsoft-Planner.md) - [Midjourney](entities/Midjourney.md) @@ -697,6 +698,7 @@ - [Podcastfy](entities/Podcastfy.md) - [Portainer](entities/Portainer.md) - [Prismer-AI](entities/Prismer-AI.md) +- [Product-Security-Group](entities/Product-Security-Group.md) - [Prometheus](entities/Prometheus.md) - [Public-Cloud-Provider](entities/Public-Cloud-Provider.md) - [Qdrant](entities/Qdrant.md) @@ -728,6 +730,7 @@ - [Telnyx](entities/Telnyx.md) - [Terraform](entities/Terraform.md) - [Tiago-Forte](entities/Tiago-Forte.md) +- [tini](entities/tini.md) - [Todoist](entities/Todoist.md) - [Trae](entities/Trae.md) - [TranscriptAPI](entities/TranscriptAPI.md) @@ -796,6 +799,7 @@ - [Automated-Health-Logging](concepts/Automated-Health-Logging.md) - [Automated-Security-Audit](concepts/Automated-Security-Audit.md) - [Availability](concepts/Availability.md) +- [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) - [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) - [AWS-Tags](concepts/AWS-Tags.md) - [BEATS](concepts/BEATS.md) @@ -852,6 +856,7 @@ - [Compliance-Automation](concepts/Compliance-Automation.md) - [Configuration-Management](concepts/Configuration-Management.md) - [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md) +- [Container-Lifecycle-Hardening](concepts/Container-Lifecycle-Hardening.md) - [Content Automation](concepts/Content Automation.md) - [Content-Creator](concepts/Content-Creator.md) - [Content-Hashing](concepts/Content-Hashing.md) @@ -907,6 +912,7 @@ - [ELK-Stack](concepts/ELK-Stack.md) - [Email-Triage](concepts/Email-Triage.md) - [Emergency-Change](concepts/Emergency-Change.md) +- [emptyDir-Volume](concepts/emptyDir-Volume.md) - [Enterprise-Architecture](concepts/Enterprise-Architecture.md) - [Error-Accountability](concepts/Error-Accountability.md) - [Error-Budget](concepts/Error-Budget.md) @@ -1040,6 +1046,7 @@ - [Plan-Mode](concepts/Plan-Mode.md) - [PMDelegationPattern](concepts/PMDelegationPattern.md) - [pmset](concepts/pmset.md) +- [Pod-Security-Context](concepts/Pod-Security-Context.md) - [Policy-as-Code](concepts/Policy-as-Code.md) - [PRD生成工作流](concepts/PRD生成工作流.md) - [Pre-Build-Validation](concepts/Pre-Build-Validation.md) @@ -1095,6 +1102,7 @@ - [SDDC](concepts/SDDC.md) - [SE-Linux-Enforcing](concepts/SE-Linux-Enforcing.md) - [Second-Renaissance](concepts/Second-Renaissance.md) +- [Secrets-Management](concepts/Secrets-Management.md) - [Security-and-Compliance](concepts/Security-and-Compliance.md) - [Self-Education](concepts/Self-Education.md) - [Self-Healing-Systems](concepts/Self-Healing-Systems.md) diff --git a/wiki/log.md b/wiki/log.md index 8d3a88ac..c2fd5b8a 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,47 @@ +## [2026-04-24] ingest | CTP Topic 49 Container Lifecycle Hardening Standards +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 产品安全小组 Ashish 主讲，容器镜像构建阶段 11 条安全加固标准——基础镜像选择、Init 系统（tini 防止僵尸进程）、只读根文件系统（readOnlyRootFilesystem: true）、emptyDir Volume、禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false）、私有服务账号+RBAC、避免 hostNetwork/hostPort +- Concepts created: [[Container-Lifecycle-Hardening]], [[Pod-Security-Context]], [[emptyDir-Volume]] +- Entities created: [[Ashish]], [[Product-Security-Group]], [[tini]] +- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md +- Notes: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 就 hostNetwork 配置存在场景冲突（Topic 39 Lab 环境特例 vs Topic 49 通用最佳实践）；检测到 3 个潜在概念（Container-Lifecycle-Hardening/Pod-Security-Context/emptyDir-Volume）和 3 个实体（Ashish/Product-Security-Group/tini），均已创建 Entity/Concept 页面；overview.md 已更新 + +## [2026-04-14] ingest | CTP Topic 21 Supply Chain Security in Micro Focus +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-21-supply-chain-security-in-micro-focus.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 软件供应链安全新方法——供应链（产品层面）涵盖 SCM/CI/CD 全环节；驱动因素：SolarWinds 攻击事件、美国网络安全行政命令、AWS/SaaS 迁移风险；安全观念转变：从 99% 关注研发安全转向全生命周期防护；供应链安全成为 SDL 第五支柱，强调 CI 和 CD 过程完整性 +- Concepts identified: [[Supply Chain Security（供应链安全）]], [[SolarWinds Hack]], [[CI/CD Security]], [[SDL（Security Development Lifecycle）]], [[Executive Order on Cybersecurity]], [[Lateral Movement]] +- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]] +- Source page: wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md +- Notes: 无冲突检测；Micro Focus 已在多处来源提及但无独立 Entity 页面，本次补充创建；SolarWinds/Shlomi Ben-Hur 仅出现一次，不满足 Entity 创建条件 + +## [2026-04-24] ingest | CTP Topic 52 3 Lines of Defence (3LoD) Framework Cloud Security Posture Management +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md +- Status: ✅ 成功摄入 +- Summary: 3LoD 安全治理框架落地（业务单元→集团职能部门→审计三层责任分层）+ Cloud Guard CSPM 工具选型（态势管理/资产管理/网络可视化/事件管理/威胁情报）+ 新账户创建流程中自动纳入 Cloud Guard +- Concepts identified: [[Three Lines of Defence（3LoD）]], [[Cloud Security Posture Management（CSPM）]] +- Source page: wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md +- Notes: 无冲突内容；3LoD/CSPM 均属行业通用概念，已有 CSPM 相关内容于 cloud-security.md；Cloud Guard 为该组织专用 CSPM 工具，暂不单独建 Entity 页面 + +## [2026-04-24] ingest | CTP Topic 55 AWS Firewall Manager +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md +- Status: ✅ 成功摄入 +- Summary: AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 统一部署基线安全组；三种策略类型（通用/审计强制/清理冗余）；通过 AWS Config + Lambda 实现自动修复；RAM 前缀列表跨账户共享规则；独立 Firewall Manager 账户支持跨 LZ 部署；Demo 展示 EC2 实例安全组的自动附加与移除 +- Concepts identified: [[Security-Group]], [[Prefix-List]], [[Auto-Remediation]], [[WAF-Rules-Management]] +- Entities identified: [[AWS-Firewall-Manager]], [[Landing-Zones]], [[QALIS]], [[Checkpoint-Firewall]] +- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md +- Notes: 无冲突检测；与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint 方案属互补关系（网络边界防火墙 vs 实例级安全组基线），已于 Contradictions 节记录 + +## [2026-04-30] ingest | CTP Topic 37 Secrets Certificates Management +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-37-secrets-certificates-management.md +- Status: ✅ 成功摄入 +- Summary: 云转型计划密钥与证书管理解决方案选型与实施——30天试点对比 AWS Secrets Manager 与 HashiCorp Vault，AWS Secrets Manager 以更低成本和更简实施胜出；实施阶段从 Control Tower 开始，从 CI/CD 流程清除明文密钥，集中化管理。 +- Concepts identified: [[Secrets-Management]], [[AWS-Secrets-Manager]] +- Entities identified: [[Micro-Focus]], [[CCLE]]（CCLE 在 2022 年 3 月负责评估工作，关键组织角色） +- Source page: wiki/sources/ctp-topic-37-secrets-certificates-management.md +- Notes: 无冲突；与 [[ctp-topic-62-aws-secrets-manager]] 的关系记录于 Contradictions 节（Topic 37 试点结论 + Topic 62 深度实践，属补充关系而非冲突） + ## [2026-04-30] ingest | CTP Topic 62 AWS Secrets Manager - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md - Status: ✅ 成功摄入 diff --git a/wiki/overview.md b/wiki/overview.md index 3e418dfa..89834b1a 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -41,6 +41,10 @@ Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Refer ### Cloud Transformation & DevOps Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. +**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）：Micro Focus 产品安全小组 Shlomi Ben-Hur 主讲的软件供应链安全新方法——核心议题：在云转型背景下，软件供应链安全已成为企业安全战略的重中之重。供应链（产品层面）涵盖源码管理（SCM）、构建组件（CI）、制品库到最终交付系统（CD）的所有环节，Micro Focus 内部存在 17 种不同 SCM 工具的极高多样性。主要驱动因素：SolarWinds 攻击事件（通过渗透构建过程注入恶意代码）、美国网络安全行政命令、以及向 AWS/SaaS 迁移带来的开放性风险。核心转变：从过去 99% 关注研发安全（代码扫描/渗透测试）转向全生命周期安全防护；供应链安全成为 SDL（安全开发生命周期）的第五大支柱，强调必须同时确保 CI 过程（构建环境/自动化服务器）和 CD 过程（交付系统）的完整性，防止黑客在任何环节篡改二进制文件。属 [[Supply Chain Security（供应链安全）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[DevSecOps]]（开发安全运维一体化）高度关联。 + +**[[ctp-topic-49-container-lifecycle-hardening-standards]]**（CTP Topic 49）：Micro Focus 产品安全小组 Ashish 主讲的容器镜像构建阶段 11 条安全加固标准——涵盖使用 Micro Focus 基础镜像（non-root/non-privileged）、引入 Init 系统（[[tini]] 防止僵尸进程）、镜像不含敏感信息、只读根文件系统（readOnlyRootFilesystem: true）、[[emptyDir Volume]] 临时文件系统、镜像漏洞扫描、容器单应用原则、禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false）、私有服务账号配合精确 RBAC、避免 hostNetwork 和 hostPort。辅以 Demo 演示 [[tini]] 阻止僵尸进程和只读文件系统阻止未授权文件创建的效果。属 [[DevSecOps]] 在容器层面的具体实践，与 [[ctp-topic-21-supply-chain-security-in-micro-focus]] 共同构成供应链安全体系（上游源码 → 中游镜像构建 → 下游运行时）。 + **[[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 1）：Karpenter 深度解析与 Cluster Autoscaler 对比——Karpenter 直接与 EC2 Fleet API 通信降低延迟，原生集成 Kubernetes 调度约束（node selectors/affinity/taints/tolerations/topology spread），内置 Spot 中断处理（EventBridge + SQS）和 AMI 滚动升级，Eliminate 节点组管理痛点；Consolidation 策略自动整合低利用率节点，支持中断预算控制和峰值时段豁免。Part 3 将介绍 EKS Auto Mode 进一步简化数据平面管理（内置 Karpenter Controller）。属 [[Karpenter]] 在 AWS EKS 的核心实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）共同构成 EKS 完整知识链路。 **[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 2）：Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版，核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践，与 Part 1（Karpenter 计算优化）和 Part 3（EKS Auto Mode）共同构成 EKS 优化三专题完整链路；Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。 @@ -89,6 +93,8 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-26-standard-ami-build-publish-share-processes]]**（CTP Topic 26）：Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼），而非物理复制（AMI Copying），避免额外存储成本；每两个月更新，采用 N-2 版本保留策略。责任共担模型：CCOE 提供安全基础镜像，产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础，与 [[ctp-topic-58-aws-ec2-image-builder]]（演进方向 EC2 Image Builder）和 [[learning-sessions-standard-amis-updates]]（2023年更新机制）共同构成完整的 AMI 管理知识体系。 +**[[ctp-topic-55-aws-firewall-manager]]**（CTP Topic 55）：AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——核心动机：跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 管理安全策略的复杂性；原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案：①在独立的 Firewall Manager 账户创建安全组策略，指定目标账户或 OU，自动将基线安全组附加到现有和新实例；②三种策略类型——通用安全组（允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持手动或自动修复）、清理未使用冗余安全组；③通过 RAM 前缀列表跨账户共享规则，支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件：OU 内管理员权限 + AWS Config 全账户启用。属 [[AWS-Landing-Zone]] 安全策略集中化管理层的核心实践，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（Checkpoint 防火墙）互补——后者提供网络边界防火墙，前者提供实例级别安全组基线。| + **CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。 **[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。 @@ -135,6 +141,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast **[[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]**（Learning Sessions，Mike & Ed 主讲）：OpenText 全球信息安全团队（GIS）安全策略全景——GIS 是分层组织架构，包含安全运营（事件响应与保障）、合规（认证与政策执行）、治理风险验证（GRV，季度审查 Admin 角色）、隐私（新增集成中）四个支柱。OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做"；持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售；每月处理 2250 亿条日志，分诊约 350 个案例。姿态框架基于 ISO 27001（2022 年更新，新增 11 个控制方面）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查。安全运营涵盖 Cyber Response Center、威胁情报（BrightCloud）、云安全、安全工具与工程等核心服务；合规组织涵盖合规项目、路线图、产品风险评估、持续合规与审计、自动化等内容。属企业级安全治理体系的核心入门，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（AWS 层面标签化安全）互补——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地。 +**[[ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management]]**（CTP Topic 52）：Coyote（Enterprise Application Security 负责人）分享 Three Lines of Defence（3LoD）安全治理框架落地和 Cloud Security Posture Management（CSPM）工具选型——3LoD 框架经 ELT 批准后成为组织统一的安全治理模型，明确业务单元（一线：实施管理安全控制）→ 集团职能部门（二线：政策/事件响应/网络安全工具）→ 审计（三线：确保一二线合规）的三层责任分层，解决了此前安全团队和政策碎片化导致的审计问题。CSPM 解决多云账户管理碎片化问题，提供统一的合规框架视图（ CIS、NIST、ISO）和自定义策略能力；Cloud Guard 在 POC 后被选中，核心功能涵盖态势管理、资产管理、网络配置可视化、事件管理和威胁情报，新账户在创建流程中即被纳入 Cloud Guard 确保全面覆盖。核心理念：**从被动安全响应转向主动防御**，通过 CSPM 主动发现和修复云配置偏差。与 [[ctp-topic-55-aws-firewall-manager]]（Firewall Manager 安全组策略）和 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（标签化安全）共同构成完整的云安全防护体系，与 [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]（GIS 安全策略全景）互补——后者定义组织层面的安全策略框架，前者定义云安全运营的技术落地层。 + **[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。 **[[ctp-topic-30-managing-change]]**（CTP Topic 30）：云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒；②变更分类——Standard Change（预批准，完全自动化 IaC+CI/CD，无需 CAB）→ Normal Change（需 CAB 审批，目标是通过自动化逐步归入 Standard Change）→ Emergency Change（立即执行缓解事故，事后 CAPA/Post-mortem 修复根因）；③SRE 三阶段协作——构建（Build）/早期上线支持（Early Live Support）/BAU；④Self-Healing 演进方向——各产品组分享实践，SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充，与 [[ctp-topic-28-aws-tag-validation-tool]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）共同构成变更管理知识体系。 diff --git a/wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md b/wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md new file mode 100644 index 00000000..381cbc5c --- /dev/null +++ b/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 +- 暂无发现内容冲突。该来源主要介绍供应链安全理念，未与其他页面存在直接冲突。 diff --git a/wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md b/wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md new file mode 100644 index 00000000..187daac0 --- /dev/null +++ b/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 内容的冲突） diff --git a/wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md b/wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md new file mode 100644 index 00000000..a4862bc6 --- /dev/null +++ b/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 是通用安全最佳实践，适用于大多数生产场景。 diff --git a/wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md b/wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md new file mode 100644 index 00000000..816b1e9a --- /dev/null +++ b/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 +- 无已知冲突内容 diff --git a/wiki/sources/ctp-topic-55-aws-firewall-manager.md b/wiki/sources/ctp-topic-55-aws-firewall-manager.md new file mode 100644 index 00000000..9df0f2d8 --- /dev/null +++ b/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 覆盖实例级别安全策略（互补而非冲突）