クラウド事業部の上野です。
AWSのプライベートなネットワーク（インターネット上から直接アクセスできないネットワーク）上に立てたEC2インスタンスへのsshアクセスはどのように行われていますでしょうか？よくある構成としてはパブリックなネットワーク（インターネット上からアクセスできるネットワーク）上にあるEC2インスタンスを経由してアクセスといったものがあります。俗に踏み台サーバやBastionサーバと呼ばれるものです。弊社でも踏み台サーバを用意することが多いですね。
ところがAWSにはEC2インスタンスへのアクセスをサポートするAWS Systems Manager Session Managerという機能があります。
これはEC2にインストールされているAWS Systems Manager エージェント (SSM エージェント) を利用してリモート接続を行います。SSMエージェントを利用すればネットワーク的に接続できないEC2インスタンスへ接続することも可能ですし、sshを使わないのでsshdのサービスを停止してもアクセスすることができるという優れものです。長年サーバ管理者をやっていますが、sshdを止めれる日が来るなんて思いもしなかったです。
それでは試してみましょう。
プライベートネットワーク上にEC2インスタンスを起動し、Session Managerを利用してアクセスするということをやってみたいと思います。
まず、AWSアカウント作成後に標準で準備されている Amazon Virtual Private Cloud (Amazon VPC)にプライベートネットワークを用意します。
ssm01
このプライベートネットワーク上にEC2インスタンスを立てます。このインスタンスはパブリックIPを持たないため外部から直接ssh接続することはできません。
ssm02
次にAWS Systems Manager をEC2が利用できるようにIAMロールを作成してEC2インスタンスに設定します。
ロールに設定するポリシーは AmazonEC2RoleforSSM になります。
これで準備が整いました。では早速インスタンスに接続してみましょう。
AWSマネジメントコンソールより、AWS Systems Manager -> セッションマネージャーを開きます。
セッションの開始というボタンを押すとインスタンスの一覧が表示されます。インスタンスを選択し、セッションの開始ボタンを押します。
ssm04
するとWebブラウザでコンソールの画面が開きます。
ユーザはssm-userというユーザで接続されているようですね。sudoコマンドを使ってroot権限得ることもできます。
ssm05
それでは試しにsshdのサービスを止めてみましょう。
リモートからsshdを止めるなんていう暴挙は初めてです。sshdを停止してもアクセスできていることが確認できます。
ssm09
セッションの履歴からどのIAMユーザで接続されたかを確認することができます。
ssm06
セッションの詳細な情報をログとして出力することも可能です。
Amazon CloudWatch Logsに出力するように設定するとこのようになります。実行されたコマンド一つ一つまで記録されていますね。
ssm007
S3にファイルとして保管させることも可能です。
ssm08
いかがでしたか。
比較的容易にSession Managerを使ってアクセスすることができました。
Session Managerのいいところは踏み台サーバが不要であるということだけではなく、EC2インスタンスへのアクセスをIAMユーザで管理できるということにあります。
ログもコマンドレベルで出力されていますので、いざという時の監査ログとしても利用できそうですね。
今後は踏み台サーバではなく、Session Managerを使うことも考慮に入れていきたいと思います。