全員を管理者にしないために。必要な操作から考えるアクセス権限

「ログインできる人」と「何でも変更してよい人」は同じではありません。閲覧、編集、公開、削除を分け、必要な対象と期間に絞って考えると、仕事を進めながら余分な権限を減らしやすくなります。

本人確認と、操作の許可は別の段階

認証は誰であるかを確かめること、認可はその人に何を許すかを判断することです。本人としてログインできても、すべてのデータを閲覧・変更してよいとは限りません。

OWASPの認可ガイドは、仕事に必要な最小限の権限を与える原則を説明しています。同じ役職でも担当する情報が違えば、必要なアクセス範囲が異なるという考え方です。

「担当者」「管理者」といった役割名だけでは、実際に許される操作が見えにくいことがあります。先に作業を書き出し、そのあとで役割にまとめると、名前の印象に頼らずに済みます。

たとえば、架空の社内マニュアルを管理する場面を考えてみましょう。読む人、原稿を書く人、内容を確認して公開する人では、必要な操作が違います。

表が見切れる場合は横にスクロールできます

この表は説明用の一例です。すべての組織が四つの役割に分ける必要はありません。少人数でも「文章を直すために、利用者の権限管理まで必要か」と考えると、範囲を整理できます。

対象の範囲も重要です。一つの案件を担当するために、別の顧客の案件まで読める必要があるとは限りません。操作の種類と、操作できるデータを組にして見ると、過剰なアクセスに気付きやすくなります。

利用者に不要なボタンを見せないことは、使いやすさに役立ちます。しかし、画面を隠すことと、サーバーが操作を拒否することは別です。

OWASPの同ガイドは、初期状態では許可しない設計と、リクエストごとの権限確認を勧めています。ページを開いたときだけ確認するのではなく、実際の読み取りや変更の時点で対象の権限を確かめる必要があります。

運営者が確認を依頼するなら、「編集できる人が編集できたか」に加え、「閲覧だけの人は変更できないか」も条件に含めるとよいでしょう。許可された操作と拒否される操作の両方を見ることで、役割名と実際の動作を照合できます。

権限は付与した時点では適切でも、担当変更や契約終了のあとには不要になることがあります。一時的な応援で追加した権限が、そのまま残る場合もあるでしょう。

見直しのきっかけを、入社・異動・案件終了などの出来事に結び付ける方法が考えられます。誰が、何のために、いつまで必要と判断したかを残すと、削除してよいか話し合う材料になります。

外部サービスとつなぐアプリにも同じ視点を使えます。人のアカウントだけでなく、連携が読み取れる対象や実行できる操作も、必要な用途に合っているかを確認します。

アクセス権限は、仕事、操作、対象データから考えると具体的になります。画面上の見え方と実際の許可を分け、担当が変わるタイミングで範囲を見直すことが、無理のない管理につながります。

外部アプリへ許可する範囲は、OAuthのアクセス許可の基本で説明しています。