SaaS Shadow Access ve Eski Çalışanlardan Kalan Erişimler

Yayın: 26 Ekim 2026 · Son güncelleme: 26 Ekim 2026

SaaS shadow access, kurumun kimlik yönetimi (IdP) sisteminin görmediği SaaS hesapları, OAuth izinleri, API anahtarları ve otomasyon bağlantılarıdır. Çalışan ayrılıp SSO hesabı kapatıldığında bu erişimlerin bir kısmı açık kalabilir. 26 Ekim 2026 itibarıyla OWASP Non-Human Identities Top 10 listesinin ilk sırasında “Improper Offboarding” yer alıyor; yani sorun yalnızca insan hesaplarında değil, onların bıraktığı token ve entegrasyonlarda.

İlgili Rehberler

PAM: Ayrıcalıklı Erişim Yönetimi
Yüksek yetkili hesapların kontrolü ve izlenmesi.

Sızma Testi Türleri
Hangi test yaklaşımı hangi riske uygun.

Veri İhlali Müdahale Planı
İhlalin ilk 60 dakikasında yapılacaklar.

Shadow Access Nedir ve Neden Görünmez Kalır?

Shadow access, BT ve güvenlik ekibinin bilgisi dışında oluşan SaaS erişim yollarının tamamıdır. Gölge BT’den (shadow IT) farkı, yalnızca izinsiz uygulamaları değil, izinli uygulamaların içinde fark edilmeyen yetkileri de kapsamasıdır. Bu erişimler SSO ve SCIM gibi merkezi kontrollerin dışında kaldığı için kullanıcı kapatıldığında birlikte kapanmaz.

Örneğin bir çalışan kurumsal e-postasıyla Canva, Notion veya Calendly gibi bir servise SSO kullanmadan kayıt olur; bu hesap IdP’de hiç görünmez. Başka biri bir üçüncü taraf uygulamaya Google Workspace veya Microsoft 365 verileri üzerinde okuma-yazma izni verir. Bir geliştirici de test için kendi adına bir API anahtarı açar ve unutur. Bu erişimleri bir insan oluşturmuştur, ama o insan ayrıldığında kendiliğinden kapanmazlar.

Eski Çalışan Hesapları Neden Açık Kalır?

SSO hesabını kapatmak, çalışanın IdP üzerinden yeni oturum açmasını engeller; ancak daha önce verilmiş tokenları ve uygulamaların kendi oturumlarını her zaman sonlandırmaz. Microsoft’un Entra ID belgelerine göre devre dışı bırakılan bir kullanıcının elindeki erişim tokenı varsayılan olarak bir saate kadar geçerli kalır ve uygulamanın kendi ürettiği oturumu Entra ID doğrudan iptal edemez.

Microsoft ortamında hesabı kapattıktan sonra mevcut oturumları da sonlandırmak için kullanılan komut şudur:

# Microsoft Graph PowerShell: kullanıcının tüm oturum ve refresh tokenlarını iptal eder
Connect-MgGraph -Scopes "User.RevokeSessions.All"
# UserId: ayrılan kullanıcının Entra ID nesne kimliği (Object ID)
Revoke-MgUserSignInSession -UserId "00000000-0000-0000-0000-000000000000"

Bu adım yalnızca Entra ID’ye bağlı uygulamalar için geçerlidir. SSO dışındaki hesaplar ve uygulamaların kendi tokenları için ayrı bir envanter gerekir.

Yetim Entegrasyonlar ve OAuth Token Riskleri Nelerdir?

Yetim entegrasyon, bir çalışanın kurduğu ve o çalışan ayrıldıktan sonra sahipsiz kalan OAuth izni, API bağlantısı veya otomasyondur. Kurulurken genellikle “işe yarasın” diye geniş yetki verilir ve sonra kimse dönüp bakmaz. Token entegrasyona ait olduğu için kişinin hesabı kapansa bile çalışmaya devam edebilir; ele geçirilirse birden fazla sisteme açılan bir anahtar olur.

Tipik örnekler şunlardır: proje bittiği halde açık kalan geniş yetkili bir Jira–GitHub bağlantısı, bir CRM’e tüm posta kutusunu okuma izni veren e-posta entegrasyonu, kurucusu ayrıldığı halde her gece Google Drive’dan dosya kopyalayan bir Zapier akışı veya bir yapay zekâ asistanına verilmiş Drive erişimi.

