Shadow API (Gölge API) Nedir? Nasıl Keşfedilir?

Shadow API (gölge API), kurumun envanterinde ve dokümantasyonunda kaydı olmayan, buna rağmen ağ üzerinden istek karşılamaya devam eden uç noktalardır. Bir entegrasyon için açılmış ve işi bitince kapatılmamış bir arayüz, emekliye ayrılmayan eski bir sürüm, canlıya çıkarken silinmesi unutulan bir test adresi. Hepsinin ortak yanı kötü yazılmış olmaları değil, kurumun onların orada olduğunu hiç bilmemesidir.

Bir şirket santralini düşünün. İntranette bir dahili rehberi durur: muhasebe 1002, satış 1015, destek 1030. O rehber kurumun beyanıdır, “bizde şu hatlar var” der. Ama santral rehberi okumaz; kendisine tanımlanmış her dahiliyi çalıştırır. Yıllar önce bir proje için açılıp kapatılmayan bir test dahilisi hâlâ tanımlıdır ve hâlâ bir telefona bağlıdır. Rehberde yoktur. Numarayı çeviren yine de içeri girer.

Bu yazı boyunca o santralde kalacağız. Konu BT Danışmanlık hizmetimizin risk tespiti koluna girer ve gölge BT (Shadow IT) ailesinin bir üyesidir: kardeşleri gölge veri, gölge yönetici ve gölge yapay zekâ gibi, buradaki tehlike de bir şeyin var olması değil, kurumun onu görmüyor olmasıdır.

Shadow API (Gölge API) Nedir?

Shadow API, kurumun API envanterinde kaydı bulunmayan ama ağ üzerinden fiilen cevap veren her uç noktadır. Tanımın ağırlığı “kayıt” kelimesindedir: uç noktanın kötü yazılmış, güvensiz ya da eski olması şart değildir. Kayıtsız olması yeter, çünkü kayıtta olmayan şey yönetilmez.

İki terimi baştan ayırmak gerekir, yazının geri kalanı bu ayrımın üstünde duruyor. API (Application Programming Interface) bir yazılımın başka bir yazılıma açtığı arayüzdür: insan için tasarlanmış ekranın yerine, program için tasarlanmış giriş. Uç nokta (endpoint) ise o arayüzün tek tek adresleridir. https://portal.ad.sistemkusu.com/api/v2/izin bir uç noktadır ve aynı sunucuda onlarcası bulunabilir. Bu yüzden “kurumun API’si var mı?” genelde yanlış sorudur; doğrusu kaç uç noktası olduğu ve kaçını bildiğidir.

Santral ile sunucu arasındaki eşleme, yazının geri kalanında sürekli işimize yarayacak:

Uç Nokta ile Açık Port Aynı Şey Değildir

Bir portun açık olması gölge API demek değildir; gölge API, açık bir portun üstünde çalışan ve adresi bilinmeyen bir yoldur. Güvenlik duvarınız 443 portunu açar, çünkü kurumun meşru bir web sitesi vardır. O tek kapıdan geçen her istek sunucuya ulaşır ve isteğin hangi yola gideceğine sunucu karar verir. Portun kendisi nasıl çalışır sorusunu port nedir yazımızda ele alıyoruz; burada gereken tek cümle şu: açık port sayısı bir kurumun saldırı yüzeyini ölçmez.

Santralde bunun karşılığı nettir. Dış hat tektir, kurumun şehir numarasıdır. Dahililer o tek hattın arkasında durur. Dışarıdan bakan biri “bir numaraları var” der, içeride kaç dahilinin çaldığını bilmez.

Gölge API Nasıl Doğar? “Geçici” Diye Açılan Uç Nokta

Gölge API neredeyse hiçbir zaman ihmalden değil, geçici olduğu düşünülen bir işten doğar. Bir entegrasyon için uç nokta açılır, proje bitince kapatılacaktır. Yeni sürüm yayına alınır, eskisi birkaç hafta daha ayakta kalacaktır. Bir test adresi canlı sunucuya konur, doğrulama biter bitmez silinecektir. Sonra iş biter, kararı veren kişi başka bir işe geçer ve geçici olan kalıcı olur.

