목차/07. 공개 키 기반구조(PKI)

07공개 키 기반구조(PKI)공개 키 기반구조(PKI)

VPN 피어가 서로를 믿는 가장 강력한 방법은 인증서 입니다. PKI(Public Key Infrastructure) 는 공통으로 신뢰하는 인증 기관(CA)을 통해 서로 신뢰 관계를 맺는 토대입니다. 이 장은 인증서로 신뢰가 성립하는 원리부터, 다양한 CA 구성, 외부 CA를 신뢰시키는 법, 엔티티를 등록(enrollment)하는 절차, 인증서를 검증하고 폐기 상태를 확인하는 방법, CA 인증서 롤오버, 그리고 OCSP·CRL 구성까지 Check Point R82 Site-to-Site VPN에서 PKI를 다루는 모든 작업을 빠짐없이 풀어 정리합니다. 원문이 표·목록·절차로 나열한 내용도 그대로 담되, 왜 그렇게 하는지를 함께 설명합니다.

서로 다른 PKI 솔루션과의 연동이 필요한 이유

X.509 기반 PKI는 서로가 같은 인증 기관(CA, Certificate Authority) 을 신뢰한다는 사실을 바탕으로 엔티티끼리 신뢰 관계를 맺을 수 있게 해 주는 기반 구조입니다. 신뢰받는 CA는 어떤 엔티티에게 그 엔티티의 공개 키가 담긴 인증서 를 발급합니다. 그 CA를 믿는 다른 피어들은 CA의 서명을 검증할 수 있으므로 그 인증서도 신뢰 할 수 있고, 인증서에 담긴 정보 — 그중에서도 가장 중요한 "엔티티 ↔ 공개 키"의 연결 — 을 신뢰하고 활용합니다.

IKE 표준은 강력한 인증이 필요한 VPN 환경에서 PKI를 사용할 것을 권장 합니다.

VPN 터널 수립에 참여하는 Security Gateway는 반드시 RSA 키 쌍과, 신뢰받는 CA가 발급한 인증서 를 가지고 있어야 합니다. 이 인증서에는 해당 모듈의 신원, 공개 키, CRL 조회 정보(CRL retrieval details) 가 담기고, CA가 서명합니다.

두 엔티티가 VPN 터널을 맺으려 할 때는, 각자 자기 개인 키(private key) 로 서명한 임의 정보(random information)와, 공개 키가 든 인증서를 상대에게 제시 합니다. 이 인증서가 Security Gateway 사이에 신뢰 관계를 세우는 열쇠입니다. 각 Security Gateway는 상대 Security Gateway의 공개 키로 서명된 정보의 출처를 확인 하고, CA의 공개 키로 그 인증서가 진짜인지(authenticity)를 검증 합니다. 한마디로, 검증을 통과한 인증서로 피어를 인증 하는 것입니다.

Check Point의 모든 Security Management Server 배포본에는 ICA(Internal Certificate Authority, 내부 인증 기관) 가 포함되어 있어, 자신이 관리하는 VPN 모듈들에게 VPN 인증서를 발급 합니다. 이 ICA가 발급한 VPN 인증서 덕분에, 같은 관리 서버가 관리하는 모듈끼리는 VPN 정의가 매우 간단해집니다.

그러나 다른 PKI 솔루션과의 연동이 필요해지는 상황도 생깁니다. 예를 들면 다음과 같습니다.

  • 외부 Security Management Server 가 관리하는 Security Gateway와 VPN을 맺어야 하는 경우 — 예컨대 상대 Security Gateway가 Check Point 제품을 쓰는 다른 조직 에 속해 있고, 그 인증서가 그 조직 자신의 Security Management Server ICA로 서명된 경우입니다.
  • 비-Check Point VPN 엔티티 와 VPN을 맺어야 하는 경우 — 이때 상대의 인증서는 서드파티(third-party) CA가 서명합니다.
  • 조직이 어떤 이유로든 자사 Security Gateway의 인증서를 서드파티 CA 로 생성하기로 결정한 경우 입니다.

다양한 PKI 솔루션 지원

개요

Check Point Security Gateway는 VPN 환경에 PKI를 연동하는 여러 시나리오를 지원합니다.

  • 단일 VPN 터널에서 복수 CA 지원(Multiple CA Support for Single VPN Tunnel) — 두 Security Gateway가 서로 다른 ICA가 서명한 인증서 를 각각 제시하는 경우입니다.
  • 비-ICA CA 지원(Support for non-ICA CAs) — ICA뿐 아니라, Security Gateway는 다음 인증 기관도 지원합니다.
    • External ICA — 다른 Security Management Server의 ICA
    • 그 밖의 OPSEC 인증(OPSEC certified) PKI 솔루션
  • CA 계층 구조(CA Hierarchy) — CA는 보통 여러 CA가 하나의 루트 권한 CA(root authority CA) 아래에 종속되는 계층 구조 로 배치됩니다. 종속 CA(Subordinate CA) 란 다른 CA에 의해 인증된 CA를 말합니다. 종속 CA는 또 다른, 더 하위의 CA에게 인증서를 발급할 수 있고, 이렇게 인증 체인(certification chain) 또는 계층 이 만들어집니다.

