NoSSHでSSMを試したら、セキュリティグループの最小構成で混乱した話
はじめに
AWSではEC2をSSHなしで管理できるAWS Systems Manager（SSM）が推奨されている。そこで、NoSSHを試したいと思い、SSMが動作するAmazon Linux2で、久しぶりにEC2を立ち上げてみた。その際に、セキュリティグループ（SG）に何をどこまで設定すればよいのか疑問に思ったため、本記事で整理する。
NoSSH実現のためのSGの考え方
NoSSH環境では、できるだけポートを開けないことが前提となる。22番ポートを開けずに通信が可能になるということは、「SSMを使うために、どこまで通信を許可すればいいのか？」を考える必要がある。そこで、調べてみたところAWSの公式ドキュメントや技術記事では、一般的に次のように説明されている。
- パブリックIPがあれば、SSMエンドポイントへ直接接続可能
- NATゲートウェイを経由すれば、パブリックIPを通じてSSMに接続可能
- SSM用VPCエンドポイントを利用すれば、プライベートネットワーク内でSSMを利用可能
しかし、どのケースでどこまで通信を制限できるのかについては、明確な説明が少なかっため、実際に試して整理してみることにした。
SSM用VPCエンドポイントとは？
VPCエンドポイントは、AWS PrivateLinkを利用して VPC内のリソースとAWSサービスをプライベート接続する仕組みだ。SSM用のVPCエンドポイントを作成することで、 パブリックIPを持たないEC2でも、インターネットを経由せずにSSMを利用できる。つまり、このあと説明するSGの設定には注意が必要となる。
なお、SSMのためのVPCエンドポイントは以下の3種類が必要となる。
com.amazonaws.<region>.ssmcom.amazonaws.<region>.ssmmessagescom.amazonaws.<region>.ec2messages
これらを適切に設定しないと、EC2のSSM AgentがSystems Managerに接続できないため注意が必要だ。
セキュリティグループ（SG）のデフォルト動作
| 項目 | デフォルトの動作 |
|---|---|
| インバウンド | すべて拒否（明示的な許可がない限り、受信トラフィックを拒否） |
| アウトバウンド | すべて許可（明示的な制限がない限り、送信トラフィックを許可） |
SGのデフォルト設定をベースに、何をどこまで設定すべきかを考えてみる。
SSMを最小限の許可で利用するためのSG設定
| ネットワーク構成 | 通信の出口 | インバウンドルールの変更 | アウトバウンドルールの変更 | 最小構成で許可すべき範囲 |
|---|---|---|---|---|
| パブリックIPあり（パブリックサブネット） | インターネット（SSMエンドポイントへ直接通信） | なし（すべて拒否でOK） | ssm.<region>.amazonaws.com のみ許可 |
インバウンド不要 / アウトバウンドをSSMエンドポイントに限定 |
| NATゲートウェイ経由（プライベートサブネット） | NATゲートウェイ | なし（すべて拒否でOK） | NATゲートウェイ経由でSSMエンドポイントのみ許可 | インバウンド不要 / アウトバウンドをNAT経由のSSMエンドポイントに限定 |
| SSM用VPCエンドポイント経由（プライベートサブネット、パブリックIPなし） | VPCエンドポイント | VPCエンドポイントのSGからのインバウンド許可が必須 | VPCエンドポイントのSGへのアウトバウンド許可が必須 | 双方向のSG許可が必須 / インバウンドをVPCエンドポイントSGのみに制限 |
どこまで許可すべきか？
NoSSH環境では、できるだけ余計な通信を発生させないことが望ましい。そのため、最低限の設定として以下を考える。
- インバウンド
- パブリックIPあり / NATゲートウェイ経由では変更不要（すべて拒否のままで問題なし）
- SSM用のVPCエンドポイント経由のみ、インバウンド許可が必要
- アウトバウンド
- ssm.<region>.amazonaws.comのみに制限すれば、よりセキュア
- ただし、運用要件に応じて柔軟にするのもあり。そのため、デフォルトのアウトバウンドの設定に近い構成になりがち。
パブリックIPありやNATゲートウェイ経由では、デフォルトのSG設定で問題なく動作する。SSM用のVPCエンドポイント経由のみ、インバウンドの許可が必要になるため、ここが設定のポイントとなる。
まとめ
NoSSH環境でのセキュリティグループ設定を整理した結果、 VPCエンドポイント経由のSSM利用時のみ、明示的なSGの設定が必要になる ことがわかった。パブリックIPを持つEC2やNATゲートウェイ経由の構成では、特別な設定なしでも動作するため、情報が錯綜しやすい点も理解できた。
また、今回の検証を通じて、 NATとVPCエンドポイントを併用すると設定が複雑になり、トラブルが発生しやすい ことも確認できた。そのため、どちらかの方式に統一するのがシンプルで運用しやすい選択肢となる。
Discussion