最小権限の原則を SaaS の共有アカウントに当てはめる

最小権限の原則を SaaS(インターネット経由で使う業務ソフト)に当てはめてみます。人ごとに、その仕事に要る権限だけを、要る間だけ渡す形になります。共有アカウントではこの形が成り立ちません。権限が ID に付いていて、一組の ID とパスワードを知る人全員に同じ権限が渡るためです。共有アカウントの定義は共有アカウントとはにあります。

共有アカウントで最小権限が成り立たない理由

米国 NIST の用語集は、SP 800-53 Revision 5 の定義を載せています。最小権限とは、各主体(entity)にその働きに必要な最小限の資源と権限だけを与えるよう設計する原則です。CNSSI 4009 の定義では、利用者のアクセス権限を、割り当てられた作業に必要な最小限に制限する原則です。どちらも、権限を絞る単位は「主体」や「利用者」です。

SaaS の権限は、利用者ではなく ID に付きます。一人一つの ID なら、ID を絞ることが人を絞ることと同じになります。共有アカウントでは、ID が一つで使う人が複数です。ID の権限を絞っても、その権限は知っている人全員に同じだけ渡ります。閲覧しかしない人にも、管理者の権限が渡ることになります。Microsoft Entra ID の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか、誰がアクセスしたかが分からないこと。外すには変えて配り直すしかないことです。

IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、ID の発行から削除までを管理する手続を定めるよう勧めています。付ける権限は必要最小限にします。共有 ID はなるべく使わないことも勧めています。やむを得ず使う場合は、共有 ID を利用した人を特定できる仕組みを整え、規定のとおりに運用します。

先に SaaS 側の権限の種類で分ける

したがって最初に行うのは、共有をやめて個人の ID に分け、ID ごとに権限の種類を選ぶことです。業務向けの SaaS の多くは、権限の種類を人ごとに割り当てられます。Google アナリティクスの公式ヘルプは、5 つの役割を挙げています。

役割はアカウントとプロパティの単位で人ごとに割り当て、上位で付けた役割は下位に引き継がれます。費用や収益の数字を見せないデータ制限も、役割とは別に付けられます。このように分けられるサービスでは、担当者ごとに「何をする人か」を書き出します。その作業ができる一番低い役割を選び、管理者の役割は少人数に限ります。媒体ごとの権限の分け方は、Meta のビジネスポートフォリオ、Google 広告の MCC、Shopify・BASE のスタッフ権限の記事にまとめています。

分けられないアカウントも残ります。アカウントを一つしか持てないサービス、SNS の公式アカウントそのもの、一つしかない管理者アカウントなどです。どれが当てはまるかの整理は共有アカウントを個人アカウントに分けられないケースの整理にあります。

共有が残る部分で代わりに絞る 3 つ

共有が残るアカウントでは、権限の種類の代わりに、次の 3 つで絞ります。

使える人の一覧

そのアカウントを使ってよい人を名前で決め、一覧にします。パスワードを知る人は、それより少なくします。権限の種類は絞れなくても、権限を持つ人の数は絞れます。IPA が勧める、必要最小限の割り当てに当たります。

期間

担当の間だけ使えるようにし、担当が終わった日に外します。委託なら契約の終了日です。使わなくなった人に権限が残る状態をなくすためで、IPA が挙げる、異動・退職に伴う削除漏れを防ぎます。

記録

誰がいつ使ったかを、サービス側の記録とは別に残します。サービス側の記録には、共有アカウントの名前しか残らないためです。IPA が勧める、利用した人を特定できる仕組みに当たります。

3 つのうち「使える人の一覧」は、パスワードを知らなくても使える手段があるときに、知る人より広くできます。手段がなければ、使える人とパスワードを知る人は一致します。一人が担当を外れるたびに、パスワードを変えて残る全員に配り直すことになります。この一覧と知る人を切り離す手段は 2 つあります。ID 管理サービス(Okta や Microsoft Entra ID など)の代理入力と、パスワードを見せずに代わりに入力する仕組みです。方法ごとの違いは共有アカウントを複数人で安全に使う方法の比較にあります。

見直しの手順

IPA のガイドラインは、異動や退職に伴う権限の変更・削除漏れと、特定の人への権限の集中による不正利用や権限の濫用を、防ぐべき被害として挙げています。そのために、事業所やフロアの入室とシステムのアクセス権限を見直すルールを定め、付与の状況を管理するよう勧めています。運用や利用状況を監視する仕組みを整えることも挙げています。このうちシステムのアクセス権限について SaaS に当てはめると、手順は 4 つです。

1. サービスごとに、個人の ID とその役割、共有アカウントとその使える人の一覧を作る。一覧の作り方は共有アカウントの棚卸しの手順と台帳の項目にあります。
2. 一人ずつ、その役割や共有アカウントがいまの作業に要るかを見て、要らないものを外す。
3. 記録を見て、一定期間使っていない人を一覧から外す。使っていない権限は、要らない権限の候補です。
4. 入退社と担当交代のたびに当てはまる行を更新し、それとは別に全件を見直す日を決める。IPA のガイドラインは周期を定めていないため、会社が決めます。

管理者用アカウント(強い権限を持つ ID)は、同じ考え方をより厳しく当てはめる対象です。扱いは特権 ID(管理者用アカウント)とはにまとめています。