PKI와 Remote Access VPN 사용자

Check Point Suite는 Security Gateway뿐 아니라 Remote Access VPN 사용자에 대해서도 인증서를 지원 합니다. 자세한 내용은 R82 Remote Access VPN Administration Guide 를 참고하세요.

PKI 배포와 Site to Site VPN

다음은 몇 가지 대표적인 CA 배포 예시입니다.

단순 배포 — 내부 인증 기관(Internal Certificate Authority) 같은 Security Management Server가 관리하는 Security Gateway들 사이에 VPN 터널을 맺을 때는, 각 피어가 그 관리 서버의 ICA가 발급한 인증서 를 가집니다. 가장 단순하고 자동화된 경우입니다.

외부 Security Management Server의 CA 어떤 Check Point Security Gateway가 외부 Security Management Server 에 의해 관리될 때(예: 다른 조직의 VPN 모듈과 터널을 맺을 때), 각 피어는 자기 쪽 Security Management Server의 ICA가 서명한 인증서 를 가집니다. 즉 Security Management Server "A"가 Security Management Server "B"용 인증서를 발급하고, 다시 "B"가 Security Gateway "B"용 인증서를 발급하는 식의 체인이 됩니다.

p.101
p.101

인터넷을 통해 제공되는 CA 서비스 Security Gateway의 인증서를 인터넷으로 접근 가능한 서드파티 CA 가 발급하는 경우, 등록(registration)이나 폐기(revocation) 같은 CA 작업은 보통 HTTP 양식(form) 을 통해 수행합니다. CRL은 CRL 저장소 역할을 하는 HTTP 서버 에서 가져옵니다.

p.101
p.101

이 시나리오에서 Security Gateway A와 B는 웹으로 접근 가능한 PKI 서비스 제공자 로부터 인증서를 받습니다. 또한 외부 CA가 발급한 인증서는 같은 Security Management Server가 관리하는 Security Gateway들이 검증 용도로 사용 할 수도 있습니다.

LAN 상의 CA 상대 VPN Security Gateway의 인증서를 LAN 내부의 서드파티 CA 가 발급한 경우, CRL은 보통 내부 LDAP 서버 에서 가져옵니다.

외부 CA 신뢰하기

p.102
p.102

설명

신뢰 관계는 VPN 터널 수립의 결정적인 전제 조건 입니다. 그런데 신뢰 관계는 상대 인증서를 서명한 CA가 "신뢰됨(trusted)" 상태일 때만 성립합니다. CA를 신뢰한다는 것은 그 CA 자신의 인증서를 받아 검증하는 것 을 의미합니다. CA의 인증서가 일단 검증되고 나면, 그 인증서에 담긴 정보와 공개 키를 이용해 그 CA가 발급한 다른 인증서들을 받아 오고 검증 할 수 있게 됩니다.

ICA 는 자신을 운영하는 Security Management Server가 관리하는 모든 모듈이 자동으로 신뢰 합니다. 반면 외부 CA — 심지어 다른 Check Point Security Management Server의 ICA라도 — 는 자동으로 신뢰되지 않습니다. 따라서 모듈은 먼저 외부 CA의 인증서를 받아 검증 해야 하며, 외부 CA는 자신의 인증서를 Security Management Server로 가져올(import) 수 있는 방법을 제공해야 합니다.

외부 CA가 다음 중 어느 것이냐에 따라 처리가 달라집니다.

  • 외부 Security Management Server의 ICA 인 경우 — R82 Security Management Administration Guide 를 참고하세요.
  • OPSEC 인증 CA 인 경우 — Servers and OPSEC Applications 탭의 CA 옵션을 사용해 CA를 정의하고 그 인증서를 받습니다.

관리 대상 엔티티 등록하기

종속 인증 기관(Subordinate Certificate Authorities)

종속 CA(Subordinate CA) 는 다른 CA에 의해 인증된 CA 입니다. 종속 CA는 또 다른 더 하위의 CA에게 인증서를 발급할 수 있고, 이렇게 인증 체인 또는 계층 이 형성됩니다. 계층의 맨 위에 있는 CA가 루트 권한(root authority) 또는 루트 CA(root CA) 이며, 루트 CA의 하위 CA들을 종속 인증 기관 이라 부릅니다.

Servers and OPSEC Applications 탭의 CA 옵션에서, CA를 Trusted(신뢰됨) 또는 Subordinate(종속) 중 하나로 정의할 수 있습니다. 단, 종속 CA는 OPSEC 유형이며 신뢰됨(trusted) 상태가 아닙니다.

등록(Enrollment)이란

등록(Enrollment) 이란 어떤 엔티티를 위해 CA에 인증서를 요청하고 받아 오는 과정 을 말합니다.

