• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# 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 ポリシーの変更、構成設定を詳細に記録します。
+ **モニタリングして調整する** - アクセスリクエストと承認ワークフローを継続的にモニタリングし、必要に応じてポリシーを調整します。
+ **ガバナンスを確立する** - 承認ポリシーを定期的にレビューし、環境の変化に応じて更新するためのプロセスを作成します。