AWS Client VPN: 클라이언트 인증서는 어떤 CA가 발급해야 할까?
기존 CA, 자체 운영 발급자, AWS Private CA는 작업을 서로 다르게 나눕니다. 출시 전에 누가 클라이언트 인증서를 승인하고 갱신하고 폐기할지 정하십시오.
AWS Client VPN의 인증서 문제는 제품 질문으로 던져지지만 실제로는 운영 질문입니다. 흔한 세 가지 구성 중 어느 것이든 작동하는 터널은 유지됩니다. 기존 조직 CA, 전용 자체 운영 발급자, 또는 AWS Private CA입니다. 이들은 누가 기기를 승인하는지, 누가 서명 키를 보관하는지, 그리고 불편한 시간에 노트북이 사라졌을 때 누가 답하는지에서 다릅니다. 책임자를 지명할 수 있는 옵션을 고르십시오.
AWS는 인증서 인증에 Private CA를 요구하지 않습니다. 서버 인증서를 ACM에 두는 것은 배포 단계이지 등록 절차가 아닙니다.
결정하는 세 가지 조건
세 가지 조건이 선택지를 명확히 가릅니다. 승인된 기기 등록 절차가 이미 있는지, 백업과 지정된 책임자를 갖춘 서명 키를 운영할 수 있는지, 그리고 폐기가 엔드포인트에 어떻게 도달하는지입니다. 각각은 예 또는 아니오에 가깝고, 첫 번째 아니오가 보통 아키텍처를 결정합니다.
순서대로 다루십시오. 곧바로 비용 비교로 뛰어드는 것이 팀이 관리형 CA를 안고 다음 노트북 인증서를 누가 발급하는지 아무도 모르게 되는 방식입니다.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
첫 번째 조건: 등록이 이미 있는가?
조직이 이미 승인된 기기 등록 경로를 갖춘 CA를 운영하고 있다면, 그 CA에서 Client VPN 클라이언트 인증서를 발급하는 것이 가장 짧은 경로입니다. 승인, 절차, 자산 기록이 이미 있습니다. 그 계층 아래의 전용 하위 발급자가 일반 발급 CA보다 보통 낫습니다. VPN에 자체 신뢰 경계와 자체 폐기 목록을 주기 때문입니다. 그 목록은 계층의 나머지와 분리해 두어 VPN 사고가 PKI 전체의 변경을 강요하지 않게 하십시오.
그런 절차가 없다면 진짜 질문은 그것을 만들고 싶은지입니다. CA는 시작하기 쉽고 잘못 소유하면 비쌉니다.
두 번째 조건: 서명 키를 운영할 수 있는가?
자체 운영 발급자는 문서화된 가져오기 모델로 작동하며, EasyRSA나 작은 내부 도구가 자료를 만들 수 있습니다. 명령을 실행하는 것이 어려운 부분이 아닙니다. 어려운 부분은 서명 키의 오프라인 백업, 누군가 실제로 시험한 복구 경로, 휴가 중이 아닌 책임자, 그리고 키가 클라이언트 번들이나 구성 내보내기에 절대 들어가지 않는다는 규칙입니다. 첫 인증서를 발급하기 전에 절차로 적어 두십시오, 첫 사고 이후가 아니라.
AWS Private CA는 그 보관을 관리형 서비스로 옮깁니다. 등록 정책, 승인 단계, 또는 기기로의 인증서 전달을 옮기지는 않습니다.
세 번째 조건: 폐기는 어떻게 도달하는가?
Client VPN은 엔드포인트로 가져오는 클라이언트 인증서 폐기 목록을 사용합니다. 인증서 수명 주기 안내서에 설명된 대로입니다. PKI의 다른 곳에 CRL을 게시해도 그것이 서비스로 밀려 들어가지는 않습니다. 가져오기는 별도의 예약된 작업이며, 만료된 목록은 조용히 나빠지는 대신 연결을 멈춥니다. 갱신을 인증서 자체와 같은 달력에 두십시오.
그렇게 하면 갱신은 책임자가 있는 모니터링 항목이 되고, 출시 때 끝나는 작업이 아닙니다. 메커니즘이 정말 필요해지기 전에 테스트 인증서 하나를 처음부터 끝까지 폐기하십시오.
어떤 옵션도 없애지 못하는 것
모든 옵션은 여전히 독립적으로 관리되는 기기마다 별도의 클라이언트 인증서와 키를 필요로 합니다. 모두에게 단일 신원을 나눠 주는 자습서는 자습서의 지름길이며, 선택적 폐기도 불가능하게 만듭니다.
ACM으로 가져온 서버 인증서에는 관리형 갱신이 없으므로 책임자가 대체 인증서를 구해 다시 가져오고, 그다음 엔드포인트가 이를 채택했는지 확인해야 합니다. 서버 인증서를 갱신해도 노트북에 이미 있는 클라이언트 자격 증명은 갱신되지 않습니다. 이들은 별도의 달력을 가진 별도의 수명 주기입니다.
무엇이든 발급하기 전에 서비스가 받아들이는 키 유형과 확장을 확인하십시오. CA가 알고리즘을 지원한다고 해서 엔드포인트가 그것을 받아들인다는 뜻은 아닙니다.
출시 전에 선택한 워크플로로 갱신 하나와 클라이언트 제거 하나를 실행하고, 어떤 자격 증명이 바뀌었는지, 어떤 엔드포인트 설정이 바뀌었는지, 활성 세션에 무슨 일이 있었는지 적어 두십시오. 그 연습이 명확한 책임자 없이 끝난다면 발급자 선택은 끝난 것이 아닙니다.