

• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。

# Systems Manager のセキュリティに関するベストプラクティス
<a name="security-best-practices"></a>

AWS Systems Manager には、独自のセキュリティポリシーを開発および実装する際に考慮する必要のあるいくつかのセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションに相当するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。

**Topics**
+ [Systems Manager の予防的セキュリティのベストプラクティス](#security-best-practices-prevent)
+ [SSM Agent のインストールのベストプラクティス](#security-best-practices-ssm-agent)
+ [Systems Manager のモニタリングと監査のベストプラクティス](#security-best-practices-detect)

## Systems Manager の予防的セキュリティのベストプラクティス
<a name="security-best-practices-prevent"></a>

Systems Manager の以下のベストプラクティスはセキュリティ問題を防ぐのに役立ちます。

**最小特権アクセスの実装**  
アクセス許可を付与する場合、どのユーザーにどの Systems Manager リソースに対するアクセス許可を付与するかは、お客様が決定します。つまり、該当リソースに対して許可する特定のアクションを許可するということです。このため、タスクの実行に必要なアクセス許可のみを付与する必要があります。最小限の特権アクセスの実装は、セキュリティリスクはもちろん、エラーや悪意ある行動によってもたらされる可能性のある影響を減らす上での基本となります。  
以下のツールは、最小限の特権アクセスを実装するために使用できます。  
+ [IAM ユーザーポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)と [IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)

**プロキシを使用する設定になっている場合は、SSM Agent の推奨設定を使用します。**  
プロキシを使用するように SSM Agent を設定する場合は、Systems Manager インスタンスメタデータサービスの IP アドレスを持つ `no_proxy` 変数を使用し、Systems Manager への呼び出しがプロキシサービスのアイデンティティを引き受けないようにします。  
詳細については、「[Linux ノードでプロキシを使用するための SSM Agent の設定](configure-proxy-ssm-agent.md)」および「[SSM Agent が Windows Server インスタンス用にプロキシを使用するように設定する](configure-proxy-ssm-agent-windows.md)」を参照してください。

**SecureString パラメータを使用して機密データを暗号化および保護する**  
AWS Systems Manager のツールである Parameter Store にある `SecureString` パラメータは、セキュアな方法で保存および参照する必要のある機密データです。パスワードやライセンスキーなどプレーンテキストで、ユーザーに変更または参照させたくないデータがある場合は、`SecureString` データ型を使用してこれらのパラメータを作成します。Parameter Store は AWS Key Management Service (AWS KMS) で AWS KMS key を使用してパラメータ値を暗号化します。AWS KMS は、パラメータ値を暗号化する際、カスタマーマネージドキーまたは AWS マネージドキー のいずれかを使用します。セキュリティを最大限に高めるため、独自の KMS キーを使用することをお勧めします。AWS マネージドキー を使用する場合、アカウントで [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) アクションと [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) アクションを実行する権限のあるユーザーは、すべての `SecureString` パラメータのコンテンツを表示または取得できます。カスタマーマネージドキーを使用してセキュアな `SecureString` 値を暗号化する場合、IAM ポリシーとキーポリシーを使用して、パラメータの暗号化と復号化のアクセス許可を管理できます。  
AWS マネージドキー を使用する場合、これらのオペレーションのためにアクセスコントロールポリシーを確立することはより困難です。例えば、AWS マネージドキー を使用して `SecureString` パラメータを暗号化し、ユーザーが `SecureString` パラメータを操作しないようにする場合は、ユーザーの IAM ポリシーでデフォルトキーへのアクセスを明示的に拒否する必要があります。  
詳細については、*AWS Key Management Service デベロッパーガイド*の「[IAM ポリシーを使用して Parameter Store パラメータへのアクセスを制限する](sysman-paramstore-access.md)」と「[AWS Systems ManagerParameter Store が AWS KMS を使用する方法](https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html)」を参照してください。

**ドキュメントパラメータの allowedValues および allowedPattern を定義する**  
`allowedValues` および `allowedPattern` を定義することで、Systems Manager ドキュメント （SSM ドキュメント) のパラメータのユーザー入力を検証できます。`allowedValues` では、パラメータに使用できる値の配列を定義します。使用できない値をユーザーが入力すると、実行の開始に失敗します。`allowedPattern` では、ユーザー入力がパラメータに対して定義されたパターンと一致するかどうかを検証する正規表現を定義します。ユーザー入力が使用できるパターンと一致しない場合、実行は開始されません。  
`allowedValues` と `allowedPattern` の詳細については、「[データ要素とパラメータ](documents-syntax-data-elements-parameters.md)」を参照してください。

**ドキュメントのパブリック共有をブロックする**  
ユースケースでパブリック共有を有効にする必要がある場合を除き、Systems Manager ドキュメントコンソールの [**Preferences**] (詳細設定) セクションで、SSM ドキュメントのパブリック共有のブロックの設定をオンにすることをお勧めします。

**Amazon Virtual Private Cloud (Amazon VPC) および VPC エンドポイントを使用する**  
Amazon VPC を使用して、定義した仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、 のスケーラブルなインフラストラクチャを使用できるというメリットがありますAWS  
VPC エンドポイントを実装することにより、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続の必要なく、AWS PrivateLink でサポートされる AWS のサービスおよび VPC エンドポイントサービスに VPC を非公開で接続できます。VPC のインスタンスでは、サービスのリソースと通信するためにパブリック IP アドレスを必要としません。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れることはありません。  
Amazon VPC セキュリティの詳細については、「Amazon VPC ユーザーガイド」の「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)」および「[Amazon VPC のインターネットワークトラフィックのプライバシー](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html)」を参照してください。

**Session Manager ユーザーを、対話型コマンドと特定の SSM セッションドキュメントを使用しているセッションに限定する**  
AWS Systems Manager のツールである Session Manager はマネージドノードに[セッションを開始する複数の方法](session-manager-working-with-sessions-start.md)を提供します。最も安全な接続を実現するため、*対話型コマンド*方式を使用して接続するようにユーザーに要求し、ユーザーの操作を特定のコマンドまたはコマンドシーケンスに制限できます。これにより、ユーザーが実行できる対話型アクションを管理できます。詳細については、「[セッションの開始 (対話形式と非対話形式のコマンド)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands)」を参照してください。  
セキュリティを強化するために、特定の Amazon EC2 Session Manager インスタンスと特定の Session Manager セッションドキュメントへのアクセスを制限できます。この方法で、AWS Identity and Access Management (IAM) Session Manager ポリシーを使用してアクセスを許可または取り消すことができます。詳細については、「[ステップ 3: マネージドノードへのセッションアクセスを制御](session-manager-getting-started-restrict-access.md)」を参照してください。

**オートメーション ワークフローに対して一時的なノード許可を付与します**  
AWS Systems Manager のツールである Automation のワークフロー中に、その実行のためにのみ、ノードが許可を必要とする場合がありますが、他の Systems Manager オペレーションには不要です。例えばオートメーション ワークフローでは、特定の API オペレーションを呼び出すためのノードに加え、特にワークフロー中では AWS リソースへのアクセスなどが必要となる場合があります。このような呼び出しまたはリソースへのアクセスを制限する場合、IAM インスタンスプロファイルにアクセス許可を追加する代わりに、オートメーション ランブック自体の中にあるノードに対して一時的かつ付随するアクセス許可を付与できます。Automation のワークフローが終了すると、一時的なアクセス許可は削除されます。詳細については、 *AWS Management and Governance Blog* の「[Providing temporary instance permissions with AWS Systems Manager Automations](https://aws.amazon.com/blogs/mt/providing-temporary-instance-permissions-with-aws-systems-manager-automations/)」を参照してください。

**AWS と Systems Manager ツールを最新の状態に維持する**  
AWS は、AWS および Systems Manager オペレーションで使用できるツールおよびプラグインの更新バージョンを定期的にリリースします。これらのリソースを最新の状態に維持することで、アカウント内のユーザーとノードがこれらツールの最新の機能性やセキュリティ機能にアクセスできるようにします。  
+ SSM Agent – AWS Systems Manager エージェント (SSM Agent) は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、オンプレミスサーバー、仮想マシン (VM) にインストールして設定することができる Amazon のソフトウェアです。SSM Agent により、Systems Manager がこれらのリソースを更新、管理、設定できるようなります。少なくとも 2 週間ごとに新しいバージョンをチェックするか、エージェントの更新を自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。また、更新プロセスの一環として SSM Agent の署名を確認することをお勧めします。詳細については、「[SSM Agent の署名の確認](verify-agent-signature.md)」を参照してください。
+ AWS CLI – AWS Command Line Interface (AWS CLI) は、コマンドラインシェルでコマンドを使用して AWS のサービスとやり取りするためのオープンソースツールです。AWS CLI を更新するには、AWS CLI のインストールに使用したコマンドと同じコマンドを実行します。オペレーティングシステムに適したコマンドを実行するために、少なくとも 2 週間に 1 回ローカルマシンでスケジュールされたタスクを作成することをお勧めします。インストールコマンドの詳細については、*AWS Command Line Interface ユーザーガイド*の「[AWS CLI バージョン 2 のインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ AWS Tools for Windows PowerShell – Tools for Windows PowerShell は、AWS SDK for .NET によって公開されている機能を基盤として構築された PowerShell モジュールです。AWS Tools for Windows PowerShell を使用することにより、PowerShell コマンドラインから AWS リソースに対する操作をスクリプト処理できます。または Tools for Windows PowerShell のアップデートバージョンが定期的にリリースされているため、ローカルで実行しているバージョンを更新する必要があります。詳細については、*IAM ポリシーシミュレーターユーザーガイド*の「[Updating the AWS Tools for Windows PowerShell on Windows](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up-windows.html#pstools-updating)」または「[Updating the AWS Tools for Windows PowerShell on Linux or macOS](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up-linux-mac.html#pstools-updating-linux)」 を参照してください。
+ Session Manager プラグイン – Session Manager を使用する許可を持つ組織内のユーザーが AWS CLI を使用してノードに接続を希望する場合、まずユーザーのローカルマシンに Session Manager のプラグインをインストールする必要があります。プラグインを更新するには、プラグインのインストールに使用したのと同じコマンドを実行します。オペレーティングシステムに適したコマンドを実行するために、少なくとも 2 週間に 1 回ローカルマシンでスケジュールされたタスクを作成することをお勧めします。詳細については、[AWS CLI 用の Session Manager プラグインをインストールする](session-manager-working-with-install-plugin.md) を参照してください。
+ CloudWatch エージェント – CloudWatch エージェントを設定および使用すると、EC2 インスタンス、オンプレミスインスタンス、仮想マシン (VM) からメトリクスとログを収集できます。これらのログは、モニタリングおよび分析のために Amazon CloudWatch Logs に送信できます。少なくとも 2 週間ごとに新しいバージョンをチェックするか、エージェントの更新を自動化することをお勧めします。最も簡単な更新を行うには、AWS Systems Manager Quick Setup を使用します。詳細については、「[AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)」を参照してください。

## SSM Agent のインストールのベストプラクティス
<a name="security-best-practices-ssm-agent"></a>

SSM Agent をインストールするときは、マシンタイプに適したインストール方法を使用します。特に、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境のすべての非 EC2 インストールには `ssm-setup-cli` ツールを使用します。このツールは、非 EC2 マシンに追加のセキュリティ保護を提供します。

エージェントをオンプレミスサーバーおよび仮想マシンにインストールするには、以下のトピックで説明されているように `ssm-setup-cli` ツールを使用します。
+ [ハイブリッド Linux ノードで SSM Agent をインストールする](hybrid-multicloud-ssm-agent-install-linux.md)
+ [ハイブリッド Windows Server ノードに SSM Agent をインストールする](hybrid-multicloud-ssm-agent-install-windows.md)

エージェントを EC2 インスタンスにインストールするには、オペレーティングシステムのタイプに適したインストール手順を使用します。
+ [Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-linux.md)
+ [macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-macos.md)
+ [Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](manually-install-ssm-agent-windows.md)

## Systems Manager のモニタリングと監査のベストプラクティス
<a name="security-best-practices-detect"></a>

以下の Systems Manager のベストプラクティスは、潜在的なセキュリティ上の弱点とインシデントを検出するのに役立ちます。

**Systems Manager のすべてのリソースの特定と監査**  
IT アセットの特定はガバナンスとセキュリティの重要な側面です。セキュリティの状態を評価し、潜在的な弱点に対処するには、すべての Systems Manager リソースを特定する必要があります。  
タグエディターを使用してセキュリティまたは監査で注意を要するリソースを識別してから、それらのタグを、リソースを検索する必要があるときに使用します。詳細については、*AWS Resource Groups ユーザーガイド*の「[タグ付けするリソースの検索](https://docs.aws.amazon.com/ARG/latest/userguide/find-resources-to-tag.html)」を参照してください。  
Systems Manager リソースのリソースグループを作成します。詳細については、 [リソースグループとは](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)を参照してください。

**Amazon CloudWatch モニタリングツールを使用したモニタリングの実装**  
モニタリングは、Systems Manager および AWS ソリューションの信頼性、セキュリティ、可用性、パフォーマンスを維持する上で重要です。Amazon CloudWatch には、Systems Manager と他の AWS のサービスのモニタリングに役立つツールとサービスが含まれています。詳細については、「[統合された CloudWatch Logs へのノードログの送信 (CloudWatch エージェント)](monitoring-cloudwatch-agent.md)」および「[Amazon EventBridge を使用して Systems Manager イベントをモニタリングする](monitoring-eventbridge-events.md)」を参照してください。

**CloudTrail の使用**  
AWS CloudTrail は、Systems Manager のユーザー、ロール、または AWS のサービスによって実行されたアクションのレコードを提供します。CloudTrail で収集した情報を使用して、Systems Manager に対して行ったリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。詳細については、「[AWS CloudTrail による AWS Systems Manager API コールのログ記録](monitoring-cloudtrail-logs.md)」を参照してください。

**AWS Config をオンにする**  
AWS Config を使用すると、AWS リソースの設定を評価して監査することができます。AWS Config はリソースの設定を監視し、必要となるセキュアな設定に照らし合わせて、記録された設定を評価できます。AWS Config を使用すると、AWS リソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定に対して、全体的なコンプライアンスを確認できます。これにより、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できます。詳細については、[AWS Config デベロッパーガイド](https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html)の*コンソールを使用した AWS Config の設定* を参照してください。記録するリソースタイプを指定するときは、必ず Systems Manager リソースを含めてください。

**AWS セキュリティアドバイザリを監視する**  
AWS アカウント について Trusted Advisor に投稿されたセキュリティ勧告を定期的に確認してください。これは、[describe-trusted-advisor-checks](https://docs.aws.amazon.com/cli/latest/reference/support/describe-trusted-advisor-checks.html) を使用してプログラムにより行うことができます。  
さらに、各 AWS アカウント に登録されているメインの E メールアドレスを注意してモニタリングしてください。AWS は、この E メールアドレスを使用して、お客様に影響を与える可能性のあるセキュリティ問題が新たに発生した場合に連絡します。  
広範な影響を与える AWS の運用上の問題は [AWS Service Health Dashboard](https://status.aws.amazon.com/) に投稿されます。運用上の問題は Personal Health ダッシュボードを介して個々のアカウントにも投稿されます。詳細については、[AWS Health のドキュメント](https://docs.aws.amazon.com/health/)を参照してください。

**詳細情報**  
+ [セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス](https://aws.amazon.com/architecture/security-identity-compliance/)
+ [開始する: AWS リソースの設定時にセキュリティのベストプラクティスに従う](https://aws.amazon.com/blogs/security/getting-started-follow-security-best-practices-as-you-configure-your-aws-resources/) (AWS セキュリティブログ)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [AWS CloudTrail でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html)
+ [Amazon S3 のセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)
+ [AWS Key Management Service のセキュリティのベストプラクティス](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html)