# 実行ロールを使用した Lambda 関数のアクセス許可の定義
Lambda 関数の実行ロールは、AWS のサービスおよびリソースにアクセスする許可を関数に付与する AWS Identity and Access Management (IAM) ロールです。Amazon CloudWatch にログを送信するアクセス許可を持つ実行ロールを作成し、トレースデータを AWS X-Ray にアップロードすることができます。このページでは、Lambda 関数の実行ロールを作成、表示、および管理する方法について説明します。
関数を呼び出すと、Lambda が自動的に実行ロールを引き受けます。関数コード内で、実行ロールを引き受けるために `sts:AssumeRole` を手動で呼び出すことは避けてください。ユースケースでロール自体を引き受ける必要がある場合は、ロール自体を信頼できるプリンシパルとしてロールの信頼ポリシーに含める必要があります。詳細については、「IAM ユーザーガイド」の「[ロールの信頼ポリシーの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy)」を参照してください。
Lambda が実行ロールを適切に引き受けるには、ロールの[信頼ポリシー](#permissions-executionrole-api)で、Lambda サービスプリンシパル (`lambda.amazonaws.com`) が信頼できるサービスとして指定されている必要があります。
**Topics**
+ [
## IAM コンソールでの実行ロールの作成
](#permissions-executionrole-console)
+ [
## AWS CLI を使用したロールの作成と管理
](#permissions-executionrole-api)
+ [
## Lambda 実行ロールへの最小権限アクセスを付与する
](#permissions-executionrole-least-privilege)
+ [
# 実行ロールのアクセス許可の表示と更新
](permissions-executionrole-update.md)
+ [
# 実行ロールでの AWS マネージドポリシーの使用
](permissions-managed-policies.md)
+ [
# ソース関数 ARN を使用した関数のアクセス動作の制御
](permissions-source-function-arn.md)
## IAM コンソールでの実行ロールの作成
デフォルトでは、[Lambda コンソールで関数を作成する](getting-started.md#getting-started-create-function)ときに、Lambda により最小限のアクセス許可で実行ロールが作成されます。具体的には、この実行ロールには [`AWSLambdaBasicExecutionRole` マネージドポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)が含まれており、Amazon CloudWatch Logs にイベントをログ記録するための基本的なアクセス許可を関数に付与します。**[アクセス許可]** セクションで **[デフォルトのロールの作成]** を選択できます。
既存のロールを選択するには、**[アクセス許可]** セクションで **[別のロールを使用する]** を選択します。Lambda 関数で、イベントに応じて Amazon DynamoDB データベースのエントリを更新するなどのタスクを実行するために追加のアクセス許可が必要な場合は、必要なアクセス許可を持つカスタム実行ロールを作成できます。これを行うには、**[アクセス許可]** セクションで **[別のロールを使用する]** を選択します。これにより、アクセス許可をカスタマイズできるドロワーが開きます。
**コンソールから実行ロールを設定するには**
1. ロールの詳細セクションに **[ロール名]** を入力します。
1. **[ポリシー]** セクションで、**[既存のポリシーを選択]** を選択します。
1. ロールにアタッチする AWS マネージドポリシーを選択します。例えば、関数が DynamoDB にアクセスする必要がある場合は、**AWSLambdaDynamoDBExecutionRole** マネージドポリシーを選択します。
1. [**ロールの作成**] を選択してください。
あるいは、[Lambda コンソールで関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)ときに、以前に作成した任意の実行ロールを関数にアタッチできます。既存の関数に新しい実行ロールをアタッチする場合は、「[関数の実行ロールの更新](permissions-executionrole-update.md)」の手順に従います。
## AWS CLI を使用したロールの作成と管理
AWS Command Line Interface (AWS CLI) を使用して実行ロールを作成するには、**create-role** コマンドを使用します。このコマンドを使用するときに、信頼ポリシーインラインを指定することもできます。ロールの信頼ポリシーでは、指定したプリンシパルに、ロールを引き受けるための許可を付与します。次の例では、Lambda サービスプリンシパルに自分の役割を引き受けるアクセス権限を付与します。JSON 文字列で引用符をエスケープするための要件は、シェルに応じて異なることに注意してください。
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
```
また、個別の JSON ファイルを使用してロールの信頼ポリシーを定義することもできます。次の例では、`trust-policy.json` は現在のディレクトリにあるファイルです。
**Example trust-policy.json**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document file://trust-policy.json
```
ロールにアクセス許可を追加するには、**attach-policy-to-role** コマンドを使用します。次のコマンドは、`AWSLambdaBasicExecutionRole` マネージドポリシーを `lambda-ex` 実行ロールにアタッチします。
```
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
実行ロールを作成したら、それを関数にアタッチします。[Lambda コンソールで関数を作成する](getting-started.md#getting-started-create-function)ときに、以前に作成した任意の実行ロールを関数にアタッチできます。既存の関数に新しい実行ロールをアタッチする場合は、「[関数の実行ロールの更新](permissions-executionrole-update.md#update-execution-role)」の手順に従います。
## Lambda 実行ロールへの最小権限アクセスを付与する
デプロイのフェーズで Lambda 関数の IAM ロールを初めて作成するときに、必要な範囲を超えたアクセス許可を付与することがあります。ベストプラクティスとしては、本番環境に関数を公開する前に、ポリシーを調整して必要なアクセス許可のみを含めるようにします。詳細については、「IAM ユーザーガイド」の「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
IAM 実行ロールポリシーに必要なアクセス許可を確認するときは、IAM Access Analyzer を使用します。IAM Access Analyzer は、指定した日付範囲で AWS CloudTrail ログを確認し、その期間中に関数が使用したアクセス許可のみを持つポリシーテンプレートを生成します。このテンプレートを使用することで、きめ細かなアクセス許可で管理ポリシーを作成し、それを IAM ロールにアタッチすることができます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス許可のみを付与します。
詳細については、「*IAM ユーザーガイド*」の「[アクセスアクティビティに基づくポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html)」を参照してください。
# 実行ロールのアクセス許可の表示と更新
このトピックでは、関数の[実行ロール](lambda-intro-execution-role.md)を表示および更新する方法について説明します。
**Topics**
+ [
## 関数の実行ロールの表示
](#view-execution-role)
+ [
## 関数の実行ロールの更新
](#update-execution-role)
## 関数の実行ロールの表示
関数の実行ロールを表示するには、Lambda コンソールを使用します。
**関数の実行ロールを表示するには (コンソール)**
1. Lambda コンソールの[関数ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数の名前を選択します。
1. **[設定]**、**[アクセス権限]** の順に選択します。
1. **[実行ロール]** で、関数の実行ロールとして現在使用されているロールを確認できます。便宜上、関数がアクセスできるすべてのリソースとアクションは、**[リソースの概要]** セクションで確認できます。また、ドロップダウンリストからサービスを選択して、そのサービスに関連するすべてのアクセス許可を確認することもできます。
## 関数の実行ロールの更新
アクセス許可は、関数の実行ロールからいつでも追加または削除できます。または、別のロールを使用するように関数を設定することもできます。関数が他のサービスまたはリソースにアクセスする必要がある場合は、必要なアクセス許可を実行ロールに追加する必要があります。
関数にアクセス許可を追加する場合は、そのコードや設定にも些細な更新を行います。これにより、(古い認証情報により実行中の) 関数のインスタンスが、強制的に停止され置き換えられます。
関数の実行ロールを更新するには、Lambda コンソールを使用できます。
**関数の実行ロールを更新するには (コンソール)**
1. Lambda コンソールの[関数ページ](https://console.aws.amazon.com/lambda/home#/functions)を開きます。
1. 関数の名前を選択します。
1. **[設定]**、**[アクセス権限]** の順に選択します。
1. **[実行ロール]** で、**[編集]** を選択します。
1. 実行ロールとして別のロールを使用するように関数を更新する場合は、**[既存のロール]** の下のドロップダウンメニューから新しいロールを選択します。
**注記**
既存の実行ロール内でアクセス許可を更新する場合は、AWS Identity and Access Management (IAM) コンソールで行う必要があります。
実行ロールとして使用する新しいロールを作成する場合は、**[実行ロール]** で **[AWS ポリシーテンプレートから新しいロールを作成する]** を選択します。次に、**[ロール名]** で新しいロールの名前を入力し、**[ポリシーテンプレート]** で新しいロールにアタッチするポリシーを指定します。
1. [**Save**] を選択します。
# 実行ロールでの AWS マネージドポリシーの使用
次の AWS マネージドポリシーは、Lambda の機能を使うために必要なアクセス許可を付与します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| **[AWSLambdaMSKExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)** - Lambda で [kafka:DescribeClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#v2-clusters-clusterarnget) がこのポリシーに追加されました。 | `AWSLambdaMSKExecutionRole` は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターからレコードを読み取り、アクセスし、Elastic Network Interface (ENI) を管理し、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 6 月 17 日 |
| **[AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaBasicExecutionRole` は、ログを CloudWatch にアップロードするための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSLambdaDynamoDBExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaDynamoDBExecutionRole` は、Amazon DynamoDB ストリームからレコードを読み取り、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSLambdaKinesisExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaKinesisExecutionRole` は、Amazon Kinesis データストリームからイベントを読み取り、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSLambdaMSKExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaMSKExecutionRole` は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターからレコードを読み取り、アクセスし、Elastic Network Interface (ENI) を管理し、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSLambdaSQSQueueExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaSQSQueueExecutionRole` は、Amazon Simple Queue Service (Amazon SQS) キューからメッセージを読み取り、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSLambdaVPCAccessExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSLambdaVPCAccessExecutionRole` は、Amazon VPC 内の ENI を管理し、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AWSXRayDaemonWriteAccess` は、トレースデータを X-Ray にアップロードするための許可を付与します。 | 2022 年 2 月 14 日 |
| **[CloudWatchLambdaInsightsExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `CloudWatchLambdaInsightsExecutionRolePolicy` は、CloudWatch Lambda Insights にランタイムメトリクスを書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
| **[AmazonS3ObjectLambdaExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonS3ObjectLambdaExecutionRolePolicy)** — Lambda は、このポリシーに対する変更の追跡を開始しました。 | `AmazonS3ObjectLambdaExecutionRolePolicy` は、Amazon Simple Storage Service (Amazon S3) オブジェクトの Lambda とやり取りし、CloudWatch Logs に書き込むための許可を付与します。 | 2022 年 2 月 14 日 |
一部の機能では、Lambda コンソールは、カスタマーマネージドポリシーの実行ロールに対して、不足しているアクセス許可を追加しようとします。これらのポリシーは数が増える可能性があります。余分なポリシーを作成しないように、機能を有効にする前に関連する AWS 管理ポリシーを実行ロールに追加します。
[イベントソースマッピング](invocation-eventsourcemapping.md)を使用して関数を呼び出すと、Lambda は実行ロールを使用してイベントデータを読み出します。例えば、Kinesis のイベントソースマッピングでは、データストリームからイベントを読み出し、バッチで関数に送信します。
アカウント内でサービスがロールを引き受ける場合は、ロール信頼ポリシーに `aws:SourceAccount` または `aws:SourceArn` のグローバル条件コンテキストキーを含めることで、期待するリソースによって生成されたリクエストのみに、ロールのアクセスを制限できます。詳細については、「[AWS Security Token Service のサービス間の混乱した代理の防止](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention)」を参照してください。
Lambda コンソールには、AWS マネージドポリシーに加えて、追加のユースケース用のアクセス許可を含むカスタムポリシーを作成するためのテンプレートが用意されています。Lambda コンソールで関数を作成する際、1 つ以上のテンプレートのアクセス許可を使用して新しい実行ロールを作成することを選択できます。これらのテンプレートは、設計図から関数を作成する場合、または他のサービスへのアクセスを必要とするオプションを設定する場合にも自動的に適用されます。サンプルテンプレートは、本ガイドの [GitHub リポジトリ](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies)から入手できます。
# ソース関数 ARN を使用した関数のアクセス動作の制御
一般的に、Lambda 関数のコードは、他の AWS のサービスに対し API リクエストを送信します。これらのリクエストを行うために、Lambda は関数の実行ロールを引き受けることによって、認証情報のセットを一時的に生成します。これらの認証情報は、関数の呼び出し中に環境変数として利用できます。AWS SDK を使用している場合に、コード内で SDK の認証情報を直接提供する必要はありません。デフォルトで、認証情報プロバイダーチェーンは認証情報を設定できる各場所を順番にチェックし、最初に利用できるものを選択します。これは通常、環境変数 (`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、および `AWS_SESSION_TOKEN`) です。
Lambda は、リクエストが実行環境内から実行される AWS API リクエストである場合、ソース関数 ARN を認証情報コンテキストに挿入します。Lambda は、Lambda がユーザーに代わって実行環境外で実行する以下の AWS API リクエストにも、ソース関数 ARN を挿入します。
| サービス | Action | Reason |
| --- | --- | --- |
| CloudWatch Logs | CreateLogGroup, CreateLogStream, PutLogEvents | CloudWatch Logs ロググループにログを保存する |
| X-Ray | PutTraceSegments | X-Ray にトレースデータを送信する |
| Amazon EFS | ClientMount | 関数を Amazon Elastic File System (Amazon EFS) ファイルシステムに接続する |
ソース関数 ARN は、Lambda が同じ実行ロールを使用して、実行環境外でユーザーに代わって実行するその他の AWS API コールには含まれていません。このように、実行環境外で実行される API コールの例としては、以下が挙げられます。
+ 環境変数を自動的に暗号化および復号化するための AWS Key Management Service (AWS KMS) の呼び出し。
+ VPC 対応関数用の Elastic Network Interfaces (ENI) を作成するための Amazon Elastic Compute Cloud (Amazon EC2) の呼び出し。
+ [イベントソースマッピング](invocation-eventsourcemapping.md)としてセットアップされたイベントソースから読み込むための、Amazon Simple Queue Service (Amazon SQS) などの AWS のサービスの呼び出し。
認証情報コンテキストに挿入されたソース関数 ARN を使用すると、特定の Lambda 関数のコードからリソースへの呼び出しが行われたのかどうかを確認できます。これを確認するには、IAM ID ベースのポリシーまたは[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) で `lambda:SourceFunctionArn` 条件キーを使用します。
**注記**
リソースベースのポリシーにある `lambda:SourceFunctionArn` は使用できませんでした。
ID ベースのポリシーまたは SCP でこの条件キーを使用することで、関数コードが他の AWS のサービスに対し実行する、API アクションのためのセキュリティ制御を実装できます。こういったセキュリティアプリケーションには、認証情報の漏洩の原因を特定する場合など、重要なものがいくつか含まれています。
**注記**
`lambda:SourceFunctionArn` 条件キーは、`lambda:FunctionArn` および `aws:SourceArn` 条件キーとは異なります。`lambda:FunctionArn` 条件キーは、[イベントソースマッピング](invocation-eventsourcemapping.md)にのみ適用され、イベントソースから呼び出しが可能な関数を定義するのに使用されます。`aws:SourceArn` 条件キーは、Lambda 関数がターゲットリソースであるポリシーにのみ適用され、その機能を呼び出すことができる他の AWS のサービスとリソースを定義するのに役立ちます。`lambda:SourceFunctionArn` 条件キーは任意の ID ベースのポリシーまたは SCP に適用して、他のリソースに対して特定の AWS API コールを行う許可を持つ特定の Lambda 関数を定義します。
ポリシーで `lambda:SourceFunctionArn` を使用するには、それを、任意の [ARN 条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_ARN)に条件として含めます。キーの値は有効な ARN にする必要があります。
例えば、Lambda 関数のコードが特定の Amazon S3 バケットをターゲットとして、`s3:PutObject` 呼び出しを実行したとします。これには、Lambda 関数の 1 つだけに、対象のバケットに対する `s3:PutObject` アクセスを許可する必要があります。この場合、関数の実行ロールには、次のようなポリシーがアタッチされている必要があります。
**Example 特定の Lambda 関数に Amazon S3 リソースへのアクセスを許可するポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleSourceFunctionArn",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
このポリシーでは、ARN が `arn:aws:lambda:us-east-1:123456789012:function:source_lambda` である Lambda 関数がソースの場合にのみ、`s3:PutObject` アクセスを許可します。このポリシーは、他の呼び出し ID に対して `s3:PutObject` アクセスを許可することはありません。別の関数またはエンティティが、同じ実行ロールを使用し `s3:PutObject` 呼び出しを行った場合も同様です。
**注記**
`lambda:SourceFunctionARN` 条件キーは、Lambda 関数のバージョンや関数エイリアスをサポートしていません。特定の関数バージョンまたはエイリアスの ARN を使用しても、関数には指定したアクションを実行するアクセス許可は付与されません。関数には、必ずバージョンやエイリアスのサフィックスが付いていない、修飾されていない ARN を使用してください。
SCP で `lambda:SourceFunctionArn` を使用することもできます。例えば、バケットへのアクセスを、単一の Lambda 関数のコードまたは特定の Amazon Virtual Private Cloud (VPC) からの呼び出しに制限したいとします。以下の SCP は、これを示したものです。
**Example 特定の条件下で Amazon S3 へのアクセスを拒否するポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"vpc-12345678"
]
}
}
},
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"ArnNotEqualsIfExists": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
このポリシーは、ARN `arn:aws:lambda:*:123456789012:function:source_lambda` を持つ特定の Lambda 関数からのものでない限り、または指定された VPC からのものでない限り、すべての S3 アクションを拒否します。`StringNotEqualsIfExists` 演算子は、`aws:SourceVpc` キー がリクエストに含まれている場合にのみ、IAM に対し、この条件を処理することを指示します。これと同様に、IAM は `lambda:SourceFunctionArn` が存在する場合にのみ `ArnNotEqualsIfExists` を認識します。