Bu doğum anı gölge veriyle ortaktır ve iki konuyu birbirine bağlayan şey budur. Ama doğan nesne aynı değildir: gölge veri envanter dışı bir kopyadır, gölge API envanter dışı bir erişim noktasıdır. Birincisi bir yerde durur ve bulunmayı bekler, ikincisi kendisine gelen isteği cevaplar. Aradaki fark, depoda unutulmuş bir kutu ile hâlâ çalan bir telefon arasındaki farktır.

Gölge Uç Noktalar En Sık Nereden Doğar?

• Emekliye ayrılmayan sürüm. v2 yayına alınır, dokümantasyon v2’yi anlatmaya başlar, v1 kimse kapatmadığı için çalışmaya devam eder. Sektörde bunun ayrı bir adı bile vardır: zombie API.
• Canlıda kalan test adresi. Bir doğrulama için açılan /test yolu, işi bitince silinmek üzere bırakılır. Silinmez.
• Satın alınan yazılımın varsayılan arayüzü. Kurum tek satır kod yazmamış olabilir; kurulan ERP, muhasebe programı, kamera kayıt yazılımı, NAS ya da ağ cihazı kendi arayüzünü açar.
• Üçüncü taraf entegrasyonu. Bir tedarikçiye veya bayiye veri vermek için açılan uç nokta, sözleşme bittikten sonra da ayakta kalır.
• Dokümandan düşen ama koddan düşmeyen yol. Bir özellik kaldırılır, dokümantasyondan silinir, koddaki yönlendirme silinmez.

Bu maddelerin yalnızca biri yazılım geliştirmeyle ilgilidir. Kalanı, kod yazmayan bir kurumun da başına gelir. Cümleyi olduğu gibi alın: API’nizin olması için API yazmanız gerekmez.

Neden Tehlikeli? Güvenlik Duvarı Yola Değil Porta Bakar

Gölge API’yi tehlikeli yapan şey uç noktanın kendisi değil, üzerinde hiçbir denetimin çalışmıyor olmasıdır. Yönetilen bir uç nokta cevap verirken arkasında bir dizi kontrol taşır: isteğin kimden geldiğini soran kimlik doğrulama, aynı adresten saniyede kaç istek gelebileceğini sınırlayan hız sınırı (rate limit), “kim ne istedi?” sorusunu sonradan cevaplayabilmek için tutulan kayıt ve bilinen açıklar için uygulanan yamalar. Bu kontrollerin hiçbiri sunucuya bağlı değildir, uç noktaya bağlıdır. Yönetimden düşen uç nokta hepsini birden kaybeder.

Peki bu uç nokta güvenlik duvarını nasıl geçiyor? Geçmiyor, çünkü onun için ayrıca açılmış bir kapı yok. Meşru web siteniz 443 üzerinden yayında olduğu için o port zaten açıktır ve güvenlik duvarı isteğin hangi yola gittiğine değil, hangi porta gittiğine bakar. Yolu okuyan taraf sunucudur. Yani gölge API duvarı aşmaz; duvarın meşru trafik için zaten açtığı kapıdan, aynı sırada içeri girer. Güvenlik duvarı kurulumunuz kusursuz olsa bile bu böyledir, çünkü ortada bir kural ihlali yoktur.

Kırılma noktasını görmek için uç noktanın kime göre tasarlandığına bakmak yeter. Bir ekran insanın hızıyla veri verir: sayfayı açarsınız, bakarsınız, ilerlersiniz. Uç nokta ağın hızıyla verir, çünkü zaten program tarafından okunmak üzere yapılmıştır. Kimlik doğrulaması olmayan ve sayfa sayfa kayıt döndüren bir uç noktanın arkasında on bin kişilik bir personel tablosu varsa, o tablo dakikalar içinde bütünüyle dışarı çıkar. Aynı veriyi bir ekrandan tek tek kopyalamak günler sürerdi. Fark uç noktanın kötü niyetli olmasında değil, makine için tasarlanmış olmasındadır.

