4장: 공용 키 구조 디자인

  • 아티클

게시 날짜: 2004년 11월 20일 | 업데이트 날짜: 2004년 11월 24일

이 페이지의 내용

소개
인증서 요구 사항 정의
인증 기관 계층 구조 디자인
인증서 프로필 구성
인증서 관리 계획 세우기
요약

소개

앞 장에서는 보안 PKI(공용 키 구조)를 사용하는 무선 솔루션의 논리적 디자인을 다루었습니다. 이 장은 Microsoft® Windows® 2003 인증서 서비스를 기반으로 솔루션의 PKI를 디자인하는 프로세스를 정의합니다. 솔루션 디자인은 배포 및 관리 비용을 낮추기 위해 비교적 간단하고 무선 클라이언트 보안 및 WLAN(wireless local area network) 인프라를 위한 인증서 발급에 적합합니다.

하지만 1차적인 목표가 보안 WLAN을 지원하는 PKI를 디자인하는 것이지만 PKI 역시 조직의 보안 인프라 전체의 중요한 일부분을 형성합니다. 즉, 사용 환경의 다른 응용 프로그램이 향후 사용하게 될 인프라 중 하나입니다. 이 인프라에 대한 투자를 보호하기 위해 여기에서는 확장 가능한 디자인을 소개합니다. 즉, 디자인이 모든 형식의 인증서를 발급하는 데 적합하지 않을지라도 앞으로 기능 및 용량을 추가하여 여기서 다루는 것보다 더 광범위한 보안 요구 사항을 충족할 수 있습니다.

본 장은 크게 세 가지 목표를 가지고 있습니다. 첫 번째는 솔루션 디자인 결정 및 결정 근거를 논의하는 것입니다. 두 번째는 디자인 결정이 PKI에 적합한지 확인하는 데 도움이 되는 계획 배경 정보를 제공하는 것입니다. 세 번째 목표는 기본 솔루션을 확장하여 이 솔루션 범위를 벗어나는 보안 요구 사항을 충족할 방법을 제시하는 것입니다.

이 장에 "이 솔루션은 ... 옵션을 사용하여" 또는 "이 디자인은 ...를 사용하여"등의 표현이 나오면 구축 및 운영 설명서 장에서 구현하는, 솔루션 디자인 일부로 이루어진 결정을 가리킵니다.

"이 ...를 결정해야 합니다." 등의 표현은 사용자 자신의 요구 사항을 기반으로 무언가를 결정해야 하는 경우를 말합니다. 이는 주로 솔루션을 확장하여 조직의 광범위한 보안 요구를 충족하는 방법을 논의하는 내용에서 등장합니다. 이런 이유로 사용자가 단계의 의미를 이해하고 다른 문서를 참조할 필요가 없도록 하기 위해 주제에 따라 상세한 논의를 하기도 합니다.

장 전제 조건

PKI의 일반적인 개념과 용어를 잘 이해해야 합니다. 용어가 생소한 경우 이 장 뒷부분의 "추가 정보" 절에 소개된 기사를 읽어보시기 바랍니다.

계속하기 전에 Microsoft Windows Server™ 2003 Deployment Kit의 "공개 키 구조 디자인"을 잘 이해해야 합니다. "공개 키 구조 디자인"을 찾으려면 이 장 뒷부분의 "추가 정보" 절을 참조하십시오. 이 장은 Deployment Kit에 나와 있는 "공개 키 구조 디자인" 장의 구성을 따랐기 때문에 관련 배경 정보 및 그 안에 포함된 상세한 논의를 참조하기 쉽습니다.

Windows Server 2003 PKI 계획 및 디자인 방법에 관한 상세한 추가 논의 링크도 "추가 정보" 절에 있습니다.

장 개요

조직의 현재 및 미래의 요구를 충족하기 위해 PKI를 계획하고 배포하는 것은 간단한 작업이 아닙니다. 보통 PKI는 하나의 독립된 보안 문제에 대한 해법을 제공하기 위한 것이 아닙니다. 조직은 PKI를 배포하여 수많은 내부 보안 요구 사항을 다루고 외부 고객 또는 비즈니스 파트너와의 협력에 수반되는 비즈니스 보안 요구 사항을 다룹니다.

다음 순서도는 장 구성을 보여줍니다.

그림 4.1 인증서 서비스 계획의 장 구성

네 가지 주요 단계는 다음과 같습니다.

  • 인증서 요구 사항 정의. 이 단계에서는 해결하려는 보안 문제를 정의합니다. 이는 보안 강화가 필요한 특정 응용 프로그램/사용자 및 보안 강화의 필요한 수준을 기반으로 합니다. 보안 및 비즈니스 요구 사항을 정의하기 전에는 PKI를 만들 수 없습니다.

  • 인증 기관 계층 구조 디자인. 다양한 요소을 기반으로 CA(인증 기관) 인프라를 만들어야 합니다. 이 단계에서는 신뢰 모델 정의, 필요한 CA 수 결정, CA 관리 방법 및 추가 CA를 도입하거나 다른 조직과 트러스트를 형성하여 PKI를 확장하는 방법을 다룹니다. 또한 PKI를 Active Directory® 디렉터리 서비스 및 Microsoft IIS(Internet Information Services) 등의 IT 인프라의 다른 기법과 통합하는 방법을 다룹니다.

  • 인증서 프로필 구성. 이 단계는 사용할 인증서 형식, 인증서와 연결할 암호화 키의 보안 수준, 인증서의 유효 수명 및 갱신 가능 여부 등을 논의합니다.

  • 인증서 관리 계획 세우기. 이 단계는 인증서를 최종 사용자에게 발급하는 법, 인증서 요청을 처리하는 법, (CRL)인증서 해지 목록 관리 및 배포 방법을 정의합니다.

페이지 위쪽

인증서 요구 사항 정의

이 절에서는 PKI의 인증서 발급 목적과 각 목적에 대한 보안 요구 사항을 정의합니다.

Certificate Practices Statement 만들기

PKI를 디자인하는 과정에서 인증서를 발급하는 방법과 조직에서 인증서를 사용하는 방법에 대해 결정한 내용을 기록해야 합니다. 이와 같은 의사 결정 내용을 인증서 정책이라고 하며 이러한 내용을 기록한 문서를 인증서 정책 설명 및 CPS(Certificate Practice Statement)라고 합니다.

정해진 용어로 CP(인증서 정책)는 PKI가 동작하는 규칙 집합니다. CP는 공통 보안 요구 사항을 지닌 특정 클라이언트 또는 응용 프로그램 그룹의 인증서 사용 가능 여부 등을 기록합니다. 반면 CPS(certificate practices statement)는 조직에서 발급하는 인증서를 관리하는 데 사용하는 방법을 설명한 것입니다. CPS는 조직의 시스템 아키텍처 및 운영 절차에 따라 해당 조직의 인증서 정책이 어떻게 해석되는지 설명합니다. CP는 조직 규모의 문서입니다. 하지만 CPS는 CA별로 결정됩니다(CA가 동일한 작업을 수행하는 경우 공통의 CPS를 가집니다. 예를 들어, 성능 또는 복원력을 이유로 CA 부하를 여러 서버에 분할하는 경우가 있습니다.).

조직이나 인증서 용도에 따라 CP 및 CPS는 법률 문서나 법적 고지 사항으로 간주됩니다. 여기에는 일반적으로 이 장의 범위를 벗어나는 전문적인 법률적 조언이 필요합니다. 그러나 이 두 가지 문서 중 하나를 PKI의 일부로 만드는 데에는 엄격한 요구 사항이 존재하지 않습니다. 특정한 법적 또는 상업적 이유가 있지 않는 한 공식적인 인증서 정책 및 방법 설명을 만들고 유지하는 데 시간이나 비용을 소비할 필요가 없습니다.

공식적인 CP 또는 CPS가 필요하지 않더라도 인증서 정책과 운영 방법을 문서화해야 합니다. 인증서 정책은 조직의 전반적인 보안 정책에 속하게 되며 운영 방법은 보안 관리 절차에 속하게 됩니다. 이러한 형식을 비공식적인 CPS라고 할 수 있습니다.

본래 의도한 PKI의 용도에 따라 공식적인 정책 설명 및 CPS를 만들어야 하는지 아닌지를 결정해야 합니다. 공식적인 CPS가 필요한 경우 이를 게시하고 여기에 대한 참조를 CA 인증서에 포함시켜야 합니다. 이 솔루션에는 공식적인 CPS 작성에 대한 지침이 제공되지 않지만 이러한 CPS를 게시하는 방법에 대한 설명은 7장 "공용 키 구조 구현" 모듈에 포함되어 있습니다. 일반적으로 비공식 CPS를 게시할 필요가 없습니다.

이 장의 나머지 부분에는 CPS와 관련된 의사 결정을 문서화하는 것에 대한 참조 자료가 자주 나옵니다. 이러한 설명은 공식적인 CPS 및 비공식적인 CPS 모두에 동일하게 적용됩니다.

CPS 작성에 대한 추가 정보의 출처는 이 장 뒷부분의 "추가 정보"에 포함되어 있습니다.

인증서 응용 프로그램 식별

PKI 디자인 프로세스의 첫 번째 단계에서는 인증서를 활용하는 응용 프로그램 목록을 식별합니다. 각 응용 프로그램에 대해 각 응용 프로그램에 필요한 인증서 종류와 인증서의 대략적인 개수를 문서화해야 합니다. 이 단계에서는 인증서의 세부 사항을 지정할 필요가 없으며 간략한 설명만 제공하면 됩니다.

무선 솔루션 보안의 경우 무선 클라이언트 보안 및 Windows RADIUS(Remote Authentication Dial-In User Service) 서버를 위한 인증서가 필요합니다. Microsoft RADIUS 서버는 IAS(Internet Authentication Service)라는 Windows Server의 구성 요소입니다.

필요한 인증서의 종류는 다음 표에 나와 있습니다. 이 솔루션에 반드시 필요한 것은 아니지만 PKI는 도메인 컨트롤러에 인증서를 발급합니다(포리스트에 Windows 2003 Enterprise CA가 설치되어 있는 경우 기본적으로 인증서가 발급됩니다.).

표 4.1. 무선 솔루션 보안을 위한 인증서 요구 사항

응용 프로그램 인증서 종류 인증서 개수
보안 WLAN 사용자용 클라이언트 인증 인증서 WLAN 액세스가 필요한 모든 사용자
  컴퓨터용 클라이언트 인증 인증서 모든 무선 LAN 컴퓨터
  IAS 서버용 서비 인증 인증서 모든 IAS 서버
Active Directory 도메인 컨트롤러 인증 포리스트의 모든 도메인 컨트롤러
다음 표에 나와 있는 응용 프로그램의 인증서 발급을 위해 향후 PKI를 확장할 수 있습니다. **표 4.2. 향후 인증서 요구 사항**

응용 프로그램 인증서 종류 인증서 개수
클라이언트 액세스 VPN(가상 사설망) 컴퓨터 클라이언트 인증(IPSec) 모든 원격 VPN 클라이언트
지점 간 VPN VPN 서버 인증(IPSec) 모든 VPN 라우터
IP 보안(IPSec) 컴퓨터 클라이언트 인증 IPSec을 필요로 하는 모든 클라이언트 및 서버 컴퓨터
웹 보안 인트라넷 웹 응용 프로그램에 대한 사용자 인증 모든 사용자
  인트라넷 웹 서버 보안 인트라넷 웹 서버
EFS(파일 암호화 시스템) EFS 사용자 모든 사용자
  EFS 데이터 복구 복구 에이전트
보안 전자 메일 S/MIME(Secure/Multipurpose Internet Mail Extensions) 서명 및 암호화 모든 전자 메일 사용자
  키 복구 복구 에이전트
스마트 카드 스마트 카드 로그인 도메인 사용자
코드 서명 내부 코드 및 매크로 서명 코드 릴리스 관리자
#### 인증서 클라이언트 정의 앞 절에 소개한 응용 프로그램의 경우 인증서를 사용할 클라이언트를 정의해야 합니다. 여기서 "클라이언트"는 PKI가 발급하는 인증서를 사용하는 임의의 사람, 소프트웨어 프로세스 또는 장치를 말합니다. 클라이언트에는 사용자, 서버, 워크스테이션 및 네트워크 장치가 포함됩니다. 발급된 인증서가 어떻게 사용되는지 이해하려면 클라이언트의 두 가지 주요 범주를 이해해야 합니다. 인증서 주체(또는 *최종 엔터티*) 및 나머지 인증서 사용자입니다. 최종 엔터티는 PKI가 발급한 인증서를 보유한 클라이언트입니다. 인증서는 **주체** 또는 **대체 주체 이름** 필드에 클라이언트를 해당 인증서의 소유자로 식별하는 하나 이상의 개체가 있어야 합니다(예를 들어 호스트 이름, 전자 메일 주소 또는 디렉터리 구분 이름). 또 다른 인증서 사용자 범주는 최종 엔터티의 인증서를 확인하거나 디렉터리에서 인증서를 찾아야 하지만 반드시 PKI가 클라이언트에 발급한 인증서를 갖고 있을 필요는 없는 클라이언트입니다. 예제를 보면 차이점을 분명히 알 수 있습니다. 보안 웹 사이트에서 물건을 구매하는 인터넷 사용자는 웹 사이트의 보안 SSL(Secure Sockets Layer) 인증서 사용자가 됩니다. 하지만 웹 사이트는 인증서 최종 엔터티입니다. ID인 www.woodgrovebank.com은 인증서 **주체** 필드에 인코딩됩니다. 인증서 주체만 인증서 개인 키를 사용할 수 있는 액세스 권한이 있으며 인증서의 다른 사용자는 없습니다. 참고: 인증서 *주체*는 거의 항상 자신이 인증서 *사용자*이기도 하고 보통 다른 항목의 인증서입니다. **참고:** "최종 엔터티"가 정확한 용어지만 이 장에서는 대부분 "인증서 주체"라는 친숙한 용어를 사용합니다. 인증서 주체와 사용자 모두에 대해 다음 질문에 대답하여 각 클라이언트 유형을 분류해야 합니다. - 클라이언트가 사람 컴퓨터 또는 장치, 소프트웨어 프로세스 중 어느 것입니까? - 어떤 플랫폼(운영 체제 버전)을 기반으로 인증서를 사용합니까? - 클라이언트의 네트워크 위치는 어디입니까? 예를 들어 클라이언트가 내부 LAN, 협력 업체, 인터넷 등에 연결되어 있습니까? - 클라이언트가 도메인 구성원입니까? 그렇다면 CA와 다른 도메인 또는 다른 포리스트에 있습니까? 트러스트되지 않은 도메인입니까? - 클라이언트는 어떤 작업을 수행해야 합니까? 예를 들어 인증서를 등록하고 인증서로 서명하고 인증서 신뢰를 확인하고 디렉터리에서 인증서를 찾고 인증서 해지 상태를 확인하는 등의 작업이 있습니다. 이러한 분류는 인증서 발급 방법, 특정 인증서에 적용할 수 있는 트러스트 수준, 인증서 해지 정보 게시 방법 등 여러 디자인 의사 결정에 영향을 줍니다. 이 솔루션의 클라이언트 범주는 다음 표에 상세하게 나와 있습니다. **표 4.3. 인증서 주체(최종 엔터티) 범주**

인증서 클라이언트 유형 플랫폼 위치 도메인 인증서 작업
무선 클라이언트 인증 사용자 Windows XP 내부 네트워크 도메인 구성원 –등록 –인증
무선 클라이언트 인증 컴퓨터 Windows XP 내부 네트워크 도메인 구성원 –등록 –인증
IAS 서버 인증 컴퓨터 Microsoft Windows Server? 2003 내부 네트워크 도메인 구성원 –등록 –인증 –보안 채널

이 응용 프로그램에서 인증서의 사용자는 역할은 반대이지만 클라이언트는 같습니다. 예를 들어 IAS 서버가 클라이언트 인증서의 사용자가 되며 인증서를 확인해야 합니다. 보통 확인에는 인증서가 신뢰할 수 있는 루트 CA에 연결되어 있는지 클라이언트가 제공하는 서명이 클라이언트 인증서의 공개 키와 일치하는지 확인하는 작업 등이 있습니다. 또한 인증서는 해지 확인 작업을 해야 합니다. 이 주제에 관한 상세한 설명은 Troubleshooting Certificate Status and Revocation 을 참조하십시오.전체 참조는 이 장 뒷부분의* * "추가 정보" 절에 있습니다.

표 4.4. 인증서 사용자 범주

