サーバーレスアプリケーションの認証と認可 ～サーバーレスアーキテクチャで何が変わるのか～
サーバーレスアーキテクチャで何が変わるのか
- 2017年公開（2021年改訂）
サーバーレスアーキテクチャで何が変わるのか
- 2022年3月2日公開
Web3層アプリケーションとの比較
- 2022年4月5日（本記事）
サーバーレスアプリケーションの認証と認可
- 2022年5月27日公開
サーバーレスアーキテクチャにおけるバックエンドとバッキングサービス
- 2022年7月27日公開
開発・リリースフローの変化 前編
- 2022年8月24日公開
開発・リリースフローの変化 後編
本技術レポートは、「サーバーレスアーキテクチャで何が変わるのか」の記事の新章となります。
今後続章を追加で公開して参ります。
サーバーレスアプリケーションの認証と認可
AWSのサーバーレスアプリケーションの認証でよく使われるのはAWS Cognitoである。AWS Cognitoは認証に関わる複数の機能を持っている。ここで気にしなければならない概念として認証(Authentication)と認可(Authorization)がある。認証については多くの方が既知であろうが、認可については解説が少ない。
まず、英語の意味の違いに注目してみよう。単語が似ているが、意味は異なる。
| 単語 | 意味 |
|---|---|
| Authentication | 何かが「現実であり、真であり、人々が言うようにそうであること」を証明するプロセス |
| Authorization | 何かが起こることを公式に許可すること、または誰かに何かをすることを公式に許可する行為。 |
表1 単語の意味の違い ※ Cambridge Dictionaryより意訳
AWSではそれぞれ認証と認可と呼ばれ、認証は誰であるかを示す機能であり、認可は権限を公式に許可する機能のことを指す。そして、Cognitoの機能ではユーザープールとIDプールにそれぞれ紐づく。以下に表と図を示す。図はAWS公式ドキュメントの図を意訳したものである。
| 機能名 | 担当 | 説明 |
|---|---|---|
| ユーザープール | 認証 | ユーザーの認証と、AWSネイティブの認証もしくはサードパーティの認証プロバイダへの接続機能を提供し、トークンを発行する |
| IDプール | 認可 | 認証されたトークンを元にアクセスコントロールに基づいたクレデンシャルを発行する |
図2 Cognitoの認証と認可
図3 Cognitoの認証と認可
ここでもだが、サーバーレスアーキテクチャーでは認証と認可の概念がこれまでと異なる。層のような考え方は現れず、特定の組み合せの中でその認証と認可は行われる。後続処理のマネージドサービスAからマネージドサービスBの認証と認可は多くの場合は、マネージドサービスAのIAMロールとそれに紐づけられた権限で行われるため、分割されているところに注目すべきである。例えばLambdaからDynamoDBへのアクセスはLambdaに紐づいたIAMロールで決定され、アプリケーション内部には認証情報は持っていない。
AWSにおける認証と認可はCognitoを経由した一意のユーザーやデバイスなどの認証と、それを経由した特定のリソースへのアクセスの認可、そして特定のリソースから特定のリソースへのIAMロール経由の認証と認可の組み合わせでセキュリティを担保すると考えると理解しやすいかもしれない。また、Kubernetes環境ではサービスアカウントがこのIAMロールに近い役割を担い、Pod間やネームスペース間のアクセス制御を同様に行う。サービスアカウントはAWS EKSにおいてはクラスタ毎に設定が必要である。AWSの認証の仕組みはABACと呼ばれるRBACに近いものである。
乱暴な言い方をすれば従来の考え方の認証はCognitoで吸収され、リソース間の認証はアクセス元のリソースに紐づいたIAMロールで行われるので、2層＋nとも言える。
もちろんアプリケーションとしてユーザーやデバイス単位のユニークなアクセス制御を行いたい場合はCognitoを経由した認証と認可を使うことで、従来のような仕組みを実現できる。また、Cognitoを使うのは必須ではなく、独自に実装したりHashicorp Vaultのようなサードパーティーアプリケーションを利用したりする選択肢もある。ただし、前述の仕組みと組み合わせることで、必要がないところはAWSの機能に委ねることが出来るようになったことが注目すべき点である。
