AWS Systems Manager のポートフォワーディング機能がリリースされました

AWS運用自動化サービス「Cloud Automator」

こんにちは!
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)の図

  1. 各EC2のセキュリティグループには、sshやRDPのポートを踏み台サーバに対して開放しておき、踏み台サーバからアクセス可能にします
  2. パブリックサブネットに配置した踏み台サーバのセキュリティグループには、接続拠点のIPアドレス(32ビット推奨)からのsshまたはRDPのみを許可しておきます
  3. 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 が、踏み台サーバの代わりになります

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

実際にやってみた

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

Clientの準備

図の下記箇所になります

Mac編

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

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

Windows編

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

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認証を可能にしておく

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

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

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

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

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

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

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

Windowsで成功したコマンド

載せておきます

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

macで成功したコマンド

踏み台サーバ・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ライフを〜♪

AWS運用自動化サービス「Cloud Automator」