Ortak CA, ayrı kapılar: her kabul dosyası için bir hizmet

Ortak bir otoriteye karşı doğrulanan bir sertifika güven testini geçmiştir, üyelik testini değil. Bu iki karar sıklıkla birbirine karıştırılır çünkü ikisi de bağlantı anında gerçekleşir ve bu karışma, bir hizmette olmaması gereken biri oraya kabul edilene kadar görünmez kalır. Çözüm ikinci bir otorite değil; her hizmet için verilen ve daemonun okuduğu yerde kaydedilen ikinci bir karardır. İkisini ayrı tutun, bu alandaki karışıklığın çoğu kaybolur.

Güvenilen bir zincir hizmet üyeliği hakkında hiçbir şey söylemez

İki hizmet aynı veren hiyerarşiyi kabul edip yine de farklı kullanıcı kitlelerine sahip olabilir. Bir dizüstü bilgisayar birinciye aittir ve ikinciye ulaşmamalıdır, oysa aynı hiyerarşinin diğer istemcileri gerçekten oraya aittir. Otoriteyi o hizmetten kaldırmak, onu meşru olarak kullanan herkesi kilitlerdi, dolayısıyla iş kabuldür, güven değil.

Bir kapıda iki kilit hayal etmek yardımcı olur. Sertifika dış kilidi açar ve hizmet başına karar iç kilidi açar; hiçbiri diğerinin yerini tutmaz. Yalnızca dış kilidi olan bir hizmet üyeliği hiç uygulamaz, sadece kimlik doğrular. Bir şeyi değiştirmeden önce iki kararı da yazın, çünkü yalnızca çalışan bir bağlantı biçiminde var olan bir politika denetlenemez. Aşağıdakiler iç kilit ile ilgilidir.

İsteğe bağlı geçersiz kılmaları bir kabul kapısına dönüştürün

İstemci yapılandırma dizini genellikle bir kolaylıktır: içindeki dosyalar adlarını verdikleri istemcilerin ayarlarını geçersiz kılar ve dosyası olmayan bir istemci yalnızca sunucunun varsayılanlarıyla çalışır. Tek bir yönerge bu kolaylığı bir kapıya dönüştürür, böylece eksik dosya bağlantının reddedilmesi anlamına gelir.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Topluluk sürümü OpenVPN 2.6 ccd-exclusive kendi el kitabı sayfasında tam olarak bu koşulu belgeler ve adlandırılmış dosyanın aranması istemcinin etkin kimliğine bağlıdır. Diğer derlemeler ve ürün tarafından yönetilen sunucular farklı olabilir, bu yüzden başka bir yerde aynı anlambilime güvenmeden önce kurulu sürümü doğrulayın.

Yukarıdaki yolu bir örnek olarak ele alın ve bir kılavuzun uydurduğu dizini oluşturmak yerine gerçekten dağıtılan düzeni denetleyin. Mevcut sertifika denetimlerini, sunucu kimlik denetimlerini ve hesap kimlik doğrulamasını tam olduğu gibi bırakın, çünkü parça bir koşul ekler ve hiçbir şeyi kaldırmaz. Değişikliği üretimden önce hazırlayın, çünkü yanlış noktada yükseltilen bir ret sertifika arızası gibi görünür ve soruşturmayı otoriteye yönlendirir. Ardından reddedilen istemcinin günlük satırının zinciri değil eksik yapılandırma dosyasını adlandırdığını doğrulayın.

Hizmet başına bir dizin, tek bir ortak liste değil

Üyelik, onu uygulayan hizmete aittir, bu yüzden her hizmet kendi dizinini ve kendi dosyalarını tutar. İki hizmeti tek bir listeye yönlendirmek, üyeliği paylaşmalarına yol açar kimse bunu istemiş olsun ya da olmasın, ve ortaya çıkan değişikliği bir karara kadar geri izlemek zordur. Ortak otorite ortak kalabilir; kabul dosyaları kalamaz. Onları ayrı tutmak ayrıca bir hizmetteki hatanın diğerini sessizce genişletemeyeceği anlamına gelir.

DEFAULT girdisi insanları yanıltan durumdur. Adlandırılmış bir dosya bulunamadığında yedek ayarlar sağlar, ancak kapının istediği adlandırılmış dosya o değildir, bu yüzden tek başına bir istemciyi kabul edemez. Hiç girdisi olmayan bir istemciyi test edin ve reddi doğrulayın; o istemci kabul ediliyorsa yedek uygulanıyor demektir ve ccd-exclusive o örnekte yürürlükte değildir.

Etkin kimlik hangi dosyanın okunacağına karar verir

Arama, istemcinin gerçekte kimlik doğruladığı kimliği kullanır, bu genellikle sertifikanın ortak adıdır. Sunucu ayrıca bir kullanıcı adı ve parola doğrulayıp bu adı ortak ada eşliyorsa, dosya bunun yerine kimliği doğrulanmış kullanıcı adıyla eşleşmelidir. Uyumsuzluk, dizini hiç seçilmeyen makul dosya adlarıyla dolu bırakır.

Okuma diğer yarıdır. Daemon genellikle başlatmadan sonra ayrıcalıkları bırakır, bu yüzden azaltılmış hesabın dizine ve içindeki her girdiye okuma erişimi olmalıdır. İstemciler yazılabilir herhangi bir yoldan kendi girdilerini oluşturamamalıdır, çünkü self-servis kabul mekanizmayı tamamen etkisiz kılar. Yalnızca dosya kipini değil bağlama ve paylaşma izinlerini de denetleyin, çünkü bir hesap için kapalı görünen dizin başka bir hesap için açık olabilir. Ardından çalışan sürecin gerçekte hangi hesabı kullandığını doğrulayın, unit dosyasının hangi hesabı andığını değil. İkisi yalnızca başka hiçbir şey onları değiştirmediğinde aynıdır.

Reddi, kabulü ve iptali ayrı ayrı gözlemleyin

Hizmete ait bir kimliği deneyin ve bağlandığını doğrulayın. Girdisi olmayan geçerli bir sertifikayı deneyin ve reddedildiğini doğrulayın. Diğer hizmete kabul edilmiş bir kimliği deneyin ve burada kabul edilmediğini doğrulayın. Her sonucun yanına hizmet örneğini ve etkin kimliği not edin, çünkü o bağlam olmadan bir sonucu başka kimse yeniden üretemez.

Geri çekme, iptalden ayrı bir işlemdir. Bir kabul dosyasını düzenlemek bir hizmet hakkını kaldırırken kimlik her yerde geçerli kalır, oysa ele geçirilmiş bir anahtar kuruluşun iptal yanıtını gerektirir. Zaten açık olan oturumlara ne olacağına önceden karar verin, çünkü ne dizin düzenlemesi ne de iptal listesi onları kendi başına sona erdirir.

Kabul aynı zamanda yalnızca ilk kapıdır. Bir hizmete katılmak, arkasındaki alt ağlar, veritabanları veya yönetim arayüzleri hakkında hiçbir şey söylemez ve bu kaynak politikası ayrıca yazılıp test edilmelidir.