AWS アカウント間での CloudTrail ログファイルの共有 - AWS CloudTrail

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

AWS アカウント間での CloudTrail ログファイルの共有

このセクションでは、複数の AWS アカウント間で CloudTrail ログファイルを共有する方法について説明します。間でログを共有するために使用する方法は、S3 バケットの設定 AWS アカウント によって異なります。ログファイルを共有するためのオプションは次のとおりです。

  • バケット所有者の強制S3 オブジェクトの所有権は Amazon S3 バケットレベルの設定であり、バケットにアップロードされたオブジェクトの所有権を制御し、アクセスコントロールリスト (ACL) を有効または無効にために使用できます。デフォルトでは、オブジェクト所有権は [バケット所有者の強制] により設定され、すべての ACL は無効になっています。ACL が無効になっている場合、バケット所有者はバケット内のすべてのオブジェクトを所有し、アクセス管理ポリシーのみを使用してデータへのアクセスを管理します。[バケット所有者の強制] オプションを設定すると、アクセスはバケットポリシーによって管理されるため、ユーザーが役割を引き受ける必要がなくなります。

  • ログファイルを共有するロールを引き受ける[バケット所有者の強制] 設定を選択していない場合、ユーザーは S3 バケット内のログファイルにアクセスするロールを引き受ける必要があります。

ロールを引き受けてアカウント間でログファイルを共有する

注記

このセクションは、[バケット所有者の強制] 設定を使用していない Amazon S3 バケットにのみ適用されます。

このセクションでは、ロールを引き受け AWS アカウント て複数の 間で CloudTrail ログファイルを共有する方法と、ログファイルを共有するシナリオについて説明します。

  • シナリオ 1: Amazon S3 バケットに保存されているログファイルの生成元のアカウントに、読み取り専用のアクセス権限を付与します。

  • シナリオ 2: Amazon S3 バケット内のすべてのログファイルへのアクセス権を、ログファイルを分析するためのサードパーティのアカウントに付与します。

Amazon S3 バケット内のログファイルへの読み取り専用アクセス権を付与するには
  1. ログファイルを共有する各アカウントのために、IAM ロールを作成します。アクセス許可を付与するには管理者である必要があります。

    ロールを作成する場合、以下の作業を行います。

    • [その他の AWS アカウント] オプションを選択します。

    • アクセス許可が付与されるアカウントの、12 桁のアカウント ID を入力します。

    • ロールを割り当てる前に、ユーザーに多要素認証を提供させる場合は、[Require MFA] ボックスをオンにします。

    • AmazonS3ReadOnlyAccess ポリシーを選択します。

      注記

      デフォルトでは、AmazonS3ReadOnlyAccess ポリシーは、アカウント内のすべての Amazon S3 バケットに対する取得および一覧表示権限を付与します。

    IAM ロールのアクセス許可の管理の詳細については、「IAM ユーザーガイド」の「IAM ロール」を参照してください。

  2. ログファイルを共有するアカウントに読み取り専用のアクセス権限を付与する、アクセスポリシーを作成します。

  3. ログファイルを取得するロールを引き受けるよう、各アカウントに指示します。

サードパーティアカウントにログファイルへの読み取り専用アクセス権を付与するには
  1. ログファイルを共有するサードパーティアカウント用の IAM ロールを作成します。アクセス許可を付与するには管理者である必要があります。

    ロールを作成する場合、以下の作業を行います。

    • [その他の AWS アカウント] オプションを選択します。

    • アクセス許可が付与されるアカウントの、12 桁のアカウント ID を入力します。

    • ロールを担当できるユーザーをより高度に制御できるようにするための、外部 ID を入力します。詳細については、「IAM ユーザーガイド」の「 AWS リソースへのアクセスを第三者に許可するときに外部 ID を使用する方法」を参照してください。

    • AmazonS3ReadOnlyAccess ポリシーを選択します。

      注記

      デフォルトでは、AmazonS3ReadOnlyAccess ポリシーは、アカウント内のすべての Amazon S3 バケットに対する取得および一覧表示権限を付与します。

  2. ログファイルを共有するサードパーティアカウントに読み取り専用のアクセス権限を付与する、アクセスポリシーを作成します。

  3. ログファイルを取得するロールを引き受けるよう、サードパーティアカウントに指示します。

