API Anahtarlarını Kötü Amaçlı VS Code Eklentisinden Koruma

20 Mayıs 2026'da GitHub, saldırganların yaklaşık 3.800 dahili kod deposundan veri çaldığını doğruladı. Giriş noktası GitHub sunucularında bir sıfır gün açığı değildi. Tek bir çalışanın dizüstü bilgisayarına yüklenen zehirli bir VS Code uzantısıydı. Bu uzantı, geliştiricinin dosya sistemi izinleriyle aynı şekilde çalıştığında, ulaşabileceği her şeyi okuyabildi: kaynak kod, yapılandırma dosyaları ve çalışma alanında bulunan tüm kimlik bilgileri. API anahtarlarını aynı tür saldırılardan korumak isterseniz, ders rahatsız edici ama basittir. En zayıf halka nadiren buluttur. Geliştirici makinesi ve üzerinde çalışan araçlardır.

TL;DR

API anahtarlarını tehlikeye girmiş bir IDE uzantısından veya sızdırılmış bir depodan korumak için, canlı kimlik bilgilerini geliştirme araçlarının okuyabileceği yerlerde saklamayı bırakın. Sırları kaynak koddan ve commit edilmiş .env dosyalarından uzak tutun. .gitignore'u bir güvenlik kontrolü olarak değil, bir kolaylık olarak görün. Her anahtarı tek bir ortama kapsamlayın, kısa ömürlü ve en az ayrıcalıklı kimlik bilgileri kullanın ve düzenli olarak değiştirin. Apidog gibi araçlar, API kimlik bilgilerini deponuzda ve çalışma alanınızda dağınık metin olarak değil, yalnızca yerel değerlere sahip ortam değişkenlerinde tutarak yardımcı olur.

GitHub ihlalinin her geliştirici için neden bir uyandırma çağrısı olduğu

GitHub olayı, ders kitaplık bir tedarik zinciri saldırısı gibi okunuyor. TeamPCP olarak takip edilen tehdit grubu, npm, PyPI ve PHP ekosistemlerinde paketleri truva atı haline getirme geçmişine sahip. Bu sefer kötü amaçlı yük bir VS Code uzantısı aracılığıyla geldi. TechCrunch'ın raporlamasına göre, saldırganlar yaklaşık 3.800 dahili depodan veri sızdırdı ve şimdi veri kümesini yeraltı forumlarında 50.000 dolardan fazla bir fiyata satıyorlar. GitHub, bu dahili depoların dışında depolanan müşteri verilerinin etkilenmediğine dair bir kanıtı olmadığını ve soruşturmanın devam ettiğini belirtiyor.

İşte durup düşünmeniz gereken kısım. Bir VS Code uzantısı sadece bir koddur. Bir tane yüklediğinizde, düzenleyici işleminde kullanıcı izinlerinizle birlikte çalışır. Dosyaları listeleyebilir, açabilir ve içeriklerini okuyabilir. Dosya değişikliklerini izleyebilir. Dış ağ istekleri yapabilir. Bunların hiçbiri bir güvenlik açığı değildir; bu, uzantı modelinin tasarlandığı gibi çalışmasıdır. Çoğu uzantının işlerini yapmak için dosya erişimine ihtiyacı vardır. Sorun şu ki, kötü niyetli veya tehlikeye girmiş bir uzantı, bulduğu her şeyi toplamak için aynı erişimi kullanır.

Ne bulur? Tipik bir projede çok şey bulur. Depo kökünde bir .env dosyası. Bir config/secrets.yml. Silmeyi düşündüğünüz hızlı bir test betiğinde sabit kodlanmış bir jeton. ~/.aws/credentials içinde AWS kimlik bilgileri. Bir kimlik doğrulama jetonu içeren bir .npmrc. SSH anahtarları. TeamPCP grubu, enfekte makinelerden geliştirici, CI/CD, bulut ve yapay zeka araçları kimlik bilgilerini toplayan "Mini Shai-Hulud" npm solucan kampanyasının arkasındaki aynı aktördür. Desen tutarlıdır: geliştiricinin bilgisayarında kod çalıştırın, ardından kimlik bilgisi gibi görünen her şeyi tarayın.

