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

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

AWS Systems Manager
記事タイトルとURLをコピーする

こんにちは！
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) にアップデート
$ 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]:
    $ 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ç·¨

    $ 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 --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ライフを〜♪

【お知らせ】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む

swx-yamamoto

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });