没人用的那个账号，其实权限最大

目标

从账户、角色、权限数据中展开有效权限，找出未被使用的权限、休眠账户、职责分离违规和权限提升路径，制定精简方案，然后在应用之后重新判定，用数字表明违规减少了。

为什么重要

权限清单随着时间推移，会变成没有人能解释的状态。在隔离网络中，把数据搬到外部的唯一通道就是拥有这种权限的账户，所以这份清单就是导出路径的清单。因此监理方会问“谁能做什么”，而答案必须从数据中计算得出，而不是靠记忆。本实验中困难的部分不是规则，而是结构。如果角色继承出现循环，朴素的递归就停不下来；而可以授予权限的账户，只追一步就会漏掉实际能到达的范围。

步骤

1. 用 python3 在 /root/least/data 中创建六个数据文件。直接使用生成脚本。
2. 把展开继承后每个账户的有效权限写入 /root/least/effective.json，把互相继承的两个角色写入 /root/least/cycle.txt。
3. 把拥有的权限中在观测期间没有被使用的，以 account_id,perm 的格式写入 /root/least/unused.csv。
4. 把以基准日计算未登录达 90 天以上、或带有离职标记的账户，以 account_id,days_idle,reason 的格式写入 /root/least/dormant.csv。
5. 把在有效权限中违反职责分离规则的配对，以 account_id,rule_id,perm_a,perm_b 的格式写入 /root/least/sod.csv。
6. 把可以通过自己追加角色而到达的额外权限，按账户写入 /root/least/escalation.json。
7. 为每项分配确定撤销或保留以及原因，以 account_id,role,action,reason 的格式写入 /root/least/plan.csv。
8. 把应用了精简方案的分配留在 /root/least/after/assignments.csv，把比较前后数量的报告留在 /root/least/after/report.json。

参考

• 基准日在 /root/least/data/asof.txt 中。如果用 date 取今天，同样的数据每天都会得出不同的答案。
• 职责分离规则和休眠基准天数在 /root/least/data/policy.json 中。不要把数字写死在代码里，而要从该文件中读取。
• 展开继承时，要一边记住已经访问过的角色，一边向下走。否则会出现 RecursionError。
• 第 7 步中的“该项分配单独给出的权限”，是去掉该项分配后会消失的权限。如果其他角色已经给出了同样的权限，那么这项分配就没有给出任何东西。
• 常见错误 1：在第 6 步只追一步。被授予的角色可能还能授予其他角色。
• 常见错误 2：在第 8 步覆盖原来的分配文件。必须保留应用之前的数据，才能比较前后。
• 标准文档：NIST SP 800-53 Rev 5、NIST SP 800-171 Rev 3。本实验的规则编号（如 SOD-01）不是标准的控制项编号，而是只在数据中使用的合成编号。

创建判定所用的数据

用 python3 在 /root/least/data 中创建 accounts.csv、roles.json、assignments.csv、usage.csv、policy.json、asof.txt 六个文件。直接使用不含随机数的生成脚本。

隔离网络里没有可以下载的样本，所以先亲自创建数据。不使用随机数，才能保证无论谁运行多少次，得到的数据都相同，彼此的判定才能比对。评分器会把文件内容转换成标准形式并核对指纹，所以如果手工修改数据，后面的步骤会全部被卡住。

展开继承，看账户实际握有什么

在 /root/least/effective.json 中写入每个账户的有效权限清单，在 /root/least/cycle.txt 中写入互相继承的角色名称，每行一个。

角色继承其他角色，而继承是多级的。如果不记住已经访问过的角色，递归就不会结束——而这个事实本身，就是在这份数据中要找的东西之一。两个角色互相继承时，二者的有效权限相同。

统计拥有却从未使用的权限

在 /root/least/unused.csv 中，第一行写 account_id,perm，把有效权限中没有出现在 usage.csv 里的，每行一个写入。

使用记录是账户与权限的配对。从有效权限集合中减去已使用的权限集合，剩下的就是答案。请记住，这份清单不是判定，而是问卷——每个季度只用一次的权限，在观测期间是看不到的。

按基准日区分休眠账户

在 /root/least/dormant.csv 中，第一行写 account_id,days_idle,reason，写入以基准日计算的未登录天数达到 policy.json 的基准以上、或者状态为 terminated 的账户。原因是 미접속、퇴직、미접속+퇴직 之一。

基准日在 asof.txt 中。如果使用今天的日期，同样的数据昨天和今天的答案就不同，无法作为审计材料。天数是基准日减去最后登录日期得到的天数，如果两个原因重叠，就两个都写。

找出不能同时拥有的权限配对

在 /root/least/sod.csv 中，第一行写 account_id,rule_id,perm_a,perm_b，针对 policy.json 中的每条规则，写入同时拥有这两个权限的账户。

规则针对的不是一个权限，而是一对权限。有效权限集合中同时有 a 和 b，就是违规。不要把规则编号写死在代码里，而要遍历 policy.json 来判定——规则增加了，代码也应保持不变。

追踪到自己能够扩大的权限

在 /root/least/escalation.json 中，按账户写入现在没有、但可以通过自己追加角色而到达的权限清单。没有可额外获得内容的账户不要放入。

持有可以授予权限的权限的账户，可以给自己附上角色。如果这样附上的角色又能授予其他角色，就再往前走一步。重复到没有可再附加的角色为止，然后从到达的权限中减去原本拥有的权限。

为每项分配确定撤销还是保留

在 /root/least/plan.csv 中，第一行写 account_id,role,action,reason，每项分配各写一行。action 是 revoke 或 keep，reason 是 휴면、중복、미사용、사용 之一。

判定顺序会改变结果。如果是休眠账户，不必追究原因，全部撤销。然后，如果该项分配单独给出的权限一个也没有，就是重复；如果有，但一个也没有被使用，就是未使用。其余的是保留。

应用之后重新判定，看是否减少

把应用了精简方案的分配留在 /root/least/after/assignments.csv 中，并在 /root/least/after/report.json 中写入 assignments_before、assignments_after、sod_before、sod_after、unused_before、unused_after、escalation_before、escalation_after、dormant 九个数。

原始数据保持不动，把应用的结果写入新文件。这样才能比较前后，再次评分时也会得到同样的结果。报告中的数不要手工统计，而要用与前面步骤相同的函数，对应用之后的分配重新计算——评分器也做同样的计算。