Bu tür olarak yeni değil, sadece profil olarak yeni. Vercel ihlalinden alınan API güvenlik dersleri ile ilgili analizimizde benzer bir ifşa modelinden bahsetmiştik ve tedarik zinciri mekanikleri, npm tedarik zinciri güvenlik rehberimizde ele aldıklarımızla yakından örtüşüyor. GitHub olayı, daha büyük bir isimle aynı hikaye. Dolayısıyla bugün sorulması gereken doğrudan soru şudur: şu anda düzenleyicinizde kötü niyetli bir uzantı çalışsaydı, neyle ayrılırdı?

Sabit kodlanmış anahtarlar ve commit edilmiş .env dosyaları kalıcı bir yükümlülüktür

Çoğu kimlik bilgisi sızıntısı sofistike değildir. Bunlar, bir geliştiricinin bir anahtarı "şimdilik" koda yapıştırması ve unutması veya bir .env dosyasının bir commit'e girmesidir. Her ikisi de deponuzda süresiz olarak duran bir yükümlülük yaratır.

Sabit kodlanmış anahtarlar bariz bir günahtır. Şöyle bir kod görmüşsünüzdür:

import requests

# Ödeme uç noktasının hızlı testi
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())

Bu sk_live_ anahtarı artık dosyanın bir parçasıdır. Çalışma dizininizde, herhangi bir uzantının okuyabileceği bir yerdedir. Dosya commit edilmişse, anahtar daha sonraki bir commit'te satırı silseniz bile Git geçmişinizde sonsuza kadar kalır. Depoyu klonlayan herkes veya onu tarayan herhangi bir araç anahtarı alır.

.env dosyasının düzeltme olması gerekiyordu. Fikir sağlamdır: sırları koddan uzak tutun, çalışma zamanında yükleyin. Gerçek bir .env şöyle görünür:

# .env (çalışma zamanında yüklenir, asla gönderilmez)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350

Bu, sabit kodlamadan daha iyidir. Ancak neyin değişmediğine dikkat edin. Bu dosya hala çalışma alanınızda, düz metin olarak, düzenleyicinin çalıştırdığı her işlem tarafından okunabilir bir şekilde duruyor. Kötü niyetli bir uzantı, sırlarınızın app.py içinde mi yoksa .env içinde mi olduğuna aldırış etmez. Her ikisi de dosyadır. Her ikisi de tek bir fs.readFileSync uzaklıktadır. .env deseni, "Git geçmişindeki sırlar" sorununu yalnızca dosya asla commit edilmezse çözer ve "tehlikeye girmiş yerel araç" sorunu için hiçbir şey yapmaz.

Commit edilmiş .env en kötü sonuçtur. Alarm verici derecede yaygındır. Bir geliştirici .env'i projeye ekler, içine gerçek anahtarları yazar ve ilk commit'ten önce onu yok saymayı unutur. Veya bir ekip arkadaşı depoyu klonlar, .env.example'ı görür, .env'e kopyalar, üretim anahtarlarını doldurur ve daha sonraki bir git add . onu içine alır. Şimdi üretim kimlik bilgileri, herkese açık olabilecek, yansıtılabilecek veya GitHub'ınki gibi bir ihlalle sonuçlanabilecek bir deponun paylaşılan geçmişinde yer alıyor. API dokümantasyonu ve Git depo güvenliği ile ilgili ek makalemizde depo sızıntısı açısını daha derinlemesine inceliyoruz.

.gitignore bir güvenlik kontrolü değildir

Bu, yanlış anlaşılma çok yaygın olduğu için kendi bölümünü hak ediyor. .env'i .gitignore'a eklemek kapıyı kilitlemek gibi hissettiriyor. Öyle değil. Bu, "lütfen bunu alma" diyen yapışkan bir nottur.

İşte .gitignore'un aslında yaptığı şey. git add komutunu çalıştırdığınızda Git'e bir desene uyan izlenmeyen dosyaları atlamasını söyler. Kapsamı budur. Güvenlik için önemli olan üç hata modu vardır:

1. Zaten izlenen dosyalar için hiçbir şey yapmaz. Eğer .env, ignore kuralını eklemeden önce bir kez commit edilmişse, Git onu izlemeye devam eder. Ignore kuralı sessizce geçersiz kılınır. git rm --cached .env komutunu çalıştırmanız ve bu kaldırmayı commit etmeniz gerekir ve sır hala her geçmiş commit'te bulunur.
2. Diskteki dosya için hiçbir şey yapmaz. .gitignore bir Git talimatıdır. .env dosyası hala çalışma dizininizde düz metin olarak durur. Kötü niyetli bir VS Code uzantısı, Git indeksini değil, dosya sistemini okur. Ignore kuralınız ona görünmezdir. GitHub tarzı saldırı için en önemli olan hata modu budur.
3. Atlatılmasına bir hata uzaklıktadır. git add -f .env ignore kuralını yok sayar. Bir düzenleyicinin kaynak kontrol kullanıcı arayüzü aracılığıyla dosya eklemek de öyle. Deseni tekrarlamayan bir alt dizindeki farklı bir .gitignore de öyle.

Birinci noktayı kendiniz doğrulayabilirsiniz. Eğer bir sırrın daha önce commit edildiğinden şüpheleniyorsanız, bu komut size gösterir:

# Dosyayı etkileyen her commit'i listele, şu anda "yok sayılmış" olsa bile
git log --all --full-history --oneline -- .env

# Geçmişte hala bulunan gerçek sır değerlerini gör
git log -p --all -- .env | grep -iE "key|secret|token|password"

Eğer bu bir şey döndürürse, depo ifşa edildiği anda kimlik bilgisi tehlikeye girmiştir. Çözüm daha iyi bir ignore kuralı değildir. Çözüm, anahtarı döndürmek ve git filter-repo gibi bir araçla dosyayı geçmişten kaldırmaktır. Daha derin çözüm, canlı kimlik bilgisinin ilk etapta hiçbir dosyada bulunmamasını sağlamaktır.

.gitignore kullanmaya değerdir. Dürüst hataları yakalar ve farklarınızı temiz tutar. Ancak bunu bir saldırganın saygı duyduğu bir sınır olarak karıştırmayın. Bu hijyendir, savunma değil.

Kapsam belirle, ayır, kısalt, döndür: Patlama yarıçapını küçülten dört alışkanlık

Bir kimlik bilgisinin asla sızmayacağını garanti edemezsiniz. Ancak sızdırılmış bir kimlik bilgisinin neredeyse değersiz olacağını garanti edebilirsiniz. Dört alışkanlık işin çoğunu halleder.

Sırları ortamlara göre kapsamla

Sızdırılmış bir anahtar, tüm mülkünüzü değil, yalnızca bir şeyi açmalıdır. En yaygın kapsam belirleme hatası, daha kolay olduğu için aynı API anahtarını geliştirme, hazırlık ve üretim ortamlarında kullanmaktır. Bu anahtar sızdığında, her ortam aynı anda çöker.

Her ortama kendi kimlik bilgilerini verin. Yerel makineniz, bir sandbox projesine ve test verilerine erişimi olan bir geliştirme anahtarı kullanır. Hazırlık ortamı bir hazırlık anahtarı kullanır. Üretim ortamı, tam olarak tek bir yerde bulunan ve asla bir dizüstü bilgisayara kopyalanmayan bir üretim anahtarı kullanır. Eğer geliştirme anahtarı tehlikeye girmiş bir uzantı aracılığıyla sızarsa, saldırgan sahte müşterilerle dolu bir sandbox'a ulaşır. Bu bir rahatsızlıktır, bir olay değil.

Ortamları düzgün bir şekilde ayırın

Ortam ayrımı, üç farklı anahtar değerinden daha fazlasıdır. Ortamların birbirine ulaşamaması anlamına gelir. Geliştirme veritabanı, üretimin okuma replikası değil, farklı bir veritabanıdır. Hazırlık ödeme sağlayıcısı, sağlayıcının test modudur, bu nedenle sızdırılmış bir hazırlık anahtarı gerçek bir ücret almaz. Araçlar ve insanlar, tek bir değişkeni değiştirerek "dev" yapılandırmasını üretim verilerine yönlendirememelidir.

