Mfa OAuth onay istismarından sizi kurtarmaz

Açıklıklar ve Tehditler

Siber Saldırılar ve Veri İhlalleri

Kimlik ve Erişim Yönetimi Güvenliği

MFA temel olmakla birlikte OAuth yönetimini, en az ayrıcalık kapsamlarını, onay izlemesini ve hızlı iptali ikame edemez.

Vishnu Galata, Kıdemli Profesyonel Hizmetler Danışmanı, F5 Inc.

Saldırganlar tek bir ikna edici onay istemiyle şifreye veya kötü amaçlı yazılıma ihtiyaç duymadan kalıcı yazılım-olarak-hizmet erişimi elde edebilir.

Güvenlik ekipleri uzun süredir çok faktörlü kimlik doğrulamayı bir hesabın korunduğuna dair güçlü bir işaret olarak gördü. Bu düşünce anlaşılır, ancak eksik. MFA kimlik doğrulamasını güvence altına alır. Kullanıcı giriş yaptıktan sonra neyi yetkilendirebileceğini kontrol etmez.

Bu ayrım önemlidir çünkü OAuth onayı SaaS ve bulut ortamlarında ayrı bir erişim yolu haline geldi. Bir kullanıcı giriş yapabilir, MFA'dan geçebilir ve hâlâ e-posta, dosya, depo, iş platformları veya bulut bağlantılı iş akışlarına erişim sağlayan bir uygulamayı onaylayabilir. Şifre çalınmasına gerek yoktur. Kötü amaçlı yazılımın çalışması gerekmez. Risk kullanıcı meşru bir sağlayıcı alanında gezinirken başlayabilir.

OAuth onay istismarı daha fazla dikkat hak eder çünkü bu yalnızca bir kimlik avı sorunu değildir. Bu bir yetkilendirme yönetimi sorunudur.

Saldırı yolu basittir. Bir kullanıcı e-posta, sohbet, paylaşılan bir belge veya sorun izleyicisi üzerinden bir bağlantı alır. Bağlantı bir bulut veya SaaS sağlayıcısı için gerçek bir OAuth yetkilendirme akışına götürür. Uygulama zararsız görünebilir; örneğin bir üretkenlik bağlayıcısı, raporlama aracı veya iş akışı asistanı.

Kullanıcı zaten oturum açtığı için süreç rutin gibi gelir. Onay ekranı izinler ister. Kullanıcı onaylar.

O noktada saldırgan kullanıcının şifresine ihtiyaç duymaz. Sağlayıcıya, uygulama türüne, kiracı politikasına ve verilen kapsamlara bağlı olarak saldırgan, izinler iptal edilene veya jetonlar geçersiz kılınana kadar devam eden API erişimi sağlayan jetonlar veya uygulama izinleri elde edebilir.

Saldırgan daha sonra verilere erişebilir, posta kutularını arayabilir, dosyaları listeleyebilir, kaynak kodu çıkarabilir, depo ayarlarını değiştirebilir, CI/CD meta verilerine erişebilir veya onaylı API'ler aracılığıyla iş platformlarıyla etkileşime geçebilir.

OAuth Bozuk Değil; Yönetim Bozuk

Risk OAuth'un kendisinin bozuk olması değildir. OAuth tasarlandığı şeyi yapar: erişimi devretmek.

Sorun, birçok kuruluşun devredilen erişime sınırlı inceleme, aşırı kapsam ve onay sonrası zayıf izleme ile izin vermesidir. Sonuç olarak tek bir kullanıcı kararı hassas sistemlere kalıcı erişim yaratabilir.

Bu nedenle MFA tek başına yetersizdir. Kimlik doğrulamasından sonra onay kararları genellikle güvenilen oturumlar içinde gerçekleşir. Güvenlik ekipleri başarılı girişler, meşru alanlar ve normal API trafiği görebilir. Uç nokta ve ağ araçları kötü amaçlı yazılım veya geleneksel komuta-kontrol trafiği olmadığı için şüpheli bir şey tespit etmeyebilir.

Hatta olgun güvenlik bilgisi ve olay yönetimi programları bile yeni uygulama izinlerini, riskli kapsamları, olağandışı jeton etkinliğini ve onay sonrası API davranışındaki önemli değişiklikleri özellikle izlemedikçe riski kaçırabilir.

Birçok kimlik programı MFA benimsemesini, riskli girişlerin engellenmesini ve ayrıcalıklı hesap korumasını takip eder. Bu kontroller önemlidir, ancak kritik bir soruyu yanıtlamaz: Üçüncü taraf uygulamaların kurumsal verilere erişimini kim verebilir ve bu onay istismar edilirse bunu ne kadar hızlı öğrenirdik?

Bu soru, kuruluşlar SaaS platformlarına, bulut konsollarına, kaynak kodu depolarına, otomasyon araçlarına ve üretkenlik uygulamalarına güvendikçe daha da önem kazanır. Her entegrasyon talebi hem bir kolaylık kararı hem de bir güvenlik kararıdır.

