DEV Community

Cover image for API Anahtarlarını Kötü Amaçlı VS Code Eklentisinden Koruma
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

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ındaki bir sıfır gün açığı değil, tek bir çalışanın dizüstü bilgisayarına yüklenen zehirli bir VS Code uzantısıydı. Uzantı, geliştiricinin dosya sistemi izinleriyle çalıştığı için kaynak kodu, yapılandırma dosyalarını ve çalışma alanındaki kimlik bilgilerini okuyabildi. API anahtarlarını benzer saldırılardan korumak istiyorsanız çıkarım net: en zayıf halka çoğu zaman bulut değil, geliştirici makinesi ve üzerinde çalışan araçlardır.

Apidog'u bugün deneyin

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ın.

Uygulanacak temel kontroller:

  • Sırları kaynak koddan ve commit edilmiş .env dosyalarından çıkarın.
  • .gitignore'u güvenlik kontrolü değil, hata önleme kolaylığı olarak görün.
  • Her anahtarı tek bir ortama kapsamlayın: geliştirme, hazırlık veya üretim.
  • Kısa ömürlü ve en az ayrıcalıklı kimlik bilgileri kullanın.
  • Anahtarları olay anında değil, düzenli bir takvimle döndürün.
  • API istemcilerinde gerçek değerleri düz metin dosyalarında değil, ortam değişkenlerinde ve mümkünse yerel değerlerde tutun.

Apidog gibi araçlar, API kimlik bilgilerini deponuzda veya çalışma alanınızda dağınık düz metin olarak tutmak yerine ortam değişkenleriyle yönetmenize yardımcı olur.

GitHub ihlali neden her geliştirici için uyarı niteliğinde?

GitHub olayı tipik bir tedarik zinciri saldırısı gibi ilerledi. TeamPCP olarak takip edilen tehdit grubu daha önce npm, PyPI ve PHP ekosistemlerinde truva atına dönüştürülmüş paketlerle ilişkilendirilmişti. Bu olayda kötü amaçlı yük bir VS Code uzantısı üzerinden geldi.

TechCrunch'ın raporuna göre saldırganlar yaklaşık 3.800 dahili depodan veri sızdırdı ve veri kümesini yeraltı forumlarında 50.000 dolardan fazla bir fiyata satmaya çalışıyor. GitHub, bu dahili depolar dışında saklanan müşteri verilerinin etkilendiğine dair kanıt olmadığını ve soruşturmanın sürdüğünü belirtiyor.

Buradaki kritik nokta şu: VS Code uzantısı da nihayetinde koddur. Bir uzantı yüklediğinizde, düzenleyici işleminde kullanıcı izinlerinizle çalışır. Şunları yapabilir:

  • Dizinleri listeleyebilir.
  • Dosyaları açabilir ve okuyabilir.
  • Dosya değişikliklerini izleyebilir.
  • Harici ağ istekleri yapabilir.

Bunların hiçbiri tek başına güvenlik açığı değildir. Uzantı modelinin normal çalışma şekli budur. Çoğu uzantının işini yapabilmesi için dosya erişimine ihtiyacı vardır. Sorun, kötü niyetli veya ele geçirilmiş bir uzantının aynı erişimi sır toplamak için kullanabilmesidir.

Tipik bir geliştirici makinesinde saldırganın bulabileceği şeyler:

  • Proje kökündeki .env
  • config/secrets.yml
  • Hızlı test betiklerinde unutulmuş token'lar
  • ~/.aws/credentials
  • Kimlik doğrulama token'ı içeren .npmrc
  • SSH anahtarları
  • API istemcilerindeki bearer token'lar
  • CI/CD veya bulut sağlayıcı kimlik bilgileri

TeamPCP grubunun ilişkilendirildiği “Mini Shai-Hulud” npm solucanı da benzer bir desen izliyordu: geliştirici makinesinde kod çalıştır, ardından kimlik bilgisi gibi görünen her şeyi tara.

Bu saldırı türü yeni değil. Daha önce Vercel ihlalinden çıkarılabilecek API güvenliği derslerinde benzer ifşa modellerini, npm tedarik zinciri güvenlik rehberinde ise paket ekosistemi risklerini ele almıştık.

Kendinize şu soruyu sorun:

Şu anda düzenleyicimde kötü niyetli bir uzantı çalışıyor olsaydı, hangi sırları okuyabilirdi?

Sabit kodlanmış anahtarlar ve commit edilmiş .env dosyaları kalıcı risktir

Kimlik bilgisi sızıntılarının çoğu karmaşık değildir. Genellikle iki şekilde başlar:

  1. Bir geliştirici anahtarı “şimdilik” koda yapıştırır.
  2. .env dosyası yanlışlıkla commit edilir.

İkisi de uzun ömürlü bir risk yaratır.

Sabit kodlanmış anahtar örneği

Aşağıdaki gibi bir kod parçası tanıdık gelebilir:

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())
Enter fullscreen mode Exit fullscreen mode

Bu kodda sorun sadece anahtarın görünür olması değildir. Sorun şu:

  • Anahtar çalışma dizinindedir.
  • Herhangi bir yerel araç veya uzantı tarafından okunabilir.
  • Dosya commit edilirse anahtar Git geçmişine girer.
  • Daha sonra satırı silseniz bile eski commit'lerde kalır.
  • Depoyu klonlayan veya geçmişi tarayan herkes anahtara ulaşabilir.

.env tek başına yeterli değildir

.env yaklaşımının amacı doğrudur: sırları koddan ayırmak ve çalışma zamanında yüklemek.

Örnek:

# .env (çalışma zamanında yüklenir, asla gönderilmemelidir)
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
Enter fullscreen mode Exit fullscreen mode

Bu, sabit kodlamadan daha iyidir. Ancak önemli bir risk değişmez:

.env dosyası hâlâ çalışma alanınızda düz metin olarak durur.

Kötü niyetli bir uzantı için sırrın app.py içinde veya .env içinde olması fark etmez. İkisi de dosyadır. İkisi de okunabilir.

.env deseni yalnızca şu koşulda Git geçmişi riskini azaltır:

  • Dosya hiçbir zaman commit edilmemiş olmalıdır.
  • Dosya hiçbir zaman paylaşılan arşivlere, yedeklere veya loglara girmemelidir.
  • Yerel makinedeki araçların dosyayı okuyabileceği kabul edilmelidir.

En kötü senaryo commit edilmiş .env dosyasıdır. Bu hâlâ çok yaygındır:

git add .
git commit -m "initial commit"
Enter fullscreen mode Exit fullscreen mode

Bu komutlar, .env doğru şekilde yok sayılmadıysa üretim sırlarını deponun geçmişine ekleyebilir. Depo özel olsa bile risk devam eder. Depo daha sonra sızabilir, fork'lanabilir, yedeklenebilir veya bir tedarik zinciri olayıyla ifşa olabilir.

Bu konunun depo güvenliği tarafını API dokümantasyonu ve Git depo güvenliği yazısında daha ayrıntılı ele alıyoruz.

.gitignore bir güvenlik kontrolü değildir

.env dosyasını .gitignore içine eklemek iyi bir pratiktir, ancak güvenlik sınırı değildir. Daha doğru tanım şudur:

.gitignore, Git'e “bu dosyayı varsayılan olarak ekleme” demenin yoludur.

Bir saldırganı, kötü niyetli uzantıyı veya diskteki dosya erişimini engellemez.

.gitignore nerede başarısız olur?

1. Zaten izlenen dosyaları durdurmaz

Eğer .env dosyası .gitignore kuralından önce commit edildiyse Git onu izlemeye devam eder.

Kontrol edin:

git status
Enter fullscreen mode Exit fullscreen mode

Dosya hâlâ izleniyorsa kaldırın:

git rm --cached .env
git commit -m "remove env file from tracking"
Enter fullscreen mode Exit fullscreen mode

Ancak bu sadece dosyayı son durumdan çıkarır. Sır geçmiş commit'lerde kalmaya devam eder.

