En Az Privilej Prensibi, Açıklandı
En az privilej prensibinin pratik bir analizi: bunun ne anlama geldiği, neden ihlaller bunu olmadan yayılır ve bunu gerçekten nasıl uygulanır.
En az privilej, söylediğiniz zaman açık görünür: bir hesaba, işleme veya kullanıcıya işini yapmak için ihtiyaç duyduğu erişimi verin, başka bir şey yok. Bunu söylemek ile sistemlerinizi bu şekilde çalıştırmak arasındaki boşluk, çoğu ihlalinin küçük bir olaydan tam bir domain uzlaşmasına dönüştüğü yerdir.
Bunun gerçekte ne anlama geldiği
En az privilej prensibi (PoLP), bir sistemdeki her konu — bir kullanıcı, bir hizmet hesabı, bir uygulama, bir konteyner — işlevini tamamlamak için gerekli olan minimum izin setiyle çalışmalıdır. Uygun olan izinler değil. Üç yıl önce birinin verip iptal etmeyi unuttuğu izinler değil. Minimum.
Bu her katmanda geçerlidir: dosya sistemi izinleri, veritabanı rolleri, API kapsamları, bulut IAM ilkeleri, güvenlik duvarı kuralları, sudo erişimi. Statik dosyaları okuyan bir web sunucusu işlemi /etc konumuna yazma erişimine ihtiyaç duymaz. Yalnızca SELECT sorguları çalıştıran bir raporlama betiği DROP TABLE haklarına sahip bir veritabanı rolüne ihtiyaç duymaz. Pazarlama stajyeri, doğru grubu bulmaktan daha kolay olduğu için domain admin'e ihtiyaç duymaz.
Bunun ses çıkardığından daha fazla neden önemli olduğu
Saldırgan bir hesabı veya işlemi tehlikeye atarsa, o hesabın yapabileceği her şeyi devralır. Phishing'e uğramış bir çalışanın dizüstü bilgisayarının yalnızca ekibine ait dosya paylaşımlarına erişimi varsa, bu phishing'in etki alanı sınırlandırılmıştır. Aynı hesap, BT'nin bunu bir kez sorun giderme için bu şekilde ayarladığı ve hiçbir zaman geri alınmadığı için domain admin haklarına sahipse, saldırgan artık ağa sahiptir.
Bu, çoğu ihlal sonrası adli rapor ardında yatan mantıktır: ilk erişim düşük değerdi, ancak aşırı izinli hesaplar aracılığıyla yanal hareket bunu tüm ortam genelinde fidye yazılımına dönüştürdü. Fazla izin ilk uzlaşmayı neden olmaz, ancak uzlaşmayı pahalı kılan neredeyse her zaman budur.
Pratikte nerede göründüğü
Bulut IAM. AWS, Azure ve GCP, dikkatli olmadığınız takdirde varsayılan olarak izin verici davranışa sahiptir — "Action": "*" ve "Resource": "*" ile bir IAM ilkesi doğrulamayı geçer ve sıfır saat kadar iyi çalışır, sızdırılan bir erişim anahtarı bir saldırgana tam hesap kontrolü verinceye kadar. İlkeleri joker karakterlere ulaşmak yerine belirli eylemlere ve kaynak ARN'lerine kapsamlı hale getirin.
Hizmet hesapları. Bunlar, insanın hesapları inceledikleri şekilde gözden geçirilmedikleri için sıkça en kötü suçlulardır. Bir CI/CD boru hattı bir S3 paketine dağıtılması, hesaptaki her paketi okuyabilen kimlik bilgilerini tutmamalıdır.
Veritabanı rolleri. Salt okunur raporlama rollerini INSERT/UPDATE gerektiren uygulama rollerinden ayırın ve bunları şemayı değiştirebilen DBA rolünden ayırın. PostgreSQL ve MySQL, ayrıntılı GRANT ifadelerini destekler — her uygulama bağlantısına root'un eşdeğerini vermek yerine bunları kullanın.
Sudo ve yerel admin. Just-in-time yükseltme (erişim talep edin, sınırlı bir pencere için alın, otomatik olarak kaybetmeyin), daima duran admin haklarını yener. sudo gibi araçlar zaman sınırlı kurallarla veya kurumsal ortamlarda PAM çözümleri, bunun için özel olarak mevcuttur.
Gerilim ile
AI yardımıyla yazıldı, Michal Pilch (CISSP), Korra Studio tarafından incelendi ve yayınlandı.
Bu, Korra Studio bilgi tabanından bir nottur — platform her konuyu 1-to-1 mentoring ile eşleştirir.
Ücretsiz başlaarrow_forward