翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS CodePipeline
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャからメリットを得られます。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。が適用されるコンプライアンスプログラムの詳細については AWS CodePipeline、「コンプライアンスプログラム[AWS による対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、企業の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
このドキュメントは、CodePipeline を使用する際の責任共有モデルの適用方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するように CodePipeline を設定する方法について説明します。また、CodePipeline リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [でのデータ保護 AWS CodePipeline](data-protection.md)
+ [の ID とアクセスの管理 AWS CodePipeline](security-iam.md)
+ [CodePipeline でのロギングとモニタリング](incident-response.md)
+ [のコンプライアンス検証 AWS CodePipeline](compliance-validation.md)
+ [の耐障害性 AWS CodePipeline](disaster-recovery-resiliency.md)
+ [のインフラストラクチャセキュリティ AWS CodePipeline](infrastructure-security.md)
+ [セキュリティのベストプラクティス](security-best-practices.md)
# でのデータ保護 AWS CodePipeline
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 でのデータ保護に適用されます。このモデルで説明されているように、 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 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](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、または SDK を使用して AWS CLIまたは他の AWS のサービス を操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
以下のセキュリティのベストプラクティスも CodePipeline でのデータ保護に対処します。
+ [CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する](S3-artifact-encryption.md)
+ [AWS Secrets Manager を使用してデータベースパスワードまたはサードパーティー API キーを追跡する](parameter-store-encryption.md)
## ネットワーク間のトラフィックのプライバシー
Amazon VPC AWS のサービス は、定義した仮想ネットワーク (*仮想プライベートクラウド*) で AWS リソースを起動するために使用できる です。CodePipeline は、プライベート IP アドレスを持つ Elastic Network Interface AWS のサービス を使用する間のプライベート通信を容易にする AWS テクノロジーである AWS PrivateLink を搭載した Amazon VPC エンドポイントをサポートしています。つまり、VPC 内のプライベートエンドポイントを介して CodePipeline に直接接続し、VPC と AWS ネットワーク内にすべてのトラフィックを保持できます。以前は、VPC 内で実行されているアプリケーションから、CodePipeline にインターネット接続する必要がありました。VPC では、次のようなネットワーク設定を管理することができます。
+ IP アドレス範囲
+ Subnets
+ ルートテーブル、
+ ネットワークゲートウェイ。
VPC を CodePipeline に接続するには、CodePipeline のインターフェイス VPC エンドポイントを定義します。このタイプのエンドポイントにより、VPC を AWS のサービスに接続できるようになります。このエンドポイントは、インターネットゲートウェイ、ネットワークアドレス変換 (NAT) インスタンス、および VPN 接続を必要とせず、信頼性が高くスケーラブルな CodePipeline への接続を提供します。VPC を設定する方法の詳細については、[VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)参照してください。
## 保管中の暗号化
CodePipeline のデータは、保管時に を使用して暗号化されます AWS KMS keys。コードアーティファクトは、カスタマー所有の S3 バケットに保存され、 AWS マネージドキー またはカスタマーマネージドキーで暗号化されます。詳細については、「[CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する](S3-artifact-encryption.md)」を参照してください。
## 転送中の暗号化
すべてのサービス間の通信は、SSL/TLS を使用して転送中に暗号化されます。
## 暗号化キーの管理
コードアーティファクトを暗号化するためのデフォルトのオプションを選択する場合、CodePipeline は AWS マネージドキーを使用します。これを変更または削除することはできません AWS マネージドキー。でカスタマーマネージドキーを使用して S3 バケット内のアーティファクトを AWS KMS 暗号化または復号する場合は、必要に応じてこのカスタマーマネージドキーを変更またはローテーションできます。
**重要**
CodePipeline は、対称 KMS キーのみをサポートしています。非対称キーを使用して S3 bucket のデータを暗号化しないでください。
**Topics**
# CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する
Amazon S3 アーティファクトのサーバー側の暗号化を設定するには、次の 2 つの方法があります。
+ CodePipeline は、パイプラインの作成ウィザードを使用してパイプラインを作成する AWS マネージドキー ときに S3 アーティファクトバケットとデフォルトを作成します。 AWS マネージドキー はオブジェクトデータと共に暗号化され、 によって管理されます AWS。
+ 独自の カスタマーマネージドキー を作成して管理できます。
**重要**
CodePipeline は、対称 KMS キーのみを対応しています。非対称 KMS キーを使用して S3 bucket のデータを暗号化しないでください。
デフォルトの S3 キーを使用している場合、この AWS マネージドキーを変更または削除することはできません。でカスタマーマネージドキーを使用して S3 バケット内のアーティファクトを AWS KMS 暗号化または復号する場合は、必要に応じてこのカスタマーマネージドキーを変更またはローテーションできます。
Amazon S3 は、バケットに格納されているすべてのオブジェクトに対してサーバー側の暗号化が必要な場合に使用できるバケットポリシーをサポートしています。例えば、SSE-KMS を使用したサーバー側の暗号化を要求する `s3:PutObject` ヘッダーがリクエストに含まれていない場合、次のバケットポリシーはすべてのユーザーに対し、オブジェクト (`x-amz-server-side-encryption`) をアップロードするアクセス許可を拒否します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
------
サーバー側の暗号化の詳細については AWS KMS、[「サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)」および[「 (SSE-KMS) に保存 AWS Key Management Service されている KMS キーを使用したサーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)」を参照してください。
詳細については AWS KMS、「 [AWS Key Management Service デベロッパーガイド](https://docs.aws.amazon.com/kms/latest/developerguide/)」を参照してください。
**Topics**
+ [を表示する AWS マネージドキー](#S3-view-default-keys)
+ [CloudFormation または を使用して S3 バケットのサーバー側の暗号化を設定する AWS CLI](#S3-rotate-customer-key)
## を表示する AWS マネージドキー
[**パイプラインの作成**] ウィザードを使用して最初のパイプラインを作成すると、パイプラインを作成したのと同じリージョンに S3 バケットが作成されます。バケットは、パイプラインアーティファクトを格納するために使用されます。パイプラインを実行すると、アーティファクトが、S3 バケットに入れられるか、そこから取得されます。デフォルトでは、CodePipeline は AWS マネージドキー for Amazon S3 ( `aws/s3`キー) AWS KMS を使用して でサーバー側の暗号化を使用します。これは AWS マネージドキー 作成され、 AWS アカウントに保存されます。アーティファクトが S3 バケットから取得されると、CodePipeline は同じ SSE-KMS プロセスを使用してアーティファクトを復号化します。
**に関する情報を表示するには AWS マネージドキー**
1. にサインイン AWS マネジメントコンソール し、 AWS KMS コンソールを開きます。
1. ウェルカムページが表示される場合は、[**今すぐ始める**] を選択します。
1. サービスのナビゲーションペインで、[**AWS managed keys**] を選択します。
1. パイプラインのリージョンを選択します。例えば、パイプラインが `us-east-2` に作成されている場合は、フィルタが 米国西部 (オハイオ州) に設定されていることを確認します。
CodePipeline で使用できるリージョンとエンドポイントの詳細については、「[AWS CodePipeline エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/codepipeline.html)」を参照してください。
1. リスト内のパイプラインに使用されるエイリアスがあるキー (デフォルトは **aws/s3**) を選択します。キーの基本情報が表示されます。
## CloudFormation または を使用して S3 バケットのサーバー側の暗号化を設定する AWS CLI
CloudFormation または を使用してパイプライン AWS CLI を作成する場合は、サーバー側の暗号化を手動で設定する必要があります。上記のサンプルバケットポリシーを使用して、独自のカスタマーマネージドキーを作成します。デフォルトの AWS マネージドキーキーの代わりに独自のキーを使用することもできます。独自のキーを選択する理由には、次のようなものがあります。
+ 組織のビジネス要件またはセキュリティ要件を満たすために、スケジュールに基づいてキーのローテーションをする必要があります。
+ 別の AWS アカウントに関連付けられたリソースを使用するパイプラインを作成する必要があります。これには、 カスタマーマネージドキー を使用する必要があります。詳細については、「[別の AWS アカウントのリソースを使用するパイプラインを CodePipeline に作成する](pipelines-create-cross-account.md)」を参照してください。
暗号化のベストプラクティスでは、暗号化キーの広範な再利用を推奨していません。ベストプラクティスとして、キーを定期的にローテーションします。 AWS KMS キーの新しい暗号化マテリアルを作成するには、カスタマーマネージドキーを作成し、新しいカスタマーマネージドキーを使用するようにアプリケーションまたはエイリアスを変更します。または、既存の カスタマー管理キー の自動キーローテーションを有効にすることができます。
カスタマーマネージドキーをローテーションするには、「[キーローテーション](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。
**重要**
CodePipeline は、対称 KMS キーのみを対応しています。非対称キーを使用して S3 bucket のデータを暗号化しないでください。
# AWS Secrets Manager を使用してデータベースパスワードまたはサードパーティー API キーを追跡する
を使用して、データベース認証情報、API キー、およびその他の**シークレット** AWS Secrets Manager をライフサイクル全体でローテーション、管理、取得することをお勧めします。Secrets Manager を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を、Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。詳細については、[AWS 「Secrets Manager とは」を参照してください。](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) *AWS 「Secrets Manager ユーザーガイド*」の「」を参照してください。
CloudFormation テンプレートでシークレットであるパラメータ (OAuth 認証情報など) を渡すパイプラインの場合、Secrets Manager に保存したシークレットにアクセスする動的参照をテンプレートに含める必要があります。参照 ID パターンと例については、「[Secrets Manager のシークレット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager)の*AWS CloudFormation ユーザーガイド*」を参照してください。パイプラインで GitHub Webhook のテンプレートスニペットで動的参照を使用する例については、「[Webhook リソースの設定](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html#aws-resource-codepipeline-webhook--examples)」を参照してください。
## 関連情報
シークレットを管理する際に役立つ関連リソースは以下の通りです。
+ Secrets Manager は、Amazon RDS シークレットのローテーションなど、データベースの認証情報を自動的にローテーションできます。詳細については、[AWS 「 Secrets Manager ユーザーガイド」の「Secrets Manager シークレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)」を参照してください。 *AWS *
+ Secrets Manager の動的参照を CloudFormation テンプレートに追加する方法については、[https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/](https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/) を参照してください。
# の ID とアクセスの管理 AWS CodePipeline
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を *認証* (サインイン) し、誰に CodePipeline リソースの使用を *承認する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [が IAM と AWS CodePipeline 連携する方法](security_iam_service-with-iam.md)
+ [AWS CodePipeline アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [AWS CodePipeline リソースベースのポリシーの例](security_iam_resource-based-policy-examples.md)
+ [AWS CodePipeline ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ [アクセス許可に関するリファレンス](permissions-reference.md)
+ [CodePipeline サービスロールを管理する](how-to-custom-role.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS CodePipeline ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[が IAM と AWS CodePipeline 連携する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[AWS CodePipeline アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウントのルートユーザー
を作成するときは AWS アカウント、まず、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスする必要がある AWS](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 ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*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 には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー 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)」を参照してください。
# が IAM と AWS CodePipeline 連携する方法
IAM を使用して CodePipeline へのアクセスを管理する前に、CodePipeline で使用できる IAM 機能について理解しておく必要があります。CodePipeline およびその他の AWS のサービス が IAM と連携する方法の概要を把握するには、[AWS のサービス 「IAM ユーザーガイド」の「IAM と連携する ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 **
**Topics**
+ [CodePipeline アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies)
+ [CodePipeline リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [CodePipeline タグに基づく許可](#security_iam_service-with-iam-tags)
+ [CodePipeline IAM ロール](#security_iam_service-with-iam-roles)
## CodePipeline アイデンティティベースのポリシー
IAM アイデンティティベースのポリシーでは許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。CodePipeline は、特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については、「IAM ユーザーガイド」の「[IAM JSON ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### アクション
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
CodePipeline のポリシーアクションは、アクションの前にプレフィックス `codepipeline:` を使用します：。
例えば、アカウント内の既存のパイプラインを表示するアクセス許可を他のユーザーに付与するには、ユーザーのポリシーに `codepipeline:GetPipeline` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。CodePipeline は、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。
単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。
```
"Action": [
"codepipeline:action1",
"codepipeline:action2"
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Get` という単語で始まるすべてのアクションを指定するには次のアクションを含めます。
```
"Action": "codepipeline:Get*"
```
CodePipeline アクションのリストを表示するには、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions) の「* AWS CodePipelineによって定義されたアクション*」を参照してください。
### リソース
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
#### リソースとオペレーション
では、プライマリリソースはパイプラインです。ポリシーで Amazon リソースネーム (ARN) を使用して、ポリシーを適用するリソースを識別します。 は、ステージ、アクション、カスタムアクションなど、プライマリリソースで使用できる他のリソースを選択します。これらは サブリソースと呼ばれます。これらのリソースとサブリソースには、一意の Amazon リソースネーム (ARN) が関連付けられています。ARNs、の[「Amazon リソースネーム (ARN) と AWS のサービス 名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください*Amazon Web Services 全般のリファレンス*。パイプラインに関連付けられたパイプラインの ARN を取得するには、「**設定**コンソールに表示されるパイプラインの ARN 」を参照してください。詳細については、「[パイプラインの ARN とサービスロール ARN (コンソール) を表示します。](pipelines-settings-console.md)」を参照してください。
| リソースタイプ | ARN 形式 |
| --- | --- |
| パイプライン | arn:aws:コードパイプライン:[*領域*]:[*アカウント*]:[*パイプライン名*] |
| ステージ | arn:aws:コードパイプライン:[*領域*]:[*アカウント*]:[*パイプライン名*/*ステージ名*] |
| アクション | arn:aws:codepipeline:*region*:*account*:*pipeline-name*/*stage-name*/*action-name* |
| カスタムアクション | arn:aws:codepipeline:region:account:actiontype:owner/category/provider/version |
| すべてのリソース | arn:aws:codepipeline:\$1 |
| 特定リージョンの特定アカウントが所有するすべての リソース | arn:aws:コードパイプライン:[*領域*]:[*アカウント*]:\$1 |
**注記**
のほとんどのサービスは、ARN でコロン (:) またはスラッシュ (/) を同じ文字として AWS 扱います。 ARNs ただし、 では、イベントパターンおよびルールで完全一致を使用します。イベントパターンの作成時に正しい ARN 文字を使用して、一致させるリソース内の ARN 構文とそれらの文字が一致する必要があります。
では、リソースレベルのアクセス許可をサポートする API コールがあります。リソースレベルのアクセス許可は、API コールでリソース ARN を指定できるかどうか、または API コールでワイルドカードを使用したすべてのリソースの呼び出しのみが可能かどうかを示します。リソースレベルのアクセス許可の詳細な説明と、リソースレベルのアクセス許可をサポートする CodePipeline API コールの一覧については、[アクセス許可に関するリファレンス](permissions-reference.md) を参照してください。
例えば、以下の要領で ARN を使用して、ステートメント内の特定のパイプライン (*myPipeline*) を指定することができます。
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:myPipeline"
```
また、以下の要領でワイルドカード文字 (\$1) を使用して、特定のアカウントに属するすべてのパイプラインを指定することもできます。
```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:*"
```
すべてのリソースを指定する場合、または特定の API アクションが ARN をサポートしていない場合は、以下のように、`Resource` エレメント内でワイルドカード文字 (\$1) を使用します。
```
"Resource": "*"
```
**注記**
IAM ポリシーを作成するとき、最小限の特権を認めるという標準的なセキュリティアドバイスに従いましょう。そうすれば、タスクを実行するというリクエストのアクセス許可のみを認めることができます。API コールが ARN をサポートしている場合、リソースレベルのアクセス許可をサポートしていて、ワイルドカード文字 (\$1) を使用する必要はありません。
一部の API コールは、複数のリソース ( など) を受け入れます`GetPipeline`。単一のステートメントに複数のリソースを指定するには、以下のようにコンマで ARN を区切ります。
```
"Resource": ["arn1", "arn2"]
```
には、 リソースを操作するための一連のオペレーションが用意されています。使用可能なオペレーションのリストについては、「[アクセス許可に関するリファレンス](permissions-reference.md)」を参照してください。
### 条件キー
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`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)」を参照してください。
CodePipeline は独自の条件キーを定義し、一部のグローバル条件キーの使用をサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については、「[例: 特定のリージョンへのアクセスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)」を参照してください。
CodePipeline 条件キーのリストを確認するには、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys) の* AWS CodePipelineの条件キー*を参照してください。条件キーを使用できるアクションとリソースについては、[「 で定義されるアクション AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions)」を参照してください。
### 例
CodePipeline アイデンティティベースのポリシーの例については、[AWS CodePipeline アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md) を参照してください。
## CodePipeline リソースベースのポリシー
CodePipeline は、リソースベースのポリシーに対応していません。ただし、CodePipeline に関連する S3 サービスのリソースベースのポリシーの例が提供されています。
### 例
CodePipeline リソースベースのポリシーの例を表示する場合、[AWS CodePipeline リソースベースのポリシーの例](security_iam_resource-based-policy-examples.md) を参照してください。
## CodePipeline タグに基づく許可
CodePipeline リソースにタグをアタッチしたり、リクエスト内のタグを CodePipeline に渡したりできます。タグに基づいてアクセスを制御するには、`codepipeline:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの [条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) でタグ情報を提供します。CodePipeline リソースのタグ付けの詳細については、[リソースのタグ付け](tag-resources.md) を参照してください。
リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースポリシーの例を表示するには、「[タグを使用した CodePipeline リソースへのアクセスのコントロール](tag-based-access-control.md)」を参照してください。
## CodePipeline IAM ロール
[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、特定のアクセス許可を持つ AWS アカウントのエンティティです。
### CodePipeline で一時的な認証情報の使用
一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには、[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) や [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS STS API オペレーションを呼び出します。
CodePipeline は、一時的な認証情報の使用をサポートしています。
### サービスロール
CodePipeline は、[サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)をユーザーに代わって引き受けることをサービスに許可します。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールはIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、それにより、サービスの機能が損なわれる場合があります。
CodePipeline はサービスロールに対応しています。
# AWS CodePipeline アイデンティティベースのポリシーの例
デフォルトでは、IAM ユーザーおよびロールには、CodePipeline リソースを作成または変更するアクセス許可はありません。また、 AWS マネジメントコンソール、 AWS CLI、または AWS API を使用してタスクを実行することはできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。
JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
別のアカウントのリソースを使用するパイプラインを作成する方法、および関連するポリシーの例については、「[別の AWS アカウントのリソースを使用するパイプラインを CodePipeline に作成する](pipelines-create-cross-account.md)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](security_iam_service-with-iam-policy-best-practices.md)
+ [コンソールでのリソースの表示](security-iam-resources-console.md)
+ [自分の権限の表示をユーザーに許可する](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [アイデンティティベースのポリシー (IAM) の例](security-iam-id-policies-examples.md)
+ [タグを使用した CodePipeline リソースへのアクセスのコントロール](tag-based-access-control.md)
+ [コンソールの使用に必要な許可](security-iam-permissions-console.md)
+ [コンソールでコンピューティングログを表示するために必要なアクセス許可](security-iam-permissions-console-logs.md)
+ [AWS の 管理ポリシー AWS CodePipeline](managed-policies.md)
+ [カスタマーマネージドポリシーの例](#customer-managed-policies)
# ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内の CodePipeline リソースを誰かが作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 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 を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*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) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、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) を参照してください。
# コンソールでのリソースの表示
コンソールには、サインインしている AWS リージョンの AWS アカウントのリポジトリのリストを表示するアクセス`ListRepositories`許可が必要です。このコンソールには、大文字と小文字を区別しない検索をリソースに対して迅速に実行するための [**Go to resource (リソースに移動)**] 機能も含まれています。この検索は、サインインしている AWS リージョンの AWS アカウントで実行されます。次のリソースは、以下のサービス全体で表示されます。
+ AWS CodeBuild: プロジェクトの構築
+ AWS CodeCommit: リポジトリ
+ AWS CodeDeploy: アプリケーション
+ AWS CodePipeline: パイプライン
この検索をすべてのサービスのリソースにわたって実行するには、次のアクセス権限が必要です。
+ AWS CodeBuild: `ListProjects`
+ CodeCommit: `ListRepositories`
+ CodeDeploy: `ListApplications`
+ CodePipeline: `ListPipelines`
あるサービスに対するアクセス権限がない場合、そのサービスのリソースに関して結果は返されません。表示のアクセス権限がある場合でも、表示に対する明示的な `Deny` が設定されているリソースについては、結果が返されません。
# 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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": "*"
}
]
}
```
# アイデンティティベースのポリシー (IAM) の例
ポリシーを IAM アイデンティティにアタッチできます。例えば、次のオペレーションを実行できます。
+ **アカウントのユーザーまたはグループにアクセス許可ポリシーをアタッチする** – コンソールでパイプラインを表示するアクセス許可をユーザーに付与するには、ユーザーが属するユーザーまたはグループにアクセス許可ポリシーをアタッチできます。
+ **アクセス権限ポリシーをロールにアタッチする (クロスアカウントの許可を付与)** - ID ベースのアクセス権限ポリシーを IAM ロールにアタッチして、クロスアカウントの権限を付与することができます。たとえば、アカウント A の管理者は、次のように別の AWS アカウント (アカウント B など) または にクロスアカウントアクセス許可を付与するロールを作成できます AWS のサービス 。
1. アカウント A の管理者は、IAM ロールを作成して、アカウント A のリソースに許可を付与するロールに許可ポリシーをアタッチします。
1. アカウント A の管理者は、アカウント B をそのロールを引き受けるプリンシパルとして識別するロールに、信頼ポリシーをアタッチします。
1. アカウント B の管理者は、アカウント B のユーザーにロールを引き受けるアクセス許可を委任できます。これにより、アカウント B のユーザーがアカウント A のリソースを作成またはアクセスできるようになります。ロールを引き受けるアクセス AWS のサービス 許可を付与する場合は、信頼ポリシーのプリンシパルもプリンシ AWS のサービス パルになることができます。
IAM を使用した許可の委任の詳細については、「IAM ユーザーガイド」の「[アクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。
以下に示しているアクセス許可ポリシーの例では、`us-west-2 region` で `MyFirstPipeline` という名前のパイプライン内のすべてのステージ間の移行を無効または有効にするアクセス許可を付与しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"codepipeline:EnableStageTransition",
"codepipeline:DisableStageTransition"
],
"Resource" : [
"arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
]
}
]
}
```
------
次の例は、111222333444 アカウントのポリシーを示しています。このポリシーでは、コンソール`MyFirstPipeline`で という名前のパイプラインを表示することはできますが、変更することはできません。このポリシーは、`AWSCodePipeline_ReadOnlyAccess` マネージドポリシーに基づいていますが、パイプライン `MyFirstPipeline` に固有であるため、このマネージドポリシーを直接使用することはできません。ポリシーを特定のパイプラインに制限しない場合は、 によって作成および保守されているいずれかのマネージドポリシーを使用することを検討してください。詳細については、「[マネージドポリシーの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)」を参照してください。このポリシーは、アクセス用に作成した IAM ロール (`CrossAccountPipelineViewers` という名前のロールなど) にアタッチする必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:ListAllMyBuckets",
"codecommit:ListRepositories",
"codedeploy:ListApplications",
"lambda:ListFunctions",
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Effect": "Allow",
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
},
{
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:GetPipelineExecution",
"codepipeline:ListPipelineExecutions",
"codepipeline:ListActionExecutions",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"codepipeline:ListTagsForResource",
"iam:ListRoles",
"s3:GetBucketPolicy",
"s3:GetObject",
"s3:ListBucket",
"codecommit:ListBranches",
"codedeploy:GetApplication",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListDeploymentGroups",
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEnvironments",
"lambda:GetFunctionConfiguration",
"opsworks:DescribeApps",
"opsworks:DescribeLayers",
"opsworks:DescribeStacks"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsReadOnlyAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"codestar-notifications:NotificationsForResource": "arn:aws:iam::*:role/Service*"
}
}
}
]
}
```
------
このポリシーを作成したら、アカウント (111222333444) に IAM ロールを作成し、そのロールにポリシーをアタッチします。ロールの信頼関係で、このロールを引き受ける AWS アカウントを追加する必要があります。次の例は、*111111111111* AWS アカウントのユーザーが アカウントで定義されたロールを引き受けることを許可するポリシーを示しています111222333444。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
次の例は、ユーザーが *111111111111* AWS アカウントで *CrossAccountPipelineViewers* という名前のロールを引き受けることを許可する 111222333444 アカウントで作成されたポリシーを示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111222333444:role/CrossAccountPipelineViewers"
}
]
}
```
------
アカウントのユーザーがアクセスを許可される通話とリソースを制限する IAM ポリシーを作成し、管理者ユーザーにそれらのポリシーをアタッチできます。IAM ロールの作成方法と の IAM ポリシーステートメントの例については、「」を参照してください[カスタマーマネージドポリシーの例](security_iam_id-based-policy-examples.md#customer-managed-policies)。
# タグを使用した CodePipeline リソースへのアクセスのコントロール
IAM ポリシーステートメントの条件は、CodePipeline アクションに必要なリソースへのアクセス許可を指定するために使用する構文の一部です。条件内でタグを使用することは、リソースとリクエストへのアクセスをコントロールするひとつの方法です。CodePipeline リソースのタグ付けの詳細情報は、[リソースのタグ付け](tag-resources.md) を参照してください。このトピックでは、タグベースのアクセスコントロールについて説明します。
IAM ポリシーの設計時に特定のリソースへのアクセス権を付与することで、詳細なアクセス許可を設定できます。管理するリソースの数が増えるに従って、このタスクはより困難になります。リソースにタグ付けしてポリシーステートメント条件でタグを使用することにより、このタスクをより容易にすることができます。特定のタグを使用して任意のリソースへのアクセス権を一括して付与します。次に、作成時や以降の段階で、このタグを関連リソースに繰り返し適用します。
タグは、リソースにアタッチしたり、タグ付けをサポートするサービスへのリクエストに渡したりすることができます。CodePipeline では、リソースにタグを付けることができ、一部のアクションにタグを含めることができます。IAM ポリシーを作成するときに、タグ条件キーを使用して以下をコントロールできます。
+ どのユーザーがパイプラインリソースに対してアクションを実行できるか (リソースに既に付けられているタグに基づいて)。
+ どのタグをアクションのリクエストで渡すことができるか。
+ リクエストで特定のタグキーを使用できるかどうか。
文字列条件演算子では、キーと文字列値の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。Null 条件以外の条件演算子名の末尾に `IfExists` を追加できます。「ポリシーキーがリクエストのコンテキストで存在する場合、ポリシーで指定されたとおりにキーを処理します。キーが存在しない場合、条件要素は true と評価されます。」 例えば、`StringEqualsIfExists` を使用して、他のタイプのリソースには存在しない可能性のある条件キーに基づいた制限を行うことができます。
タグ条件キーの完全な構文と意味については、「[タグを使用したアクセスコントロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。条件キーの詳細については、以下のリソースを参照してください。このセクションに示す CodePipeline ポリシーの例は、条件キーに関する以下の情報に沿っています。また、リソースのネスティングなど CodePipeline 特有の考慮点についても、例を交えて補足説明しています。
+ [文字列条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)
+ [AWS のサービス IAM で動作する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
+ [SCP 構文](https://docs.aws.amazon.com/IAM/latest/UserGuide/orgs_manage_policies_scps_syntax.html)
+ [IAM JSON ポリシーエレメント: 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
+ [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)
+ [CodePipeline の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys)
次の例は、CodePipeline ユーザー用のポリシーでタグ条件を指定する方法を示しています。
**Example 1: リクエストのタグに基づいてアクションを制限する**
`AWSCodePipeline_FullAccess` マネージドユーザーポリシーは、すべてのリソースに対して任意の CodePipeline アクションを実行する無制限のアクセス許可をユーザーに付与します。
以下ののポリシーでは、この権限を制限し、権限のないユーザーがリクエストに特定のタグが記載されたパイプラインを作成することを許可しません。これを行うには、リクエストに指定されているタグ `Project` の値が `ProjectA` または `ProjectB` のいずれかである場合、`CreatePipeline` アクションを拒否します。(この `aws:RequestTag` 条件キーを使用して、IAM リクエストで渡すことができるタグをコントロールします)。
以下の例で、ポリシーの目的は、指定したタグ値を使用してパイプラインを作成するアクセス許可を、権限のないユーザーに与えないことです。ただし、パイプラインを作成するには、パイプライン自体に加えてリソース (パイプラインのアクションやステージなど) にアクセスする必要があります。ポリシーに指定された `'Resource'` が `'*'` であるため、このポリシーは、ARN の付いたリソースのうち、パイプラインの作成時に作成されるすべてのリソースに適用されます。これらの追加のリソースにはタグ条件キーがないため、`StringEquals` のチェックは失敗し、ユーザーはいずれのタイプのインスタンスも起動できません。これに対応するには、`StringEqualsIfExists` 条件演算子を代わりに使用します。そうすれば、条件キーが存在する場合のみにテストが行われます。
以下のコードは次のように解釈できます。「チェックされるリソースには `"RequestTag/Project"` 条件キーがあり、キー値が `projectA` で始まる場合にのみ、アクションを許可します。チェックされるリソースにこの条件キーがなくても問題ありません。」
また、このポリシーでは `aws:TagKeys` 条件キーを使用して、タグ変更アクションにこれらの同じタグ値を含めることを許可しないことで、これらの権限のないユーザーがリソースを改ざんするのを防ぎます。お客様の管理者は、権限のない管理者ユーザーには、マネージドユーザーポリシーに加えて、この IAM ポリシーをアタッチする必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"aws:RequestTag/Project": ["ProjectA", "ProjectB"]
}
}
},
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 2: リソースタグに基づいてタグ付けアクションを制限する**
`AWSCodePipeline_FullAccess` マネージドユーザーポリシーは、すべてのリソースに対して任意の CodePipeline アクションを実行する無制限のアクセス許可をユーザーに付与します。
次のポリシーは、この権限を制限し、権限のないユーザーに対して特定のプロジェクトのパイプラインでアクションを実行するアクセス許可を拒否します。そのために、`ProjectA` または `ProjectB` の値のいずれかを持つ `Project` という名前のタグをこのリソースが持つ場合、一部のアクションを拒否します。(この`aws:ResourceTag` 条件キーを使用して、それらのリソースのタグに基づいて、このリソースへのアクセスをコントロールします)。お客様の管理者は、権限のない IAM ユーザーには、マネージドユーザーポリシーに加えて、この IAM ポリシーをアタッチする必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": ["ProjectA", "ProjectB"]
}
}
}
]
}
```
**Example 3: リクエストのタグに基づいてアクションを許可する**
次のポリシーでは、CodePipeline の開発パイプラインを作成するアクセス許可をユーザーに付与します。
これを行うには、リクエストに指定されているタグ `Project` の値が `ProjectA` である場合に、`CreatePipeline` アクションと `TagResource` アクションを許可します。つまり、指定できるタグキーは `Project` のみで、その値は `ProjectA` であることが必要です。
この `aws:RequestTag` 条件キーを使用して、IAM リクエストで渡すことができるタグをコントロールします。`aws:TagKeys` 条件は、タグキーの大文字と小文字を区別します。このポリシーは、`AWSCodePipeline_FullAccess` マネージドユーザーポリシーがアタッチされていないユーザーまたはロールに便利です。このマネージドポリシーは、すべてのリソースに対して任意の CodePipeline アクションを実行する無制限のアクセス許可をユーザーに付与します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:CreatePipeline",
"codepipeline:TagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "ProjectA"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
**Example 4: リソースタグに基づいてタグ削除アクションを制限する**
`AWSCodePipeline_FullAccess` マネージドユーザーポリシーは、すべてのリソースに対して任意の CodePipeline アクションを実行する無制限のアクセス許可をユーザーに付与します。
次のポリシーは、この権限を制限し、権限のないユーザーに対して特定のプロジェクトのパイプラインでアクションを実行するアクセス許可を拒否します。そのために、`ProjectA` または `ProjectB` の値のいずれかを持つ `Project` という名前のタグをこのリソースが持つ場合、一部のアクションを拒否します。
また、このポリシーでは `aws:TagKeys` 条件キーを使用して、タグ変更アクションに `Project` タグを完全に削除することを許可しないことで、これらの権限のないユーザーがリソースを改ざんするのを防ぎます。お客様の管理者は、権限のないユーザーまたはロールには、マネージドユーザーポリシーに加えて、この IAM ポリシーをアタッチする必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"codepipeline:UntagResource"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["Project"]
}
}
}
]
}
```
# コンソールの使用に必要な許可
コンソールで を使用するには、以下のサービスからの最小限のアクセス許可が必要です。
+ AWS Identity and Access Management
+ Amazon Simple Storage Service
これらのアクセス許可により、アカウントの他の AWS リソースを記述できます AWS 。
他のサービスをパイプラインに取り入れた場合は、次のアクセス許可が 1 つ以上必要になることがあります。
+ AWS CodeCommit
+ AWS CodeBuild
+ CloudFormation
+ AWS CodeDeploy
+ AWS Elastic Beanstalk
+ AWS Lambda
+ AWS OpsWorks
これらの最小限必要なアクセス許可よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。「`AWSCodePipeline_ReadOnlyAccess`」で説明されているとおり、ユーザーがコンソールを使用できること、および [AWS の 管理ポリシー AWS CodePipeline](managed-policies.md) 管理ポリシーがユーザーにアタッチされていることを確認してください。
AWS CLI または API を呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。
# コンソールでコンピューティングログを表示するために必要なアクセス許可
CodePipeline コンソールでコマンドアクションのログを表示するには、コンソールロールにアクセス許可が必要です。コンソールでログを表示するには、コンソールロールに `logs:GetLogEvents` アクセス許可を追加します。
コンソールロールポリシーステートメントで、次の例に示すように、アクセス許可の範囲をパイプラインレベルに絞り込みます。
```
{
"Effect": "Allow",
"Action": [
"Action": "logs:GetLogEvents"
],
"Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*"
}
```
# AWS の 管理ポリシー AWS CodePipeline
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 を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS 管理ポリシーを更新する可能性が高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
**重要**
AWS マネージドポリシー `AWSCodePipelineFullAccess` および `AWSCodePipelineReadOnlyAccess` は置き換えられました。`AWSCodePipeline_FullAccess` および `AWSCodePipeline_ReadOnlyAccess` ポリシーを使用してください。
## AWS 管理ポリシー: `AWSCodePipeline_FullAccess`
これは CodePipeline へのフルアクセスを許可するポリシーです。IAM コンソールで JSON ポリシードキュメントを表示するには、「[AWSCodePipeline\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `codepipeline` - CodePipeline に対するアクセス許可を付与します。
+ `chatbot` - チャットアプリケーションで Amazon Q Developer のリソースを管理するためのアクセス許可をプリンシパルに付与します。
+ `cloudformation` – プリンシパルがリソーススタックを管理できるようにするアクセス許可を付与します CloudFormation。
+ `cloudtrail` - プリンシパルに、CloudTrail でリソースのログ記録を管理するためのアクセス許可を付与します。
+ `codebuild` - プリンシパルに、CodeBuild でビルドリソースを利用するためのアクセス許可を付与します。
+ `codecommit` - プリンシパルに、CodeCommit でソースリソースを利用するためのアクセス許可を付与します。
+ `codedeploy` - プリンシパルに、CodeDeploy でデプロイリソースを利用するためのアクセス許可を付与します。
+ `codestar-notifications` – プリンシパルが AWS CodeStar Notifications のリソースにアクセスできるようにするアクセス許可を付与します。
+ `ec2` - CodeCatalyst でのデプロイにおいて、Amazon EC2 で Elastic Load Balancing を管理するためのアクセス許可を付与します。
+ `ecr` - Amazon ECR でリソースを利用するためのアクセス許可を付与します。
+ `elasticbeanstalk` - プリンシパルに、Elastic Beanstalk でリソースを利用するためのアクセス許可を付与します。
+ `iam` - プリンシパルに、IAM でロールとポリシーを管理するためのアクセス許可を付与します。
+ `lambda` - プリンシパルに、Lambda でリソースを管理するためのアクセス許可を付与します。
+ `events` - プリンシパルに、CloudWatch Events でリソースを管理するためのアクセス許可を付与します。
+ `opsworks` – プリンシパルがリソースを管理できるようにするアクセス許可を付与します AWS OpsWorks。
+ `s3` - プリンシパルに、Amazon S3 でリソースを管理するためのアクセス許可を付与します。
+ `sns` - プリンシパルに、Amazon SNS で通知リソースを管理するためのアクセス許可を付与します。
+ `states` – プリンシパルにステートマシンの表示を許可するアクセス許可を付与します AWS Step Functions。ステートマシンは、状態の集まりで構成され、それぞれの状態がタスクを管理し、状態間の遷移を制御します。
ポリシーについては、「[AWSCodePipeline\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_FullAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCodePipeline_ReadOnlyAccess`
これは CodePipeline への読み取り専用アクセスを許可するポリシーです。IAM コンソールで JSON ポリシードキュメントを表示するには、「[AWSCodePipeline\$1ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_ReadOnlyAccess)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `codepipeline` - CodePipeline でのアクションに対するアクセス許可を付与します。
+ `codestar-notifications` – プリンシパルが AWS CodeStar Notifications のリソースにアクセスできるようにするアクセス許可を付与します。
+ `s3` - プリンシパルに、Amazon S3 でリソースを管理するためのアクセス許可を付与します。
+ `sns` - プリンシパルに、Amazon SNS で通知リソースを管理するためのアクセス許可を付与します。
ポリシーについては、「[AWSCodePipeline\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_ReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCodePipelineApproverAccess`
これは、手動承認アクションを承認または拒否するためのアクセス許可を付与するポリシーです。IAM コンソールで JSON ポリシードキュメントを表示するには、「[AWSCodePipelineApproverAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineApproverAccess)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `codepipeline` - CodePipeline でのアクションに対するアクセス許可を付与します。
ポリシーについては、「[AWSCodePipelineApproverAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineApproverAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCodePipelineCustomActionAccess`
これは、CodePipeline でカスタムアクションを作成したり、ビルドまたはテストアクション用に Jenkins リソースを統合したりするためのアクセス許可を付与するポリシーです。IAM コンソールで JSON ポリシードキュメントを表示するには、「[AWSCodePipelineCustomActionAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineCustomActionAccess)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `codepipeline` - CodePipeline でのアクションに対するアクセス許可を付与します。
ポリシーについては、「[AWSCodePipelineCustomActionAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineCustomActionAccess.html)」を参照してください。
## CodePipeline のマネージドポリシーと通知
CodePipeline は、パイプラインへの重要な変更をユーザーに通知できる通知機能をサポートしています。CodePipeline のマネージドポリシーには、通知機能のポリシーステートメントが含まれます。詳細については、[通知とは](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html) を参照してください。
### フルアクセスマネージドポリシーの通知に関連するアクセス許可
この管理ポリシーは、CodeCommit、CodeBuild、CodeDeploy、および Notifications の関連サービスとともに CodePipeline のアクセス許可を付与します。 CodeCommit CodeBuild CodeDeploy AWS CodeStar このポリシーは、Amazon S3、Elastic Beanstalk、CloudTrail、Amazon EC2、 CloudFormationなど、パイプラインと統合する他のサービスで作業するためのアクセス許可も付与します。これらのマネージドポリシーのいずれかが適用されたユーザーは、通知の Amazon SNS トピックの作成と管理、トピックに対するユーザーのサブスクライブとサブスクライブ解除、通知ルールのターゲットとして選択するトピックの一覧表示、Slack 用に設定されたチャットアプリケーションクライアントで Amazon Q Developer の一覧表示を行うこともできます。
`AWSCodePipeline_FullAccess` マネージドポリシーには、通知へのフルアクセスを許可する次のステートメントが含まれています。
```
{
"Sid": "CodeStarNotificationsReadWriteAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:CreateNotificationRule",
"codestar-notifications:DescribeNotificationRule",
"codestar-notifications:UpdateNotificationRule",
"codestar-notifications:DeleteNotificationRule",
"codestar-notifications:Subscribe",
"codestar-notifications:Unsubscribe"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListTargets",
"codestar-notifications:ListTagsforResource",
"codestar-notifications:ListEventTypes"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsSNSTopicCreateAccess",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": "arn:aws:sns:*:*:codestar-notifications*"
},
{
"Sid": "SNSTopicListAccess",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "CodeStarNotificationsChatbotAccess",
"Effect": "Allow",
"Action": [
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:ListMicrosoftTeamsChannelConfigurations"
],
"Resource": "*"
}
```
### 読み取り専用マネージドポリシーの通知に関連するアクセス許可
`AWSCodePipeline_ReadOnlyAccess` マネージドポリシーには、通知への読み取り専用アクセスを許可する以下のステートメントが含まれています。このポリシーを適用したユーザーは、リソースの通知を表示できますが、リソースを作成、管理、サブスクライブすることはできません。
```
{
"Sid": "CodeStarNotificationsPowerUserAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:DescribeNotificationRule"
],
"Resource": "*",
"Condition" : {
"StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"}
}
},
{
"Sid": "CodeStarNotificationsListAccess",
"Effect": "Allow",
"Action": [
"codestar-notifications:ListNotificationRules",
"codestar-notifications:ListEventTypes",
"codestar-notifications:ListTargets"
],
"Resource": "*"
}
```
IAM と通知の詳細については、「[AWS CodeStar Notifications の Identity and Access Management](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security-iam.html)」を参照してください。
## AWS CodePipeline AWS 管理ポリシーの更新
このサービスがこれらの変更の追跡を開始してからの CodePipeline の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動通知を受け取るには、CodePipeline の [[ドキュメント履歴](https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html)] ページで RSS フィードをサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess) - 既存のポリシーの更新 | CodePipeline は、ListStacks を CloudFormationでサポートするためのアクセス許可を、このポリシーに追加しました。 | 2024 年 3 月 15 日 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess) - 既存のポリシーの更新 | このポリシーが更新され、チャットアプリケーションで Amazon Q Developer のアクセス許可が追加されました。詳細については、「[CodePipeline のマネージドポリシーと通知](#notifications-permissions)」を参照してください。 | 2023 年 6 月 21 日 |
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess) および [AWSCodePipeline\$1ReadOnlyAccess](#security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess) マネージドポリシー - 既存のポリシーの更新 | CodePipeline はこれらのポリシーにアクセス許可を追加し、チャットアプリケーションで Amazon Q Developer (`chatbot:ListMicrosoftTeamsChannelConfigurations`) を使用して、追加の通知タイプをサポートするようになりました。 | 2023 年 5 月 16 日 |
| **AWSCodePipelineFullAccess** - 廃止 | このポリシーは `AWSCodePipeline_FullAccess` に置き換えられました。 2022 年 11 月 17 日以降、このポリシーは新しいユーザー、グループ、またはロールにアタッチできなくなりました。詳細については、「[AWS の 管理ポリシー AWS CodePipeline](#managed-policies)」を参照してください。 | 2022 年 11 月 17 日 |
| **AWSCodePipelineReadOnlyAccess** - 廃止 | このポリシーは `AWSCodePipeline_ReadOnlyAccess` に置き換えられました。 2022 年 11 月 17 日以降、このポリシーは新しいユーザー、グループ、またはロールにアタッチできなくなりました。詳細については、「[AWS の 管理ポリシー AWS CodePipeline](#managed-policies)」を参照してください。 | 2022 年 11 月 17 日 |
| CodePipeline が変更の追跡を開始 | CodePipeline は AWS 、管理ポリシーの変更の追跡を開始しました。 | 2021 年 3 月 12 日 |
## カスタマーマネージドポリシーの例
このセクションでは、さまざまな アクションのアクセス許可を付与するユーザーポリシーの例を示しています。これらのポリシーは、API、 AWS SDKs、または を使用している場合に機能します AWS CLI。コンソールを使用している場合は、コンソールに固有の追加のアクセス許可を付与する必要があります。詳細については、「[コンソールの使用に必要な許可](security-iam-permissions-console.md)」を参照してください。
**注記**
各例は全て、米国西部 (オレゴン) リージョン (`us-west-2`) を使用し、架空のアカウント ID を使用しています。
**例**
+ [例 1: パイプラインの状態を取得するアクセス許可を付与する](#identity-based-policies-example-1)
+ [例 2: ステージ間の移行を有効または無効にするアクセス許可を付与する](#identity-based-policies-example-2)
+ [例 3: 使用可能なすべてのアクションタイプのリストを取得するアクセス許可を付与する](#identity-based-policies-example-3)
+ [例 4: 手動の承認アクションを承認または拒否するアクセス許可を付与する](#identity-based-policies-example-4)
+ [例 5: カスタムアクションのジョブをポーリングするアクセス許可を付与する](#identity-based-policies-example-5)
+ [例 6: Jenkins と AWS CodePipeline の統合に関するポリシーをアタッチまたは編集する](#identity-based-policies-example-6)
+ [例 7: パイプラインへのクロスアカウントアクセスを設定する](#identity-based-policies-example-7)
### 例 1: パイプラインの状態を取得するアクセス許可を付与する
以下の例では、パイプライン (`MyFirstPipeline`) の状態を取得する権限を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:GetPipelineState"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
}
]
}
```
------
### 例 2: ステージ間の移行を有効または無効にするアクセス許可を付与する
以下の例では、パイプライン (`MyFirstPipeline`) のすべてのステージ間での移行を無効化または有効化するアクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:DisableStageTransition",
"codepipeline:EnableStageTransition"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
}
]
}
```
------
ユーザーが、パイプラインの 1 つのステージでの移行を無効化または有効化できるようにするには、ステージを指定する必要があります。例えば、ユーザーがパイプライン `Staging` のステージ `MyFirstPipeline` の移行を有効化または無効化できるようにするには、以下を行います。
```
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"
```
### 例 3: 使用可能なすべてのアクションタイプのリストを取得するアクセス許可を付与する
以下の例では、`us-west-2` リージョンのパイプラインで利用できるすべてのアクションの種類のリストを取得するためのアクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:ListActionTypes"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*"
}
]
}
```
------
### 例 4: 手動の承認アクションを承認または拒否するアクセス許可を付与する
以下の例では、パイプライン `MyFirstPipeline` のステージ `Staging` で手動の承認アクションを承認または拒否するためのアクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PutApprovalResult"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*"
}
]
}
```
------
### 例 5: カスタムアクションのジョブをポーリングするアクセス許可を付与する
以下の例では、カスタムアクション `TestProvider` のジョブをポーリングするためのアクセス許可を付与します。これは、すべてのパイプラインで最初のバージョンのアクションの種類である `Test` です。
**注記**
カスタムアクションのジョブワーカーは、異なる AWS アカウントを使用して設定するか、特定の IAM ロールで実行する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PollForJobs"
],
"Resource": [
"arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1"
]
}
]
}
```
------
### 例 6: Jenkins と AWS CodePipeline の統合に関するポリシーをアタッチまたは編集する
ビルドまたはテストに Jenkins を使用するようにパイプラインを設定する場合は、その統合用に別の ID を作成し、Jenkins と の統合に必要な最小限のアクセス許可を持つ IAM ポリシーをアタッチします。このポリシーは、`AWSCodePipelineCustomActionAccess` マネージドポリシーと同じです。以下の例では、Jenkins との統合で使用するポリシーを示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:AcknowledgeJob",
"codepipeline:GetJobDetails",
"codepipeline:PollForJobs",
"codepipeline:PutJobFailureResult",
"codepipeline:PutJobSuccessResult"
],
"Resource": "*"
}
]
}
```
------
### 例 7: パイプラインへのクロスアカウントアクセスを設定する
別の AWS アカウントのユーザーおよびグループのパイプラインへのアクセスを設定できます。推奨される方法は、パイプラインが作成されたアカウントにロールを作成することです。ロールは、他の AWS アカウントのユーザーがそのロールを引き受けてパイプラインにアクセスすることを許可する必要があります。詳細については、「[ウォークスルー: ロールを使用したクロスアカウントアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html)」を参照してください。
次の例は、80398EXAMPLE アカウントのポリシーを示しています。このポリシーでは、コンソール`MyFirstPipeline`で という名前のパイプラインを表示することはできますが、変更することはできません。このポリシーは、`AWSCodePipeline_ReadOnlyAccess` マネージドポリシーに基づいていますが、パイプライン `MyFirstPipeline` に固有であるため、このマネージドポリシーを直接使用することはできません。ポリシーを特定のパイプラインに制限しない場合は、 によって作成および保守されているいずれかのマネージドポリシーを使用することを検討してください。詳細については、「[マネージドポリシーの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)」を参照してください。このポリシーは、アクセス用に作成した IAM ロール (`CrossAccountPipelineViewers` という名前のロールなど) にアタッチする必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:GetPipeline",
"codepipeline:GetPipelineState",
"codepipeline:ListActionTypes",
"codepipeline:ListPipelines",
"iam:ListRoles",
"s3:GetBucketPolicy",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"codedeploy:GetApplication",
"codedeploy:GetDeploymentGroup",
"codedeploy:ListApplications",
"codedeploy:ListDeploymentGroups",
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEnvironments",
"lambda:GetFunctionConfiguration",
"lambda:ListFunctions"
],
"Resource": "arn:aws:codepipeline:us-east-2:111122223333:MyFirstPipeline"
}
]
}
```
------
このポリシーを作成したら、アカウント (80398EXAMPLE) に IAM ロールを作成し、そのロールにポリシーをアタッチします。ロールの信頼関係で、このロールを引き受ける AWS アカウントを追加する必要があります。
次の例は、ユーザーが 80398EXAMPLE アカウントで という名前のロールを引き受けることを許可する *111111111111* AWS アカウント`CrossAccountPipelineViewers`で作成されたポリシーを示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/CrossAccountPipelineViewers"
}
]
}
```
------
# AWS CodePipeline リソースベースのポリシーの例
**Topics**
Simple Storage Service (Amazon S3) などの他のサービスでは、リソースベースの許可ポリシーもサポートされています。例えば、ポリシーを S3 バケットにアタッチして、そのバケットに対するアクセス許可を管理できます。CodePipeline は、リソースベースのポリシーをサポートしていませんが、バージョニングされた S3 バケットのパイプラインで使用されるアーティファクトを保存します。
**Example S3 バケットのポリシーを作成して、CodePipeline のアーティファクトストアとして使用する方法**
バージョニングされた S3 バケットを CodePipeline のアーティファクトストアとして使用します。[**パイプラインの作成**] ウィザードを使用して最初のパイプラインを作成した場合、この S3 バケットは、アーティファクトストアにアップロードされているすべてのオブジェクトが暗号化されており、バケットへの接続が安全であることを保証するために作成されます。ベストプラクティスとして、独自の S3 バケットを作成する場合は、以下のポリシーまたはその要素をバケットに追加することを検討してください。このポリシーでは、S3 バケットの ARN は `codepipeline-us-east-2-1234567890` です。この ARN を S3 バケットの ARN に置き換えます。
****
```
{
"Version":"2012-10-17",
"Id": "SSEAndSSLPolicy",
"Statement": [
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyInsecureConnections",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": false
}
}
}
]
}
```
# AWS CodePipeline ID とアクセスのトラブルシューティング
次の情報は、CodePipeline と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [CodePipeline でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [管理者として CodePipeline へのアクセスを他のユーザーに許可したい](#security_iam_troubleshoot-admin-delegate)
+ [自分の AWS アカウント以外のユーザーに CodePipeline リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## CodePipeline でアクションを実行する権限がない
にアクションを実行する権限がないと AWS マネジメントコンソール 通知された場合は、管理者に連絡してサポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。
以下の例のエラーは、`mateojackson` IAM ユーザーがコンソールを使用してパイプラインの詳細を表示しようとしているが、 `codepipeline:GetPipeline` の許可がない場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: codepipeline:GetPipeline on resource: my-pipeline
```
この場合、Mateo は、`codepipeline:GetPipeline` アクションを使用して `my-pipeline` リソースにアクセスできるように、管理者にポリシーの更新を依頼します。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がありませんというエラーが表示された場合、管理者に問い合わせ、サポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。CodePipeline にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して CodePipeline でアクションを実行しようする場合に発生します。ただし、アクションには、サービスロールによってサービスに許可が付与されている必要があります。Mary には、ロールをサービスに渡す許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary は `iam:PassRole` アクションの実行が許可されるように、担当の管理者にポリシーの更新を依頼します。
## 管理者として CodePipeline へのアクセスを他のユーザーに許可したい
CodePipeline へのアクセスを他のユーザーに許可するには、アクセスを必要とするユーザーまたはアプリケーションにアクセス許可を付与する必要があります。 AWS IAM アイデンティティセンター を使用してユーザーとアプリケーションを管理する場合は、アクセスレベルを定義するアクセス許可セットをユーザーまたはグループに割り当てます。アクセス許可セットは、ユーザーまたはアプリケーションに関連付けられている IAM ロールに自動的に IAM ポリシーを作成して割り当てます。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
IAM アイデンティティセンターを使用していない場合は、アクセスを必要とするユーザーまたはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。次に、CodePipeline の適切なアクセス許可を付与するポリシーを、そのエンティティにアタッチする必要があります。アクセス許可が付与されたら、ユーザーまたはアプリケーション開発者に認証情報を提供します。これらの認証情報を使用して AWSにアクセスします。IAM ユーザー、グループ、ポリシー、アクセス許可の作成の詳細については、「*IAM ユーザーガイド*」の「[IAM アイデンティティ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」と「[IAM のポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。
## 自分の AWS アカウント以外のユーザーに CodePipeline リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ CodePipeline の今後の対応予定機能の詳細は、[が IAM と AWS CodePipeline 連携する方法](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) を参照してください。
# アクセス許可に関するリファレンス
IAM アイデンティティ (アイデンティティベースのポリシー) にアタッチできるアクセスコントロールの設定やアクセス許可ポリシーのを作成する際に、以下の表をリファレンスとして使用します。この表には、各 API オペレーション、およびその実行のためのアクセス権限を付与できる対応するアクションを示しています。*リソースレベルのアクセス許可*をサポートするオペレーションの場合、 テーブルにはアクセス許可を付与できる AWS リソースが一覧表示されます。アクションは、ポリシーの `Action` フィールドで指定します。
*リソースレベルのアクセス許可*は、ユーザーがアクションを実行できるリソースを指定できるアクセス許可です。 AWS CodePipeline は、リソースレベルのアクセス許可を部分的にサポートします。つまり、一部の AWS CodePipeline API コールでは、満たす必要がある条件に基づいてユーザーがこれらのアクションを使用できるタイミングや、ユーザーが使用できるリソースを制御できます。例えば、パイプラインの実行情報を一覧表示できるが、特定のパイプラインに限定するアクセス許可をユーザーに付与できます。
**注記**
[**リソース**] 列には、リソースレベルのアクセス許可をサポートする API コールに必要なリソースが一覧表示されます。リソースレベルのアクセス許可をサポートしない API コールの場合は、それを使用するためのアクセス許可をユーザーに付与できますが、ポリシーステートメントのリソース要素でワイルドカード (\$1) を指定する必要があります。
**API オペレーションとアクションに必要なアクセス許可**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/permissions-reference.html)
# CodePipeline サービスロールを管理する
サービスロールは、パイプラインで使用される AWS リソースへのアクセスを制御する 1 つ以上のポリシーで設定されます。このロールにさらにポリシーをアタッチしたり、ロールにアタッチされたポリシーを編集したり、 で他のサービスロールのポリシーを設定したりできます AWS。また、パイプラインへクロスアカウントアクセスを設定する際に、ポリシーをロールにアタッチすることもできます。
**重要**
ポリシーステートメントを変更するか、他のポリシーをロールにアタッチすると、パイプラインの動作が停止することがあります。 のサービスロールは、必ず影響を理解した上で変更するようにしてください。パイプラインは、必ずサービスロールに変更を加えてからテストします。
**注記**
コンソールでは、2018 年 9 月より前に作成されたサービスロールは、`oneClick_AWS-CodePipeline-Service_ID-Number` という名前で作成されています。
2018 年 9 月以降に作成されたサービスロールは、サービスロール名の形式 `AWSCodePipelineServiceRole-Region-Pipeline_Name` を使用します。例えば、`MyFirstPipeline` という名前のパイプラインが `eu-west-2` にある場合、コンソールはロールとポリシー `AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline` の名前を付けます。
## CodePipeline のサービスロールポリシー
CodePipeline のサービスロールポリシーステートメントには、パイプラインを管理するための最小限必要なアクセス許可が含まれています。サービスロールのステートメントを編集して、使用していないリソースへのアクセスを削除または追加します。CodePipeline が各アクションに使用する最小限必要なアクセス許可については、適切なアクションリファレンスを参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3BucketAccess",
"Effect": "Allow",
"Action": [
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
},
{
"Sid": "AllowS3ObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:PutObjectTagging",
"s3:GetObjectTagging",
"s3:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::[[pipeArtifactBucketNames]]/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "{{accountId}}"
}
}
}
]
}
```
------
**注記**
ポリシーでは、ソースバケット内の S3 オブジェクトにタグがある場合、次のアクセス許可が必要です。
```
s3:PutObjectTagging
s3:GetObjectTagging
s3:GetObjectVersionTagging
```
## CodePipeline サービスロールからアクセス許可を削除する
サービスロールのステートメントを編集して、使用していないリソースへのアクセスを削除します。例えば、いずれのパイプラインにも Elastic Beanstalk が含まれていない場合は、ポリシーステートメントを編集して Elastic Beanstalk リソースへのアクセスを許可するセクションを削除できます。
同様に、いずれのパイプラインにも CodeDeploy が含まれていない場合は、ポリシーステートメントを編集して CodeDeploy リソースへのアクセスを許可するセクションを削除できます。
```
{
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetApplicationRevision",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:RegisterApplicationRevision"
],
"Resource": "*",
"Effect": "Allow"
},
```
## CodePipeline サービスロールにアクセス許可を追加する
サービスロールのポリシーステートメントは、パイプラインで使用する前に、デフォルトのサービスロールのポリシーステートメントに含まれていない AWS のサービス のアクセス許可で更新する必要があります。
これは、パイプラインに使用するサービスロールが、 のサポートが に追加される前に作成された場合に特に重要です AWS のサービス。
以下の表は、他の AWS のサービスにサポートが追加された場合の例を示しています。
****
| AWS のサービス | CodePipeline のサポート日付 |
| --- | --- |
| CodePipeline の呼び出しアクションのサポートが追加されました。「[CodePipeline 呼び出しアクションのサービスロールポリシーのアクセス許可](action-reference-PipelineInvoke.md#action-reference-PipelineInvoke-permissions-action)」を参照してください。 | 2025 年 3 月 14 日 |
| EC2 アクションのサポートが追加されました。「[EC2 デプロイアクションのサービスロールポリシーのアクセス許可](action-reference-EC2Deploy.md#action-reference-EC2Deploy-permissions-action)」を参照してください。 | 2025 年 2 月 21 日 |
| EKS アクションのサポートが追加されました。「[サービスロールのポリシーのアクセス許可](action-reference-EKS.md#action-reference-EKS-service-role)」を参照してください。 | 2025 年 2 月 20 日 |
| Amazon Elastic Container Registry の ECRBuildAndPublish アクションのサポートが追加されました。「[サービスロールのアクセス許可: `ECRBuildAndPublish` アクション](action-reference-ECRBuildAndPublish.md#edit-role-ECRBuildAndPublish)」を参照してください。 | 2024 年 11 月 22 日 |
| Amazon Inspector の InspectorScan アクションのサポートが追加されました。「[サービスロールのアクセス許可: `InspectorScan` アクション](action-reference-InspectorScan.md#edit-role-InspectorScan)」を参照してください。 | 2024 年 11 月 22 日 |
| コマンドアクションのサポートが追加されました。「[サービスロールのアクセス許可: コマンドアクション](action-reference-Commands.md#edit-role-Commands)」を参照してください。 | 2024 年 10 月 3 日 |
| CloudFormation アクションのサポートが追加されました。「[サービスロールのアクセス許可: `CloudFormationStackSet` アクション](action-reference-StackSets.md#edit-role-cfn-stackset)」および「[サービスロールのアクセス許可: `CloudFormationStackInstances` アクション](action-reference-StackSets.md#edit-role-cfn-stackinstances)」を参照してください。 | 2020 年 12 月 30 日 |
| CodeCommit フルクローン出力アーティファクト形式のサポートが追加されました。「[サービスロールのアクセス許可: CodeCommit アクション](action-reference-CodeCommit.md#edit-role-codecommit)」を参照してください。 | 2020 年 11 月 11 日 |
| AWS CodeBuild バッチビルドアクションのサポートが追加されました。「[サービスロールのアクセス許可: CodeCommit アクション](action-reference-CodeCommit.md#edit-role-codecommit)」を参照してください。 | 2020 年 7 月 30 日 |
| AWS AppConfig アクションのサポートが追加されました。「[サービスロールのアクセス許可: `AppConfig` アクション](action-reference-AppConfig.md#edit-role-appconfig)」を参照してください。 | 2020 年 6 月 22 日 |
| AWS Step Functions アクションのサポートが追加されました。「[サービスロールのアクセス許可: `StepFunctions` アクション](action-reference-StepFunctions.md#edit-role-stepfunctions)」を参照してください。 | 2020 年 5 月 27 日 |
| AWS CodeStar Connections アクションのサポートが追加されました。「[サービスロールのアクセス許可: CodeConnections アクション](action-reference-CodestarConnectionSource.md#edit-role-connections)」を参照してください。 | 2019 年 12 月 18 日 |
| S3 デプロイアクションのサポートが追加されました。「[サービスロールのアクセス許可: S3 デプロイアクション](action-reference-S3Deploy.md#edit-role-s3deploy)」を参照してください。 | 2019 年 1 月 16 日 |
| CodeDeployToECS アクションのサポートが追加されました。「[サービスロールのアクセス許可: `CodeDeployToECS` アクション](action-reference-ECSbluegreen.md#edit-role-codedeploy-ecs)」を参照してください。 | 2018 年 11 月 27 日 |
| Amazon ECR アクションのサポートが追加されました。「[サービスロールのアクセス許可: Amazon ECR アクション](action-reference-ECR.md#edit-role-ecr)」を参照してください。 | 2018 年 11 月 27 日 |
| Service Catalog アクションのサポートが追加されました。「[サービスロールのアクセス許可: Service Catalog アクション](action-reference-ServiceCatalog.md#edit-role-servicecatalog)」を参照してください。 | 2018 年 10 月 16 日 |
| AWS Device Farm アクションのサポートが追加されました。「[サービスロールのアクセス許可: AWS Device Farm アクション](action-reference-DeviceFarm.md#edit-role-devicefarm)」を参照してください。 | 2018 年 7 月 19 日 |
| Amazon ECS アクションのサポートが追加されました。「[サービスロールのアクセス許可: Amazon ECS 標準アクション](action-reference-ECS.md#edit-role-ecs)」を参照してください。 | 2017 年 12 月 12 日 / 2017 年 7 月 21 日から開始されたタグ付け承認のオプトインのための更新 |
| CodeCommit アクションのサポートが追加されました。「[サービスロールのアクセス許可: CodeCommit アクション](action-reference-CodeCommit.md#edit-role-codecommit)」を参照してください。 | 2016 年 4 月 18 日 |
| AWS OpsWorks アクションのサポートが追加されました。「[サービスロールのアクセス許可: AWS OpsWorks アクション](action-reference-OpsWorks.md#edit-role-opsworks)」を参照してください。 | 2016 年 6 月 2 日 |
| CloudFormation アクションのサポートが追加されました。「[サービスロールのアクセス許可: CloudFormation アクション](action-reference-CloudFormation.md#edit-role-cloudformation)」を参照してください。 | 2016 年 11 月 3 日 |
| AWS CodeBuild アクションのサポートが追加されました。「[サービスロールのアクセス許可: CodeBuild アクション](action-reference-CodeBuild.md#edit-role-codebuild)」を参照してください。 | 2016 年 12 月 1 日 |
| Elastic Beanstalk アクションのサポートが追加されました。「[サービスロールのアクセス許可: `ElasticBeanstalk` のデプロイアクション](action-reference-Beanstalk.md#edit-role-beanstalk)」を参照してください。 | 初回サービス起動 |
| CodeDeploy アクションのサポートが追加されました。「[サービスロールのアクセス許可: AWS CodeDeploy アクション](action-reference-CodeDeploy.md#edit-role-codedeploy)」を参照してください。 | 初回サービス起動 |
| S3 ソースアクションのサポートが追加されました。「[サービスロールのアクセス許可: S3 ソースアクション](action-reference-S3.md#edit-role-s3source)」を参照してください。 | 初回サービスの起動 |
サポートされているサービスのアクセス許可を追加するには、次の手順に従います。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールのナビゲーションペインで、[**ロール**] を選択し、ロールのリストから `AWS-CodePipeline-Service` ロール を選択します。
1. [**アクセス権限**] タブの [**インラインポリシー**] で、サービスロールポリシーの列の [**ポリシーの編集**] を選択します。
1. [**Policy Document**] ボックスに必要なアクセス許可を追加します。
**注記**
IAM ポリシーを作成するとき、最小限の特権を認めるという標準的なセキュリティアドバイスに従いましょう。そうすれば、タスクを実行するというリクエストのアクセス許可のみを認めることができます。一部の API コールはリソースベースのアクセス許可をサポートしており、アクセスを制限できます。たとえば、この場合、`DescribeTasks` および `ListTasks` を呼び出す際のアクセス許可を制限するために、ワイルドカード文字 (\$1) をリソース ARN またはワイルドカード文字 (\$1) を含むリソース ARN に置き換えることができます。最小権限アクセスを付与するポリシーの作成の詳細については、[https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) を参照してください。
1. **[Review policy]** (ポリシーの確認) を選択して、ポリシーにエラーがないことを確認します。ポリシーにエラーがなければ、**ポリシーの適用** を選択します。
# CodePipeline でのロギングとモニタリング
のログ記録機能を使用して AWS 、ユーザーがアカウントで実行したアクションと使用されたリソースを判断できます。ログファイルは次の情報を表示します：
+ アクションが実行された日時。
+ アクションのソース IP アドレス。
+ 不適切なアクセス権限が理由で失敗したアクション。
ロギング機能は次の AWS のサービスで使用できます。
+ AWS CloudTrail は、 によって行われた、または に代わって行われた AWS API コールおよび関連イベントのログ記録に使用できます AWS アカウント。詳細については、「[を使用した CodePipeline API コールのログ記録 AWS CloudTrail](monitoring-cloudtrail-logs.md)」を参照してください。
+ Amazon CloudWatch Events を使用して、 AWS クラウド リソースと実行するアプリケーションをモニタリングできます AWS。定義したメトリクスに基づいて、 Amazon CloudWatch Events でアラートを作成できます。詳細については、「[CodePipeline イベントのモニタリング](detect-state-changes-cloudwatch-events.md)」を参照してください。
# のコンプライアンス検証 AWS CodePipeline
AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによる対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照し、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
アーティファクトを使用してサードパーティーの監査レポートをダウンロードできます。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# の耐障害性 AWS CodePipeline
AWS グローバルインフラストラクチャは、 AWS リージョンとアベイラビリティーゾーンを中心に構築されています。 AWS リージョンは、低レイテンシー、高スループット、高度に冗長なネットワークで接続された、物理的に分離された複数のアベイラビリティーゾーンを提供します。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェールオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、[AWS 「グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# のインフラストラクチャセキュリティ AWS CodePipeline
マネージドサービスである AWS CodePipeline は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS 公開された API コールを使用して、ネットワーク経由で CodePipeline にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
# セキュリティのベストプラクティス
**Topics**
CodePipeline には、独自のセキュリティポリシーを開発および実装する際に考慮する必要のあるいくつかのセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。
パイプラインに接続するソースリポジトリには暗号化と認証を使用します。こちらがセキュリティで使用する CodePipeline のベストプラクティスです。
+ トークンやパスワードのようなシークレットを含むパイプラインやアクション設定を作成する場合は、そのシークレットをアクション設定や、パイプラインレベルまたは CloudFormation 設定で定義された変数のデフォルト値に直接入力しないでください。シークレットの情報がログに表示される可能性があるためです。[AWS Secrets Manager を使用してデータベースパスワードまたはサードパーティー API キーを追跡する](parameter-store-encryption.md) で説明しているように、Secrets Manager を使用してシークレットを設定して保存し、パイプラインとアクション設定には、シークレットの参照を使用します。
+ S3 ソースバケットを使用するパイプラインを作成する場合は、 AWS KMS keysを管理して CodePipeline 用の Amazon S3 に保存されたアーティファクトのサーバー側の暗号化を設定します。[CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する](S3-artifact-encryption.md) に説明があります。
+ Jenkins アクションプロバイダを使用しており、Jenkins ビルドプロバイダをパイプラインのビルドまたはテスト作業に使用する際は、ECS インスタンスに Jenkins をインストールし、別の EC2 インスタンスプロファイルを構成してください。インスタンスプロファイルが、Amazon S3 からファイルを取得するなど、プロジェクトのタスクを実行するために必要な AWS アクセス許可のみを Jenkins に付与していることを確認します。Jenkins インスタンスプロファイルのロールを作成する方法については、「[Jenkins 統合に使用する IAM ロールを作成する](tutorials-four-stage-pipeline.md#tutorials-four-stage-pipeline-prerequisites-jenkins-iam-role)」のステップを参照してください。