Mimari ve çalışma modeli
Statik SSH anahtarında sunucu, izin verilen her açık anahtarı authorized_keys içinde veya merkezi bir kaynaktan tanır. Kullanıcı ayrıldığında anahtarın bulunduğu bütün hedeflerden kaldırılması gerekir. SSH sertifikasında ise kısa ömürlü kullanıcı anahtarı; güvenilen bir sertifika otoritesi tarafından kimlik, principal, geçerlilik süresi ve kritik seçeneklerle imzalanır. Sunucu tek tek kullanıcı anahtarları yerine CA açık anahtarına güvenir.
Sertifika, kimlik doğrulamayı merkezileştirir fakat yetkilendirmeyi ortadan kaldırmaz. Sertifikadaki principal değerinin Unix hesabına veya izin politikasına nasıl eşleneceği açıkça tanımlanmalıdır. Host sertifikaları da istemcinin çok sayıda host key kaydını yönetme yükünü azaltabilir; kullanıcı ve host CA anahtarları aynı anahtar olmak zorunda değildir ve ayrılması daha dar bir güven sınırı sağlar.
Kısa ömür tek başına güvenli dağıtım değildir. İmzalama hizmetine erişim, CA özel anahtarının korunması, saat senkronizasyonu, sertifika seri numarası ve audit kaydı tasarımın parçasıdır. Acil iptal için kısa süreye ek olarak Key Revocation List veya erişim katmanında kesme mekanizması gerekir. Statik anahtarlar küçük ve değişmeyen ortamlarda daha basit olabilir; insan sayısı, sunucu sayısı ve görev süresi büyüdükçe sertifikaların yaşam döngüsü avantajı artar.
- 1Kullanıcı anahtarı
- 2Kimlik ve politika kontrolü
- 3Kısa ömürlü SSH sertifikası
- 4Sunucu principal kararı
Tasarım parametreleri
- Geçerlilik süresi
- İnsan erişimi için görev süresine yakın kısa pencere seçin; otomasyon hesapları için yenileme ve kesinti davranışını ayrıca test edin.
- Principal tasarımı
- E-posta adresini doğrudan Unix kullanıcı adı saymak yerine sabit rol veya hesap eşleme politikasını yazın.
- CA ayrımı
- Kullanıcı ve host sertifikalarını ayrı CA ve yetki alanlarıyla yönetin; çevrimdışı kök veya donanım korumasını riske göre değerlendirin.
- Kayıt ve iptal
- Kim, hangi principal için, hangi hedef kapsamıyla ve ne kadar süreli sertifika aldı sorularını seri numarasıyla kaydedin.
Hesap ve uygulama örneği
Pilot ortamında ops ekibine 30 dakikalık, yalnızca web-admin principal değerini taşıyan sertifika verin. Web sunucuları TrustedUserCAKeys ile kullanıcı CA'sına güvensin; veritabanı sunucuları aynı principal değerini kabul etmesin. Süre dolduğunda yeni bağlantının reddedildiğini, mevcut oturumun ise ürün politikasına göre devam edebileceğini kaydedin.
Yirmi yönetici ve 200 sunuculu yapıda statik model, rol başına anahtar dağıtımı ve geri alma işlemlerini yüzlerce hedefe yayabilir. Sertifika modeli bunu CA güveni ve imzalama politikasına toplar; ancak CA kaybı daha geniş etki yaratır. Karar yalnız dosya sayısına değil, CA işletme olgunluğuna dayanmalıdır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
ssh-keygen -s user_ca -I ticket-4821 -n web-admin -V -5m:+30m -z 4821 operator.pub
ssh-keygen -L -f operator-cert.pub
sshd -T | grep -E 'trustedusercakeys|authorizedprincipals'Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Sertifika imzalı ama erişim reddediliyor | Principal, TrustedUserCAKeys yolu veya sistem saati uyuşmuyor olabilir. | ssh-keygen -L ile principal ve süreyi; sshd etkin yapılandırmasını ve zamanı birlikte kontrol edin. |
| Eski yetki beklenenden uzun sürüyor | Açık oturumlar sertifika süresi dolunca otomatik kapanmayabilir. | Yeni bağlantı ve mevcut oturumu ayrı test edin; oturum süresi politikasını erişim katmanında uygulayın. |
| Çok sayıda hedef aynı anda erişilemez | CA dosyası, dağıtım hatası veya imzalama bağımlılığı ortak arıza alanıdır. | CA güven dosyasının dağıtımını ve son çalışan sertifika alma yolunu bağımsız izleyin. |
Kabul ve doğrulama kontrolleri
- CA güvenini yalnız hedeflenen sunuculara dağıtın.
- Principal eşlemesini beklenen ve beklenmeyen hesaplarla sınayın.
- Süresi dolmuş ve henüz geçerli olmayan sertifikayı reddedin.
- Yanlış kullanıcı CA'sıyla imzalanmış sertifikayı reddedin.
- İmzalama olaylarını seri numarası ve talep kimliğiyle kaydedin.
- Acil iptal ve imzalama hizmeti kesintisi prosedürünü prova edin.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az ayrıcalık ve görev ayrımı
En az ayrıcalık, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.