Ayrım gerçek olduğunda, "bu anahtar hangi ortamdan geldi?" sorusunun net bir cevabı vardır ve bu cevap size bir sızıntının ne kadar kötü olduğunu tam olarak söyler.

En az ayrıcalıklı, kısa ömürlü anahtarlar kullanın

Çalınan bir anahtarın ne kadar hasar vereceğini iki özellik belirler.

Ayrıcalık. Bir anahtar, görevinin gerektirdiği en dar izin setini taşımalıdır. Herkese açık bir ürün kataloğunu okuyan bir ön uç derlemesi, yalnızca o kaynağa kapsamlanmış salt okunur bir anahtara ihtiyaç duyar. Yazma erişimine, faturalandırma erişimine ihtiyacı yoktur ve kesinlikle yönetici ayrıcalıklarına ihtiyacı yoktur. Çoğu API sağlayıcısı kapsamlı anahtarları veya ince taneli jetonları destekler; GitHub'ın kendi ince taneli kişisel erişim jetonları iyi bir modeldir. Jeton stillerini değerlendiriyorsanız, API anahtarları ile OAuth karşılaştırmamız, kısa ömürlü OAuth jetonlarının statik anahtarları ne zaman açıkça yendiğini gösterir.

Ömür. Bir saat içinde sona eren bir anahtar, zayıf bir ödüldür. Bir saldırgan çalınan bir veri kümesini satın alıp anahtarınıza ulaşana kadar, anahtarın süresi dolmuş olur. Sonsuza kadar yaşayan statik anahtarlar tam tersidir: birisi fark edene kadar çalışırlar, ki bu genellikle aylarca sürer. Talep üzerine verilen kısa ömürlü jetonları tercih edin. Uzun ömürlü bir anahtar kaçınılmazsa, iş akışının tolere ettiği en kısa süreyi ayarlayın.

Panik anında değil, programa göre döndürün

Döndürme, bir kimlik bilgisinin değerini değiştirerek eskisinin çalışmamasını sağlamaktır. Çoğu ekip, yalnızca bir ihlalden sonra, aceleyle, stres altında döndürme yapar. Bu, döndürme sürecinizin belgelenmediğini öğrenmek için en kötü zamandır.

Bunun yerine bir takvime göre döndürün. Her kimlik bilgisi sınıfı için bir aralık seçin; yüksek ayrıcalıklı üretim anahtarları için aylık, daha düşük riskli anahtarlar için üç aylık. Rutin döndürme iki şey yapar. Henüz tespit etmediğiniz herhangi bir sızıntının faydalı ömrünü sınırlar, çünkü bugün çalınan bir anahtar bir sonraki döngüde çalışmayı durdurur. Ve mekanikleri, değeri her tüketen ortamda güncellemeyi, alıştırma yapılmış ve sıkıcı hale getirir. Gerçek bir olay meydana geldiğinde, döndürme elli kez bastığınız bir düğmedir, bir tatbikat değil. Daha kapsamlı bir inceleme için, API anahtarı yönetimi araçları özetimize bakın.

Kimlik bilgilerini çalışma alanınızda dağınık bir şekilde değil, Apidog ortam değişkenlerinde saklayın

İşte dürüst bir çerçeve. Apidog kendi VS Code uzantısını ve bir MCP sunucusunu gönderir. Tartışma "aracımız GitHub'ı vuran saldırı sınıfına karşı bağışıktır" şeklinde değildir. Hiçbir istemci tarafı araç bağışık değildir. Tartışma, sırlarınızın nerede yaşadığı ve makinenizdeki bir şey kötüye gittiğinde ne kadar açıkta oldukları hakkındadır.

Gerçekçi senaryoyu düşünün. Bütün gün API'ler oluşturuyor ve test ediyorsunuz. Bir taşıyıcı jetona, bir API anahtarına, bir veritabanı bağlantı dizesine ihtiyacınız var. Varsayılan hareket, istemcinizin bunları kullanabilmesi için bir .env dosyasına veya bir betiğe bırakmaktır. Bu, canlı kimlik bilgilerini çalışma alanındaki düz metin dosyalarına yerleştirir, ki bu tam da kötü niyetli bir uzantının kazıdığı yüzeydir. Apidog'un ortam sistemi, bu değerlerin nerede durduğunu değiştirir.

