Güvenlik uzmanı değilim, bu yüzden sorumu bir cevap için yeterince netleştirmediysem lütfen bir yorumda bulunun.
Senaryo
WCF hizmetlerini çalıştıran bir sunucumuz ve bağlanan birkaç istemcimiz var. Bu istemciler aslında inşa ettiğimiz Linux bilgisayarlar. Sunucumuz ve müşterilerimiz arasında güvenli iletişim kurmamız gerekiyor (yine onları oluşturup müşteri sitelerine dağıtıyoruz).
İstemci sunucuya güveniyor
Bunu, istemcinin SSL iletişimini uygulayarak sunucu ile güvenilir bir bağlantı kurmasına izin vererek uygulayacağız.
Sunucu istemciye güveniyor
Artık istemcinin kimliğini doğrulama görevimiz var. Açıkçası bu, istemcide bir çeşit kimlik bilgisi tutularak yapılır. İstemci bağlandıktan sonra, kimlik bilgilerini sunucuya gönderebilir ve sunucu bunları doğrulayabilir.
Bu kimlik bilgileri için bir seçenek, WCF tabanlı uygulama tarafından oluşturulan bir çeşit Guid veya başka bir kimlik/şifre saklamaktır. Kimlik bilgilerini aldıktan sonra, WCF hizmeti veritabanında arama yapar ve doğru olduklarını doğrular.
Başka bir seçenek, Sertifika Hizmetlerini, istemci bilgisayara gönderilmeden önce kopyalanan istemci sertifikaları oluşturmak için kullanmaktır. Güvenli bağlantı kurulduktan sonra, istemci sertifikayı Sertifika Hizmetleri ile kimlik doğrulayan sunucuya gönderir.
Sorular
İstemcinin kimliğini doğrulamak için sertifika kullanmanın bir kullanıcı adı/kılavuzdan daha avantajları nelerdir? Ne dezavantajları var?
Düşünün lütfen:
Müşteri sertifikalarını dağıtmak buraya sığabilir. Kullanıcı adı üzerinde sertifika kullanmanın avantajları biraz basittir. Herkes herhangi bir istemci cihazdan bir kullanıcı adı yazabilir. Guid ile bir kullanıcı adı kombinasyonu kullanıyorsanız, istemcinin bilinen/yetkili bir istemci cihazdan bağlandığına dair "güvenlik" veya güvence, kılavuzun gücüne ve benzersizliğine bağlıdır. Kılavuzu klonlamanın veya taklit etmenin bir yolu varsa (mac adresleri kolayca taklit edilebilir), güvence seviyesi düşecektir.
İstemci sertifikaları, geçerlilik denetimi olan veya olmayan (geçerlilik tarihi, cn, ski/aki, parmak izi vb. Dışında) istemcilere dağıtılabilir. Ocsp gibi isteğe bağlı geçerlilik denetleme mekanizmaları, istemci kimlik doğrulamasına her bağlandığında/çalıştığında bir ocsp sunucusuyla sunucu uygulaması denetimi gerektirir. Ancak açıklamadan, geçerlilik kontrolünün sertifikayı istemci cihaza bağlayabilmek kadar önemli olduğunu okumadım.
Müşteri sertifikaları (genel olarak sertifikalar) ile önemli bir ayrıntı, ihraç edilebileceği ve uygulamaların çoğunun sertifikanın taşınabilirliğini kilitlememesidir. İstemci sertifikalarının saklanıp saklanmayacağına veya nasıl saklanacağına bakılmaksızın, uygun önlemler alınmadan sertifika sertifikadan cihaza kolayca kopyalanabilir. Bazı uygulamalar sertifikayı dosya sisteminde saklar (.cer, .der, .key, .crt ile biten dosyalar genellikle dosya dosyalarında sertifikaların depolandığının göstergeleridir). Daha güçlü uygulamalar (uygulamaya bağlı), sertifikaları ve anahtarları bir anahtar deposunda depolayabilir (örn. Java anahtar deposu). Anahtar deposu, özel anahtarın dışa aktarılabilir olmamasını sağlamak gibi ek koruma ekleyebilir. anahtarın dışa aktarılmadığının güvencesi sadece anahtar deposu kadar güçlüdür.Donanım anahtar depoları (yani akıllı kartlar, usb hsm, ironkey, vb.) özel anahtarın yazılım anahtar depolarından daha fazla dışa aktarılamayacağından çok daha güçlü bir güvence sunar.
BTW, yukarıdaki nokta aynı zamanda sunucu anahtarlarını da etkiler. Çoğu uygulama özel anahtarı bir yazılım anahtarı deposunda saklar ve genellikle dışa aktarılabilir olarak işaretlenir. Ayrıca, özel anahtar genellikle parola korumalı değildir, böylece sunucuya erişimi olan herkes özel anahtarla birlikte uzaklaşabilir. Eğer bir sertifika kopyalanabiliyorsa, itibari yoktur.
Sorunuzu cevaplamak için, yazılım tabanlı bir kimlik kullanmaktan daha fazla güvence sağlayacak (örneğin, sertifikalar, seri numarası, HSM'de depolanan sertifika vb.) Bir donanım kimliğini kullanmanın iyi bir yolu varsa (istemci sertifikaları dahil) . Özel anahtar erişimi için parola koruması etkinleştirilmiş istemci sertifikalarının kullanılması, yalnızca bir istemcinin özel anahtara değil, aynı zamanda onu kullanmak için parolaya da sahip olması gerektiği için biraz daha güçlü doğrulama sağlar.
İstemci sertifikalarını kullanmaya karar verirseniz, mevcut bir PKI altyapısını oluşturmanız veya kullanmanız gerekir. Codomo, Entrust, Symantec (eski adıyla vrsn, thawte ve geotrust), Godaddy ve diğerleri gibi satıcılar kullanım için hem genel hem de özel altyapı sunar. Bununla birlikte, yazılım tabanlı bir istemci sertifikası uygulamanın maliyeti muhtemelen yazılım tabanlı bir donanım kimliği veya belki de donanım tabanlı bir benzersiz kimlik kullanmaktan daha yüksek olacaktır.
Herhangi bir şey varsa, sahip olmak istediğiniz güvence düzeyini belirleyin ve yazılım, yazılım + şifre veya donanımın yeterli olup olmadığına karar verin.
İstemci sertifikası kimlik doğrulamasında, gizli (özel anahtar) istemciden asla ayrılmaz ve sunucuya gitmez. Sunucuya güvenip güvenmediğinizi (yine de ilk önce kontrol etmelisiniz), özel anahtarınız sızdırılmaz. Bu, geleneksel form tabanlı veya HTTP Temel kimlik doğrulamasına göre bir avantajdır.
Özel anahtar hiçbir zaman belirteci bırakmayacak şekilde tasarlanmış bazı donanım şifreleme belirteçlerini/akıllı kartlarını bile kullanabilirsiniz (TLS anlaşmasında yer alan imzalar gemide gerçekleşir).
İstemci sertifikalarını Ortak Anahtar Altyapısı bağlamında (büyük olasılıkla) kullanırsanız, PKI'nın sunduğu avantajlardan da yararlanabilirsiniz. Bu çoğunlukla büyük yapılar için yararlıdır, ancak şunları yapabilirsiniz:
Daha önce hiç kaydetmediğiniz kullanıcıların kimliğini öğrenin.
Sertifika Yetkilileri bunun içindir. CA'ya güveniyorsanız, verdiği sertifikaya güvenirsiniz. Bilinmeyen kullanıcılar sisteminizde önceden var olan bir hesap olmadan oturum açarsa ve güvendiğiniz sertifikaları sunarlarsa, CA tarafından kefil edildiği gibi kimliklerini tanıyabilirsiniz. Kullanıcıdan daha fazla ayrıntı almak isteyebilir veya istemeyebilirsiniz, ancak ana kimlik CA ile onaylanmış ve orada bir yönetici izi bırakmış olacaktır.
Sertifika tarafından belirtilen aynı kimlik, muhtemelen Tek Oturum Açma biçimi olarak kullanılan birden fazla bağımsız web sitesinde (aynı CA'ya güvenmeleri koşuluyla) kullanılabilir.
Güvenliği ihlal edilmiş bir sertifika doğrudan CA tarafından iptal edilebilir.
CA aracılığıyla, kullanıcının kimliğini ispatlama problemini hizmetin kendisinden ayırmanız gerekir. OpenID gibi diğer yöntemler de bu hedefe ulaşır, ancak CA'ların yapabilecekleriyle aynı düzeyde güvence sağlamaz (CA'ların işlerini doğru bir şekilde yapmaları koşuluyla). Güvence düzeyi CA'nın kalitesine bağlı olarak değişir.
Bunun bir avantajı, farklı anahtarlarla aynı kullanıcıya yeni bir sertifika verebilmeniz (önceki sertifikanın süresi dolmuşsa veya özel anahtarın güvenliği ihlal edilmişse) ve buna güvenen tüm sistemlerde aynı tanımlayıcıyı (Konu) tutabilmenizdir. CA.
(İstemci sertifikalarını bir PKI bağlamının dışında da kullanabilirsiniz, ancak oldukça sıkıcı olabilecek kendi güven kurallarınızı tanımlamanız gerekir.)
İstemci sertifikaları, SSL/TLS'nin üstünde çalışan protokolden bağımsız olarak da kullanılabilir. Bunları örneğin S/MIME için de kullanabilirsiniz.
Başka bir avantajı, kimlik doğrulaması HTTP düzeyinde gerçekleşmediği için, REST mimari tarzı sizin için önemliyse) etkili bir şekilde durumsuzdur.
Bazı web hizmetleri bunu ileti düzeyinde güvenlik için de kullanabilir ve böylece gerektiğinde belirli iletilerin reddedilmemesi için denetim izi bırakabilir.
Ana dezavantajı, kullanıcılarınızı ortak anahtar şifrelemesinin temel kavramları konusunda eğitmeniz gerekmesidir. Bu, özellikle donanım belirteçleri kullanmıyorsanız (ancak yalnızca sertifikaları ve özel anahtarı kullanıcının yazılımında saklıyorsanız) önemlidir.
Parolaların aksine, kullanıcılar özel anahtarı/sertifikayı hatırlamaz. Sertifikanın yüklendiği (veya donanım çözümleri için uygun bir kart okuyucunun bulunduğu) bir makine kullanmaları gerekir. Köşeleri kesmek için, bazıları özel anahtarlarına gerektiği kadar dikkatli bakmamaya cazip gelebilir (normalde kendileri parola korumalıdır).
Açıklarken, "sertifika" kavramı kafa karıştırıcı olabilir. Uzmanlar bile bazen cümleleri kısaltıyor. "Oturum açmak için sertifikanızı kullanın" derseniz, gerçekte "özel anahtarı ve oturum açmak için sertifikanızı kullanın" demek istiyorsanız: özel anahtar bu ifadede belirtilir. Buna karşılık, birisi size "sertifikanızı bana gönder" derse, özel anahtarınızı kullanmamalısınız. Dokümantasyona bakarsanız, PKCS # 12 dosyalarına bir dizi referans bulacaksınız (
.p12 veya
.pfx) ve PEM sertifika dosyaları (
.pem veya
.crt, tipik). Tipik olarak, birincisi özel anahtarı içerirken ikincisi içermez (yine de yapabilir). Tüm bu kavramlar, ne yaptığını bilmedikçe kullanıcıları şaşırtacaktır.
İstemci sertifikaları için tarayıcının kullanıcı arabirimleri genellikle oldukça zayıftır. Bir kullanıcı sertifikası açısından, örneğin bir istemci sertifikasıyla (HTTP Basic gibi) kimlik doğrulaması yaptığınız bir web sitesinden çıkış yapmak oldukça zordur. (CSRF korumasını daha da önemli hale getirir.) İstemcileriniz bir tarayıcı aracılığıyla kullanıcı değil, "makine" ise, bu çok da sorun değildir.
Altyapı açısından, istemci sertifikalarınız için ticari bir CA'nın hizmetlerini kullanmak istemiyorsanız, kendi CA'nızı dağıtmanız gerekir. İstemcilerin kimliğini doğrulamak için kullanılan CA'nın, sunucunun kimliğini doğrulamak için kullanılan CA'dan bağımsız olabileceğini unutmayın. Tanınmış bir CA tarafından verilen bir sertifikaya sahip bir web sitesi çalıştırabilir, ancak kendi CA'nızdan istemci sertifikalarına güvenmesini sağlayabilirsiniz. CA yönetimi için çeşitli araçlar vardır, açık kaynak kodlu olanlar dahil . Bazıları tarayıcı içi anahtar oluşturma bile yapabilir, böylece özel anahtar tarayıcıda hazırdır (bunun olumsuz tarafı, kullanıcının sertifikayı verdikten sonra içe aktarmak için aynı tarayıcıyı yeniden kullanmasıdır).
Sunucuların yapılandırılması, sertifikaların (CA sertifikaları, sunucu sertifikası) belirli bir şekilde anlaşılmasını gerektirir, ancak aslında bu kadar karmaşık değildir. Çoğu sunucu bunu şu ya da bu şekilde destekler.
İstemci sertifikaları yalnızca kimlik doğrulaması sağlar. Yine de daha fazla öznitelik almanız gerekebilir (örn. LDAP veya veritabanından sertifikaların konularına karşı). Kesinlikle bunun üzerinde bir yetkilendirme mantığına sahip olmanız gerekecektir, çünkü diğer herhangi bir kimlik doğrulama sisteminde olduğu gibi. Bir Konu DN'sini sisteminizdeki bir yerel tanımlayıcıya eşlemek tipiktir.
(Proxy sertifikaları kullanarak kimlik doğrulaması için temsilci atayabileceğiniz veya öznitelik sertifikaları aracılığıyla yetkilendirme simgelerini geçirebileceğiniz daha gelişmiş kullanımlar vardır, ancak bunlar daha sıra dışıdır ve tüm yazılım yığınları tarafından kabul edilmez.)