등록 과정은 키 쌍(key pair) 생성 으로 시작합니다. 그런 다음 공개 키와 모듈에 관한 추가 정보로 인증서 요청(certificate request)을 만듭니다. 이 인증서 요청의 형식과 이후 등록 절차는 CA의 종류에 따라 달라집니다.

  • 내부 관리(internally managed) Security Gateway 의 경우가 가장 단순합니다. ICA가 Security Management Server 장비에 있으므로 등록 과정이 자동으로 완료 됩니다.
  • OPSEC 인증 CA 에서 인증서를 받을 때는, Security Management Server가 모듈 정보와 공개 키를 받아 PKCS#10 요청 으로 인코딩 합니다. 이 요청(OPSEC 인증서의 경우 SubjectAltName 과 Extended Key Usage 확장을 포함할 수 있음)은 관리자가 직접 수동으로 CA에 전달 합니다. CA가 인증서를 발급하면, 관리자는 그 인증서를 Security Management Server로 가져와 과정을 마무리 합니다.

또한 자동 등록(Automatic Enrollment) 으로도 Security Gateway 인증서를 받을 수 있습니다. 자동 등록을 쓰면 커뮤니티 내 어떤 Security Gateway든, 신뢰받는 CA에 인증서 요청을 자동으로 보낼 수 있습니다. 자동 등록이 지원하는 프로토콜은 다음과 같습니다.

  • SCEP
  • CMPV1
  • CMPV2

인증서의 검증

설명

엔티티가 다른 엔티티로부터 인증서를 받으면, 다음을 반드시 수행해야 합니다.

  1. 인증서 서명 검증 — 그 인증서가 신뢰받는 CA가 서명한 것인지 확인합니다. 만약 신뢰받는 CA가 직접 서명한 게 아니라 그 CA의 하위(subsidiary)가 서명 했다면, 신뢰받는 CA까지 이어지는 CA 인증서 경로(path)를 따라가며 검증 합니다.
  2. 인증서 체인 만료 검증 — 인증서 체인이 만료되지 않았는지 확인합니다.
  3. 인증서 체인 폐기 검증 — 인증서 체인이 폐기되지 않았는지 확인합니다. 이를 위해 CRL 을 가져와, 검증 중인 인증서의 일련번호(serial number)가 폐기된 인증서 목록에 들어 있지 않은지 확인합니다.

여기에 더해, VPN은 그 상황에서 인증서를 쓰는 것이 유효한지 도 검증합니다. 구체적으로 다음을 확인합니다.

  • 인증서가 요구된 동작을 수행할 권한이 있는지 — 예를 들어, 데이터에 서명하기 위해(예: 인증) 개인 키가 필요한 경우, 인증서에 KeyUsage 확장이 있다면 그 동작이 허용되는지 확인합니다.
  • 피어가 협상에서 올바른 인증서를 사용했는지 — 외부에서 관리되는 모듈과 VPN 터널을 만들 때, 관리자는 신뢰하는 CA 중에서도 특정 CA가 서명한 인증서만 받아들이도록 결정할 수 있습니다. (또한 Distinguished Name(DN) 같은 특정 세부 정보를 가진 인증서만 받아들이는 것도 가능합니다.)

폐기 확인(Revocation Checking)

인증서의 상태를 판단하는 데 쓸 수 있는 두 가지 방법이 있습니다.

  1. OCSP(Online Certificate Status Protocol)
  2. CRL

OCSP OCSP(Online Certificate Status Protocol) 는 애플리케이션이 인증서의 상태를 식별 할 수 있게 해 줍니다. OCSP는 CRL보다 더 시의적절한(timely) 폐기 정보 를 얻는 데 쓸 수 있고, 추가 상태 정보를 얻는 데도 활용할 수 있습니다. OCSP 클라이언트가 OCSP 서버에 상태 요청을 보내면, 서버가 응답을 줄 때까지 해당 인증서의 수락은 보류 됩니다.

OCSP를 사용하려면 루트 CA가 CRL 대신 이 방법을 쓰도록 구성 해야 합니다. 이 설정은 종속 CA들에게 상속 됩니다. (구성 방법은 아래 OCSP 구성 참고.)

CRL VPN은 CRL을 HTTP 서버 또는 LDAP 서버 에서 가져올 수 있습니다.

  • CRL 저장소가 HTTP 서버 인 경우, 모듈은 인증서의 CRL Distribution Point 확장에 게시된 URL 을 사용해 CRL 저장소에 HTTP 연결을 열고 CRL을 가져옵니다.
  • CRL 저장소가 LDAP 서버 인 경우, VPN은 정의된 LDAP account unit 중 하나에서 CRL을 찾으려 시도합니다. 이 경우 LDAP account unit이 정의되어 있어야 합니다. CRL Distribution Point 확장이 있으면 CRL의 DN(디렉터리에서 CRL이 게시된 항목) 또는 LDAP URI 가 거기 게시됩니다. 확장이 없으면, VPN은 LDAP 서버에서 CA 자신의 항목(entry)에서 CRL을 찾으려 시도합니다.

CRL 사전 인출 캐시(CRL Prefetch-Cache)

