Slack审计日志与异常检测技术详解

Slack审计日志是什么？

与许多软件即服务(SaaS)产品类似，Slack为企业网格客户提供审计日志，记录实体在平台上的操作行为。例如用户登录、更新个人资料、应用下载文件等。审计日志捕获的操作列表非常广泛，建议定期查看新增内容。文档中提供了审计日志示例并详细讨论了各字段含义。

Slack审计日志可通过审计日志仪表板向组织管理员、所有者和具有审计日志管理员角色的用户开放，路径为：工具和设置→管理审计日志。审计日志也提供API接口，许多供应商都提供连接器将其摄入各自平台，例如：

审计日志API支持按属性过滤，包括日志生成时间、操作（最多指定30个操作）、执行者和实体。例如，如果企业只想使用审计日志中的用户登录事件，可以在调用API时指定action参数为user_login。

审计日志流中包含异常事件（动作为anomaly的事件）。这些事件与其他审计日志事件不同，它们不是记录实体在平台上执行的操作，而是表明Slack的分析管道检测到实体执行了异常操作（或操作集），或者实体执行操作的环境存在异常。

与组织引入的任何新事件源一样，Slack异常需要检测与响应团队进行调查、实验和分析后才能投入运营。

通常，组织不会直接将异常作为事件上报。它们表明发生了意外情况，可能需要进一步调查。异常的重要性因组织的政策和允许活动而异。

如果组织知道某些IP地址或网络范围与合法活动相关，Slack提供了允许列表这些来源的方法。这些API端点允许添加受信任的CIDR范围和ASN，为微调异常检测和减少异常量提供了灵活选项。

关联多个异常可以为潜在安全问题提供有价值的洞察。例如，user_agent异常与excessive_downloads异常同时发生可能表明正在使用爬取工具。如果ip_address或session_fingerprint异常伴随上述异常，情况可能更加严重。

我们可以聚合某些异常以发现感兴趣的场景。例如，组织可能观察到多个用户每天生成excessive_downloads异常，但这些异常可能不代表恶意活动。通过检查用户在一段时间内生成的excessive_downloads异常数量并与历史规范比较，可以帮助发现用户执行不需要活动的情况。

异常日志的量级远低于审计日志，通常至少低两个数量级。如果组织希望关注异常日志但无法处理完整的审计日志量，可以使用前面概述的方法仅过滤异常。但我们强烈建议尽可能使用完整的审计日志，以便在调查异常日志时拥有最全面的上下文信息。

如果不使用外部服务查看Slack审计日志，可以通过工具和设置→管理审计日志访问UI界面。以销售员Matt离开虚构公司Acme Corp为例：

首先加载审计日志主标签页，然后切换到安全检测标签页查看Matt生成的异常。通过点击•••菜单并选择查看完整日志详情，可以获取异常的更多信息。

如果发现与用户账户相关的可疑活动并希望立即采取措施，可以直接从审计日志仪表板终止用户的活动会话。导航到相应用户的特定异常日志条目，点击•••菜单并选择"退出Slack"。此操作会立即使用户的所有活动会话失效。

虽然Matt的活动没有生成ip_address异常，但如果生成，分析人员需要确定触发IP是否是Matt访问Slack的预期IP。同样，如果在此异常期间为Matt生成了session_fingerprint异常，可能表明Matt的会话cookie已被泄露。

正如我们之前讨论的，与excessive_downloads、user_agent和ip_address等异常相关的用户代理可以很好地表明正在发生爬取或其他不需要的活动。我们可以通过展示具有意外用户代理的异常来操作这一洞察。