Bu riskin en net örneği Salesloft Drift olayıdır. Google Threat Intelligence Group’un raporuna göre UNC6395 olarak izlenen grup, 8–18 Ağustos 2025 arasında Drift entegrasyonuna ait OAuth tokenlarıyla çok sayıda kurumun Salesforce ortamından Account, Case, User ve Opportunity kayıtlarını dışarı aktardı. Ardından bu verilerin içinde AWS erişim anahtarı (AKIA ile başlayan), parola ve Snowflake tokenı aradı. Saldırganın girdiği kapı bir çalışan hesabı değil, kurumların zamanında onay verdiği bir entegrasyondu.

OAuth tokenlarını tehlikeli yapan, refresh token sayesinde erişimin uzun süre yenilenebilmesi ve tek bir iznin e-posta, takvim ve dosya gibi birden fazla kapsamı (scope) birlikte içerebilmesidir. PAM ile ayrıcalıklı erişim yönetimi programları çoğunlukla insan yöneticileri kapsar; OAuth tokenları ve servis hesapları bu kapsama alınmazsa görünmeyen bir ayrıcalık katmanı oluşur.

Shadow SaaS Keşfi Nasıl Yapılır?

Shadow SaaS keşfi, kurumun envanterinde olmayan SaaS uygulamalarını ve erişim yollarını bulma işidir. Tek bir kaynak yetmez; IdP logları ücretsiz uygulamaları, harcama kayıtları da OAuth izinlerini göstermez. Bu yüzden IdP, ağ, harcama ve uç nokta verileri birlikte incelenir ve her kaynak diğerinin kör noktasını kapatır.

Offboarding Sürecinde Hangi Adımlar Atlanıyor?

Standart offboarding birçok kurumda IdP hesabını kapatma, e-postayı devretme ve kartı iptal etmekle biter. SaaS tarafındaki erişimlerin çoğu bu listede yer almaz, çünkü kimse onların varlığını bilmez. Sorun ihmalden çok görünürlük eksikliğidir; aşağıdaki altı adım bu yüzden offboarding formuna ayrı satırlar olarak eklenmelidir.

1. Kullanıcının verdiği üçüncü taraf OAuth izinlerini Google Workspace veya Microsoft 365 yönetici panelinden listeleyip iptal edin.
2. SSO dışında parolayla açılmış SaaS hesaplarını bulup kapatın veya bir ekip hesabına devredin.
3. Çalışanın oluşturduğu API anahtarlarını, kişisel erişim tokenlarını ve servis hesaplarını iptal edin ya da sahipliğini aktarın.
4. Trello panoları, Slack kanalları, Confluence alanları ve paylaşılan sürücülerin sahipliğini aktarın.
5. Zapier, Make ve Power Automate’teki akışları inceleyip sahipsiz kalanları durdurun.
6. Kurumsal cihazlarda MDM ile, kişisel cihazlarda uygulama bazlı oturum iptaliyle mobil erişimi kapatın.

8 Adımlı SaaS Erişim Güvenliği Kontrol Listesi

Aşağıdaki sekiz adım, shadow access’i keşiften olay müdahalesine kadar ele alır. Envanter olmadan diğer adımların hiçbiri tam çalışmayacağı için ilk adım her zaman keşiftir. Sonraki adımların sırası kurumun büyüklüğüne ve kullandığı IdP’ye göre değişebilir; küçük bir ekipte SSO kapsamını genişletmek, büyük bir kurumda OAuth onay politikası daha hızlı sonuç verebilir.

1. Envanter çıkarın: Yukarıdaki keşif yöntemleriyle SaaS uygulamalarını, OAuth izinlerini ve API anahtarlarını tek listede toplayın.
2. SSO ve SCIM kapsamını genişletin: Kritik uygulamaları SSO’ya ve SCIM ile otomatik hesap kapatmaya bağlayın.
3. OAuth onay politikası yazın: Kullanıcıların hangi kapsamlara kendi başına izin verebileceğini, hangilerinin yönetici onayı gerektirdiğini belirleyin.
4. Offboarding formunu güncelleyin: Bir önceki bölümdeki altı adımı forma ayrı satırlar olarak ekleyin.
5. İnsan dışı kimlikleri kayıt altına alın: Her API anahtarı ve servis hesabı için sahip, amaç ve yetki kaydı tutun; anahtarları düzenli yenileyin.
6. Erişimleri periyodik gözden geçirin: Kritik uygulamalar (e-posta, CRM, kod deposu, bulut depolama) için üç ayda bir, diğerleri için altı ayda bir inceleme öneriyoruz.
7. Çalışanlara talep yolunu anlatın: Yeni bir SaaS’a ihtiyaç duyan çalışanın nereye başvuracağı belli değilse, kendi başına kayıt olur.
8. Olay müdahale planına ekleyin: SaaS ve OAuth kaynaklı sızıntı senaryolarını veri ihlali müdahale planı içine dahil edin.

