OktaとAWSが提携し、セッションタグによるアクセスを簡素化
AWSリソースへのアクセスの制御を強化するために、Okta管理者は多くのAWSロールを作成する必要があります。これにより、機密/高額のAWSリソースにアクセスできるユーザーを管理できます。
ここでの課題は、下の画面のように、1日のうちにユーザーがさまざまなロールを切り替えて仕事をこなす必要があることです。
Okta管理者が直面するもう1つの課題は、新しいリソースをカバーするために既存のポリシーを変更する必要があることです。AWSセッションタグを使用すると、属性ベースのアクセスに関する新しいアプローチが可能になります。
AWS環境に出入りするリソースについて、属性に基づいてアクセスを許可するポリシーを設定できます。AWSセッションタグは、アクセスできる内容に適切なコンテキストを設定し、ユーザーが常に適切なリソースにアクセスできるようにします。
この記事では、Oktaの動的SAML属性でAWSセッションタグを使って、運用を簡素化する方法について説明します。これによって、ユーザーがAWSで表示できるものの制御を強化できるようになり、さらにログイン時により速く簡単なエクスペリエンスを実現できます。
注：動的SAML属性は、現在アーリーアクセスです。本番組織で有効にするには、Oktaカスタマーサポートに連絡し、機能フラグOIN_SAML2_DYNAMIC_ATTRIBUTESの有効化をリクエストする必要があります。
AWSセッションタグとは？
AWSセッションタグによって、エンドユーザーのSSOエクスペリエンスを簡素化すると同時に、個々のユーザーがアクセスできる対象をより正確に制御できます。
具体的には、AWSセッションタグは、OktaのようなIdPがSAMLアサーションやOIDCトークンに追加できる属性です。AWS側では、Oktaが設定したセッションタグで渡されるものと一致するタグを持つAWSリソースへのアクセスのみを許可する条件のIAMポリシーを定義します。
SAMLの使用に慣れている場合は、AWSセッションタグは単にsaml2:Attributeであり、名前の前にhttps://aws.amazon.com/SAML/Attributes/PrincipalTag:を付けたもの、または名前がhttps://aws.amazon.com/SAML/Attributes/TransitiveTagKeysを含むものです。
上記のように、AWSセッションタグには「PrincipalTag」と「TransitiveTagKeys」の2タイプがあります。
「PrincipalTag」には、AWSに送信したいOktaのプロファイル属性を含めます。AWSに送る属性には、countryCode、costCenter、organization、division、departmentなどがあります。
以下に、「costCenter」を「PrincipalTag」として設定した例を示します。
<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:costCenter"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"> 31415926 </saml2:AttributeValue> </saml2:Attribute
TransitiveTagKeys属性はオプションであり、セッション間で「PrincipalTag」を永続化することをAWSに伝えるために使用されます（AWSアカウント間で移動する場合など）。
以下に、「PrincipalTag」の「costCenter」をTransitive Tag Keyとして設定した例を示します。
<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys"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"> costCenter </saml2:AttributeValue> </saml2:Attribute>
注：TransitiveTagKeysをOktaで使用するには、Okta orgでSAML_SUPPORT_ARRAY_ATTRIBUTES機能が有効になっている必要があります。オプションのTransitiveTagKeys属性を利用したい場合は、Oktaサポートに連絡して、SAML_SUPPORT_ARRAY_ATTRIBUTES機能の有効化をリクエストする必要があります。
AWSセッションタグの活用法
社内に3つのチームがあり、各チームが3〜4件のプロジェクトを持つ例で考えてみましょう。
ユーザーが必要なリソースだけにアクセスできるようにする場合、AWSに3～12種類のロールを用意する必要があります。これらのロールについては、それぞれに固有の属性やリソースに正確にマッピングする必要があり、その上でロールの割り当てを考えます。チームメンバーシップとプロジェクトメンバーシップのどちらに基づいて割り当てるべきか、複数のチームにまたがるプロジェクトをどのように処理するか、新しいプロジェクトが始まったらどのように対処するかなど、検討しなければなりません。
どのようにユーザーをグループ化し、ロールを割り当てたとしても、ユーザーには複数のロールが割り当てられ、定期的にロールを切り替えなければならないでしょう。
AWSセッションタグを使えば、そのような複雑さをすべて解消できます。Oktaは、各ユーザーが所属しているチームやプロジェクトをそのまま伝え、それらのメンバーシップに基づいてAWSでポリシーを作成します。
OktaでAWSセッションタグを構成する方法
AWSセッションタグは、Oktaで動的SAML属性機能を使って構成できます。
前述の「team」と「project」の属性を持つ例を使ってAWSセッションタグを構成するには、次のように操作します。
- 管理者として、OktaでAmazon Web Servicesアプリを開きます。
- Amazon Web ServicesアプリのSign Onタブを開きます。
- Editボタンをクリックします。
- SAML 2.0サインオンメソッドセクションで、Attributes (Optional)部分を開きます。
下図のようなページが表示されます。
Attributesセクションを開いたら、以下のように構成します。
|
名前 |
名前のフォーマット |
値 |
https://aws.amazon.com/SAML/Attributes/PrincipalTag:team |
URI Reference |
user.team |
https://aws.amazon.com/SAML/Attributes/PrincipalTag:project |
URI Reference |
user.project |
https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys |
URI Reference |
{"team", "project"} |
注意点として、オプションのTransitiveTagKeys属性を使用するには、Okta orgでSAML_SUPPORT_ARRAY_ATTRIBUTES機能が有効になっている必要があります。Oktaサポートに連絡して、SAML_SUPPORT_ARRAY_ATTRIBUTES機能の有効化をリクエストしてください。
また、この例では、カスタムの「team」と「project」のクレームを使用していることに注意してください。これらは、Oktaユーザープロファイルと、AWSアプリのアプリユーザープロファイルに追加する必要があります。カスタムユーザープロファイル属性の詳細については、Oktaヘルプセンターで、Oktaユーザープロファイルおよび属性の使用方法に関する記事を参照してください。
OktaでAWSアプリへの属性追加が完了したら、Preview SAMLボタンをクリックします。以下のようなSAMLプレビューが表示されます。
<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:team"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.team</saml2:AttributeValue></saml2:Attribute> <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:project"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.project</saml2:AttributeValue></saml2:Attribute> <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys"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">{"team", "project"}</saml2:AttributeValue> </saml2:Attribute>TransitiveTagKeysタグには、{"team", "project"}という文字列が含まれていますが、これは単にプレビュー用です。SAML_SUPPORT_ARRAY_ATTRIBUTES機能がOkta orgで有効になっている場合、実際のSAMLアサーションには適切な入れ子の属性が含まれています。
完成したら、SAMLアサーションで渡される属性の名前（この例では「team」と「project」）を反映させるために、AWS IAMでポリシーを作成または更新する必要があります。この方法の例については、セッションタグに関するAWSのドキュメントを参照してください。
Oktaを使用したAWSセッションタグまとめ
ここでは、AWSの新機能であるセッションタグについて、Oktaでの使用例を交えて紹介しました。この組み合わせにより、クラウドのリソースを効率的に制御できます。まだAWSでOktaを試したことがない場合は、今すぐOktaアカウントを登録して無償でお試しください。
詳細なドキュメントは、Oktaヘルプセンターの動的SAML属性の記事をご覧ください。AWSセッションタグの詳細については、AWSのドキュメントをご覧ください。
Follow Joël Franusic
