离职之后，谁都不该还留着权限

离职员工的账号还能登录，是最常见、也最容易避免的一种安全事故。解决办法很朴素：一份清单，每次都当天做完。

正在加载工具……

工作原理

选择“leaving”（离职）还是“changing role”（调岗），然后勾选在用的平台 —— 从 Google Workspace 到 kintone、freee、Chatwork，再到门禁卡。
按清单逐条执行：收到离职通知时、最后一天、24 小时内、一周内、30 天内分别要做什么，每一条都标着责任人。
打印带勾选框的版本，或者导出 Markdown/CSV 到你们的工单系统里。

这个页面上的每一步操作，都由运行在你浏览器标签页里的代码完成，用的就是渲染网页的那套引擎。文件从磁盘读进标签页的内存，在那里被处理，再作为下载写回去。它不会被送到任何地方 —— 不会送给我们，也不会送给第三方。

打开浏览器的开发者工具（F12），选择“网络”（Network）面板。
载入你的文件，运行这个工具。
你能看到的请求只有这些：工具自己的代码 —— 少数几个重型工具还会从公共 CDN 取它们的开源引擎 —— 外加一条发往 loreatec.jp 的小小访问记录（页面地址和标题，仅此而已）。没有一条带着你的文件。

为什么最后一天写的是“停用，而不是删除”？

因为邮箱和文件通常还要用于交接，其中一些可能还受留存规定约束。停用登录、撤销会话和令牌，能立刻消除风险；删除是之后的事，安排在 30 天那部分，是一个经过考虑的动作。

为什么要轮换共享密码 —— 是不是太过谨慎了？

这恰恰是最容易被漏掉的一项。Wi-Fi 密钥、社交媒体登录、供应商门户和服务账号的密码，凡是用过的人都知道；停用个人账号对这些完全没用。真正把门关上的，是把这些密码都换掉。

涵盖日本本地的工具吗？

涵盖 —— Chatwork、LINE WORKS、freee、マネーフォワードクラウド、kintone、Sansan 和虚拟主机管理面板，都和 Google Workspace、Microsoft 365、Slack 以及各家云控制台一起列在清单里，每一项的步骤都按各自的管理方式来写。

调岗（部门转岗）也能用吗？

选“changing role”（调岗）：清单的重点会变成清理旧权限，而不是清理这个人 —— 旧的共享盘、频道和管理员角色都要处理掉，账号本身则继续使用。“留着以防万一”的权限，正是权限不断累积失控的原因。