パターンを使用して ServiceNow で AWS クラウドディスカバリーを構成するためのステップバイステップガイド - Support and Troubleshooting

パターンを使用して ServiceNow で AWS クラウドディスカバリーを構成するためのステップバイステップガイド .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 要約 この KB 記事では、AWS クラウドディスカバリー用に AWS 環境を設定する手順について説明します。このセットアップにより、AWS クラウドディスカバリーの結果が CMDB に取り込まれます。また、AWS ポータル側および ServiceNow インスタンス側での構成全体についての詳細なドキュメントも提供します。

はじめに AWS 認証情報のタイプ アクセスを許可する方法 認証情報ベースのディスカバリー構成タイプ 権限 マルチアカウント構成モデル モデル 1:単一の AWS アカウント IAM ユーザーを持つ単一の AWS アカウント (アクセスキー) IAM ロールを使用する単一の AWS アカウント（EC2 インスタンスプロファイル） モデル 2:管理→メンバーアカウント 管理アカウントの IAM ユーザー 管理アカウントの IAM ロール (EC2 インスタンスプロファイル) モデル 3: アクセサー→管理→メンバーアカウント (ロールチェーン) アクセサーアカウントの IAM ユーザー アクセサーアカウントの IAM ロール (EC2 インスタンスプロファイル) モデル 4:アクセサー→メンバー/管理ダイレクト アクセサーアカウント直接の IAM ユーザー アクセサーアカウント直接の IAM ロール (EC2 インスタンスプロファイル) 認証情報ベースのディスカバリー アカウントの種類 アクセサーアカウント構成 管理アカウント構成 メンバーアカウント構成 認証情報なしディスカバリー アカウントの種類 アクセサーアカウント構成 管理アカウント構成 メンバーアカウント構成

1.はじめに 1.1 認証情報の種類 永続的な認証情報:

永続的な認証情報は、サービスアカウントに関連付けられた AWS アクセスキー です。これらは、Now Platform の AWS Credentials（aws_credentials）テーブルに手動で追加されます。永続的な認証情報の管理にはより多くの管理作業が必要ですが、このアプローチでは、一時的な認証情報構成の使用に伴う複雑な構成を回避できます。

一時的な認証情報:

一時的な認証情報は、IAM ロール向けに AWS Security Token Service (AWS STS) を使用して生成されます。AWS で IAM ロールベースのアクセスを設定すると、MID サーバーはそれらのロールを引き受けて、一時的な認証情報を使用して AWS リソースにアクセスできます。一般に、この方法はセキュリティとスケーラビリティの観点から好まれます。

1.2 アクセスを許可する方法 トラスティングアカウント

トラスティングアカウントは、 IAM ロールを作成し、別の AWS アカウント（Trusted Account）の IAM ユーザーまたはロールに対して、AWS Security Token Service (STS) を使用してそのロールを引き受ける権限を付与する AWS アカウントです。

ServiceNow クラウドディスカバリーシナリオの場合:

トラスティングアカウントは 認証情報を ServiceNow インスタンスに保存しません。 代わりに、 ディスカバリー権限を持つ IAM ロールを作成します これらのロールは、トラステッドアカウント（アクセサーアカウント）の IAM ID（ユーザーまたはロール）がそのロールを引き受けられるよう信頼関係を構成します。 実行時に、 MID サーバー はその IAM ID を使用して これらのロールを引き受け トラスティングアカウントのリソースを検出します。

トラステッドアカウント

トラステッドアカウントは、クロスアカウントアクセス用に他の AWS アカウント ( トラスティング アカウントと呼ばれる) によって信頼されている IAM ID (ユーザーまたはロール) を提供する AWS アカウントです。 ServiceNow の用語では、これは アクセサーアカウント とも呼ばれます。

ServiceNow クラウドディスカバリーシナリオの場合:

トラステッドアカウントには、MID サーバーが使用する認証情報が配置されています。 これらの認証情報は次のいずれかになります。 IAM ユーザーからの永続的な認証情報 (ServiceNow に手動で入力) IAM ロール（インスタンスプロファイル）がアタッチされた EC2 インスタンス上に MID サーバーがデプロイされた際に自動的に取得される一時的な認証情報。 この IAM ID は トラスティングアカウントの IAM ロール の信頼ポリシーで明示的に信頼されている必要があります 。 このモデルにより、MID サーバーは各アカウントごとに認証情報を保存することなく、複数のアカウントにまたがるリソースを検出できます。 注: MID サーバーがインスタンスプロファイルを持つ EC2 インスタンスで実行されている場合、AWS はインスタンスメタデータサービスを介して 一時的な認証情報 を自動的に発行します。

概要:

アカウントの種類 説明 トラスティングアカウント トラステッドアカウントの ID が STS 経由で引き受けられる IAM ロールを作成します。 トラステッドアカウント 他のアカウントのロールを引き受けるために ID が使用される IAM ユーザーまたはロール を保持します。

1.3 認証情報ベースのディスカバリー構成タイプ AWS 向け ServiceNow クラウドディスカバリー は、認証情報の管理方法とアクセス方法に基づいて、認証情報ベースのディスカバリーと認証情報なしのディスカバリーという 2 つの主要な構成アプローチをサポートしています

認証情報ベースのディスカバリー

このセットアップでは、 アクセサーアカウント (トラステッドアカウント) からの 永続的な AWS 認証情報 (アクセスキー ID と秘密アクセスキー) が AWS Credentials（aws_credentials）テーブルに安全に保存されます。

MID サーバーはこれらの認証情報を使用して AWS で認証し、トラスティングアカウントでロールを引き受けます。 このセットアップは、AWS の外部で MID サーバーを実行する場合に管理しやすくなります。 ただし、セキュリティとコンプライアンスのために慎重な認証情報ライフサイクル管理が必要です。

認証情報なしのディスカバリー

このアプローチにより、ServiceNow に AWS 認証情報を保存する必要がなくなります。

MID サーバーは、アクセサーアカウント（トラステッドアカウント）内の EC2 インスタンス上で実行されます。 EC2 インスタンスには、必要な権限と信頼関係が設定された IAM インスタンスプロファイル ロールが割り当てられます。 MID サーバーは、EC2 インスタンスのメタデータサービスを使用して、AWS STS を介して一時的な認証情報を自動的に取得します。 この方法はより安全であり、ハードコードされた認証情報や長期的な認証情報を回避することで、AWS のベストプラクティスに沿っています。 まとめ

セットアップタイプ 認証情報ベース 認証情報なし ServiceNow の認証情報 はい (アクセサーアカウントの永続的な認証情報) いいえ MID サーバーの場所 どこでも (オンプレミスまたはクラウド) アクセサーアカウント内の AWS EC2 インスタンス ユースケース AWS の外部でのセットアップが簡単 より安全で、AWS でホストされる MID に推奨されます

1.4 権限 ReadOnlyAccess を使用する代わりにカスタムディスカバリーポリシーを作成するには、公式の クラウドディスカバリーパターンスプレッドシートの「 権限 」シートを参照してください

このシートでは、さまざまな AWS リソースを検出するために ServiceNow が必要とする詳細な AWS アクションについて説明します。

この参照を使用して、必要な権限のみを付与するカスタマイズされた IAM ポリシーを定義できます。

2.マルチアカウント構成モデル このセクションでは、さまざまな AWS アカウントアーキテクチャを使用して ServiceNow で AWS クラウドディスカバリーを構成する方法について説明します。構成は、複数のアカウント間で AWS リソースへのアクセスを管理する方法によって異なります。

ServiceNow では、MID サーバーを使用して AWS リソースを検出するために、以下の認証モデルおよび信頼モデルをサポートしています。

サポートされるアカウントモデル:

モデル ID 名前 認証タイプ ユースケース M1 単一の AWS アカウント IAM ユーザー (アクセスキー) IAM ロール (EC2 インスタンスプロファイル) 静的認証情報 (IAM ユーザーアクセスキー) または EC2 にアタッチされた IAM ロール のいずれかを使用して、 単一の AWS アカウント 内のリソースを検出する場合に使用します。クロスアカウントアクセスなし。 M2 管理→メンバーアカウント 管理アカウントの IAM ユーザー (アクセスキー) 管理アカウントの IAM ロール (EC2 インスタンスプロファイル) 管理アカウント が IAM ユーザー認証情報 または EC2 添付 IAM ロール のいずれかを保持し、すべてのメンバーアカウントでディスカバリーを実行するロールを引き受けている場合に使用します。 M3 アクセサー→管理→メンバーアカウント ( ロールチェーン ) アクセサーアカウントの IAM ユーザー (アクセスキー) アクセサーアカウントの IAM ロール (EC2 インスタンスプロファイル) アクセサーアカウントが IAM ユーザー認証情報 または EC2 にアタッチされた IAM ロール のいずれかを保持し、 管理アカウントを介してロールチェーンを実行してメンバーアカウントにアクセスする場合 に使用します。一元的な認証情報ストレージと、管理アカウントを介した階層化された信頼を必要とするセットアップに適しています。 M4 アクセサー → メンバー／管理（直接接続） アクセサーアカウントの IAM ユーザー (アクセスキー) アクセサーアカウントの IAM ロール (EC2 インスタンスプロファイル) アクセサーアカウントが IAM ユーザー認証情報 または EC2 添付 IAM ロール のいずれかを保持し、管理アカウントとメンバーアカウントの両方でロールを 直接引き受けることができる場合に使用します。 すべてのアカウントが アクセサーを直接信頼する場合に最適で ロールチェーンが不要になります。

