SAMLセッションタグを使用してフェデレーションユーザーのSession Managerアクセスを構成する

このブログ投稿では、フェデレーションユーザーに対して、AWS Systems Manager Session Managerへのアクセス権限を属性ベースのアクセスコントロール（ABAC=Attribute Based Access Control）にて設定する方法を示します。SAML セッションタグを使用することで、外部IDシステムで定義された属性をAWS内のABACの判定の一部として使用できます。たとえば、AWS Identity and Access Management（IAM）ユーザーが所属する部門に基づいて、特定のマネージドインスタンスへのアクセスを許可することができます。フェデレーションユーザーが使用できる属性の詳細については、「新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する」を参照してください。

Session Managerを使用すると、Amazon EC2インスタンスおよびハイブリッド環境（オンプレミスサーバーと仮想マシン（VM）、他のクラウド環境でホストされているVMを含む）を、ワンクリックで開くインタラクティブなブラウザーベースのシェルまたはAWS CLIを介して管理できます。これはセキュアで監査可能な方法でおこなわれ、受信ポートを開いたり踏み台ホストを維持したりSSHキーを管理したりする必要がありません。Session Managerへのアクセス権限はIAMポリシーを介して管理できます。それにより、誰がどのリソースに対しアクセスでき、インタラクティブ操作を可能とするかを制御できます。

この投稿では、AWS Systems Managerの機能へのアクセスを制限するために、SAMLセッションタグと外部ID属性を使用してアクセス許可を設定する手順について説明します。

ソリューションの概要

以下にソリューション概要のアーキテクチャ図を示します。

図1: ソリューションアーキテクチャ図

AliceとBobが外部IDプロバイダー（IdP）を使用してAWSマネジメントコンソールにフェデレートする例を見てみましょう。それぞれが所属する部門であるAmberとBlueに基づいて、特定のEC2インスタンスへのSession Managerを使用したアクセスが可能となります。

この例ではOktaを使用したIAMフェデレーションを示していますが、このソリューションは、システムで定義された属性をAWSセッションに正しく渡すことのできる、任意の外部IDプロバイダーを使用することができます。

前提条件

ABACにSAMLセッションタグを使用するには、外部IDプロバイダーとのIAMフェデレーションを構成しておく必要があります。詳細については、IAMユーザーガイドで”SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする”と、Oktaウェブサイトで”How to Configure SAML 2.0 for AWS Account Federation”を確認してください。

また、Session Managerを介してインスタンスへのコンソールセッションを作成するには、EC2インスタンスとSession Managerを構成しておく必要があります。詳細については、”Session Manager の開始方法“を確認してください。

ソリューションを実装する

ソリューションを実装するには、次の手順を行います。

ABAC IAMポリシーを作成します。
SAMLベースのフェデレーション用IAMロールを変更します。
Oktaの動的SAML属性を構成します。
Oktaのユーザー属性を変更します。
マネージドインスタンスに対しEC2タグを作成します。

Step 1 – ABAC IAMポリシーの作成

最小権限の原則に基づいて、CustomSessionManagerPolicyという名前のポリシーを作成します（このポリシーは、次の手順でロールに追加します）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:describeInstances",
                "ssm:DescribeSessions",
                "ssm:DescribeInstanceProperties",
                "ssm:GetConnectionStatus"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ssm:resourceTag/department": "${aws:PrincipalTag/department}"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession"
            ],
            "Resource": [
                "arn:aws:ssm:::session/${aws:PrincipalTag/login}-*"
            ]
        }
    ]
}

最初のブロックは、接続可能なEC2インスタンスをAWS Session Managerコンソールにて一覧表示できる権限をフェデレーションユーザーに与えています。

2番目のブロックは、リソースタグのdepartmentの値がプリンシパルタグのdepartmentの値と一致している条件下において、すべてのリソースでSession ManagerのStartSessionを許可しています。

3番目のステートメントは、Session ManagerのTerminateSessionができる権限を、同じフェデレーションユーザーによって作成されたセッションリソースに制限します。リソースセッションARNの構造にはセッションを開始したプリンシパルが含まれるため、プリンシパルタグのlogin値を変数 ${aws:PrincipalTag/login} としてポリシーで使用することでARNと一致させます。

Step 2 – SAMLベースのフェデレーション用IAMロールの変更

Step 2A – 信頼ポリシーの変更

セッションタグを渡すため、ロールの信頼ポリシーにAWS STS TagSessionアクションを追加します。2番目の条件はオプションです。StringLikeを使用して特定のセッションタグのみに限定しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/Okta"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.thinkwithwp.com/saml"
        },
        "StringLike": {
          "aws:RequestTag/login": "*",
          "aws:RequestTag/department": "*"
        }
      }
    }
  ]
}

このステートメントにより、フェデレーションユーザーは、Okta IDプロバイダーからAWSにフェデレートするときに、ロールを引き受けてセッションタグを渡すことができます。 IDの属性は、loginタグとdepartmentタグとして任意の値を持つことができます。詳細については、IAMユーザーガイドの”ABAC での SAML セッションタグの使用“を確認してください。

Step 2B – ABAC IAMポリシーの追加

前の手順で作成したCustomSessionManagerPolicyポリシーをSAMLベースのフェデレーション用IAMロールにアタッチします。これは、SAML経由でのOktaフェデレーションの初期セットアップの際に作成したロールです（上記の前提条件を参照）。

Step 3 – Oktaの動的SAML属性の構成

重要：この機能を有効にするには、Okta customer supportに連絡して、機能フラグOIN_SAML2_DYNAMIC_ATTRIBUTESを有効にするよう依頼する必要がある場合があります。

次に示すように、name、name format、valueを追加して、SAML 2.0サインオンメソッドセクションの属性を構成します。

Name	Name format	Value
https://thinkwithwp.com/SAML/Attributes/PrincipalTag:login	URI reference	user.login
https://thinkwithwp.com/SAML/Attributes/PrincipalTag:department	URI reference	user.department

OktaコンソールでSAML属性を確認します。

図2: Oktaコンソールでの必須のSAML属性

これらの変更を保存する前に、SAMLオプションをプレビューして、新しいSAML属性を確認できます。

<saml2:Attribute Name="https://thinkwithwp.com/SAML/Attributes/PrincipalTag:login" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.login</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="https://thinkwithwp.com/SAML/Attributes/PrincipalTag:department" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user.department</saml2:AttributeValue>
</saml2:Attribute>

Step 4 – Oktaのユーザー属性の変更

AliceとBobのユーザープロファイルのdepartment属性値をそれぞれAmberとBlueに変更します。ログイン属性値は、ユーザーのメールアドレスを使用してデフォルトですでに設定されています（例：alice@example.comやbob@example.com）。

Oktaコンソールのユーザー属性は次のようになります。

図3: OktaコンソールでのAliceのユーザープロファイル属性

図4: OktaコンソールでのBobのユーザープロファイル属性

Step 5 – マネージドインスタンスに対しEC2タグの作成

このリソース属性に基づいてアクセスを許可するため、EC2インスタンスにタグを付けます。 EC2コンソールで、[タグの追加/編集]を選択します。以下の例（department：amber）のように、インスタンスごとに特定のkey：valuesを指定してください。

図5: EC2コンソールでのインスタンスタグ

ソリューションをテストする

Aliceの認証情報を使用してOktaにログインし、Amazon Web Services Applicationを選択してAWSマネジメントコンソールにフェデレーテッドログインします。

図6: Oktaログインコンソール

図7: OktaコンソールでのAWS Application

AWSマネジメントコンソールで、AWS Systems Managerを検索します。 AWS Systems Managerコンソールが表示されたら、Session Managerに移動し、[セッションの開始]を選択します。接続可能なEC2インスタンスのリストが表示されます。amber-instanceを選択し、[セッションを開始する]をクリックします。

図8: Session Managerコンソール

Aliceの認証情報を使用してフェデレーテッドログインしたため、プリンシパルのdepartmentタグの値がリソースタグの値と一致し、セッションの開始が許可されます。新しいタブにリダイレクトされ、keyがdepartment、ValueがAmberとタグ付けされたEC2インスタンスへのアクセスができることを確認してください。

図9: Session Managerのアクティブセッションの例

blue-instanceというEC2インスタンスを選択してセッションを開始しようとすると、（予期された）許可されていない旨のメッセージが表示されます。

User: arn:aws:sts::123456789012:assumed-role/OktaUsers/alice@example.com is not authorized to perform: ssm:StartSession on resource: arn:aws:ec2:eu-west-3:123456789012:instance/i-0b0444bb293823cd0

セッションを終了できるのは、自身で開始したセッションのみです。この場合、セッションIDにはAliceプリンシパルのloginタグの値が含まれ、ABACポリシーリソースと一致するため、terminateアクションが許可されます。

Bobによって開始されたセッションを終了しようとすると、次の（予期された）許可されていない旨のメッセージが表示されます。

User: arn:aws:sts::123456789012:assumed-role/OktaUsers/alice@exampe.com is not authorized to perform: ssm:TerminateSession on resource: arn:aws:ssm:eu-west-3:123456789012:session/bob@example.com-01020dff18f1670d3

まとめ

このブログ投稿では、SAML属性を使用して、特定のマネージドインスタンスへのSession Managerアクセスを制御する方法を示しました。

はじめに、SAML属性と一致するAWSセッションタグに基づいてアクセスを制限するための、IAM ABACポリシーを作成する方法を示しました。そしてフェデレーション用IAMロールの信頼ポリシーを変更する方法を示しました。

次に、Oktaの動的SAML属性を構成してサインオンSAML属性を変更し、AWSセッションタグに必要な情報をユーザープロファイルに含める方法を示しました。

最後に、各フェデレーションユーザーが適切な属性でタグ付けされたインスタンスでセッションを開始できることを確認して、ソリューションをテストしました。また、自分で作成したセッションを終了できることを確認しました。

著者について

Iago SánchezはAWSプレミアムサポートのクラウドサポートエンジニアです。彼はAWS Systems ManagerとAmazon EC2 Windowsを専門としています。仕事以外では、友人や家族と過ごしたり、ビデオゲームをしたり、ギターの弾き方の知っているふりをしたりしています。

Rodrigo Ferroniは、AWS Enterprise Supportのシニアセキュリティスペシャリストです。彼はCISSP、AWS Security Specialist、およびAWS Solutions Architect Associateを保持しています。彼は、お客様がクラウドでのセキュリティ構成を改善するために、AWSセキュリティサービスに関する支援を行なっています。仕事以外では、旅行をするのが大好きです。毎冬、友達とスノーボードを楽しんでいます。

翻訳はSA石橋が担当しました。原文はこちら。

Amazon Web Services ブログ