인증서 클라이언트 유형 플랫폼 위치 도메인 인증서 작업
무선 클라이언트 인증 –컴퓨터 Windows Server 2003 내부 네트워크 도메인 구성원 –확인 –해지 확인
무선 클라이언트 인증 –컴퓨터 Windows Server 2003 내부 네트워크 도메인 구성원 –확인 –해지 확인
IAS 서버 인증 –사용자 –컴퓨터 Windows XP 내부 네트워크 도메인 구성원 –확인
앞의 표에서 지원해야 하는 플랫폼과 작업 종류를 식별할 수 있습니다. WLAN 시나리오에서 항상 적용되는 것은 아니지만 사용자 환경의 다른 응용 프로그램의 경우 인터넷상에서의 클라이언트의 인증서 조회나 확인  또는 Windows가 아닌 플랫폼에서의 등록을 지원해야 합니다. 이런 사안은 대부분 디자인 프로세스 초기에 결정해야 하기 때문에 향후 인증서 요구 사항에 대해 생각하는 것이 중요합니다. 이 솔루션은 향후 요구 사항에 대해 다음과 같은 가정을 합니다. - Windows가 아닌 클라이언트에서 인증서를 확인해야 하는 경우가 많습니다. - 인터넷에서 인증서를 확인해야 할 수도 있습니다. - Windows XP 및 Windows Server 2003을 제외한 다른 플랫폼에서 인증서 주체 및 인증서 사용자 모두를 지원해야 합니다. 현재 이러한 요구 사항이 모두 디자인에서 지원되는 것은 아니지만 디자인에서 쉽게 수용할 수는 있습니다. #### 인증서 보안 요구 사항 정의 인증서 보안을 인증서의 보증 수준이라고도 합니다. 인증서 보안은 인증서의 주체를 인증서 자체에 결합하는 기준으로 간주할 수 있습니다. 인증서 보안은 해당 인증서를 사용하는 사람이나 장치가 실제로 인증서에 명명된 주체와 같음을 확신할 수 있게 해 줍니다. 보증 수준은 다음 두 가지를 위한 기준입니다. - 등록 및 인증서 등록 과정의 어려움 - 인증서를 얻기 위해 해당되는 사람이 직접 나타나 사진 ID를 제시해야 하는 경우도 있고 전자 메일 주소가 있는 것만으로 충분한 경우도 있습니다. - 개인 키를 저장하는 방법 - 키를 복사하거나 손상하기가 어려울수록 원래 소유자(인증서 주체)만 이 키를 보유하고 있다는 확신이 강해집니다. 개인 키의 소유자 신원에 대해 확실하지 않은 경우 값비싼 개인 키 보호에 투자할 필요가 없기 때문의 위의 두 가지는 매우 밀접하게 연관되어 있습니다. 마찬가지로 광범위한 배경 검사 및 DNA(deoxyribonucleic acid) 지문 검사를 비롯한 복잡한 등록 과정은 이후에 개인 키를 안전하게 보관하지 못하면 가치가 없습니다. 그러나 인증서를 높은 수준으로 유지하는 데에는 비용이 들며 대부분의 인증서 사용 시 이러한 수준의 보증이 필요하지 않은 경우가 많습니다. 인증서가 인증된 도메인 사용자에 속해 있는 경우만큼 강력한 수준의 보증이 필요하지 않은 경우에는 인증서 등록을 위한 등록 근거로 도메인 자격 증명이 적합합니다. 인증서 정책 및 방법 설명에서 사용하는 보증 수준의 의미를 문서화해야 합니다. 이 솔루션의 경우 다음 표에서 세 가지 보증 수준을 정의합니다. **표 4.5. 인증서 보증 수준**

수준 등록 요구 사항 키 저장소 요구 사항
표준 (낮음) 도메인 또는 기타 암호 기반 인증에 의존하는 자동 승인 소프트웨어 키
보통 인증서 관리자 승인, 시각적 ID 확인(스마트 카드) 또는 등록 사무소 서명 소프트웨어 키 또는 하드웨어 훼손 방지 토큰(스마트 카드 또는 USB 토큰)
높음 지정된 등록 직원 서명 및 인증서 관리자 승인 하드웨어 훼손 방지 토큰(스마트 카드 또는 USB 토큰)
각 범주 사이에 중복되는 부분이 있습니다. 이러한 범주는 엄격한 기술 분류라기보다는 정책 분류입니다. 조직의 경우 이 범주는 인증서 처리 방법에 대한 정책 결정을 기준으로 분류됩니다. 일반적으로 높은 수준의 보증이 흔하지 않은데 비해 낮은 수준의 보증은 흔하게 볼 수 있습니다. **중요:** 이 장에서는 "낮은 가치" 및 "낮은 보증" 대신 "표준 가치" 인증서 및 "표준 보증" 인증서라는 용어를 사용합니다. 전자는 부정적인 인상을 주기 때문에 "표준"이 의도하는 의미를 더 잘 반영합니다. 이전 표에 정의된 각 보증 범주를 다양한 주체 유형으로 나누면 보증 범주를 한층 더 구체화할 수 있습니다. 공통되는 범주는 다음과 같습니다. - 컴퓨터 - 조직 내에 있는 모든 컴퓨터 또는 장치에 해당합니다. - 내부 사용자 — 이는 정규 직원 또는 이와 동등하게 간주하는 직원(예: 계약 직원)을 말합니다. - 외부 사용자 - 조직 외부에 위치해 있지만 업무나 법률적인 관계를 맺고 있는 다른 모든 엔터티를 나타냅니다(예: 비즈니스 파트너 및 고객). 위와 같이 분류하는 이유는 주체 유형에 따라 적용되는 인증서 정책도 다르기 때문입니다. 인증서를 발급, 해지, 갱신하는 조건이 이러한 인증서 정책에 해당합니다. 특정 범주에 대한 인증서 계획이 없더라도 이 범주에 적용되는 인증서 정책을 문서화하여 정책과 CPS를 적절하게 준비해야 합니다. 다음 표에서는 보증 수준과 주체 범주를 결합한 결과에 대해 설명합니다. **표 4.6. 인증서 보안 범주**

인증서 보안 범주 보안 범주의 특성 예제 인증서 종류 예제
컴퓨터 인증서
높은 보증 컴퓨터 인증서 –컴퓨터 도메인 자격 증명을 기반으로 한 자동 승인 –매년 갱신 –WLAN 컴퓨터 –IPsec
보통 보증 컴퓨터 인증서 –인증서 관리자 승인이 필요함 –소프트웨어의 키 저장소 –매년 갱신 –웹 서버 –IAS 서버 인증
높은 보증 컴퓨터 인증서 –인증서 관리자 승인 –HSM(hardware security module)의 키 저장소 –인증 기관 –보안 시간 서비스 –등록 기관
내부 사용자 인증서
높은 보증 내부 사용자 인증서 –사용자 도메인 자격 증명을 기반으로 한 자동 승인 –매년 갱신 EFS 사용자
보통 보증 내부 사용자 인증서 –인증서 관리자 또는 등록 담당자 승인이 필요함 –스마트 카드 또는 소프트웨어의 키 저장소 –매년 갱신 –보안 전자 메일 –중저 가치의 재정 인증 –스마트 카드 로그온 –내부 코드 서명 –데이터 복구 에이전트 –키 복구 에이전트
높은 보증 내부 사용자 인증서 –인증서 주체의 실제 ID 확인이 필요함 –인증서 관리자 승인이 필요함 –요청 시 등록 담당자 서명이 필요함 –스마트 카드의 키 저장소 –6개월 단위 갱신 –높은 가치의 재정 인증 –상업용 코드 서명
외부(사용자) 인증서
높은 보증 외부 인증 –미리 할당된 암호를 기반으로 한 자동 승인 –매년 갱신 클라이언트 인증(인터넷 웹 사이트에 대한 인증)
보통 보증 외부 인증서 –인증서 관리자 승인이 필요함 –스마트 카드의 키 저장소 –6개월 단위 갱신 B2B(기업 간 전자 상거래) 재정 인증
높은 보증 외부 인증 –인증서 주체의 실제 ID 확인이 필요함 –인증서 관리자 승인이 필요함 –요청 시 등록 담당자 서명이 필요함 –스마트 카드의 키 저장소 –6개월 단위 갱신 매우 높은 가치의 B2B 거래
**참고:** 분류가 필요하지 않으면 만들 필요가 없습니다. 보다 간단하거나 복잡한 분류 체계가 필요할 수 있으며 모든 조합 요구가 발급하려는 인증서 종류에 해당되는 것은 아닙니다. 다양한 인증서 주체 유형을 모두 똑같이 다룰 수 없는 이유를 기술적으로 설명하는 것은 불가능합니다. 그러나 주체 유형에 따라 보안 정책을 정의하는 것이 일반적입니다. 예를 들어 내부 직원은 다른 조직의 직원과 다른 대우를 받게 됩니다. 인증서 정책의 차이 및 CPS에 따라 다르게 구체화된 인증서 정책 형태는 이러한 다양한 인증서 종류를 발급하기 위해 CA를 구성하는 방법과 관련된 의사 결정에 영향을 줄 수 있습니다. 여기에 대해서는 이 장 뒷부분에서 다룰 것입니다. 또한 위의 세 가지 인증서 사용자(또는 PKI 용어의 경우 "최종 엔터티") 범주에 발급된 인증서에 대해 같은 관리자가 최종적인 책임을 질 것인지에 대해서도 고려해야 합니다. 대부분의 조직에서 컴퓨터가 합법적인 도메인 구성원인지 인증할 수 있는 직원과 파트너 회사의 신원을 인증할 수 있는 직원은 다릅니다. CPS에 이러한 책임 관계를 문서화해야 합니다. ##### 응용 프로그램 인증서 보안 정의 이전 절에 정의된 인증서 보안 범주를 사용하여 디자인에 대한 인증서 종류를 분류할 수 있습니다. 인증서 종류는 다음 표에 나와 있습니다. **표 4.7. 인증서 보안 요구 사항**