Düz metin dosyaları yerine ortam değişkenleri

Apidog'da, kimlik bilgilerini deponuzdaki dağınık metin olarak değil, ortam değişkenleri olarak saklarsınız. Bir istek, bir Authorization başlığında {{access_token}} gibi değişkeni adıyla referans alır ve Apidog gönderme sırasında bunu çözer. İstek tanımınızdaki başlık, Bearer sk-proj-aB3dEf... değil, Bearer {{access_token}} olarak okunur. Gerçek sır, projenin kökünde okunmayı bekleyen bir .env dosyasında durmaz.

Bu, .env'in sabit kodlamadan neden daha iyi olduğuyla aynı nedenden ötürü önemlidir, bir adım daha ileriye götürülmüştür. Kimlik bilgisi artık kaynak kodunuzun yanında duran bir dosyada düz metin bir satır değildir. API istemcisi içinde yönetilen, dolaylı olarak referans alınan bir değerdir.

Yerel değerler sırları makinenizde tutar

Apidog, her değişken için iki tür değer arasında kasıtlı bir çizgi çizer. Apidog sunucularıyla senkronize olan ve ekibiniz tarafından görülebilen paylaşılan veya başlangıç değeri vardır. Ve makinenizde kalan ve asla yüklenmeyen yerel veya güncel bir değer vardır. Resmi rehberlik açıkça belirtir: jetonlar ve parolalar gibi hassas verileri yerel değere koyun, böylece istemcinizden asla ayrılmaz.

Pratik etkisi şudur: proje yapısını klonlayan bir ekip arkadaşı değişken adını ve şeklini (access_token, db_password ve diğerleri) alır, ancak gerçek sırrınızı almaz. Her geliştirici kendi yerel değerini doldurur. Kimsenin canlı üretim jetonu senkronize edilmiş proje verilerinde taşınmaz ve sızdırılabilecek gerçek anahtarların paylaşılan bir dosyası yoktur.

Ortam yönetimi ve ortam izolasyonu

Apidog'un ortam yönetimi, önceki bölümdeki kapsam belirleme alışkanlığı üzerine kuruludur. Ayrı ortamlar (Geliştirme, Hazırlık, Üretim) tanımlarsınız ve her biri kendi temel URL'sini ve kendi değişken değer setini taşır. Değişkenler ortama kapsamlıdır: yalnızca etkin ortamın değerleri geçerlidir ve ortamları değiştirmek, tüm kimlik bilgisi setini bir kerede değiştirir.

Bu size yapı gereği ortam izolasyonu sağlar. payment_api_key değişkeniniz Geliştirme altında bir sandbox anahtarı ve Üretim altında bir üretim anahtarı tutar. Aralarında geçiş yapmak için asla bir isteği düzenlemezsiniz; ortamı değiştirirsiniz. Değerler ortama bağlı olduğundan, bir geliştirme kimlik bilgisi yanlışlıkla bir üretim çağrısına düşemez ve bir üretim sırrının yerel geliştirme ortamınızda hiç bulunması gerekmez. Sızdırılmış bir geliştirme ortamı geliştirme değerlerini ifşa eder. Üretim etkilenmeden kalır.

Katı bir sınıra ihtiyaç duyan ekipler için: kasa sırları

Ekibiniz üretim sırlarının API istemcisine asla dokunmasını istemiyorsa, Apidog'un Enterprise planı, sırları doğrudan HashiCorp Vault, Azure Key Vault veya AWS Secrets Manager'dan alan bir Kasa Sırrı özelliğini ekler. Apidog yalnızca kasa yolunu ve meta verileri saklar. Gerçek sır değerleri talep üzerine çekilir, yerel istemcide şifrelenir ve proje aracılığıyla ekip arkadaşlarıyla asla paylaşılmaz. Kimlik bilgisinin evi özel sır yöneticisi olarak kalır, ki bir üretim kimlik bilgisinin tam olarak yaşaması gereken yer orasıdır.

Ortam değişkeni iş akışını denemek için, Apidog'u indirin, bir proje oluşturun, Ortam Yönetimi'ni açın ve kimlik bilgilerinizi yalnızca yerel değerlerle ortam değişkenleri olarak ekleyin. Birkaç dakika sürer ve canlı sırları bir uzantının okuyabileceği düz metin dosyalarından çıkarır.

