Windows Server 2025 / AD CS의 역할과 내부 인증서 도입 전에 검토할 사항
AD CS는 조직 내부에서 인증서를 발급·관리하기 위한 Windows Server 역할입니다. 내부 HTTPS·장치 인증·사용자 인증처럼 반복되는 수요가 있을 때 검토하며, 설치 전에 신뢰 체계·발급 권한·폐기·갱신·복구와 운영 책임을 설계해야 합니다.
AD CS가 해결하는 문제입니다
AD CS(Active Directory Certificate Services)는 공개 키 기반 구조(PKI)의 인증기관을 운영하는 데 사용합니다. 인증기관(CA)은 특정 사용자·장치·서비스의 신원과 공개 키를 연결하는 인증서에 서명합니다. 클라이언트가 그 인증기관을 신뢰하고 인증서를 검증할 수 있어야 의미가 있습니다.
예를 들어 내부 웹 서버 수십 대에 인증서를 발급하고 만료 전에 갱신하거나, 관리되는 단말에 장치 인증서를 등록하는 데 사용할 수 있습니다. 모든 브라우저가 내부 CA를 자동으로 신뢰하는 것은 아닙니다. 조직이 관리하지 않는 외부 사용자를 위한 공개 서비스라면 공개 신뢰 인증서가 더 적합할 수 있습니다.
AD CS 개요의 인증서 발급·관리 역할을 출발점으로 삼되, HTTPS 하나를 적용하기 위해 반드시 내부 CA를 구축해야 한다고 생각하지 않습니다. 기존 조직 PKI나 관리형 발급 서비스가 있는지 먼저 조사하면 중복된 신뢰 체계를 피할 수 있습니다.
인증기관 구조와 신뢰 경계를 정합니다
| 설계 항목 | 결정할 질문 |
|---|---|
| 루트와 발급 CA | 신뢰의 최상위 키를 어디에 두고 누가 보관하는가 |
| 엔터프라이즈·독립형 | AD 통합·템플릿·자동 등록이 필요한가 |
| 온라인·오프라인 | 상시 발급이 필요한 계층과 분리 보관할 계층은 무엇인가 |
| 외부·비관리 단말 | 신뢰 배포와 폐기 확인 경로를 어떻게 제공하는가 |
루트 CA는 신뢰의 출발점이고 하위 발급 CA는 실제 인증서 발급을 담당할 수 있습니다. 루트는 오프라인, 발급 CA는 온라인으로 분리하는 구조를 검토할 수 있지만 조직 규모·위협·복구 능력에 맞춰 결정해야 합니다. 계층을 많이 만든다고 자동으로 안전해지는 것은 아닙니다.
PKI 설계 고려 사항에 따라 CA 이름·서버 이름·키 보관·유효 기간·배포 주소를 설치 전에 정합니다. CA 설치 후 서버 이름을 가볍게 바꾸는 방식으로 운영하지 않습니다. 도메인 컨트롤러와 CA를 한 서버에 합치는 편의보다 키 보호와 관리자 권한 분리를 우선 검토하세요.
템플릿과 등록 권한을 통제합니다
인증서 템플릿은 용도·키 정책·유효 기간·등록 조건을 정하는 설계 단위입니다. EKU(확장 키 사용)는 서버 인증·클라이언트 인증 등 허용된 용도를 나타냅니다. 웹 서버용 인증서와 로그인에 쓰이는 인증서를 같은 수준으로 무제한 발급하면 신원 위조 위험이 커질 수 있습니다.
- 인증서를 요청할 수 있는 계정과 승인·발급을 관리하는 계정을 구분합니다.
- 요청자가 이름을 임의로 지정할 수 있는지와 그 이름을 어떻게 검증할지 정합니다.
- 개인 키를 내보낼 필요가 있는지, 서비스 계정의 키 접근 범위가 어디까지인지 정합니다.
- 자동 등록은 승인된 대상 그룹과 용도에 한정하고 결과·실패를 감시합니다.
템플릿 권한은 편의상 Authenticated Users 등에 넓게 부여하기 전에 발급 용도와 악용 가능성을 검토합니다. CA 관리자, 인증서 관리자와 일반 서버 관리자의 권한도 분리하세요. AD CS 보안·위임·감사 안내는 CA 운영 권한과 감사를 검토하는 데 도움이 됩니다.
만료·폐기·배포 경로를 운영해야 합니다
인증서를 발급한 뒤 만료일까지 방치해서는 안 됩니다. 키 유출·사용자 퇴사·서버 폐기 때 인증서를 폐기하고 클라이언트가 그 상태를 확인할 수 있어야 합니다. CRL은 폐기 인증서 목록이며, AIA는 인증기관 인증서 등을 찾는 위치와 관계됩니다. 폐기 확인에 필요한 주소는 실제 클라이언트가 접근할 수 있어야 합니다.
내부 인증서를 외부 접속에도 쓸 경우 내부 전용 DNS·LDAP 주소만으로 검증이 가능한지 확인해야 합니다. CA 자체가 꺼져 있어도 기존 인증서 사용이 모두 즉시 중단되는 것은 아니지만, 발급·갱신과 폐기 정보 제공의 장애는 각각 다른 영향을 줍니다. 상태 확인 동작은 앱·클라이언트 정책에 따라 달라집니다.
루트·하위 CA·서비스 인증서의 유효 기간과 갱신 순서를 함께 설계합니다. 발급 CA의 만료가 가까운데 서비스 인증서만 길게 요청한다고 원하는 유효 기간이 생기는 것은 아닙니다. 인증서 저장소에 새 항목이 있는지뿐 아니라 서비스가 실제로 제시하는 항목도 확인하세요.
키 보호·백업·복구 계획을 작성합니다
CA 개인 키가 유출되면 개별 웹 서버 장애보다 훨씬 넓은 신뢰 범위에 영향을 줍니다. 필요하면 하드웨어 보안 모듈(HSM), 분리된 관리 경로와 역할 분담을 검토합니다. 백업은 데이터베이스뿐 아니라 키·구성·정책·배포 정보를 포함하는 지원되는 절차로 설계하고 접근을 제한합니다.
- 인증서가 필요한 서비스·장치·사용자 수와 용도를 목록으로 만듭니다.
- 기존 PKI 활용 또는 새 구축의 이유와 책임자를 정합니다.
- CA 구조·키 보호·템플릿·등록 권한·신뢰 배포를 설계합니다.
- 폐기 정보 제공·갱신 알림·백업·격리 복구 절차를 정합니다.
- 별도 시험 환경에서 발급·이름 검증·갱신·폐기·복구를 확인한 뒤 도입을 결정합니다.
이 문서의 결과물은 CA 설치가 아니라 검토표와 설계 결정입니다. 시험 루트를 실제 단말 전체에 배포하거나 강좌의 DC1에 바로 CA를 설치하지 않습니다. 구축을 결정했다면 담당자가 유지할 수 있는 운영 절차와 신뢰 제거·서비스 전환 계획까지 준비해야 합니다.
