こんにちは！
AWSをこよなく愛す技術4課の山本(通称ヤマゾン)です
昨日は実質9時間くらい寝ました
今日は、AWS Systems Manager(以下、SSM)の新機能について紹介します

SSMでポートフォワーディング機能を提供するようになりました～ (拍手) プライベートサブネットのEC2にsshやRDPで接続する際には、多くの場合に、「踏み台サーバを使ってポートフォワーディング」しています (※1) ※1 厳密には、2019年7月のアップデートにより、SSHのトンネリングについては、もうサポートしていますセッションマネージャーが SSH と SCP のトンネリングサポートを開始 ( 2019/07/09 )

踏み台サーバって何？

踏み台サーバは、プライベートサブネットやパブリックサブネットにある各EC2に接続する際に、入り口となるサーバのことです踏み台サーバは、拠点などのグローバルIPからアクセスを一手に引き受けて、VPC内にある他のEC2にアクセス可能にします

踏み台サーバ(Bastion)の図

各EC2のセキュリティグループには、sshやRDPのポートを踏み台サーバに対して開放しておき、踏み台サーバからアクセス可能にします
パブリックサブネットに配置した踏み台サーバのセキュリティグループには、接続拠点のIPアドレス(32ビット推奨)からのsshまたはRDPのみを許可しておきます
1,2の設定により、拠点から踏み台サーバに接続(RDP/ssh)し、踏み台サーバから各EC2に接続(RDP/ssh)可能になります

図に書いていないものの、もちろん、踏み台サーバから他のAZにあるサブネットのEC2や、パブリックサブネットのEC2にも接続可能にしますまた、踏み台サーバそのものも、マルチAZ(複数のAZにそれぞれ1台は構築した状態)にすることを、AWSは推奨しています公式ドキュメントでは、踏み台サーバのことをBastion(要塞)と言っています Windowsでは、RD Gateway という技術を使い、踏み台サーバを構築します

ご参考

ポートフォワーディングって何？

Clientの指定ポートに来た通信を、リモートサーバー(EC2)の指定ポートに、踏み台サーバを利用して、フォワーディング(転送)する機能になります

ポートフォワーディングの図

Clientからポートフォワーディングを設定すると、 Clientのポート(図の例なら、9999ポート)にssh/RDP 接続した際に、 EC2の指定ポート(図の例なら、22ポート)に接続するようになります Client利用者は、踏み台サーバを意識せず、Clientから直接EC2に繋ぐようになりますポートフォワーディングする際の前提条件は以下です

Clientからポートフォワーディングに使用するプロトコル(sshなど)を使い、踏み台サーバに接続可能なこと
踏み台サーバからEC2の指定ポート(図の例なら、22ポート)に接続可能なこと
Clientの指定ポート(図の例なら、9999ポート)は未使用になっていて、空いていること
踏み台サーバとEC2のOS認証情報を持っていること

長くなるため、具体的な実行方法は示しません端末がmacならsshコマンド(-Lオプション)、端末Windowsならターミナルソフト(Teratermなど)にて設定し実行できます

「AWS System Manager Sessions Manager を使用した新しい – Port Forwarding」って何？

本題になります

「AWS System Manager Sessions Manager を使用した新しい – Port Forwarding」の図

Clientの指定ポートに来た通信を、リモートサーバー(EC2)の指定ポートに、SSMを利用して、フォワーディング(転送)する機能になります SSM が、踏み台サーバの代わりになります

接続拠点のIPアドレス(32ビット推奨)からのsshまたはRDPのみを許可するには、IAMユーザーにアタッチするIAMロールを使用します
- ご参考：IAM ロールを使用して特定の IP アドレスからの API コールを制限する方法を教えてください。

また、IAMロールを利用して、接続可能なEC2を制御することも可能になっています

実際にやってみた

IAM Policy でのIP制御等はせず、 Administratorに近いIAMユーザー権限で、同じアカウントのEC2に、端末(Client)からポートフォワーディングしてみました

Clientの準備

図の下記箇所になります

Mac編

