外部IdP（EntraID）＋AWS IAM Identity Center＋SSMで実現するOSパスワードレス運用 ～Entra ID B2B対応の実践ノウハウ～

はじめに

クラウド時代の運用現場では、OSパスワード管理の煩雑さやセキュリティリスクが大きな課題となっています。

本記事では、外部IdP（EntraID）＋AWS IAM Identity Center＋SSMを活用し、LinuxやWindowsサーバーへの管理接続において「パスワードレス運用」を実現するための実践ノウハウを紹介します。

特に「Microsoft EntraID B2B」を活用した場合の課題と、その解決策にフォーカスします。

なお、今回紹介するソリューションに利用する機能は下記になりますが、個々の設定は他記事でも多く案内されていますので、ここでは触れていません。AWS公式ドキュメントを参照ください。

システム構成とログインフロー

構成要素：

• EntraID（外部IdP）
• AWS IAM Identity Center
• SSM Sessionマネージャ/SSM Fleetマネージャ

ログインの流れ：

1. EntraIDでユーザ認証
2. IAM Identity Center経由でAWSにサインイン
3. SSMを通じて、EntraIDより連携されるuserPrincipalName（UPN）をユーザIDとして各OSにログイン

主要な課題と解決策

Windowsの場合

● 課題

CLIのSSM SessionマネージャとGUIのFleetマネージャの2種類が利用できますが、

• CLIのSSM Session Manager利用時、共通ユーザ「ec2-user」で接続され、個別ユーザでのログインができない
• そのため、OSのセキュリティログに記録されるユーザIDが共用となり、個人の特定が困難

※GUIのFleetマネージャを利用時は、EntraIDより連携されるUPNの情報を基にユーザIDが生成され、個々のユーザにてログインできます。

メールアドレス（kazuhisa.ban@ctc-g.co.jp）をUPNとして利用時に、OS側で生成されるユーザID

● 解決策

• AWSの仕様上、LinuxのようなRunAsは利用不可
• 運用ルールと発見的統制で対応
  1. EventBridge＋Lambdaで“StartSession”イベントを検知し、インスタンスIDからOS種別のWindowsのみ通知
  2. 利用ガイドラインで「WindowsはSSM Session Manager原則利用禁止」と明記し、利用時は管理者へ通知

Linuxの場合

● 課題

• SSO実現には事前にOSへユーザーID登録が必要
• EntraIDから連携されるUPN（メールアドレス形式）に「@」などの禁止文字が含まれると利用不可
• EntraID B2B利用時はメールアドレスで招待するため、UPNのままでは利用できない

● 解決策

• メールアドレスの「@」以降を除いた値をAWS IAM Identity Centerに連携し、SSM Session ManagerのRunAs用ユーザーIDとして利用
• AWS IAM Identity Centerの「アクセスコントロールの属性」に、
  1. キー：SSMSessionRunAs
  2. 値：${path:enterprise.division}

を設定

下図が、AWS IAM Identity Centerの該当する設定画面

属性マッピングのポイント

EntraID B2Bを念頭にメールアドレスをUPNに使いつつ、動的にメールアドレスの@以降を省いた値をAWS IAM Identity Centerへ連携する属性に代入する策が最良です。

この方法であれば、影響範囲はAWS IAM Identity Centerと連携させるEntraIDのエンタープライズアプリケーション定義に限定され、他への影響はありません。

また、下表の案とおり課題が残さずに対応できます。

なお、下図のように表示名（属性名：displayName）がアルファベットで統一している場合は案1、案2の採用が可能です。

属性マッピング

EntraIDの属性からAWS IAM Identity Centerへ連携可能な主な属性は以下の通りです。

詳細は、下記の公式サイトをご参照ください。

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html#supportedidpattributes

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html#defaultattributemappings

● 設定手順（例）

EntraIDのエンタープライズアプリケーション設定

利用されることが少ないと思われる部門属性（urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:division）に、メールアドレスの＠ドメインを省いた値を代入する手順を示します。

1. エンタープライズアプリケーションに設定されているAWS IAM Identity Centerのプロビジョニングより、マッピングから、Usersを選択