인증서 종류 보안 범주 플랫폼 논리적 위치 승인 키 크기 유효 기간
클라이언트 인증 - 사용자 높은 보증 컴퓨터 인증서 –Windows XP –Windows Server 2003 내부 자동 (도메인 인증) 보통 보통
클라이언트 인증 - 컴퓨터 표준 보증 사용자 인증서 –Windows XP –Windows Server 2003 내부 자동 (도메인 인증) 보통 보통
IAS 서버 인증 보통 보증 컴퓨터 인증서 –Windows XP –Windows Server 2003 내부 수동 보통 보통
이와 같은 광범위한 요구 사항은 이 장 뒷부분에 나오는 "인증서 프로필 구성" 절에서 특정 인증서 프로필로 세부적으로 다루어집니다. ##### 인증서 목적 결합 하나의 인증서를 사용하여 전자 메일에 서명하고 네트워크에 로그온하며 응용 프로그램에 대한 액세스 권한을 부여할 수 있도록 여러 개의 응용 프로그램 기능(또는 용도)을 하나의 인증서로 결합할 수 있습니다. 용도를 결합하면 관리 작업과 인증서 및 디렉터리 서버의 저장소 오버헤드가 줄어듭니다. 하지만 다용도 인증서의 단점이 있습니다. 예를 들어 응용 프로그램에 따라 인증서의 승인 과정이 다를 수 있습니다. 대부분 기술적인 이유를 들 수 있지만 가장 중요한 원인은 일반적으로 응용 프로그램에 따라 필요한 인증서 보안 수준이 다르기 때문입니다. 즉, 서로 다른 보증 수준에서 인증서와 인증서 주체가 연결됩니다. 여기에는 다음 중 하나 또는 전부에 해당하는 차이점이 포함될 수 있습니다. - 인증서 승인 프로세스 - 키 길이 - 키 저장소 메커니즘 - 인증서 수명 이 때문에 인증서 용도를 같은 보안 수준과 결합하는 전략이 최선입니다. 이 솔루션에 사용된 클라이언트 인증 인증서 형식에는  IPsec 및 컴퓨터 인증과 같은 다른 표준 응용 프로그램 용도가 포함됩니다. 다른 인증서 용도의 요구 사항을 정의할 때 이를 포함시킨 다음 인증서를 재발급합니다. 이렇게 하려면 강제로 갱신해야 하며 인증서 템플릿 정의에서 작업을 시작할 수 있습니다. 하지만 IAS 서버 인증서는 보통 보증 인증서로 간주됩니다. 무허가 서버 인증서로 인한 위협은 무허가 클라이언트 인증서 위협보다 훨씬 큽니다. 따라서 서버 인증서를 더 신중하게 다루는 것이 현명하고 Microsoft는 서버 인증서에 표준 보증 응용 프로그램 사용을 통합하지 않을 것을 권장합니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 인증 기관 계층 구조 디자인 조직의 인증서 기반 응용 프로그램을 지원하기 위해서는 필요에 따라 인증서를 발급, 유효성 검사, 갱신 및 해지할 수 있는 연결된 CA 구조를 구축해야 합니다. 그러면 CA는 인증서 주체 인증, 인증서 게시, 인증서 해지 정보 게시 등과 같은 작업을 위해 기본 IT 인프라에 의존합니다. CA 인프라를 구축하면 사용자에게 안정적인 서비스를 제공할 수 있고 관리자들이 쉽게 관리 작업을 할 수 있으며 현재는 물론 앞으로의 요구 사항들을 모두 만족할 수 있는 융통성을 제공할 수 있습니다. 뿐만 아니라 CA 인프라는 조직의 보안을 최적의 수준으로 유지해 줍니다. #### 신뢰 모델 선택 CA 인프라 디자인의 첫 번째 단계는 사용자의 요구 사항에 가장 적합한 신뢰 모델을 결정하는 것입니다. 두 가지 기본 모델에는 Hierarchal Trust 및 Network Trust가 있으며 이 두 모델의 요소를 Hybrid Trust 모델에 결합할 수 있습니다. 신뢰 모델에 관한 자세한 논의는 "추가 정보" 절에서 *Windows Server 2003 Deployment Kit*의 "공용 키 구조 디자인"을 참조하십시오. 이 설명서의 솔루션은 Hierarchal Trust 모델을 사용합니다. 그 이유는 다음과 같습니다. - 오프라인 CA는 온라인 CA에 비해 높은 보안 수준으로 처리할 수 있습니다. 오프라인 CA 계층을 하나 이상 만들면 발급된 인증서의 전체적인 신뢰도가 향상됩니다. - 계층 구조는 디렉터리 없이 쉽게 작동할 수 있습니다. 이러한 특징은 내부 디렉터리에 대한 액세스 권한이 없는 외부 클라이언트를 지원하기 위한 것입니다. 네트워크 트러스트는 사용자가 신뢰 체인을 작성하기 위해 CA 교차 인증서를 조회할 수 있도록 항상 디렉터리를 요구합니다. 계층 구조의 신뢰 체인은 항상 명시적입니다. - 이 모델에서는 유지 및 클라이언트 배포를 위한 신뢰 앵커 수를 줄였기 때문에 인증서 사용자에게 루트 CA 인증서만 배포하면 됩니다. - 루트된 계층 구조를 사용하는 경우에도 다른 계층 구조와 비교 인증하여 나중에 여러 개의 신뢰 앵커(또는 루트)를 포함하기 위한 옵션이 항상 존재합니다. 즉, 디자인은 조직 병합, 부서에 따른 특수한 목적을 위한 인증서 제어 양도 등을 수용할 수 있습니다. 제안된 솔루션에서는 하나의 루트가 적합합니다. ##### 타사 대 내부 루트 여기에서는 내부 루트를 PKI를 위한 신뢰 앵커로 사용하거나 상용 CA 서비스를 사용할 수 있습니다. 타사 루트를 사용하면 발급 CA가 상용 루트 CA에 의해 인증됩니다(보통 하나 이상의 중간 CA를 통해). 따라서 발급된 모든 인증서의 신뢰 앵커는 결국 이 외부 루트 CA에 위치하게 됩니다. **참고:** 이 설명서에 명시적으로 다루지는 않지만 조직의 모든 인증서 요구 사항을 상용 CA에 아웃소싱할 수 있습니다. 온사이트 관리 서비스를 사용하거나 인증서 공급자로부터 직접 인증서를 얻을 수 있습니다. 소규모 조직이나 제한된 인증서 용도의 경우를 제외하고 이러한 방법은 대부분 재정적으로 현실성이 없습니다. 이 결정은 내부 루트를 사용하느냐 타사 루트를 사용하느냐의 문제와는 전혀 상관이 없지만 두 가지를 혼동하는 경우가 많습니다. 내부적으로 발급된 인증서에 대해 상용 루트를 사용하면 여러 가지 장점이 있습니다. - 상용 루트를 사용하면 외부인(예: 보안 웹 사이트를 방문하는 고객 또는 서명된 전자 메일을 받는 파트너 조직)이 더욱 확신을 갖고 조직과 보안 거래를 할 수 있습니다. 일반적으로 외부인들은 이미 타사 루트 CA를 신뢰하고 있기 때문에 인증서 신뢰 여부를 결정할 필요가 없습니다. - 사용 루트를 사용하여 조직은 인증서 사용과 연관된 기술, 법률, 업무상의 문제에 대한 지식을 비롯하여 전문적인 서비스 공급자의 전문 지식을 활용할 수 있습니다. 인증서 공급자가 모든 인증서를 발급하지 않는 이상 인증서 발급 및 사용 방법에 대한 책임을 져야 하며 CPS에서 이러한 내용을 문서화해야 합니다. 그러나 이러한 방식에는 다음과 같은 여러 가지 단점도 있습니다. - 일반적으로 인증서당 높은 비용이 요구됩니다. - 인증서 공급자가 상용 루트 CA에 속해 있는 모든 CA에 대해 보다 엄격한 보안 및 감사 기준을 요구할 수 있습니다. - 내부 사용자 및 장치가 인터넷에 게시된 타사 CA의 CRL에 액세스할 수 있어야 합니다. - 일부 응용 프로그램은 루트 및 중간 CA 인증서에 특정 매개 변수나 확장 프로그램이 있어야 합니다(예: Microsoft Windows 스마트 카드 로그온). 그러나 이러한 인증서를 인증서 공급자가 제공하지 않을 수도 있습니다. - 조직과 인증서 공급자 간의 상업적 계약 내용에 따라 하위 CA로부터 발급할 수 있는 인증서의 종류가 제한될 수 있습니다. 예를 들어 웹 서버 인증서는 발급할 수 없을 수도 있습니다. - 상용 루트 CA에 대한 신뢰는 조직의 보안 요구 사항과 비교해 너무 범위가 넓을 수 있습니다. 특수한 검사 또는 내부 CA의 추가 계층을 도입하여 조직에서 발급하는 인증서와 같은 루트에 역시 종속되어 있는 다른 조직에서 발급하는 인증서를 구분할 수 있습니다. 이와 같은 단점에도 불구하고 조직 밖의 사용자가 신뢰하는 인증서를 많이 발급해야 하는 경우 적어도 PKI의 일부분을 상용 루트에 종속시키는 것을 고려해야 합니다(단, 이 방법을 사용할 경우 별도의 계층 구조 두 개를 만들어야 할 수도 있습니다.). 조직에서 사용되는 대부분의 인증서의 경우 이 솔루션은 내부 루트 CA를 기반으로 하는 계층 구조를 사용합니다. 이 방식을 사용하면 다음과 같은 이점이 있습니다. - 조직이 중앙 신뢰 앵커(루트 CA)와 조직에서 발급한 인증서의 발급 및 사용을 총괄하는 보안 정책에 대한 직접적인 제어 권한을 유지할 수 있습니다. - 대다수의 인증서는 비교적 낮은 비용으로 내부 PKI에서 발급할 수 있습니다. - 발급할 수 있는 인증서 종류가 제한됩니다. - 내부 인증서와 외부 인증서 사이에는 모호성이 전혀 없습니다. - CRL 및 AIA(기관 정보 액세스) 정보를 필요에 따라 내부 또는 외부에 게시합니다. 인증서 사용자의 신뢰할 수 있는 루트를 쉽게 관리할 수 없는 경우 외부 루트 사용을 고려해야 합니다. 이 솔루션은 다음 서비스에 대해 타사 인증서 및 외부 루트 사용을 제안합니다. - 인터넷 웹 서버 - 상용 코드 서명 - 상용 문서 서명 - 외부에서 신뢰할 수 있는 보안 전자 메일 ##### 외부 인증서 신뢰 정의 이전 절에서는 다른 조직의 인증서 인프라 신뢰에 대해 다루었습니다. 인증서에 대한 신뢰가 조직에서 어떻게 제어되는지 결정하려면 이 내용을 좀더 폭넓게 고려해야 합니다. 여기서 "신뢰"라는 단어에는 다음과 같은 세 가지 중요한 조건이 있습니다. - 신뢰의 대상이 되는 사람 또는 엔터티 - 누구를 신뢰할 것인가? - 타사에 믿고 맡길 작업 또는 활동 — 어떤 일을 믿고 맡길 것인가? - 이러한 신뢰를 유지할 수 있는 기간 - 얼마나 오래 신뢰할 것인가? 인증서의 경우 "누구"는 인증서 발급 기관 이고 "무엇"은 제어하려는 용도 및 기타 인증서 특성입니다. "기간"은 루트 CA 인증서의 유효 기간이나 경우에 따라 사용자가 정의한 특수한 교차 신뢰 인증서의 유효 기간에 해당합니다. 다른 조직과 새로운 업무 관계를 수립하거나 사용자를 위한 일부 기능을 사용 가능하도록 설정할 때 외부인과의 기본 신뢰 관계를 변경해야 할 가능성이 큽니다(예: 보안 HTTP 세션을 허용하기 위해 웹 인증서를 신뢰할 경우). 이때 다음과 같은 작업을 수행해야 합니다. - 파트너 조직 또는 새로운 상용 인증서 공급자의 CA 인증서를 배포하여 사용자 일부 또는 전부가 파트너 또는 상용 CA 인증서를 신뢰할 수 있도록 합니다 - 조직 전체가 신뢰할 필요가 없는 특수한 목적을 위한 CA 또는 PKI의 CA 인증서를 조직 내에 배포합니다. - 클라이언트의 루트 저장소에서 기존 상용 루트를 교체하여 신뢰 인증서의 용도를 제안하도록 합니다. 예를 들어 전자 메일과 보안 웹 서버 인증서에 대한 특정 상용 루트만을 신뢰하고 스마트 카드 로그온 인증서의 상용 루트는 신뢰하지 않도록 결정할 수 있습니다. 다음과 같은 여러 가지 방법으로 이러한 목적을 이룰 수 있습니다. - 신뢰할 수 있는 내부 루트와 CA 인증서 사이에 정규 종속 관계를 만듭니다. 이 과정을 교차 인증이라고도 합니다. 이 과정에서는 외부 CA 인증서에 다시 서명하는 내부 CA 중 하나가 필요합니다. 이렇게 하면 외부 CA가 내부 PKI에 서명 CA의 신뢰된 하위 CA로 추가됩니다. 인증서 종류를 제한하면 인증서 용도와 정책, 주체 이름 유형, 신뢰하는 발급 정책 등을 정확하게 제한할 수 있습니다. **중요:** 정규 종속 또는 교차 인증 사안은 복잡하고 올바로 구현하기가 매우 어려운 방법입니다. 장 뒷부분의 "추가 정보" 절에서 기술 자료 *Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003*을 참조하십시오. - CTL(인증서 신뢰 목록)을 만듭니다. 이렇게 하면 신뢰된 루트 CA 목록을 정의하고 이 CA를 신뢰하는 목적(예: 보안 전자 메일)을 지정할 수 있습니다. 그런 다음 Active Directory GPO(그룹 정책 개체)를 사용하여 CTL을 배포합니다. 이 방법은 편리하지만 Microsoft에게 소유권이 있습니다. Windows 2000 이상을 사용하는 클라이언트만 CTL을 사용할 수 있습니다. 이 옵션은 CTL GPO가 적용된 도메인의 클라이언트에만 영향을 줍니다. - 루트 CA 인증서를 구성 컨테이너에 있는 Active Directory 신뢰된 인증 기관 저장소에 설치합니다. 이렇게 하면 루트 CA에 포리스트 전체의 사용자 및 장치 모두에 대해 무조건적인 신뢰가 생겨납니다. 하지만 이 형식의 신뢰를 부여할 때 매우 신중해야 합니다. 이 방법은 조직이 관리하고 있는 CA에만 사용하십시오. - 그룹 정책을 사용하여 사용자 또는 컴퓨터 하위 집합에 신뢰된 루트 CA 인증서를 배포합니다. 이 방법은 이전 옵션과 비슷하기는 하지만 어떤 대상이 신뢰된 루트를 받는지(GPO가 대상으로 하는 사용자나 컴퓨터) 구체적으로 지정할 수 있다는 점에서 다릅니다. 이 옵션은 GPO가 적용된 도메인의 사용자에게만 영향을 줍니다. - Microsoft Root Update 서비스를 사용합니다. 이 서비스는 상용 인증서 공급자가 새 루트를 여러 사람에게 쉽게 배포하도록 하기 위한 것입니다. 신뢰된 루트 CA를 직접 제어하려는 경우 조직의 모든 시스템에서 이 서비스를 제거해야 합니다. - 그룹 정책을 사용하여 타사 신뢰된 루트를 사용할 수 없도록 설정합니다. 이 목록에 있는 다른 항목과 달리 이 방법에서는 신뢰를 높이기보다 제한합니다. Windows를 실행하는 모든 컴퓨터(및 이러한 컴퓨터를 사용하는 사용자)는 기본적으로 설치된 루트 집합을 상속합니다. (이러한 특성은 다양한 플랫폼의 기타 운영 체제 및 웹 브라우저에서도 마찬가지입니다.) 그룹 정책을 사용하여 이러한 루트의 자동 신뢰를 사용하지 않도록 설정할 수 있습니다. 그런 다음 이전에 설명한 방법 중 하나를 사용하여 필요한 신뢰된 루트를 다시 추가하도록 선택할 수 있습니다. 이때 자신의 보안 요구 사항에 따라 제한을 적용하거나 적용하지 않을 수 있습니다. **참고**: 사용 안 함으로 설정할 수 없는 루트 인증서가 있습니다. 그 이유는 운영 체제가 드라이버 서명 정책과 같은 부분에 대해 이러한 루트 인증서에 의존하기 때문입니다. 이 필수 루트는 그룹 정책 설정으로 사용 안 함으로 설정할 수 없습니다. 이 솔루션에서는 CA에서 루트 인증서 업데이트 서비스를 사용할 수 없습니다. 조직의 다른 컴퓨터에서 이 서비스를 사용하지 않는 것을 고려해야 합니다. 또한 그룹 정책을 사용하여 모든 도메인 사용자에 대해 기본 타사 루트를 사용 안 함으로 설정하는 방법도 있습니다. 7장 "PKI 구현"은 이 문제를 상세하게 다룹니다. 이 솔루션에서 PKI의 루트 CA 인증서는 Active Directory에 가져오기를 통해 클라이언트에게 배포하는데 이는 다음 절에서 논의합니다. ##### 루트 CA 인증서 배포 루트 CA 인증서는 Active Directory 포리스트 구성원에게 자동으로 배포됩니다. CA 인증서를 인증 기관 컨테이너로 가져오면 포리스트에 있는 모든 도메인의 구성원(컴퓨터 및 사용자)이 해당 로컬 신뢰된 루트 CA 저장소에 이 인증서를 설치합니다. 전체 포리스트 신뢰 범위를 필요로 하는 모든 내부 루트 CA의 경우 이 방법이 권장됩니다. 또한 일반적으로 내부 루트와 함께 한층 제한된 신뢰 범위를 사용하여 루트를 배포해야 합니다. 이 주제에 관한 자세한 정보는 이 장 뒷부분의 "인증 기관 인프라 확장" 절을 참조하십시오. 다른 플랫폼 및 포리스트 외부의 사용자와 컴퓨터에 루트 CA 인증서를 배포하려면 인증서를 수동으로 설치하거나 이들에게 루트 인증서를 배포하는 다른 방법을 사용해야 합니다. #### 인증 기관 역할 정의 신뢰 모델을 정의하고 루트 CA 전략을 선택한 후 CA 인프라의 나머지 부분을 계획합니다. 그러기 위해서는 조직에서 CA가 수행하는 여러 가지 역할을 정의해야 합니다. CA를 루트 CA 또는 하위 CA로 구성합니다. 하위 CA는 발급 CA 또는 중간 CA가 될 수 있으며 발급 CA와 루트 CA 간에는 중간 신뢰 단계가 있습니다. ##### 루트 CA 루트 CA 역할은 어느 조직에서나 매우 중요합니다. 루트 CA는 조직의 모든 사용자 및 장치가 명시적으로 신뢰하는 역할입니다. 많은 보안 결정 사항(예: 로그온을 허용할지, 전자 메일을 신뢰할 수 있는지, 천 만 달러의 증권 거래를 허용할지 등)들이 최종적으로 이 루트의 보안 및 이 루트 ID를 제공하는 개인 키에 의해 좌우됩니다. 대다수의 작업이 이 루트에 의존하기 때문에 루트 키 및 인증서를 변경하면 작업이 매우 복잡해지고 오류가 발생하기 쉬워지며 오랜 기간에 걸쳐 응용 프로그램과 사용자를 위한 서비스가 주기적으로 손상을 입을 수 있습니다. 이러한 이유 때문에 루트 CA 개인 키를 최대한 안전하게 보호하는 것이 좋습니다. 최상의 보호 방법 중 하나는 네트워크에서 CA를 분리하여 액세스 권한을 극도로 제한하는 것입니다(이때 서버에 대한 실제 액세스 권한을 제한하는 방법도 함께 구현되어야 합니다.). CA 키를 보다 효과적으로 보호하는 다른 방법은 전용 HSM(Hardware Security Module)을 사용하는 것입니다. 이렇게 하면 오프라인 CA에 대한 키 보안이 강화될 뿐 아니라 온라인 CA의 보안 또한 크게 향상됩니다. 이 설명서에 정의된 솔루션은 오프라인 루트 CA를 사용합니다. **중요**: 루트 CA의 경우 HSM을 사용하여 CA 키의 보안을 강화할 수 있습니다. CA를 설치한 후 HSM을 추가할 수 있지만 처음부터 설치하는 것이 훨씬 간단하고 안전합니다. HSM을 나중에 설치하면 새 키를 사용하여 CA를 갱신해야 합니다. 그러나 대부분의 공급업체에서는 기존 키를 가져올 수 있도록 허용합니다. ##### 중간 및 발급 CA 루트 CA를 오프라인으로 사용하면 일 단위로 CA에서 인증서를 발급하는 것이 실용적이지 못합니다. 매일 사용할 수 있는 인증서를 발급하는 데 사용할 CA를 만들기 위해 루트 CA는 하위 CA가 대신 인증서를 발급할 수 있도록 인증합니다. 이렇게 하면 루트 CA 키가 보안 위협에 노출될 위험 없이 하위 CA가 루트 CA의 신뢰 정보를 상속받을 수 있습니다. 이 프로세스를 자세히 살펴 봅시다. 하위 CA는 직접 인증서를 발급하는 대신 CA의 추가 계층을 인증하여 최종 엔터티(사용자 및 컴퓨터)에 인증서를 발급합니다. 이렇게 하면 루트 CA 키에 추가 보안 계층이 제공될 뿐 아니라 하위 CA 분기 간에 발생할 수 있는 위험을 차단할 수 있습니다. 예를 들어 중간 CA 하나가 내부 발급 CA를 인증하는 동안 또 다른 중간 CA가 외부 인증서를 발급하는 CA를 인증할 수 있습니다. 이 방법은 다음과 같은 장점이 있습니다. - 전체 PKI 계층 구조의 일부분에 대한 CA 손상 위협을 제한할 수 있습니다. - CA 계층 구조의 전체 분기에 대해 별도의 인증서 정책을 구현할 수 있습니다. - CA 키를 사용해야 하는 횟수가 줄어들어 키가 손상될 확률이 줄어듭니다. 중간 CA의 추가 계층이 PKI의 전체적인 보안을 향상시키기는 하지만 더욱 복잡해진 구조와 관리 오버헤드와 같은 문제를 초래할 수 있습니다. 이로 인해 드는 비용은 하드웨어 또는 소프트웨어 라이센스 비용에 비해 훨씬 높습니다. 따라서 대부분의 응용 프로그램은 어떤 보안 요구 사항도 3 계층 구조를 사용할 수 없습니다. CA 키가 HSM에 의해 보호되는 경우 특히 그렇습니다. 본 설명서의 솔루션에서는 2 계층 구조를 제안합니다. 솔루션 디자인은 뛰어난 보안과 경제성의 균형을 잘 맞추는 동시에 향후 인증서 응용 프로그램 사용을 위한 유연성도 보장합니다(예는 장 앞부분의 "인증서 요구 사항 정의" 절의 상세한 설명 참고). **참고:** 3 계층 구조를 사용해야 하는 관리 또는 규제 요구 사항에 관한 논의는 본 설명서의 범위를 벗어납니다. 물론 이 요구 사항은 다른 고려 사항에 우선합니다. ##### 제안된 CA 계층 구조 다음 그림은 제안된 계층 구조를 나타냅니다. 현재 구현 방식은 루트 CA와 발급 CA 하나로 이루어져 있습니다. 발급하는 CA는 주로 컴퓨터 또는 사용자에 대해 표준 보증("기술"이라고도 함) 인증서를 발급하고 컴퓨터에 대해 높은 가치 인증서를 발급합니다. [![](images/Dd547898.04fig4-2(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/dd547898.04fig4-2_big(ko-kr,technet.10).gif) **그림 4.2 인증서 인증 기관** 이 디자인에서는 비교적 낮은 하드웨어, 소프트웨어 경비와 낮은 관리 비용으로 무선 LAN 인증(802.1X) 보안을 지원할 수 있는 완전한 기능의 PKI를 배포할 수 있습니다. **참고:** 이 단순한 인프라 디자인을 여러 가지로 확장하여 다양한 요구 사항을 수용합니다. 이 문제는 "CA 인프라 확장" 절에 설명되어 있습니다. 발급 CA는 다음과 같은 인증서 종류를 발급하도록 초기에 구성됩니다(인증서 종류는 위 그림의 굵은 상자 안에 표시되어 있습니다.). - 클라이언트 인증 - 사용자 - 클라이언트 인증 - 컴퓨터 - IAS 서버 인증 처음 두 가지는 표준 보증 인증서로 사용자 또는 컴퓨터의 도메인 자격 증명을 기반으로 자동으로 발급됩니다. 이와 같은 인증서가 있는 경우 올바른 도메인 사용자 이름과 암호가 있는 경우에 비해 밀접하게 연결되어 있지 않은 것으로 나타납니다. 하지만 도메인 이름 및 암호 대신 인증서를 사용하면 보안 및 기타 기술상의 이점이 있습니다. IAS 서버 인증은 IAS 서버가 수준 높은 보안 기능을 수행하기 때문에 보통 보증 인증서로 분류됩니다. 이러한 종류의 인증서 발급에는 일반적으로 요청의 유효성 추가 검사가 포함되며 인증서 관리자 승인이 필요합니다. **참고:** 이 인증서 종류를 만들기 위한 구축 관련 장에서 인증서 관리자 승인에 대한 요구 사항은 사용하지 않는 것으로 되어 있습니다. 따라서 IAS 서버에서 자동으로 만료 인증서를 갱신할 수 있으며 인증?서가 만료되더라도 서비스가 중단되는 것을 막을 수 있습니다. 인증서 요청을 올바르게 검사 및 승인하기 위한 적절한 프로세스가 있는 경우 인증서 관리자 승인을 위한 요구 사항을 사용할 수 있도록 설정하는 것이 좋습니다. ##### CA의 하드웨어 및 소프트웨어 요구 사항 이 절에서는 CA의 하드웨어 및 소프트웨어 요구 사항에 대해 다룹니다. ###### 루트 CA 루트 CA는 최소한의 하드웨어 사양을 요구합니다. 컴퓨터 사양은 Windows Server 2003을 실행할 수 있는 최소 요구 사항 이상일 필요가 없습니다. 루트 CA 하드웨어의 가장 중요한 특성은 장기적인 안정성 및 관리 편의성입니다. 루트 CA는 일반적으로 수명은 길지만 대부분 시간 꺼져 있는 컴퓨터에 상주합니다. 하지만 컴퓨터가 *켜질 때는* 안정적으로 시작해야 합니다. 하드웨어 오류에 대처하기 위해 컴퓨터 모델이 단종된 후 수년이 지나도 구성 요소를 쉽게 교체할 수 있어야 합니다. 이 고려 사항을 염두에 두고 Microsoft는 다음을 권장합니다. - 지원 및 장기적인 하드웨어 유지 보수 경력을 지닌 유명 컴퓨터 제조업체를 선택합니다. 제조업체에서 예비 부품을 구할 수 있는 기간에 대해 문의합니다. - 워크스테이션이나 휴대용 컴퓨터 하드웨어 대신 서버를 사용합니다. 서버는 대개 표준화되어 있고 자주 변경되지 않습니다. - 하드웨어가 고장을 일으켜 짧은 시간 내에 수정이 불가능한 경우를 대비해 루트 CA 역할을 대신할  예비 시스템을 마련해 두는 것이 좋습니다. - 오류가 발생할 경우 시스템을 재구축할 수 있도록 원본 설치 미디어, 드라이버 및 패치의 복사본을 보관합니다. - 추가 보안을 위해 HSM을 사용합니다. 루트 CA는 Windows Server 2003의 Enterprise Edition의 추가 기능이 필요하지 않습니다. 따라서 본 설명서의 솔루션은 Windows Server의 Standard Edition을 사용합니다. ###### 발급하는 CA 발급하는 CA에 대한 성능 요구 사항이 있기는 하지만 CA가 수행하는 작업이 매우 적기 때문에 이러한 요구 사항의 수준이 비교적 낮습니다. 많은 작업을 수행하는 경우에도 성능 평가에 따르면 Enterprise CA에서는 보통 CA 자체가 아닌 Active Directory와의 상호 작용이 제약이 된다고 합니다. 따라서 하드웨어 성능 요구 사항의 수준은 그다지 높지 않습니다. 루트 CA에서와 마찬가지로 하드웨어 선택 시 안정성과 관리 편의성이 중요한 요소로 작용합니다. 인증서 서비스는 Active Directory와 같은 데이터베이스 기술을 사용하므로 동일한 성능 지침이 대부분 적용됩니다. 따라서 이 경우 대부분의 조직에서 Active Directory 도메인 컨트롤러에 대한 하드웨어 사양과 같은 사양을 사용하는 것이 좋습니다. CA 성능에 대한 자세한 내용은 이 장 뒷부분에 소개된 "Designing a Public Key Infrastructure" 장의 "CA Capacity, Performance, and Scalability" 절을 참조하십시오. 7장 "공용 키 구조 구현"에서 제시된 하드웨어 프로필을 제공합니다. 루트 CA에 대한 지금까지의 지침 외에도 Microsoft는 발급하는 CA에 서버 하드웨어를 지정할 경우 다음 사항을 고려할 것을 권장합니다. - NIC 팀을 사용하는 중복 NIC(네트워크 인터페이스 카드) - 두 개의 RAID 1(redundant array of independent disks) 볼륨이 CA 로그를 별도의 물리적 저장소에 저장하기 위한 최소의 권장 요구 사항입니다. 성능 면에서 추가적인 이점을 얻을 수 있을 뿐 아니라 하드웨어 고장 시 복원력이 향상됩니다. - 두 개가 아닌 세 개의 RAID 1 볼륨을 사용하면 별도의 볼륨에 운영 체제, 인증서 서비스 데이터베이스, 인증서 서비스 로그를 각각 저장하여 더 뛰어난 성능을 발휘할 수 있습니다. - IDE(integrated device electronics)보다는 고성능 SCSI(small computer system interface) 드라이브 및 컨트롤러가 성능 및 복원력 면에서 뛰어나기 때문에 SCSI를 사용하는 것이 좋습니다. Active Directory와의 상호 작용을 차치하고 디스크 하위 시스템의 성능이 전체적인 CA 성능을 결정하는 데 가장 중요한 요소가 될 수 있습니다. - HSM을 사용하면 인증서 발급 중에 작업을 서명할 때 보안 및 성능이 향상됩니다 루트 CA와 달리 발급하는 CA는 편집 가능한 인증서 템플릿 및 사용자 인증서 자동 등록을 지원하기 위해 Windows Server 2003 Enterprise Edition 기능이 추가로 *필요합니다*. ###### 서비스 복원력을 위해 여러 개의 발급 CA 사용 이 절에서는 발급 CA를 여러 개 설치해야 하는 기술적인 이유를 설명합니다. 등록하는 인증서 종류에 따라 다른 발급 CA를 사용해야 하는 보안 및 정책 상의 이유도 있습니다. 보안 및 정책상의 이유는 이 장 뒷부분에서 다룹니다. 하드웨어 사양이 낮은 발급 CA 한 대면 수만개 클라이언트에 앞에서 기술한 인증서를 발급하는 데 적합하기 때문에 성능 이유만으로 여러 발급 CA가 필요한 경우는 거의 없습니다. 그러나 발급 CA의 가용성 요구 사항 때문에 같은 형식의 인증서를 등록하기 위해 여러 CA를 배포해야 하는지 고려해야 합니다. CA에는 가용성과 관련하여 다른 여러 서비스에서 제기된 문제점이 존재하지 않습니다. 인증서를 사용하거나 확인하기 위해 클라이언트가 CA에 연결하지 않아도 됩니다. CA가 다음 작업을 해야 할 경우에만 클라이언트가 직접 CA와 접촉해야 합니다. - 새 인증서 등록 - 인증서 갱신 - 인증서 해지 - 새 CRL 게시 - CA 인증서 자체 갱신 각 작업에 대한 가용성 요구 사항이 다음 표에 자세하게 설명되어 있습니다. **표 4.8. CA 서비스 가용성 요구 사항**

