AWS CodeCommitの認証とアクセスコントロール - AWS CodeCommit

AWS CodeCommit は、新しいお客様では利用できなくなりました。 AWS CodeCommit の既存のお客様は、通常どおりサービスを引き続き使用できます。詳細はこちら

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

AWS CodeCommitの認証とアクセスコントロール

へのアクセスには認証情報 AWS CodeCommit が必要です。これらの認証情報には、Git 認証情報や Git 接続に使用するSSHパブリックキーの管理に使用する CodeCommit リポジトリやIAMユーザーなどの AWS リソースにアクセスするためのアクセス許可が必要です。以下のセクションでは、 AWS Identity and Access Management (IAM) と CodeCommit を使用してリソースへの安全なアクセスを実現する方法について詳しく説明します。

認証

CodeCommit リポジトリは Git ベースであり、Git 認証情報を含む Git の基本機能をサポートしているため、 を使用する際はIAMユーザーを使用することをお勧めします CodeCommit。他の ID タイプ CodeCommit を使用して にアクセスできますが、他の ID タイプには、以下で説明するように制限が適用されます。

アイデンティティタイプ

  • IAM userIAMユーザーは、特定のカスタムアクセス許可を持つ Amazon Web Services アカウント内の ID です。例えば、リポジトリにアクセスするための Git 認証情報を作成および管理するためのアクセス許可をIAMユーザーに付与できます CodeCommit 。これは、 の使用に推奨されるユーザータイプです CodeCommit。IAM ユーザー名とパスワードを使用してサインインしAWS Management Console、、AWS ディスカッションフォーラムAWS Support センター などの AWS ウェブページを保護することができます。

    Git 認証情報を生成したり、SSHパブリックキーをIAMユーザーに関連付けることも、 をインストールして設定することもできますgit-remote-codecommit。これらは、 CodeCommit リポジトリを操作するように Git を設定する最も簡単な方法です。Git 認証情報 では、 で静的ユーザー名とパスワードを生成しますIAM。次に、Git および Git ユーザー名とパスワード認証をサポートするサードパーティーツールHTTPSへの接続にこれらの認証情報を使用します。SSH 接続では、Git と をSSH認証 CodeCommit に使用するパブリックキーファイルとプライベートキーファイルをローカルマシンに作成します。パブリックキーをIAMユーザーに関連付けると、プライベートキーをローカルマシンに保存します。 は Git 自体git-remote-codecommitを拡張し、ユーザーの Git 認証情報を設定する必要はありません。

    また、各ユーザーのアクセスキーを生成することができます。 AWS のサービスにプログラムでアクセスする場合は、 のいずれか AWS SDKsまたは AWS Command Line Interface (AWS CLI) を使用してアクセスキーを使用します。SDK および CLIツールは、アクセスキーを使用してリクエストに暗号化的に署名します。 AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。 CodeCommit は、インバウンドAPIリクエストを認証するためのプロトコルである署名バージョン 4 をサポートしています。リクエストの認証の詳細については、『』の「署名バージョン 4 の署名プロセスAWS 全般のリファレンス」を参照してください。

  • Amazon Web Services アカウントのルートユーザー – にサインアップすると AWS、Amazon Web Services アカウントに関連付けられている E メールアドレスとパスワードが提供されます。これらは [ルート認証情報]であり、これらの情報を使用すると、すべての AWS リソースに完全にアクセスできるようになります。一部の CodeCommit 機能は、ルートアカウントユーザーでは使用できません。さらに、ルートアカウントで Git を使用する唯一の方法は、 をインストールして設定する git-remote-codecommit (推奨) か、 に含まれている AWS 認証情報ヘルパーを設定することです AWS CLI。Git 認証情報またはSSHパブリック/プライベートキーペアをルートアカウントユーザーで使用することはできません。これらの理由から、 を操作するときにルートアカウントユーザーを使用することはお勧めしません CodeCommit。

    重要

    セキュリティ上の理由から、 ルート認証情報は、アカウント AWS への完全なアクセス許可を持つユーザーである管理者ユーザー の作成にのみ使用することをお勧めします。 IAM 次に、この管理者ユーザーを使用して、アクセス許可が制限された他のユーザーIAMとロールを作成できます。詳細については、IAM「 ユーザーガイド」のIAM「ベストプラクティス」と「管理者ユーザーとグループの作成」を参照してください。

  • IAM Identity Center と IAM Identity Center のユーザー – AWS IAM Identity Center の機能を拡張 AWS Identity and Access Management して、ユーザーの管理と、ユーザーによる AWS アカウント および クラウドアプリケーションへのアクセスをまとめた一元的な場所を提供します。を使用するほとんどのユーザーにはベストプラクティスとして推奨されていますが AWS、IAMIdentity Center では現在、Git 認証情報やSSHキーペアのメカニズムを提供していません。これらのユーザーはリポジトリをローカルでクローンgit-remote-codecommit CodeCommitするようにインストールおよび設定できますが、すべての統合開発環境 (IDEs) が でのクローン作成、プッシュ、プルをサポートしているわけではありませんgit-remote-codecommit

    ベストプラクティスとして、 では、管理者アクセスを必要とするユーザーを含む人間のユーザーに、一時的な認証情報を使用してアクセスするために ID プロバイダーとのフェデレーション AWS のサービス の使用を要求します。

    フェデレーティッド ID は、エンタープライズユーザーディレクトリ、ウェブアイデンティティプロバイダー、 AWS Directory Service、アイデンティティセンターディレクトリ、または ID ソースを介して提供された認証情報 AWS のサービス を使用してアクセスするすべてのユーザーのユーザーです。フェデレーティッド ID が にアクセスすると AWS アカウント、それらはロールを引き受け、ロールは一時的な認証情報を提供します。

    アクセスを一元管理する場合は、 AWS IAM Identity Centerを使用することをお勧めします。IAM Identity Center でユーザーとグループを作成するか、独自の ID ソース内のユーザーとグループのセットに接続して同期し、すべての AWS アカウント とアプリケーションで使用できます。IAM Identity Center の詳細については、AWS IAM Identity Center 「 ユーザーガイド」のIAM「Identity Center とは」を参照してください。

  • IAM ロール – IAM ユーザーと同様に、IAMロールは、特定のアクセス許可を付与するためにアカウントで作成できる IAM ID です。

    IAM ロールは、特定のアクセス許可 AWS アカウント を持つ 内の ID です。ユーザーと似ていますがIAM、特定の人物には関連付けられていません。でIAMロールを一時的に引き受けるには AWS Management Console、ユーザーからIAMロール (コンソール) に切り替えることができます。または AWS API オペレーションを AWS CLI 呼び出すか、カスタム を使用してロールを引き受けることができますURL。ロールを使用する方法の詳細については、IAM「 ユーザーガイド」の「ロールを引き受ける方法」を参照してください。

    IAM 一時的な認証情報を持つ ロールは、以下の状況で役立ちます。

    • フェデレーションユーザーアクセス – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーティッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションのロールの詳細については、 IAM ユーザーガイド「サードパーティー ID プロバイダーのロールの作成」を参照してください。IAM Identity Center を使用する場合は、アクセス許可セットを設定します。ID が認証された後にアクセスできる内容を制御するために、IAMIdentity Center はアクセス許可セットを のロールに関連付けますIAM。アクセス許可セットの詳細については、「AWS IAM Identity Center ユーザーガイド」の「アクセス許可セット」を参照してください。

    • 一時的なIAMユーザーアクセス許可 – IAM ユーザーまたはロールは、特定のタスクに対して異なるアクセス許可を一時的に引き受けるIAMロールを引き受けることができます。

    • クロスアカウントアクセス – IAMロールを使用して、別のアカウントの誰か (信頼できるプリンシパル) が自分のアカウントのリソースにアクセスすることを許可できます。クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の では AWS のサービス、 (プロキシとしてロールを使用する代わりに) リソースに直接ポリシーをアタッチできます。クロスアカウントアクセスのロールとリソースベースのポリシーの違いについては、IAM「 ユーザーガイド」の「 のクロスアカウントリソースアクセスIAM」を参照してください。

    • クロスサービスアクセス — 他の の機能 AWS のサービス を使用するものもあります AWS のサービス。例えば、サービスで呼び出しを行うと、そのサービスが Amazon でアプリケーションを実行EC2したりAmazon S3にオブジェクトを保存したりするのが一般的です。サービスでは、呼び出し元プリンシパルの許可、サービスロール、またはサービスリンクロールを使用してこれを行う場合があります。

      • 転送アクセスセッション (FAS) – IAM ユーザーまたはロールを使用して でアクションを実行すると AWS、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストのリクエストを使用します。FAS リクエストは、サービスが他の AWS のサービス または リソースとのやり取りを完了する必要があるリクエストを受け取った場合にのみ行われます。この場合、両方のアクションを実行するための権限が必要です。FAS リクエストを行う際のポリシーの詳細については、「アクセスセッションの転送」を参照してください。

      • サービスロール – サービスロールは、ユーザーに代わってアクションを実行するためにサービスが引き受けるIAMロールです。IAM 管理者は、 内からサービスロールを作成、変更、削除できますIAM。詳細については、IAM「 ユーザーガイド」の「 にアクセス許可を委任するロールの作成 AWS のサービス」を参照してください。

      • サービスにリンクされたロール – サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、 サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示することはできますが、編集することはできません。

    • Amazon で実行されているアプリケーション EC2 – IAMロールを使用して、EC2インスタンスで実行され、 AWS CLI または AWS API リクエストを行うアプリケーションの一時的な認証情報を管理できます。これは、EC2インスタンス内にアクセスキーを保存するよりも望ましいです。 AWS ロールをEC2インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルには ロールが含まれており、EC2インスタンスで実行されているプログラムが一時的な認証情報を取得できるようにします。詳細については、IAM「 ユーザーガイド」のIAM「ロールを使用して Amazon EC2インスタンスで実行されているアプリケーションにアクセス許可を付与する」を参照してください。

    注記

    フェデレーティッドユーザーでは、Git 認証情報またはSSHパブリック/プライベートキーペアを使用できません。さらに、ユーザー設定はフェデレーティッドユーザーでは使用できません。フェデレーティッドアクセスを使用して接続を設定する方法については、「git-remote-codecommit を使用して AWS CodeCommit への HTTPS 接続をセットアップする手順」を参照してください。

