CA 계층 구조 계획

모범 사례로 조직의 구조에 맞는 인증 기관의 계층 구조를 계획하는 것이 좋습니다. 일반적으로 다음과 같은 일반적인 CA 구조 중 하나를 구현할 수 있습니다.

2 레벨: 루트 CA 및 종속 CA

워크로드에 가장 단순한 CA 구조가 필요한 경우 이 옵션을 사용하십시오. 이 시나리오에서는 단일 신뢰 루트 CA를 작성합니다. 그런 다음 종속 CA(예: 중간 CA)를 작성하여 리프 인증서를 앱 및 서비스에 발행합니다.

세 가지 수준: 루트 CA 및 두 개의 하위 인증 기관

워크로드에 루트 CA와 하위 레벨 CA 오퍼레이션 사이에 추가 계층이 필요한 경우 이 옵션을 사용하십시오. 이 시나리오에서 중간 하위 CA는 앱에 리프 인증서를 발급하는 하위 인증 기관을 서명하는 데만 사용됩니다.

CA 계층 구조의 깊이 설정

Secrets Manager에서 인증 기관을 작성하는 경우, 최대 경로 길이 매개변수를 설정하여 해당 기관 체인에 존재할 수 있는 CA 인증서의 수를 결정할 수 있습니다. 이 값은 CA의 인증 경로에 있을 수 있는 CA 인증서의 수를 적용합니다.

일반적으로 인증 경로에 만들 수 있는 하위 인증 기관의 수를 제한하지 않는 루트 CA를 구성할 수 있습니다. 그러나 하위 인증 기관에 최대 경로 길이를 정의하는 것은 인증 기관이 잘못 구성되는 것을 방지하기 위한 중요한 보안 단계입니다. 계층 구조에 있는 종속 CA의 배치에 따라, 서명 기관의 권한이 의도된 깊이로만 제한되도록 최대 경로 길이를 지정해야 합니다.

정의하는 최대 경로 길이에는 리프 인증서가 포함되지 않습니다. 앞의 예에서 레벨 4의 하위 CA는 리프 인증서를 발급할 수 있지만 경로에 더 많은 CA 인증서를 가질 수 없습니다.

인증서의 유효 기간 선택

X.509 인증서의 유효 기간은 인증서를 신뢰하는 기간 및 유효한 상태로 유지되는 기간을 결정하는 필수 필드입니다. CA 계층 구조를 계획할 때 애플리케이션에 발행하려는 리프 인증서에 대해 선호하는 수명에서 역방향으로 작업합니다. 그런 다음, CA 인증서의 유효 기간을 결정합니다.

인증서의 유효 기간은 인증서를 발급한 CA의 유효 기간보다 짧거나 같아야 합니다. 예를 들어, TTL(유효 기간)이 10년인 루트 CA를 만드는 경우, 그 아래에 있는 모든 중간 인증 기관은 10년 이하의 TTL을 가져야 합니다. 마찬가지로 중간 CA의 TTL이 3년인 경우, 모든 리프 인증서의 TTL은 3년 이하여야 합니다.

1. 사용자의 유스 케이스에 적합한 리프 인증서의 유효 기간을 선택합니다.

   Secrets Manager로 작성할 수 있는 개인 인증서는 클라이언트 또는 서버 앱과 같은 최종 엔티티에 발행될 수 있는 리프 인증서로 간주됩니다. Secrets Manager를 사용하면 최대 유효 기간이 3년 또는 36개월인 인증서를 작성할 수 있습니다. 리프 인증서에 대한 TTL 또는 유효 기간을 결정한 후에 인증서 템플릿을 사용하여 값을 설정하여 새 리프 인증서를 생성할 때마다 원하는 TTL이 적용되도록 합니다.

   리프 인증서의 TTL이 짧을수록 인증서와 개인 키가 실수로 노출되거나 손상되는 것을 방지할 수 있습니다. 인증서에 대한 유효 기간이 짧을수록 손상 가능성이 줄어들지만, 인증서를 더 자주 순환시켜 유효한 상태를 유지하도록 해야 합니다. 부주의로 인한 가동 중단을 방지하기 위해 개인 인증서의 자동 순환을 스케줄할 수 있습니다.

2. 종속 CA의 유효 기간을 선택합니다.

   모범 사례로 하위 CA 인증서의 유효 기간을 발급하는 인증서의 유효 기간보다 훨씬 더 길게 설정합니다. 상위 CA의 유효 기간을 해당 상위 CA가 발행하는 모든 하위 CA 인증서 또는 리프 인증서의 유효 기간의 2~5배로 정의하십시오. 예를 들어, 2 레벨 CA 계층 구조가 있고 TTL이 1년인 리프 인증서를 발행하려는 경우, 3년의 TTL로 종속 발행 CA를 구성하십시오. 루트 CA 인증서를 교체하지 않고도 항상 종속 CA 인증서를 업데이트할 수 있습니다.

3. 루트 CA의 유효 기간을 선택합니다.

   루트 CA 인증서를 업데이트하면 변경 사항이 전체 공개 키 인프라(PKI)에 영향을 줍니다. 영향을 최소화하려면 루트 CA 인증서의 유효 기간을 길게 설정하는 것이 좋습니다. Secrets Manager에서 루트 인증서의 기본 TTL은 10년입니다.

키 관리 서비스 선택하기

