VPN 사용자 등록: 먼저 ID 소유자를 찾으세요

누군가 VPN 접근을 요청하면 첫 반응은 서버에서 adduser를 실행하는 것입니다. 그 반응은 아주 좁은 범위의 배포에서만 맞습니다. 무엇이든 만들기 전에, 계정이 제품 데이터베이스, ID 제공자, 호스트 자체의 인증 스택에 있을 수 있음을 염두에 두고, 서버 구성을 열어 어떤 제품이 돌아가는지, 어디서 자격 증명을 검증하는지 확인하세요. 잘못된 종류의 계정을 만들면 그 사람은 로그인은 되지만 터널은 없는 상태가 됩니다.

OpenVPN이라고 적힌 클라이언트 프로필은 프로토콜을 설명할 뿐, 그 뒤의 ID 시스템을 설명하지 않습니다.

adduser가 아니라 서버에서 시작하세요

먼저 제품을 식별하세요. Community OpenVPN은 데몬과 거기에 연결한 인증의 조합이고, Access Server는 자체 사용자 계층을 가진 제품입니다. 구성, 유닛 이름, 패키지 목록을 요청하고 사용자 관리를 위한 웹 인터페이스가 있는지 확인하세요. 그다음 배포된 프로필이 클라이언트에게 인증서, 사용자 이름과 비밀번호, 또는 둘 다 중 무엇으로 신원을 증명하도록 기대하는지 보세요. 그 답이 계정을 소유한 시스템을 지목합니다.

그 뒤에야 사용자 생성이라는 말이 의미를 갖습니다. 인증서만 쓰는 배포에서는 승인된 절차로 장치 ID를 발급한다는 뜻이고, Unix 로그인은 아무것도 바꾸지 않습니다. 비밀번호 배포에서는 실제로 비밀번호를 검증하는 백엔드를 뜻합니다.

네 가지 백엔드, 계정을 만드는 네 곳

Access Server의 로컬 인증은 계정을 자체 데이터베이스에 보관하므로, 계정을 만드는 인터페이스는 호스트가 아니라 제품에 속합니다. PAM은 검증을 운영 체제 스택에 위임하므로, 서비스가 그 스택을 선택했다면 로컬 Unix 계정이 등록의 일부가 될 수 있습니다. LDAP, RADIUS, SAML은 검증을 외부 서비스로 옮기며, 프로비저닝, 비밀번호 정책, MFA가 그곳에 있습니다. Access Server는 네 가지 경우 모두에서 사용자별 인증서와 권한을 보관할 수 있고, 바로 그것이 분리를 혼란스럽게 만듭니다.

전역 기본값이 아니라 이 특정 사용자에게 적용되는 방식을 확인하세요. Access Server 2.10 이후 버전은 그룹이나 사용자별로 다른 인증 방식을 적용할 수 있으므로, 기본값이 로컬이라는 사실이 앞에 있는 계정이 로컬에서 검증된다는 증거는 아닙니다.

권한은 별도의 결정입니다

인증은 그 사람이 누구인지에 답하고, 권한은 그 사람이 무엇에 도달할 수 있는지에 답합니다. 성공한 로그인은 부여가 아니므로 이 둘을 두 단계로 유지하세요. 의도한 경로, 리소스 권한, 관리 권한을 의식적으로 할당하고 관련 없는 접근은 계속 거부되는지 확인하세요. 배포가 개별 ID를 지원한다면, 공유 프로필은 한 사람을 위해 해지할 수 없으므로 다른 사람의 프로필을 전달하는 대신 사람마다 하나씩 발급하세요.

클라이언트 자료도 중요합니다. 자동 로그인 프로필과 대화형 사용자 로그인은 서로 다른 인증 관계를 나타내며, 하나를 다른 것으로 바꾸면 서버가 실제로 검증하는 내용이 달라집니다.

접근 해지는 등록의 일부입니다

사용자를 만드는 동안 누가 계정을 검증하는지, 누가 VPN 접근을 승인하는지, 어떤 장치나 프로필이 연결을 나타내는지 세 명의 소유자를 적어 두세요. 이들은 세 가지 다른 시스템일 수 있고, 그중 하나만 언급하는 해지 계획은 경로 하나를 열어 둡니다. 그 사람이 떠나면 권한을 그 소유자에게서 제거하고 발급된 모든 자격 증명을 그 소유자에게서 해지하세요. 내려받은 파일을 삭제하는 것은 해지가 아니며, 외부 ID가 여전히 인증된다면 로컬 항목을 삭제하는 것도 해지가 아닙니다.

그다음 공격자가 할 것처럼 새 ID로 한 번 연결해 의도한 리소스에 대한 접근을 확인하고, 관련 없는 리소스는 여전히 거부하는지 확인하며 등록을 시험하세요. 작동하는 첫 연결과 부정 테스트가 함께라면 등록이 완료된 것입니다.

기록은 그것이 속한 프로필과 함께 보관하세요. 다음 감사자는 특정 달에 누가 연결할 수 있었는지 묻고, 그 답은 그 세 소유자 안에 있습니다.