アプリケーションの認可をシンプルに

はじめに

みなさん、はじめまして。
jinjerプロダクト開発部に所属している玄です。

今回は、最近興味を持った記事を通じて学んだ「認可」についてお話しします。

認可の話を始める前に、よく似た言葉として「認証」がありますね。
そもそも、認証（Authentication） と 認可（Authorization） とは何でしょうか？

認証と認可

認証とは？
認証とは、ユーザーが本人であることを確認するプロセスです。つまり、「あなたは誰か？」を確かめることを指します。

認証の主な方法には、以下のようなものがあります。

本人確認
パスワード、指紋、顔認識、スマートカードなどを利用し、ユーザーが主張するIDを確認する。

多要素認証（MFA）
より高いセキュリティを実現するため、複数の要素を組み合わせてIDを確認する。（例 パスワード＋SMSコード）

認可とは？
認可とは、認証されたユーザーがどのリソースにアクセスできるか、あるいはどの操作を実行できるかを決定するプロセス です。つまり、「あなたには何ができるのか？」を判断することを指します。

このアクセス制御では、ユーザーに対するアクセス許可を設定し、リソースやデータに対する操作（読み取り、書き込み、削除など）を制限します。

認可について

ここからが本題の「認可」についてです。

アプリケーションにおける 認可（Authorization） は、複雑になりがちです。
認可は、単に本人確認をおこなう 認証（Authentication） とは異なり、
「だれが、どのリソースに対して、どの操作を実行できるのか」 を定義する必要があります。

このように複雑な認可ルールをアプリケーションコードのさまざまな場所に組み込むと、何が許可され、何が拒否されるのかが分かりにくくなる可能性があります。さらに、ビジネスの成長とともに認可ルールはますます複雑化していきます。

この問題を解決する方法がないか、認可におけるアクセス制御の手法 について調査しました。

認可のアクセス制御

認可におけるアクセス制御には、以下のような手法があります。

ロールベースアクセス制御（RBAC Role-Based Access Control）

ユーザーの役割や権限に基づいてアクセス許可を与える方式です。
例えば、「管理者」「一般ユーザー」「ゲスト」などの権限を定義し、それぞれに適切なアクセス権を付与します。

属性ベースアクセス制御（ABAC Attribute-Based Access Control）

ユーザーや環境、リソースの属性に基づいてアクセスを制御する方式です。
この方法では、ユーザーが特定のリソースにアクセスするために必要な条件を満たしているかどうか を、属性をもとに判断します。

関係ベースアクセス制御（ReBAC Relationship-Based Access Control）

ユーザーやリソース間の関係に基づいてアクセスを制御する方式です。
ソーシャルネットワークやコラボレーションツールでよく利用されます。

例えば、Facebookの「友達」関係をもとに、特定の情報を共有する仕組みなどが該当します。
関係性を考慮することで、より直感的で柔軟なアクセス制御が可能になります。

ポリシーベースアクセス制御（PBAC Policy-Based Access Control）

ポリシー（方針）に基づいてアクセスを管理する方式です。
組織の セキュリティポリシーやコンプライアンス要件に従ってポリシーを定義し、それに基づいてアクセスを制御します。

これらのアクセス制御手法は、単独で利用するだけでなく、組み合わせて運用も可能 です。

このような認可ルールの複雑化を解決する手段の１つに、AWS（Amazon Web Services）が提供する Amazon Verified Permissions というサービスがあります。

Amazon Verified Permissions

Amazon Verified Permissions は、アクセス制御および認可管理サービスです。
アプリケーションの きめ細やかな認可ポリシーを一元管理し、判断結果を返すことができます。

利点

1. きめ細かいアクセス制御が可能
   RBAC（ロールベース）、ABAC（属性ベース）、ReBAC（関係ベース）を組み合わせた 複雑な認可ルールを柔軟に設定可能。

2. ポリシー管理の一元化
   認可ルールを一元管理できるため、アプリケーションのコードに分散せず、保守性が向上する。

3. スケーラブルなアクセス制御
   大規模なシステムでもパフォーマンスを維持しながら動作でき、ユーザー数やリソース数が多いアプリケーションにも適用しやすい。

4. Cedarポリシー言語の採用
   人間が理解しやすいシンプルな構文の Cedar を利用し、ポリシーの定義やテストがしやすい。

欠点

1. AWSに依存する
   AWSのサービスなので、AWS以外の環境（オンプレミスやほかのクラウド）との統合が難しい場合がある。

2. 料金が発生する
   リクエスト数に応じた従量課金制のため、トラフィックが多いシステムではコストが増加する可能性がある。

3. Cedarの学習コスト
   Cedarポリシー言語を知る必要があり、学習コストがかかる。

結論

アプリケーションの複雑化した認可ルールを一元管理したい場合、Amazon Verified Permissions は有力な選択肢の1つです。特に、マイクロサービスやマルチテナント環境でのきめ細かいアクセス制御を実現したい場合にメリットがあると思います。
ただし、運用コスト・学習コスト・AWS依存度 を十分に考慮しながら導入を進める必要があります。

今後、このサービスの実用性を検証するとともに、ほかのサービスについても調査を進めたいと思います。興味を持たれた方は、ぜひ関連記事をご覧ください。