VPN kullanıcısı kaydı: önce kimliğin sahibini bulun

Biri VPN erişimi ister ve ilk refleks sunucuda adduser çalıştırmaktır. Bu refleks yalnızca dar bir dağıtım kümesinde doğrudur. Bir şey oluşturmadan önce sunucunun yapılandırmasını açın ve orada hangi ürünün çalıştığını ve kimlik bilgilerini nerede doğruladığını öğrenin, çünkü hesap bir ürün veritabanında, bir kimlik sağlayıcısında veya ana makinenin kendi kimlik doğrulama yığınında olabilir. Yanlış türde hesap oluşturmak kişiyi çalışan bir girişle ve tünelsiz bırakır.

OpenVPN yazan bir istemci profili protokolü tanımlar, arkasındaki kimlik sistemini değil.

adduser ile değil, sunucuyla başlayın

Önce ürünü tanımlayın. Community OpenVPN, ona bağladığınız her türlü kimlik doğrulamayla birlikte arka plan programıdır; Access Server ise kendi kullanıcı katmanına sahip bir üründür. Yapılandırmayı, birim adını ve paket listesini isteyin ve kullanıcı yönetimi için bir web arayüzü olup olmadığını kontrol edin. Ardından dağıtılan profilin istemcilerden kim olduklarını nasıl kanıtlamalarını beklediğine bakın: sertifika, kullanıcı adı ve parola ya da her ikisi. Bu yanıt, hesabın sahibi olan sistemi adlandırır.

Ancak bundan sonra kullanıcı oluşturma ifadesi bir anlam taşır. Yalnızca sertifika içeren bir dağıtımda bu, onaylanmış süreçle bir cihaz kimliği vermek anlamına gelir ve Unix oturum açma hiçbir şeyi değiştirmez. Parola içeren bir dağıtımda bu, parolayı gerçekten doğrulayan backend anlamına gelir.

Dört backend, hesap oluşturmak için dört yer

Access Server'ın yerel kimlik doğrulaması hesapları kendi veritabanında tutar, bu yüzden bunları oluşturma arayüzü ana makineye değil ürüne aittir. PAM doğrulamayı işletim sisteminin yığınına devreder, bu nedenle hizmet tam olarak o yığını seçtiyse yerel bir Unix hesabı kaydın parçası olabilir. LDAP, RADIUS ve SAML doğrulamayı, sağlama, parola ilkesi ve MFA'nın yaşadığı harici bir hizmete taşır. Access Server dört durumda da kullanıcı başına sertifika ve izinleri tutmaya devam edebilir ve ayrımı kafa karıştırıcı yapan da budur.

Genel varsayılanı değil, bu belirli kullanıcı için geçerli yöntemi kontrol edin. Access Server 2.10 ve sonrası grup veya kullanıcı başına farklı kimlik doğrulama yöntemleri uygulayabilir, bu yüzden yerel bir varsayılan, önünüzdeki hesabın yerel olarak doğrulandığını kanıtlamaz.

Hak ayrı bir karardır

Kimlik doğrulama kişinin kim olduğunu yanıtlar; hak neye ulaşabileceğini yanıtlar. Bunları iki adım olarak tutun, çünkü başarılı bir oturum açma bir verme değildir. Amaçlanan rotaları, kaynak izinlerini ve yönetim haklarını bilinçli olarak atayın ve ilgisiz erişimin reddedilmiş kalmasını doğrulayın. Dağıtım bireysel kimlikleri destekliyorsa, başkasının profilini iletmek yerine kişi başına bir tane verin, çünkü paylaşılan bir profil tek bir kişi için geri alınamaz.

İstemci malzemesi de önemlidir. Otomatik oturum açma profili ile etkileşimli kullanıcı oturumu açma farklı kimlik doğrulama ilişkilerini temsil eder ve birini diğeriyle değiştirmek sunucunun gerçekte neyi doğruladığını değiştirir.

Erişimin geri alınması kaydın parçasıdır

Kullanıcı oluşturulurken üç sahip not edin: hesabı kim doğruluyor, VPN erişimini kim yetkilendiriyor ve bağlantıyı hangi cihaz veya profil temsil ediyor. Bunlar üç farklı sistem olabilir ve yalnızca birini adlandıran bir geri alma planı bir yolu açık bırakır. Kişi ayrıldığında hakkı sahibinden kaldırın ve verilen her kimlik bilgisini sahibinde geri alın. İndirilen bir dosyayı silmek geri alma değildir ve harici bir kimlik hâlâ doğrulanıyorsa yerel bir kaydı silmek de geri alma değildir.

Ardından kaydı bir saldırganın yapacağı gibi test edin: yeni kimlikle bir kez bağlanın, amaçlanan kaynağa erişimi doğrulayın ve ilgisiz bir kaynağın hâlâ reddettiğini doğrulayın. Çalışan ilk bağlantı artı olumsuz bir test, tamamlanmış bir kayıttır.

Kaydı ait olduğu profille birlikte saklayın. Bir sonraki denetçi belirli bir ayda kimin bağlanabildiğini soracak ve yanıt o üç sahipte.