CRL을 가져오는 데는 (전체 IKE 협상 과정에 비해) 시간이 오래 걸릴 수 있으므로, VPN은 CRL을 CRL 캐시 에 저장 해 두어 이후 IKE 협상에서 매번 CRL을 다시 가져오지 않도록 합니다.

캐시는 다음 시점에 사전 인출(pre-fetch) 됩니다.

  • 2시간마다
  • 정책 설치(policy installation) 시
  • 캐시가 만료될 때

사전 인출이 실패해도 이전 캐시는 지워지지 않습니다.

관리자는 캐시 내 CRL의 수명을 줄이거나, 캐시 사용 자체를 취소 할 수 있습니다. 단, CRL 캐시 동작을 취소하면 이후 모든 IKE 협상마다 CRL을 다시 가져와야 하므로 VPN 터널 수립이 상당히 느려집니다. 이런 성능 영향 때문에, 지속적인 CRL 인출을 요구할 만큼 보안 수준이 높은 경우에만 CRL 캐싱을 끄는 것을 권장 합니다.

CRL 사전 인출 메커니즘의 특별 고려 사항 CRL 사전 인출 메커니즘은 가장 최신의 폐기 목록을 얻으려 "최선의 노력(best effort)" 을 합니다. 그러나 cpstop, cpstart 명령을 실행한 뒤에는 캐시가 더 이상 갱신되지 않습니다. Security Gateway는 기존 CRL이 유효한 동안에는 (CA에 더 최신 CRL이 있더라도) 계속 옛 CRL을 사용 합니다. 사전 인출 캐시 메커니즘은 옛 CRL이 만료되고 새 CRL을 CA에서 가져온 뒤에야 정상 동작으로 돌아옵니다.

cpstop/cpstart 이후에도 CRL이 즉시 갱신되어야 한다면 다음 중 하나를 수행합니다.

  • cprestart 명령을 실행한 뒤, 캐시를 비우는 vpn crl_zap 명령을 실행합니다.
  vpn crl_zap
  • 또는 SmartConsole 에서 다음을 수행합니다.
    1. Menu > Global properties > Advanced > Configure 를 클릭합니다.
    2. Certificates and PKI properties 를 클릭합니다.
    3. flush_crl_cache_file_on_install 을 선택합니다.
    4. OK 를 클릭합니다.
    5. Access Control Policy 를 설치합니다.

새 정책이 설치되면 캐시가 비워지고(flush), 새 CRL은 필요 시(on demand) 가져옵니다.

CRL 유예 기간(CRL Grace Period)

CRL 저장소와의 일시적 연결 끊김 이나, 장비 간 시계(clock)의 미세한 차이 때문에 유효한 CRL이 무효로 간주될 수 있고, 그러면 인증서까지 무효가 될 수 있습니다. VPN은 CRL 유예 기간(CRL Grace Period) 을 두어 이 문제를 해결합니다. 이 기간 동안에는 CRL 유효 시간상으로는 유효하지 않더라도 CRL을 유효한 것으로 간주 합니다.

인증 기관에 등록하기

ICA 는 내부에서 관리되며 VPN 가능한(VPN-capable) 모든 엔티티에 대해 인증서를 자동으로 발급 합니다. 즉, 관리자가 Security Gateway나 Cluster 객체에서 (General Properties 페이지 > Network Security 탭에서) IPsec VPN 소프트웨어 블레이드를 켜기만 하면 됩니다.

OPSEC PKI CA 나 External Check Point CA 에서 인증서를 받는 과정은 두 경우가 동일 합니다.

OPSEC 인증 PKI로 수동 등록하기

PKCS#10 인증서 요청을 만들려면:

  1. Certificate Authority 객체 를 만듭니다.
  2. 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
  3. 해당 Security Gateway 또는 Cluster 객체 를 더블 클릭합니다.
  4. 왼쪽 트리에서 General Properties 를 클릭하고, IPsec VPN 소프트웨어 블레이드가 켜져 있는지 확인 합니다.
  5. 왼쪽 트리에서 IPsec VPN 을 클릭합니다.
  6. Repository of Certificates Available to the Gateway 섹션에서 Add 를 클릭합니다. → Certificate Properties 창이 열립니다.
  7. Certificate Nickname 필드에 문자열을 입력합니다. 이 별칭(nickname)은 식별자일 뿐, 인증서 내용과는 무관 합니다.
  8. CA to enroll from 드롭다운에서, 인증서를 발급할 Certificate Authority 를 선택합니다.
  1. Key pair generation and storage 섹션에서 알맞은 방식을 선택합니다.