CA 서비스 가용성 요구 사항
등록 서비스 — 새 인증서 새로운 사용자가 네트워크나 인증서를 요구하는 서비스에 액세스하지 못하도록 하기 때문에 중요한 요소입니다. 백업에서 CA를 복구하는 데 필요한 시간이 조직에서 새로운 사용자가 인증서를 등록하는 데 걸리는 시간보다 긴지 평가해야 합니다. 대부분의 조직은 CA가 복구될 때까지 기다리는 비용이 추가 CA 관리 비용보다 낮다고 판단합니다. 그렇지 않으면 관련 인증서 형식에 여러 발급 CA가 필요합니다.
등록 서비스 — 인증서 갱신 해당 인증서 종류에 자동 갱신이 사용되면 이전 인증서가 만료되기 6주 전에 기본적으로 자동 갱신이 실행됩니다. 반대로 CA의 백업으로부터 복구 시간은 보통 시간 단위로 측정합니다. 수동으로 갱신된 인증서의 갱신은 소유자가 수행합니다. 중요한 인증서를 갱신할 날짜가 되면 소유자에게 이 사실을 알리는 자동화된 경고 시스템을 도입할 수 있습니다. 그렇지 않으면 가용성 기준이 새 인증서를 등록할 때와 같아집니다.
인증서 해지 인증서는 보통 인증서를 발급한 CA에 의해서만 해지할 수 있습니다. 다른 CA는 불가능합니다. 해지하는 시기가 특히 중요한 경우(CA를 복구하기 전에 해지해야 하는 경우) 해지할 인증서의 일련 번호와 다른 컴퓨터로 복원된 CA 개인 키가 있다는 가정 아래 현재 CRL에 해지 항목을 삽입할 수 있습니다. CRL에는 보통 하루 이상의 대기 시간이 있습니다. CA의 복구 시간이 다음 CRL 게시까지 걸리는 시간보다 길지 않은 이상 CRL을 수동으로 업데이트하는 것은 도움이 되지 않습니다.
CRL 게시 CRL은 CA에만 해당되며 두 번째 CA로 인해 CRL 게시 복원력이 높아지지는 않습니다. 다만 CRL 게시 실패로 인해 받는 영향을 최소화합니다(발급된 인증서 전부가 실패한 CRL에 의존하지 않기 때문). 현재 해지 상태에 대한 액세스 권한은 많은 인증서 응용 프로그램에 필수적입니다. 즉, 아직 만료되지 않은 CRL을 게시된 CDP(CRL 배포 지점)에서 사용할 수 있어야 합니다. 그렇지 않으면 해지에 민감한 인증서 응용 프로그램이 중단됩니다. CA 복구 기간은 이전 CRL이 만료되고 새 CRL이 발급되는 사이에 중복되는 시간보다 길어서는 안 됩니다. 아주 드물게 길어지는 경우 CRL을 다시 서명하여 유효 기간을 연장할 수 있습니다. 이 절차는 운영 설명서에 나와 있습니다.
CA 인증서 갱신 두 번째 발급 CA는 이 경우 도움이 되지 않습니다. 나중에 CA의 복구 시간이 문제가 되도록 하려면 이 작업을 중단해서는 안 됩니다. 복구 시간이 문제가 되더라도 부모 CA 키로 CA 인증서를 다시 서명하여 유효 기간을 늘일 수 있습니다.

참고: 위의 표에서 CA 복구 시간 및 CA 가용성은 최종 사용자에게 서비스를 제공하는 CA 기능에 영향을 주는 모든 요구 사항을 참조한 것입니다. 이상은 서버 오류에만 해당되는 내용이 아닙니다. 실제로 사이트 사이의 네트워크 정지를 서비스 실패의 가장 큰 원인으로 예를 들 수 있습니다. 필요한 서비스 가용성 수준을 결정할 때 사용자에게 제공되는 서비스에 영향을 줄 수 있는 모든 요소를 고려해야 합니다.

CA 백업 및 복구를 효과적으로 관리하는 이상 등록 및 일부 갱신 요구 사항만이 서비스 복원력을 위해 여러 개의 CA를 사용하는 것과 관련된 결정에 영향을 줍니다. 이러한 서비스를 사용할 수 없음에 따른 비용 부담과 추가 CA를 제공함에 따른 설치 및 관리 비용을 비교 검토해야 합니다.

발급 CA를 여러 대 사용하면 가용성을 개선할 뿐 아니라 인증서 발급 성능을 높이고 CRL 크기를 반으로 줄입니다. 이 설명서의 솔루션에서는 이 요소들이 중요하지 않습니다. 이 솔루션은 CA를 신중하게 관리하고 적절한 백업 및 복구 절차를 포함시켜 복원성 문제를 다룹니다. 이런 이유로 솔루션에는 한 대의 발급 CA만 있으면 됩니다.

HSM을 사용하여 CA 키 보호

설명서에 소개된 기본 솔루션의 보안을 향상시키기 위해 HSM을 사용하여 모든 CA의 개인 키를 보호할 수 있습니다. HSM 사용은 CA 서버보다 비용이 많이 들지만  사용 환경의 보안 수준은 상당히 높아집니다. 이 방법을 사용하면 CA 키 작업에 대한 액세스를 권한이 있는 사용자에게만 제한할 수 있습니다. 민감한 작업(예: CA의 내보내기 및 백업)은 일반적으로 여러 스마트 카드로 보호됩니다. 이 방법은 소프트웨어 기반 키만 사용하는 것보다 안전한데 로컬 Administrators 또는 Backup Operators 그룹 구성원에 의해 CA에서 복사됩니다.

HSM의 수많은 보안 이점 뿐 아니라 CPU에서 전용 암호화 가속 프로세서로 작업을 오프로드하여 CA 작업 속도도 높입니다.

CA 보안

이 절에서는 운영 체제 및 실제 보안, 보안 감사 및 모니터링, CA에 대한 관리 의무를 위임하는 역할 사용 등 CA 보안에 대해 살펴봅니다.

운영 체제 보안

CA는 Windows 보안 정책에 의해 보호됩니다. 설정은 Windows Server 2003 Security Guide의 인증 기관 서버 역할을 기반으로 합니다.

이 역할에 사용되는 설정에 관한 세부 정보는 7장 "공용 키 구조 구현"을 참조하십시오.

루트 CA의 보안 설정은 보안 템플릿을 사용하여 직접 적용하는 반면 발급 CA 설정은 그룹 정책을 사용하여 적용합니다.

실제 보안

CA 서버의 실제 보안은 최고의 수준을 자랑합니다. 서버에 대한 기본적인 실제 액세스 권한을 제어할 수 있어야만 효과적인 네트워크 또는 운영 체제 보안이 가능합니다.

루트 CA는 서버에 대한 액세스 권한이 엄격하게 제어되는 위치에 있어야 합니다. CA에 액세스해야 하는 경우는 거의 드물며(연간 2-3회 정도) 이 경우 외에는 서버의 전원을 켜지 않아도 됩니다. 즉, 서버실의 표준 컴퓨터 기능을 가지고 있지 않은 안전한 저장실에 서버를 보관할 수 있다는 뜻입니다. (예를 들어, 저장실은 네트워킹, 정교한 서버 성능 또는 특수한 전원 및 온도 관리가 필요하지 않습니다.)

발급 CA 또한 물리적 액세스가 엄격하게 제어되는 위치에 저장해야 합니다. 공격자가 컴퓨터 시스템에 물리적으로 접근할 수 있는 경우(네트워크상에서 발생하는 공격 외에) 해당 컴퓨터 시스템을 다양한 방법으로 손상시킬 수 있으므로 물리적 보안이 중요합니다. 이 서버는 항상 온라인 상태로 있어야 하기 때문에 일반적인 컴퓨터 서버실 기능(온도 제어, 전원 관리, 통풍 및 소방 시설)이 있는 곳에 보관해야 합니다.

가능하면 두 서버 모두 화재, 홍수 등과 같은 외부의 위험에서 최대한 벗어난 위치를 선택합니다.

실제 액세스 권한을 제어하는 것만큼 백업, 키 자료 및 기타 구성 데이터의 실제 보안을 보장하는 것도 중요합니다. 이러한 정보는 자연 재해나 화재 등으로 인해 전체 사이트를 사용할 수 없게 되는 경우 CA의 복구를 가능하게 하기 위해 서버와는 다른 위치에 저장해야 합니다.

CA의 보안 관리

인증서 인프라는 잠재적으로 매우 높은 가치의 자산입니다. 그 가치의 정도는 조직에서 현재를 비롯해 앞으로 5년 이상의 기간 동안 인증서를 어떤 용도로 사용하는지에 따라 달라질 수 있습니다. 이러한 점 때문에 다른 IT 인프라를 설치할 때 사용하는 보안 및 확인 기준보다 엄격한 기준을 사용하여 CA 설치, 구성 및 관리를 수행해야 합니다. CA에는 도메인 컨트롤러 기준과 같거나 높은 기준을 적용해야 합니다. 이보다 높은 수준의 보안이 필요한 경우도 있습니다.

CA가 안전하게 설치 및 관리되고 있다고 확신하는 정도에 따라 CA에 대한 신뢰가 달라질 수 있습니다. CA의 개인 키가 부정적으로 복사되지 않았음을 보장할 수 없으면 해당 CA가 발급하는 인증서가 위조된 인증서가 아님을 신뢰할 수 없습니다.

이러한 보증 수준과 신뢰도는 처음부터 이와 같은 특수한 상태로 CA를 처리하지 않는 이상 쉽게 향상될 수 없습니다. 예를 들어 CA에 대한 모든 액세스가 정당하다는 감사 내역이나 기타 근거가 있으면 CA 개인 키가 손상되지 않았다는 조직의 확신이 훨씬 커집니다. 예를 들어 CA이 모든 관리 작업을 관리자 외의 사용자가 감시하거나 비디오로 기록합니다. 오프라인 CA의 경우 네트워크에 연결한 적이 없다는 사실이 네트워크 손상 가능성을 크게 줄여줍니다.

이와 같은 높은 수준의 보증은 조직이 발급된 인증서의 유효성에 대한 법적 문제에 직면했을 때 특히 중요합니다. 이러한 경우 CA가 손상되지 않았다는 증거가 있으면 이러한 법적 상황에서 승소할 가능성이 높아집니다. 이 문제에 관한 상세한 논의는 이 설명서의 범위를 벗어나므로 자세한 내용은 감사자 및 법률 고문에게 문의해야 합니다.

CA의 보증 수준을 크게 높이기 위해 수행할 수 있는 단계는 다음과 같습니다.

  • CA의 실제 보안을 보장하여 인증되지 않은 개인이 CA 하드웨어나 백업 미디어에 액세스할 수 없도록 합니다.

  • 증인이 있는 상태에서 모든 설치 및 구성 단계를 수행하여 중요한 설치 단계를 기록하고 이러한 단계가 성공적으로 수행되었음을 확인하는 서명을 증인에게 받아내도록 합니다. (아니면 설치 과정을 비디오 테이프로 녹화하여 이 테이프의 사본을 제 3자에게 맡길 수도 있습니다.)

  • 루트 CA에 대한 모든 인증서 발급 및 해지 작업을 유사한 조건에서 수행합니다. 가능하면 루트 CA에 대한 모든 액세스 내역을 증명할 수 있어야 합니다.

  • CA에 대한 관리 액세스 권한이 있는 모든 사람에게 추적 가능한 개별적인 계정이 있는지 확인합니다. CA의 모든 작업에 대한 감사를 수행합니다.

  • CA에 대한 역할 분담을 사용할 수도 있습니다. (이 장 뒷부분에서 상세하게 논의합니다.)

