はじめに
この記事では「この前リリースされた機能って実際に動かすとどんな感じなんだろう」とか「もしかしたら内容次第では使えるかも」などAWSサービスの中でも特定の機能にフォーカスして検証していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。
今回はAWS Systems Managerが機能として提供しているセッションマネージャー（以下、SSM）が踏み台サーバの代わりになり得るのか考察してみます。
SSMがあれば、踏み台はいらないのか
クラウド環境のリソースを操作する際、CloudShellではなくちゃんとしたサーバにログインしてクラウド環境にアクセスしたい場合があります。
このようなケースに対応する場合にはBastion Host、いわゆる踏み台サーバと呼ばれるものを使って対応します。
なお、AzureではBastion Hostを構築するためのAzure BastionというフルマネージドサービスがありますがAWSではそのようなサービスはありません。
ただし、Bastionという文脈を除くのであれば、SSMが似たようなことに対応しています。
なぜ踏み台を使うのか
SSH等のアクセスでクラウド環境をCLIで操作できるようなサービスがあれば、踏み台サーバは不要です。ではなぜ、踏み台サーバを構築するのでしょうか。
そもそも踏み台サーバを作る理由はなんでしょうか。踏み台サーバを作る理由はさまざまですが、筆者の知る範囲では以下のような要件があると認識しています。
- 特定のロケーションからのアクセスのみ許可しているため
- あるいは特定のIPアドレスからのアクセスのみ許可しているため
- 特定のアプライアンスからのみアクセスを許可しているため
- 特定のライセンス・パッケージを適用した装置を使う必要があるため
- アクセスログ監視およびトラップ監視のため
- 誰がいつどのようなアクセスをしたか権限レベルはどれくらいかを知るため
いずれにしてもアクセス元をはっきりさせておくことが目的になっているかと思います。順番に見ていきましょう。
特定のロケーションからのアクセスのみ許可しているため
これはよくあるところです。いわゆる地理的な制約です。
特定のIPからのみアクセスを許可しているため、許可IPを持つサーバを構築しておき、そこからのアクセスを継続的にモニタリングします。
場合によってはMACアドレスまでモニタリングすることもあります。
特定のアプライアンスからのみアクセスを許可しているため
特定のアプライアンスからのみアクセスを許可する場合は先述のとおり、MACアドレスを使いますが
ライセンスが必要な特定のソフトウェアを使って、アクセスする場合もあるでしょう。
厳しいライセンス形態のものの中では許可されたデバイスでのみ適用を許されるライセンスもあると思います。そうなると、決まった環境からアクセスできる必要が出てくるため、踏み台サーバが必要となります。
アクセスログ監視およびトラップ監視のため
IP制限やMACアドレス制限などをしたとしても誰がどのようなアクセスしたかまではチェックできません。
組織で利用する踏み台サーバというのは不特定多数の人が使うため、誰がどのようにアクセスしたかをすぐに検出できる必要があります。
まとめると
以上のことから踏み台サーバは必要です。
しかし、踏み台サーバを配置することによる手間というのは避けられません。具体的には以下のとおりです。
- 定期的な更新がサーバで必要であること
- ssh接続であれば、ssh接続のための鍵管理が必要であること
- 制限しているとはいえ、侵入経路になり得ること
本題：話を戻して
ここまでの結論では「個々の要件があるときはクラウド環境にログインするための踏み台サーバが必要」ということになりました。
では、SSMは活用できないでしょうか。実際に「SSMでは踏み台サーバの用途にはならない」という言葉をよく聞きます。本当にそうなのか考察していきましょう。
今回の要件
多くの人がイメージする制限された踏み台サーバをSSMで実現するためには以下の要件がSSMで必要です。
- 操作ログをとる
- セッション開始時に通知を出す
- VPCエンドポイントで対象にアクセス
- 特定のIPアドレスからアクセス
それぞれの要件が実現可能かドキュメントベースで確認してみます。
操作ログをとる
操作ログをとるというのはコマンド実行がテキストベースで残っているかということです。
SSMではAmazon S3にログを保管する機能が存在します。
Amazon S3 を使用してセッションデータをログ記録する
なお、CloudWatch Logsを使ったロギングも存在します。
Amazon CloudWatch Logs を使用してセッションデータをログ記録する
S3かCloudWatch Logsかというところですが、それぞれ料金が異なるため業務ではコスト面を見て導入を決めましょう。
セッション開始時に通知を出す
SSMの利用を開始したタイミングで通知を受け取りたいということがあると思います。
SSMに限らず、AWSのサービスはほとんどの場合において何かしらのアクションをするとイベントが発生します。EventBridgeを活用することでこのイベントをキャッチできます。
Amazon EventBridge を使用してセッションアクティビティをモニタリングする
キャッチしたイベントはAmazon SNSに利用できるため、イベントキャッチ後のアクションを使ってSNSを操作します。
VPCエンドポイントで対象にアクセス
以下のドキュメントにあるようにVPCエンドポイントを使ったアクセスが可能です。
Systems Manager のために VPC エンドポイントを使用して EC2 インスタンスのセキュリティを強化する
特定のIPアドレスからアクセス
SSMはIPアドレスを持たないため、特定のIPアドレスからのアクセスはできません。
しかし、EC2（接続先のサーバ）にアタッチされたIAMロールのポリシードキュメントでソースIPを指定することによってIP制限をかけることができます。「もしかして利用できるのでは」と思います。
まとめ
今回は「AWS Systems Managerがあれば、踏み台サーバはいらないのか」というテーマで要件と資料を見ながら考察しました。所感レベルでは踏み台サーバの代わりをSSMで担えそうに見えました。
次は実際に構築をしてみようと思います。