special1zt/ZT-GOVERNANCE-capstone

# AI 代理的零信任 本项目是一个面向AI代理的零信任实验室。其核心理念是，AI代理不应在没有任何实际监督的情况下，就被直接放入一个能访问API、工具和内部资源的环境中。 如果一个代理可以请求数据、与系统交互或做出决策，那么它就需要像可能影响环境的事物一样被管理。这意味着它应该有一个身份、一个角色、一个态势状态、日志记录，以及能够将其行为追溯到某个资产或事件的记录。 本实验室将AI代理视为受管配置项，而不仅仅是一个普通的脚本。代理不会仅因为拥有一个令牌就获得信任。其访问权限取决于身份、角色、态势，以及它是否被识别为 GLPI 中的活跃资产。 目标不是构建一个完美的企业产品，而是展示一个可行的模型，说明如何运用零信任理念来治理AI代理。 ## 主要组件 ## 我为什么构建这个 AI代理的行为开始越来越不像简单的聊天机器人，而更像自动化工作人员。它们可以跨系统调用API、检查数据、使用工具并做出决策。 这带来了安全问题。如果一个AI代理拥有访问权限，却没有明确的身份、没有资产记录、没有态势检查、没有事件追踪，那么它就会成为安全团队日后不得不追查的另一个未受管事物。 这个项目是我模拟一种更好方法的方式： ``` Keycloak ↓ Resource API / Posture API ↓ GLPI / CMDB ↓ Logs ↓ Splunk ↓ alert_fwd ↓ GLPI Incident Ticket ``` 这是项目的核心。 ## 研究问题 如何利用零信任安全模型，通过结合身份、态势验证、资产管理、API访问控制、SIEM检测和自动化事件响应来治理AI代理？ ## 架构概述 实验室采用基本的零信任流程： 1. 代理通过 Keycloak 进行身份验证。 2. 代理请求一个受保护的 API 资源。 3. 资源 API 检查令牌和角色。 4. 资源 API 检查代理态势。 5. 态势检查确认代理在 GLPI 中是否健康且活跃。 6. 请求被允许或拒绝。 7. 决策被记录。 8. Splunk 可以检测可疑活动。 9. `alert_fwd` 接收警报并创建 GLPI 工单。 ``` Authenticated → Posture Validated → Access Allowed ``` ## 资源访问模型 API 资源按敏感度分级。 | 资源类型 | 用途 | |---|---| | 公开 | 用于基本测试的低风险端点 | | 内部 | 需要有效的身份和良好的态势 | | 敏感 | 用于测试更严格访问控制的高风险端点 | | 蜜罐/诱饵 | 用于在被访问时证明检测和响应能力 | 蜜罐端点的存在并非因为项目需要虚假的密钥，而是为了展示可疑的代理行为可以被检测、记录并转化为事件。 ## Qwen / Ollama 测试 Qwen 被用作测试的 AI 代理。为其赋予一个身份和任务，然后观察当代理尝试访问受保护资源时，系统的反应。 测试聚焦于三种基本情况： ### 允许的访问 代理访问了它应被允许使用的资源。 预期结果： ``` Authenticated → Posture Failed → Access Denied → Event Logged ``` ### 拒绝的访问 代理通过了身份验证，但系统因态势或授权失败而拒绝了请求。 预期结果： ``` Decoy Access → Splunk Alert → alert_fwd → GLPI Ticket ``` ### 诱饵访问 代理接触了蜜罐或敏感端点。 预期结果： ``` . ├── agent OBSOLETE/ # Older agent work kept for reference ├── alert_fwd/ # Micro-SOC alert forwarder for Splunk-to-GLPI tickets ├── extras/ # Screenshots and prompts used during testing ├── keycloak/ # Keycloak realm, identity, or setup files ├── logs/ # API and test logs ├── scripts/ # Setup, test, and helper scripts ├── services/ # Main API services for resource access and posture checks ├── splunk/ # Splunk configuration, searches, or detection notes ├── wazuhOBSOLETE/ # Older Wazuh work kept for reference ├── .env # Local environment variables, not for public commits ├── docker-compose.yml # Local lab setup └── init-db.sql # Database initialization script ``` ## 什么算作成功的演示 一个可行的演示应展示完整的链条： 1. 代理在 Keycloak 中拥有身份。 2. 代理在 GLPI 中作为受管资产存在。 3. 代理请求一个受保护的资源。 4. API 检查令牌、角色和态势。 5. 有效的请求被允许。 6. 被拒绝或可疑的请求被记录。 7. Splunk 检测到该事件。 8. `alert_fwd` 接收警报。 9. GLPI 获得一个与该代理关联的事件工单。 如果这行得通，项目就算成功。 ## 示例场景 一个名为 `agent-dev-02` 的代理尝试访问一个内部资源。 系统检查： - 令牌是否有效？ - 代理是否拥有正确的角色？ - 设备态势是否健康？ - 代理在 GLPI 中是否活跃？ - 该资源是否允许该代理访问？ 如果代理态势检查失败，即使身份验证成功，请求也会被拒绝。 这是有意为之的。仅有身份并不等同于信任。 ## 仓库结构 ``` Keycloak GLPI Database services Resource / posture APIs Splunk alert_fwd ``` 有些文件夹标记为已过时，因为它们属于项目的早期版本。保留它们是作为参考，但当前的构建主要围绕 Keycloak、API 服务、GLPI、Splunk 和 `alert_fwd`。 ## 设置说明 本项目构建为本地实验室。具体值取决于本地环境，但主要服务通过 Docker 和环境变量控制。 典型的本地服务包括： ``` Agent Request → Access Decision → Log Event → Splunk Alert → alert_fwd → GLPI Ticket ``` `.env` 文件存储本地值，如服务 URL、令牌和数据库设置。真实的密钥不应提交到公开仓库。 ## 当前重点 当前的重点是让整个安全循环稳定运行： 当前工作包括： - 验证 `agent-dev-02` 的态势检查 - 确认在态势健康时允许访问正常工作 - 确认拒绝的访问被正确记录 - 测试蜜罐端点 - 检查 Splunk 是否看到正确的事件 - 检查 `alert_fwd` 是否创建了正确的 GLPI 工单 - 保持 Qwen 提示足够一致以便重复测试 ## 已知局限性 这仍然是一个原型实验室，而非生产系统。 一些局限性： - 部分凭据为测试目的存储在本地。 - 工作负载身份是模拟的，而非完全生产级。 - 运行时隔离有限。 - 态势逻辑经过简化。 - 一些较旧的项目文件夹仍作为参考存在。 - Qwen/Ollama 的行为在不同运行间可能变化。 一个更强大的生产版本将需要更好的密钥处理、更强的运行时隔离、短期凭据、工作负载身份以及更成熟的 SIEM/SOAR 工作流。 ## 最终目标 最终目标是展示AI代理可以使用已用于企业系统的相同安全理念来治理： - 身份 - 态势 - 资产管理 - 访问控制 - 监控 - 检测 - 事件响应 本项目并非声称能解决所有AI安全问题。它展示了一个切实的起点，用于在AI代理成为另一个无人愿意负责的未受管系统之前，对其进行管理。 ## 作者 Elton White CIT481 顶点项目

标签：AI代理安全, AI风险缓解, API安全, CMDB治理, GLPI, JSON输出, Keycloak, SIEM检测, Streamlit, 人工智能安全, 代理治理, 健康检查, 占用监测, 合规性, 姿态验证, 安全信息事件管理, 安全架构, 网络安全, 自动化事件响应, 行为审计, 访问控制, 请求拦截, 资产管理, 身份管理, 逆向工具, 隐私保护, 零信任架构