どうしても語りたい AWS Systems Manager の魅力 !

~ 第 3 回こんなに簡単にサーバー接続できるなんて ! 応用編

2024-09-03

How to be a Developer

Author : 瀧田直斗, 上野涼平

はてブ »

みなさん、こんにちは ! ソリューションアーキテクトの上野です。
今回は、どうしても語りたい AWS Systems Manager の魅力シリーズの第 3 回目ということで、「こんなに簡単にサーバー接続できるなんて ! 応用編」をお届けしていきます。

第 2 回では、「どうしても語りたい AWS Systems Manager の魅力 ! ~ 第 2 回こんなに簡単にサーバー接続できるなんて !」というタイトルで、AWS Systems Manager の Session Manager を利用して簡単にサーバー接続する方法をご紹介し、まずはお手軽に利用できるイメージをみなさんにお届けできたかと思います。しかし、実際の運用ではサーバー接続に関連する細かい要件として、操作ログの取得やアクセス制御といったお話が出てくるケースがあります。今回は、そういったお話に対応するための Session Manager の機能を深掘りしていき、要件に応じて Session Manager を使いこなせるようにご説明をしていきたいと思います !

この連載記事のバックナンバー

この記事の登場人物

瀧田直斗 (たきたなおと) ソリューションアーキテクト
前職では 10 年以上オンプレミスの運用に従事
最近 AWS Systems Manager を触り始め可能性を感じており、上野へ話を持ちかける。

上野涼平 (うえのりょうへい) ソリューションアーキテクト
前職では AWS 環境の構築と運用改善に従事
好きなサービスに AWS Systems Manager を掲げていたこともあり、瀧田から相談を受ける。

対談

瀧田
早いものでこのシリーズも第 3 回目ですね !

上野
祝 ! 第 3 回 ! よろしくお願いします！

瀧田
前回は、Session Manager を利用して簡単にサーバー接続できることを紹介していただきましたが、実はまだまだ聞きたいことがありまして。

上野
そういえば後半に質問攻めされた記憶があります・・・!

瀧田
いやー、気になることが多くて (笑)
話は戻るのですが、実際の運用のシーンでは、監査要件などで操作ログを取得する必要や、作業者ごとに接続できるサーバーを制限するといった要件が何かしら出てくると思うんですよ。場合によっては実行できるコマンドまで制限したいとか。

上野
確かに。今までにもそういったご要件をお客様からご相談いただくことはありましたね。

瀧田
あとは作業者目線だと、ローカルのファイルをリモート接続先に送ることはできるのか？とかそのあたりも気になりますね。

上野
わかりました！では今回出てきたような要件を Session Manager でどう実現できるかをご紹介していきましょうか ! ちなみにマネジメントコンソールからつなぐ場合と、ポート転送機能を使ってローカルから接続する場合で少し話が変わってくるので、そのあたりも踏まえて説明していきますね !

瀧田
頼もしい！よろしくお願いします !

アクティビティログの取得

上野
まずは、サーバー接続後のコマンド操作など、アクティビティログの取得についてです。Session Manager ではセッションアクティビティロギングを有効化することで、サーバー接続後、実行したコマンドやその結果をログで取得することができます。

瀧田
おお ! できるとは思ってましたが、さすが Session Manager！ログはどこに保存されるのでしょうか ?

上野
ログの保存先は、Amazon S3 か Amazon CloudWatch Logs を選択できます。ログの生成タイミングは、セッション終了時に生成される方式とストリーミングでリアルタイムにログを送信する方式があります。ストリーミングについては、CloudWatch Logs のみ対応となります。

瀧田
リアルタイムでもログ取得ができるのですね！となると、CloudWatch Logs 側の設定で、特定のコマンドを実行したことをトリガーに何か通知飛ばすということもできそうですね。

上野
そうですね ! 禁止するわけにはいかないものの、実行されたことをすぐに検知したいコマンドがもしあればそういったこともできますね。ここはCloudWatch Logs にストリーミングで送信できる利点かと思います。

上野
ちなみに設定は簡単で、Session Manager の設定から、ロギングの設定を有効にして、ログの送信先であるログストリームや S3 バケットを指定するだけです!

画像をクリックすると拡大します

