Bulut sunucuda en yaygın kimlik hatası, yerel yönetici hesabını birden çok kişiye ve birden çok sunucuya açık bırakmaktır. Kurulum anında kolay görünür, ama altı ay sonra kimin hangi yetkiyle neyi değiştirdiği bilinmez. Doğru yaklaşım üç adımdır. Kimliği merkezde toplayın, yönetici yetkisini süreli verin ve her girişi kayıt altına alın.
Hızlı Özet
IaaS modelinde misafir işletim sistemi, uygulama ve kimlik sizin sorumluluğunuzdadır. Yerel admin hesapları sunucu başına ayrı parola ister. Ayrılan bir çalışanın erişimini kapatmak zorlaşır ve olay anında kimin değişiklik yaptığı izlenemez. Yerel hesapları merkezi kimliğe bağlamak, yetkiyi talep ve onay ile süreli vermek ve oturumları kayda almak bu sorunu büyük ölçüde çözer. Leon-X bulut altyapısının sahibi değildir. Bu kararlar mevcut ortamın keşfinde birlikte netleşir.
İçindekiler
- Yerel Admin Hesabı Neden Sorun Olur
- Kimlik Sorumluluğu Katmanlara Ayrılır
- Yönetici Yetkisi Süreli Verilir
- Oturum Merkezi Kimlikten Açılır
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Rear of rack at NERSC data center - closeup. Fotoğraf Derrick Coetzee tarafından çekilmiş olup CC0 kapsamında kamu malıdır. Görsel WebP biçimine çevrilip boyutlandırıldı.
Yerel Admin Hesabı Neden Sorun Olur
Yerel yönetici hesabı tek bir sunucuda makul görünür. Ama bulut ortamında sunucu sayısı hızla artar. Sanal sunucu ile bulut sunucu arasındaki işletim farkları için bu karşılaştırmaya bakabilirsiniz. Her sanal makineye ayrı parola verilirse parola yönetimi dağılır. Bir çalışan ayrıldığında her sunucuya tek tek girip hesabı kapatmak gerekir ve bu adım çoğu zaman atlanır. Ortak bir yönetici hesabı ise en kötü seçenektir, çünkü olay anında hangi kişinin işlem yaptığı görünmez.
Uygulama hesapları da bu tabloya girer. Bir servis hesabı yönetici yetkisiyle açılırsa uygulamadaki tek bir açık sunucunun tamamına kadar uzanabilir. Yerel admin alışkanlığını bırakmak bu yüzden yalnızca düzen meselesi değildir. Saldırı yüzeyini daraltmanın da yoludur.
Kimlik Sorumluluğu Katmanlara Ayrılır
Kimliği tek bir başlık altında düşünmek yetmez. Dört katmanın her birine ayrı sahip atamak gerekir. Sağlayıcı konsolu sanal makinenin yönetim düzlemidir ve buradaki rol modeli ayrı tanımlanır. İşletim sistemi katmanında yönetici yetkisinin kimde olacağı yazılır. Uygulama katmanında servis hesapları ve veritabanı kullanıcıları durur. Veri katmanında yedek ve anahtar erişimi ayrılır.
Sahibi belli olmayan yetki, bir süre sonra kimsenin bakmadığı bir yetkiye dönüşür. Bu tabloyu proje başında çıkarın ve sağlayıcının sorumluluk sınırıyla karşılaştırın. Kimlik katmanının taşıma sırasında nasıl doğrulanacağı için buluta geçiş kontrol listesi da işinize yarar. Hangi katmanın sağlayıcıda, hangisinin sizde kaldığını görmek için IaaS sorumluluk paylaşım yazısı iyi bir başlangıçtır.
Yönetici Yetkisi Süreli Verilir
Yerel yönetici hakkını tümden kaldırmak çoğu zaman mümkün değildir. Sistemin işi için bir kişiye yetki gerekir. Bu yüzden yetki talep üzerine, süreli ve onaylı verilmelidir. Bir değişiklik için istek açılır, onaylayan kişi belirlenir ve yetki belirli bir süre sonra kendiliğinden düşer.
Bu modelde üç şey zorunludur. Birincisi, yönetici grubu üyeliği tek bir kimlik sağlayıcıdan yönetilir. İkincisi, varsayılan yerel hesap devre dışı bırakılır ya da parolası güvenli bir kasada tutulur. Üçüncüsü, acil durum için bir kırılma hesabı tanımlanır ve her kullanımı kayda geçirilir. Kırılma hesabı genellikle kimlik sağlayıcıya ulaşılamadığı anda gerekir. Bu yüzden onun da kendi kaydı olmalıdır. Yetki ve erişim kayıtlarının denetimde nasıl tutulacağı için ISO 27001 erişim kontrolü yazısı yardımcı olur.
Oturum Merkezi Kimlikten Açılır
Yönetici oturumları merkezi dizin hizmeti ya da kimlik sağlayıcı üzerinden açılmalıdır. Linux sunucularda parola ile giriş kapatılır ve her yöneticinin kendi SSH anahtarı olur. Her iki durumda da yönetici girişinde çok faktörlü doğrulama istenir. Yönetim portuna erişim yalnızca bilinen adres aralıklarından açılır.
Burada sık gözden kaçan bir nokta var. Ortak anahtar dosyası, ortak parola kadar tehlikelidir. Ayrılan bir çalışanın anahtarı sunucudan silinmezse kapı açık kalır. Anahtar listesini düzenli gözden geçirin ve her anahtarın kime ait olduğunu kayıt altında tutun.
Yaygın Hatalar
Yerel admin hesabını her sunucuya aynı parolayla bırakmak ilk hatadır. Tek bir parola sızdığında bütün sunucular aynı anda açılır.
Ayrılan çalışanın hesabını yalnızca e-posta ve kurumsal kimlik üzerinden kapatıp sunucudaki yerel hesapları unutmak ikinci hatadır. Merkezdeki hesap kapatıldığında sunucudaki yerel kayıt ayrıca temizlenmelidir.
Servis hesabına yönetici yetkisi vermek üçüncü hatadır. Uygulamanın çalışması için gereken yetki çoğu zaman çok daha dardır.
Son olarak yetki değişikliklerini kayda geçirmemek vardır. Olay anında kimin ne zaman yetki aldığını bilmeden kök nedeni bulmak uzar.
Kontrol Listesi
- Her sunucudaki yerel yönetici hesapları listelendi mi?
- Ortak yönetici hesabı kaldırıldı mı, ya da parolası kasada mı?
- Yönetici grubu tek bir kimlik sağlayıcıdan mı yönetiliyor?
- Yetki talepleri onaylı ve süreli mi veriliyor?
- Yönetici girişinde çok faktörlü doğrulama açık mı?
- Ayrılan çalışanların hesapları hem merkezde hem sunucularda kapatıldı mı?
- Kırılma hesabının her kullanımı kayda geçiyor mu?
- Yetki kayıtları ne zaman gözden geçirildi ve bir sonraki ne zaman yapılacak?
Leon-X ile Sonraki Adım
Leon-X bulut sunucu altyapısının sahibi değildir. Danışman ve çözüm ortağı olarak mevcut kimlik yapısını, yönetici gruplarını ve servis hesaplarını birlikte inceler. Hangi katmanın hangi ekiple yönetileceği keşifte netleşir. Kesin yapılandırma kararları sizin ekibinizin onayıyla uygulanır. Bulut sunucu kapsamını görmek için bulut sunucu çözümleri sayfasına bakabilirsiniz. Mevcut kurulumunuz için iletişime geçebilirsiniz.
Sık Sorulan Sorular
Yerel admin hesabını tamamen kaldırmak mümkün mü?
Çoğu ortamda mümkündür. Ancak acil durum erişimi için bir kırılma hesabı tutulmalıdır. Bu hesap kasada durur ve her kullanımı kayda geçer.
Sağlayıcı kimlik altyapısını işletiyorsa sorumluluk da onda mı?
Hayır. Sağlayıcı kimlik altyapısını işletebilir, ama hangi kişinin hangi sunucuda yönetici olacağı müşterinin kararıdır. Bu ayrım proje öncesinde yazılı hale getirilmelidir.
Süreli yetki iş akışını yavaşlatır mı?
Başlangıçta talep adımı biraz zaman alır. Onay süreci kısa tutulduğunda acil değişiklikler de kabul edilebilir bir sürede ilerler.
Sonuç
Bulut sunucuda yerel admin alışkanlığı kısa vadede kolaylık sağlar, ama kimin neyi değiştirdiğini bilmeyi zorlaştırır. Kimliği katmanlara ayırın, yönetici yetkisini süreli verin ve oturumları merkezi kimlikten açın. Mevcut yapınızı bulut sunucu çözümleri kapsamıyla birlikte değerlendirmek için keşfe başlayabilirsiniz.
Kaynaklar
- Kullanılan bulut sağlayıcısının kimlik ve erişim yönetimi dokümantasyonu
- Kurumun kendi erişim politikası ve denetim kayıtları