次のセクションでは、これらの手順についてさらに詳しく説明しています。

自分が所有するアカウントへのアクセスを許可するアカウントポリシーの作成

Amazon S3 バケット所有者は、 が他のアカウントのログファイルを CloudTrail 書き込む Amazon S3 バケットを完全に制御できます。各ビジネスユニットのログファイルを、それらを作成したビジネスユニットと共有したい場合を考えます。ただし、ユニットが他のユニットのログファイルを読み取ることはできないようにします。

例えば、アカウント B が所有するログファイルをアカウント B と共有し、アカウント C とは共有しない場合は、アカウント B が信頼されたアカウントであることを指定する新しい IAM ロールを、自分のアカウントに作成する必要があります。このロールの信頼ポリシーは、アカウント B が信頼されており、自分のアカウントによって作成されたロールを継承できることを指定するもので、次の例のようになります。コンソールを使用してロールを作成した場合は、信頼ポリシーが自動的に作成されます。SDK を使用してロールを作成する場合は、CreateRole API へのパラメータとして信頼ポリシーを指定する必要があります。CLI を使用してロールを作成する場合は、create-role CLI コマンドで信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::account-B-id:root" }, "Action": "sts:AssumeRole" } ] }

アカウント B が読み取りできるのは、それ自体がログファイルを書き込んだ先の場所からのみであることを指定するために、アクセスポリシーも作成する必要があります。アクセスポリシーは次のようになります。リソース ARN には、アカウント B の 12 桁のアカウント ID と、集約プロセス中に CloudTrail アカウント B をオンにしたときに指定したプレフィックスが含まれていることに注意してください。プレフィックスを指定する方法については、「追加アカウントでの証跡の作成」を参照してください。

重要