上野
こちらは CloudWatch Logs に出力されたログです。ログからどの IAM で Session Manager を利用しているかも確認することができます。

画像をクリックすると拡大します

瀧田
設定も簡単ですね ! ちょっと気になったのですが、前回ご紹介していただいたようなリモートデスクトップ接続でのログはどうなるのでしょうか ?

上野
いつも鋭いご質問ありがとうございます。セッションアクティビティログが取得できるのは、マネージメントコンソールおよび AWS CLI を利用してセッションを開始した場合のみになります。そのため、リモートデスクトップ接続を行うために使用するポート転送など他の方法での Session Manager 利用において、操作の証跡を残しておきたいとなってくると、操作画面をキャプチャするようなツールをご検討いただくことになりますね。今更ですが、Session Manager のセッション開始方法の種類については以下のドキュメントをご覧ください。
Session Manager - セッションを開始する »

瀧田
なるほど、Session Manager の中でも接続方法によってできることが異なるのですね。

上野
はい、なのでセッションアクティビティログの取得や既存のクライアントツールで接続できること、といった要件のうちどれを重視するかで選択いただく必要がありますね。セッションアクティビティログの詳細についてはぜひドキュメントもご確認ください。
セッションアクティビティロギングの有効化と無効化 »

アクセス制御

上野
次はアクセス制御にいきましょう ! 作業者ごとにアクセスできるサーバーを制御したいというお話でしたよね ?

瀧田
そうですね ! 社内の部署やチームという単位でアクセスできるサーバーをわけたり、協力会社など外部の方が接続できるサーバーを限定したりといったユースケースを想定しています。

上野
第 2 回でも少しご紹介しましたが、Session Manager は IAM ポリシーでサーバーへのアクセス制御が可能です。マネジメントコンソールを利用する IAM ユーザーやスイッチロールで利用する IAM ロールなど、とにかく人による操作に関わる IAM ポリシーによって、インスタンス単位やタグ単位でアクセスできるサーバーを制御できます。ドキュメントでもポリシーの例が紹介されているのでこちらをもとに説明しますね。
Session Manager の追加サンプル IAM ポリシー »

上野
まずは、インスタンス単位でアクセス制御を行う方法です。ssm:StartSession の Resource に接続させる Amazon EC2 インスタンスを指定することで制御が可能です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:us-east-2:123456789012:instance/i-1234567890EXAMPLE",
                "arn:aws:ec2:us-east-2:123456789012:instance/i-abcdefghijEXAMPLE",
                "arn:aws:ec2:us-east-2:123456789012:instance/i-0e9d8c7b6aEXAMPLE",
                "arn:aws:ssm:us-east-2:123456789012:document/SSM-SessionManagerRunShell"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession",
                "ssm:ResumeSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:session/${aws:userid}-*"
            ]
        }
    ]
}

