3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS Verified Permissionsで認可機能を実装したら思ったより便利だった

3
Last updated at Posted at 2025-12-22

1. はじめに

認証認可機能をAWSで実装しようと検討した際に、AWS Verified Permissionsを使うと認可周りを簡単に作成できたので概要をまとめます。


2. AWS Verified Permissionsとは

AWS Verified Permissionsは、アプリケーションのきめ細かな認可を実現するマネージドサービスです。このサービスを使うと認可を外部化し、ポリシーのマネジメントを一元化することができます。

主な特徴

  • Cedar Policy Language: Amazonが開発したオープンソースのポリシー言語を使用
  • 宣言的な認可管理: コードではなくポリシーで認可ロジックを記述
  • ビジネスロジックからの分離: 認可ロジックをアプリケーションコードから切り離して管理
  • 複数のIDプロバイダー対応: Amazon CognitoやOIDC準拠のIDプロバイダーと統合可能

認可の仕組み

Verified Permissionsは、以下の3つの要素で認可判断を行います。

  1. Principal(プリンシパル): 誰が(ユーザー、グループ)
  2. Action(アクション): 何を(API操作、リソースアクセス)
  3. Resource(リソース): どのリソースに対して

これらの要素をCedarポリシーで定義し、リクエスト時に評価してAllowまたはDenyを返します。


3. AWS Verified Permissionsがやってくれること

1. ロールベースアクセス制御によるきめ細かなアクセス制御

ロールベースアクセス制御(RBAC)によって、ユーザ―ごと、グループごとにアクセス制御することができます。また、属性ベースアクセス制御(ABAC)も可能で、同じグループに所属しているユーザーでも、カスタム属性の値に基づいて異なる権限を付与するといった、よりきめ細かいアクセス制御も可能です。

2. API Gatewayとの統合

API-linked policy storeを使用することで、API GatewayとVerified Permissionsを簡単に統合できます。起動オプションAPI GatewayとIDプロバイダーによるセットアップを選択し、設定を進めていくと、Cedarスキーマ、基本的なポリシーが自動生成されます。

image.png

3. API Gatewayに紐づけるLambdaオーソライザーの自動作成

API-linked policy storeを作成すると、Verified Permissionsと連携するLambdaオーソライザーも自動的に生成され、API Gatewayに設定されます。手動でのLambdaオーソライザー実装が不要になります。

4. トークン検証

IsAuthorizedWithToken APIを使用することで、JWTトークンの署名検証と有効期限チェックを自動で実行してくれます。
IsAuthorizedWithTokenはLambdaオーソライザーから呼び出します)

個人的に3、4がとても便利で、Lambdaオーソライザーでトークン検証や認可判定ロジックを実装する必要がなくなり、大幅に開発工数を削減できました。


4. 実装した認証認可のフロー

アーキテクチャ図

処理の流れ

ステップ1: ユーザー認証

クライアントがCognito User Poolで認証を行い、トークンを取得します。

IDトークンに含まれる情報:

{
  "sub": "user-id",
  "cognito:groups": ["user"],
  "custom:role": "editor",
  "email": "user@example.com"
}

ステップ2: API リクエスト

クライアントがAuthorizationヘッダーにトークンを含めてAPI Gatewayにリクエストを送信します。

GET /user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

ステップ3: Lambdaオーソライザーの実行

API GatewayがLambdaオーソライザーを呼び出し、トークンとリクエスト情報を渡します。

ステップ4: Verified Permissionsでの認可判断

LambdaオーソライザーがIsAuthorizedWithToken APIを呼び出します。

リクエスト例:

{
  "policyStoreId": "policy-store-id",
  "identityToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "action": {
    "actionType": "Action",
    "actionId": "GET /user/profile"
  },
  "resource": {
    "entityType": "Application",
    "entityId": "MyAPI"
  }
}

Verified Permissionsは以下を実行します:

  1. トークン検証: IDトークンの署名と有効期限を検証
  2. ポリシー評価: Cedarポリシーに基づいて認可判断

レスポンス例:

{
  "decision": "ALLOW",
  "determiningPolicies": [
    {
      "policyId": "policy-id-123"
    }
  ]
}

ステップ5: IAMポリシーの返却

LambdaオーソライザーがVerified Permissionsの判断結果(ALLOW / DENY)に基づき、ALLOWの場合にIAMポリシーを生成し、API Gatewayに返却します。

Allow時のポリシー:

{
  "principalId": "user-id",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow",
        "Resource": "arn:aws:execute-api:region:account:api-id/stage/method/path"
      }
    ]
  }
}

ステップ6: バックエンドへのリクエスト転送

API Gatewayが認可されたリクエストをバックエンドに転送し、レスポンスをクライアントに返します。


Cedarポリシーの例

ポリシー1: adminグループの権限

全アクセス許可

permit(
  principal in UserGroup::"admin",
  action,
  resource
);

ポリシー2: editorロールを持つuserグループの権限

GET /user/*POST /user/*POST /reportsに対してアクセス許可

permit(
  principal in UserGroup::"user",
  action in [
    Action::"GET /user/*",
    Action::"POST /user/*",
    Action::"POST /reports"
  ],
  resource
)
when {
  principal.role == "editor"
};

ポリシー3: 一般userグループの権限(role属性を持っていないか、role属性が空文字列の場合)

GET /user/*に対してのみアクセス許可

permit(
  principal in UserGroup::"user",
  action in [
    Action::"GET /user/*"
  ],
  resource
)
when {
  !principal has role || principal.role == ""
};

同じグループに所属していても、カスタム属性(例ではrole)によってよりきめ細かいアクセス制御ができます。


5. まとめ

Lambdaオーソライザーとの比較(実装の複雑さ)

項目 Lambdaオーソライザー Verified Permissions
セットアップ 手動でLambda関数を作成 ウィザードで自動生成
認可ロジック コードで実装 Cedarポリシーで宣言的に記述
トークン検証 コードで実装(JWKSの取得・検証) 自動で実行(LambdaオーソライザーがIsAuthorizedWithTokenAPIを呼び出す)
ポリシー管理 コード内にハードコード ポリシーストアで一元管理

結論

AWS Verified Permissionsは、きめ細かな認証認可のアクセス制御が必要なアプリケーションにおいて、認可機能の開発コストを削減できるAWSマネージドサービスであることが分かりました。宣言的なポリシー記述により認可ロジックが明確になり、保守性が向上します。

所感

良かった点:

  1. セットアップが簡単: マネジメントコンソール数クリックで認可機能を実装可能
  2. 変更が容易: コードのデプロイなしでポリシーの更新が可能
  3. Lambdaオーソライザー作成不要: AWS Verified Permissionsが自動で作成

Lambdaオーソライザーで複雑なコードを実装することなく、適切なアクセス制御ができる認可機能を作成することができました。

注意点:

  1. Cedar言語の学習: 新しい言語の習得が必要

参考資料

公式ドキュメント

Cedar Policy Language

その他

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?