iPad에 전용 VPN 클라이언트 인증서가 필요한가?

새 iPad가 팀에 합류하면 가장 빠른 길은 기존 클라이언트 인증서를 내보내 태블릿에 설치하는 것입니다. 이 방식은 누군가 퇴사하거나 기기를 잃어버리거나 어느 기기가 언제 연결했는지 묻는 감사가 필요해질 때까지 통합니다. 결정할 것은 인증서 파일이 아니라 각 기기를 개별적으로 승인하고 폐기할 수 있는지라는 ID입니다. 비용과 관리 노력이 답을 정하며 둘 다 보이는 것보다 작습니다.

공유 발급자, 분리된 ID

모든 기기는 같은 인증 기관을 신뢰하고 같은 게이트웨이에 연결하면서도 서로 다른 클라이언트 ID를 가질 수 있습니다. 발급자는 신뢰의 닻이고, ID는 서버가 그 주체를 정책에 매핑하는 키 쌍입니다. 이 둘을 혼동하면 공유 인증서가 무해하게 느껴집니다. 무해한 상태는 누군가 어느 기기가 세션을 열었는지 알아야 할 때까지 이어집니다.

발급자를 공유하면 구성 작업이 줄고 기기별 책임에는 아무 변화가 없습니다. ID를 공유하면 모든 기기가 하나의 폐기 가능한 단위로 접히고, 하나를 폐기하면 전부 폐기되며, 대체품을 승인하면 지금까지 만들어진 키 사본 전부가 승인됩니다. 이 거래는 금요일 오후에 더 빠르다는 이유로 파일을 복사하는 대신 명시적으로 하는 편이 낫습니다.

두 번째 인증서가 너무 비쌀 때

기기별 등록은 관리형 페이로드, SCEP 요청 또는 일회용 비밀번호를 사용한 안내식 가져오기라는 한 단계를 씁니다. 일련번호와 만료일을 추적할 자리도 필요하며, 이는 첫 인증서가 만료될 때까지 대부분의 배포가 잊는 부분입니다. 두 비용 모두 일회성이고 등록 흐름이 자동화하면 둘 다 줄어듭니다.

태블릿 두 대와 사용자 한 명인 가정에서는 공유 ID가 한 문장으로 문서화할 수 있는 합리적인 결정이며 비용은 현실적입니다. 그러나 사람별 또는 기기별로 접근을 회수해야 하는 서비스에는, 폐기 이야기야말로 비밀번호 대신 인증서를 쓰는 이유 전부이기 때문에 합리적이지 않습니다. 배포는 오늘 기기가 몇 대인지가 아니라 기기가 얼마나 자주 주인을 바꾸는지로 판단하십시오.

기기를 등록하고 키를 복사하지 마십시오

최신 플랫폼은 개인 키를 보호된 저장소에 두고, 일부는 설계상 내보낼 수 없음으로 표시합니다. 그 속성이 복사를 처음부터 불가능하게 만들며, 노트북에서 내보낸 번들을 지원되는 어떤 방법으로도 태블릿에 다시 가져올 수 없는 이유이기도 합니다. 그럼에도 시도하면 깔끔하게 설치된 뒤 절대 인증하지 않는 프로필이 만들어집니다.

배포가 이미 지원하는 등록 방법, 즉 관리형 ID 페이로드, SCEP 서비스, 또는 기기에서 새 키를 발급하는 계정 기반 흐름을 사용하십시오. 빠진 ID를 해결하려고 인증 기관의 개인 키를 배포하는 것은 영향 범위가 훨씬 큰 다른 실수입니다. 기관은 자격 증명을 발급하며 엔드포인트로 이동해서는 안 됩니다.

답하기 전에 폐기를 확인하십시오

공유 옵션을 고르기 전에 최악의 날 폐기가 어떻게 보이는지 서술하십시오. 답이 여러 기기에 영향을 주는 단일 작업이라면 설계는 이미 당신에게 불리하게 결정되었습니다.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

실제로 보유한 자료, 즉 개인 키가 있는지, 주체가 무엇을 말하는지, 일련번호를 개별적으로 폐기할 수 있는지를 확인하십시오. 키가 없는 인증서 파일은 아무것도 인증할 수 없음 때문에 일부 복사된 ID는 첫 연결에서 실패합니다.

태블릿에서 앱을 삭제하는 것은 폐기가 아니며, 누군가 비활성화할 때까지 서버는 ID를 계속 받아들입니다. 첫 기기를 등록하기 전에 그 문장을 런북에 적으십시오.