アクセスコントロール

リクエストを認証するための有効な認証情報を持つことができますが、アクセス許可がない限り、 CodeCommit リソースを作成またはアクセスすることはできません。たとえば、リポジトリの表示、コードのプッシュ、Git の認証情報の作成および管理などにはアクセス許可が必要です。

以下のセクションでは、 のアクセス許可を管理する方法について説明します CodeCommit。最初に概要のセクションを読むことをお勧めします。

CodeCommit リソースへのアクセス許可の管理の概要

すべての AWS リソースは Amazon Web Services アカウントによって所有されています。リソースを作成またはアクセスするためのアクセス許可は、アクセス許可ポリシーで管理されます。アカウント管理者は、アクセス許可ポリシーを ID (ユーザー、グループ、ロール) IAM にアタッチできます。などの一部のサービスでは AWS Lambda、アクセス許可ポリシーのリソースへのアタッチもサポートされています。

注記

アカウント管理者 (または管理者ユーザー) は、管理者権限を持つユーザーです。詳細については、「 ユーザーガイド」のIAM「ベストプラクティス」を参照してください。 IAM

アクセス許可を付与する場合、アクセス許可を取得するユーザー、取得するアクセス許可の対象となるリソース、およびそれらのリソースに対して許可される特定のアクションを決定します。

