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

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

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

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

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

認証

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

アイデンティティタイプ

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

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

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

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

    重要

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

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

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

    フェデレーティッド 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 ロール (コンソール) に切り替えることができます。or AWS API オペレーションを AWS CLI 呼び出すか、カスタム URL を使用してロールを引き受けることができます。ロールの使用方法の詳細については、IAM ユーザーガイドの「ロールを引き受ける方法」を参照してください。

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

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

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

    • クロスアカウントアクセス — IAM ロールを使用して、別のアカウントの誰か (信頼できるプリンシパル) がアカウントのリソースにアクセスすることを許可できます。クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の では AWS のサービス、 (プロキシとしてロールを使用する代わりに) リソースに直接ポリシーをアタッチできます。クロスアカウントアクセスのロールとリソースベースのポリシーの違いについては、IAM ユーザーガイドの「Word の」の「クロスアカウントリソースアクセス」を参照してください。 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 で実行されているアプリケーション – Word ロールを使用して、IAM EC2インスタンスで実行され、 AWS CLI または AWS API リクエストを行っているアプリケーションの一時的な認証情報を管理できます。これは、EC2 インスタンス内にアクセスキーを保存するよりも望ましいです。EC2 インスタンスに AWS ロールを割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれており、EC2 インスタンスで実行されているプログラムが一時的な認証情報を取得できるようにします。詳細については、IAM ユーザーガイド」の「Word ロールを使用して Amazon EC2 インスタンスで実行されているアプリケーションにアクセス許可を付与する」を参照してください。 IAM

    注記

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

アクセスコントロール

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

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

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

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

注記

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

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

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

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

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

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

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

All 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": "*"

また、ワイルドカード文字 (*) を使用して、リポジトリ名の一部に一致するすべてのリソースを指定できます。例えば、次の ARN は、 の名前で始まりMyDemo、 111111111111の Amazon Web Services アカウントに登録されている任意の CodeCommit us-east-2 リポジトリを指定します 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 リソースの所有者です。

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

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

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

注記

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

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

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

AWS リソースへのアクセスを管理するには、アクセス許可ポリシーを IAM ID にアタッチします。In 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 ロールの作成方法と CodeCommit の IAM ポリシーステートメントの例については、「」を参照してくださいカスタマー管理のアイデンティティポリシーの例。

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

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

in CodeCommit のリソーススコープ

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

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

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

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

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

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

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

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

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

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

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

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

ポリシーの条件の指定

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

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