awscliのインストール
- 下記コマンドにより最新バージョンの AWS Command Line Interface (CLI) にアップデート

$ sudo pip install -U awscli
    〜出力省略〜

$ aws --version
aws-cli/1.16.235 Python/3.7.2 Darwin/18.7.0 botocore/1.12.225

アクセスキー・シークレットキーの設定

    $ aws configure
    AWS Access Key ID [********************]:xxxxxxxxxxxxxxxx
    AWS Secret Access Key [********************]:xxxxxxxxxxxxxxxxxx
    Default region name [ap-northeast-1]:
    Default output format [None]:

Session Manager Plugin のインストール
- 下記リンク参考に、Systems Manager CLI 拡張機能をインストール
  - (オプション) AWS CLI 用の Session Manager Plugin をインストールする

    $ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
    〜出力省略〜

    $ unzip sessionmanager-bundle.zip
    〜出力省略〜

    $ sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
    〜出力省略〜

    $ session-manager-plugin --version
    1.1.31.0

Windows編

awscliのインストール
- 下記を参考にインストールします (キャプチャは申し訳ありません、載せません...)
  - Windows に AWS CLI をインストールする

    $ aws --version
    aws-cli/1.16.234 Python/3.6.0 Windows/10 botocore/1.12.224

アクセスキー・シークレットキーの設定

    $ aws configure
    AWS Access Key ID [********************]:xxxxxxxxxxxxxxxx
    AWS Secret Access Key [********************]:xxxxxxxxxxxxxxxxxx
    Default region name [ap-northeast-1]:
    Default output format [None]:

Session Manager Plugin のインストール
- 下記を参考にインストールします (キャプチャは申し訳ありません、載せません...)
  - (オプション) AWS CLI 用の Session Manager Plugin をインストールする

    $ session-manager-plugin --version
    1.1.31.0

EC2の準備

図の下記箇所になります

EC2 ( Wiindows Server 2016 ) 作成

Windows Server 2016 を1台立てて検証するため、下記手順を実施しました (キャプチャは申し訳ありません、載せません...)

VPCを作成し、その中にPrivate サブネットを作成

Privateサブネットに、EC2のSSMエージェントが利用するVPCエンドポイント作成　(以下4つ)

エンドポイント
com.amazonaws.ap-northeast-1.ec2
com.amazonaws.ap-northeast-1.ec2messages
com.amazonaws.ap-northeast-1.ssm
com.amazonaws.ap-northeast-1.ssmmessages

PrivateサブネットにEC2を作成

利用したAMI
Windows_Server-2016-English-Full-Base-2019.08.16 (ami-068721b34f85a5a99)

EC2と、VPCエンドポイントが通信できるように、セキュリティグループを変更

EC2に付与するIAMロールを作成し、下記1つのSSM用ポリシーをアタッチする

IAM Policy
AmazonEC2RoleforSSM

EC2に、SSM の「コマンドの実行」機能で下記を実行し、SSMエージェントのバージョンをアップデート ( AMIから起動したインスタンスに Systems Manager のエージェントはインストールされているため、アップデートのみ行います )
- 2.3.634.0 → 2.3.701.0 に上がりました

コマンドのドキュメント
AWS-UpdateSSMAgent

EC2に、セッションマネージャからからアクセスし、下記コマンドにより、Administratorのパスワードを変更し、RDP時のOS認証を可能にしておく

$ net user Administrator hogehoge(パスワード)
    The command completed successfully.

ポートフォワーディングしてみる

試しにWindows端末からやってみます

Clientにて、SSMのAPI(aws ssm start-session)を実行し、SSMを利用して、EC2にポートフォワーディングします

$ aws ssm start-session --target  i-xxxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"
    Starting session with SessionId: xxxxxxxxxxxxxxxx

おおよそ数秒後に、Clientの指定ポート(例なら13389ポート)にセッションを開けた旨のメッセージが追加されます

$ aws ssm start-session --target  i-xxxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"
    Starting session with SessionId: xxxxxxxxxxxxxxxx
    Port 13389 opened for sessionId xxxxxxxxxxxxxxxx   ← セッションを開けた ★

