Bulut altyapınızın güvenliğini değerlendirirken, genellikle değişimleri izleyen sistemlere güveniyorsunuz. Güvenlik grubu kurallarının değişmesi, veritabanı örneğinin halka açık duruma gelmesi ya da yanlışlıkla yapılan etiketlemeler gibi durumlar, otomatik olarak risk olarak işaretlenir. Ancak bu yaklaşımın en büyük zaafı, hiçbir şeyin değişmediği tehlikeli durumları gözden kaçırmasıdır.
Örneğin, AWS Secrets Manager’da saklanan bir gizli anahtarın 200 günden uzun süredir döndürülmediğini varsayalım. Hafta boyunca her gün tarama yapsanız bile, sistem hiçbir değişiklik algılamayacaktır. Çünkü gizli anahtar döndürülmediği için statik bir durumda kalmaktadır. Bu da, mevcut sistemlerin “ne değişti?” sorusuna odaklanması nedeniyle, “şu anda ne durumda?” sorusunu yanıtsız bırakması anlamına gelir.
Değişim tabanlı algılama sisteminin sınırları
Çoğu bulut güvenlik aracı, iki farklı anlık görüntüyü karşılaştırarak çalışır. Örneğin, geçen hafta yapılan bir değişiklik, güvenlik riski olarak değerlendirilir. Ancak bu yaklaşım, sürekli olarak aynı durumda kalan varlıklar için yetersiz kalır. Özellikle gizli anahtarların döndürülmemesi gibi statik koşullar, değişim tabanlı sistemler tarafından algılanamaz.
Bu sorunu çözmek için, iki farklı modül geliştirmek gerekiyor:
- Değişim tabanlı kurallar (Diff-based rules): Var olan sistemde olduğu gibi, iki anlık görüntü arasındaki farkları değerlendirir.
- Statik durum kuralları (Standing condition rules): Mevcut durumu doğrudan analiz eder ve değişim olup olmadığına bakmaz.
Bu şekilde, hem değişikliklere hem de statik risklere karşı kapsamlı bir koruma sağlanabilir.
Gizli anahtarların döndürülme durumunu nasıl değerlendiriyoruz?
Gizli anahtarların döndürülme durumu, basit bir boolean değil, bir risk merdiveni olarak değerlendirilmelidir. Her basamak, farklı bir ciddiyet düzeyini temsil eder:
def assess_rotation(raw_data, now, max_age_days):
raw = raw_data or {}
findings = []
# Döndürme otomatik olarak devre dışı bırakılmış mı?
if not _truthy(raw.get('rotation_enabled')):
findings.append({
'field': 'rotation_enabled',
'severity': 'HIGH',
'reason': 'Otomatik döndürme devre dışı bırakılmış'
})
return _wrap(findings)
# Döndürme hiç yapılmamış mı?
last = _parse(raw.get('last_rotated_date'))
if last is None:
findings.append({
'field': 'last_rotated_date',
'severity': 'MEDIUM',
'reason': 'Döndürme etkin ancak gizli anahtar hiç döndürülmemiş'
})
return _wrap(findings)
# Geçen süre hesaplanıyor
age_days = (now - last).days
# Kritik eşikler
if age_days >= max_age_days * 2:
findings.append({
'severity': 'CRITICAL',
'reason': 'İki katı geçiş süresi aşılmış'
})
elif age_days >= max_age_days:
findings.append({
'severity': 'HIGH',
'reason': 'Geçiş süresi aşılmış'
})
return _wrap(findings)- Otomatik döndürme devre dışı: YÜKSEK risk. Döndürme hiç olmayacak, bu nedenle en ciddi durumdur.
- Döndürme etkin ancak hiç yapılmamış: ORTA risk. Sistemin doğru yapılandırılmadığını gösterir.
- Geçiş süresi aşılmış: YÜKSEK risk. 90 günlük varsayılan sürenin geçilmesiyle oluşur.
- İki katı geçiş süresi aşılmış: KRİTİK risk. 180 günlük sürenin geçilmesi, sürecin tamamen gözden kaçtığını gösterir.
Bu değerlendirme, salt mevcut duruma odaklanan ve değişimlere bağlı olmayan bir fonksiyon olarak çalışır. Böylece, sistemin sadece AWS API’lerinden gelen metadata ile çalışması sağlanır.
Veri güvenliği: Gizli anahtarların kendisi hiç okunmuyor
Güvenlik tarayıcılarının en büyük risklerinden biri, gizli anahtarları okumak olabilir. Ancak bu sistem, sadece metadata’ları kullanır. AWS Secrets Manager’ın list_secrets çağrısı, gizli anahtarın kendisini değil, sadece:
- Döndürme durumu (
RotationEnabled) - Son döndürme tarihi (
LastRotatedDate) - Bir sonraki döndürme tarihi (
NextRotationDate) - Döndürme kuralları (
RotationRules)
ilgilerini döndürür. Gizli anahtarın kendisi asla okunmaz ve sistemden dışarı çıkmaz.
Bunun doğruluğunu test etmek için, yalnızca metadata’ları içeren bir kayıt oluşturulur ve gizli anahtarın kendisi sistemde hiçbir zaman saklanmaz.
“Değişikliği kim yaptı?” sorusu statik durumlarda yanıtsız kalıyor
Çoğu güvenlik aracında, bir riskin detayında “Değişikliği kim yaptı?” butonu bulunur. Bu buton, CloudTrail gibi hizmetlere başvurarak, değişikliği yapan kullanıcıyı tespit eder. Ancak statik durumlar için bu buton anlamsız hale gelir.
Örneğin, gizli anahtarın 200 günden uzun süredir döndürülmemesi, hiçbir kullanıcı tarafından yapılan bir eylem değildir. Bu nedenle, CloudTrail’e başvurulduğunda, hiçbir sonuç dönmeyecektir.
Bu durumda, buton yalnızca değişiklik tabanlı riskler için gösterilmelidir. Statik durumlarda, “kim yaptı?” sorusu mantıksızdır.
Sistemdeki sınırlamalar ve geleceğe yönelik öneriler
Bu yaklaşımın bazı doğal sınırları vardır:
- Risk merdiveni bir kuraldır, politika değil. 90 günlük varsayılan süre ve iki katı geçiş eşiği, varsayılan değerlerdir. Her organizasyon, kendi ihtiyaçlarına göre bu değerleri ayarlamalıdır.
- Statik durumların tespiti için değişim tabanlı sistemlere bağımlı kalmamak gerekir. Mevcut durum analizi, gelecekteki güvenlik araçlarının temel bileşeni olacaktır.
Gelecekte, bulut güvenlik sistemlerinin hem dinamik hem statik riskleri aynı hassasiyetle değerlendirmesi bekleniyor. Bu sayede, değişimlere odaklanan sistemler, statik tehlikeleri de yakalayabilecek ve bulut altyapılarının güvenliği daha da sağlamlaşacaktır.
Yapay zeka özeti
Bulut sistemlerinde gizli anahtarların dönme süresi ihlallerini tespit etmek için statik durum analizi şart. Değişim tabanlı sistemlerin kaçırdığı riskleri nasıl yakalarsınız?