2. Diskteki dosyayı korumaz

.gitignore sadece Git davranışını etkiler. Şunu engellemez:

const fs = require("fs");

const env = fs.readFileSync(".env", "utf8");
console.log(env);
Enter fullscreen mode Exit fullscreen mode

Kötü niyetli bir uzantı Git indeksini değil, dosya sistemini okur.

3. Kolayca atlatılabilir

Şu komut .gitignore kuralını bypass eder:

git add -f .env
Enter fullscreen mode Exit fullscreen mode

Ayrıca bazı editör UI'ları, alt dizinlerdeki farklı ignore kuralları veya yanlış yapılandırılmış repo kökleri de beklenmedik dosyaların commit edilmesine yol açabilir.

Git geçmişinde sır var mı kontrol edin

Bir sırrın daha önce commit edilmiş olabileceğinden şüpheleniyorsanız:

# .env dosyasını etkileyen tüm commit'leri listele
git log --all --full-history --oneline -- .env

# Geçmişte sır benzeri değerleri ara
git log -p --all -- .env | grep -iE "key|secret|token|password"
Enter fullscreen mode Exit fullscreen mode

Daha geniş arama için:

git grep -n -iE "api_key|apikey|secret|token|password|access_key"
Enter fullscreen mode Exit fullscreen mode

Tüm geçmişte aramak için:

git log -p --all | grep -iE "api_key|apikey|secret|token|password|access_key"
Enter fullscreen mode Exit fullscreen mode

Eğer sonuç dönüyorsa, anahtarı ifşa olmuş kabul edin.

Uygulanacak sıra:

  1. Anahtarı hemen döndürün.
  2. Eski değerin artık çalışmadığını doğrulayın.
  3. Dosyayı geçmişten temizlemek için git filter-repo gibi bir araç kullanın.
  4. Temizlenmiş geçmişi ekiple koordine ederek gönderin.
  5. Canlı sırrı düz metin dosyalarından çıkarın.

Özet: .gitignore hijyendir, savunma değildir.

Kapsam belirle, ayır, kısalt, döndür

Bir kimlik bilgisinin asla sızmayacağını garanti edemezsiniz. Ancak sızarsa ne kadar zarar vereceğini kontrol edebilirsiniz.

Dört alışkanlık riski ciddi şekilde azaltır:

  1. Ortama göre kapsam belirle.
  2. Ortamları gerçekten ayır.
  3. En az ayrıcalıklı ve kısa ömürlü anahtarlar kullan.
  4. Düzenli olarak döndür.

1. Sırları ortama göre kapsamlayın

En sık yapılan hata, aynı API anahtarını geliştirme, hazırlık ve üretimde kullanmaktır.

Bunu yapmayın:

# Kötü örnek
DEV_API_KEY=sk_live_shared_key
STAGING_API_KEY=sk_live_shared_key
PROD_API_KEY=sk_live_shared_key
Enter fullscreen mode Exit fullscreen mode

Bunun yerine her ortam için ayrı kimlik bilgisi kullanın:

# Daha güvenli model
DEV_API_KEY=dev_sandbox_key
STAGING_API_KEY=staging_test_key
PROD_API_KEY=prod_restricted_key
Enter fullscreen mode Exit fullscreen mode

Pratik kural:

  • Yerel geliştirme anahtarı sadece sandbox verilerine erişmeli.
  • Hazırlık anahtarı test modunda çalışmalı.
  • Üretim anahtarı geliştirici dizüstü bilgisayarında bulunmamalı.
  • Bir geliştirme anahtarı sızarsa üretim etkilenmemeli.

Sızdırılmış bir geliştirme anahtarı sahte verilerle dolu bir sandbox'a erişiyorsa bu bir olay değil, yönetilebilir bir rahatsızlıktır.

2. Ortamları gerçekten ayırın

Ortam ayrımı sadece farklı değişken değerleri kullanmak değildir. Ortamların birbirine ulaşamaması gerekir.

