CA 계층 구조 설계

AWS Private CA를 사용하면 최대 5개 수준의 인증 기관 계층 구조를 만들 수 있습니다. 계층 트리 맨 위에 있는 루트 CA에는 원하는 수만큼 분기를 가질 수 있습니다. 루트 CA는 각 분기에 최대 4개의 하위 CA를 가질 수 있습니다. 또한 각각이 자체 루트를 가진 계층을 여러 개 만들 수 있습니다.

잘 설계된 CA 계층 구조는 다음과 같은 이점을 제공합니다.

• 각 CA에 적합한 세분화된 보안 제어

• 로드 밸런싱 및 보안 향상을 위한 관리 작업 분할

• 일상적 운영에 대한 신뢰가 제한적이고 해지 가능한 CA 사용

• 유효 기간 및 인증서 경로 제한

다음 다이어그램에서는 간단한 3단계 CA 계층 구조를 보여 줍니다.

트리의 각 CA는 서명 권한이 있는 X.509 v3 인증서 (아이콘으로 표시됨) 로 뒷받침됩니다. pen-and-paper 이는 곧 CA가 해당 CA에 종속된 다른 인증서에 서명할 수 있다는 의미입니다. CA가 하위 레벨의 CA 인증서에 서명하면 서명된 인증서에 제한적이고 해지 가능한 권한이 부여됩니다. 레벨 1의 루트 CA는 레벨 2의 상위 레벨 하위 CA 인증서에 서명합니다. 이러한 CA는 최종 엔터티 인증서를 관리하는 퍼블릭 키 인프라(PKI) 관리자가 사용하는 레벨 3의 CA에 대한 인증서에 서명합니다.

CA 계층 구조의 보안은 트리 최상단에 가장 강력하게 구성되어 있어야 합니다. 이러한 구조는 루트 CA 인증서와 해당 프라이빗 키를 보호합니다. 루트 CA는 모든 하위 CA와 그 아래의 최종 엔터티 인증서에 대한 신뢰를 기반으로 합니다. 최종 엔터티 인증서의 손상으로 인해 지역화된 손상이 발생할 수 있지만, 루트가 손상되면 전체 PKI의 신뢰가 파괴됩니다. 루트 및 상위 레벨의 하위 CA는 자주 사용되지 않습니다(일반적으로 다른 CA 인증서에 서명하는 데 사용). 따라서 손상 위험을 낮출 수 있도록 인증서에 대해 엄격한 제어 및 감사가 이루어집니다. 계층 구조의 하위 레벨에서는 보안이 덜 제한적입니다. 이 접근 방법을 사용하면 사용자, 컴퓨터 호스트 및 소프트웨어 서비스에 대한 최종 엔터티 인증서를 발급하고 해지하는 일상적인 관리 작업을 수행할 수 있습니다.

참고

루트 CA를 사용하여 하위 인증서에 서명하는 것은 몇 가지 상황에서만 발생하는 드문 경우입니다.

• PKI가 생성되는 경우

• 상위 레벨의 인증 기관을 교체해야 하는 경우

• 인증서 해지 목록(CRL) 또는 온라인 인증서 상태 프로토콜(OCSP) 응답자를 구성해야 하는 경우

루트 및 기타 상위 레벨 CA에는 매우 안전한 운영 프로세스와 액세스 제어 프로토콜이 필요합니다.

최종 엔터티 인증서 유효성 검사

최종 엔터티 인증서는 하위 CA를 통해 루트 CA로 되돌아가는 인증 경로에서 신뢰를 파생시킵니다. 웹 브라우저 또는 다른 클라이언트는 최종 엔터티 인증서가 제공될 때 신뢰 체인을 구성하려고 시도합니다. 예를 들어, 인증서의 발급자 고유 이름 및 보안 주체 고유 이름이 발급 CA 인증서의 해당 필드와 일치하는지 확인할 수 있습니다. 클라이언트가 신뢰 저장소에 포함된 신뢰할 수 있는 루트에 도달할 때까지 계층 구조의 각 연속 레벨에서 일치 작업이 계속됩니다.