Bir dürüst uyarı. Sırları Apidog'a taşımak, deponuzda ve çalışma alanınızda bulunan düz metin kimlik bilgilerinin sayısını azaltır. Bu, makinenizi tehlikeye girmiş bir araca karşı bağışık hale getirmez. Derinlemesine savunma hala geçerlidir: yüklediğiniz uzantıları denetleyin, üretim anahtarlarını en az ayrıcalıklı ve kısa ömürlü tutun ve düzenli olarak döndürün. Apidog "kimlik bilgileri nerede yaşıyor" kısmını halleder. Gerisi hala size kalmış.

Sonuç

GitHub ihlali açık bir sinyaldir. Saldırganlar, geliştirici makinesinin, güvenilir araçları ve düz metin yapılandırma dosyalarıyla, herhangi bir üretim sunucusundan daha yumuşak bir hedef olduğunu anlamışlardır. Bu makineyi tamamen güvenli hale getiremezsiniz. Ancak tehlikeye girmiş bir IDE uzantısının veya sızdırılmış bir deponun bir saldırgana çok az şey vermesini sağlayabilirsiniz.

Bir denetimle başlayın. En çok çalıştığınız depoyu açın ve içinde key, secret, token ve password kelimelerini arayın. .env'in Git geçmişinizde olup olmadığını kontrol edin. Bulduğunuz her ne olursa olsun, onu ifşa olmuş gibi değerlendirin: döndürün, ardından canlı değeri başıboş bir aracın okuyamayacağı bir yere taşıyın. Apidog'u indirin ve bir sonraki API kimlik bilgileri setinizi düz metin bir dosya yerine ortam değişkenlerine koyun. Daha geniş bağlam için, GitHub ihlalinden sonra kendi kendine barındırılan API araçları ve API anahtarı yönetimi araçları hakkındaki tamamlayıcı makalelerimiz iyi birer sonraki okumadır.

Sıkça Sorulan Sorular

Bir VS Code uzantısı gerçekten benim .env dosyamı ve API anahtarlarımı okuyabilir mi?

Evet. Bir VS Code uzantısı, düzenleyici işleminde kullanıcı hesabınızın dosya izinleriyle çalışır. Dizinleri listeleyebilir, dosyaları açabilir ve .env dosyaları, yapılandırma dosyaları ve ~/.aws/credentials gibi kimlik bilgisi dosyaları dahil olmak üzere içeriklerini okuyabilir. Bu, normal uzantı davranışıdır, çünkü birçok uzantının yasal olarak dosya erişimine ihtiyacı vardır. Risk, kötü niyetli veya tehlikeye girmiş bir uzantının aynı erişimi kullanarak sırları toplamasıdır. Mayıs 2026'daki GitHub ihlalinin arkasındaki mekanizma budur.

.env'i .gitignore'a eklemek API anahtarlarını korumak için yeterli midir?

Hayır. .gitignore yalnızca Git'e git add sırasında izlenmeyen dosyaları atlamasını söyler. Kural var olmadan önce zaten commit edilmiş dosyalar için hiçbir şey yapmaz ve sır yine de Git geçmişinde kalır. Ayrıca diskteki dosya için de hiçbir şey yapmaz: .env dosyası hala çalışma alanınızda düz metin olarak durur, herhangi bir yerel araç veya uzantı tarafından tamamen okunabilir. .gitignore'u dürüst hataları önlemenin bir yolu olarak görün, bir güvenlik sınırı olarak değil.

Git geçmişimde bir API anahtarı bulursam ne yapmalıyım?

Repo özel olsa bile, hemen tehlikeye girmiş gibi işlem yapın. Önce anahtarı döndürün, böylece açığa çıkan değer çalışmayı durdurur. Ardından git filter-repo gibi bir araç kullanarak dosyayı geçmişten kaldırın ve ekibinizle koordinasyon sağladıktan sonra temizlenmiş geçmişi zorla gönderin. Son olarak, canlı kimlik bilgisini herhangi bir düz metin dosyasından çıkarın, böylece aynı sızıntı tekrar yaşanmasın. Devam eden uygulamalar için API anahtarı yönetimi araçları rehberimize bakın.

