it-swarm-korea.com

1 계층에서 2 계층 Microsoft 인증 기관 계층으로 이동

현재 VPN 사용자에게 2 단계 인증을 위해 인증서를 발급하는 단일 Microsoft Enterprise Root CA가 있습니다. RDP 및 Dell Open Manage (시스템 관리 응용 프로그램)에 대한 인증서를 발급하기 위해 CA 사용을 확대 할 계획입니다.

지금까지 읽은 대부분의 내용은 현재 아키텍처가 이상적이지 않다고 제안했습니다. 내가 이해하기 때문에 강화 된 (전원이 꺼져있을 수도 있음) 엔터프라이즈 루트 CA가 있어야하며 발급 CA를 사용하여 실제로 발급해야합니다. 인증서. 이상적으로는 발급 CA도 안정성을 위해 클러스터링됩니다.

내 질문은 다음과 같습니다.

1) 위에서 설명한 것처럼 단일 계층 접근 방식에서 2 계층 접근 방식으로 어떻게 마이그레이션 할 수 있습니까?.

2) 기존 VPN 인증서를 깨고 재발급하지 않고도 이것이 가능합니까?

3)이 과정을보다 단계별로 설명하는 책/블로그/웹 사이트를 아는 사람이 있습니까?

이 주제에 대해 찾을 수있는 많은 자료는 Microsoft의 Technet 웹 사이트에 있으며 유용하지만 반드시 좋은 방법은 아닙니다.

감사
브래드

8
Brad

이론적으로 인증서를 재발급하지 않고도 "2 계층"접근 방식으로 마이그레이션 할 수 있지만 이것이 좋은 아이디어인지 여부는 명확하지 않습니다.

일부 시스템 이 인증서를 확인 할 때 a로 이어지는 chain 신뢰 앵커 (해당 시스템에서 하드 코딩 된 "루트 인증서")는 유효성을 검사 할 인증서 ( "최종 엔터티"로 "EE"라고 함)에 연결합니다. 기본 아이디어는 체인의 각 인증서에 다음 인증서의 서명을 확인하는 데 사용되는 공개 키가 포함되어 있다는 것입니다. 인증서 형식에 서명 필드가 포함되어 있고 해당 필드가 선택 사항이 아니기 때문에 루트 인증서도 서명됩니다. 그러나 아무도 그 서명을 확인하지 않으며 (신뢰 앵커는 서명 되었기 때문에가 아니라 "정의에 의해"신뢰 됨) 루트 인증서가 자체 서명되는 것이 일반적입니다.

검증자는 서명이 암호 학적으로 정확하고 인증서가 X.509 에 자세히 설명 된 속성 무리를 충족하는 경우 체인을 수락합니다. 간단하게하기 위해 각 인증서에는 주체 이름 발급자 이름 이 있습니다. ); 발급자 이름은 발급 한 인증서의 주체 이름 (예 : 체인의 이전 인증서)과 동일해야합니다. 여기서도 루트 인증서에는 발급자가 없으므로 루트가 자신을 발급자 (발급자와 주체 이름이 동일 함)로 갖는 것이 전통적이지만 필수는 아닙니다.

따라서 루트를 새 루트와 새 루트에서 발급 한 중간 CA의 조합으로 바꾸려고합니다. 중간 CA 인증서에 이전 루트와 동일한 주체 이름 및 동일한 공개 키 (및 동일한 "키 식별자"및 기타 X.509 확장)가 포함 된 경우 이전에 발급 된 EE 인증서를 이전 루트 ( 현재와 ​​같이) 새 루트로 시작하여 중간 CA를 통과하고 끝이 나는 체인의 일부로 새 루트에 대해 EE.

Microsoft Enterprise Root CA가 이전 루트의 특성 (이름, 공개 키 ...)을 재사용하는 중간 CA를 만드는 데 편리한 인터페이스를 제공할지 여부는 알 수 없습니다. 그러나 그렇다면 이러한 중간 CA를 생성하면 기존 VPN 인증서를 즉시 교체 할 필요없이 마이그레이션 작업의 절반을 수행 할 수 있습니다.

그래도 아직 끝나지 않았습니다. 새 루트는 배포 되어야합니다. 즉, 검증자는 새 루트를 인식해야하며 이전 루트도 잊어야합니다 (후자는 약간 지연). 이것은 비용이 많이 드는 부분이며 신뢰 앵커가 신뢰 시스템의 기초이기 때문에 까다 롭습니다. 관리자처럼 보이는 이메일이 사용자에게 그렇게하라고 지시했기 때문에 사용자가 트러스트 앵커를 다루도록 "교육"하고 싶지는 않습니다.

