Sync: add container security notes
This commit is contained in:
@@ -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 术语表
|
||||
|
||||
|
||||
60
wiki/concepts/Container-Lifecycle-Hardening.md
Normal file
60
wiki/concepts/Container-Lifecycle-Hardening.md
Normal file
@@ -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]]
|
||||
56
wiki/concepts/Pod-Security-Context.md
Normal file
56
wiki/concepts/Pod-Security-Context.md
Normal file
@@ -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]]
|
||||
42
wiki/concepts/emptyDir-Volume.md
Normal file
42
wiki/concepts/emptyDir-Volume.md
Normal file
@@ -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]]
|
||||
20
wiki/entities/Ashish.md
Normal file
20
wiki/entities/Ashish.md
Normal file
@@ -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]]
|
||||
39
wiki/entities/Micro-Focus.md
Normal file
39
wiki/entities/Micro-Focus.md
Normal file
@@ -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
|
||||
21
wiki/entities/Product-Security-Group.md
Normal file
21
wiki/entities/Product-Security-Group.md
Normal file
@@ -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]]
|
||||
31
wiki/entities/tini.md
Normal file
31
wiki/entities/tini.md
Normal file
@@ -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]]
|
||||
@@ -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)
|
||||
|
||||
44
wiki/log.md
44
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: ✅ 成功摄入
|
||||
|
||||
@@ -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 范畴）共同构成变更管理知识体系。
|
||||
|
||||
@@ -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
|
||||
- 暂无发现内容冲突。该来源主要介绍供应链安全理念，未与其他页面存在直接冲突。
|
||||
@@ -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 内容的冲突）
|
||||
@@ -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 是通用安全最佳实践，适用于大多数生产场景。
|
||||
@@ -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
|
||||
- 无已知冲突内容
|
||||
49
wiki/sources/ctp-topic-55-aws-firewall-manager.md
Normal file
49
wiki/sources/ctp-topic-55-aws-firewall-manager.md
Normal file
@@ -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 覆盖实例级别安全策略（互补而非冲突）
|
||||
Reference in New Issue
Block a user