Tek başına CSR kayıt değildir: bir VPN CA'sı neyi kontrol etmeli

Bir sertifika imzalama isteği, eşleşen özel anahtarla imzalanmış bir genel anahtar ve istenen subject taşır. Bu imza, talep edenin anahtara sahip olduğunu kanıtlar. İstenen ad, cihaz veya VPN rolüne hak sahibi olduğunu kanıtlamaz ve isteği bunu kanıtlıyormuş gibi ele almak, bir yardım masası talebinin erişim verilmesine dönüşme biçimidir.

İki kayıt modelini hangi protokolü konuştuklarına göre değil, neyi bağladıklarına göre karşılaştırmak gerekir.

İstek bir ad ileri sürer, onu kanıtlamaz

İsteği gerçekte ne içerdiğine göre okuyun: bir genel anahtar, talep edenin seçtiği bir subject ve ikisi üzerinde kendi imzası. Bu yapıda envanterinize, hesap dizininize veya onay akışınıza atıfta bulunan hiçbir şey yok. cn=finance-laptop gibi bir subject, birinin yazdığı bir dizedir. Verme süreci bu dizeyi güvendiği bir kayıtla karşılaştırmadıkça sertifika, imza eklenmiş bir iddiadır. Bu ayrım, kayıt sürecinin var olmasının tüm nedenidir.

Sonucu operasyonel olarak önemlidir. Bir sertifika otoritesi sertifika vermek için hiçbir zaman istemcinin özel anahtarına ihtiyaç duymaz ve bunu isteyen bir akış imzalamayı anahtar saklama ile karıştırmıştır. Üretimi uç noktada tutun ve yalnızca genel yarıyı gönderin.

Modelleri neyi bağladıklarına göre karşılaştırın

Elle imzalama, operatörün kontrol etmeyi hatırladığı şeyi bağlar. Otomatik bir kayıt hizmeti, kimliği doğrulanmış isteği hizmetin uygulayabileceği bir karara bağlar ve RFC 7030 istemcinin sertifika döndürülmeden önce kimliğini doğruladığı böyle bir tasarımı açıklar. Denetimden sağ çıkan fark otomasyon değildir; kimlik kontrolünün verme yolunun içinde mi yoksa yanında mı gerçekleştiğidir.

Her iki model de aynı üç soruyu yanıtlamak zorundadır. Kim istiyor, hangi cihazda veya rolde ve ne kadar süreyle. Yanıtları kaydeden bir talep sistemi gerçek iş yapar; birinin genel bir ada baktığı bir kuyruk yapmaz, sertifika sonradan ne kadar özenle biçimlendirilirse biçimlendirilsin.

Modeli beklediğiniz kayıt sayısına ve cihazların yenilenme hızına göre seçin. Yılda birkaç sunucu yazılı bir kontrol listesiyle elle incelemeyi kaldırabilir. Dizüstü bilgisayar filosu kaldıramaz.

Yaşam döngüsünü ilk vermeden itibaren kaydedin

Sertifika tanımlayıcısını, sahibini, amaçlanan kullanımı, son kullanma tarihini ve kaldırma yolunu verme anında saklayın, ilk olayda değil. Amaçlanan kullanım, genişletilmiş anahtar kullanımıyla sertifikanın kendisinde yer almalı ve kayıt onunla uyuşmalıdır. İstemci kimlik doğrulaması için üretilen bir sertifika, sunucu için olandan ayırt edilemez olmamalıdır.

Onuncu profili vermeden önce yenilemeyi ve kaybolan cihazın iptalini planlayın. Bir departman genelinde paylaşılan sertifika, hedefli kaldırmayı kesintiye dönüştürür ve bu kararı şimdi gözden geçirmek cuma günkü bir olay sırasında gözden geçirmekten çok daha ucuzdur.

Verilen sertifikayı, sonra erişimi doğrulayın

Kayıttan sonra nelerin verildiğini inceleyin ve beklediğiniz otoriteye zincirlendiğini doğrulayın. İki komut yaygın hataları kapsar: yanlış kullanımlı bir sertifika ve yalnızca istemci doğrulamayı yok sayacak şekilde yapılandırıldığı için çalışan bir zincir.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Sonra artefaktı değil erişimi test edin. Sertifika kimliği tesis eder ve hangi hizmetlere bu kimliğin ulaşabileceğine hâlâ politika karar verir. İkisini de kontrol edin, çünkü doğru bir artefakt bile fazla geniş bir politikayla incelemeden geçmez. İstemcinin kimliğini doğruladığını ve yalnızca amaçlanan rotaları veya kaynakları aldığını doğrulayın. Gözlemlediğinizi not edin, profilin ne yapması gerektiğini değil.

Yanlış nedenle çalışan bir profil, örneğin eşleşen bir genel ad ve hiçbir kimlik kontrolü yokluğu, sahip olduğunuzu sandığınız kontrol kaldırıldıktan sonra da çalışmaya devam eder.