이상의 방법은 루트 CA 서버에서 특히 중요합니다. 발급 CA의 보증 수준은 발급해야 하는 인증서의 종류에 따라 다른 CA보다 훨씬 낮을 수 있습니다. 예를 들어 CA가 높은 가치의 인증서를 발급하지 않으면(컴퓨터 및 사용자 네트워크 인증과 같은 표준 인증서만 발급할 경우) 이 CA에 도메인 컨트롤러에 사용하는 것 이상의 보안을 적용할 필요가 없습니다.

루트 CA의 보안 수준이 높은 경우 더 높은 수준의 발급 CA를 추가하여 나중에 더 높은 가치의 인증서를 발급할 수 있습니다. 기존의 표준 보증 CA와 함께 높은 보증 CA를 유지 관리할 수 있습니다. 하지만 비교적 낮은 보안 환경에 루트 CA를 설치 및 구성하고 나서 이후에 높은 가치의 인증서를 발급하려고 하면 루트 CA를 다시 설치하거나 새로운 루트 CA를 만들어야 합니다.

보안 모니터링 및 감사

운영 체제 및 인증 서비스 감사는 모든 CA에서 사용됩니다. 효율을 높이기 위해 감사 및 조금이라도 수상한 항목은 모니터링해야 합니다. 인증서 서비스 감사 이벤트 항목의 중요성에 대한 논의는 11장 "공용 키 구조 관리"를 참조하십시오.

관리 역할

인증서 서비스는 관리 역할의 위임에 관한 상당한 제어권을 제공합니다. 이 솔루션은 이 기능을 활용하여 PKI를 매우 융통성 있게 관리할 수 있는 방법을 제공합니다. 인증서 서비스가 정의하는 각각의 핵심 관리 역할을 도메인 보안 그룹이나 오프라인 CA의 경우 로컬 보안 그룹을 사용하여 구현했습니다. 또한 두 가지 이상의 역할과 보안 그룹을 정의하여 Active Directory의 PKI 구성 요소에 대한 관리 임무를 위임할 수 있도록 도와 줍니다.

이러한 역할과 조직 내 다른 IT 직원 사이에 반드시 일대일 매핑이 존재하는 것은 아니라는 사실을 이해할 필요가 있습니다. 대부분의 조직에서는 한 명의 직원이 여러 가지 역할을 수행합니다. 다음 표에 나와 있는 보안 그룹 하나 또는 전부에 해당 직원을 추가하여 역할을 쉽게 구현할 수 있습니다. 반대로 조직이 관리 책임을 더 복잡하게 세분화한 경우 이미 이를 구현하기 위한 기능이 있습니다.

보안 그룹에 대해 구현된 역할과 해당 매핑이 다음 표에 나와 있습니다.

표 4.9. 핵심 인증서 서비스 역할

