はじめに
AWS環境におけるプライベート環境のサーバーアクセスをどのように実施していますか？
セキュリティを守るために、踏み台サーバーを運用していることも多いと思います。
一方で、踏み台サーバーという管理対象が増えることで課題も生じてしまいます。
【運用面での課題】
・セキュリティパッチの適用
・ミドルやエージェントの管理
・キーペアやログインユーザーの管理
・ログやディスクの管理…etc
まだまだ現場では考慮しなくてはならないことはあるとは思いますが、
今回は、そんな課題を解決する AWS Systems ManagerのSession Managerについてご紹介します！
具体的に検証環境を作成していきますので、ぜひご覧ください。
目次
検証構成
まずは踏み台を利用した一般的な構成例です。
(Before)
そしてSession Managerを利用した今回の構成です。
(After)
今回はより閉域環境でのアクセスを可能とする検証を目的として事前に以下を作成しております。
そのため今回はNAT Gatewayは使用しません。
【作成済みのリソース】
・VPC：1つ
*DNS 解決／DNS ホスト名を有効に設定
今回のEC2はインターネットに出られないためVPCのDNS設定を使って
エンドポイントをプライベート環境で名前解決させる必要があります。
・EC2：1台 (OS:Linux)
*パブリックIPは付与しない
・プライベートサブネット：1つ
・EC2用セキュリティグループ：１つ
*今回はインバウンドルールは設定せずに検証します。
検証の流れ
今回は以下の流れで作成していきます。
1:IAMロールの作成、作成したロールをEC2へアタッチ
2:VPCエンドポイント用セキュリティグループの作成
3:VPCエンドポイントの作成
とても簡単なステップです！
検証手順
1：IAMロールの作成/インスタンスにロールをアタッチ
コンソール画面からIAMを選択し、ロールの作成まで進みます。
信頼されたエンティティタイプ：AWSサービス
サービスまたはユースケース：EC2
ユースケース：EC2 Role for AWS Systems Manager
このまま[次へ]を押下します。
許可ポリシーに「AmazonSSMManagedInstanceCore」を選択してくれています！
必要なロールはこれで問題ないので、[次へ]を押下してロールの詳細を入力します。
あとはデフォルトで問題ないので[ロールを作成]を押下して作成してください。
ロールが作成できたら今度はEC2にアタッチします。
対象のEC2を選択し[インスタンスの概要]を開き右端にある[アクション]ボタンを押下します。
[アクション]→[セキュリティ]→[IAMロールを変更]を選択します。
あとは作成したIAMロールを選択して[IAMロールの更新]を押せばOKです！
2：VPCエンドポイント用セキュリティグループの作成
IAMロールのアタッチまで完了したら、次はVPCエンドポイント用セキュリティグループを作成していきます。
対象のEC2からVPCエンドポイントまではHTTPSの通信が発生しますので、許可してあげます。
ワンポイント!
VPCエンドポイントの作成時にセキュリティグループを選択しますので、このタイミングでの作成がおすすめです！
コンソール画面のEC2からセキュリティグループを選択して作成します。
【インバウンドルール】
・タイプ：HTTPS
・プロトコル：TCP
・ポート範囲：443
・ソース：対象のEC2のセキュリティグループ
アウトバウンドルールはデフォルトもしくはVPC CIDRでOKです！
3：VPCエンドポイントの作成
ここまできたらあと少しです！
コンソール画面のVPCからエンドポイントを選択して作成します。
今回は3つのエンドポイントを作成します。
使うサービスはこちらです。
1:com.amazonaws.ap-northeast-1.ssm
2:com.amazonaws.ap-northeast-1.ssmmessages
3:com.amazonaws.ap-northeast-1.ec2messages
エンドポイントの設定をします。
・名前：任意の名前
・タイプ：AWSのサービス
・サービス名：com.amazonaws.ap-northeast-1.ssm
まずは1つめのサービスを検索欄に入力して、チェックボタンを押して選択します。
ネットワークの設定をします。
VPC：対象のVPCを選択
▼追加設定
プライベートDNS名：[プライベートDNS名を有効化]にチェックを入れてください。
ワンポイント!
今回の検証はNAT Gatewayを利用していない閉域環境なので、
このチェックを忘れると接続できません！
サブネットの設定をします。
対象のEC2が存在するアベイラビリティーゾーンと、サブネットを選択します。
セキュリティグループの設定をします。
先ほど作成したVPCエンドポイント用のセキュリティグループを選択してください。
次にポリシーを設定します。
今回はフルアクセスで作成します。
厳密にアクセス制限をしたい場合はカスタムを選択して、JSONを記載して制御します。
ここまで出来たら作成してください。
1つ目のエンドポイント(com.amazonaws.ap-northeast-1.ssm用)が作成できたら
残り2つのサービスも同じ設定内容で作成します。
4：接続確認
エンドポイントが作成できたら、実際に接続してみましょう。
対象のEC2を選択して、インスタンス概要画面から右端の[接続]ボタンを押下します。
SSM Session Managerのタブを選択して、[接続]ボタンを押下します。
ワンポイント！
接続画面で[Session Manager connection status]が[Not connected]の場合は以下3つを確認してみてください。
・IAMロールが付与されているか？
・VPCエンドポイントは正しいサービスで3つ作成されているか？
・VPCのDNS設定は有効になっているか？
接続できました！
あとはこの画面で、コマンドを入力できれば完全なプライベート接続環境の完成です。
補足ですが、Session ManagerでLinuxインスタンスに初めて接続すると、
SSMエージェントが自動的にssm-userという名前でユーザーを作ってくれるようです！
今回もしっかりssm-userになっておりました！
まとめ
今回はAWS Systems ManagerのSession Managerを使って、完全な閉域環境でインスタンスにアクセスしてみました。
この機能を使えば踏み台サーバーを利用しなくても、セキュリティを担保してアクセスできることが分かりました。
ぜひ、この機会に踏み台サーバの運用をやめてSession Managerを使った運用を検討してみてください！
おまけ
コンソール画面からAWS Systems Managerを選択し、
Session Manager→セッション履歴を選択するとセッションIDをはじめ、開始日やステータスが表示されるので、だれがいつアクセスしたのかを見ることもできます。
ただし、長期保存はできないので、監査対応などで利用する場合は別途S3に保管することもできますので検討してみてください。