モデル M3 の詳細構成: アクセサーアカウントで IAM ロール (EC2 インスタンスプロファイル) を使用するアクセサー→管理→メンバーアカウント (ロールチェーン) ステップバイステップの構成ガイダンスについては、次の リンク を参照してください。

パート 1:概要とアクセサーアカウントのセットアップ パート 2:管理アカウントのセットアップ パート 3:メンバーアカウントのセットアップ これらのガイドでは、AWS アカウントの構成方法と、このモデルに対応する ServiceNow インスタンス設定の包括的な概要について説明します。

別のアカウントモデルを使用している場合でも、これらの手順から構成プロセス全体に関する有用な情報が得られます。特定のモデルの詳細については、それぞれのセクションを参照してください。

2.1 モデル 1: 単一の AWS アカウント

このセクションでは、 1 つの AWS アカウントのみ を使用する環境向けに ServiceNow で AWS クラウドディスカバリーを構成する方法について説明します。これは最もシンプルなモデルで、複数の AWS アカウントまたは AWS Organizations を使用しないお客様に最適です。

ServiceNow では、この構成に対して次の 2 つの認証情報モデルがサポートされています。

静的認証情報 (アクセスキーとシークレットアクセスキー) を持つ IAM ユーザー AWS でホストされている MID サーバーの場合、EC2 (インスタンスプロファイル) に添付された IAM ロール 2.1.1 - IAM ユーザーを持つ単一の AWS アカウント (アクセスキー)

これには、プログラムによるアクセス権を持つ IAM ユーザーを作成し、認証情報を ServiceNow に安全に保存する必要があります。

セクション アイテム 詳細 AWS 側

アカウントの種類 - 単一の AWS アカウント 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 KB の「Use Cases and Execution Flow」セクションにある「IAM User → Member (Same Account)」を参照してください。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

IAM ユーザー - プログラムによるアクセス権を持つIAM ユーザーの作成

- アクセスキー ID と秘密アクセスキーの生成

IAM ユーザー権限 - AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します ServiceNow 側 AWS 認証情報テーブル ( aws_credentials )

- IAM ユーザーのアクセスキーIDと秘密アクセスキーを使用してエントリを作成します クラウドサービスアカウント ( cloud_service_account ) - この AWS アカウントのエントリを作成します

- aws_credentials の credentials エントリに関連付けます

2.1.2 - IAM ロールを使用する単一の AWS アカウント（EC2 インスタンスプロファイル）

このモデルは、 MID サーバーが同じ AWS アカウント内の EC2 インスタンスで実行されている場合に使用します 。静的認証情報の代わりに、EC2 インスタンスプロファイルを使用してインスタンスに IAM ロールを割り当てます。ServiceNow ディスカバリーはこのロールを自動的に使用するため、 セキュリティと管理性が向上します。

セクション アイテム 詳細 AWS 側 アカウントの種類 - 単一の AWS アカウント 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 KB の「Use Cases and Execution Flow」セクションにある「EC2 → Member (Same Account)」を参照してください。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

IAM ロール EC2 信頼関係を持つ IAM ロールの作成 AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します EC2 インスタンスプロファイル - EC2 インスタンスで MID サーバーを起動します

- IAM ロールをEC2インスタンスにアタッチします

ServiceNow 側 AWS 認証情報テーブル ( aws_credentials )

- 必須ではありません (認証情報は EC2 インスタンスプロファイル によって動的に提供されます) MID サーバー構成プロパティ

- MID サーバーパラメーターを設定します

mid.aws.instance_profile_name = EC2 インスタンスに添付された IAM ロールの名前

クラウドサービスアカウント ( cloud_service_account ) - この AWS アカウントのエントリを作成します

注: EC2 インスタンスプロファイルベースの認証を使用する場合は、MID サーバーがシステムプロパティ mid.aws.instance_profile_name で構成され、EC2 インスタンスに添付されている IAM ロール名に設定されていることを確認します。これにより、MID サーバーはインスタンスメタデータサービスから一時的な認証情報を取得します。

2.2 モデル2:管理→メンバーアカウント

このモデルは、管理アカウントが複数のメンバーアカウントにまたがる AWS リソースを 一元的に検出するときに使用されます。 管理アカウントは AWS STS AssumeRole を使用して、各メンバーアカウントのディスカバリーロールを引き受けます。

注: AWS Organizations とデフォルトのロール OrganizationAccountAccessRole を使用している場合は、メンバーアカウントでのカスタムロールの作成をスキップできます。管理アカウントにそれを引き受ける権限があることを確認します。

ServiceNow では、次の 2 つの認証バリアントがサポートされています。

オプション 使用するタイミング 管理アカウントの IAM ユーザー (アクセスキー) MID サーバーが外部で実行されている場合に使用します。AWS 静的認証情報が必要です。 管理アカウントの IAM ロール (EC2 インスタンスプロファイル) 管理アカウントの EC2 で MID サーバーが実行されている場合に使用します。認証情報は、インスタンスプロファイルによって動的に提供されます。 2.2.1 管理アカウントのIAM ユーザー

MID サーバーは、アクセスキーとシークレットアクセスキーを使用して認証し、すべてのメンバーアカウントで IAM ロールを引き受けます。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 - 管理アカウント - メンバーアカウント 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 2 を参照してください。KB の ユースケースと実行フロー の IAM ユーザー (管理) →メンバー

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

管理アカウント IAM ユーザー - プログラムによるアクセス権を持つIAM ユーザーの作成

- アクセスキー ID とシークレットアクセスキーの生成

- メンバー・ロールにsts:AssumeRoleを許可するポリシーを添付する

- AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタム検出ポリシー (セクション 1.4 を参照) を添付します

- さらに 管理アカウントの IAM ユーザー に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます

メンバーアカウント IAM ロール - 各メンバーアカウントにカスタム IAM ロールを作成します。

- 信頼ポリシーにより、管理アカウントはこのロールを引き受けることができます

- AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタム検出ポリシー (セクション 1.4 を参照) を添付します

ServiceNow 側 管理アカウント AWS 認証情報テーブル ( aws_credentials ) - 管理アカウントの IAM ユーザー（アクセスキー ID + シークレットアクセスキー）のエントリを追加 クラウドサービスアカウント ( cloud_service_account ) 管理アカウントのエントリを作成

アカウント ID:> 管理アカウント ID ディスカバリー認証情報 → アクセサーアカウントの認証情報を参照 データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) Is 管理アカウント → チェック済み メンバーアカウント クラウドサービスアカウント ( cloud_service_account ) 管理アカウントの検証に成功すると、メンバーアカウントが自動的に入力されます。存在しない場合は、[更新] ボタンをクリックして手動で入力します。

メンバーアカウントが設定されている場合は、各メンバーアカウントのサービスアカウントの作成をスキップできます。

代わりに、メンバーアカウントのエントリを作成します

アカウント ID:>メンバーアカウントアカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウントである -> オフ アクセサーアカウント>空白のままにします (メンバーアカウントが自分の管理アカウントを信頼している場合) 注 :手動で作成する場合、この手順は各メンバーアカウントに対して繰り返されます

クラウドサービスアカウント AWS 組織AssumeRoleパラメーターテーブル ( cloud_service_account_aws_org_assume_role_params ) すべてのメンバーアカウントが同じ IAM ロール名 (SN_MEMBER_ACCOUNT_ROLE など) を使用して管理アカウントを信頼する場合:

cloud_service_account_aws_org_assume_role_paramsテーブルに単一のエントリを作成します。 クラウドサービスアカウント:管理アカウント アクセスロール名:> arn:aws:iam::*:role/MemberRoleName (例:arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE) メンバーアカウントが同じ IAM ロール名を使用していない場合、または信頼関係が異なる場合:

- 各 メンバーアカウントのエントリを作成します •クラウドサービスアカウント:>メンバーアカウント •アクセスロール名:>完全なカスタム IAM ロール ARN

注意: メンバーアカウントのデフォルトロール (OrganizationAccountAccessRole) を使用して、この手順をスキップします

2.2.2 管理アカウントのIAM ロール(EC2インスタンスプロファイル)

MID サーバーは、管理アカウントの EC2 インスタンスでホストされ、EC2 IAM ロールを使用してメンバーアカウントのロールを引き受けます。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 - 管理アカウント - メンバーアカウント 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 6 を参照してください。 KB の「 ユースケースと実行フロー にある EC2(管理) →メンバー 。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

管理アカウント IAM ロール - EC2 信頼関係を持つ IAM ロールの作成

- メンバー・ロールにsts:AssumeRoleを許可するポリシーを添付する

- AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタム検出ポリシー (セクション 1.4 を参照) を添付します

