re:Inforce 2023のハンズオンセッション参加レポート
アナハイムで開催されたAWS re:Infroce 2023のハンズオンセッションについてご紹介します。
ハンズオンセッションとは
re:Inforceはハンズオンセッションが非常に多く、手を動かして学びたい人にとって非常におすすめです。
ハンズオンは「AWS Workshop Studio」を利用し、一時的なAWSアカウントと手順書が与えられるので、料金の心配もありません。
以下のような少人数のテーブルに分けられて、各テーブルにAWSの技術者がつきます。
手順で困ったり疑問があればすぐに質問することができます。
当日発表された新サービスを体験するセッションもあり、いち早く試すことができます。
また、参加者同士の交流もあり様々な意見を聞けることが、現地ならではの体験です。
ハンズオンセッションのご紹介
今回体験したハンズオンをいくつかご紹介します。
[GRC351] Build an end-to-end DevSecOps pipeline on AWS
セキュリティとコンプライアンスのテストが開発プロセスに統合されたDevSecOps CI/CDパイプラインを構築します。
Amazon CodeCatalystを使用してポリシー検証を実行し、パイプラインのデプロイメントに一貫性があり、組織のコンプライアンス基準を満たしていることを確認します。
以下が構成図です。
Amazon CodeCatalystでリポジトリを作成し、環境やワークフローの設定を行います。
チェックで失敗するようになっているので、チェックが通るように修正していきます。
[TDR251] Streamline and centralize security operations with AWS Security Hub
AWS Security Hubのアラートの優先順位付けや調査方法などを学びます。
すでにたくさんの検知があるSecurity Hubダッシュボードです。
どのようにアラートを調査して、どのようなアプローチが取れるかを考察していきます。
[GRC353] Build a security posture leaderboard using AWS Security Hub
AWS Security Hubの調査結果を使用して、堅牢で包括的なリーダーボードを作成する手法を学びます。
最終的にこのようなものができます。
以下が構成図です。
Security HubのイベントをEventBridgeとKinesis Firehose経由でS3に保存し、Glue、Athena、QuickSightを使ってダッシュボードを作成します。
Glueクローラーでデータを検出し、Athenaで分析します。
そして、QuickSIghtでダッシュボードを作成していきます。
まとめ
用意された環境で、いち早く新サービスを試せたり、ベストプラクティスや工夫した手法を学習できるため、非常に楽しく勉強できました。
その場で議論や質問ができるのも現地でハンズオンをする醍醐味ですね。
手を動かして学びたい方は、ぜひ現地でハンズオンセッションに参加してみてください。
Security Hub automation rulesで検出結果を更新または抑制できるようになりました
Security Hub automation rulesで検出結果を更新または抑制できるようになったので、検証してみました。
アップデート概要
- 検出結果のさまざまなフィールドの自動更新、検出結果の抑制、重大度やワークフローステータスの更新、メモの追加が可能
事前準備
Security Hubのメニューに「オートメーション」が追加されています。
今回は更新と抑止を検証したいので、それぞれの共同を確認するために、ブロックパブリックアクセスを無効にしたS3バケットを2つ用意します。
検出結果の重要度を変更する
S3バケット「test1-automation-rules-bucket」のブロックパブリックアクセスが無効であることを検出させ、その重要度を変更します。
「オートメーション」→「ルールを作成」から、ルールテンプレート「Elevate severity of findings that relate to important resources」を選択します。
条件で、ResourceIdにS3バケットに「test1-automation-rules-bucket」のARNを指定します。
重要度はデフォルトで「CRITICAL」になっています。
ルールステータスが「有効」になっていることを確認し、「ルールを作成」を押下します。
複数のコントロールで検出されるため、今回は「AWS基礎セキュリティのベストプラクティス v1.0.0」から「[S3.8] S3 Block Public Access setting should be enabled at the bucket level」に絞って確認します。
SecurityHubの定期チェック後に検出結果を確認してみると、本コントロールの重要度は通常HIGHですが、CRITICALに変更されていることが分かります。
また、自動アクションに記載されているノートが反映されています。
詳細の画面も同様に変更されています。
また、履歴タブから「オートメーション」が重要度とノートを変更したことが記録されています。
JSONログを確認すると、元の重要度はSeverity.Originalに保持され、Severity.Labelに変更後の値が記録されています。
また、Noto.Textにノートが記録されています。
{ "SchemaVersion": "2018-10-08", "Id": "arn:aws:securityhub:ap-northeast-1:xxxxxxxxxxxx:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.8/finding/xxxxxxxxxxxx", "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/securityhub", "ProductName": "Security Hub", "CompanyName": "AWS", "Region": "ap-northeast-1", "GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/S3.8", "AwsAccountId": "xxxxxxxxxxxx", "Types": [ "Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices" ], "FirstObservedAt": "2023-06-26T04:04:35.301Z", "LastObservedAt": "2023-06-26T04:04:42.291Z", "CreatedAt": "2023-06-26T04:04:35.301Z", "UpdatedAt": "2023-06-26T04:04:35.301Z", "Severity": { "Product": 70, "Label": "CRITICAL", "Normalized": 70, "Original": "HIGH" }, "Title": "S3.8 S3 Block Public Access setting should be enabled at the bucket-level", （省略） "Note": { "Text": "This is a critical resource. Please review ASAP.", "UpdatedBy": "sechub-automation", "UpdatedAt": "2023-06-26T04:04:45.635Z" }, （省略）
検出結果を抑制する
S3バケット「test2-automation-rules-bucket」のブロックパブリックアクセスが無効であることを検出させ、その検出を抑制します。
「オートメーション」→「ルールを作成」から、ルールテンプレート「Suppress informational findings」を選択します。
条件で、ResourceIdにS3バケットに「test2-automation-rules-bucket」のARNを指定します。
ワークフローステータスはデフォルトで「SUPPRESSED」になっています。
ルールステータスが「有効」になっていることを確認し、「ルールを作成」を押下します。
先ほどと同様、「AWS基礎セキュリティのベストプラクティス v1.0.0」から「[S3.8] S3 Block Public Access setting should be enabled at the bucket level」に絞って確認します。
ワークフローのステータスが「SUPPRESSED」に変更されています。
また、自動アクションに記載されているノートが反映されています。
詳細の画面も同様に変更されています。
また、履歴タブから「オートメーション」がステータスとノートを変更したことが記録されています。
JSONログを確認すると、Workflow.Statuslに抑制を表す「SUPPRESSED」が記録されています。
また、Noto.Textにノートが記録されています。
{ "SchemaVersion": "2018-10-08", "Id": "arn:aws:securityhub:ap-northeast-1:xxxxxxxxxxxx:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.8/finding/xxxxxxxxxxxx", "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/securityhub", "ProductName": "Security Hub", "CompanyName": "AWS", "Region": "ap-northeast-1", "GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/S3.8", "AwsAccountId": "xxxxxxxxxxxx", "Types": [ "Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices" ], "FirstObservedAt": "2023-06-26T04:04:35.301Z", "LastObservedAt": "2023-06-26T04:04:40.573Z", "CreatedAt": "2023-06-26T04:04:35.301Z", "UpdatedAt": "2023-06-26T04:04:35.301Z", （省略） "Workflow": { "Status": "SUPPRESSED" }, "RecordState": "ACTIVE", "Note": { "Text": "Automatically suppress this bucket", "UpdatedBy": "sechub-automation", "UpdatedAt": "2023-06-26T04:04:42.523Z" }, （省略）
まとめ
Security Hub automation rulesで検出結果を更新または抑制することができました。
これまで、手動で対応していた運用を、事前にルールを定義することで自動化することができます。
きめ細やかな条件を指定できることで運用が楽になると思うので、ぜひ活用してみてください。
Amazon EC2 Instance Connect Endpoint経由でEC2インスタンスのプライベートIPアドレスにSSH接続する
Amazon EC2 Instance Connectで、パブリック IP アドレスなしのSSHおよびRDP接続ができるようになりました。
今回はプライベートサブネットに配置したEC2インスタンスに、Amazon EC2 Instance Connect Endpoint経由でSSH接続をしてみます。
以下が今回作成する構成図です。
アップデート概要
- EC2 Instance Connect Endpoint (EIC エンドポイント) を使用すると、パブリック IP アドレスを使用せずに EC2 インスタンスにSSHおよびRDP接続が可能
- プライベートサブネット内のインスタンスにリモート接続できるため、接続にパブリックIPv4アドレスを使用する必要がない
事前準備
構成図のセキュリティグループを作成しておきます。
EC2 Instance Connect Endpoint用のセキュリティグループ
セキュリティグループ名 ： test-eic-sg
インバウンドルール ： なし
アウトバウンドルール ： セキュリティグループ「test-ec2-sg」宛のSSH(22)
EC2インスタンス用のセキュリティグループ
セキュリティグループ名 ： test-ec2-sg
インバウンドルール ： セキュリティグループ「test-eic-sg」からのSSH(22)
アウトバウンドルール ： 0.0.0.0/0宛の全ポート
VPCの「エンドポイント」→「エンドポイントの作成」から、「EC2 Instance Connect Endpoint」を選択します。
事前に作成した、EC2 Instance Connect Endpoint用のセキュリティグループ「test-eic-sg」を選択し、サブネットを指定して、「エンドポイントを作成」を押下します。
EC2に接続する
それでは、AWSマネジメントコンソールから接続するEC2インスタンスを選択し、Amazon EC2 Instance Connect Endpoint経由でSSH接続してみます。
「EC2 Instance Connect」タブから、「EC2 Instance Connectエンドポイントを使用して接続する」を選択し、エンドポイントを指定して、「接続」します。
接続できました。
CloudTrailログを確認する
AWS CloudTrailで接続ログを取得しているので、いつ誰がどのインスタンスに接続したかを調査することができます。
イベント名は「OpenTunnel」です。
Trailログの例
{ "eventVersion": "1.08", "userIdentity": { "type": "IAMUser", "principalId": "xxxxxxxxxxxx", "arn": "arn:aws:iam::xxxxxxxxxxxx:user/xxxxxxxxxxxx", "accountId": "xxxxxxxxxxxx", "accessKeyId": "xxxxxxxxxxxx", "userName": "xxxxxxxxxxxx" }, "eventTime": "2023-06-25T05:09:44Z", "eventSource": "ec2-instance-connect.amazonaws.com", "eventName": "OpenTunnel", "awsRegion": "ap-northeast-1", "sourceIPAddress": "xxxxxxxxxxxx", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0", "requestParameters": { "instanceConnectEndpointId": "eice-xxxxxxxxxxxx", "maxTunnelDuration": "3600", "remotePort": "22", "privateIpAddress": "10.0.128.161" }, "responseElements": null, "requestID": "xxxxxxxxxxxx", "eventID": "xxxxxxxxxxxx", "readOnly": false, "resources": [ { "accountId": "xxxxxxxxxxxx", "type": "AWS::EC2::InstanceConnectEndpoint", "ARN": "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxx:instance-connect-endpoint/eice-xxxxxxxxxxxx" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "xxxxxxxxxxxx", "eventCategory": "Management" }
SSM Session Managerとの違い
以前、SSM Session Managerを使ってEC2インスタンスに接続する方法を紹介しました。
SSM Session ManagerはIAMポリシーでアクセスコントロールをしているのに対し、Instance Connect Endpointはセキュリティグループでアクセスコントロールしています。
要件に応じて使い分ければ良いと思います。
また、SSM Session Managerは3つのVPCエンドポイントが必要で費用が掛かりますが、Instance Connect Endpointは無料になります。
費用面を気にする場合は、このメリットは大きいと思います。
まとめ
プライベートサブネットに配置したEC2インスタンスに、Amazon EC2 Instance Connect Endpoint経由でSSH接続することができました。
プライベートサブネットのEC2インスタンスに対して、手軽に安全に接続できるため、非常に使い勝手が良いと思います。
SSM Session Managerとの違いを意識しながら、要件に応じて使い分けていただければと思います。
Amazon InspectorでSBOMエクスポートができるようになりました
Amazon InspectorでSBOMエクスポートができるようになったので、検証してみました。
SBOM（Software Bill of Materials、ソフトウェア部品表）とは、ソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表であり、ソフトウェアサプライチェーンのリスク管理等に利用されます。
アップデート概要
- Amazon Inspectorで監視されているすべてのリソースのSBOMを、CycloneDxやSPDXなどの業界標準形式でエクスポート可能
- ソフトウェアパッケージに関する詳細と、関連する脆弱性情報が含まれている
検証
事前準備
Inspectorのメニューに「Export SBOMs」があります。
SBOMに脆弱性情報を含ませるため、マーケットプレイスから古いAMIを取得し、EC2インスタンスを起動します。
202個の脆弱性が検知されました。
出力先のS3バケットとKMSキーを用意します。
S3バケットとKMSキーのポリシーが適切に設定されていないとエラーになるので、以下のドキュメントを参考に設定します。
バケットポリシー
{ "Version": "2012-10-17", "Statement": [ { "Sid": "allow-inspector", "Effect": "Allow", "Principal": { "Service": "inspector2.amazonaws.com" }, "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:AbortMultipartUpload" ], "Resource": "arn:aws:s3:::<S3バケット名>/*", "Condition": { "StringEquals": { "aws:SourceAccount": "<AWSアカウントID>" }, "ArnLike": { "aws:SourceArn": "arn:aws:inspector2:<リージョン>:<AWSアカウントID>:report/*" } } } ] }
KMSキーポリシー
{ "Sid": "Allow Amazon Inspector to use the key", "Effect": "Allow", "Principal": { "Service": "inspector2.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "<AWSアカウントID>" }, "ArnLike": { "aws:SourceArn": "arn:aws:inspector2:<リージョン>:<AWSアカウントID>:report/*" } } }
SBOMをエクスポートする
「Export SBOMs」に戻り、エクスポートの設定を行います。
「Add filter」でエクスポート対象を選択することができます。
利用できるフィルターは以下ドキュメントで確認できます。
今回はタグを使って、先ほどのEC2インスタンスを選択します。
事前準備で作成したS3バケットとKMSキーを選択し、「Export」を押下します。
エクスポートが始まります。
数分後にエクスポートが完了します。
S3バケットにSBOMが出力されました。
ファイルを確認します。
EC2インスタンスの情報から、ソフトウェア情報と検知された脆弱性情報が分かります。
{ "bomFormat": "CycloneDX", "specVersion": "1.4", "version": 1, "metadata": { "timestamp": "2023-06-25T02:34:37Z", "component": { "type": "operating-system", "name": "AMAZON_LINUX_2" }, "properties": [ { "name": "amazon:inspector:ami", "value": "ami-xxxxxxxxxxxx" }, { "name": "amazon:inspector:arch", "value": "x86_64" }, { "name": "amazon:inspector:account_id", "value": "xxxxxxxxxxxx" }, { "name": "amazon:inspector:resource_type", "value": "AWS_EC2_INSTANCE" }, { "name": "amazon:inspector:instance_id", "value": "i-xxxxxxxxxxxx" }, { "name": "amazon:inspector:resource_arn", "value": "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxx:instance/i-xxxxxxxxxxxx" } ] }, "components": [ { "type": "application", "name": "elfutils-libelf", "purl": "pkg:rpm/elfutils-libelf@0.176-2.amzn2?arch=X86_64&epoch=0&upstream=elfutils-libelf-0.176-2.amzn2.src.rpm", "version": "0.176", "bom-ref": "ddf56a513c0e76ab2ae3246d9a91c463" }, { "type": "application", "name": "libffi", "purl": "pkg:rpm/libffi@3.0.13-18.amzn2.0.2?arch=X86_64&epoch=0&upstream=libffi-3.0.13-18.amzn2.0.2.src.rpm", "version": "3.0.13", "bom-ref": "7815cd0f8a2522a9c1bfa22c7c75e0d5" }, （省略） "vulnerabilities": [ { "id": "CVE-2022-40304", "affects": [ { "ref": "d767c0d05ad199c30aa487f4c139fc94" }, { "ref": "1ec2a0f3c6035ce88b5256faa942a09d" } ] }, { "id": "CVE-2022-32221", "affects": [ { "ref": "49a798c08887e728538e676d0702a3d8" }, { "ref": "4b5db358ca74293f49fb57d2a0bef249" } ] }, ] }
エクスポートされたファイルに含まれる脆弱性の数が、Inspectorで確認したものと一致するか確認しておきます。
下記のコマンドで202個という結果なので、一致しています。
$ aws s3 cp s3://test-sbom-export-bucket/CYCLONEDX_1_4_outputs_xxxxxxxxxxxx/account=xxxxxxxxxxxx/resource=AWS_EC2_INSTANCE/i-xxxxxxxxxxxx_CYCLONEDX_1_4.json - | jq '.vulnerabilities[].id' | wc -l 202
まとめ
Amazon InspectorのSBOMエクスポート機能を確認しました。
脆弱性情報だけでなく、ソフトウェアパッケージの構成情報まで出力できるようになり、Inspectorの幅が一気に広がりました。
昨今のソフトウェア構成の複雑化により、SBOMの重要性がさらに増しているので、脆弱性管理の一貫としてぜひ活用してみてください。
Amazon InspectorでLambda関数のコードスキャンができるようになりました
AWS re:Inforce 2023にて、AWSセキュリティサービスについてたくさんのアップデートがありました。
Amazon InspectorでLambda関数のコードスキャンができるようになったので、検証してみました。
本アップデートは2月にプレビュー版がリリースされていましたが、今回の発表で一般提供開始になりました。
アップデート概要
- ユーザが作成したLambda関数内のコードをスキャンして、インジェクションの欠陥、データ漏洩、弱い暗号化、または暗号化の欠落などのコードセキュリティの脆弱性をスキャン
- Lambdaのスキャンは、レイヤーを対象とした「標準スキャン」とコードを対象とした「コードスキャン」があり、今回のアップデートは後者のコードスキャン
- スキャンタイミングは、Lambda関数のデプロイ時、Lambda関数の更新時、新しい脆弱性 ( CVE ) の公開時
詳細は以下のドキュメントに記載されています。
検証
事前準備
Inspectorの「アカウント管理」にて、「AWS Lambdaスキャン」の項目があります。
依然は「標準スキャン」だけでしたが、「コードスキャン」の記載が増えており、非アクティブ（無効化）になっていることが分かります。
「アクティブ化」から「AWS Lambda標準スキャン + AWS Lambdaコードスキャン」を押下します。
しばらくすると、「コードスキャン」もアクティブ（有効化）になりました。
Organizationを使っていれば、Inspector委任管理者アカウントから全アカウントまとめて有効化できます。 新しいメンバーアカウントを追加したときに、コードスキャンが有効化になるように、「AWS Lambdaコードスキャン」にチェックを入れて保存しておきましょう。
検知させてみる
脆弱なコードで含むLambda関数を作成します。
今回は、「Amazon CodeGuru, Detector Library」から以下の「Improper privilege management」を検知させてみます。
サンプルコード
import os def lambda_handler(event, context): root = 0 # Noncompliant: the process user is set to root. os.setuid(root)
しばらくすると、検知がありました。
詳細画面から、関連するCWE情報やコードの脆弱な部分がハイライトされています。
まとめ
Amazon Inspectorで簡単にLambda関数のコードスキャンができるようになりました。
コードのどこに脆弱性があるかも示してくれるため、非常に使い勝手が良いサービスです。
Inspectorの機能も増えてきているので、今後の動向に注目です。
Session Managerのポートフォワーディング機能によるRDP接続
前回、「Fleet Managerを使用したEC2接続」をご紹介しましたが、Fleet Managerで見る画面は解像度はあまり高くなく、Windows上で細かい作業をしたいときには向きません。
もしRDP接続ができれば、解像度の調整もできるため作業しやすくなります。
そこで、Session Managerのポートフォワーディング機能を使うことで、ローカル端末の指定ポートで受けた通信をリモート端末のポートにフォワーディング（転送）させることが可能になります。
今回はこの、Session Managerのポートフォワーディング機能によるRDP接続の方法をご紹介します。
以下にイメージ図を掲載します。
AWSの設定
Session Managerでセッションを張るために、IAMユーザに権限を付与します。
今回は、IAMユーザ「testuser01」をIAMグループ「SessionAllowGroup」に所属させ、このグループにポリシーを付与します。
必要なポリシーは以下です。
リソースは要件に応じて制限すると良いでしょう。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ssm:ResumeSession", "ssm:DescribeSessions", "ssm:TerminateSession", "ssm:StartSession" ], "Resource": "*", "Effect": "Allow" } ] }
続いて、このユーザのアクセスキーを作成します。
ローカル端末の準備
以下のドキュメントを参考に、AWS CLIとSSMプラグインをローカル端末にインストールします。
SSMプラグインのインストール
続いて、コマンドプロンプトを開き、アクセスキーとシークレットを設定します。
>aws configure AWS Access Key ID [None]: ****************ABCD AWS Secret Access Key [None]: ****************abcd Default region name [ap-northeast-1]: Default output format [json]:
ポートフォワーディングでRDP接続してみる
コマンドプロンプトでポートフォワードのコマンドを実行します。
ここでは、ローカル端末のポート番号11111をリモート端末の3389に転送します。
>aws ssm start-session --target <インスタンスID> --document-name AWS-StartPortForwardingSession --parameters portNumber=3389,localPortNumber=11111 Starting session with SessionId: testuser01-xxxxxxxxxx Port 11111 opened for sessionId testuser01-xxxxxxxxxx. Waiting for connections...
「Waiting for connections...」と表示されたら、コネクションを待ち受けている状態です。
リモートデスクトップを開き、「localhost:11111」にadministratorで接続してみます。
ちなみに、先ほどのコマンドプロンプトで「Connection accepted for session」と表示され、通信が開始されたことが分かります。
Starting session with SessionId: testuser01-xxxxxxxxxx Port 11111 opened for sessionId testuser01-xxxxxxxxxx. Waiting for connections... Connection accepted for session [testuser01-xxxxxxxxxx]
Administratorのパスワードを入力します。
接続が成功しました。
もちろん、ローカル端末のドライブとも共有が可能です。
まとめ
Session Managerのポートフォワーディング機能によるRDP接続の方法をご紹介しました。
Fleet Managerで十分であれば良いですが、要件によってはリモートデスクトップを使いたいときもあると思います。
Session Managerであれば、プライベートサブネットにあるインスタンスにもRDPで接続でき、さらにIAMによる制御も可能になります。
非常に便利な機能なので、ぜひ活用してみてください。
Fleet Managerを使用したEC2接続
以前、「Session Managerを使用したEC2接続」をご紹介しましたが、インスタンスがWindowsの場合はFleet Managerを使ってGUIログインができます。
Fleet Managerとは
AWS Systems Managerという、AWSリソースの構成や変更を管理するサービスがあり、Fleet Managerはその1機能です。
Fleet Managerを利用することで、従来のRDPを使わずに、AWSマネジメントコンソールからEC2へ接続することができます。
前提条件
前提条件はSession Managerを利用するときと同じです。
EC2にSSM Agentの導入が必要
導入されていない場合は手動でインストールする必要があります。
EC2にSystem Managerへの適切な権限が必要
AWS管理ポリシー「AmazonSSMManagedInstanceCore」を含む権限が、インスタンスにアタッチされている必要があります。
インターネットを経由しない場合は、適切なVPCエンドポイントが必要
インターネットを経由しない完全に閉じた環境でSession Managerを使用する場合は、以下のVPCエンドポイントを用意し、それらにアタッチするセキュリティグループでインバウンド443ポートを許可する必要があります。
- com.amazonaws.region.ssm
- com.amazonaws.region.ec2messages
- com.amazonaws.region.ssmmessages
Fleet Managerで接続してみる
OSにWindowsを選択したEC2インスタンスを作成します。
後ほどログインパスワードを取得するためにキーペアが必要になるので、キーペアも作成しておきます。
インスタンスの接続画面から「RDPクライアント」を選択し、画面下部の「パスワードを取得」ボタンを押下します。
「プライベートキーファイルのアップロード」を押下し、インスタンスのキーペアをアップロードし、パスワードを復号化します。
すると、Administratorのパスワードが表示されるので、これを控えます。
AWS Systems ManagerのFleet Managerで該当インスタンスを選択し、ユーザネームにAdministrator、パスワードに先ほど控えたパスワードをそれぞれ入力し、「Connect」ボタンを押下します。
リモートデスクトップ接続の確立中なので、しばらく待ちます。
しばらくすると、Windowsに接続することができました。
インスタンス名のタブを選択すると、画面を拡大することもできます。
まとめ
Fleet Managerを使用したEC2接続の方法を紹介しました。
AWSマネジメントコンソール上で、RDP接続をしているかのようにGUIログインができるため、使い勝手が良いです。
セキュリティを考慮しながら、簡単にプライベートサブネットのインスタンスへGUI接続することができるため、ぜひ活用してみてください。
