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

本日から、AWS Single Sign-On を使用してお客様の従業員がクラウドにサインインする際に、AWS セッションでユーザー属性を渡すことができるようになりました。これにより、AWS Single Sign-On および ABAC のアカウントアクセスを一元管理でき、AWS SSO、Active Directory、または外部 ID プロバイダーを ID ソースとしてを柔軟に使用できます。AWS での ABAC ポリシーの利点の詳細については、このテーマに関する私の以前のブログ記事をお読みください。

概要
一方では、システム管理者は AWS Single Sign-On ID リポジトリまたはマネージド Active Directory でユーザー属性を設定します。システム管理者は、Okta、OneLogin、または PingIdentity などの外部 ID プロバイダーを設定して、従業員が AWS にフェデレートするときに AWS セッションで既存のユーザー属性を渡すこともできます。これらの属性は、AWS ではセッションタグと呼ばれます。他方、クラウド管理者は、従業員が一致するリソースタグを持つクラウドリソースにのみアクセスできるように、きめ細かいアクセス許可ポリシーを作成します。

機能ロールの代わりに一致する属性に基づいてポリシーを作成すると、AWS 環境で作成および管理する必要がある個別のアクセス許可とロールの数を減らすことができます。たとえば、チームレッドのデベロッパーである Bob およびチームブルーのデベロッパーである Alice が AWS にサインインし、同じ AWS Identity and Access Management (IAM) ロールを引き受けると、チーム用にタグ付けされたプロジェクトリソースに対する個別のアクセス許可が与えられます。Bob と Alice が AWS にサインインすると、ID システムは AWS セッションでチーム名属性を送信します。ロールのアクセス許可は、一致するチーム名タグを持つプロジェクトリソースへのアクセス権を付与します。これで、Bob がチームブルーに移行し、システム管理者が ID プロバイダーディレクトリでチーム名を更新すると、Bob は IAM でアクセス許可を更新することなく、チームブルーのプロジェクトリソースに自動的にアクセスできます。

ユーザー属性をマップするように AWS SSO を設定する方法
AWS SSO を設定する前に、強調しておくべき重要なポイントが 2 つあります。まず、ABAC は、AWS SSO で設定された任意の ID ソース (AWS SSO 自体、マネージド Active Directory、または外部 ID プロバイダー) の属性を使用して動作します。次に、AWS SSO にアクセスコントロールの属性を渡すには、2 つの方法があります。プレフィックス https://thinkwithwp.com/SAML/Attributes/AccessControl を使用して SAML アサーションで属性を直接渡すか、AWS SSO ID ストアにある属性を使用できます。これらの属性は、AWS SSO 管理者によって、AWS SSO で作成されたユーザー、Active Directory から同期されたユーザー、または自動プロビジョニング (SCIM) を使用する外部 ID プロバイダー同期されたユーザーについて設定されます。

このデモでは、外部 ID プロバイダーと SCIM を使用することを選択します。

AWS SSO を使用して AWS で ABAC を有効にするには、次の 3 つのステップを実行します。

ステップ 1: 外部 ID プロバイダーの関連付けられたユーザー ID と属性を使用して、自分の ID ソースを設定します。今日の時点で、AWS SSO は、Azure AD、Okta、OneLogin、および PingIdentity と SCIM 経由の ID 同期をサポートしています。最新のリストを取得するには、このページをチェックしてください。詳細は、各 ID プロバイダーによって異なります。

ステップ 2: AWS SSO コンソールまたは API の新しいアクセスコントロール属性グローバル設定を使用して、アクセスコントロールに使用する SCIM 属性を設定します。この画面では、ステップ 1 で設定した ID ソースから、アクセスコントロールの属性を選択できます。

ステップ 3: ステップ 2 で設定した属性を使用して、アクセス許可セットとリソースベースのポリシーを使用して ABAC ルールを作成できます。これについては、すぐ後に詳細を確認します。

これで、従業員が SSO を使用して AWS アカウントにフェデレートすると、一致する属性に基づいて AWS リソースにアクセスできます。

属性はセッションタグとして渡されます。これらは、カンマで区切られたキー:値のペアとして渡されます。すべての属性の合計文字数は、460 文字以下である必要があります。

ポリシーについて
アクセスコントロールルールを作成するときに、aws:PrincipalTag 条件キーを使用して、アクセス許可セットでユーザー属性を使用できるようになりました。たとえば、組織内のすべてのリソースにそれぞれの部門名でタグを付けて、デベロッパーが所属する部門のリソースにのみアクセスできるようにする 1 つのアクセス許可セットを使用できます。これで、デベロッパーが AWS アカウントにフェデレートするたびに、AWS SSO は ID プロバイダーから受け取った値を使用して部門セッションタグを作成します。セキュリティポリシーでは、デベロッパーが所属する各部門のリソースへのアクセスのみを許可します。チームはプロジェクトにデベロッパーとリソースを追加する場合であっても、私が必要なのは、リソースに正しい部門名でタグを付けることだけです。その結果、組織が部署に新しいリソースとデベロッパーを追加すると、デベロッパーはアクセス許可の更新を必要とせずに、各部門用に調整されたリソースのみを管理できます。

ABAC SSO アクセス許可セットポリシーは次のようになります。

{
    "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}"
                }
            }
        }
    ]
}

このポリシーでは、すべてのユーザーに DescribeInstances を許可しますが、aws:PrincipalTag/Department タグの値が EC2 インスタンスの ec2:ResourceTag/Department タグの値と一致しているユーザーのみが、インスタンスを停止または開始できます。

このポリシーを AWS アカウントのアクセス許可セットにアタッチします。AWS Single Sign-On コンソールの左側で、[AWS アカウント] をクリックし、[アクセス許可セット] タブを選択します。次に、[アクセス許可セットの作成] をクリックします。次の画面で、[顧客アクセス許可セットの作成] を選択します。

名前と説明を入力し、[カスタムアクセス許可ポリシーの作成] が選択されていることを確認します。次に、以前のポリシーをコピーして貼り付けて、部門名タグの値がユーザーの部門名タグの値と等しい場合に EC2 インスタンスを開始および停止できます。

次の画面で、タグを入力し、[作成] をクリックする前に設定を確認します。これで完了です。

AWS Security Token Service を使用して既存のフェデレーションを設定している場合、外部 ID プロバイダーは AWS SSO を新しいアプリケーション設定とみなします。つまり、直接 IAM フェデレーションから AWS SSO に移行する場合、AWS SSO に接続し、この設定のセッションタグとして属性を導入するように外部 ID プロバイダーの設定を更新する必要があります。

今すぐご利用いただけます
AWS Single Sign-On でユーザー属性を設定する場合、追加料金はかかりません。AWS SSO が利用可能なすべての AWS リージョンで、今すぐ使用を開始できます。

— Seb