인증서 생성

PEG 설치 과정에서 인증서를 만듭니다.

전제 조건

두 가지 옵션 중 하나를 사용하여 인증서를 생성할 수 있습니다.
두 경우 모두 다음이 필요합니다.
  • 고유 ID(UID): 실행하는 각 PEG VM에는 고유한 ID가 있어야 합니다. UID는 다음 기준을 충족하는 한 원하는 대로 정의할 수 있습니다
    • 길이가 18자 이하
    • a에서 z까지의 문자, 0에서 9까지의 숫자 또는 하이픈만 포함합니다.
    • 하이픈으로 시작하거나 끝나서는 안 됩니다.
    • 연속으로 하이픈을 포함하지 않아야 합니다.
    • 팁: UID를 쉽게 만들려면 온라인 GUID 생성기에서 생성된 GUID의 마지막 18자를 가져옵니다.
  • PEG DNS 이름에 사용할 apex 도메인(예: example.com)

옵션 2 - 자체 키 및 인증서 생성

PEG를 배포하기 전에 키와 인증서를 만드는 방법을 알아보십시오.

키 및 인증서는 Base64 PEM 형식이어야 합니다(일부 시스템에서는 키 형식의 경우 openssl 또는 PKCS #8이라고 함). 일반 태스크 - 인증서 생성에 따라 인증서를 생성합니다. 키는 비밀번호로 보호되면 안 됩니다. 또한 키가 일반 태스크 - 인증서 생성의 키 파일 이름 열에 있는 파일 이름과 일치하는지 확인합니다.

터미널에 붙여넣은 인증서가 소스 인증서와 정확히 일치하는지 확인하는 것이 중요합니다. 일부 애플리케이션에서는 복사 및 붙여넣기 중에 파일에 숨겨진 문자가 추가될 수 있습니다. 문제를 방지하려면 다음 단계에 따라 도움을 받으십시오.

  • 파일 콘텐츠 확인: 파일에 콘텐츠를 붙여넣은 후 텍스트 편집기(예: nano, vim 또는 gedit)를 사용하여 파일 끝에 원하지 않는 문자가 있는지 확인합니다.
  • 리디렉션이 있는 에코 사용: 콘텐츠를 직접 붙여넣는 대신 리디렉션이 있는 에코를 사용하여 파일을 만듭니다. 이렇게 하면 숨겨진 문자의 위험이 최소화됩니다.
  • scp를 사용하여 파일을 로컬 시스템에서 원격 인스턴스로 복사하십시오.

일반 태스크 - 인증서 생성

Base64 PEM 인증서를 만드는 방법을 알아봅니다.

인증서를 생성할 때 다음과 같이 매핑된 도메인 이름 및 파일 이름을 사용하여 6개의 서버 Base64 PEM 인증서(일부 시스템에서는 openssl 형식이라고 함)를 생성합니다. 여기서 UID는 Process Discovery에서 제공하고 apex domain은 PEG에 사용할 apex 도메인입니다. 생성하는 각 인증서에는 전체 체인이 아닌 리프 인증서만 포함되어야 합니다.

표 1. 인증서 파일 이름에 도메인 이름 매핑
도메인 인증서 파일 이름 키 파일 이름(자체 키를 생성한 경우에만 필요)
analytics-fiq-<UID>.<apex domain> analytics-cert.pem analytics-key.pem
proxy-fiq-<UID>.<apex domain> proxy-cert.pem proxy-key.pem
storage-fiq-<UID>.<apex domain> storage-cert.pem storage-key.pem
st-fiq-<UID>.<apex domain> st-cert.pem st-key.pem
dlp-fiq-<UID>.<apex domain> dlp-cert.pem dlp-key.pem
es-fiq-<UID>.<apex domain> es-cert.pem es-key.pem
klite-fiq-<UID>.<apex domain> klite-cert.pem klite-key.pem
주: 모든 SAN에 대해 하나의 인증서를 생성할 수 있습니다. 키를 생성하는 경우 필요에 따라 키를 하나만 생성할 수도 있습니다. 그러나 이전에 표시된 대로 이름이 지정된 해당 인증서 사본 7개와 해당 키 사본 7개(키를 생성한 경우)가 있는지 확인해야 합니다. 와일드카드 인증서를 생성하지 마십시오.

고려 사항

PEG 설치를 위한 인증서를 생성할 때 다음 고려 사항을 검토하십시오.
  • 와일드카드 인증서는 허용되지 않습니다. PEG 배포에는 와일드카드 인증서를 사용할 수 없습니다. 각 인증서는 특정 도메인 이름을 사용하여 각 서비스에 대해 개별적으로 생성되어야 합니다.
  • 인증서는 전 세계적으로 유효하지 않습니다. 내부 CA에서 생성한 인증서는 외부 시스템에서 전 세계적으로 신뢰받지 못하므로 모든 클라이언트 장치나 서비스에서 수동으로 신뢰 여부를 지정해야 합니다.
  • 인증서 수동 검증: 인증서는 각 배포 단계에서 수동으로 검증하여 정확하고 전송 중에 손상되거나 변조되지 않았는지 확인해야 합니다.
  • 수동 인증서 전송: 인증서는 VM(가상 머신)에 수동으로 복사해야 하며, 복사하는 동안 파일이 변경되거나 작업이 잘못 수행될 경우 잠재적인 오류가 발생할 수 있습니다.
  • 모든 컴퓨터에서 유효한 인증서 확인: 모든 인증서가 유효하고 이러한 인증서로 보호되는 서비스에 액세스해야 하는 모든 컴퓨터에 올바르게 설치되어 있는지 확인해야 합니다.
  • 자동 인증서 갱신 없음: 내부 인증서는 글로벌 CA 시스템과 통합되지 않으므로 자동화된 갱신 프로세스가 없습니다. 관리자는 서비스 중단을 방지하기 위해 인증서가 만료되기 전에 수동으로 추적하고 갱신해야 합니다.
  • 신뢰를 위한 추가 구성: PEG 서비스에 액세스하는 각 클라이언트나 시스템은 내부 CA 인증서를 신뢰하도록 수동으로 구성해야 하며, 이를 위해 루트 인증서를 설치하거나 보안 설정을 조정해야 할 수도 있습니다.
  • 인적 오류의 위험: 인증서 생성, 검증 및 배포 과정이 수동으로 이루어지므로 잘못된 파일 이름, 잘못된 구성 또는 누락된 인증서 등 인적 오류가 발생할 가능성이 높습니다.
  • 제한된 취소 및 감사: 내부 CA 설정에는 정교한 폐기 메커니즘(인증서 폐기 목록이나 OCSP 등)이 부족하여 손상되거나 만료된 인증서를 폐기하고 해당 인증서의 사용을 효과적으로 감사하기가 어려울 수 있습니다.
  • 확장의 어려움: 시스템이 확장되면 여러 VM(가상 머신)과 환경에서 많은 수의 인증서를 수동으로 관리하는 것이 어려워질 수 있으며, 일관성을 보장하기 위한 전담 프로세스가 필요합니다.