방식동작
Store keys on the Security Management server인증서 생성이 관리 서버와 해당 CA 사이에서 전부 수행 됩니다. 키와 인증서는 정책 설치 시 Security Gateway(Cluster Member)로 안전하게 다운로드 됩니다.
Store keys on the Module관리 서버가 Security Gateway(또는 Cluster Member)에게 키를 직접 만들게 지시 하고, 인증서 요청 생성에 필요한 재료만 받습니다. 정책 설치 시에는 인증서만 Security Gateway(Cluster Member)로 다운로드 됩니다.
  1. Generate 를 클릭합니다. → Generate Certificate Properties 창이 열립니다.
  2. 알맞은 DN 을 입력합니다. 인증서에 최종적으로 나타나는 DN은 CA 관리자가 결정 합니다. 인증서에 Subject Alternate Name 확장이 필요하면 Define Alternate Name 을 선택합니다. 이제 공개 키와 DN으로 PKCS#10 인증서 요청을 DER 인코딩 합니다.
  1. Repository of Certificates Available to the Gateway 섹션에 인증서가 나타나면:
    1. 이 인증서를 선택합니다.
    2. View 를 클릭합니다.
    3. Certificate View 창에서: ① 창 안을 클릭하고, ② 전체 텍스트를 선택하고(CTRL+A, 또는 마우스 우클릭 후 Select All), ③ 전체 텍스트를 복사하고(CTRL+C, 또는 우클릭 후 Copy), ④ 그 텍스트를 메모장 같은 일반 텍스트 편집기에 붙여넣고, ⑤ OK 를 클릭합니다.
  2. 인증서 정보를 CA 관리자에게 전달 합니다. 이제 CA 관리자가 인증서 발급 작업을 마무리해야 합니다. CA마다 방식이 다르며(예: 사용자용 일반 양식이 아닌 고급 등록 양식), 발급된 인증서는 이메일 등 다양한 방식으로 전달될 수 있습니다.
  3. CA 관리자로부터 인증서가 도착하면, 그 인증서를 Certificate Authority 객체에 저장 해야 합니다.
    1. SmartConsole에서 Objects > Object Explorer 를 클릭합니다(또는 CTRL+E).
    2. 왼쪽 트리에서 Servers 를 클릭합니다.
    3. 해당 Certificate Authority 객체 를 더블 클릭합니다.
    4. OPSEC PKI 탭을 클릭합니다.
    5. Certificate 섹션에서 Get 을 클릭합니다.
    6. 인증서 파일을 저장한 위치로 이동합니다.
    7. 인증서 파일을 선택하고 Open 을 클릭합니다.
    8. 인증서 세부 정보가 정확하면 OK 를 클릭해 이 인증서를 수락합니다.
    9. OK 를 클릭해 Certificate Authority Properties 창을 닫습니다.
    10. Object Explorer 창을 닫습니다.
  4. SmartConsole 세션을 게시(Publish) 합니다.

인증 기관으로 자동 등록하기

Certificate Authority 객체의 OPSEC PKI 탭에서:

  1. Automatically enroll certificate 옵션을 선택합니다.
  2. 알맞은 프로토콜(scep 또는 cmp)을 선택합니다.

그런 다음 아래 절차를 따릅니다.

  1. 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
  2. 해당 Security Gateway 또는 Cluster 객체 를 더블 클릭합니다.
  3. 왼쪽 트리에서 General Properties 를 클릭하고, IPsec VPN 소프트웨어 블레이드가 켜져 있는지 확인합니다.
  4. 왼쪽 트리에서 IPsec VPN 을 클릭합니다.
  5. Repository of Certificates Available to the Gateway 섹션에서 Add 를 클릭합니다. → Certificate Properties 창이 열립니다.
  6. Certificate Nickname 필드에 문자열을 입력합니다. (별칭은 식별자일 뿐 인증서 내용과 무관합니다.)
  7. CA to enroll from 드롭다운에서 인증서를 발급할 Certificate Authority를 선택합니다.
  1. Key pair generation and storage 섹션에서 알맞은 방식(Store keys on the Security Management server 또는 Store keys on the Module, 위 표와 동일)을 선택합니다.
  2. Generate 를 클릭하고 Automatic enrollment 를 선택합니다. → Generate Keys and Get Automatic Enrollment Certificate 창이 열립니다. Key Identifier 와 비밀 Authorization code 를 입력하고 OK 를 클릭합니다.
  3. Repository of Certificates Available to the Gateway 섹션에 인증서가 나타나면: ① 인증서를 선택하고, ② View 를 클릭하고, ③ Certificate View 창에서 Copy to Clipboard 또는 Save to File 을 클릭합니다.
  4. 요청을 CA 관리자에게 전달 합니다. CA마다 방식이 다르며(예: 웹사이트의 고급 등록 양식), 발급된 인증서는 이메일 등으로 전달될 수 있습니다. 인증서를 받으면 디스크에 저장합니다.
  5. 왼쪽 트리에서 IPsec VPN 을 클릭합니다.
  6. Repository of Certificates Available to the Gateway 섹션에서: ① 해당 인증서를 선택하고, ② Complete 를 클릭합니다.
  7. 발급된 인증서를 저장한 폴더로 이동해 인증서를 선택하고, 인증서 세부 정보를 확인 합니다.
  8. OK 를 클릭해 Security Gateway 또는 Cluster 객체를 닫습니다.
  9. SmartConsole 세션을 게시(Publish) 합니다.

