먼저 EAP 방식: VPN이 쓸 수 있는 비밀번호 해시
VPN은 비밀 자체를 검증하며 웹 해시를 검증하지 않는다. 같은 비밀번호가 계속 동작한다고 약속하기 전에 방식을 읽고 저장소에 무엇이 있는지 확인하라.
웹 로그인은 되는데 같은 테이블의 비밀번호를 VPN이 모두 거부하는 팀이 많습니다. 웹 애플리케이션은 스스로 계산한 해시를 비교하지만, 터널은 서버가 검증할 수 있는 방식으로 비밀의 보유를 클라이언트에게 증명하라고 요구합니다. 저장된 재료에 대한 요구가 서로 다른 것입니다. 이런 프로젝트 대부분이 멈추는 지점이 바로 이 차이입니다.
방식을 먼저, 스키마는 그다음
어떤 스키마를 보기 전에 선택한 방식이 어떤 증명을 요구하는지 적어 두십시오. 챌린지-응답 방식은 서버가 기대 응답을 계산할 수 있는 재료를 필요로 하며, 실제로는 비밀번호 자체나 호환되는 파생 형태를 뜻합니다. 보호된 터널 안에서 비밀번호를 운반하는 방식은 검증자 쪽에 비밀번호 자체가 필요합니다. 클라이언트 설정이 아니라 검증자 요구 사항을 기준으로 방식 문서를 읽으십시오. 클라이언트 요구 사항은 보통 쉬운 부분입니다.
현대 웹 프레임워크가 만드는 솔트 해시는 둘 다 제공하지 않습니다. 특정한 비교 하나를 검증할 뿐이며 원래 비밀로 되돌릴 수 없습니다.
챌린지-응답은 솔트 해시를 쓸 수 없다
MSCHAPv2는 챌린지-응답 교환이므로 서버는 비밀번호를 받지 않으며 저장된 문자열과 비교할 수 없습니다. 이미 가진 재료에서 기대 응답을 도출해야 하고, 호환되는 저장 형태가 그렇게 좁은 이유가 여기 있습니다. 사용자별 솔트가 있는 bcrypt나 Argon2 값은 일방향이어서 이 교환을 완전히 배제합니다. 아래 표가 방식 이름이 아니라 저장 형태에서 출발하는 이유는 답을 결정하는 것이 저장 형태이기 때문입니다.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
strongSwan용 SQL 플러그인 문서 는 구성과 자격 증명을 위한 자체 스키마를 정의하며, 프로젝트는 여전히 그 플러그인을 실험적으로 표시합니다. 애플리케이션의 사용자 테이블에 맞춰지지도 않고 어떤 해싱 방식이 저장 값을 만들었는지 추측하지도 않습니다. 따라서 현실적인 선택은 게이트웨이가 쓸 수 있는 저장소로 이전하거나, 기존 저장소 앞에 이 교환을 수행할 수 있는 인증 서비스를 두는 것입니다. 그 밖의 것은 내부에 숨은 가정을 품은 커넥터일 뿐입니다.
RADIUS는 작업을 옮길 뿐, 요구는 옮기지 않는다
EAP를 RADIUS 서버에 위임하면 검증이 일어나는 위치가 바뀌고 보통 감사 추적이 좋아집니다. 일방향 해시에서 비밀번호를 되살리지는 못하므로 인증 서비스에는 종료하는 방식과 호환되는 재료가 여전히 필요합니다. 팀은 RADIUS 경로를 만든 뒤 반대편에서 같은 벽에 부딪히고 나서야 이를 알게 됩니다.
RADIUS 서버가 호환되는 자격 증명을 담은 디렉터리를 읽을 수 있으면 설계가 동작하고 VPN 게이트웨이는 단순하게 유지됩니다. 읽을 수 없으면 정직한 답은 또 다른 커넥터가 아니라 등록 변경입니다. 프로비저닝과 폐기는 신원을 소유한 쪽의 일이므로, 지원되는 동기화 절차 없는 복사 테이블은 싱글 사인온이 아니라 두 번째 자격 증명 수명 주기입니다. 누군가 한 곳에서만 비밀번호를 재설정하는 첫 순간에 어긋나기 시작하며, 두 시스템에 모두 있는 계정이 각각 다르게 동작할 때까지 그 어긋남은 조용합니다.
디렉터리를 읽는 계정은 그 읽기만으로 제한하고, 게이트웨이가 자체 구성에 쓰는 계정과 분리하십시오. 관리 계정을 공유하면 읽기 전용 설계가 훨씬 넓은 영향 범위로 바뀝니다.
계정이 있어야 할 자리
재료 문제가 정리되면 두 가지 구조가 남습니다. 게이트웨이가 자신만 읽는 작은 자격 증명 저장소를 가질 수도 있고, 기업 디렉터리 앞에 서는 인증 서비스에 위임할 수도 있습니다.
전자는 따져 보기 쉽지만 사용자에게는 불리합니다. 두 번째 비밀번호를 유지해야 하기 때문입니다. 후자는 신원을 하나로 유지하지만, 이제 누군가 접속하기 전에 반드시 살아 있어야 하는 서비스에 대한 의존을 더합니다. 어느 쪽도 틀리지 않았지만, 선택은 게이트웨이 설정 옆에 기록해야 합니다. 그렇지 않으면 다음 엔지니어가 다른 쪽을 골랐다고 전제할 것입니다. 무엇을 고르든 아래 두 명령이 변경 전의 현재 상태를 보여 줍니다.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-conns계정 인증이 권한 부여까지 해결하지는 않습니다. 그룹 소속, 장치 상태, 네트워크 권한은 사용자가 요구된 신원을 증명한 뒤에도 명시적인 매핑이 필요합니다. 완벽하게 인증하면서 아무것도 허용하지 않는 연결은 정책의 결과이지 방식의 결함이 아닙니다.