[アップデート] AWS Systems Manager セッションマネージャーで最大セッション期間の指定と開始時の理由の追加ができるようになりました

Session Manager 接続後、減っていく残り時間を見ながらヒリヒリしたいあなたへ。

コンバンハ、千葉(幸)です。

今日も今日とて AWS Systems Manager のドキュメント履歴を眺めていると、更新に気がつきました。

Document_history_-_AWS_Systems_Manager

機械翻訳の結果は以下の通りです。

最大セッション期間を指定し、セッションの理由を提供します

AWSアカウントのAWSリージョン内のすべてのSessionManagerセッションの最大セッション期間を指定できるようになりました。セッションが指定した期間に達すると、セッションは終了します。オプションで、セッションの開始時に理由を追加することもできるようになりました。

これまでセッションマネージャーではアイドルセッションタイムアウト(操作しない時間が一定を超過すると切断)のパラメータを指定できましたが、それとは別に最大セッション期間を指定できるようになりました。

また、何のために接続を行ったのか、理由を記載できるようになりました。ここで記載した理由はセッションマネージャーの履歴や CloudTrail イベントで確認できます。

……やったぜ!

SSM セッションマネージャーの設定変更

早速、最大セッション期間の設定を試してみます。

Systems Manager のサービス画面から、「セッションマネージャー」→「設定」→「編集」を押下します。

AWS_Systems_Manager_-_Session_Manager_edit

最大セッション期間を有効化し、期間を指定します。 1 〜 1,440 分(24時間)を指定可能です。

AWS_Systems_Manager_-_Session_Manager_max

設定を保存して更新完了です。今回はミニマムの 1 分を指定してみました。

AWS_Systems_Manager_-_Session_Manager_max-7234925

ちなみにこういった設定は、自己所有の Systems Manager ドキュメントSSM-SessionManagerRunShellから確認できます。

AWS_Systems_Manager_-_Documents_session

ドキュメントのコンテンツを確認すると、今回の設定変更が反映されていることがわかります。

SSM-SessionManagerRunShell

{
  "schemaVersion": "1.0",
  "description": "Document to hold regional settings for Session Manager",
  "sessionType": "Standard_Stream",
  "inputs": {
    "s3BucketName": "chiba-ssm-log",
    "s3KeyPrefix": "SSMLogs",
    "s3EncryptionEnabled": false,
    "cloudWatchLogGroupName": "SSMLogs",
    "cloudWatchEncryptionEnabled": false,
    "idleSessionTimeout": "20",
    "maxSessionDuration": "1",
    "cloudWatchStreamingEnabled": true,
    "kmsKeyId": "",
    "runAsEnabled": false,
    "runAsDefaultUser": "",
    "shellProfile": {
      "windows": "",
      "linux": ""
    }
  }
}

SSM セッションマネージャー接続の開始( EC2 画面から)

早速この状態でセッションマネージャー接続を開始します。

おそらく一番ベーシックであろう、EC2 のサービス画面からの接続です。

Session_Manager_EC2

はい。

SessionManager

接続が開始されました。

これまでは見られなかった、残り時間を示す表示が画面上部に確認できます。ヒリヒリしますね。

AWS_Systems_Manager_-_Session_Manager_MAX-7235315

分単位での表示なので、「残り 30 秒……」といった細かい確認はできません。

時間を迎えると、メッセージとともに接続が切断されます。

AWS_Systems_Manager_-_Session_Manager_intrupt

セッションが次の理由で終了されました。 Max session duration reached. Your session has been terminated.

画面の奥でうっすらと、0 minutesとなっていることが確認できます。今回はミニマムの 1 分からのスタートだったので分かりづらいですが、2 分以上を指定していれば残り時間がカウントダウンされていきます。

SSM セッションマネージャー接続の開始( SSM 画面から)

今回のアップデートでもう一つできるようになった「理由の追加」を確認します。

EC2 画面からの接続開始ではそういった指定ができる箇所はなかったな……?と思ったのですが、Systems Manager の画面からもセッションマネージャー接続を開始でき、そちらで指定可能です。

