WanThinnn/Cloud-Policy-Crypto-Access

# 云策略加密访问系统 一个全面的企业级文件存储系统，实现了集成 **Hybrid Ciphertext-Policy Attribute-Based Encryption (CP-ABE)** 与 **Supabase**，提供高度安全的文件管理、多层级 Attribute-Based Access Control (ABAC) 和高性能缓存。 ## 项目概述 本代码库包含一个基于 Django 的稳健安全文件共享系统。该系统通过实现与用户属性在数学上绑定的细粒度访问控制，摆脱了传统的基于角色的安全机制，为敏感数据提供零信任安全性。  在 `img/` 目录中查看更多演示图片。 ### 核心功能 - **混合 CP-ABE 加密 (v3.1.0)**：高级的基于属性的加密，利用高速内存缓冲区 (RAM) 进行加密/解密，完全绕过磁盘 I/O 瓶颈。详情请见：https://github.com/WanThinnn/Hybrid-CP-ABE-Library.git - **HashiCorp Vault 集成（信封加密）**：企业级密钥管理。Vault 保护 CP-ABE 主密钥，并动态包装逐文件 Data Encryption Keys (DEK)，确保密钥永远不会泄漏到磁盘。 - **Supabase 集成**：利用 Supabase Storage 托管加密文件，利用 Supabase PostgreSQL 进行高性能元数据管理。 - **多层安全性**：结合 **HashiCorp Vault**、**CP-ABE AC17** 和 **AES-GCM-256**（数学加密）与 **Casbin ABAC**（应用层访问控制）实现深度防御。 - **字段级 SQL 加密与盲索引**：保护关系数据库中的敏感元数据。诸如物理路径、原始文件名、签名 URL 和自动提取的上传元数据等字段均使用 AES-256-GCM 进行重度加密。对这些字段的查询利用 HMAC-SHA3-256 盲索引，在确保绝对隐私的同时保持可搜索性。 - **高级策略引擎**：为 ABAC 和 CP-ABE 策略实现了抽象语法树 (AST) 评估器，支持任意复杂的嵌套布尔逻辑（例如 `(A and B) or C`），并集成了可视化 UI 构建器。 - **智能策略组合**：当现有文件被授予新的访问权限时，自动使用 `OR` 逻辑重新加密并合并策略。 - **交互式文件管理 SPA**：一个动态的单页文件管理器，具有层级文件夹导航、拖放上传、剪贴板操作（复制/剪切/粘贴）、文件版本控制、带回收站与恢复的软删除、内联重命名以及可视化的 CP-ABE 策略构建器。 - **前端零密钥暴露**：私钥严格在后端的内存空间内生成、使用和销毁。 - **Redis 缓存**：为 CP-ABE 私钥和 Casbin 策略提供高度优化的 Redis 缓存，确保近乎瞬间的文件预览。 - **高级安全加固**：实现 **Content Security Policy (CSP)** 以严格防止 XSS，实现 **速率限制** 以保护高 CPU 占用的 CP-ABE 操作免受 DoS/DDoS 攻击，并实现 **不可能旅行检测** 以阻止可疑的地理登录异常。 - **设备与会话管理**：使用 Stateful JWT 追踪所有活跃设备，允许用户通过单击安全地“登出所有其他设备”。 - **细粒度 SIEM JSON 日志记录**：将日志分离为 7 个独立的 JSON 文件（`auth`、`storage`、`policy`、`user`、`attributes`、`audit`、`system`），并为事件添加上下文 `user_id` 和 `user_name`，以便 SIEM 系统（例如 Wazuh、Splunk、ELK）立即摄取。 - **O(1) 审计日志完整性**：使用 Redis Hash 缓存结合连续的加密哈希链（区块链风格），在 `O(1)` 时间内瞬间验证日志篡改，并提供深度验证回退。 - **Post-Quantum TLS 就绪**：构建于 OpenQuantumSafe (OQS) Nginx 分支之上，系统自动在 TLS 1.3 上强制执行 **Hybrid ML-KEM-768 (Kyber)** 密钥交换，以保护所有传输中的数据免受量子计算机攻击（现在收集，稍后解密）。 - **Docker 化架构**：完全容器化的环境，包含 Nginx、Gunicorn、Django、HashiCorp Vault 和 Redis，实现无缝生产部署。 ## 技术栈 ### 后端与基础设施 - **框架**：Django 5.x & Django REST Framework - **数据库与存储**：Supabase PostgreSQL & Supabase Storage - **安全与加密**：HashiCorp Vault、OpenQuantumSafe (OQS)、Post-Quantum Hybrid TLS 1.3 (ML-KEM) - **缓存与消息代理**：Redis 7 - **Web 服务器**：OQS Nginx & Gunicorn - **部署**：Docker & Docker Compose ### 安全与加密 - **密钥管理**：HashiCorp Vault - **混合 CP-ABE**：通过 Python `ctypes` 桥接的自定义 C++ `libhybrid-cp-abe` (v3.1.0) - **访问控制**：PyCasbin (Attribute-Based Access Control) - **身份验证**：JWT (JSON Web Tokens) ## 架构 ``` flowchart LR classDef client fill:#f9f9f9,stroke:#333,stroke-width:2px; classDef gateway fill:#e1f5fe,stroke:#0288d1,stroke-width:2px; classDef datalayer fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px; classDef core fill:#fff3e0,stroke:#f57c00,stroke-width:2px,stroke-dasharray: 5 5; subgraph Clients ["📱 Clients"] direction TB Web("🌐 Web Frontend"):::client Mob("📱 Mobile / CLI"):::client end subgraph Gateway ["🛡️ Django API Server"] direction TB Auth("🔑 JWT Auth"):::gateway Casbin("🛂 Casbin ABAC"):::gateway Ctrl("📦 File Controller"):::gateway CPABE("🔐 CP-ABE C++ Lib"):::core Auth --> Casbin Casbin --> Ctrl Ctrl <-->|In-Memory Buffer| CPABE end subgraph DataLayer ["🗄️ Infrastructure"] direction TB Vault[("🛡️ HashiCorp Vault
(Master Keys)")]:::datalayer Redis[("⚡ Redis Cache
(User Keys & Policies)")]:::datalayer DB[("🐘 Supabase DB
(Metadata)")]:::datalayer Storage[("☁️ Supabase Storage
(Ciphertexts)")]:::datalayer end Web -->|HTTPS / REST| Auth Mob -->|HTTPS / REST| Auth Casbin -.->|Cache| Redis Casbin -.->|Verify| DB Ctrl <-->|Fetch DEK/CP-ABE Key| Vault Ctrl <-->|Cache User Key| Redis Ctrl <-->|CRUD Metadata| DB Ctrl <-->|Upload/Download| Storage ``` ### 工作流概述 1. **身份验证与授权**：客户端通过 HTTPS 发出请求，其中包含 `HttpOnly Cookie`（用于 JWT）和 `X-CSRFToken` header。**Auth Middleware** 验证身份，**Casbin ABAC Engine** 根据存储的策略（缓存在 Redis 中）评估用户属性以确定访问权限。 2. **加密/解密（内存中）**：在经过授权的文件上传/下载时，**Storage Controller** 从 **HashiCorp Vault** 获取 CP-ABE 主密钥。它根据用户的当前属性生成临时的 CP-ABE 私钥。此密钥临时缓存在 **Redis** 中。文件本身使用随机 AES-256-GCM DEK 加密，然后此 DEK 被 CP-ABE 包装（加密）。数据缓冲区传递给 **CP-ABE C++ 库** 以在 RAM 中直接处理，确保明文数据永远不会写入磁盘。 3. **数据持久化**：文件元数据、访问策略和用户属性在 **Supabase PostgreSQL** 中进行安全管理。完全加密的密文被上传到 **Supabase Storage**。 ## 快速开始（针对新环境的分步指南） 按照这些说明在全新的机器上从零开始部署系统。 ### 1. 前置条件 - 已安装 **Docker** 和 **Docker Compose**。 - **Python 3.10+**（如果您想在本地运行管理脚本）。 - 一个 **Supabase 项目**（您将需要 PostgreSQL 数据库 URL、项目 URL 和 Service Role Key）。 ### 2. 获取代码与加密库 ``` # 克隆此主仓库 git clone https://github.com/WanThinnn/Cloud-Policy-Crypto-Access.git cd Cloud-Policy-Crypto-Access ``` *注意：所需的 C++ 加密库（`libhybrid-cp-abe` v3.1.0）默认已包含在此代码库的 `src/lib/` 目录中。只有在您希望编译或更新到更新版本时，才需要访问 [Hybrid-CP-ABE-Library 代码库](https://github.com/WanThinnn/Hybrid-CP-ABE-Library.git)。* ### 3. 环境配置 从示例模板创建 `.env` 文件： ``` cp .env.example .env ``` 在文本编辑器中打开 `.env` 并填写缺失的关键值： - `DJANGO_SECRET_KEY`：生成一个长随机字符串。 - `DATABASE_URL`：从您的 Supabase Dashboard -> Settings -> Database -> Connection string (URI) 获取。如果使用 Supabase，请确保它以 `?sslmode=require` 结尾。 - `SUPABASE_URL`：您的 Supabase 项目 URL（例如 `https://xxxx.supabase.co`）。 - `SUPABASE_SERVICE_KEY`：您的 Supabase Service Role Key (Dashboard -> Settings -> API)。**切勿使用公开的 anon 密钥！** - `KEYS_DIR`：保持为 `./keys`，以安全地将您的加密主密钥挂载在源代码之外。 - `SSL_CERT_FILE` & `SSL_KEY_FILE`：（可选）默认情况下，系统使用自签名的 CyberFortress 证书。要在生产环境中使用您自己的证书，请将您的 `.crt` 和 `.key` 文件放在 `./certs` 文件夹中，并在此处指定它们的文件名。 ### 4. 设置 Supabase Storage 在运行系统之前，请配置您的存储： 1. 转到您的 Supabase Dashboard。 2. 导航到 **Storage**。 3. 创建一个新的 bucket（例如 `secure-storage`）。 4. 确保该 bucket 设置为 **Private**（不允许公开访问）。 ### 5. 构建并启动 Docker 容器 系统使用 Docker Compose 来编排 Django、Redis 和 Nginx。提供了 `start.py` 脚本以简化命令。 ``` # 构建 Docker 镜像 python start.py build # 以 detached 模式启动所有容器 python start.py up ``` ### 6. 初始化数据库并创建超级管理员 一旦容器成功运行（`python start.py status`），初始化系统。`initdata` 命令将自动迁移数据库、播种 ABAC 策略，并创建一个默认的超级管理员帐户。 ``` # 初始化 DB，注入 policies，并自动创建超级管理员 (admin/admin123) python start.py initdata ``` *（可选）* 如果您希望手动创建自定义超级管理员： ``` python start.py createsuperuser ``` ### 7. 访问应用程序 - 打开您的 Web 浏览器并导航至：**`http://localhost:8000/auth/login/`** - 使用您刚刚创建的超级管理员凭据登录。 - 登录后，导航到 **Manage** 部分，开始创建 User Types、定义 Attribute Schemas、为用户分配属性以及上传文件！ ## 文档 - **[项目规格说明书 (英文)](docs/en/project-specs-en.md)**：详细说明了双层架构、属性 schema 和系统工作流。 - **[API 规格说明书 (英文)](docs/en/api-specs-en.md)**：详细说明了身份验证流程、CP-ABE 加密工作流和 REST API endpoint。 - **[Đặc tả Dự án (Tiếng Việt)](docs/vi/project-specs.md)** - **[Đặc tả API (Tiếng Việt)](docs/vi/api-specs.md)** *服务器运行时，可在 `/api/docs/` 获取详细的 Swagger/OpenAPI 文档。* ## 安全须知 - **零持久化密钥**：CP-ABE 私钥永远不会存储在磁盘或数据库中。它们是动态（即时）生成的，并临时缓存在 Redis 中。 - **XSS 与攻击防护**：JWT Token 安全地存储在 HttpOnly cookie 中，并结合了严格的 **Content Security Policy (CSP)**。 - **DoS/DDoS 防护**：关键 endpoint（上传/下载/预览）受到 Django REST Framework Throttling 使用 Redis 的严格速率限制，以防止恶意 CP-ABE 生成请求导致 CPU 耗尽。 - 确保在生产环境中正确保护 `keys` 目录。`cpabe_msk.key` (Master Key) 绝不能暴露。`src/keys/` 中的开发密钥会被自动 git-ignored。 - **灾难恢复/迁移**：如果 `./keys` 文件夹中不存在 CP-ABE PublicKey 和 Master Key，后端会在启动时**自动生成**它们。但是，如果您迁移服务器或移动到全新的机器，您**必须**手动将旧机器上的 `cpabe_pub.key` 和 `cpabe_msk.key` 复制到新的 `./keys` 目录中。如果您丢失了旧的 Master Key，存储中所有以前加密的文件将变得永久无法访问。 - **元数据隐私**：云端存储端的真实物理文件路径使用随机 UUID 进行混淆，确保云提供商或基础设施攻击者无法推断目录结构或文件身份。 - 在生产环境中始终使用 `HTTPS`，以防止在 token 传输过程中发生 Man-in-the-Middle (MITM) 攻击。 ## 许可证 本项目基于 MIT 许可证授权 - 详情请参阅 [LICENSE](LICENSE) 文件。

标签：CP-ABE, Django, Streamlit, 密码学, 手动系统调用, 搜索引擎查询, 文件存储, 访问控制, 请求拦截