Seçim Rehberi · Siber Güvenlik
Sertifika Yaşam Döngüsü Platformu Seçimi: ACME, PKI ve Otomasyon
Sertifika yönetiminde seçim yalnız CA seçmek değildir. Hangi sistemlerin sertifika kullandığı, anahtarın nerede üretildiği, onayın nasıl verildiği ve yenilemenin servise nasıl yüklendiği…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Sertifika yönetiminde seçim yalnız CA seçmek değildir. Hangi sistemlerin sertifika kullandığı, anahtarın nerede üretildiği, onayın nasıl verildiği ve yenilemenin servise nasıl yüklendiği birlikte ele alınır. Dış web, iç servis, cihaz ve kullanıcı sertifikaları farklı kimlik kanıtlarına ihtiyaç duyar.
ACME otomatik sertifika isteme/yenileme protokolüdür; başlı başına kurumsal envanter veya yetki yönetimi değildir. İç PKI kök dağıtımı ve güven zincirini yönetirken yönetim platformu farklı CA ve protokolleri birleştirebilir. Üretici bağımlılığını azaltmak için standart protokol, dışa aktarılabilir envanter ve anahtar erişim kontrolünü değerlendirin.
Pilot seçimi en kolay web sunucusuyla sınırlamayın. Eski cihaz, load balancer ve otomasyon API’si olmayan bir uygulamayı dahil edin. Yenileme başarısı dosyanın oluşması değil, doğru sertifikanın gerçek uç noktadan sunulmasıdır.
- 1Envanter ve sahiplik
- 2İstem/onay protokolü
- 3Anahtar ve dağıtım
- 4Uç nokta doğrulama
Tasarım parametreleri
- Kapsam
- TLS, mTLS, kullanıcı ve cihaz sertifikalarını desteklenen protokol ve işletim sistemiyle eşleştirin.
- Anahtar egemenliği
- Dışa aktarılabilir anahtar, donanımsal koruma ve yeniden üretim gereksinimlerini iş yüküne göre seçin.
- Operasyon kanıtı
- Keşif, yenileme, dağıtım doğrulaması, alarm ve acil iptal için ayrı kabul ölçütleri yazın.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Yaklaşım | Güçlü taraf | Ek gereksinim |
|---|---|---|
| ACME istemcisi | Tekrarlanabilir istem/yenileme | Envanter ve dağıtım doğrulaması |
| İç PKI | Kurumsal güven ve kimlik politikası | Kök dağıtımı ve CA işletimi |
| Yaşam döngüsü platformu | Çoklu CA ve uç nokta koordinasyonu | Konnektör, erişim ve çıkış testi |
Hesap ve uygulama örneği
120 uç nokta için 80 otomatik, 25 yarı otomatik ve 15 manuel yenileme olduğunu varsayın. Yıllık iş yükünü her grubun yenileme sayısı × işlem süresiyle hesaplayın; CA aboneliği dışındaki bakım ve kesinti maliyetini ekleyin. Bir pilotta yenileme sonrası uç nokta fingerprintini eski değerle karşılaştırın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Envanter yeşil, servis eski sertifika sunuyor | Dosya yenilendi ancak servis yeniden yüklenmedi. | Gerçek TLS uç noktasının seri numarasını okuyun. |
| İç istemciler yeni CA’yı kabul etmiyor | Güven kökü dağıtımı eksik. | Pilot istemcilerde zinciri ve güven deposunu doğrulayın. |
Kabul ve doğrulama kontrolleri
- Sertifika tüketen tüm uç noktaları listeleyin.
- Her sertifikaya sahip atayın.
- Anahtar yetkilerini test edin.
- Yenilemeyi gerçek uç noktada doğrulayın.
- Acil iptal ve geri dönüşü sınayın.
- Envanter dışa aktarımını doğrulayın.
İlgili kavramlar
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
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.
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.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalı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.