- さらに 管理アカウントの IAM ロール に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます

メンバーアカウント IAM ロール - 各メンバーアカウントにカスタム IAM ロールを作成します。

- 信頼ポリシーにより、管理アカウントはこのロールを引き受けることができます

- AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタム検出ポリシー (セクション 1.4 を参照) を添付します

ServiceNow 側 管理アカウント AWS 認証情報テーブル ( aws_credentials ) - 必須ではありません (認証情報は EC2 インスタンスプロファイル によって動的に提供されます) MID サーバー構成プロパティ - MID サーバーパラメーターを設定します mid.aws.instance_profile_name = EC2 インスタンスに添付された IAM ロールの名前

クラウドサービスアカウント ( cloud_service_account ) 管理アカウントのエントリを作成

アカウント ID:> 管理アカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) Is 管理アカウント → チェック済み メンバーアカウント セクション「2.2.1 管理アカウントの IAM ユーザー」と同じ:> メンバーアカウント構成 (正しい IAM ロール ARN を持つメンバーアカウントごとに 1 つのエントリ)

2.3 モデル3:アクセサー→管理→メンバーアカウント(ロールチェーン)

この構成は、一元化されたアクセサーアカウントによって AWS リソースディスカバリーが開始され、ロールチェーンを使用して管理アカウントにアクセスし、さらに複数のメンバーアカウントにロールを引き受ける場合に使用されます。

ServiceNow では、次の 2 つの認証バリアントがサポートされています。

オプション 使用するタイミング アクセサーアカウントの IAM ユーザー (アクセスキー) MID サーバーが AWS の外部で実行されている場合、または EC2 インスタンスのロールを引き受けられない場合に使用します。静的認証情報が必要です。 アクセサーアカウントの IAM ロール (EC2 インスタンスプロファイル) アクセサーアカウントの EC2 で MID サーバーが実行されている場合に使用します。認証情報は、インスタンスプロファイルによって動的に提供されます。 2.3.1 アクセサー・アカウントのIAM ユーザー

MID サーバーはアクセサーアカウント (アクセスキーとシークレットアクセスキー) を使用して認証し、管理アカウントで IAM ロールを引き受けます。管理 IAM ロールは、すべてのメンバーアカウントでロールを引き受けます。

詳細な手順については、「3. 認証情報ベースのディスカバリー」を参照してください。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 アクセサーアカウント:IAM ユーザー 管理アカウント（アクセサーアカウントを信頼し、メンバーアカウントから信頼される） メンバーアカウント（管理アカウントを信頼） 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 3 を参照してください。KB の「 ユースケースと実行フロー の IAM ユーザー (アクセサー) → 管理→メンバー 。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

アクセサーアカウント IAM ユーザー プログラムによるアクセス権を持つ IAM ユーザーを作成する IAM ポリシーで、管理アカウントのロールに対する sts:AssumeRole が許可されています AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します 管理アカウント IAM ロール IAM ロールを作成 信頼ポリシー:アクセサー IAM ユーザーにこのロールの引き受けを許可します 権限:メンバーアカウントのロールに対する sts:AssumeRole AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します さらに 管理アカウントの IAM ロール に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます メンバーアカウント IAM ロール IAM ロールを作成 信頼ポリシー:管理アカウントの IAM ロールを引き受けることを許可します AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します トラストチェーンサマリー アクセサーアカウントの IAM ユーザー → 管理アカウントの IAM ロール → メンバーアカウントの IAM ロール 権限の概要 アクセサー IAM ユーザー: 管理ロールに対する sts:AssumeRole: SN_MGMT_ASSUME_ROLE 管理 IAM ロール: メンバーロールに対する sts:AssumeRole: SN_MEMBER_ACCOUNT_ROLE 全アカウント対象(アクセサー/管理/メンバーアカウント) 読み取り専用またはディスカバリー固有の権限 ServiceNow 側 アクセサーアカウント AWS 認証情報テーブル ( aws_credentials ) アクセサーアカウント IAM ユーザーの認証情報エントリを作成します (アクセスキーとシークレットアクセスキー) クラウドサービスアカウント ( cloud_service_account ) アクセサーアカウントのエントリの作成

アカウント ID:> アクセサーアカウント ID ディスカバリー認証情報 → アクセサーアカウントの認証情報を参照 データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウント -> false 管理アカウント クラウドサービスアカウント ( cloud_service_account )

管理アカウントのエントリを作成

アカウント ID:> 管理アカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) Is 管理アカウント → チェック済み アクセサーアカウント:>アクセサーアカウントへの参照 クラウドサービスアカウント AWS クロスAssumeRoleパラメーター ( cloud_service_account_aws_cross_assume_role_params ) 管理アカウントのエントリを作成 •クラウドサービスアカウント:>管理アカウント •アクセスロール名:>フル管理 IAM ロール ARN メンバーアカウント クラウドサービスアカウント ( cloud_service_account )

管理アカウントの検証に成功すると、メンバーアカウントが自動的に入力されます。存在しない場合は、[更新] ボタンをクリックして手動で入力します。

メンバーアカウントが設定されている場合は、各メンバーアカウントのサービスアカウントの作成をスキップできます。

代わりに、メンバーアカウントのエントリを作成します

アカウント ID:>メンバーアカウントアカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウントである -> オフ アクセサーアカウント:>管理アカウントを選択 注意 :この手順は各メンバーアカウントに対して繰り返されます

クラウドサービスアカウント AWS 組織AssumeRoleパラメーターテーブル ( cloud_service_account_aws_org_assume_role_params )

すべてのメンバーアカウントが同じ IAM ロール名 (SN_MEMBER_ACCOUNT_ROLE など) を使用して管理アカウントを信頼する場合:

cloud_service_account_aws_org_assume_role_paramsテーブルに単一のエントリを作成します。 クラウドサービスアカウント:管理アカウント アクセスロール名:> arn:aws:iam::*:role/MemberRoleName (例:arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE) メンバーアカウントが同じ IAM ロール名を使用していない場合、または信頼関係が異なる場合:

メンバーアカウントごとに個別のエントリを作成します。 クラウドサービスアカウント:>メンバーアカウント アクセスロール名:>そのメンバーアカウントの特定の IAM ロールの完全な ARN 注: AWS のデフォルトロール OrganizationAccountAccessRole を使用している場合は、この構成をスキップします。

2.3.2 アクセサーアカウントのIAM ロール(EC2インスタンス・プロファイル)

MID サーバーはアクセサーアカウントの EC2 インスタンスでホストされ、EC2 IAM ロールを使用して管理アカウントのロールを引き受けます。すべてのメンバーアカウントで管理アカウントの IAM ロールが引き受けられます。

使用するタイミング このバリアントは次の場合に使用します。

MID サーバーは、アクセサーアカウント内の EC2 インスタンスで実行されます 静的認証情報 (アクセスキーとシークレット) の管理を 回避 したい インスタンスメタデータを介して IAM ロールベースの動的認証情報 を使用する場合

詳細な手順については、「4. 認証情報なしのディスカバリー」を参照してください。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 アクセサーアカウント (EC2 インスタンスプロファイル) 管理アカウント（アクセサーアカウントを信頼し、メンバーアカウントから信頼される） メンバーアカウント（管理アカウントを信頼） 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 7 を参照してください。KB の「 ユースケースと実行フロー の EC2(アクセサー) → 管理→メンバー 。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

アクセサーアカウント IAM ロール EC2 信頼関係を持つ IAM ロールの作成 IAM ポリシーにより、管理アカウントのロールに対する sts:AssumeRole が許可されます AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します 管理アカウント IAM ロール IAM ロールを作成 信頼ポリシー:アクセサー IAM ロールにこのロールの引き受けを許可します 権限:メンバーアカウントのロールに対する sts:AssumeRole AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー を添付します さらに 管理アカウントの IAM ロール に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます メンバーアカウント IAM ロール IAM ロールを作成 信頼ポリシー:管理アカウントの IAM ロールを引き受けることを許可します AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー を添付します トラストチェーンサマリー アクセサーアカウントの IAM ロール → 管理アカウントの IAM ロール → メンバーアカウントの IAM ロール 権限の概要 アクセサー IAM ロール: 管理ロールに対する sts:AssumeRole: SN_MGMT_ASSUME_ROLE 管理 IAM ロール: メンバーロールに対する sts:AssumeRole: SN_MEMBER_ACCOUNT_ROLE 全アカウント対象(アクセサー/管理/メンバーアカウント) 読み取り専用またはディスカバリー固有の権限 ServiceNow 側 アクセサーアカウント AWS 認証情報テーブル ( aws_credentials ) 必須ではありません (認証情報は EC2 インスタンスプロファイル によって動的に提供されます) MID サーバー構成プロパティ MID サーバーパラメーターの設定 mid.aws.instance_profile_name = EC2 インスタンスに添付された IAM ロールの名前 クラウドサービスアカウント (cloud_service_account) アクセサーアカウントのエントリの作成