「Remote Desktop 接続」からClientの指定ポートに接続し、RDP可能なことを確認します

成功すると、コネクション確率に成功したメッセージが出ます

$ aws ssm start-session --target  i-xxxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"
    Starting session with SessionId: xxxxxxxxxxxxxxxx
    Port 9999 opened for sessionId xxxxxxxxxxxxxxxx
    Connection accepted for session xxxxxxxxxxxxxxxx   ← コネクション確率に成功 ★

Remote Desktop 接続を切断、または[Ctrl] + c を押すと、セッション終了となります

$ aws ssm start-session --target  i-xxxxxxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"
    Starting session with SessionId: xxxxxxxxxxxxxxxx
    Port 9999 opened for sessionId xxxxxxxxxxxxxxxx
    Connection accepted for session xxxxxxxxxxxxxxxx

    Exiting session with sessionId: xxxxxxxxxxxxxxxx   ← セッション終了 ★

Windowsで成功したコマンド

載せておきます

$ aws ssm start-session --target  i-xxxxxxxx --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"

Powershellでは出来ませんでした....

    $ Get-SSMSession -State Active
    # ↑ここまでは成功して「Status       : Connected」になるものの、実際に接続出来ませんでした ( 上手くいくやり方見つけたらブログ書きます

macで成功したコマンド

   $ aws ssm start-session --target i-xxxxxxxx \
                           --document-name AWS-StartPortForwardingSession \
                           --parameters '{"portNumber":["3389"],"localPortNumber":["13389"]}'

踏み台サーバ・SSM、それぞれの運用負荷を考える

踏み台とSSM、それぞれを運用するにあたり、何が運用負荷となりそうか考えてみましたざっくり、下記と考えました・踏み台はEC2であること・セキュリティグループの管理をすること・SSMはIAMポリシーの管理、Clientのアクセスキー管理をすること詳細は下に書いてみます

踏み台サーバにおける運用負荷

脆弱性の検知とパッチ適用
ウイルス対策
バックアップの取得
システムログ管理
セキュリティグループによるClientから踏み台サーバへの接続元IPアドレス制御
セキュリティグループによる踏み台サーバから各EC2への接続制御
ポートフォワーディングを使用したEC2への接続方法の周知
踏み台サーバのOS認証情報(鍵など)管理
各EC2のOS認証情報(鍵など)管理
マルチAZ構成などによる、AZ障害を考慮したリカバリ手順の準備

SSMにおける運用負荷

ClientにAWS CLIをインストールすること
AWS CLIで使うアクセスキーの定期的なローテーション
アクセスキーなどがインターネットに流出しないための教育と定期チェック
EC2に入っているSSMエージェントの定期的なアップデート
EC2に入っているSSMで利用するVPC Endpointとセキュリティグループ設定
IAM Role による、API実行をするClientの接続元IPアドレス制御
IAM Role による、API実行をするClientの接続先インスタンスの管理
SSMのAPIを利用した接続方法の周知
各EC2のOS認証情報(鍵など)管理
SSMのSLAは99.9%(月)であり、月間で40〜50分の停止時間を許容できること
マネージドサービスなので中身の実装は見えないため、障害時にデバッグしにくい
新しい機能であり、まだ定着していない

所感

設定方法や仕組みに複雑さがあり、踏み台サーバと比較して考えたときに、「すぐ乗り換えるぞ！」とは、正直ならないかもしれないな、と感じましたしかし、とても魅力的な機能に感じました踏み台サーバを使う場合、セキュリティグループの管理をすることになります WEBサービスにおいては、ユーザーからのWEBアクセスを受け付けるためにも、セキュリティグループの管理をすることになりますセキュリティグループに対する誤ったオペレーションで、サービスに与える影響を考えると、SSM を使うのは良さそうに感じましたもう一歩踏み込んで、業務で利用できる具体的な実装を考えてみようと思いましたそれでは皆様、良いSSMライフを〜♪