AI 资源库 · 已整理 2 项

审计日志

查看与审计日志相关的 AI 资讯、工具、Skill、工作流和开源项目。

工具与应用

保持常青：我们如何在共享组织中自动化安全访问与仓库卫生

GitHub 员工在共享组织里和外部客户、合作伙伴一起做项目，时间一长，谁还需要访问权限、哪些仓库已经没人用了，靠人工记录很难跟上。他们做了一个叫 Evergreen 的 GitHub App，用 GitHub 自带的定时任务、webhook 和 issue 来干活：每季度给每个仓库开一张清单 issue 让人勾选保留谁，没人回复就默认收回权限；长期没人动的仓库会先警告、再归档，而且从不删除内容。所有状态存成 git 里的 JSON 文件，改动记录本身就是审计日志。这样仓库管理员不用再维护表格，也能保证权限不会一直留着。

文中可用工具

  • Evergreen自动审查外部协作者访问权限并归档长期无活动仓库的 GitHub App
  • GitHub Actions按季度定时触发工作流，作为 Evergreen 的时钟
  • repository_dispatchGitHub 事件类型，用于唤醒 Evergreen 执行任务
  • workflow_dispatch支持手动触发工作流步骤
  • GitHub webhooks监听 issues.closed 等事件并驱动后续操作
  • GitHub custom properties设置 evergreen_repo_owner 来指定仓库负责人
  • Copilot可通过复制粘贴快速回滚误操作
# 审计日志# 权限管理# 仓库治理# GitHub App# 自动化工作流
☆ 收藏查看来源 ↗
评论 · 分享第一个看法
Agent 与工作流

Agent 干了活，审计日志却说不出是谁下的指令

CloudBolt 的首席客户官 Shawn Petty 和售前工程总监 Mike Bombard 在一次网络研讨会上，分享了他们对客户和潜在客户环境的检查结果：超过 20% 与 MCP 相关的访问策略要么失效要么缺失，多数情况下 MCP 服务器跑在某个人的私人令牌上，而不是服务账号。这带来的麻烦是出事后审计日志查不清责任：私人令牌会把某个工程师的名字写进日志，共享服务账号则只留下账号名，两种都说不准到底是谁下的指令、谁批准了这次访问。他们演示的做法是把 Agent 的活动对接到企业已有的身份提供商，限制 Agent 能碰哪些资源，再读出可追溯的审计记录。对用 Agent 操作云基础设施的团队来说，这提供了一个把 Agent 行为追责到具体人的思路；该研讨会需注册后参加，具体产品能力原文未说明。

文中可用工具

  • CloudBolt把 Agent 活动对接到已有身份提供商、限制 Agent 可访问范围并输出审计记录的方案
# MCP# 审计日志# 身份提供商# 访问策略# CloudBolt
☆ 收藏查看来源 ↗
评论 · 分享第一个看法