신뢰 저장소는 브라우저 또는 운영 체제에 포함된 신뢰할 수 있는 CA의 라이브러리입니다. 프라이빗 PKI의 경우, 조직의 IT 팀은 각 브라우저 또는 시스템이 이전에 사설 루트 CA를 신뢰 저장소에 추가했는지 확인해야 합니다. 그렇지 않으면 인증 경로의 유효성을 검사할 수 없으므로 클라이언트 오류가 발생합니다.

다음 그림은 최종 엔터티 X.509 인증서와 함께 표시될 때 브라우저가 따르는 유효성 검사 경로를 보여줍니다. 최종 엔터티 인증서에는 서명 권한이 없으며, 이러한 권한을 소유한 엔터티를 인증하는 역할만 합니다.

브라우저는 최종 엔터티 인증서를 검사합니다. 브라우저는 인증서가 하위 CA(레벨 3)의 서명을 신뢰 자격 증명으로 제공한다는 것을 확인합니다. 하위 CA의 인증서는 동일한 PEM 파일에 포함되어야 합니다. 또는 신뢰 체인을 구성하는 인증서가 포함된 별도의 파일에 있을 수도 있습니다. 이를 찾으면 브라우저는 하위 CA(레벨 3)의 인증서를 확인하고 하위 CA(레벨 2)의 서명을 제공하는지 확인합니다. 그러면 하위 CA(레벨 2)가 루트 CA(레벨 1)의 서명을 신뢰 자격 증명으로 제공합니다. 브라우저는 신뢰 저장소에 사전 설치된 사설 루트 CA 인증서의 복사본을 찾으면 최종 엔터티 인증서가 신뢰할 수 있는지 유효성 검사를 합니다.

일반적으로 브라우저는 인증서 해지 목록(CRL)과 비교하여 각 인증서를 확인합니다. 만료, 해지 또는 잘못 구성된 인증서는 거부되고 유효성 검사가 실패합니다.

CA 계층 구조 계획

일반적으로 CA 계층 구조에는 조직의 구조가 반영되어야 합니다. 관리 및 보안 역할을 위임하는 데 필요한 레벨 이상의 경로 길이(즉, CA 레벨 수)를 목표로 합니다. 계층에 CA를 추가하면 인증 경로에서 인증서 수가 늘어나므로 유효성 검사 시간이 길어집니다. 경로 길이를 최소로 유지하면 최종 엔터티 인증서를 검증할 때 서버에서 클라이언트로 보내는 인증서 수도 줄어듭니다.

이론적으로 pathLenConstraint파라미터가 없는 루트 CA는 무제한 수준의 하위 CA를 승인할 수 있습니다. 하위 CA는 내부 구성에서 허용하는 만큼의 하위 하위 CA를 가질 수 있습니다. AWS Private CA 관리형 계층 구조는 최대 5단계 깊이의 CA 인증 경로를 지원합니다.

잘 설계된 CA 구조에는 몇 가지 이점이 있습니다.

• 서로 다른 조직 단위에 대한 별도의 관리 제어

• 하위 CA에 대한 액세스 권한을 위임하는 기능

• 추가 보안 제어를 통해 상위 레벨의 CA를 보호하는 계층 구조

두 가지 공통 CA 구조가 이 모든 것을 수행합니다.

• 2개의 CA 레벨: 루트 CA 및 하위 CA

  이것은 루트 CA 및 하위 CA에 대해 별도의 관리, 제어 및 보안 정책을 허용하는 가장 간단한 CA 구조입니다. 하위 CA에 대해서는 보다 허용적으로 액세스를 허락하면서 루트 CA에 대해서는 제한적인 제어 및 정책을 유지할 수 있습니다. 후자는 최종 엔터티 인증서의 대량 발급에 사용됩니다.

