# AWS Lambda でのセキュリティ
AWS では、クラウドのセキュリティが最優先事項です。セキュリティを最も重視する組織の要件を満たすために構築された 「AWS」 のデータセンターとネットワークアーキテクチャは、お客様に大きく貢献します。
セキュリティは、「AWS」 と顧客の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、この責任がクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明されています。
+ **クラウドのセキュリティ** — AWS は、AWS クラウドで AWS のサービス を実行するインフラストラクチャを保護する責任を負います。また AWS は、お客様が使用するサービスを安全に提供します。[「AWS」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。AWS Lambda に適用されるコンプライアンスプログラムの詳細については、「[コンプライアンスプログラムの対象範囲となる AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** - ユーザーの責任は、使用する 「AWS」 のサービスに応じて異なります。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
このドキュメントは、Lambda を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティとコンプライアンスの目的を達成するために Lambda を設定する方法を示します。また、Lambda リソースのモニタリングや保護に役立つ、他の AWS のサービスの使用方法についても説明します。
Lambda アプリケーションに対するセキュリティプリンシパルの適用の詳細については、Serverless Land の「[セキュリティ](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops)」を参照してください。
**Topics**
+ [
# AWS Lambda でのデータ保護
](security-dataprotection.md)
+ [
# Lambda 用のサービスリンクロールの使用
](using-service-linked-roles.md)
+ [
# AWS Lambda 向けの Identity and Access Management
](security-iam.md)
+ [
# Lambda 関数とレイヤーのガバナンス戦略を作成する
](governance-concepts.md)
+ [
# AWS Lambda のコンプライアンス検証
](security-compliance.md)
+ [
# AWS Lambda での耐障害性
](security-resilience.md)
+ [
# でのインフラストラクチャセキュリティAWS Lambda
](security-infrastructure.md)
+ [
# パブリックエンドポイントによるワークロードの保護
](security-public-endpoints.md)
+ [
# コード署名を使用して Lambda でコードの整合性を検証する
](configuration-codesigning.md)
# AWS Lambda でのデータ保護
AWS[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/) は、AWS Lambda でのデータ保護に適用されます。このモデルで説明されているように、AWS は、AWS クラウド のすべてを実行するグローバルインフラストラクチャを保護するがあります。お客様は、このインフラストラクチャでホストされているコンテンツに対する管理を維持する責任があります。また、使用する AWS のサービスのセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーのよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)のブログ記事を参照してください。
データを保護するため、AWS アカウント 認証情報を保護し、AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーをセットアップすることをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須であり TLS 1.3 がお勧めです。
+ AWS CloudTrail で API とユーザーアクティビティロギングをセットアップします。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「AWS CloudTrail ユーザーガイド**」の「[Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS のサービス 内のすべてのデフォルトセキュリティ管理に加え、AWS 暗号化ソリューションを使用します。
+ Amazon Macie などの高度なマネージドセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API を使用して AWS にアクセスする際に FIPS 140-3 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報は、タグ、または名前****フィールドなどの自由形式のテキストフィールドに配置しないことを強くお勧めします。これには、コンソール、API、AWS CLI、または AWS SDK を使用して Lambda またはその他の AWS のサービスを使用する状況が含まれます。名前に使用する自由記述のテキストフィールドやタグに入力したデータは、課金や診断ログに使用される場合があります。外部サーバーへの URL を提供する場合は、そのサーバーへのリクエストを検証するための認証情報を URL に含めないように強くお勧めします。
**Topics**
+ [
## 転送時の暗号化
](#security-privacy-intransit)
+ [
# AWS Lambda での静止時のデータの暗号化
](security-encryption-at-rest.md)
## 転送時の暗号化
Lambda API エンドポイントでは、HTTPS 経由の安全な接続のみがサポートされます。Lambda リソースを AWS マネジメントコンソール、AWS SDK、または Lambda API を使用して管理する場合、すべての通信は Transport Layer Security (TLS) で暗号化されます。API エンドポイントの完全なリストについては、AWS 全般のリファレンス の「[AWSリージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
[関数をファイルシステムに接続](configuration-filesystem.md)すると、Lambda では、すべての接続で転送時の暗号化が使用されます。詳細については、*Amazon Elastic File System ユーザーガイド* の「[Amazon EFS でのデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)」を参照してください。
[環境変数](configuration-envvars.md)を使用する場合、コンソール暗号化ヘルパーを有効にして、クライアント側の暗号化で転送中の環境変数を保護できます。詳細については、「[Lambda 環境変数の保護](configuration-envvars-encryption.md)」を参照してください。
# AWS Lambda での静止時のデータの暗号化
Lambda は、[AWS 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)または [AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)を使用して、次のリソースの保管時の暗号化を常に提供します。
+ 環境変数
+ デプロイパッケージやレイヤーアーカイブを含め、Lambda にアップロードされるファイル
+ イベントソースマッピングフィルター条件オブジェクト
オプションで、カスタマーマネージドキーを使用して[環境変数](configuration-envvars-encryption.md)、[.zip デプロイパッケージ](encrypt-zip-package.md)、[フィルター条件オブジェクト](invocation-eventfiltering.md#filter-criteria-encryption)を暗号化するように Lambda を設定できます。
Amazon CloudWatch Logs と AWS X-Ray は、デフォルトでデータを暗号化し、カスタマーマネージドキーを使用するように設定できます。詳細については、「[Encrypt log data in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」および「[Data protection in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html)」を参照してください。
## Lambda の暗号化キーのモニタリング
Lambda で AWS KMS カスタマーマネージドキーを使用する場合は、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) を使用します。以下は、カスタマーマネージドキーで暗号化したデータにアクセスすることを目的とした、Lambda による `Decrypt`、`DescribeKey`、および `GenerateDataKey` 呼び出しの CloudTrail イベントの例です。
------
#### [ Decrypt ]
AWS KMS カスタマーマネージドキーを使用して[フィルター条件](invocation-eventfiltering.md#filter-criteria-encryption)オブジェクトを暗号化した場合、オブジェクトへのプレーンテキストでのアクセス時 (`ListEventSourceMappings` 呼び出し経由など) に、Lambda がユーザーに代わって `Decrypt` リクエストを送信します。以下のイベント例では `Decrypt` オペレーションを記録しています。
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
AWS KMS カスタマーマネージドキーを使用して[フィルター条件](invocation-eventfiltering.md#filter-criteria-encryption)オブジェクトを暗号化した場合、オブジェクトへのアクセス時 (`GetEventSourceMapping` 呼び出し経由など) に、Lambda がユーザーに代わって `DescribeKey` リクエストを送信します。以下のイベント例では `DescribeKey` オペレーションを記録しています。
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
AWS KMS カスタマーマネージドキーを使用して `CreateEventSourceMapping` または `UpdateEventSourceMapping` 呼び出しの[フィルター条件](invocation-eventfiltering.md#filter-criteria-encryption)オブジェクトを暗号化すると、Lambda がユーザーに代わって `GenerateDataKey` リクエストを送信し、フィルター条件を暗号化するデータキーを生成します ([エンベロープ暗号化](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping))。以下のイベント例では `GenerateDataKey` オペレーションを記録しています。
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Lambda 用のサービスリンクロールの使用
Lambda は AWS Identity and Access Management (IAM) の[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスリンクロールは Lambda に直接リンクされた一意のタイプの IAM ロールです。サービスリンクロールは、Lambda による事前定義済みのロールであり、ユーザーに代わってサービスから他の AWS サービスを呼び出すために必要なアクセス許可を備えています。
Lambda は、サービスリンクロールのアクセス許可を定義し、Lambda のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。これにより、リソースへの意図しないアクセスによる許可の削除が防止され、Lambda リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、**サービスリンクロール列**内で**はい**と表記されたサービスを確認してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
## Lambda 用のサービスリンクロールのアクセス許可
Lambda は **[AWSServiceRoleForLambda]** という名前のサービスリンクロールを使用します。 サービスリンクロールは、以下のサービスを信頼してロールを引き受けます。
+ `lambda.amazonaws.com`
AWSLambdaServiceRolePolicy という名前のロールアクセス許可ポリシーを使用すると、Lambda は指定されたリソースに対して次のアクションを完了できます。
+ アクション: `ec2:ManagedResourceOperator` が `scaler.lambda.amazonaws.com` と等しい条件の `arn:aws:ec2:*:*:instance/*` で `ec2:TerminateInstances`
+ アクション: `ec2:DescribeInstanceStatus` に対する `ec2:DescribeInstances` と `*`。
ユーザー、グループ、またはロールにサービスリンクロールの作成、編集、または削除を許可するには、アクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
管理ポリシーの更新については、「[Lambda managed policies](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates)」を参照してください。
## Lambda 用のサービスリンクロールの作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で Lambda キャパシティープロバイダーを作成すると、Lambda によってサービスリンクロールが作成されます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。Lambda キャパシティープロバイダーを作成すると、Lambda によってサービスリンクロールが再度作成されます。
**AWSServiceRoleForLambda** ユースケースでサービスリンクロールを作成するのにも、IAM コンソールを使用できます。AWS CLI または AWS API では、`lambda.amazonaws.com` サービス名を使用してサービスリンクロールを作成します。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。
## Lambda 用のサービスリンクロールの編集
Lambda では、AWSServiceRoleForLambda のサービスリンクロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Lambda 用のサービスリンクロールの削除
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、積極的にモニタリングまたは保守されていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンクロールのリソースをクリーンアップする必要があります。
**注記**
リソースを削除する際に、Lambda のサービスでロールが使用されていると、削除に失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
**AWSServiceRoleForLambda が使用する Lambda リソースを削除するには**
1. アカウントからすべての Lambda キャパシティープロバイダーを削除します。これは、Lambda のコンソール、CLI または API を使用すれば可能です。
1. サービスリンクロールを削除する前に、アカウントに Lambda キャパシティプロバイダーが残っていないことを確認します。
**サービスリンクロールを IAM で手動削除するには**
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForLambda のサービスリンクロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Lambda のサービスリンクロールをサポートするリージョン
Lambda はサービスが利用可能なすべてのリージョンでサービスリンクロールの使用がサポートされているとは限りません。AWSServiceRoleForLambda は次の AWS リージョンでサポートされています。
| リージョン名 | リージョン識別子 | Lambda でのサポート |
| --- | --- | --- |
| 米国東部 (バージニア北部) | us-east-1 | はい |
| 米国東部 (オハイオ) | us-east-2 | はい |
| 米国西部 (北カリフォルニア) | us-west-1 | はい |
| 米国西部 (オレゴン) | us-west-2 | はい |
| アフリカ (ケープタウン) | af-south-1 | いいえ |
| アジアパシフィック (香港) | ap-east-1 | はい |
| アジアパシフィック (ジャカルタ) | ap-southeast-3 | はい |
| アジアパシフィック (バンコク) | ap-southeast-7 | はい |
| アジアパシフィック (ムンバイ) | ap-south-1 | はい |
| アジアパシフィック (大阪) | ap-northeast-3 | いいえ |
| アジアパシフィック (ソウル) | ap-northeast-2 | いいえ |
| アジアパシフィック (シンガポール) | ap-southeast-1 | はい |
| アジアパシフィック (シドニー) | ap-southeast-2 | はい |
| アジアパシフィック (東京) | ap-northeast-1 | はい |
| カナダ (中部) | ca-central-1 | いいえ |
| 欧州 (フランクフルト) | eu-central-1 | はい |
| 欧州 (アイルランド) | eu-west-1 | はい |
| 欧州 (ロンドン) | eu-west-2 | はい |
| 欧州 (ミラノ) | eu-south-1 | いいえ |
| 欧州 (パリ) | eu-west-3 | いいえ |
| 欧州 (ストックホルム) | eu-north-1 | いいえ |
| 中東 (バーレーン) | me-south-1 | いいえ |
| 中東 (アラブ首長国連邦) | me-central-1 | いいえ |
| 南米 (サンパウロ） | sa-east-1 | いいえ |
| AWS GovCloud (米国東部) | us-gov-east-1 | いいえ |
| AWS GovCloud (米国西部) | us-gov-west-1 | いいえ |
# AWS Lambda 向けの Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は、誰を*認証* (サインイン) し、誰に Lambda リソースの使用を*許可する* (アクセス許可を持たせる) かを制御します。IAM は、追加費用なしで使用できる AWS のサービス です。
**Topics**
+ [
## 対象者
](#security_iam_audience)
+ [
## アイデンティティによる認証
](#security_iam_authentication)
+ [
## ポリシーを使用したアクセス権の管理
](#security_iam_access-manage)
+ [
# AWS Lambda と IAM の連携方法
](security_iam_service-with-iam.md)
+ [
# AWS Lambda のアイデンティティベースのポリシーの例
](security_iam_id-based-policy-examples.md)
+ [
# AWS Lambda の AWS マネージドポリシー
](security-iam-awsmanpol.md)
+ [
# AWS Lambda ID とアクセスのトラブルシューティング
](security_iam_troubleshoot.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS Lambda ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[AWS Lambda と IAM の連携方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[AWS Lambda のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティによる認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。
AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント のルートユーザー
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。
*フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービス にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセス権の管理
AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは、アイデンティティやリソースとの関連付けに伴うアクセス許可を定義します。AWS は、プリンシパルがリクエストを行うときに、これらのポリシーを評価します。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプで付与された最大数のアクセス許可を設定できる、追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations 内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、「*IAM ユーザーガイド*」の「[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# AWS Lambda と IAM の連携方法
IAM を使用して Lambda へのアクセスを管理する前に、Lambda で使用できる IAM 機能について学びます。
| IAM 機能 | Lambda サポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | はい |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サービス固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | はい |
| [ACL](#security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | 部分的 |
| [一時認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [転送アクセスセッション (FAS)](#security_iam_service-with-iam-principal-permissions) | いいえ |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | 部分的 |
Lambda やその他の AWS サービスがほとんどの IAM 機能との連携する方法の詳細については、「IAM ユーザーガイド」の「[IAM と連携する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Lambda のアイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### Lambda のアイデンティティベースのポリシー例
Lambda のアイデンティティベースポリシーの例を確認するには、「[AWS Lambda のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Lambda 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** あり
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
リソースベースのポリシーを Lambda 関数またはレイヤーにアタッチできます。このポリシーは、関数またはレイヤー上でアクションを実行できるプリンシパルを定義します。
リソースベースのポリシーを機能またはレイヤーにアタッチする方法については、「[Lambda でのリソースベースの IAM ポリシーの表示](access-control-resource-based.md)」を参照してください。
## Lambda のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Lambda アクションのリストを確認するには、「サービス認可リファレンス」の「[AWS Lambda で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)」を参照してください。
Lambda のポリシーアクションは、アクションの前に次のプレフィックスを使用します。
```
lambda
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Lambda のアイデンティティベースポリシーの例を確認するには、「[AWS Lambda のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Lambda のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Lambda リソースのタイプとその ARN のリストを確認するには、「サービス認可リファレンス」の「[AWS Lambda で定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS Lambda で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)」を参照してください。
Lambda のアイデンティティベースポリシーの例を確認するには、「[AWS Lambda のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Lambda のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。
Lambda の条件キーのリストを確認するには、「サービス認可リファレンス」の「[AWS Lambda の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys)」を参照してください。どのアクションおよびリソースと条件キーを使用できるかについては、「[AWS Lambda で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)」を参照してください。
Lambda のアイデンティティベースポリシーの例を確認するには、「[AWS Lambda のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Lambda の ACL
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Lambda での ABAC
**ABAC (ポリシー内のタグ) のサポート:** 一部
属性ベースのアクセスコントロール (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグを付けることで、プリンシパルのタグがリソースタグと一致するときに操作を許可する ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
Lambda リソースのタグ付けの詳細については、「[Lambda での属性ベースのアクセスコントロールの使用](attribute-based-access-control.md)」を参照してください。
## Lambda で一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は、AWSリソースへの短期的なアクセスを提供し、フェデレーションの使用時またはロールの切り替え時に自動的に作成されます。AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Lambda の転送アクセスセッション
**転送アクセスセッション (FAS) のサポート:** なし
転送アクセスセッション (FAS) は、AWS のサービスを呼び出すプリンシパルの権限と、リクエスト元の AWS のサービスを合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Lambda のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
Lambda では、サービスロールは[実行ロール](lambda-intro-execution-role.md)と呼ばれます。
**警告**
実行ロールのアクセス許可を変更すると、Lambda の機能が破損する可能性があります。
## Lambda 用のサービスにリンクされたロール
**サービスにリンクされたロールをサポート**： 一部
サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
Lambda にはサービスにリンクされたロールはありませんが、Lambda@Edge にはあります。詳細については、「Amazon CloudFront デベロッパーガイド」の「[Lambda@Edge 用のサービスにリンクされたロール](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles)」を参照してください。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスリンクロールに関するドキュメントをサービスで表示するには、「**はい**」 リンクを選択します。
# AWS Lambda のアイデンティティベースのポリシーの例
デフォルトで、ユーザーとロールには Lambda リソースを作成または変更する許可がありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Lambda が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「サービス認可リファレンス」の「[AWS Lambda のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html)」を参照してください。
**Topics**
+ [
## ポリシーに関するベストプラクティス
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Lambda コンソールを使用する
](#security_iam_id-based-policy-examples-console)
+ [
## 自分の許可の表示をユーザーに許可する
](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウントで誰かが Lambda リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Lambda コンソールを使用する
AWS Lambda コンソールにアクセスするには、最小限の許可セットが必要です。これらのアクセス許可により、AWS アカウント の Lambda リソースの詳細をリスト化し表示することができます。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスを許可します。
関数開発に最小限のアクセスを許可するポリシーの例については、「」を参照してください[Lambda 関数へのアクセス権をユーザーに付与する](permissions-user-function.md) Lambda API に加えて、Lambda コンソールでは他のサービスを使用して、トリガーの設定を表示し、新しいトリガーを追加できるようにします。ユーザーが他のサービスで Lambda を使用する場合は、それらのサービスにもアクセスする必要があります。Lambda を使用して他のサービスを設定する方法の詳細については、[他の AWS サービスからのイベントを使用した Lambda の呼び出し](lambda-services.md) を参照してください。
## 自分の許可の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS Lambda の AWS マネージドポリシー
AWS マネージドポリシーは、AWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは、多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、ロールへのアクセス許可の割り当てを開始できます。
AWS マネージドポリシーは、ご利用の特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることにご注意ください。これは、すべての AWS ユーザーが使用できるようになるのを避けるためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS マネージドポリシーで定義されたアクセス許可は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、ロール) に影響します。新しい AWS のサービス を起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
**Topics**
+ [
## AWS 管理ポリシー: AWSLambda\$1FullAccess
](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [
## AWS 管理ポリシー: AWSLambda\$1ReadOnlyAccess
](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [
## AWS 管理ポリシー: AWSLambdaBasicExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [
## AWS マネージドポリシー: AWSLambdaBasicDurableExecutionRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [
## AWS 管理ポリシー: AWSLambdaDynamoDBExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [
## AWS 管理ポリシー: AWSLambdaENIManagementAccess
](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [
## AWS 管理ポリシー: AWSLambdaInvocation-DynamoDB
](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [
## AWS 管理ポリシー: AWSLambdaKinesisExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [
## AWS 管理ポリシー: AWSLambdaMSKExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [
## AWS 管理ポリシー: AWSLambdaRole
](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [
## AWS 管理ポリシー: AWSLambdaSQSQueueExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [
## AWS 管理ポリシー: AWSLambdaVPCAccessExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [
## AWS マネージドポリシー: AWSLambdaManagedEC2ResourceOperator
](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [
## AWS マネージドポリシー: AWSLambdaServiceRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [
## Lambda での AWS マネージドポリシーの更新
](#lambda-security-iam-awsmanpol-updates)
## AWS 管理ポリシー: AWSLambda\$1FullAccess
このポリシーは Lambda アクションに対するフルアクセスを付与します。また、Lambda リソースの開発と保守に使用される他の AWS サービスへのアクセス許可も付与します。
ユーザー、グループおよびロールに `AWSLambda_FullAccess` ポリシーをアタッチできます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `lambda` – プリンシパルに Lambda への完全なアクセスを許可します。
+ `cloudformation` — プリンシパルが AWS CloudFormation スタックを記述し、それらのスタック内のリソースを一覧表示できるようにします。
+ `cloudwatch` — プリンシパルが Amazon CloudWatch メトリクスを一覧表示し、メトリクスデータを取得できるようにします。
+ `ec2` — プリンシパルがセキュリティグループ、サブネット、および VPC を記述できるようにします。
+ `iam` — プリンシパルがポリシー、ポリシーバージョン、ロール、ロールポリシー、アタッチされたロールポリシー、およびロールのリストを取得できるようにします。また、このポリシーでは、プリンシパルが Lambda にロールを渡すことも許可されます。`PassRole` 許可は、関数に実行ロールを割り当てる際に使用します。`CreateServiceLinkedRole` アクセス許可は、サービスにリンクされたロールを作成するときに使用されます。
+ `kms` – プリンシパルにエイリアスの一覧表示とボリューム暗号化のキーの記述を許可します。
+ `logs` – プリンシパルがログストリームを記述し、ログイベントを取得し、ログイベントをフィルタリングし、ライブテールセッションを開始および停止できるようにします。
+ `states` — プリンシパルが AWS Step Functions 状態のマシンを記述および一覧表示できるようにします。
+ `tag` — プリンシパルがタグに基づいてリソースを取得できるようにします。
+ `xray` — プリンシパルが AWS X-Ray トレースサマリーを取得し、ID で指定されたトレースのリストを取得できるようにします。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)」を参照してください。
## AWS 管理ポリシー: AWSLambda\$1ReadOnlyAccess
このポリシーは、Lambda リソースと、Lambda リソースの開発と保守に使用される他の AWS サービスへの読み取り専用アクセスを許可します。
ユーザー、グループおよびロールに `AWSLambda_ReadOnlyAccess` ポリシーをアタッチできます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `lambda` - プリンシパルがすべてのリソースを取得して一覧表示できるようにします。
+ `cloudformation` — プリンシパルが AWS CloudFormation スタックを記述および一覧表示して、それらのスタック内のリソースを一覧表示できるようにします。
+ `cloudwatch` — プリンシパルが Amazon CloudWatch メトリクスを一覧表示し、メトリクスデータを取得できるようにします。
+ `ec2` — プリンシパルがセキュリティグループ、サブネット、および VPC を記述できるようにします。
+ `iam` — プリンシパルがポリシー、ポリシーバージョン、ロール、ロールポリシー、アタッチされたロールポリシー、およびロールのリストを取得できるようにします。
+ `kms` - プリンシパルがエイリアスを一覧表示できるようにします。
+ `logs` – プリンシパルがログストリームを記述し、ログイベントを取得し、ログイベントをフィルタリングし、ライブテールセッションを開始および停止できるようにします。
+ `states` — プリンシパルが AWS Step Functions 状態のマシンを記述および一覧表示できるようにします。
+ `tag` — プリンシパルがタグに基づいてリソースを取得できるようにします。
+ `xray` — プリンシパルが AWS X-Ray トレースサマリーを取得し、ID で指定されたトレースのリストを取得できるようにします。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaBasicExecutionRole
このポリシーは、ログを CloudWatch Logs にアップロードするための許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaBasicExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)」を参照してください。
## AWS マネージドポリシー: AWSLambdaBasicDurableExecutionRolePolicy
このポリシーは、CloudWatch Logs への書き込みアクセス許可と、Lambda の永続関数で使用される永続的実行 API への読み取り/書き込みアクセス許可を提供します。このポリシーは、Lambda の永続関数に必要な重要なアクセス許可を提供します。このアクセス許可は、永続的実行 API を使用して、関数の呼び出し全体で進行状況と状態を維持します。
ユーザー、グループおよびロールに `AWSLambdaBasicDurableExecutionRolePolicy` ポリシーをアタッチできます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `logs` – プリンシパルに、ロググループ、ログストリームの作成、CloudWatch Logs へのログイベントの書き込みを許可します。
+ `lambda` – プリンシパルが永続的実行の状態をチェックポイントし、Lambda 永続関数の永続的実行の状態を取得できるようにします。
ポリシーの詳細 (JSON ポリシードキュメントの最新バージョンを含む) を確認するには、「*AWS マネージドポリシーのリファレンスガイド*」の「[AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaDynamoDBExecutionRole
このポリシーは、Amazon DynamoDB ストリームからレコードを読み取り、CloudWatch Logs に書き込むための許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaDynamoDBExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaENIManagementAccess
このポリシーは、VPC 対応の Lambda 関数で使用される Elastic Network Interface を作成、記述、削除する許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaENIManagementAccess` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaInvocation-DynamoDB
このポリシーは Amazon DynamoDB Streams への読み取りアクセスを許可します。
ユーザー、グループおよびロールに `AWSLambdaInvocation-DynamoDB` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaKinesisExecutionRole
このポリシーは、Amazon Kinesis データストリームからイベントを読み取り、CloudWatch Logs に書き込むための許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaKinesisExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaMSKExecutionRole
このポリシーは、Amazon Managed Streaming for Apache Kafka クラスターからレコードを読み取り、アクセスし、Elastic Network Interface を管理し、CloudWatch Logs に書き込むための許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaMSKExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaRole
このポリシーは、Lambda 関数を呼び出す許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaSQSQueueExecutionRole
このポリシーは、Amazon Simple Queue Service キューからのメッセージの読み取りと削除の許可を付与し、CloudWatch Logs への書き込みの許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaSQSQueueExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)」を参照してください。
## AWS 管理ポリシー: AWSLambdaVPCAccessExecutionRole
このポリシーは、Amazon 仮想プライベートクラウド内の Elastic Network Interface を管理して、CloudWatch Logs に書き込む許可を付与します。
ユーザー、グループおよびロールに `AWSLambdaVPCAccessExecutionRole` ポリシーをアタッチできます。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)」を参照してください。
## AWS マネージドポリシー: AWSLambdaManagedEC2ResourceOperator
このポリシーは、Lambda キャパシティープロバイダーの自動 Amazon Elastic Compute Cloud インスタンス管理を有効にします。これは、ユーザーに代わってインスタンスライフサイクルオペレーションを実行するためのアクセス許可を Lambda スケーラーサービスに付与します。
ユーザー、グループおよびロールに `AWSLambdaManagedEC2ResourceOperator` ポリシーをアタッチできます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ec2:RunInstances` – ec2:ManagedResourceOperator が scaler.lambda.amazonaws.com に等しく、AMI の使用を Amazon が所有するイメージのみに制限するという条件で、Lambda が新しい Amazon EC2 インスタンスを起動できるようにします。
+ `ec2:DescribeInstances` および `ec2:DescribeInstanceStatus` – Lambda がインスタンスのステータスをモニタリングし、インスタンス情報を取得できるようにします。
+ `ec2:CreateTags` – Lambda が管理および識別の目的で Amazon EC2 リソースにタグを付けることを許可します。
+ `ec2:DescribeAvailabilityZones` – Lambda がインスタンス配置の決定に使用できるゾーンを表示できるようにします。
+ `ec2:DescribeCapacityReservations` – Lambda が最適なインスタンス配置のためにキャパシティ予約をチェックできるようにします。
+ `ec2:DescribeInstanceTypes` および `ec2:DescribeInstanceTypeOfferings` – Lambda が使用可能なインスタンスタイプとそのサービスを確認できるようにします。
+ `ec2:DescribeSubnets` – Lambda がネットワーク計画のサブネット設定を調べることを許可します。
+ `ec2:DescribeSecurityGroups` – Lambda がネットワークインターフェイス設定のセキュリティグループ情報を取得できるようにします。
+ `ec2:CreateNetworkInterface` – Lambda がネットワークインターフェイスを作成し、サブネットとセキュリティグループの関連付けを管理できるようにします。
+ `ec2:AttachNetworkInterface` – `ec2:ManagedResourceOperator` が [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/) に等しいという条件で、Lambda が Amazon EC2 インスタンスにネットワークインターフェイスをアタッチできるようにします。
JSON ポリシードキュメントやポリシーバージョンを含むこのポリシーの詳細については、「*AWS 管理ポリシーリファレンスガイド*」の「[AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)」を参照してください。
## AWS マネージドポリシー: AWSLambdaServiceRolePolicy
このポリシーは、AWSServiceRoleForLambda という名前のサービスにリンクされたロールにアタッチされ、Lambda が Lambda キャパシティプロバイダーの一部として管理されるインスタンスを終了できるようにします。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ec2:TerminateInstances` – ec2:ManagedResourceOperator が scaler.lambda.amazonaws.com に等しいという条件で、Lambda が EC2 インスタンスを終了できるようにします。
+ `ec2:DescribeInstanceStatus` および `ec2:DescribeInstances` – Lambda が EC2 インスタンスを記述できるようにします。
このポリシーに関する詳細については、「[Lambda に、サービスにリンクされたロールを使用する方法](using-service-linked-roles.md)」を参照してください。
## Lambda での AWS マネージドポリシーの更新
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) – 新しいポリシー | Lambda は、Lambda キャパシティプロバイダーの自動 Amazon EC2 インスタンス管理を有効にする新しいマネージドポリシーを追加し、スケーラーサービスがインスタンスライフサイクルオペレーションを実行できるようにしました。 | 2025 年 11 月 30 日 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – 新しいポリシー | Lambda は、サービスにリンクされたロールに新しい管理ポリシーを追加し、Lambda が Lambda キャパシティプロバイダーの一部として管理されるインスタンスを終了できるようにしました。 | 2025 年 11 月 30 日 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 変更 | Lambda は、`kms:DescribeKey` と `iam:CreateServiceLinkedRole` アクションを許可するように `AWSLambda_FullAccess` ポリシーを更新しました。 | 2025 年 11 月 30 日 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) – 新しい管理ポリシー | Lambda は、CloudWatch Logs への書き込みアクセス許可と、Lambda の永続関数で使用される永続的実行 API への読み取り/書き込みアクセス許可を提供する新しいマネージドポリシー `AWSLambdaBasicDurableExecutionRolePolicy` をリリースしました。 | 2025 年 12 月 1 日 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) および [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 変更 | Lambda は、`logs:StartLiveTail` と `logs:StopLiveTail` アクションを許可するように `AWSLambda_ReadOnlyAccess` と `AWSLambda_FullAccess` ポリシーを更新しました。 | 2025 年 3 月 17 日 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) – 変更 | Lambda は、アクション `ec2:DescribeSubnets` を許可するように `AWSLambdaVPCAccessExecutionRole` ポリシーを更新しました。 | 2024 年 1 月 5 日 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) — 変更 | Lambda は、プリンシパルが CloudFormation スタックを一覧表示できるように `AWSLambda_ReadOnlyAccess` ポリシーを更新しました。 | 2023 年 7 月 27 日 |
| AWS Lambda は変更の追跡を開始しました | AWS Lambda が AWS マネージドポリシーの変更の追跡を開始しました。 | 2023 年 7 月 27 日 |
# AWS Lambda ID とアクセスのトラブルシューティング
次の情報は、Lambda と IAM の使用に伴い発生する可能性のある、一般的な問題の診断や修復に役立ちます。
**Topics**
+ [
## Lambda でアクションを実行する権限がない
](#security_iam_troubleshoot-no-permissions)
+ [
## iam:PassRole を実行する権限がありません
](#security_iam_troubleshoot-passrole)
+ [
## 自分の AWS アカウント アカウント以外のユーザーに Lambda リソースへのアクセスを許可したい
](#security_iam_troubleshoot-cross-account-access)
## Lambda でアクションを実行する権限がない
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `lambda:GetWidget` アクセス許可を持っていない場合に発生するものです。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
この場合、`lambda:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Lambda にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールやサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Lambda でアクションを実行しようすると、発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## 自分の AWS アカウント アカウント以外のユーザーに Lambda リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Lambda でこれらの機能がサポートされるかどうかを確認するには、[AWS Lambda と IAM の連携方法](security_iam_service-with-iam.md) を参照してください。
+ 所有している AWS アカウント全体のリソースへのアクセス権を提供する方法については、*IAM ユーザーガイド*の「[所有している別の AWS アカウント アカウントへのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ サードパーティの AWS アカウント にリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[サードパーティが所有する AWS アカウント へのアクセス権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
# Lambda 関数とレイヤーのガバナンス戦略を作成する
サーバーレスのクラウドネイティブアプリケーションを構築してデプロイするには、適切なガバナンスとガードレールを備えた俊敏性と市場投入までのスピードを考慮する必要があります。ビジネスレベルの優先事項を設定し、最優先事項として俊敏性を重視したり、ガバナンス、ガードレール、統制によるリスク回避を重視したりします。現実的には、「二者択一」戦略ではなく、ソフトウェア開発ライフサイクルにおけるアジリティとガードレールの両方のバランスを取る「両立」戦略を採用することになります。これらの要件が会社のライフサイクルのどの段階にあっても、ガバナンス機能はプロセスやツールチェーンの実装要件になる可能性が高くなります。
組織が Lambda に実装する可能性のあるガバナンスコントロールの例をいくつか紹介します。
+ Lambda 関数へのパブリックアクセスを許可してはなりません。
+ Lambda 関数は VPC にアタッチされている必要があります。
+ Lambda 関数では非推奨のランタイムを使用してはなりません。
+ Lambda 関数は、必要なタグのセットでタグ付けする必要があります。
+ Lambda レイヤーは組織の外部からアクセスできないようにする必要があります。
+ セキュリティグループがアタッチされている Lambda 関数では、関数とセキュリティグループのタグが一致している必要があります。
+ レイヤーがアタッチされた Lambda 関数は承認されたバージョンを使用する必要があります
+ Lambda 環境変数は、カスタマーマネージド型キーを使用して保存時に暗号化する必要があります。
次の図は、ソフトウェアの開発とデプロイのプロセス全体にわたってコントロールとポリシーを実装する詳細なガバナンス戦略の例です。
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-concepts.png)
以下のトピックでは、スタートアップとエンタープライズの両方を対象に、組織で Lambda 関数を開発およびデプロイするためのコントロールを実装する方法について説明します。組織でツールが設定済みである場合があります。以下のトピックでは、これらのコントロールをモジュール方式で行うため、実際に必要なコンポーネントを自由に選択できます。
**Topics**
+ [
# AWS CloudFormation Guard による Lambda のプロアクティブコントロール
](governance-cloudformation-guard.md)
+ [
# AWS Config を使用して Lambda の予防的コントロールを実装する
](governance-config.md)
+ [
# AWS Config を使用して非準拠の Lambda デプロイと設定を検出する
](governance-config-detection.md)
+ [
# AWS Signer で Lambda コード署名を行う
](governance-code-signing.md)
+ [
# Amazon Inspector を使用して Lambda のセキュリティ評価を自動化する
](governance-code-scanning.md)
+ [
# Lambda のセキュリティとコンプライアンスのためのオブザーバビリティの実装
](governance-observability.md)
# AWS CloudFormation Guard による Lambda のプロアクティブコントロール
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) は、オープンソースの汎用ポリシーアズコード評価ツールです。Infrastructure as Code (IaC) テンプレートとサービス構成をポリシールールに照らして検証することで、ガバナンスとコンプライアンスの予防を行えます。これらのルールは、チームや組織の要件に基づいてカスタマイズできます。Lambda 関数の場合、Lambda 関数の作成または更新時に必要なプロパティ設定を定義することで、Guard ルールを使用してリソースの作成と設定の更新を制御できます。
コンプライアンス管理者は、Lambda 関数のデプロイと更新に必要なコントロールとガバナンスポリシーのリストを定義します。プラットフォーム管理者は、コードリポジトリを備えたコミット前の検証 Webhook として CI/CD パイプラインにコントロールを実装し、ローカルワークステーションでテンプレートとコードを検証するためのコマンドラインツールを開発者に提供します。開発者はコードを作成し、コマンドラインツールでテンプレートを検証し、コードをリポジトリにコミットします。リポジトリは、AWS 環境へのデプロイ前に CI/CD パイプラインを介して自動的に検証されます。
Guard では、以下のようにドメイン固有の言語を使用して[ルールを記述](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html)し、コントロールを実装できます。
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-cloudformation-guard.png)
例えば、開発者が必ず最新のランタイムのみを選択するように指定するとします。2 つの異なるポリシーを指定できます。1 つは廃止済みの[ランタイム](lambda-runtimes.md)を識別するためのもので、もう 1 つは間もなく廃止されるランタイムを識別するためのものです。これを行うには、以下の `etc/rules.guard` ファイルを記述します。
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
ここで、Lambda 関数を定義する次の `iac/lambda.yaml` CloudFormation テンプレートを作成するとします。
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
Guard ユーティリティを[インストール](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html)したら、テンプレートを検証します。
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
出力は次のようになります。
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard を使用すると、開発者はローカルの開発者ワークステーションを参照し、組織で許可されているランタイムを使用するにはテンプレートを更新する必要があることを確認できます。これは、コードリポジトリにコミットし、その後 CI/CD パイプライン内のチェックに失敗する前に発生します。これにより開発者がコンプライアンスに準拠したテンプレートを開発する方法に関するフィードバックを得ることができ、ビジネス価値をもたらすコードの作成に時間を割くことができます。この制御は、ローカルの開発者ワークステーション、コミット前の検証 Webhook、デプロイ前の CI/CD パイプラインに適用できます。
## 注意
AWS Serverless Application Model (AWS SAM) テンプレートを使用して Lambda 関数を定義する場合、以下のように `AWS::Serverless::Function` リソースタイプを検索するように Guard ルールを更新する必要があることに注意してください。
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard では、プロパティがリソース定義に含まれていることも想定しています。一方、AWS SAM テンプレートではプロパティを別の [[Globals]](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) セクションで指定できます。Globals セクションで定義されているプロパティは、Guard ルールでは検証されません。
Guard のトラブルシューティング[ドキュメント](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html)で説明されているように、Guard は `!GetAtt`、`!Sub` のような短縮形式の組み込み関数をサポートしておらず、`Fn::GetAtt`、`Fn::Sub` の拡張形式を使用する必要があることに注意してください。([前の例](#guard-iac-yaml)では Role プロパティを評価していないため、簡潔にするために短縮形式の組み込み関数を使用しました)。
# AWS Config を使用して Lambda の予防的コントロールを実装する
開発プロセスのできるだけ早い段階で、サーバーレスアプリケーションのコンプライアンスを確保することが不可欠です。このトピックでは、[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) を使用して予防的制御を実装する方法について説明します。これにより、開発プロセスの早い段階でコンプライアンスチェックを実装でき、CI/CD パイプラインにも同じコントロールを実装できます。また、一元管理されるルールのリポジトリでコントロールが標準化され、AWS アカウント全体にコントロールを一貫して適用できるようになります。
例えば、コンプライアンス管理者が、すべての Lambda 関数に AWS X-Ray トレースが含まれるようにする要件を定義したとします。AWS Config のプロアクティブモードを使用すると、デプロイ前に Lambda 関数リソースのコンプライアンスチェックを実行できます。不適切に設定された Lambda 関数をデプロイするリスクを軽減し、インフラストラクチャに関するフィードバックをコードテンプレートとして迅速に提供することで、開発者の時間を節約できます。以下は AWS Config による予防コントロールのフローを視覚化したものです。
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-1.png)
すべての Lambda 関数でトレースを有効にする必要があるという要件を考えてみましょう。これを受けて、プラットフォームチームは、特定の AWS Config ルールをすべてのアカウントでプロアクティブに実行する必要があると判断しました。このルールは、X-Ray トレーシング設定が設定されていない Lambda 関数を非準拠リソースとしてフラグします。チームはルールを作成し、それを[コンフォーマンスパック](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)にパッケージ化し、そのコンフォーマンスパックをすべての AWS アカウントにデプロイして、組織内のすべてのアカウントがこれらのコントロールを統一的に適用できるようにします。ルールは AWS CloudFormation Guard 2.x.x 構文で記述し、次のような形式を取ります。
```
rule name when condition { assertion }
```
以下は、Lambda 関数でトレースが有効になっていることを確認する Guard ルールのサンプルです。
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
プラットフォームチームは、すべての AWS CloudFormation デプロイで事前作成/更新[フック](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html)を呼び出すことを義務付けることで、さらなる措置を講じます。また、このフックを開発してパイプラインを構成し、コンプライアンスルールの一元管理を強化し、すべてのデプロイメントで一貫した適用を維持する全責任を負います。フックを開発、パッケージ化、登録するには、CloudFormation コマンドラインインターフェイス (CFN-CLI) ドキュメントの「[Developing AWS CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html)」を参照してください。[CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) を使用してフックプロジェクトを作成できます。
```
cfn init
```
このコマンドは、フックプロジェクトに関する基本情報の入力を求め、以下のファイルを含むプロジェクトを作成します。
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
フック開発者は、必要なターゲットリソースタイプを `.json` 設定ファイルに追加する必要があります。以下の設定では、CloudFormation を使用して Lambda 関数が作成される前にフックが実行されるように設定されています。`preUpdate` および `preDelete` アクションにも同様のハンドラーを追加できます。
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
また、CloudFormation フックに AWS Config API を呼び出すための適切な権限があることを確認する必要があります。そのためには、`hook-role.yaml` という名前のロール定義ファイルを更新します。ロール定義ファイルには、デフォルトで以下の信頼ポリシーがあります。これにより、CloudFormation がロールを引き受けることができます。
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
このフックで config API を呼び出せるようにするには、ポリシーステートメントに以下の権限を追加する必要があります。次に、`cfn submit` コマンドを使用してフックプロジェクトを送信します。ここで、CloudFormation は必要な権限を持つロールを作成します。
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
次に、Lambda 関数を `src/handler.py` ファイルに記述する必要があります。このファイルには `preCreate`、`preUpdate`、`preDelete` という名前のメソッドがあり、プロジェクトを開始したときにすでに作成されています。目的は、AWS SDK for Python (Boto3) を使用してプロアクティブモードで AWS Config `StartResourceEvaluation` API を呼び出す、再利用可能な共通関数を作成することです。この API コールは、リソースプロパティを入力として受け取り、ルール定義と照らし合わせてリソースを評価します。
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
これで、作成前フックのハンドラーから共通関数を呼び出すことができます。ハンドラーの例を示します。
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
このステップの後、フックを登録して、すべての AWS Lambda 関数作成イベントをリッスンするように設定できます。
開発者は、Lambda を使用してサーバーレスマイクロサービス用の Infrastructure as Code (IaC) テンプレートを準備します。この準備には、内部標準を順守した後に、テンプレートをローカルでテストしてリポジトリにコミットすることが含まれます。IaC テンプレート例を次に示します。
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
CI/CD プロセスの一環として、CloudFormation テンプレートがデプロイされると、CloudFormation サービスは `AWS::Lambda::Function` リソースタイプをプロビジョニングする直前に事前作成/更新フックを呼び出します。フックは、プロアクティブモードで実行されている AWS Config ルールを利用して、Lambda 関数設定に必須のトレース設定が含まれていることを確認します。フックからの応答によって次のステップが決まります。準拠していれば、フックは成功を通知し、CloudFormation はリソースのプロビジョニングを続行します。そうでない場合、CloudFormation スタックのデプロイは失敗し、パイプラインはただちに停止し、システムはその詳細を記録して後で確認できるようにします。コンプライアンス通知は、関連する利害関係者に送信されます。
フックの成功/失敗に関する情報は、CloudFormation コンソールで確認できます。
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-2.png)
CloudFormation フックのログが有効になっている場合は、フックの評価結果をキャプチャできます。以下は、失敗ステータスのフックのサンプルログです。これは、Lambda 関数で X-Ray が有効になっていないことを示しています。
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-3.png)
開発者が IaC を変更して `TracingConfig Mode` 値を `Active` に更新して再デプロイすることを選択した場合、フックは正常に実行され、スタックは Lambda リソースの作成に進みます。
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-4.png)
これにより、サーバーレスリソースを開発して AWS アカウントにデプロイするときに、AWS Config による予防的コントロールをプロアクティブモードで実装できます。AWS Config ルールを CI/CD パイプラインに統合することで、アクティブなトレーシング設定がない Lambda 関数など、非準拠のリソースのデプロイを特定し、オプションでブロックできます。これにより、最新のガバナンスポリシーに準拠するリソースのみが AWS 環境にデプロイされます。
# AWS Config を使用して非準拠の Lambda デプロイと設定を検出する
[事前評価](governance-config.md)に加えて、AWS Config は、ガバナンスポリシーに準拠していないリソースのデプロイや設定を事後的に検出することもできます。ガバナンスポリシーは、組織が新しいベストプラクティスを学び、実装するにつれて変化するため、これは重要です。
Lambda 関数をデプロイまたは更新するときに、まったく新しいポリシーを設定するシナリオを考えてみましょう。すべての Lambda 関数には、常に特定の承認された Lambda レイヤーバージョンを使用する必要があります。AWS Config を設定し、レイヤー設定の新規または更新された関数をモニタリングするようにできます。AWS Config が承認されたレイヤーバージョンを使用していない機能を検出すると、その関数は非準拠リソースとしてフラグ付けされます。オプションで、AWS Systems Manager 自動化ドキュメントを使用した修復アクションを指定することで、AWS Config がリソースを自動的に修正するように設定できます。例えば、AWS SDK for Python (Boto3) を使用して Python でオートメーションドキュメントを作成できます。これにより、非準拠関数が承認されたレイヤーバージョンを指すように更新されます。したがって、AWS Config は検出と是正の両方の制御を行い、コンプライアンス管理を自動化します。
このプロセスを次の 3 つの重要な実装フェーズに分けてみましょう。
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-detective-1.png)
## フェーズ 1: アクセスリソースの特定
まず、アカウント全体で AWS Config を有効にし、AWS Lambda 関数を記録するように設定します。これにより、AWS Config は Lambda 関数がいつ作成または更新されたかを確認できます。その後、AWS CloudFormation Guard 構文を使用して特定のポリシー違反をチェックする[カスタムポリシールール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html)を設定できます。Guard ルールには次のような一般的な形式があります。
```
rule name when condition { assertion }
```
以下は、古いレイヤーバージョンにレイヤーが設定されていないことを確認するルールのサンプルです。
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
ルールの構文と構造を理解しましょう。
+ **ルール名:** 例では、ルール名は `desiredlayer` です。
+ **条件:** この句は、ルールを確認する条件を指定します。示されている例では、条件は `configuration.layers !empty` です。つまり、設定内の `layers` プロパティが空でない場合にのみ、リソースが評価されます。
+ **アサーション:** `when` 句の後に、アサーションによってルールがチェックする内容が決まります。アサーション `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` は、Lambda レイヤの ARN のいずれかが `OldLayerArn` 値と一致しないかどうかを確認します。一致しない場合、アサーションは true でルールは成功し、一致しない場合は失敗します。
`CONFIG_RULE_PARAMETERS` は、AWS Config ルールで設定される特別なパラメータセットです。この場合、`OldLayerArn` は `CONFIG_RULE_PARAMETERS` 内部のパラメータです。これにより、ユーザーは古い、または廃止されたと思われる特定の ARN 値を指定し、ルールはその古い ARN を使用する Lambda 関数がないかをチェックします。
## フェーズ 2: 視覚化と設計
AWS Config は、設定データを収集し、そのデータを Amazon Simple Storage Service (Amazon S3) バケットに保存します。[Amazon Athena](https://aws.amazon.com/athena/) を使用して、S3 バケットから直接このデータをクエリできます。Athena を使用すると、このデータを組織レベルで集約し、すべてのアカウントにわたるリソース構成の全体像を生成できます。リソース設定データの集約を設定するには、AWS クラウド運用と管理ブログの「[Athena と Amazon Quick による AWS Config データの視覚化](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)」を参照してください。
以下は、特定のレイヤー ARN を使用してすべての Lambda 関数を識別する Athena クエリのサンプルです。
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
クエリの結果は次のとおりです。
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-detective-2.png)
組織全体で AWS Config データを集約したら、[Amazon Quick](https://aws.amazon.com/quicksight/) を使用してダッシュボードを作成できます。Athena の結果を Quick にインポートすることで、Lambda 関数がレイヤーバージョンのルールにどれ程度忠実に適合しているかを視覚化することができます。このダッシュボードでは、[次のセクション](#governance-config-detective-implement)で説明するように、準拠しているリソースと準拠していないリソースをハイライト表示できるため、施行ポリシーを決定するのに役立ちます。以下の画像は、組織内の機能に適用されるレイヤーバージョンの分布をレポートするダッシュボードの例です。
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-config-detective-3.png)
## フェーズ 3: 実装と適用
[フェーズ 1](#governance-config-detective-identify) で作成したレイヤーバージョンルールを、Systems Manager 自動化ドキュメントによる修復アクションとオプションで組み合わせることができるようになりました。このドキュメントは、AWS SDK for Python (Boto3) で記述した Python スクリプトとして作成します。このスクリプトは Lambda 関数ごとに [UpdateFunctionConfiguration API](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) アクションを呼び出し、新しいレイヤー ARN を使用して関数設定を更新します。あるいは、スクリプトでコードリポジトリにプルリクエストを送信し、レイヤー ARN を更新することもできます。これにより、今後のコードのデプロイも正しいレイヤー ARN で更新されます。
# AWS Signer で Lambda コード署名を行う
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) は完全マネージド型のコード署名サービスで、コードをデジタル署名と照合して検証し、コードが変更されていないこと、信頼できるパブリッシャーからのものであることを確認できます。AWS Signer を AWS Lambda と併用して、AWS 環境へのデプロイ前に機能やレイヤーが変更されていないことを確認できます。これにより、認証情報を取得して新しい機能を作成したり、既存の機能を更新したりする悪意のある攻撃者から組織を保護できます。
Lambda 関数のコード署名を設定するには、まずバージョニングを有効にして S3 バケットを作成します。その後、AWS Signer を使用して署名プロファイルを作成し、プラットフォームに Lambda を指定し、署名プロファイルの有効日数を指定します。例：
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
次に、署名プロファイルを使用して、Lambda で署名設定を作成します。署名設定で、想定していたデジタル署名と一致しないアーティファクトが見つかった場合、「警告」(ただしデプロイは許可) または「強制」 (デプロイをブロックする) のいずれかの対処方法を指定する必要があります。以下の例は、デプロイメントを強制し、ブロックするように設定されています。
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
これで、AWS Signer が信頼できないデプロイをブロックするよう Lambda で設定できました。機能リクエストのコーディングが完了し、関数をデプロイする準備ができたと仮定しましょう。最初のステップは、適切な依存関係を含めてコードを圧縮し、作成した署名プロファイルを使用してアーティファクトに署名することです。そのためには、zip アーティファクトを S3 バケットにアップロードし、署名ジョブを開始します。
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
`jobId` は送信先バケットで作成されるオブジェクトでプレフィックスであり、`jobOwner` はジョブが実行された AWS アカウント の 12 桁 ID である出力が得られます。
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
これで、署名された S3 オブジェクトと作成したコード署名設定を使用して関数をデプロイできます。
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
あるいは、元の署名されていないソース ZIP アーティファクトを使用して関数デプロイをテストすることもできます。デプロイに失敗し、以下のメッセージが表示されます。
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
AWS Serverless Application Model (AWS SAM) を使用して関数をビルドしてデプロイする場合、package コマンドは zip アーティファクトを S3 にアップロードし、署名ジョブを開始して署名されたアーティファクトを取得します。以下のコマンドとパラメータで、これを行えます。
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer は、アカウントにデプロイされた zip アーティファクトがデプロイ対象として信頼されていることを確認するのに役立ちます。上記のプロセスを CI/CD パイプラインに含め、前のトピックで説明した手法を使用してすべての機能にコード署名設定を添付することを要求できます。Lambda 関数のデプロイでコード署名を使用することにより、関数を作成または更新するための認証情報を取得した悪意のあるアクターが関数に悪意のあるコードを挿入するのを防ぐことができます。
# Amazon Inspector を使用して Lambda のセキュリティ評価を自動化する
[Amazon Inspector](https://aws.amazon.com/inspector/) は、既知のソフトウェアの脆弱性や意図しないネットワークの露出について、ワークロードを継続的にスキャンする脆弱性管理サービスです。Amazon Inspector が生成する検出結果は、脆弱性を説明し、影響を受けるリソースを特定し、脆弱性の重要度を評価し、修正ガイダンスを提供します。
Amazon Inspector サポートにより、Lambda 関数とレイヤーのセキュリティ脆弱性評価が継続的かつ自動的に行われます。Amazon Inspector では、2 種類の Lambda スキャンを提供しています。
+ **Lambda 標準スキャン (デフォルト):** Lambda 関数とそのレイヤー内のアプリケーションの依存関係をスキャンして、[パッケージの脆弱性](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package)がないか調べます。
+ **Lambda コードスキャン:** Lambda 関数内のカスタムアプリケーションコードをスキャンして、[コードの脆弱性](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code)がないか調べます。Lambda 標準スキャンをアクティブ化することも、Lambda コードスキャンと同時に Lambda 標準スキャンをアクティブ化することもできます。
Amazon Inspector を有効にするには、[Amazon Inspector コンソール](https://console.aws.amazon.com/inspector/)に移動し、**[設定]** セクションを展開して **[アカウント管理]** を選択します。**[アカウント]** タブで **[有効化]** を選択し、スキャンオプションのいずれかを選択します。
Amazon Inspector をセットアップするときに、複数のアカウントで Amazon Inspector を有効にし、組織の Amazon Inspector を管理するためのアクセス権限を特定のアカウントに委任できます。有効にする際には、`AWSServiceRoleForAmazonInspector2` ロールを作成して Amazon Inspector にアクセス権限を付与する必要があります。Amazon Inspector コンソールで、ワンクリックオプションを使用してこのロールを作成できます。
Lambda の標準スキャンでは、Amazon Inspector は、次のような状況で Lambda 関数の脆弱性スキャンを開始します。
+ Amazon Inspector が既存の Lambda 関数を検出した時。
+ 新しい Lambda 関数をデプロイした時。
+ 既存の Lambda 関数またはそのレイヤーのアプリケーションコードまたは依存関係に更新がデプロイされた場合。
+ Amazon Inspector がデータベースに新しい共通脆弱性識別子 (CVE) 項目を追加し、その CVE が関数に関連している場合。
Lambda コードスキャンでは、Amazon Inspector は、自動推論と機械学習を使用して Lambda 関数のアプリケーションコードを評価し、アプリケーションコードを分析して全体的なセキュリティコンプライアンスを確認します。Amazon Inspector が Lambda 関数のアプリケーションコードに脆弱性を検出すると、Amazon Inspector は詳細な **[コード脆弱性]** の検出結果を生成します。可能な検出のリストについては、「[Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/)」を参照してください。
結果を確認するには、[Amazon Inspector コンソール](https://console.aws.amazon.com/inspector/)にアクセスしてください。**[結果]** メニューで **[Lambda 関数別]** を選択すると、Lambda 関数で実行されたセキュリティスキャン結果が表示されます。
Lambda 関数を標準スキャンから除外するには、関数に次のキーと値のペアをタグ付けします。
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
コードスキャンから Lambda 関数を除外するには、関数に次のキーと値のペアをタグ付けします。
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
例えば、以下の画像では、Amazon Inspector は脆弱性を自動的に検出し、検出結果を **[コード脆弱性]** という種類に分類しています。これは、脆弱性がコード依存ライブラリのいずれにもなく、関数のコードにあることを示します。特定の機能または複数の機能について、これらの詳細を一度に確認できます。
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-code-scanning-1.png)
これらの検出結果を 1 つずつ詳しく調べて、問題を解決する方法を知ることができます。
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-code-scanning-2.png)
Lambda 関数を使用する際は、必ず Lambda 関数の命名規則に準拠するようにしてください。詳細については、「[Lambda 環境変数の操作](configuration-envvars.md)」を参照してください。
修復案を承認する責任はユーザーにあります。修復案を受け入れる前に、必ず確認してください。コードが意図したとおりに動作するように、修正案の編集が必要となる場合があります。
# Lambda のセキュリティとコンプライアンスのためのオブザーバビリティの実装
AWS Config は、非準拠の AWS サーバーレスリソースを見つけて修正するのに便利なツールです。サーバーレスリソースに加えた変更はすべて AWS Config に記録されます。さらに、AWS Config では、設定スナップショットデータを S3 に保存できます。Amazon Athena と Amazon Quick を使用して、ダッシュボードを作成し、AWS Config データを表示できます。[AWS Config を使用して非準拠の Lambda デプロイと設定を検出する](governance-config-detection.md) では、Lambda レイヤーのような特定の設定を視覚化する方法について説明しました。このトピックでは、これらの概念について詳しく説明します。
## Lambda 設定の可視性
クエリを使用して、AWS アカウント ID、リージョン、AWS X-Ray トレーシング設定、VPC 設定、メモリサイズ、ランタイム、タグなどの重要な設定を取得できます。Athena からこの情報を取得するために使用できるクエリ例を次に示します。
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
クエリを使用して Quick ダッシュボードを構築し、データを視覚化することができます。AWS リソース設定データを集約し、Athena でテーブルを作成し、Athena から取得するデータに基づいて Quick ダッシュボードを構築する方法については、「AWS クラウド運用と管理」ブログの「[Athena と Amazon QuickSight を使用して AWS Config データを視覚化する](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)」を参照してください。特に、このクエリは関数のタグ情報も取得します。これにより、特にカスタムタグを使用する場合に、ワークロードと環境をより深く把握できます。
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-1.png)
実行できるアクションの詳細については、このトピックで後述する [オブザーバビリティに関する検出結果への対処](#governance-observability-addressing) セクションを参照してください。
## Lambda コンプライアンスの可視性
AWS Config で生成されたデータを使用して、コンプライアンスを監視するための組織レベルのダッシュボードを作成できます。これにより、以下の項目を一貫して追跡およびモニタリングできます。
+ コンプライアンススコアによるコンプライアンスパック
+ 非準拠リソースによるルール
+ コンプライアンスステータス
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-2.png)
各ルールをチェックして、そのルールに適合していないリソースを特定します。例えば、組織ですべての Lambda 関数を VPC に関連付けることが義務付けられていて、コンプライアンスを識別する AWS Config ルールをデプロイしている場合は、上のリストから `lambda-inside-vpc` ルールを選択できます。
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-3.png)
実行できるアクションの詳細については、以下の [オブザーバビリティに関する検出結果への対処](#governance-observability-addressing) セクションを参照してください。
## Security Hub CSPM を使用した Lambda 関数の境界の可視化
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-4.png)
Lambda を含む AWS サービスを安全に使用するために、AWS は基礎セキュリティのベストプラクティス v1.0.0 を導入しました。この一連のベストプラクティスは、AWS 環境内のリソースとデータを保護するための明確なガイドラインを提供し、強固なセキュリティ体制を維持することの重要性を強調しています。AWS Security Hub CSPM は、セキュリティとコンプライアンスの統合センターを提供することで、これを補完しています。Amazon Inspector、AWS Identity and Access Management Access Analyzer、Amazon GuardDuty などの複数の AWS サービスからセキュリティ結果を集計、整理、優先順位付けします。
AWS 組織内で Security Hub CSPM、Amazon Inspector、IAM アクセスアナライザー、および GuardDuty が有効になっている場合、Security Hub CSPM はこれらのサービスからの検出結果を自動的に集計します。例えば、Amazon Inspector を考えてみましょう。Security Hub CSPM を使用すると、Lambda 関数のコードとパッケージの脆弱性を効率的に特定できます。Security Hub CSPM コンソールで、「**AWS 統合からの最新の調査結果**」というラベルの付いた一番下のセクションに移動します。ここでは、さまざまな統合 AWS サービスから得られた結果を表示して分析できます。
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-5.png)
詳細を確認するには、2 番目の列の **[結果を参照]** リンクを選択します。これにより、Amazon Inspector などの製品別にフィルタリングされた結果のリストが表示されます。検索を Lambda 関数に限定するには、`ResourceType` を `AwsLambdaFunction` に設定します。これには、Lambda 関数に関連する Amazon Inspector からの結果が表示されます。
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/governance-observability-6.png)
GuardDuty では、疑わしいネットワークトラフィックパターンを特定できます。このような異常は、Lambda 関数内に潜在的に悪意のあるコードが存在することを示唆している可能性があります。
IAM Access Analyzer を使用すると、ポリシー、特に外部エンティティへの関数アクセスを許可する条件ステートメントを含むポリシーを確認できます。さらに、IAM アクセスアナライザーは、Lambda API の [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) オペレーションを `EventSourceToken` と共に使用したときに設定されたアクセス権限を評価します。
## オブザーバビリティに関する検出結果への対処
Lambda 関数の設定は多岐にわたり、要件も異なるため、標準化された修正自動化ソリューションがすべての状況に適しているとは限りません。さらに、変更の実装方法は環境によって異なります。準拠していないと思われる設定が見つかった場合は、以下のガイドラインを検討してください。
1. **タグ付け戦略**
包括的なタグ付け戦略を実装することをお勧めします。各 Lambda 関数には、次のような重要な情報をタグ付けする必要があります。
+ **オーナー:** 関数の責任を負う個人またはチーム。
+ **環境:** 本番、ステージング、開発、またはサンドボックス。
+ **アプリケーション:** この関数が属するより広いコンテキスト (該当する場合)。
1. **オーナーへの働きかけ**
重大な変更 (VPC 設定の調整など) は自動化せず、準拠していない機能 (所有者タグで識別) の所有者に事前に連絡し、次のいずれかを行うための十分な時間を確保してください。
+ Lambda 関数の非準拠設定を調整します。
+ 説明をして例外をリクエストするか、コンプライアンス基準を改定してください。
1. **構成管理データベース (CMDB) のメンテナンス**
タグはコンテキストをすぐに提供できますが、一元管理された CMDB を管理することでより深い洞察を得ることができます。各 Lambda 関数、依存関係、その他の重要なメタデータに関するより詳細な情報を保持できます。CMDB は、監査、コンプライアンスチェック、および関数所有者の特定において非常に貴重なリソースです。
サーバーレスインフラストラクチャの状況は絶えず進化しているため、監視に対して積極的な姿勢をとることが不可欠です。AWS Config、Security Hub CSPM、Amazon Inspector などのツールを使用すると、潜在的な異常や非準拠の設定を迅速に特定できます。ただし、ツールだけでは完全なコンプライアンスや最適な構成を保証することはできません。これらのツールを、十分に文書化されたプロセスやベストプラクティスと組み合わせることが重要です。
+ **フィードバックループ:** 是正措置を講じたら、必ずフィードバックループを実施してください。つまり、コンプライアンス違反のリソースを定期的に見直して、更新されていないか、同じ問題がまだ発生していないかを確認します。
+ **文書化:** 観察結果、実施した措置、および認められた例外事項を必ず文書化してください。適切な文書化は、監査時に役立つだけでなく、今後のコンプライアンスとセキュリティを向上させるためのプロセスを強化するのにも役立ちます。
+ **トレーニングと啓発:** すべての利害関係者、特に Lambda 関数の所有者に定期的にトレーニングを実施し、ベストプラクティス、組織ポリシー、コンプライアンス義務について周知徹底するようにします。定期的なワークショップ、ウェビナー、トレーニングセッションなどは、セキュリティとコンプライアンスに関して全員が同じ認識を持つようにするのに大いに役立ちます。
結論として、ツールやテクノロジーは潜在的な問題を検出して報告するための強力な機能を備えていますが、理解、コミュニケーション、トレーニング、文書化といった人的要素が極めて重要です。これらを合わせることで、Lambda 関数と広範なインフラストラクチャがコンプライアンス、安全性を維持し、ビジネスニーズに合わせて最適化されることを保証する強力な組み合わせになります。
# AWS Lambda のコンプライアンス検証
サードパーティーの監査者は、複数の AWS Lambda コンプライアンスプログラムの一環として AWS のセキュリティとコンプライアンスを評価します。これらのプログラムには、SOC、PCI、FedRAMP、HIPAA などが含まれます。
特定のコンプライアンスプログラムの範囲内の AWS サービスのリストについては、「[コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。一般的な情報については、「[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
AWS Artifact を使用して、サードパーティーの監査レポートをダウンロードできます。詳細については、[AWS Artifact のレポートのダウンロード](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)を参照してください。
Lambda を使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。ガバナンスコントロールを実装して、会社の Lambda 関数がコンプライアンス要件を満たしていることを確認できます。詳細については、「[Lambda 関数とレイヤーのガバナンス戦略を作成する](governance-concepts.md)」を参照してください。
# AWS Lambda での耐障害性
AWS のグローバルインフラストラクチャは AWS リージョンとアベイラビリティーゾーンを中心に構築されます。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立し隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。
AWS のリージョンとアベイラビリティーゾーンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
Lambda では、AWS グローバルインフラストラクチャに加えて、データの耐障害性とバックアップのニーズに対応できるように複数の機能を提供しています。
+ **バージョニング** - バージョニングは、Lambda で使用して、開発時に関数のコードと設定を保存できます。エイリアスと合わせてバージョニングを使用して、Blue/Green デプロイおよびローリングデプロイを実行できます。詳細については、「[Lambda 関数のバージョンを管理する](configuration-versions.md)」を参照してください。
+ **スケーリング** — 関数が前のリクエストの処理中にリクエストを受信すると、Lambda が、増えた負荷を処理するために、関数の別のインスタンスを起動します。Lambda は、リージョンごとに 1,000 回の同時実行を処理するように、自動的にスケーリングされます。[クォータ](gettingstarted-limits.md)は必要に応じて増やすことができます。詳細については、「[Lambda 関数のスケーリングについて](lambda-concurrency.md)」を参照してください。
+ **高可用性** - Lambda は、複数のアベイラビリティーゾーンで関数を実行し、1 つのゾーンでサービスの中断が発生した場合にも、関数をイベントの処理に使用できることを保証します。お客様のアカウントで Virtual Private Cloud (VPC) に接続するように関数を設定する場合は、複数のアベイラビリティーゾーンでサブネットを指定することで、高可用性を確保します。詳細については、「[Lambda 関数に Amazon VPC 内のリソースへのアクセスを許可する](configuration-vpc.md)」を参照してください。
+ **リザーブド同時実行** - 関数が常にスケーリングして、追加リクエストを処理できるようにするため、関数に同時実行を予約できます。関数に予約された同時実行を設定することにより、指定した数の同時呼び出し数までスケーリングできますが、これを超えることはありません。これにより、利用可能なすべての同時実行数が他の関数に消費されているために、リクエストを失うことがありません。詳細については、「[関数に対する予約済み同時実行数の設定](configuration-concurrency.md)」を参照してください。
+ **非同期呼び出し** - 非同期呼び出しと、他のサービスによってトリガーされた呼び出しのサブセットの場合、エラーが発生すると、Lambda は、再試行の間に遅延を置きながら、自動的に再試行します。関数を同期的に呼び出すその他のクライアントと AWS のサービスが、再試行の実行を担当します。詳細については、「[Lambda での再試行動作について](invocation-retries.md)」を参照してください。
+ **デッドレターキュー** - 非同期呼び出しでは、すべての再試行に失敗した場合、Lambda を設定してデッドレターキューにリクエストを送信することができます。デッドレターキューは、Amazon SNS のトピックまたはトラブルシューティングまたは再処理のためにイベントを受信する Amazon SQS キューです。詳細については、「[デッドレターキューの追加](invocation-async-retain-records.md#invocation-dlq)」を参照してください。
# でのインフラストラクチャセキュリティAWS Lambda
マネージドサービスである AWS Lambda は AWS グローバルネットワークセキュリティで保護されています。AWSセキュリティサービスと AWS がインフラストラクチャを保護する方法については、「[AWSクラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスにより AWS 環境を設計するには、「*セキュリティの柱 - AWS Well-Architected フレームワーク*」の「[インフラストラクチャ保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が発行している API 呼び出しを使用して、ネットワーク経由で Lambda にアクセスします。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
# パブリックエンドポイントによるワークロードの保護
パブリックにアクセス可能なワークロードに対して、AWS は、特定のリスクを軽減するのに役立つ多くの機能とサービスを提供しています。このセクションでは、アプリケーションユーザーの認証と認可、および API エンドポイントの保護について説明します。
## 認証と認可
認証はアイデンティティに関連しており、認可はアクションを指します。認証を使用して Lambda 関数を呼び出すことができるユーザーを制御し、認可を使用して実行できる操作を制御します。多くのアプリケーションでは、両方の制御メカニズムを管理するのに IAM で十分です。
ウェブアプリケーションやモバイルアプリケーションなどの外部ユーザーを持つアプリケーションでは、[JSON ウェブトークン (JWT)](https://jwt.io/introduction/) を使用して認証と認可を管理するのが一般的です。従来のサーバーベースのパスワード管理とは異なり、JWT はすべてのリクエストでクライアントから渡されます。これらは、クライアントから渡されたデータを使用してアイデンティティとクレームを検証する暗号的に安全な方法です。Lambda ベースのアプリケーションの場合、認証を中央サーバーに依存することなく、各 API エンドポイントへのすべての呼び出しを保護できます。
登録、認証、アカウント復旧、その他の一般的なアカウント管理オペレーションを処理できるユーザーディレクトリサービスである [Amazon Cognito を使用して JWT を実装](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)できます。[Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) は、このサービスをフロントエンドアプリケーションに簡単に統合するためのライブラリを提供しています。[Auth0](https://auth0.com/) などのサードパーティーのパートナーサービスを使用することも検討できます。
ID プロバイダーサービスの重要なセキュリティ上の役割を考慮すると、アプリケーションを保護するために専門的なツールを使用することが重要です。認証または認可を処理するために独自のサービスを作成することはお勧めしません。カスタムライブラリに脆弱性があると、ワークロードとそのデータのセキュリティに大きな影響を与える可能性があります。
## API エンドポイントの保護
サーバーレスアプリケーションの場合、バックエンドアプリケーションをパブリックで提供する方法には、Amazon API Gateway を使用することをお勧めします。これにより、悪意のあるユーザーやトラフィックの急増から API を保護できます。
API Gateway では、サーバーレスデベロッパー向けに [REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) と [HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) という 2 つのエンドポイントタイプを用意しています。どちらも [AWS Lambda を使用した認証](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)、IAM、Amazon Cognito をサポートしています。IAM または Amazon Cognito を使用する場合、受信リクエストが評価され、必要なトークンが欠落しているか、無効な認証が含まれているとリクエストは拒否されます。これらのリクエストは課金されず、スロットリングクォータにもカウントされません。
未認証の API ルートには、パブリックインターネット上の誰でもアクセスできる可能性があるため、未認証 API の使用は制限することをお勧めします。未認証 API を使用する必要がある場合、[サービス拒否](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS) 攻撃などの一般的なリスクから保護することが重要です。[これらの API に AWS WAF を適用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)すると、アプリケーションをSQL インジェクションおよびクロスサイトスクリプティング (XSS) 攻撃から保護できるようになります。API Gateway は API キーが使用されるとき、AWS アカウントレベルおよびクライアントごとのレベルで[スロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)も実装します。
多くの場合、未認証 API が提供する機能は、代替アプローチで実現できます。例えば、ウェブアプリケーションでは、ログインしていないユーザーに対して DynamoDB テーブルから顧客向け小売店舗のリストを提供するとします。このリクエストは、フロントエンドのウェブアプリケーションから、または URL エンドポイントを呼び出す他のソースから発信される可能性があります。この図は、3 つの解決策を比較したものです。
![\[セキュリティオペレーションの図 5\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/security-ops-figure-5.png)
1. この未認証 API は、インターネット上の誰でも呼び出すことができます。サービス拒否攻撃では、API スロットリング制限、Lambda 同時実行数、または基盤となるテーブルにおける DynamoDB でプロビジョニングされた読み取り容量を使い果たす可能性があります。
1. 適切な[有効期限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) 設定を持つ API エンドポイントの前に CloudFront 配信を配置すると、データを取得するための基盤となるソリューションを変更することなく、DoS 攻撃のトラフィックをほとんど吸収します。
1. または、まれに変更される静的データの場合、CloudFront 配信は Amazon S3 バケットからのデータを処理できます。
# コード署名を使用して Lambda でコードの整合性を検証する
コード署名を使用すると、信頼できるコードのみが Lambda 関数にデプロイされるようにできます。AWS Signer を使用すると、関数のデジタル署名付きコードパッケージを作成できます。[コード署名の設定を関数に追加](configuration-codesigning-create.md)すると、Lambda はすべての新しいコードデプロイが信頼できるソースによって署名されていることを検証します。コード署名の検証チェックはデプロイ時に実行されるため、関数の実行に影響しません。
**重要**
コード署名の設定では、署名なしコードの新規デプロイのみが防止されます。署名なしコードがある既存の関数にコード署名の設定を追加した場合、そのコードは新しいコードパッケージをデプロイするまで実行され続けます。
関数に対してコード署名を有効にする場合、関数に追加するすべての[レイヤー](chapter-layers.md)も許可された署名プロファイルによって署名されている必要があります。
AWS Lambda での AWS Signer またはコード署名の使用には、追加料金は発生しません。
## 署名の検証
ユーザーが署名付きコードパッケージを関数にデプロイすると、Lambda により次の検証チェックが実行されます。
1. **整合性**: コードパッケージが、署名されてから変更されていないことを検証します。Lambda が、パッケージのハッシュと署名からのハッシュを比較します。
1. **有効期限**: コードパッケージの署名が有効期限切れになっていないことを検証します。
1. **不一致**: 許可された署名プロファイルによってコードパッケージが署名されていることを検証します。
1. **失効**: コードパッケージの署名が取り消されていないことを検証します。
コード署名の設定を作成するときは、[UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) パラメータを使用して、有効期限、不一致、または失効のチェックが失敗した場合に Lambda がどのように対応するかを指定できます。以下のいずれかのアクションを選択できます。
+ `Warn`: これはデフォルトの設定です。Lambda はコードパッケージのデプロイを許可しますが、警告を発行します。Lambda は、新しい Amazon CloudWatch メトリクス (`SignatureValidationErrors`) を発行し、警告を CloudTrail ログに保存します。
+ `Enforce`: Lambda は (`Warn` アクションと同じように) 警告を発行し、コードパッケージのデプロイをブロックします。
**Topics**
+ [
## 署名の検証
](#config-codesigning-valid)
+ [
# Lambda のコード署名の設定を作成する
](configuration-codesigning-create.md)
+ [
# Lambda コード署名設定用の IAM ポリシーの設定
](config-codesigning-policies.md)
+ [
# コード署名設定でのタグの使用
](tags-csc.md)
# Lambda のコード署名の設定を作成する
関数でコード署名を有効にするには、*コード署名の設定*を作成し、その設定を関数にアタッチします。コード署名の設定では、許可済みの署名プロファイルのリストと、検証チェックが失敗した場合に実行するポリシーアクションを定義します。
**注記**
コンテナイメージとして定義された関数では、コード署名はサポートされません。
**Topics**
+ [
## 構成の前提条件
](#config-codesigning-prereqs)
+ [
## コード署名の設定を作成する
](#config-codesigning-config-console)
+ [
## 関数のコード署名を有効化する
](#config-codesigning-function-console)
## 構成の前提条件
Lambda 関数用のコード署名を設定する前に、AWS Signer を使用して次の操作を実行します。
+ 1 つまたは複数の[署名プロファイル](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html)を作成します。
+ 署名プロファイルを使用して、[関数の署名付きコードパッケージを作成](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html)します。
## コード署名の設定を作成する
コード署名の設定では、許可された署名プロファイルと署名検証ポリシーのリストを定義します。
**コード署名設定を (コンソールで) 作成するには、**
1. Lambda コンソールの [[Code signing configurations (コード署名設定)] ページ)](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)を開きます。
1. **[設定を作成]** を選択します。
1. [**説明**] に、その設定のための、分かりやすい名前を入力します。
1. [**署名プロファイル**] に、設定のための署名プロファイルを (最大 20 個まで) 追加します。
1. [**署名プロファイルバージョンの ARN**] から、使用するプロファイルバージョンの Amazon リソースネーム (ARN) を選択します。あるいは、そこに ARN を入力します。
1. 署名プロファイルを追加するには、[**署名プロファイルの追加**] をクリックします。
1. [**署名の検証ポリシー**] で、[**警告 **] または [**強制**] を選択します。
1. **[設定を作成]** を選択します。
## 関数のコード署名を有効化する
関数のコード署名を有効にするには、コード署名の設定を関数に追加します。
**重要**
コード署名の設定では、署名なしコードの新規デプロイのみが防止されます。署名なしコードがある既存の関数にコード署名の設定を追加した場合、そのコードは新しいコードパッケージをデプロイするまで実行され続けます。
**コード署名の設定を (コンソールで) 関数に関連付けるには**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. コード署名を有効にする関数を選択します。
1. **[設定]** タブを開きます。
1. 下にスクロールし、**[コード署名]** を選択します。
1. **[編集]** を選択します。
1. **[コード署名を編集]** で、対象の関数に関連付けるコード署名の設定を選択します。
1. **[保存]** を選択します。
# Lambda コード署名設定用の IAM ポリシーの設定
Lambda コード署名 API オペレーションにアクセスする権限をユーザーに付与するには、1 つ以上のポリシーステートメントをそのユーザーのポリシーにアタッチします。ユーザーポリシーの詳細については、「[Lambda のアイデンティティベースの IAM ポリシー](access-control-identity-based.md)」を参照してください。
次に示すポリシーステートメントの例では、コード署名の設定を作成、更新、および取得するためのアクセス権限を付与しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
管理者は、`CodeSigningConfigArn` 条件キーを使用して、デベロッパーが関数を作成または更新する際に必要となる、コード署名の設定を指定できます。
次に示すポリシーステートメントの例では、関数を作成するための権限を付与しています。ポリシーステートメントには、許可されるコード署名設定を指定する `lambda:CodeSigningConfigArn` 条件を含めます。[CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) パラメータが欠如しているか、条件の値と一致しない場合、Lambda は `CreateFunction` API リクエストをブロックします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# コード署名設定でのタグの使用
コード署名設定にタグを付けて、リソースを整理および管理できます。タグは、AWS のサービス間でサポートされているリソースに関連付けられた自由形式のキーと値のペアです。タグのユースケースの詳細については、「*タグ付け AWS リソースとタグエディタガイド*」の「[一般的なタグ付け戦略](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)」を参照してください。
AWS Lambda API を使用して、タグを表示および更新できます。Lambda コンソールで特定のコード署名設定を管理しながら、タグを表示および更新することもできます。
**Topics**
+ [
## タグの操作に必要なアクセス許可
](#csc-tags-required-permissions)
+ [
## Lambda コンソールでのタグの使用
](#tags-csc-console)
+ [
## AWS CLIでのタグの使用
](#tags-csc-cli)
## タグの操作に必要なアクセス許可
AWS Identity and Access Management (IAM) ID (ユーザー、グループ、ロール) がリソースのタグを読み取るまたは設定できるようにするには、以下の対応するアクセス許可を付与します。
+ **lambda:ListTags** – リソースがタグ付けされている場合は、そのリソースで `ListTags` を呼び出す必要があるすべてのユーザーに対し、このアクセス許可を付与します。タグ付き関数の場合、このアクセス許可は `GetFunction` にも必要です。
+ **lambda:TagResource** – 作成時に `TagResource` を呼び出すかタグを実行する必要があるすべてのユーザーにこのアクセス許可を付与します。
必要に応じて、**Lambda:UntagResource** アクセス許可も付与して、リソースへの `UntagResource` 呼び出しを許可することを検討してください。
詳細については、「[Lambda のアイデンティティベースの IAM ポリシー](access-control-identity-based.md)」を参照してください。
## Lambda コンソールでのタグの使用
Lambda コンソールを使用して、タグを持つコード署名設定を作成し、既存のコード署名設定にタグを追加して、コード署名設定をタグでフィルタリングできます。
**コード署名設定の作成時にタグを追加するには**
1. Lambda コンソールの [[コード署名設定]](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) を開きます。
1. コンテンツペインのヘッダーから、**[設定の作成]** を選択します。
1. コンテンツペインの上部にあるセクションで、コード署名設定をセットアップします。コード署名設定の設定の詳細については、「[コード署名を使用して Lambda でコードの整合性を検証する](configuration-codesigning.md)」を参照してください。
1. In the **Tags** section, choose **Add new tag**.
1. **[キー]** フィールドにタグキーを入力します。タグ付け制限の詳細については、「*タグ付け AWS リソースとタグエディタユーザーガイド*」の「[タグの命名制限と要件](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)」を参照してください。
1. **[設定を作成]** を選択します。
**既存のコード署名設定にタグを追加するには**
1. Lambda コンソールの [[コード署名設定]](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) を開きます。
1. コード署名設定の名前を選択します。
1. **[詳細]** ペインの下にあるタブで、**[タグ]** を選択します。
1. [**Manage tags (タグの管理)**] を選択します。
1. **新しいタグを追加**を選択します。
1. **[キー]** フィールドにタグキーを入力します。タグ付け制限の詳細については、「*タグ付け AWS リソースとタグエディタユーザーガイド*」の「[タグの命名制限と要件](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)」を参照してください。
1. **[保存]** を選択します。
**タグでコード署名設定をフィルタリングするには**
1. Lambda コンソールの [[コード署名設定]](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) を開きます。
1. 検索ボックスを選択します。
1. ドロップダウンリストで、**[タグ]** の小見出しの下からタグを選択します。
1. **[使用: "tag-name"]** を選択して、このキーでタグ付けされたすべてのコード署名設定を表示するか、**[演算子]** を選択して、値でさらにフィルタリングします。
1. タグキーと値の組み合わせでフィルタリングするタグ値を選択します。
検索ボックスは、タグキーの検索もサポートしています。キーの名前を入力し、リスト内で見つけます。
## AWS CLIでのタグの使用
Lambda API を使用して、コード署名設定を含む既存の Lambda リソースにタグを追加および削除できます。コード署名設定の作成時にタグを追加することもできます。これにより、ライフサイクル全体を通じてリソースにタグを付けることができます。
### Lambda タグ API を使用したタグの更新
サポートされている Lambda リソースのタグを追加または削除するには、[TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) および [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API オペレーションを使用します。
これらの操作は AWS CLI を使用して呼び出すことができます。既存のリソースにタグを追加するには、`tag-resource` コマンドを使用します。この例では、2 つのタグを追加します。1 つはキー *Department* を持つタグで、もう 1 つはキー *CostCenter* を持つタグです。
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
タグを削除するには、`untag-resource` コマンドを使用します。この例では、キー *Department* を持つタグを削除します。
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### コード署名設定作成時のタグの追加
タグを使用して新しい Lambda コード署名設定を作成するには、[CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html) API オペレーションを使用します。`Tags` パラメータを指定します。このオペレーションは、`create-code-signing-config` AWS CLI コマンドと `--tags` オプションを使用して呼び出すことができます。CLI コマンドの詳細については、「*AWS CLI コマンドリファレンス*」の「[create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)」を参照してください。
`CreateCodeSigningConfig` で `Tags` パラメータを使用する前に、このオペレーションに必要な通常のアクセス許可と共に、リソースにタグを付けるアクセス許可をロールが有していることを確認してください。タグ付けのアクセス許可の詳細については、「[タグの操作に必要なアクセス許可](#csc-tags-required-permissions)」を参照してください。
### Lambda タグ API を使用したタグの表示
特定の Lambda リソースに適用されるタグを表示するには、`ListTags` API オペレーションを使用します。詳細については、「[ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)」を参照してください。
このオペレーションは、ARN (Amazon リソースネーム) を指定することで `list-tags` AWS CLI コマンドで呼び出すことができます。
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### タグによるリソースのフィルタリング
AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API オペレーションを使用すると、リソースをタグでフィルタリングできます。この `GetResources` オペレーションは、それぞれにタグキーと最大 10 個のタグ値が含まれているフィルタを、最大 10 個まで受け取ります。特定のリソースタイプでフィルタリングするには、`GetResources` で `ResourceType` を指定します。
このオペレーションは、`get-resources` AWS CLI コマンドを使用して呼び出すことができます。`get-resources` の使用例については、「*AWS CLI コマンドリファレンス*」の「[get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)」を参照してください。