アクセスポリシーのプレフィックスが、アカウント B CloudTrail に対してオンにしたときに指定したプレフィックスとまったく同じであることを確認する必要があります。そうでない場合は、アカウント B の実際のプレフィックスを組み込むように、アカウントの IAM ロールアクセスポリシーを編集する必要があります。ロールアクセスポリシーのプレフィックスが、アカウント B CloudTrail でオンにしたときに指定したプレフィックスとまったく同じでない場合、アカウント B はログファイルにアクセスできません。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/prefix/AWSLogs/account-B-id/*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET" } ] }

追加するアカウントに対しても前述のプロセスを使用します。

各アカウントのロールを作成し、適切な信頼ポリシーとアクセスポリシーを指定した後、また、各アカウントの IAM ユーザーがそのアカウントの管理者によってアクセスを許可された後、アカウント B または C の IAM ユーザーは、プログラムによってロールを継承できます。

詳細については、「ロールを割り当てる」を参照してください。

アクセスポリシーを作成してサードパーティにアクセス権限を付与する

サードパーティアカウント用に個別の IAM ロールを作成する必要があります。ロールを作成すると、 AWS によって信頼関係が自動的に作成され、サードパーティアカウントが信頼されたロールの割り当て先であることを指定します。アカウントがどのアクションを実行できるかは、ロールのアクセスポリシーによって指定されます。ロールの作成の詳細については、「IAM ロールの作成」を参照してください。

例えば、 によって作成された信頼関係は、サードパーティーアカウント (この例ではアカウント Z) が、作成したロールを引き受けるために信頼されていること AWS を指定します。以下に示しているのは、信頼ポリシーの例です。

{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::account-Z-id:root"}, "Action": "sts:AssumeRole" }] }

サードパーティアカウント用のロールを作成する際に外部 ID を指定した場合は、そのアカウントによって割り当てられた一意の ID をテストする Condition 要素が、アクセスポリシー内に追加されます。このテストはロールを引き受けた時点で実行されます。次の例では、アクセスポリシーに Condition 要素が含まれています。

詳細については、「IAM ユーザーガイド」の「 AWS リソースへのアクセスを第三者に付与するときに外部 ID を使用する方法」を参照してください。

{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::account-Z-id:root"}, "Action": "sts:AssumeRole", "Condition": {"StringEquals": {"sts:ExternalId": "external-ID-issued-by-account-Z"}} }] }

また、自分のアカウントでアクセスポリシーを作成して、サードパーティアカウントが Amazon S3 バケットからすべてのログを読み取れるように指定する必要もあります。アクセスポリシーは、次の例のようになります。Resource 値の末尾のワイルドカード (*) は、アクセス権限を付与されたサードパーティアカウントが、S3 バケット内の任意のログファイルをアクセスできることを示しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET" } ] }

サードパーティアカウントのロールを作成し、適切な信頼関係とアクセスポリシーを指定した後、そのサードパーティアカウント内の IAM ユーザーにプログラムでロールを割り当てて、ユーザーがバケットからログファイルを読み取れるようにする必要があります。詳細については、「ロールを割り当てる」を参照してください。

ロールを割り当てる

各アカウントで作成したロールを担う、IAM ユーザーを個別に指定する必要があります。次に、各 IAM ユーザーに適切な権限が与えられていることを確認する必要があります。

IAM ユーザーとロール

必要なロールとポリシーを作成した後は、ファイルを共有するアカウントで IAM ユーザーを指定する必要があります。ログファイルにアクセスするには、プログラムによって各 IAM ユーザーが適切なロールを引き受けます。ユーザーがロールを引き受けると、 AWS は、一時的なセキュリティ認証情報をそのユーザーに返します。その後、ロールに関連するアクセスポリシーによって付与された権限に応じて、ログファイルのリスト、取得、コピー、削除をリクエストできます。

IAM ID の詳細については、「IAM ID (ユーザー、ユーザーグループ、ロール)」を参照してください。

各シナリオで各 IAM ロールに対して作成するアクセスポリシーの主な相違点。

IAM ユーザーに対するアクセス許可ポリシーを作成する

ロールで許可されるアクションを実行するには、IAM ユーザーに API を呼び出す AWS STS AssumeRoleアクセス許可が必要です。 ユーザーごとのポリシーを編集し、ユーザーに適切なアクセス許可を付与する必要があります。そのためには、IAM ユーザーにアタッチするポリシーの [リソース] 要素を設定します。以下の例では、アカウント A によって以前に作成された Test という名前のロールを引き受けることを、別のアカウントのIAM ユーザーに許可するためのポリシーを示します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["sts:AssumeRole"], "Resource": "arn:aws:iam::account-A-id:role/Test" } ] }
カスタマー管理ポリシーを編集するには (コンソール)
  1. にサインイン AWS Management Console し、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。

  2. ナビゲーションペインで、ポリシー を選択します。

  3. ポリシーの一覧で、編集するポリシーの名前を選択します。検索ボックスを使用して、ポリシーのリストをフィルタリングできます。

  4. [アクセス許可] タブを選択し、[編集] を選択します。

  5. 次のいずれかを行います。

    • [ビジュアル] オプションを選択し、JSON 構文を理解することなくポリシーを変更します。ポリシー内の各権限ブロックのサービス、アクション、リソース、またはオプションの条件を変更することができます。また、ポリシーをインポートして、ポリシーの最下部に権限を追加することもできます。変更が完了したら、[次へ] を選択して続行します。

    • [JSON] オプションを選択し、JSON テキストボックスにテキストを入力または貼り付けてポリシーを変更します。また、ポリシーをインポートして、ポリシーの最下部に権限を追加することもできます。ポリシーの検証中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、[Next] (次へ) を選択します。

      注記

      いつでも [Visual] と [JSON] エディタオプションを切り替えることができます。ただし、[Visual] エディタで [] に変更または選択した場合、IAM はポリシーを再構成して visual エディタに合わせて最適化することがあります。詳細については、「IAM ユーザーガイド」の「ポリシーの再構成」を参照してください。

  6. [確認して保存] ページで、このポリシーで定義されているアクセス許可を確認し、[変更を保存] を選択して作業を保存します。

  7. 最大 5 つのバージョンの管理ポリシーがすでにある場合は、[変更を保存] を選択すると、ダイアログボックスが表示されます。新しいバージョンを保存するには、ポリシーの最も古い非デフォルトバージョンが削除され、この新しいバージョンに置き換えられます。オプションで、新しいバージョンをポリシーのデフォルトバージョンとして設定できます。

    [ポリシーを保存] を選択して、新しいバージョンのポリシーを保存します。

呼び出し AssumeRole

ユーザーは、 AWS STS AssumeRoleAPI を呼び出し、ロールセッション名、引き受けるロールの Amazon リソースナンバー (ARN)、およびオプションの外部 ID を渡すアプリケーションを作成することで、ロールを引き受けることができます。ロールセッション名は、引き受けるロールを作成したアカウントによって定義されます。外部 ID (ある場合) は、サードパーティアカウントによって定義され、ロールに含めるよう、そのロールの作成時に所有アカウントに渡されます。詳細については、「IAM ユーザーガイド」の「 AWS リソースへのアクセスを第三者に付与するときに外部 ID を使用する方法」を参照してください。IAM コンソールを開くことによって、アカウント A から ARN を取得できます。

IAM コンソールを使用してアカウント A で ARN の値を探すには
  1. [Roles] を選択します。

  2. 調べるロールを選択します。

  3. [Summary] セクションで [Role ARN] を検索します。

AssumeRole API は、所有アカウントのリソースにアクセスするために使用する一時的な認証情報を返します。この例では、アクセスするリソースは Amazon S3 バケットと、そのバケットに含まれるログファイルです。この一時的な認証情報には、ロールのアクセスポリシーで定義したアクセス許可があります。

次の Python の例 (AWS SDK for Python (Boto) を使用) では、AssumeRole を呼び出す方法、および返された一時的な認証情報を使用して、アカウント A によって管理されるすべての Amazon S3 バケットの一覧を取得する方法を示します。

def list_buckets_from_assumed_role(user_key, assume_role_arn, session_name): """ Assumes a role that grants permission to list the Amazon S3 buckets in the account. Uses the temporary credentials from the role to list the buckets that are owned by the assumed role's account. :param user_key: The access key of a user that has permission to assume the role. :param assume_role_arn: The Amazon Resource Name (ARN) of the role that grants access to list the other account's buckets. :param session_name: The name of the STS session. """ sts_client = boto3.client( "sts", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret ) try: response = sts_client.assume_role( RoleArn=assume_role_arn, RoleSessionName=session_name ) temp_credentials = response["Credentials"] print(f"Assumed role {assume_role_arn} and got temporary credentials.") except ClientError as error: print( f"Couldn't assume role {assume_role_arn}. Here's why: " f"{error.response['Error']['Message']}" ) raise # Create an S3 resource that can access the account with the temporary credentials. s3_resource = boto3.resource( "s3", aws_access_key_id=temp_credentials["AccessKeyId"], aws_secret_access_key=temp_credentials["SecretAccessKey"], aws_session_token=temp_credentials["SessionToken"], ) print(f"Listing buckets for the assumed role's account:") try: for bucket in s3_resource.buckets.all(): print(bucket.name) except ClientError as error: print( f"Couldn't list buckets for the account. Here's why: " f"{error.response['Error']['Message']}" ) raise

AWS アカウント間の CloudTrail ログファイルの共有を停止する

別の へのログファイルの共有を停止するには AWS アカウント、そのアカウント用に作成したロールを削除します。ロールを削除する方法の詳細については、「ロールまたはインスタンスプロファイルの削除」を参照してください。