Apidog'da API anahtarlarını saklamak maruz kalma durumumu nasıl azaltır?

Apidog, kimlik bilgilerini ortam değişkenleri olarak saklamanıza ve isteklerde adıyla referans almanıza olanak tanır, böylece gerçek sır deponuzda düz metin bir .env dosyasında durmaz. Her değişken, makinenizde kalan ve sunuculara veya ekip arkadaşlarına asla senkronize edilmeyen yalnızca yerel bir değeri destekler; belgelerin jetonları ve parolaları saklamayı önerdiği yer burasıdır. Ortama kapsamlı değişkenler ayrıca geliştirme ve üretim kimlik bilgilerini ayrı tutar. Bir aracın kazıyabileceği dosyalarda bulunan canlı sırların sayısını azaltır; makinenizi tehlikeye girmiş bir araca karşı bağışık hale getirmez.

Apidog'un da bir VS Code uzantısı var mı ve bu bir risk mi?

Evet, Apidog bir VS Code uzantısı ve bir MCP sunucusu sunar. Bu makalenin amacı, herhangi bir aracın tedarik zinciri saldırılarına karşı bağışık olduğunu söylemek değildir; hiçbir istemci tarafı araç bağışık değildir. Önemli olan sırlarınızın nerede yaşadığıdır. Kimlik bilgilerini yalnızca yerel değerlere sahip ortam değişkenlerinde veya bir kasa entegrasyonunda tutmak, makinenizdeki herhangi bir araç, Apidog'un kendi uzantısı da dahil olmak üzere, tehlikeye girerse daha az düz metin anahtarının açığa çıkması anlamına gelir. Derinlemesine savunma, uzantıları denetleme, en az ayrıcalık ve döndürme hala geçerlidir.

API anahtarlarını kapsam belirleme ve döndürme arasındaki fark nedir?

Kapsam belirleme, bir anahtarın ne yapabileceğini ve nerede geçerli olduğunu sınırlar: bir geliştirme anahtarı yalnızca bir sanal ortama ulaşır ve salt okunur bir anahtar yazma işlemi yapamaz. Döndürme, bir anahtarın değerini belirli bir programa göre değiştirerek eski değerin çalışmamasını sağlar. Kapsam belirleme, sızdırılmış bir anahtarın neden olabileceği zararı azaltır; döndürme ise sızdırılmış bir anahtarın işe yarar kalma süresini kısaltır. Her ikisini de istersiniz. Birlikte kullanıldığında, çalınan bir anahtar çok az şeyin kilidini açar ve kısa sürede sona erer.

API anahtarlarını ne sıklıkla döndürmeliyim?

Yalnızca bir olaydan sonra değil, belirli bir programa göre döndürün. Makul bir temel, yüksek ayrıcalıklı üretim kimlik bilgileri için aylık, daha düşük riskli anahtarlar için ise üç aylıktır; bu, risk toleransınıza ve herhangi bir uyumluluk kuralına göre ayarlanır. Programlı döndürme, tespit etmediğiniz sızıntıların faydalı ömrünü sınırlar ve döndürme sürecini iyi bir şekilde pratik hale getirir, böylece gerçek bir olay aceleyle yapılan bir iş değil, rutin bir işlem olur.

Üretim API anahtarları bir geliştiricinin dizüstü bilgisayarında olmalı mı?

İdeal olarak, hayır. Bir üretim kimlik bilgisi mümkün olduğunca az yerde bulunmalı, normalde özel bir sır yöneticisi ve üretim çalışma zamanı olmalı, asla bir geliştiricinin makinesine kopyalanmamalıdır. Geliştiriciler, üretim dışı verilere kapsamlanmış geliştirme veya hazırlık kimlik bilgileriyle çalışmalıdır. Bir dizüstü bilgisayar tehlikeye girerse, saldırgan canlı müşteri sistemlerine değil, bir sanal ortama ulaşır. Apidog'un ortam izolasyonu ve kasa entegrasyonu, üretim değerlerini yerel geliştirme ortamlarından uzak tutarak bunu destekler.