• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# SSM Agent に関する技術的な詳細を知る
このトピックの情報を使用して、AWS Systems Manager Agent (SSM Agent) を実装し、エージェントの仕組みを理解するのに役立ちます。
**Topics**
+ [SSM Agent バージョン 3.2.x.x 認証情報の動作](#credentials-file)
+ [SSM Agent 認証情報の優先順位](#credentials-precedence)
+ [連邦情報処理規格 (FIPS) での使用のための SSM Agent の設定](#fips-compliant-configurations)
+ [ローカル ssm-user アカウントについて](#ssm-user-account)
+ [SSM Agentと Instance Metadata Service (IMDS)](#imds)
+ [SSM Agent を最新の状態に維持](#updating)
+ [SSM Agent インストールディレクトリが変更、移動、削除されていないことの確認](#installation-directory)
+ [AWS リージョン による SSM Agent のローリング更新](#rolling-updates)
+ [SSM Agent と AWS マネージド S3 バケットとの通信](#ssm-agent-minimum-s3-permissions)
+ [GitHub での SSM Agent](#github)
+ [SSM Agent の休止について](#ssm-agent-hibernation)
## SSM Agent バージョン 3.2.x.x 認証情報の動作
インスタンスが、Quick Setup のデフォルトのホスト管理設定を使用してオンボーディングされた場合、SSM Agent は一時的な認証情報のセットを `/var/lib/amazon/ssm/credentials` (Linux と macOS の場合)、または `%PROGRAMFILES%\Amazon\SSM\credentials` (Windows Server の場合) に格納します。一時的な認証情報には、デフォルトのホスト管理設定で選択した IAM ロールに指定した許可が含まれます。Linux では、これらの認証情報にアクセスできるのは、root アカウントだけです。Windows Server では、SYSTEM アカウントとローカル管理者のみがこれらの認証情報にアクセスできます。
## SSM Agent 認証情報の優先順位
このトピックは SSM Agent がリソースにアクションを実行するためにどのようにアクセス許可が付与されるか、重要な情報について説明します。
**注記**
エッジデバイスのサポートは少し異なります。AWS IoT Greengrass コアソフトウェアを使用できようにエッジデバイスを設定、AWS Identity and Access Management (IAM) サービスロールを設定、AWS IoT Greengrass を使って SSM Agent をデバイスに展開する必要があります。詳細については、「[Systems Manager を利用したエッジデバイスの管理](systems-manager-setting-up-edge-devices.md)」を参照してください。
SSM Agent がマシンにインストールされている場合、Systems Manager サービスと通信するにはアクセス許可が必要です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでは、このようなアクセス許可は、インスタンスにアタッチされたインスタンスプロファイルで提供されます。非 EC2 マシンの場合、SSM Agent は通常、必要な許可を共有認証情報ファイルから取得し、`/root/.aws/credentials` (Linux と macOS) または `%USERPROFILE%\.aws\credentials` (Windows Server) に保存されています。必要な許可は、[ハイブリッドアクティベーション](activations.md)プロセス中にこのファイルに追加されます。ハイブリッドアクティベーションノードの登録が解除されると、エージェントは休止モードになる可能性があります。詳細については、「[SSM Agent の休止について](#ssm-agent-hibernation)」を参照してください。
ただし、まれに、SSM Agent がタスクを実行するための許可をチェックする複数の場所に、マシンの許可が追加されてしまうことがあります。
例えば、Systems Manager によって管理されるように EC2 インスタンスを設定したとします。その設定にはインスタンスプロファイルのアタッチが含まれます。しかし、そのインスタンスをデベロッパーまたはエンドユーザーのタスクにも使用し、そのインスタンス に AWS Command Line Interface (AWS CLI) をインストールすることにしました。このインストールでは、インスタンス上の認証情報ファイルに追加のアクセス許可が追加されます。
インスタンスで Systems Manager コマンドを実行すると、SSM Agent は、インスタンスプロファイルではなく認証情報ファイルからの認証情報など、使用する想定とは異なる認証情報を使用しようとすることがあります。これは、SSM Agent が*デフォルトの資格情報プロバイダーチェーン*に規定された順序で資格情報を検索するためです。
**注記**
Linux と macOS では、SSM Agent はルートユーザーとして実行されます。したがって、このプロセスで SSM Agent が検索する環境変数と認証情報ファイルは、ルートユーザーのみのものです (`/root/.aws/credentials`)。SSM Agent は、認証情報の検索中に、インスタンス上の他のユーザーの環境変数や認証情報ファイルを参照しません。
デフォルトのプロバイダーチェーンは、次の順序で認証情報を検索します。
1. 環境変数 (設定されている場合) (`AWS_ACCESS_KEY_ID` および `AWS_SECRET_ACCESS_KEY`)。
1. ハイブリッド環境のアクティベーションや AWS CLI のインストールなどによって提供されるアクセス許可を持つ共有認証情報ファイル (Linux と macOS の場合は `$HOME/.aws/credentials`、Windows Server の場合は `%USERPROFILE%\.aws\credentials`)。
1. Amazon Elastic Container Service (Amazon ECS) タスク定義または **RunTask** API オペレーションを使用するアプリケーションが存在する場合、タスクの AWS Identity and Access Management (IAM) ロール。
1. Amazon EC2 インスタンスにアタッチされたインスタンスプロファイル。
1. デフォルトのホスト管理構成用に選択された IAM ロール。
関連情報については、次のトピックを参照してください。
+ EC2 インスタンスのインスタンスプロファイル — [Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)
+ ハイブリッドアクティベーション – [ハイブリッドアクティベーションを作成して、Systems Manager にノードを登録する](hybrid-activation-managed-nodes.md)
+ AWS CLI クレデンシャルファイル – *AWS Command Line Interface ユーザーガイド*の「[設定と認証情報ファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」
+ デフォルトの認証情報プロバイダーチェーン – *AWS SDK for Go デベロッパーガイド*の「[認証情報の指定](https://docs.aws.amazon.com/sdk-for-go/latest/developer-guide/configuring-sdk.html#specifying-credentials)」
**注記**
*AWS SDK for Go デベロッパーガイド*のこのトピックでは、SDK for Go に関するデフォルトのプロバイダーチェーンについて説明します。ただし、SSM Agent の認証情報の評価にも同じ原則が適用されます。
## 連邦情報処理規格 (FIPS) での使用のための SSM Agent の設定
Systems Manager を連邦情報処理規格 (FIPS) 140-3 検証済み暗号化モジュールで使用する必要がある場合は、サポートされているリージョン内の FIPS エンドポイントを使用するように AWS Systems Manager Agent (SSM Agent) を設定することができます。
**FIPS 140-3 エンドポイントに接続するように SSM Agent を設定する**
1. マネージドノードに接続します。
1. `amazon-ssm-agent.json` ファイルが格納されているディレクトリに移動します。
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM\`
1. 編集する `amazon-ssm-agent.json` という名前のファイルを開きます。
**ヒント**
`amazon-ssm-agent.json` ファイルがまだ存在していない場合は、`amazon-ssm-agent.json.template` のコンテンツを `amazon-ssm-agent.json` という名前の新しいファイルにコピーします。`amazon-ssm-agent.json.template` と同じディレクトリに `amazon-ssm-agent.json` を保存します。
1. ファイルに次のコンテンツを追加します。{{region}} のプレースホルダー値を、パーティションに適したリージョンコードに置き換えます:
```
{
---Existing file content, if any---
"Mds": {
"Endpoint": "ec2messages-fips.{{region}}.amazonaws.com",
},
"Ssm": {
"Endpoint": "ssm-fips.{{region}}.amazonaws.com",
},
"Mgs": {
"Endpoint": "ssmmessages-fips.{{region}}.amazonaws.com",
"Region": "{{region}}"
},
"S3": {
"Endpoint": "s3-fips.dualstack.{{region}}.amazonaws.com",
"Region": {{region}}"
},
"Kms": {
"Endpoint": "kms-fips.{{region}}.amazonaws.com"
}
}
```
サポートされるリージョンには以下が含まれます。
+ `us-east-1` (米国東部 (バージニア北部) リージョンの場合)
+ `us-east-2` (米国東部 (オハイオ) リージョンの場合)
+ `us-west-1` (米国西部 (北カリフォルニア) リージョンの場合)
+ `us-west-2` (米国西部 (オレゴン) リージョンの場合)
+ `ca-west-1` (カナダ西部 (カルガリー) リージョンの場合)
1. ファイルを保存して、SSM Agent を再起動します。
設定を変更するたびに、SSM Agent を再起動します。
同じ手順を使用して、SSM Agent の他の機能をカスタマイズできます。利用可能な設定プロパティとそのデフォルト値の最新リストについては、GitHub の `amazon-ssm-agent` リポジトリで「[Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions)」を参照してください。
FIPS に対する AWS サポートの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
## ローカル ssm-user アカウントについて
SSM Agent バージョン 2.3.50.0 以降では、エージェントは `ssm-user` という名前のローカルユーザーアカウントを作成し、`/etc/sudoers.d` ディレクトリ (Linux と macOS) または、管理者グループ (Windows Server) に追加します。2.3.612.0 より前のエージェントバージョンでは、アカウントはインストール後に SSM Agent が最初に起動または再起動するときに作成されます。バージョン 2.3.612.0 以降では、`ssm-user` アカウントは、インスタンスでセッションが最初に開始されたときに作成されます。この `ssm-user` は、AWS Systems Manager のツールである Session Manager でセッションが開始されたときのデフォルトの OS ユーザーです。`ssm-user` を特権の少ないグループに移動するか、`sudoers` ファイルを変更することで、アクセス許可を変更できます。SSM Agent がアンインストールされるときに、`ssm-user` アカウントはシステムから削除されません。
Windows Server では、SSM Agent は各セッションの開始時に `ssm-user` アカウントの新しいパスワードの設定を処理します。Linux マネージドインスタンスで `ssm-user` にはパスワードは設定されていません。
SSM Agent 2.3.612.0 バージョンから、`ssm-user` アカウントは、ドメインコントローラーとして使用されている Windows Server マシンに自動的には作成されません。Session Manager ドメインコントローラーで Windows Server を使用するには、`ssm-user` アカウントが存在しない場合は手動でアカウントを作成し、ドメイン管理者のアクセス許可をユーザーに割り当てます。
**重要**
`ssm-user` アカウントを作成するには、インスタンスに添付されたインスタンスプロファイルによって、必要なアクセス許可が付与される必要があります。詳細については、「[ステップ 2: Session Managerのインスタンスのアクセス権限の確認または追加](session-manager-getting-started-instance-profile.md)」を参照してください。
## SSM Agentと Instance Metadata Service (IMDS)
Systems Manager の正常な機能は、EC2 インスタンスメタデータに左右されます。Systems Manager は、Instance Metadata Service (IMDSv1 および IMDSv2) のバージョン 1 またはバージョン 2 を使用して、インスタンスメタデータにアクセスできます。インスタンスはインスタンスメタデータサービスの IPv4 アドレスにアクセスできる必要があります: 169.254.169.254。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Instance Metadata and User Data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」を参照してください。
## SSM Agent を最新の状態に維持
新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。
**注記**
新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。
デフォルトで SSM Agentが含まれている Amazon Machine Images (AMIs) は、最新バージョンの SSM Agentで更新されるまでに最大 2 週間かかります。SSM Agent に対するさらに頻繁な自動更新を設定することをお勧めします。
## SSM Agent インストールディレクトリが変更、移動、削除されていないことの確認
SSM Agent は `/var/lib/amazon/ssm/` (Linux と macOS) および `%PROGRAMFILES%\Amazon\SSM\` (Windows Server) にインストールされます。これらのインストールディレクトリには、認証情報ファイル、プロセス間通信 (IPC) 用リソース、オーケストレーションフォルダなど、SSM Agent が使用する重要なファイルやフォルダが含まれています。インストールディレクトリ内のものは変更、移動、削除しないでください。そうでないと、SSM Agent が正しく機能しなくなる可能性があります。
## AWS リージョン による SSM Agent のローリング更新
GitHub リポジトリで SSM Agent 更新が使用可能になった後、更新されたバージョンは各 AWS リージョン に異なる時間にロールアウトされ、すべてにロールアウトされるまで、最大 2 週間かかることがあります。このため、リージョンに SSM Agent の新しいバージョンをデプロイしようとすると、「Unsupported on current platform (現在のプラットフォームでサポートされていません)」または「updating amazon-ssm-agent to an older version, please turn on allow downgrade to proceed (amazon-ssm-agent を古いバージョンに更新しています。ダウングレードを許可してください)」というエラーが表示されることがあります。
使用可能な SSM Agent のバージョンを確認するには、`curl` コマンドを実行します。
グローバルダウンロードバケットで利用できるエージェントのバージョンを表示するには、次のコマンドを実行します。
```
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION
```
特定のリージョンで使用可能なエージェントのバージョンを表示するには、次のコマンドを実行します。{{region}} を(米国東部 (オハイオ) リージョンでは `us-east-2` などの作業しているリージョンに置き換えます。
```
curl https://s3.{{region}}.amazonaws.com/amazon-ssm-{{region}}/latest/VERSION
```
`VERSION` コマンドなしでブラウザで `curl` ファイルを直接開くこともできます。
## SSM Agent と AWS マネージド S3 バケットとの通信
さまざまな Systems Manager のオペレーションを実行する過程で、AWS Systems Manager Agent (SSM Agent) は多数の Amazon Simple Storage Service (Amazon S3) バケットにアクセスします。これらの S3 バケットはパブリックにアクセス可能です。デフォルトで、SSM Agent は `HTTP` 呼び出しを使用してこれに接続します。
ただし、Systems Manager のオペレーションで仮想プライベートクラウド (VPC) エンドポイントを使用している場合は、Systems Manager の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスプロファイル、または[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境の非 EC2 マシンのサービスロールで、明示的なアクセス許可を付与する必要があります。それ以外の場合、リソースからこれらのパブリックバケットにアクセスすることはできません。
VPC エンドポイントの使用中にこれらのバケットへのマネージドノードアクセスを許可するには、カスタム Amazon S3 許可ポリシーを作成し、それをインスタンスプロファイル (EC2 インスタンスの場合) またはサービスロール (非 EC2 ノードの場合) にアタッチします。
Systems Manager オペレーションで仮想プライベートクラウド (VPC) エンドポイントを使用する方法については、「[Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する](setup-create-vpc.md)」を参照してください。
**注記**
これらのアクセス許可では、SSM Agent が必要とする AWS マネージドバケットへのアクセスのみが付与されます。また、その他の Amazon S3 オペレーションに必要なアクセス許可は付与されません。また、独自の S3 バケットへのアクセス許可は付与されません。
詳細については、以下の各トピックを参照してください。
+ [Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)
+ [ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)
+ [参照: パッチ適用オペレーション用の Amazon S3 バケット](patch-operations-s3-buckets.md)
**Topics**
+ [必要なバケットアクセス許可](#ssm-agent-minimum-s3-permissions-required)
+ [例](#ssm-agent-minimum-s3-permissions-example)
+ [ハードウェアフィンガープリントを使用したハイブリッドアクティベーションマシンの検証](#fingerprint-validation)
### 必要なバケットアクセス許可
次の表は、各 S3 バケットについて説明しています。SSM Agent は Systems Manager のオペレーションで、このようなバケットにアクセスする必要があるかもしれません。
**注記**
{{region}} は、米国東部 (オハイオ) リージョンの `us-east-2` のように、AWS Systems Manager でサポートされている AWS リージョン の識別子を表します。サポートされている {{region}} 値の一覧については、「Amazon Web Services 全般のリファレンス」の「[Systems Manager サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)」にある **Region** 列を参照してください。
SSM Agent が必要とする Amazon S3 のアクセス許可
| S3 バケット ARN | 説明 |
| --- | --- |
| `arn:aws:s3:::aws-windows-downloads-{{region}}/*` | Windows Server オペレーティングシステムのみをサポートする一部の SSM ドキュメントに必要です。さらに、`AWSEC2-ConfigureSTIG` などのクロスプラットフォームサポート用のドキュメントもあります。 |
| `arn:aws:s3:::amazon-ssm-{{region}}/*` | SSM Agent インストールの更新のために必須です。これらのバケットには SSM Agent インストールパッケージ、および AWS-UpdateSSMAgent ドキュメントとプラグインによって参照されるインストールマニフェストが含まれています。これらのアクセス許可が提供されていない場合、SSM Agent は HTTP コールを実行して更新プログラムをダウンロードします。 |
| arn:aws:s3:::aws-ssm-{{region}}/\* | パッチ適用とパッチ適用以外の両方オペレーションの Systems Manager ドキュメント (SSM Command ドキュメント) での使用に必要なモジュールが含まれる S3 バケットへのアクセスを提供します。例: arn:aws:s3:::aws-ssm-us-east-2/\*。 以下は、これらのバケットに格納されていて、一般的に使用される SSM ドキュメントの一部です。 [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html) |
| `arn:aws:s3:::patch-baseline-snapshot-{{region}}/*`
-または-
`arn:aws:s3:::patch-baseline-snapshot-{{region}}-{{unique-suffix}}/*` | パッチベースラインのスナップショットを含む S3 バケットへのアクセスを提供します。これは、以下の SSM Command ドキュメントのいずれかを使用する場合に必要です。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html)
ほとんどのサポート対象 AWS リージョンのバケットは、以下の形式を使用しています。
`arn:aws:s3:::patch-baseline-snapshot-{{region}}`
一部のリージョンでは、バケット名に一意のサフィックスが追加されています。例えば、中東 (バーレーン) リージョン (me-south-1) のバケット名は以下のようになります。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html)
パッチベースラインスナップショットのバケット名の完全なリストについては、「[AWS が管理するパッチベースラインのスナップショットが含まれるバケット](patch-operations-s3-buckets.md#aws-patch-manager-buckets-baseline-snapshots)」を参照してください。 オンプレミスのファイアウォールを使用していて Patch Manager を使用する場合は、そのファイアウォールでパッチベースラインのエンドポイントへの適切なアクセスを許可する必要もあります。 |
| Linux と Windows Server マネージドノードの場合: `arn:aws:s3:::aws-patch-manager-{{region}}-{{unique-suffix}}/*`
macOS の Amazon EC2 インスタンスの場合: `arn:aws:s3:::aws-patchmanager-macos-{{region}}-{{unique-suffix}}/*` | Patch Manager でのパッチ適用オペレーションのために SSM Command ドキュメントによって使用されるモジュールを含む S3 バケットへのアクセスを提供します。各バケット名には、米国東部 (オハイオ) (us-east-2) リージョンにあるバケットの `552881074` など、一意のサフィックスが含まれています。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html) SSM ドキュメント 以下は、これらのバケットに格納されていて、一般的に使用される SSM ドキュメントの一部です。 [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html)
パッチ適用オペレーション用の AWS マネージド S3 バケットの完全なリストについては、以下のトピックを参照してください。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-technical-details.html) |
| `arn:aws:s3:::{{region}}-birdwatcher-prod/*` | Distributor オペレーションに必要です。このバケットには、`AWS-ConfigureAWSPackage` などのドキュメントを使用して Distributor パッケージをインストールまたは更新するときに `aws:configurePackage` プラグインで使用されるパッケージマニフェストが含まれています。VPC エンドポイントを使用している場合は、S3 VPC エンドポイントポリシーにこのバケットへのアクセスを含める必要があります。 |
### 例
次の例は、米国東部 (オハイオ) リージョン (us-east-2) で Systems Manager の使用に必要な S3 バケットへのアクセス権を付与する方法を示しています。ほとんどの場合、VPC エンドポイントを使用する場合にのみ、インスタンスプロファイルまたはサービスロールでこれらのアクセス許可を明示的に指定する必要があります。
**重要**
このポリシーの特定のリージョンの代わりにワイルドカード文字 (\*) を使用しないことをお勧めします。例えば、`arn:aws:s3:::aws-ssm-us-east-2/*` を使用して、`arn:aws:s3:::aws-ssm-*/*` は使用しないでください。ワイルドカードを使用すると、アクセスを付与する S3 バケットへのアクセス権が付与される場合があります。複数のリージョンでインスタンスプロファイルを使用する場合は、各リージョンの最初の `Statement` ブロックを繰り返すことをお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
"arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
"arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
]
}
]
}
```
------
### ハードウェアフィンガープリントを使用したハイブリッドアクティベーションマシンの検証
[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境で非 EC2 マシンを実行すると、SSM Agent は多数のシステム属性 (*ハードウェアハッシュ*と呼ばれる) を収集し、これらの属性を使用して*フィンガープリント*を計算します。フィンガープリントは、エージェントが特定の Systems Manager API に渡す不透明な文字列です。この固有のフィンガープリントは、発信者を特定のハイブリッドアクティベーションマネージドノードに関連付けます。エージェントは、フィンガープリントとハードウェアハッシュをローカルディスク上の *Vault* と呼ばれる場所に保存します。
エージェントは、マシンが Systems Manager で使用するために登録されると、ハードウェアハッシュとフィンガープリントを計算します。エージェントが `RegisterManagedInstance` コマンドを送信すると、フィンガープリントが Systems Manager サービスに戻されます。
その後、`RequestManagedInstanceRoleToken` コマンドを送信するときに、エージェントは Vault 内のフィンガープリントとハードウェアハッシュをチェックして、現在のマシン属性が保存されているハードウェアハッシュと一致することを確認します。現在のマシン属性が Vault に保存されているハードウェアハッシュと一致する場合、エージェントはフィンガープリントを Vault から `RegisterManagedInstance` に渡し、呼び出しが成功します。
現在のマシン属性が保存されているハードウェアハッシュと一致しない場合、SSM Agent は新しいフィンガープリントを計算し、新しいハードウェアハッシュとフィンガープリントを Vault に保存し、新しいフィンガープリントを `RequestManagedInstanceRoleToken` * に渡します。これにより `RequestManagedInstanceRoleToken` が失敗し、エージェントは Systems Manager サービスに接続するためのロールトークンを取得できません。*
この障害は設計上のものであり、複数のマネージドノードが同じマネージドノードとして Systems Manager サービスと通信することを防ぐための検証手順として使用されます。
現在のマシン属性を Vault に保存されているハードウェアハッシュと比較すると、エージェントは次のロジックを使用して、古いハッシュと新しいハッシュが一致するかどうかを判断します。
+ SID (システム/マシン ID) が異なる場合は、一致しません。
+ 同じ場合は、IP アドレスが同じであれば一致します。
+ それ以外の場合は、一致するマシン属性の割合が計算され、ユーザー設定の類似度しきい値と比較され、一致があるかどうかが判断されます。
類似度のしきい値は、ハードウェアハッシュの一部として Vault に保存されます。
類似度のしきい値は、インスタンスの登録後に次のようなコマンドを使用して設定できます。
Linux マシンの場合:
```
sudo amazon-ssm-agent -fingerprint -similarityThreshold 1
```
PowerShell を使用している Windows Server マシンの場合:
```
cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
```
**重要**
フィンガープリントの計算に使用されるコンポーネントの 1 つが変更されると、エージェントが休止状態になる可能性があります。この休止状態を回避するには、類似度のしきい値を低い値 (**1** など) に設定します。休止の詳細については、「[SSM Agent の休止について](#ssm-agent-hibernation)」を参照してください。
## GitHub での SSM Agent
SSM Agent のソースコードが [https://github.com/aws/amazon-ssm-agent](https://github.com/aws/amazon-ssm-agent) に用意されているので、ニーズに応じてエージェントを調整できます。含めることを希望する変更について、[プルリクエスト](https://github.com/aws/amazon-ssm-agent/blob/mainline/CONTRIBUTING.md)を送信することをお勧めします。ただし、Amazon Web Services はこのソフトウェアの変更されたコピーの実行をサポートしていません。
## SSM Agent の休止について
AWS Systems Manager エージェント (SSM Agent) の休止は、エージェントが Systems Manager サービスとの適切な通信を維持できない場合に発生するオペレーションモードです。休止中、エージェントは通信頻度を減らし、スタンバイ状態になります。
**SSM Agent の休止が発生する場合**
SSM Agent の休止は、以下のシナリオで発生する可能性があります。
登録解除されたハイブリッドノード
Systems Manager から[ハイブリッドアクティベーションノード](hybrid-activation-managed-nodes.md)の登録を解除すると、そのノードの SSM Agent は認可トークンを更新できません。これにより、エージェントはサービスで認証できないため、休止モードになります。
ハードウェアフィンガープリントの変更
SSM Agent は、ハードウェアフィンガープリントを使用してハイブリッドアクティベーションマシンを検証します。このフィンガープリントを計算するために使用されるコンポーネントの 1 つが大幅に変更された場合、エージェントがセキュリティ対策として休止になる可能性があります。これは、複数のマネージドノードが同じノードとして Systems Manager と通信するのを防ぐための設計によるものです。詳細については、「[ハードウェアフィンガープリントを使用したハイブリッドアクティベーションマシンの検証](#fingerprint-validation)」を参照してください。
Amazon EC2 インスタンスでの SSM Agent の休止
休止は、Systems Manager サービスに接続の問題や認証の問題がある場合など、特定の条件下で Amazon EC2 インスタンスでも発生する可能性があります。
**休止通信動作**
SSM Agent が休止モードになると、Systems Manager サービスとの通信パターンが変わります。
+ **通常のオペレーション**: エージェントは Systems Manager と定期的に (通常は数分ごとに) 通信して、新しいコマンドをチェックし、ステータスを報告します。
+ **休止モード**: ping 頻度は 5 分ごとから始まり、デフォルトで 1 時間に 1 回まで徐々に低下します (最大 24 時間まで設定可能)。この通信頻度の低下により、不要なネットワークトラフィックを最小限に抑えながら、条件が変化してもエージェントが回復できる可能性を維持します。
休止中、エージェントは認証と接続の試行を低頻度で継続しますが、休止が解消されるまで新しいコマンドを処理したり、詳細なステータス情報を報告したりすることはできません。
**ハイブリッドインスタンスの休止を防ぐための設定オプション**
ハードウェアフィンガープリントの変更による休止を防ぐのに役立つ主な設定オプションは、類似度しきい値の調整です。
Linux マシンの場合:
```
sudo amazon-ssm-agent -fingerprint -similarityThreshold 1
```
PowerShell を使用する Windows Server マシンの場合:
```
cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
```
類似度しきい値は、エージェントが現在のマシン属性と格納されたハードウェアハッシュをどの程度厳密に比較するかを決定します。
+ 値が大きいほど、一致する属性がより多く必要になります
+ 小さい値 (**1** など) はより寛容で、小規模なハードウェア変更による休止を回避するのに役立ちます
**休止のログ記録とモニタリング**
SSM Agent が休止モードになると、休止状態の特定とトラブルシューティングに役立つログエントリが作成されます。
+ **エージェントログファイル**: 休止イベントは標準 SSM Agent ログファイルに記録されます。ログファイルロケーションの詳細については、「[SSM Agent ログファイルを使用して問題をトラブルシューティングする](troubleshooting-ssm-agent.md#systems-manager-ssm-agent-log-files)」を参照してください。
+ **Amazon EC2 コンソールのログ記録**: EC2 インスタンスの場合、休止メッセージが Amazon EC2 コンソールシステムログに記録されるようになり、エージェントのステータスをさらに可視化できるようになりました。ログにアクセスするには、EC2 コンソールでインスタンスを選択し、**[アクション]**、**[モニタリングとトラブルシューティング]**、**[システムログの取得]** の順に選択します。
+ **特定のログファイル**: 休止が開始されると、休止トリガーとステータスに関する詳細情報を含む特定のログファイルが作成されます。
これらのログソースをモニタリングして休止イベントを早期に検出し、修正アクションを実行して通常のエージェントオペレーションを復元します。
**休止からの復旧**
休止から復旧するには、根本的な原因に対処します。
+ **登録解除されたハイブリッドノードの場合**: 「[マネージドノードの登録解除と再登録 (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)」および「[マネージドノードの登録解除と再登録 (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)」で説明されているように、新しいアクティベーションコードと ID を使用して Systems Manager にノードを再登録します。
+ **ハードウェアフィンガープリントの問題の場合**: 上記の「**ハイブリッドインスタンスの休止を防ぐための設定オプション**」で説明したように類似度しきい値を調整するか、ハードウェアの変更が大きい場合はノードを再登録します。
+ **接続の問題の場合**: ネットワーク接続を確認し、必要なエンドポイントにアクセスできることを確認します。詳細については、「[`ssm-cli` を使用したマネージドノードの可用性のトラブルシューティング](troubleshooting-managed-nodes-using-ssm-cli.md)」を参照してください。
根本的な問題を解決したら、エージェントは自動的に休止モードを終了し、次の通信試行時に通常のオペレーションを再開する必要があります。