CodeCommit リソースとオペレーション

では CodeCommit、プライマリリソースはリポジトリです。各リソースには、一意の Amazon リソースネーム (ARN) が関連付けられています。ポリシーでは、Amazon リソースネーム (ARN) を使用して、ポリシーが適用されるリソースを識別します。の詳細についてはARNs、「」の「Amazon リソースネーム (ARN)」と AWS 「サービス名前空間」を参照してくださいAmazon Web Services 全般のリファレンス。 CodeCommit は現在、サブリソースと呼ばれる他のリソースタイプをサポートしていません。

次の表は、 CodeCommit リソースを指定する方法を示しています。

リソースタイプ ARN 形式
リポジトリ

arn:aws:codecommit:region:account-id:repository-name

すべての CodeCommit リポジトリ

arn:aws:codecommit:*

指定されたアカウントが所有するすべての CodeCommit リポジトリ AWS リージョン

arn:aws:codecommit:region:account-id:*

注記

ほとんどの AWS サービスは、 のコロン (:) またはスラッシュ (/) を同じ文字ARNsとして扱います。ただし、 ではリソースパターンとルールの完全一致 CodeCommit が必要です。イベントパターンを作成するときは、リソース内のARN構文と一致するように、必ず正しいARN文字を使用してください。

例えば、特定のリポジトリ (MyDemoRepo) ARNは、次のように ステートメントで使用します。