역할 이름 보안 그룹 범위 설명
Enterprise PKI Administrator Enterprise PKI Admins Active Directory 포리스트 PKI를 담당하며 회사의 인증서 종류, 응용 프로그램 정책, 신뢰 경로 등을 정의합니다.
Enterprise PKI Publisher Enterprise PKI Publishers Active Directory 포리스트 신뢰된 루트 인증서, 하위 CA 인증서 및 CRL을 디렉터리에 게시합니다.
CA Administrator CA Admins CA CA 구성을 담당합니다. Enterprise PKI Administrator 및 Administrator 역할 담당자와 동일한 경우가 많습니다. 인증서 사용법에 규정되어 있는 경우 다양한 CA 관리자가 다양한 CA를 담당할 수도 있습니다.
Administrator Local Administrators CA CA 운영 체제 및 서버를 관리합니다. CA 설치 및 CA 인증서 갱신을 담당합니다. 일반적으로 CA Administrator와 역할을 공유합니다.
CA Auditor CA Auditor CA CA의 감사 대상 이벤트의 감사 이벤트 로그 및 정책을 관리합니다.
Certificate Manager Certificate Manager CA 수동 승인이 필요한 인증서 요청을 승인하고 인증서를 해지합니다. 인증서 사용법에 규정되어 있는 경우 다양한 CA의 승인을 담당하는 여러 인증서 관리자가 있는 경우도 있습니다.
등록 기관 또는 등록 담당자 정의되지 않음 인증서 프로필 인증서 관리자 역할을 확장한 것입니다. out-of-band ID 확인 후 인증서 요청을 승인하고 서명하는 것을 담당합니다. 직원, IT 프로세스 또는 장치(예: 지문 스캐너 및 데이터베이스)가 될 수 있습니다. 인증서 프로필(템플릿)에 따라 여러 등록 기관을 지정하고 여러 CA를 적용할 수 있습니다.
키 복구 에이전트 정의되지 않음 CA CA 데이터베이스에 보관된 개인 키를 해독하는 키를 보관합니다.
CA Backup Operator CA Backup Operator CA CA 서버의 백업과 복구 및 백업 미디어를 안전하게 저장하는 업무를 담당합니다.
이러한 보안 그룹은 도메인 유니버설 그룹으로 구현되며 발급 CA 및 디렉터리에 적용됩니다. 루트 CA의 경우 동일한 그룹이 로컬 그룹으로 구현됩니다. 단, 오프라인 CA에 대한 Enterprise PKI Admins 및 Enterprise PKI Publishers에는 동일한 그룹이 존재하지 않습니다. 이 솔루션에서는 같은 보안 그룹이 회사 내에 있는 모든 CA에서 사용된다고 가정합니다. 이러한 가정이 자신의 조직에 해당되지 않은 경우에는 CA 범위 내의 모든 역할에 대한 각 CA에 대해 별도의 그룹을 구현해야 합니다. 그룹 이름은 알맞게 바꿔야 합니다(예: CA Admins - Issuing CA 1). 이 솔루션에는 등록 기관(또는 등록 직원)과 키 보관 및 복구가 구현되지 않았으므로 이와 같은 역할에는 정의된 보안 그룹이 없습니다. CA에 대한 CA 역할을 구분할 수 있습니다. 역할 구분을 사용하면 하나 이상의 역할 그룹의 구성원인 사용자 모든 역할 그룹 권한에 액세스할 경우 거부됩니다. 역할 구분은 이 솔루션에 구현되어 있지 않습니다. ##### Active Directory 통합 CA는 Enterprise 모드(또는 Active Directory 통합) 또는 독립 실행형 모드 중 하나로 설치할 수 있습니다. 이 두 모드의 주요 차이점 중 Enterprise CA에 해당되는 내용은 다음과 같습니다. Active Directory를 사용하여 구성 정보를 저장하고 Active Directory를 등록 기관으로 사용할 수 있으며 발급된 인증서를 디렉터리에 자동으로 게시할 수 있습니다. 독립 실행형 CA는 인증서와 CRL을 디렉터리에 게시할 수 있지만 Active Directory에 의존하지 않습니다. 이 부분에 대한 상세한 설명을 제공하는 리소스를 보려면 이 장 뒷부분의 "추가 정보" 절을 참조하십시오. 오프라인이기 때문에 루트 CA를 독립형 서버로 구성할 수 밖에 없습니다. 환경에 오프라인 중간 CA를 배포하려는 계획을 세운 경우에도 마찬가지입니다. 발급 CA는 다음과 같은 이유로 Enterprise CA로 구성됩니다. - 이 솔루션에서 사용되는 인증서 종류의 경우 인증서 자동 등록 및 자동 승인이 필요합니다. - 또한 인증서 템플릿이 필요합니다. 인증서 템플릿을 사용하면 여러 개의 CA 전체에서 다양한 인증서 종류를 쉽게 관리할 수 있으므로 많은 이점을 얻을 수 있습니다. - IAS에서는 신뢰된 인증서 매핑을 수행하여 무선 클라이언트를 인증합니다. 이를 위해서는 NTAuth 저장소에 CA가 등록되어 있어야 합니다. - 해당 사용자나 컴퓨터 개체에 인증서를 자동으로 게시할 수 있습니다(이 솔루션에서는 필요하지 않음). - CA에서는 인증서 요청 및 발급된 인증서에서 사용하기 위한 주체 이름 정보를 얻을 수 있도록 신뢰할 수 있는 원본이 필요합니다. Active Directory는 디렉터리에 저장되어 있는 사용자 및 컴퓨터 특성으로부터 이러한 원본을 제공합니다. - 향후에 스마트 카드 로그온 인증서가 필요할 수도 있습니다. 이는 엔터프라이즈 CA를 사용하여 구현하는 것이 훨씬 쉽습니다. **참고:** 이 기능은 엔터프라이즈 CA에 기본적으로 제공되지만 올바로 구성된 독립 실행형 CA에서 제공할 수도 있습니다. 이는 인증서 서비스 제품 설명서에 더 상세하게 나와 있습니다. (이 장 끝에 나오는 참조를 확인하십시오.) ###### 도메인에 CA 설치 조직에 여러 개의 도메인 포리스트나 포리스트가 있는 경우 CA를 설치할 도메인을 결정해야 합니다. 이러한 결정에 영향을 주는 여러 가지 요소 중에는 여러 도메인 관리자에 대한 제어를 위임해야 할 필요성이나 조직의 다양한 부서에서 인증서 서비스를 제공하는 데 영향을 미치는 국가 또는 지역 법률이 있습니다. 가장 일반적인 방법은 CA를 포리스트 루트 도메인이나 관리 전용 도메인에 설치하는 것입니다. 오랜 기간 동안 안정적인 상태를 유지할 수 있는 도메인에 CA를 설치해야 합니다. (CA의 이름, 도메인 구성원 및 DNS 도메인 이름은 설치 후 변경할 수 없습니다.) 또한 컴퓨터 계정의 보안이나 무결성을 보장할 수 없는 도메인에 CA를 설치해서는 안 됩니다. 중앙 집중화된 관리가 더 쉬울지 모르지만 CA를 동일한 도메인에 설치할 필요는 없습니다. 이 솔루션에서는 CA 서버 계정(Enterprise 발급 CA만)을 포리스트 루트 도메인이나 도메인이 단일 도메인 포리스트인 경우 이 도메인에 설치합니다. ##### 인증서 방법 설명을 CA로 매핑 CPS를 게시하려는 경우 이 CPS의 범위를 결정해야 합니다. 전체 CA 계층 구조 또는 부분 CA 계층 구조에 대해 CPS를 만들거나 CA 하나당 하나의 CPS를 만들 수 있습니다. 두 번째 옵션이 가장 융통성 있는 방법이기는 하지만 여러 개의 CPS를 관리해야 함에 따라 오버헤드가 증가합니다. 표준적인 방법은 각 CA에 대해 별도의 CPS를 만들거나 인증서 정책이 같은 CA 그룹, 주체 유형, 보안 수준에 대해 별도의 CPS를 만드는 것입니다. CA에 따라 크게 다르기는 하지만 여러 개의 CPS를 사용해야 하는 경우가 있습니다. 복원력이나 성능적인 이유로 여러 개의 동일한 CA가 있는 경우에는 물론 CPS도 같아야 합니다. 앞에 설명한 것처럼 CPS를 만들기만 하고 게시하지 않아야 합니다. 예를 들어 CPS에 내부적인 운영 및 보안 정보가 들어 있다고 판단되면 CPS를 외부적으로 게시하지 않는 것이 좋습니다. 내부 운영에 관한 자세한 정보는 노출시키지 않고 CA의 중요한 운영 정책을 나열하는 CPS의 간략화된 버전만 게시하도록 할 수도 있습니다. CA 인증서에 액세스할 수 있는 양식으로 CPS를 게시하려는 경우 공식 ISO(국제 표준화 기구)에서 조직에 할당한 OID(개체 식별자) 네임스페이스에서 인증서 정책의 OID를 가져와야 합니다. 조직마다 고유한 인증서 정책이 있기 때문에 CPS를 식별하기 위해서는 전체적으로 고유한 OID가 필요합니다. 이 CP OID는 조직의 인증서 각각에 인증서 확장으로 인코딩됩니다. "*인증서 확장*"은 일종의 인증서 데이터 필드입니다. URL은 인증서를 발급한 CA의 CPS를 가리키는 확장 일부로 포함됩니다. 인증서의 목적이나 출처를 나타내는 텍스트 형식의 사용자 알림이 포함되는 것이 일반적입니다. 이러한 알림은 200자로 제한되므로 별도의 CPS 문서를 만드는 방법의 대안이 될 수 없습니다. 인증서 정책 OID 및 CPS URL이 인증서에 인코딩되는 방식에 관한 상세한 논의는 이 장 뒷부분의 "추가 정보"의 RFC 3280 *인터넷 X.509 공용 키 구조 인증서 및 CRL 프로필*을 참조하십시오. CP OID를 얻고 CPS를 게시할 URL을 결정한 다음에는 CA 인증서에 사용자 알림을 포함시킬 수 있습니다. 7장 "공용 키 구조 구현"에서 이 절차를 다룹니다. #### IT 인프라 지원 이 솔루션의 PKI는 다른 인프라 서비스를 사용하여 동작합니다. 다음 다이어그램은 주요 서비스(Active Directory 및 IIS) 및 이들이 CA 및 인증서 클라이언트와 상호 작용하는 방식을 나타냅니다. [![](images/Dd547898.04fig4-3(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/dd547898.04fig4-3_big(ko-kr,technet.10).gif) **그림 4.3 CA와 IT 인프라 간의 상호 작용** 그림에는 나오지 않지만 모니터링, 경고 및 관리 인프라는 인증서 서비스 운영에 매우 중요합니다. 11장 "공용 키 구조 관리"에서 이 인프라를 더 상세하게 설명합니다. 다음 절에서는 Active Directory와 IIS가 PKI에 제공하는 서비스에 대해 설명합니다. ##### Active Directory 앞의 "Active Directory 통합" 절에서 설명한 대로 Active Directory는 PKI에 필수적인 여러 가지 서비스를 제공합니다. 여기에는 인증서 게시, 인증서 등록, 인증서 계정 매핑, 신뢰 및 구성 정보 저장 등이 포함됩니다. 이러한 서비스는 모두 Enterprise CA에서 자동으로 제공됩니다. 온라인 독립 실행형 CA는 또한 이러한 서비스를 활용할 수 있습니다. 반대로 오프라인 CA는 Active Directory와 직접 상호 작용하여 정보를 저장 및 검색할 수 없습니다. 이 솔루션에서 오프라인 루트 CA의 CA 인증서는 Active Directory의 신뢰할 수 있는 루트 저장소에 게시됩니다. 이렇게 하면 루트 CA 인증서가 포리스트 내에 있는 모든 Active Directory 클라이언트의 신뢰할 수 있는 루트 저장소에 자동으로 배포됩니다. 루트 CA는 다음과 같은 게시 서비스를 위해 Active Directory 를 사용합니다(이 솔루션에서 사용하지 않음). - CRL 게시  — 도메인 클라이언트(포리스트 전체)는 로컬 도메인 컨트롤러에서 Active Directory에 게시된 CRL을 검색할 수 있습니다. - 도메인 클라이언트로 교차 인증서 배포 — Active Directory에 게시된 교차 인증서는 자동으로 포리스트의 각 Active Directory 클라이언트의 로컬 인증서 저장소에 배포됩니다. 발급하는 CA는 "Active Directory 통합" 절에 기술된 모든 서비스에 대해 Active Directory를 사용합니다. ###### 비Active Directory 클라이언트를 위한 Active Directory 신뢰할 수 없는 다른 Active Directory 포리스트 구성원이거나 Active Directory 포리스트 구성원이 아닌 PKI 클라이언트를 지원하기 위해 고려해야 할 점이 몇 가지 있습니다. 이러한 유형의 외부 클라이언트에서 LDAP(Lightweight Directory Access Protocol)를 사용하여 CA 인증서 및 CRL을 검색하려면 다음 사항을 고려해야 합니다. - 외부 클라이언트의 경우 CDP 및 AIA 경로에 명확한 LDAP 호스트 이름을 구성해야 합니다. 자세한 내용은 이 장 뒷부분의 "CDP 및 AIA 경로 구성"을 참조하십시오. - 외부 클라이언트는 Active Directory에서 익명 LDAP 쿼리를 기본적으로 수행할 수 없습니다. 포리스트의 **dsHeuristics** 값을 변경하고 Anonymous 계정에 명확한 액세스 권한을 부여해야 합니다. 자세한 정보는 이 장 끝에 나오는 "추가 정보" 절을 참조하십시오. **경고**: 위와 같이 하면 포리스트에 있는 모든 도메인 컨트롤러에 대한 익명 LDAP가 허용됩니다. (단, Anonymous 계정에 권한이 명시된 항목만 인증되지 않은 사용자가 액세스할 수 있습니다.) 계속하기 전에 디렉터리에 무단 액세스를 허용하면 어떤 결과가 발생하는지 주의 깊게 고려해야 합니다. - 외부 클라이언트는 디렉터리에서 구성된 신뢰할 수 있는 루트 정보를 상속하지 않으므로 다른 방법으로 이 정보를 구성해야 합니다. ###### 인터넷 클라이언트의 고려 사항 또한 조직 외부의 클라이언트(예: 인터넷 클라이언트)에 대한 CDP 및 AIA 구성에 관한 중요한 고려 사항이 있습니다. 이는 이 장 뒷부분의 "CDP 및 AIA 경로 구성" 절에서 다룹니다. 예를 들어 전자 메일 인증서 조회를 지원하기 위해 인터넷 클라이언트에 대한 인증서 조회를 제공해야 하는 경우 인터넷 클라이언트를 위해 별도의 LDAP 디렉터리를 만들어야 하는 경우가 있습니다. 보안상의 이유로 Microsoft는 익명 LDAP을 내부 Active Directory 포리스트에 허용하기 위해 앞에서 기술한 방법을 사용하지 말 것을 적극 권장합니다. 그 대신 별도의 Active Directory 포리스트를 만들고 MMS(Microsoft Metadirectory Services)나 기타 디렉터리 동기화 제품과 같은 메타 디렉터리 제품인 LDIFDE 도구를 사용하여 내부 포리스트에서 정보를 복제합니다. ##### 인터넷 정보 서비스 IIS는 이 디자인에서 PKI를 위한 두 가지 서비스를 제공합니다. - IIS는 CRL, CA 인증서를 비롯해 CPS 문서에 이르기까지 CA 정보를 게시합니다. - 웹 인터페이스를 사용하여 인증서를 등록할 수도 있지만(특히 Windows가 아닌 클라이언트에 유용함) 이 기능은 이 솔루션에서는 사용하지 않습니다. ###### IIS를 사용하여 CA 정보 게시 이 솔루션에서 루트 및 발급 CA 모두에 대한 CDP 및 AIA 정보가 웹 서버에 게시됩니다. HTTP 게시 기능을 사용하면 광범위한 클라이언트에서 필요한 정보를 검색할 수 있습니다. 이러한 용도로 발급 CA에 IIS를 설치하는 것이 일반적이지만 최상의 방법이라 할 수는 없습니다. 다른 IIS 서버를 사용하여 CRL 및 CA 정보를 게시할 수 있는 경우 그 서버를 사용하십시오. CA에 있는 모든 추가 프로토콜 및 서비스는 공격자가 서버에 침입할 수 있는 경로를 제공하기 때문에 사용자가 CA에 액세스할 수 있는 방법을 제한해야 합니다. CA는 대부분의 클라이언트에게 유일한 유효 CRL 위치가 될 수 있기 때문에 CA에서 IIS를 사용하면 유지 관리를 위한 CA 종료에 걸림돌이 됩니다. 구축 설명서에서 발급 CA는 CRL 및 CA 게시를 위해 IIS를 호스팅하는 데 사용됩니다. 이렇게 하면 빌드 프로세스가 단순화되고 추가 하드웨어에 대한 요구 사항이 줄어듭니다. 하지만 Microsoft는 가능하면 따로 배치할 것을 권장합니다. ###### IIS 등록 페이지를 사용하여 인증서 등록 IIS 등록 페이지는 수많은 시나리오에 유용합니다. 도메인이 아닌 클라이언트 등록, Windows가 아닌 클라이언트 등록 또는 Microsoft Internet Explorer 외의 브라우저 클라이언트 등록에 유용합니다. 하지만 CA는 웹 등록 페이지가 필요하지 않습니다. 이 솔루션에서는 기본적으로 발급하는 CA에 등록 페이지를 설치했지만 별도의 웹 서버에 설치할 수 있습니다(ASP 페이지를 지원하려면 서버가 IIS 5.0 이상을 실행해야 합니다.). 등록 페이지를 사용하면 등록 작업이 수월하지만 필요하지 않으면 설치하지 않아도 됩니다. 웹 등록 페이지 설치 및 사용에 대한 자세한 내용은 이 장 마지막에 나오는 "추가 정보" 절을 참조하십시오. #### CDP 및 AIA 경로 구성 인증서가 해지되었는지 아닌지 판별하기 위해서는 클라이언트에서 최신 CRL에 액세스할 수 있어야 합니다. 또한 최종 엔터티 인증서가 신뢰할 수 있는 루트에 연결되어 있는지 확인하기 위해 클라이언트에서 CA 인증서를 검색해야 하는 경우도 있습니다. 각 CA는 해당 인증서로 하나 이상의 URL을 인코딩해야 합니다. 이 URL은 클라이언트가 인증서에 대한 이와 같은 정보를 얻을 수 있는 위치를 제공합니다. CA 각각에 CDP 및 AIA를 구성하는 것은 인증서를 사용할 클라이언트 형식에 따라 결정됩니다. 인증서는 Active Directory 포리스트의 구성원인 사용자와 컴퓨터만 사용하기 위한 것입니까? 아니면 외부 사용자나 장치도 사용해야 합니까? 인증서 클라이언트 정의는 이 장 앞부분에서 다룹니다. ##### 루트 CA 이 솔루션에서 루트 CA는 다음과 같이 구성됩니다. - CDP 및 AIA의 주요(목록의 맨 처음) 경로는 HTTP URL입니다. 루트 CA CRL은 일반적으로 크기가 작고(1 – 2 KB) 게시 간격은 매우 길기 때문에(6개월) 한 장소에 게시하는 것이 CRL을 검색하는 클라이언트에게 큰 제약이 되지 않습니다. - 보조 경로는 LDAP URL로 구성하여 HTTP 위치에 백업을 만듭니다. LDAP 호스트 이름이 사용되지 않으므로 같은 포리스트의 클라이언트가 해당 로컬 도메인 컨트롤러에서 정보를 검색합니다. 포리스트 외부 클라이언트는 이 위치를 액세스할 수 없습니다. 이 구성은 기본적으로 HTTP 경로가 사용되기 때문에 Active Directory 포리스트 외부의 클라이언트가 이 CA 및 하위 CA의 인증서를 사용할 수 있습니다. ##### 발급하는 CA 이 솔루션에서 발급 CA는 내부 Active Directory 클라이언트가 사용하도록 최적화됩니다. CA는 다음과 같이 구성됩니다. - CDP 및 AIA URL의 주요 경로는 LDAP 디렉터리 경로입니다. - CDP 및 AIA URL에서 LDAP 호스트 이름이 지정되지 않기 때문에 클라이언트에서 기본 LDAP 서버를 사용할 수 있습니다. Active Directory 클라이언트의 경우 기본 LDAP 서버가 로컬 도메인 컨트롤러가 됩니다. 다른 LDAP 클라이언트의 경우에는 이와 같은 LDAP 경로를 쿼리하면 오류가 발생할 수 있습니다. 이러한 구성은 CA와 같은 포리스트에 있는 클라이언트에 가장 적합합니다. 기본 CRL은 주 단위로 게시되며 델타 CRL은 일 단위로 게시됩니다. 이 두 CRL의 기본 위치가 Active Directory이므로 클라이언트는 근접한 도메인 컨트롤러에서 이 CRL을 검색합니다. 이 구성은 복원성이 뛰어나고 네트워크 트래픽을 최적화합니다. ###### 외부 클라이언트를 지원하도록 CDP 및 AIA 설정 앞에 설명한 방식은 다른 Active Directory 포리스트 구성원이거나 Active Directory 포리스트 구성원이 아닌 클라이언트의 경우에는 적합하지 않습니다(예: 라우터). 외부 클라이언트는 LDAP CDP 및 AIA(기관 정보 액세스)에 액세스할 수 없기 때문에 외부 사용자는 해지 및 AIA 정보를 확인할 때 시간이 크게 지연됩니다. 시간 지연으로 외부 사용자가 응용 프로그램을 사용하는 데 오류가 발생할 수 있습니다. Active Directory 포리스트 외부의 클라이언트가 인증서를 사용할 가능성이 있는 경우 CDP 및 AIA 값을 구성하여 LDAP URL 대신 HTTP URL을 주요 경로로 사용해야 합니다. 외부 클라이언트가 사용할 수 있는 LDAP URL을 포함하려면 다음 작업을 수행해야 합니다. - CDP 및 AIA 경로에 명시적인 LDAP 호스트 이름을 구성합니다. 기본 null 경로(LDAP:///)를 사용할 수 없습니다. CA의 CDP 또는 AIA 경로를 바꾸려면 CA 인증서를 재발급(갱신)해야 합니다. - 앞서 설명한 대로 익명 LDAP 액세스를 사용함으로 설정해야 합니다. ###### 인터넷 클라이언트의 고려 사항 조직 밖으로 인증서를 배포하여 인터넷에서 사용하도록 하려면 추가로 다음과 같은 사항을 고려해야 합니다. 내부에 LDAP URL이 있는 인증서는 내부 Active Directory와 CA 구조 및 이름에 대한 정보를 제공할 수 있습니다. 이러한 정보를 제공하지 못하도록 하려면 다음을 수행해야 합니다. - 루트 CA의 CDP 및 AIA 값 또는 체인에 있는 모든 종속 CA에 대한 HTTP URL만을 사용합니다. - 외부에서 사용할 인증서는 별도의 CA에서 발급합니다. 이 CA는 HTTP CDP 및 AIA URL만을 사용합니다. 두 경우 모두 CRL 검색에 대한 이차적인 HTTP 위치를 제공해야만 주요 위치를 사용할 수 없을 경우 클라이언트가 이 위치를 사용할 수 있습니다. CRL 및 CDP 사용에 대한 자세한 내용은 이 장 뒷부분의 "추가 정보"에 포함된 참조 자료를 참조하십시오. #### CA 인프라 확장 "인증서 보안 요구 사항 정의" 절에서는 보안 수준 및 주체 유형에 따른 인증서 분류에 대해 설명했습니다. 주체 유형을 구별하는 주된 이유는 이러한 주체 유형에 CPS에 문서화된 다양한 인증서 정책 및 운영 방법이 적용될 수 있기 때문입니다. 일반적으로 CA 하나당 하나의 CPS가 적용됩니다. 하나의 CA에 여러 개의 주체 유형을 통제하는 다양한 정책을 적용할 수 있지만 이렇게 하면 CPS가 복잡해지고 올바르게 구현하기 어렵게 됩니다. 이 PKI를 확장하여 여러 정책 및 보안 요구 사항에 해당되는 인증서를 발급하기 위해서는 주요 주체 유형에 대해 추가 발급 CA를 만들어야 합니다. 여기에 대해서는 다음 그림에 나와 있습니다. **참고:** 이 그림은 이전 CA 계층 구조를 확장하는 방법만 나타냅니다. 조직에서 향후 요구 사항에 대해 이보다 훨씬 더 복잡하거나 아니면 간단한 방법을 필요로 할 수도 있습니다. 보안 요구 사항에 기초하여 추가 CA 및 인증서 기능을 디자인합니다. PKI 디자인에 있어 절대적인 옳고 그름은 없습니다. 다른 인증서 요구를 해결하기 위해 PKI를 확장하려는 경우 여기 기술된 단순한 PKI 디자인 방법과 유사한 방법을 사용해야 합니다. [![](images/Dd547898.04fig4-4(ko-kr,TechNet.10).gif)](https://technet.microsoft.com/ko-kr/dd547898.04fig4-4_big(ko-kr,technet.10).gif) **그림 4.4 CA 계층 구조 확장** 이 그림은 이전에 소개한 간단한 CA 계층 구조를 확장하여 보다 광범위한 인증서 요구 사항을 만족하는 방법을 보여 줍니다. 새로운 CA 및 인증서 기능이 회색 바탕에 대비되어 나타나 있습니다. 이 그림에서는 또한 높은 가치의 인증서(두 개의 열쇠 기호) 사용을 보여 주고 사용자(내부 및 외부) CA를 온라인으로 가져오면 이 CA가 첫 번째 CA를 대신해 표준 사용자 인증서를 발급하는 역할을 맡게 된다는 사실을 확인할 수 있습니다. CA 인프라 확장을 위한 전략은 다음과 같은 몇 가지 사항을 가정합니다. - CA 인프라 관리가 중앙 집중화됩니다. 즉, 조직 또는 지리적으로 분류하여 CA 제어를 위임할 필요가 없습니다. - 조직 전체에 공통 인증서 표준이 사용됩니다. 특정 형식의 인증서가 공통으로 수용되고 협의된 용도 및 정책이 조직 전체에 적용됩니다. - 기존 PKI와의 상호 운용성이 요구되지 않습니다. - 그림에 나와 있는 인증서 종류와 그 밖에 필요한 인증서 종류에 따라 다른 보안 수준 및 정책이 필요합니다. 위와 같은 가정이 자신의 조직에 맞지 않으면 다른 구조가 필요합니다. CA 인프라 확장을 위한 여러 가지 옵션 및 방식에 대한 자세한 설명은 이 장 마지막의 "Designing a Public Key Infrastructure"를 참조하십시오. ##### 정규 종속 인증서 정의를 사용하여 더 이상의 사용자 지정 작업 없이도 인증서 템플릿을 정의하고 인증서를 발급할 수 있습니다. 그러나 PKI를 확장할 때 발급 CA 인증서의 위임을 제한하여 CA가 발급할 수 있는 인증서의 범위를 제한해야 할 수도 있습니다. 앞에서 설명한 정규 종속을 사용하면 CA 인프라와 외부 조직 사이에 교차 인증서를 만들어 조직 내 신뢰 범위와 목적을 제어할 수 있습니다. 같은 기술을 사용하여 인증서 종류와 CA 계층 구조 내의 특정한 인증서 특성을 제한할 수 있습니다. 이 주제의 자세한 논의는 이 장의 범위를 벗어납니다. 자세한 내용은 이 장 뒷부분의 기술 자료 *Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003*을 참조하십시오. 이 솔루션의 PKI는 CA 계층 구조 내에 정규 종속이 필요치 않습니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 인증서 프로필 구성 이 절에서는 인증서를 구성하여 앞부분에서 정의한 요구 사항을 만족하는 방법을 설명합니다. #### 인증서 매개 변수 정의 필요한 인증서 종류별로 인증서 프로필을 문서화해야 합니다. 프로필 매개 변수를 인증서 템플릿에 구성할 수 있는데 이는 CA에서 발급하는 인증서 종류를 제어합니다. **참고**: 독립 실행형 CA에서는 인증서 템플릿을 사용하지 않습니다. 요청은 Certreq.exe와 같은 도구를 사용하여 웹 등록 페이지의 양식을 이용하거나 프로그래밍 방식으로 요청을 생성하여 만들어야 합니다. 독립 실행형 CA를 사용하는 경우에도 독립 실행형 CA에 인증서 요청을 작성할 때 각 인증서 종류별로 인증서 프로필을 정의하고 해당 프로필을 사용해야 합니다. 인증서 프로필은 다음을 모두 포함합니다. - 템플릿 이름 및 표시 이름(명명 표준을 정의해야 함) - 인증서 키 길이 - 인증서 유효 기간 - 옵션 인증서 확장 프로그램 - 등록 및 갱신 정책 - 유효 기간과 관련된 정책 - 응용 프로그램 용도와 관련된 정책 - 키 용도와 관련된 정책 - 키 보관과 관련된 정책 - 인증서 인증 - 주체 이름 만들기 - 인증서 등록 에이전트 - 키 만들기 - 키 및 CSP 유형 키 길이, 유효 기간, 키 만들기 옵션, 등록 및 인증 정책은 모두 앞부분에서 설명한 필요한 인증서 보안 수준 및 응용 프로그램 요구 사항에 의해 결정됩니다. #### 인증서 및 키 수명 정의 인증서 수명은 인증서 종류와 조직의 보안 요구 사항, 업계 표준 방식, 정부 규정 등과 같은 여러 가지 요소의 영향을 받습니다. 일반적으로 키의 길이가 길수록 지원하는 인증서 수명과 키 수명이 길어집니다. 키 길이와 키 유형을 제한하는 요소는 다음과 같습니다. - 호환성 — 일부 인증서 응용 프로그램은 2048비트보다 긴 키를 지원하지 않습니다. 키 종류는 호환성에도 영향을 줍니다. 일반적으로 RSA 키는 호환성이 가장 뛰어나지만 다른 키는 응용 프로그램이 필요할 수 있습니다. 체인에 있는 인증서를 모두 처리하는 데 응용 프로그램이 필요하기 때문에 체인의 모든 CA에 대해 키 길이와 키 호환성을 모두 고려해야 합니다. - 성능 - 서명 및 암호화 작업의 경우 크기가 작은 키보다 큰 키에서 더욱 강력한 처리 성능이 요구됩니다. 따라서 2,048비트보다 크기가 큰 키의 경우 일반적으로 인증서 발급 속도가 빠른 발급 CA에 사용하지 않아야 합니다. - 저장 - 크기가 큰 키일수록 만들어 내는 인증서의 크기도 커지며 인증서 데이터베이스에서 더 많은 저장 공간을 필요로 합니다. 인증서를 Active Directory에 게시하면 저장 요구 사항이 늘어납니다. 백업 크기와 시간도 이에 맞춰 늘어납니다. 인증서와 키 수명을 선택할 때 키가 손상에 얼마나 약한지 및 손상으로 인해 발생하는 결과를 고려해야 합니다. 인증서 및 키에 대해 선택하는 수명에 영향을 주는 요소는 다음과 같습니다. - 개인 키 길이 - 키의 길이가 길면 쉽게 손상되지 않으므로 키 수명이 연장됩니다. - CA 보안 - CA와 개인 키가 안전하면 안전할수록 수명이 길어집니다. - 특수화된 암호화 하드웨어 사용 - 스마트 카드 및 HSM을 사용하면 개인 키의 보안이 강화되고 수명이 길어집니다. - 인증서 주체에 대한 신뢰 - 외부 사용자 및 컴퓨터보다 직원과 내부 컴퓨터의 인증서 수명을 길게 만들 수 있습니다. - CA 키를 사용하여 서명한 인증서 개수 - 키를 액세스하는 횟수가 많을수록 CA 공용 키가 더 광범위하게 배포될수록 공격이나 손상에 노출될 확률이 높아집니다. 이 솔루션에서 사용되는 이러한 CA 및 최종 엔터티의 키 수명 및 갱신 기간이 다음 표에 나와 있습니다. **표 4.10 인증서 및 키 수명**

인증서 주체 키 길이 키 수명 갱신 간격
루트 CA 4096비트 16년 8년
발급하는 CA 2048비트 8년 4년
최종 엔터티 1,024 - 2,048비트 6개월 — 2년 유효 기간의 90%
키 길이에 있어 1024비트 키는 현재 매우 실용적인 암호 해독법으로 간주됩니다. 이러한 키에는 제안된 2년 최종 엔터티 값을 초과하는 안전한 키 수명이 필요합니다. 512비트 길이의 키는 보안 요구 사항이 매우 낮은 응용 프로그램을 제외하고 안전한 방법으로 간주되지 않습니다. 이런 이유로 512비트 키는 이 솔루션에서 사용하지 않습니다. 발급 CA 키 강도는 보안과 성능 요구 사항을 적절히 절충하여 정해야 합니다. 이 정도 크기의 키 수명은 갱신 기간인 4년보다 훨씬 깁니다. 루트 CA에는 실제 성능 제한이 없으므로 키 강도를 최대값인 16킬로비트로 설정할 수 있습니다. 이 솔루션에서는 호환성을 이유로 훨씬 더 낮은 수준으로 설정합니다. 그럼에도 불구하고 4,096비트 키의 보안 키 수명은 갱신 기간 8년을 넘습니다. 최종 엔터티에 대한 키 유형은 해당 응용 프로그램 요구 사항에 의해 결정되지만 RSA 키는 모든 CA에서 사용됩니다. 같은 키로 인증서를 갱신할 수 있지만 일반적인 상황에서는  권장하지 않습니다. 이 솔루션에서는 인증서 갱신 때마다 새로운 키 쌍을 만듭니다. CA가 발급한 인증서는 발급 CA 및 루트에 이르는 모든 상위 CA의 남은 유효 기간을 초과하는 유효 기간을 가질 수 없습니다. 예를 들어 CA 인증서가 6개월 안에 만료되는 경우 최대 수명 주기가 6개월인 인증서만 발급할 수 있습니다. 따라서 이 솔루션에서는 인증서 수명 주기가 반 정도 지나면 CA 인증서가 갱신되도록 지정합니다. CA가 발급하는 모든 인증서의 유효 기간은 발급 CA 인증서 수명의 반을 넘지 않아야 합니다. 최종 엔터티, 발급 CA, 루트 CA에 대한 중첩된 최대 유효 기간이 4년, 8년, 16년으로 각각 설정되기 때문입니다. 이 솔루션에서는 최종 엔터티 인증서가 최대 유효 기간인 2년 동안 유효합니다. 이란‡게 해야만 인증서 수명 계층 구조에 큰 영향을 주지 않고 추가 중간 CA 계층을 도입할 수 있습니다. #### 인증서 매개 변수에 보안 요구 사항 매핑 다음 표에는 이 장 앞부분에서 식별한 인증서의 종류와 인증서 종류별로 보안 범주를 인증서 프로필 매개 변수에 매핑하는 방법이 나와 있습니다. **표 4.11. 인증서 매개 변수**

인증서 종류 발급 정책 승인 방법 키 유효 기간 키 저장 키 내보내기 CSP
클라이언트 인증 - 사용자 낮음 자동(도메인 인증) 1024 1년 소프트웨어 필요 없음 지정됨
클라이언트 인증 - 컴퓨터 낮음 자동 (도메인 인증) 1024 1년 소프트웨어 필요 없음 지정됨
IAS 서버 인증 보통 수동(Cert Manager) 1024 1년 소프트웨어 필요 없음 지정됨
**참고:**  **발급 정책** 열의 "낮은" 정책은 인증서 서비스에서 앞서 정의한 "낮은 보증" 인증서 정책을 가리킵니다. 이 장 앞에서 설명한 표준 보증 또는 표준 보안 수준에 해당됩니다. **CSP**(cryptographic service providers) 열의 "명명" 값은 해당 인증서 형식에서 사용할 수 있는 CSP를 템플릿에 지정•해야 하고 클라이언트가 결정퓀˜도록 해서는 안 된다는 것을 의미합니다. 클라이언트 컴퓨터와 서버 인증서에는 특정 CSP 요구 사항이 있습니다. #### 인증서 템플릿 매개 변수에 인증서 요구 사항 매핑 응용 프로그램에서는 인증서를 정확하게 구성해야 하는 경우가 자주 있습니다. 특정한 방식으로 주체 이름의 서식을 정하고 특정 응용 프로그램 정책 OID를 포함해야 하거나 특정한 발급 정책을 사용하여 인증서를 발급해야 합니다. 위의 요구 사항이 아니더라도 응용 프로그램에서는 적어도 키 용도를 올바르게 정의해야 합니다. 인증서 프로필을 정의하기 위해서는 이러한 모든 매개 변수를 응용 프로그램 소유자(공급업체)로부터 구해야 합니다. 이 솔루션에서 요구하는 인증서 목록에 대한 응용 프로그램 요구 사항이 다음 표에 나와 있습니다. 이 표에는 인증서 속성 및 CA 매개 변수가 인증서 템플릿에서 구성된 대로 표시되어 있습니다. 모든 속성이 여기에 표시되어 있는 것은 아닙니다. **참고:** 아래에 있는 인증서는 각각 기본 제공되는 템플릿 유형을 기반으로 합니다. 원본 템플릿을 편집하지 말고 기본 제공되는 템플릿의 사본을 만들어 사본을 편집하여 필요한 설정을 합니다. 이렇게 하면 기본 제공되는 템플릿을 수정하지 않았으므로 필요할 때 쉽게 기본 제공되는 템플릿으로 돌아갈 수 있습니다. **표 4.12. 클라이언트 인증 - 사용자**

인증서 매개 변수 필요한 값
인증서 템플릿 이름 클라이언트 인증 - 사용자
Active Directory 게시 필요 없음
키 용도 디지털 서명
키 보관 필요 없음
최소 키 크기 1024
주체 이름 일반 이름
대체 주체 이름 사용자 이름
응용 프로그램 정책/확장 키 용도 클라이언트 인증
CSP(암호화 서비스 공급자) Microsoft Base Cryptographic Provider v1.0 Microsoft Enhanced Cryptographic Provider v1.0
파생된 템플릿 인증된 세션
**표 4.13. 클라이언트 인증 - 컴퓨터**

인증서 매개 변수 필요한 값
인증서 템플릿 이름 클라이언트 인증 - 컴퓨터
Active Directory 게시 필요 없음
키 용도 디지털 서명 키 암호화
키 보관 필요 없음
최소 키 크기 1024
주체 이름 일반 이름
대체 주체 이름 DNS 이름
응용 프로그램 정책/확장 키 용도 클라이언트 인증
CSP(암호화 서비스 공급자) Microsoft RSA SChannel 암호화 공급자
파생된 템플릿 워크스테이션 인증
**표 4.14. 802.1X 서버 인증**

인증서 매개 변수 필요한 값
인증서 템플릿 이름 802.1X 서버 인증
Active Directory 게시 필요 없음
키 용도 디지털 서명 키 암호화
키 보관 필요 없음
최소 키 크기 1024
주체 이름 일반 이름
대체 주체 이름 DNS 이름
응용 프로그램 정책/확장 키 용도 서버 인증
CSP(암호화 서비스 공급자) Microsoft RSA SChannel 암호화 공급자
파생된 템플릿 RAS 및 IAS 서버
#### 인증서 템플릿 만들기 Windows Server 2003 Active Directory에는 수많은 공통 기능을 위한 미리 정의된 인증서 템플릿 모음이 들어 있습니다. Enterprise CA를 설치할 경우 이러한 기본 제공 인증서 유형 중 몇 가지를 발급하도록 기본적으로 구성됩니다. 기본 제공 템플릿에 대한 설명은 Windows Server 2003 Enterprise Edition 제품 설명서에 있습니다. (정확한 참조 자료는 이 장 뒷부분의 "추가 정보" 절을 참조하십시오.) 이 설명서의 솔루션에서는 기본 템플릿 대부분을 CA에서 제거합니다. 즉, 인증 기관 관리 콘솔의 템플릿 폴더에서 템플릿을 제거합니다. 디렉터리에서 템플릿 정의를 삭제할 수 없습니다. 미리 정의된 템플릿이 요구 사항에 맞으면 이 템플릿을 사용할 수 있습니다. 대부분의 Windows 인증서 기반 응용 프로그램(예: 파일 시스템 암호화, VPN 인증 등)이 이러한 템플릿의 지원을 받습니다. 다른 종류의 인증서를 발급해야 하는 경우 자신의 요구 사항과 구체적으로 일치하는 템플릿을 만드는 것이 좋습니다. 미리 정의된 템플릿의 기능을 이해하지 않고 바로 사용하면 의도하지 않은 기능을 사용하게 될 위험이 있습니다. 예를 들어 간단한 클라이언트 인증을 위한 컴퓨터 인증서가 웹 서버 인증서로도 사용될 수 있습니다. 새 템플릿을 만들려면 인증서 프로필 요구 사항과 비슷한 미리 정의된 템플릿을 찾고 새 템플릿의 기반이 될 해당 템플릿의 복제물을 만들어야 합니다. 템플릿 구성은 이 절에서 정의한 인증서 프로필에 일치하는 특성을 선택하는 간단한 프로세스입니다. **참고:** 새 템플릿을 처음부터 만들 수 없습니다. 기존 템플릿의 사본을 만들어 필요한 대로 편집해야 합니다. 컴퓨터 템플릿은 컴퓨터 템플릿으로부터, 사용자 템플릿은 사용자 템플릿으로부터 파생시켜야 하며 두 가지를 교대로 사용할 수 없습니다. 템플릿을 만들고 수정하는 과정에서 구성 관리 시스템의 일환으로 템플릿 매개 변수의 자세한 기록을 보관해야 합니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 인증서 관리 계획 세우기 조직의 인증서를 구성한 다음에는 전체 수명에 대한 인증서 관리 계획을 세워야 합니다. 인증서 관리 계획을 세우려면 다음에 대한 결정을 내려야 합니다. - 새 인증서에 대한 요청 및 인증서 갱신을 처리하는 법 - 인증서를 사용자 계정으로 매핑하는 법 - CRL 관리 및 배포 방법 - 암호화된 데이터 복구 전략 #### 등록 및 갱신 방법 선택 여러 가지 방법을 사용하여 인증서 등록을 수행할 수 있습니다(이 방법 모두 인증서 갱신도 가능합니다). - Windows 자동 등록. - 일반적으로 인증서 관리 콘솔에서 시작하는 인증서 등록 마법사를 사용한 온라인 등록입니다. - 응용 프로그램 또는 스크립트에서 CryptoAPI 또는 CAPICOM 인터페이스를 사용한 온라인 등록입니다. - Certreq.exe 도구를 사용하여 요청을 만들고 전송한 뒤 발급된 인증서를 검색합니다. **참고**: 위의 네 가지 방법은 같은 온라인 등록 인터페이스의 여러 가지 인터페이스일 뿐입니다. - 웹 페이지 등록. - 수동 오프라인 등록(이 과정에는 이전에 정의한 방법 중 하나를 사용하여 요청을 파일로 생성하고 CA로 가져간 뒤 이 요청을 인증 기관 관리 콘솔을 사용하여 전송하고 관리 콘솔을 사용하여 검색하는 작업이 포함됨) 이러한 방법은 모두 유효하며 경우에 따라 적합하게 사용할 수 있습니다. 이 솔루션은 다음 등록 방법을 사용합니다. - Windows 자동 등록. 가능한 경우 이 방법은 인증서 관리 오버헤드를 낮추는 데 사용하는 것이 좋습니다. 인증서에 수동 승인이 필요한 경우에도 자동 등록을 사용할 수 있지만 등록 에이전트 서명이 필요한 경우에는 그렇지 않습니다. 바로 인증서가 발급되는 것은 아니지만 CA로 요청이 전송되고 승인된 후에 등록이 완료됩니다. - 수동 오프라인 등록. 이 방법은 루트 CA에 있는 모든 인증서 등록 및 갱신에서 사용됩니다. 이 중에는 인증서 요청을 CA로 전송하기 전 제3자가 서명해야 하는 경우와 같이 복잡한 시나리오에 적합한 방법은 없습니다. RPC 기반 온라인 등록 또한 대부분의 Windows가 아닌 플랫폼(예: 라우터)에서 지원되지 않습니다. 또한 자동 등록은 Active Directory에서 주체 이름을 생성하지 않고 인증서 요청에서 주체 이름 또는 대체 주체 이름을 정의해야 하는 경우에는 가능하지 않습니다. 이와 같은 고급 요구 사항을 수용하려면 다음 방법 중 하나를 사용해야 합니다. - CAPICOM 스크립트를 만들어 로그온 스크립트의 일부로 클라이언트 독립 실행형 컴퓨터에서 실행합니다. - 요청을 생성 및 전송하고 발급된 인증서를 검색 및 설치하는 데 명령에 certreq.exe를 사용하거나 배치 파일을 사용합니다. - CAPICOM을 활용하여 사용자 지정 웹(ASP 또는 Microsoft ASP.NET) 페이지를 만들어 요청을 만들고 전송합니다. 마지막 기술을 사용하여 다양한 클라이언트에게 등록 서비스를 제공하고 요청을 승인하기 위해 여러 개의 서명이 필요한 경우와 같이 정교한 다중 단계 프로세스를 포함시킬 수 있습니다. #### 신원으로 인증서 매핑 인증서와 인증서에서 이름이 지정된 주체 사이의 매핑은 매우 광범위한 주제로 이 문서에서는 다루지 않습니다. 그러나 다음 두 가지 사항은 중요하게 고려해야 합니다. - 인증서가 발급되기 전에 인증서 주체의 신원은 어떻게 확인합니까? - 디렉터리에 제공된 정보에서 검색한 인증서 주체의 신원은 어떻습니까? 이 중 첫 번째 질문은 인증서 등록 프로세스가 어떻게 처리되는지에 대한 것입니다. 이 문제는 다음 절 "인증서 정책 만들기"에서 다룹니다. 두 번째 문제는 인증서 사용자(응용 프로그램 및 서비스)가 인증서 주체 ID를 사용할 수 있는 다른 ID에 올바로 매핑하는 방법을 다룹니다. 여기에 해당되는 예제는 다음과 같습니다. - 도메인 컨트롤러가 도메인에 사용자를 로그온시키고 액세스 토큰을 만드는 등의 작업을 위해 스마트 카드에서 사용자를 식별하는 방법은 무엇입니까?? - 전자 메일 사용자는 보안 전자 메일을 보내려는 대상의 인증서를 어떻게 검색합니까? 인증서의 대부분은 Active Directory 보안 원칙(사용자 및 컴퓨터)에 등록 프로세스의 일부로 자동으로 매핑됩니다. Active Directory는 인증서의 주체 이름 및 대체 주체 이름을 정의하여 인증서와 인증서에 지정된 보안 원칙 사이에 암시적 매핑을 설정합니다. 대체 주체 이름에는 사용자의 UPN 또는 전자 메일 이름, SPN(Service Principal Name) 또는 컴퓨터 또는 컴퓨터 프로세스의 DNS 호스트 이름이 들어 있습니다. UPN 및 SPN 값은 Active Directory 포리스트 내에서 고유합니다. 전자 메일 및 DNS 이름은 Active Directory에서 강제로 적용하지 않더라도 전체적으로 고유해야 합니다. IIS 및 IAS 등의 다른 Windows 서비스는 사용자 또는 컴퓨터 ID로의 인증서 매핑을 수행합니다. **참고:** 인증서 매핑은 인증서 게시와 관계 없습니다. 인증서 매핑은 디렉터리에서 개체를 고유하게 식별하는 인증서 특성(보통 대체 주체 이름)이 있음을 뜻합니다. IAS 서버는 이를 사용하여 제시된 인증서의 사용자 또는 컴퓨터의 ID를 확인합니다. IAS는 디렉터리에서 인증서를 조회하지 않고 암시적 매핑을 사용합니다. 인증서 게시 및 그로 인한 인증서 조회는 인증서가 사용자 또는 컴퓨터 개체의 특성으로 디렉터리에 저장되어 있음을 말합니다. 사용자는 디렉터리에서 사람을 검색하여 그 사람의 인증서를 가져올 수 있습니다. 또한 Active Directory 사용자 및 컴퓨터 관리 콘솔을 사용하여 사용자 또는 컴퓨터 개체에 다른 인증서를 수동으로 가져오거나 매핑할 수 있습니다. 반대로 디렉터리의 개체에 직접 매핑할 필요가 없는 경우도 많습니다. 다음과 같은 경우입니다. - 주요 식별자가 웹 사이트의 DNS 호스트 이름인 웹 서버 - 인증서가 Active Directory가 없는 엔터티로 발급된 경우(예: 다른 조직의 라우터 또는 사용자) 이 설명서의 솔루션의 모든 최종 엔터티는 Active Directory 사용자 및 컴퓨터에 직접(및 암시적으로) 매핑합니다. CA는 반드시 컴퓨터 개체로 매핑되지 않는다는 점에서 특수한 경우입니다. 그러나 CA는 거의 대부분 Active Directory AIA 및 신뢰할 수 있는 인증 기관 컨테이너에 있는 인증 기관 개체로 매핑됩니다. #### 인증서 정책 만들기 최소한 인증서 보안 범주별로(높음, 보통 및 표준) 인증서 승인 방법을 정의해야 하고 Microsoft도 인증서 주체 범주별로(컴퓨터, 내부 사용자, 외부 사용자) 정의할 것을 권장합니다. 이보다 세부적인 수준에서 정책을 정의해야 하는 경우는 거의 없습니다. 정책 결정을 인증서 정책 설명 및 CPS의 일부로 문서화해야 합니다. 다양한 인증서 정책을 사용하여 인증서 등록에 사용되는 인증서 승인 프로세스 종류 및 개인 키 보안 수준을 나타냅니다. OID를 사용하여 이를 인증서로 인코딩하여 여러 가지 정책을 표시합니다(하지만 할 필요는 없습니다). 승인 프로세스의 까다로움이 발급 중인 인증서의 가치를 반영합니다. 승인 또는 등록 프로세스는 인증서의 요청자가 인증서 주체와 같은 엔터티라는 사실을 충분하게 확신할 수 있도록 하는 것을 목표로 합니다. 키 보안 강도는 개인 키가 비밀로 유지되고 인증서 주체가 단독으로 소유한다는 사실에 대해 얼마나 확신할 수 있는지 평가합니다. 이 솔루션에서 사용되는 인증서 보증 수준은 장 앞부분의 "인증서 보안 요구 사항" 절에 정의되어 있습니다. 이 인증서 보증 수준에 해당하는 발급 정책 OID를 포함시켜 발급하는 인증서의 보증 수준을 나타낼 수 있습니다. 응용 프로그램(및 사용자)은 발급 정책을 사용하여 특정 인증서가 얼마나 신뢰할 만한지 결정합니다. 앞서 정의한 세 가지 보증 수준은 Windows Server 2003에서 미리 정의한 세 가지 인증서 정책에 매핑됩니다(인증서 템플릿 MMC의 발급 정책이라고 함). 다음 표는 이 솔루션의 다양한 발급 정책 사용에 대해 설명합니다. 인증서 템플릿에 정책 OID를  포함시켜(최소한 보통 및 높은 보증 인증서에) 높은 보증 인증서를 식별하기 쉽도록 합니다. 인증서 정책이 없는 인증서는 표준 보증으로 간주됩니다. **표 4.15 인증서 발급 정책 수준**

