AWS SSOのIDストアをAzure ADにしている環境においてABACを行う方法

AWS SSO と Azure AD を SAML 2.0 で認証連携している環境において、Azure AD の属性情報を用いて AWS で属性ベースのアクセスコントロールを行う方法を紹介します。

yhana

2022.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS SSO と Azure AD を SAML 2.0 で認証連携している環境において、Azure AD のユーザーの属性情報を用いて AWS で ABAC (Attribute-based access control) を行う方法を紹介します。例えば、開発部門のユーザーが開発部門を示すタグが付いた EC2 のみ操作できる、といった制御ができます。

ABAC とは何かの説明やどのようなときに利用すべきかを知りたい方は、まずは次の 2 つのブログから見ることをおすすめします。


ABAC に利用するユーザー属性情報の指定方法

ABAC に利用する Azure AD ユーザーの属性情報を指定する方法は 2 つあります。

  • AWS SSO 側で設定する方法
  • Azure AD 側で設定する方法

それぞれの設定イメージを説明します。


AWS SSO 側で設定する方法

AWS SSO 側で設定する場合は、Azure AD から AWS SSO へプロビジョニングされたユーザーの情報を利用します。

AWS SSO の「アクセスコントロールの属性」設定で ABAC に利用する属性情報（氏名や部門名など）を指定することで、AWS アカウントにスイッチロールした際にセッションタグとして属性情報が渡されます。

セッションタグについてはこちらのブログが参考になります。

AWS ユーザーガイドは下記となります。

Passing session tags in AWS STS - AWS Identity and Access Management


Azure AD 側で設定する方法

Azure AD 側で設定する場合は、SAML Response に属性情報を格納することで AWS SSO に ABAC で利用する属性方法を伝えます。Azure AD のエンタープライズアプリケーションの設定において SAML Response に含める属性情報を指定します。


ABAC を試してみた

ABAC の設定のイメージ図を示します。

ユーザーの属性情報である部門名と EC2 インスタンスにタグ付けされている Department の値が一致する場合にインスタンスの起動・停止ができる設定を行います。

今回、試したのは次のブログで紹介している手順で構築した環境となります。


事前準備

始めに Azure AD において、テスト用に部門が Development のユーザーと Operation のユーザーを作成します。

次の準備として、AWS 側でテスト用に EC2 インスタンスを 2 台構築した後にタグ Department を付与します。タグの値は Development と Operation にします。

AWS SSO において、アクセスコントロールの属性を有効化します。

以降は ABAC で利用する属性情報を設定していきますが、AWS SSO 側で設定する方法と Azure AD 側で設定する方法で内容が変わりますので、それぞれ試してみます。


AWS SSO 側で設定する方法

AWS SSO の設定画面からアクセスコントロールの属性として次の内容を設定します。

キー：Department
値：${path:enterprise.department}

キーは、EC2　に設定しているタグのキー名と同じにする必要があります。

値には、外部 ID プロバイダーである Azure AD の属性を指定します。サポートされている外部 ID プロバイダーの属性は次のドキュメントを確認して設定を行います。

Attribute mappings - AWS Single Sign-On

また、Azure AD のユーザーにおける 部門 と AWS SSO のユーザーににおける 部 とのマッピングは SCIM により行われており、マッピングの定義は Azure AD のエンタープライズアプリケーションのプロビジョニングの項目で設定されています。

2022 年 2 月 27 日時点のエンタープライズアプリケーションのギャラリー AWS Single Sgin-on では、department はデフォルトで設定されていたため、このまま利用します。

SCIM の設定に関しては、次のチュートリアルが役立ちます。

Tutorial - Develop a SCIM endpoint for user provisioning to apps from Azure Active Directory | Microsoft Docs

このあたりの設定がややこしいと思ったのですが、Azure AD のマッピング設定における属性の値と AWS SSO のアクセスコントロールの属性設定で利用される値、さらに AWS SSO のユーザー画面で表示される属性名との一連の対応を記載したドキュメントは見つけることはできませんでした（リサーチ不足なだけかもしれません）


次に、AWS SSO のアクセス権限セットを設定します。

カスタムアクセス権限ポリシーに ABAC のポリシーを記載します。今回は EC2 に付与されている ResourceTag とユーザーの属性情報が設定されている PrincipalTag を比較して同じ内容なら起動・停止ができるポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
                }
            }
        }
    ]
}


以上で設定は終わりであり、ここからは動作確認となります。

始めに、部門が Development である Test User1 で試します。

タグ Key=Department, Value=Development を設定しているインスタンスは起動に成功しました。

タグ Key=Department, Value=Operation を設定しているインスタンスは起動に失敗しました。

次に、部門が Operation である Test User2 で試します。

タグ Key=Department, Value=Development を設定しているインスタンスは起動に失敗しました。

タグ Key=Department, Value=Operation を設定しているインスタンスは起動に成功しました。

意図通り動作することを確認できました。


Azure AD 側で設定する方法

AWS SSO との認証連携の設定を行っている Azure AD のエンタープライズアプリケーションにおけるシングルサインオンの設定を変更します。

ABAC で利用するユーザーの部門情報を AWS SSO に伝えるために「属性とクレーム」に次の情報を追加します。

名前：AccessControl:Department
名前空間：https://aws.amazon.com/SAML/Attributes
ソース：属性
ソース情報：user.department

指定する「名前 (Name) 」「名前空間 (Namespace) 」「ソース (Source) 」「ソース属性 (Source attribute) 」は AWS のユーザーガイドに記載があります

Azure AD - AWS Single Sign-On

次に、AWS SSO 側でアクセス権限セットを設定します。設定内容は AWS SSO 側で設定する方法と同様です。

カスタムアクセス権限ポリシーも AWS SSO 側で設定する方法と同様のポリシーです。

EC2 に付与されている ResourceTag とユーザーの属性情報が設定されている PrincipalTag を比較して同じ内容なら起動・停止ができるポリシーとなります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
                }
            }
        }
    ]
}

Azure AD のシングルサインオンのテスト機能を用いて SAML Response を確認したところ、Department 属性が格納されていました。

一部抜粋した SAML Response の内容です。

<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
    <AttributeValue>Test</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
    <AttributeValue>User1</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
    <AttributeValue>test-user1@example.net</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
    <AttributeValue>test-user1@example.net</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/AccessControl:Department">
    <AttributeValue>Development</AttributeValue>
</Attribute>


以上で設定は終わりです。

AWS SSO 側で設定する方法と異なり、AWS SSO においてアクセスコントロールの属性の追加は不要です。そのため、Azure AD 管理者と AWS SSO 管理者の間で ABAC に利用する属性情報を事前に連携しておく必要があります。

ここからは動作確認となります。

始めに、部門が Development である Test User1 で試します。

タグ Key=Department, Value=Development を設定しているインスタンスは起動に成功しました。

タグ Key=Department, Value=Operation を設定しているインスタンスは起動に失敗しました。

次に、部門が Operation である Test User2 で試します。

タグ Key=Department, Value=Development を設定しているインスタンスは起動に失敗しました。

タグ Key=Department, Value=Operation を設定しているインスタンスは起動に成功しました。

Azure AD 側で設定する方法においても、意図通り動作することを確認できました。


ABAC に利用される属性情報の確認方法

ABAC で利用するタグ情報はセッションタグとして渡されます。

セッションタグが渡されているかを確認する場合は、CloudTrail においてイベント名 AssumeRoleWithSAML で検索することで確認可能です。

principalTags に指定した属性情報が格納されていることが確認できます。principalTags がない場合は設定誤りの可能性があります。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "SAMLUser",
        "principalId": "AROAIDPPEZS35WEXAMPLE:test-user1@example.net",
        "userName": "test-user1@example.net",
        "identityProvider": "AROAIDPPEZS35"
    },
    "eventTime": "2022-02-27T12:30:25Z",
    "eventSource": "sts.amazonaws.com",
    "eventName": "AssumeRoleWithSAML",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "xxx.xxx.xxx.xxx",
    "userAgent": "xxxxxx",
    "requestParameters": {
        "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE",
        "roleSessionName": "test-user1@example.net",
        "principalTags": {
            "Department": "Development"
        },
        "durationSeconds": 3600,
        "roleArn": "arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_TestABAC_2aa1c9ce47d99987",
        "principalArn": "arn:aws:iam::111122223333:saml-provider/AWSSSO_3f18e62f5dd69731_DO_NOT_DELETE"
    },
（以下、省略）


さいごに

AWS SSO と Azure AD を SAML 2.0 で認証連携している環境において、Azure AD の属性情報を用いて AWS で属性ベースのアクセスコントロールを行う方法を紹介しました。

設定方法が 2 つあり、始めは違いが分からなったため調べました。どなたかのご参考になれば幸いです。


参考資料

Azure AD - AWS Single Sign-On

新機能 — AWS Single Sign-On による属性ベースのアクセスコントロール | Amazon Web Services ブログ

AWS