PKI Sertifikaları Kullanarak Web Kimlik Doğrulaması

PKI'yı kavramsal bir bakış açısından - yani özel anahtarlar / ortak anahtarlar - arkalarındaki matematik, sertifika imzalamak için karma ve şifreleme kullanımı, İşlemlerin veya Belgelerin Dijital İmzalanması vb.İle oldukça iyi anlıyorum. C kütüphaneleri iletişim ve kimlik doğrulamanın sağlanması için serts ile birlikte kullanılmıştır. Ayrıca openssl komut satırı araçlarına çok aşinayım.

Ancak, web tabanlı PKI özellikli projelerle ilgili çok az deneyimim var ve bu yüzden bunu daha iyi anlamak için kişisel bir proje tasarlamaya ve kodlamaya çalışıyorum.

Gereksinimleri

Bu bir bankanın web sitesidir. Tüm İnternet Bankacılığı kullanıcılarının bilinen birkaç CA tarafından verilen sertifika (verisign, Thawte, emanet vb.) Kullanmalarına izin verilir. Banka, kullanıcıya sertifika temin etmekten sorumlu değildir. Bu sertifikalar bankaların web sitesinde kimlik doğrulaması için kullanılacaktır. Platformlar / OS vb. Hala sabit değildir.

tasarlamak

Kimlik doğrulaması yapmanın en iyi yolunun ne olduğunu merak ediyordum.

1. Apache'nin 2 yönlü ssl'yi etkinleştirmenin bir yolu olduğunu gördüm - bu durumda, web sitesine gitmenin otomatik olarak kullanıcıdan bir sertifika isteyeceğini düşünüyorum. Ancak bunun yeterli olup olmadığından emin değilim çünkü doğruladığı tek şey, bir sertifikanın güvenilir bir CA tarafından imzalanıp imzalanmadığı ve aynı zamanda sertifikaların konu satırlarının beyaz bir listesine girip girmediği olabilir. Ancak bu yeterli değil çünkü bir bankuserid'i bir sertifikayla ilişkilendirebilmeniz gerekir.

2. IIS'nin, Active Directory'deki her kullanıcı için bir sertifika depolayabileceğim bir yolu var gibi görünüyor. Bu, birkaç MSDN makalesini okuduğumdan anladım. IIS'de 2 yönlü SSL'yi açarsınız ve kullanıcı web sitesine gitmeye çalıştığında, IIS onaylı CA'ların listesiyle tarayıcıya bir istek gönderir ve tarayıcı kullanıcının sertifika deposundan uygun bir sertifika seçmesine ve göndermesine izin verir arka uç. IIS'nin 2 şey yapacağını varsayıyorum

   • Kullanıcının sertifikaya karşılık gelen özel anahtarın olduğundan emin olun (kapak görüşmeleri kapsamında)
   • AD Kullanıcı Sertifikası Eşlemesine dayanarak, IIS kullanıcı adını uygulamaya bildirir.

3. Bunu yapmak için web sunucusuna bağlı olarak kripto işlevlerini çağırarak kimlik doğrulama açıklığını yapın.

   • Bir sertifika yüklediği kullanıcı ekranını göster ve uygulama kullanıcının sertifikaya karşılık gelen özel anahtara sahip olmasını sağlar (ön uçtan sertifikayı kullanarak bazı dizeleri imzalamasını isteyerek).
   • Uygulama, her kullanıcının kendi kullanıcı kimliğiyle eşlenmesini sağlayan bazı verilerin depolandığı bir veritabanına sahiptir. Bu olabilir
   • her kullanıcı kimliğine karşılık gelen tüm sertifika
   • her kullanıcı kimliğine karşılık gelen CA ve sertifika seri numarası.

Hangisinin yaygın olarak kullanıldığını merak ediyordum. En iyi uygulamalar nelerdir? # 3 ile devam edersem, bunu yapmanın en iyi yolları nelerdir?

Akıllı telefon uygulamalarıyla da kolayca çalışabilecek bir şey ek bir bonus olacaktır.

Güncelleme

"Kimlik doğrulama kısmını kendim kodla" ifademi açıklığa kavuşturacağım, çünkü bazı cevaplar yanlış anlaşıldığını gösteriyor - net olmamak benim için kötü.

Bu, kendim kripto şeyler yazdığım anlamına gelmiyor. Sadece aslında IIS veya başka bir web sunucusuna bağlı yapmak yerine açık bir şekilde kripto rutinleri arayacağım anlamına gelir.

