secretary

🛡️ 安全优先的 M365 智能办公助手

办公榜 #18

基于 Microsoft Graph API 与 MSAL 认证的安全办公助手,实现邮件分类、日历协调与文件治理自动化,提升高管办公效率。

收藏
16.5k
安装
3.8k
版本
v1.0.1
CLS 安全性认证2026-05-06
点击查看完整报告 >

使用说明

核心用法

Secretary 是一款面向 Microsoft 365 生态的安全自动化工具,通过 Python 脚本与 Microsoft Graph API 交互,提供四大核心功能模块:邮件智能分类(mail)、日历空闲查询(calendar)、OneDrive 文件治理(drive)以及 Teams 频道通知(teams)。该技能采用 MSAL(Microsoft Authentication Library)官方库实现 OAuth2 委派权限认证,要求用户预先在 Azure Entra ID 中注册公共客户端应用,并通过环境变量配置 CLIENT_IDTENANT_ID,确保所有操作均在用户显式授权下执行,严格遵循最小权限原则。

显著优点

安全性设计是该技能的最大亮点。首先,代码层面完全杜绝了 eval()exec()os.system() 等危险函数,敏感信息均通过环境变量注入,无硬编码密钥风险。其次,采用委派权限(Delegated Permissions)而非应用程序权限,确保只能访问当前用户的数据,而非整个租户。此外,令牌缓存文件设置了 Unix 权限保护(0o600),且所有数据仅与官方 Microsoft Graph API 通信,不存在静默上传至第三方服务器的风险。依赖库均为成熟官方组件(msal、requests、python-dotenv),无已知 CVE 漏洞。

潜在缺点与局限性

尽管代码质量良好,但仍存在若干限制。首先,作为 T3 级社区来源(个人 GitHub 账号),缺乏组织级背书与代码签名,用户需自行承担代码审查责任。其次,命令行接口缺乏输入验证机制,calendar 命令的 email 参数与 teams 命令的 ID 参数均未进行格式校验,可能导致 API 调用失败。错误处理较为简单,可能暴露部分系统错误信息。最后,部署门槛较高,需要用户具备 Azure 应用注册与权限配置的专业知识,对非技术用户不够友好。

适合的目标群体

该技能最适合以下人群:一是需要自动化处理大量 M365 邮件的个人高级用户或高管助理;二是小型团队中负责 OneDrive 存储治理的 IT 管理员;三是希望集成 Teams 通知功能的自动化工作流开发者;四是具备一定 Python 与 Azure 基础、注重数据隐私的隐私敏感型用户。对于缺乏技术背景或无法信任社区代码的企业环境,建议谨慎评估后再使用。

使用风险说明

主要风险集中在配置与输入环节。若 .env 文件保管不当导致 CLIENT_IDTENANT_ID 泄露,可能被用于伪造身份请求。命令行参数缺乏校验可能导致意外的 API 调用或权限错误。此外,依赖项版本未完全锁定(requirements.txt 未指定版本号),在极端情况下可能因依赖库更新引入破坏性变更。建议用户在隔离环境中运行,定期审查令牌权限范围,并对敏感操作添加额外的审计日志。

安全解读

核心用法

Secretary 是一款面向 Microsoft 365 生态的安全优先型执行助手,通过委派权限模式(Delegated Permissions)以用户身份安全访问数据。主要功能涵盖四大模块:

  • Mail 模块:执行高优先级邮件分类(secretary_engine.py mail),自动识别需紧急处理的邮件
  • Calendar 模块:协调会议时间槽查询(secretary_engine.py calendar [email]),支持跨用户日程对齐
  • Drive 模块:治理 OneDrive 存储,识别孤立/过期文件(secretary_engine.py drive
  • Teams 模块:向指定频道推送安全警报(secretary_engine.py teams [team_id] [channel_id] [msg]

部署需先在 Azure Entra ID 注册 Public Client 应用,授予 Mail.ReadWriteCalendars.ReadWriteFiles.ReadWriteChatMessage.Send 委派权限,并配置 SECRETARY_CLIENT_IDSECRETARY_TENANT_ID 环境变量。

显著优点

  • 安全架构领先:采用委派权限而非应用权限,确保仅访问用户自有数据,避免越权风险
  • 认证机制严谨:使用微软官方 MSAL 库,实现 OAuth 2.0 设备码流,令牌缓存文件设置 Unix 0600 权限(仅所有者可读写)
  • 供应链可信:依赖 msalrequestspython-dotenv 均为微软/业界权威库,无已知 CVE
  • 传输加密完备:所有通信强制 HTTPS/TLS 1.2+,仅限于 login.microsoftonline.comgraph.microsoft.com 官方端点
  • 敏感信息管理:Client ID、Tenant ID 通过环境变量注入,避免硬编码泄露

潜在缺点与局限性

  • 权限范围较宽:一次性申请读写组合权限(Mail.ReadWrite 等),虽为委派模式,但仍建议用户按实际场景在 Azure Portal 中裁剪
  • 交互式认证依赖:当前实现需用户参与设备码认证流程,尚未实现 acquire_token_by_refresh_token 的非交互式刷新
  • 网络强依赖:全部功能绑定 Microsoft Graph API,离线环境或网络受限场景无法运行
  • 日志审计缺失:未内置敏感操作审计日志(邮件修改、消息发送等),需用户自行扩展
  • 错误处理简约:API 响应校验与结构化错误返回机制待完善

适合人群

  • 需要自动化 M365 工作流但拒绝应用级广泛权限的安全敏感型企业用户
  • 已具备 Azure AD 管理权限、熟悉 OAuth 委派模式的 IT 管理员
  • 追求代码透明可审计、愿意自行部署维护的开源安全倡导者

常规风险

  • 凭证泄露风险.env 文件若误提交至版本控制或权限设置不当,可能导致 Client ID 暴露(虽 Tenant ID 与 Client ID 单独泄露风险有限,但仍建议 chmod 600 保护)
  • 令牌窃取风险token_cache.bin 虽设 0600 权限,但在多用户服务器或容器环境中仍需确保运行用户隔离
  • 供应链监控需求:GitHub 组织账号 openclaw 来源需持续监控,建议关注上游更新与签名验证
  • 权限维持审计:建议在 Azure Portal 定期审计该应用的同意记录,及时撤销不再使用的用户授权

secretary 内容

手动下载zip · 3.3 kB
.envtext/plain
请选择文件