Kontrol listesi:

  • Geliştirme veritabanı üretim replikası olmamalı.
  • Hazırlık ödeme sağlayıcısı test modunda olmalı.
  • Geliştirme token'ı üretim API'sinde çalışmamalı.
  • Tek bir BASE_URL değişikliği üretim verilerine erişim sağlamamalı.
  • Üretim sırları yerel geliştirme ortamına kopyalanmamalı.

Kötü örnek:

APP_ENV=dev
DATABASE_URL=postgres://readonly_user@prod-replica.internal:5432/app
Enter fullscreen mode Exit fullscreen mode

Bu yapı “geliştirme” gibi görünür ama üretim verisine bağlıdır.

Daha iyi yaklaşım:

APP_ENV=dev
DATABASE_URL=postgres://dev_user@dev-db.internal:5432/app
Enter fullscreen mode Exit fullscreen mode

Ortam ayrımı gerçek olduğunda şu sorunun net cevabı olur:

Bu anahtar hangi ortamdan geldi ve sızarsa neye erişebilir?

3. En az ayrıcalıklı ve kısa ömürlü anahtarlar kullanın

Çalınan bir anahtarın etkisini iki faktör belirler:

  • Ne yapabilir?
  • Ne kadar süre çalışır?

Ayrıcalığı azaltın

Bir anahtar yalnızca görevi için gereken izinlere sahip olmalıdır.

Örnek:

  • Ürün kataloğu okuyan bir frontend build'i sadece salt okunur erişime ihtiyaç duyar.
  • Faturalandırma erişimine ihtiyaç duymaz.
  • Yazma erişimine ihtiyaç duymaz.
  • Yönetici yetkisine kesinlikle ihtiyaç duymaz.

Kötü model:

token: full_admin_access
usage: read product catalog
Enter fullscreen mode Exit fullscreen mode

Daha iyi model:

token: read_only_products
usage: read product catalog
Enter fullscreen mode Exit fullscreen mode

Çoğu API sağlayıcısı kapsamlı anahtarları veya ince taneli token'ları destekler. Token yaklaşımını değerlendiriyorsanız API anahtarı ve OAuth karşılaştırması, kısa ömürlü OAuth token'larının statik anahtarlara göre ne zaman daha iyi olduğunu açıklar.

Ömrü kısaltın

Bir saat içinde sona eren token, saldırgan için zayıf bir hedeftir. Sonsuza kadar yaşayan statik anahtar ise biri fark edene kadar çalışır.

Tercih sırası:

  1. Talep üzerine üretilen kısa ömürlü token.
  2. Sınırlı süreli statik anahtar.
  3. Uzun ömürlü anahtar, yalnızca zorunluysa.

Eğer uzun ömürlü anahtar kullanmanız gerekiyorsa:

  • Kapsamını daraltın.
  • Ortama bağlayın.
  • Düzenli döndürün.
  • Kullanımını loglayın.
  • Anormal erişim için alarm kurun.

4. Panikte değil, programa göre döndürün

Döndürme, bir kimlik bilgisinin değerini değiştirip eski değeri geçersiz kılmaktır.

Çoğu ekip bunu yalnızca ihlalden sonra yapar. Bu kötü bir zamandır çünkü:

  • Süreç belgelenmemiş olabilir.
  • Hangi servisin hangi anahtarı kullandığı bilinmeyebilir.
  • Güncelleme sırası net olmayabilir.
  • Kesinti riski artar.

Bunun yerine takvim oluşturun.

Örnek başlangıç planı:

Kimlik bilgisi türü Önerilen döndürme sıklığı
Yüksek ayrıcalıklı üretim anahtarları Aylık
Düşük riskli servis anahtarları Üç aylık
Geliştirme/sandbox anahtarları Üç aylık veya ihtiyaç oldukça
Olayda ifşa olduğundan şüphelenilen tüm anahtarlar Hemen

Basit döndürme akışı:

  1. Yeni anahtarı oluşturun.
  2. Tüketen servislerde yeni anahtarı tanımlayın.
  3. Servislerin yeni anahtarla çalıştığını doğrulayın.
  4. Eski anahtarı devre dışı bırakın.
  5. Loglarda eski anahtarla deneme olup olmadığını izleyin.
  6. Envanteri güncelleyin.