Santral benzetmesinin nerede koptuğunu da tam burada söylemek gerekir, çünkü kopma noktası mekanizmanın kendisini gösteriyor. Bir dahiliyi çeviren kişi karşısında bir insan bulur ve o insan “kimsiniz, kimi aramıştınız?” diye sorabilir. Üstelik biri arka arkaya beş yüz dahili çevirirse bu birinin dikkatini çeker.

Uç noktada iki güvenlik de yoktur: karşıda soru soran kimse yoktur, cevabı kod verir; ve beş yüz adres denemek saniyeler sürer, hiç ses çıkarmaz. Telefon sistemini asıl koruyan şey teknolojisi değil, hattın ucundaki insandı. Kimlik doğrulama, hız sınırı ve kayıt, o eksik insanın yerine konan üç şeydir. Uç nokta envanterden düşünce üçü birden düşer.

Bir sınırı da baştan koymak gerekir, çünkü bu konu kolayca alarma dönüşür: her belgelenmemiş yol tehlikeli değildir. Bir logo dosyasının adresi de dokümantasyonda yazmaz; neyin kayda girip neyin girmeyeceği ayrı bir karardır ve ölçütlerini BT dokümantasyonu rehberimizde yazdık. Ayrımı yapan soru şudur: bu adres veri veriyor mu, bir işlem tetikliyor mu? Cevap hayırsa elinizde bir dosya vardır, gölge API değil.

Sahada: Dokümantasyon Ne Diyor, Sunucu Ne Cevaplıyor?

Buraya kadar anlatılan mekanizma bir iddiada bulunuyor: envanter eksiktir ve eksik olduğunu envantere bakarak anlayamazsınız. Bu ölçülebilir bir iddia. Sahada bu konudaki yerleşik cevap şudur: adresini kimsenin bilmediği bir uç nokta pratikte gizlidir, çünkü onu bulmak için adresi bilmek gerekir. Ölçtüm ve sunucu bu cevabı doğrulamadı.

Kurulum

Lab makinesi web01 üzerinde IIS ile yayında olan portal.ad.sistemkusu.com sitesine dört uç nokta kuruldu. İkisi kurumun envanterinde kayıtlı ve Basic kimlik doğrulamasının arkasında; ikisi ise envantere hiç girmemiş durumda: biri emekliye ayrılmayan bir v1 sürümü, diğeri canlıda unutulmuş bir test adresi. Ekibin elindeki envanter dosyası şunu diyor:

{
  "sistem": "Izin ve Bordro Portali",
  "sorumlu": "BT",
  "son_guncelleme": "2026-03-14",
  "uc_noktalar": [
    { "yol": "/api/v2/izin",   "kimlik_dogrulama": "Basic", "sahip": "BT" },
    { "yol": "/api/v2/bordro", "kimlik_dogrulama": "Basic", "sahip": "BT" }
  ]
}

Envanter iki uç nokta sayıyor ve en son mart ayında güncellenmiş. Şimdi aynı soruyu sunucuya soralım.

Beklenti, Ölçüm, Sonuç

Tarama iş istasyonundan yapıldı: aday yol listesi dış duvara gönderildi ve kaydedilen tek şey dönen durum kodu oldu. Çıktıyı okurken üç yere bakın:

• envanterde olmayıp 200 dönen yollar,
• envanterde olup 401 dönen yollar,
• ve hiç var olmayan yolların ne döndürdüğü.

Tablodaki KOD sütunu sunucunun ilk cevabı, SON sütunu ise yönlendirme izlendiğinde ulaşılan cevaptır. IIS klasör adreslerini sonuna eğik çizgi ekleyerek yönlendirdiği için ilk cevap sık sık 301 olur.

YOL                              KOD    SON
/                                200    200
/api                             301    403
/api/v1                          301    403
/api/v1/personel                 301    200
/api/v1/izin                     404    404
/api/v2                          401    401
/api/v2/izin                     401    401
/api/v2/bordro                   401    401
/api/v3/izin                     404    404
/swagger                         404    404
/openapi.json                    404    404
/test                            301    403
/test/servis-durum               301    200
/admin                           404    404
/health                          404    404