종속 CA를 통한 등록

종속 CA를 통해 등록할 때는 다음에 유의합니다.

  • 인증서를 발급하는 종속 CA의 암호 를 입력 합니다. (계층 맨 위의 CA 암호가 아닙니다.)
  • 그 종속 CA는 신뢰받는 CA로 직접 이어져야 합니다.

PKI 관련 특별 고려 사항

내부 CA 사용 vs. 서드파티 CA 배포

내부 CA(Internal CA) 는 Site-to-Site VPN과 Remote Access VPN 같은 Check Point 애플리케이션에서 PKI를 손쉽게 쓸 수 있게 해 줍니다. 다만 관리자가, 이미 조직 안에서 운영 중인 CA (예: 보안 이메일이나 디스크 암호화에 쓰는 CA)를 계속 쓰고 싶어 할 수도 있습니다.

분산 키 관리 및 저장(DKM)

DKM(Distributed Key Management) 은 키 생성 단계에 추가 보안 계층 을 제공합니다. Security Management Server가 공개 키와 개인 키를 모두 생성해 정책 설치 중 모듈로 내려보내는 대신, 관리 서버가 모듈에게 자체적으로 공개·개인 키를 만들게 지시 하고, 모듈은 자신의 공개 키만 관리 서버로 전송 합니다. 개인 키는 하드웨어 저장 장치, 또는 하드웨어 저장을 모방하는 소프트웨어를 통해 모듈에 생성·저장 됩니다. 그 후 Security Management Server가 인증서 등록을 수행하고, 정책 설치 중 인증서가 모듈로 다운로드 됩니다. 개인 키는 절대 모듈을 떠나지 않습니다.

  • 로컬 키 저장(Local key storage)은 모든 CA 유형에서 지원 됩니다.
  • DKM은 모든 등록 방식에서 지원 됩니다. 기본 설정으로 구성하려면:
    1. SmartConsole에서 Menu > Global properties > Advanced > Configure 를 클릭합니다.
    2. 왼쪽 패널에서 Certificates and PKI properties 를 클릭합니다.
    3. use_dkm_cert_by_default 를 선택합니다.
    4. OK 를 클릭합니다.
    5. Access Control Policy 를 설치합니다.

PKI 작업 구성

CA 신뢰하기 — 단계별

이 절은 CA가 발급한 인증서를 신뢰하기 위한 전제 조건인, CA 자신의 인증서를 얻는 절차 를 설명합니다. CA를 신뢰하려면 CA 서버 객체를 정의 해야 합니다. 시나리오별로 필요한 구성 단계는 아래와 같습니다.

ICA 신뢰하기 VPN 모듈은 자신을 관리하는 Security Management Server의 ICA를 자동으로 신뢰 합니다. 추가 구성은 필요 없습니다.

외부에서 관리되는 CA 신뢰하기(Trusting an Externally Managed CA) 외부에서 관리되는 CA란 다른 Security Management Server의 ICA 입니다. 그 CA 인증서를 미리 받아 디스크에 저장 해 두어야 합니다. 신뢰를 맺으려면:

  1. Object Explorer 에서 New > Server > More > Trusted CA 를 클릭합니다. → Certificate Authority Properties 창이 열립니다.
  2. CA 객체의 Name 을 입력합니다.
  3. OPSEC PKI 탭으로 이동합니다.
  4. Get 을 클릭합니다.
  5. 저장해 둔 피어 CA 인증서가 있는 위치로 이동해 선택 합니다. → 인증서 세부 정보가 표시됩니다. 세부 정보가 올바른지, 그리고 CA 인증서의 SHA-1·MD5 지문(fingerprint)이 정확한지 확인 합니다.
  6. OK 를 클릭합니다.

OPSEC 인증 CA 신뢰하기(Trusting an OPSEC Certified CA) CA 인증서를 미리 받아 디스크에 저장 해 두어야 합니다.