Daha kapsamlı araç seçenekleri için API anahtarı yönetimi araçları rehberine bakabilirsiniz.

Kimlik bilgilerini çalışma alanında dağınık tutmak yerine Apidog ortam değişkenlerini kullanın

Burada dürüst çerçeve şu: Apidog kendi VS Code uzantısını ve MCP sunucusunu sunar. Bu yazının iddiası “bu araç tedarik zinciri saldırılarına karşı bağışıktır” değildir. Hiçbir istemci tarafı araç bağışık değildir.

Önemli soru şudur:

Sırlarınız nerede yaşıyor ve makinenizdeki bir araç kötüye giderse ne kadar kolay okunabiliyor?

Günlük API geliştirme akışında genellikle şunlara ihtiyaç duyarsınız:

  • Bearer token
  • API anahtarı
  • Veritabanı bağlantı dizesi
  • Ortama özel base URL
  • Test kullanıcı bilgileri

Varsayılan yaklaşım bunları .env dosyasına, betiğe veya not dosyasına yazmaktır. Bu da canlı kimlik bilgilerini çalışma alanındaki düz metin dosyalarına koyar.

Apidog'un ortam sistemi bu yüzeyi azaltmaya yardımcı olur.

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

Apidog'da kimlik bilgilerini deponuzdaki metin dosyalarında değil, ortam değişkenleri olarak saklayabilirsiniz.

Örnek istek başlığı:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Burada istek tanımı gerçek token'ı içermez:

Authorization: Bearer sk-proj-aB3dEf...
Enter fullscreen mode Exit fullscreen mode

Bunun yerine değişken adı kullanılır:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Pratik fayda:

  • İstek koleksiyonunda gerçek sır görünmez.
  • Değişken adı paylaşılabilir.
  • Gerçek değer ortam düzeyinde yönetilir.
  • Sır, proje kökündeki .env dosyasında beklemez.

Bu, .env yaklaşımındaki “kodu sırdan ayırma” fikrini bir adım ileri taşır: sır artık kaynak kodun yanında duran düz metin satırı değildir.

Yerel değerler sırları makinenizde tutar

Apidog değişkenleri için iki değer tipi arasında ayrım yapar:

  • Paylaşılan veya başlangıç değeri
  • Yerel veya güncel değer

Paylaşılan değer ekip ve proje ile senkronize olabilir. Yerel değer ise makinenizde kalır ve yüklenmez.

Hassas veriler için doğru yer yerel değerdir:

access_token = <yalnızca yerel değer>
db_password  = <yalnızca yerel değer>
api_key      = <yalnızca yerel değer>
Enter fullscreen mode Exit fullscreen mode

Bunun etkisi:

  • Ekip arkadaşı değişken adını görür.
  • Gerçek sırrınızı görmez.
  • Her geliştirici kendi yerel değerini girer.
  • Canlı token senkronize proje verisinde taşınmaz.
  • Paylaşılan dosyada gerçek anahtar listesi oluşmaz.

Bu model, özellikle API koleksiyonlarını ekiple paylaşırken önemlidir. Paylaşmanız gereken şey istek yapısıdır; canlı sırlar değildir.

Ortam yönetimi ile geliştirme, hazırlık ve üretimi ayırın

Apidog'un ortam yönetimi yaklaşımı, anahtarları ortama göre kapsamlamayı kolaylaştırır.

Örneğin üç ortam tanımlayabilirsiniz:

  • Geliştirme
  • Hazırlık
  • Üretim

Her ortamın kendi değerleri olur:

Değişken Geliştirme Hazırlık Üretim
base_url https://dev-api.example.com https://staging-api.example.com https://api.example.com
payment_api_key Sandbox anahtarı Test modu anahtarı Üretim anahtarı
access_token Yerel dev token Yerel staging token Gerekirse sınırlı üretim token