이제 잘 이해되어야하는 구조적 기술이 있습니다. 클라이언트 인증서가있는 VPN에서 클라이언트 인증서의 확인자는 서버입니다. 그러나 이러한 VPN은 클라이언트 소프트웨어에 의해 확인되는 서버 인증서도 사용합니다. client 인증서를 확인하는 데 사용되는 루트 CA를 변경하면 해당 확인을 수행하는 시스템에 새 루트를 삽입해야합니다. 이것이 바로 서버입니다 ( 그래서 아마도 이것은 쉽습니다). server 인증서를 발급하는 PKI의 새 루트 인증서로 전환하는 경우에만 클라이언트의 트러스트 앵커를 변경해야합니다. 아마도 양쪽에 동일한 루트를 사용했지만 이것이 절대적인 요구 사항은 아닙니다.

중간 CA를 갖고 싶은 주된 이유는 손상 억제 때문입니다. 중간 CA는 매일 새 인증서에 서명하는 CA입니다. 따라서 온라인 상태이고 중복 가능성이 있으므로 공격에 취약합니다. 손상된 경우 루트에 전원을 공급하여 새 중간 CA (새 키 사용)를 만들고 이전 중간 CA를 취소 할 수 있습니다. 따라서 verifiers 에서 신뢰 설정을 변경하지 않고도 손상으로부터 복구 할 수 있습니다. 현재 손상된 CA에서 발급 한 인증서를 교체하려면 여전히 새 인증서를 발급해야합니다. '

귀하의 VPN 시스템에는 귀하가 직접 제어하는 ​​단일 서버 또는 일부 서버가 있다고 가정합니다. 해당 (이) 서버에서 신뢰 앵커를 변경하는 것은 쉽고 저렴해야합니다. 마찬가지로 서버에 대한 새 인증서를 발급하는 것도 쉽습니다. 그리고 그렇게 자주하지 않기 때문에 서버 인증서의 루트가 오프라인 상태 일 수 있으며 확장 할 필요가 없습니다. 1 년에 한두 번 실행되지 않고 더 이상 실행되지 않습니다. 중간 CA는 루트로 수행하는 것과 동일한 방식으로 관리 할 수 ​​있기 때문에 서버 인증서에 대해 2 계층 접근 방식을 가질 필요가 거의 없습니다. 오프라인, 대부분의 시간을 안전하게 보관하고 있습니다. 클라이언트 인증서의 경우 많은 인증서를 발급하므로 해당 인증서에 대한 CA가 가동되고 네트워크로 연결되고 확장 가능해야하며 따라서 취약해야합니다. 그러나 손상 될 경우 클라이언트 인증서에 대한 신뢰 앵커를 변경하는 것은 어렵지 않습니다. 신뢰 앵커는 단일 VPN 서버에 있습니다. 따라서 2 계층 접근 방식을 사용할 수 있지만 추가 수준은 많은 것을 사지 못할 것입니다. 즉, 시스템 관리자의 경우 최대 10 분 작업과 같이 12 대의 서버에서 신뢰 앵커를 변경하는 비용 만 절약 할 수 있습니다. 클라이언트 인증서를 발급 한 CA 손상에 대한 실제 비용은 새 클라이언트 인증서를 발급해야하고 즉시 2 계층 CA를 변경하는 것입니다. 그것에 아무것도.

중간 CA 인증서가있는 "2 계층"PKI는 인증서 소유자와 검증자가 PKI를 관리하는 사람이 쉽게 제어 할 수없는 시스템이있을 때 좋은 생각입니다. VPN/RDP 설정에서 이것은 수백 의 서버가있는 경우에 적용되며, 서버 인증서 또는 다음에서 사용하는 트러스트 앵커를 변경하는 비용이 발생합니다. 무시할 수없는 서버.

이제 나는 지나치게 장황했습니다. 요약하자면 :

  • 이전에 발급 된 인증서에 영향을주지 않고 루트 CA를 중간 CA로 변환하는 것은 이론적으로 가능합니다.
  • 주어진 PKI 시스템 구현이 사용하기 쉬운 인터페이스를 제공하는지 여부는 또 다른 질문입니다.
  • "2 계층"은 일부 상황에서는 좋은 생각이지만, 다른 상황에서는 (일반적인 VPN 설치에 대한 가정을 포함하여) 구매하지 않습니다. 복잡성을 더하기 때문에 노력할만한 가치가 있는지 확실하지 않습니다.
  • PKI에 대해 생각하려면 누가 어떤 인증서를 확인하는지 식별해야합니다. 특히, 서버 PKI (클라이언트가 확인한 서버에 대한 인증서를 발급하는 PKI)와 클라이언트 PKI (서버에서 확인한 클라이언트에 대한 인증서를 발급하는 PKI)는 동일 할 필요가 없으며 다른 관리 프로세스.
5
Thomas Pornin