翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 証明書ベースの認証
Microsoft Active Directory に参加している WorkSpaces アプリケーションフリートでは、証明書ベースの認証を使用できます。これにより、ユーザーがログインするときに Active Directory ドメインパスワードの入力を求めるユーザープロンプトが省略されます。Active Directory ドメインで証明書ベースの認証を使用すると、以下のことを行うことができます。
+ SAML 2.0 ID プロバイダーに依頼してユーザーを認証し、Active Directory 内のユーザーと一致する SAML アサーションを提供する。
+ ユーザープロンプトの回数を減らして、シングルサインオンでログオンできるようにする。
+ SAML 2.0 ID プロバイダーを使用して、パスワードなしの認証フローを有効にする。
証明書ベースの認証では、 AWS で Private Certificate Authority (AWS Private CA) リソースを使用します AWS アカウント。 AWS プライベート CA を使用すると、ルート CA と下位 CAs を含むプライベート認証機関 (CA) 階層を作成できます。独自の CA 階層を作成し、そこから内部ユーザーを認証する証明書を発行することもできます。詳細については、[「 とは AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)」を参照してください。
証明書ベースの認証に AWS プライベート CA を使用すると、WorkSpaces アプリケーションは各 WorkSpaces アプリケーションフリートインスタンスのセッション予約時にユーザーの証明書を自動的にリクエストします。証明書でプロビジョニングされた仮想スマートカードを使用して、ユーザーを Active Directory に対して認証します。
証明書ベースの認証 (CBA) は、Windows インスタンスを実行する WorkSpaces Applications ドメイン結合フリート (単一セッションフリートとマルチセッションフリートの両方) でサポートされています。マルチセッションフリートで CBA を有効にするには、02-07-2025 以降にリリースされた WorkSpaces Applications エージェントを使用する WorkSpaces Applications イメージを使用する必要があります。または、 以降にリリースされたマネージド WorkSpaces アプリケーションイメージ更新をイメージで使用する必要があります02-11-2025。
**Topics**
+ [前提条件](certificate-based-authentication-prereq.md)
+ [証明書ベースの認証](certificate-based-authentication-enable.md)
+ [証明書ベースの認証の管理](certificate-based-authentication-manage.md)
+ [クロスアカウント PCA 共有を有効にする](pca-sharing.md)
# 前提条件
証明書ベースの認証を使用する前に、以下のステップを完了します。
1. ドメイン結合フリートを設定し、SAML 2.0 を設定する。必ず SAML\$1Subject `NameID` 用の `username@domain.com` `userPrincipalName` 形式を使用してください。詳細については、「[ステップ 5: SAML 認証レスポンスのアサーションを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions)」を参照してください。
**注記**
証明書ベースの認証を使用する場合は、スタック内の **Active Directory のスマートカードサインイン**を有効にしないでください。詳細については、「[スマートカード](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards)」を参照してください。
1. イメージで WorkSpaces Applications エージェントバージョン 10-13-2022 以降を使用します。詳細については、「[Amazon WorkSpaces アプリケーションイメージUp-to-Date状態に保つ](keep-image-updated.md)」を参照してください。
1. SAML アサーションの `ObjectSid` 属性を設定します。この属性を使用して、Active Directory ユーザーとの強力なマッピングを実行できます。`ObjectSid` 属性が SAML\$1Subject `NameID` で指定されたユーザーの Active Directory セキュリティ識別子 (SID) と一致しない場合、証明書ベースの認証は失敗します。詳細については、「[ステップ 5: SAML 認証レスポンスのアサーションを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions)」を参照してください。`ObjectSid` は、2025 年 9 月 10 日以降の証明書ベースの認証に必須です。詳細については、「[KB5014754 – Windows ドメインコントローラーでの証明書ベースの認証の変更](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16)」を参照してください。
1. SAML 2.0 設定で使用する IAM ロールの信頼ポリシーに `sts:TagSession` アクセス権限を追加します。詳細については、「[AWS STSでのセッションタグの受け渡し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html)」を参照してください。この権限は、証明書ベースの認証を使用する場合に必要です。詳細については、「[ステップ 2: SAML 2.0 フェデレーション IAM ロールを作成する](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms)」を参照してください。
1. Active Directory で設定されていない場合は、 AWS プライベート CA を使用してプライベート認証機関 (CA) を作成します。証明書ベースの認証を使用するには、 AWS プライベート CA が必要です。詳細については、「[AWS Private CA デプロイの計画](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html)」を参照してください。証明書ベースの認証の多くのユースケースでは、次の AWS プライベート CA 設定が一般的です。
+ **CA タイプオプション**
+ **使用期間が短い証明書 CA 使用モード** – CA が証明書ベースの認証のためにエンドユーザー証明書のみを発行する場合に推奨されます。
+ **ルート CA を含む単一レベルの階層** – 下位 CA を選択して既存の CA 階層と統合します。
+ **主要なアルゴリズムオプション** – RSA 2048
+ **サブジェクト識別名オプション** – 最も適切なオプションを使用して、Active Directory の信頼されたルート証明機関ストアでこの CA を識別します。
+ **証明書失効オプション** – CRL のディストリビューション
**注記**
証明書ベースの認証には、WorkSpaces アプリケーションフリートインスタンスとドメインコントローラーの両方からアクセスできるオンライン CRL ディストリビューションポイントが必要です。これには、 AWS プライベート CA CRL エントリ用に設定された Amazon S3 バケットへの認証されていないアクセスが必要です。パブリックアクセスをブロックする場合は Amazon S3 バケットにアクセスできる CloudFront ディストリビューションが必要です。これらのオプションの詳細については、「[証明書失効リスト (CRL) の計画](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)」を参照してください。
1. プライベート CA `euc-private-ca` に、WorkSpaces アプリケーション証明書ベースの認証で使用する CA を指定する権限を持つキーをタグ付けします。このキーには値は必要ありません。詳細については、「[プライベート CA のタグ管理](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html)」を参照してください。のリソースにアクセス許可を付与するために WorkSpaces アプリケーションで使用される AWS マネージドポリシーの詳細については AWS アカウント、「」を参照してください[AWS WorkSpaces アプリケーションリソースにアクセスするために必要な管理ポリシー](managed-policies-required-to-access-appstream-resources.md)。
1. 証明書ベースの認証では、仮想スマートカードを使用してログオンします。詳細については、「[サードパーティーの証明機関でスマートカードオンを有効にするためのガイドライン](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities)」を参照してください。以下の手順に従ってください。
1. スマートカードユーザーを認証するには、ドメインコントローラー証明書を使用してドメインコントローラーを設定します。Active Directory 証明書サービスのエンタープライズ CA が Active Directory に設定されている場合、スマートカードによるログオンを可能にするドメインコントローラーが証明書に自動的に登録されます。Active Directory 証明書サービスがない場合は、[「サードパーティー CA からのドメインコントローラー証明書の要件](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller)」を参照してください。 AWS は、ドメインコントローラー証明書の登録を自動的に管理するために Active Directory エンタープライズ認証機関を推奨します。
**注記**
AWS Managed Microsoft AD を使用する場合は、ドメインコントローラー証明書の要件を満たす Amazon EC2 インスタンスで証明書サービスを設定できます。[Active Directory 証明書サービスで設定された Managed Microsoft AD のデプロイ例については、「新しい Amazon Virtual Private Cloud に](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) Active Directory をデプロイする」を参照してください。 AWS
AWS Managed Microsoft AD と Active Directory Certificate Services では、コントローラーの VPC セキュリティグループから Certificate Services を実行する Amazon EC2 インスタンスへのアウトバウンドルールも作成する必要があります。証明書の自動登録を有効にするには、セキュリティグループに TCP ポート 135 とポート 49152～65535 へのアクセスを提供する必要があります。Amazon EC2 インスタンスは、ドメインコントローラーを含むドメインインスタンスからの同じポートへのインバウンドアクセスも許可する必要があります。 AWS Managed Microsoft AD のセキュリティグループを見つける方法の詳細については、「VPC [サブネットとセキュリティグループを設定する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc)」を参照してください。
1. AWS プライベート CA コンソール、または SDK または CLI で、プライベート CA 証明書をエクスポートします。詳細については、「[プライベート証明書のエクスポート](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html)」を参照してください。
1. プライベート CA を Active Directory に公開します。ドメインコントローラーまたはドメイン結合マシンにログオンします。プライベート CA 証明書を任意の `\` にコピーし、ドメイン管理者として次のコマンドを実行します。また、グループポリシーと Microsoft PKI Health ツール (PKIView) を使用して CA を公開することもできます。詳細については、「[設定手順](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions)」を参照してください。
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
コマンドが正常に完了したことを確認してから、プライベート CA 証明書ファイルを削除します。Active Directory のレプリケーション設定によっては、CA がドメインコントローラーと WorkSpaces Applications フリートインスタンスに発行するまでに数分かかる場合があります。
**注記**
Active Directory は、ドメインに参加するときにWorkSpaces アプリケーションフリートインスタンスの信頼されたルート認証機関とエンタープライズ NTAuth ストアに CA を自動的に配布する必要があります。
Windows オペレーティングシステムの場合、CA (認証局) のディストリビューションは自動的に行われます。ただし、Rocky Linux および Red Hat Enterprise Linux の場合は、WorkSpaces Applications Directory Config が使用する CA からルート CA 証明書 (複数可) をダウンロードする必要があります。KDC ルート CA 証明書が異なる場合、それらもダウンロードする必要があります。証明書ベースの認証を使用する前に、これらの証明書をイメージまたはスナップショットにインポートする必要があります。
イメージには、/`etc/sssd/pki/sssd_auth_ca_db.pem` という名前のファイルが必要です。次のようになります。
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**注記**
リージョンやアカウント間でイメージをコピーする場合、またはイメージを新しい Active Directory に再関連付けする場合は、このファイルを Image Builder の関連する証明書で再設定し、使用前に再度スナップショットを作成する必要があります。
ルート CA 証明書をダウンロードする手順は次のとおりです。
1. Image Builder で、`/etc/sssd/pki/sssd_auth_ca_db.pem` という名前のファイルを作成します。
1. [AWS Private CA コンソール](https://console.aws.amazon.com/acm-pca/) を開きます。
1. WorkSpaces Applications Directory Config で使用されるプライベート証明書を選択します。
1. **[CA 証明書]** タブを選択します。
1. 証明書チェーンと証明書本文を Image Builder の `/etc/sssd/pki/sssd_auth_ca_db.pem` にコピーします。
KDCs で使用されるルート CA 証明書が WorkSpaces Applications Directory Config で使用されるルート CA 証明書と異なる場合は、以下の例の手順に従ってダウンロードします。
1. Image Builder と同じドメインに参加している Windows インスタンスに接続します。
1. `certlm.msc` を開きます。
1. 左側のペインで、**[信頼できるルート証明機関]** を選択し、**[証明書]** を選択します。
1. ルート CA 証明書ごとに、コンテキスト (右クリック) メニューを開きます。
1. **[すべてのタスク]** を選択し、**[エクスポート]** を選択して証明書エクスポートウィザードを開き、**[次へ]** を選択します。
1. **[Base64 でエンコードされた X.509 (.CER)]** を選択し、**[次へ]** を選択します。
1. **[参照]** を選択し、ファイル名を入力し、**[次へ]** を選択します。
1. [**Finish**] を選択してください。
1. エクスポートされた証明書をテキストエディタで開きます。
1. ファイルの内容を Image Builder の `/etc/sssd/pki/sssd_auth_ca_db.pem` にコピーします。
# 証明書ベースの認証
証明書ベースの認証を使用する前に、以下の手順を完了します。
**証明書ベースの認証**
1. [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2) で WorkSpaces アプリケーションコンソールを開きます。
1. ナビゲーションペインで、[**Directory Configs**] (ディレクトリの設定) を選択します。設定するディレクトリ設定を選択し、[**編集**] を選択します。
1. [**証明書ベースの認証を有効にする**] を選択します。
1. プライベート CA の ARN がリストで関連付けられていることを確認します。リストに表示するには、プライベート CA を同じ AWS アカウント と に保存する必要があります AWS リージョン。また、プライベート CA には `euc-private-ca` という名前のキーをタグ付けする必要があります。
1. フォールバックのディレクトリログを設定します。フォールバックを使用すると、証明書ベースの認証に失敗した場合でも、ユーザーは AD ドメインのパスワードでログインできます。これは、ユーザーがドメインパスワードを知っている場合にのみ推奨されます。フォールバックがオフになっていると、ロック画面や Windows のログオフが発生した場合に、セッションによってユーザーの接続が切断される可能性があります。フォールバックがオンになっている場合、セッションはユーザーに AD ドメインパスワードの入力を求めます。
1. **[Save changes]** (変更の保存) をクリックします。
1. 証明書ベースの認証が有効になりました。ユーザーが WorkSpaces Applications ウェブクライアントまたは Windows 用クライアント (バージョン 1.1.1099 以降) のドメイン結合フリートを使用して WorkSpaces アプリケーションスタックに対して SAML 2.0 で認証すると、ドメインパスワードの入力を求めるプロンプトが表示されなくなります。証明書ベースの認証を有効にしたセッションに接続するときに、「証明書ベースの認証で接続中...」というメッセージがユーザーに表示されます。
# 証明書ベースの認証の管理
証明書ベースの認証を有効にしたら、次のタスクを確認します。
**Topics**
+ [プライベート CA 証明書](certificate-based-authentication-manage-CA.md)
+ [エンドユーザー証明書](certificate-based-authentication-manage-certs.md)
+ [監査レポート](certificate-based-authentication-manage-audit.md)
+ [ログ記録とモニタリング](certificate-based-authentication-manage-logging.md)
# プライベート CA 証明書
一般的な設定では、プライベート CA 証明書の有効期間は 10 年です。証明書の有効期限が切れたプライベート CA を置き換える方法、またはプライベート CA を新しい有効期間で再発行する方法の詳細については、「[プライベート CA ライフサイクルの管理](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html)」を参照してください。
# エンドユーザー証明書
WorkSpaces アプリケーション証明書ベースの認証用に AWS Private CA によって発行されたエンドユーザー証明書は、更新や取り消しを必要としません。これらは使用期間が短い証明書です。WorkSpaces Applications は、新しいセッションごとに新しい証明書を自動的に発行するか、長期間のセッションの場合は 24 時間ごとに新しい証明書を発行します。WorkSpaces アプリケーションセッションは、これらのエンドユーザー証明書の使用を管理します。セッションを終了すると、WorkSpaces アプリケーションはその証明書の使用を停止します。これらのエンドユーザー証明書の有効期間は、一般的な AWS プライベート CA CRL ディストリビューションよりも短くなります。そのため、エンドユーザー証明書を取り消さなくても、CRL に表示されなくなります。
# 監査レポート
プライベート CA が発行または取り消したすべての証明書を一覧表示する監査報告書を作成できます。詳細については、「[プライベート CA での監査レポートの使用](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html)」を参照してください。
# ログ記録とモニタリング
CloudTrail を使用して、WorkSpaces アプリケーションによるプライベート CA への API コールを記録できます。詳細については、「[AWS CloudTrailとは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」および「[CloudTrail の使用](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html)」を参照してください。CloudTrail イベント履歴では、WorkSpaces Applications**EcmAssumeRoleSession** ユーザー名によって作成された **acm-pca.amazonaws.com** イベントソースから **GetCertificate** イベント名と **IssueCertificate** イベント名を表示できます。これらのイベントは、WorkSpaces アプリケーション証明書ベースの認証リクエストごとに記録されます。詳細については、「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
# クロスアカウント PCA 共有を有効にする
プライベート CA (PCA) のクロスアカウント共有を使用すると、他のアカウントに一元的な CA を使用するアクセス許可を付与できます。CA は、[AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) を使用して証明書を生成および発行し、アクセス許可を管理できます。これにより、アカウントごとのプライベート CA は不要になります。プライベート CA クロスアカウント共有は、同じ 内の WorkSpaces アプリケーション証明書ベースの認証 (CBA) で使用できます AWS リージョン。
WorkSpaces Applications CBA で共有プライベート CA リソースを使用するには、次の手順を実行します。
1. 一元化された で CBA のプライベート CA を設定します AWS アカウント。詳細については、「[証明書ベースの認証](certificate-based-authentication.md)」を参照してください。
1. プライベート CA を WorkSpaces アプリケーションリソース AWS アカウント が CBA を利用するリソースと共有します。これを行うには、「[How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)」の手順に従います。証明書を作成するために、ステップ 3 を完了する必要はありません。プライベート CA を個人と共有することも AWS アカウント、 を通じて共有することもできます AWS Organizations。個々のアカウントと共有する場合は、 AWS Resource Access Manager コンソールまたは APIs を使用して、リソースアカウントで共有プライベート CA を受け入れる必要があります。
共有を設定するときは、 AWS Resource Access Manager リソースアカウントのプライベート CA のリソース共有が `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority`マネージドアクセス許可テンプレートを使用していることを確認します。このテンプレートは、CBA 証明書の発行時に WorkSpaces アプリケーションサービスロールで使用される PCA テンプレートと一致しています。
1. 共有が成功したら、リソースアカウントのプライベート CA コンソールを使用して、共有プライベート CA を表示します。
1. API または CLI を使用して、WorkSpaces Applications Directory Config の CBA にプライベート CA ARN を関連付けます。現時点では、WorkSpaces アプリケーションコンソールは共有プライベート CA ARNs の選択をサポートしていません。CLI コマンドの例を次に示します。
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`