翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS アカウント間での CloudTrail ログファイルの共有
このセクションでは、複数の AWS アカウント間で CloudTrail ログファイルを共有する方法について説明します。間でログを共有するために使用する方法は、S3 バケットの設定 AWS アカウント によって異なります。ログファイルを共有するためのオプションは次のとおりです。
-
バケット所有者の強制 – S3 オブジェクトの所有権は、バケットにアップロードされたオブジェクトの所有権を制御したり、アクセスコントロールリスト () を無効化または有効にしたりするために使用できる Amazon S3 バケットレベルの設定ですACLs。デフォルトでは、オブジェクトの所有権はバケット所有者の強制設定に設定され、すべて無効ACLsになっています。を無効にすると、バケット所有者ACLsはバケット内のすべてのオブジェクトを所有し、アクセス管理ポリシーのみを使用してデータへのアクセスを管理します。[バケット所有者の強制] オプションを設定すると、アクセスはバケットポリシーによって管理されるため、ユーザーが役割を引き受ける必要がなくなります。
-
ログファイルを共有するロールを引き受ける – [バケット所有者の強制] 設定を選択していない場合、ユーザーは S3 バケット内のログファイルにアクセスするロールを引き受ける必要があります。
ロールを引き受けてアカウント間でログファイルを共有する
注記
このセクションは、[バケット所有者の強制] 設定を使用していない Amazon S3 バケットにのみ適用されます。
このセクションでは、ロールを引き受け AWS アカウント て複数の 間で CloudTrail ログファイルを共有する方法と、ログファイルを共有するシナリオについて説明します。
-
シナリオ 1: Amazon S3 バケットに保存されているログファイルの生成元のアカウントに、読み取り専用のアクセス権限を付与します。
-
シナリオ 2: Amazon S3 バケット内のすべてのログファイルへのアクセス権を、ログファイルを分析するためのサードパーティのアカウントに付与します。
Amazon S3 バケット内のログファイルへの読み取り専用アクセス権を付与するには
-
ログファイルを共有するアカウントごとに IAMロールを作成します。アクセス許可を付与するには管理者である必要があります。
ロールを作成する場合、以下の作業を行います。
-
[その他の AWS アカウント] オプションを選択します。
-
アクセス許可が付与されるアカウントの、12 桁のアカウント ID を入力します。
-
ロールを引き受ける前にユーザーが多要素認証を提供できるようにする場合は、「必須MFA」チェックボックスをオンにします。
-
AmazonS3ReadOnlyAccess ポリシーを選択します。
注記
デフォルトでは、AmazonS3ReadOnlyAccess ポリシーは、アカウント内のすべての Amazon S3 バケットに対する取得および一覧表示権限を付与します。
IAM ロールのアクセス許可管理の詳細については、「 ユーザーガイド」の「 IAMロールIAM」を参照してください。
-
-
ログファイルを共有するアカウントに読み取り専用のアクセス権限を付与する、アクセスポリシーを作成します。
-
ログファイルを取得するロールを引き受けるよう、各アカウントに指示します。
サードパーティアカウントにログファイルへの読み取り専用アクセス権を付与するには
-
ログファイルを共有するサードパーティーアカウントの IAMロールを作成します。アクセス許可を付与するには管理者である必要があります。
ロールを作成する場合、以下の作業を行います。
-
[その他の AWS アカウント] オプションを選択します。
-
アクセス許可が付与されるアカウントの、12 桁のアカウント ID を入力します。
-
ロールを担当できるユーザーをより高度に制御できるようにするための、外部 ID を入力します。詳細については、「 IAMユーザーガイド」の「 AWS リソースへのアクセスを第三者に付与するときに外部 ID を使用する方法」を参照してください。
-
AmazonS3ReadOnlyAccess ポリシーを選択します。
注記
デフォルトでは、AmazonS3ReadOnlyAccess ポリシーは、アカウント内のすべての Amazon S3 バケットに対する取得および一覧表示権限を付与します。
-
-
ログファイルを共有するサードパーティアカウントに読み取り専用のアクセス権限を付与する、アクセスポリシーを作成します。
-
ログファイルを取得するロールを引き受けるよう、サードパーティアカウントに指示します。
次のセクションでは、これらの手順についてさらに詳しく説明しています。
トピック
自分が所有するアカウントへのアクセスを許可するアカウントポリシーの作成
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:::
amzn-s3-demo-bucket
/prefix/AWSLogs/account-B-id
/*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::amzn-s3-demo-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
要素が含まれています。
詳細については、「 ユーザーガイド」の「 AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法」を参照してください。 IAM
{ "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:::
amzn-s3-demo-bucket
/*" }, { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket
" } ] }
サードパーティーアカウントのロールを作成し、適切な信頼関係とアクセスポリシーを指定した後、サードパーティーアカウントのIAMユーザーは、バケットからログファイルを読み取れるようにロールをプログラムで引き受ける必要があります。詳細については、「ロールを割り当てる」を参照してください。
ロールを割り当てる
各アカウントで作成する各ロールを引き受けるには、個別のIAMユーザーを指定する必要があります。次に、各IAMユーザーに適切なアクセス許可があることを確認する必要があります。
IAM ユーザーとロール
必要なロールとポリシーを作成したら、ファイルを共有する各アカウントのIAMユーザーを指定する必要があります。各IAMユーザーは、ログファイルにアクセスするための適切なロールをプログラムで引き受けます。ユーザーがロールを引き受けると、 AWS は、一時的なセキュリティ認証情報をそのユーザーに返します。その後、ロールに関連するアクセスポリシーによって付与された権限に応じて、ログファイルのリスト、取得、コピー、削除をリクエストできます。
IAM ID の使用の詳細については、IAM「ID (ユーザー、ユーザーグループ、ロール)」を参照してください。
各シナリオでIAMロールごとに作成するアクセスポリシーの主な違い。
-
シナリオ 1 では、アクセスポリシーが、各アカウントを自分のログファイルの読み取りのみに制限します。詳細については、「自分が所有するアカウントへのアクセスを許可するアカウントポリシーの作成」を参照してください。
-
シナリオ 2 では、アクセスポリシーが、Amazon S3 バケットに集計されたすべてのログファイルを読み取ることを、サードパーティに許可します。詳細については、「アクセスポリシーを作成してサードパーティにアクセス権限を付与する」を参照してください。
IAM ユーザーに対するアクセス許可ポリシーを作成する
ロールで許可されるアクションを実行するには、IAMユーザーに を呼び出す AWS STS AssumeRole
アクセス許可が必要ですAPI。 ユーザーごとのポリシーを編集し、ユーザーに適切なアクセス許可を付与する必要があります。これを行うには、IAMユーザーにアタッチするポリシーでリソース要素を設定します。次の例は、別の アカウントのIAMユーザーのポリシーを示しています。このポリシーでは、そのユーザーがアカウント A によって以前にTest
作成された という名前のロールを引き受けることを許可します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["sts:AssumeRole"], "Resource": "arn:aws:iam::
account-A-id
:role/Test" } ] }
カスタマー管理ポリシーを編集するには (コンソール)
にサインイン AWS Management Console し、 でIAMコンソールを開きますhttps://console.aws.amazon.com/iam/
。 -
ナビゲーションペインで、ポリシー を選択します。
-
ポリシーの一覧で、編集するポリシーの名前を選択します。検索ボックスを使用して、ポリシーのリストをフィルタリングできます。
-
[アクセス許可] タブを選択し、[編集] を選択します。
-
次のいずれかを行います。
-
ビジュアルオプションを選択して、JSON構文を理解しずにポリシーを変更します。ポリシー内の各権限ブロックのサービス、アクション、リソース、またはオプションの条件を変更することができます。また、ポリシーをインポートして、ポリシーの最下部に権限を追加することもできます。変更が完了したら、[次へ] を選択して続行します。
-
JSON テキストボックスにテキストを入力または貼り付けて、ポリシーを変更するJSONオプションを選択します。また、ポリシーをインポートして、ポリシーの最下部に権限を追加することもできます。ポリシーの検証中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、[Next] (次へ) を選択します。
注記
ビジュアルオプションとJSONエディタオプションはいつでも切り替えることができます。ただし、ビジュアルエディタで変更を加えるか、次へ を選択すると、 IAMはビジュアルエディタに合わせて最適化するようにポリシーを再構成する場合があります。詳細については、「 ユーザーガイド」の「ポリシーの再構築」を参照してください。 IAM
-
-
[確認して保存] ページで、このポリシーで定義されているアクセス許可を確認し、[変更を保存] を選択して作業を保存します。
-
最大 5 つのバージョンの管理ポリシーがすでにある場合は、[変更を保存] を選択すると、ダイアログボックスが表示されます。新しいバージョンを保存するには、ポリシーの最も古い非デフォルトバージョンが削除され、この新しいバージョンに置き換えられます。オプションで、新しいバージョンをポリシーのデフォルトバージョンとして設定できます。
[ポリシーを保存] を選択して、新しいバージョンのポリシーを保存します。
呼び出し AssumeRole
ユーザーは、 を呼び出し、ロールセッション名、引き受けるロールの Amazon リソース番号 (ARN)、およびオプションの外部 ID を AWS STS AssumeRole
API渡すアプリケーションを作成することで、ロールを引き受けることができます。ロールセッション名は、引き受けるロールを作成したアカウントによって定義されます。外部 ID (ある場合) は、サードパーティアカウントによって定義され、ロールに含めるよう、そのロールの作成時に所有アカウントに渡されます。詳細については、「 IAMユーザーガイド」の「 AWS リソースへのアクセスを第三者に許可するときに外部 ID を使用する方法」を参照してください。IAM コンソールを開くと、アカウント A ARNから を取得できます。
IAM コンソールを使用してアカウント A でARN値を検索するには
-
[Roles] を選択します。
-
調べるロールを選択します。
-
概要セクションで ロール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 アカウント、そのアカウント用に作成したロールを削除します。ロールを削除する方法の詳細については、「ロールまたはインスタンスプロファイルの削除」を参照してください。