# AWS Lambda アクセス許可の管理
AWS Identity and Access Management (IAM) を使用して AWS Lambda でアクセス許可を管理できます。Lambda 関数を使用する際に考慮する必要があるアクセス許可には、主に次の 2 つのカテゴリがあります。
+ Lambda 関数が API アクションを実行して他の AWS リソースにアクセスするために必要なアクセス許可
+ 他の AWS ユーザーやエンティティが Lambda 関数にアクセスするために必要なアクセス許可
Lambda 関数は、多くの場合、他の AWS リソースにアクセスし、それらのリソースに対してさまざまな API オペレーションを実行する必要があります。例えば、Amazon DynamoDB データベースのエントリを更新してイベントに応答する Lambda 関数があるとします。この場合、その関数にはデータベースにアクセスするためのアクセス許可と、そのデータベースに項目を配置または更新するためのアクセス許可が必要です。
Lambda 関数に必要なアクセス許可は、[実行ロール](lambda-intro-execution-role.md)と呼ばれる特別な IAM ロールで定義します。このロールでは、関数が他の AWS リソースにアクセスして、イベントソースから読み取るために必要なすべてのアクセス許可を定義するポリシーをアタッチできます。すべての Lambda 関数には実行ロールが必要です。Lambda 関数はデフォルトで Amazon CloudWatch にログ記録するため、実行ロールには、少なくとも Amazon CloudWatch へのアクセス権が必要です。[`AWSLambdaBasicExecutionRole` マネージドポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)を実行ロールにアタッチして、この要件を満たすことができます。
他の AWS アカウント、組織、およびサービスに、Lambda リソースにアクセスするためのアクセス許可を付与するには、いくつかのオプションがあります。
+ [ID ベースのポリシー](access-control-identity-based.md)を使用して、Lambda リソースへのアクセス権を他のユーザーに付与することができます。アイデンティティベースのポリシーは、ユーザーに直接適用するか、ユーザーに関連付けられているグループおよびロールに適用することができます。
+ [リソースベースのポリシー](access-control-resource-based.md)を使用して、Lambda リソースにアクセスするためのアクセス許可を他のアカウントや AWS のサービスに付与することができます。ユーザーが Lambda リソースへのアクセスを試みた際、Lambda は、ユーザーのアイデンティティベースのポリシーと、リソースのリソースベースのポリシーの両方を認識しようとします。Amazon Simple Storage Service (Amazon S3) などの AWS のサービスが Lambda 関数を呼び出す際。Lambda はリソースベースのポリシーのみを認識しようとします。
+ [属性ベースのアクセス制御 (ABAC)](attribute-based-access-control.md) モデルを使用して、Lambda 関数へのアクセスを制御できます。ABAC を使用すると、Lambda 関数にタグをアタッチしたり、特定の API リクエストでタグを渡したり、リクエストを実行する IAM プリンシパルにタグをアタッチしたりすることができます。IAM ポリシーの条件要素で同じタグを指定して、関数アクセスを制御します。
AWS のベストプラクティスとして、タスクを実行するために必要なアクセス許可のみ ([最小特権のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)) を付与するようにしてください。Lambda でこれを実装するには、[AWS マネージドポリシー](permissions-managed-policies.md)から始めることをお勧めします。これらの管理ポリシーは、そのまま使用することができますが、より制限的なポリシーを記述する際の開始点として使用することもできます。
最小特権アクセスを実現するためにアクセス許可を微調整できるように、Lambda ではポリシーに含めることができるいくつかの追加条件が用意されています。詳細については、「[ポリシーのリソースセクションと条件セクションの微調整](lambda-api-permissions-ref.md)」を参照してください。
IAM の詳細については、*[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)* を参照してください。
# 実行ロールを使用した 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` を認識します。
# 他の AWS エンティティに Lambda 関数へのアクセス権を付与する
他の AWS アカウント、組織、およびサービスに、Lambda リソースにアクセスするためのアクセス許可を付与するには、いくつかのオプションがあります。
+ [ID ベースのポリシー](access-control-identity-based.md)を使用して、Lambda リソースへのアクセス権を他のユーザーに付与することができます。アイデンティティベースのポリシーは、ユーザーに直接適用するか、ユーザーに関連付けられているグループおよびロールに適用することができます。
+ [リソースベースのポリシー](access-control-resource-based.md)を使用して、Lambda リソースにアクセスするためのアクセス許可を他のアカウントや AWS のサービスに付与することができます。ユーザーが Lambda リソースへのアクセスを試みた際、Lambda は、ユーザーのアイデンティティベースのポリシーと、リソースのリソースベースのポリシーの両方を認識しようとします。Amazon Simple Storage Service (Amazon S3) などの AWS のサービスが Lambda 関数を呼び出す際。Lambda はリソースベースのポリシーのみを認識しようとします。
+ [属性ベースのアクセス制御 (ABAC)](attribute-based-access-control.md) モデルを使用して、Lambda 関数へのアクセスを制御できます。ABAC を使用すると、Lambda 関数にタグをアタッチしたり、特定の API リクエストでタグを渡したり、リクエストを実行する IAM プリンシパルにタグをアタッチしたりすることができます。IAM ポリシーの条件要素で同じタグを指定して、関数アクセスを制御します。
最小特権アクセスを実現するためにアクセス許可を微調整できるように、Lambda ではポリシーに含めることができるいくつかの追加条件が用意されています。詳細については、「[ポリシーのリソースセクションと条件セクションの微調整](lambda-api-permissions-ref.md)」を参照してください。
# Lambda のアイデンティティベースの IAM ポリシー
Lambda へのアクセス権をアカウントのユーザーに付与するには、AWS Identity and Access Management (IAM) のアイデンティティベースのポリシーを使用します。アイデンティティベースのポリシーは、ユーザー、ユーザーグループ、またはロールに適用できます。または、アカウントのロールを引き受け、Lambda リソースにアクセスするためのアクセス許可を、別のアカウントのユーザーに付与することもできます。
Lambda は、Lambda API アクションへのアクセスを許可し、場合によっては、Lambda リソースの開発と管理に使用される他の AWS サービスへのアクセスを許可する、AWS マネージドポリシーを提供します。Lambda は、新機能がリリースされたときにユーザーがそれらにアクセスできるよう、これらのマネージドポリシーを必要に応じて更新します。
+ [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) - Lambda リソースの開発および維持に使用する Lambda アクションおよびその他の AWS サービスへのフルアクセス権を付与します。
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) - Lambda リソースへの読み取り専用のアクセス権を付与します。
+ [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) - Lambda 関数を呼び出すアクセス許可を付与します。
AWS マネージドポリシーでは、ユーザーが変更できる Lambda 関数やレイヤーを制限することなく、API アクションへのアクセス許可を付与します。きめ細かな制御では、ユーザーのアクセス許可の範囲を制限する独自のポリシーを作成することができます。
**Topics**
+ [Lambda 関数へのアクセス権をユーザーに付与する](permissions-user-function.md)
+ [Lambda レイヤーへのアクセス権をユーザーに付与する](permissions-user-layer.md)
# Lambda 関数へのアクセス権をユーザーに付与する
[アイデンティティベースのポリシー](access-control-identity-based.md)を使用して、ユーザー、ユーザーグループ、またはロールが Lambda 関数でオペレーションを実行できるようにします。
**注記**
コンテナイメージとして定義された関数の場合、イメージにアクセスするためのユーザーのアクセス許可は、Amazon Elastic Container Registry (Amazon ECR) で設定する必要があります。例については、「[Amazon ECR リポジトリポリシー](images-create.md#configuration-images-permissions)」を参照してください。
範囲を制限したアクセス許可ポリシーの例を以下に示します。このポリシーにより、ユーザーは、指定されたプレフィックス (`intern-`) が名前に付き、指定された実行ロールで設定されている Lambda 関数を作成および管理することができます。
**Example 関数の開発ポリシー**
****
```
{
"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": {
"ArnLike": {
"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-*"
}
]
}
```
ポリシーのアクセス許可は、アクセス許可でサポートされている[リソースおよび条件](lambda-api-permissions-ref.md)に基づき、ステートメントに整理されます。
+ `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` では、関数の[リソースベースのポリシー](access-control-resource-based.md)が変更されるため、セキュリティへの影響が生じる可能性があります。`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 アクションを使用するアクセス許可が必要です。このようなアクセス許可の多くは、[AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) 管理ポリシーに含まれています。
# Lambda レイヤーへのアクセス権をユーザーに付与する
[アイデンティティベースのポリシー](access-control-identity-based.md)を使用して、ユーザー、ユーザーグループ、またはロールが Lambda レイヤーでオペレーションを実行できるようにします。次のポリシーでは、レイヤーを作成し、それらを関数と共に使用するためのユーザーアクセス許可を付与します。リソースパターンでは、レイヤーの名前が `test-` で開始している限り、ユーザーは、すべての AWS リージョン ですべてのレイヤーバージョンを使用できます。
**Example レイヤーの開発ポリシー**
****
```
{
"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` に追加します。
------
#### [ JSON ]
****
```
{
"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 では、Lambda 関数およびレイヤーのための、リソースベースのアクセス許可ポリシーをサポートしています。リソースベースのポリシーを使用して、他の [AWS アカウント](permissions-function-cross-account.md)、[組織](permissions-function-organization.md)、または[サービス](permissions-function-services.md)へのアクセスを許可できます。リソースベースのポリシーは、1 つの関数、バージョン、エイリアス、レイヤーバージョンに適用されます。
------
#### [ Console ]
**関数のリソースベースのポリシーを表示するには**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. [**設定**] を選択して、[**アクセス許可**] を選択します。
1. [**リソースベースのポリシー**] まで下にスクロールし、[**View policy document (ポリシードキュメントの表示)**] を選択します。リソースベースのポリシーには、別のアカウントまたは AWS のサービスが関数にアクセスしようとしたときに適用されるアクセス許可が表示されます。次の例は、アカウント `123456789012` の `amzn-s3-demo-bucket` という名前のバケットに対して `my-function` という名前の関数を呼び出すことを Amazon S3 に許可するステートメントを示しています。
**Example リソースベースのポリシー**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-allow-s3-my-function",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789012"
},
"ArnLike": {
"AWS:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
}
]
}
```
------
#### [ AWS CLI ]
関数のリソースベースのポリシーを表示するには、`get-policy` コマンドを使用します。
```
aws lambda get-policy \
--function-name my-function \
--output text
```
次のような出力が表示されます。
****
```
{"Version":"2012-10-17", "Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]}
```
バージョンおよびエイリアスでは、バージョン番号またはエイリアスを関数名に追加します。
```
aws lambda get-policy --function-name my-function:PROD
```
関数からアクセス許可を削除するには、`remove-permission` を使用します。
```
aws lambda remove-permission \
--function-name example \
--statement-id sns
```
レイヤーでのアクセス許可を表示するには、`get-layer-version-policy` コマンドを使用します。
```
aws lambda get-layer-version-policy \
--layer-name my-layer \
--version-number 3 \
--output text
```
次のような出力が表示されます。
```
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
`remove-layer-version-permission` を使用して、ポリシーからステートメントを削除します。
```
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
```
------
## サポートされている API アクション
次の Lambda API アクションは、リソースベースのポリシーをサポートしています。
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
+ [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionEventInvokeConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionEventInvokeConfig.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
+ [InvokeFunctionUrl](urls-auth.md)（アクセス許可のみ）
+ [ListAliases](https://docs.aws.amazon.com/lambda/latest/api/API_ListAliases.html)
+ [ListFunctionEventInvokeConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionEventInvokeConfigs.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)
+ [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
# Lambda 関数へのアクセス権を AWS のサービスに付与する
[AWS のサービスを使用して関数を呼び出す](lambda-services.md)場合は、リソースベースのポリシーのステートメントでアクセス許可を付与します。このステートメントを、関数全体に適用することも、単一のバージョンまたはエイリアスに制限することもできます。
**注記**
Lambda コンソールで関数にトリガーを追加すると、サービスでその関数を呼び出せるように、関数のリソースベースのポリシーがコンソールで更新されます。Lambda コンソールで使用できない他のアカウントやサービスにアクセス許可を付与するには、AWS CLI を使用します。
[add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) コマンドを使用してステートメントを追加します。最もシンプルなリソースベースのポリシーのステートメントでは、サービスで関数を呼び出すことができます。次のコマンドは、`my-function` という名前の関数を呼び出すためのアクセス許可を Amazon Simple Notification Service に付与します。
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns \
--principal sns.amazonaws.com \
--output text
```
以下の出力が表示されます。
```
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
```
これにより、Amazon SNS は関数に対して [呼び出し](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) API アクションを呼び出すことができますが、呼び出しをトリガーする Amazon SNS トピックは制限されません。関数が特定のリソースからのみ呼び出せるようにするには、`source-arn` オプションでリソースの Amazon リソースネーム (ARN) を指定します。次のコマンドは、Amazon SNS に、`my-topic` という名前のトピックをサブスクリプションするための、関数を呼び出すことのみ許可します。
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns-my-topic \
--principal sns.amazonaws.com \
--source-arn arn:aws:sns:us-east-2:123456789012:my-topic
```
一部のサービスでは、他のアカウントで関数を呼び出すことができます。アカウント ID を含むソース ARN を指定した場合は問題ではありません。ただし、Amazon S3 では、ソースは、ARN にアカウント ID が含まれないバケットになります。バケットを削除すると、別のアカウントで同じ名前のバケットが作成される可能性があります。アカウントのリソースでのみ関数を呼び出せるように、アカウント ID を指定して `source-account` オプションを使用します。
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id s3-account \
--principal s3.amazonaws.com \
--source-arn arn:aws:s3:::amzn-s3-demo-bucket \
--source-account 123456789012
```
# 関数へのアクセス権を組織に付与する
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) の組織にアクセス許可を付与するには、組織 ID を `principal-org-id` として指定します。次の [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) コマンドは、組織 `o-a1b2c3d4e5f` 内のすべてのユーザーに呼び出しアクセス権を付与します。
```
aws lambda add-permission \
--function-name example \
--statement-id PrincipalOrgIDExample \
--action lambda:InvokeFunction \
--principal * \
--principal-org-id o-a1b2c3d4e5f
```
**注記**
このコマンドでは、`Principal` は `*` です。これにより、組織 `o-a1b2c3d4e5f` 内のすべてのユーザーが関数呼び出しアクセス許可を取得します。AWS アカウント またはロールを `Principal` として指定した場合、そのプリンシパルだけが関数呼び出しアクセス許可を取得します。ただし、それらが `o-a1b2c3d4e5f` 組織の一部である場合に限ります。
このコマンドで、次のようなリソースベースのポリシーが作成されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalOrgIDExample",
"Effect": "Allow",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:example",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-a1b2c3d4e5f"
}
}
}
]
}
```
------
詳細については、「IAM ユーザーガイド」の「[aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid)」を参照してください。
# Lambda 関数へのアクセス権を他のアカウントに付与する
関数を別の AWS アカウント と共有するには、クロスアカウントアクセス許可ステートメントを関数の[リソースベースのポリシー](access-control-resource-based.md)に追加します。[add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) コマンドを実行し、アカウント ID を `principal` として指定します。次の例では、`111122223333` エイリアスを使用して `my-function` を呼び出すアクセス許可をアカウント `prod` に付与します。
```
aws lambda add-permission \
--function-name my-function:prod \
--statement-id xaccount \
--action lambda:InvokeFunction \
--principal 111122223333 \
--output text
```
次のような出力が表示されます。
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-1:123456789012:function:my-function"}
```
リソースベースのポリシーは、他のアカウントに対して関数へのアクセス許可を付与しますが、そのアカウントのユーザーに対してはユーザーに付与済みのアクセス許可を超える許可を付与しません。他のアカウントのユーザーが Lambda API を使用するには、対応する[ユーザー権限](access-control-identity-based.md)が必要です。
別のアカウントのユーザーまたはロールへのアクセスを制限するには、ID の完全な ARN をプリンシパルとして指定します。例えば、`arn:aws:iam::123456789012:user/developer` と指定します。
[エイリアス](configuration-aliases.md)では、他のアカウントが呼び出すことができるバージョンを制限します。この方法では、他のアカウントは、エイリアスを関数 ARN を含める必要があります。
```
aws lambda invoke \
--function-name arn:aws:lambda:us-east-2:123456789012:function:my-function:prod out
```
次のような出力が表示されます。
```
{
"StatusCode": 200,
"ExecutedVersion": "1"
}
```
その後、関数の所有者は、新しいバージョンを参照するようにエイリアスを更新できます。これにより、呼び出し元で関数を呼び出す方法を変更する必要がなくなります。また、他のアカウントは、新しいバージョンを使用するようにコードを変更する必要もなくなります。エイリアスに関連付けられた関数のバージョンを呼び出すアクセス許可が付与されるだけです。
既存の関数で動作するほとんどの API アクションにクロスアカウントアクセスを付与できます。例えば、アカウントによるエイリアスのリストの取得を許可する `lambda:ListAliases`、または関数コードのダウンロードを許可する `lambda:GetFunction` へのアクセス権を付与することができます。各アクセス許可を個別に追加するか、`lambda:*` を使用して、指定された関数のすべてのアクションに対するアクセス権を付与します。
他のアカウントに複数の関数に対するアクセス許可、または関数で実行しないアクションに対するアクセス許可を付与するには、[IAM ロール](access-control-identity-based.md)を使用することをお勧めします。
# 他のアカウントに Lambda レイヤーへのアクセス許可を付与する
レイヤーを別の AWS アカウント と共有するには、レイヤーの[リソースベースのポリシー](access-control-resource-based.md) にクロスアカウントアクセス許可ステートメントを追加します。[add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) コマンドを実行し、アカウント ID を として指定します`principal`。アクセス許可は、各ステートメントで、1 つのアカウント、すべてのアカウント、または [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 内の組織に付与することができます。
以下の例では、アカウント 111122223333 に `bash-runtime` レイヤーのバージョン 2 へのアクセス許可を付与します。
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
次のような出力が表示されます。
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
アクセス許可は、単一レイヤーバージョンにのみ適用されます。新しいレイヤーバージョンを作成するたびに、このプロセスを繰り返します。
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 組織のすべてのアカウントにアクセス許可を付与するには、`organization-id` オプションを使用します。以下の例では、バージョン 3 の `my-layer` を使用する `o-t194hfs8cz` アクセス許可を、組織のすべてのアカウントに付与します。
```
aws lambda add-layer-version-permission \
--layer-name my-layer \
--version-number 3 \
--statement-id engineering-org \
--principal '*' \
--action lambda:GetLayerVersion \
--organization-id o-t194hfs8cz \
--output text
```
以下の出力が表示されます。
```
{"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
複数のアカウントまたは組織にアクセス許可を付与するには、複数のステートメントを追加する必要があります。
# Lambda での属性ベースのアクセスコントロールの使用
[属性ベースのアクセス制御 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) では、タグを使用して Lambda リソースへのアクセスを制御できます。タグは、特定の Lambda リソースにアタッチしたり、特定の API リクエストに渡したり、リクエストを実行する AWS Identity and Access Management (IAM) プリンシパルにアタッチしたりすることができます。AWS による属性ベースアクセスの付与の詳細については、「IAM ユーザーガイド」の「[タグを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。
ABAC を使用すると、IAM ポリシーで Amazon リソースネーム (ARN) または ARN パターンを指定しなくても、[最小特権を付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)することができます。代わりに、IAM ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)で、アクセスを制御するためのタグを指定します。新しいリソースを作成する際の IAM ポリシーの更新が必要なくなるため、ABAC を使用するとスケーリングが容易になります。代わりに、新しいリソースには、アクセスを制御するためのタグを追加します。
Lambda では、タグは次のリソースで機能します。
+ 関数 — 関数のタグ付けの詳細については、「[Lambda 関数でのタグの使用](configuration-tags.md)」を参照してください。
+ コード署名設定 — コード署名設定のタグ付けの詳細については、「[コード署名設定でのタグの使用](tags-csc.md)」を参照してください。
+ イベントソースマッピング — イベントソースマッピングのタグ付けの詳細については、「[イベントソースマッピングでのタグの使用](tags-esm.md)」を参照してください。
レイヤーではタグはサポートされていません。
次の条件キーを使用すると、タグに基づいて IAM ポリシールールを記述できます。
+ [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag): Lambda リソースにアタッチされているタグに基づいてアクセスを制御します。
+ [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag): 新しい関数の作成時などに、リクエスト内のタグを要求します。
+ [aws:PrincipalTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag): IAM プリンシパル (リクエストを行っているユーザー) が実行できる操作内容を、IAM [ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html)または[ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_roles.html)にアタッチされたタグに基づき制御します。
+ [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys): リクエストで特定のタグキーを使用できるかどうかを制御します。
それらをサポートするアクションに対してのみ、条件を指定できます。各 Lambda アクションでサポートされる条件のリストについては、「サービス認可リファレンス」の「[AWS Lambda のアクション、リソース、および条件キー](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html)」を参照してください。**aws:ResourceTag/tag-key** のサポートについては、「AWS Lambda で定義されるリソースタイプ」を参照してください。**aws:RequestTag/tag-key** および **aws:TagKeys** のサポートについては、「AWS Lambda で定義されるアクション」を参照してください。
**Topics**
+ [タグによる関数の保護](attribute-based-access-control-example.md)
# タグによる関数の保護
次の手順は、ABAC を使用して関数のアクセス許可を設定する方法の一例です。この例のシナリオでは、IAM アクセス許可ポリシーを 4 つ作成しています。その後、これらのポリシーを新しい IAM ロールにアタッチします。最後に、IAM ユーザーを作成し、そのユーザーに、新しいロールを引き受けるためのアクセス許可を付与します。
**Topics**
+ [前提条件](#abac-prerequisites)
+ [ステップ 1: 新しい関数のタグを要求する](#require-tag-on-create)
+ [ステップ 2: Lambda 関数と IAM プリンシパルにアタッチされたタグに基づいてアクションを許可する](#restrict-actions-function-tags)
+ [ステップ 3: リスト作成のためのアクセス許可を付与する](#abac-list-permissions)
+ [ステップ 4: IAM のアクセス許可を付与する](#abac-iam-permissions)
+ [ステップ 5: IAM ロールを作成する](#abac-create-role)
+ [ステップ 6: IAM ユーザーを作成する](#abac-create-user)
+ [ステップ 7: アクセス許可をテストする](#abac-test)
+ [ステップ 8: リソースをクリーンアップする](#abac-clean-up)
## 前提条件
[Lambda の実行ロール](lambda-intro-execution-role.md)が必要です。このロールは、IAM アクセス許可の付与、および Lambda 関数の作成を行う際に使用します。
## ステップ 1: 新しい関数のタグを要求する
Lambda で ABAC を使用する場合、すべての関数にタグを付けるようにするのがベストプラクティスです。これにより、ABAC での許可ポリシーが期待どおりに機能することが保証されます。
次の例のような [IAM ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)を作成します。このポリシーでは、[aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)、[aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag)、および [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) 条件キーにより、新しい関数と、その関数を作成する IAM プリンシパルの両方に、`project` タグが付けられていることを要求しています。`ForAllValues` 修飾子により、`project` を唯一許可されているタグとして指定しています。`ForAllValues` 修飾子含めない場合、ユーザーは `project` を渡すことで他のタグを関数に追加できるようになります。
**Example – 新しい関数のタグを要求する**
****
```
{
"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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) 条件キーを使用して 2 番目の IAM ポリシーを作成し、プリンシパルのタグが関数にアタッチされているタグと一致することを要求します。次のポリシー例は、`project` タグが付けられたプリンシパルに対し、`project` タグが付けられた関数を呼び出すことを許可します。他のタグが関数に付けられている場合、このアクションは拒否されます。
**Example – 関数と 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 アクション呼び出時に認識できるようになります。
**Example – 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 のサービスにロールを渡すアクセス許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」を参照してください。
**Example – 実行ロールを渡すためのアクセス許可を付与する**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/lambda-ex"
}
]
}
```
## ステップ 5: IAM ロールを作成する
[アクセス許可を委任するためには、ロールを使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate-using-roles)ことがベストプラクティスです。`abac-project-role` という [IAM ロールを作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html#roles-creatingrole-user-console)します。
+ **[ステップ 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 ユーザーを作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)します。**[Set permissions]** (アクセス許可の設定) セクションで、**[Attach existing policies directly]** (既存のポリシーを直接アタッチ) を選択し、次に **[Create policy]** (ポリシーを作成) を選択します。ポリシーの定義を以下のように入力します。*111122223333* の部分は、自分の [AWS アカウント ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers) に置き換えます。このポリシーでは、`abac-project-role` を引き受けることを `abac-test-user` に対し許可します。
**Example – ABAC ロールを引き受けることを、IAM ユーザーに対し許可する**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/abac-project-role"
}
}
```
------
## ステップ 7: アクセス許可をテストする
1. AWS コンソールに、`abac-test-user` としてサインインします。詳細については、「[IAM ユーザーとしてサインインする](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html#user-sign-in-page)」を参照してください。
1. `abac-project-role` ロールに切り替えます。詳細については、「[ロールの切り替え (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)」を参照してください。
1. [Lambda 関数を作成します](configuration-tags.md#using-tags-with-the-console)。
+ **[Permissions]** (許可) で **[Change default execution role]** (デフォルトの実行ロールの変更) を選択した後、**[Execution role]** (実行ロール) で **[Use an existing role]** (既存のロールを使用する) を選択します。[ステップ 4: IAM のアクセス許可を付与する](#abac-iam-permissions) で使用したものと同じ実行ロールを選択します。
+ **[Advanced settings]** (詳細設定) で **[Enable tags]** (タグを有効化) を選択した上で、**[Add new tag]** (新しいタグを追加) を選択します。**[Key]** (キー) に「`project`」と入力します。ここでは、**値**は入力しません。
1. [関数をテストします](testing-functions.md)。
1. 2 つ目の Lambda 関数を作成し、異なるタグ (例: `environment`) を追加します。通常、この操作は失敗します。[ステップ 1: 新しい関数のタグを要求する](#require-tag-on-create) で作成した ABAC ポリシーでは、`project` タグが付いた関数を作成することのみをプリンシパルに許可しているためです。
1. タグを付けずに 3 つ目の関数を作成します。通常、この操作も失敗します。[ステップ 1: 新しい関数のタグを要求する](#require-tag-on-create) で作成した ABAC ポリシーでは、タグなしの関数を作成することをプリンシパルに許可していないためです。
この認可戦略により、それぞれの新しいユーザーに新しいポリシーを作成することなく、アクセスの制御が可能になります。新しいユーザーにアクセス権を付与する際は、割り当てられたプロジェクトに対応するロールを引き受けるための、アクセス許可を付与するだけですみます。
## ステップ 8: リソースをクリーンアップする
**IAM ロールを削除するには**
1. IAM コンソールの [[ロール]](https://console.aws.amazon.com/iam/home#/roles) ページを開きます。
1. [ステップ 5](#abac-create-role) で作成したロールを選択します。
1. **[削除]** を選択します。
1. 削除を確認するには、テキスト入力フィールドにロール名を入力します。
1. **[削除]** を選択します。
**IAM ユーザーを削除するには**
1. IAM コンソールで[ユーザーページ](https://console.aws.amazon.com/iam/home#/users)を開きます。
1. [ステップ 6](#abac-create-user) で作成した IAM ユーザーを選択します。
1. **[削除]** を選択します。
1. 削除を確認するには、テキスト入力フィールドにユーザー名を入力します。
1. [**ユーザーの削除**] を選択します。
**Lambda 関数を削除するには**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 作成した関数を選択します。
1. **[アクション]** で、**[削除]** を選択します。
1. テキスト入力フィールドに **confirm** と入力し、**[Delete]** (削除) を選択します。
# ポリシーのリソースセクションと条件セクションの微調整
AWS Identity and Access Management (IAM) ポリシーでリソースと条件を指定することで、ユーザーのアクセス許可の範囲を制限できます。ポリシーの各アクションが、それぞれの動作によって異なるリソースタイプと条件タイプの組み合わせをサポートします。
各 IAM ポリシーステートメントによって、リソースで実行されるアクションに対するアクセス許可が付与されます。アクションが名前の付いたリソースで動作しない場合、またはすべてのリソースに対してアクションを実行するアクセス許可を付与した場合、ポリシー内のリソースの値はワイルドカード (`*`) になります。多くのアクションでは、リソースの Amazon リソースネーム (ARN)、または複数のリソースに一致する ARN パターンを指定することによって、ユーザーによる変更が可能なリソースを制限できます。
リソースタイプ別の、アクションの範囲を制限する一般的な設計は次のとおりです。
+ 関数 - 関数を操作するアクションは、関数、バージョン、またはエイリアス ARN によって特定の関数に制限することができます。
+ イベントソースマッピング – アクションは、ARN によって特定のイベントソースマッピングリソースに制限することができます。イベントソースマッピングは常に関数に関連付けられます。また、`lambda:FunctionArn` 条件を使用して、関連する関数によってアクションを制限することもできます。
+ レイヤー - レイヤーの使用とアクセス許可に関連するアクションは、レイヤーのバージョンに影響します。
+ コード署名設定 – アクションは、ARN によって特定のコード署名設定リソースに制限することができます。
+ タグ – 標準のタグ条件を使用します。詳細については、「[Lambda での属性ベースのアクセスコントロールの使用](attribute-based-access-control.md)」を参照してください。
リソース別にアクセス許可を制限するには、ARN 別にリソースを指定します。
**Lambda リソース ARN 形式**
+ 関数 - `arn:aws:lambda:us-west-2:123456789012:function:my-function`
+ 関数のバージョン - `arn:aws:lambda:us-west-2:123456789012:function:my-function:1`
+ 関数のエイリアス - `arn:aws:lambda:us-west-2:123456789012:function:my-function:TEST`
+ イベントソースマッピング - `arn:aws:lambda:us-west-2:123456789012:event-source-mapping:fa123456-14a1-4fd2-9fec-83de64ad683de6d47`
+ レイヤー - `arn:aws:lambda:us-west-2:123456789012:layer:my-layer`
+ レイヤーバージョン - `arn:aws:lambda:us-west-2:123456789012:layer:my-layer:1`
+ コード署名設定 – `arn:aws:lambda:us-west-2:123456789012:code-signing-config:my-csc`
例えば、以下のポリシーでは、`my-function` という名前の関数を米国西部 (オレゴン) AWS リージョンで呼び出すことを、AWS アカウント `123456789012` のユーザーに対し許可します。
**Example 関数ポリシーを呼び出す**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Invoke",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:my-function"
}
]
}
```
アクションの識別子 (`lambda:InvokeFunction`) が、API オペレーション ([Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)) と異なる特別なケースです。その他のアクションのアクションの識別子は、`lambda:` プレフィックスがついたオペレーション名です。
**Topics**
+ [ポリシーの条件セクションについて](#authorization-conditions)
+ [ポリシーのリソースセクションで関数を参照する](#function-resources)
+ [サポートされている IAM アクションと関数の動作](#permissions-resources)
## ポリシーの条件セクションについて
条件は、アクションが許可されているかどうかを判断するために追加のロジックを適用するオプションのポリシー要素です。すべてのアクションでサポートされている共通の[条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)に加えて、Lambda は、一部のアクションが使用する追加パラメータの値を制限するための条件タイプも定義します。
例えば、`lambda:Principal` 条件では、関数の[リソースベースのポリシー](access-control-resource-based.md)への呼び出しアクセス権をユーザーが付与できる、サービスまたはアカウントを制限できます。次のポリシーを使用すると、ユーザーは、`test` という名前の関数を呼び出すアクセス許可を Amazon Simple Notification Service (Amazon SNS) トピックに付与できます。
**Example 関数ポリシーのアクセス許可を管理する**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageFunctionPolicy",
"Effect": "Allow",
"Action": [
"lambda:AddPermission",
"lambda:RemovePermission"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:test:*",
"Condition": {
"StringEquals": {
"lambda:Principal": "sns.amazonaws.com"
}
}
}
]
}
```
この条件では、プリンシパルが Amazon SNS で、別のサービスやアカウントでないことが必要です。リソースパターンでは、関数名が `test` で、バージョン番号またはエイリアスが含まれている必要があります。例えば、`test:v1`。
Lambda およびその他の AWS サービスのリソースと条件の詳細については、「*サービス認可リファレンス*」の「[AWS のサービスのアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)」を参照してください。
## ポリシーのリソースセクションで関数を参照する
Amazon リソースネーム (ARN) を使用して、ポリシーステートメント内で Lambda 関数を参照します。関数 ARN の形式は、関数全体を参照する (修飾)か、関数の[バージョン](configuration-versions.md)や[エイリアス](configuration-aliases.md)を参照する (非修飾) かに応じて異なります。
Lambda API コールを行うとき、ユーザーは、[GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) `FunctionName` パラメータにあるバージョン ARN またはエイリアス ARN を渡すか、 [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) `Qualifier` パラメータにある値を設定することで、バージョンまたはエイリアスを指定することができます。Lambda は、IAM ポリシー内のリソース要素を、API コールで渡された `FunctionName` と `Qualifier` の両方と比較することによって、認可の決定を行います。一致しないものがある場合、Lambda はそのリクエストを拒否します。
関数に対するアクションを許可するか拒否するかにかかわらず、期待どおりの結果を得るには、ポリシーステートメントで正しい関数の ARN タイプを使用する必要があります。例えば、ポリシーが非修飾 ARN を参照する場合、Lambda は非修飾 ARN を参照するリクエストを受け入れますが、修飾 ARN を参照するリクエストは拒否します。
**注記**
アカウント ID を照合するためにワイルドカード文字 (\$1) を使用することはできません。認められる構文の詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。
**Example 非修飾 ARN の呼び出しの許可**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction"
}
]
}
```
ポリシーが特定の修飾 ARN を参照する場合、Lambda はその ARN を参照するリクエストを受け入れますが、非修飾 ARN や別の修飾 ARN (`myFunction:2` など) を参照するリクエストは拒否します。
**Example 特定の修飾 ARN の呼び出しの許可**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:1"
}
]
}
```
ポリシーが `:*` を使用して任意の修飾 ARN を参照する場合、Lambda は修飾 ARN ならどれでも受け入れますが、非修飾 ARN を参照するリクエストは拒否します。
**Example 任意の修飾 ARN の呼び出しの許可**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
}
]
}
```
ポリシーが `*` を使用して任意の ARN を参照する場合、Lambda はすべての修飾 ARN と非修飾 ARN を受け入れます。
**Example 任意の修飾または非修飾 ARN の呼び出しの許可**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction*"
}
]
}
```
## サポートされている IAM アクションと関数の動作
アクションは、IAM ポリシーを通じて許可できる操作を定義します。Lambda でサポートされるアクションのリストについては、「サービス認可リファレンス」の「[AWS Lambda のアクション、リソース、および条件キー](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html)」を参照してください。ほとんどの場合、IAM アクションで Lambda API アクションを許可する場合、IAM アクションの名前は Lambda API アクションの名前と同じですが、以下の例外があります。
| API アクション | IAM アクション |
| --- | --- |
| [Invoke](https://docs.aws.amazon.com//lambda/latest/api/API_Invoke.html) | lambda:InvokeFunction |
| [GetLayerVersion](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersion.html) [GetLayerVersionByArn](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersionByArn.html) | lambda:GetLayerVersion |
「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html)」で定義されているリソースと条件に加えて、Lambda では特定のアクションに対して以下のリソースと条件をサポートしています。これらの多くは、ポリシーのリソースセクションの関数の参照に関連しています。以下の表で説明されているように、関数を操作するアクションは、関数、バージョン、またはエイリアス ARN によって特定の関数に制限することができます。
| Action | リソース | 条件 |
| --- | --- | --- |
| [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) (**アクセス許可:** `lambda:InvokeFunction`) | 関数のバージョン 関数のエイリアス | 該当なし |
| [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) | 該当なし | `lambda:CodeSigningConfigArn` |
| [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) | 関数のエイリアス | 該当なし |