第八章　熟悉的账号，也可能正在被别人使用

案例与证据

纽约州金融服务局对 2020 年 Twitter 事件的调查报告认为，攻击者冒充内部技术支持，诱骗员工并取得内部工具权限。部分知名账号随后被用于发布比特币诈骗消息。报告记录的入侵与发帖范围不同，不能把“遭访问”全部写成“被公开发帖”。纽约州金融服务局调查报告，S15

从中看见的机制

一个账号有多年历史，头像也熟悉，这些信息能支持“它过去是谁的账号”，却不足以单独保证“现在这条消息仍由本人发出”。

同样，一个人说得出单位名称和你的岗位，只说明他掌握了这些信息，不自动取得技术支持权限。

日常应用

熟人账号突然要求转款、提供验证码或安装软件时，回到以前已经核实的联系方式。不要由可疑消息为你指定“另一个更方便的核实人”。

小团队可以把协作权限拆开：看稿、编辑、发布、付款、修改账户设置，分别由谁负责？临时合作结束后，哪些权限要收回？如果平台允许分角色，就尽量避免共享一个拥有全部权限的账号。

这些安排不等于怀疑合作者。它们使每个人的职责更清楚，也使某个账号出问题时，不必连带失去整个项目。

一个虚构的工作室练习

一位外部剪辑师需要下载三段素材。负责人可以给指定文件的访问权，设置适当期限；不必因此把整个云盘的管理权和付款资料一起交出。

练习的重点在于检查“完成这项工作，实际需要什么”。如果权限划分太细，已经妨碍正常工作，就重新设计；一味增加麻烦并不等于更安全。

练习： 查看一项仍在进行的共享协作。确认对方确实需要的范围，并检查已经结束的合作是否还保留不必要的权限。变更前告知受影响的人，避免误伤工作。