İstek içinde aynı değişken adı kalır:

POST {{base_url}}/payments
Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Değişen şey aktif ortamdır.

Bu yaklaşımın faydaları:

  • İstekleri üretim için elle düzenlemeniz gerekmez.
  • Ortam değiştiğinde tüm değer seti birlikte değişir.
  • Geliştirme anahtarı yanlışlıkla üretim çağrısında kullanılmaz.
  • Üretim sırrının yerel geliştirme ortamında bulunması gerekmez.
  • Sızan geliştirme ortamı sadece geliştirme değerlerini ifşa eder.

Daha katı sınır isteyen ekipler için kasa sırları

Bazı ekipler üretim sırlarının API istemcisine bile yazılmasını istemez. Bu durumda Apidog Enterprise planındaki Kasa Sırrı özelliği, sırları doğrudan şu sistemlerden alabilir:

  • HashiCorp Vault
  • Azure Key Vault
  • AWS Secrets Manager

Bu modelde Apidog gerçek sır değerini proje verisi olarak paylaşmak yerine kasa yolu ve meta verilerle çalışır. Gerçek değerler talep üzerine alınır, yerel istemcide şifrelenir ve ekip arkadaşlarıyla proje üzerinden paylaşılmaz.

Üretim kimlik bilgileri için doğru yer genellikle özel sır yöneticisidir. API istemcisi bu sırların kalıcı evi olmamalıdır.

Uygulanabilir Apidog akışı

API kimlik bilgilerinizi düz metin dosyalarından çıkarmak için basit bir başlangıç akışı:

  1. Apidog'u indirin.
  2. Bir proje oluşturun.
  3. Ortam Yönetimi'ni açın.
  4. Development, Staging, Production ortamlarını tanımlayın.
  5. base_url, access_token, api_key gibi değişkenler oluşturun.
  6. Hassas değerleri yalnızca yerel değer olarak girin.
  7. İsteklerde gerçek değer yerine {{variable_name}} kullanın.
  8. Eski .env veya test betiklerindeki canlı sırları kaldırın.
  9. Eğer bu sırlar daha önce commit edildiyse döndürün.

Önemli uyarı: Sırları Apidog'a taşımak makinenizi tehlikeye girmiş bir araca karşı bağışık hale getirmez. Sadece deponuzda ve çalışma alanınızda bulunan düz metin kimlik bilgilerinin sayısını azaltır.

Derinlemesine savunma hâlâ gerekir:

  • Yüklediğiniz uzantıları denetleyin.
  • Gereksiz uzantıları kaldırın.
  • Üretim anahtarlarını en az ayrıcalıklı tutun.
  • Kısa ömürlü token'ları tercih edin.
  • Anahtarları düzenli olarak döndürün.
  • Sırları Git geçmişinde tarayın.

Sonuç

GitHub ihlali açık bir sinyal veriyor: saldırganlar, geliştirici makinesinin güvenilir araçlar, yerel dosyalar ve düz metin yapılandırmalar nedeniyle yumuşak bir hedef olduğunu biliyor.

Bu makineyi tamamen güvenli hale getiremezsiniz. Ancak tehlikeye girmiş bir IDE uzantısının veya sızdırılmış bir deponun saldırgana çok az şey vermesini sağlayabilirsiniz.

Bugün uygulanabilecek kısa denetim:

# Çalışma dizininde sır benzeri değerleri ara
grep -RniE "api_key|apikey|secret|token|password|access_key" . \
  --exclude-dir=.git \
  --exclude-dir=node_modules
Enter fullscreen mode Exit fullscreen mode

Git geçmişinde .env var mı kontrol edin:

git log --all --full-history --oneline -- .env
Enter fullscreen mode Exit fullscreen mode

Sır bulursanız şu sırayla ilerleyin:

  1. İfşa olmuş kabul edin.
  2. Anahtarı döndürün.
  3. Eski değerin çalışmadığını doğrulayın.
  4. Git geçmişini temizleyin.
  5. Canlı değeri düz metin dosyasından çıkarın.
  6. Ortama kapsamlı, en az ayrıcalıklı ve kısa ömürlü yeni kimlik bilgisi kullanın.