KVKK Açısından Shadow Access Neden Önemlidir?

Kurumun bilmediği bir SaaS uygulamasında kişisel veri işleniyorsa, veri sorumlusu o veriyi koruduğunu gösteremez. 6698 sayılı Kişisel Verilerin Korunması Kanunu Md. 12, kişisel verilere hukuka aykırı erişimin önlenmesi için gerekli teknik ve idari tedbirleri veri sorumlusuna yükler. Ayrılmış bir çalışanın hâlâ müşteri verisine erişebilmesi, bu yükümlülüğün yerine getirilmediğini gösteren somut bir bulgudur.

• Shadow SaaS uygulamaları veri işleme envanterinde ve VERBİS kaydında yer almaz.
• Yurt dışında barındırılan bir SaaS’a veri aktarımı, 1 Haziran 2024’te yürürlüğe giren değişiklikle Md. 9’daki yeterlilik kararı, uygun güvenceler (ör. standart sözleşme) veya istisnai hallerden birine dayanmak zorundadır. Kurumun haberi olmayan bir aktarım için bu dayanak kurulamaz.
• Kişisel Verileri Koruma Kurulu’nun 2019/10 sayılı kararı, ihlalin öğrenilmesinden itibaren en geç 72 saat içinde Kurul’a bildirim yapılmasını ister. Görülmeyen bir SaaS’taki sızıntı ise çoğu zaman bu süre geçtikten sonra fark edilir.

Teknik tedbirlerin bulut ortamına nasıl uygulandığını bulut tabanlı sistemlerde KVKK uyumu yazımızda, Kurum’un önerdiği tedbirleri ise KVKK teknik önlemleri yazımızda ele aldık.

Sızma Testinde SaaS Shadow Access Nasıl Değerlendirilir?

Sızma testinde shadow access değerlendirmesi, offboarding sürecinin ve OAuth izin yönetiminin saldırgan gözüyle sınanmasıdır. Genellikle gri kutu yaklaşımıyla yapılır: test ekibine ayrılan çalışan listesi ve yönetici konsollarında okuma yetkisi verilir. Amaç, kapatıldığı sanılan ama hâlâ çalışan hesap ve tokenları kanıtıyla ortaya koymaktır.

1. Google Workspace veya Microsoft 365’te tüm üçüncü taraf OAuth izinleri ve kapsamları listelenir.
2. İK’nın ayrılan çalışan listesi IdP ve SaaS kullanıcı listeleriyle karşılaştırılır.
3. GitHub, AWS ve Slack gibi platformlarda sahibi ayrılmış kişiler olan anahtar ve tokenlar bulunur.
4. Bulunan yetim tokenların hâlâ geçerli olup olmadığı, müşteri onayıyla ve zarar vermeden doğrulanır.
5. Geçerli bir tokenın zincirleme olarak hangi sistemlere ulaşabildiği haritalanır.

Farklı test yaklaşımlarının bu tür değerlendirmelere nasıl uyduğunu sızma testi türleri rehberimizde bulabilirsiniz.

Sıkça Sorulan Sorular

Bu bölümde SaaS erişimleri ve offboarding konusunda en çok sorulan üç soru yer alıyor: shadow SaaS’in gölge BT’den farkı, ayrılan çalışanın erişimlerinin ne kadar sürede kapatılması gerektiği ve OAuth izinlerinin toplu olarak iptal edilip edilemeyeceği. Süre önerisi Nesil Teknoloji’nin kendi uygulamasına dayanır; standartların ne dediği yanıtta ayrıca belirtilmiştir.

Yazar: Afra Görgen

Kaynaklar

• OWASP — NHI1:2025 Improper Offboarding (Non-Human Identities Top 10)
• Google Threat Intelligence Group — Widespread Data Theft Targets Salesforce Instances via Salesloft Drift (2025)
• Microsoft Learn — Revoke user access in Microsoft Entra ID
• 6698 sayılı Kişisel Verilerin Korunması Kanunu (Mevzuat Bilgi Sistemi)
• Kişisel Verileri Koruma Kurumu — Veri İhlali Bildirimi (Kurul’un 2019/10 sayılı kararı)
• ISO/IEC 27001:2022 — Information security management systems
• IETF RFC 6749 — The OAuth 2.0 Authorization Framework (2012)

Erişim tarihi (tüm kaynaklar): 26 Ekim 2026. Güncelleme tarihçesi: 26 Ekim 2026 — ilk yayın.