CA 계층 구조 설계

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

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

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

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

• 일일 작업에 대한 제한적이고 취소 가능한 신뢰와 CAs 함께 사용

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

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

트리의 각 CA는 서명 권한이 있는 X.509 v3 인증서(아이콘으로 기호화됨)의 pen-and-paper 지원을 받습니다. 즉CAs, 로서 다른 인증서에 하위 서명할 수 있습니다. CA가 하위 레벨의 CA 인증서에 서명하면 서명된 인증서에 제한적이고 해지 가능한 권한이 부여됩니다. 레벨 1의 루트 CA는 레벨 2의 상위 레벨 하위 CA 인증서에 서명합니다. 이러한 는 최종 사용자 인증서를 관리하는 PKI (퍼블릭 키 인프라) 관리자가 사용하는 수준 3CAs의 에 대한 인증서에 CAs서명합니다.

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

참고

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

• PKI 가 생성될 때

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

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

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

최종 주체 인증서 검증

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

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

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

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

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

CA 계층 구조 계획

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

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

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

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

• 하위 에 대한 액세스를 위임하는 기능 CAs

• 추가 보안 제어CAs로 상위 수준을 보호하는 계층 구조

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

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

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

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

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

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

• 4개 이상의 CA 레벨

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

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

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

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

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

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

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

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

외부 작업 측에서 분리된 루트 CAs 및 추가 하위 CA 계층을 사용하는 것은 비즈니스 및 보안 요구 사항을 충족하는 설계 결정입니다. 여러 CA 트리를 사용하면 PKI가 기업 개편, 매각 또는 인수에 대비하여 미래 보장됩니다. 변경 사항이 발생할 때 보호 부문에서 전체 루트 CA 계층을 완전히 이동시킬 수 있습니다. 또한 두 가지 수준의 하위 CA를 사용하면 루트CAs는 수천 또는 수백만 개의 제조 품목에 대한 인증서에 대량 서명을 CAs 담당하는 수준 3과 높은 수준의 격리를 갖습니다.

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

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

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

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

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

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

참고

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

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

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

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

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

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

• R ootCACertificate/V1

• S ubordinateCACertificate_PathLen0/V1

• S ubordinateCACertificate_PathLen1/V1

• S ubordinateCACertificate_PathLen2/V1

• S ubordinateCACertificate_PathLen3/V1

• EndEntityCertificate/V1

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

인증서 템플릿에 대한 자세한 내용은 AWS Private CA 인증서 템플릿 사용 단원을 참조하십시오.

를 사용하여 CA 계층 구조 설정 자동화 AWS CloudFormation

CA 계층 구조에 대한 설계에 합의한 경우 AWS CloudFormation 템플릿을 사용하여 이를 테스트하고 프로덕션에 배치할 수 있습니다. 이러한 템플릿의 예제는 AWS CloudFormation 사용 설명서의 프라이빗 CA 계층 선언을 참조하세요.