AWS Lambda
開発者ガイド

AWS Lambda のアイデンティティベースの IAM ポリシー

Lambda へのアクセス権をアカウントのユーザーに付与するには、AWS Identity and Access Management (IAM) のアイデンティティベースのポリシーを使用できます。アイデンティティベースのポリシーは、ユーザーに直接適用するか、ユーザーに関連付けられているグループおよびロールに適用することができます。または、アカウントのロールを引き受け、Lambda リソースにアクセスするためのアクセス許可を別のアカウントのユーザーに付与することもできます。

Lambda には、Lambda API アクションへのアクセス権、場合によっては、Lambda リソースの開発および管理に使用する他のサービスへのアクセス権を付与する管理ポリシーがあります。Lambda では、新機能がリリースされたときにユーザーがアクセスできるように、必要に応じて、管理ポリシーを更新します。

  • AWSLambdaFullAccess – Lambda リソースの開発および保守管理に使用する AWS Lambda アクションおよび他のサービスへのフルアクセスを付与します。

  • AWSLambdaReadOnlyAccess – AWS Lambda リソースへの読み取り専用アクセスを付与します。

  • AWSLambdaRole – 任意の Lambda 関数を呼び出すアクセス許可を付与します。

管理ポリシーでは、ユーザーが変更できる関数やレイヤーを制限することなく、API アクションへのアクセス許可を付与します。きめ細かな制御では、ユーザーのアクセス許可の範囲を制限する独自のポリシーを作成することができます。

関数の開発

範囲を制限したアクセス許可ポリシーの例を以下に示します。このポリシーでは、ユーザーは、名前に指定されたプレフィックス (intern-) が付いており、指定された実行ロールで設定された Lambda 関数を作成および管理することができます。

例 関数の開発ポリシー

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ReadOnlyPermissions", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "iam:ListRoles" ], "Resource": "*" }, { "Sid": "DevelopFunctions", "Effect": "Allow", "NotAction": [ "lambda:AddPermission", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:*:*:function:intern-*" }, { "Sid": "DevelopEventSourceMappings", "Effect": "Allow", "Action": [ "lambda:DeleteEventSourceMapping", "lambda:UpdateEventSourceMapping", "lambda:CreateEventSourceMapping" ], "Resource": "*", "Condition": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } } }, { "Sid": "PassExecutionRole", "Effect": "Allow", "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" }, { "Sid": "ViewExecutionRolePolicies", "Effect": "Allow", "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*" }, { "Sid": "ViewLogs", "Effect": "Allow", "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*" } ] }

