はじめに
AWSでサーバ運用をする際、メンテナンス用の踏み台サーバを構築することは良くあると思います。ただ、面倒なサーバ運用のターゲットが増えてしまうことは、運用目線だと望ましくありません。AWS Systems Manager（SSM）を使うと踏み台サーバを構築せずにサーバのメンテナンス経路を用意できます。
本記事ではサーバ運用の面倒さと代替手段としてのSSMを使う際のポイントについてご紹介いたします。
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。
サーバを運用する上での課題事項
まずサーバを利用する上での課題事項を整理してみたいと思います。
- セキュリティ対策が必須
例：セキュリティパッチの適用，EDR等セキュリティソフトの導入 - ログインユーザの管理が必要
例：ユーザ毎のアカウントの払い出し・鍵管理・権限管理 - 操作ログの取得が必要
例：AWSの場合はCloudwatchLogsへのログ転送 - 上記の対応をするための定期的なメンテナンスが必要
「サーバが増える ＝ 上記の課題を考慮すべき対象が増える」ということですので、不要ならば踏み台サーバは作らないほうが良いです。運用上の負荷の増加につながります。
SSMを踏み台代わりに利用する上で気を付けるポイント
一方でSSMを使う場合に気を付けるべきポイントはいくつかあります。
事前にSSMエージェントの導入が必要
SSMはEC2内にインストールしたSSMエージェントを介してアクセスをするのでエージェントの導入が事前に必要です。またエージェントがAWSと通信するために以下の設定が必要となります。
-
EC2に対し、AmazonSSMManagedInstanceCoreポリシーを持ったIAMロールをアタッチする
-
https(443)でEC2のセキュリティグループのアウトバウンド通信を許可しておく（SSHやRDPのインバウンドは不要）
-
InternetGatewayまたはVPCエンドポイント経由でのAWSとの通信経路を用意する
エージェントのインストール自体はEC2構築時のuser dataに以下のようなコマンドを仕込んでおけば簡単にできてしまうため、そこまで難しくはありません。
# Linux用のSSMエージェントセットアップサンプル
sudo su
dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent --now
オフィシャルのAMIではSSMエージェントがすでにインストールされています。（Amazon Linux，Ubuntu Server，Windows Server等）
OS側のログイン履歴に履歴が残らない
Linuxだとlastコマンド等でログイン履歴を確認できますが、SSM経由でアクセスした場合、こちらのコマンドでSSMでのアクセス履歴を追跡することができません。理由はどうやらSSM経由でのアクセスはログイン扱いではないためのようです。
そのため、SSM経由でのアクセス履歴は別の方法で記録する必要があります。具体的には以下の手段があると考えています。
-
マネコン上でSSMの利用履歴を確認する（どのユーザがどのインスタンスにいつSSMを使ったかがわかる）
-
セッションログを取得する（サーバ内での操作ログが取得できる）
ただし上記の方法でもRDP接続をしたときの操作ログはAWS側には残らないため、注意が必要になります。
通信速度は速くない
SSMは通信速度がそこまで速くないのでクライアントからのファイル転送などの用途には不向きです。素直にS3経由でファイルを送るなどをしましょう。
余談になりますが、本記事をレビューいただいた弊社のベテランエンジニアの方からは 「通信速度が速くない＝不要なファイル転送を防ぐことができる」 のでメリットであるというご意見をいただきました。
- クライアント⇒サーバへの転送であればS3やAWSのCI/CDパイプライン（アプリデプロイ時）を使う
- サーバ⇒クライアントであれば、情報漏洩の危険性があるので、そもそも非推奨の挙動である
※ログはS3やCloudwatch等に安全に吐き出す
言われてみればごもっともです。とはいえCI/CDパイプラインを安定して稼働させるにはアプリ側にもそれなりのクラウドの知識が求められると思いますので、弊社のような職能型の組織構造だとなかなかに難しいような気がしています。
またほかの方が書いている記事を見ていると第3の選択肢として、Tailscaleという製品を挙げられている方がいらっしゃいました。性能的には踏み台・SSMよりも上のように見えましたが、ビジネス利用だと有償になるため、企業で導入する際にはしっかりとコストに見合う製品かの見極めが必要になりそうです。
接続方法はマネコンからだけではない
SSMを使ってサーバに入るとき、基本的にはAWSのマネコン上で操作を行いますが、通常のSSHクライアントなどを使ってSSM経由でSSHすることも可能です。
SSHクライアントを使ってSSM経由でSSHすることは可能です。
SSM経由でのSSH接続でポートフォワードしてRDP接続するといったことも可能です。
まとめ
今回は踏み台サーバの代わりにSSMを利用することについて考えてみました。セキュリティやコスト的にはSSMが一番良さげな選択肢に見えますが、実際にその運用をしようとするとアプリ部隊を巻き込んで調整が必要になってくると思います。
参考までにAWSがSSMに関して、無料のオンラインセミナーを公開していますので、興味がある方は受講してみるとよいかと思います。SSM本来の用途であるサーバ管理ツールとしてどんな機能が提供されているかざっくりと理解することができます。