Systems Manager の画面から、「Session Manager」→「セッション」→「セッションの開始」を押下します。

AWS_Systems_Manager_-_Session_Manager_start_Session

ここで理由を追加できます。最大で 256 文字までです。

こういった場面でマルチバイト文字を使うのは邪道ですが、「セッションを開始する理由?そりゃそこにセッションがあるからだろう」と発作的に思ったので、その思いを込めました。

AWS_Systems_Manager_-_Session_Manager_reason

接続が開始された後の操作は、先ほどの EC2 画面からの接続と変わりありません。

接続を切断すると、セッション履歴が記録されます。Reason列で、先ほど指定した理由が確認できます。

AWS_Systems_Manager_-_Session_Manager_Reason-7238435

これなら後から見返しても、何のための接続かが一目瞭然ですね。

そして、こういった接続の開始は CloudTrail ではStartSessionとして記録されます。イベントの内訳を確認すると、ここでも理由を確認できます。

StartSession

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAQ3BIIH732QEGJXBGU:cm-chiba.yukihiro",
        "arn": "arn:aws:sts::000000000000:assumed-role/cm-chiba.yukihiro/cm-chiba.yukihiro",
        "accountId": "000000000000",
        "accessKeyId": "ASIAQ3BIIH73ZQ6HAU5N",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROAQ3BIIH732QEGJXBGU",
                "arn": "arn:aws:iam::000000000000:role/cm-chiba.yukihiro",
                "accountId": "000000000000",
                "userName": "cm-chiba.yukihiro"
            },
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2021-11-18T10:48:56Z",
                "mfaAuthenticated": "true"
            }
        }
    },
    "eventTime": "2021-11-18T11:55:39Z",
    "eventSource": "ssm.amazonaws.com",
    "eventName": "StartSession",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "219.xx.xx.xx",
    "userAgent": "aws-internal/3 aws-sdk-java/1.12.100 Linux/5.4.147-83.259.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/25.312-b07 java/1.8.0_312 vendor/Oracle_Corporation cfg/retry-mode/standard",
    "requestParameters": {
        "target": "i-047875da17caa9cc2",
        "reason": "そこにセッションがあるから"
    },
    "responseElements": {
        "sessionId": "cm-chiba.yukihiro-07410a2ea602eeaa5",
        "tokenValue": "Value hidden due to security reasons.",
        "streamUrl": "wss://ssmmessages.ap-northeast-1.amazonaws.com/v1/data-channel/cm-chiba.yukihiro-07410a2ea602eeaa5?role=publish_subscribe"
    },
    "requestID": "b040b285-f80e-42b0-a869-e61d1534d0c6",
    "eventID": "02a59438-fdc7-4265-a006-fa8d0f98f7b8",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "000000000000",
    "eventCategory": "Management",
    "sessionCredentialFromConsole": "true"
}

まとめ

  • 最大セッション期間を 1 - 1,440 minutes の間で指定できる
    • セッションマネージャー接続時に残り時間がわかる
  • セッション開始時に理由を追加できる
    • セッションマネージャーの履歴や、CloudTrail イベントで確認できる
    • マネジメントコンソールから接続する場合、Systems Manager の画面から接続することで理由の指定が可能

終わりに

Systems Manager セッションマネージャーに関するアップデートを確認しました。

従来からアイドルセッションタイムアウトがあったため「意図せず接続しっぱなしであった」という状況は起こり得ませんでしたが、また別の切り口で時間制限を設けられるようになったのは嬉しい方が多いのではないでしょうか。(あまり短い時間を指定すると、作業途中に切断されるという悲劇を生みかねませんが……)

理由を追加できるのも、後から履歴を見直したときに一目瞭然になるので痒い所に手が届く改善ですね。

比較的監査をしっかりやっているような環境に刺さるアップデートだったのではないでしょうか。ご活用ください。

以上、 チバユキ (@batchicchi) がお送りしました。