Bu tabloda dört şey yazıyor.

1. Envanter iki uç nokta sayıyordu, sunucu dört adrese cevap verdi. /api/v1/personel ve /test/servis-durum listenin hiçbir yerinde geçmiyor, ama ikisi de 200 dönüyor. Aradaki fark, kurumun bilmediği saldırı yüzeyidir.
2. Kayıtlı uç noktalar doğru davrandı. /api/v2/izin ve /api/v2/bordro kimlik istemeden veri vermedi. 401 cevabıyla birlikte WWW-Authenticate: Basic realm="portal.ad.sistemkusu.com" başlığını döndürdüler, yani nasıl kimlik doğrulanacağını da söylediler. Sorun API’nin kendisinde değil, envanterin dışında kalanlarda.
3. Tarama körü körüne suçlamıyor. /api/v1/izin, /api/v3/izin, /admin, /health, /swagger ve /openapi.json yollarının hepsi 404 döndü. Sunucu var olmayan için “yok” diyor; dolayısıyla 200 dönen bir yol gerçekten oradadır. Bu, yöntemi kullanılabilir yapan şeydir: liste tahmin değil, ölçüm.
4. Asıl bulgu beklenmedik yerden geldi: reddedilen istek de bilgi veriyor. /api ve /api/v1 adreslerinin ikisi de 403 döndü. 403, 404’ten bambaşka bir şey söyler: burada bir şey var, ama sana göstermiyorum. Yani sunucu içeriği vermediği yerde bile yapının kendisini veriyor. Tarayan taraf /api/v1 için 403 gördüğü anda v1 diye bir sürümün var olduğunu öğrenir ve altını denemeye başlar.

Dördüncü madde, bölümün başındaki yerleşik cevabı doğrudan çürütüyor. Santralde bunun karşılığı gündelik bir sahne: operatöre olmayan bir dahili sorduğunuzda “böyle bir numara yok” der, ama var olan ama vermek istemediği bir dahili sorduğunuzda “o hatta bağlayamam” der. İkinci cevap birinciden çok daha fazlasını söyler, çünkü hattın var olduğunu onaylar. Sunucu da tam olarak bunu yapıyor.

Envanter dışındaki iki uç noktanın ne döndürdüğüne bakmak riskin ölçüsünü de veriyor. Birincisi kimlik doğrulaması olmadan doğrudan kişisel veri veriyor:

{
  "surum": "v1",
  "kayitlar": [
    { "ad": "Ayse Yilmaz",  "tc": "10000000146", "telefon": "0532 000 00 01", "departman": "Muhasebe", "maas": 48000 },
    { "ad": "Mehmet Demir", "tc": "10000000238", "telefon": "0532 000 00 02", "departman": "Satis",    "maas": 51000 },
    { "ad": "Zeynep Kaya",  "tc": "10000000320", "telefon": "0532 000 00 03", "departman": "IK",       "maas": 46000 }
  ]
}

İkincisi hiç kişisel veri döndürmüyor, ama başka bir şey veriyor:

{
  "ortam": "test",
  "surum": "1.4.2-test",
  "veritabani": "sql01.ad.sistemkusu.com",
  "baglanti": "Server=sql01;Database=PortalDb;User Id=portal_svc",
  "son_yedek": "2026-08-29T03:00:00"
}

İkisi arasındaki fark, gölge API’nin tek bir risk türü olmadığını gösteriyor. Unutulmuş v1 sürümü veriyi veriyor; unutulmuş test adresi ise veritabanı sunucusunun adını, veritabanının adını ve servis hesabını, yani haritayı veriyor. İkincisi tek başına hiçbir kaydı sızdırmaz, ama bir sonraki adımı planlayan biri için birincisinden daha değerlidir.

Gölge API Nasıl Keşfedilir? Dokümanı Değil, Duvarı Taramak