アカウント ID:> アクセサーアカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウント -> false 管理アカウント セクション「2.3.1 アクセサーアカウントの IAM ユーザー」と同じ-> 管理アカウント構成 (サービスアカウント用に 1 つのエントリ、cloud_service_account_aws_cross_assume_role_params 用に 1 つのエントリ) メンバーアカウント セクション「2.3.1 アクセサーアカウントの IAM ユーザー」と同じ:> メンバーアカウント構成 (正しい IAM ロール ARN を持つメンバーアカウントごとに 1 つのエントリ)

2.4. モデル 4: アクセサー → メンバー／管理アカウント（直接アクセス）

この構成では、アクセサーアカウントの IAM ユーザー/ロールが、管理アカウントとすべてのメンバーアカウントで IAM ロールを直接引き受けることを前提としています。管理アカウントとメンバーアカウントの両方がアクセサー IAM ユーザーを直接信頼します。ロールチェーンはありません。

2.4.1 アクセサ・アカウント・ダイレクトのIAM ユーザー

MID サーバーはアクセサーアカウント (アクセスキーとシークレットアクセスキー) を使用して認証し、管理アカウントとすべてのメンバーアカウントの両方で IAM ロールを引き受けます。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 アクセサーアカウント (IAM ユーザー) 管理アカウント（アクセサーアカウントを信頼） メンバーアカウント（アクセサーアカウントを直接信頼） 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 4 を参照してください。KB の「 ユースケースと実行フロー の IAM ユーザー (アクセサー) → 管理 + メンバー (直接) 。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

アクセサーアカウント IAM ユーザー プログラムによるアクセス権を持つ IAM ユーザーを作成する IAM ポリシーでは、管理アカウント ( SN_MGMT_ASSUME_ROLE ) およびすべてのメンバーアカウント ( SN_MEMBER_ACCOUNT_ASSUME_ROLE ) のロールで sts:AssumeRole が許可されています AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します 管理アカウント IAM ロール IAM ロールを作成 (例:SN_MGMT_ASSUME_ROLE) 信頼ポリシーにより、 アクセサー IAM ユーザー ARN がこのロールを引き受けることが許可されます AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します さらに 管理アカウントの IAM ロール に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます メンバーアカウント IAM ロール IAM ロールの作成 (例:SN_MEMBER_ACCOUNT_ROLE) 信頼ポリシーにより、 アクセサー IAM ユーザー ARN がこのロールを引き受けることが許可されます AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess またはカスタムディスカバリーポリシー (セクション 1.4 を参照) を添付します トラストチェーンサマリー アクセサーアカウント IAM ユーザー → 管理アカウント内の SN_MGMT_ASSUME_ROLE を引き受ける アクセサーアカウント IAM ユーザー → メンバーアカウント内の SN_MEMBER_ACCOUNT_ROLE を引き受ける 権限の概要 アクセサー IAM ユーザー: 管理ロールに対する sts:AssumeRole: SN_MGMT_ASSUME_ROLE メンバーロールに対する sts:AssumeRole: SN_MEMBER_ACCOUNT_ROLE 全アカウント対象(アクセサー/管理/メンバーアカウント) 読み取り専用またはディスカバリー固有の権限 ServiceNow 側 アクセサーアカウント AWS 認証情報テーブル ( aws_credentials ) アクセサーアカウント IAM ユーザーの認証情報エントリを作成します (アクセスキーとシークレットアクセスキー) クラウドサービスアカウント ( cloud_service_account ) アクセサーアカウントのエントリの作成

アカウント ID:> アクセサーアカウント ID ディスカバリー認証情報 → アクセサーアカウントの認証情報を参照 データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウント -> false 管理アカウント クラウドサービスアカウント ( cloud_service_account )

管理アカウントのエントリを作成

アカウント ID:> 管理アカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) Is 管理アカウント → チェック済み アクセサーアカウント:>アクセサーアカウントへの参照 クラウドサービスアカウント AWS クロスAssumeRoleパラメーター ( cloud_service_account_aws_cross_assume_role_params ) 管理アカウントのエントリを作成 •クラウドサービスアカウント:>管理アカウント •アクセスロール名:>フル管理 IAM ロール ARN メンバーアカウント クラウドサービスアカウント ( cloud_service_account )

メンバーアカウントのエントリを作成

アカウント ID:>メンバーアカウントアカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウントである -> オフ アクセサーアカウント:> [アクセサーアカウント] を選択します 注 : 管理アカウントの検証が既に完了している場合 、クラウドサービスアカウントテーブルのすべてのメンバーアカウントのエントリが既に存在している可能性があります。その場合は、次の手順に直接進み ( クラウドサービスアカウント AWS クロスAssumeRoleパラメーター テーブル) で各メンバーアカウントのエントリを作成し、必要に応じてクラウドサービスアカウントの [アクセサーアカウント] フィールドを更新します。

この手順は各メンバーアカウントに対して繰り返されます

クラウドサービスアカウント AWS クロスAssumeRoleパラメーター ( cloud_service_account_aws_cross_assume_role_params )

各メンバーアカウントのエントリーを作成 •クラウドサービスアカウント:>メンバーアカウント •アクセスロール名:>メンバーアカウント IAM ロールの完全な ARN

2.4.2 アクセサーアカウントダイレクトのIAM ロール(EC2インスタンス・プロファイル)

MID サーバーは、アクセサーアカウントの EC2 インスタンスでホストされ、EC2 IAM ロールを使用して管理アカウントとすべてのメンバーアカウントのロールを直接引き受けます。

使用するタイミング このバリアントは次の場合に使用します。

MID サーバーは、アクセサーアカウント内の EC2 インスタンスで実行されます 静的認証情報 (アクセスキーとシークレット) の管理を 回避 したい インスタンスメタデータを介して IAM ロールベースの動的認証情報 を使用する場合 アクセサーアカウントは、管理アカウントとすべてのメンバーアカウントのロールを直接引き受けます。

セクション アカウント アイテム 詳細 AWS 側 アカウント構造 アクセサーアカウント (EC2 インスタンスプロファイル) 管理アカウント（アクセサーアカウントを信頼） メンバーアカウント（アクセサーアカウントを直接信頼） 自動セットアップ方法 AWS 側のすべてのステップは CFT セットアップ KB を使用して自動化できます。 セクション 8 を参照してください。 KB の「 ユースケースと実行フロー のEC2(アクセサー) →管理 + メンバー (ダイレクト))。

次の AWS のサイドステップはスキップできます。CFT を使用する場合は、手動で実行しないでください。

アクセサーアカウント IAM ロール EC2 信頼関係を持つ IAM ロールの作成 IAM ポリシーにより、管理アカウントのロールに対する sts:AssumeRole が許可されます AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess または カスタムディスカバリーポリシー を添付します 管理アカウント IAM ロール IAM ロールを作成 信頼ポリシーにより、 アクセサー IAM ロール ARN がこのロールを引き受けることが許可されます 権限:メンバーアカウントのロールに対する sts:AssumeRole AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess または カスタムディスカバリーポリシー を添付します さらに、管理アカウントの IAM ロール に、AWS Organizations API 呼び出し (ListAccounts、DescribeOrganization など) を実行してメンバーアカウントを動的に検出する権限があることを確認します。- これは、AWS 管理ポリシー AWSOrganizationsReadOnlyAccess をアタッチするか、カスタムポリシーに同等のアクションを含めることで実行できます メンバーアカウント IAM ロール IAM ロールの作成 (例:SN_MEMBER_ACCOUNT_ROLE) 信頼ポリシーにより、 アクセサー IAM ロール ARN がこのロールを引き受けることが許可されます。 AWS リソースを検出するために必要な AWS 権限を持つ ReadOnlyAccess または カスタムディスカバリーポリシー を添付します。 トラストチェーンサマリー アクセサーアカウントの IAM ロール → 管理アカウントの IAM ロールを引き受ける アクセサーアカウントの IAM ロール → すべてのメンバーアカウントの IAM ロールを引き受ける 権限の概要 アクセサー IAM ロール: 管理ロールに対する sts:AssumeRole メンバーロールに対する sts:AssumeRole 全アカウント対象(アクセサー/管理/メンバーアカウント) 読み取り専用またはディスカバリー固有の権限 ServiceNow 側 アクセサーアカウント AWS 認証情報テーブル ( aws_credentials ) 必須ではありません (認証情報は EC2 インスタンスプロファイル によって動的に提供されます) MID サーバー構成プロパティ MID サーバーパラメーターの設定 mid.aws.instance_profile_name = EC2 インスタンスに添付された IAM ロールの名前

クラウドサービスアカウント ( cloud_service_account ) アクセサーアカウントのエントリの作成

アカウント ID:> アクセサーアカウント ID ディスカバリー認証情報>空白のままにします データセンタータイプ:> AWS データセンター (cmdb_ci_aws_datacenter) 管理アカウント -> false 管理アカウント セクション「2.4.1 アクセサーアカウント直接の IAM ユーザー」と同じ>管理アカウント構成 (サービスアカウント用に 1 つのエントリ、cloud_service_account_aws_cross_assume_role_params 用に 1 つのエントリ)

メンバーアカウント セクション「2.4.1 アクセサーアカウント直接の IAM ユーザー」と同じ:> メンバーアカウント構成 (正しい IAM ロール ARN を持つメンバーアカウントごとに 1 つのエントリ)

3.認証情報ベースのディスカバリー このセクションでは、「モデル 3:アクセサー→管理→メンバーアカウント (ロールチェーン) で 永続的な IAM ユーザー認証情報 を使用して AWS クラウドディスカバリーを構成するための ステップバイステップ ガイドを提供します。

このセットアップでは、ServiceNow はアクセサーアカウントの 静的 IAM 認証情報（アクセスキー ID とシークレットアクセスキー） を使用して、管理アカウントとメンバーアカウント間で IAM ロールを引き受け AWS リソースを検出します。

次の 3 つのタイプの AWS アカウントを設定します。

アクセサーアカウント:MID サーバーで使用される IAM ユーザーをホストします 管理アカウント: メンバーアカウントのロールを引き受けます メンバーアカウント

アカウントセットアップモデル

3.1 アカウントの種類

3.1.1.アクセサーアカウント (トラステッドアカウント):IAM ユーザー>

キーロール:永続的な認証情報を持つ IAM ユーザーを保持し、管理アカウントによって信頼されています

このアカウントには、ServiceNow の Connections & Credentials モジュールで構成される永続的な AWS 認証情報（Access Key ID と Secret Key）を持つ IAM ユーザーが含まれます。 MID サーバーは、ディスカバリー中にこれらの認証情報を使用して 管理アカウントのロールを引き受けます 次の場合があります。 AWS 組織内の メンバーアカウント 組織外の外部アカウント 管理アカウントのトラステッドアカウントとして機能します。 検出する AWS リソースを含めることもできます 3.1.2.管理アカウント:> IAM ロール

キーロール:アクセサーアカウントのトラスティングアカウントとメンバーアカウントのトラステッドアカウント

管理アカウント（以前は Master Account と呼ばれていました）は、AWS Organizations のルートアカウントです。 MID サーバーによるクロスアカウントディスカバリーを可能にするロールを定義し、アクセサーアカウントの IAM ユーザーを信頼します。 このコンテキストでは、 トラスティング アカウントとして機能します また、メンバーアカウントのディスカバリー時に MID サーバーが引き受ける IAM ロールも定義し、それらのアカウントに対するトラステッドアカウントとして機能します。 検出する AWS リソースを含めることもできます 3.1.3.メンバーアカウント (トラスティングアカウント):> IAM ロール

キーロール: アクセスのために管理アカウントを信頼する IAM ロール

これらは組織の下のアカウントです。 管理アカウントの IAM ロールを信頼し、MID サーバーがクロスアカウントディスカバリーを実行できるようにします。 ディスカバリーの対象となる AWS リソースが含まれます。 まとめ

アカウントの種類 として機能 信頼関係 アクセサーアカウント トラステッドアカウント (アクセサー) 管理アカウントによって信頼されている IAM ユーザーを提供します 管理アカウント トラスティング（アクセサー向け）およびトラステッド（メンバー向け） アクセサー IAM ユーザーを信頼します。そのロールはメンバーアカウントから信頼されます メンバーアカウント トラスティングアカウント 管理アカウントが所有するディスカバリーロールを信頼します

3.2 アクセサーアカウント構成 このセクションでは、 AWS ポータル と ServiceNow インスタンス の両方でアクセサーアカウントを構成する手順の概要を説明します。

3.2.1 AWS ポータルでのアクセサーアカウントのセットアップ 3.2.1.1. IAM ユーザーの作成 (例:SN_ACCESSOR_ACCOUNT_USER)

ユーザーを作成する> IAM >ユーザーに移動し

ステップ 1 :ユーザーのデフォルトを指定する

ユーザー名:ユーザー名を入力します (例: SN_ACCESSOR_ACCOUNT_USER ) ステップ 2: 権限の設定

ディスカバリーに必要な権限を付与する AWS 管理の ReadOnlyAccess ポリシーまたは カスタムポリシー (セクション 1.4 を参照) を追加します ステップ 3: レビューと作成

作成 3.2.1.2. 管理アカウントのロールを引き受けるインラインポリシーを追加

IAM ユーザーに インラインポリシー を添付して、管理アカウントでのロールを引き受けることができるようにします。(例。 SN_MGMT_ACCOUNT_ROLE )

インラインポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" } ] } 注: ここで参照する IAM ロール ( SN_MGMT_ACCOUNT_ROLE など) は、管理アカウントで作成する必要があります。これについては後のセクションで説明します。

3.2.1.3. アクセスキーの生成

上で作成した IAM ユーザーに移動します。 [セキュリティ認証情報] タブで、新しいアクセスキーを生成します :アクセスキーを作成 アクセスキー ID とシークレットアクセスキーを安全に保管してください。 これらは ServiceNow での構成中に必要になります。 結果: これで、アクセサーアカウントが次のように設定されました。

次の IAM ユーザー: 自分のアカウントのリソースを検出する権限 sts:AssumeRole を介して管理アカウントでロールを引き受ける権限 ServiceNow での認証用に生成されたアクセスキーと秘密キー 重要：

後の構成ステップで使用するために、次の詳細を保持します。

アクセサーアカウント ID IAM ユーザー名 IAM ユーザーのアクセスキー ID とシークレットアクセスキー 3.2.2 ServiceNowインスタンスでのアクセサーアカウントのセットアップ

ステップ 3.2.2.1: アクセサー認証情報の追加

[ 接続 & 認証情報 -> 認証情報 (Connections & Credentials - Credentials) に移動します。 タイプ AWS 認証情報 の新しいエントリを作成し、IAM ユーザーのアクセスキー ID とシークレットアクセスキーを追加します ステップ 3.2.2.2:クラウドサービスアカウントの作成

移動先： ワークスペース:> クラウドディスカバリー ワークスペース:> クラウドディスカバリー:> 新規ディスカバリースケジュール スケジュールの詳細を入力します。 プロバイダーを選択: AWS ディスカバリースケジュール名:スケジュールの希望する名前 ディスカバリースケジュール名 -> クラウドプロバイダー ->AWS MID 選択タイプ:AWS ディスカバリー設計に基づく 次へ 3.サービスアカウントの作成:サービスアカウント>新しいサービスアカウント

名前:分かりやすい名前 アカウント ID:アクセサーアカウント ID 認証情報:上で作成した認証情報へのリンク データセンタータイプ:AWS ［テストアカウント］をクリックします（完了まで数分かかる場合があります） ステップ 3.2.2.3: サービスアカウントのテスト

サービスアカウントレコードの テストアカウント ボタンを使用します。 これにより、バックグラウンドチェックがトリガーされ、ディスカバリーステータスレコードが作成されます。 [ディスカバリーステータス] でログを確認して、結果を確認できます。 テストアカウントのトラブルシューティング:

これにより、ディスカバリーステータステーブルにレコードが作成されます。 ディスカバリーステータスに移動 -> 説明を検索します:「 検証アカウントを実行 - 」->検証に失敗した場合は、最新のログを参照してトラブルシューティングを行います。 結果:

サービスアカウントの検証に成功するはずです。 これで、MID サーバーはこのアクセサーアカウントを使用して、クラウドディスカバリーの管理アカウントでロールを引き受けることができます。

オプション:アクセサーアカウントのディスカバリースケジュールを作成します :

アクセサーアカウントのサービスアカウントを検証した後、そのディスカバリースケジュールの作成に進むことができます (アクセサーアカウント自体内のリソースを検出する場合のみ 限り)。

ユースケース: アクセサーアカウントに、管理アカウントまたはメンバーアカウントとは独立して検出される AWS リソース (EC2、S3 など) が含まれている場合。

次の場合は、この手順をスキップします。

アクセサーアカウントは、既に管理アカウントの AWS 組織の一部であり、 管理アカウントから 一元化されたディスカバリースケジュールを作成する予定である (メンバーアカウントの場合はアクセサーが自動的に含まれます)

3.3 管理アカウントの構成

このセクションでは、 AWS ポータル と ServiceNow インスタンス の両方で管理アカウントを構成するステップバイステップのプロセスの概要を説明します。

3.3.1 AWS ポータルでの管理アカウントのセットアップ 3.3.1.1. IAM ロールの作成 (例:SN_MGMT_ACCOUNT_ROLE)

IAM >ロールに移動し>ロールを作成します

ステップ 1 :信頼できるエンティティを選択

タイプ: カスタム信頼ポリシー プリンシパルの追加 -> プリンシパルタイプ: IAM ユーザー -> ARN -> arn:aws:iam::{Account}:user/{UserName} {Account} を実際のアクセサーアカウント ID に、{UserName} をアクセサーアカウントで作成された IAM ユーザー名に置き換えます プリンシパルを追加 カスタム信頼ポリシーの例 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :user/ " }, "Action": "sts:AssumeRole" } ] } ステップ 2 :権限の追加 - > 追加 ディスカバリーに必要な権限を付与する AWS managed ReadOnlyAccess ポリシーまたは カスタムポリシー (セクション 1.4 を参照)

AWSOrganizationsReadOnlyAccess ポリシーを追加します。

注: AWSOrganizationsReadOnlyAccess は、AWS 管理対象の ReadOnlyAccess ポリシーが使用されている場合、オプションです

ステップ 3: 名前を付け、確認し、作成する

ロール名: SN_MGMT_ACCOUNT_ROLE（アクセサーアカウント IAM ユーザーのインラインポリシー作成に使用される管理 IAM ロール）

ステップ 4: ロールの作成

3.3.1.2. メンバーアカウントのロールを引き受けるインラインポリシーを追加

インラインポリシーを SN_MGMT_ACCOUNT_ROLE に添付して、すべてのメンバーアカウントでロールを引き受けることができるようにします。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE" } ] } 注意: SN_MEMBER_ACCOUNT_ROLE は後で各メンバーアカウントで作成する必要があります。

結果: これで、管理アカウントが次のように構成されました。

次の IAM ロール。 アクセサーアカウント IAM ユーザーとの信頼関係 管理アカウント内のリソースを検出する権限 sts:AssumeRole を介して各メンバーアカウントでロールを引き受ける権限 メンバーアカウントを検出する権限:AWSOrganizationsReadOnlyAccess ポリシー 重要：

後の構成ステップで使用するために、次の詳細を保持します。

管理アカウント ID IAM ロールの ARN: SN_MGMT_ACCOUNT_ROLE 3.3.2 ServiceNowインスタンスでの管理アカウントのセットアップ

管理アカウントのクラウドサービスアカウントを作成します。

移動先： ワークスペース:> クラウドディスカバリー ワークスペース:> クラウドディスカバリー:> 新規ディスカバリースケジュール スケジュールの詳細を入力します。 プロバイダーを選択: AWS ディスカバリースケジュール名:スケジュールの希望する名前 ディスカバリースケジュール名 -> クラウドプロバイダー ->AWS MID 選択タイプ:AWS ディスカバリー設計に基づく 次へ 3.サービスアカウントの作成:サービスアカウント>新しいサービスアカウント

名前:アカウントの分かりやすい名前 アカウント ID:管理アカウント ID アクセスロール名: 管理アカウントの完全な ARN IAM ロール ( SN_MGMT_ACCOUNT_ROLE ) アクセサーアカウントを選択:リストからアクセサーアカウントを選択します。アクセサーアカウントのクラウドサービスアカウントは、「ServiceNow インスタンスでのアクセサーアカウントのセットアップ」の手順で既に作成および検証されています。 テストアカウント:>数分かかります。 テストアカウントの検証に成功すると、管理アカウント下のすべてのメンバーアカウントが検出されます テストアカウントのトラブルシューティング:

これにより、ディスカバリーステータステーブルにレコードが作成されます。 ディスカバリーステータスに移動 -> 説明を検索します:「 検証アカウントを実行 - 」->検証に失敗した場合は、最新のログを参照してトラブルシューティングを行います。 ディスカバリーステータスに移動 -> 説明を検索します:「 スケジュールに対してメンバーアカウントのリフレッシュを実行する - 」->関連する詳細については、最新のログを参照してください。 結果:

管理アカウントのサービスアカウントの検証に成功しました 管理アカウントが信頼するすべてのメンバーアカウントからデータを取得できる状態になります。

オプション:管理アカウントのディスカバリースケジュールを作成

注: 管理アカウントのサービスアカウントを検証した後、そのディスカバリースケジュールの作成に進むことができます ( この段階で管理アカウント自体内のリソースを検出する場合のみ)。

ただし、管理アカウントから 一元化されたディスカバリースケジュール を作成する予定の場合は (構成されたすべてのメンバーアカウントも自動的に含まれます)、今すぐスケジュールの作成を スキップする必要があります。

代わりに、必要なすべてのメンバーアカウントの構成を続行し これらの手順を完了した後にスケジュールを作成し 1 回の実行で完全なマルチアカウントディスカバリーを有効にします。

3.4 メンバーアカウント構成 このセクションでは、 AWS ポータル と ServiceNow インスタンス の両方でメンバーアカウントを設定するステップバイステップのプロセスの概要を説明します。

注意:このプロセスは、検出するすべてのメンバーアカウントに対して繰り返す必要があります。

3.4.1 AWSポータルでのメンバーアカウントのセットアップ 3.4.1.1. IAM ロールの作成 (例:SN_MEMBER_ACCOUNT_ROLE)

IAM >ロールに移動し>ロールを作成します

ステップ 1 :信頼できるエンティティを選択

タイプ: カスタム信頼ポリシー プリンシパルの追加 ->プリンシパルタイプ: IAM ロール -> ARN -> arn:aws:iam:: {Account} :role/ {RoleNameWithPath} {Account} を実際のメンバーアカウント ID に、{ RoleNameWithPath } を管理アカウントで作成された IAM ロール名 ( SN_MGMT_ACCOUNT_ROLE など) に置き換えます プリンシパルを追加 カスタム信頼ポリシーの例 { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" }, "Action": "sts:AssumeRole" } ] } ステップ 2 :権限の追加:> 添付 AWS 管理の ReadOnlyAccess ポリシー、またはディスカバリーに必要な権限を付与するカスタムディスカバリーポリシー

ステップ 3: 名前を付け、確認し、作成する

ロール名: SN_MEMBER_ACCOUNT_ROLE（管理アカウントの IAM インラインポリシーで参照されるメンバーアカウント用 IAM ロール）

ステップ 4: ロールの作成

結果: これで、メンバーアカウントは次のように構成されます。

次の IAM ロール ( SN_MEMBER_ACCOUNT_ROLE ) には次のものがあります。 管理アカウントの IAM ロールとの信頼関係 メンバーアカウント内のリソースを検出する権限 重要：

後の構成ステップで使用するために、次の詳細を保持します。

メンバーアカウント ID 作成された IAM ロールの完全な ARN: SN_MEMBER_ACCOUNT_ROLE

3.4.2 ServiceNowインスタンスでのメンバーアカウントのセットアップ

ステップ 1:組織AssumeRoleを追加 パラメーター:

次に移動: クラウドプロビジョニングとガバナンス -> 組織アクセスパラメーター -> AWS 組織AssumeRoleパラメーター-> 新規

フォームフィールド:

アクセスロール名: メンバーアカウント IAM ロールの完全な ARN（例: arn:aws:iam:: :role/SN_MEMBER_ACCOUNT_ROLE）

クラウドサービスアカウント: 管理アカウント (前の手順で作成) を選択します

注意: この手順は、すべてのメンバーアカウントに対して完了する必要があります。すべてのメンバーアカウントが同じ IAM ロール 名を使用している場合は、ARN のアカウント ID にワイルドカードを使用できます ( arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE >IAM ロールのアカウント ID は「*」に置き換えられます。 MID サーバーは、ディスカバリー中に適切なアカウント番号に置き換えます。

ステップ 2:(オプション) メンバーアカウントのクラウドサービスアカウントを作成します。

メンバーアカウントごとに ServiceNow で個別のサービスアカウントを作成する必要はありません。代わりに、管理アカウントのサービスアカウントを使用してすべてのメンバーアカウントが検出されます。

ただし、メンバーアカウントが cmdb_ci_cloud_service_account テーブルにまだ存在しない場合は、テスト用に手動で作成できます。

ステップ 3:(オプション) 既存のメンバーアカウントでは、以下のステップはオプションです。テストアカウントのトラブルシューティングは管理アカウントと同じです

テストアカウントのトラブルシューティング:

これにより、ディスカバリーステータステーブルにレコードが作成されます。 ディスカバリーステータスに移動 -> 説明「 検証を実行アカウント - 」を検索します 検証に失敗した場合のトラブルシューティングについては、最新のログを参照してください。 結果:

メンバーアカウントのサービスアカウントの検証に成功しました

最後のステップ:管理アカウントとメンバーアカウントのクラウドディスカバリースケジュールを作成する 管理アカウントと必要なすべてのメンバーアカウント が完全に構成されたので、管理アカウントからクラウドディスカバリースケジュールの作成に進むことができます。このスケジュールでは次のことを行います。

管理アカウントのリソースを検出します すべての信頼できるメンバーアカウントのリソースを自動的に検出します 以前に確立したロールチェーンセットアップを使用します 成果： ディスカバリープロセスでは、管理アカウントの IAM ロールを使用して、構成されているすべてのメンバーアカウントに引き継がれます。 管理アカウントとメンバーアカウントの両方のリソースが検出され、CMDB に取り込まれます 4.認証情報なしディスカバリー このセクションでは、モデル 3（アクセサー→管理→メンバーアカウント／ロールチェーン）において、アクセサーアカウントの IAM ロール（EC2 インスタンスプロファイル）を使用して AWS クラウドディスカバリーを構成する手順を説明します。

認証情報なしディスカバリーとは 認証情報なしディスカバリーにより、ServiceNow は、永続的な IAM 認証情報（Access Key および Secret Key）を使用せずに AWS ディスカバリーを実行できます。 代わりに、 MID サーバーは、 IAM ロール が割り当てられたアクセサーアカウントの EC2 インスタンス で実行されます。このロールは インスタンスメタデータサービス (IMDS) を通じ 一時的な認証情報を提供します。

このモデルは、長期的な認証情報を保存する必要がなくなることでセキュリティを向上させ、短期間の認証情報使用に関する AWS のベストプラクティスに沿っています。

詳細な構成手順については、以下を参照してください。

パート 1:概要とアクセサーアカウントのセットアップ パート 2:管理アカウントのセットアップ パート 3:メンバーアカウントのセットアップ (オプション)上記の手順を既に実行している場合は、以下の残りの手順をスキップできます。

このセットアップでは、ディスカバリーにより、ServiceNow クラウドディスカバリーは、手動で管理する長期的な認証情報（IAM ユーザーのアクセスキーなど）を使用せずに AWS アカウントにアクセスできます。代わりに、 MID サーバーが EC2 インスタンス で実行され、適切な IAM ロール が割り当てられているときに、 インスタンスメタデータ を通じて AWS が提供する 一時的な認証情報 を活用します。

次の 3 つのタイプの AWS アカウントを設定します。

アクセサーアカウント:EC2 インスタンスプロファイルに添付された IAM ロールをホストします 管理アカウント: メンバーアカウントのロールを引き受けます メンバーアカウント 仕組み

認証情報なしのセットアップでは、ServiceNow は MID サーバーを使用し、インスタンスプロファイルを使用してアクセサーの一時的な認証情報を生成します。 認証情報なしセットアップでは、永続的な IAM 認証情報はありません。 代わりに: MID サーバーは、アクセサーアカウントの EC2 インスタンス で実行されます。 EC2 インスタンスには、管理アカウントでロールを引き受けるために必要な権限を持つ IAM ロール がアサインされます。 このロールは、 インスタンスメタデータサービス を使用して一時的な認証情報を提供します。 MID サーバーは これらの認証情報を実行時に取得 し、次の目的で使用します。 管理アカウントのロールを引き受ける その後、管理アカウントは各メンバーアカウントの IAM ロールを引き受けます ディスカバリーは、この信頼チェーンを使用してアカウント階層全体で進行します。

アカウント構造の比較

アカウントの種類 認証情報ベースのディスカバリー 認証情報なしのディスカバリー アクセサーアカウント - IAM ユーザーの永続的な認証情報

- MID サーバーはどこでも実行可能 (オンプレミス/EC2 インスタンス)

- 管理アカウントに対する sts:AssumeRole 権限を持つ IAM ユーザー

- EC2 サービスへの IAM ロール 信頼関係

- EC2 インスタンスに添付された IAM ロール

- MID サーバーは同じ EC2 インスタンス上で実行する必要があります

- 管理アカウントに対する sts:AssumeRole 権限を持つ IAM ロール

管理アカウント - アクセサーアカウントIAM ユーザーとの信頼関係 - EC2インスタンスにアタッチされたアクセサーアカウントIAM ロールとの信頼関係 メンバーアカウント - 管理アカウントによって信頼されているIAM ロール - 認証情報ベースのセットアップからの 変更なし

アカウントセットアップモデル

4.1 アカウントの種類

認証情報なしディスカバリーでは、同じ 3 タイプのアカウントを設定する必要があります。

4.1.1.アクセサーアカウント (トラステッドアカウント):IAM ロール>添付された EC2 インスタンス

キーロール:管理アカウントから信頼される IAM ロールがアタッチされた EC2 インスタンスを保持します

EC2 サービスを 信頼します EC2 インスタンスで MID サーバー をホストします MID サーバーは、ディスカバリー中にこれらの認証情報を使用して 管理アカウントのロールを引き受けます 次の場合があります。 AWS 組織内の メンバーアカウント 組織外の外部アカウント 管理アカウントのトラステッドアカウントとして機能します。 検出する AWS リソースを含めることもできます 4.1.2.管理アカウント:> IAM ロール

キーロール:アクセサーアカウントのトラスティングアカウントとメンバーアカウントのトラステッドアカウント

管理アカウント（以前は Master Account と呼ばれていました）は、AWS Organizations のルートアカウントです。 MID サーバーを介したクロスアカウントディスカバリーを可能にするロールを定義することで、アクセサーアカウントから IAM ロールを信頼 します このコンテキストでは、 トラスティング アカウントとして機能します また、メンバーアカウントのディスカバリー時に MID サーバーが引き受ける IAM ロールも定義し、それらのアカウントに対するトラステッドアカウントとして機能します。 検出する AWS リソースを含めることもできます 4.1.3.メンバーアカウント (トラスティングアカウント):> IAM ロール

キーロール:管理アカウントを信頼し、アクセスを可能にする IAM ロールです。

これらは組織の下のアカウントです 管理アカウントの IAM ロールを信頼し、MID サーバーがクロスアカウントディスカバリーを実行できるようにします。 ディスカバリーの対象となる AWS リソースが含まれます。 まとめ

アカウントの種類 として機能 信頼関係 アクセサーアカウント トラステッドアカウント (アクセサー) 管理アカウントによって信頼されている IAM ロールを提供します 管理アカウント トラスティング（アクセサー向け）およびトラステッド（メンバー向け） アクセサー IAM ロールを信頼します。そのロールはメンバーアカウントから信頼されます メンバーアカウント トラスティングアカウント 管理アカウントが所有するディスカバリーロールを信頼します

4.2 アクセサーアカウント構成 このセクションでは、認証情報なしディスカバリー用の AWS ポータル と ServiceNow インスタンス の両方でアクセサーアカウントを構成する手順の概要を説明します。

4.2.1 AWS ポータルでのアクセサーアカウントのセットアップ このセクションでは、認証情報なしディスカバリー用に AWS ポータルでアクセサーアカウントを構成する手順の概要を説明します。このセクションでは、MID サーバーが永続的な認証情報ではなく IAM ロールを使用して EC2 インスタンス上で実行されます。

注: これらの手順は、MID サーバーがホストされているアカウント (アクセサーアカウント) に適用されます。

4.2.1.1. IAM ロールの作成 (例:SN_MID_SERVER_EC2_ROLE)

IAM >ロールに移動し>ロールを作成します

ステップ 1 :信頼できるエンティティを選択

信頼できるエンティティタイプ: AWS サービス ユースケース:>サービスまたはユースケース: EC2 [次へ:権限] をクリックします ステップ 2 :権限の追加:>ディスカバリーに必要な権限を付与する AWS 管理の ReadOnlyAccess ポリシーまたはカスタムポリシーを追加します

ステップ 3: 名前を付け、確認し、作成する

ロール名: SN_MID_SERVER_EC2_ROLE

ステップ 4: ロールの作成

4.2.1.2. 管理アカウントでロールを引き受けるインラインポリシーを追加

上記ステップで作成したアクセサーアカウント IAM ロールに インラインポリシー を添付し、管理アカウントでのロールを引き受けることができるようにします。(例。 SN_MGMT_ACCOUNT_ROLE )

新しく作成した IAM ロール（例: SN_MID_SERVER_EC2_ROLE）に移動します。

[権限]-> [インラインポリシーを作成] に移動します

ステップ 1:権限の指定

サービスを選択: STS

許可されたアクション:書き込み -> ロールを引き受ける

ARN の追加:ARN を指定:他のアカウント> 管理アカウント ID>

ロール名（パスを含む）: 管理アカウント IAM ロール（例: SN_MGMT_ACCOUNT_ROLE）

[ARN の追加] をクリックします

ステップ 2:レビューと作成

ポリシー名: 分かりやすい名前 (例: InlinePolicyToAllowAssumeRoleToMgmtAccount)

ポリシーを作成

インラインポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" } ] } このインラインポリシーにより、EC2 IAM ロールは実行時に管理アカウントのディスカバリーロールを引き受けることができます

注: ここで参照する IAM ロール ( SN_MGMT_ACCOUNT_ROLE など) は、管理アカウントで作成する必要があります。これについては後のセクションで説明します。

4.2.1.3. MID サーバーをホストする EC2 インスタンスに IAM ロールをアタッチする

EC2 >インスタンス>に移動します MID サーバーがインストールされる (またはインストールされる予定の) インスタンスを選択します インスタンスがまだ作成されていない場合は、作成してから続行します。 [ アクション] > [セキュリティ] > [IAM ロールの変更] に移動 IAM ロール フィールドで IAM ロール（例: SN_MID_SERVER_EC2_ROLE）を選択します [ IAM ロールを更新] をクリックします 検証: EC2 インスタンスの詳細ページの [ IAM ロール] に、添付されたロール が表示されます。

結果: IAM ロール (SN_MID_SERVER_EC2_ROLE): EC2 サービスから信頼されている 次に対する権限を付与: ローカルリソースの検出 sts:AssumeRole を使用して、管理アカウントで IAM ロールを引き受けます この IAM ロールは、 MID サーバーを実行している EC2 インスタンスにアタッチされました 重要：

後の構成ステップで使用するために、次の詳細を保持します。

アクセサーアカウント ID IAM ロールの ARN 4.2.2 ServiceNowインスタンスでのアクセサーアカウントのセットアップ

前提条件: IAM ロール (SN_MID_SERVER_EC2_ROLE) が関連付けられているアクセサーアカウント の EC2 インスタンスに MID サーバーがインストールされ、実行されていることを確認します。

4.2.2.1 MID サーバーインスタンスプロファイルパラメータの追加

MID サーバーが EC2 メタデータを介して一時的な認証情報を使用できるようにするには:

ServiceNow インスタンス (EC2 インスタンスでホスト) の MID サーバーレコードに移動します [ configuration parameters (設定パラメーター)] で [新規] をクリックします 以下の詳細を入力します。 パラメーター名: mid.aws.instance_profile_name Value: EC2 インスタンスに添付された IAM ロールの名前 (例:SN_MID_SERVER_EC2_ROLE) パラメーターを保存する ステップ 4.2.2.2: サービスアカウントの作成

移動先： ワークスペース:> クラウドディスカバリー ワークスペース:> クラウドディスカバリー:> 新規ディスカバリースケジュール スケジュールの詳細を入力:プロバイダーを選択します ディスカバリースケジュール名:スケジュールの希望する名前 ディスカバリースケジュール名 クラウドプロバイダー: AWS MID 選択タイプ:特定の MID サーバー:>ディスカバリーでは適切な MID サーバーを使用する必要があります (ユーザー固有の MID クラスターも同様) 「Credential-less Discovery」を有効にします MID サーバー:> 正しい MID サーバーを選択します (インスタンスプロファイルが添付されています) 3.サービスアカウントの作成:サービスアカウント>新しいサービスアカウント

名前:アカウントの分かりやすい名前 アカウント ID:アクセサーアカウント ID 認証情報は 空白 のままにします (認証情報なしのセットアップのため) テストアカウント:>数分かかります。 テストアカウントのトラブルシューティング:

これにより、ディスカバリーステータステーブルにレコードが作成されます。 ディスカバリーステータスに移動 -> 説明を検索します:「 検証を実行アカウント - 」->検証に失敗した場合は、最新のログを参照してトラブルシューティングを行います。 結果:

アクセサーアカウントの検証に成功する必要があります。

オプション:アクセサーアカウントのディスカバリースケジュールを作成します :

アクセサーアカウントのサービスアカウントを検証した後、そのディスカバリースケジュールの作成に進むことができます (アクセサーアカウント自体内のリソースを検出する場合のみ 限り)。

ユースケース: アクセサーアカウントに、管理アカウントまたはメンバーアカウントとは独立して検出される AWS リソース (EC2、S3 など) が含まれている場合。

次の場合は、この手順をスキップします。

アクセサーアカウントは、既に管理アカウントの AWS 組織の一部であり、 管理アカウントから 一元化されたディスカバリースケジュールを作成する予定である (メンバーアカウントの場合はアクセサーが自動的に含まれます)

4.3 管理アカウントの構成 このセクションでは、認証情報なしディスカバリーで使用するために AWS ポータル と ServiceNow インスタンス の両方で管理アカウントを構成する手順の概要を説明します。

4.3.1 AWSポータルでの管理アカウントのセットアップ 4.3.1.1. IAM ロールの作成 (例:SN_MGMT_ACCOUNT_ROLE)

このロールにより、アクセサーアカウントは管理アカウントロールを引き受け、リソースとメンバーアカウントを検出できます。

IAM >ロールに移動し>ロールを作成します

ステップ 1 :信頼できるエンティティを選択

タイプ: カスタム信頼ポリシー プリンシパルの追加 ->プリンシパルタイプ: IAM ロール -> ARN -> arn:aws:iam::{Account}:role/{RoleNameWithPath} {Account} を実際のアクセサーアカウント ID に置き換え、{RoleNameWithPath} をアクセサーアカウントで作成された IAM ロール (例: SN_MID_SERVER_EC2_ROLE ) に置き換えます プリンシパルを追加 カスタム信頼ポリシーの例 { "Version": "2012-10-17", "Statement": [ { "Sid": "TrustAccessorRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :role/ " }, "Action": "sts:AssumeRole" } ] } ステップ 2 :権限の追加 - > 追加 ディスカバリーに必要な権限を付与する AWS 管理の ReadOnlyAccess ポリシーまたはカスタムポリシー

AWSOrganizationsReadOnlyAccess ポリシーを追加します。

注: AWSOrganizationsReadOnlyAccess は、AWS 管理対象の ReadOnlyAccess ポリシーが使用されている場合、オプションです

ステップ 3: 名前を付け、確認し、作成する

ロール名: SN_MGMT_ACCOUNT_ROLE（アクセサーアカウント IAM ロールのインラインポリシー作成に使用される管理 IAM ロール）

ステップ 4: ロールの作成

4.3.1.2. メンバーアカウントのロールを引き受けるインラインポリシーを追加

インラインポリシーを SN_MGMT_ACCOUNT_ROLE に添付して、すべてのメンバーアカウントでロールを引き受けることができるようにします。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE" } ] } 注意: SN_MEMBER_ACCOUNT_ROLE は後で各メンバーアカウントで作成する必要があります。

結果: これで、管理アカウントが次のように構成されました。

次の IAM ロール。 アクセサーアカウント IAM ロールとの信頼関係 管理アカウント内のリソースを検出する権限 sts:AssumeRole を介して各メンバーアカウントでロールを引き受ける権限 メンバーアカウントを検出する権限:AWSOrganizationsReadOnlyAccess ポリシー 重要：

後の構成ステップで使用するために、次の詳細を保持します。

管理アカウント ID IAM ロールの ARN: SN_MGMT_ACCOUNT_ROLE 4.3.2 ServiceNowインスタンスでの管理アカウントのセットアップ

管理アカウントのクラウドサービスアカウントを作成します。

移動先： ワークスペース:> クラウドディスカバリー ワークスペース:> クラウドディスカバリー:> 新規ディスカバリースケジュール スケジュールの詳細を入力します。 プロバイダーを選択: AWS ディスカバリースケジュール名：任意のスケジュール名 -> クラウドプロバイダー -> AWS MID 選択タイプ:AWS ディスカバリー設計に基づく (MID サーバーに接続されたインスタンスプロファイルを使用) 次へ 3.サービスアカウントの作成:サービスアカウント>新しいサービスアカウント

名前:アカウントの分かりやすい名前 アカウント ID:管理アカウント ID アクセスロール名: 管理アカウントの完全な ARN IAM ロール ( SN_MGMT_ACCOUNT_ROLE ) アクセサーアカウントを選択:リストからアクセサーアカウントを選択します。アクセサーアカウントのクラウドサービスアカウントは、「ServiceNow インスタンスでのアクセサーアカウントのセットアップ」の手順で既に作成および検証されています。 テストアカウント:>数分かかります。 テストアカウントの検証に成功すると、管理アカウント下のすべてのメンバーアカウントが検出されます。 テストアカウントのトラブルシューティング:

これにより、ディスカバリーステータステーブルにレコードが作成されます。 ディスカバリーステータスに移動 -> 説明を検索します:「 検証アカウントを実行 - 」->検証に失敗した場合は、最新のログを参照してトラブルシューティングを行います。 ディスカバリーステータスに移動 -> 説明を検索します:「 スケジュールに対してメンバーアカウントのリフレッシュを実行する - 」->関連する詳細については、最新のログを参照してください。 結果:

管理アカウントのサービスアカウントの検証に成功しました。 管理アカウントが信頼するすべてのメンバーアカウントからデータを取得できる状態になります。 オプション:管理アカウントのディスカバリースケジュールを作成

注: 管理アカウントのサービスアカウントを検証した後、そのディスカバリースケジュールの作成に進むことができます ( この段階で管理アカウント自体内のリソースを検出する場合のみ)。

ただし、管理アカウントから 一元化されたディスカバリースケジュール を作成する予定の場合は (構成されたすべてのメンバーアカウントも自動的に含まれます)、今すぐスケジュールの作成を スキップする必要があります。

代わりに、必要なすべてのメンバーアカウントの構成を続行し これらの手順を完了した後にスケジュールを作成し 1 回の実行で完全なマルチアカウントディスカバリーを有効にします。

4.4 メンバーアカウント構成:

これは、AWS ポータル側および ServiceNow 側の両方において、認証情報ベースのディスカバリーのメンバーアカウント構成（3.4 メンバーアカウント構成）とまったく同じです。

最後のステップ:管理アカウントとメンバーアカウントのクラウドディスカバリースケジュールを作成する 管理アカウントと必要なすべてのメンバーアカウント が完全に構成されたので、管理アカウントからクラウドディスカバリースケジュールの作成に進むことができます。このスケジュールでは次のことを行います。

管理アカウントのリソースを検出します。 すべての信頼できるメンバーアカウントのリソースを自動的に検出します。 以前に確立したロールチェーンセットアップを使用します。 成果： ディスカバリープロセスでは、管理アカウントの IAM ロールを使用して、構成されているすべてのメンバーアカウントに引き継がれます。 管理アカウントとメンバーアカウントの両方のリソースが検出され、CMDB に取り込まれます。