

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# AWS Private CA 모범 사례
<a name="ca-best-practices"></a>

모범 사례는를 AWS Private CA 효과적으로 사용하는 데 도움이 되는 권장 사항입니다. 다음 모범 사례는 현재 AWS Certificate Manager 및 AWS Private CA 고객의 실제 경험을 기반으로 합니다.

## CA 구조 및 정책 문서화
<a name="document-ca"></a>

AWS 에서는 CA 운영에 대한 모든 정책 및 관행을 문서화할 것을 권장합니다. 여기에는 다음이 포함될 수 있습니다.
+ CA 구조에 대한 의사 결정을 위한 추론
+ CA 및 CA 관계를 보여주는 다이어그램
+ CA 유효 기간에 대한 정책
+ CA 승계 계획
+ 경로 길이에 대한 정책
+ 권한 카탈로그
+ 관리 제어 구조에 대한 설명
+ 보안

이 정보는 CP(인증 정책)와 CPS(인증 사례 명세서)라는 두 문서에서 캡처할 수 있습니다. CA 작업에 대한 중요한 정보를 캡처하기 위한 프레임워크는 [RFC 3647](https://www.ietf.org/rfc/rfc3647.txt)을 참조하십시오.

## 가능한 경우 루트 CA 사용 최소화
<a name="minimize-root-use"></a>

루트 CA는 일반적으로 중간 CA에 대한 인증서를 발급하기 위한 용도로만 사용해야 합니다. 이렇게 하면 중간 CA가 최종 엔터티 인증서를 발급하는 일상적인 작업을 수행하는 동안 루트 CA를 손상 없이 저장할 수 있습니다.

그러나 조직의 현재 관행이 루트 CA에서 직접 최종 엔터티 인증서를 발급하는 경우는 보안 및 운영 제어를 개선하면서이 워크플로를 지원할 AWS Private CA 수 있습니다. 이 시나리오에서 최종 엔터티 인증서를 발급하려면 루트 CA가 최종 엔터티 인증서 템플릿을 사용하도록 허용하는 IAM 권한 정책이 필요합니다. IAM 정책에 대한 자세한 내용은 [용 Identity and Access Management(IAM) AWS Private Certificate Authority](security-iam.md) 단원을 참조하십시오.

**참고**  
이 구성의 경우, 제한 조건으로 인해 운영 문제가 야기될 수 있습니다. 예를 들어 루트 CA가 손상되거나 손실된 경우 새 루트 CA를 생성해서 환경의 모든 클라이언트에 배포해야 합니다. 이러한 복구 프로세스가 완료될 때까지 새 인증서를 발급할 수 없습니다. 루트 CA에서 직접 인증서를 발급하면 액세스를 제한하고 루트에서 발급된 인증서 수를 한정하지 못하게 되므로 둘 다 루트 CA 관리에 대한 모범 사례로 간주됩니다.

## 루트 CA에 고유한 권한 부여 AWS 계정
<a name="isolate-root-account"></a>

서로 다른 두 AWS 계정에 루트 CA와 하위 CA를 생성하는 것이 모범 사례입니다. 이렇게 하면 루트 CA에 대한 추가 보호 및 액세스 제어를 제공할 수 있습니다. 이를 위해 한 계정의 하위 CA에서 CSR을 내보내고 다른 계정의 루트 CA로 CSR을 서명하면 됩니다. 이 접근 방식의 이점은 계정별로 CA에 대한 제어를 분리할 수 있다는 것입니다. 단점은 AWS Management Console 마법사를 사용하여 루트 CA에서 하위 CA의 CA 인증서에 서명하는 프로세스를 간소화할 수 없다는 것입니다.

**중요**  
에 액세스할 때마다 다중 인증(MFA)을 사용하는 것이 좋습니다 AWS Private CA.

## 별도의 관리자 및 발급자 역할
<a name="role-separation"></a>

CA 관리자 역할은 최종 엔터티 인증서만 발급하면 되는 사용자와는 분리되어야 합니다. CA 관리자와 인증서 발급자가 동일한에 있는 경우 해당 용도에 맞는 IAM 사용자를 생성하여 발급자 권한을 제한 AWS 계정할 수 있습니다.

## 인증서의 관리형 해지 구현
<a name="managed-revocation"></a>

관리형 해지는 인증서가 해지되면 인증서 클라이언트에게 자동으로 알림을 제공합니다. 암호화 정보가 손상되었거나 잘못 발급된 경우 인증서를 해지해야 할 수 있습니다. 클라이언트는 일반적으로 해지된 인증서 수락을 거부합니다.는 관리형 해지를 위한 두 가지 표준 옵션인 온라인 인증서 상태 프로토콜(OCSP)과 인증서 해지 목록(CRLs AWS Private CA 제공합니다. 자세한 내용은 [AWS Private CA 인증서 해지 방법 계획](revocation-setup.md) 단원을 참조하십시오.

## 켜기 AWS CloudTrail
<a name="use-cloudtrail"></a>

프라이빗 CA를 생성하고 운영을 시작하기 전에 CloudTrail 로깅을 활성화합니다. CloudTrail을 사용하면 계정에 대한 AWS API 호출 기록을 검색하여 배포를 모니터링할 수 있습니다 AWS . 이 기록에는 AWS Management Console, AWS SDKs, AWS Command Line Interface및 상위 수준 AWS 서비스에서 수행된 API 호출이 포함됩니다. 또한 어떤 사용자 및 계정이 PCA API 작업을 호출했는지, 어떤 소스 IP 주소에 호출이 수행되었는지, 언제 호출이 발생했는지도 확인할 수 있습니다. API를 사용해 CloudTrail을 애플리케이션에 통합시킴으로써 조직에 대한 추적 생성을 자동화하고 추적 상태를 확인하며 관리자가 CloudTrail 로깅을 활성화하고 비활성화하는 방식을 제어할 수 있습니다. 자세한 내용은 [추적 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)을 참조하세요. AWS Private CA 작업에 대한 예제 추적을 [를 사용하여 AWS Private Certificate Authority API 호출 로깅 AWS CloudTrail](logging-using-cloudtrail-pca.md) 보려면 로 이동합니다.

## CA 키 및 인증서 관리
<a name="rotate-keys"></a>

유효 기간을 연장하거나 CA 키를 교체하여 프라이빗 CA의 수명 주기를 관리할 수 있습니다.

### CA 유효 기간 연장
<a name="extend-ca-validity"></a>

만료 날짜가 더 긴 새 CA 인증서를 가져와 CA의 유효 기간을 연장할 수 있습니다.

### CA 키 교체
<a name="rotate-ca-key"></a>

프라이빗 CA를 새 CA로 교체하여 CA 키를 주기적으로 교체합니다. 새 CA를 생성한 후 애플리케이션 및 서비스의 CA ARN에 대한 모든 참조를 새로 생성된 CA ARN으로 업데이트하고 인프라 전반의 트러스트 스토어를 새 CA 인증서로 업데이트합니다.

**참고**  
CA 자체를 교체하는 경우 CA의 ARN이 변경된다는 점에 유의하세요. 자동화에서 하드 코딩된 ARN 참조는 중단됩니다.

## 미사용 CA 삭제
<a name="delete-unused-ca"></a>

프라이빗 CA를 영구적으로 삭제할 수 있습니다. CA가 더 이상 필요하지 않거나 새 프라이빗 키가 있는 CA로 교체하려는 경우 그렇게 하는 것이 좋습니다. CA를 안전하게 삭제하려면 [프라이빗 CA 삭제](PCADeleteCA.md)에 설명된 절차를 따르는 것이 좋습니다.

**참고**  
AWS 는 CA가 삭제될 때까지 CA에 대한 요금을 청구합니다.

## CRL에 대한 퍼블릭 액세스 차단
<a name="bpa-crl"></a>

AWS Private CA 에서는 CRLs이 포함된 버킷에서 Amazon S3 퍼블릭 액세스 차단(BPA) 기능을 사용할 것을 권장합니다. 이렇게 하면 프라이빗 PKI의 세부 정보가 잠재적 공격자에게 불필요하게 노출되는 것을 방지할 수 있습니다. BPA는 S3 [모범 사례](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)이며 새 버킷에서 기본적으로 활성화됩니다. 경우에 따라 추가 설정이 필요합니다. 자세한 내용은 [CloudFront를 사용하여 S3 퍼블릭 액세스 차단(BPA) 활성화](crl-planning.md#s3-bpa) 단원을 참조하십시오.

## Amazon EKS 애플리케이션 모범 사례
<a name="kubernetes"></a>

 AWS Private CA 를 사용하여 X.509 인증서로 Amazon EKS를 프로비저닝하는 경우 [Amazon EKS 모범 사례 가이드의 다중 테넌트 환경 보안을 위한 권장 사항을 따르세요](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/#kubernetes-as-a-service). Kubernetes와 AWS Private CA 의 통합에 대한 일반 정보는 [를 사용하여 Kubernetes 보호 AWS Private Certificate Authority](PcaKubernetes.md) 섹션을 참조하세요.