上野
同様に、特定のタグついた EC2 インスタンスにアクセスを限定させたい場合は、以下のようなポリシーを利用します。Condition でタグを指定しているのがポイントですね。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:us-east-2:123456789012:instance/*"
            ],
            "Condition": {
                "StringLike": {
                    "ssm:resourceTag/Finance": [
                        "WebServers"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession",
                "ssm:ResumeSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:session/${aws:userid}-*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:us-east-2:123456789012:document/SSM-SessionManagerRunShell"
            ]
        }
    ]
}

瀧田
インスタンス数が多い時はタグ単位の制御が使えそうですね ! 少し気になったのですが、タグのバリエーションが多い時には、その分 IAM ポリシーを作成しないといけないってことですか ?

上野
IAM ユーザーの管理方法次第ですが、そういった状況になることもあると思います。ちなみに、IAM ユーザーの管理を外部の Idp と連携させているケースですと、Idp 側の属性情報と EC2 インスタンスに付与されているタグの値が一致するかどうかでアクセス制御ができるので、IAM ポリシーは共通化できますね。以下のブログをご参考にしていただけると！
SAMLセッションタグを使用してフェデレーションユーザーのSession Managerアクセスを構成する »

コマンド制御

瀧田
アクセス制御の次は、コマンド制御についてもお聞きしたいです ! Linux での話にはなりますが、通常は OS ユーザー側の設定で実行できるコマンドを制御することがあると思います。Session Manager の設定でもそういったことができるのでしょうか ?

上野
結論から申し上げると現時点で Session Manager 単体の設定では制御ができません・・・! そのため、従来通り OS ユーザー側の設定で制御を行う必要がありますね。

瀧田
なるほど、さすがにここは Session Manager でも厳しかったわけですね。あれ、今更なのですが Session Manager で接続するときってどの OS ユーザーを利用しているんでしたっけ ? EC2 だから ec2-user ?

上野
Session Manager では ssm-user というOS ユーザーがデフォルトで利用されます。先ほど、Session Manager 単体ではコマンド制御はできないとお伝えしましたが、従来の OS 側の設定と Session Manager の設定を組み合わせることで、コマンド実行制御をより強固なものにできると考えています。ここに Session Manager での接続ユーザーが大きく関わってきます !

瀧田
おお ! 詳しく ! (いつもの流れきた !)

上野
デフォルトでは、ssm-user が利用されますが、RunAs という設定によって接続に利用する OS ユーザーを指定することができます。(Linux のみ)
OS 側でコマンド実行制御など権限の設定がされたユーザーを事前に用意しておき、RunAs のユーザーに指定することで、Session Manager 利用でも今回のような要件を満たせる状態になるかと思います。

瀧田
おお ! これで接続時に利用する OS ユーザーを限定できるってことですね ! 間接的にサポートしてくれる感じですね。そしてすみません、例のごとく気になることが・・・! この設定をしてしまうと Session Manager を利用する人全員が、同じ OS ユーザーでログインしないといけないってことでしょうか ?

上野
やはり鋭い ! キレッキレですね、瀧田さん。まずお答えとしては設定の方法を工夫することで、接続時の OS ユーザーは利用者に応じて変えることができます。そちらについてもご紹介していきますね。

瀧田
待ってました !

上野
実は、IAM ユーザーまたはロールに付与されたタグの内容を RunAs の設定に利用することができるのです ! そのため、各々が利用する IAM ユーザーやロールに応じて、Session Manager でサーバーに接続する際の OS ユーザーをコントロールできます。

画像をクリックすると拡大します

上野
詳細は省きますが、Session Manager の設定で RunAs を有効化しておき、タグをつけた IAM ユーザーもしくはロールでセッションを開始すると、こちらのように、指定した OS ユーザーで接続できるようになります。これは実質、接続する OS ユーザーを制御しているので結果的に、OS ユーザー側の設定とあわさり、コマンド実行制御までつなげることができますね。

画像をクリックすると拡大します

瀧田
なるほどー ! これなら個人ごとに利用する OS ユーザーも指定することができますね ! 確かに今までだと、ログイン情報知っていれば強い権限を持った OS ユーザーで接続できてしまうという問題がありましたが、OS ユーザーの指定を IAM 側でコントロールできてしまうのですね !

上野
RunAs の詳細はぜひドキュメントもご覧ください !
Linux と macOS のマネージドノードで Run As サポートを有効にする »

接続手段ごとに変わってくること

瀧田
いやー、今回は応用編ということもあり内容が盛りだくさんでしたね ! これで疑問は全て解決しました・・・と思いましたが一つだけ残ってました ! ローカルからのファイルの転送ってどうなるのでしょうか・・・?

上野
あ、失礼しました ! そういえばその話がありましたね。ファイル転送もそうなんですが、接続手段で変わることも踏まえて説明していきますね。綺麗な比較表にはできなかったので、そこはご了承ください・・・!

瀧田
ぜひお願いします !

上野
まず、ローカルからのファイル転送ですが、マネージメントコンソールや AWS CLI を利用した一番ベーシックな接続の場合、 Session Manager の機能では実現できないため、Amazon S3 などを利用してファイルのやりとりを行う必要があります。ただし、ポート転送での接続の場合は、従来のクライアントツールと同様に、SCPでの転送やクリップボードでのファイル転送が可能です。

瀧田
なるほど、そこで違いが出てくるのですね。となると、作業者目線だとポート転送での接続のほうが良さそうに思えますね。

上野
確かにそういった方もいらっしゃると思いますね。ただ、ログの部分でもお伝えしたように、ポート転送利用の場合、セッションアクティビティログの取得ができません。加えて、クライアント側に AWS CLI や Session Manager Plugin のインストールなどのセットアップ作業が必要になります。さらに言うと、接続時にキーペアも必要になってきます。ここは監査要件や利用人数に応じて接続方法を選んでいただくことになりますね。

瀧田
トレードオフってことですね。最後に無茶ぶりなのですが、AWS Systems Manager の Fleet Manager や EC2 Instance Connect エンドポイントといった他のサーバー接続機能との違いについてもざっくりでいいので教えてほしいです !

上野
なかなか難しいところなのですが、まず Fleet Manager はマネージメントコンソールからリモートデスクトップ接続できるとても便利な機能です。しかし、現時点では日本語入力できない点や、ポート転送同様にキーペアの管理が必要になるため、とにかく簡単に参照オンリーでいいのでリモートデスクトップ接続したいときなどにご検討いただくといいのではないかと思います。

瀧田
ふむふむ、ただマネージメントコンソール (ブラウザ) からリモートデスクトップ接続できるのはすごいですね !

上野
EC2 Instance Connect エンドポイントは、Session Manager と共通部分が非常に多いです。EC2 インスタンスをプライベートなネットワークに置いたまま接続できますので。違いとなってくると、必要なエンドポイントが一つで済むため、VPC エンドポイントで Session Manager を利用する場合よりコストをお安くすることが可能です。一方で、現時点ではエンドポイントは VPC に一つしか作成できないため、エンドポイントをマルチ AZ 構成にすることはできないです。さらに細かいことをいうと、EC2 インスタンスのセキュリティグループでは、SSH 用に 22 番ポート、RDP 用に 3389 番ポートを開けておく必要があります。Session Manager はセキュリティグループでポートの解放は不要です。

瀧田
こちらもちょっとした違いがありますね。話を聞く限り一概にどちらが良いという判断は難しそうですね。

上野
そうですね。ただ、Session Manager を利用する場合、Systems Manager の他の機能を利用するための土台が整っていることにもなりますので、第 1 回でご紹介したようなサーバー管理もあわせてやりたいといった話があれば、ぜひ Session Manager を使いつつ、Systems Manager 全体をご活用いただければと思います !

瀧田
今回も非常に勉強になりました ! 第 4 回も楽しみにしています !

上野
がんばります !!

まとめ

今回はサーバー接続機能である Session Manager の深堀りということで、実運用で出てくる要件にどのように対応できるかをご紹介してきました。

Session Manager にも複数の利用方法があり、それぞれでできること、対応していることが異なります。要件に応じてどの方法で Session Manager を利用すべきか判断するための情報をご紹介できたかと思います。AWS Systems Manager はサーバー接続の Session Manager 以外にも運用をサポートする便利な機能があります。

これを機にみなさんも Systems Manager をぜひご活用ください !

この連載記事のバックナンバー

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

メンバー特典を受け取る »

筆者プロフィール

瀧田直斗 (たきたなおと)
アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト

前職では 10 年以上オンプレミスの運用に従事。
現在は、業種・規模を問わず幅広いお客様に対して技術的な側面からビジネスを支援行う。
上野さんとはスプラトゥーン仲間。

上野涼平 (うえのりょうへい)
アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト

前職では AWS 環境の構築と運用改善に従事。
様々な業界・業種のお客様に対して技術面を中心に支援を行っている。
瀧田さんとはスプラトゥーン仲間。

X ポスト »

はてブ »

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫

5 ステップでアカウント作成できます

無料サインアップ ≫

ご不明な点がおありですか?

日本担当チームへ相談する

どうしても語りたい AWS Systems Manager の魅力 !

X ポスト »

シェア »

はてブ »

この連載記事のバックナンバー

この記事の登場人物

対談

アクティビティログの取得

アクセス制御

コマンド制御

接続手段ごとに変わってくること

まとめ

この連載記事のバックナンバー

筆者プロフィール

X ポスト »

シェア »

はてブ »

どうしても語りたい AWS Systems Manager の魅力 !

X ポスト »

シェア »

はてブ »

この連載記事のバックナンバー

この記事の登場人物

対談

アクティビティログの取得

アクセス制御

コマンド制御

接続手段ごとに変わってくること

まとめ

この連載記事のバックナンバー

筆者プロフィール

X ポスト »

シェア »

はてブ »

Internet Explorer のサポートの終了