CA 인증서는 Certificate Authority 객체의 CA 옵션으로 다운로드 하거나, 피어 관리자에게 미리 받아 두어야 합니다. 아래 단계대로 CA 객체를 정의합니다.

  1. Object Explorer 에서 New > Server > More > Trusted CA 또는 Subordinate CA 를 클릭합니다. → Certificate Authority Properties 창이 열립니다.
  2. CA 객체의 Name 을 입력합니다.
  3. OPSEC PKI 탭에서:
    • 자동 등록의 경우 Automatically enroll certificate 를 선택합니다.
    • Connect to CA with protocol 에서 CA에 연결할 프로토콜(SCEP, CMPV1, CMPV2 중 하나)을 선택합니다.
  1. Properties 를 클릭합니다.
    • SCEP 를 골랐다면, Properties for SCEP protocol 창에서 CA 식별자(예: example.com)와 Certification Authority/Registration Authority URL 을 입력합니다.
    • CMPV1 을 골랐다면, Properties for CMP protocol - V1 창에서 알맞은 IP 주소와 포트 번호 를 입력합니다(기본 포트는 829).
    • CMPV2 를 골랐다면, Properties for CMP protocol - V2 창에서 전송 계층으로 직접 TCP(direct TCP) 또는 HTTP 중 무엇을 쓸지 결정합니다.
  1. 이 CA로부터 CRL을 가져올 방법 을 선택합니다.
    • CA가 HTTP 서버에 CRL을 게시 하면 HTTP Server(s) 를 선택합니다. 이 CA가 발급하는 인증서에는 CRL Distribution Point 확장에 CRL 위치 URL이 들어 있어야 합니다.
    • CA가 LDAP 서버에 CRL을 게시 하면 LDAP Server(s) 를 선택합니다. 이 경우 LDAP Account Unit 도 정의 해야 합니다(LDAP 객체 정의는 R82 Security Management Administration Guide 참고). LDAP Account Unit Properties 창의 General 탭에서 CRL retrieval 을 체크 해야 합니다. 이 CA가 발급하는 인증서에는 CRL이 위치한 LDAP DN이 CRL Distribution Point 확장에 들어 있어야 합니다.
  2. Get 을 클릭합니다.
  3. SCEP가 구성되어 있으면 CA에 연결해 인증서를 가져오려 시도 합니다. 그렇지 않으면 저장해 둔 피어 CA 인증서 위치로 이동해 선택합니다. → 인증서를 가져옵니다. 세부 정보를 확인하고, CA 인증서의 SHA-1·MD5 지문을 표시·검증 합니다.
  4. OK 를 클릭합니다.

인증서 폐기(모든 CA 유형)

ICA가 발급한 인증서는 인증서 객체가 제거될 때 폐기 됩니다. 그 외의 경우, 인증서 폐기는 CA 객체의 Advanced 탭 옵션으로 CA 관리자가 제어 합니다. 또한 인증서를 Security Gateway에서도 제거 해야 합니다.

단, Security Management Server가 다른 설정으로 보아 그 인증서가 사용 중이라고 판단하면 인증서를 제거할 수 없습니다. 예를 들어, 그 Security Gateway가 하나 이상의 VPN 커뮤니티에 속해 있고 그 인증서가 Security Gateway의 유일한 인증서 인 경우입니다.

인증서를 제거하려면:

  1. 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
  2. Security Gateway / Cluster 객체 를 더블 클릭합니다.
  3. 왼쪽 패널에서 IPsec VPN 을 클릭합니다.
  4. Repository of Certificates Available to the Gateway 에서 해당 인증서를 선택하고 Remove 를 클릭합니다.
  5. OK 를 클릭합니다.
  6. Access Control policy 를 설치합니다.

인증서 복구 및 갱신(Certificate Recovery and Renewal)

인증서가 폐기되거나 만료되면, 새로 만들거나 기존 것을 갱신 해야 합니다. 손상되거나 만료된 인증서를 제거하면, 관리자의 개입 없이 자동으로 새 인증서 생성이 트리거 됩니다.

인증서를 수동으로 갱신하려면:

  1. 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
  2. Security Gateway / Cluster 객체 를 더블 클릭합니다.
  3. 왼쪽 패널에서 IPsec VPN 을 클릭합니다.
  4. Repository of Certificates Available to the Gateway 에서 해당 인증서를 선택하고 Renew 를 클릭합니다.
  5. OK 를 클릭합니다.
  6. Access Control policy 를 설치합니다.

CA 인증서 롤오버(CA Certificate Rollover)

CA Certificate Rollover 는 VPN 트래픽용 클라이언트·Security Gateway 인증서를 서명하는 데 쓰는 CA 인증서를, 전환 과정에서 기능 상실 위험 없이 교체(rollover) 할 수 있게 해 주는 VPN 기능입니다.

점진적 CA 인증서 롤오버를 위해, 이 기능은 Microsoft Windows CA 같은 서드파티 OPSEC 호환 CA가 생성한 여러 CA 인증서 를 VPN이 지원 하도록 합니다. 여러 CA 인증서가 있으면, 두 CA 인증서로 서명된 클라이언트·Security Gateway 인증서가 모두 인정되는 전환 기간 동안 점진적으로 인증서를 갈아탈 수 있습니다.

이미 인증서를 가진 CA에 인증서를 추가하면, 새 인증서는 Additional(추가) 로 정의되고 기존 최고 인덱스보다 1 큰 인덱스 번호 를 받습니다. 원래 인증서는 Main(주) 으로 정의됩니다. 제거할 수 있는 것은 Additional 인증서뿐 입니다. CA Certificate Rollover는 인증서를 추가·제거하고, 상태를 Additional↔Main으로 바꾸는 도구를 제공합니다.

CA 인증서 롤오버 관리 — 권장 워크플로 다음은 가장 흔한 시나리오의 권장 워크플로입니다(CLI 명령 전체 내용은 CA Certificate Rollover CLI 절 참고).

시작하기 전에: SmartConsole에서 여러 CA 인증서를 생성할 수 있는 서드파티 OPSEC 호환 CA(예: Microsoft Windows CA)를 정의 합니다. 그리고 주(main) CA 인증서를 생성해 SmartConsole에 정의 합니다.