Gölge API’yi bulmanın yolu, soruyu kime sorduğunuzu değiştirmekten geçer. Ölçüm bunu tek bir cümleye indiriyor: dokümantasyon kurumun beyanıdır, sunucu ise olgudur. Uygulamada üç ayrı kaynağa sorabilirsiniz ve üçü aynı şeyi bilmez.

1. Dokümantasyon, ekibin bildiği ve yazmayı hatırladığı uç noktaları verir. Eksiksiz olduğu varsayılır, hiçbir zaman değildir.
2. Gateway ve sunucu kayıtları, gerçekten çağrılmış uç noktaları verir. Bu daha güçlü bir kaynaktır ama körlüğü nettir: hiç çağrılmamış, sadece açık duran bir uç nokta kayıtta da görünmez.
3. Tarama, fiilen cevap veren uç noktaları verir. Tam listeyi yalnızca bu üçüncüsü çıkarır, çünkü tek olguya soran odur.

Taramanın kendisi karmaşık bir iş değildir ve şu sırayla yürür:

1. Dış duvardan görünen adresleri listeleyin: DNS kayıtları, sertifikaların SAN alanındaki adlar, güvenlik duvarındaki NAT kuralları.
2. Her adres için bilinen yolları çıkarın. Bu, karşılaştıracağınız envanterdir.
3. Aday yol listesiyle istek gönderin ve dönen durum kodunu kaydedin.
4. Envanterinizde olmayıp cevap veren her yolu tek tek doğrulayın: ne döndürüyor, kimlik doğrulaması var mı?
5. Bulunan her uç nokta için tek soru sorun: sahibi kim ve hâlâ gerekli mi?

Üçüncü adımı bir örnekle somutlaştıralım. Yukarıdaki ölçümde çalıştırılan tarama, özünde şu kadar basit bir döngüydü:

for yol in / /api /api/v1 /api/v2 /test /admin /health /swagger; do
  printf '%-24s %s\n' "$yol" \
    "$(curl -s -o /dev/null -w '%{http_code}' "https://portal.ad.sistemkusu.com$yol")"
done

Aday yol listesi uzadıkça tarama da uzar, mantığı değişmez. İşi yapan şey araç değil, listenizle sunucunun cevabını yan yana koymanız.

Dönen durum kodu taramanın bütün bilgisini taşır ve okunuşu şöyledir. 404 o adreste bir şey olmadığını söyler. 200 bir şey olduğunu ve korunmadığını söyler. 401 ile 403 ise iki şeyi birden söyler ve bu ayrımı kaçırmayın.

Birincisi korumanın çalıştığıdır, ki iyi haberdir. İkincisi orada bir şeyin olduğudur, ki az önce ölçümde gördüğümüz sızıntının kendisidir. Reddedilen bir istek erişimi engeller, keşfi engellemez. Kodların ne anlama geldiğini HTTP ve HTTPS yazımızda ayrıntısıyla ele alıyoruz; buradaki kullanım şekli şu: taramanın bulduğu şey içerik değil, farktır.

Bu mantık gölge yöneticiyi bulurken kullandığımızın aynısıdır. Orada da grup listesi kurumun beyanıydı, etkin izin taraması olguydu ve risk tam olarak ikisinin ayrıldığı yerde duruyordu. Nesne değişiyor, yöntem aynı kalıyor: beyanı değil sistemi sorgulayın.

Nasıl Önlenir? Her Uç Noktaya Bir Sahip ve Bir Emeklilik Tarihi

Önlemin tamamı tek cümleye sığar: bir uç nokta açılırken ne zaman kapatılacağı da aynı anda yazılır. Bu, gölge veride her kopyaya son kullanma tarihi yazma kuralının aynısıdır, çünkü ikisi de aynı kökten doğuyor. Pratikte dört ayağı var.

