権限は自然には減らない — 減らす作業は別に必要だ
一言でいうと
権限は、必要なたびに足され、必要が終わってもそのまま残ります。そのため、「誰が何をできるか」は、人の記憶ではなく、アカウント・ロール・権限のデータから計算して出すべき値であり、減らす作業は、誰かが日程を組んで別に行わなければならない作業です。
なぜ必要なのか
納品直後の権限は、たいてい合っています。そのときは、誰が何をするかをみんなが知っていて、ロールも数個しかありません。問題はその次です。夜間作業のために一時的に与えた権限が残り、人が部署を移ると新しいロールが付くのに古いロールは外れず、退職処理は人事システムでだけ起きてアカウントは生きています。1年が過ぎると、誰も全体像を語れなくなります。
エアギャップ環境では、これは単なる衛生の問題ではありません。ネットワークの外に出る道がもともとない場所で、データを外に移せる唯一の通路は、そうする権限を持ったアカウントです。そのため、監査が納品物について尋ねる最初の質問の1つが、アカウント一覧と権限一覧で、2つ目の質問は「その権限はなぜ必要なのか」です。2つ目の質問に答えられない権限は、あってはならない権限です。
公開標準も、同じところを指しています。NIST SP 800-53 Rev 5のアクセス制御ファミリーは、アカウント管理、最小権限、職務分離を、それぞれ別の統制に分けていて、防衛産業の協力会社がよく突き合わせるNIST SP 800-171 Rev 3も、アクセス制御を最初の要求ファミリーに置いています。3つが別々である理由は、3つが互いに代わりになれないからです。アカウントをうまく作っても権限が広ければ意味がなく、権限を絞っても、1人が承認と実行を兼ねれば、承認は形式になります。
どう動くのか
計算の順序は、常に同じです。
1つ目に、有効権限を展開します。アカウントにはロールが付き、ロールは他のロールを継承します。画面に見えるのは「ロール2つ」ですが、実際に持っているのは、継承をすべて展開した権限の和集合です。ここで最初に引っかかるのが、循環継承です。ロールAがBを継承し、BがまたAを継承すると、素朴に組んだ再帰は終わりません。訪問したロールを記憶しながら下りなければならず、そうして展開してみると、2つのロールが、事実上同じ権限の集合だということが現れます。その事実自体が、発見です。
2つ目に、使われていない権限を分けます。持っている権限と、観測期間に実際に使った権限を比べると、一度も使われていない権限が残ります。これは「消してよい権限」と同じ意味ではありません。四半期に1回使う復旧権限は、観測期間には見えないことがあります。そのため、一覧は判定ではなく、質問票として使います。
3つ目に、アカウント側を見ます。最終ログインが基準日から遠くなったアカウント、人事記録に退職として残っているアカウント。ここで必ず守ることが1つあります。基準日を「今日」にすると、同じデータから、昨日と今日で答えが変わります。監査対応の資料で、これは致命的です。基準日はデータに書いておき、その値を使います。
4つ目に、組み合わせを見ます。職務分離は、権限1つ1つではなく、ペアについてのルールです。承認と実行、監査記録の読み取りと削除のように、一緒に持つと統制が無力になるペアを一覧にしておき、有効権限からそのペアを探します。
5つ目に、到達可能なものまで見ます。権限を付与できる権限を持つアカウントは、今持っているものより多くのことができます。自分にロールをもう1つ付ければよいからです。そして、そうして付けたロールが、また別のロールを付与できるなら、もう一歩進みます。1段階だけ見て終えると、最も危険なアカウントを見逃します。これは、グラフを最後までたどる問題です。
現場での姿
ある納品現場で、アカウントの縮小を行ったことがあります。目に付いたのは、管理者アカウントではなく、名前が「移行アカウント」のアカウントでした。移行が終わってから長く、誰も使っておらず、最終ログインは8か月前でした。ところが、そのアカウントに付いたロールは、他のロールを付与でき、そのロールが付与できるロールの1つが、監査記録を削除できました。誰も使っていないアカウントが、事実上最も強いアカウントだったわけです。縮小作業で実際にリスクを減らしたのは、管理者権限を整理したことではなく、そのアカウント1つをなくしたことでした。
もう1つよく見るのは、重複割り当てです。すでに上位のロールを持っている人に、下位のロールが別に付いている場合です。権限は1つも増えないのでリスクは同じですが、一覧を読む人には、ずっとノイズになります。取り消しても有効権限がそのままだということを計算で示せれば、この整理は、議論なしに終わります。
3つ目によく出会うのは、縮小作業が1回で終わると信じることです。権限を減らすことは、掃除ではなく、定期的な作業です。1回減らしても、半年が経つと、同じ一覧がまた膨らんでいます。そのため、縮小の成果物として最も価値があるのは、減らした権限の個数ではなく、その判定を再び回せるスクリプトと基準日データです。次回、同じスクリプトを回して数字を比べれば、その間に何が増えたかが表になって出ます。納品文書に縮小の結果だけを書いて、その計算を残さなければ、半年後の担当者は、最初からやり直しです。
次のラボですること
18個のアカウントと9個のロール、そして3か月分の使用記録で、有効権限を展開し、使われていない権限・休眠アカウント・職務分離違反・権限昇格経路を、順に探します。そのあと、割り当て1つ1つに、取り消しか維持かを決めた縮小案を作り、それを適用した状態で同じ判定をもう一度回して、違反が実際に減ったかを数字で確認します。循環継承と、複数段の昇格経路が混ざっているので、1段階だけを見る実装は、途中で行き詰まります。