이 페이지에서는 인증서 관리자 및 Certificate Authority Service (CA 서비스)를 사용하여 인증서를 Google Cloud 구성하고 관리하는 다양한 권장사항을 설명합니다. 이 페이지에서는 인증서 관리 아키텍처를 설계하는 방법을 설명합니다.
이 페이지를 읽기 전에 인증서 관리자 개요 및 Certificate Authority Service 개요 페이지를 숙지해야 합니다.
인증서 관리 아키텍처 설계
엔터프라이즈 인증서 관리 전략을 설계할 때는 조직의 주요 사용 사례와 인증서의 전체 수명 주기를 고려해야 합니다. 이러한 결정은 발급, 해지, 순환과 같은 인증서 관리 기능의 비용, 운영 오버헤드, 구현 용이성에 영향을 미칩니다.
다음 섹션에서는 각 설계 선택사항에 대한 권장사항을 설명합니다.
인증서 유형 선택
인증서를 만들 때는 애플리케이션 요구사항과 조직의 보안 정책에 따라 사용 사례에 적합한 인증서 유형을 선택해야 합니다.
가장 적합한 인증서 유형을 분석하려면 다음 플로우 차트를 참고하세요.
다음은 순서도에 언급된 주제에 대한 몇 가지 유용한 문서 링크입니다.
비공개 CA 서비스 계층 구조 간소화
원활한 운영과 문제 해결을 위해 CA 서비스의 계층 구조를 최대한 간단하게 유지하는 것이 좋습니다. 루트 인증 기관 (CA)을 자체 Google 프로젝트에 저장해야 합니다. 루트 CA는 몇 개의 중간 CA에 서명하고 이러한 CA는 최종 인증서를 발급합니다.
이 플랫 계층 구조는 투명성을 높이고 인증서 해지 프로세스를 간소화하며 잘못된 구성의 가능성을 줄입니다. CA 서비스는 리전 서비스이지만 한 리전의 루트 CA는 다른 리전에 있는 하위 CA에 서명할 수 있습니다.
다이어그램에 표시된 대로 CA 서비스 계층 구조에서 다음 권장사항을 따르세요.
- 발급 CA에 서명할 자체 Google Cloud 프로젝트에서 루트 CA를 격리합니다.
별도의 프로젝트에서 호스팅되는 CA 풀에 발급 CA를 만듭니다. 이러한 풀을 별도의 프로젝트에서 호스팅하고 지리적 위치(리전), 소프트웨어 개발 수명 주기 (개발, 프로덕션, 테스트) 또는 특정 사용 사례별로 세그먼트화합니다.
지원되는 리소스에 대해 비공개로 신뢰할 수 있는 인증서를 발급할 수 있는 발급 CA 풀을 사용하도록 인증서 관리자를 구성합니다.
포괄적인 호스트 이름 적용 범위 사용
인증서가 서비스에서 보호해야 하는 모든 도메인 및 하위 도메인에 충분한 호스트 이름 적용 범위를 제공하는지 확인하는 것이 좋습니다. 호스트 이름 적용 범위가 부족하면 사용자에게 보안 경고가 표시되고 서비스가 중단되며 사용자 경험이 저하될 수 있습니다.
여러 도메인에 단일 인증서를 사용하지 마세요. 단일 인증서가 갱신되지 않거나 실수로 삭제되면 적용되는 모든 도메인이 보호되지 않습니다. 서로 다른 도메인에 대해 고유한 인증서를 만드는 것이 좋습니다.
나중에 새 하위 도메인 또는 서비스를 추가할 계획이라면 와일드 카드 문자를 사용하여 처음부터 인증서에 하위 도메인 또는 서비스를 포함하세요. 예를 들어 *.myorg.example.com의 와일드 카드 인증서는 첫 번째 하위 도메인 수준만 보호하고 sub.subdomain.myorg.example.com과 같은 더 깊은 하위 도메인 수준은 보호하지 않습니다.
Google 관리형 인증서 사용
효율적인 공개 인증서 관리와 사용 편의성을 위해 Google 관리형 인증서를 사용하는 것이 좋습니다. 이 접근 방식은 인증서 순환과 같은 작업을 자동화하고 수동 갱신과 관련된 위험을 제거하여 운영 오버헤드를 크게 줄입니다.
또한 Google 관리형 인증서는 다른
Google Cloud 서비스와의 원활한 통합을 제공합니다. 인증서 관리자는 공개적으로 신뢰할 수 있는 Google 관리형 인증서를 발급하기 위해 Public Certificate Authority (pki.goog) 및 Let's Encrypt CA (letsencrypt.org)만 지원합니다. 인증서 관리자는 발급 CA에 따라 유효 기간이 45일 또는 90일인 Google 관리형 인증서를 프로비저닝합니다.
- 공개 CA에서 발급한 인증서는 유효 기간이 90일에서 45일로 점진적으로 전환됩니다. 기존 90일 인증서는 다음 갱신까지 90일 동안 유효합니다.
- Let's Encrypt CA에서 발급한 인증서의 유효 기간은 90일입니다.
인증서 관리자는 인증서 유효 기간의 약 1/3이 남으면 갱신 프로세스를 자동으로 시작합니다. 갱신은 45일 인증서의 경우 만료 약 15일 전, 90일 인증서의 경우 만료 약 30일 전에 시작됩니다.
인증서 성능 확장 및 개선
다음 섹션에서는 인증서를 확장하고 프로비저닝 및 갱신과 같은 인증서 관련 작업의 성능을 개선하기 위한 권장사항을 설명합니다.
인증서 관리자에 분산 배포 적용
프로젝트별 및 위치별로 인증서 관리자를 사용합니다. 즉, 인증서는 동일한 리전의 연결된 리소스와 동일한 프로젝트에 저장됩니다. 이 전략은 여러 리전에서 인증서가 재사용되지 않도록 하여 안정성을 높이고 리전 서비스 중단과 같은 드문 이벤트가 발생할 경우 영향을 효과적으로 최소화합니다.
또한 할당량과 한도는 프로젝트 수준에서 적용되므로 Google Cloud 여러 프로젝트에 인증서 관리자를 배포하면 전반적인 할당량이 늘어납101}니다. 한 프로젝트의 리소스를 사용해도 다른 프로젝트에서 사용 가능한 할당량은 영향을 받지 않기 때문입니다.
ECDSA 키가 있는 인증서 사용
이 섹션에서는 인증서 서명 키의 권장사항으로 RSA보다 ECDSA를 권장하는 이유를 살펴봅니다.
사용할 키 유형
ECDSA P-256 은 강력한 암호화 보안, 서명 작업의 뛰어난 성능, 네트워크 대역폭의 효율적인 사용을 제공하므로 대부분의 TLS 인증서에 권장되는 키 유형입니다.
다른 인증서 키 유형을 사용할 수 있는 몇 가지 이유는 다음과 같습니다.
- ECDSA 인증서를 지원하지 않는 레거시 클라이언트를 지원해야 하는 경우 ECDSA P-256 인증서 외에 RSA-2048 인증서를 제공할 수 있습니다.
- 더 큰 키 크기 또는 특정 키 유형을 사용해야 하는 특정 규정 준수 요구사항이 있는 경우 ECDSA P-384, RSA-2048, RSA-3072, RSA-4096 키를 사용할 수 있습니다.
RSA보다 ECDSA를 선택하는 이유
ECDSA의 주요 이점은 RSA에 비해 훨씬 작은 키로 동등한 암호화 보안 수준을 제공할 수 있다는 점입니다. 이러한 효율성은 실질적인 성능 및 리소스 이점으로 이어집니다. 키가 작다고 보안이 약한 것은 아닙니다. ECDSA는 키 단위당 더 강력한 보안을 제공하고 경우에 따라 RSA보다 더 나은 계산 효율성을 제공하는 타원 곡선 이산 로그 문제를 기반으로 합니다.
예를 들면 다음과 같습니다.
- 256비트 ECDSA 키는 RSA-3072 키와 유사한 보안 수준을 제공합니다.
- 384비트 ECDSA 키는 널리 지원되는 모든 RSA 키 크기보다 더 높은 보안 수준을 제공합니다.
ECDSA의 주요 이점은 다음과 같습니다.
성능: ECDSA 서명 작업은 동등한 보안 수준을 제공하는 RSA 작업보다 계산 집약도가 훨씬 낮습니다. 이렇게 하면 CPU 부하와 지연 시간이 줄어들며 이는 처리량이 많거나 지연 시간에 민감한 시스템에 매우 중요합니다.
효율성: 키와 서명이 작을수록 대역폭과 스토리지가 적게 필요하며 이는 모바일 및 IoT 기기와 같이 리소스가 제한된 환경에 특히 유용합니다.
다음과 같은 커스텀 조직 정책을 만들어 인증서에서 특정 키 유형 을 사용하도록 적용할 수 있습니다. 이는 자체 관리형 인증서 및 공개 신뢰 Google 관리형 인증서가 아닌 CA 서비스 (비공개 신뢰 관리형 인증서)의 Google 관리형 인증서에만 적용됩니다.
name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
resourceTypes: \
- certificatemanager.googleapis.com/CertificateIssuanceConfig \
methodTypes: \
- CREATE \
- UPDATE \
condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
actionType: ALLOW \
displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
description: Only ECDSA_P256 certificates are allowed from CA Service.
CA 풀을 사용하여 비공개 CA에서 인증서 발급
발급 CA에 CA 풀을 사용하는 것이 좋습니다. CA 풀은 공통 인증서 발급 정책과 Identity and Access Management (IAM) 정책이 적용되는 여러 CA의 모음입니다. CA 풀을 사용하면 풀 내에서 사용 설정된 모든 CA에 수신 인증서 요청을 부하 분산하고 분산하여 총 유효 초당 쿼리 수 (QPS)가 증가합니다. 이렇게 하면 워크로드나 클라이언트 측 변경사항에 영향을 미치지 않고 성능이 개선됩니다.
CA 풀은 인증서 발급 및 검색을 위한 단일 엔드포인트를 제공합니다. CA 풀을 사용하면 인증서 만료 또는 손상으로 인한 다운타임 없이 CA를 안전하게 순환할 수 있습니다.
인증서 맵 사용
최적의 확장성을 보장하려면 인증서 맵과 함께 지원되는 리소스를 사용하는 것이 좋습니다. 인증서 맵은 기본적으로 수천 개의 인증서 항목을 지원하고 수백만 개의 인증서를 처리할 수 있도록 확장되도록 설계되었습니다. 부하 분산기에서 사용하는 경우 인증서 맵 항목은 Compute Engine SSL 인증서와 같은 다른 인증서보다 우선합니다.
인증서 맵을 사용하면 인증서 선택 로직을 구성할 수도 있습니다. 예를 들어 핸드셰이크 중에 클라이언트의 호스트 이름이 프로비저닝된 인증서 맵의 항목과 일치하지 않으면 부하 분산기가 기본 인증서를 반환합니다.
올바른 도메인 승인 유형 선택
Google 관리형 인증서를 발급하려면 부하 분산기 승인 또는 DNS 승인을 사용하여 도메인 소유권을 증명하면 됩니다.
다음 표에서는 각 접근 방식의 고려사항을 설명합니다.
| 기능 | 부하 분산기 승인 | DNS 승인 |
|---|---|---|
| 설정 난이도 | DNS 구성에 추가 구성 단계나 변경이 필요하지 않습니다. | DNS 승인을 만들고 해당 해당 CNAME 레코드를 DNS 구성에 추가해야 합니다. |
| 네트워크 보안 | 부하 분산기는 인증서에서 제공하는 모든 도메인의 DNS
구성을 포함하여 포트 443의
인터넷을 사용하여 완전히 액세스할 수 있어야 합니다. 부하 분산기
승인은 다른 구성에서는 작동하지 않습니다. |
DNS 승인은 복잡성이 높은 구성(예: 443 이외의 포트 및 대상 프록시 앞에 있는 CDN 레이어)에서 작동합니다. |
| 프로비저닝 속도 | 프로비저닝 속도가 더 빠릅니다. 부하 분산기가 완전히 설정되고 네트워크 트래픽을 제공한 후에만 인증서를 프로비저닝할 수 있습니다. | 대상 프록시가 네트워크 트래픽을 제공할 준비가 되기 전에 인증서를 미리 프로비저닝할 수 있습니다. |
| 와일드 카드 인증서 | 지원되지 않음. | 지원됨 |
자체 관리형 인증서 순환 자동화
Google 관리형 인증서와 달리 자체 관리형 인증서는 만료되기 전에 수동으로 교체해야 합니다. 선택한 인증서 수명 주기 관리 (CLM) 제품을 사용하여 이 프로세스를 자동화하는 것이 좋습니다. 이렇게 하면 오류와 다운타임을 줄이고 운영 효율성을 보장할 수 있습니다.
인증서 맵을 사용하여 원활한 인증서 순환을 오케스트레이션할 수도 있습니다. 이 프로세스에는 다음 단계가 포함됩니다.
- Cloud Monitoring 및 알림을 사용하여 인증서 만료를 모니터링합니다. 향후 15~30일 이내에 만료되는 인증서에 대한 알림을 만드는 것이 좋습니다.
- 인증서 서명 요청 (CSR) 및 비공개 키를 생성하여 CA에 제출합니다.
- CSR 및 비공개 키를 CA에 제출한 후 새 인증서를 검색합니다.
새 인증서를 인증서 관리자의 적절한 인증서 맵에 업로드합니다.
- 새 인증서의 도메인 이름이 만료 예정인 인증서와 일치하면 기존 인증서 리소스에서
UpdateCertificate메서드를 사용합니다. - 새 인증서에 다른 도메인 이름이 있는 경우 먼저 새 PEM (개인 정보 보호 메일) 파일과 함께
CreateCertificateRequest메서드를 사용하여 만듭니다. 그런 다음UpdateCertificateMapEntry메서드를 사용하여 인증서 맵의 기존 인증서 참조를 새 인증서로 바꿉니다.
중요: 다운타임 없이 하나의 API 호출로 이 프로세스를 완료해야 합니다.
- 새 인증서의 도메인 이름이 만료 예정인 인증서와 일치하면 기존 인증서 리소스에서
적절한 액세스 제어 적용
액세스 제어를 구성할 때는 최소 권한의 원칙과 책임 구분을 고려하는 것이 좋습니다. 다음 섹션에서는 이러한 권장사항을 자세히 설명합니다.
최소 권한의 원칙 적용
인증서를 관리할 권한을 할당할 때는 최소 권한의 원칙을 고려해서 태스크 수행에 필요한 최소 권한을 부여해야 합니다. 기본 IAM 역할은 사용하지 않는 것이 좋습니다. 대신 사전 정의된 또는 커스텀 인증서 관리자 및 CA 서비스 역할을 부여하여 초과 권한 액세스와 관련된 보안 사고 위험을 줄이세요.
책임 구분 계획
인증서 관리자와 인증서 발급자 또는 인증서 요청자 역할이 있는 사용자에 대해 고유한 ID와 권한을 유지하는 것이 좋습니다. 이렇게 하려면 사용자 리소스 계층 구조의 최상위에서 별도의 관리자 및 요청자 그룹을 만듭니다.
관리자 그룹이 다음 작업을 수행해야 합니다.
- CA 프로비저닝과 같은 인증서 인프라를 관리하고 유지보수합니다.
- 인증서 템플릿을 구성합니다.
- 인증서 해지 목록 (CRL) 및 온라인 인증서 상태 프로토콜 (OCSP) 응답자를 관리합니다.
- CA의 보안 정책을 구현합니다.
루트 CA를 호스팅하는 프로젝트의 경우 사용자 또는 그룹에 소유자 (roles/owner), 편집자 (roles/editor), CA 서비스 관리자(roles/privateca.admin)와 같은 기본 역할을 할당하지 마세요. 이 방법은 실수로 인한 삭제, 잘못된 구성, 과도한 노출을 방지합니다. 대신 루트 CA가 설치되고 구성된 후에는 필요에 따라 정당한 사유와 승인을 통해 적시(JIT) 액세스에
Privileged Access Manager(PAM)을(를) 사용합니다.
요청자 그룹은 사전 정의된 템플릿을 기반으로 인증서 요청을 처리하고 인증서를 발급하는 일상적인 작업을 담당해야 합니다.
다음 표에는 다양한 직무 기능과 일반적으로 연결되는 IAM 역할이 나와 있습니다.
| 페르소나 | 설명 | IAM 역할 |
|---|---|---|
| 인증서 관리자 | CA 및 인증서 인프라를 설정하고 관리합니다. | 인증서 관리자 소유자 (roles/certificatemanager.owner),CA 서비스 관리자 ( roles/privateca.admin) |
| 인증서 요청자 | 워크로드의 인증서를 요청합니다. | Certificate Authority Service 인증서 요청자
(roles/privateca.certificateRequester) |
| 워크로드 (자동화 서비스 계정) | 워크로드 또는 파이프라인에서 인증서를 요청하는 데 사용됩니다. | Certificate Authority Service 워크로드 인증서 요청자
(roles/privateca.workloadCertificateRequester)
|
| 보안 엔지니어 또는 PKI 소유자 | 인증서 정책, 해지, 수명 주기를 관리합니다. | CA Service 작업 관리자 (roles/privateca.caManager),
Certificate Authority Service 인증서 관리자 (roles/privateca.certificateManager) |
| DevOps 또는 플랫폼 엔지니어 | 부하 분산기에 인증서 배포 등을 관리합니다. | 인증서 관리자 편집자 (roles/certificatemanager.editor) |
| 감사자 또는 규정 준수 | 인증서 및 사용량을 모니터링합니다. | 인증서 관리자 뷰어 (roles/certificatemanager.viewer),
Certificate Authority Service 감사자 (roles/privateca.auditor) |
멀티 리전 및 멀티 클라우드 배포에 프로젝트별 DNS 승인 사용
프로젝트별 DNS 승인 접근 방식을 사용하여 여러 리전, 여러 클라우드, 소프트웨어 개발 수명 주기 (SDLC) 전반에서 프로젝트의 여러 승인을 독립적으로 관리하는 것이 좋습니다.
DNS 승인을 구획화하면 각 프로젝트가 고유한 DNS 레코드 및 권한 집합을 유지할 수 있습니다. 이러한 수준의 제어를 통해 각 프로젝트는 다른 프로젝트의 작업에 영향을 미치거나 영향을 받지 않고 DNS 구성을 자율적으로 관리할 수 있습니다. 예를 들어 개발팀은 프로덕션 시스템 또는 진행 중인 다른 프로젝트에 부정적인 영향을 미칠 위험 없이 특정 애플리케이션의 새로운 DNS 구성을 실험할 수 있습니다.
CAA 레코드를 사용하여 도메인 보호
인증 기관 승인 (CAA) 레코드는 도메인 이름 시스템 (DNS)의 보안 메커니즘입니다. CAA 레코드는 도메인 소유자에게 도메인에 대한 인증서를 발급할 수 있는 Public Certificate Authority (CA)를 구성할 수 있는 완전한 제어 권한을 제공합니다. 이 제어는 무단 인증서 발급을 방지하는 데 중요합니다. CAA가 적용되면 사기성 인증서의 공격 노출 영역이 줄어들어 웹사이트가 더 안전해집니다.
Google 관리형 인증서의 경우 인증서 발급 및 갱신 요청의 최적의 안정성을 위해 다음을 수동으로 승인하는 것이 좋습니다.
Cloud Logging, Cloud Monitoring, 가시성
다음 섹션에서는 감사 로깅 및 인증서 사용량과 만료를 모니터링하기 위한 권장사항을 설명합니다.
감사 로그 사용 설정 및 집계
조직의 모든 리소스를 모니터링하려면 관리자 활동 감사 로그 를 인증서 관리자를 비롯한 모든 서비스에 대해 중앙 위치로 집계합니다.
이렇게 하면 보안팀 또는 감사자가 인증서 관리자 및 CA 서비스 리소스 만들기 또는 수정과 관련된 모든 활동을 한곳에서 검토할 수 있습니다. 집계된 로그 구성에 대한 자세한 내용은 조직 로그 집계 및 저장을 참조하세요.
인증서 사용량 및 만료 모니터링
루트 CA 사용량, 인증서 만료, 인증서 삭제와 같은 중요한 인증서 관리자 이벤트에 대해 로그 기반 알림을 설정하는 것이 좋습니다. 이러한 알림은 인증서 생성 실패율과 같은 트리아지 작업을 지원하고 새 인증서를 요청하거나 할당량을 늘리는 다운스트림 프로세스를 트리거할 수 있습니다.
권한 관련 작업에 대해 다음 로그 알림 및 정책을 구성합니다.
규정 준수 요구사항
일반적으로 규정 준수 프레임워크는 특정 제품 또는 구성이 아닌 인증서 관리에 대한 대략적인 기대치와 목표를 지정합니다.
예를 들어 결제 카드 산업 데이터 보안 표준 (PCI DSS) 및 미국 국립표준기술연구소 (NIST)에서는 조직이 서명 키의 순환 기간을 문서화하고 구현하도록 요구합니다. 또한 카드 소지자 데이터를 보호하는 인벤토리와 모든 신뢰할 수 있는 서명 키 및 인증서를 지속적으로 모니터링하도록 요구합니다.
서비스가 Google Cloud 다양한 규정 준수 프레임워크 요구사항을 충족하는 데 어떻게 도움이 되는지 자세히 알아보려면 다음 리소스를 참고하세요.