Konuya konuya gerçekten cevap vermek istesem de, bu konuyu konuya göre vuracağım:

Yetkilendirme / Onaylama

Tamam, ilk önce. Örneğin, her ikisine de ihtiyacınız var:

• Kimlik doğrulama - kullanıcının söylediği kişi olduğuna dair kanıt. Kimlik doğrulamanız olarak özel anahtarın zımni kanıtıyla PKI'yı seçtiniz.
• Yetkilendirme - kullanıcının izin verdiği şeye bağlantısı. Oturum açma ile izin verilen hesaplara erişim arasındaki bağlantı noktası budur. Sertifikanın hesap ve hesap erişim yetenekleriyle eşlenmesi yetkilendirmedir.

Yetkilendirme açısından, kullanıcının konu DN'sini banka hesaplarına bağlama işlemini çözme sorununa sahipsiniz. İşlemin ağırlığı göz önüne alındığında, bunun için kesinlikle güçlü bir sürece sahip olmak istiyorsunuz ve burada tek bir doğru yol yok. Bunu politikaya göre nasıl yapacağınızı anlamak için bankaya ve muhtemelen avukatlara danışmanız gerekir.

SSL, İstemci / Sunucu Kimlik Doğrulaması, Özel Anahtarın İspatı

SSL protokolü her zaman sunucu kimlik doğrulaması içerir ve istemci tarafı yetkilendirmesi için ek bir isteğe bağlı ayar içerir. Apache'nin PKI tarafından İstemci Kimlik Doğrulaması ekleyen bir ayar sunması nedeniyle # 1 haklısınız ve bunu güvenilir CA'ların bir listesi ile sağlayabilirsiniz. PKI aracılığıyla İstemci Kimlik Doğrulaması gerektiren bir SSL oturumunun kurulumu sırasında - özel anahtarın kanıtını alırsınız.

Seçenek # 1 veya seçenek # 2 bunu sağlayacaktır - hem Apache hem de IIS bu şekilde yapılandırılabilir. En iyi uygulama akıllıca, ikisini de kendi çözümünüzü yuvarlayarak ele alacağım. # 3, "kendi kripto paranızı yazma" kuralına çok yakın geliyor. İşleminizi, kimliği doğrulanmış bir SSL oturumunun varlığına bağlayabileceğinizi varsayarsak, kendi hesabınızı devralmanız için bir neden yoktur.

Ayrıca - seçenek # 1 veya seçenek # 2'de, ellerinizi tüm sertifikaya ve oradan sertifikanın herhangi bir bölümüne almanın bir yolu vardır. Tipik olarak Konu DN'si ve / veya sertifika seri numarası, yetkilendirme amacıyla kullanıcının kimliğini belirlemek için kullanılır.

"Yaygın kullanım" açısından - tüm büyük web sunucuları oldukça yaygındır. IIS, Apache, Tomcat ve daha birçoğu istemci yetkilendirme SSL'si ile yapılandırılabilir. Oradan alınan karar büyük ölçüde genel uygulamaya dayanmaktadır. Büyük web sunucularının hepsinin SSL oturumunda sağlanan sertifikaya erişme yolları vardır, bu da daha ayrıntılı doğrulama için ihtiyacınız olan şeydir.

Sertifika Doğrulama Ekleme Ons

En azından şunları yapmanız gerekir:

• SSL oturumu kur
• sertifikayı çekin (çoğu web sunucusu sertifikanın imzasını ve özel anahtarın kanıtını kontrol edecektir)
• sertifikanın geçerlilik tarihini doğrulayın (herhangi bir web sunucusunda verilmez)
• bu sertifikanın hangi hesaplara erişebileceğini yetkilendirme kontrolü yapın

Bankacılığın yüksek miktarları göz önüne alındığında, sertifikanın iptal durumunu da doğrulamak isteyebilirsiniz - kullanıcının özel anahtarı kaybolur veya çalınırsa, sertifikası iptal edilmelidir.

IIS, OCSP veya CRL doğrulaması için kancalara sahip olabilir - daha kapsamlı (el tutma!) Bir sistem olma eğilimindedir, ancak başımın üstünü hatırlamıyorum. Bunun için Microsoft ürünlerini kullanmaya zorlanıp zorlanmayacağını da hatırlamıyorum. Apache için, neredeyse kesinlikle bir OCSP / CRL kontrolünü kodlamanız veya eklemeniz gerekir. SSL oturumu sırasında kancaları olduğuna inanıyorum - genellikle bu kontrol SSL oturumu ayarlandığında bir kez yapılır.