2. 属性マッピングの画面を下にスクロールして、新しいマッピングの追加を選択

3. マッピング種類に式を選択し、式に下記の値を入力

• 式：Replace(IIF(IsNullOrEmpty([mail]), [userPrincipalName], [mail]), , "(?@(.)*)", "Suffix", "", , )
• 対象の属性：urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:division

※式は、Microsoft公式サイトの値を転用

https://learn.microsoft.com/en-us/entra/identity/app-provisioning/functions-for-customizing-application-data#replace

4. 設定後に、AWS IAM Identity Centerへプロビジョニング後、ジョブ関連の課属性に値が入ってきます

5. AWS IAM Identity Centerのアクセスコントロールの属性にて、下記の値を設定する。

• キー：SSMSessionRunAs
• 値：${path:enterprise.division} を指定する。

下図が、AWS IAM Identity Centerの該当する設定画面

6. SSM Sessionマネージャの設定で「LinuxインスタンスのRun Asサポート」を有効化する。

7. 事前にLinuxへ「kazuhisa.ban」をOSユーザとして登録後、SSM Sessionマネージャから接続することで、接続ができます。

監査ログの考え方：ポテンヒットを防ぐために

OS内のSSM Sessionエージェントログから、利用者の特定することも可能です。

コマンド：sudo cat /var/log/amazon/ssm/amazon-ssm-agent.log

少し整形

sudo grep 'Payload:' /var/log/amazon/ssm/amazon-ssm-agent.log \
| sed 's/^.*Payload: //' \
| jq -r '
  .content
  | fromjson
  | {
      session_id: .SessionId,
      runas_user: .RunAsUser,
      session_owner: .SessionOwner
    }
'

タイムスタンプを加えて、接続日時を特定

sudo grep 'Payload:' /var/log/amazon/ssm/amazon-ssm-agent.log \
| sed 's/^//' \
| awk '{print $1 " " $2 "|" substr($0, index($0,"Payload: ")+9)}' \
| awk -F'|' '{print $1 "\t" $2}' \
| while IFS=$'\t' read -r ts payload; do
    echo "$payload" \
    | jq -r --arg ts "$ts" '
        .content
        | fromjson
        | [
            $ts,
            .SessionId,
            .RunAsUser,
            .SessionOwner
          ]
        | @csv
      '
  done

まとめ

この構成により、OSパスワードの運用負荷は劇的に下がる。

• パスワードポリシーの設計（管理者）
• パスワード初期化運用の排除（管理者）
• 利用者が多数のEC2にログインするパスワード管理の排除（利用者）

自社/B2B連携する他社のEntraIDにて管理する属性利用のポリシーが大きく影響する。

• 自社/他社の属性ポリシーに影響を受けない施策が必要
• EntraIDエンタープライズアプリケーションに登録する個々の定義で対応する
  ※EntraIDは情シス管理下にあることが多いので、全体影響する施策は受け入れられない

WindowsとLinuxでOS上の監査ログにおいてポテンヒットを理解し、運用ルールやCloudTrailでの補完を検討する。

一つの目的（OSパスワード運用の脱却）達成することで、別の課題が浮上する。それを踏まえ何をトレードオフするかが重要です。

この例では、CloudTrailを合わせた監査運用するという運用負荷が１つ増えますが、個々の仮想マシンに対する設定の負荷と、CloudTrailの調査する仕組みを検討する負荷の重さを比較し、よりよい方向へ進めばとよいと考えます。

また、トレードオフした結果、Linux向けSSMセッションマネージャの利用にルールを設け、スイッチロールを行う運用が合致するケースもあると思います。

今回はちょっとしたTipsになりますが、外部IdP（EntraID）＋AWS IAM Identity Center＋SSMを活用し、EC2を利用されている方にとっては、有用な情報と思っています。

一度は仮想マシンのシングルサインオンを断念した方、これをきっかけにパスワード管理からの脱却を再度検討してはいかがでしょうか。

今回共有したノウハウが、皆さまの課題解決や運用効率化の一助となれば幸いです。