
Yedekleme betiği kök kullanıcı olarak çalışıyor. İzleme aracı da kök kullanıcı. Dağıtım sistemi de. Üç farklı otomasyon aynı sınırsız yetkiyi taşıyor ve birinin ele geçirilmesi sunucunun tamamını kaybettirir.
Bu yazı, otomasyon erişimlerinin doğru yapılandırılmasını ele alıyor.
Neden Ayrı Hesap?
- Yetki sınırlanabilir.
- Hangi otomasyonun ne yaptığı ayrışır.
- Biri iptal edilse diğerleri çalışır.
- Denetim izi anlamlı olur.
Dördüncü madde teşhis açısından çok değerlidir: tüm otomasyonlar aynı hesapla çalışıyorsa, günlükte görünen bir işlemin hangi araca ait olduğu asla anlaşılmaz.
Ayrı hesaplarla ise "bu dosyayı yedekleme betiği mi sildi, dağıtım sistemi mi?" sorusu saniyeler içinde cevaplanır.
Üçüncü madde ise olay müdahalesinde kritiktir. Şüpheli bir otomasyonu devre dışı bırakmak, diğer tüm işleri durdurmamalıdır.
En Az Yetki İlkesi
Her otomasyon yalnızca işini yapabilmelidir:
| Otomasyon | Gereken yetki |
|---|---|
| İzleme aracı | Salt okuma |
| Yedekleme betiği | Veri okuma, hedefe yazma |
| Dağıtım sistemi | Uygulama dizini ve servis yeniden başlatma |
| Günlük toplayıcı | Günlük dosyalarını okuma |
Birinci satır çok sık ihlal edilir: izleme araçları yalnızca veri okur ama çoğu kurulumda kök yetkisiyle çalıştırılır — oysa ihtiyaç duyduğu bilgilerin neredeyse tamamı sıradan bir kullanıcıya da açıktır.
Bazı ölçümler için yükseltilmiş yetki gerekebilir; bu durumda tüm araca değil, yalnızca o tek komuta izin verilir.
Üçüncü satır ise dikkatli tanımlanmalıdır. Dağıtım sisteminin servis yeniden başlatabilmesi gerekir ama tüm servisleri değil, yalnızca ilgili olanı.
Seçici Yetki Yükseltme
Tam yetki yerine komut bazında izin verilebilir:
- Hangi komutlara izin verildiği tanımlanır.
- Parametreler de sınırlanabilir.
- Parola sorulmadan çalışması ayarlanır.
- Her kullanım kaydedilir.
İkinci madde çoğu kurulumun atladığı ince ama önemli bir ayrıntıdır: bir servisi yeniden başlatma izni verilirken hangi servis olduğu belirtilmezse, o hesap veritabanını ve güvenlik duvarını da yeniden başlatabilir.
İzin tanımı mümkün olduğunca dar yazılmalıdır.
Üçüncü madde otomasyon için zorunludur çünkü betik parola giremez. Ancak bu, izin listesinin dar tutulmasını daha da kritik hâle getirir.
Dördüncü madde ise denetim sağlar. Yükseltilmiş yetkiyle çalıştırılan her komut günlüğe düşer.
Oturum Açma Kısıtları
Hizmet hesapları insan gibi davranmamalıdır:
- Etkileşimli giriş kapatılmalı.
- Parola ile giriş devre dışı olmalı.
- Yalnızca anahtarla erişilmeli.
- Kaynak adres kısıtlanmalı.
Birinci madde önemli bir savunma katmanıdır: bir hizmet hesabının kabuğu devre dışı bırakılırsa, o hesabın kimlik bilgisi ele geçirilse bile saldırgan etkileşimli bir oturum açamaz.
Betikler yine de o kullanıcı adına çalışabilir; kısıtlanan yalnızca doğrudan giriştir.
Dördüncü madde ise erişimi coğrafi ve mantıksal olarak daraltır. Yedekleme hesabı yalnızca yedekleme sunucusundan bağlanabilmelidir.
Kimlik Bilgilerini Saklamak
| Yer | Değerlendirme |
|---|---|
| Betik içinde | Kabul edilemez |
| Sürüm kontrolünde | Kabul edilemez |
| Kısıtlı izinli dosyada | Kabul edilebilir |
| Sır yönetim sisteminde | En iyi |
| Komut satırı parametresinde | Riskli |
Beşinci satır az bilinen bir sızıntı yoludur: komut satırında geçirilen bir parola, süreç listesini görebilen tüm kullanıcılar tarafından okunabilir — hatta sunucudaki başka bir hesap tarafından.
Bu nedenle kimlik bilgileri ya ortam değişkeninden ya da kısıtlı izinli bir dosyadan okunmalıdır.
İkinci satır ise geri alınamaz bir hatadır. Sürüm geçmişine giren bir sır, sonradan silinse bile geçmişte durmaya devam eder.
Hesap Envanteri
Zamanla biriken hesapları takip etmek gerekir:
- Her hizmet hesabının amacını yazın.
- Hangi otomasyona ait olduğunu belirtin.
- Sorumlusunu tanımlayın.
- Kullanılmayanları kaldırın.
Dördüncü madde düzenli denetim gerektirir: artık kullanılmayan bir araç için oluşturulmuş hizmet hesabı, sunucuda erişim yetkisiyle beklemeye devam eder ve kimse fark etmez.
Bu hesaplar saldırı yüzeyini genişletir ve hiçbir fayda sağlamaz.
Birinci madde ise silme kararını mümkün kılar. Ne işe yaradığı yazılmayan bir hesabı kimse silmeye cesaret edemez.
Anormal Davranışı Yakalamak
- Beklenmedik saatte çalışma.
- Beklenmedik adresten bağlantı.
- Yetki dışı komut denemesi.
- Anormal veri hacmi.
Birinci madde güçlü bir sinyaldir çünkü otomasyon öngörülebilirdir: yedekleme hesabı her gece aynı saatte çalışıyorsa, öğle vakti bir bağlantı görmek doğrudan şüphelidir — insan hesaplarında böyle net bir desen yoktur.
Bu öngörülebilirlik, hizmet hesaplarını izlemeyi insan hesaplarını izlemekten daha kolay ve daha etkili kılar.
Üçüncü madde ise erken uyarıdır. Yetki dışı bir komut denemesi, ya yanlış yapılandırma ya da kötüye kullanım göstergesidir.
Erişim ve yetki yapılandırmasını kurulum aşamasında planlamak gerekir; dedicated sunucu hizmeti teslim alındığında kök erişimi size ait olduğu için bu yapıyı baştan doğru kurabilirsiniz.
Sonuç
Tüm otomasyonların kök yetkisiyle çalışması yalnızca güvenlik sorunu değildir: aynı hesapla çalışan araçlarda, günlükte görünen bir işlemin hangi araca ait olduğu asla anlaşılmaz. Her otomasyona ayrı hesap açın ve yetkiyi dar tanımlayın — özellikle servis yeniden başlatma izninde hangi servis olduğunu belirtin, yoksa o hesap veritabanını da yeniden başlatabilir. Kimlik bilgilerini komut satırında geçirmeyin; süreç listesini görebilen herkes o parolayı okuyabilir.
Sıkça Sorulan Sorular (SSS)
Neden her otomasyona ayrı hesap?
Yetkiyi sınırlamak, birini iptal ederken diğerlerini etkilememek ve en önemlisi denetim izini anlamlı kılmak için. Tüm araçlar aynı hesapla çalışıyorsa günlükteki bir işlemin hangi araca ait olduğu anlaşılmaz; ayrı hesaplarla bu soru saniyeler içinde cevaplanır.
İzleme aracına kök yetkisi gerekir mi?
Genellikle hayır. İzleme araçları yalnızca veri okur ve ihtiyaç duydukları bilgilerin neredeyse tamamı sıradan bir kullanıcıya da açıktır. Belirli ölçümler için yükseltilmiş yetki gerekiyorsa, tüm araca değil yalnızca o tek komuta izin verin.
Seçici yetki verirken neye dikkat etmeliyim?
İzni mümkün olduğunca dar yazın ve parametreleri de sınırlayın. Bir servisi yeniden başlatma izni verirken hangi servis olduğu belirtilmezse, o hesap veritabanını ve güvenlik duvarını da yeniden başlatabilir. Ayrıca her yükseltilmiş komut kullanımının günlüğe düştüğünden emin olun.
Kimlik bilgilerini nereye koymalıyım?
Sır yönetim sistemine, yoksa kısıtlı izinli bir dosyaya. Betiğin içine veya sürüm kontrolüne asla koymayın — geçmişe giren bir sır sonradan silinse bile orada durur. Komut satırı parametresi de risklidir: süreç listesini görebilen tüm kullanıcılar o parolayı okuyabilir.