【ITニュース解説】One Login Is Not an Access Policy

システム開発において、ユーザーがシステムにアクセスする際の権限管理は非常に重要な要素だ。多くの人が同じログインシステムを使っていたとしても、その役割や立場によって、アクセスできる情報や実行できる操作は大きく異なることがある。例えば、企業の社員とアルバイト、あるいはオンラインコミュニティの一般メンバーと運営スタッフでは、同じシステムを使っても見られる情報やできることが違うのは当然だ。しかし、複数の異なるツールやサービスを一つに統合しようとすると、この細かな権限の違いが見落とされがちになる。

一つのログインシステムがあるだけでは、全てのアクセスに関する問題を解決することはできない。ログインは「誰であるか」をシステムに伝える認証のプロセスに過ぎず、「何ができるか」を制御するアクセス権限のポリシーとは別物だと考える必要がある。権限の設計を適切に行わないと、セキュリティ上のリスクが生じたり、ユーザーが不必要な情報にアクセスできてしまったりする可能性が出てくる。システム開発者は、ユーザーの役割や所属部署、情報の所有権、そして具体的なアクセスルールに基づいて、きめ細やかな権限を設定する必要があるのだ。機密性の高い情報はサーバー側でしっかりと保護し、個人情報のように共有に同意が必要なデータは、その同意に基づいてのみアクセスできるようにする、といった配慮が求められる。

この設計課題は、システムが全体としてつながっているように感じさせつつ、同時に、各ユーザーがなぜシステムの一部しか見ることができないのか、その理由を明確に保つという点にある。最近の例として、GitHubのアプリケーション権限アップデートが挙げられる。以前は、リポジトリの作成には「リポジトリの管理」という広い権限が必要だったが、今では「リポジトリ作成」という、より限定的な権限で対応できるようになった。これは、特定のタスクに必要な権限だけを許可し、それ以外の不要な権限は与えないという方針の良い例だ。例えば、リポジトリの管理権限には削除や移転といった、より強力な操作も含まれるが、作成だけの権限があれば、管理者はリクエストされた機能だけをより正確に評価できるようになる。これはセキュリティの向上だけでなく、製品設計としても非常に有用な判断だと言えるだろう。

これを組織内のアプリケーションに適用するなら、まず行うべきは、それぞれの「行動」に名前をつけることだ。例えば、「自分の利用可能状況を更新する」「誰かをチームに割り当てる」「個人のプライベートな記録を編集する」といった行動は、それぞれ独立した権限として扱うべきだ。単に「スタッフ」という広いカテゴリで権限を付与するだけでは、何ができるのかがあまりにも曖昧になり、適切なアクセス制御が難しくなる。このような設計は、追加の権限名を具体的に定義したり、データベースのスキーマに影響を与えたりする可能性があるが、初期段階でしっかりと検討することが重要だ。

次に、データの保存方法、つまりデータモデルが、プライバシーとアクセス権限にどう影響するかを理解しておく必要がある。Firebaseというデータベースのセキュリティルールに関する資料でも、保存されているデータがアクセスパターンに合致している方が、ルールが理解しやすくなると説明されている。特にFirestoreのようなデータベースでは、セキュリティルールはドキュメント全体を読み取り可能にするか否かを判断する。つまり、一つのドキュメント内に、一部のユーザーには見せたい情報と、他のユーザーには見せたくない機密性の高い情報が混在している場合、セキュリティルールではドキュメント全体を読み取り可能にしない限り、見せたい情報だけを許可し、機密情報を隠すというような細かな制御はできないのだ。クライアントが直接データを読み取る場合、いったんブラウザに渡されたデータを、画面表示から削除したとしても、データそのものがブラウザに渡ってしまっている状態は変わらない。もし、異なる読み取り権限が必要なデータがあるのであれば、それらは個別のドキュメントとして保存し、それぞれに異なるルールを設定するのが望ましい。

ただし、データの「読み取り」権限と「書き込み（変更）」権限は、別々に考えるべき問題だ。Firebaseのガイドでも、ドキュメントの変更前と変更後の状態を比較し、特定のフィールドへの変更のみを許可する、という設定が可能だと説明されている。つまり、あるデータが見えること（読み取り）と、その値を変更できること（書き込み）は、それぞれ独立した意思決定に基づいて設計する必要がある。新しいシステムを設計する際には、プロファイルのスキーマを決める前に、どの情報が一緒に読み取れるべきか、どの更新が本人によって行われるべきか、どの値が他の権限者の承認を必要とするか、といった意思決定を明確にスケッチすることが重要だ。

さらに、ユーザーからのリクエストが実際にどのような経路をたどるのかも、常に意識しておく必要がある。Firebaseのセキュリティルールに関するガイドでは、サーバー側のクライアントライブラリはFirestoreのセキュリティルールをバイパスすると説明されている。これは、サーバーがユーザーに代わって操作を行う場合、そのサーバーが持つ認証情報やIAM（Identity and Access Management）の設定についても、別途注意を払う必要があることを意味する。サーバー側がユーザーの代行として動作する際は、アプリケーションの認証認可の決定をサーバー自身が強制する必要があるのだ。また、セキュリティルールは検索結果をフィルタリングするようには動作しない点も重要だ。例えば、クライアントが全てのドキュメントを検索し、Firestoreが自動的に権限のあるレコードだけを返すことを期待してはいけない。クエリ自体が、関連する制約を満たすように作成されている必要があるのだ。これらの細かい点が実装のレビューに影響を与えるため、クライアントからの直接のリクエストと、サーバーを介したリクエストの経路を別々に辿り、それぞれの経路で適切なポリシーが適用されているかを確認することが不可欠だ。単に画面上のボタンが見えているかどうかだけで、どちらの経路が何を許可しているかを判断することはできない。

最後に、アクセス権限のテストでは、「拒否されるべき人」をテストすることが非常に重要だ。許可されるワークフローが正しく動作することを確認するだけでなく、特定の行動が拒否されるべきユーザーが実際に拒否されることを検証する必要がある。例えば、

• 一般メンバーが、他の人の制限された個人記録に直接アクセスしようとするケース。
• コーディネーターが、自分が管理していないチームの範囲外の操作を試みるケース。
• アクセス権限を削除された元コーディネーターが、同じ操作を再度試みるケース。
• ユーザーが、更新が許可されていない保護されたフィールドを、通常の内容の更新に含めて送ろうとするケース。 このような拒否されるべきシナリオをいくつか用意し、それぞれに対してどのような結果が期待され、どの時点でその拒否が強制されるのかを検証することが重要だ。デモンストレーションデータを使った画面表示が成功したからといって、全てのアクセス権限の特性が検証できたとは限らない。

より精密なアクセス権限を設計することは、より多くのポリシーを定義し、より多くのテストを行い、そして拒否されたユーザーに対してその理由を説明する方法を用意する必要があるため、確かに労力がかかる。過度に例外的なルールは、システムの維持管理を難しくすることもあるだろう。しかし、実際の業務で本当に必要な区別から始めて、具体的なワークフローで必要になったときに、より詳細なルールを追加していくのが賢明だ。

複数のソフトウェアを統合しようとしているチームにとって、GitHubの事例は、アクセス権限の設計が、新機能の開発と同様に進化できるという有用な示唆を与えている。共有のIDによって、何度もログインし直す手間は省ける。しかし、精密なアクセス権限のポリシーがあれば、その利便性を、一人ひとりのユーザーやシステム連携、将来的な自動処理エージェントに同じ権限を与えることなく、より多くのワークフローに広げることができるのだ。