Takvim erişimini onaylamak bir şeydir. Geniş e-posta, dosya, depo veya yönetici erişimini onaylamak başka bir şeydir.

İlk kontrol onay yönetişimidir. Kuruluşlar kullanıcıların üçüncü taraf uygulamaları varsayılan olarak onaylamasını kısıtlamalıdır.

Yüksek riskli kapsamlar yönetici onayı gerektirmelidir. Doğrulanmamış veya tanıdık olmayan uygulamalar engellenmeli veya inceleme için yönlendirilmelidir. Güvenlik ekipleri e-posta, dosya depolama, kaynak kontrol, CRM, kimlik sistemleri, bulut konsolları ve otomasyon platformları gibi daha katı onay kontrolleri gerektiren yüksek değerli platformları belirlemelidir.

Her entegrasyon engellenmemelidir. Ancak onay, kullanıcıların saniyeler içinde anlaması beklenen hızlı bir açılır pencere olarak değil, erişim kadar dikkatli yönetilmelidir.

İkinci kontrol kapsam disiplini. Geniş izinler kullanışlıdır, ancak OAuth istismarını da mümkün kılar.

Bir takvim entegrasyonunun geniş dosya erişimine ihtiyacı olmamalıdır. Bir raporlama bağlayıcısının depo yönetici haklarına sahip olmamalıdır. Bir iş akışı aracı açık bir iş gerekçesi ve sorumlu bir sahibi olmadıkça kuruluş çapında izin almamalıdır.

Güvenlik ekipleri OAuth kapsamlarını güvenlik duvarı kuralları, ayrıcalıklı roller veya üretim erişimi kadar titizlikle gözden geçirmelidir. Kapsamlar spesifik, gerekçelendirilmiş, belgelenmiş ve düzenli olarak yeniden doğrulanmalıdır.

Üçüncü kontrol onay sonrası izlemedir. Tespit giriş olayında durmamalıdır.

Temel sinyaller yeni uygulama onayları, yeni hizmet sorumluları veya kurumsal uygulamalar, yüksek ayrıcalıklı kapsamların onaylanması, olağandışı konumlardan yetkilendirme, tanıdık olmayan altyapıdan yenileme jetonu etkinliği ve kullanıcının tipik düzeninden sapma gösteren API davranışını içerir.

Normalde birkaç belge okuyan bir kullanıcı aniden toplu indirme, depo değişiklikleri, posta kutusu aramaları veya CI/CD güncellemeleri gerçekleştirirse oturum kimlik doğrulamalı olsa bile soruşturma tetiklenmelidir.

Öncelik, ön kapıdaki kimlik doğrulamadan ziyade yetkilendirme sonrası davranışı izlemektir.

Dördüncü kontrol iptal hazırlığıdır. Birçok kuruluş şüpheli OAuth izinlerini tanımlayabilir ancak bunları hızlıca kaldırmak için etkin bir sürece sahip değildir.

Olay müdahale planları uygulamanın nasıl tanımlanacağı, kimin onay verdiği, verilen kapsamların gözden geçirilmesi, uygulama izinlerinin iptal edilmesi, destekleniyorsa yenileme jetonlarının geçersiz kılınması, açığa çıkan gizli bilgilerin döndürülmesi ve bağlı SaaS sistemleri genelinde aşağı akış etkinliğinin kontrol edilmesi konularını kapsamalıdır.

Bu süreç bir olay meydana gelmeden önce test edilmelidir. Aktif bir ihlal sırasında jeton iptali ve uygulama izni temizliğiyle uğraşmayı beklemek bir hatadır.

Kullanıcı eğitimi daha spesifik hale gelmelidir. Kullanıcılara "URL'yi kontrol edin" tavsiyesi, URL meşru olabileceğinde yetersiz kalır.

Kullanıcılar onay ekranının kendisinin bir güvenlik kararı olduğunu tanımalıdır. Temel soru yalnızca "Bu Microsoft, Google, GitHub veya Salesforce mu?" değildir; daha iyi soru "Bu uygulama bu izne neden ihtiyaç duyuyor, kim yayınladı ve kuruluşum bunu onayladı mı?" dır.

Bu ders geleneksel kimlik avı farkındalığından daha zordur, ancak artık gereklidir.

Kimlik Doğrulama Bitiş Noktası Değildir

Ana çıkarım açıktır: Kimlik güvenliği kimlik doğrulamanın ötesine uzanır.

SaaS ağırlıklı ortamlarda yetkilendirme kararları çalınan kimlik bilgileri kadar kalıcılık sağlayabilir. MFA esastır, ancak OAuth yönetişiminin, en az ayrıcalık kapsamlarının, onay izlemesinin ve hızlı iptalin yerini alamaz.

Bir sonraki ihlal başarısız bir girişle değil, başarılı bir girişle ve "İzin Ver"e verilen tek bir dikkatsiz tıklamayla başlayabilir.