ポリシーのアクセス許可は、アクセス許可でサポートされているリソースおよび条件に基づき、ステートメントに整理されます。

  • ReadOnlyPermissions – Lambda コンソールでは、関数を参照および表示する場合に次のアクセス許可を使用します。リソースパターンや条件はサポートされていません。

    "Action": [ "lambda:GetAccountSettings", "lambda:ListFunctions", "lambda:ListTags", "lambda:GetEventSourceMapping", "lambda:ListEventSourceMappings", "iam:ListRoles" ], "Resource": "*"
  • DevelopFunctions – プレフィックス intern- が付いた関数で動作する Lambda アクションを使用します (AddPermission および PutFunctionConcurrency除く)。AddPermission では、関数のリソースベースのポリシーが変更されるため、セキュリティへの影響が生じる可能性があります。PutFunctionConcurrency では、関数のスケーリングキャパシティーを予約するため、他の関数にキャパシティーが奪われる可能性があります。

    "NotAction": [ "lambda:AddPermission", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:*:*:function:intern-*"
  • DevelopEventSourceMappings – プレフィックス intern- が付いた関数のイベントソースマッピングを管理します。これらのアクションは、イベントソースマッピング上で動作しますが、条件を指定した関数を使用して制限することができます。

    "Action": [ "lambda:DeleteEventSourceMapping", "lambda:UpdateEventSourceMapping", "lambda:CreateEventSourceMapping" ], "Resource": "*", "Condition": { "StringLike": { "lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*" } }
  • PassExecutionRoleintern-lambda-execution-role という名前のロールのみ表示して渡します。このロールは、ユーザーが IAM アクセス許可を使用して作成および管理する必要があります。PassRole は、実行ロールを関数に割り当てる際に使用します。

    "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
  • ViewExecutionRolePolicies – 実行ロールにアタッチされている AWS 提供の管理ポリシーを表示します。これにより、コンソールに関数のアクセス許可を表示することはできますが、アカウントの他のユーザーによって作成されたポリシーを表示するためのアクセス許可は含まれません。

    "Action": [ "iam:GetPolicy", "iam:GetPolicyVersion" ], "Resource": "arn:aws:iam::aws:policy/*"
  • ViewLogs – CloudWatch Logs を使用して、プレフィックス intern- が付いた関数のログを表示します。

    "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"

このポリシーでは、他のユーザーのリソースをリスクにさらすことなく、Lambda の使用を開始することができます。他の AWS サービスでトリガーされるように関数を設定したり、AWS の他のサービスを呼び出すことはできません。そのためには、広範囲の IAM アクセス許可が必要です。また、範囲が制限されたポリシーをサポートしていないサービス (例: CloudWatch および X-Ray) のアクセス許可は含まれません。メトリクスおよびトレースデータへのアクセス権をユーザーに付与するには、このようなサービスの読み取り専用ポリシーを使用します。

関数のトリガーを設定する場合は、関数を呼び出す AWS サービスを使用するためのアクセス権が必要です。たとえば、Amazon S3 トリガーを設定するには、バケット通知を管理するための Amazon S3 アクションに対するアクセス許可が必要です。このようなアクセス許可の多くは、AWSLambdaFullAccess 管理ポリシーに含まれています。サンプルポリシーは、本ガイドの GitHub リポジトリで入手できます。

レイヤーの開発および使用

次のポリシーでは、レイヤーを作成し、それらを関数と共に使用するためのユーザーアクセス許可を付与します。リソースパターンでは、レイヤーの名前が test- で始まっている限り、ユーザーは、すべての AWS リージョンですべてのレイヤーバージョンを使用できます。

例 レイヤーの開発ポリシー

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublishLayers", "Effect": "Allow", "Action": [ "lambda:PublishLayerVersion" ], "Resource": "arn:aws:lambda:*:*:layer:test-*" }, { "Sid": "ManageLayerVersions", "Effect": "Allow", "Action": [ "lambda:GetLayerVersion", "lambda:DeleteLayerVersion" ], "Resource": "arn:aws:lambda:*:*:layer:test-*:*" } ] }

また、関数作成時のレイヤーの使用や、lambda:Layer 条件を指定した設定を強制することもできます。たとえば、ユーザーが、他のアカウントによって発行されたレイヤーを使用できないようにすることもできます。次のポリシーでは、指定されたすべてのレイヤーをアカウント 123456789012 で作成することを求める条件を CreateFunction および UpdateFunctionConfiguration に追加します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ConfigureFunctions", "Effect": "Allow", "Action": [ "lambda:CreateFunction", "lambda:UpdateFunctionConfiguration" ], "Resource": "*", "Condition": { "ForAllValues:StringLike": { "lambda:Layer": [ "arn:aws:lambda:*:123456789012:layer:*:*" ] } } } ] }

条件が適用されるように、他のステートメントによって、これらのアクションに対するアクセス許可がユーザーに付与されていないことを確認します。

クロスアカウントロール

以前のポリシーおよびステートメントのいずれかをロールに適用することができます。これで、別のアカウントと共有して、Lambda リソースへのアクセス権を付与することができます。IAM ユーザーとは異なり、認証用の認証情報はロールに含まれません。その代わりに、ロールを引き受け、そのアクセス許可を使用することができるユーザーを指定する信頼ポリシーがあります。

クロスアカウントロールを使用して、Lambda アクションおよびリソースへのアクセス権を、信頼するアカウントに付与することができます。関数を呼び出すアクセス許可、またはレイヤーを使用するアクセス許可を付与する場合は、代わりにリソースベースのポリシーを使用します。

詳細については、『IAM ユーザーガイド』の「IAM ロール」を参照してください。