새 CA 인증서로 롤오버하려면:

  1. 서드파티 CA에서 이전 CA 인증서와 다른 키 를 가진 두 번째 CA 인증서를 DER 형식(PEM은 미지원)으로 생성 합니다. 그 인증서를 Security Management Server로 복사합니다.
  2. Security Management Server의 명령줄에 접속합니다.
  3. Expert mode 로 로그인합니다.
  4. Security Management Server 데이터베이스의 서드파티 CA 정의에 새 CA 인증서를 추가합니다.
   mcc add <CA Name> <Certificate File>
  • <CA Name> 은 Security Management Server 데이터베이스에 정의된 CA의 이름 입니다.
    • <Certificate File> 은 인증서 파일 이름 또는 경로 입니다.
  1. 이제 새 CA 인증서가 additional #1 로 정의 되어야 합니다. mcc lca 또는 mcc show 명령으로 확인합니다.
   mcc lca
   mcc show
  1. SmartConsole에서 모든 Security Gateway에 Access Control Policy 를 설치 합니다. 그리고 새 추가 CA 인증서로 클라이언트 인증서를 서명 합니다.

CA 인증서 롤오버 CLI CA 인증서 롤오버는 VPN Multi-Certificate CA 명령인 mcc 로 수행합니다.

검증 과정에 매칭 기준 추가하기(Adding Matching Criteria)

외부에서 관리되는 VPN 엔티티의 인증서는 로컬 Security Management Server가 다루지 않지만, VPN 터널을 만들 때 피어가 특정 인증서를 제시하도록 구성 할 수는 있습니다.

구성:

  1. 외부에서 관리되는 VPN 엔티티의 VPN 페이지를 엽니다.
  2. Matching Criteria 를 클릭합니다.
  3. 피어가 제시할 것으로 기대하는 인증서의 특성을 고릅니다. 다음을 포함합니다.
    • 인증서를 발급한 CA
    • 인증서의 정확한 DN
    • 인증서의 Subject Alternate Name 확장에 나타나는 IP 주소 (이 IP 주소는 IKE 협상 중 VPN 모듈에 보이는 VPN 피어 자신의 IP 주소와 비교 됩니다.)
    • 인증서의 Subject Alternate Name 확장에 나타나는 이메일 주소

CRL 캐시 사용(CRL Cache Usage)

CRL 캐시의 동작을 취소하거나 변경하려면:

  1. Certificate Authority 객체의 Advanced 탭을 엽니다.
  2. CRL 캐시를 켜려면 Cache CRL on the Security Gateway 를 체크합니다. ICA의 경우 캐시를 끄면 안 됩니다. 일반적으로 모든 CA 유형에서 캐시를 켜 두는 것을 권장 하며, 엄격한 보안 요구로 CRL을 계속 가져와야 하는 경우에만(비-ICA에 한해) 캐시를 끄세요.
  1. CRL 캐시가 켜져 있으면, CRL을 만료 시 캐시에서 지울지, 아니면 (먼저 만료되지 않는 한) 고정된 기간 후 에 지울지 를 선택합니다. 두 번째 옵션은 CRL이 만료 시점보다 더 자주 발급될 수 있으므로 CRL을 더 자주 가져오도록 유도 합니다. 기본값은 24시간 후 캐시에서 CRL 삭제 입니다.

CRL 사전 인출 캐시 변경(Modifying the CRL Pre-Fetch Cache)

  1. SmartConsole에서 Menu > Global Properties > Advanced > Configure 를 클릭합니다.
  2. Certificates and PKI properties 를 클릭합니다.
  3. prefetch_crls_duration 필드에서 기간(duration)을 설정합니다.
  4. OK 를 클릭합니다.
  5. Access Control Policy 를 설치합니다.

CRL 유예 기간 구성(Configuring CRL Grace Period)

  1. SmartConsole에서 Menu > Global properties > VPN > Advanced 를 클릭합니다.
  2. CRL Grace Period 섹션에서 알맞은 시간을 설정합니다.
  3. OK 를 클릭합니다.
  4. Access Control Policy 를 설치합니다.

유예 기간은 지정된 CRL 유효 기간의 이전 과 이후 양쪽 모두에 대해 정의 할 수 있습니다.

OCSP 구성

OCSP를 사용하려면, CA 객체가 CRL 방법 대신 OCSP 폐기 정보 방법 을 쓰도록 구성 해야 합니다.

Database Tool(GuiDBEdit Tool) 로 ocsp_validation 필드의 값을 true 로 변경 합니다. true 로 설정하면 CA가 OCSP를 사용해 인증서의 유효성을 확인 합니다. 이 설정은 루트 CA에 구성하면 종속 CA들에게 상속 됩니다.

CA가 OCSP를 쓰도록 구성하려면 Database Tool(GuiDBEdit Tool)에서 작업하며, 자세한 지침은 sk37803 을 참고하세요.