認証
WorkSpaces Applications では、認証を Amazon WorkSpaces Applications サービス外として行うことも、WorkSpaces Applications サービスの一環として行うこともできます。WorkSpaces Applications デプロイの認証方法の選択は、設計の基本的な考慮事項です。組織がさまざまなユースケースに合わせて WorkSpaces Applications を複数デプロイすることは珍しいことではありません。ユースケースごとに認証方法が異なる場合があります。
WorkSpaces Applications には次の 3 つのタイプの認証方法があります。
最適化された方法の決定
Amazon WorkSpaces Applications は、ほとんどの組織の設計要件に柔軟に対応できるように設計されています。最適な認証方法を決定する際には、サービスを利用する人々の目標と目的、および組織のポリシーと手順を考慮することがベストプラクティスです。
ユースケースと組織の目標を組み合わせた例をいくつか紹介します。
表 4 — 組織的な目標のあるユースケース
| 例 | 説明 | Authentication |
|---|---|---|
| ドメインに参加したフリートインスタンスが必要 | WorkSpaces Applications イメージにインストールされたアプリケーションには、ドメインに参加しているリソースにのみがアクセスできます。 | SAML 2.0 |
| Microsoft サービスとの緊密な統合 | Microsoft のグループポリシーとバックエンドインフラストラクチャの開発に対して組織が依存している | SAML 2.0 |
| 既存のエンタープライズシングルサインオン (SSO) | 新しいサービスはすべて、複数の報告プロセスとセキュリティプロセスが確立されたエンタープライズ SSO ソリューションを活用する必要がある。 | SAML 2.0 |
| スマートカードによるアプリケーションのサポート | スマートカードリーダーを介してストリーミングされるアプリケーションのセッション内認証されるスマートカード (プライベート ID 検証や共通アクセスカードなど)。 | SAML 2.0 |
| 臨時スタッフによる一時的な人材 | 派遣社員には、1 年のうち数か月間、業務を遂行するための社内リソースを含まない少数のアプリケーションが割り当てられる。 | ユーザープール |
| サポートの制限 | ユーザー数が 50 人未満で、IT スタッフが限られている小規模な組織で、ID プロバイダー (IdP) の維持にかかる諸経費の削減を検討している | ユーザープール |
| 独立系ソフトウェアベンダー (ISV) | ユーザーの使用権限と認証を含む、組織が構築した独自のソリューションであり、ソリューションの一部として WorkSpaces Applications を拡張する。* | プログラミング |
| テクノロジーの紹介 | ユーザー情報を保存する必要がなく、ソリューションのガイド付きツアーの一環として独自のテクノロジーを紹介する、完全に一時的な環境。 | プログラミング |
| インタラクティブな Web サイトエクスペリエンス |
ストリーミング中の Windows アプリケーションで Web サイトをインタラクティブにする。** |
プログラミング |
*詳細については、「ソフトウェアベンダー: アプリケーションを任意のデバイスで使用する
**詳細については、「WorkSpaces Applications ストリーミングセッションの埋め込み」を参照してください。
組織に前述の例に記載されていないユースケースやポリシーがある場合は、WorkSpaces Applications ワークフローの使用の望ましい最終状態を予測して、認証ソリューションがそれと競合しないようにすることがベストプラクティスです。
ID プロバイダーの設定
SAML 2.0
Security Assertion Markup Language (SAML) 2.0 は、ユーザーがAWS リソースを使用できるようにするための一般的な導入オプションです
ほとんどの IdP は SAML アプリケーションごとに特定の SAML 属性を持つ固有の metadata.xml を生成するため、すべての WorkSpaces Applications スタックには SAML IdP と信頼できる関係を持つロールと、SAML IdP と WorkSpaces Applications スタックの ARN の要件に一致する条件で appstream:Stream に対する単一のアクセス許可を持つポリシーが必要です。
WorkSpaces Applications 管理ガイドには、単一の WorkSpaces Applications スタック設計の例が記載されています。マルチスタックデプロイの場合は、SAML 2.0 マルチスタックアプリケーションカタログを使用するためのオプション手順を参照してください。
ユーザープール
WorkSpaces Applications の [ユーザープール] タブは、小規模な概念実証に有効なオプションです。ベストプラクティスとして、WorkSpaces Applications を使用して本番アプリケーションを配信するユースケースや組織では、ユーザープールを避けることが最善です。
ユーザープールについて注意すべき重要な点の 1 つは、ユーザーの E メールアドレスでは大文字と小文字が区別されるということです。そのため、ユーザー認証情報の正しい入力方法をユーザーに確実に伝えることがベストプラクティスです。
ストリーミング URL
集中型サービス (通常は ISV) から WorkSpaces Applications リソースを呼び出すデプロイの場合、プログラムによる認証では、アプリケーションが AWS に対してプログラムによる呼び出しを行って情報を動的に渡し、そのユーザー用の WorkSpaces Applications セッションを作成します。CreateStreamingURL オペレーションを使用してストリーミング URL を作成する場合は、API 認証方法 (一般に「プログラミング」と呼ばれます) を使用してください。CreateStreamingURL 呼び出しを行うユーザーは、appstream:CreateStreamingURL のアクセス許可を持つ有効なユーザーまたはロールを使用している必要があります。
プログラムによるアクセスのポリシーを作成するときは、デフォルトの「*」の代わりに [リソース] セクションで正確な WorkSpaces Applications Stack ARN を指定してアクセスを保護するのがベストプラクティスです。例えば、次のようになります。
例
WorkSpaces Applications インスタンスは汎用インスタンスとして開始する必要があります。アプリケーションから渡される情報を通じて、WorkSpaces Applications インスタンスはセッションコンテキストを使用して環境を確立し、ユーザーにとって物事を動的にします。
ローカル GPO を使用してユーザーログオン時に設定を指定できますが、CreateStreamingURL を使用し、WorkSpaces Applications セッションで使用されるカスタマー ID やデータベース接続設定などの重要な属性を使用して渡す場合は、セッションコンテキストを使用するのがベストプラクティスです。
アプリケーションの使用権限
WorkSpaces Applications は、ユーザーに表示されるアプリケーションカタログを動的に構築できます。アプリケーションの使用権限は、SAML 2.0 の属性に基づくか、または WorkSpaces Applications 動的アプリケーションフレームワークを使用します。
ほとんどのシナリオでは、SAML 2.0 を使用する属性ベースのアプリケーションの使用権限が推奨されます。アプリケーションパッケージの配信を管理するには、動的アプリケーションフレームワークが推奨されます。
