Self Hosted API Araçları: Bulutu Terk Etmeli misiniz?

Kendi kendine barındırılan API araçları artık yalnızca “uyumluluk için iyi olur” kategorisinde değil. GitHub’ın yaklaşık 3.800 dahili deposundan veri çalındığını doğruladığı olay, API ekipleri için daha pratik bir soruyu öne çıkardı: OpenAPI spesifikasyonlarınız, koleksiyonlarınız, test verileriniz ve ortam sırlarınız tam olarak nerede tutuluyor?

Apidog'u bugün deneyin

Birçok ekip için cevap şudur: “Bir satıcının bulutunda, ama hangi bölgede ve hangi alt işleyicilerle işlendiğini tam bilmiyoruz.” Bu her zaman yanlış değildir. Bulut senkronizasyonu hızlı kurulur, ekip içi paylaşımı kolaylaştırır ve dağıtık ekipler için güçlüdür. Ancak API verileriniz hassas kimlik bilgileri, müşteri verisi veya düzenlemeye tabi bilgiler içeriyorsa, bulut mu yoksa kendi güvenlik çevreniz mi sorusunu bilinçli şekilde yanıtlamanız gerekir.

TL;DR

Kendi kendine barındırılan API araçları; OpenAPI spesifikasyonlarınızı, istek koleksiyonlarınızı, test verilerinizi ve kimlik bilgilerinizi satıcı bulutu yerine kontrol ettiğiniz altyapıda tutmanızı sağlar.

GitHub olayında saldırganlar, zehirli bir VS Code uzantısı üzerinden bir çalışanın cihazına erişti ve yaklaşık 3.800 dahili depodan veri sızdırdı. Bu olay, API ekipleri için şu kontrol listesini gündeme getiriyor:

• API aracınız hangi verileri buluta senkronize ediyor?
• Ortam değişkenlerinde gerçek token veya API anahtarı var mı?
• Paylaşılan çalışma alanlarına kimler erişebiliyor?
• Test verileri müşteri veya kişisel veri içeriyor mu?
• Uyum gereksinimleriniz veri ikametini zorunlu kılıyor mu?
• İzole veya kısıtlı ağlarda çalışmanız gerekiyor mu?

Apidog hem bulut ürünü hem de kendi kendine barındırılan şirket içi dağıtım ve çevrimdışı mod sunar. Böylece API verilerinizin nerede yaşayacağına araç değil, siz karar verirsiniz.

GitHub’da ne oldu ve API ekipleri neden önemsemeli?

20 Mayıs 2026’da GitHub, saldırganların yaklaşık 3.800 dahili kod deposundan veri çaldığını doğruladı. Giriş noktası GitHub’ın çekirdek platformundaki bir sıfır gün açığı değildi. Bir GitHub çalışanının cihazına yüklenen zehirli bir VS Code uzantısıydı.

Uzantı çalışanın izinleriyle çalışınca saldırganlar GitHub ağı içinde bir dayanak noktası elde etti. TeamPCP olarak takip edilen tehdit grubu, npm, PyPI ve PHP paket ekosistemlerindeki tedarik zinciri saldırılarıyla biliniyor. Güvenlik raporları, grubun çalınan veri kümesini yeraltı forumlarında 50.000 dolardan fazla bir fiyata satışa çıkardığını belirtiyor.

GitHub, müşteri verilerinin etkilendiğine dair kanıt olmadığını ve soruşturmanın sürdüğünü açıkladı. Bu ayrım önemli: olay müşteri depolarını değil, GitHub’ın dahili depolarını etkiledi.

Ancak API ekipleri için çıkarılacak ders açık:

• Geliştirici cihazları saldırı yüzeyidir.
• IDE uzantıları tedarik zinciri riski taşır.
• Tek bir çalışan cihazı, daha geniş ağ erişimine dönüşebilir.
• API spesifikasyonları, test verileri ve sırlar genellikle aynı geliştirici araç zincirinde bulunur.

GitHub’ın zor bir ay geçirmesi bununla sınırlı değildi. Nisan 2026’da bulut güvenlik firması Wiz, GitHub’ın dahili Git altyapısında kritik bir uzaktan kod çalıştırma açığı olan CVE-2026-3854’ü açıkladı. Bu açık yamalanmadan önce milyonlarca depoyu ifşa etmişti. SecurityWeek, güvenlik açığını ve kapsamını belgeledi.

API tarafında GitHub genellikle yalnızca kod deposu değildir. Çoğu ekip için API gerçeğinin kaynağıdır:

• OpenAPI / Swagger dosyaları
• İstek koleksiyonları
• env.example dosyaları
• CI/CD iş akışları
• Terraform ve API ağ geçidi yapılandırmaları
• Mock server tanımları
• Entegrasyon testleri
• Dağıtım token’ları

Bu veriler bir bulut platformunda yaşıyorsa, o platformun ihlali sizin risk modelinizin parçasıdır.

Bu konunun geliştirici tarafını VS Code uzantısı API anahtarı güvenliği yazısında, depo tarafını ise Git deposunda API belgelerini nasıl güvende tutacağımız rehberinde ele aldık. Buradaki odak daha temel: API tasarımınız ve test verileriniz satıcı bulutunda mı, yoksa sizin altyapınızda mı yaşamalı?

API istemciniz buluta hangi verileri senkronize eder?

Bir API aracını ekip çalışma alanıyla kullandığınızda cihazınızdan ayrılabilecek veri türlerini netleştirmeniz gerekir.

Pratik bir envanter çıkarın:

[ ] OpenAPI / Swagger spesifikasyonları
[ ] İstek koleksiyonları
[ ] Kaydedilmiş yanıt örnekleri
[ ] Ortam değişkenleri
[ ] API anahtarları
[ ] Bearer token’lar
[ ] OAuth client secret değerleri
[ ] Veritabanı bağlantı dizeleri
[ ] Mock server verileri
[ ] Test payload’ları
[ ] Çalışma alanı üyeleri ve yorumlar
[ ] Klasör yapısı ve servis adları

1. API spesifikasyonları

OpenAPI belgeniz saldırgan için bir haritadır. Şunları gösterir:

• Hangi endpoint’ler var?
• Hangi parametreler kabul ediliyor?
• Hangi şemalar kullanılıyor?
• Kimlik doğrulama sınırları nerede?
• Hangi kaynaklar ID ile erişiliyor?

Spesifikasyon tek başına parola değildir. Ancak tam bir API planı, keşif aşamasını ciddi şekilde kısaltır.

2. İstek koleksiyonları ve örnek yanıtlar

Kaydedilmiş istekler genellikle gerçek payload içerir:

{
  "email": "[e-mail]",
  "accountId": "acc_123456",
  "internalHost": "staging-api.internal.local"
}

Kaydedilmiş yanıtlar daha da hassas olabilir. Bir geliştirici test sırasında tam kullanıcı nesnesini veya kayıt listesini yapıştırıp unutabilir.

3. Ortam değişkenleri ve sırlar

En kritik alan burasıdır. API istemcilerinde sıkça şunlar saklanır:

API_BASE_URL=https://api.example.com
ACCESS_TOKEN=eyJhbGciOi...
CLIENT_SECRET=prod-secret-value
DATABASE_URL=mysql://user:pass@host/db

Bu değerler buluta senkronize edilirse üretim veya staging kimlik bilgileriniz üçüncü taraf bir sistemde tutulur.

Ortam senkronizasyonunun neden karmaşık olduğunu Postman ortam senkronizasyon sorunları analizinde daha ayrıntılı inceledik.

4. Test verileri ve mock tanımları

Mock server ve test senaryoları genellikle iş kurallarınızı ortaya çıkarır:

pm.test("Premium kullanıcı günlük limit aşımından etkilenmez", function () {
  pm.expect(response.plan).to.eql("premium");
  pm.expect(response.rateLimit.remaining).to.be.above(0);
});

Bu tip testler sır değildir, ancak ürün davranışı ve yetkilendirme modeli hakkında bilgi verir.

5. Çalışma alanı meta verileri

Tek tek önemsiz görünen şu veriler toplu halde anlamlıdır:

• Servis adları
• Takım üyeleri
• Yorumlar
• Klasör yapısı
• Değişiklik geçmişi
• Ortam isimleri

Bunlar organizasyon şeması, ürün yol haritası ve iç sistem mimarisi hakkında ipucu verir.

Bulut senkronizasyonunun veri modelini daha ayrıntılı okumak isterseniz Postman güvenli mi analizine bakabilirsiniz.

Bulut senkronizasyonunun gerçek saldırı yüzeyi

Bulutla senkronize API araçları iş birliğini kolaylaştırır, ancak yeni saldırı yüzeyleri ekler.

Satıcı yüksek değerli bir hedeftir

Binlerce şirketin API spesifikasyonlarını, koleksiyonlarını ve kimlik bilgilerini tutan çok kullanıcılı SaaS platformları doğal olarak hedef olur.

Kullandığınız satıcının şunlarını da risk modelinize dahil edersiniz:

• Güvenlik duruşu
• Yama hızı
• Olay müdahale kalitesi
• Çalışan cihaz güvenliği
• Alt işleyicileri
• Telemetri ve log politikası