인증서 (발급) 정책 등록 요구 사항 최소 키 저장소 요구 사항
낮음 (표준) 성공적인 도메인 인증에 따른 자동 승인. 독립 실행형 CA의 경우 자동 승인은 인증되지 않은 승인 수준으로서 CA는 요청자에 대한 아무(또는 최소한의) 검사도 수행하지 않고 인증서를 발급합니다. 소프트웨어 키
보통 인증서 관리자 승인. 정책에서 인증서 요청을 승인하기 전에 인증서 관리자가 수행해야 하는 검사 유형을 정의해야 합니다. 소프트웨어 키 또는 하드웨어 키. 소프트웨어 키를 사용하는 경우 응용 프로그램에서 사용할 수 없는 경우를 제외하고 강력한 키 보호 사용을 고려해야 합니다. (예를 들어 컴퓨터 인증서는 강력한 키 보호를 사용할 수 없습니다.)
높음 지정된 등록 직원 서명 및 인증서 관리자 승인. 요청을 승인하기 전에 등록 직원 및 인증서 관리자가 수행해야 하는 검사 유형을 정의해야 합니다. 하드웨어 훼손 방지 토큰. 예를 들어 스마트 카드 또는 사용자를 위한 USB(범용 직렬 버스) 암호화 토큰이나 컴퓨터를 위한 HSM을 사용합니다.

참고: 조직의 요구 사항이 어떤지에 따라 이에 맞게 인증서 정책 및 보증 수준을 더 많이 또는 적게 정의할 수 있습니다.

인증서 해지 정책 정의

경우에 따라 인증서가 수명을 다하기 전에 인증서를 무효화해야 할 수도 있습니다. 인증서 해지를 위한 정책을 만드는 경우 다음과 같은 작업을 수행합니다.

  • 인증서 해지를 보장하는 조건 정의

  • CRL 게시 위치 선택

  • 사용하려는 CRL 유형 선택

  • CRL 게시 일정 정하기

인증서 정책 일부에는 인증서 해지를 보장하는 조건 정의가 들어 있습니다. 이는 인정서 종류에 따라 다르며 보증 수준과 주체 유형, CA에 따라서도 크게 달라질 수 있습니다.

또한 인증서를 해지할 때 해지 이류 코드를 어떻게 사용할지 문서화해야 합니다. 다음 표는 여러 가지 해지 이유 코드에 대해 설명합니다.

표 4.16 인증서 해지 코드

이유 코드 설명
키 손상 인증서의 개인 키가 손상되었거나 손상된 것으로 의심됩니다.
CA 손상 CA의 개인 키가 손상되었거나 손상된 것으로 의심됩니다.
정보 변경 주체가 다른 조직으로 이동했습니다.
대체됨 이 인증서를 대신하는 새로운 인증서가 발급되었습니다.
운영 중단 CA가 더 이상 동작하지 않습니다.
인증서 보류 인증서 사용을 일시적으로 중단해야 합니다(예: 사용자가 스마트 카드를 잃어버렸으나 분실 여부를 확실히 모르는 경우).
지정되지 않음 다른 코드에 의해 설명되지 않는 모든 이유
**중요:** 불가피한 상황을 제외하고 인증서 보류 이유 코드를 사용하지 마십시오. 인증서를 보류했다가 다시 사용하면 정해진 시기에 인증서의 해지 상태는 물론 인증서에 의해 만들어진 모든 서명의 유효성을 결정할 수 없게 됩니다. 해지 절차의 일환으로 문서가 다음 질문에 대한 대답을 제공하는지 확인해야 합니다. 아래 질문은 일반적으로 변화 관리 또는 사고 관리 로그에 저장됩니다. - 이 인증서를 해지하는 이유는 무엇입니까? - 이 인증서의 해지를 요청한 사람은 누구입니까? - 서명 확인이나 메시지 해독을 위해 이 인증서가 나중에 다시 필요합니까? 필요하다면 어떤 용도로 필요합니까(예: 서명 확인, 메시지 해독, 일반적인 용도)? - 인증서를 해지하는 사람에 대해 관리자로서 만족해야 하는 특수한 요구 사항(예: 인증서를 해지하는 사람이 관리자여야 함)이 있습니까? - 인증서를 해지할 때 따라야만 하는 문서화된 조직의 운영 지침이 있습니까(예: 백업)? 인증서 해지를 통제하는 기술적인 매개 변수도 여러 개 있습니다. Microsoft는 이를 CA 정책 일부로 문서화할 것도 권장합니다. 다음 표의 매개 변수는 이 솔루션의 루트 및 발급 CA에 대한 것입니다. **표 4.17 루트 CA 인증서 해지 매개 변수**

매개 변수 선택한 값 이유
CRL 게시 위치(CDP) 내부 웹 서버의 HTTP 경로 웹 서버에 게시하면 LDAP 위치를 백업할 수 있으며 비 LDAP 클라이언트가 CRL에 액세스할 수 있습니다.
  Active Directory CDP 컨테이너에 대한 DAP 경로 모든 도메인 컨트롤러에 게시하면 모든 도메인 사용자가 쉽게 로컬에서 액세스할 수 있습니다.
CRL 유형 기준 CRL 전용 발급된 인증서 수가 작기 때문에 델타 CRL을 사용함으로써 얻을 수 있는 이점이 없습니다.
게시 일정 6개월 발급 CA 인증서를 해지하기가 어려워지므로 발급 CA 보안에 대한 확인을 가질 필요가 있습니다. 그러나 기간이 이 정도로 길어지면 루트 CA 관리 작업량이 최소화됩니다.
CRL 중복 기간(새 CRL 게시와 이전 CRL 만료 사이 간격) 10일 루트 CA에서 새로운 CRL을 검색할 때 오류가 발생할 수 있습니다.
**표 4.18. 발급 CA 인증서 해지 매개 변수**

매개 변수 선택한 값 이유
CRL 게시 위치(CDP) Active Directory CDP 컨테이너에 대한 LDAP 경로(기준 및 델타 CRL 모두) 모든 도메인 컨트롤러에 게시하면 모든 도메인 사용자가 쉽게 로컬에서 액세스할 수 있습니다. (델타 CRL의 Active Directory 게시에 관한 아래 참고를 참조하십시오.)
  내부 웹 서버의 HTTP 경로 웹 서버에 게시하면 LDAP 위치를 백업할 수 있으며 비 LDAP 클라이언트가 CRL에 액세스할 수 있습니다.
CRL 유형 기본 CRL 델타 CRL 델타 CRL은 게시되는 해지 정보의 시간 간격은 비교적 짧게 줄이면서 CRL 검색 트래픽을 최적화하는 데 도움이 됩니다.
게시 일정 기준 CRL — 7일 델타 CRL을 인식하지 못하는 시스템에서도 계속해서 비교적 최신 상태의 해지 정보를 받을 수 있도록 간격이 짧아야 합니다.
  델타 CRL — 1일 델타 CRL을 사용하는 최근 사용자들에게 비교적 짧은 시간 간격을 제공합니다.
기준 CRL 중복 기간(새 CRL이 게시되는 것과 이전의 CRL이 만료되는 것 사이의 간격) 4일 기준 CRL을 정해진 시간에 게시하지 못할 경우 CA 복구 오류가 발생할 수도 있습니다. 연휴가 시작되는 금요일 밤에 CA가 충돌하여 다음 화요일까지 아무도 여기에 대해 알아차리지 못하는 최악의 사태에 대비하여 4일이라는 기간을 선택했습니다.
델타 CRL 중복 기간 1일 델타 CRL은 서비스에서는 그다지 중요하지 않으므로 델타 CRL 게시가 실패해도 그 영향은 심각하지 않습니다. 델타 CRL은 Active Directory 대기 시간보다 중복 시간이 길어지도록 하기 위해 설정합니다.
**참고**: 델타 CRL이 사용되는 기간은 하루 정도로 비교적 짧기 때문에 최대 Active Directory 복제 지연 시간이 델타 CRL 복제 기간의 50% 미만이 되도록 해야 합니다. 그렇지 않으면 인증서 클라이언트가 안정적인 해지 정보를 사용할 수 있게 될 뿐 아니라 네트워크 대역폭이 제한된 디렉터리 복제 트래픽에 부정적인 영향을 미칠 수 있습니다. 델타 CRL 중복 시간은 포리스트에서 디렉터리 정보가 복제되는 최대 시간보다 큰 값으로 설정해야 합니다. Active Directory 지연 시간이 이 값보다 크거나 추가 디렉터리 복제 트래픽을 원하지 않는 경우 델타 CRL 게시 기간을 늘이거나 디렉터리에 델타 CRL을 게시하지 말아야 합니다. 델타 CRL 위치를 변경하면 새 기준 CRL을 발급해야 합니다. LDAP URL 대신 HTTP 위치를 사용하여 델타 CRL을 게시할 때 복제 지연은 크게 문제가 되지 않습니다. #### 키 및 데이터 복구 계획 키 복구 및 데이터 복구에 대해서는 이 솔루션에서 다루지 않습니다. 이 둘 중 하나 또는 두 가지 모두가 필요한 경우 계획 및 관리 시 주의를 기울여 데이터 손실을 방지하고 암호화된 데이터가 부주의로 인해 노출되지 않도록 해야 합니다. *Windows Server 2003 Deployment Kit*의 "Planning for Data Recovery and Key Recovery" 및 "Designing a Public Key Infrastructure" 절 및 Microsoft 기술 자료 "Key Archival and Management in Windows Server 2003"을 참조하는 것이 좋습니다. [](#mainsection)[페이지 위쪽](#mainsection) ### 요약 이 장에서는 보안 무선 LAN용 PKI(공용 키 구조) 디자인 프로세스를 다루었습니다. 이 설명서에 소개된 PKI는 향후 많은 조직이 다른 응용 프로그램에 PKI를 사용할 가능성을 염두에 두고 설계했습니다. 이 장에 소개한 디자인은 유연성이 뛰어나 사용자가 향후 다양한 요구 사항을 다루기 위해 확장할 수 있습니니다. 이 정보를 사용하여 WLAN 응용 프로그램에서 요구되는 훨씬 엄격한 보안 기준을 만족할 수 있는 안전한 PKI를 디자인할 수 있습니다. 이 장에서 다룬 디자인 결정은 구축 설명서 및 운영 설명서에서 PKI를 구현하는 데 사용됩니다. 이 정보는 솔루션 설명서 7장 및 11장에서 자세히 다룹니다. 계획 설명서 나머지 장에서는 이 솔루션의 나머지 핵심 구성 요소인 RADIUS 인프라(IAS와 공동 구현됨) 및 WLAN 보안 인프라 디자인을 다룹니다. #### 추가 정보 다음 참조는 이 장에서 다룬 주제에 관한 상세한 배경 정보 및 기타 관련 정보를 제공합니다. - https://go.microsoft.com/fwlink/?LinkId=4735의 *Windows Server 2003 Deployment Kit*의 "[Designing a Public Key Infrastructure](https://go.microsoft.com/fwlink/?linkid=4735)" - PKI 개념에 대한 일반적인 소개 및 Windows 2000의 인증서 서비스 사용은 https://www.microsoft.com/korea/technet/archive/windows2000serv/evaluate/ featfunc/pkiintro.mspx의 [*Windows 2000 공용 키 구조 개요*](https://www.microsoft.com/technet/archive/windows2000serv/evaluate/featfunc/pkiintro.mspx)(영문)를 참조하십시오. - Windows Server 2003 및 Windows XP에서 향상된 PKI 기능에 대한 설명은 https://www.microsoft.com/korea/technet/prodtechnol/winxppro/plan/pkienh.mspx의 [*Windows XP Professional 및 Windows Server 2003의 PKI 향상 기능*](https://www.microsoft.com/korea/technet/prodtechnol/winxppro/plan/pkienh.asp)을 참조하십시오. - https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ proddocs/entserver/SE\_PKI.mspx의 Windows 2003 Server Enterprise Edition [공용 키 구조](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/se_pki.mspx)(영문) 제품 설명서는 인증서 서비스의 핵심 개념 및 관리 작업을 논의합니다. - 인증서 방법 설명서 작성에 관한 자세한 내용은 www.ietf.org/rfc/rfc2527.txt에서 RFC2527 [*Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework*](https://www.ietf.org/rfc/rfc2527.txt)를 참조하십시오. - CPS의 예는 www.verisign.com/repository/CPS/의 [VeriSign Certification Practice Statement(CPS)](https://www.verisign.com/repository/cps/) 페이지를 참조하십시오. - 인증서 정책 OID 및 CPS URL이 인증서에 인코딩되는 방법에 관한 세부 정보는 www.ietf.org/rfc/rfc3280.txt의 RFC 3280 [*인터넷 X.509 공용 키 구조 인증서 및 CRL 프로필*](https://www.ietf.org/rfc/rfc3280.txt)을 참조하십시오. - 정규 종속에 관한 자세한 내용은 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/ws03qswp.mspx의 기술 자료 [*Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx)(영문)을 참조하십시오. - 엔터프라이즈 CA와 독립 실행형 CA의 차이점에 관한 상세한 설명은 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ proddocs/entserver/sag\_CSCAs.mspx의 인증서 서비스 제품 설명서의 [인증 기관](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/sag_cscas.mspx)(영문) 절을 참조하십시오. - Windows Server 2003의 익명 LDAP 액세스 사용에 관한 자세한 정보는 https://support.microsoft.com/default.aspx?scid=326690의 Microsoft 기술 자료 문서 Q326690 "[Anonymous LDAP operations to Active Directory are disabled on Windows Server 2003 domain controllers](https://support.microsoft.com/default.aspx?scid=326690)(영문)"를 참조하십시오. - 인증서 해지에 관한 상세한 논의는 https://www.microsoft.com/korea/technet/prodtechnol/winxppro/support/tshtcrl.mspx의 [*Troubleshooting Certificate Status and Revocation*](https://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx) (영문)을 참조하십시오. CDP Extensions에 대한 절은 특히 이 장에서 설명한 내용과 관련이 있습니다. - 인증서 서비스 웹 등록 페이지 설치 및 사용에 관한 자세한 정보는 https://www.microsoft.com/windowsserver2003/proddoc/default.mspx의 [Product Documentation for Windows Server 2003](https://www.microsoft.com/korea/windowsserver2003/proddoc/default.asp) 웹 페이지에서 Security, Public Key Infrastructure, Certificate Services, How to... 및 Set up a Certification Authority를 검색하십시오. - 인증서 템플릿의 자세한 설명서는 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/ws03crtm.mspx의 [*Implementing and Administering Certificate Templates in Windows Server 2003*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03crtm.mspx) (영문)을 참조하십시오. - 기본 제공되는 모든 인증서 템플릿의 설명은 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ proddocs/entserver/ctcon\_tshoot.mspx의 Windows Server 2003 제품 설명서의 [Troubleshooting](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/ctcon_tshoot.mspx) 절에 있습니다. - 인증서 자동 등록에 관한 자세한 정보는 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/autoenro.mspx의 [*Certificate Autoenrollment in Windows Server 2003*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx) (영문)을 참조하십시오. - Windows Server 2003의 키 보관 및 관리에 관한 정보는 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/kyacws03.mspx의 기술 자료 [*Key Archival and Management in Windows Server 2003*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx) (영문)을 참조하십시오. - 고급 인증서 등록에 대한 자세한 내용은 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/advcert.mspx의 [*고급 인증서 등록 및 관리*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advcert.mspx) (영문)를 참조하십시오. - 웹 등록 페이지를 사용한 인증서 등록에 관한 정보는 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/webenroll.mspx의 [*Configuring and Troubleshooting Windows 2000 and Windows Server 2003 Certificate Services Web Enrollment*](https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.asp)를 참조하십시오. - Windows Server 2003 PKI 구현에 관한 자세한 정보는 https://www.microsoft.com/korea/technet/prodtechnol/windowsserver2003/ technologies/security/ws3pkibp.mspx의 "[Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx) (영문)"를 참조하십시오. - 자세한 구현 정보는 Microsoft Systems Architecture 버전 2.0 구현 설명서에 나와 있는데 이는 https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx의 [Windows Server System Reference Architecture](https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx)(영문) 페이지에서 다운로드할 수 있습니다. [](#mainsection)[페이지 위쪽](#mainsection)