WindowsインスタンスにSSM Session Manager経由でアクセスする

WindowsインスタンスにSSM Session Manager経由でアクセスする構成

WindowsインスタンスにSSM Session Manager経由でアクセスする構成を確認します。

Session Manager は完全マネージド型の AWS Systems Manager 機能です。ブラウザベースのインタラクティブなワンクリックシェルまたは AWS CLI を介して Amazon EC2 インスタンスを管理できます。Session Manager を使用して、アカウント内のインスタンスとのセッションを開始できます。セッションの開始後、他の接続タイプと同様、bash コマンドを実行できます。

Session Manager を使用した Linux インスタンスへの接続

SSM Session Managerを使用したインスタンスへのアクセスは、一般的なリモートデスクトップ接続でのアクセスと比べてさまざまなメリットがあります。特に注目すべきポイントは、リモートアクセス用のポート開放が不要になる点と、踏み台サーバも不要になる点です。

インスタンスでインバウンド SSH ポートとリモート PowerShell ポートを開いたままにすると、エンティティが許可されていないコマンドや、悪意のあるコマンドをインスタンス上で実行するリスクが大幅に増加します。Session Manager は、これらの着信ポートを閉じることにより、SSH キーと証明書、踏み台ホスト、およびジャンプボックスの管理からユーザーを解放して、セキュリティ体制を向上させるのに役立ちます。

AWS Systems Manager Session Manager

今回は、一般的なリモートデスクトップ(RDP)接続でのアクセスと比較しつつ確認します。
なお本ページはWindowsインスタンスを対象とした内容ですが、LinuxインスタンスにSession Manager経由でアクセスする方法については、以下のページをご確認ください。

あわせて読みたい
LinuxインスタンスにSSM Session Manager経由でアクセスする 【LinuxインスタンスにSSM Session Manager経由でアクセスする】 EC2インスタンスにSSM Session Manager経由でアクセスする構成を確認します。 Session Manager は完全...

構築する環境

Diagram of accessing Windows instance via SSM Session Manager

VPCにサブネットを1つ作成します。
インターネットにアクセス可能なパブリックサブネットです。

このサブネットにWindowsインスタンスを3台ずつ配置します。
今回作成するインスタンスはWindows Server 2022です。
いずれもパブリックアドレスを設定します。

これらのインスタンスはLinux版で言うところの①または②に相当します。
この2パターンしか用意していない理由ですが、本ページではWindowsにおけるRDP接続やSSM Session Managerの動きを確認することにフォーカスしているためです。

環境構築用のCloudFormationテンプレートファイル

上記の構成をCloudFormationで構築します。

以下のURLにCloudFormationテンプレートを配置します。

https://github.com/awstut-an-r/awstut-fa/tree/main/007

検証のシナリオ

Windowsインスタンスへのアクセス方法に関して、以下の3パターンを確認します。

  1. RDP接続
  2. SSM Session Manager接続(PowerShell)
  3. SSM Session Manager接続(ポートフォワーディングを使用してRDP)

テンプレートファイルのポイント解説

本ページでは、SSM Session Managerを使用してWindowsインスタンスにアクセスする方法を中心に取り上げます。

SSM Session Managerに関する基本的な事項については、以下のページをご確認ください。

あわせて読みたい
LinuxインスタンスにSSM Session Manager経由でアクセスする 【LinuxインスタンスにSSM Session Manager経由でアクセスする】 EC2インスタンスにSSM Session Manager経由でアクセスする構成を確認します。 Session Manager は完全...

セキュリティグループ設定

RDPとSSM Session Managerを比較する上で、大きな違いがあるのがセキュリティグループです。
RDPの場合、同サービス用のポート(一般に3389/tcp)を開ける必要があります。
一方SSM Session Managerであれば、そのような対応は不要です。

以下がセキュリティグループにおいて各インスタンスが許可するインバウンド通信をまとめた表です。

インスタンス方法セキュリティグループ
インスタンス1RDP3389/tcpを許可
インスタンス2SSM Session Manager
インスタンス3SSM Session Manager

インスタンス1:RDPを許可するセキュリティグループ

Resources:
  InstanceSecurityGroup1:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup1"
      GroupDescription: Allow SSH.
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref RDPPort
          ToPort: !Ref RDPPort
          CidrIp: 0.0.0.0/0
Code language: YAML (yaml)

セキュリティグループを考える上でポイントは2つです。

1つ目はポート番号です。今回はRDP(3389/tcp)でこのセキュリティグループが適用されるインスタンス1にアクセスしますから、同ポートを指定します。

2つ目は送信元です。今回はCIDRとして「0.0.0.0/0」を指定します。このように設定することによって、全送信元アドレスからのアクセスを許可することを意味します。

以上をまとめるとインターネット経由の全アドレスからのRDP接続を許可することになります。

インスタンス2および3:SSM Session Managerではインバウンド通信は発生しない

