• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# AWS Systems Manager を使用したノード管理タスクの実行
以下のトピックでは、統合 AWS Systems Manager コンソールを使用して AWS Organizations 組織とシングル AWS アカウントに対する一般的なノードタスクを完了する方法について説明します。
**Topics**
+ [ノードインサイトの確認](review-node-insights.md)
+ [ノードの探索](view-aggregated-node-details.md)
+ [Systems Manager を使用したジャストインタイムノードアクセス](systems-manager-just-in-time-node-access.md)
+ [診断と修復](diagnose-and-remediate.md)
+ [Systems Manager 設定の調整](settings-overview.md)
# ノードインサイトの確認
Systems Manager の統合コンソールを使用することで、組織またはアカウント内のマネージドノードおよびアンマネージド EC2 インスタンスの全体的なステータスに関するインサイトを得ることができます。
Systems Manager は、マネージドノードと、Systems Manager によってまだ管理されていない EC2 インスタンスに関する視覚的な概要を提供します。(マネージドノードとは、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境において Systems Manager で使用するように設定された任意のマシンです。サポートされているマシンタイプの詳細については、「[ハイブリッドおよびマルチクラウド環境でサポートされるマシンタイプ](operating-systems-and-machine-types.md#supported-machine-types)」を参照してください。)
この概要は、*ウィジェット*と呼ばれる個別のレポートボックスを通じて提供されます。ウィジェットには、インタラクティブな円グラフやその他のグラフィックが備わっています。
**[開始する前に]**
ノードインサイトを確認するには、まず組織またはアカウントを Systems Manager 統合コンソールにオンボーディングする必要があります。詳細については、「[AWS Systems Manager を設定する](systems-manager-setting-up-console.md)」を参照してください。
オンボーディング後、[Systems Manager コンソール](https://console.aws.amazon.com/systems-manager/explorer)を開き、**[ノードインサイトの確認]** を選択します。
次の図は、**[ノードインサイトの確認]** ページで使用できる*ウィジェット*と呼ばれる個別のレポートボックスを示しています。
![\[Systems Manager の [ノードインサイトの確認] ページに表示されるノードデータ\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/SYS2-Dashboard-Nodes.png)
この表示では、以下の情報を提供するウィジェットがサポートされています。
**ノードの概要**
組織またはアカウント内で現在マネージドノードではない EC2 インスタンスの数と、組織またはアカウントのフリートに含まれるマネージドノードの数を示します。
**アンマネージドインスタンスとは**
マネージド EC2 インスタンスを停止すると、Systems Manager コンソールで「アンマネージド」としてレポートされます。これは、SSM Agent がサービスへのアクティブな接続を持っていないため、想定される動作です。
これは、AWS Config がインスタンスをアンマネージドとして定義する方法とは異なります。インスタンスが現在停止している場合、AWS Config は、インスタンスの SSM Agent と Systems Manager サービスとの間で「ハートビート」接続が最後に確立されたときのインスタンスのステータスを報告します。
インスタンスが再起動すると、Systems Manager サービスに自動的に再接続され、統合コンソールのステータスは 5 分以内に「マネージド」に復元されます。手動による介入は必要なく、インスタンスのすべての Systems Manager 設定は停止/開始サイクルの間も保持されます。
ただし、インスタンスが起動から数分後に「マネージド」としてまだ報告されていない場合、インスタンスは Systems Manager 管理用に正しく設定されていない可能性があります。この場合、診断を実行して、インスタンスがアンマネージド状態のままである理由を特定することをお勧めします。詳細については、「[Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復](remediating-unmanaged-instances.md)」を参照してください。
診断スキャンで問題を特定できない場合は、次のトピックを参照して、SSM Agent、AWS Identity and Access Management (IAM) ロール、および Systems Manager の前提条件の要件がすべて満たされていることを確認します。
+ [SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)
+ [Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)
+ [マネージドノードの可用性のトラブルシューティング](fleet-manager-troubleshooting-managed-nodes.md)
**マネージドノードのタイプ**
フリート内のマネージドノードのうち、EC2 インスタンスの数および他のサーバータイプの数を示します。他のサーバータイプには、自社設備内のサーバー (オンプレミスサーバー)、AWS IoT Greengrass コアデバイス、AWS IoT および非 AWS エッジデバイス、仮想マシン (VM) などがあります。仮想マシンには、他のクラウド環境の VM も含まれます。**[ノードタイプ]** グラフィックにカーソルを合わせると、**[ノードの探索]** ページの詳細情報へのリンクにアクセスできます。
ハイブリッド環境およびマルチクラウド環境での AWS のサポートの詳細については、「[ハイブリッドおよびマルチクラウド向けの AWS ソリューション](https://aws.amazon.com/hybrid-multicloud/)」を参照してください。
**「SSM Agent バージョン**」
フリートにおける AWS Systems Manager エージェント (SSM Agent) のインストールに関する情報を提供します。SSM Agent は、マネージドノードで実行される Amazon ソフトウェアです。SSM Agent により、Systems Manager はこれらのリソースを更新、管理、および設定できるようになります。エージェントは AWS クラウド 上の Systems Manager サービスからのリクエストを処理し、リクエストに指定されたとおりにそれらを実行します。
フリート内のマネージドノードについて、このウィジェットは、フリート内の SSM Agent のバージョンを最新のものから順に報告します。**SSM Agent バージョン**のグラフィックにカーソルを合わせると、**[ノードの探索]** ページの詳細情報へのリンクにアクセスできます。
SSM Agent の詳細については、「[「SSM Agent」 の使用](ssm-agent.md)」を参照してください。
**マネージドノードのオペレーティングシステム**
フリート内のマネージドノードにおける各オペレーティングシステムの割合の内訳を提供します。**オペレーティングシステム別のマネージドノード**のグラフィックにカーソルを合わせると、**[ノードの探索]** ページの詳細情報へのリンクにアクセスできます。
**[ノードインサイトの確認]** ページでウィジェットのレイアウトをカスタマイズするには、ドラッグアンドドロップ機能を使用したり、表示するウィジェットの削除や追加を行ったりします。
以下のトピックの情報は、Systems Manager のノードインサイトのウィジェットを操作するのに役立ちます。
**Topics**
+ [**[ノードインサイトの確認]** ページのウィジェットの追加または削除](review-node-insights-add-and-remove-widgets.md)
+ [**[ノードインサイトの確認]** ページのウィジェットの再配置](review-node-insights-rearrange-widgets.md)
# **[ノードインサイトの確認]** ページのウィジェットの追加または削除
ウィジェットを追加および削除することで、Systems Manager の **[ノードインサイトの確認]** ページでレイアウトをカスタマイズできます。
**注記**
デフォルトでは、このページには使用可能なすべてのウィジェットが表示されます。
****[ノードインサイトの確認]** ページのウィジェットを追加または削除する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. 左のナビゲーションで、**[ノードインサイトの確認]** を選択します。
1. 表示からウィジェットを削除するには、次の手順を実行します。
1. ウィジェットのメニューから [その他] (![\[The More options menu\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/more-options-menu-widgets.png)) を選択します。
1. [**Remove widget**] (ウィジェットの削除) を選択します。
1. 表示にウィジェットを追加するには、次の手順を実行します。
1. **ウィジェットの追加** を選択します。
1. **[ウィジェットの追加]** ペインで、表示に追加するウィジェットのドラッグハンドル (![\[The drag handle\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) をクリックして長押しします。
1. ウィジェットをドラッグして、メインペインにドロップします。
# **[ノードインサイトの確認]** ページのウィジェットの再配置
ウィジェットを再配置することで、**[ノードインサイトの確認]** ページのレイアウトをカスタマイズできます。
****[ノードインサイトの確認]** ページでウィジェットを再配置する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードインサイトの確認]** を選択します。
1. ウィジェットのレイアウトをカスタマイズするには、移動するウィジェットを選択します。ウィジェットのドラッグハンドル (![\[The drag handle\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) をクリックしたまま、新しい場所までドラッグします。
1. 再配置するウィジェットごとにこのプロセスを繰り返します。
新しいレイアウトが気に入らない場合は、**[デフォルトレイアウトにリセット]** を選択すると、すべてのウィジェットが元の場所に戻ります。
# ノードの探索
Systems Manager で **[ノードの探索]** ページを使用すると、フィルターに指定した条件に従って組織またはアカウント内のマネージドノードの詳細を確認できます。また、AWS 生成 AI ソリューションである Amazon Q Developer (Amazon Q) と Systems Manager との統合により、テキストプロンプトを使用して検索することもできます。
**[開始する前に]**
**[ノードの探索]** 機能を使用するには、まず組織またはアカウントを Systems Manager の統合コンソールにオンボーディングする必要があります。詳細については、「[組織用の Systems Manager 統合コンソールのセットアップ](systems-manager-setting-up-organizations.md)」を参照してください。
オンボーディング後、[Systems Manager コンソール](https://console.aws.amazon.com/systems-manager/)を開き、**[ノードの探索]** を選択します。
**注記**
ホームリージョンとは異なるリージョンに Resource Explorer 用のアグリゲーターインデックスを作成した場合は、Systems Manager により現在のインデックスが降格します。その後、Systems Manager によりホームリージョン内のローカルインデックスが新しいアグリゲーターインデックスとして昇格します。それまでの間、ホームリージョンのノードのみが表示されます。このプロセスが完了するまで最大 24 時間かかる場合があります。
**Topics**
+ [コンソールフィルターを使用したノードの探索](view-aggregated-node-details-console.md)
+ [Amazon Q でテキストプロンプトを使用したノードの探索](view-aggregated-node-details-Q.md)
+ [個々のノードの詳細の表示およびノードに対するアクションの実行](node-detail-actions.md)
+ [マネージドノードレポートのダウンロードまたはエクスポート](explore-nodes-download-report.md)
+ [ノードレポートのコンテンツと外観の管理](explore-nodes-manage-report-display.md)
# コンソールフィルターを使用したノードの探索
Systems Manager コンソールでは、以下のビューに従ってマネージドノードをグループ化できます。
------
#### [ All nodes (No filter) ]
組織またはアカウント内のすべてのマネージドノードをリストします。
![\[[ノードの探索] ページに示されたマネージドノードのリスト\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-explore-nodes-managed-nodes.png)
------
#### [ Node types ]
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとその他のマシンタイプのデータがタブに分かれて表示されます。こうしたマシンタイプには自社構築サーバー (オンプレミスサーバー)、AWS IoT Greengrass コアデバイス、AWS IoT デバイス、非 AWS エッジデバイス、他のクラウド環境の VM も含めた仮想マシン (VM) などがあります。
![\[ノードタイプタブに表示されるマネージドノードのリスト\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-explore-nodes-node-types.png)
------
#### [ Operating systems ]
**Amazon Linux** や **Microsoft Windows Server 2022 Datacenter** など、組織またはアカウント内のオペレーティングシステムタイプごとにタブが表示されます。各タブでは、*Amazon Linux 2* や *Amazon Linux 2023* など特定のバージョンのオペレーティングシステムのみを選択して、さらにリストをフィルタリングできます。
![\[OS タブに表示されるマネージドノードのリスト\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-explore-nodes-operating-system.png)
------
#### [ SSM Agent versions ]
フリート内のマネージドノードにインストールされている SSM Agent のバージョンごとにタブが表示されます。各タブでは、**Amazon Linux** や **Amazon Windows Server 2022 Datacenter** など特定のオペレーティングシステムのみを選択して、さらにリストをフィルタリングできます。
![\[エージェントタブに表示されるマネージドノードのリスト\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-explore-nodes-agent-versions.png)
------
またこれらのビューごとに、ノードステータス、AWS アカウント ID、組織単位 ID など特定のプロパティのノードのみを表示するように選択することで、レポートされるノードのリストをさらに絞り込むことができます。
使用可能なデータ列のうちどれを **[ノードの探索]** ページに表示するかを選択することで、レポート表示をカスタマイズできます。また、`CSV` 形式または `JSON` 形式でレポートをダウンロードしたり、レポートを `CSV` 形式で Amazon S3 にエクスポートしたりすることもできます。
**Topics**
+ [マネージドノードの概要のフィルタービューの選択](explore-nodes-filter-view.md)
# マネージドノードの概要のフィルタービューの選択
Systems Manager の **[ノードの探索]** ページでは、使用可能なさまざまなフィルタービューに応じて、フリートに関する集約データを表示できます。
**マネージドノードの概要のフィルタービューを選択する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードの探索]** を選択します。
1. **[フィルタービュー]** で、いずれかのフィルターオプションを選択し、必要に応じてレポートをさらに絞り込みます。
+ **[マネージドノード]** – 検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスで、プロパティと区切り記号を選択できます (`Node type = Managed EC2 instances` など)。
+ **[オペレーティングシステム]** – **[オペレーティングシステムバージョンをフィルタリング]** リストで、OS バージョン番号を選択できます。検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスで、プロパティと区切り文字を選択できます (`Node type = Managed EC2 instances` など)。
+ **[SSM Agent のバージョン]** – **[オペレーティングシステムをフィルタリング]** リストで、OS 名を選択できます。検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスで、プロパティと区切り文字を選択できます (`Node type = Managed EC2 instances` など)。
+ **[ノードタイプ]** – **[オペレーティングシステムをフィルタリング]** リストで、OS 名を選択できます。検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスで、プロパティと区切り文字を選択できます (`Node type = Managed EC2 instances` など)。
オプションでリストをフィルタリングした後、**[ノード ID]** 列で ID を選択することで、特定のマネージドノードの詳細を表示できます。その詳細ビューから、ノードに対してさまざまなアクションを実行できます。
# Amazon Q でテキストプロンプトを使用したノードの探索
Amazon Q Developer と Systems Manager との統合により、テキストプロンプトを使用して、マネージドノードについて生成 AI が作成した情報を表示できます。
Amazon Q Developer は、AWS アプリケーションの理解、構築、拡張、運用を支援する生成 AI 搭載の会話型アシスタントです。AWS での構築を加速するために、過不足がなく、実用的で参考になる回答が生成されるよう、Amazon Q を支えるモデルを高品質の AWS コンテンツで強化しています。詳細については、「*Amazon Q Developer ユーザーガイド*」の「[What is Amazon Q Developer?](https://docs.aws.amazon.com/amazonq/latest/aws-builder-use-ug/what-is.html)」を参照してください。
Systems Manager と Amazon Q との統合により、複数の AWS アカウントとリージョン全体にわたって大規模な分散環境をすばやく可視化して制御できます。自然言語クエリを使用してノードデータをすばやく検索し、問題を特定して迅速に対策を講じることができます。
ユーザーがマネージドノードまたはマネージドインスタンスについて自然言語で質問すると、Amazon Q は Systems Manager `ListNodes` アクションを使用し、ユーザーが入力したテキストに基づいてフィルターを作成して結果を取得します。
例えば、Amazon Q に以下のプロンプトを与えたとします。
**List my managed nodes running Red Hat Enterprise Linux 9.2**
Amazon Q は、リクエストに含めるフィルターを判断して、以下のようなクエリを実行します。
```
aws ssm list-nodes \
--filters Key=PlatformName,Values='Red Hat Enterprise Linux',Type=Equal Key=PlatformVersion,Values=9.2,Type=Equal
```
次に、Amazon Q はアカウント内の Red Hat Enterprise Linux インスタンスに関するレポートを生成して、インスタンスの数、その ID とリージョンなどの情報をリストします。
また、各インスタンスの詳細を JSON 形式のサマリーで表示できるほか、Systems Manager の **[ノードの探索]** ページに EC2 インスタンスまたはマネージドノードのリスト全体を表示するためのリンクを開くことができます。**[ノードの探索]** には、プロンプトに含めたフィルター条件に一致する結果が表示されます。それを基に、「[ノードの探索](view-aggregated-node-details.md)」で説明しているようにリクエストのフィルターを変更したり絞り込んだりできます。
**Topics**
+ [Amazon Q にフリートについてたずねる的確なプロンプトの作成方法](view-aggregated-node-details-Q-prompts.md)
+ [Amazon Q を使用したマネージドノードの探索](explore-managed-nodes-using-Q.md)
# Amazon Q にフリートについてたずねる的確なプロンプトの作成方法
Amazon Q に与える質問 (プロンプト) の質を上げれば、得られる結果の質も向上します。
**クエリプロンプトのヒント**
Amazon Q にフリートについてクエリする場合は、以下のヒントに留意してください。
1. 結果の精度を高めるには、プロンプトで単に「ノード」や「インスタンス」を使用するのではなく「マネージドノード」や「マネージドインスタンス」という語句を使用します。
1. AWS Organizations に設定されているように、*組織*に含まれる複数のアカウントを対象に結果をクエリするには、指定されたホームリージョンの委任管理者アカウントにログインする必要があります。
1. 委任管理者アカウントでは、組織全体にわたるノードとインスタンスについてたずねていることを Amazon Q が理解できる用語を使用します。特に、「組織内で」や「123456789012 というアカウントで」といった用語を使用すると効果的です。
**Topics**
+ [Amazon Q へのサンプルの質問](#sample-questions-Q)
+ [プロンプトでサポートされているオペレーティングシステムの名前とバージョン](#supported-os-names-Q)
## Amazon Q へのサンプルの質問
以下の表にサンプルの質問を挙げて、Amazon Q でよりよい結果を得るためのクエリの作成方法を示します。
[ListNodes](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListNodes.html) コマンドの実行時に Amazon Q が適用するフィルターの例も示します。これらは、プロンプトの内容から生成されます。
| 自然言語によるサンプルの質問 | Amazon Q が適用したフィルター |
| --- | --- |
| Show me my Windows managed nodes. | PlatformType = Windows
|
| List my managed instances in account 123456789012. | AccountId = 123456789012
|
| Show me all managed nodes running Amazon Linux 2 across my organization. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| Show me all managed instances running Microsoft Windows Server 2019 Datacenter in my organization. | PlatformName = Microsoft Windows Server 2019 Datacenter
|
| Can you show me all managed nodes with SSM Agent version 3.3.1142.0? | AgentType = amazon-ssm-agent
AgentVersion = 3.3.1142.0
|
| List all Amazon Linux 2 managed instances in account 123456789012 that have SSM Agent version 3.3.1230.0. | PlatformName = Amazon Linux
PlatformVersion = 2
AccountId = 123456789012
AgentType = amazon-ssm-agent
AgentVersion = 3.3.1230.0
|
| What Microsoft Windows Server 2012 R2 Enterprise managed nodes are running in the eu-central-1 region across my entire organization? | PlatformName = Microsoft Windows Server 2012 R2 Enterprise
Region = eu-central-1
|
| Show me all managed instances running Red Hat Linux 7 in ou-d6ty-gxdma6vm. | PlatformName = RHEL Linux
PlatformVersion = 7
OrganizationalUnitId = ou-d6ty-gxdma6vm
|
| What Ubuntu managed instances are in account 123456789012? | PlatformName = Ubuntu
AccountId = 123456789012
|
| List my Linux managed instances. | PlatformType = Linux
|
| Find my macOS managed nodes. | PlatformType = macOS
|
| Show me all versions of Amazon Linux managed nodes in my org. | PlatformName = Amazon Linux
|
| List managed nodes running Amazon Linux 2. | PlatformName = Amazon Linux
PlatformVersion = 2
|
| List the managed nodes with Ubuntu 16.04 in account 123456789012. | PlatformName = Ubuntu
PlatformVersion = 16.04
AccountId = 123456789012
|
| Find all managed nodes that have an SSM Agent version that is not 3.3.987.0. | AgentType = amazon-ssm-agent
AgentVersion != 3.3.987.0
|
| List all managed instances that are not running a Linux operating system. | PlatformType != Linux
|
## プロンプトでサポートされているオペレーティングシステムの名前とバージョン
Amazon Q にアカウント内のマネージドノードについてたずねるときは、オペレーティングシステムの名前を Systems Manager でのラベルのとおりに指定すると効果的です。また、バージョン番号を指定して結果をさらに絞り込むこともできます。例えば、以下の表に示すように、**macOS 14.5**、**Microsoft Windows Server 2019 Datacenter**、**AlmaLinux 9.2 through 9.4** といった名前を具体的に挙げて結果を求めることができます。
以下のリストは網羅的なものではなく、例として挙げているにすぎません。
**macOS**
| プラットフォーム名 | バージョン番号 |
| --- | --- |
| macOS | 13.2、13.4、13.7、14.1、14.5、14.6.1、15.0 |
**Server**
| リリース | バージョン番号 |
| --- | --- |
| Microsoft Windows Server 2012 R2 Datacenter | 6.3.9600 |
| Microsoft Windows Server 2012 R2 Standard | 6.3.9600 |
| Microsoft Windows Server 2012 Standard | 6.2.9200 |
| Microsoft Windows Server 2016 Datacenter | 該当なし |
| Microsoft Windows Server 2016 Standard | 10.0.14393 |
| Microsoft Windows Server 2019 Datacenter | 該当なし |
| Microsoft Windows Server 2019 Standard | 該当なし |
| Microsoft Windows Server 2022 Datacenter | 該当なし |
| Microsoft Windows Server 2022 Standard | 10.0.20348 |
**Linux**
| プラットフォーム名 | バージョン番号 |
| --- | --- |
| AlmaLinux | 8.10、9.2、9.3、9.4 |
| Amazon Linux 2 | 2.0 以降 |
| Amazon Linux 2023 | 2,023.0.20230315.0 以降 |
| Bottlerocket | 1.14.3、1.16.1、1.18.0、1.19.1、1.19.2、1.19.5、1.20.0、1.20.1、1.20.2、1.20.3、1.20.5、1.21.1、1.23.0、1.24.0、1.24.1、1.25.0、1.26.1、 |
| CentOS Stream | 9 |
| Debian GNU/Linux | 11～12 |
| Oracle Linux Server | 7.8、8.2、8.3、8.8、8.9、8.10、9.4 |
| Red Hat Enterprise Linux | 8.2、8.3、8.4、8.5、8.6、8.7、8.8、8.9、8.10、9.2、9.3、9.4 |
| Red Hat Enterprise Linux サーバー | 17.3、7.6、7.7、7.8、7.9 |
| Rocky Linux | 8.6、8.7、8.8、8.9、8.10、9.1、9.2、9.3、9.4 |
| Ubuntu Server | 16.04、18.04、20.04、22.04、24.04 |
# Amazon Q を使用したマネージドノードの探索
Systems Manager と Amazon Q Developer の統合により、Amazon Q インターフェイスが使用可能な AWS マネジメントコンソールの任意の場所から、フリート内のマネージドノードについて質問できます。
Amazon Q の操作方法の詳細については、「*Amazon Q Developer ユーザーガイド*」の「[Chatting with Amazon Q Developer about AWS](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html)」を参照してください。
**Amazon Q を使用してマネージドノードを探索する手順**
1. AWS マネジメントコンソールの任意の場所から、Amazon Q アイコン (![\[The Amazon Q icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/q-icon-white.png)) を選択します。
1. Amazon Q ペインの下部にあるプロンプトフィールドで、アカウントまたは組織内のマネージドノードについて質問します。
**ヒント**
効果的なプロンプトの作成方法に関するヒントは、「[Amazon Q にフリートについてたずねる的確なプロンプトの作成方法](view-aggregated-node-details-Q-prompts.md)」の情報を参照してください。
1. 特定のノードに関する情報を調査するか、**[AWS Systems Manager コンソールを開く]** を選択して探索を続行します。
# 個々のノードの詳細の表示およびノードに対するアクションの実行
Systems Manager の **[ノードの探索]** ページのリストから個々のノードを選択して、マシンに関する包括的な詳細を表示したり、ノードに対してさまざまなアクションを実行したりできます。詳細ページの **[一般]** ページには、ノードに関する包括的な情報が表示されます。
**個々のノードの詳細を表示し、ノードに対してアクションを実行する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードの探索]** を選択します。
1. (オプション)「[マネージドノードの概要のフィルタービューの選択](explore-nodes-filter-view.md)」の手順に従って、組織またはアカウントに表示されるマネージドノードのリストを絞り込みます。
1. **[ノード ID]** 列で、ノードのリンクされた ID を選択します。
1. ノードの詳細を表示するには、左側のナビゲーションの **[プロパティ]** リストで、詳細を表示するプロパティを選択します。
+ **[タグ]** – ノードに適用されているタグのリストを表示します。タグを追加または削除することもできます。
+ **[インベントリ]** – インベントリタイプ (**[AWS:Application]** や **[AWS:Network]** など) を選択して、ノードのインベントリの詳細を表示します。
+ **[関連付け]** – ノードに適用されているすべての State Manager 関連付けに関する詳細 (ステータスや関連付けられている SSM ドキュメント名など) を表示します。
+ **[パッチ]** – ノードのパッチとパッチステータスに関する概要情報を表示します。
+ **[設定コンプライアンス]** — ノードのコンプライアンスの詳細 (コンプライアンスステータスやコンプライアンス問題の重要度など) を表示します。
タブの詳細のさらなる情報については、「[統合コンソールとは](systems-manager-unified-console.md)」を参照してください。
1. ノードに対してアクションを実行するには、**[ノードアクション]** メニューで次のオプションを使用します。
**注記**
これらのアクションは、現在作業している AWS アカウントおよびリージョンのマネージドノードに対してのみ使用できます。他のアカウントまたはリージョンのマネージドノードの場合は、そのノードに対するアクセス権を持っていれば、代わりに **[プロパティ]** リストにアクセスできます。
+ **[接続、ターミナルセッションを開始する]** — [AWS Systems Manager Session Manager](session-manager.md) を使用してノードに接続します。
+ **ツール**
+ **[ファイルシステムを表示]** – ノードのディレクトリ構造のコンテンツを参照します。ディレクトリを追加、名前変更、削除します。ファイルを切り取り/コピーして貼り付けます。
+ **[パフォーマンスカウンタを表示]** – ノードに関するパフォーマンス情報 (CPU 使用率、ネットワークトラフィック、その他の使用率タイプなど) を表示します。
+ **[プロセスを管理]** – ノードのリソース使用状況に関する情報を表示します。ノード上でプロセスを開始または停止します。
+ **[ユーザーとグループを管理]** – ノード上のユーザーアカウントおよびユーザーグループを表示、追加、または削除します。
+ **[実行コマンドを実行]** – [AWS Systems Manager Run Command](run-command.md)を使用してノードの設定を管理します。Run Command は [Systems Manager ドキュメント](documents.md)を使用して、アプリケーションの更新、Linux シェルスクリプトや Windows PowerShell コマンドの実行など、オンデマンドの変更を実行します。
+ **[パッチノード]** – [AWS Systems Manager Patch Manager](patch-manager.md) の **[今すぐパッチ適用]** 機能を使用して、コンソールからノードに対するオンデマンドパッチ適用オペレーションを実行します。
**注記**
上記のタスクは、左側のナビゲーションにある **[ツール]** メニューから開始することもできます。
+ **ノード設定**
+ **[タグの追加]** — ノードに追加のタグキーと値のペアを適用します。
+ **[ノードユーザーパスワードのリセット]** – ノード上の指定されたユーザー用に新しいパスワードを設定します。
+ **[IAM ロールを変更]** – ノードに関連付けられている IAM ロールを変更します。ノードにアタッチする新しい IAM ロールを作成します。
# マネージドノードレポートのダウンロードまたはエクスポート
Systems Manager の **[ノードの探索]** 機能を使用して、Systems Manager コンソールで、AWS 組織またはアカウント内のマネージドノードのフィルタリングされた/フィルタリングされていないリストを表示できます。データをオフラインで表示したり、別のアプリケーションで処理したりする場合は、レポートを `CSV` ファイルまたは `JSON` ファイルとして保存できます。
レポートのサイズに応じて、レポートをローカルマシンにダウンロードするか、Amazon S3 バケットにエクスポートするかを求められます。S3 バケットに保存されるレポートは `CSV` 形式のみです。
**マネージドノードレポートをダウンロードまたはエクスポートする手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードの探索]** を選択します。
1. (オプション)「[マネージドノードの概要のフィルタービューの選択](explore-nodes-filter-view.md)」の手順に従って、組織またはアカウントに表示されるマネージドノードのリストを絞り込みます。
1. **[レポート]** (![\[The download report icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/download-arrow-icon.png)) を選択します。
1. **[レポートのダウンロード]** ダイアログボックスが表示された場合は、以下の手順を実行します。
1. **[ファイル名]** にファイルの名前を入力します。レポートの範囲を表す名前 (`all-organization-nodes` や `ec2-instances-out-of-date-agent` など) を指定することをお勧めします。
1. **[含まれる列]** で、すべての使用可能なノード詳細の列を含めるか、現在の表示用に選択した列のみを含めるかを指定します。
**ヒント**
レポート表示の列の管理については、「[ノードレポートのコンテンツと外観の管理](explore-nodes-manage-report-display.md)」を参照してください。
1. **[ファイル形式]** で、ファイルの使用方法に応じて **[CSV]** または **[JSON]** を選択します。
1. `CSV` ファイルに列見出し行を含める場合は、**[スプレッドシートの見出し]** で **[列名の行を含める]** を選択します。
1. [**ダウンロード**] を選択します。
レポートは、ブラウザの設定に応じて、デフォルトのダウンロード場所に保存されます。
1. **[Amazon S3 にエクスポート]** ダイアログボックスが表示された場合は、以下の手順を実行します。
1. **[S3 URI]** に、レポートのエクスポート先のバケットの URI を入力します。
**ヒント**
Amazon S3 コンソールでバケットのリストを表示するには、**[表示]** を選択します。アカウント内のバケットのリストから選択するには、**[S3 を参照]** を選択します。
1. **[承認方法]** で、レポートをバケットにエクスポートするためのアクセス許可の付与に使用するサービスロールを指定します。
Systems Manager にロールを作成させることを選択した場合は、Systems Manager によって、オペレーションに必要なすべてのアクセス許可と信頼ステートメントが提供されます。
独自のロールを使用または作成する場合は、そのロールに必要なアクセス許可と信頼ステートメントを含める必要があります。このロールの作成の詳細については、「[診断レポートを S3 にエクスポートするカスタムサービスロールの作成](create-s3-export-role.md)」を参照してください。
1. [**Submit**] を選択します。
# 診断レポートを S3 にエクスポートするカスタムサービスロールの作成
Systems Manager の **[ノードの探索]** ページで、AWS 組織やアカウントのマネージドノードのフィルタリングされた/フィルタリングされていないリストを表示している場合、そのリストをレポートとして `CSV` ファイル形式で Amazon S3 バケットにエクスポートできます。
そのためには、オペレーションに必要なアクセス許可と信頼ポリシーを持つサービスロールを指定する必要があります。レポートのダウンロードプロセス中に Systems Manager によって自動的にロールが作成されるようにすることもできます。オプションで、ユーザー自身がロールおよびそのロールに必要なポリシーを作成することもできます。
**診断レポートを S3 にエクスポートするカスタムサービスロールを作成する手順**
1. 「*IAM ユーザーガイド*」の「[JSON エディターを使用したポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)」の手順を実行します。
+ ポリシーコンテンツとして以下を使用します。その際に、*プレースホルダー値*は独自の情報に置き換えてください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketAcl",
"s3:ListBucket",
"s3:PutLifecycleConfiguration",
"s3:GetLifecycleConfiguration"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:ListNodes"
],
"Resource": "*"
}
]
}
```
------
+ 次のステップで簡単にわかるように、ポリシーに名前を付けます。
1. 「*IAM ユーザーガイド*」の「[カスタム信頼ポリシーを使用した IAM ロールの作成 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)」の手順を実行します。
+ ステップ 4 では、次の信頼ポリシーを入力します。その際に、*プレースホルダー値*は独自の情報に置き換えてください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMAssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
1. ステップ 10 では、**[ステップ 2: アクセス許可を追加する]** を選択し、前のステップで作成したポリシーの名前を選択します。
ロールを作成すると、「[マネージドノードレポートのダウンロードまたはエクスポート](explore-nodes-download-report.md)」の手順を実行する際にそのロールを選択できるようになります。
# ノードレポートのコンテンツと外観の管理
Systems Manager の **[ノードの探索]** 機能を使用して、Systems Manager コンソールで、AWS 組織またはアカウント内のマネージドノードのフィルタリングされた/フィルタリングされていないリストを表示できます。ノードのリストに含めるフィールドとして、**[ノード ID]**、**[オペレーティングシステム名]**、**[リージョン]** など、多数のフィールドから選択できます。また、リストやレポートの列の順序を変更したり、コンソールでのリストの表示方法を変更したりすることもできます。
**ノードレポートのコンテンツと外観を管理する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードの探索]** を選択します。
1. **[ノード]** 領域で、設定の歯車アイコン (![\[The preferences gear icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/preferences-icon.png)) を選択します。
1. **[設定]** ダイアログボックスで、以下の操作を実行します。
1. **[ページサイズ]** で、各コンソールビュー表示に含める行数 (**10**、**25**、または **50**) を選択します。
1. **[改行]** でボックスを選択すると、セルのすべてのコンテンツが使用可能な列幅で表示されます。
1. **[ストライプ行]** でボックスを選択すると、背景が透明な行と網掛けの行が交互に表示されます。
1. **[表示するコンテンツを選択]** で、以下の操作を実行します。
+ リスト表示とレポートの個々の列のオン/オフを設定します。
+ 列の順序を変更するには、列名のドラッグハンドル (![\[The drag handle\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/drag-handle-dashboard.png)) をクリックしたまま、リスト内で上下にドラッグします。
1. [**確認**] を選択してください。
# Systems Manager を使用したジャストインタイムノードアクセス
Systems Manager では、*ジャストインタイム*アクセスをサポートすることで、ノードのセキュリティを強化できます。ジャストインタイムノードアクセスを使用すると、ユーザーがノードへの期限付きの一時的なアクセスをリクエストできるようになり、アクセスが本当に必要な場合にのみリクエストを承認できます。そのため、IAM ポリシーで管理するノードへの長期的なアクセスを付与する必要がなくなります。また、Systems Manager では Windows Server ノードへの RDP セッションを記録できるので、コンプライアンス要件を満たす、根本原因を分析するといったことができるようになります。ジャストインタイムノードアクセスを使用するには、Systems Manager 統合コンソールをセットアップする必要があります。
ジャストインタイムノードアクセスを使用するときは、許可したユーザーのみがノードへのアクセスリクエストを送信できるようにきめ細かく IAM ポリシーを作成します。次に、*承認ポリシー*を作成して、ノードへの接続に必要な承認を定義します。ジャストインタイムノードアクセス用のポリシーには、*自動承認*ポリシーと*手動承認*ポリシーがあります。自動承認ポリシーでは、ユーザーが自動的に接続できるノードを定義します。手動承認ポリシーでは、指定したノードにアクセスするために必要な手動承認の数とレベルを定義します。このほか、*アクセス拒否*ポリシーも作成できます。アクセス拒否ポリシーを使用すると、指定したノードへのアクセスリクエストの自動承認を明示的に防ぐことができます。アクセス拒否ポリシーは、AWS Organizations 組織内のすべてのアカウントに適用されます。自動承認ポリシーと手動承認ポリシーは、作成元の AWS アカウントと AWS リージョンにのみ適用されます。
ノードに接続しようとすると、ユーザーはノードにアクセスする理由を入力するように求められます。次に、承認ポリシーが評価されます。ポリシーに応じて、ユーザーがターゲットノードに自動的に接続するか、Systems Manager がリクエスタに代わって手動承認リクエストを自動的に作成します。その後、ノードに適用される手動承認ポリシーに定められた承認者にアクセスリクエストに関する通知が届き、承認者はリクエストを承認または拒否できます。承認者とリクエスタへの通知には E メールを使用できるほか、チャットアプリケーションを Slack や Microsoft Teams と統合していれば Amazon Q Developer からも行えます。Systems Manager がリクエストされたノードへのアクセスを許可するのは、指定された承認者から必要なすべての承認が得られたときだけです。必要なすべての承認が得られたら、ユーザーは承認ポリシーに指定されているアクセス時間帯が終了するまで必要な数だけノードへのセッションを開始できます。Systems Manager は、ジャストインタイムノードアクセスセッションを自動的には終了しません。セッション設定で*最大セッション期間*と*アイドルセッションタイムアウト*の値を指定するのがベストプラクティスです。これらの値を設定すると、ユーザーは承認されたアクセス時間帯を超えてノードに接続したままにすることができなくなります。
重要度の高いデータがあるノードは保護し、重要度の低いノードは介入なしでユーザーの接続を許可するように、承認ポリシーをいくつか組み合わせて使用することをお勧めします。例えば、データベースノードへのアクセスリクエストには手動承認を義務づけ、永続的でないプレゼンテーション層のノードへのセッションは自動承認します。
Systems Manager は、IAM アイデンティティセンターまたは IAM とフェデレートされたユーザーに対するジャストインタイムノードアクセスをサポートしています。アクセスリクエストを送信するときに、フェデレーションユーザーはターゲットノード、およびノードへの接続が必要な理由を指定します。Systems Manager は、組織の承認ポリシーに定義されているパラメータとユーザーの ID を比較します。自動承認ポリシーの条件が満たされるか、承認者が手動で承認を与えると、リクエスタはターゲットノードに接続できます。ユーザーが承認されたノードへの接続を試みると、Systems Manager は一時的なトークンを作成し、それを使用してセッションを確立します。
Systems Manager サービスがアクセスリクエストの認証とセッションの確立を担当するため、IAM ポリシーを使用してノードへのアクセスを管理する必要はありません。Systems Manager ではジャストインタイムノードアクセスを使用することで、Zero Standing Privileges に近いアプローチを取ることができます。ユーザーにノードへの永続的なアクセス許可を与えてセッションの開始を許可するのではなく、アクセスリクエストの作成を許可するだけでよくなります。コンプライアンス要件の遵守を支援するため、Systems Manager はすべてのアクセスリクエストを 1 年間保持します。Systems Manager はこのほか、ジャストインタイムノードアクセスに関する EventBridge イベントを発行して、アクセスリクエストの失敗に備え、手動承認のアクセスリクエストのステータスを更新できるようにします。詳細については、「[Amazon EventBridge を使用して Systems Manager イベントをモニタリングする](monitoring-eventbridge-events.md)」を参照してください。
**Topics**
+ [Systems Manager でジャストインタイムアクセスをセットアップする](systems-manager-just-in-time-node-access-setting-up.md)
+ [ジャストインタイムノードアクセスセッションを開始する](systems-manager-just-in-time-node-access-start-session.md)
+ [ジャストインタイムアクセスリクエストを管理する](systems-manager-just-in-time-node-access-manage-requests.md)
+ [Session Manager からジャストインタイムノードアクセスに移行する](systems-manager-just-in-time-node-access-moving-from-session-manager.md)
+ [Systems Manager でジャストインタイムアクセスを無効にする](systems-manager-just-in-time-node-access-disable.md)
+ [ジャストインタイムノードアクセスに関するよくある質問](just-in-time-node-access-faq.md)
# Systems Manager でジャストインタイムアクセスをセットアップする
Systems Manager でジャストインタイムノードアクセスをセットアップするには、複数のステップが必要です。まず、ジャストインタイムノードアクセスをセットアップする*ターゲット*を選択します。ターゲットは、AWS Organizations 組織単位 (OU) と AWS リージョンで構成されています。デフォルトでは、Systems Manager 統合コンソールをセットアップするときに選択したのと同じターゲットがジャストインタイムノードアクセスにも選択されます。ジャストインタイムノードアクセスは、同じすべてのターゲットにセットアップすることも、Systems Manager 統合コンソールをセットアップするときに指定したターゲットのサブセットにセットアップすることもできます。Systems Manager 統合コンソールをセットアップするときに選択されなかったターゲットを新たに追加する機能はサポートされていません。
次に、*承認ポリシー*を作成して、どのようなときにノード接続に手動承認が必要になるのか、どのようなときにノード接続を自動的に承認するのかを決定します。承認ポリシーは、組織内の各アカウントで管理されます。また、委任された管理者アカウントからのポリシーを共有して、特定のノードへの接続の自動承認を明示的に拒否することもできます。
**注記**
ジャストインタイムノードアクセスをセットアップしても、Session Manager に対して設定した既存の IAM ポリシーや設定には影響しません。ユーザーがノードへの接続を試みたときにジャストインタイムノードアクセスのみが使用されるようにするには、IAM ポリシーから `StartSession` API アクションへのアクセス許可を削除する必要があります。ジャストインタイムノードアクセスをセットアップしたら、Session Manager に対するアクセス許可を削除する前に、ユーザーとノードのサブセットで承認ポリシーをテストして、ポリシーが想定通りに機能していることを確認することをお勧めします。
**認証のサポート**
ジャストインタイムノードアクセスに使用される認証サポートについては、次の詳細に注意してください。
+ ジャストインタイムノードアクセスでは、リモートデスクトップで Windows Server インスタンスに接続する場合、シングルサインオン認証タイプはサポートされません。
+ AWS Security Token Service (AWS STS) の一時的なセキュリティ認証情報 `AssumeRole` のみがサポートされます。詳細については、*IAM ユーザーガイド*にある下記のトピックを参照してください。
+
+ [IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS STS 認証情報を比較する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)
+ [一時的なセキュリティ認証情報をリクエストする](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)
以下の IAM ポリシーは、ユーザーが Systems Manager でノードへのジャストインタイムノードアクセスリクエストを作成することを管理および許可するために必要なアクセス許可の概要を示しています。Systems Manager でジャストインタイムノードアクセスを使用するために必要なアクセス許可が付与されていることを確認したら、セットアッププロセスを続行できます。各*リソースプレースホルダーの例*をユーザー自身の情報に置き換えます。
## ジャストインタイムノードアクセスを有効にするための IAM ポリシー
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:CreateConfigurationManager",
"ssm-quicksetup:DeleteConfigurationManager",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:GetServiceSettings",
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:ListTagsForResource",
"ssm-quicksetup:TagResource",
"ssm-quicksetup:UntagResource",
"ssm-quicksetup:UpdateConfigurationDefinition",
"ssm-quicksetup:UpdateConfigurationManager",
"ssm-quicksetup:UpdateServiceSettings"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:DescribeStackSetOperation",
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackResources",
"cloudformation:ListStackSetOperations",
"cloudformation:ListStackInstances",
"cloudformation:DescribeStackSet",
"cloudformation:ListStackSets",
"cloudformation:DescribeStackInstance",
"cloudformation:DescribeOrganizationsAccess",
"cloudformation:ActivateOrganizationsAccess",
"cloudformation:GetTemplate",
"cloudformation:ListStackSetOperationResults",
"cloudformation:DescribeStackEvents",
"cloudformation:UntagResource",
"ssm:DescribeAutomationExecutions",
"ssm:GetAutomationExecution",
"ssm:ListAssociations",
"ssm:DescribeAssociation",
"ssm:GetDocument",
"ssm:ListDocuments",
"ssm:DescribeDocument",
"ssm:GetOpsSummary",
"organizations:DeregisterDelegatedAdministrator",
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators",
"organizations:ListRoots",
"organizations:ListParents",
"organizations:ListOrganizationalUnitsForParent",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAWSServiceAccessForOrganization",
"iam:ListRoles",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:CreatePolicy",
"cloudformation:TagResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:RollbackStack",
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack"
],
"Resource": [
"arn:aws:cloudformation:*:*:stack/StackSet-AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:stack/AWS-QuickSetup-*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stack/StackSet-SSMQuickSetup"
]
},
{
"Sid": "StackSetOperations",
"Effect": "Allow",
"Action": [
"cloudformation:CreateStackSet",
"cloudformation:UpdateStackSet",
"cloudformation:DeleteStackSet",
"cloudformation:DeleteStackInstances",
"cloudformation:CreateStackInstances",
"cloudformation:StopStackSetOperation"
],
"Resource": [
"arn:aws:cloudformation:*:*:stackset/AWS-QuickSetup-JITNA*",
"arn:aws:cloudformation:*:*:type/resource/*",
"arn:aws:cloudformation:*:*:stackset-target/AWS-QuickSetup-JITNA*:*"
]
},
{
"Sid": "IamRolesMgmt",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRolePolicy",
"iam:ListRolePolicies"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
]
},
{
"Sid": "IamPassRole",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/AWS-QuickSetup-JITNA*",
"arn:aws:iam::*:role/service-role/AWS-QuickSetup-JITNA*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "SSMAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/AWS-EnableExplorer",
"arn:aws:ssm:us-east-1:111122223333:automation-execution/*"
]
},
{
"Sid": "SSMAssociationPermissions",
"Effect": "Allow",
"Action": [
"ssm:DeleteAssociation",
"ssm:CreateAssociation",
"ssm:StartAssociationsOnce"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:association/*"
},
{
"Sid": "SSMResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:CreateResourceDataSync",
"ssm:UpdateResourceDataSync"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:resource-data-sync/AWS-QuickSetup-*"
},
{
"Sid": "ListResourceDataSync",
"Effect": "Allow",
"Action": [
"ssm:ListResourceDataSync"
],
"Resource": "*"
},
{
"Sid": "CreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"accountdiscovery.ssm.amazonaws.com",
"ssm.amazonaws.com",
"ssm-quicksetup.amazonaws.com",
"stacksets.cloudformation.amazonaws.com"
]
}
},
"Resource": "*"
},
{
"Sid": "CreateStackSetsServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/stacksets.cloudformation.amazonaws.com/AWSServiceRoleForCloudFormationStackSetsOrgAdmin"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-JustInTimeAccessDenyAccessOrgPolicy"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "IdentityCenterPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## ジャストインタイムノードアクセスを設定するための IAM ポリシー
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:UpdateDocumentDefaultVersion",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:DeleteDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/SSM-JustInTimeAccessTokenRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"justintimeaccess.ssm.amazonaws.com"
]
}
}
},
{
"Sid": "AllowAccessRequestOpsItemOperations",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem",
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:DeleteOpsItem",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerPreferencesOperation",
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "Session"
}
}
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:TerminateSession"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:UpdateConnectionRecordingPreferences",
"ssm-guiconnect:GetConnectionRecordingPreferences",
"ssm-guiconnect:DeleteConnectionRecordingPreferences"
],
"Resource": "*"
},
{
"Sid": "AllowRDPConnectionRecordingKmsOperation",
"Effect": "Allow",
"Action": [
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"StringLike": {
"kms:ViaService": "ssm-guiconnect.*.amazonaws.com"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
},
{
"Sid": "AllowFleetManagerOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
},
{
"Sid": "SNSTopicManagement",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:SetTopicAttributes"
],
"Resource": [
"arn:aws:sns:us-east-1:111122223333:SSM-JITNA*"
]
},
{
"Sid": "SNSListTopics",
"Effect": "Allow",
"Action": [
"sns:ListTopics"
],
"Resource": "*"
},
{
"Sid": "EventBridgeRuleManagement",
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets"
],
"Resource": [
"arn:aws:events:us-east-1::rule/SSM-JITNA*"
]
},
{
"Sid": "ChatbotSlackManagement",
"Effect": "Allow",
"Action": [
"chatbot:CreateSlackChannelConfiguration",
"chatbot:UpdateSlackChannelConfiguration",
"chatbot:DescribeSlackChannelConfigurations",
"chatbot:DescribeSlackWorkspaces",
"chatbot:DeleteSlackChannelConfiguration",
"chatbot:RedeemSlackOauthCode",
"chatbot:DeleteSlackWorkspaceAuthorization",
"chatbot:GetSlackOauthParameters"
],
"Resource": "*"
},
{
"Sid": "ChatbotTeamsManagement",
"Effect": "Allow",
"Action": [
"chatbot:ListMicrosoftTeamsChannelConfigurations",
"chatbot:CreateMicrosoftTeamsChannelConfiguration",
"chatbot:UpdateMicrosoftTeamsChannelConfiguration",
"chatbot:ListMicrosoftTeamsConfiguredTeams",
"chatbot:DeleteMicrosoftTeamsChannelConfiguration",
"chatbot:RedeemMicrosoftTeamsOauthCode",
"chatbot:DeleteMicrosoftTeamsConfiguredTeam",
"chatbot:GetMicrosoftTeamsOauthParameters",
"chatbot:TagResource"
],
"Resource": "*"
},
{
"Sid": "SSMEmailSettings",
"Effect": "Allow",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:GetServiceSetting"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/email-role-mapping",
"arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/access-request/enabled-email-notifications"
]
},
{
"Sid": "AllowViewingJitnaCloudWatchMetrics",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/SSM/JustInTimeAccess"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration",
"ssm-quicksetup:GetConfigurationManager"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "ManualPolicy",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"ssm:GetServiceSetting",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "SessionPreference",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "AllowIamListForKMS",
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": "arn:aws:iam::111122223333:user/*"
},
{
"Sid": "KMSPermission",
"Effect": "Allow",
"Action": [
"kms:TagResource",
"kms:ListAliases",
"kms:CreateAlias"
],
"Resource": "*"
},
{
"Sid": "KMSCreateKey",
"Effect": "Allow",
"Action": [
"kms:CreateKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"SystemsManagerJustInTimeNodeAccessManaged"
]
}
}
},
{
"Sid": "AllowIamRoleForChatbotAction",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/role name",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"chatbot.amazonaws.com"
]
}
}
},
{
"Sid": "AllowIamServiceRoleForChat",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/management.chatbot.amazonaws.com/AWSServiceRoleForAWSChatbot"
},
{
"Sid": "CloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:111122223333:log-group::log-stream:"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"sso-directory:SearchUsers",
"sso-directory:SearchGroups",
"identitystore:DescribeGroup",
"identitystore:DescribeUser"
],
"Resource": "*"
}
]
}
```
------
## アクセスリクエスト承認者用の IAM ポリシー
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessRequestDescriptions",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents"
],
"Resource": "*"
},
{
"Sid": "AllowGetSpecificAccessRequest",
"Effect": "Allow",
"Action": [
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:opsitem/*"
},
{
"Sid": "AllowApprovalRejectionSignal",
"Effect": "Allow",
"Action": [
"ssm:SendAutomationSignal"
],
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesCrudOperations",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "IDCPermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup",
"identitystore:ListGroupMembershipsForMember"
],
"Resource": "*"
}
]
}
```
------
## ジャストインタイムノードアクセスユーザー用の IAM ポリシー
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowJITNAOperations",
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken"
],
"Resource": "*"
},
{
"Sid": "AllowOpsItemCreationAndRetrieval",
"Effect": "Allow",
"Action": [
"ssm:CreateOpsItem",
"ssm:GetOpsItem"
],
"Resource": "arn:aws:ssm:*:*:opsitem/*"
},
{
"Sid": "AllowListAccessRequests",
"Effect": "Allow",
"Action": [
"ssm:DescribeOpsItems",
"ssm:GetOpsSummary",
"ssm:ListOpsItemEvents",
"ssm:DescribeSessions"
],
"Resource": "*"
},
{
"Sid": "RequestManualApprovals",
"Action": "ssm:StartAutomationExecution",
"Effect": "Allow",
"Resource": "arn:aws:ssm:*:*:document/*",
"Condition": {
"StringEquals": {
"ssm:DocumentType": "ManualApprovalPolicy"
}
}
},
{
"Sid": "StartManualApprovalsAutomationExecution",
"Effect": "Allow",
"Action": "ssm:StartAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*"
},
{
"Sid": "CancelAccessRequestManualApproval",
"Effect": "Allow",
"Action": "ssm:StopAutomationExecution",
"Resource": "arn:aws:ssm:*:*:automation-execution/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/SystemsManagerJustInTimeNodeAccessManaged": "true"
}
}
},
{
"Sid": "DescribeEC2Instances",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "AllowListSSMManagedNodesAndTags",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceInformation",
"ssm:ListTagsForResource"
],
"Resource": "*"
},
{
"Sid": "QuickSetupConfigurationManagers",
"Effect": "Allow",
"Action": [
"ssm-quicksetup:ListConfigurationManagers",
"ssm-quicksetup:GetConfigurationManager",
"ssm-quicksetup:ListConfigurations",
"ssm-quicksetup:ListQuickSetupTypes",
"ssm-quicksetup:GetConfiguration"
],
"Resource": "*"
},
{
"Sid": "AllowSessionManagerOperations",
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "AllowRDPOperations",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:ListConnections",
"ssm:GetConnectionStatus"
],
"Resource": "*"
},
{
"Sid": "QuickSetupDeployments",
"Effect": "Allow",
"Action": [
"cloudformation:ListStacks",
"cloudformation:DescribeStacks",
"organizations:DescribeOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
},
{
"Sid": "AllowSsmJitnaPoliciesReadOnly",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": [
"arn:aws:ssm:*:111122223333:document/*"
],
"Condition": {
"StringEquals": {
"ssm:DocumentType": [
"ManualApprovalPolicy",
"AutoApprovalPolicy"
]
}
}
},
{
"Sid": "AllowSsmJitnaPoliciesListOperations",
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:ListDocumentVersions"
],
"Resource": "*"
},
{
"Sid": "ExploreNodes",
"Effect": "Allow",
"Action": [
"ssm:ListNodesSummary",
"ssm:ListNodes",
"ssm:DescribeInstanceProperties"
],
"Resource": "*"
},
{
"Sid": "IdentityStorePermissions",
"Effect": "Allow",
"Action": [
"sso:DescribeRegisteredRegions",
"sso:ListDirectoryAssociations",
"identitystore:GetUserId",
"identitystore:DescribeUser",
"identitystore:DescribeGroup"
],
"Resource": "*"
}
]
}
```
------
**注記**
承認ポリシーを作成、更新、または削除する API オペレーションへのアクセスを制限するには、`AutoApprovalPolicy` と `ManualApprovalPolicy ` のドキュメントタイプに対して `ssm:DocumentType` 条件キーを使用します。`StartAccessRequest` と `GetAccessToken` のどちらの API オペレーションも、以下のグローバルコンテキストキーをサポートしません。
`aws:SourceVpc`
`aws:SourceVpce`
`aws:VpcSourceIp`
`aws:UserAgent`
`aws:MultiFactorAuthPresent`
Systems Manager の条件コンテキストキーの詳細については、「*サービス許可リファレンス*」の「[Condition keys for AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html#awssystemsmanager-policy-keys)」を参照してください。
以下の手順では、ジャストインタイムノードアクセスの最初のセットアップステップを完了する方法について説明します。
**ジャストインタイムノードアクセスをセットアップするには**
1. 組織用の Systems Manager 委任管理者アカウントにログインします。
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ジャストインタイムノードアクセス]** を選択します。
1. **[新しいエクスペリエンスを有効にする]** を選択します。
1. ジャストインタイムノードアクセスを有効にするリージョンを選択します。デフォルトでは、Systems Manager 統合コンソールをセットアップするときに選択したのと同じリージョンがジャストインタイムノードアクセスにも選択されます。Systems Manager 統合コンソールをセットアップするときに選択されなかったリージョンを新たに選択する機能はサポートされていません。
1. **[ジャストインタイムノードアクセスを有効にする]** を選択します。
この機能を有効にしてから 30 日間、ジャストインタイムノードアクセスは無料で使用できます。30 日間のトライアル期間が過ぎると、ジャストインタイムノードアクセスの使用には料金がかかります。詳細については、[AWS Systems Manager 料金](https://aws.amazon.com/systems-manager/pricing/)を参照してください。
# ノードの承認ポリシーを作成する
承認ポリシーでは、ユーザーがノードにアクセスするために必要な承認を定義します。ジャストインタイムノードアクセスでは、IAM ポリシーを通じたノードへの長期的なアクセス許可が不要になるため、ノードへのアクセスを許可する承認ポリシーを作成する必要があります。ノードに適用される承認ポリシーがない場合、ユーザーはノードへのアクセスをリクエストできません。
ジャストインタイムノードアクセスには、3 つのポリシータイプがあります。このポリシータイプは、*自動承認*、*アクセス拒否*、および*手動承認*です。
**ジャストインタイムノードアクセスポリシータイプ**
+ 自動承認ポリシーでは、ユーザーが自動的に接続できるノードを定義します。
+ 手動承認ポリシーでは、指定したノードにアクセスするために必要な手動承認の数とレベルを定義します。
+ アクセス拒否ポリシーを使用すると、指定したノードへのアクセスリクエストの自動承認を明示的に防ぐことができます。
アクセス拒否ポリシーは、AWS Organizations 組織内のすべてのアカウントに適用されます。例えば、`Production` キーでタグ付けされたノードに対して、`Intern` グループの自動承認を明示的に拒否できます。自動承認ポリシーと手動承認ポリシーは、作成元の AWS アカウントと AWS リージョンにのみ適用されます。組織内の各メンバーアカウントが、独自の承認ポリシーを管理します。承認ポリシーは次の順序で評価されます。
1. アクセス拒否
1. 自動承認
1. 手動
組織ごとに 1 つのアクセス拒否ポリシー、アカウントとリージョンごとに 1 つの自動承認ポリシーのみを持つことができますが、アカウントには複数の手動承認ポリシーがある可能性があります。手動承認ポリシーを評価する場合、ジャストインタイムノードアクセスでは、ノードのより具体的なポリシーが常に優先されます。手動承認ポリシーは次の順序で評価されます。
1. タグの具体的なターゲット
1. すべてのノードのターゲット
例えば、`Demo` キーでタグ付けされたノードがあるとします。同じアカウントに、すべてのノードをターゲットとする手動承認ポリシーがあり、1 つのレベルからの 1 つの承認が必要です。また、`Demo` キーでタグ付けされたノードには、2 つのレベルからの 2 つの承認を必要とする手動承認ポリシーもあります。Systems Manager は、`Demo` タグをターゲットとするポリシーをノードに適用します。このポリシーが、すべてのノードをターゲットとするポリシーよりも具体的であるためです。これにより、アカウント内のすべてのノードの一般的なポリシーを作成し、ユーザーがアクセスリクエストを送信できるようにしながら、必要に応じてより詳細なポリシーを作成できます。
組織によっては、ノードに複数のタグが適用される場合があります。このシナリオでは、ノードに複数の手動承認ポリシーが適用されると、アクセスリクエストは失敗します。例えば、ノードに `Production` および `Database` キーがタグ付けされているとします。同じアカウントに、`Production` キーでタグ付けされたノードに適用される手動承認ポリシーと、`Database` キーでタグ付けされたノードに適用される別の手動承認ポリシーがあります。その結果、両方のキーでタグ付けされたノードで競合が発生し、アクセスリクエストが失敗します。Systems Manager は、失敗したリクエストにユーザーをリダイレクトします。ここでは、競合しているポリシーとタグの詳細を表示して、必要なアクセス許可がある場合は必要な調整を行うことができます。そうでない場合は、ポリシーを変更するために必要なアクセス許可を持つ組織内の同僚に通知できます。アクセスリクエストの失敗につながるポリシーの競合は EventBridge イベントを出力するため、独自のレスポンスワークフローを柔軟に構築できます。さらに、Systems Manager はアクセスリクエストの失敗につながるポリシーの競合に関する E メール通知を指定された受信者に送信します。ポリシーの競合用の E メール通知の設定の詳細については、「[ジャストインタイムアクセスリクエストに関する通知を設定する](systems-manager-just-in-time-node-access-notifications.md)」を参照してください。
*アクセス拒否*ポリシーでは、Cedar ポリシー言語を使用して、ユーザーが組織内で明示的に自動的に接続できないノードを定義します。このポリシーは、組織の委任管理者アカウントから作成および共有されます。アクセス拒否ポリシーは、すべての自動承認ポリシーよりも優先されます。組織ごとに 1 つのアクセス拒否ポリシーのみを持つことができます。
*自動承認*ポリシーでは、Cedar ポリシー言語を使用して、手動承認なしで指定されたノードに自動的に接続できるユーザーを定義します。自動的に承認されるアクセスリクエストのアクセス期間は 1 時間です。この値は変更できません。アカウントとリージョンごとに 1 つの自動承認ポリシーのみを持つことができます。
*手動*承認ポリシーでは、アクセス期間、必要な承認レベル数、レベルごとに必要な承認者の数、ジャストインタイムアクセスリクエストを承認できるノードを指定します。手動承認ポリシーのアクセス期間は 1～336 時間である必要があります。複数の承認レベルを指定した場合、アクセスリクエストの承認では一度に 1 つずつレベルが処理されます。つまり、承認プロセスが後続のレベルに移行する前に、1 つのレベルに必要なすべての承認が提供される必要があります。手動承認ポリシーで複数のタグを指定した場合、`and` ステートメントではなく `or` ステートメントとして評価されます。例えば、タグ `Application`、`Web`、および `Test` を含む手動承認ポリシーを作成した場合、これらのキーのいずれかでタグ付けされたすべてのノードにポリシーが適用されます。3 つすべてのキーでタグ付けされたノードにのみポリシーが適用されるわけではありません。
手動ポリシーと自動承認ポリシーを組み合わせて使用して、より重要なデータがあるノードを保護しながら、重要度の低いノードにユーザーが介入なしで接続できるようにすることをお勧めします。例えば、データベースノードへのアクセスリクエストには手動承認を義務づけ、永続的でないプレゼンテーション層のノードへのセッションは自動承認します。
次の手順では、ジャストインタイムノードアクセス用の承認ポリシーを作成する方法について説明します。
**Topics**
+ [ジャストインタイムノードアクセス用の手動承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-manual-policies.md)
+ [自動承認ポリシーとアクセス拒否ポリシーのステートメントの構造とビルトイン演算子](auto-approval-deny-access-policy-statement-structure.md)
+ [ジャストインタイムノードアクセスの自動承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-auto-approval-policies.md)
+ [ジャストインタイムノードアクセス用のアクセス拒否ポリシーを作成する](systems-manager-just-in-time-node-access-create-deny-access-policies.md)
+ [Amazon Q を使用してジャストインタイムノードアクセスの承認ポリシーを作成する](systems-manager-just-in-time-node-access-create-approval-policies-q-ide-cli.md)
# ジャストインタイムノードアクセス用の手動承認ポリシーを作成する
以下の手順では、手動承認ポリシーを作成する方法について説明します。Systems Manager では、AWS アカウントと AWS リージョンごとに手動承認ポリシーを最大 50 個作成できます。
**手動承認ポリシーを作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードアクセスを管理]** を選択します。
1. **[手動承認ポリシーの作成]** ステップの **[ポリシーの詳細]** セクションで、承認ポリシーの名前と説明を入力します。
1. **[アクセス期間]** の値を入力します。これは、アクセスリクエストの承認後にユーザーがノードへのセッションを開始できる最大時間です。1～336 の値で時間を指定する必要があります。
1. **[ノードターゲット]** セクションで、ポリシーを適用するノードに関連付けられたタグキーと値のペアを入力します。ポリシーに指定されているタグのいずれもノードに関連付けられていない場合、ポリシーはノードに適用されません。
1. **[アクセスリクエスト承認者]** セクションで、ポリシー内のノードターゲットへのアクセスリクエストを承認できるようにするユーザーまたはグループを入力します。アクセスリクエスト承認者には、IAM アイデンティティセンターユーザーとグループ、または IAM ロールを指定することが可能です。レベルごとに最大 5 人の承認者と、最大 5 レベルの承認者を指定できます。
1. **[手動承認ポリシーの作成]** を選択します。
# 自動承認ポリシーとアクセス拒否ポリシーのステートメントの構造とビルトイン演算子
次の表は、自動承認ポリシーとアクセス拒否ポリシーの構造を示しています。
| コンポーネント | 構文 |
| --- | --- |
| effect | `permit \| forbid` |
| scope | `(principal, action, resource)` |
| 条件句 | when {
principal or resource has attribute name
}; |
## ポリシーの構成要素
自動承認ポリシーまたはアクセス拒否ポリシーには、次のコンポーネントが含まれます。
+ **効果** - アクセスの `permit` (許可) または `forbid` (拒否)。
+ **スコープ** - 効果を適用するプリンシパル、アクション、リソース。特定のプリンシパル、アクション、リソースを指定しないでおくと、Cedar のスコープを未定義のままにすることができます。この場合、ポリシーはすべてのプリンシパル、アクション、リソースに適用されます。ジャストインタイムノードアクセスの場合、`action` は常に `AWS::SSM::Action::"getTokenForInstanceAccess"` です。
+ **条件句** - 効果が適用されるコンテキスト。
## コメント
ポリシーにコメントを含めることができます。コメントは、`//` で始まり改行文字で終わる行として定義されます。
以下の例は、ポリシー内のコメントを示しています。
```
// Allows users in the Engineering group from the Platform org to automatically connect to nodes tagged with Engineering and Production keys.
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
```
## 複数の句
`&&` 演算子を使用すると、1 つのポリシーステートメントに複数の条件句を含めることができます。
```
// Allow access if node has tag where the tag key is Environment
// & tag value is Development
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Development"
};
```
## 予約文字
次の例は、コンテキストのプロパティでポリシー言語の予約文字である `:` (セミコロン) が使用されている場合のポリシーの記述方法を示しています。
```
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
}
```
その他の例については、「[ポリシーステートメントの例](#policy-statement-examples)」を参照してください。
## ジャストインタイムノードアクセスのスキーマ
以下は、ジャストインタイムノードアクセス用の Cedar スキーマです。
```
namespace AWS::EC2 {
entity Instance tags String;
}
namespace AWS::IdentityStore {
entity Group;
entity User in [Group] {
employeeNumber?: String,
costCenter?: String,
organization?: String,
division?: String,
};
}
namespace AWS::IAM {
entity Role;
type AuthorizationContext = {
principalTags: PrincipalTags,
};
entity PrincipalTags tags String;
}
namespace AWS::SSM {
entity ManagedInstance tags String;
action "getTokenForInstanceAccess" appliesTo {
principal: [AWS::IdentityStore::User],
resource: [AWS::EC2::Instance, AWS::SSM::ManagedInstance],
context: {
"iam": AWS::IAM::AuthorizationContext
}
};
}
```
## ビルトイン演算子
さまざまな条件を使用して自動承認ポリシーまたはアクセス拒否ポリシーのコンテキストを作成する場合は、`&&` 演算子を使用して追加条件を指定できます。ポリシー条件にさらに表現力を加えるために使用できるビルトイン演算子は他にも多数あります。参照用にすべてのビルトイン演算子を下表に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/auto-approval-deny-access-policy-statement-structure.html)
## ポリシーステートメントの例
ポリシーステートメントの例を以下に示します。
```
// Users assuming IAM roles with a principal tag of "Elevated" can automatically access nodes tagged with the "Environment" key when the value equals "prod"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify IAM role principal tag
context.iam.principalTags.getTag("AccessLevel") == "Elevated" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "prod"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "prod"
};
```
```
// Identity Center users in the "Contractor" division can automatically access nodes tagged with the "Environment" key when the value equals "dev"
permit(principal, action == AWS::SSM::getTokenForInstanceAccess, resource)
when {
// Verify that the user is part of the "Contractor" division
principal.division == "Contractor" &&
// Verify the node has a tag with "Environment" tag key and a tag value of "dev"
resource.hasTag("Environment") &&
resource.getTag("Environment") == "dev"
};
```
```
// Identity Center users in a specified group can automatically access nodes tagged with the "Environment" key when the value equals "Production"
permit(principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::getTokenForInstanceAccess,
resource)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Production"
};
```
# ジャストインタイムノードアクセスの自動承認ポリシーを作成する
自動承認ポリシーでは、Cedar ポリシー言語を使用して、どのユーザーが指定されたノードに手動承認なしで自動的に接続できるかを定義します。自動承認ポリシーには、`principal` と `resource` を指定する `permit` ステートメントがいくつか含まれています。各ステートメントには、自動承認の条件を定義する `when` 句があります。
次に、自動承認ポリシーの例を示します。
```
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has costCenter && resource.hasTag("CostCenter") && principal.costCenter == resource.getTag("CostCenter")
};
permit (
principal in AWS::IdentityStore::Group::"d4q81745-r081-7079-d789-14da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "E-1*" && resource.hasTag("Purpose") && resource.getTag("Purpose") == "Testing"
};
```
以下の手順では、ジャストインタイムノードアクセス用に自動承認ポリシーを作成する方法について説明します。自動的に承認されるアクセスリクエストのアクセス期間は 1 時間です。この値は変更できません。AWS アカウントと AWS リージョンごとに自動承認ポリシーを 1 つのみ設定できます。ポリシーステートメントを作成する方法の詳細については、「[自動承認ポリシーとアクセス拒否ポリシーのステートメントの構造とビルトイン演算子](auto-approval-deny-access-policy-statement-structure.md)」を参照してください。
**自動承認ポリシーを作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードアクセスを管理]** を選択します。
1. **[承認ポリシー]** タブで、**[自動承認ポリシーを作成]** を選択します。
1. **[ポリシーステートメント]** セクションに自動承認ポリシー用のポリシーステートメントを入力します。あらかじめ用意されている **[サンプルステートメント]** を使用すると、ポリシーを簡単に作成できます。
1. **[自動承認ポリシーを作成]** を選択します。
# ジャストインタイムノードアクセス用のアクセス拒否ポリシーを作成する
アクセス拒否ポリシーでは、Cedar ポリシー言語を使用して、ユーザーが手動承認なしでどのノードに自動的には接続できないかを定義します。アクセス拒否ポリシーには、`principal` と `resource` を指定する `forbid` ステートメントがいくつか含まれています。各ステートメントには、自動承認を明示的に拒否する条件を定義する `when` 句があります。
次に、アクセス拒否ポリシーの例を示します。
```
forbid (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") && resource.getTag("Environment") == "Production"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has division && principal.division != "Finance" && resource.hasTag("DataClassification") && resource.getTag("DataClassification") == "Financial"
};
forbid (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has employeeNumber && principal.employeeNumber like "TEMP-*" && resource.hasTag("Criticality") && resource.getTag("Criticality") == "High"
};
```
以下の手順では、ジャストインタイムノードアクセス用にアクセス拒否ポリシーを作成する方法について説明します。ポリシーステートメントを作成する方法の詳細については、「[自動承認ポリシーとアクセス拒否ポリシーのステートメントの構造とビルトイン演算子](auto-approval-deny-access-policy-statement-structure.md)」を参照してください。
**注記**
以下の情報に注意してください。
アクセス拒否ポリシーを作成するには、AWS 管理アカウントまたは委任管理者アカウントにログインしている必要があります。AWS Organizations 組織は、アクセス拒否ポリシーを 1 つのみ設定できます。
ジャストインタイムノードアクセスは AWS Resource Access Manager (AWS RAM) を使用して、拒否アクセスポリシーを組織内のメンバーアカウントと共有します。拒否アクセスポリシーを組織内のメンバーアカウントと共有する場合は、組織の管理アカウントからリソース共有を有効にする必要があります。詳細については、「AWS RAM ユーザーガイド」の「[AWS Organizations 内でリソース共有を有効にする](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」を参照してください。
**アクセス拒否ポリシーを作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードアクセスを管理]** を選択します。
1. **[承認ポリシー]** タブで、**[アクセス拒否ポリシーを作成]** を選択します。
1. **[ポリシーステートメント]** セクションにアクセス拒否ポリシー用のポリシーステートメントを入力します。あらかじめ用意されている **[サンプルステートメント]** を使用すると、ポリシーを簡単に作成できます。
1. **[アクセス拒否ポリシーを作成]** を選択します。
# Amazon Q を使用してジャストインタイムノードアクセスの承認ポリシーを作成する
コマンドライン用の Amazon Q Developer を使用すると、ソフトウェア開発のさまざまな側面でガイダンスとサポートが提供されます。ジャストインタイムノードアクセスの場合、Amazon Q は、ポリシーのコードの生成および更新や、ポリシーステートメントの分析などにより、承認ポリシーを作成する際に役立ちます。以下の情報は、コマンドライン用の Amazon Q を使用して承認ポリシーを作成する方法を示しています。
## ユースケースの特定
承認ポリシーを作成する最初のステップは、ユースケースを明確に定義することです。例えば、組織で `Environment:Testing` タグを持つノードへのアクセスリクエストを自動的に承認できます。また、従業員 ID が `TEMP` で始まる場合に、`Environment:Production` タグを持つノードへの自動承認を明示的に拒否することもできます。`Tier:Database` タグを持つノードについて、2 つのレベルの手動承認を必要とすることもできます。
特定のシナリオで、あるポリシーまたは条件を別のポリシーまたは条件よりも優先できます。そのため、ユースケースと設定に最適なステートメントを決定するために必要なポリシーの動作を明確に定義することをお勧めします。
## 開発環境をセットアップする
承認ポリシーを作成するコマンドライン用の Amazon Q をインストールします。コマンドライン用の Amazon Q のインストールについては、「*Amazon Q Developer ユーザーガイド*」の「[Installing Amazon Q for command line](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html)」を参照してください。
また、AWS ドキュメントの MCP サーバーをインストールすることをお勧めします。この MCP サーバーは、コマンドライン用の Amazon Q を最新のドキュメントリソースに接続します。コマンドライン用の Amazon Q との MCP の使用の詳細については、「*Amazon Q Developer ユーザーガイド*」の「[Using MCP with Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-mcp.html)」を参照してください。
AWS ドキュメント MCP サーバーの詳細については、「[AWS Documentation MCP Server](https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server/)」を参照してください。
まだ AWS CLI をインストールして設定していない場合は、インストールして設定します。詳細については、「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
## 承認ポリシーの内容を開発する
ユースケースを特定して環境をセットアップしたら、ポリシーの内容を開発できます。主にユースケースと設定によって、使用する承認ポリシーとステートメントのタイプが決まります。
特定のポリシーの使用方法が不明な場合や、ポリシーのスキーマに関する詳細情報が必要な場合は、「[ノードの承認ポリシーを作成する](systems-manager-just-in-time-node-access-approval-policies.md)」および以降のトピックを参照してください。これらのトピックでは、ポリシーの評価方法を詳しく説明し、実用的なステートメントの例を示しています。
以下の手順は、コマンドライン用の Amazon Q を使用して承認ポリシーを作成する方法を示しています。
**注記**
Amazon Q Developer は生成 AI を使用します。レスポンスの検証が必要になる場合があります。「[AWS 責任ある AI ポリシー](https://aws.amazon.com/ai/responsible-ai/policy/)」を参照してください。
**コマンドライン用の Amazon Q を使用して承認ポリシーを作成するには**
1. ターミナルを開き、Amazon Q とのセッションを開始します。
```
$ q chat
```
1. プロンプトを入力し、作成するポリシーステートメントの種類を記述します。例えば、承認ポリシーの前述のシナリオを使用して、次のプロンプトを入力できます。
```
Create a Cedar policy statement that allows a principal to use the “getTokenForInstanceAccess" action for a resource
that has a tag key “Environment” and tag value of “Testing”. Use the following example statement for reference to verify the syntax.
permit (
principal in AWS::IdentityStore::Group::"e8c17310-e011-7089-d989-10da1EXAMPLE",
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
principal has organization && resource.hasTag("Engineering") && resource.hasTag("Production") && principal.organization == "Platform"
};
The Cedar policy statement you create must be valid. Validate the Cedar statement using the AWS documentation provided for just-in-time node access policy statement structure and make sure you abide by the schema.
```
1. このプロンプト例を入力すると、次のように出力されます。
```
Based on the AWS documentation for Cedar policy statements and the examples provided, I'll create a valid Cedar policy
statement that allows a principal to use the "getTokenForInstanceAccess" action for resources with the tag key "Environment" and tag value "Testing".
Here's the Cedar policy statement:
permit (
principal,
action == AWS::SSM::Action::"getTokenForInstanceAccess",
resource
)
when {
resource.hasTag("Environment") &&
resource.getTag("Environment") == "Testing"
};
This policy statement:
1. Uses the permit effect to allow access
2. Applies to any principal (since no specific principal is defined)
3. Specifically targets the "getTokenForInstanceAccess" action
4. Applies to resources that have a tag with key "Environment" and value "Testing"
5. Uses the proper syntax for the condition clause with the hasTag() and getTag() operators
The statement follows the Cedar policy language structure as documented in the AWS Systems Manager documentation for just-in-time node access policies.
```
1. ポリシーステートメントを新しい Cedar ファイルに貼り付けて、構文を検証します。[Cedar プレイグラウンド](https://www.cedarpolicy.com/en/playground)を使用してステートメントを検証することもできます。
1. ステートメントを検証したら、Cedar ファイルを保存します。
1. ターミナルから次の AWS CLI コマンドを実行して、ポリシーの内容を使用して SSM ドキュメントを作成します。本番環境で承認ポリシーを使用する前に、AWS アカウントおよび AWS リージョンの ID とノードのサブセットを使用して承認ポリシーをテストします。
**注記**
自動承認ポリシーの場合、ドキュメント名は `SSM-JustInTimeAccessAutoApprovalPolicy` である必要があります。AWS アカウントおよび AWS リージョンごとに 1 つの自動承認ポリシーのみが存在できます。アクセス拒否ポリシーの場合、ドキュメント名は `SSM-JustInTimeAccessDenyAccessOrgPolicy` である必要があります。AWS Organizations 組織ごとに 1 つのアクセス拒否ポリシーのみが存在できます。このポリシーは、Systems Manager の委任管理者アカウントで作成する必要があります。手動承認ポリシーの命名に関する制約は、他の SSM ドキュメントと同じです。詳細については、「[CreateDocument](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html#systemsmanager-CreateDocument-request-Name)」を参照してください。
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/policyContent.cedar \
--name "SSM-JustInTimeAccessAutoApprovalPolicy" \
--document-type "AutoApproval"
```
------
#### [ Server ]
```
aws ssm create-document ^
--content file://C:\path\to\file\policyContent.cedar ^
--name "SSM-JustInTimeAccessAutoApprovalPolicy" ^
--document-type "AutoApproval"
```
------
#### [ PowerShell ]
```
$cedar = Get-Content -Path "C:\path\to\file\policyContent.cedar" | Out-String
New-SSMDocument `
-Content $cedar `
-Name "SSM-JustInTimeAccessAutoApprovalPolicy" `
-DocumentType "AutoApproval"
```
------
# ジャストインタイムノードアクセスセッション設定を更新する
ジャストインタイムノードアクセスでは、組織内の AWS アカウントと AWS リージョンごとにセッション記録とログ記録の全般的な設定を指定できます。あるいは、CloudFormation StackSets を使用して複数のアカウントとリージョンに 1 つのセッション設定ドキュメントを作成することで、セッション設定の一貫性を保つことができます。セッション設定ドキュメントのスキーマについては、「[セッションドキュメントスキーマ](session-manager-schema.md)」を参照してください。
ログ記録の用途には、Amazon CloudWatch Logs でストリーミングオプションを使用することをお勧めします。この機能により、セッションデータログの連続ストリームを CloudWatch Logs に送信できます。セッションデータのストリーミングには、ユーザーがセッションで実行したコマンド、コマンドを実行したユーザーの ID、セッションデータが CloudWatch Logs にストリーミングされた時のタイムスタンプなど、重要な詳細情報が含まれます。セッションデータをストリーミングする場合、ログは JSON 形式で、既存のログソリューションとの統合に役立ちます。
Systems Manager は、ジャストインタイムノードアクセスセッションを自動的には終了しません。*最大セッション期間*設定と*アイドルセッションタイムアウト*設定に値を指定するのがベストプラクティスです。これらの設定を使用すると、ユーザーがアクセスリクエストで承認された時間枠よりも長くノードに接続したままにするのを防ぐことができます。以下の手順では、ジャストインタイムノードアクセスのセッション設定を更新する方法について説明します。
**重要**
ジャストインタイムノードアクセスの Session Manager 暗号化と RDP 記録に使用する AWS KMS キーにタグキー `SystemsManagerJustInTimeNodeAccessManaged` とタグ値 `true` でタグ付けする必要があります。
KMS キーのタグ付けの詳細については、「AWS Key Management Service デベロッパーガイド」の「[Tags in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html)」を参照してください。
**セッション設定を更新するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[セッション設定]** セクションで、**[編集]** を選択します。
1. 必要に応じて全般的な設定とログ記録の設定を更新し、**[保存]** を選択します。
# ジャストインタイムアクセスリクエストに関する通知を設定する
ユーザーがジャストインタイムノードアクセスリクエストを作成したら、承認者とリクエスタの E メールアドレスまたはチャットクライアントに通知を送信するように、Systems Manager を設定できます。通知にはリクエスタが指定したアクセスリクエストの理由、AWS アカウント、AWS リージョン、リクエストのステータス、ターゲットノードの ID が含まれています。現在、チャットアプリケーションに Amazon Q Developer が統合されたことで、Systems Manager は Slack クライアントと Microsoft Teams クライアントをサポートしています。チャットクライアントで通知を使用するときに、アクセスリクエスト承認者はアクセスリクエストと直接対話できます。このため、アクセスリクエストを操作するためにコンソールにログインする必要がなくなります。
**[開始する前に]**
ジャストインタイムノードアクセス通知用にチャットクライアントを設定する前に、次の要件に注意してください。
+ 現在 IAM ロールを使用してアカウント内のユーザー ID を管理している場合は、通知の送信先となる承認者またはリクエスタの E メールアドレスを、関連付けられたロールに手動で関連付ける必要があります。そうしないと、E メールで目的の受信者に通知できません。
以下の手順では、ジャストインタイムノードアクセスリクエストに関する通知を設定する方法について説明します。
**ジャストインタイムノードアクセスの通知を受け取れるようにチャットクライアントを設定するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[チャット]** セクションで、**[新しいクライアントを設定]** を選択します。
1. **[クライアントタイプを選択]** ドロップダウンで、設定するチャットクライアントのタイプを選択し、**[次へ]** を選択します。
1. チャットアプリケーションの Amazon Q Developer からチャットクライアントへのアクセスを許可するように求められます。**[許可]** を選択します。
1. **[チャネルを設定]** セクションで、チャットクライアントチャネルに関する情報を入力し、受け取る通知のタイプを選択します。
1. Slack 通知を設定する場合は、通知が設定されているすべての Slack チャネルに「@Amazon Q」を招待します。
1. **[チャネルを設定]** を選択します。
**注記**
Slack チャネルから直接アクセスリクエストを承認または拒否できるようにするには、Slack チャネルで設定された IAM ロールに `ssm:SendAutomationSignal` アクセス許可があり、チャットボットを含む信頼ポリシーがあることを確認してください。
```
{
"Effect": "Allow",
"Principal": {
"Service": "chatbot.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
```
**ジャストインタイムノードアクセスの通知を受け取れるように E メール通知を設定するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[E メール]** セクションで、**[編集]** を選択します。
1. **[E メールの追加]** を選択し、E メールアドレスを手動で関連付ける **IAM ロール**を選択します。
1. **[E メールアドレス]** フィールドに E メールアドレスを入力します。指定した IAM ロールによる承認が必要なアクセスリクエストが作成されるたびに、そのロールに関連付けた E メールアドレスに通知が届きます。
1. **[E メールアドレスの追加]** を選択します。
# RDP 接続を記録する
ジャストインタイムノードアクセスには、Windows Server ノードへの RDP 接続を記録する機能があります。RDP 接続を記録するには、S3 バケットおよび AWS Key Management Service (AWS KMS) カスタマーマネージドキーが必要です。AWS KMS key は、記録対象のデータが生成されて Systems Manager リソースに保存される際に一時的に暗号化するために使用されます。カスタマーマネージドキーは、暗号化と復号を主な用途とする対称キーでなければなりません。組織で 1 つのマルチリージョンキーを使用することもできれば、ジャストインタイムノードアクセスを有効にしたリージョンごとにカスタマーマネージドキーを作成しなければならないこともあります。
記録を保存する S3 バケットで KMS 暗号化を有効にしている場合は、バケット暗号化に使用されるカスタマーマネージドキーへのアクセスを `ssm-guiconnect` サービスプリンシパルに提供する必要があります。このカスタマーマネージドキーは、記録設定で指定したものとは異なる場合があります。これには、接続を確立するために必要な `kms:CreateGrant` アクセス許可を含める必要があります。
## RDP 記録用の S3 バケット暗号化の設定
接続記録は、RDP 記録を有効にするときに指定した S3 バケットに保存されます。
S3 バケット (SSE-KMS) のデフォルトの暗号化メカニズムとして KMS キーを使用する場合は、`ssm-guiconnect` サービスプリンシパルにキーに対する `kms:GenerateDataKey` アクションへのアクセスを許可する必要があります。S3 バケットで SSE-KMS 暗号化を使用する場合は、カスタマーマネージドキーを使用することをお勧めします。お勧めする理由は、カスタマーマネージドキーの関連付けられたキーポリシーを更新できるためです。AWS マネージドキー のキーポリシーを更新することはできません。
**重要**
ジャストインタイムノードアクセスの Session Manager 暗号化と RDP 記録に使用する AWS KMS キーにタグキー `SystemsManagerJustInTimeNodeAccessManaged` とタグ値 `true` でタグ付けする必要があります。
KMS キーのタグ付けの詳細については、「AWS Key Management Service デベロッパーガイド」の「[Tags in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/tagging-keys.html)」を参照してください。
次のカスタマーマネージドキーポリシーを使用して、S3 ストレージの KMS キーへの `ssm-guiconnect` サービスアクセスを許可します。カスタマーマネージドキーの更新の詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[キーポリシーの変更](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)」を参照してください。
各 *example resource placeholder* をユーザー自身の情報に置き換えます。
+ *account-id* は、接続を開始する AWS アカウントの ID を表します。
+ *region* は、S3 バケットが位置する AWS リージョンを表します。(バケットが複数のリージョンからの録画を受信する場合、`*` を使用できます。例: `s3.*.amazonaws.com`。)
**注記**
アカウントが AWS Organizations の組織に属している場合、`aws:SourceAccount` の代わりにポリシーの `aws:SourceOrgID` を使用できます。
```
{
"Sid": "Allow the GUI Connect service principal to access S3",
"Effect": "Allow",
"Principal": {
"Service": "ssm-guiconnect.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "account-id"
},
"StringLike": {
"kms:ViaService": "s3.region.amazonaws.com"
}
}
}
```
## RDP 接続を記録するように IAM アクセス許可を設定する
ジャストインタイムノードアクセスに IAM アクセス許可が必要になるほか、実行する必要があるタスクに基づいて、使用するユーザーやロールに対して以下のアクセス許可を付与する必要があります。
**接続を記録するように設定するためのアクセス許可**
RDP 接続を記録するように設定するには、以下のアクセス許可が必要です。
+ `ssm-guiconnect:UpdateConnectionRecordingPreferences`
+ `ssm-guiconnect:GetConnectionRecordingPreferences`
+ `ssm-guiconnect:DeleteConnectionRecordingPreferences`
+ `kms:CreateGrant`
**接続を開始するためのアクセス許可**
ジャストインタイムノードアクセスとの RDP 接続を確立するには、以下のアクセス許可が必要です。
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
+ `kms:CreateGrant`
**[開始する前に]**
接続の記録を保存するには、まず S3 バケットを作成し、以下のバケットポリシーを追加する必要があります。各*リソースプレースホルダーの例*をユーザー自身の情報に置き換えます。
(バケットポリシーの追加方法の詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConnectionRecording",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm-guiconnect.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition":{
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
------
## RDP 接続記録の有効化と設定
以下の手順では、RDP 接続の記録を有効にして設定する方法について説明します。
**RDP 接続記録を有効化および設定するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[RDP 記録]** セクションで、**[RDP 記録を有効にする]** を選択します。
1. セッション記録のアップロード先となる S3 バケットを選択します。
1. 記録対象のデータが生成されて Systems Manager リソースに保存される際に、データの一時的な暗号化に使用するカスタマーマネージドキーを選択します。(これは、バケットの暗号化に使用するものとは異なるカスタマーマネージドキーにすることができます。)
1. **[保存]** を選択します。
## RDP 接続の記録ステータス値
RPD 接続記録の有効なステータス値は次のとおりです。
+ `Recording` - 接続は記録中です。
+ `Processing` - 接続が終了した後、動画が処理されています。
+ `Finished` - 正常な終了状態: 接続録画の動画が正常に処理され、指定されたバケットにアップロードされました。
+ `Failed` - 失敗した終了状態。接続は正常に記録されませんでした。
+ `ProcessingError` - 動画処理中に 1 つ以上の中間障害/エラーが発生しました。考えられる原因には、記録の保存用に指定された S3 バケットの設定ミスによるサービス依存関係の問題やアクセス許可の不足などがあります。記録がこの状態にある場合、サービスは処理を試行し続けます。
**注記**
`ProcessingError` は、接続の確立後に S3 バケットにオブジェクトをアップロードするアクセス許可が `ssm-guiconnect` サービスプリンシパルに付与されていない可能性があります。もう 1 つの考えられる原因は、S3 バケット暗号化に使用される KMS キーに対する KMS アクセス許可がないことです。
# ターゲットを変更する
ジャストインタイムノードアクセスを設定するときに、ジャストインタイムノードアクセスをセットアップする*ターゲット*を選択します。ターゲットは、AWS Organizations 組織単位 (OU) と AWS リージョンで構成されています。デフォルトでは、Systems Manager 統合コンソールをセットアップするときに選択したのと同じターゲットがジャストインタイムノードアクセスにも選択されます。ジャストインタイムノードアクセスは、同じすべてのターゲットにセットアップすることも、Systems Manager 統合コンソールをセットアップするときに指定したターゲットのサブセットにセットアップすることもできます。Systems Manager 統合コンソールをセットアップするときに選択されなかったターゲットを新たに追加する機能はサポートされていません。ジャストインタイムノードアクセスをセットアップした後で選択したターゲットを変更できます。
以下の手順では、ジャストインタイムノードアクセスのターゲットを変更する方法について説明します。
**ターゲットを変更するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[ターゲット]** セクションで、**[編集]** を選択します。
1. ジャストインタイムノードアクセスを使用する **[組織単位]** と **[リージョン]** を選択します。
1. **[保存]** を選択します。
# ID プロバイダーを変更する
デフォルトでは、ジャストインタイムノードアクセスでは ID プロバイダーに IAM が使用されます。ジャストインタイムノードアクセスを有効にした後に、組織で統合コンソールを使用しているお客様は、IAM アイデンティティセンターを使用するようにこの設定を変更できます。単一のアカウントとリージョン用に設定する場合、ジャストインタイムノードアクセスでは、ID プロバイダーとして IAM アイデンティティセンターはサポートされていません。
次の手順では、ジャストインタイムノードアクセスの ID プロバイダーを変更する方法について説明します。
**ID プロバイダーを変更するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブを選択します。
1. **[ユーザー ID]** セクションで、**[編集]** を選択します。
1. **[AWS IAM アイデンティティセンター]** を選択します。
1. **[保存]** を選択します。
# ジャストインタイムノードアクセスセッションを開始する
ジャストインタイムノードアクセスを有効にしてセットアップし、セッションと通知の設定を行ったら、ユーザーがジャストインタイムノードアクセスセッションを開始する準備は完了です。Systems Manager コンソールから、または Session Manager プラグインを使用して AWS Command Line Interface から、ジャストインタイムノードアクセスを使用してセッションを開始できます。ジャストインタイムノードアクセスセッションは、同じアカウントとリージョン内のノード上で開始できます。以下の手順では、ジャストインタイムノードアクセスでセッションを開始する方法について説明します。
**注記**
ユーザーが以前に Session Manager を使用してノードに接続していた場合、ジャストインタイムノードアクセスを使用してセッションを開始するには、IAM ポリシーから Session Manager アクセス許可 (例えば `ssm:StartSession`) を削除する必要があります。そうしないと、ノードに接続するときにユーザーは引き続き Session Manager を使用します。
**コンソールを使用してジャストインタイムノードアクセスでセッションを開始するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[ノードを詳しく見る]** を選択します。
1. 接続するノードを選択します。
1. **[アクション]** ドロップダウンで、**[接続]** を選択します。
組織の承認ポリシーがノードへの自動接続を許可していない場合は、アクセスリクエストを送信するように求められます。必要事項を入力してアクセスリクエストを送信し、必要なすべての承認が得られたら、ノードへのセッションを開始できるようになります。
**AWS CLI を使用してジャストインタイムノードアクセスでセッションを開始するには**
1. 次のコマンドを実行して、アクセスリクエストワークフローを開始します。*プレースホルダ値*は自分の情報に置き換えてください。
```
aws ssm start-access-request \
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE
--reason "Troubleshooting networking performance issue"
```
組織の承認ポリシーに応じて、ノードに自動的に接続されるか、手動承認プロセスが開始されます。リクエストに手動承認が必要な場合は、レスポンスで返されたアクセスリクエストの ID を書き留めます。
1. 必要なすべての承認が得られるまで待機します。
1. 必要なすべての承認が得られたら、以下のコマンドを実行して一時的な認証情報が含まれているアクセストークンを取得します。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。
```
aws ssm get-access-token \
--access-request-id oi-12345abcdef
```
レスポンスで返されたアクセストークンを書き留めます。
1. 次のコマンドを実行して、AWS CLI で一時的な認証情報を使用します。*プレースホルダ値*は自分の情報に置き換えてください。
```
export AWS_SESSION_TOKEN=AQoDYXdzEJr...
```
1. 次のコマンドを実行して、ノードへのセッションを開始します。*プレースホルダ値*は自分の情報に置き換えてください。
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
# ジャストインタイムアクセスリクエストを管理する
組織全体にわたって可視性を高めるために、Systems Manager は組織用の委任管理者アカウントにアクセスリクエストをレプリケートします。コンプライアンス要件の遵守を支援するため、Systems Manager はすべてのアクセスリクエストを 1 年間保持します。以下のトピックでは、ジャストインタイムノードアクセスリクエストを管理する方法について説明します。この情報は、アクセスリクエスト承認者を対象としています。作業を始める前に、IAM ポリシーをレビューし、ジャストインタイムノードアクセスを管理するために必要なアクセス許可が付与されていることを確認しておくことをお勧めします。詳細については、「[Systems Manager でジャストインタイムアクセスをセットアップする](systems-manager-just-in-time-node-access-setting-up.md)」を参照してください。
**Topics**
+ [ジャストインタイムノードアクセスリクエストを承認および拒否する](systems-manager-just-in-time-node-access-approve-deny-requests.md)
# ジャストインタイムノードアクセスリクエストを承認および拒否する
アクセスリクエスト承認者は、統合 Systems Manager コンソールまたは任意のコマンドラインツールを使用して、ジャストインタイムノードアクセスリクエストを承認または拒否できます。この情報は、アクセスリクエスト承認者を対象としています。アクセスリクエストを承認または拒否するために必要なアクセス許可がない場合は、管理者にお問い合わせください。次の手順では、ジャストインタイムノードアクセスリクエストを承認または拒否する方法について説明します。
**コンソールを使用してジャストインタイムノードアクセスリクエストを承認または拒否するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[ノードアクセスを管理]** を選択します。
1. **[アクセスリクエスト]** タブを選択します。
1. **[自分のためのリクエスト]** トグルを選択します。
1. 承認または拒否するアクセスリクエストの横にあるチェックボックスをオンにします。
1. **[承認]** または **[拒否]** を選択します。
アクセスリクエストを承認した後に、**[取り消し]** を選択して、いつでも承認を取り消すことができます。
**コマンドラインを使用してジャストインタイムノードアクセスリクエストを承認または拒否するには**
1. 通知のアクセスリクエスト ID を書き留めます。例えば、*oi-12345abcdef* などです。
1. 次のコマンドを実行して、アクセスリクエストの承認ワークフローの詳細を返します。*placeholder values* を自身の情報に置き換えていることを確認します。
```
aws ssm get-ops-item \
--ops-item-id oi-12345abcdef
```
`OperationalData` の `/aws/accessrequest` フィールドの `automationExecutionId` 値を書き留めます。例えば、*9231944f-61c6-40be-8bce-8ee2bEXAMPLE* などです。
1. 次のコマンドを実行して、アクセスリクエストを承認または拒否します。`Approve` シグナルタイプを使用してリクエストを承認し、`Deny` を使用してリクエストを拒否します。*placeholder values* を自身の情報に置き換えていることを確認します。
```
aws ssm send-automation-signal \
--automation-execution-id 9231944f-61c6-40be-8bce-8ee2bEXAMPLE \
--signal-type "Approve"
```
# Session Manager からジャストインタイムノードアクセスに移行する
ジャストインタイムノードアクセスを有効にしても、Systems Manager が Session Manager の既存のリソースに変更を加えることはありません。そのため、既存の環境に混乱が生じることはなく、ユーザーは承認ポリシーを作成し検証しているときでも引き続きセッションを開始できるようになります。承認ポリシーをテストする準備ができたら、ジャストインタイムノードアクセスへの移行を完了できるように既存の IAM ポリシーを変更する必要があります。例えば、ID へのジャストインタイムノードアクセスに必要なアクセス許可を追加する、Session Manager への `StartSession` API オペレーション用のアクセス許可を削除するといったことです。AWS アカウントと AWS リージョンの ID とノードのサブセットで承認ポリシーをテストすることをお勧めします。
ジャストインタイムノードアクセスに必要なアクセス許可の詳細については、「[Systems Manager でジャストインタイムアクセスをセットアップする](systems-manager-just-in-time-node-access-setting-up.md)」を参照してください。
ID の IAM アクセス許可の変更に関する詳細については、「*IAM ユーザーガイド*」の「[IAM アイデンティティ許可の追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
ここでは、Session Manager からジャストインタイムノードアクセスに移行する方法について詳しく説明します。
Session Manager からジャストインタイムノードアクセスに移行するには、運用に混乱を招くことなくスムーズに移行できるように入念に計画を立ててテストする必要があります。以降のセクションでは、このプロセスを完了する方法について説明します。
## 前提条件
作業を開始する前に、次のタスクが完了していることを確認してください。
+ Systems Manager 統合コンソールをセットアップする。
+ 自分のアカウントに IAM ポリシーを変更するアクセス許可が付与されていることを確認する。
+ 現時点で Session Manager アクセス許可を付与しているすべての IAM ポリシーとロールを特定する。
+ セッション設定やログ記録設定など現在の Session Manager 設定を文書化する。
## 評価
以下のタスクを完了することで、現在の環境を評価し、承認に必要な作業を明らかにします。
1. **ノードのインベントリを作成する** - ユーザーが現在 Session Manager を介してアクセスしているすべてのノードを特定します。
1. **ユーザーアクセスパターンを特定する** - どのユーザーやロールがどのノードにどのような状況でアクセスする必要があるかを文書化します。
1. **承認ワークフローをマッピングする** - さまざまなタイプのノードに対するアクセスリクエストを誰が承認すべきかを決定します。
1. **タグ付け戦略をレビューする** - 計画した承認ポリシーをサポートするようにノードが適切にタグ付けされていることを確認します。
1. **既存の IAM ポリシーを監査する** - Session Manager アクセス許可が含まれているすべてのポリシーを特定する。
## 計画
### 段階的戦略
Session Manager からジャストインタイムノードアクセスに移行するときは、以下のような段階的アプローチを使用することをお勧めします。
1. **フェーズ 1: セットアップと設定** - 既存の Session Manager アクセス許可を変更することなくジャストインタイムノードアクセスを有効にします。
1. **フェーズ 2: ポリシー策定** - ノードの承認ポリシーを作成し、テストします。
1. **フェーズ 3: パイロット移行** - 重要でないノードとユーザーやロールからなる小さなグループを Session Manager からジャストインタイムノードアクセスに変更します。
1. **フェーズ 4: 完全移行** - 残りのノードとユーザーやロールを徐々に移行します。
### タイムラインの考慮事項
Session Manager からジャストインタイムノードアクセスに移行するタイムラインを作成するときは、以下の要因を考慮します。
+ 新しい承認ワークフローに合わせてユーザーをトレーニングし調整する時間を確保する。
+ 運用アクティビティの少ない時間帯に移行をスケジュールする。
+ トラブルシューティングと調整のバッファ時間を含める。
+ 両方のシステムが稼働する並列オペレーションの期間を計画する。
## 実装手順
### フェーズ 1: セットアップと設定
1. Systems Manager コンソールでジャストインタイムノードアクセスを有効にします。詳細なステップについては、「[Systems Manager でジャストインタイムアクセスをセットアップする](systems-manager-just-in-time-node-access-setting-up.md)」を参照してください。
1. 現在の Session Manager 設定に合わせてジャストインタイムノードアクセスのセッション設定を行います。詳細については、「[ジャストインタイムノードアクセスセッション設定を更新する](systems-manager-just-in-time-node-access-session-preferences.md)」を参照してください。
1. アクセスリクエストの通知設定をセットアップします。詳細については、「[ジャストインタイムアクセスリクエストに関する通知を設定する](systems-manager-just-in-time-node-access-notifications.md)」を参照してください。
1. Windows Server ノードへの RDP 接続を使用する場合は、RDP 記録を設定します。詳細については、「[RDP 接続を記録する](systems-manager-just-in-time-node-access-rdp-recording.md)」を参照してください。
### フェーズ 2: ポリシー策定
1. ジャストインタイムノードアクセスの管理者とユーザーを対象とした IAM ポリシーを作成します。
1. セキュリティ要件およびユースケースに基づいて承認ポリシーを策定します。
1. 非本番環境でポリシーをテストして、想定通りに機能することを確認します。
### フェーズ 3: パイロット移行
1. ユーザーと重要でないノードからなる小さなグループをパイロットとして選択します。
1. パイロットユーザー用にジャストインタイムノードアクセス許可を含めた新しい IAM ポリシーを作成します。
1. パイロットユーザーの IAM ポリシーから Session Manager アクセス許可 (`ssm:StartSession`) を削除します。
1. 新しいアクセスリクエストワークフローでパイロットユーザーをトレーニングします。
1. 問題がないかパイロットをモニタリングし、フィードバックを収集します。
1. パイロットの結果に基づいてポリシーと手順を調整します。
**パイロットユーザー向けに IAM ポリシーを変更する例**
Session Manager アクセス許可がある元のポリシー:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
ジャストインタイムノードアクセスに合わせてポリシーを変更:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartAccessRequest",
"ssm:GetAccessToken",
"ssm:ResumeSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
### フェーズ 4: 完全移行
残りのユーザーとノードを一括して移行するスケジュールを策定します。
## テスト方法
移行プロセス全体を通して、以下のテストを実施します。
+ **ポリシーの検証** - 承認ポリシーが目的のノードとユーザーに適切に適用されていることを検証します。
+ **アクセスリクエストワークフロー** - 自動承認と手動承認の両方のシナリオで、アクセスリクエストからセッション確立までのワークフロー全体をテストします。
+ **通知** - 設定されたチャネル (E メール、Slack、Microsoft Teams) を介して承認者が通知を受け取ることを検証します。
+ **ログ記録とモニタリング** - セッションログとアクセスリクエストが適切にキャプチャされて保存されることを検証します。
## 移行を正常に完了するためのベストプラクティス
+ **早めに頻繁に伝える** - ジャストインタイムノードアクセスの移行タイムラインと利点についてユーザーに周知します。
+ **重要でないシステムから開始する** - 本番環境に移行する前に開発環境またはテスト環境で移行を開始します。
+ **何事も文書化する** - 承認ポリシー、IAM ポリシーの変更、構成設定を詳細に記録します。
+ **モニタリングして調整する** - アクセスリクエストと承認ワークフローを継続的にモニタリングし、必要に応じてポリシーを調整します。
+ **ガバナンスを確立する** - 承認ポリシーを定期的にレビューし、環境の変化に応じて更新するためのプロセスを作成します。
# Systems Manager でジャストインタイムアクセスを無効にする
以下の手順では、ジャストインタイムノードアクセスを無効にする方法について説明します。ジャストインタイムノードアクセスを無効にすると、他の接続方法を既に実装している場合を除き、組織内のユーザーはノードに接続できなくなる可能性があります。
**ジャストインタイムノードアクセスを無効にするには**
1. 組織用の Systems Manager 委任管理者アカウントにログインします。
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインの **[設定]** を選択します。
1. **[ジャストインタイムノードアクセス]** タブで、**[無効]** を選択します。
# ジャストインタイムノードアクセスに関するよくある質問
## Session Manager からジャストインタイムノードアクセスに移行するにはどうすればよいですか?
統合コンソールを設定してジャストインタイムノードアクセスを有効にした後に、既存の IAM ポリシーを変更してジャストインタイムノードアクセスへの移行を完了する必要があります。これには、ジャストインタイムノードアクセスに必要なアクセス許可の追加や、Session Manager 用の `StartSession` API オペレーションのアクセス許可の削除が含まれます。ジャストインタイムノードアクセス用の IAM ポリシーの詳細については、「[Systems Manager でジャストインタイムアクセスをセットアップする](systems-manager-just-in-time-node-access-setting-up.md)」を参照してください。
## ジャストインタイムノードアクセスを使用するように統合コンソールを設定する必要がありますか?
はい。統合コンソールの設定は、ジャストインタイムノードアクセスの前提条件です。ただし、統合コンソールを設定してジャストインタイムノードアクセスを有効にした後は、ノードに接続する方法がいくつかあります。例えば、Amazon EC2 コンソールと AWS CLI からジャストインタイムノードアクセスセッションを開始できます。統合コンソールの設定の詳細については、「[組織用の Systems Manager 統合コンソールのセットアップ](systems-manager-setting-up-organizations.md)」を参照してください。
## ジャストインタイムノードアクセスに関連するコストはありますか?
Systems Manager では、ジャストインタイムノードアクセス用の 30 日間の無料トライアルが提供されます。トライアル後、ジャストインタイムノードアクセスにはコストが発生します。詳細については、[AWS Systems Manager の料金](https://aws.amazon.com/systems-manager/pricing/)を参照してください。
## ジャストインタイムノードアクセスの承認ポリシーの優先順位はどのようになっていますか?
承認ポリシーは次の順序で評価されます。
1. アクセス拒否
1. 自動承認
1. 手動
## 手動承認ポリシーはどのように評価されますか?
ジャストインタイムノードアクセスでは、ノードのより具体的なポリシーが常に優先されます。手動承認ポリシーは次の順序で評価されます。
1. タグの具体的なターゲット
1. すべてのノードのターゲット
## ノードに適用される承認ポリシーがない場合はどのようになりますか?
ジャストインタイムノードアクセスを使用してノードに接続するには、ノードに承認ポリシーを適用する必要があります。ノードに適用される承認ポリシーがない場合、ユーザーはノードへのアクセスをリクエストできません。
## 複数の承認ポリシーでタグをターゲットにできますか?
タグは、承認ポリシーで 1 回のみターゲットにできます。
## タグが重複した結果、複数の手動承認ポリシーがノードに適用された場合はどのようになりますか?
ノードに複数の手動承認ポリシーが適用されると、競合が発生し、ユーザーはノードへのアクセスをリクエストできません。ケースによってはインスタンスに複数のタグがある場合もあるため、手動承認ポリシーを作成するときはこの点に注意してください。
## ジャストインタイムノードアクセスを使用して、アカウントとリージョンをまたいだノードでアクセスをリクエストし、セッションを開始することはできますか?
ジャストインタイムノードアクセスでは、リクエスタと同じアカウントとリージョンのノードでの、アクセスのリクエストとセッションの開始がサポートされています。
## ジャストインタイムノードアクセスを使用して、ハイブリッドアクティベーションに登録されたノードでアクセスをリクエストし、セッションを開始することはできますか?
はい。ジャストインタイムノードアクセスでは、ハイブリッドアクティベーションに登録されたノードでの、アクセスのリクエストとセッションの開始がサポートされています。ノードは、リクエスタと同じアカウントとリージョンに登録する必要があります。
# 診断と修復
Systems Manager の統合コンソールを使用すると、単一の診断オペレーションでフリート全体の問題を特定できます。組織の場合、単一のオートメーションオペレーションを使用して、すべてのターゲットまたは選択したターゲットのみに対して修復を試みることができます。組織の場合、委任されたアカウント管理者として、すべてのアカウントおよびリージョンにわたってターゲットを選択できます。単一のアカウントで作業している場合は、一度に 1 つのリージョンのターゲットを選択できます。
Systems Manager は、複数のタイプのデプロイ障害やドリフトした設定を診断することができ、それらをユーザーが修復するのに役立ちます。また、Systems Manager は、アカウント内または組織内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのうち、*マネージドノード*として扱うことができないインスタンスを特定することもできます。EC2 インスタンス診断プロセスでは、仮想プライベートクラウド (VPC)、ドメインネームサービス (DNS) 設定、または Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループの設定ミスに関連する問題を特定できます。
**注記**
Systems Manager は、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境において、EC2 インスタンスとその他のマシンタイプの両方を*マネージドノード*としてサポートします。マネージドノードになるには、そのマシンに AWS Systems Manager Agent (SSM Agent) がインストールされており、Systems Manager がそのマシン上でアクションを実行するアクセス許可を持っている必要があります。
EC2 インスタンスの場合、このアクセス許可は、AWS Identity and Access Management (IAM) ロールを使用してアカウントレベルで付与するか、またはインスタンスプロファイルを使用してインスタンスレベルで付与することができます。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。
非 EC2 マシンの場合、このアクセス許可は IAM サービスロールを使用して付与されます。詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。
**[開始する前に]**
**[診断および修復]** 機能を使用してアンマネージド EC2 インスタンスを検出するには、まず、組織またはアカウントを Systems Manager の統合コンソールにオンボーディングする必要があります。このプロセス中に、これらのオペレーションに必要な IAM ロールとマネージドポリシーを作成するオプションを選択する必要があります。詳細については、「[組織用の Systems Manager 統合コンソールのセットアップ](systems-manager-setting-up-organizations.md)」を参照してください。
以下のトピックは、一般的なタイプのデプロイ障害、ドリフトした設定、およびアンマネージド EC2 インスタンスを特定して修正するのに役立ちます。
**Topics**
+ [失敗したデプロイの診断と修復](remediating-deployment-issues.md)
+ [ドリフトした設定の診断と修復](remediating-configuration-drift.md)
+ [Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復](remediating-unmanaged-instances.md)
+ [ランブックアクションの修復の影響タイプ](remediation-impact-type.md)
+ [Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)
# 失敗したデプロイの診断と修復
Systems Manager は、次のタイプの失敗したデプロイを診断することができ、ユーザーによる修復を支援します。
+ 組織メンバーアカウントのコアセットアップ
+ 委任管理者アカウントのコアセットアップ
+ アカウントのコアセットアップ
次の手順を使用して、これらのタイプの問題の修復を試みます。
**失敗したデプロイを診断および修復する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[診断および修復]** を選択します。
1. **[デプロイ関連]** タブを選択します。
1. **[失敗したデプロイ]** セクションで、失敗したデプロイの検出結果のリストを確認します。
1. **[セットアップ手順]** 列で、検出結果の名前を選択して、問題に関する追加の詳細を確認します。例: **組織メンバーアカウントのコアセットアップ**。
1. その失敗したデプロイの詳細ページで、アカウントのリストと、各アカウント内でデプロイの失敗が発生したリージョンの数を確認できます。
1. アカウント ID を選択すると、そのアカウントにおける失敗の理由に関する情報が表示されます。
1. **[失敗したリージョン]** 領域で、**[ステータスの理由]** として提供された情報を調べます。この情報には、デプロイが失敗した理由が示されており、必要な設定変更についてのインサイトが得られる場合があります。
1. 設定を変更せずにデプロイを再試行する場合は、**[再デプロイ]** を選択します。
# ドリフトした設定の診断と修復
Systems Manager は、次のタイプのドリフトした設定を診断することができ、ユーザーによる修復を支援します。
+ 組織メンバーアカウントのコアセットアップ
+ 委任管理者アカウントのコアセットアップ
+ アカウントのコアセットアップ
次の手順を使用して、これらのタイプのドリフトした設定の修復を試みます。
**ドリフトした設定を診断および修復する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[診断および修復]** を選択します。
1. **[デプロイ関連]** タブを選択します。
1. **[ドリフトしたデプロイ]** セクションで、失敗したデプロイの検出結果のリストを確認します。
-または-
新しい診断を実行するには、**[ドリフトの検出]** を選択します。
1. **[セットアップ手順]** 列で、検出結果の名前を選択して、問題に関する追加の詳細を確認します。例: **組織メンバーアカウントのコアセットアップ**。
1. その失敗したデプロイの詳細ページで、アカウントのリストと、各アカウント内で設定ドリフトが発生したリージョンの数を確認できます。
1. アカウント ID を選択すると、そのアカウントにおける設定ドリフトの理由に関する情報が表示されます。
1. **[ドリフトされたリソース]** 領域で、**[リソース]** 列にドリフトが発生したリソースの名前が報告されます。**[ドリフトタイプ]** 列には、リソースが変更されたか削除されたかが報告されます。
1. 目的の設定を再デプロイするには、**[再デプロイ]** を選択します。
# Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復
Systems Manager を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理するのを支援するために、Systems Manager の統合コンソールを使用して次のことができます。
1. 手動による、またはスケジュールされた診断プロセスを実行して、現在 Systems Manager によって管理されていない、アカウントまたは組織内の EC2 インスタンスを特定します。
1. Systems Manager がインスタンスの管理を引き継ぐのを妨げているネットワークまたはその他の問題を特定します。
1. オートメーション実行を実行して問題を自動的に修復するか、手動で問題に対処するのに役立つ情報にアクセスします。
以下のトピックの情報を使用して、Systems Manager が EC2 インスタンスを管理することを妨げている問題を診断および修復できます。
## Systems Manager が「アンマネージド EC2 インスタンスの問題」リストで影響を受けるノードをカウントする方法
**[アンマネージド EC2 インスタンスの問題]** タブでアンマネージドとして報告されたノードの数は、診断スキャン時に以下のいずれかのステータス値を持っていたインスタンスの総数を表します。
+ `Running`
+ `Stopped`
+ `Stopping`
この数は、**[問題の概要]** 領域で **[影響を受けるノード]** として報告されます。次の図で、現在 Systems Manager によって管理されていない、影響を受けるノードの数は `40` です。
![\[[診断および修復] ページで影響を受けるノードの数が 40 であることを示している [問題の概要] 領域\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)
**[ノードインサイトの確認]** ページのアンマネージド EC2 インスタンスのレポートとは異なり、この EC2 インスタンスの数は動的ではありません。これは、最後に報告された診断スキャン時 (**[スキャン時刻]** の値として示されている) における検出結果を表しています。そのため、この報告された影響を受けるノードの数を最新の状態に保つために、アンマネージド EC2 インスタンスの診断スキャンを定期的に実行することをお勧めします。
**[ノードのインサイトを確認]** ページでのアンマネージドインスタンス数の詳細については、「[ノードインサイトの確認](review-node-insights.md)」トピックの「[アンマネージドインスタンスとは](review-node-insights.md#unmanaged-instance-definition)」を参照してください。
**Topics**
+ [Systems Manager が「アンマネージド EC2 インスタンスの問題」リストで影響を受けるノードをカウントする方法](#unmanaged-instance-scan-count)
+ [診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ](diagnosing-ec2-category-types.md)
+ [アンマネージド EC2 インスタンスに対する診断およびオプションの修復の実行](running-diagnosis-execution-ec2.md)
+ [アンマネージド EC2 インスタンスの定期スキャンのスケジュール](schedule-recurring-ec2-diagnosis.md)
# 診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ
このトピックでは、ユーザーが診断と修復を行う際に Systems Manager が支援できる EC2 管理の問題の主要なカテゴリと、各カテゴリの具体的な問題についてリストします。一部の問題については、Systems Manager が問題を特定することはできるが、自動修復を行うことはできない場合があるので注意してください。そのような場合、Systems Manager のコンソールで、問題を手動で解決するのに役立つ情報が提供されます。
診断プロセスでは、EC2 インスタンスが属する仮想プライベートクラウド (VPC) に応じて、各グループの EC2 インスタンスを一度に検査します。
**Topics**
+ [問題カテゴリ: セキュリティグループ設定と HTTPS 通信](#unmanaged-ec2-issue-security-groups)
+ [問題カテゴリ: DNS または DNS ホスト名の設定](#unmanaged-ec2-issue-dns-configuration)
+ [問題カテゴリ: VPC エンドポイント設定](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [問題カテゴリ: ネットワーク ACL 設定](#unmanaged-ec2-issue-nacl-configuration)
## 問題カテゴリ: セキュリティグループ設定と HTTPS 通信
診断オペレーションによって、SSM Agent が HTTPS 経由で Systems Manager サービスと通信できないことが検出される場合があります。そのような場合は、オートメーションランブックを実行することを選択できます。これにより、インスタンスにアタッチされているセキュリティグループの更新が試行されます。
**注記**
場合によっては、Systems Manager がこれらの問題を自動的に修復できないことがありますが、影響を受けたセキュリティグループを手動で編集することは可能です。
**サポートされている問題タイプ**
+ **インスタンスセキュリティグループ**: ポート 443 でのアウトバウンドトラフィックは許可されません
+ **`ssm` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません
+ **`ssmmessages` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません
+ **`ec2messages` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません
詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[エンドポイントセキュリティグループでイングレスルールを検証する](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules)」を参照してください。
## 問題カテゴリ: DNS または DNS ホスト名の設定
診断オペレーションによって、ドメインネームシステム (DNS) または DNS ホスト名が VPC に対して適切に設定されていないことが検出される場合があります。そのような場合は、オートメーションランブックを実行することを選択できます。これにより、影響を受けた VPC の `enableDnsSupport` 属性および `enableDnsHostnames` 属性の有効化が試行されます。
**サポートされている問題タイプ**
+ VPC では DNS サポートは無効化されています。
+ VPC では DNS ホスト名は無効化されています。
詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[VPC DNS 関連の属性を検証する](troubleshooting-ssm-agent.md#agent-ts-dns-attributes)」を参照してください。
## 問題カテゴリ: VPC エンドポイント設定
診断オペレーションによって、VPC エンドポイントが VPC に対して適切に設定されていないことが検出される場合があります。
SSM Agent に必要な VPC エンドポイントが存在しない場合、Systems Manager はオートメーションランブックを実行して VPC エンドポイントを作成し、それを関連する各リージョンアベイラビリティーゾーン (AZ) 内の 1 つのサブネットに関連付けようとします。VPC に必要なエンドポイントは存在するが、問題が見つかったサブネットに関連付けられていない場合、ランブックはその VPC エンドポイントを影響を受けたサブネットに関連付けます。
**注記**
Systems Manager は、誤って設定された VPC エンドポイントのすべての問題の修復をサポートしているわけではありません。そのような場合、Systems Manager は、オートメーションランブックを実行する代わりに、ユーザーに対して手動修復手順を提供します。
**サポートされている問題タイプ**
+ PrivateLink 用の `ssm.region.amazonaws.com` エンドポイントが見つかりませんでした。
+ PrivateLink 用の `ssmmessages.region.amazonaws.com` エンドポイントが見つかりませんでした。
+ PrivateLink 用の `ec2messages.region.amazonaws.com` エンドポイントが見つかりませんでした。
**診断可能な問題タイプ**
Systems Manager は、以下の問題タイプを診断できますが、現在、これらの問題の修復に使用できるランブックはありません。これらの問題について、設定を手動で編集することは可能です。
+ インスタンスのサブネットが `ssm.region.amazonaws.com` エンドポイントにアタッチされていません。
+ インスタンスのサブネットが `ssmmessages.region.amazonaws.com` エンドポイントにアタッチされていません。
+ インスタンスのサブネットが `ec2messages.region.amazonaws.com` エンドポイントにアタッチされていません。
詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[VPC 設定を検証する](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration)」を参照してください。
## 問題カテゴリ: ネットワーク ACL 設定
診断オペレーションにより、VPC のネットワークアクセス制御リスト (NACL) が適切に構成されておらず、Systems Manager 通信に必要なトラフィックがブロックされている可能性があることが判明するかもしれません。NACL はステートレスであるため、アウトバウンドとインバウンドの両方のルールで Systems Manager のトラフィックを許可する必要があります。
Systems Manager は NACL 設定の問題を特定し、手動での修正手順を提供します。
**サポートされている問題タイプ**
+ **インスタンスサブネットの NACL **: システムマネージャーエンドポイントへのポート 443 のアウトバウンド通信は許可されていません
+ **インスタンスサブネット NACL **: Systems Manager 応答のための一時的ポート (1024-65535) への着信トラフィックは許可されません
**診断可能な問題タイプ**
Systems Manager は以下の NACL 構成の問題を診断できますが、手動での修正が必要です。
+ インスタンスのサブネット NACL は、Systems Manager エンドポイントへのアウトバウンド HTTPS (ポート 443) トラフィックをブロックします
+ インスタンスのサブネット NACL は、Systems Manager の応答に必要な一時ポートトラフィック (1024-65535) の受信をブロックします
詳細については、[「SSM エージェントのトラブルシューティング」](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html) および [「VPC 用のカスタムネットワーク ACL」](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports) を参照してください。
# アンマネージド EC2 インスタンスに対する診断およびオプションの修復の実行
Systems Manager が EC2 インスタンスを管理するのを妨げている可能性があるネットワーク関連および VPC 関連の問題を診断するには、次の手順を使用します。
診断オペレーションでは、以下のタイプの問題を検出してグループ化できます。
+ **[ネットワーク設定の問題]** — EC2 インスタンスがクラウド内の Systems Manager サービスと通信するのを妨げている可能性があるネットワーク問題のタイプ。これらの問題では、修復オペレーションを使用できる場合があります。ネットワーク設定の問題の詳細については、「[診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ](diagnosing-ec2-category-types.md)」を参照してください。
+ **[未確認の問題]** — EC2 インスタンスがクラウド内の Systems Manager サービスと通信できない理由を診断オペレーションによって判断できなかった場合の検出結果のリスト。
**アンマネージド EC2 インスタンスに対して診断および修復を実行する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[診断および修復]** を選択します。
1. **[アンマネージド EC2 インスタンスの問題]** タブを選択します。
1. **[問題の概要]** セクションで **[新しい診断の実行]** を選択します。
-または-
アンマネージド EC2 の問題を初めて診断する場合は、**[アンマネージド EC2 インスタンスの診断]** セクションで **[実行]** を選択します。
**ヒント**
診断の実行中に **[進行状況を表示]** または **[実行を表示]** を選択すると、実行の現在の状態をモニタリングできます。詳細については、「[Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)」を参照してください。
1. 診断が完了したら、次の操作を実行します。
+ **[未確認の問題]** セクションで報告された問題については、**[詳細]** リンクを選択すると問題の解決方法を確認できます。
+ **[ネットワーク設定の問題]** セクションで報告された問題については、次のステップに進みます。
1. 検出結果タイプのリスト内で、特定の問題に対応する **[推奨事項]** 列のリンク (**[2 つの推奨事項]** など) を選択します。
1. 開いた **[推奨事項]** ペインで、使用可能な緩和策から選択します。
+ **[詳細]** — 問題を手動で解決する方法に関する情報を含むトピックを開きます。
+ **[ランブックの表示]** – EC2 インスタンスの問題を解決するために実行できるオートメーションランブックに関する情報と、ランブックが実行するアクションの*プレビュー*を生成するためのオプションを含むペインを開きます。次のステップに進みます。
1. ランブックペインで、次の操作を実行します。
1. **[ドキュメントの説明]** で、コンテンツを確認します。コンテンツには、ランブックがアンマネージド EC2 インスタンスの問題を修復するために実行できるアクションの概要が示されています。**[ステップを表示]** を選択して、ランブックで実行される個々のアクションをプレビューします。
1. **[ターゲット]** で、以下の作業を行います。
+ 組織の修復を管理している場合は、**[アカウント]** で、このランブックがすべてのアカウントをターゲットにするか、選択したアカウントのサブセットのみをターゲットにするかを指定します。
+ **[リージョン]** で、このランブックがアカウントまたは組織内のすべての AWS リージョンをターゲットにするか、選択したリージョンのサブセットのみをターゲットにするかを指定します。
1. **[ランブックのプレビュー]** で、情報を慎重に確認します。この情報は、ランブックの実行を選択した場合の範囲と影響について説明しています。
**注記**
ランブックの実行を選択すると、料金が発生します。続行するかどうかを決定する前に、プレビュー情報を注意深く確認してください。
**[ランブックのプレビュー]** のコンテンツでは、次の情報が提供されます。
+ ランブックオペレーションが実行されるリージョンの数。
+ (組織のみ) オペレーションを実行する組織単位 (OU) の数。
+ 実行されるアクションのタイプと、各アクションの実行回数。
アクションタイプには以下のものがあります。
+ **変異**: ランブックステップは、リソースの作成、変更、または削除を行うアクションを通じて、ターゲットに変更を加えます。
+ **非変異**: ランブックステップは、リソースに関するデータを取得しますが、データに変更を加えることはありません。このカテゴリには通常、`Describe*`、`List*`、`Get*`、および同様の読み取り専用 API アクションが含まれます。
+ **未確定**: 未確定ステップは、AWS Lambda、AWS Step Functions、または AWS Systems Manager Run Command など、他のオーケストレーションサービスによって処理される実行を呼び出します。未確定ステップは、サードパーティー API を呼び出すこともあります。Systems Manager Automation は、オーケストレーションプロセスやサードパーティー API の実行結果を認識できないため、それらのステップの結果は未確定になります。
1. この時点で、次のいずれかのアクションを選択できます。
+ 停止して、ランブックを実行しない。
+ **[実行]** を選択して、既に選択したオプションを使用してランブックを実行する。
オペレーションを実行することを選択した場合は、**[進行状況を表示]** または **[実行を表示]** を選択すると、実行の現在の状態をモニタリングできます。詳細については、「[Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)」を参照してください。
# アンマネージド EC2 インスタンスの定期スキャンのスケジュール
さまざまな設定の問題によって Systems Manager が管理できない、アカウントまたは組織内の Amazon EC2 インスタンスに対して、オンデマンドスキャンを実行できます。定期的なスケジュールに従って自動的に実行されるように、このスキャンをスケジュールすることもできます。
**アンマネージド EC2 インスタンスの定期スキャンをスケジュールする手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[診断および修復]** を選択します。
1. **[アンマネージド EC2 インスタンスの問題]** タブを選択します。
1. **[アンマネージド EC2 インスタンスの診断]** セクションで、**[定期診断のスケジュール]** をオンにします。
1. **[診断頻度]** で、診断を 1 日に 1 回実行するか、週に 1 回実行するかを選択します。
1. (オプション) **[開始時刻]** に、診断を開始する時刻を 24 時間形式で入力します。例えば、午後 8:15 の場合は **20:15** と入力します。
入力する時刻は、現在のローカルタイムゾーンの時刻です。
時刻を指定しない場合、診断スキャンは即時に実行されます。Systems Manager は、今後のスキャンも現在時刻に実行されるようにスケジュールします。時刻を指定すると、Systems Manager は指定された時刻まで待ってから診断スキャンを実行します。
1. **[実行]** を選択してください。診断は即時に実行されますが、指定したスケジュールでも実行されます。
# ランブックアクションの修復の影響タイプ
Systems Manager は、特定のタイプの失敗したデプロイやドリフトした構成、および Systems Manager が EC2 インスタンスを管理するのを妨げている特定のタイプの設定の問題を検出する診断オペレーションを実行できます。診断の結果には、問題の解決を試みるために実行できるオートメーションランブックの推奨事項が含まれる場合があります。これらの診断オペレーションの詳細については、次のトピックを参照してください。
+ [失敗したデプロイの診断と修復](remediating-deployment-issues.md)
+ [ドリフトした設定の診断と修復](remediating-configuration-drift.md)
+ [Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復](remediating-unmanaged-instances.md)
Systems Manager は、影響を受けるリソースでオートメーションランブックを実行することで修正できる可能性のある問題を特定すると、*実行プレビュー*を提供します。実行プレビューでは、ランブックの実行によってターゲットにどのような*タイプ*の変更が加えられるかについての情報が提供されます。この情報には、診断によって特定された 3 つのタイプの変更それぞれの数が含まれます。
これらの変更タイプは以下のとおりです。
+ `Mutating`: ランブックステップは、リソースの作成、変更、または削除を行うアクションを通じて、ターゲットに変更を加えます。
+ `Non-Mutating`: ランブックステップは、リソースに関するデータを取得しますが、データに変更を加えることはありません。このカテゴリには通常、`Describe*`、`List*`、`Get*`、および同様の読み取り専用 API アクションが含まれます。
+ `Undetermined`: 未確定ステップは、AWS Lambda、AWS Step Functions、または AWS Systems Manager のツールである Run Command など、他のオーケストレーションサービスによって処理される実行を呼び出します。また、未確定ステップは、サードパーティー API を呼び出したり、Python や PowerShell スクリプトを実行したりする場合もあります。Systems Manager Automation は、オーケストレーションプロセスまたはサードパーティー API 実行の結果を検出できないため、それらを評価することができません。これらのステップの結果は、手動で確認して、その影響を判断する必要があります。
サポートされているオートメーションアクションの影響タイプについては、次の表を参照してください。
## サポートされている修復アクションの影響タイプ
この表は、修復ランブックに含めることができるさまざまなアクションの影響タイプ (変異、非変異、未確定) を示しています。
| アクション¹ | 影響タイプ |
| --- | --- |
| aws:approve | 非変異 |
| aws:assertAwsResourceProperty | 非変異 |
| aws:branch | 非変異 |
| aws:changeInstanceState | 変異 |
| aws:copyImage | 変異 |
| aws:createImage | 変異 |
| aws:createStack | 変異 |
| aws:createTags | 変異 |
| aws:deleteImage | 変異 |
| aws:deleteStack | 変異 |
| aws:executeAutomation | 未定 |
| aws:executeAwsApi | 未定 |
| aws:executeScript | 未定 |
| aws:executeStateMachine | 未定 |
| aws:invokeLambdaFunction | 未定 |
| aws:invokeWebhook | 未定 |
| aws:loop | 可変。ループに含まれるアクションによって異なります。 |
| aws:pause | 非変異 |
| aws:runCommand | 未定 |
| aws:runInstances | 変異 |
| aws:sleep | 非変異 |
| aws:updateVariable | 変異 |
| aws:waitForAwsResourceProperty | 非変異 |
¹ オートメーションアクションの詳細については、「[Systems Manager Automation アクションのリファレンス](automation-actions.md)」を参照してください。
# Systems Manager での修復実行の進行状況と履歴の表示
Systems Manager の **[診断および修復]** 機能を使用して実行された、すべての進行中および完了済みの修復オペレーションのリストを表示できます。
実行履歴リストのデータによって、以下のタイプの情報が報告されます。
+ 実行のタイプ: `Diagnosis` または `Remediation`。
+ 実行ステータス: `Success` や `Failed` など。
+ 実行の開始時刻と終了時刻。
**修復の実行の進行状況と履歴を表示する手順**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[診断および修復]** を選択します。
1. **[実行の表示]** を選択します。
**ヒント**
実行が進行中の場合は、**[進行状況を表示]** を選択して **[実行履歴]** ページを開くこともできます。
1. (オプション) 検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスに、**EC2** や **VPC** など、実行リストを絞り込むのに役立つフレーズを入力します。
1. (オプション) 実行に関する詳細を表示するには、**[実行名]** 列で **[AWS-DiagnoseUnmanagedEC2NetworkIssues]** などのオペレーション名を選択します。
詳細ペインでは、オペレーション中に試行されたすべてのステップ、および実行におけるすべての入力と出力に関する情報を確認できます。
# Systems Manager 設定の調整
Systems Manager 統合コンソールで **[設定]** ページのオプションを使用して、各種機能を有効にして設定できます。表示されるオプションは、ログインに使用しているアカウントと、Systems Manager を既にセットアップしているかどうかによって異なります。
**注記**
**[設定]** ページのオプションが Systems Manager のツール (これまで機能と呼ばれていたもの) に影響を与えることはありません。
## アカウントセットアップ設定
Systems Manager が有効になっている場合に、Organizations のメンバーでないアカウントでログインするか、委任管理者が Organizations アカウントを Systems Manager に追加していないと、**[アカウント設定]** ページに **[Systems Manager を無効にする]** オプションが表示されます。Systems Manager を無効にすると、Systems Manager に統合コンソールが表示されなくなります。Systems Manager ツールはいずれも引き続き機能します。
## 組織のセットアップの設定
**[組織のセットアップ]** タブの **[ホームリージョン]** セクションに、セットアップ時にホームリージョンとして選択された AWS リージョンが表示されます。AWS Organizations を使用するマルチアカウントとマルチリージョンの環境で、Systems Manager がすべてのアカウントとリージョンからホームリージョンにノードデータを自動的に集約します。このようにデータを集約すると、アカウントとリージョン全体のノードデータを 1 か所に表示できます。
**注記**
ホームリージョンを変更する場合は、Systems Manager をいったん無効にしてから再度有効にする必要があります。Systems Manager を無効にするには、**[無効化]** を選択します。
**[組織のセットアップ]** セクションに、セットアップ時に選択した AWS 組織単位と AWS リージョンが表示されます。Systems Manager にノードデータを表示する組織単位とリージョンを変更するには、**[編集]** を選択します。組織に Systems Manager をセットアップする方法の詳細については、「[AWS Systems Manager を設定する](systems-manager-setting-up-console.md)」を参照してください。
## 機能設定
**[Feature configurations]** セクションでは、組織全体のノード管理を強化する主要な Systems Manager 機能を有効にして設定できます。これらの機能は連携して、マネージドノードの自動管理、コンプライアンスモニタリング、メンテナンスを提供します。
これらの機能は、Systems Manager の初期設定時に設定するか、後で [設定] ページから変更することができます。各機能は、組織の要件に応じて個別に有効化または無効化することができます。
### デフォルトのホスト管理設定
デフォルトのホスト管理設定 (DHMC) は、Systems Manager によって管理されるように、組織内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを自動的に設定します。有効にすると、DHMC は、Systems Manager サービスと通信するために必要な AWS Identity and Access Management (IAM) アクセス許可と設定が新規および既存の EC2 インスタンスにあることを確認します。
DHMC には次の利点があります。
+ **自動 IAM ロール割り当て** – EC2 インスタンスにマネージドノードとして機能するために必要な IAM ロールとポリシーがあることを確認します。
+ **ドリフト修復** – インスタンスがマネージドノードのステータスを失うと、設定ドリフトを自動的に修正します。
+ **オンボーディングの簡素化** – 新しいインスタンスの手動設定手順を削減します。
+ **一貫した設定** – EC2 フリート全体で統一された設定を維持します。
#### ドリフト修復頻度の設定
ドリフト修復は、EC2 インスタンスがマネージドノード設定を失ったときに自動的に検出して修正します。Systems Manager が設定ドリフトをチェックして修正する頻度を設定できます。
**デフォルトのホスト管理設定を無効にするには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[設定]** を選択します。
1. **[Feature configurations]**セクションで、**[デフォルトのホスト管理設定]**を見つけます。
1. DHMC を有効にするには、トグルスイッチをオンにします。
1. **[Drift remediation frequency]** で、Systems Manager で設定ドリフトをチェックして修正する頻度を選択します。
+ **毎日** – ドリフトを 1 日に 1 回チェックして修復します。
+ **毎週** – ドリフトを週に 1 回チェックして修復します。
+ **毎月** – ドリフトを 1 か月に 1 回チェックして修復します。
1. **[保存]** を選択します。
**注記**
DHMC を有効にすると、Systems Manager は必要な IAM ロールとポリシーをアカウントに作成します。これらのロールにより、EC2 インスタンスは Systems Manager サービスと通信できます。DHMC によって作成される IAM ロールの詳細については、「[Systems Manager を利用した EC2 インスタンスの管理](systems-manager-setting-up-ec2.md)」を参照してください。
### インベントリメタデータの収集
インベントリメタデータの収集は、インストールされたアプリケーション、ネットワーク設定、システム更新、その他のシステムメタデータなど、マネージドノードに関する詳細情報を自動的に収集します。この情報は、コンプライアンスの維持、セキュリティ分析の実行、インフラストラクチャ構成の理解に役立ちます。
インベントリの収集には、次の利点があります。
+ **コンプライアンスモニタリング** – インストール済みのソフトウェアと設定をコンプライアンスレポートの目的で追跡します。
+ **セキュリティ分析** – 古いソフトウェアと潜在的なセキュリティ脆弱性を特定します。
+ **アセット管理** – インフラストラクチャの最新インベントリを維持します。
+ **クエリ機能** – Amazon Q Developer で収集されたデータを自然言語クエリに使用します。
#### 収集されるインベントリデータのタイプ
インベントリメタデータの収集を有効にすると、Systems Manager はマネージドノードから次のタイプの情報を収集します。
+ **アプリケーション** – インストール済みのソフトウェアパッケージとアプリケーション
+ **ネットワーク設定** – ネットワークインターフェイス、IP アドレス、ネットワーク設定
+ **システム更新** – インストール済みのパッチと利用可能な更新
+ **システムプロパティ** – ハードウェア仕様、オペレーティングシステムの詳細、システム設定
+ **サービス** – 実行中のサービスとその設定
#### インベントリ収集頻度の設定
Systems Manager がマネージドノードからインベントリメタデータを収集する頻度を設定できます。収集頻度が高いほど、より最新の情報が得られますが、AWS サービスの使用量が増加する可能性があります。
**インベントリメタデータの収集を有効にするには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[設定]** を選択します。
1. **[Feature configurations]** セクションで、**[Inventory metadata collection]** を見つけます。
1. インベントリの収集を有効にするには、トグルスイッチをオンにします。
1. **[データ収集の頻度]** で、Systems Manager でインベントリデータを収集する頻度を選択します。
+ **毎日** – インベントリデータを 1 日に 1 回収集します。
+ **毎週** – インベントリデータを週に 1 回収集します。
+ **毎月** – インベントリデータを 1 か月に 1 回収集します。
1. **[保存]** を選択します。
**重要**
インベントリの収集では、マネージドノードにシステム情報を収集するために必要なアクセス許可が必要です。マネージドノードに適切な IAM ロールとポリシーがあることを確認します。必要なアクセス許可の詳細については、「[AWS Systems Manager インベントリ](systems-manager-inventory.md)」を参照してください。
### SSM Agent の更新
SSM Agent の自動更新により、マネージドノードが最新バージョンの SSM Agent を実行していることが保証されます。エージェントを最新状態に保つことで、最新の機能、セキュリティ強化、バグ修正にアクセスできます。
SSM Agent の自動更新には以下の利点があります。
+ **最新の機能** – Systems Manager 新機能と機能向上へのアクセス
+ **セキュリティ更新** – セキュリティパッチと修正の自動インストール
+ **信頼性の向上** – バグ修正と安定性の向上
+ **メンテナンスの削減** – エージェントを手動で更新する必要がなくなります。
#### エージェントの自動更新の設定
Systems Manager がマネージドノードで SSM Agent の更新をチェックしてインストールする頻度を設定できます。定期的に更新することで、最適なパフォーマンスとセキュリティが保証されます。
**SSM Agent の更新を設定するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[設定]** を選択します。
1. **[Feature configurations]** セクションで、**[SSM Agent updates]** を見つけます。
1. 自動更新を有効にするには、トグルスイッチをオンにします。
1. **[更新頻度]** で、Systems Manager でエージェントの更新をチェックしてインストールする頻度を選択します。
+ **毎日** – 1 日に 1 回更新を確認します。
+ **毎週** – 1 週間に 1 回更新をチェックします。
+ **毎月** – 1 か月に 1 回更新を確認します。
1. **[保存]** を選択します。
## [診断および修復] の設定
**[診断および修復]** の設定によって、Systems Manager でノードを自動的にスキャンしてノードが Systems Manager と通信できるようにするかどうかが決まります。この機能を有効にすると、定義したスケジュールに従って機能が自動的に実行されます。これにより、Systems Manager に接続できないノードとその理由を特定できます。この機能には、ネットワークの問題のほか、ノードをマネージドノードとして設定することを阻害しているその他の問題を修復するのに適したお勧めのランブックも用意されています。
### 定期診断スキャンのスケジューリング
Systems Manager は、複数のタイプのデプロイ障害やドリフトした設定を診断することができ、それらをユーザーが修復するのに役立ちます。また、Systems Manager は、アカウント内または組織内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのうち、*マネージドノード*として扱うことができないインスタンスを特定することもできます。EC2 インスタンス診断プロセスでは、仮想プライベートクラウド (VPC)、ドメインネームサービス (DNS) 設定、または Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループの設定ミスに関連する問題を特定できます。
**[定期診断のスケジューリング]** 機能を使用して定期診断スキャンを自動化することで、Systems Manager に接続できないノードを特定するタスクを簡単に実行できます。このスキャンにより、Systems Manager に接続できないノードとその理由を特定できます。ノードの定期診断スキャンを有効にして設定するには、以下の手順に従います。
**定期診断スキャンをスケジューリングするには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[設定]**、**[診断および修復]** タブの順に選択します。
1. **[定期診断のスケジューリング]** オプションを有効にします。
1. **[スキャン期間]** でスキャンの実行頻度を選択します。
1. (オプション) **[開始時刻]** に、診断を開始する時刻を 24 時間形式で入力します。例えば、午後 8:15 の場合は **20:15** と入力します。
入力する時刻は、現在のローカルタイムゾーンの時刻です。
時刻を指定しない場合、診断スキャンは即時に実行されます。Systems Manager は、今後のスキャンも現在時刻に実行されるようにスケジュールします。時刻を指定すると、Systems Manager は指定された時刻まで待ってから診断スキャンを実行します。
1. **[保存]** を選択します。
1. スキャンが完了したら、左側のナビゲーションで **[診断および修復]** を選択して詳細を表示します。
**[診断および修復]** 機能の詳細については、「[診断と修復](diagnose-and-remediate.md)」を参照してください。
### S3 バケット暗号化の更新
Systems Manager をオンボーディングすると、AWS Organizations セットアップ用の委任管理者アカウントに Quick Setup によって Amazon Simple Storage Service (Amazon S3) バケットが作成されます。シングルアカウントセットアップの場合、バケットはセットアップされるアカウントに保存されます。このバケットは、診断スキャン中に生成されたメタデータを保存するために使用されます。
Systems Manager の統合コンソールのセットアップ方法については、「[AWS Systems Manager を設定する](systems-manager-setting-up-console.md)」を参照してください。
デフォルトでは、バケット内のデータは AWS がユーザーに代わって所有および管理する AWS Key Management Service (AWS KMS) キーを使用して暗号化されます。
これとは別の AWS KMS キーをバケットの暗号化に使用することもできます。例えば、カスタマーマネージドキー (CMK) を使用して、AWS KMS keysによるサーバー側の暗号化 (SSE-KMS) を使用するという方法があります。詳細については、「[Systems Manager での Amazon S3 バケットとバケットポリシーの使用](systems-manager-diagnosis-metadata-bucket.md)」を参照してください。
**S3 バケットの暗号化に別の AWS KMS キーを使用するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、**[設定]**、**[診断および修復]** タブの順に選択します。
1. **[S3 バケットの暗号化の更新]** 領域で、**[編集]** を選択します。
1. **[暗号化設定のカスタマイズ (高度)]** チェックボックスを選択します。
1. **[AWS KMS キーの選択]** でそのキーの Amazon リソースネーム (ARN) を選択または入力します。
**ヒント**
新しいキーを作成するには、**[AWS KMS キーを作成]** を選択します。
1. **[保存]** を選択します。
# Systems Manager での Amazon S3 バケットとバケットポリシーの使用
AWS Systems Manager の[オンボーディングプロセス](systems-manager-setting-up-console.md)時に、Quick Setup によって組織セットアップ用に Amazon Simple Storage Service (Amazon S3) バケットが委任管理者アカウントに作成されます。シングルアカウントセットアップの場合、バケットはセットアップされるアカウントに保存されます。
Systems Manager を使用してフリートで診断オペレーションを実行することで、デプロイが失敗して設定がドリフトした原因を特定できます。Systems Manager では、設定の問題のために Systems Manager がアカウントや組織の EC2 インスタンスを管理できないケースも検出できます。こうした診断オペレーションの結果は、この Amazon S3 バケットに保存され、暗号化方法と S3 バケットポリシーの両方で保護されます。このバケットにデータを出力する診断オペレーションについては、「[診断と修復](diagnose-and-remediate.md)」を参照してください。
**バケット暗号化方法の変更**
デフォルトでは、S3 バケットは Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用します。
「[S3 リソースを暗号化するための AWS KMS カスタマーマネージドキーへの変更](remediate-s3-bucket-encryption.md)」で説明しているように、Amazon S3 マネージドキーの代わりにカスタマーマネージドキー (CMK) を使用して、AWS KMS keys (SSE-KMS) でサーバー側の暗号化を使用することもできます。
**バケットポリシーの内容**
バケットポリシーを使用すると、組織内のメンバーアカウントが互いに検出することを防ぐことができます。バケットに対する読み取りおよび書き込み許可は、Systems Manager に対して作成された診断および修復ロールにのみ許可されます。こうしたシステム生成のポリシーの内容については、「[Systems Manager 統合コンソールの S3 バケットポリシー](remediate-s3-bucket-policies.md)」を参照してください。
**警告**
デフォルトのバケットポリシーを変更すると、組織内のメンバーアカウントが相互に発見したり、他のアカウントのインスタンスの診断出力を読み取ったりできるようになる可能性があります。このポリシーを変更する場合は、細心の注意を払うことをお勧めします。
**Topics**
+ [S3 リソースを暗号化するための AWS KMS カスタマーマネージドキーへの変更](remediate-s3-bucket-encryption.md)
+ [Systems Manager 統合コンソールの S3 バケットポリシー](remediate-s3-bucket-policies.md)
# S3 リソースを暗号化するための AWS KMS カスタマーマネージドキーへの変更
Systems Manager の統合コンソールのオンボーディングプロセス中に、Quick Setup は委任管理者アカウントに Amazon Simple Storage Service (Amazon S3) バケットを作成します。このバケットは、修復ランブックの実行中に生成された診断出力データを保存するために使用されます。デフォルトでは、このバケットは Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用します。
これらのポリシーのコンテンツについては、「[Systems Manager 統合コンソールの S3 バケットポリシー](remediate-s3-bucket-policies.md)」を参照してください。
ただし、AWS KMS keyの代わりにカスタマーマネージドキー (CMK) を使用して、AWS KMS keysによるサーバー側の暗号化 (SSE-KMS) を使用することもできます。
CMK を使用するように Systems Manager を設定するには、以下のタスクを実行します。
## タスク 1: 既存の CMK にタグを追加する
AWS Systems Manager は、次のキーと値のペアでタグ付けされている場合にのみ CMK を使用します。
+ キー: `SystemsManagerManaged`
+ 値: `true`
次の手順を使用して、CMK で S3 バケットを暗号化するためのアクセス権を付与します。
**既存の CMK にタグを追加する手順**
1. AWS KMS コンソール ([https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms)) を開きます。
1. 左のナビゲーションで、**[カスタマーマネージドキー]** を選択します。
1. AWS Systems Manager で使用する AWS KMS keyを選択します。
1. **[タグ]** タブを選択し、次に **[編集]** を選択します。
1. **[タグを追加]** を選択します。
1. 以下の操作を実行します。
1. [**Tag key (タグキー)**] に、**SystemsManagerManaged** と入力します。
1. **[タグ値]** に **true** と入力します。
1. **[保存]** を選択します。
## タスク 2: 既存の CMK キーポリシーを変更する
次の手順を使用して、AWS Systems Manager のロールがユーザーの代わりに S3 バケットを暗号化できるように、CMK の [KMS キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)を更新します。
**既存の CMK キーポリシーを変更する手順**
1. AWS KMS コンソール ([https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms)) を開きます。
1. 左のナビゲーションで、**[カスタマーマネージドキー]** を選択します。
1. AWS Systems Manager で使用する AWS KMS keyを選択します。
1. **アクセスポリシー** タブで **編集** を選択します。
1. 次の JSON ステートメントを `Statement` フィールドに追加し、*プレースホルダー値*を独自の情報に置き換えます。
AWS Systems Manager にオンボーディングされている組織内のすべての AWS アカウント ID を、`Principal` フィールドに追加する必要があります。
Amazon S3 コンソールで正しいバケット名を見つけるには、委任管理者アカウントで、`do-not-delete-ssm-operational-account-id-home-region-disambiguator` の形式のバケットを探します。
```
{
"Sid": "EncryptionForSystemsManagerS3Bucket",
"Effect": "Allow",
"Principal": {
"AWS": [
"account-id-1",
"account-id-2",
...
]
},
"Action": ["kms:Decrypt", "kms:GenerateDataKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket"
},
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/AWS-SSM-*"
}
}
}
```
**ヒント**
または、[aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) 条件キーを使用して CMK キーポリシーを更新することにより、AWS Systems Manager に CMK へのアクセスを許可することもできます。
## タスク 3: Systems Manager 設定で CMK を指定する
上記の 2 つのタスクを完了したら、次の手順を使用して S3 バケットの暗号化を変更します。この変更により、関連付けられた Quick Setup 設定プロセスで、Systems Manager が CMK を受け入れるためのアクセス許可を追加できるようになります。
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[設定]** を選択します。
1. **[診断および修復]** タブの **[S3 バケットの暗号化の更新]** セクションで、**[編集]** を選択します。
1. **[暗号化設定のカスタマイズ (高度)]** チェックボックスを選択します。
1. 検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスで、既存のキーの ID を選択するか、既存のキーの ARN を貼り付けます。
1. **[保存]** を選択します。
# Systems Manager 統合コンソールの S3 バケットポリシー
このトピックでは、組織または単一アカウントを Systems Manager 統合コンソールにオンボーディングする際に Systems Manager によって作成される Amazon S3 バケットポリシーについて説明します。
**警告**
デフォルトのバケットポリシーを変更すると、組織内のメンバーアカウントが相互に発見したり、他のアカウントのインスタンスの診断出力を読み取ったりできるようになる可能性があります。このポリシーを変更する場合は、細心の注意を払うことをお勧めします。
## 組織の Amazon S3 バケットポリシー
診断バケットは、組織を Systems Manager にオンボーディングする際に、次のデフォルトのバケットポリシーを使用して作成されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
},
{
"Sid": "AllowAccessLog",
"Effect": "Allow",
"Principal": {
"Service": "logging.s3.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/access-logs/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "000000000000"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
},
{
"Sid": "AllowCrossAccountRead",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
},
{
"Sid": "AllowCrossAccountWrite",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/actions/*/${aws:PrincipalAccount}/*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/AWS-SSM-DiagnosisExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-DiagnosisAdminRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationExecutionRole-operational-123456789012-home-region",
"arn:aws:iam::*:role/AWS-SSM-RemediationAdminRole-operational-123456789012-home-region"
]
}
}
},
{
"Sid": "AllowCrossAccountListUnderAccountOwnPrefix",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
},
"StringLike": {
"s3:prefix": "*/${aws:PrincipalAccount}/*"
}
}
},
{
"Sid": "AllowCrossAccountGetConfigWithinOrganization",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetEncryptionConfiguration",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "organization-id"
}
}
}
]
}
```
------
## 単一アカウントの Amazon S3 バケットポリシー
診断バケットは、単一アカウントを Systems Manager にオンボーディングする際に、次のデフォルトのバケットポリシーを使用して作成されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyHTTPRequests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyNonSigV4Requests",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringNotEquals": {
"s3:SignatureVersion": "AWS4-HMAC-SHA256"
}
}
}
]
}
```
------