实验设置
本周的Sunday Funday挑战涉及审查微软365统一审计日志(UAL)，为此我获取了一个开发租户。首先确保UAL已启用，然后使用不同账户进行特定搜索操作。
搜索场景测试结果
1. 用户搜索自己的邮箱
假设：应记录搜索查询但不会显示具体内容 数据生成：发送包含"TESTKITCHENSEARCHEMAIL"的邮件并搜索 结果：日志中未显示任何搜索记录
2. 用户搜索自己的OneDrive
假设：应记录搜索查询但不会显示具体内容
数据生成：上传文件并搜索文件内容
结果：日志中无搜索记录
3. 管理员搜索自己的邮箱
假设：应记录搜索操作但不显示内容 数据生成：使用全局管理员账户执行搜索 结果：无返回结果
4. 管理员搜索自己的OneDrive
假设：应记录搜索操作但不显示内容 数据生成：使用全局管理员账户执行搜索 结果：无返回结果，搜索功能出现异常
5. 管理员搜索他人邮箱
假设：内容搜索会被记录，但委托访问搜索不会
数据生成：
- 通过Purview eDiscovery门户运行内容搜索
- 通过Outlook Web Access添加委托访问
结果：
- eDiscovery操作被详细记录，包括"查看eDiscovery案例"、“查看Purview搜索”、“开始内容搜索"等
- “开始内容搜索"显示搜索文本但未显示搜索资源
- OWA中的搜索完全未被记录
6. 管理员搜索他人OneDrive
假设：委托访问搜索会被记录 数据生成：通过管理门户添加委托访问并执行搜索 结果：再次无返回结果，仅记录"ListViewed"或"Viewed Page"操作
重要发现
用户搜索导出功能
在用户设置中可导出用户搜索历史，文件包含具体的搜索记录：
|
|
审计配置限制
搜索记录是需要专门启用的事件类型，默认未开启。
结论
本次测试最有趣的是几乎没有任何搜索操作出现在日志中。虽然在实际案例工作中见过搜索记录，但大多不包含搜索文本或仅显示星号。
唯一在日志中明确观察到的搜索相关活动是eDiscovery案例操作，这符合审计预期。
需要进一步研究Entra，且目前无法直接使用KQL查询UAL，CloudEvents表在实践中也不是完整记录。