기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 인증서 기반 인증
Microsoft Active Directory에 조인된 WorkSpaces 애플리케이션 플릿에서 인증서 기반 인증을 사용할 수 있습니다. 이렇게 하면 사용자가 로그인할 때 Active Directory 도메인 암호를 입력하라는 메시지가 표시되지 않습니다. Active Directory 도메인에서 인증서 기반 인증을 사용하면 다음과 같은 작업을 수행할 수 있습니다.
+ SAML 2.0 ID 제공업체를 통해 사용자를 인증하고 Active Directory의 사용자와 매칭하도록 SAML 어설션을 제공할 수 있습니다.
+ 사용자 프롬프트 수를 줄여 Single Sign-On 로그온 경험을 생성할 수 있습니다.
+ SAML 2.0 ID 제공업체를 사용하여 암호 없는 인증 흐름을 활성화할 수 있습니다.
인증서 기반 인증은에서 AWS 프라이빗 인증 기관(AWS 프라이빗 CA) 리소스를 사용합니다 AWS 계정. AWS Private CA를 사용하면 루트 및 하위 CA를 포함한 사설 인증 기관(CA) 계층 구조를 생성할 수 CAs. 또한 자체 CA 계층 구조를 만들고 이 계층 구조를 사용하여 내부 사용자를 인증하는 데 사용할 인증서를 발급할 수 있습니다. 자세한 내용은 [란 무엇입니까? AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)를 참조하십시오.
인증서 기반 인증에 AWS Private CA를 사용하는 경우 WorkSpaces 애플리케이션은 각 WorkSpaces 애플리케이션 플릿 인스턴스의 세션 예약 시 사용자를 위해 인증서를 자동으로 요청합니다. 사용자는 인증서로 프로비저닝된 가상 스마트 카드를 사용하여 Active Directory에 인증됩니다.
인증서 기반 인증(CBA)은 Windows 인스턴스를 실행하는 WorkSpaces Applications 도메인에 조인된 플릿(단일 세션 및 다중 세션 플릿 모두)에서 지원됩니다. 다중 세션 플릿에서 CBA를 활성화하려면 02-07-2025 또는 그 이후에 릴리스된 WorkSpaces 애플리케이션 에이전트를 사용하는 WorkSpaces 애플리케이션 이미지를 사용해야 합니다. 또는 이미지는 02-11-2025 또는 그 이후에 릴리스된 관리형 WorkSpaces 애플리케이션 이미지 업데이트를 사용해야 합니다.
**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일 이후 인증서 기반 인증에 필수입니다. 자세한 내용은 Microsoft 지원 설명서에서 [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로 구성되지 않은 경우 Private CA를 사용하여 AWS 프라이빗 인증 기관(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 Trusted Root Certification Authorities 저장소에서 가장 적합한 옵션을 사용하여 이 CA를 식별합니다.
+ **인증서 취소 옵션** - CRL 배포
**참고**
인증서 기반 인증에는 WorkSpaces Applications 플릿 인스턴스와 도메인 컨트롤러 모두에서 액세스할 수 있는 온라인 CRL 배포 지점이 필요합니다. 이를 위해서는 AWS Private CA CRL 항목용으로 구성된 Amazon S3 버킷에 대한 인증되지 않은 액세스 또는 퍼블릭 액세스를 차단하는 경우 Amazon S3 버킷에 액세스할 수 있는 CloudFront 배포가 필요합니다. 옵션에 대한 자세한 내용은 [인증서 취소 목록(CRL) 계획](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)을 참조하세요.
1. WorkSpaces Applications 인증서 기반 인증에 사용할 CA를 지정할 `euc-private-ca` 권한이 있는 키로 프라이빗 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에 Active Directory Certificate Services 엔터프라이즈 CA가 구성되어 있는 경우 스마트 카드 로그온을 활성화하는 인증서가 포함된 도메인 컨트롤러가 자동으로 등록됩니다. Active Directory 인증서 서비스가 없는 경우 [타사 CA의 도메인 컨트롤러 인증서 요구 사항을](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller) 참조하세요. Active Directory 엔터프라이즈 인증 기관에서 도메인 컨트롤러 인증서 등록을 자동으로 관리할 것을 AWS 권장합니다.
**참고**
AWS 관리형 Microsoft AD를 사용하는 경우 도메인 컨트롤러 인증서에 대한 요구 사항을 충족하는 Amazon EC2 인스턴스에서 Certificate Services를 구성할 수 있습니다. [Active Directory 인증서 서비스로 구성된 관리형 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 관리형 Microsoft AD 및 Active Directory 인증서 서비스를 사용하면 컨트롤러의 VPC 보안 그룹에서 인증서 서비스를 실행하는 Amazon EC2 인스턴스로 아웃바운드 규칙도 생성해야 합니다. 인증서 자동 등록을 활성화하려면 TCP 포트 135와 포트 49152\$165535에 대한 보안 그룹 액세스 권한을 제공해야 합니다. 또한 Amazon EC2 인스턴스는 도메인 컨트롤러를 포함한 도메인 인스턴스로부터 동일한 포트에 대한 인바운드 액세스를 허용해야 합니다. AWS 관리형 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 Tool(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 애플리케이션 플릿 인스턴스에 게시하는 데 몇 분 정도 걸릴 수 있습니다.
**참고**
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에 다시 연결할 경우, 이 파일을 사용하기 전에 이미지 빌더에서 관련 인증서를 사용하여 다시 구성하고 스냅샷을 다시 생성해야 합니다.
다음은 루트 CA 인증서 다운로드 지침입니다.
1. 이미지 빌더에서 `/etc/sssd/pki/sssd_auth_ca_db.pem`이라는 파일을 생성합니다.
1. [AWS Private CA 콘솔](https://console.aws.amazon.com/acm-pca/)을 엽니다.
1. WorkSpaces 애플리케이션 디렉터리 구성에 사용되는 프라이빗 인증서를 선택합니다.
1. **CA 인증서** 탭을 선택합니다.
1. 인증서 체인과 인증서 본문을 이미지 빌더의 `/etc/sssd/pki/sssd_auth_ca_db.pem`에 복사합니다.
KDCs에서 사용하는 루트 CA 인증서가 WorkSpaces Applications Directory Config에서 사용하는 루트 CA 인증서와 다른 경우 다음 예제 단계에 따라 다운로드합니다.
1. 이미지 빌더와 동일한 도메인에 조인된 Windows 인스턴스에 연결합니다.
1. `certlm.msc`를 엽니다.
1. 왼쪽 창에서 **신뢰할 수 있는 루트 인증 기관**을 선택한 다음 **인증서**를 선택합니다.
1. 각 루트 CA 인증서에 대해 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 엽니다.
1. **모든 작업**을 선택하고 **내보내기**를 선택하여 인증서 내보내기 마법사를 연 후 **다음**을 선택합니다.
1. **Base64 인코딩 X.509(.CER)**를 선택하고 **다음**을 선택합니다.
1. **찾아보기**를 선택하고 파일 이름을 입력한 후 **다음**을 선택합니다.
1. **마침**을 클릭합니다.
1. 내보낸 인증서를 텍스트 편집기에서 엽니다.
1. 파일 내용을 이미지 빌더의 `/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 애플리케이션 웹 클라이언트 또는 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 애플리케이션은 각 새 세션에 대해 새 인증서를 자동으로 발급하거나 기간이 긴 세션의 경우 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에서 공유 Private CA 리소스를 사용하려면 다음 단계를 완료하세요.
1. 중앙 집중식에서 CBA용 프라이빗 CA를 구성합니다 AWS 계정. 자세한 내용은 [인증서 기반 인증](certificate-based-authentication.md) 단원을 참조하십시오.
1. WorkSpaces 애플리케이션 리소스 AWS 계정 가 CBA를 사용하는 리소스와 프라이빗 CA를 공유합니다. 이렇게 하려면 [AWS RAM을 사용하여 ACM Private CA 교차 계정을 공유하는 방법](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.
공유를 구성할 때 AWS Resource Access Manager 리소스 계정의 프라이빗 CA에 대한 리소스 공유가 `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` 관리형 권한 템플릿을 사용하고 있는지 확인합니다. 이 템플릿은 CBA 인증서를 발급할 때 WorkSpaces 애플리케이션 서비스 역할에서 사용하는 PCA 템플릿과 일치합니다.
1. 공유가 성공하면 리소스 계정의 프라이빗 CA 콘솔을 사용하여 공유 프라이빗 CA를 봅니다.
1. API 또는 CLI를 사용하여 WorkSpaces Applications Directory Config에서 프라이빗 CA ARN을 CBA와 연결합니다. 현재 WorkSpaces 애플리케이션 콘솔은 공유 프라이빗 CA ARNs 선택을 지원하지 않습니다. 다음은 CLI 명령 예시입니다.
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`