"Resource": "arn:aws:codecommit:us-west-2:111111111111:MyDemoRepo"

特定のアカウントに属するすべてのリポジトリを指定するには、以下のようにワイルドカード文字 (*) を使用します。

"Resource": "arn:aws:codecommit:us-west-2:111111111111:*"

すべてのリソースを指定するか、特定のAPIアクションが をサポートしていない場合はARNs、次のように Resource要素でワイルドカード文字 (*) を使用します。

"Resource": "*"

また、ワイルドカード文字 (*) を使用して、リポジトリ名の一部に一致するすべてのリソースを指定できます。例えば、 の名前で始まりMyDemo111111111111の Amazon Web Services us-east-2 アカウントに登録されているリポジトリを CodeCommit以下ARNに示します AWS リージョン。

arn:aws:codecommit:us-east-2:111111111111:MyDemo*

CodeCommit リソースで動作する使用可能なオペレーションのリストについては、「」を参照してくださいCodeCommit アクセス許可リファレンス

リソース所有権について

Amazon Web Services アカウントは、誰がリソースを作成したかにかかわらず、アカウントで作成されたリソースを所有します。具体的には、リソース所有者は、リソース作成リクエストを認証するプリンシパルエンティティ (ルートアカウント、IAMユーザー、またはIAMロール) の Amazon Web Services アカウントです。次の例は、この仕組みを示しています。

  • Amazon Web Services アカウントにIAMユーザーを作成し、そのユーザーに CodeCommit リソースを作成するアクセス許可を付与すると、ユーザーは CodeCommit リソースを作成できます。ただし、ユーザーが属する Amazon Web Services アカウントが CodeCommit リソースを所有します。

  • Amazon Web Services アカウントのルートアカウント認証情報を使用してルールを作成する場合、Amazon Web Services アカウントは CodeCommit リソースの所有者です。

  • CodeCommit リソースを作成するアクセス許可を持つIAMロールを Amazon Web Services アカウントに作成する場合、そのロールを引き受けることができるすべてのユーザーが CodeCommit リソースを作成できます。ロールが属する Amazon Web Services アカウントが CodeCommit リソースを所有します。

リソースへのアクセスの管理

AWS リソースへのアクセスを管理するには、アクセス許可ポリシーを使用します。アクセスポリシーは、誰が何に対するアクセス権を持っているのかを説明します。以下のセクションでは、アクセス権限のポリシーを作成するためのオプションについて説明します。