Resources:
  InstanceSecurityGroup2:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup2"
      GroupDescription: Deny All.
      VpcId: !Ref VPC
Code language: YAML (yaml)

インスタンス2および3に適用するセキュリティグループです。
インスタンス1と比較すると良くわかりますが、何もインバウンド通信を許可していません。
つまり全てのインバウンド通信を許可しないということです。

詳細は割愛しますが、SSM Session Managerを実行するためには、許可するべきインバウンド通信は発生しません。
ですから全インバウンド通信を許可しないセキュリティグループを作成します。

EC2設定

EC2インスタンスの設定において、今回ポイントとなる点は4つです。

1つ目はセキュリティグループです。
これは前項で確認したため割愛します。

2つ目はIAMロールです。
SSM Session Managerを使用するためには、IAMロールを関連付けてインスタンスに複数のSSMアクションを許可する必要があります。
必要なアクションはAWS管理ポリシー(AmazonSSMManagedInstanceCore)という形でまとめられており、作成するIAMロールにこれをアタッチします。

3つ目はキーペアです。
RDPを使用する場合は、キーペアの設定が必要です。

キーペアには、プライベートキーと公開キーを含んでおり、 Amazon EC2 インスタンスへの接続時の身分証明に使用する、セキュリティ認証情報のセットを構成しています。

Amazon EC2 のキーペアと Linux インスタンス

インスタンス1はRDPを使用して直接アクセスしますし、インスタンス3はSSM Session Managerのポートフォワーディング機能を使用してRDP接続を行いますので、両インスタンスでキーペアの設定が必要となります。

以下が各インスタンスの設定をまとめた表です。

インスタンス方法IAMロールにアタッチするポリシーキーペア
インスタンス1RDP設定する
インスタンス2SSM Session Manager(PowerShell)SSM用AWS管理ポリシー
インスタンス3SSM Session Manager(Port Fowarding)SSM用AWS管理ポリシー設定する

インスタンス1:キーペアとセキュリティグループでRDPを許可する

Resources:
  Instance1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup1
Code language: YAML (yaml)

キーペアを設定します。
今回は「MyKeyPair」という名前のキーペアを作成しているものとして記載しています。
キーペアの作成に関しては以下のページをご確認ください。

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-ec2-keypairs.html

インスタンス1用のセキュリティグループを使用します。
これはインターネットからのRDP(3389/tcp)を許可するものです。

インスタンス2:IAMロールでSSM Session Managerを許可する

Resources:
  Instance2:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup2
Code language: YAML (yaml)

インスタンス2用のセキュリティグループでは、全インバウンド通信を許可していません。

IamInstanceProfileプロパティでインスタンスプロファイル(IAMロール)を関連づけます。
今回関連付けるIAMロールには、AWS管理ポリシーAmazonSSMManagedInstanceCoreをアタッチしています。
これをアタッチすることでSSM Session Managerを実行するために必要なアクションが許可されます。

なおSSM Session Managerを実行するためのもう1つの条件として、インスタンスにSSMエージェントがインストールする必要があります。
ただしWindows Server 2022にはデフォルトで同エージェントがインストールされているため、特別な対応は不要です。

AWS Systems Manager Agent (SSM Agent) は、以下の Amazon Machine Images (AMIs) にデフォルトでプレインストールされています。

2016 年 11 月以降に公開された Windows Server 2008-2012 R2 AMIs

Windows Server 2016、2019、および 2022

Windows Server 用 EC2 インスタンスで SSM Agent を使用する

インスタンス3:SSM Session ManagerのPort Forwardingを使用してRDPするためにはキーペアの設定が必要

Resources:
  Instance3:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup2
Code language: YAML (yaml)

インスタンス3もSSM Session Managerを使用するため、インスタンス2と同様にインスタンスプロファイルとセキュリティグループを設定します。

加えてインスタンス3はSSM Session Managerのポートフォワーディングを使用して、RDP接続することになりますので、キーペアの設定も行います。

環境構築

CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。

CloudFormationスタックを作成し、スタック内のリソースを確認する

CloudFormationスタックを作成します。

スタックの作成および各スタックの確認方法については、以下のページをご確認ください。

あわせて読みたい
CloudFormationのネストされたスタックで環境を構築する 【CloudFormationのネストされたスタックで環境を構築する方法】 CloudFormationにおけるネストされたスタックを検証します。 CloudFormationでは、スタックをネストす...

AWS Management Consoleから各リソースを確認します。

インスタンス1

Detail of EC2 01.

確かにキーペアが設定されています。

このインスタンスに適用されているセキュリティグループを確認します。

Detail of EC2 02.

確かにRDPが許可する内容であることが確認できます。

インスタンス2

Detail of EC2 03.

IAMロールが設定されていることがわかります。

このIAMロールを確認します。

Detail of EC2 04.

確かにこのIAMロールにAWS管理ポリシーAmazonSSMManagedInstanceCoreがアタッチされています。

インスタンス3

Detail of EC2 05.

IAMロールとキーペアが設定されていることがわかります。

