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

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

Lambda は、Lambda API アクションへのアクセスを許可し、場合によっては、Lambda リソースの開発と管理に使用される他の AWS サービスへのアクセスを許可する、AWS マネージドポリシーを提供します。Lambda は、新機能がリリースされたときにユーザーがそれらにアクセスできるよう、これらのマネージドポリシーを必要に応じて更新します。

  • AWSLambda_FullAccess– Lambda リソースの開発と保守に使用される Lambda アクションおよびその他のAWSサービスへのフルアクセスを許可します。このポリシーは、前のポリシー の範囲を絞り込むことで作成されましたAWSLambdaFullAccess

  • AWSLambda_ReadOnlyAccess– Lambda リソースへの読み取り専用アクセスを許可します。このポリシーは、前のポリシー の範囲を絞り込むことで作成されましたAWSLambdaReadOnlyAccess

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

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

関数の開発

ID ベースのポリシーを使用して、ユーザーが Lambda 関数でオペレーションを実行することを許可します。

注記

コンテナーイメージとして定義された関数の場合、イメージにアクセスするためのユーザー権限は、Amazon Elastic Container Registry で設定する必要があります。例については、Amazon ECR のアクセス許可を参照してください。

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

例 関数の開発ポリシー
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ReadOnlyPermissions", "Effect": "Allow", "Action": [ "lambda:GetAccountSettings", "lambda:GetEventSourceMapping", "lambda:GetFunction", "lambda:GetFunctionConfiguration", "lambda:GetFunctionCodeSigningConfig", "lambda:GetFunctionConcurrency", "lambda:ListEventSourceMappings", "lambda:ListFunctions", "lambda:ListTags", "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:GetRolePolicy", "iam:PassRole", "iam:SimulatePrincipalPolicy" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role" }, { "Sid": "ViewLogs", "Effect": "Allow", "Action": [ "logs:*" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*" } ] }

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

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

    "Action": [ "lambda:GetAccountSettings", "lambda:GetEventSourceMapping", "lambda:GetFunction", "lambda:GetFunctionConfiguration", "lambda:GetFunctionCodeSigningConfig", "lambda:GetFunctionConcurrency", "lambda:ListEventSourceMappings", "lambda:ListFunctions", "lambda:ListTags", "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-*" } }
  • PassExecutionRole - intern-lambda-execution-role という名前のロールのみ表示して渡します。このロールは、ユーザーが IAM アクセス許可を使用して作成および管理する必要があります。PassRole は、実行ロールを関数に割り当てる際に使用します。

    "Action": [ "iam:ListRolePolicies", "iam:ListAttachedRolePolicies", "iam:GetRole", "iam:GetRolePolicy", "iam:PassRole", "iam:SimulatePrincipalPolicy" ], "Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
  • ViewLogs – CloudWatch Logs を使用して、プレフィックス が付いた関数のログを表示しますintern-

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

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

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

レイヤーの開発と使用

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

例 レイヤーの開発ポリシー
{ "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 条件を指定した設定を強制することもできます。たとえば、ユーザーが、他のアカウントによって発行されたレイヤーを使用できないようにすることもできます。次のポリシーでは、指定されたすべてのレイヤーをアカウント CreateFunction で作成することを求める条件を UpdateFunctionConfiguration および 123456789012 に追加します。

{ "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 リソースへのアクセス権を付与することができます。ユーザーとは異なり、認証用の認証情報はロールに含まれません。その代わりに、ロールを引き受け、そのアクセス許可を使用することができるユーザーを指定する信頼ポリシーがあります。

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

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

VPC 設定の条件キー

VPC 設定の条件キーを使用して、Lambda 関数に追加のアクセス許可コントロールを提供できます。例えば、組織内のすべての Lambda 関数を VPC に接続するように強制できます。また、関数に対して使用を許可または拒否するサブネットとセキュリティグループを指定することもできます。

詳細については、「VPC 設定で IAM 条件キーを使用する」を参照してください。