Secrets Manager 에서 인증 기관을 만들기 전에 CA의 공개 키 및 비공개 키를 생성하기 위한 키 관리 서비스(KMS)를 선택해야 합니다. 개인 인증서 엔진 내부 KMS를 선택할 수 있으며, 이 경우 CA 공개 키와 개인 키가 소프트웨어에서 생성되고 서비스에서 내부적으로 관리합니다. 외부 하드웨어 보안 모듈(HSM)에서 키를 관리하도록 선택할 수도 있습니다. Secrets Manager는 CA 키 관리를 위해 IBM Cloud Hyper Protect Crypto Services(HPCS)를 지원합니다. HPCS 비공개 키 저장소에 있는 기존 키를 사용하도록 CA를 구성하거나 Secrets Manager가 CA의 새 키를 만들도록 허용할 수 있습니다.

Secrets Manager 비공개 인증서 엔진은 PKCS#11 API를 사용하여 HPCS와 통신하고 있습니다. 인증 및 권한 부여는 Secrets Manager IAM 자격증명 비밀을 사용하여 관리되는 IAM API 키를 사용하여 수행됩니다. 암호화 서명 작업은 CA 개인 키 자료가 암호화 장치를 떠나지 않고 HPCS에서 수행됩니다.

참고: Secrets Manager 는 HPCS에서 키를 사용하여 CA 인증서를 만드는 것과 관련된 비용 또는 요금 제한을 제어하지 않습니다.

키 생성을 위한 알고리즘 선택

Secrets Manager에서 인증 기관을 작성하기 전에 CA의 공개 키 및 개인 키를 생성하기 위한 키 알고리즘을 선택해야 합니다. 공개 및 개인 키 쌍은 SSL/TLS 연결을 인증하는 데 사용됩니다. 어디에서 시작해야 할지 확실하지 않은 경우에는 다음과 같은 제안된 안내서를 사용하여 키 알고리즘을 선택할 수 있습니다.

1. 알고리즘 군을 선택합니다.

   선택하는 키 알고리즘은 키를 생성하고 인증서에 서명하는 데 사용할 암호화 알고리즘 및 키 크기를 결정합니다. 우수 사례는 인증서 체인에 속하는 모든 인증서에 대해 동일한 알고리즘 군을 사용하는 것입니다. Secrets Manager는 다음 알고리즘 군을 지원합니다.

   지원되는 알고리즘 제품군 및 키 크기

   알고리즘 군	설명	지원되는 키 크기
   RSA	널리 사용되고 대부분의 브라우저와 서버와 호환되는 RSA는 공개 키 암호화에 대한 업계 표준입니다.	2048비트 4096비트
   타원 곡선(EC)	더 강력한 키와 더 작은 인증서를 생성합니다. 예를 들어 256비트 EC 키는 암호화 강도가 3072비트 RSA 키와 동등합니다.	224비트 256 비트 384 비트 521비트

2. 키 크기를 선택합니다.

   선택하는 키 크기 또는 길이에 따라 암호화 강도가 결정됩니다. 알고리즘 군의 키 크기가 클수록 암호화를 깨기가 더 어렵습니다. 키 길이가 길수록 더 많은 데이터를 저장 및 전송해야 하므로 인증서의 성능에 영향을 줄 수 있습니다. 우수 사례는 인증서의 TTL 또는 유효 기간에 적합한 키 크기를 선택하는 것입니다.

   수명이 긴 인증서의 경우, 더 긴 키 길이를 사용하여 더 많은 암호화 보호 기능을 제공하는 것이 좋습니다.

인증서 폐기 목록 읽기

이 엔드포인트를 사용하면 현재 CRL을 원시 DER-인코딩된 형태로 검색할 수 있습니다. /pem 을 엔드포인트에 추가하면 CRL이 PEM 형식으로 반환됩니다.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

리프 또는 중간 CA 인증서가 리프 인증서의 컨텍스트에서 취소되지 않았는지 유효성 검증하기 위해 "crl_distribution_points_encoded": true 특성을 사용하여 CA를 구성할 수 있습니다. 이 구성은 각 리프 또는 중간 CA 인증서의 X509v3 CRL Distribution Points 같은 속성에서 발급 CA CRL을 다운로드하는 데 사용되는 URL 을 인코딩합니다. 그런 다음 CA 유효성 검증기가 리프 또는 중간 CA 인증서가 취소되었는지 여부를 확인할 수 있습니다.

CA 인증서 읽기

이 엔드포인트를 사용하면 원시 DER-인코딩된 형태로 CA 인증서를 검색할 수 있습니다. /pem 을 엔드포인트에 추가하면 PEM 형식으로 CA 인증서가 반환됩니다.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

CA 인증서 체인 읽기

이 엔드포인트를 사용하여 PEM 형식의 CA를 포함하는 CA 인증서 체인을 검색할 수 있습니다. 이 엔드포인트는 베어 (bare) 상태입니다. 표준 Vault 데이터 구조를 리턴하지 않으며 Vault CLI가 이를 읽을 수 없습니다.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

CA 체인이 리프 인증서의 컨텍스트에서 온 것인지 확인하려면 "issuing_certificates_urls_encoded": true 속성을 사용하여 Secrets Manager 에서 인증 기관을 구성할 수 있습니다. 각 리프 또는 중간 CA 인증서에서 이 구성은 Authority Information Access/CA Issuers 속성에서 발급 CA 인증서를 다운로드하는 데 사용되는 URL 을 인코딩합니다. 그런 다음 CA 유효성 검증기가 각 CA 인증서의 유효성을 검증할 수 있습니다.