GitHub olayında zayıf halka bir çalışan cihazıydı; etki alanı ise binlerce dahili depoydu.

Hesap ele geçirme etkisi büyüktür

Bir ekip üyesinin hesabı ele geçirilirse saldırgan şunlara erişebilir:

• Paylaşılan çalışma alanları
• Senkronize ortamlar
• Koleksiyonlar
• Kaydedilmiş token’lar
• Test verileri

MFA şarttır, ancak tek başına yeterli değildir. Oturum ele geçirme, OAuth token hırsızlığı ve kötü amaçlı uzantılar MFA’yı aşabilir.

Çalışma alanı paylaşımı zamanla genişler

Sık görülen problemler:

• İki haftalık iş için eklenen yüklenici kaldırılmaz.
• “Engineering” çalışma alanına herkes otomatik eklenir.
• Eski production ortamları hâlâ paylaşılır.
• Yeni başlayanlar gerekmediği halde tüm projeleri görür.

Uygulanabilir kontrol:

Her ay:
1. Çalışma alanı üyelerini dışa aktarın.
2. Son erişim tarihlerini kontrol edin.
3. Yüklenici ve eski çalışanları kaldırın.
4. Production ortamlarını ayrı projeye taşıyın.
5. Sır içeren değişkenleri paylaşılmayan yerel değişkenlere ayırın.

Uzantı ve entegrasyon katmanı risklidir

GitHub olayındaki vektör tam olarak buydu: zehirli bir VS Code uzantısı.

API istemcileri, IDE’ler ve CI araçları genellikle şunlarla genişletilir:

• Eklentiler
• Uzantılar
• Webhook entegrasyonları
• OAuth uygulamaları
• CLI araçları

Her biri, geliştirici izinleriyle çalışan üçüncü taraf kodu olabilir.

Telemetri, loglar ve alt işleyiciler

Bulut araçlarında veriniz yalnızca ana uygulamada kalmayabilir. Şuralara akabilir:

• Sunucu logları
• Hata raporlama sistemleri
• Analitik sağlayıcıları
• Destek araçları
• Bulut altyapısı sağlayıcıları
• Alt işleyiciler

Örneğin bir hata raporu yanlış yapılandırılırsa istek gövdesi veya Authorization header’ı yakalanabilir.

Benzer platform risklerini Vercel ihlali ve API ekiplerine öğrettikleri yazısında ele aldık.

Burada önemli denge şu: Bulut otomatik olarak güvensiz değildir. Olgun satıcılar şifreleme, SOC 2, ISO 27001, güvenlik ekipleri ve hızlı yama süreçleriyle birçok şirket içi kurulumdan daha güvenli olabilir. Sorun bulut kullanmak değil; bulutu varsayılan olarak ve veri sınıfını düşünmeden kullanmaktır.

Uyum ve veri ikameti: kendi kendine barındırma ne zaman zorunlu hale gelir?

Bazı ekipler için bulut veya şirket içi seçimi tercih değil, gerekliliktir.

Veri ikameti ve egemenliği

GDPR ve veri yerelleştirme yasaları, kişisel verinin fiziksel olarak nerede bulunabileceğini kısıtlayabilir.

API test veriniz AB sakinlerinin kişisel verilerini içeriyorsa, bu verinin ABD bölgesindeki çok kullanıcılı bir veritabanına senkronize edilmesi uyumluluk riski oluşturabilir.

Kendi kendine barındırılan API platformu ile:

• Verinin bulunduğu bölgeyi siz seçersiniz.
• Ağ erişimini siz kısıtlarsınız.
• Logları siz tutarsınız.
• Yedekleme politikasını siz belirlersiniz.

Sınır ötesi veri aktarımı için Avrupa Veri Koruma Kurulu’nun rehberliği referans alınabilir.

Sektöre özel çerçeveler

Şu alanlarda kendi kendine barındırma veya izole çalışma pratikte zorunlu hale gelebilir:

• HIPAA kapsamındaki sağlık verileri
• PCI DSS kapsamındaki ödeme verileri
• FedRAMP kapsamındaki ABD federal iş yükleri
• CMMC kapsamındaki savunma yüklenicileri
• İzole veya air-gapped ağlar

Bu senaryoyu güvenli ortamlar için izole API test araçları rehberinde daha ayrıntılı inceledik.

Sözleşmeden doğan yükümlülükler

Kurumsal müşteri sözleşmeleri sıkça şu şartları içerir:

Müşteri verisi onaylanmamış alt işleyiciler tarafından işlenemez.
Müşteri verisi belirli bölge dışına çıkarılamaz.
Test verisi üretim verisiyle aynı güvenlik kontrollerine tabi olmalıdır.

API istemciniz test payload’larını otomatik olarak satıcı bulutuna gönderiyorsa, farkında olmadan sözleşme ihlali yaratabilirsiniz.

Denetim ve velayet zinciri

Denetçi genellikle basit sorular sorar:

Bu verilere kim erişebilir?
Bunu nasıl biliyorsunuz?
Erişimler nerede loglanıyor?
Veri hangi bölgede tutuluyor?
Yedekler nerede?
Alt işleyiciler kimler?

Kendi kendine barındırılan dağıtımda cevap daha somuttur: veri sizin sunucularınızda, sizin ağ kontrollerinizin arkasında, sizin erişim politikalarınız kapsamındadır.

Kendi kendine barındırma mı, bulut mu?

Aşağıdaki tabloyu karar başlangıcı olarak kullanabilirsiniz.

Faktör	Bulutla senkronize API araçları	Kendi kendine barındırılan / şirket içi / çevrimdışı
Kurulum	Dakikalar içinde	Altyapı ve operasyon gerekir
Bakım	Satıcı yönetir	Siz yama, yedekleme ve izleme yaparsınız
Gerçek zamanlı iş birliği	Çok güçlü	VPN veya iç ağ üzerinden çalışır
Veri ikameti	Satıcı bölgeleriyle sınırlı	Tam kontrol sizde
Saldırı yüzeyi	Satıcı bulutu, hesaplar, alt işleyiciler	Kendi güvenlik çevreniz
Uyum	Satıcı sertifikalarına bağlı	Daha savunulabilir
Maliyet	Kullanıcı başı abonelik	Lisans + altyapı + operasyon
İzole ağ	Genellikle uygun değil	Uygun
Felaket kurtarma	Satıcı sorumluluğunda	Sizin tasarlamanız gerekir

Kendi kendine barındırmayı seçin, eğer:

• Düzenlemeye tabi bir sektördeyseniz.
• API aracınızda üretim token’ları veya müşteri verisi saklanıyorsa.
• İzole, kısıtlı veya air-gapped ağlarda çalışıyorsanız.
• Hukuk veya güvenlik ekibiniz net velayet zinciri istiyorsa.
• Tek bir satıcıda çok fazla kritik veri birikmesini azaltmak istiyorsanız.
• Denetimde veri konumunu ve erişimi kanıtlamanız gerekiyorsa.

Bulutu seçmek mantıklıdır, eğer:

• Ekip dağıtık çalışıyor ve gerçek zamanlı iş birliği kritikse.
• Küçük bir ekipsiniz ve güvenli altyapı işletecek kapasiteniz yoksa.
• API veriniz hassas veya düzenlemeye tabi değilse.
• Ürün erken aşamada ve hız veri ikametinden daha önemliyse.
• İyi yönetilen bir satıcı bulutu, sizin yarı bakımlı sunucunuzdan daha güvenliyse.

En iyi model çoğu zaman hibrittir:

Düşük hassasiyetli API dokümantasyonu  -> Bulut
Public API örnekleri                   -> Bulut
Üretim token’ları                      -> Yerel / çevrimdışı
Müşteri verisi içeren testler           -> Kendi kendine barındırılan
İzole ağ testleri                       -> Şirket içi

Kararı şirkete göre değil, veri sınıfına göre verin.

API verilerinizi Apidog ile kendi güvenlik çevrenizde tutma

GitHub olayı API verilerinizin nerede yaşadığını sorgulatıyorsa, pratik çözüm size seçim hakkı veren araçlar kullanmaktır.

Apidog; API tasarımı, hata ayıklama, test, mock ve dokümantasyonu tek platformda birleştirir. Önemli nokta şu: Apidog’u bulutta kullanabilir veya ihtiyaç duyduğunuzda kendi güvenlik çevrenizde çalıştırabilirsiniz.

Apidog bulut ürünü birçok ekip için doğru seçim olabilir. Ancak hassas verilerle çalışıyorsanız, API spesifikasyonlarınızı, test verilerinizi ve kimlik bilgilerinizi kendi altyapınızda tutma seçeneğiniz de vardır.

1. Şirket içi ve kendi kendine barındırılan dağıtım

Apidog, işletmeler için tamamen kendi kendine barındırılan şirket içi dağıtım sunar.

Dağıtım seçenekleri Apidog kendi kendine barındırma belgelerinde açıklanır:

• Bağımsız Docker kurulumu
• Uygulama + MySQL + Redis’in sizin sunucularınızda çalışması
• Hibrit model
• Yönetilen veritabanı ve önbellek servisleriyle kullanım
• Kurumsal ölçek için Kubernetes dağıtımı

Bu modelde aşağıdaki veriler sizin altyapınızda kalır:

OpenAPI spesifikasyonları
API koleksiyonları
Test verileri
Ortam değişkenleri
Mock tanımları
Erişim logları

Kendi kendine barındırılan sürüm ayrıca kendi kendine barındırılan test çalıştırıcılarını destekler. Böylece otomatik API testleri üçüncü taraf üzerinden yönlendirilmeden ağınız içinde çalışır.

Bu özellikle şu durumlarda önemlidir:

• Test istekleri gerçek token taşıyorsa
• Endpoint’ler yalnızca iç ağdan erişilebiliyorsa
• Trafiğin şirket dışına çıkmaması gerekiyorsa
• Denetim loglarının kurum içinde tutulması gerekiyorsa

2. Yerel öncelikli çevrimdışı mod

Tam şirket içi dağıtım her zaman gerekli olmayabilir. Tek geliştirici veya küçük ekipler için Apidog’un Çevrimdışı Alanı, verileri cihaz üzerinde tutar.

Apidog Çevrimdışı Alanı belgelerine göre:

• Veriler yerel makinede kalır.
• Buluta yüklenmez.
• Arka plan senkronizasyonu yapılmaz.
• Uç noktalar çevrimdışı tasarlanabilir.
• Debug ve test işlemleri çevrimdışı yürütülebilir.

Bu, geçici “bağlanınca senkronize et” modeli değildir. Kalıcı ve bağımsız bir çalışma alanıdır.

Özellikle sırlar için kullanışlıdır:

Bearer token      -> Yerel
OAuth secret      -> Yerel
DB connection URL -> Yerel
Account password  -> Yerel

Bu değerler bulutla senkronize edilmez ve ekip üyeleriyle otomatik paylaşılmaz.

3. Varsayılan olarak verinin konumunu siz belirlersiniz

Apidog ile iki pratik model kullanabilirsiniz:

Ekip düzeyi kaynak gerçekliği -> Şirket içi Apidog
Bireysel hassas çalışma       -> Çevrimdışı Alan
Düşük riskli iş birliği       -> Apidog bulut

Böylece API verileriniz varsayılan olarak çok kullanıcılı bir buluta devredilmez. Nerede tutulduğunu gösterebilir, denetleyebilir ve savunabilirsiniz.

Başlamak için Apidog’u indirin ve masaüstü uygulamasında Çevrimdışı Alanı etkinleştirin. Kurumsal dağıtım planlıyorsanız kendi kendine barındırma belgelerini inceleyin.

Açık olmak gerekirse: Apidog GitHub ihlalini engellemezdi; hiçbir API aracı bunu yapamazdı. Sağladığı şey, API verilerinizin nerede yaşayacağına olay olduktan sonra değil, önceden karar verebilmenizdir.

Sonuç

GitHub olayı bulutun bozuk olduğunu göstermez. Ancak API ekipleri için net bir uyarıdır.

Özet karar noktaları:

• GitHub, bir çalışan cihazındaki zehirli VS Code uzantısı üzerinden ihlal edildi.
• Yaklaşık 3.800 dahili depodan veri çalındı.
• API gerçekliği çoğu ekipte kod depolarında ve API araçlarında birikir.
• Bulut senkronizasyonu satıcı, hesap, entegrasyon, uzantı ve alt işleyici riskleri ekler.
• Bulutun ciddi avantajları vardır; amaç bulutu reddetmek değil, bilinçli seçim yapmaktır.
• Düzenlemeye tabi veri, üretim sırları ve izole ağlar için kendi kendine barındırma veya çevrimdışı mod güçlü bir gereksinimdir.
• Dağıtık ekipler ve düşük hassasiyetli işler için bulut hâlâ doğru seçim olabilir.

Bu hafta uygulanabilir küçük adım:

1. API aracınızın senkronize ettiği veri türlerini listeleyin.
2. Her veri türünü hassasiyetine göre sınıflandırın.
3. Sırları ve müşteri verilerini bulut senkronizasyonundan ayırın.
4. Çalışma alanı erişimlerini gözden geçirin.
5. Hangi verinin bulutta, hangisinin yerelde veya şirket içinde kalacağına karar verin.

Cevabınızın bir kısmı “kendi çevremizde kalmalı” ise Apidog, şirket içi kendi kendine barındırılan dağıtım ve çevrimdışı mod ile bu modeli uygulamanıza yardımcı olur. Başlamak için Apidog’u indirin.