Bir sonraki API kimlik bilgisi setiniz için Apidog'u indirin ve değerleri düz metin dosyaları yerine ortam değişkenleriyle yönetin.

Daha geniş bağlam için şu yazılar da iyi devam kaynaklarıdır:

Sıkça Sorulan Sorular

Bir VS Code uzantısı gerçekten .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, yapılandırma dosyaları veya ~/.aws/credentials gibi kimlik bilgisi dosyalarını okuyabilir. Bu, birçok uzantı için normal çalışma modelidir. Risk, kötü niyetli veya ele geçirilmiş bir uzantının aynı erişimi sır toplamak için kullanmasıdır.

.env dosyasını .gitignore içine eklemek yeterli mi?

Hayır. .gitignore yalnızca Git'e git add sırasında izlenmeyen dosyaları atlamasını söyler. Dosya daha önce commit edildiyse sır Git geçmişinde kalır. Ayrıca .env diskte düz metin olarak durmaya devam eder ve yerel araçlar tarafından okunabilir. .gitignore hata önleme aracıdır, güvenlik sınırı değildir.

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

Repo özel olsa bile anahtarı ifşa olmuş kabul edin. Önce anahtarı döndürün. Ardından git filter-repo gibi bir araçla geçmişi temizleyin ve ekiple koordineli şekilde temizlenmiş geçmişi gönderin. Son olarak canlı kimlik bilgisini düz metin dosyalarından çıkarın. Devam eden uygulamalar için API anahtarı yönetimi araçları rehberine bakabilirsiniz.

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

Apidog, kimlik bilgilerini ortam değişkenleri olarak saklamanıza ve isteklerde adlarıyla referans vermenize olanak tanır. Böylece gerçek sır, deponuzda düz metin .env dosyası olarak durmaz. Yerel değerler makinenizde kalır ve sunuculara veya ekip arkadaşlarına senkronize edilmez. Ortama kapsamlı değişkenler de geliştirme ve üretim kimlik bilgilerini ayrı tutar.

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

Evet, Apidog bir VS Code uzantısı ve MCP sunucusu sunar. Bu, herhangi bir istemci tarafı aracın tedarik zinciri saldırılarına karşı bağışık olduğu anlamına gelmez. Asıl nokta, sırlarınızın nerede yaşadığıdır. Kimlik bilgilerini yalnızca yerel değerlere sahip ortam değişkenlerinde veya kasa entegrasyonunda tutmak, makinedeki herhangi bir araç tehlikeye girerse açığa çıkabilecek düz metin sır sayısını azaltır.

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

Kapsam belirleme, anahtarın ne yapabileceğini ve nerede geçerli olduğunu sınırlar. Örneğin bir geliştirme anahtarı yalnızca sandbox ortamına erişebilir ve salt okunur token yazma işlemi yapamaz. Döndürme ise anahtarın değerini değiştirerek eski değeri geçersiz kılar. Kapsam belirleme zararı azaltır; döndürme sızan anahtarın işe yarar kalma süresini kısaltır.

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

Sadece olaydan sonra değil, düzenli takvimle döndürün. Makul bir başlangıç noktası, yüksek ayrıcalıklı üretim kimlik bilgileri için aylık, düşük riskli anahtarlar için üç aylık döndürmedir. Bu aralıkları risk toleransınıza, uyumluluk gereksinimlerinize ve operasyonel kapasitenize göre ayarlayın.

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

İdeal olarak hayır. Üretim kimlik bilgisi mümkün olduğunca az yerde bulunmalıdır: özel bir sır yöneticisi ve üretim çalışma zamanı gibi. Geliştiriciler geliştirme veya hazırlık ortamına kapsamlanmış kimlik bilgileriyle çalışmalıdır. Bir dizüstü bilgisayar tehlikeye girerse saldırgan canlı müşteri sistemlerine değil, izole edilmiş bir test ortamına erişebilmelidir.

Top comments (0)