注記

このセクションでは、 のコンテキストIAMでの の使用について説明します CodeCommit。IAM サービスに関する詳細情報は提供されません。の詳細についてはIAM、 IAM ユーザーガイド「 とはIAM」を参照してください。IAM ポリシーの構文と説明については、「 ユーザーガイド」のIAM「ポリシーリファレンス」を参照してください。 IAM

IAM ID にアタッチされたアクセス許可ポリシーは、アイデンティティベースのポリシー (IAM ポリシー) と呼ばれます。リソースにアタッチされたアクセス許可ポリシーは、リソースベースのポリシーと呼ばれます。現在、 CodeCommit は ID ベースのポリシー (IAM ポリシー) のみをサポートしています。

ID ベースのポリシー (IAM ポリシー)

AWS リソースへのアクセスを管理するには、アクセス許可ポリシーを ID IAM にアタッチします。では CodeCommit、アイデンティティベースのポリシーを使用してリポジトリへのアクセスを制御します。例えば、次のオペレーションを実行できます。

  • アカウントのユーザーまたはグループにアクセス許可ポリシーをアタッチする – CodeCommit コンソールで CodeCommit リソースを表示するアクセス許可をユーザーに付与するには、ユーザーが属するユーザーまたはグループに ID ベースのアクセス許可ポリシーをアタッチします。

  • アクセス許可ポリシーをロールにアタッチする (クロスアカウントのアクセス許可を付与) – クロスアカウントアクセスを付与するときなど、委任には、リソースを所有するアカウント (信頼するアカウント) と、リソースへアクセスする必要のあるユーザーを含むアカウント (信頼されたアカウント) の間に信頼を設定することが含まれます。アクセス許可ポリシーは、リソースに対して目的のタスクを実行するために必要なアクセス許可をロールのユーザーに付与します。信頼ポリシーは、どの信頼されたアカウントのユーザーに、ロールを引き受ける権限を与えるかを指定します。詳細については、IAM「 の用語と概念」を参照してください。

    クロスアカウントアクセス許可を付与するには、アイデンティティベースのアクセス許可ポリシーをIAMロールにアタッチします。例えば、アカウント A の管理者は、次のように、別の Amazon Web Services アカウント (アカウント B など) または AWS サービスにクロスアカウントアクセス許可を付与するロールを作成できます。

    1. アカウント 管理者はIAMロールを作成し、アカウント A のリソースに対するアクセス許可を付与するアクセス許可ポリシーをロールにアタッチします。

    2. アカウント A の管理者は、アカウント B をそのロールを引き受けるプリンシパルとして識別するロールに、信頼ポリシーをアタッチします。

    3. アカウント B 管理者は、アカウント B の任意のユーザーにロールを引き受けるアクセス許可を委任できます。これにより、アカウント B のユーザーがアカウント A のリソースを作成またはアクセスできるようになります。ロールを引き受けるアクセス許可を AWS サービスに付与する場合、信頼ポリシーのプリンシパルもサービスプリンシパルになる AWS ことができます。詳細については、「 IAM用語と概念」の「委任」を参照してください。

    を使用してアクセス許可IAMを委任する方法の詳細については、「 ユーザーガイド」の「アクセス管理」を参照してください。 IAM

次のポリシー例では、 という名前のリポジトリにブランチを作成することを許可しています。MyDemoRepo:

{ "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "codecommit:CreateBranch" ], "Resource" : "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo" } ] }

アカウントのユーザーがアクセスできる呼び出しとリソースを制限するには、特定のIAMポリシーを作成してから、それらのポリシーをIAMユーザーにアタッチします。IAM ロールの作成方法と のIAMポリシーステートメントの例については CodeCommit、「」を参照してくださいカスタマー管理のアイデンティティポリシーの例

リソースベースのポリシー

Amazon S3 などのいくつかのサービスでは、リソースベースのアクセス許可ポリシーもサポートされています。例えば、リソースベースのポリシーを S3 バケットにアタッチして、そのバケットへのアクセス許可を管理することができます。 CodeCommit はリソースベースのポリシーをサポートしていませんが、タグを使用してリソースを識別し、ポリシーで使用できますIAM。タグベースのポリシーの例については、ID ベースのポリシー (IAM ポリシー) を参照してください。

でのリソーススコープ CodeCommit

では CodeCommit、「」で説明されているように、アイデンティティベースのポリシーとリソースへのアクセス許可をスコープできますCodeCommit リソースとオペレーション。ただし、リソースへの ListRepositories アクセス許可の範囲を指定することはできません。代わりに、すべてのリソースを範囲とします (ワイルドカード * を使用)。そうしない場合、そのアクションは失敗します。

他のすべての CodeCommit アクセス許可は、リソースにスコープできます。

ポリシー要素 (リソース、アクション、効果、プリンシパル) の指定

ユーザーが リソースにアクセスすることを許可または拒否するポリシーを作成したり、ユーザーがこれらのリソースに対して特定のアクションを実行することを許可または拒否したりできます。 は、 CodeCommit コンソール、、、SDKs AWS CLIまたはこれらの を直接呼び出すことによって、ユーザーがサービスを操作する方法を定義する一連のパブリックAPIオペレーション CodeCommit を定義しますAPIs。これらのAPIオペレーションのアクセス許可を付与するには、ポリシーで指定できる一連のアクション CodeCommit を定義します。

一部のAPIオペレーションでは、複数のアクションに対するアクセス許可が必要になる場合があります。リソースとAPIオペレーションの詳細については、CodeCommit リソースとオペレーション「」および「」を参照してくださいCodeCommit アクセス許可リファレンス

以下に、ポリシーの基本的な要素を示します。

  • リソース – ポリシーが適用されるリソースを特定するには、Amazon リソースネーム () を使用しますARN。詳細については、「CodeCommit リソースとオペレーション」を参照してください。

  • アクション – 許可または拒否するリソースオペレーションを識別するには、アクションキーワードを使用します。例えば、指定された に応じてEffect、 アクセスcodecommit:GetBranch許可により、ユーザーが GetBranch オペレーションを実行することを許可または拒否します。これにより、 CodeCommit リポジトリ内のブランチに関する詳細が取得されます。

  • 効果 – ユーザーが特定のアクションをリクエストする際の効果の実行について、許可または拒否のいずれかを指定します。リソースへのアクセスを明示的に許可していない場合、アクセスは暗黙的に拒否されます。また、明示的にリソースへのアクセスを拒否すると、別のポリシーによってアクセスが許可されている場合でも、ユーザーはリソースにアクセスできなくなります。

  • プリンシパル – ID ベースのポリシー (IAM ポリシー) では、 が CodeCommit サポートするポリシーの唯一のタイプで、ポリシーがアタッチされているユーザーは暗黙的なプリンシパルです。

IAM ポリシー構文の詳細については、「 ユーザーガイド」のIAM「ポリシーリファレンス」を参照してください。 IAM

すべての CodeCommit APIアクションとそれらが適用されるリソースを示す表については、「」を参照してくださいCodeCommit アクセス許可リファレンス

ポリシーでの条件の指定

アクセス許可を付与する場合、 のアクセスポリシー言語を使用してIAM、ポリシーを有効にする条件を指定します。例えば、特定の日付の後にのみ適用されるポリシーが必要になる場合があります。ポリシー言語で条件を指定する方法の詳細については、 IAM ユーザーガイド「条件ポリシーの文法」を参照してください。

条件を表すには、あらかじめ定義された条件キーを使用します。に固有の条件キーはありません CodeCommit。ただし、必要に応じて使用できる AWS全体の条件キーがあります。 AWS全体のキーの完全なリストについては、IAM「 ユーザーガイド」の「条件に使用可能なキー」を参照してください。