Lambda での属性ベースのアクセスコントロールの使用
属性ベースのアクセスコントロール (ABAC) では、タグを使用して Lambda 関数へのアクセスを制御できます。これらのタグは、Lambda 関数にをアタッチすることや、特定の API リクエストに渡すことができます。あるいは、リクエストを実行する AWS Identity and Access Management (IAM) プリンシパルにアタッチすることも可能です。AWS による属性ベースアクセスの付与の詳細については、「IAM ユーザーガイド」の「タグを使用した AWS リソースへのアクセスの制御」を参照してください。
ABAC を使用すると、IAM ポリシーで Amazon リソースネーム (ARN) または ARN パターンを指定しなくても、最小特権を付与することができます。代わりに、IAM ポリシーの条件要素で、アクセスを制御するためのタグを指定します。新しい関数を作成する際の、IAM ポリシーの更新が必要なくなるため、ABAC を使用するとスケーリングが容易になります。代わりに、新しい関数には、アクセスを制御するためのタグを追加します。
Lambda では、これらのタグは関数レベルで機能します。これらのタグは、レイヤー、コードの署名設定、またはイベントソースマッピングではサポートされていません。関数にタグを付けると、それらのタグは対象の関数に関連付けられているすべてのバージョンとエイリアスに適用されます。関数のタグ付けの方法については、「Lambda 関数でのタグの使用」を参照してください。
関数のアクションは、以下の条件キーを使用して制御できます。
-
aws:ResourceTag/tag-key: Lambda 関数にアタッチされているタグに基づいてアクセスを制御します。
-
aws:RequestTag/tag-key: 新しい関数の作成時などに、リクエスト内のタグを要求します。
-
aws:PrincipalTag/tag-key: IAM プリンシパル (リクエストを行っているユーザー) が実行できる操作内容を、IAM ユーザーまたはロールにアタッチされたタグに基づき制御します。
-
aws:TagKeys: リクエストで特定のタグキーを使用できるかどうかを制御します。
ABAC をサポートする Lambda アクションの完全なリストについては、「サポートされている関数アクション」にアクセスして、表にある [Condition] (条件) 列を参照してください。
次の手順は、ABAC を使用してアクセス許可を設定する方法の一例です。この例のシナリオでは、IAM アクセス許可ポリシーを 4 つ作成しています。その後、これらのポリシーを新しい IAM ロールにアタッチします。最後に、IAM ユーザーを作成し、そのユーザーに、新しいロールを引き受けるためのアクセス許可を付与します。
トピック
前提条件
Lambda の実行ロールが必要です。このロールは、IAM アクセス許可の付与、および Lambda 関数の作成を行う際に使用します。
ステップ 1: 新しい関数のタグを要求する
Lambda で ABAC を使用する場合、すべての関数にタグを付けるようにするのがベストプラクティスです。これにより、ABAC での許可ポリシーが期待どおりに機能することが保証されます。
次の例のような IAM ポリシーを作成します。このポリシーでは、aws:RequestTag/tag-key、aws:ResourceTag/tag-key、および aws:TagKeys 条件キーにより、新しい関数と、その関数を作成する IAM プリンシパルの両方に、project タグが付けられていることを要求しています。ForAllValues 修飾子により、project を唯一許可されているタグとして指定しています。ForAllValues 修飾子含めない場合、ユーザーは project を渡すことで他のタグを関数に追加できるようになります。
例 – 新しい関数のタグを要求する
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "lambda:CreateFunction", "lambda:TagResource" ], "Resource": "arn:aws:lambda:*:*:function:*", "Condition": { "StringEquals": { "aws:RequestTag/project": "${aws:PrincipalTag/project}", "aws:ResourceTag/project": "${aws:PrincipalTag/project}" }, "ForAllValues:StringEquals": { "aws:TagKeys": "project" } } } }
ステップ 2: Lambda 関数と IAM プリンシパルにアタッチされたタグに基づいてアクションを許可する
aws:ResourceTag/tag-key 条件キーを使用して 2 番目の IAM ポリシーを作成し、プリンシパルのタグが関数にアタッチされているタグと一致することを要求します。次のポリシー例は、project タグが付けられたプリンシパルに対し、project タグが付けられた関数を呼び出すことを許可します。他のタグが関数に付けられている場合、このアクションは拒否されます。
例 – 関数と IAM プリンシパル間でタグの一致を要求する
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunction" ], "Resource": "arn:aws:lambda:*:*:function:*", "Condition": { "StringEquals": { "aws:ResourceTag/project": "${aws:PrincipalTag/project}" } } } ] }
ステップ 3: リスト作成のためのアクセス許可を付与する
プリンシパルに対し、Lambda 関数と IAM ロールのリスト作成を許可するポリシーを作成します。これによりプリンシパルは、すべての Lambda 関数と IAM ロールをコンソールに表示でき、API アクション呼び出時に認識できるようになります。
例 – Lambda と IAM に関するリスト作成を許可する
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllResourcesLambdaNoTags", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "iam:ListRoles" ], "Resource": "*" } ] }
ステップ 4: IAM のアクセス許可を付与する
iam:PassRole を許可するポリシーを作成します。このアクセス許可は、関数に実行ロールを割り当てる際に必要となります。次のポリシー例にあるサンプルの ARN は、実際のLambda 実行ロールの ARN に置き換えます。
注記
iam:PassRole アクションでポリシーの ResourceTag 条件キーを使用しないでください。IAM ロールのタグを使用して、そのロールを渡すことができるユーザーへのアクセスを制御することはできません。サービスにロールを渡すために必要となるアクセス許可については、「AWS のサービスにロールを渡すアクセス許可をユーザーに付与する」を参照してください。
例 – 実行ロールを渡すためのアクセス許可を付与する
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::111122223333:role/lambda-ex" } ] }
ステップ 5: IAM ロールを作成する
アクセス許可を委任するためには、ロールを使用することがベストプラクティスです。abac-project-role という IAM ロールを作成します。
-
[ステップ 1: 信頼されたエンティティを選択] で、[AWS アカウント]、[このアカウント] の順に選択します。
-
[Step 2: Add permissions] (ステップ 2: アクセス許可を追加する) で、前のステップで作成した 4 つの IAM ポリシーをアタッチします。
-
[Step 3: Name, review, and create] (ステップ 3: 名前、確認、および作成) で、[Add tag] (タグを追加) を選択します。[Key] (キー) に「
project」と入力します。ここでは、値は入力しません。
ステップ 6: IAM ユーザーを作成する
abac-test-user という IAM ユーザーを作成します。[Set permissions] (アクセス許可の設定) セクションで、[Attach existing policies directly] (既存のポリシーを直接アタッチ) を選択し、次に [Create policy] (ポリシーを作成) を選択します。ポリシーの定義を以下のように入力します。111122223333 の部分は、自分の AWS アカウントID に置き換えます。このポリシーでは、abac-project-role を引き受けることを abac-test-user に対し許可します。
例 – ABAC ロールを引き受けることを、IAM ユーザーに対し許可する
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/abac-project-role" } }
ステップ 7: アクセス許可をテストする
-
AWS コンソールに、
abac-test-userとしてサインインします。詳細については、「IAM ユーザーとしてサインインする」を参照してください。 -
abac-project-roleロールに切り替えます。詳細については、「ロールの切り替え (コンソール)」を参照してください。 -
-
[Permissions] (許可) で [Change default execution role] (デフォルトの実行ロールの変更) を選択した後、[Execution role] (実行ロール) で [Use an existing role] (既存のロールを使用する) を選択します。ステップ 4: IAM のアクセス許可を付与する で使用したものと同じ実行ロールを選択します。
-
[Advanced settings] (詳細設定) で [Enable tags] (タグを有効化) を選択した上で、[Add new tag] (新しいタグを追加) を選択します。[Key] (キー) に「
project」と入力します。ここでは、値は入力しません。
-
-
2 つ目の Lambda 関数を作成し、異なるタグ (例:
environment) を追加します。通常、この操作は失敗します。ステップ 1: 新しい関数のタグを要求する で作成した ABAC ポリシーでは、projectタグが付いた関数を作成することのみをプリンシパルに許可しているためです。 -
タグを付けずに 3 つ目の関数を作成します。通常、この操作も失敗します。ステップ 1: 新しい関数のタグを要求する で作成した ABAC ポリシーでは、タグなしの関数を作成することをプリンシパルに許可していないためです。
この認証戦略により、それぞれの新しいユーザーに新しいポリシーを作成することなく、アクセスの制御が可能になります。新しいユーザーにアクセス権を付与する際は、割り当てられたプロジェクトに対応するロールを引き受けるための、アクセス許可を付与するだけですみます。
ステップ 8: リソースをクリーンアップする
IAM ロールを削除するには
IAM ユーザーを削除するには
Lambda 関数を削除するには
-
Lambda コンソールの関数
ページを開きます。 -
作成した関数を選択します。
-
[アクション] で、[削除] を選択します。
-
テキスト入力フィールドに
deleteと入力し、[Delete] (削除) を選択します。