• 3개의 CA 레벨: 루트 CA 및 두 계층의 하위 CA

  위와 유사하게 이러한 구조는 루트 CA를 하위 레벨의 CA 작업과 분리하기 위해 CA 계층을 추가합니다. 중간 CA 계층은 최종 엔터티 인증서의 발급을 수행하는 하위 CA에 서명하는 데만 사용됩니다.

덜 일반적인 CA 구조는 다음과 같습니다.

• 4개 이상의 CA 레벨

  레벨이 3개인 계층 구조보다 덜 일반적이지만 레벨이 4개 이상인 CA 계층 구조가 가능하며, 이러한 구조는 관리 위임을 허용하는 데 필요할 수 있습니다.

• 1개의 CA 레벨: 루트 CA만

  이 구조는 보통 전체 신뢰 체인이 필요하지 않을 때 개발 및 테스트에 사용됩니다. 프로덕션 환경에서 사용되며 비정형적입니다. 또한 루트 CA와 최종 엔터티 인증서를 발급하는 CA에 대해 별도의 보안 정책을 유지 관리하는 모범 사례를 위반합니다.

  하지만 이미 루트 CA에서 직접 인증서를 발급하고 있는 경우에는 마이그레이션할 수 있습니다. AWS Private CA이렇게 하면 OpenSSL 또는 기타 소프트웨어로 관리되는 루트 CA를 사용하는 것보다 보안 및 제어 측면에서 이점이 있습니다.

제조업체용 프라이빗 PKI의 예

이 예에서는 어떤 가상의 기술 업체가 스마트 전구와 스마트 토스터라는 2개의 사물 인터넷(IoT) 제품을 제조합니다. 생산 중에 각 디바이스에 최종 엔터티 인증서가 발급되므로 인터넷을 통해 제조업체와 안전하게 통신할 수 있습니다. 또한 회사의 PKI는 내부 웹 사이트 및 금융 및 비즈니스 업무를 실행하는 다양한 자체 호스팅 컴퓨터 서비스를 포함해 컴퓨터 인프라를 보호합니다.

따라서 CA 계층 구조는 이러한 비즈니스의 관리 및 운영 측면을 면밀하게 모델링합니다.

이 계층 구조에는 내부 작업용 루트 1개와 외부 작업용 루트 2개(각 제품 라인마다 1개의 루트 CA) 등 3개의 루트가 포함되어 있습니다. 또한 내부 운영을 위한 CA 레벨 2개와 외부 운영을 위한 레벨 3개 등 여러 인증 경로 길이를 보여 줍니다.

분리된 루트 CA를 사용하고 외부 운영 측면에서 하위 CA 레이어를 추가하는 것은 비즈니스 및 보안 요구 사항을 충족하는 설계입니다. CA 트리가 여러 개 있는 PKI는 기업 조직 개편, 매각 또는 인수에 대해 미래에 대비할 수 있습니다. 변경 사항이 발생할 때 보호 부문에서 전체 루트 CA 계층을 완전히 이동시킬 수 있습니다. 그리고 하위 CA의 레벨이 2개이기 때문에 수 천 또는 수 백만 개의 제조 항목에 대한 인증서를 대량 서명하는 역할을 하는 레벨 3 CA로부터 루트 CA를 철저하게 분리할 수 있습니다.

내부 측면에서 기업 웹 및 내부 컴퓨터 작업은 레벨이 2개인 계층 구조를 완성합니다. 이러한 레벨들 덕분에 웹 관리자와 운영 엔지니어는 자체 작업 도메인에 대해 독립적으로 인증서 발급을 관리할 수 있습니다. PKI를 별도의 기능 도메인으로 구분하는 것이 보안 상 가장 바람직하며, 이렇게 하면 상호 영향을 미칠 수 있는 손상으로부터 각자를 보호할 수 있습니다. 웹 관리자는 회사 전체에 웹 브라우저에서 사용할 최종 엔터티 인증서를 발급하여 내부 웹 사이트에서 통신을 인증하고 암호화합니다. 운영 엔지니어는 데이터 센터 호스트와 컴퓨터 서비스를 상호 인증하는 최종 엔터티 인증서를 발급합니다. 이 시스템은 중요한 데이터를 LAN에서 암호화하여 안전하게 유지합니다.