yetki

# 1 ve # 2'de - IIS'nin SSL oturumunda sağlanan sertifikayı bir AD havuzuna bağlayacak yerleşik bir işleve sahip olduğunu haklıyorsunuz. Microsoft'un daha fazla ürün satın almayı ve kullanmayı kolaylaştırmak için ekstra yol kat ettiği durumlardan biri. :) IIS'nin AD'ye nasıl bağlandığına dair bu sorunun kapsamı dışında ve anında hatırlamamın ötesinde nüanslar var. IIS ve AD ile oldukça çılgınca şeyler yaptım ve genel düşüncem, bir AD havuzundan sertifikaya dayalı kullanıcı adını çekmek kadar nispeten basit bir şey yaparken - muhtemelen iyisinizdir. Veri depolama, garip AD aramaları ve özellikle PKI ile çılgın (ama meşru) şeylerle ilgili daha karmaşık konulara girdiğinizde,

IIS ile, yine de - AD yapınıza veya başka bir yere, kullanıcı adını banka hesabına bağlayan bir şey eklemeniz gerekir. Tipik olarak bankacılıkta bir kullanıcının birden fazla hesabı vardır. Ve 2 kullanıcı ortak bir hesaba sahip olabilir, bu yüzden bu çok çok ilişkidir.

# 1 - evet için kendi aramanızı yazmanız gerekiyor. Aşağıdakileri kodlamanız gerekir: - sertifikayı kullanıcıya ve kullanıcıyı kullanıcı bankası hesaplarına bağlayan bir veritabanı veya LDAP hiyerarşisi. Bir sertifikanın garanti edilen benzersiz kısmı seri numarası + düzenleyici DN'dir. Genellikle Konu DN çalışır, ancak tüm PKI sistemlerinde garanti edilmez.

Genellikle Apache ile üst düzey kimlik doğrulaması için PKI kullanan geliştiriciler bunu yapar. Bu sistemlerin birçoğunda çalıştıktan sonra, henüz bir yetkilendirme yeniden kullanımı vakasıyla karşılaşmadım, bu yüzden bunu gerçekten büyük bir eksi olarak görmüyorum - roller / ayrıcalıklar gibi, her iki şekilde de özel bir şeye sahip olmak zorunda kalacağım. asla kolay değil.

Bu, # 1 ve # 3'ün bir karışımı gibi görünüyor - güçlü tavsiyem - SSL oturumunu oluşturmak için kullandığınız uygulama / web sunucusunun yerel özelliklerini kullanın. Bu, tarayıcının sunucuya sertifika sorgusu ile kurulumunu standart, en iyi uygulama şeklinde gerçekleştirmesini sağlar. Oradan, Apache ile kendi yetkilendirme sisteminizi devretmeniz gerekecek. IIS, Microsoft'un bunun sizin için nasıl çalışması gerektiğine dair fikir verecektir.

Bilinen Gotchas

Bir sürü tarayıcı testi yapın. Yıldan yıla, tarayıcıdan tarayıcıya, SSL oturum işlemeli gotchas buluyorum. SSL oturumunu web sayfası istekleri serisine doğru bir şekilde bağlamak ve oturumun doğru bir şekilde ele alındığından emin olmak en önemli endişe alanlarıdır. Hem sunucu hem de tarayıcı yazılımı ile çok ilgisi var. SSL, çalışırken diğer herkesle ilgili sorunlar olsa da, genellikle çalıştığından yeterince kararlıdır.

Özellikle, bunu en son yaptığımda, güç kodlama ve oturum zaman aşımı sorunu çok önemliydi.

Akıllı Telefonlar

İyi. Şans. söyleyebileceğim her şeyle ilgili. Ben hiç bir mobil uygulama geliştiricisi değilim, ama şimdiye kadar benim izlenim ortalama akıllı telefon, PKI sertifika işleme alt eşit ya da olmayan olmasıdır.

Yanlış kanıtlanmayı çok isterim.

Kişisel sertifikalar, sertifikaların periyodik olarak yenilenmesi için iyi çalışır (arkasında oldukça sağlam bir süreç vardır) ve müşterilerin sevdiği "şifresiz" bir kimlik doğrulama olarak uygulanabilir

