COLUMN

2025.05.07 ｜ Writer：杉山

Amazon WorkspacesとOktaを連携し多要素認証を利用してみた

SAML 2.0連携設定ガイド

こんにちは、クラウドエンジニアの杉山です。本コラムではAmazon WorkspacesをOktaと連携し、多要素認証によるデスクトップへのログインを実装する方法についてご紹介します。

また、本コラムではAmazon Workspacesの利用形態の一つであるWorkspaces Poolsを取り上げますが、従来のAmazon Workspacesと異なり、Active Directoryが不要（オプション）であるため、素早く環境をセットアップできるメリットがあります。

本コラムで解説すること

Workspaces Poolsの特徴やユースケース
Oktaを連携するメリット
Workspaces PoolsとOktaの具体的な連携設定手順
設定における注意点やポイント

本コラムで解説しないこと

AWSの基本的な操作、設定
本コラムではWorkspaces Poolsを展開するVPCがすでにあることを前提に解説をします
Oktaの基本的な操作、設定
本コラムではWorkspaces Poolsへ接続するユーザー、グループがすでにあることを前提に解説をします
Workspaces PersonalとOkta、Active Directory連携に関する設定
前述のとおり、本コラムではActive Directoryを必要としない、Workspaces PoolsとOktaの連携設定について、解説をします

クラウドVDIの導入に関するご相談はこちら！

Amazon Workspaces Poolsとは？: 主な特徴; 主なユースケース; Okta連携の利点; Amazon Workspaces Poolsの料金体系
Workspaces PoolsとOktaの連携設定: 作業概要; Workspaces Pool Directoryの作成; Workspaces Poolsの作成; Okta SAML 2.0アプリ統合の作成; Workspaces Pools SAML設定; IAM IDプロバイダーの作成; IAMロールの作成; SAML Assertionの設定
接続確認
まとめ: Oktaとの連携により得られるメリット; 設定の注意点

Workspaces Poolsとは？

Workspaces Poolsとは、AWSが提供する仮想デスクトップインターフェース（VDI）サービスであるAmazon Workspacesの提供形態の呼称です。

従来のAmazon Workspaces（現在ではWorkspaces Poolsと区別されWorkspaces Personalと呼称されます）がユーザー個々に永続的な仮想デスクトップを割り当てるのに対し、Workspaces Poolsは複数のユーザーで仮想デスクトップの「プール」を共有し、オンデマンドで利用する形態をとります。

主な特徴

コスト効率の高い料金体系：
- ユーザーが実際にデスクトップセッションを利用した時間に基づいて課金される従量課金制です。
- Workspaces Personalと比較して課金単価が低いため、従来の仮想デスクトップ環境にかかるコストを大幅に削減できる可能性があります。
非永続的なデスクトップセッション：
- ユーザーがセッションを終了すると、利用していたデスクトップインスタンスは基本的に初期状態に戻ります。ユーザー固有のデータや設定は通常残りません。
- ただし、Amazon FSx for Windows File Serverなどの外部ストレージと連携することで、ユーザードキュメントやプロファイルを永続化することも可能です。
オンデマンドなリソース提供：
- ユーザーはログイン時に、利用可能なデスクトップインスタンスのプールから空いているものが割り当てられます。特定のインスタンスに固定されません。
- 管理者は、想定される同時利用ユーザー数に基づいてプールのキャパシティ（インスタンス数）を定義・調整できます。
効率的な管理：
- 個々のデスクトップではなく、プール全体（フリート）を一元的に管理します。
- OSイメージ（AMI）を更新し、それをプール全体に適用することで、パッチ適用やソフトウェア更新を効率的に行えます。
スケーラビリティ：
- 需要（同時接続ユーザー数）の増減に応じて、プール内のインスタンス数を自動または手動でスケールさせることが可能です。

主なユースケース

Workspaces Poolsは、以下のような場合に特に有効です。

利用頻度が変動するユーザー：パートタイム従業員、アルバイト、派遣社員、季節労働者など。
一時的なアクセスニーズ：短期プロジェクトメンバー、研修・トレーニング参加者、教育機関の学生、ソフトウェアのデモンストレーション環境など。
共有端末的な利用：コールセンターやコンタクトセンターのエージェント、特定の業務でのみ仮想デスクトップを利用する従業員。
開発・テスト環境：アプリケーションのテストや開発のために一時的にデスクトップ環境が必要な場合。

Okta連携の利点

Workspaces PoolsをOktaと連携させることには、主に情報セキュリティ強化、ID管理の効率化、そしてユーザー利便性の向上という点で大きな利点があります。

具体的には以下の点が挙げられます。

情報セキュリティレベルの大幅な向上：
- 多要素認証 (MFA) の適用：Oktaが提供する多様な認証要素（Okta Verifyプッシュ通知、SMS、電話、セキュリティキー、生体認証など）を利用して、Workspaces PoolsへのログインにMFAを必須化できます。これにより、パスワード漏洩時の不正アクセスリスクを大幅に低減できます。
- 高度なアクセスポリシー制御：Oktaの「認証ポリシー」を利用し、ユーザーの状況（アクセス元のIPアドレス、国、デバイスの状態、時間帯、所属グループなど）に基づいてアクセス許可/拒否や追加認証要求を動的に行うことができます。例えば、「信頼できないネットワークからのアクセス時はMFAを必須にする」「特定の役職者のみアクセスを許可する」といった柔軟できめ細やかな制御が可能です。
- リスクベース認証：Oktaが検知した不審なログイン試行（通常と異なる場所からのアクセスなど）に対して、アクセスをブロックしたり、追加認証を要求したりすることで、情報セキュリティリスクをプロアクティブに低減できます。
ID管理の一元化と運用負荷の軽減：
- シングルサインオン (SSO) の実現：ユーザーは使い慣れたOktaの認証情報（ID/パスワード、MFA）でWorkspaces Poolsにログインできるようになります。他のOkta連携アプリケーションと同様のログイン体験を提供でき、複数のパスワードを管理する手間が省けます。
- IDライフサイクル管理の効率化：すでにOktaを社内のID管理基盤（IdP）として利用している場合、人事システム等との連携による入社・異動・退職に伴うアカウント管理プロセスにWorkspaces Poolsのアクセス権管理も組み込むことができます。これにより、アカウントの払い出しや削除漏れを防ぎ、管理者の運用負荷を大幅に軽減できます。
- 既存のID基盤の活用：Oktaに登録済みのユーザー情報やグループ情報をそのままWorkspaces Poolsの認証・認可に利用できるため、新たにディレクトリサービスを構築・管理する必要がなく、導入コストや管理の手間を削減できます。特に、流動的なユーザーが多いPools環境において、効率的なID管理は重要です。
監査証跡とコンプライアンスの強化：
- 詳細な認証ログ：Oktaは「いつ、誰が、どこから、どのデバイスでWorkspaces Pools（を含む連携アプリ）にアクセスしようとし、認証に成功/失敗したか」といった詳細な監査ログを提供します。これにより、不正アクセスの追跡やコンプライアンス要件への対応が容易になります。

これらの利点により、Workspaces Poolsの導入効果（コスト効率、柔軟性）を最大限に引き出しつつ、エンタープライズレベルの情報セキュリティとガバナンスを確保することが可能になります。

クラウドVDIの導入に関するご相談はこちら！

Workspaces Poolsの料金体系

Workspaces Poolsの料金体系は、主に以下の2つの要素に基づいて計算されます。

1. 時間料金：
- これはWorkspaces Poolsに設定する仮想デスクトップに対して発生する時間単価の料金です。
- 時間単価は利用するバンドルごとに異なります。
- ユーザーが接続していない非アクティブなデスクトップに対しては、バンドルによらず一律の時間単価（Stopped Instance Fee）が適用されます。
2. Remote Desktop Services SAL料金（月額固定）：
- これはデスクトップに接続するユニークユーザごとに発生する月額の料金です。
- 日割りなどはなく、その月に仮想デスクトップへ接続したユーザーごとに1ヶ月分の料金が発生します。

その他の料金要素：

(オプション) ストレージ料金：ユーザープロファイルやデータを永続化するためにAmazon FSx for Windows File Serverなどのストレージサービスを利用する場合、そのサービスの利用料金が別途発生します。
(オプション) BYOL (Bring Your Own License)：既存のMicrosoftライセンスを持ち込む（BYOL）場合、料金体系が異なります。

料金体系および料金に関する詳細な情報はこちらのAWS公式の料金ページをご覧ください。

クラウドVDIの導入に関するご相談はこちら！

Workspaces PoolsとOktaの連携設定

それでは、実際に設定を見ていきます。

作業概要

以下の順でWorkspaces PoolsとOktaの連携設定を進めます。

なお、本項目で説明する作業にかかる所要時間は概ね1時間程度です。

1. Workspaces Poolsのセットアップ
Pool Directory、Workspaces Poolsの順に作成します
2. Oktaアプリ統合のセットアップ
Okta SAML 2.0 アプリ統合を作成し、作成されたアプリの情報からPool DirectoryのSAMLサインインの設定を行います
3. AWS IAM IDプロバイダーのセットアップ
- IAMにOktaをSAML 2.0 IdPとするIDプロバイダーを作成します
- IAMにIDプロバイダーへ付与するロールを作成します
4. Oktaアプリ統合にSAML assertionを設定します。

Pool Directoryの作成

Workspaces Poolsに紐づけて使用するPool Directoryを作成します。

Pool DirectoryにはOktaと連携するためのSAML 2.0に関する情報が含まれます。

1. AWS管理コンソールを開きます。

2. Workspacesページを開きます。

3. ディレクトリを選択します。

4. ディレクトリの作成をクリックします。

5. 以下のように各項目の値を入力し、ディレクトリの作成をクリックします。

※以下に記載のない項目はすべてデフォルト値

a. Workspace タイプ：プール

b. ユーザーIDソース：

i. ユーザーアクセス URL：https://placeholder

c. ディレクトリ情報

i. ディレクトリ名：Directory-1

d. ネットワークとセキュリティ

i. インターネットへのアクセス：NAT Gatewayを使ってインターネットへのアクセスを行う場合には、チェックを外す

ii. VPC：任意のVPCを選択

iii. サブネット 1：任意のサブネットを選択

iv. サブネット 2：任意のサブネットを選択

v. セキュリティグループ：任意のサブネットを選択

6. 作成されたディレクトリIDを選択し、詳細を表示をクリックします。

7. 本作業を行ったブラウザのタブは閉じずに、新規タブを開いて次の作業を進めます。

Workspaces Poolsの作成

ユーザーが利用するバンドルの種類などを指定して、Workspaces Poolsを作成します。

1. AWS管理コンソールを開きます。

2. Workspacesページを開きます。

3. Workspaces > プールを選択します。

4. Workspaceの作成をクリックします。

5. 自分のユースケースに必要なワークスペースオプションを把握している。を選択し、次へをクリックします。

6. 以下のように各項目の値を入力し、次へをクリックします。

※以下に記載のない項目はすべてデフォルト値

a. 基本情報

i. Workspace タイプ：プール

ii. 名前：Pool-1

iii. 説明：任意の値

b. バンドル：Performance with Windows 10(Server 2022 based)

※他の任バンドルを選択しても、以降の手順に影響はありません

7. Pool Directoryの作成で作成したディレクトリを選択し、WorkSpaces プールの作成をクリックします。

8. 作成したプールを選択し、起動をクリックします。

9. コピーをクリックし、登録コードの値を控えておきます。

10. 本作業を行ったブラウザのタブは閉じ、新規タブで次の作業を進めます。

Okta SAML 2.0アプリ統合の作成

OktaにWorkspaces Poolsと連携するためのアプリ統合を作成します。

1. Okta管理コンソールを開きます。

2. アプリケーション > アプリケーションを開きます。

3. アプリ統合を作成をクリックします。

4. SAML 2.0を選択し、次へをクリックします。

5. アプリ名に任意の名前を入力し、次へをクリックします。

6. 以下のように各項目の値を入力し、次へをクリックします。

※以下に記載のない項目はすべてデフォルト値

a. 一般

i. シングルサインオンURL：https://signin.aws.amazon.com/saml

ii. オーディエンスURI：urn:amazon:webservices

iii. デフォルトのRelayState：https://workspaces.euc-sso.<REGION>.aws.amazon.com/sso-idp?registrationCode=<REGCODE>

※<REGION>はWorkspacesを展開するAWS Regionのコードで置き換えてください（東京リージョンは「ap-northeast-1」など）

※<REGCODE>はWorkspaces Poolsの作成で控えた登録コードの値で置き換えてください

iv. 名前IDのフォーマット：Persistent

b. 属性ステートメント（オプション）

i. 名前：https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email

1. 名前のフォーマット：指定なし

2. 値：user.email

ii. 名前：https://aws.amazon.com/SAML/Attributes/RoleSessionName

1. 名前のフォーマット：URI参照

2. 値：userName

iii. 名前：https://aws.amazon.com/SAML/Attributes/SessionDuration

1. 名前のフォーマット：基本

2. 値：3600

7. これは当社で作成した社内アプリですを選択し、終了をクリックします。

8. 認証タブを選択します。

9. サインオン設定 > サインオン方法 > SAML 2.0セクションの詳細をクリックします。

10. サインオンURLのコピーをクリックし、コピーしたURLを控えておきます。

11. 本作業を行ったブラウザのタブは閉じずに、次の作業へ進みます。

Workspaces Pools SAML設定

Oktaで作成したアプリ統合からSAML 2.0に関する連携情報をPool Directoryに設定します。

1. Pool Directoryの作成で使用したタブを開きます。

2. 認証セクションの編集をクリックします。

3. SAML 2.0 アイデンティティプロバイダーの編集をクリックします。

4. ユーザーアクセスURLへOkta SAML 2.0 アプリ統合の作成で控えたURLの値を貼り付け、保存をクリックします。

5. 本作業を行ったブラウザのタブは閉じずに、次の作業へ進みます。

IAM IDプロバイダの作成

AWSのIAMに連携先となるOktaをIDプロバイダとして設定します。

1. Okta SAML 2.0 アプリ統合の作成で使用したタブを開きます。

2. 認証タブを選択します。

3. サインオン設定 > サインオン方法 > SAML 2.0セクション内 メタデータURLのコピーをクリックします。

4. ブラウザの新規タブでコピーしたURL（ページ）を開きます。

5. ブラウザのページの保存機能を使って、開いたページをxmlファイルとして保存します。

※macOSのChromeブラウザの場合

6. ページが保存できたら、XMLを表示しているページのタブは閉じます。

7. ブラウザの新規タブでAWS管理コンソールを開きます。

8. Identity and Access Management (IAM)ページを開きます。

9. ID プロバイダを選択します。

10. プロバイダを追加をクリックします。

11. プロバイダのタイプにSAMLが選択されていることを確認します。

12. プロバイダ名に任意の名前を入力します。

13. メタデータドキュメントのファイルを選択をクリックします。

14. 前項の作業でダウンロードしたxmlファイルを指定します。

15. プロバイダを追加をクリックします。

16. 画面上部に表示される緑色のバナーのプロバイダを表示をクリックします。

17. ARNをクリップボードにコピーをクリックし、作成したIDプロバイダのARNを控えておきます。

IAMロールの作成

AWS IAMに作成したIDプロバイダに紐づけるロールを作成します。

1. AWS管理コンソールを開きます。

2. Identity and Access Management (IAM)ページを開きます。

3. ロールを選択します。

4. ロールを作成をクリックします。

5. 信頼されたエンティティタイプからSAML 2.0 フェデレーションを選択します。

6. SAML 2.0 ベースのプロバイダからIAM IDプロバイダの作成で作成したIDプロバイダを選択します。

7. 条件を追加をクリック後、以下のとおり値を指定し、次へをクリックします。

a. キー：SAML:sub_type

b. 条件：StringEquals

c. 値：persistent

8. 次へをクリックします。

9. ロール名、説明に任意の値を入力し、ロールを作成をクリックします。

10. 画面上部に表示される緑色のバナーのロールを表示をクリックします。

11. 許可タブを選択し、許可を追加 > インラインポリシーを作成をクリックします。

12. JSONを選択し、ポリシーエディタの内容を以下の内容で置き換えます。

※<ACCOUNTID>の値は実際のAWSアカウントIDの値に置き換えてください

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:*:<ACCOUNTID>:*",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

13. 次へをクリックします。

14. ポリシー名に任意の値を入力し、ポリシーの作成をクリックします。

15. 信頼関係タブを選択し、信頼ポリシーを編集をクリックします。

16. Actionセクションに「sts:TagSession」を追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNTID:saml-provider/IDPNAME"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:sub_type": "persistent"
                }
            }
        }
    ]
}