인증 경로에서 길이 제약 조건 설정

CA 계층의 구조는 각 인증서에 포함된 기본 제약 조건 확장에 의해 정의되고 적용됩니다. 확장은 두 가지 제약 조건을 정의합니다.

• cA - 인증서가 CA를 정의하는지 여부. 이 값이 false(기본값)이면 인증서는 최종 엔터티 인증서입니다.

• pathLenConstraint - 유효한 신뢰 체인에 존재할 수 있는 하위 수준 하위 CA의 최대 수. 최종 엔터티 인증서는 CA 인증서가 아니므로 계산에 포함되지 않습니다.

루트 CA 인증서에는 최대한의 유연성이 요구되며, 경로 길이 제약 조건이 포함되지 않습니다. 이렇게 하면 루트가 모든 길이의 인증 경로를 정의할 수 있습니다.

참고

AWS Private CA 인증 경로를 5단계로 제한합니다.

하위 CA는 계층 구조 배치에서 위치와 원하는 기능에 따라 0 이상의 pathLenConstraint 값을 갖습니다. 예를 들어 CA가 3개인 계층 구조에서는 루트 CA에 대해 경로 제약 조건이 지정되지 않습니다. 첫 번째 하위 CA는 경로 길이가 1이므로 하위 CA에 서명할 수 있습니다. 이러한 각 하위 CA의 pathLenConstraint 값은 반드시 0이어야 합니다. 이는 최종 엔터티 인증서에 서명은 할 수 있지만 추가 CA 인증서를 발급할 수는 없다는 의미입니다. 새 CA를 생성할 수 있는 기능을 제한하는 것은 중요한 보안 제어책입니다.

다음 그림은 이렇게 제한된 권한이 계층 구조 아래로 전파되는 것을 보여줍니다.

이렇듯 레벨이 4개인 계층 구조에서는 루트가 제약되지 않습니다(항상 그렇듯이). 그러나 첫 번째 하위 CA의 pathLenConstraint 값은 2입니다. 이 값은 하위 CA의 깊이가 2개 레벨 이상이 되지 못하도록 제한합니다. 따라서 유효한 인증 경로의 경우, 제약 조건 값이 다음 두 레벨에서 0으로 감소해야 합니다. 웹 브라우저가 이렇듯 경로 길이가 4보다 큰 분기에서 최종 엔터티 인증서를 발견하면 유효성 검사가 실패합니다. 실수로 생성된 CA, 잘못 구성된 CA 또는 무단 발급의 결과로 이러한 인증서가 생성될 수 있습니다.

템플릿을 사용한 경로 길이 관리

AWS Private CA 루트, 하위 및 최종 엔티티 인증서를 발급하기 위한 템플릿을 제공합니다. 이러한 템플릿은 경로 길이를 포함하여 기본 제약 조건 값에 대한 모범 사례를 캡슐화합니다. 템플릿에는 다음이 포함됩니다.

• RootCACertificate/V1

• 하위 ECA 인증서_ PathLen 0/V1

• 하위 CA 인증서_ 1/V1 PathLen

• 하위 ECA 인증서_ 2/V1 PathLen

• 하위 ECA 인증서_ 3/V1 PathLen

• EndEntityCertificate/V1

경로 길이를 발급 CA 인증서의 경로 길이보다 크거나 같게 해서 CA를 생성하려고 하면 IssueCertificate API가 오류를 반환합니다.

인증서 템플릿에 대한 자세한 내용은 인증서 템플릿 이해하기 단원을 참조하십시오.

AWS CloudFormation을 이용해 CA 계층 구조 설정 자동화

CA 계층 구조의 디자인을 결정했으면 템플릿을 사용하여 테스트하고 프로덕션에 적용할 수 있습니다. AWS CloudFormation 이러한 템플릿의 예제는 AWS CloudFormation 사용 설명서의 프라이빗 CA 계층 선언을 참조하세요.