이 페이지에서는 인증서 관리자 및 인증 기관 서비스 (CA 서비스)를 사용하여 Google Cloud 에서 인증서를 구성하고 관리하는 다양한 권장사항을 설명합니다. 이 페이지에서는 인증서 관리 아키텍처를 설계하는 방법을 설명합니다.
이 페이지를 읽기 전에 인증서 관리자 개요 및 인증 기관 서비스 개요 페이지를 숙지해야 합니다.
인증서 관리 아키텍처 설계
엔터프라이즈 인증서 관리 전략을 설계할 때는 조직의 주요 사용 사례와 인증서의 전체 수명 주기를 고려해야 합니다. 이러한 결정에 따라 비용과 운영 오버헤드, 그리고 발급, 취소, 교체와 같은 인증서 관리 기능 구현의 난이도가 달라집니다.
다음 섹션에서는 각 설계 선택사항에 대한 권장사항을 설명합니다.
인증서 유형 선택
인증서를 만들 때 애플리케이션 요구사항과 조직의 보안 정책에 따라 사용 사례에 적합한 인증서 유형을 선택해야 합니다.
가장 적합한 인증서 유형을 분석하려면 다음 순서도를 참고하세요.
다음은 흐름도에 언급된 주제에 관한 유용한 문서 링크입니다.
비공개 CA 서비스 계층 구조 간소화
원활한 운영과 문제 해결을 위해 CA 서비스의 계층 구조를 최대한 간단하게 유지하는 것이 좋습니다. 루트 인증 기관 (CA)을 자체 Google 프로젝트에 저장해야 합니다. 루트 CA는 몇 개의 중간 CA에 서명하고 이러한 CA는 최종 인증서를 발급합니다.
이 플랫 계층 구조는 투명성을 높이고, 인증서 취소 프로세스를 간소화하며, 구성 오류 가능성을 줄입니다. CA Service는 리전 서비스이지만 한 리전의 루트 CA는 다른 리전에 있는 하위 CA에 서명할 수 있습니다.
다이어그램에 표시된 대로 CA 서비스 계층 구조에서 다음 권장사항을 따르세요.
- 발급 CA에 서명하기 위해 자체 Google Cloud 프로젝트에서 루트 CA를 격리합니다.
별도의 프로젝트에서 호스팅되는 CA 풀에 발급 CA를 만듭니다. 이러한 풀을 별도의 프로젝트에 호스팅하고 지리적 위치(지역), 소프트웨어 개발 수명 주기 (개발, 프로덕션, 테스트) 또는 특정 사용 사례별로 분류합니다.
지원되는 리소스에 대해 비공개로 신뢰할 수 있는 인증서를 발급할 수 있는 발급 CA 풀을 사용하도록 인증서 관리자를 구성합니다.
포괄적인 호스트 이름 범위 사용
서비스에서 보호해야 하는 모든 도메인과 하위 도메인에 대해 인증서가 충분한 호스트 이름 범위를 제공하는지 확인하는 것이 좋습니다. 호스트 이름 범위가 부적절하면 사용자에게 보안 경고가 표시되고 서비스가 중단되며 사용자 환경이 저하될 수 있습니다.
여러 도메인에 단일 인증서를 사용하지 마세요. 단일 인증서가 갱신되지 않거나 실수로 삭제되면 인증서가 적용되는 모든 도메인이 보안되지 않습니다. 서로 다른 도메인에 대해 별도의 인증서를 만드는 것이 좋습니다.
나중에 새 하위 도메인이나 서비스를 추가할 계획이라면 처음부터 와일드 카드 문자를 사용하여 인증서에 하위 도메인이나 서비스를 포함하세요. 예를 들어 *.myorg.example.com의 와일드 카드 인증서는 첫 번째 하위 도메인 수준만 보호하며 sub.subdomain.myorg.example.com과 같은 더 깊은 하위 도메인 수준은 보호하지 않습니다.
Google 관리 인증서 사용
효율적인 공개 인증서 관리와 사용 편의성을 위해 Google 관리형 인증서를 사용하는 것이 좋습니다. 이 접근 방식을 사용하면 운영 오버헤드가 크게 줄어들고 인증서 순환과 같은 작업이 자동화되며 수동 갱신과 관련된 위험이 제거됩니다.
또한 Google 관리형 인증서는 다른Google Cloud 서비스와 원활하게 통합됩니다. Google 관리형 인증서는 90일 동안 유효하며 만료 약 1개월 전에 갱신 프로세스가 시작됩니다.
인증서 실적 확장 및 개선
다음 섹션에서는 인증서를 확장하고 프로비저닝 및 갱신과 같은 인증서 관련 작업의 성능을 개선하기 위한 권장사항을 설명합니다.
인증서 관리자에 분산형 배포 적용
프로젝트별 및 위치별로 인증서 관리자를 사용합니다. 즉, 인증서가 동일한 리전의 연결된 리소스와 동일한 프로젝트에 저장됩니다. 이 전략은 여러 리전에서 인증서를 재사용하지 못하도록 하여 안정성을 높이고 리전 중단이 발생할 가능성이 낮은 경우 영향을 효과적으로 최소화합니다.
또한 할당량 및 한도는 Google Cloud 프로젝트 수준에서 적용되므로 여러 프로젝트에 Certificate Manager를 배포하면 전체 할당량이 늘어납니다. 한 프로젝트의 리소스 사용은 다른 프로젝트에서 사용 가능한 할당량에 영향을 미치지 않기 때문입니다.
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 기기와 같이 리소스가 제한된 환경에 특히 유용합니다.
다음과 같은 맞춤 조직 정책을 만들어 인증서에서 특정 키 유형을 사용하도록 강제할 수 있습니다. 이는 CA 서비스의 Google 관리형 인증서 (비공개 신뢰 관리형 인증서)에만 적용되며 자체 관리 인증서 및 공개 신뢰 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)과 비공개 키를 생성합니다.
- CSR과 비공개 키를 CA에 제출한 후 새 인증서를 가져옵니다.
새 인증서를 인증서 관리자의 적절한 인증서 맵에 업로드합니다.
- 새 인증서의 도메인 이름이 만료 예정인 인증서와 일치하는 경우 기존 인증서 리소스에서
UpdateCertificate메서드를 사용합니다. - 새 인증서의 도메인 이름이 다른 경우 먼저 새 PEM (privacy-enhanced mail) 파일과 함께
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) |
| 워크로드 (자동화 서비스 계정) | 워크로드 또는 파이프라인에서 인증서를 요청하는 데 사용됩니다. | 인증 기관 서비스 워크로드 인증서 요청자
(roles/privateca.workloadCertificateRequester)
|
| 보안 엔지니어 또는 PKI 소유자 | 인증서 정책, 취소, 수명 주기를 관리합니다. | CA Service 작업 관리자 (roles/privateca.caManager),
Certificate Authority Service 인증서 관리자 (roles/privateca.certificateManager) |
| DevOps 또는 플랫폼 엔지니어 | 부하 분산기에 인증서 배포 등을 관리합니다. | 인증서 관리자 편집자(roles/certificatemanager.editor) |
| 감사 또는 규정 준수 | 인증서 및 사용량을 모니터링합니다. | 인증서 관리자 뷰어 (roles/certificatemanager.viewer),
인증 기관 서비스 감사자 (roles/privateca.auditor) |
멀티 리전 및 멀티 클라우드 배포에 프로젝트별 DNS 승인 사용
프로젝트별 DNS 승인 접근 방식을 사용하여 여러 리전, 여러 클라우드, 소프트웨어 개발 수명 주기(SDLC) 전반에서 프로젝트의 여러 승인을 독립적으로 관리하는 것이 좋습니다.
DNS 승인을 격리하면 각 프로젝트가 고유한 DNS 레코드 및 권한 집합을 유지할 수 있습니다. 이 수준의 제어를 통해 각 프로젝트는 다른 프로젝트의 작업에 간섭하거나 영향을 받지 않고 DNS 구성을 자율적으로 관리할 수 있습니다. 예를 들어 개발팀은 프로덕션 시스템이나 진행 중인 다른 프로젝트에 부정적인 영향을 미칠 위험 없이 특정 애플리케이션의 새로운 DNS 구성을 실험할 수 있습니다.
CAA 레코드를 사용하여 도메인 보호하기
인증 기관 승인 (CAA) 레코드는 도메인 이름 시스템 (DNS)의 보안 메커니즘입니다. CAA 레코드를 사용하면 도메인 소유자가 도메인에 대한 인증서를 발급할 수 있는 공개 인증 기관 (CA)을 완전히 제어할 수 있습니다. 이 제어는 인증서의 무단 발급을 방지하는 데 중요합니다. CAA가 적용되면 사기성 인증서의 공격 표면이 줄어들어 웹사이트의 보안이 효과적으로 강화됩니다.
Google 관리형 인증서의 경우 인증서 발급 및 갱신 요청의 신뢰성을 높이기 위해 다음을 수동으로 승인하는 것이 좋습니다.
Cloud Logging, Cloud Monitoring, 가시성
다음 섹션에서는 감사 로깅 및 인증서 사용량과 만료를 모니터링하기 위한 권장사항을 설명합니다.
감사 로깅 사용 설정 및 집계
조직의 모든 리소스를 모니터링하려면 Certificate Manager를 비롯한 모든 서비스의 관리자 활동 감사 로그를 중앙 위치에 집계하세요.
이렇게 하면 보안팀 또는 감사자가 Certificate Manager 및 CA 서비스 리소스 만들기 또는 수정과 관련된 모든 활동을 한곳에서 검토할 수 있습니다. 집계된 로그 구성에 대한 자세한 내용은 조직의 로그 집계 및 저장을 참고하세요.
인증서 사용 및 만료 모니터링
루트 CA 사용, 인증서 만료, 인증서 삭제와 같은 중요한 인증서 관리자 이벤트에 대해 로그 기반 알림을 설정하는 것이 좋습니다. 이러한 알림은 인증서 생성 실패율이 높은 것과 같은 작업을 분류하는 데 도움이 되며, 새 인증서를 요청하거나 할당량을 늘리는 다운스트림 프로세스를 트리거할 수 있습니다.
권한 관련 작업에 대해 다음 로그 알림 및 정책을 구성합니다.
규정 준수 요구사항
일반적으로 규정 준수 프레임워크는 특정 제품이나 구성이 아닌 인증서 관리에 대한 대략적인 기대치와 목표를 지정합니다.
예를 들어 결제 카드 산업 데이터 보안 표준 (PCI DSS) 및 국립표준기술연구소 (NIST)에서는 조직이 서명 키의 순환 기간을 문서화하고 구현하도록 요구합니다. 또한 카드 소지자 데이터를 보호하는 인벤토리와 모든 신뢰할 수 있는 서명 키 및 인증서를 지속적으로 모니터링해야 합니다.
Google Cloud 서비스가 다양한 규정 준수 프레임워크 요구사항을 충족하는 데 어떻게 도움이 되는지 자세히 알아보려면 다음 리소스를 참고하세요.