• Envanter bir tablodur, bir bilgi değil. Uç nokta listesi yol, sürüm, sahip, kimlik doğrulama yöntemi ve emeklilik tarihi alanlarıyla tutulur. Varlık envanteri yükümlülüğünün kurumsal çerçevesini ISO 27001 yazımızda ele alıyoruz.
• Sürüm emekliliği yeni sürümle birlikte kararlaştırılır. v2 yayına alınırken v1’in kapanma tarihi de o kararın parçasıdır. Sonraya bırakılan kapatma kararı hiç verilmez.
• Uç noktalar tek kapıdan geçer. API gateway, dışarıdan gelen isteği önce kendisi karşılayıp sonra arkadaki servise ileten ara katmandır: santraldeki operatör gibi, önce o cevap verir. Arkasına alınan uç noktalarda kimlik doğrulama, hız sınırı ve kayıt tek yerde toplanır; her uç noktanın tek tek doğru yapılandırılmış olmasına bel bağlamazsınız.
• Duvar periyodik taranır. Envanteri değil duvarı tararsınız ve çeyrekte bir yeterlidir. Yeni gölge API her zaman yeni bir projeden doğar, dolayısıyla proje temposuyla aynı ritmi tutturmak gerekir.

KVKK ve Loglama: Uç Nokta Kişisel Veri Taşıyorsa

Kişisel veri döndüren bir uç noktanın envanterde olmaması iki ayrı yükümlülüğü birden ihlal eder ve ikisi de teknik değil hukuki sonuç doğurur.

Birincisi güvenlik yükümlülüğüdür. KVKK m.12, veri sorumlusundan kişisel verilere hukuka aykırı erişimi önlemek ve verinin muhafazasını sağlamak için uygun güvenlik düzeyini temin etmesini ister. Kimlik doğrulaması olmayan bir uç nokta bu yükümlülüğü doğrudan karşılamaz. Kurumun yayımladığı Veri Güvenliği Rehberi de aynı yere bakar: erişim yetkileri ve sistemlerin envanteri, teknik tedbirlerin ilk basamağında sayılır.

İkincisi tespit yükümlülüğüdür ve asıl açık buradadır. Aynı maddenin beşinci fıkrası, bir ihlal öğrenildiğinde Kurula bildirim yapılmasını zorunlu kılar. Ama kaydı tutulmayan bir uç noktada ihlal öğrenilemez: kimin ne zaman ne çektiğini gösteren bir kayıt yoksa, veri dışarı çıkmış olsa bile kurumun elinde bunu gösteren hiçbir iz kalmaz.

Bildirim yükümlülüğü ortadan kalkmaz, yalnızca yerine getirilemez hâle gelir. Bu yüzden gölge API bir güvenlik açığı olduğu kadar bir görünürlük açığıdır ve teknik uyum tarafındaki karşılığını KVKK teknik uyum yazımızda ele alıyoruz.

Buradaki kayıt ihtiyacını 5651 yükümlülüğüyle karıştırmamak gerekir. 5651 log yönetimi internet erişim kayıtlarına ilişkin ayrı bir çerçevedir; uç nokta kaydı ondan bağımsız olarak, doğrudan KVKK m.12’deki tedbir yükümlülüğünden doğar. İki kaydı aynı sisteme yazabilirsiniz, ama ikisini aynı gerekçeye bağlayamazsınız.

Sonuç: Shadow API’yi Liste Değil Sunucu Taraması Bulur

Shadow API yeni bir tehdit değil, eski bir alışkanlığın adıdır: bir kapı açıp kapatmayı sonraya bırakmak. Kurumlar korumayı bildikleri uç noktalara yığar, çünkü envanterde onlar vardır. Oysa sunucu envanteri okumaz; kendisine tanımlanmış her yolu çalıştırır, tıpkı rehberi okumayan santral gibi.

Bu yüzden doğru soru “API’lerimiz güvenli mi?” değil, “dış duvarımızda kaç uç nokta cevap veriyor ve kaçı listemizde?” sorusudur. İlkini bir güvenlik denetimi cevaplar. İkincisini yalnızca sunucuya sorulan bir tarama cevaplar, çünkü aradaki farkı bilen tek taraf sunucunun kendisidir.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn