証明書ベースの認証 - Amazon WorkSpaces
前提条件証明書ベースの認証を有効にする証明書ベースの認証の管理クロスアカウント PCA 共有を有効にする

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

証明書ベースの認証

で証明書ベースの認証を使用して WorkSpaces 、Active Directory ドメインパスワードのユーザープロンプトを削除できます。Active Directory ドメインで証明書ベースの認証を使用すると、以下のことを行うことができます。

  • SAML 2.0 ID プロバイダーに依頼してユーザーを認証し、Active Directory 内のユーザーと一致する SAML アサーションを提供する。

  • ユーザープロンプトの回数を減らして、シングルサインオンでログオンできるようにする。

  • SAML 2.0 ID プロバイダーを使用して、パスワードなしの認証フローを有効にする。

証明書ベースの認証では、 AWS アカウントの AWS Private CA リソースを使用します。 は、ルート CA と下位 CAs を含むプライベート認証機関 (CA) 階層の作成 AWS Private CA を有効にします。を使用すると AWS Private CA、独自の CA 階層を作成し、内部ユーザーを認証するための証明書を発行できます。詳細については、『AWS Private Certificate Authority ユーザーガイド』を参照してください。

証明書ベースの認証 AWS Private CA に を使用する場合、 WorkSpaces はセッション認証中にユーザーの証明書を自動的にリクエストします。ユーザーは、証明書によりプロビジョニングされた仮想スマートカードを使用して Active Directory に対して認証されます。

証明書ベースの認証は、最新の WorkSpaces Web Access、Windows、macOS クライアントアプリケーションを使用する Windows WorkSpaces on WorkSpaces Streaming Protocol (WSP) バンドルでサポートされています。Amazon WorkSpaces Client のダウンロードを開いて最新バージョンを検索します。

  • Windows クライアントバージョン 5.5.0 以降

  • macOS クライアントバージョン 5.6.0 以降

Amazon での証明書ベースの認証の設定の詳細については WorkSpaces、「Amazon の証明書ベースの認証を設定する方法 WorkSpaces」および AppStream 「2.0 および WorkSpaces での証明書ベースの認証の規制の厳しい環境での証明書ベースの認証に関する考慮事項の設計」を参照してください。

前提条件

証明書ベースの認証を有効にする前に、次の手順を実行してください。

  1. 証明書ベースの認証を使用するように SAML 2.0 統合で WorkSpaces ディレクトリを設定します。詳細については、WorkSpaces「SAML 2.0 との統合」を参照してください。

  2. SAML アサーションの userPrincipalName 属性を設定します。詳細については、「SAML 認証レスポンスのアサーションを作成する」を参照してください。

  3. SAML アサーションの ObjectSid 属性を設定します。これは、Active Directory ユーザーへの強力なマッピングを行うためのオプションです。この属性が SAML_Subject NameID で指定したユーザーの Active Directory セキュリティ識別子 (SID) と一致しない場合、証明書ベースの認証は失敗します。詳細については、「SAML 認証レスポンスのアサーションを作成する」を参照してください。

  4. SAML 2.0 設定で使用される IAM ロール信頼ポリシーに sts:TagSession アクセス許可がまだ存在しない場合は、追加します。このアクセス許可は、証明書ベースの認証を使用するために必要です。詳細については、「SAML 2.0 フェデレーション IAM ロールを作成する」を参照してください。

  5. Active Directory で設定 AWS Private CA されていない場合は、 を使用してプライベート認証機関 (CA) を作成します。 AWS Private CA は証明書ベースの認証を使用する必要があります。詳細については、AWS Private CA 「デプロイの計画」を参照し、ガイダンスに従って証明書ベースの認証用に CA を設定します。証明書ベースの認証のユースケースでは、次の AWS Private CA 設定が最も一般的です。

    1. CA タイプオプション:

      1. 使用期間が短い証明書 CA 使用モード (証明書ベースの認証用のエンドユーザー証明書を発行するためだけに CA を使用する場合に推奨)

      2. ルート CA を含む単一レベルの階層 (既存の CA 階層と統合する場合は下位 CA を選択することも可能)

    2. 主要なアルゴリズムオプション: RSA 2048

    3. サブジェクト識別名オプション: 複数のオプションを自由に組み合わせて、Active Directory の信頼されたルート認証局ストア内の CA を識別します。

    4. 証明書失効オプション: CRL ディストリビューション

      注記

      証明書ベースの認証には、デスクトップとドメインコントローラーからアクセスできるオンライン CRL ディストリビューションポイントが必要です。これには、プライベート CA CRL エントリ用に設定された Amazon S3 バケットへの認証されていないアクセス、または CloudFrontパブリックアクセスをブロックしている場合は S3 バケットにアクセスできるディストリビューションが必要です。これらのオプションの詳細については、「証明書失効リスト (CRL) を計画する」を参照してください。

  6. プライベート CA に euc-private-ca という名前でキーをタグ付けし、EUC 証明書ベースの認証で使用する CA を指定します。このキーには値が必要ありません。詳細については、「プライベート CA のタグの管理」を参照してください。

  7. 証明書ベースの認証では、ログオンに仮想スマートカードを使用します。Active Directory で「サードパーティの証明機関でスマートカードログオンを有効にするためのガイドライン」に従って、次の手順を実行します。

    • ドメインコントローラー証明書を使用して、スマートカードユーザーを認証するようにドメインコントローラーを設定します。Active Directory 証明書サービスのエンタープライズ CA が Active Directory に設定されている場合、ドメインコントローラーに証明書が自動的に登録され、スマートカードによるログオンが可能になります。Active Directory 証明書サービスがない場合は、「サードパーティ CA からのドメインコントローラー証明書の要件」を参照してください。ドメインコントローラー証明書は AWS Private CAで作成できます。その場合は、使用期間の短い証明書用に設定されたプライベート CA を使用しないでください。

      注記

      を使用している場合は AWS Managed Microsoft AD、ドメインコントローラー証明書の要件を満たすように EC2 インスタンスで Certificate Services を設定できます。Active Directory Certificate Services で設定された の AWS Managed Microsoft AD デプロイ例AWS Launch Wizardについては、「」を参照してください。 AWS プライベート CA は Active Directory Certificate Services CA の下位として設定することも、 を使用するときに独自のルートとして設定することもできます AWS Managed Microsoft AD。

      AWS Managed Microsoft AD および Active Directory Certificate Services の追加設定タスクは、コントローラー VPC セキュリティグループから Certificate Services を実行している EC2 インスタンスへのアウトバウンドルールを作成して、TCP ポート 135 および 49152-65535 で証明書の自動登録を有効にすることです。さらに、実行中の EC2 インスタンスは、ドメインインスタンス (ドメインコントローラーを含む) からのインバウンドアクセスを同じポートで許可する必要があります。のセキュリティグループの検索の詳細については、「VPC サブネットとセキュリティグループを設定する AWS Managed Microsoft AD 」を参照してください。

    • AWS Private CA コンソールまたは SDK または CLI を使用して CA を選択し、CA 証明書で CA プライベート証明書をエクスポートします。詳細については「プライベート証明書のエクスポート」を参照してください。

    • CA をアクティブディレクトリに公開します。ドメインコントローラーまたはドメインに参加しているマシンにログオンします。CA プライベート証明書を任意の <path>\<file> にコピーし、ドメイン管理者として次のコマンドを実行します。または、グループポリシーと Microsoft PKI Health Tool (PKIView) ツールを使用して CA を公開することもできます。詳細については、「設定手順」を参照してください。

      certutil -dspublish -f <path>\<file> RootCA
certutil -dspublish -f  <path>\<file> NTAuthCA

      コマンドが正常に完了したことを確認したら、プライベート証明書ファイルを削除します。Active Directory のレプリケーション設定によっては、CA がドメインコントローラーとデスクトップインスタンスに公開されるまでに数分かかる場合があります。

      注記

証明書ベースの認証を有効にする

証明書ベースの認証を有効にするには、次の手順を実行します。

  1. で WorkSpaces コンソールを開きますhttps://console.aws.amazon.com/workspaces。

  2. ナビゲーションペインで [ディレクトリ] を選択します。

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

  4. [Authentication] (認証) で [Edit] (編集) をクリックします。

  5. [Edit Certificate-Based Authentication] (証明書ベースの認証を編集) をクリックします。

  6. [Enable Certificate-Based Authentication] (証明書ベースの認証を有効にする) チェックボックスをオンにします。

  7. プライベート CA ARN がリストに関連付けられていることを確認します。プライベート CA は、同じ AWS アカウントと に存在し AWS リージョン、リストに表示する euc-private-ca という権限を持つキーでタグ付けされている必要があります。

  8. [Save Changes] (変更の保存) をクリックします。これで証明書ベースの認証が有効になりました。

  9. Windows WorkSpaces on WorkSpaces Streaming Protocol (WSP) バンドルを再起動して、変更を有効にします。詳細については、「 の再起動 WorkSpace」を参照してください。

  10. 再起動後、ユーザーがサポートされているクライアントを使用して SAML 2.0 経由で認証すると、ドメインパスワードの入力を求めるプロンプトが表示されなくなります。

注記

証明書ベースの認証が にサインインするように有効になっている場合 WorkSpaces、ディレクトリで有効になっていても、ユーザーは多要素認証 (MFA) を求められません。証明書ベースの認証を使用するときに、SAML 2.0 ID プロバイダーを通じて MFA を有効にすることができます。 AWS Directory Service MFA の詳細については、「多要素認証 (AD Connector)」または「 の多要素認証を有効にする AWS Managed Microsoft AD」を参照してください。

証明書ベースの認証の管理

CA 証明書

一般的な設定の場合、プライベート CA 証明書の有効期間は 10 年です。証明書の有効期限が切れた CA を置き換えたり、新しい有効期間で CA を再発行したりする方法の詳細については、「プライベート CA ライフサイクルの管理」を参照してください。

エンドユーザー証明書

証明書ベースの認証 AWS Private CA のために によって発行されたエンドユーザー WorkSpaces 証明書は、更新や取り消しを必要としません。これらの証明書は有効期間が短くなります。 WorkSpaces は 24 時間ごとに新しい証明書を自動的に発行します。これらのエンドユーザー証明書の有効期間は、一般的な AWS Private CA CRL ディストリビューションよりも短くなります。そのため、エンドユーザー証明書を取り消さなくても、CRL に表示されなくなります。

監査レポート

プライベート CA が発行または取り消したすべての証明書を一覧表示する監査報告書を作成できます。詳細については、「プライベート CA での監査レポートの使用」を参照してください。

ログ記録とモニタリング

を使用してAWS CloudTrail、 AWS Private CA による への API コールを記録できます WorkSpaces。詳細については、「 の使用 CloudTrail」を参照してください。CloudTrail イベント履歴では、EcmAssumeRoleSessionユーザー名によって WorkSpaces作成されたIssueCertificateイベントソースから GetCertificateおよび acm-pca.amazonaws.com イベント名を表示できます。これらのイベントは、EUC 証明書ベースの認証リクエストごとに記録されます。

クロスアカウント PCA 共有を有効にする

プライベート CA クロスアカウント共有を使用すると、集中型 CA を使用するアクセス許可を他のアカウントに付与できるため、すべてのアカウントでプライベート CA が不要になります。CA は、AWS Resource Access Manager を使用してアクセス許可を管理することで、証明書を生成して発行できます。プライベート CA クロスアカウント共有は、同じ AWS リージョン内の WorkSpaces 証明書ベースの認証 (CBA) で使用できます。

WorkSpaces CBA で共有 Private CA リソースを使用するには

  1. 一元化された AWS アカウントで CBA のプライベート CA を設定します。詳細については、「証明書ベースの認証」を参照してください。

  2. 「RAM を使用して ACM プライベート CA クロス AWS アカウント を共有する方法」の手順に従って、 WorkSpaces リソースが CBA を利用するリソースアカウントとプライベート CA を共有します。 AWS証明書を作成するには、ステップ 3 を完了する必要はありません。Private CA を個々の AWS アカウントと共有することも、 AWS Organizations を通じて共有することもできます。個々のアカウントと共有するには、Resource Access Manager (RAM) コンソールまたは APIs を使用して、リソースアカウントで共有プライベート CA を受け入れる必要があります。共有を設定するときは、リソースアカウントの Private CA の RAM リソース共有が AWS RAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthorityマネージドアクセス許可テンプレートを使用していることを確認します。このテンプレートは、CBA 証明書の発行時に WorkSpaces サービスロールが使用する PCA テンプレートと一致します。

  3. 共有が成功すると、リソースアカウントの Private CA コンソールを使用して、共有 Private CA を表示できるようになります。

  4. API または CLI を使用して、プライベート CA ARN を WorkSpaces ディレクトリプロパティの CBA に関連付けます。現時点では、 WorkSpaces コンソールは共有プライベート CA ARNs の選択をサポートしていません。CLI コマンドの例：

    aws workspaces modify-certificate-based-auth-properties —resource-id <value> —certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>