Auto-sync: 2026-04-19 16:02
This commit is contained in:
49
wiki/concepts/Cloud-Security-Posture-Management.md
Normal file
49
wiki/concepts/Cloud-Security-Posture-Management.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Cloud Security Posture Management"
|
||||
type: concept
|
||||
tags: [Security, Cloud, CSPM, Compliance, Monitoring]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
云安全态势管理(Cloud Security Posture Management,CSPM)是一种持续监控云资源配置合规性的解决方案,解决多云环境安全割裂和缺乏统一视图的问题。
|
||||
|
||||
## Core Problems Solved
|
||||
- 多云账户安全管理割裂
|
||||
- 缺乏公共云安全态势的集中视图
|
||||
- 事件响应时间长
|
||||
- 合规性评估困难
|
||||
|
||||
## Core Features
|
||||
1. **发现(Discovery)**:自动发现云环境中的所有资产
|
||||
2. **监控(Monitoring)**:持续监控安全配置
|
||||
3. **评估(Assessment)**:基于合规框架(CIS、NIST、ISO)进行评估
|
||||
4. **保护(Protection)**:提供修复建议和自动修复能力
|
||||
|
||||
## Key Requirements
|
||||
- 整合多个云账户的错误配置到单一平台
|
||||
- 提供合规框架视图(CIS、NIST、ISO)
|
||||
- 支持自定义策略
|
||||
|
||||
## Selected Solution: Cloud Guard
|
||||
经过 POC 测试后选中,核心功能包括:
|
||||
- 态势管理(Posture Management)
|
||||
- 资产管理(Asset Management)
|
||||
- 网络配置探索(Network Configuration Exploration)
|
||||
- 事件管理(Event Management)
|
||||
- 身份管理(Identity Management)
|
||||
- 威胁情报(Intelligence)
|
||||
|
||||
## Onboarding Process
|
||||
新账户在创建过程中自动接入 Cloud Guard,确保全面覆盖和相关规则集的应用。
|
||||
|
||||
## Related Entities
|
||||
- [[Coyote]] — Head of Enterprise Application Security
|
||||
|
||||
## Related Concepts
|
||||
- [[Three-Lines-of-Defense]]
|
||||
- [[Multi-Cloud]]
|
||||
- [[Compliance-Enforcement]]
|
||||
|
||||
## Related Sources
|
||||
- [[CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)]]
|
||||
26
wiki/concepts/Container-Image-Scanning.md
Normal file
26
wiki/concepts/Container-Image-Scanning.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Container Image Scanning"
|
||||
type: concept
|
||||
tags: [Container, Security, Vulnerability]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
容器镜像扫描是在构建和部署阶段自动检测容器镜像中已知安全漏洞的过程。通过扫描工具识别镜像中的组件漏洞、配置问题和安全风险。
|
||||
|
||||
## 扫描内容
|
||||
- 操作系统软件包漏洞
|
||||
- 应用依赖库漏洞
|
||||
- 配置文件安全风险
|
||||
- 敏感信息泄露检测
|
||||
- 合规性检查
|
||||
|
||||
## 工具示例
|
||||
- Snyk
|
||||
- Trivy
|
||||
- Clair
|
||||
- Anchore
|
||||
|
||||
## 相关资源
|
||||
- 来源:[[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- 相关概念:[[Container-Lifecycle-Hardening]]
|
||||
34
wiki/concepts/Container-Lifecycle-Hardening.md
Normal file
34
wiki/concepts/Container-Lifecycle-Hardening.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Container Lifecycle Hardening"
|
||||
type: concept
|
||||
tags: [Container, Security, Hardening, Kubernetes]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
容器生命周期加固是指在容器构建、部署和运行各个阶段实施安全最佳实践的系统化方法。Micro Focus 产品安全组制定的容器生命周期加固标准聚焦于构建阶段的安全实践。
|
||||
|
||||
## 核心组件
|
||||
|
||||
### 1. 构建阶段标准(11 项)
|
||||
- 使用 Micro Focus 基础镜像
|
||||
- 采用 init 系统(如 teeny)
|
||||
- 确保镜像不含敏感信息
|
||||
- 使用只读文件系统
|
||||
- 使用 emptyDir 卷处理临时文件
|
||||
- 镜像扫描检测漏洞
|
||||
- 单容器单应用
|
||||
- 禁用 Kubernetes API 访问
|
||||
- 使用私有服务账户
|
||||
- 避免主机网络模式
|
||||
- 避免主机端口
|
||||
|
||||
### 2. 关键概念
|
||||
- [[Read-Only-Root-Filesystem]]:只读根文件系统配置
|
||||
- [[Container-Image-Scanning]]:镜像漏洞扫描
|
||||
- [[Init-System]]:容器初始化进程
|
||||
- [[Kubernetes-Service-Account]]:K8s 服务账户
|
||||
|
||||
## 相关资源
|
||||
- 来源:[[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- 相关:[[CTP Topic 21 Supply Chain Security in Micro Focus]]
|
||||
25
wiki/concepts/Init-System.md
Normal file
25
wiki/concepts/Init-System.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Init System"
|
||||
type: concept
|
||||
tags: [Container, Security, Process]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
Init 系统是容器内的初始化进程,用于处理系统信号和回收僵尸进程。常见实现包括 teeny、tini 等。
|
||||
|
||||
## 为什么需要 Init 系统
|
||||
容器默认只运行一个进程(PID 1),当该进程退出时容器终止。但以下情况需要 init 系统:
|
||||
- 处理孤儿僵尸进程
|
||||
- 正确传播 SIGTERM 信号
|
||||
- 清理退出的子进程
|
||||
- 避免资源耗尽
|
||||
|
||||
## 工具示例
|
||||
- teeny:轻量级 init 系统
|
||||
- tini:Docker 官方推荐
|
||||
- dumb-init:简单易用
|
||||
|
||||
## 相关资源
|
||||
- 来源:[[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- 相关概念:[[Container-Lifecycle-Hardening]]
|
||||
23
wiki/concepts/Kubernetes-Service-Account.md
Normal file
23
wiki/concepts/Kubernetes-Service-Account.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Kubernetes Service Account"
|
||||
type: concept
|
||||
tags: [Kubernetes, Security, Authentication]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
Kubernetes Service Account(服务账户)是 Pod 用于身份验证到 Kubernetes API Server 的机制。每个 Pod 关联一个服务账户,默认使用 default 服务账户。
|
||||
|
||||
## 安全最佳实践
|
||||
- 禁用自动挂载(`automountServiceAccountToken: false`)
|
||||
- 使用私有服务账户而非默认账户
|
||||
- 通过 Role/RoleBinding 最小化权限
|
||||
- 定期轮换服务账户凭据
|
||||
|
||||
## 关联安全配置
|
||||
- `automountServiceAccountToken`:控制是否自动挂载服务账户令牌
|
||||
- `imagePullSecrets`:用于私有镜像仓库认证
|
||||
|
||||
## 相关资源
|
||||
- 来源:[[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- 相关概念:[[Container-Lifecycle-Hardening]]
|
||||
22
wiki/concepts/Read-Only-Root-Filesystem.md
Normal file
22
wiki/concepts/Read-Only-Root-Filesystem.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Read Only Root Filesystem"
|
||||
type: concept
|
||||
tags: [Container, Security, Kubernetes]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
只读根文件系统(Read-Only Root Filesystem)是一种容器安全配置,将容器的根文件系统设置为只读状态,防止未授权的文件创建和修改。
|
||||
|
||||
## 实现方式
|
||||
在 Kubernetes 中通过设置 `readOnlyRootFilesystem: true` 实现。
|
||||
|
||||
## 安全价值
|
||||
- 防止恶意攻击者写入恶意文件
|
||||
- 保护系统目录不被篡改
|
||||
- 限制容器内恶意软件的活动范围
|
||||
- 符合不可变基础设施最佳实践
|
||||
|
||||
## 相关资源
|
||||
- 来源:[[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- 相关概念:[[Container-Lifecycle-Hardening]]
|
||||
41
wiki/concepts/SDL-Security-Development-Lifecycle.md
Normal file
41
wiki/concepts/SDL-Security-Development-Lifecycle.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "SDL (Security Development Lifecycle)"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- Development
|
||||
- SDLC
|
||||
---
|
||||
|
||||
## Definition
|
||||
SDL(Security Development Lifecycle,软件安全开发生命周期)是将安全实践集成到软件开发流程中的系统化方法。
|
||||
|
||||
## Micro Focus 13 个安全轨道
|
||||
Micro Focus 将供应链安全作为 SDL 的第五大支柱,共 13 个安全轨道:
|
||||
1. 威胁建模
|
||||
2. 安全需求
|
||||
3. 安全设计
|
||||
4. 安全实现
|
||||
5. 供应链安全(新增)
|
||||
6. 安全测试
|
||||
7. 代码审计
|
||||
8. 渗透测试
|
||||
9. 安全部署
|
||||
10. 安全运营
|
||||
11. 事件响应
|
||||
12. 安全培训
|
||||
13. 合规与审计
|
||||
|
||||
## Integration Points
|
||||
- 需求阶段:安全需求定义
|
||||
- 设计阶段:威胁建模、安全架构评审
|
||||
- 开发阶段:安全编码规范、SAST
|
||||
- 测试阶段:SCA、DAST
|
||||
- 部署阶段:安全配置审计
|
||||
- 运营阶段:漏洞管理、事件响应
|
||||
|
||||
## Related
|
||||
- [[Supply Chain Security]]:供应链安全作为 SDL 第五大支柱
|
||||
- [[SAST]]:静态应用安全测试
|
||||
- [[SCA]]:软件成分分析
|
||||
- [[DevSecOps]]:开发安全运营一体化
|
||||
40
wiki/concepts/Security-Group-Policy.md
Normal file
40
wiki/concepts/Security-Group-Policy.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Security Group Policy"
|
||||
type: concept
|
||||
tags: [AWS, Security, Firewall, Policy]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Security Group Policy 是 Firewall Manager 中用于管理跨账户安全组规则的策略类型。
|
||||
|
||||
## Definition
|
||||
在 Firewall Manager 环境中,Security Group Policy 定义了安全组的创建、更新和清理规则,支持三种类型:
|
||||
|
||||
## Policy Types
|
||||
|
||||
### 1. Common Security Group(通用安全组)
|
||||
- 附加基线安全组到资源
|
||||
- 允许产品团队添加额外规则
|
||||
- 确保所有账户拥有基础安全保护
|
||||
|
||||
### 2. Audit and Enforcement(审计与强制)
|
||||
- 检测并拒绝过度宽松的规则
|
||||
- 支持手动修复或自动修复
|
||||
- 提供合规性仪表板视图
|
||||
|
||||
### 3. Unused Security Group Cleanup(清理未使用)
|
||||
- 识别和删除冗余安全组
|
||||
- 简化安全管理
|
||||
- 减少攻击面
|
||||
|
||||
## Key Features
|
||||
|
||||
- 支持 AWS Organizations 组织单位(OU)级别应用
|
||||
- 通过 Prefix List 共享规则
|
||||
- 使用 RAM 实现跨账号资源共享
|
||||
|
||||
## Related Concepts
|
||||
- [[Security Group]]
|
||||
- [[AWS Firewall Manager]]
|
||||
29
wiki/concepts/Supply-Chain-Security.md
Normal file
29
wiki/concepts/Supply-Chain-Security.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Supply Chain Security"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- Supply-Chain
|
||||
- CI/CD
|
||||
---
|
||||
|
||||
## Definition
|
||||
软件供应链安全,保护从开发到交付的全流程安全。包括源码管理(SCM)、构建组件(CI)、制品库到最终交付系统(CD)的所有环节的安全性。
|
||||
|
||||
## Key Components
|
||||
- **开发环境安全**:开发人员工作站、IDE 安全
|
||||
- **源码管理(SCM)安全**:代码仓库访问控制、代码签名
|
||||
- **构建(CI)安全**:构建服务器安全、构建脚本验证、依赖检查
|
||||
- **制品库安全**:二进制文件完整性、签名验证
|
||||
- **交付(CD)安全**:交付渠道安全、版本验证
|
||||
|
||||
## Best Practices
|
||||
- SBOM(Software Bill of Materials):软件物料清单,记录所有依赖
|
||||
- 签名验证:所有构建产物必须经过数字签名
|
||||
- 安全扫描:构建过程中集成 SAST、 SCA、容器扫描
|
||||
- 最小权限:CI/CD 工具使用最小权限原则
|
||||
|
||||
## Related
|
||||
- [[SolarWinds Hack]]:著名供应链攻击案例
|
||||
- [[CI/CD Security]]:持续集成与持续交付安全
|
||||
- [[SDL (Security Development Lifecycle)]]:软件安全开发生命周期
|
||||
43
wiki/concepts/Three-Lines-of-Defense.md
Normal file
43
wiki/concepts/Three-Lines-of-Defense.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Three Lines of Defense"
|
||||
type: concept
|
||||
tags: [Security, Governance, Risk-Management, Framework]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
三道防线(Three Lines of Defense,3LoD)是一种企业风险管理框架,通过分层职责确保安全控制的有效性。
|
||||
|
||||
## First Line of Defense
|
||||
业务单元:负责在其领域内实施和管理安全控制,是安全的直接责任方。
|
||||
|
||||
## Second Line of Defense
|
||||
集团办公室:负责制定政策、事件响应和网络工具,作为第一道防线的顾问,提供指导和支持。
|
||||
|
||||
## Third Line of Defense
|
||||
审计:确保第一道和第二道防线的合规性,为企业提供保证。
|
||||
|
||||
## Key Drivers
|
||||
- 监管合规(Regulatory Compliance)
|
||||
- 集中化平台(Centralized Platform)
|
||||
- 云迁移(Cloud Migration)
|
||||
- 基线控制(Baseline Controls)
|
||||
- 更大的安全响应覆盖范围
|
||||
|
||||
## Work Streams Implemented
|
||||
- 政策审查与整合
|
||||
- 事件响应参与
|
||||
- 网络安全风险与控制指标开发
|
||||
- 网络安全工具审查
|
||||
- 安全架构标准与模式
|
||||
|
||||
## Related Entities
|
||||
- [[Coyote]] — Head of Enterprise Application Security,框架推动者
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud-Security-Posture-Management]]
|
||||
- [[Regulatory-Compliance]]
|
||||
- [[Risk-Management]]
|
||||
|
||||
## Related Sources
|
||||
- [[CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)]]
|
||||
Reference in New Issue
Block a user