Amazon Web Services ブログ
AWS Private CA Connector for Active Directoryを使用して、AppStream 2.0 と WorkSpaces の証明書ベースの認証を簡素化する
このブログは 2024 年 9 月 11 日 に Roberto Moreno、 Jeremy Schiefer によって執筆された内容を日本語化したものです。原文はこちらを参照してください。
この投稿では、AWS Private CA Connector for Active Directory が、Amazon AppStream 2.0 および Amazon WorkSpaces の証明書ベースの認証(CBA)の構成をどのように簡素化し、加速するかについて説明します。このコンテキストにおけるAWS Private Certificate Authority と Active Directory Certificate Service の概要を提供します。Active Directory Certificate Service の代替としてAWS Private CA を使用する利点について説明し、構成手順を含めています。
SAML 2.0 アイデンティティプロバイダー (IdP) を AppStream 2.0 または Amazon WorkSpaces で使用している場合、CBA を使用してログインユーザーエクスペリエンスを向上させることができます。CBA は Active Directory ドメインパスワードのユーザープロンプトを排除します。これにより、SAML 2.0 IdP から AppStream 2.0 インスタンスまたは Amazon WorkSpaces へのシングルサインオンが可能になります。CBA の詳細については、「WorkSpaces 用の CBA の構成方法」および「AppStream 2.0 用の CBA の構成方法」をご覧ください。
概要
AWS Private CA と Active Directory 証明書サービスの役割
AppStream 2.0 および WorkSpaces でのCBAは、ユーザー証明書と仮想スマートカードの組み合わせに依存しています。これにより、Active Directory ドメインのメンバーである Windows マシンへのパスワードレス認証が可能になります。これを実現するために必要な重要なインフラストラクチャコンポーネントは2つあります。
AWS Private CA は、ユーザー証明書の発行と管理に使用されます。AppStream 2.0 と WorkSpaces サービスは、セッション認証プロセス中に AWS Private CA からユーザー証明書を自動的に要求します。その後、証明書がプロビジョニングされた仮想スマートカードを使用して、ユーザーは Active Directory に対して認証されます。AWS Private CA は、必要な CA 階層に応じて、証明書チェーンのルート CA または下位 CA として使用できます。
Active Directory Certificate Service (AD CS) は、Active Directory ドメインで仮想スマートカードログインを可能にするものです。具体的には、Active Directory Certificate Service は公開鍵基盤 (PKI) を提供し、Active Directory integrated Certificate Authority (またはエンタープライズCA) も含まれています。証明機関は、ドメインコントローラー証明書の発行と管理に使用されます。これらの証明書により、Key Distribution Center (KDC) は、CBA や仮想スマートカードログインに必要なドメインの他のメンバーに対して自身の ID を証明することができます。
-
- DC / Kerberos 証明書は、AD CS での証明書自動登録を通じて、すべてのドメインコントローラーに自動的に発行およびインストールされます。
- AWS Private CA は、AD CS ルート CA に対する下位 CA として構成されています。AWS Private CA 証明書は、その後手動で AD RootCA および NTAuthCA ストアに公開されます。
- CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。
- ユーザーは SAML 2.0 プロバイダーで認証されます。
- フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。
- SAML アサーションの属性に基づいて、WorkSpaces / AppStream2.0 には AWS プライベート CA によって署名されたユーザー証明書が発行されます。
- AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開されます。
- AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証されます。
Active Directory 証明書サービスの代替としての AWS Private CA Connector for AD
AD 用コネクタにより、AWS Private CA は Active Directory 統合エンタープライズ CA の役割を担うことができます。これは Active Directory Certificate Services をデプロイして、Active Directory 内のマシンに必要な証明書テンプレートと登録サービスを提供します。このアプローチにより、Active Directory Certificate Services のインフラストラクチャをデプロイする必要がなくなり、実装の労力が大幅に簡素化されます。また、運用オーバーヘッドを削減し、CA の秘密鍵が FIPS 140-2 レベル 3 認定のハードウェアセキュリティモジュール (HSM) に保存されることでセキュリティが向上します。
-
- AWS Private CA を設定、コネクタを介して AD と統合されています。エンタープライズ CA として、その CA 証明書は自動的に AD RootCA および NTAuthCA ストアに公開されます。DC / Kerberos 証明書は、AWS Private CA による証明書自動登録を通じて、ドメインコントローラーに自動的に発行およびインストールされます。
- CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。
- ユーザーは SAML プロバイダーで認証されます。
- フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。
- SAML アサーションの属性に基づいて、AppStream 2.0 / WorkSpaces には AWS Private CA によって署名されたユーザー証明書が発行されます。
- AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開します。
- AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証します。
Walkthrough
このウォークスルーでは、 AWS Private CA 、 Active Directory 用の AWS Private CA コネクタ、および AppStream 2.0 または WorkSpaces の証明書ベースの認証を設定します。
前提条件
- 使用する AWS サービスのコマンドを実行するために必要な IAM 権限を持つ AWS コンソール。
- SAML 2.0 ID プロバイダーと統合された機能的な AppStream 2.0 または WorkSpaces のデプロイメント
- SAML アサーションで
https://cloudwatch-portal.com/SAML/Attributes/PrincipalTag:UserPrincipalName
属性を設定します。この属性は CBA に必要であり、Active Directory のユーザープリンシパル名(UPN)にマッピングする必要があります。詳細については、「SAML 認証レスポンスのアサーションを作成する」を参照してください。 - SAML 2.0 設定で使用する IAM ロール信頼ポリシーに、まだ存在しない場合は、
sts:TagSession
権限を追加してください。この権限は証明書ベースの認証を使用するために必要です。詳細については、「SAML 2.0 フェデレーション IAM ロールを作成する」を参照してください。
- SAML アサーションで
- セルフマネージド Active Directory
- AWS Managed Microsoft AD はサポートされていません。
- AWS Directory Service AD Connector
- WorkSpaces ディレクトリで構成された既存のコネクタを使用するか、この目的のために新しいコネクタを作成することができます。
注: Active Directory サービスアカウントには、以下の「ステップ3: AD 用 PCA コネクタの作成」に記載されている追加の権限が必要になります。
- WorkSpaces ディレクトリで構成された既存のコネクタを使用するか、この目的のために新しいコネクタを作成することができます。
- ニーズに基づいて認証局 (CA) 階層を計画・設計する
- 注: このブログに含まれる構成手順は、簡略化のために1レベルの CA 階層を想定しています。単一の AWS Private CA インスタンスが有効期限の短い証明書でデプロイされ、ルート CA として機能し、証明書を発行します。
- 本番環境にデプロイする際、個別の管理制御と完全な信頼チェーンが必要な場合は、AWS Private CA のドキュメントを参照してください。
- 有効期限の短い証明書は、特に AppStream 2.0 および WorkSpaces CBA での使用が推奨されています。
設定手順
ステップ1:証明書失効リスト(CRL)をホストするための公開リポジトリを作成する
- Amazon Simple Storage Service (Amazon S3) バケットを作成して ACL を無効に設定し、すべてのパブリックアクセスをブロックします。
- CloudFront ディストリビューションを作成します:
- Amazon CloudFront コンソールに移動します。
- ディストリビューションを作成します。
- オリジンドメインには、最初のステップで指定したオリジンドメインとして作成された S3 バケットを選択してください。
- オリジンアクセスには、オリジンアクセスコントロール設定(推奨)を選択してください。
- コントロール設定の作成を選択してください。
- ディストリビューションを作成します。
- S3 バケットポリシーを作成します:
- Amazon S3 コンソールに移動します。
- このステップの最初に作成した S3 バケットを選択してください。
- アクセス許可タブを選択します。
- バケットポリシーを選択し、編集を選択します。
- 次のように入力してください。S3-BUCKET-NAME、AWS-ACCOUNT-NUMBER、およびCLOUDFRONT-DISTRIBUTIONをあなたの値に置き換えてください。その後、保存を選択します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "acm-pca.amazonaws.com" }, "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::S3-BUCKET-NAME/*", "arn:aws:s3:::S3-BUCKET-NAME" ], "Condition": { "StringEquals": { "aws:SourceAccount": "AWS-ACCOUNT-NUMBER" } } }, { "Sid": "AllowCloudFrontServicePrincipal", "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::S3-BUCKET-NAME/*", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::AWS-ACCOUNT-NUMBER:distribution/CLOUDFRONT-DISTRIBUTION" } } } ] }
ステップ2:AWS Private CA を作成する
-
ca_config.txt
ファイルを作成し、以下の情報でフォーマットして、太字の情報をあなたの組織の情報に置き換えてください:{ "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"YOUR-COUNTRY", "Organization":"YOUR-ORG", "OrganizationalUnit":"YOUR-OU", "State":"YOUR-STATE", "Locality":"YOUR-LOCALITY", "CommonName":"CA-NAME" } }
revoke_config.txt
ファイルを作成し、以下の情報でフォーマットしてください。太字のプレースホルダーを置き換えてください
注意: CustomCnameにHTTPS を含めないようにしてください。{ "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "S3BucketName":"YOUR-S3-BUCKET-NAME", "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL", "CustomCname":"CLOUDFRONT-DISTRIBUTION-FQDN" } }
- 短期間のルート AWS プライベート CA を作成するには、次の AWS CLI コマンドを入力してください。ターミナル環境として AWS CloudShell を使用することができます。
注意:これらの値は必須であり、変更してはいけません。コマンドを実行する前に、ca_config.txt
とrevoke_config.txt
ファイルを AWS CloudShell にアップロードしてください。aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=euc-private-ca,Value= \ --usage-mode SHORT_LIVED_CERTIFICATE
ステップ3:AD の PCA コネクタを作成する
AWS マネジメントコンソールを使用してコネクタを作成および設定するには、次の手順に従ってください。AWS CLI create-connector コマンドまたは CreateConnector API アクションを使用することもできます。
- AWS Private CA Connector for Active Directory コンソールに移動します。
- 初回サービスのランディングページまたは Active Directory 用コネクタのページで、[コネクタの作成]を選択します。
- 「Select your Active Directory type」の下で、「On-premises Active Directory with AWS AD Connector」を選択します。
- 「ディレクトリを選択」の下で、リストからあなたのディレクトリを選択してください。
- VPC エンドポイントのセキュリティグループを選択で、リストからセキュリティグループを選択するか、新しいセキュリティグループを作成します。
- 前提条件では、PowerShell スクリプトをダウンロードして実行し、サービスアカウントに権限を委任してください。必要な権限の詳細については、前提条件を参照してください。
- プライベート認証局セクションで、リストからプライベート CA を選択してください。
- 必要な情報を提供して選択内容を確認した後、[コネクタの作成] を選択します。これにより、Active Directory 用コネクタの詳細ページが開き、コネクタの作成進行状況を確認できます。
- 証明書登録ポリシーサーバーのエンドポイント URL を記録してください。これは以下のステップ4で使用します。
ステップ4:Active Directory ポリシーを構成する
グループポリシーは、ドメインコントローラーの証明書自動登録設定を構成するために使用され、AWS Private CA Connector エンドポイントに到達するための URL も含まれます。AWS Private CA のドキュメントに記載されているグループポリシーの設定手順に従ってください。
ステップ5:証明書テンプレートを作成する
PCA コネクタには、AD アプリケーションに使用される一般的な証明書テンプレートが含まれています。Kerberos 認証証明書テンプレートは、仮想スマートカードと CBA ログオンを許可するドメインコントローラー向けの最新の証明書テンプレートです。
- AWS Private CA Connector for Active Directory コンソールに移動します。
- Active Directory のコネクタリストから作成したコネクタを選択し、[詳細を表示] を選択します。
- コネクタの詳細ページで、テンプレートセクションを見つけ、「テンプレートの作成」を選択します。
- テンプレート作成ページで、テンプレート作成方法セクションにて、定義済みテンプレートから開始(デフォルト)を選択し、リストから Kerberos 認証を選んでください。
- テンプレート設定セクションで、以下の情報を提供してください:
- テンプレート名:Kerberos 認証
- テンプレートスキーマバージョン:テンプレートバージョン2
- クライアント互換性: Windows 8以降 / Windows Server 2016 以降
- 証明書設定セクションでは、デフォルト設定を使用します。
注意:AWS Private CA を有効期間の短い証明書で使用する場合、有効期間と更新期間を一致させるように設定する必要があります。- 有効期間:7日間
- 更新期間:1日
- グループとアクセス許可のセクションで、「新しいグループとアクセス許可を追加」をクリックして、必要なグループと登録設定を必要に応じて構成します。以下の例では、特定のドメイン内のすべてのドメインコントローラーが AWS Private CA から証明書をリクエストすることを許可しています。注:セキュリティ識別子(SID)の値はドメインに固有です。ドメインコントローラーで PowerShell コマンド Get-ADGroup -Identity “Domain Controllers” を実行して SID を取得できます。
- 表示名: ドメインコントローラー
- セキュリティ識別子: S-1-5-##-##########-##########-##########-516
- 登録:許可
- 自動登録:許可
- 他のすべてのセクションにはデフォルト設定を使用してください。
- テンプレートを作成を選択してください。
ステップ6:AWS Private CA と Active Directory の統合を検証する
新しいコネクタが作成されると、Active Directory に AWS Private CA 用の新しい certificationAuthority オブジェクトが作成されます。
- Active Directory サイトとサービスの管理コンソールを開きます。
- 表示メニューで、サービスノードの表示を選択します。
- サービスを展開し、公開鍵サービスを展開してから、証明機関を選択します
- AWS PCA のオブジェクトが acm-pca-ID として表示されることを確認してください。
PCA ルート証明書はドメインの信頼されたルート証明機関に追加されます。
- ドメイン参加済みのマシンで、ローカルコンピュータ用の証明書管理コンソール(certlm.msc)を開きます。
- 信頼されたルート証明機関を展開して証明書を選択してください
- 共通名に基づいて AWS PCA 証明書を見つけて開きます。
- 認証パスタブを選択し、証明書のステータスが「この証明書は問題ありません」であることを確認します。
ドメインコントローラー証明書は自動登録によってインストールされます。
- ドメインコントローラーでローカルコンピューターの証明書管理コンソールを開きます。
- 個人を展開して証明書を選択してください
- ドメインコントローラーの FQDN に基づいて証明書を特定し、それが AWS PCA によって発行され、Kerberos 認証テンプレートを使用していることを確認します。
- 証明書を開き、証明書パスタブを選択し、証明書のステータスが「この証明書は正常です」であることを確認します。
注意:証明書の自動登録は、ドメインレプリケーション、グループポリシー、その他のプロセスなどの様々な要因に基づいて時間がかかります。場合によっては、8時間以上かかることがあります。
ステップ7:WorkSpaces または AppStream 2.0 の CBA を有効にする
AWS Private CA が Active Directory ドメイン内のエンタープライズ CA になった今、AppStream 2.0 または WorkSpaces で証明書ベースの認証を有効にするための管理ガイドに従ってください。
AWS CloudTrail は、AppStream 2.0 または WorkSpaces サービスが AWS Private CA からユーザー証明書をリクエストしていることを確認するために使用されます。CloudTrail のイベント履歴では、EcmAssumeRoleSession ユーザー名によって行われた acm-pca.amazonaws.com イベントソースからの GetCertificate および IssueCertificate イベント名を確認できます。これらのイベントは、WorkSpaces または AppStream 2.0 の証明書ベースの認証リクエストごとに記録されます。
クリーンアップ
このブログに従って作成したリソースが不要になった場合は、以下の手順に従ってください。
- AppStream 2.0 または WorkSpaces コンソールで、ディレクトリ設定の証明書ベースの認証を無効にします。
- AWS Private CA Connector for Active Directory コンソールで、ステップ3で作成されたコネクタを削除します。
- ステップ4で作成された Active Directory の GPO を削除します。
- ドメインコントローラーに発行された PCA 上の証明書を取り消します。
- ドメインコントローラーにインストールされた AWS Private CA によって発行された証明書を削除します。
- Active Directory から certificationAuthority オブジェクトを削除します。
- AWS Private CA コンソールで、ステップ2で作成したプライベート認証局を削除します。
- CloudFront コンソールで、ステップ 1 で作成した CloudFront ディストリビューションを削除します。
- S3コンソールで、ステップ1で作成した S3 バケットを削除してください。
まとめ
この投稿では、AWS Private CA Connector for Active Directory を使用して、AppStream 2.0 および WorkSpaces での CBA 設定を簡素化する方法について学びました。このユースケースでコネクタを使用する主な利点は、Active Directory 証明書サービスの展開と管理を回避できることです。
ブログで言及されているサービスについて詳しく知るには、AD 用コネクタ、AWS Private CA、CA のベストプラクティス、およびAWS Directory Services のドキュメントを参照してください。AWS Management Console を使用して、AWS Private CA で CA の作成を始めることができます。