動作確認

インスタンス1:RDP接続

インスタンス1へのアクセスはRDPを使用します。

RDP接続のために管理者アカウントのパスワードを確認する – AWS Management Console版

リモートデスクトップ接続を行う場合、管理者アカウントに設定された初期パスワードを確認する必要があります。

管理者のアカウント名は、言語によりますが、通常はAdministratorです。

管理者アカウントの名前は、オペレーティングシステムで使用する言語によって異なります。たとえば、英語の場合は Administrator、フランス語の場合は Administrateur、ポルトガル語の場合は Administrador となります。

Windows インスタンスに接続する

Administratorのパスワードを確認する方法は2通りあります。まずAWSManagement Consoleを使用する方法を取り上げます。

AWS Management Consoleにログイン後、対象のEC2インスタンスのページにアクセス後、上部の「Connect(接続)」を押下します。

Detail of EC2 06.

「RDP client(RDP クライアント)」タブを選択後、「Get password(パスワードを取得)」を押下します。

Detail of EC2 07.

インスタンスに関連付けたキーペアのプライベートキーをテキストエリアに貼り付け、「Decrypt Password(パスワードを復号化)」を押下します。

Detail of EC2 08.

「Password(パスワード)」の項目に表記されている文字列がAdministratorのパスワードです。

Detail of EC2 09.
WindowsインスタンスにRDP接続する

リモートデスクトップクライアントを起動し、アクセスを開始します。

Detail of EC2 10.

アクセス先にインスタンス1のパブリックIPv4 DNS名を指定します。そしてユーザ名にAdministrator、パスワードに先ほど確認したパスワードを指定します。

しばらく待つと、デスクトップ画面が表示されます。

Detail of EC2 11.

このようにWindowsインスタンスにRDP接続を行うことができました。

インスタンス2:SSM Session Manager – PowerShell版

インスタンス2へのアクセスはSSM Session Managerを使用します。

AWS CLIを使用して、インスタンスにアクセスします。

$ aws ssm start-session \
--target i-01d49aca0bee4c9f9

Starting session with SessionId: i-0548ccea730f12250-052fb1dfae9c09d3c
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

新機能と改善のために最新の PowerShell をインストールしてください!https://aka.ms/PSWindows

PS C:\Windows\system32>
Code language: PowerShell (powershell)

このようにSSM Session Managerを使用することで、PowerShell接続でインスタンスにアクセスすることができました。

インスタンス3:SSM Session Manager – ポートフォワーディング版

最後にSSM Session Managerのもう1つのアクセス方法である、ポートフォワーディングを使用してRDP接続する方法を確認します。

RDP接続のために管理者アカウントのパスワードを確認する – AWS CLI版

ポートフォワーディングを使用してRDP接続する場合もパスワードの事前確認が必要となります。

AWS CLIを使用してパスワードを確認する方法をご紹介します。

$ aws ec2 get-password-data \
--instance-id i-003567b4fb82d02c3 \
--priv-launch-key MyKeyPair.pem
{
    "InstanceId": "i-003567b4fb82d02c3",
    "PasswordData": "W!M5-$@.TfA@-DCZx9A.AeS!-vusQUkI",
    "Timestamp": "2024-02-15T11:33:30+00:00"
}
Code language: Bash (bash)

PasswordDataの値がパスワードです。

Windowsインスタンスにポートフォワーディングを使用してRDP接続する

まずクライアント側でポートフォワーディングを実行します。

% aws ssm start-session \
--target i-003567b4fb82d02c3 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber=3389, localPortNumber=13389"

Starting session with SessionId: root-030641470dec64987
Port 13389 opened for sessionId root-030641470dec64987.
Waiting for connections...
Code language: Bash (bash)

コマンドの内容ですが、クライアント端末の13389ポートでリッスンし、SSM Session Managerの3389ポートにフォワーディングするというものです。

リモートデスクトップクライアントを起動し、アクセスを開始します。

Detail of EC2 12.

流れは先ほどと同じですが、「PC name」の値は「localhost:13389」とします。

インスタンスのユーザー名とパスワードを入力後、しばらく待つとインスタンスのデスクトップ画面が表示されます。

Detail of EC2 13.

このようにポートフォワーディングの設定を行うことで、SSM Session Managerを使用してRDP接続でもインスタンスにアクセスすることができました。

まとめ

WindowsタイプのEC2インスタンスへのアクセス方法を確認しました。

一般的なRDP接続に加えて、SSM Session Managerを使用してアクセスすることができます。
SSM Session Managerを使用する場合、PowerShell版とポートフォワーディングを使用したRDP接続が選択できます。

RDP接続に比べてSSM Session Managerを使用する場合、リモートアクセス用のポート開放や踏み台サーバを用意する必要がなくなる等のメリットがあります。SSM Session Managerを使用することで、インスタンスに不正にアクセスされるリスクを低減することができますし、インスタンスの管理工数の軽減にも繋がるでしょう。