ruwgxo/hsed
GitHub: ruwgxo/hsed
借鉴 Unix chmod 八进制权限模型,为密码学操作提供简洁统一的权限定义与跨云平台策略生成框架。
Stars: 0 | Forks: 0
# HSED:用于密码学的 Unix 权限模型
[](https://opensource.org/licenses/MIT)
[](https://www.python.org/downloads/)
[](CONTRIBUTING.md)
**HSED:Hash | Sign | Encrypt | Decrypt**
## 痛点
你需要授予 CI/CD 流水线签名容器镜像的权限,但是你的云服务提供商的 IAM 策略却类似于这样:
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:Sign",
"kms:Verify",
"kms:GenerateDataKey",
"kms:CreateKey",
"kms:DescribeKey"
],
"Resource": "*"
}
```
**翻译过来就是:**“我们放弃治疗了,直接给了所有权限。”
听起来很熟悉?
## 解决方案
```
# 您的 CI/CD pipeline 应仅负责签名
hsed:signer = 12 # H+S (Hash + Sign only)
# 您的 secrets manager 应仅负责加密/解密
hsed:vault = 3 # E+D (Encrypt + Decrypt only)
# 您的审计团队应验证并读取
hsed:audit = 9 # H+D (Hash + Decrypt only)
```
就像 `chmod 755` 一样,只不过是用于密码学操作。
## 快速入门
### 安装
```
pip install hsed
```
### 命令行使用
```
# 初始化 HSED policy
hsed init
# 创建 signer 角色 (CI/CD)
hsed role create signer --permissions 12
# 生成 AWS KMS policy
hsed generate aws-kms --role signer --key-arn arn:aws:kms:...
# 验证现有 policies
hsed validate policy.hsed
# 审计您的 AWS KMS 权限
hsed audit aws-kms --profile production
```
### Python API
```
from hsed import Policy, Role, Permissions
# 定义角色
policy = Policy()
policy.add_role(Role('signer', permissions=12)) # H+S
policy.add_role(Role('vault', permissions=3)) # E+D
policy.add_role(Role('audit', permissions=9)) # H+D
# 在运行时 Enforce
@policy.enforce(role='signer')
def sign_artifact(data: bytes) -> bytes:
return sign_data(data) # ✓ Allowed
@policy.enforce(role='signer')
def decrypt_secret(ciphertext: bytes) -> bytes:
return decrypt_data(ciphertext) # ✗ PermissionError!
# 生成 cloud provider policies
aws_policy = policy.to_aws_kms(role='signer', key_arn='...')
vault_policy = policy.to_vault(role='signer', path='signing/*')
```
## HSED 权限模型
### 权限位
```
H | S | E | D
8 4 2 1
```
- **H (8)** - Hash/Verify(哈希/验证):计算哈希值,验证签名
- **S (4)** - Sign(签名):创建数字签名、证明
- **E (2)** - Encrypt(加密):封装数据,生成密文
- **D (1)** - Decrypt(解密):解封数据,读取明文
### 八进制表示法(类似 chmod)
```
hsed 15 # 1111 = H+S+E+D = Full crypto authority (root)
hsed 12 # 1100 = H+S = Sign only (CI/CD, code signing)
hsed 3 # 0011 = E+D = Encrypt/Decrypt (vault, secrets)
hsed 9 # 1001 = H+D = Verify + Read (audit, forensics)
hsed 10 # 1010 = H+E = Hash + Encrypt (DMZ, ingress)
```
### 标准角色
| 角色 | 权限 | 应用场景 |
|------|-------------|----------|
| `hsed:root` | 15 (H+S+E+D) | 最高权限(紧急使用) |
| `hsed:admin` | 14 (H+S+E) | 无解密权限的管理员 |
| `hsed:signer` | 12 (H+S) | CI/CD,代码签名,证明 |
| `hsed:vault` | 3 (E+D) | 密钥管理 |
| `hsed:audit` | 9 (H+D) | 合规审查,取证 |
| `hsed:encryptor` | 10 (H+E) | 数据摄入,封装 |
| `hsed:verifier` | 8 (H) | 仅限签名验证 |
## 为什么选择 HSED?
### 1. **设计上的最小权限原则**
```
# 无 HSED:Overly permissive
"Action": ["kms:*"] # 😱
# 有 HSED:精确权限
role = Role('signer', permissions=12) # Only H+S ✓
```
### 2. **职责分离**
```
Financial Transaction Flow:
┌─────────────────────────────────────┐
│ Initiator: hsed 10 (H+E) │ ← Can hash and seal request
│ Approver: hsed 13 (H+S+D) │ ← Can verify, sign, decrypt
│ Executor: hsed 9 (H+D) │ ← Can verify signature, decrypt
└─────────────────────────────────────┘
No single role can complete the transaction alone.
```
### 3. **通用性强**
适用于以下场景:
- ✅ AWS KMS
- ✅ HashiCorp Vault
- ✅ Azure Key Vault
- ✅ GCP Cloud KMS
- ✅ 硬件安全模块 (HSMs)
- ✅ 自定义密钥管理系统
### 4. **对审计友好**
```
# 查找所有 god-mode 访问权限
grep "hsed:15" audit-trail.log
# 查找所有具备 decrypt 权限的角色
hsed audit list --can-decrypt
# Compliance report
hsed report --soc2 --output compliance.pdf
```
### 5. **易于记忆和传授**
如果你的团队懂得 `chmod 755`,他们就能理解 `hsed 12`。
## 实际应用案例
### CI/CD 代码签名
```
# GitHub Actions workflow
- name: Sign container image
env:
HSED_ROLE: signer # permissions=12 (H+S)
run: |
hsed sign --key signing-key \
--input image.tar \
--output image.tar.sig
```
**受限的权限:**
- ✅ 可以对镜像进行哈希处理
- ✅ 可以对哈希值进行签名
- ❌ 无法解密生产环境的密钥
- ❌ 无法加密(防止数据外泄)
### 密钥管理
```
from hsed import enforce
@enforce(role='vault') # permissions=3 (E+D)
def store_secret(name: str, value: str):
encrypted = encrypt(value)
save_to_store(name, encrypted)
@enforce(role='vault')
def retrieve_secret(name: str) -> str:
encrypted = load_from_store(name)
return decrypt(encrypted)
```
**受限的权限:**
- ✅ 可以加密密钥
- ✅ 可以解密密钥
- ❌ 无法签名(防止伪造证明)
- ❌ 无法哈希(角色专一)
### 审计与取证
```
# Auditor 角色:hsed:audit (permissions=9, H+D)
hsed audit verify-logs \
--role audit \
--logs /var/log/audit/* \
--key-id audit-key
```
**受限的权限:**
- ✅ 可以验证日志签名
- ✅ 可以解密证据以供调查
- ❌ 无法签名(防止篡改证据)
- ❌ 无法加密(防止隐藏数据)
## 文档
### 📚 [完整手册](chapters/README.md)
涵盖以下内容的综合指南:
- 第 1 章:简介与基础概念
- 第 2 章:核心概念
- 第 3 章:实现模式
- 第 4 章:云服务提供商集成
- 第 5 章:安全与合规
- 第 6 章:高级主题
- 第 7 章:实际应用案例研究
### 📖 [规范说明](SPECIFICATION.md)
RFC 风格的 HSED 权限模型规范。
### 🚀 [快速入门指南](docs/guides/)
- [AWS KMS 集成](docs/guides/aws-kms.md)
- [HashiCorp Vault 配置](docs/guides/vault.md)
- [Azure Key Vault 配置](docs/guides/azure-keyvault.md)
- [GCP Cloud KMS 配置](docs/guides/gcp-kms.md)
### 🛠️ [示例](examples/)
可直接使用的实现方案:
- [CI/CD 流水线安全](examples/cicd-pipeline/)
- [密钥管理](examples/secrets-manager/)
- [审计轨迹设计](examples/audit-trail/)
- [零信任架构](examples/zero-trust/)
## 项目结构
```
hsed/
├── chapters/ # Complete book (YAML format)
│ ├── hsed_book_index.yaml
│ ├── chapter_1_index.yaml
│ ├── section_1_01_introduction.yaml
│ └── ...
│
├── hsed/ # Python package
│ ├── core/ # Core permission engine
│ ├── enforcement/ # Runtime enforcement
│ ├── integrations/ # Cloud provider integrations
│ ├── cli/ # Command-line interface
│ └── utils/ # Utilities
│
├── examples/ # Real-world usage patterns
│ ├── cicd-pipeline/
│ ├── secrets-manager/
│ ├── audit-trail/
│ └── zero-trust/
│
├── templates/ # Ready-to-use templates
│ ├── aws-kms/
│ ├── hashicorp-vault/
│ └── kubernetes/
│
├── tests/ # Test suite
├── docs/ # Generated documentation
└── bin/ # CLI executable
```
## 为什么叫 "HSED"?
**H**ash | **S**ign | **E**ncrypt | **D**ecrypt
四项基本的密码学操作。四个权限位。简单。通用。易于记忆。
就像 `chmod` 让我们认识了 `rwx` 一样,HSED 教会我们是谁在以何种方式接触我们的密码学资产。
## 许可证
MIT 许可证 - 详见 [LICENSE](LICENSE)。
## 引用
如果您在研究或生产系统中使用了 HSED,请引用:
```
@software{hsed2024,
title = {HSED: Unix Permissions for Cryptographic Operations},
author = {Your Name},
year = {2024},
url = {https://github.com/yourusername/hsed}
}
```
## 致谢
灵感来源于:
- Unix 文件权限 (`chmod`)
- 最小权限原则
- 管理真实环境中 KMS/HSM 权限的痛点
- 对简单、通用的安全抽象的迫切需求
## 项目状态
🚧 **早期开发阶段** - API 可能会发生变更
- [x] 核心权限模型
- [x] Python 实现
- [x] CLI 工具
- [ ] AWS KMS 集成
- [ ] HashiCorp Vault 集成
- [ ] Azure Key Vault 集成
- [ ] GCP Cloud KMS 集成
- [ ] 完整文档
- [ ] 生产就绪 (v1.0.0)
## 联系方式
- **问题反馈**:[GitHub Issues](https://github.com/yourusername/hsed/issues)
- **讨论交流**:[GitHub Discussions](https://github.com/yourusername/hsed/discussions)
- **安全漏洞**:有关负责任的漏洞披露,请参阅 [SECURITY.md](SECURITY.md)
**如果 `chmod` 教会了你 `rwx`,那么让 HSED 来教你密码学权限吧。**
怀着 ❤️ 为坚信最小权限原则的安全工程师而作。
标签:AWS KMS, CI/CD安全, CVE, DevSecOps, IAM策略, JSONLines, KMS策略, Llama, Python, Streamlit, StruQ, 上游代理, 代码签名, 八进制表示法, 加密, 哈希, 安全合规, 密码学, 密钥审计, 手动系统调用, 数字签名, 文档结构分析, 无后门, 最小权限原则, 权限管理, 模型越狱, 漏洞扫描器, 策略生成, 网络代理, 解密, 访问控制, 逆向工具, 零信任