ama başarısız olduğu yer

• Sertifika başına maliyet
• modern tarayıcılarla uyumluluk
• sertifika alan ve gizli anahtarları güvenli olmayan şekilde saklayan son kullanıcılar

sha-2 imzalı modern kişisel sertifikaların iPad'deki Safari ve birçok modern tarayıcı ile çalışmadığını unutmayın. Bunun nedeni, kişisel sertifikaların sertifika yetkilisi kuruluşlarının düşündüğü gibi asla başlamamasıdır. 30.000 sertifika yayınlamak (yaptığımız şey) sertifika başına bazı donanım belirteci türleriyle aynıdır.

Müşterilerin kendi sertifikalarını bulmalarına izin verme stratejiniz gerçekten geçerli değil. Günümüzde kişisel sertifika tedarikçileri bulmak zordur ve oldukça pahalıdır - iş vakasının çalıştığından emin olmanız gerekir, aksi takdirde müşteriler bunu satın almazlar.

Tamam, burada çok şey oluyor. İlk olarak, istemci sertifikası kimlik doğrulaması, uç noktada desteklenmiyorsa işe yaramaz. Bu nedenle, Intrepidus'tan akıllı telefon uygulamaları için istemci kimlik doğrulamasının temellerini kapsayan harika bir yazımız var .

Ardından, kendi kimlik doğrulama rutininizi kodlamamanızı şiddetle tavsiye edeyim. Bununla başa çıkabilen çok sayıda harika, denetlenmiş kütüphane vardır. Kimlik doğrulaması için olgun bir kitaplıkla çalışarak işlevsellik ve güvenlik hatalarından tasarruf edersiniz. Bunun için denetlenmiş ve olgun bir kütüphane kullanmak kesinlikle en iyi uygulamadır.

Sonraki en iyi uygulama, istemcinizi işlemek için bir dizin kullanmaktır: sertifika eşleme. Böylece AD ​​veya LDAP'ye bakacaksınız. Bahsettiğiniz gibi, Windows ve IIS bunu sizin için oldukça sorunsuz hale getiriyor. IIS.net, IIS altında sertifika eşlemesini yapılandırma konusunda iyi bir özet sunar .

Apache ile oynarsanız, bu kutudan çıktığı kadar kolay değildir. Mod_authz_ldap istemci sertifikası eşlemesi yapıyor gibi görünüyor , ancak kişisel olarak onunla çalışmadım.

Bu da bizi böyle bir şey uygulamanın lojistiğine getiriyor. Kullanıcıların sertifikalarını imzalamıyorsunuz, bu nedenle kullanıcının sertifikasını göndermesi ve uygulamanızın dizinde yayınlaması için zırhlı bir işleme ihtiyacınız var. Bunun için bir parola yetkilendirmesi ve kısa mesajla ya da güvenilir bir numaraya çağrı yaparak iki faktörlü görmek istiyorum. Kullanıcıya, hesaplarına bir sertifika eklendiğini bildirmeleri için e-posta gönderirim. Bir kullanıcının uygulamadaki hesap yönetimi sayfası aracılığıyla kullanıcı sertifikası eşlemesini kaldırmasına izin veririm.

İki faktörden kaçınmak için güvenilir cihazların çerezlerini ayarlamak için Google ve Facebook'un ne yaptığını inceleyeceğim. Yalnızca sertifika kimlik doğrulamasına izin vermeden önce iki faktörlü yeni cihaz kimlik doğrulamam olur.

Ayrıca iptal edilen kullanıcı sertifikalarının nasıl ele alınacağını da düşünürdüm. Bu, harici bir sertifika iptal listesinin (CRL) kontrol edilmesi anlamına gelir. İstemci sertifikasında CRL dağıtım noktası tanımlanmamışsa ne yaparsınız? Kullanıcı oturum açtığında veya işin bir parçası olarak planlanmış bir temelde CRL'yi kontrol ediyor musunuz, çünkü kullanımda yalnızca bir avuç CRL olacak gibi görünüyor mu?

Gerçekten, bu kaygılanıyor: Kullanıcıların güvenliğinin tehlikeye atılmadığına nasıl güvenebileceğimi ve X sertifikasını Y kullanıcısına eşleştirebileceğime nasıl güvenebilirim?