서버 키와 사용자 자격 증명에 별도의 소유자가 필요한 이유
게이트웨이의 신원과 사용자 권한은 영향 범위가 다른 별개의 비밀입니다. 세 가지 질문이 각각을 어떻게 저장하고 발급하고 폐기할지 결정합니다.
게이트웨이가 자기 자신임을 증명하는 키와 한 사람이 참여해도 된다는 자격 증명은 둘 다 비밀이며, 유사점은 거기서 끝납니다. 하나는 모든 클라이언트에게 서비스를 식별시키고, 다른 하나는 그 서비스에 한 사용자를 식별시킵니다. 둘을 섞으면 각각의 복구가 같은 작업이 아니므로 설정 중 한 단계를 아끼고 사고 중 반나절을 잃습니다. 분리는 설정하기 지루하고 건너뛰면 기억에 남습니다.
두 개의 비밀, 두 명의 다른 소유자
게이트웨이는 핸드셰이크 중 자신의 신원을 증명하는 것만이 임무인 개인 키나 인증서를 보관합니다. 클라이언트는 그것을 검증할 대응 공개 자료가 필요하며 개인 절반은 결코 필요하지 않습니다. 이 비대칭성이 모든 사용자에게 서버를 사칭할 능력을 주지 않고도 서버 인증을 가능하게 합니다.
사용자 자료는 반대 방향으로 갑니다. 클라이언트 개인 키, 클라이언트 인증서 또는 비밀번호는 바로 이 사람이나 기기에 접근이 발급되었음을 보여 줍니다. 배포되고, 기기 간에 복사되고, 결국 폐기될 것으로 예상됩니다.
WireGuard는 모든 참가자가 키 쌍을 가지므로 분리가 분명한데, 서버의 개인 키는 서버에 남고, 사용자에게 주는 구성 파일에는 그 사용자의 개인 키와 서버의 공개 키가 들어 있습니다. 서버의 개인 키가 들어 있는 프로필은 지름길이 아니라 파일 공유를 기다리는 침해입니다.
분리를 결정하는 세 가지 질문
누가 그 비밀을 읽을 수 있어야 하는지, 노출되면 공격자가 무엇을 할 수 있는지, 해결책이 한 번의 폐기인지 서비스 재구축인지 물으십시오.
사용자가 그것을 읽을 수 있고 그것이 게이트웨이 신원을 증명한다면, 클라이언트가 그 신원을 신뢰하도록 설계되어 있으므로 두 번째 질문의 답은 공격자가 모든 클라이언트 앞에서 당신의 서버를 사칭할 수 있다는 최악의 결과입니다. 한 사용자만 증명한다면 노출은 그 사용자의 한 피어 접근을 허용하며, 폐기는 일상적인 작업입니다. 인증 기관 키라면 모든 엔드포인트가 신뢰하는 신원을 공격자가 만들 수 있으므로 노출은 둘보다 더 나쁩니다.
이 세 답에서 CA 키는 오프라인이나 금고에, 게이트웨이 키는 게이트웨이에, 사용자 키는 사용자와 함께 두는 저장 규칙이 나옵니다. 편의를 위해 셋을 한 디렉터리에 넣는 배치는 결정을 사고로 바꾼 것입니다.
클라이언트에게 실제로 필요한 것
클라이언트에는 공개 인증서 또는 피어 공개 키, 신뢰해야 할 CA 자료나 지문, 자신의 개인 키, 엔드포인트 세부 정보가 필요합니다. 그 목록에는 게이트웨이의 개인 신원에 속하는 것이 없습니다.
문서가 새는 지점입니다. 서버 디렉터리를 복사하고 필요 없는 것을 지우라고 하는 안내서는 삭제 단계 후에 남는 파일을 점검하는 사람이 거의 없으므로 이미 잘못된 모델을 가르쳤습니다.
게이트웨이를 건드리지 않고 한 사용자를 폐기하기
사용자 신원은 별도로 발급되므로 별도로 철회할 수 있습니다. 인증서 기반 배포는 클라이언트 인증서를 폐기하고 갱신된 폐기 목록을 게시하며, WireGuard 배포는 서버 구성에서 피어 항목을 제거합니다. 어느 작업도 게이트웨이 자체의 키를 바꾸지 않습니다.
발급 기록을 보관하지 않으면 어느 신원을 철회해야 할지 알 수 없습니다. 사람, 기기, 일련번호나 공개 키, 날짜를 적고 그것을 만든 사람이 떠난 뒤에도 누군가 관리한다면 스프레드시트로 충분합니다.
아래 명령은 클라이언트 인증서를 검사한 다음 OpenSSL 스타일 기관을 통해 폐기하며, easy-rsa가 감싸는 흐름이 바로 이것입니다:
openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem새 목록을 클라이언트가 확인하는 곳에 게시하지 않으면 폐기는 아무것도 바꾸지 않는 파일 속 메모입니다. 게이트웨이가 폐기 목록을 참조하지 않고 클라이언트 인증서를 받아들인다면, 폐기가 작동하는 것처럼 암시하지 말고 분명히 밝히십시오.
백업을 비밀만큼 분리해 두기
재구축 아카이브에는 그것이 없으면 복원이 서비스를 재현할 수 없으므로 게이트웨이 키와 CA 자료가 정당하게 들어갑니다. 클라이언트 설정 패키지에는 들어가서는 안 되며, 둘을 함께 보관해서도 안 됩니다. 각 아카이브는 만든 날짜가 아니라 누가 보관할 수 있는지로 표시하십시오. 지친 관리자가 새벽 두 시에 읽는 것이 바로 그 표시입니다.
이 구분은 각각을 누가 가져올 수 있는지도 정합니다. 게이트웨이 관리, 사용자 신원 발급, 백업 읽기는 세 가지 다른 권한이며, 하나가 필요한 사람에게 나머지가 자동으로 필요한 것은 아닙니다. 디렉터리 상속이 정책의 의도보다 조용히 더 많이 부여하므로 그 권한을 적어 두고 실제 저장소가 허용하는 것과 대조하십시오.