API Key Güvenliği: “Trade Only” ile Güvenli Bağlantı Kurmak, “Withdraw” Yetkisini Doğru Yönetmek ve İptal Etmek

Kripto borsasına bot, TradingView sinyali veya 3Commas benzeri bir araç bağladığınız an, hesabınızın güvenliği “şifre + 2FA” seviyesinden çıkar ve “izin yönetimi + anahtar yönetimi” seviyesine taşınır. API key bu köprünün kendisidir: doğru kurulduğunda hızlı ve pratik bir otomasyon sağlar; yanlış kurulduğunda ise yetki fazlası nedeniyle zarar büyütme potansiyeli yaratır. Bu yazıda, “trade only” yetkisiyle güvenli bağlantı kurmanın mantığını, “withdraw” yetkisinin neden çoğu kullanıcı için gereksiz ve riskli olduğunu, anahtarların nerede/nasıl saklanacağını, hangi kontrollerin düzenli yapılacağını ve bir şüphe durumunda nasıl hızlıca iptal edileceğini adım adım ele alacağız.

Hedefimiz basit: aktif al-sat yapan trader’lar ve bot kullanıcıları için pratik, uygulanabilir ve “yatırım tavsiyesi”ne kaymayan bir güvenlik çerçevesi kurmak. Okurken “benim için hangisi gerekli?”, “hangi izin fazla?”, “IP whitelist gerçekten işe yarıyor mu?”, “API key ele geçirilirse ne olur?” ve “iptal etme/silme nereden yapılır?” gibi soruların net cevaplarını bulacaksınız. Ayrıca karar matrisi, senaryolar, mitos-gerçek kontrolü, mini sözlük, hata avcısı ve kontrol listesi ile işi bir kerelik okumadan çıkarıp sürdürülebilir rutine dönüştüreceğiz.

API Key Nedir? Key/Secret Mantığı ve İzin Katmanları

API key, borsadaki hesabınızın belirli fonksiyonlarına programatik erişim sağlayan kimlik bilgisidir. Çoğu borsa iki parçalı bir yapıyla çalışır: “API Key” (kimlik/ID) ve “Secret” (imza/parola gibi). Key genellikle “kimin eriştiğini” söyler; secret ise “bu isteğin gerçekten sana ait olduğunu” kanıtlayan imza üretmek için kullanılır. Bu yüzden secret, çoğu senaryoda tek başına ele geçirilse bile çok değerlidir; key ile birlikte ele geçirilirse risk çarpan etkisi gösterir. Birçok ele geçirilme hikâyesinde asıl problem, secret’ın düz metin olarak bir not uygulamasında durması, ekran görüntüsüne girmesi ya da bir ekip sohbetinde paylaşılmasıdır.

API key’in tehlikeli veya güvenli olmasını belirleyen şey “izin katmanları”dır. Borsalar genelde üç ana kategori sunar: read only (bakiye/işlem geçmişi okuma), trade (emir gönderme/iptal), withdraw (para çekme). Bazı platformlarda “futures/spot ayrı izin”, “sub-account erişimi”, “transfer” (ana hesap-alt hesap iç transferi) gibi ek kırılımlar da vardır. Güvenlik mantığı şudur: bir araç sadece fiyat okuyor ve sinyal üretiyorsa “read only” yetmelidir; bir bot emir girecekse “trade only” gerekir; “withdraw” ise çok özel durumlar dışında açılmamalıdır. Çünkü en kötü senaryoda “trade only” ile zarar genelde piyasada kötü işlem açma veya pozisyonu bozma ile sınırlanırken, “withdraw” ile hesabın boşaltılmasına kadar giden bir zincir mümkün hale gelir.

“Trade Only” vs “Withdraw”: Yetkiler Pratikte Ne Anlama Geliyor?

İzinleri “buton” gibi düşünmek yerine “kilit” gibi düşünmek daha doğru: her izin, saldırganın eline geçen bir anahtarın açabildiği kapı sayısını artırır. “Trade only” bir saldırgana genelde şu alanları açar: spotta agresif piyasa emirleriyle kötü fiyatlardan alım-satım yaptırma, küçük likiditeli çiftlerde kaydırma (slippage) yaratma, açık pozisyonları kapatma/bozma, emir iptaliyle stratejiyi sabote etme. Bu senaryolarda zarar hâlâ mümkündür; ancak saldırganın parayı “doğrudan dışarı çıkarma” yetkisi yoksa, zarar çoğu zaman borsa içi fiyat hareketleri ve komisyonlar üzerinden oluşur. Büyük portföy sahipleri için bile bu, “sigorta yapılabilir” ve “erken tespit edilebilir” bir risk sınıfına girer.

“Withdraw” yetkisi ise risk profilini bambaşka bir seviyeye taşır: saldırgan, borsadaki varlıkları dış cüzdanlara çekmeyi deneyebilir. Burada borsaların güvenlik katmanları devreye girer (çekim beyaz listesi, 24–48 saatlik kilitler, ek doğrulamalar gibi), fakat buna güvenerek hareket etmek yanlış bir psikoloji yaratır. Çünkü pratikte birçok kullanıcı çekim whitelist’ini kapalı tutar, bazıları “hızlı olsun” diye güvenlik adımlarını gevşetir, ekip hesaplarında ise süreçler net değilse çekim akışı daha da karmaşıklaşır. Kısacası “trade only” ile hasar genelde borsanın içinde kalır; “withdraw” ile hedef, varlığın borsadan çıkması olur. Bu nedenle üçüncü parti araç bağlantılarında varsayılan tercih “withdraw kapalı” olmalıdır.

Bir kontrol yöntemi: Bağlamak istediğiniz uygulama sizden “withdraw” istiyorsa, kendinize şu soruyu sorun: “Bu uygulama benim yerime dış cüzdana transfer mi yapacak?” Eğer cevap net değilse veya “hayır”a yakınsa, o izni açmayın. Bir başka pratik test: Uygulamanın kullanım senaryosunu 2 cümlede özetleyin. Eğer bu özet içinde “çekim” fiili geçmiyorsa, “withdraw” izni gereksizdir. Bu kadar basit bir filtre bile, yanlışlıkla açılan yetkilerin büyük kısmını eler.

“Withdraw” Yetkisi Açık Kalırsa Ne Olur? Gerçekçi Saldırı Zincirleri

API key sızıntısı çoğu zaman “sofistike hack” değil, basit bir hijyen hatasıyla başlar. Örnek zincir: kullanıcı botu VPS üzerinde çalıştırır, sunucudaki .env dosyasını yanlışlıkla public bir repo’ya iter, secret görünür olur. Veya ekran paylaşımında API ayarları sayfası açık kalır, key/secret kısmen görünür olur. Bir başka yaygın durum: üçüncü parti uygulama, “bağlantı testi” sırasında kullanıcıyı kendi paneline yönlendirir ve kullanıcı secret’ı doğrudan tarayıcı formuna yapıştırır; bilgisayarda clipboard geçmişi açıksa bu değer daha sonra farklı yazılımlarca yakalanabilir. Bu hatalar tek başına bile can sıkıcıdır; “withdraw” açık olduğunda zincir çok daha yıkıcı bir yere evrilebilir.

Gerçekçi bir saldırgan davranışı şöyle ilerleyebilir: önce hesabın varlık dağılımını okur (read izni varsa), ardından “trade” ile varlıkları daha kolay çekilebilir bir coine dönüştürmeye çalışır (ör. düşük ağ ücretli bir coin veya hızlı transfer edilen bir varlık). Sonra “withdraw” ile çekim başlatır. Bu noktada borsanın güvenlik önlemleri devreye girebilir: çekim whitelist açıksa saldırganın adresi ekleyememesi gibi; fakat bazı platformlarda whitelist kapalıysa veya kullanıcı daha önce farklı nedenlerle whitelist’i gevşetmişse çekim denemeleri sonuç verebilir. Ayrıca saldırgan, dikkat çekmemek için tek seferde değil, 3–5 parçaya bölerek çekim denemesi yapabilir. Bu da bildirimleri “gürültü” gibi gösterip fark edilmesini geciktirir.

Minimum İzin Prensibi: Read Only, Trade Only ve Güvenli Varsayılanlar

Minimum izin prensibi, basit bir soruya dayanır: “Bu entegrasyonun işi ne?” Cevap “sinyal üretmek, grafik okumak, performans raporlamak” ise read only yeterlidir. Cevap “emir göndermek ve yönetmek” ise trade only gerekir. Burada kritik detay: trade only seçseniz bile bazı borsalarda “transfer” gibi ek izinlerin açık kalabildiğini görebilirsiniz; bu yüzden API key oluştururken izin ekranını madde madde kontrol etmek gerekir. Güvenlik kontrolü için iyi bir pratik, izinleri açmadan önce bir kâğıda (veya güvenli not alanına) “bu bot hangi API endpoint’lerine ihtiyaç duyar?” diye yazmaktır. Endpoints’i tek tek bilmek zorunda değilsiniz; ama “bakiye okuma + emir gönderme + emir iptali” gibi işlevleri netleştirmek bile yeterli olur.

“Withdraw” yetkisini ne zaman düşünmeli? Çok sınırlı durumlarda: otomatik soğuk cüzdan stratejisi, kurumsal treasury akışı, borsa-OTC operasyonları gibi. Bireysel trader veya standart bot kullanıcıları için “withdraw” genelde gereksizdir. Ayrıca çekim işlemi bir “finansal operasyon” olduğu için, tek kişinin anahtarıyla otomatik çalışması riskli bir yönetim modelidir. Ekip ortamında çekim gerekiyorsa, iki kişili onay, çekim adresi whitelist’i, zaman kilidi (ör. 24 saat) ve ayrı bir anahtar politikası düşünülmelidir. Tek anahtarla hem trade hem withdraw işinin birleşmesi, saldırıda tek nokta kırılganlığı yaratır.

Güvenli varsayılanlar listesi: (1) “Withdraw” kapalı, (2) mümkünse “IP whitelist” açık, (3) yalnızca gerekli piyasa (spot/futures) izinleri açık, (4) anahtar adı/etiketi net, (5) oluşturma sonrası secret tek seferlik saklanır ve bir daha çıplak halde dolaşmaz. Bu beşli, teknik bilgisi sınırlı kullanıcılar için bile “kazaen açık izin” riskini ciddi ölçüde aşağı çeker.

IP Whitelist ve Erişim Kısıtları: “Kilidi Nereye Takıyorsun?”

IP whitelist, API key’inizi “belirli bir cihaz/konum” ile eşleştirmek gibi çalışır: anahtar doğru olsa bile, borsa yalnızca izin verdiğiniz IP’den gelen istekleri kabul eder. Bu, özellikle VPS üzerinde çalışan botlar için güçlü bir katmandır; çünkü saldırgan secret’ı ele geçirse bile, farklı bir IP’den emir gönderemez. Ancak IP whitelist “tak-çalıştır” değildir: dinamik IP kullanan ev internetinde IP sık değişir; VPN/proxy ile çalışan bir botun IP’si sabit değilse bağlantı sürekli kopar; bulut servislerinde bile yanlış instance’a kilitlemek mümkündür. Pratik öneri: Botu sabit IP’ye sahip bir VPS/bulut sunucuda çalıştırın ve whitelist’i sadece o IP’ye bağlayın. Tek bir IP ile başlamak, hata yüzeyini küçültür.

Bir diğer kısıtlama, borsanın sunduğu “API erişim kısıtları”dır: bazı platformlar “yalnızca belirli endpoint’lere izin”, “yalnızca spot”, “yalnızca futures” gibi seçenekler verir. Bu seçenekler varsa, trade botu spotta çalışıyorsa futures’ı kapatmak mantıklıdır. Çünkü saldırganın “strateji dışı ürün” kullanarak zarar üretme kapasitesi kısıtlanır. Örneğin kaldıraçlı ürünlere erişim kapalıysa, trade only bile olsa zarar senaryosunun şiddeti düşebilir. Burada amaç, saldırganın hareket alanını “tek kulvar”a sıkıştırmaktır.

Yanlış güven hissi yaratan iki tuzak var: Birincisi, whitelist’i “0.0.0.0/0” gibi geniş bir aralıkla açmak veya “her yerden erişim”i açık bırakmak. İkincisi, whitelist’i açtığını sanıp uygulamada yanlış IP’yi yazmak. Bu yüzden her yeni API key’den sonra küçük bir test yapın: bota bağlı sunucudan basit bir “bakiye oku” testi çalıştırın; sonra farklı bir ağdan (telefon hotspot gibi) aynı isteği denediğinizde borsanın reddettiğini görün. Bu iki aşamalı test, whitelist’in gerçekten devrede olduğuna dair hızlı bir kanıttır.

Bot/TradingView/3Commas Bağlantısı: Güvenli Kurulum Akışı

Üçüncü parti bir araca borsa hesabı bağlarken asıl hata “hızlı geçmek”tir. Güvenli kurulum akışını 7 adımda standartlaştırın: (1) Uygulamayı bağlamadan önce borsada yeni bir API key oluşturun, (2) anahtarı sadece o uygulama için kullanın (paylaştırmayın), (3) izinleri read/trade ile sınırlayın ve withdraw’ı kapalı tutun, (4) IP whitelist varsa uygulamanın kullandığı IP’leri netleştirin (VPS ise tek IP), (5) API key’e anlamlı bir isim verin (ör. “spot_bot_A_vps1_2026-01”), (6) uygulamada bağlantıyı test edin, (7) test sonrası borsanın API yönetim ekranında “son kullanım” veya “log” kayıtlarını kontrol edin. Bu akış, “bir anahtarı her yere takma” alışkanlığını kırar.

TradingView gibi sinyal tarafında çalışan sistemlerde ayrı bir ayrım var: TradingView doğrudan borsaya emir göndermez; genelde webhook üzerinden sizin botunuza sinyal gönderir. Bu durumda borsaya bağlanan taraf botunuzdur; yani API key’i TradingView’a değil, botun çalıştığı sunucuya koyarsınız. Burada güvenlik sorusu değişir: “API key’i hangi sunucuda saklıyorum?” Eğer botunuzu ev bilgisayarında çalıştırıyorsanız, zararlı yazılım riskini ciddiye almak gerekir. Basit bir ölçüt: botun çalıştığı cihazda “günlük kullanım” (oyun, crack, rastgele indirme) varsa, aynı cihazda API secret tutmak risklidir. Ayrı bir ortam (temiz VPS) daha sağlıklıdır.

3Commas benzeri SaaS araçlarında ise IP whitelist konusu borsaya göre zorlaşabilir; çünkü SaaS’in kullandığı IP’ler listeli olabilir veya değişebilir. Böyle bir durumda savunma katmanını izinler üzerinden kurarsınız: trade only + çekim kapalı + mümkünse “transfer” kapalı + düşük riskli limitler. Birçok bot platformu “max order size”, “max daily volume” gibi limitler sunar; bunları 2–3 katmanlı düşünün. Örneğin günlük toplam hacim limitini portföyünüzün %20–%30 bandına çekmek, bir ele geçirilme halinde hasarı sınırlandırabilir. Bu tür limitler, tek başına güvenlik değildir; ama erken fark edene kadar “sigorta” görevi görür.

API Key Saklama: Secret Yönetimi, Şifreleme ve Paylaşım Disiplini

API secret, pratikte “geri alınamaz parola” gibidir: birçok borsa secret’ı bir kez gösterir, sonra tekrar göstermez. Bu iyi bir güvenlik alışkanlığı kazandırır: secret’ı üretim anında doğru yere koy, sonra ortalıkta dolaştırma. En güvenli yaklaşım, secret’ı bir “secret manager” içinde tutmaktır; bu imkan yoksa ikinci en iyi yaklaşım, en azından şifreli bir parola yöneticisi kullanmaktır. Düz metin notlar, ekran görüntüleri, e-posta taslakları, sohbet mesajları veya Google Docs gibi paylaşıma açık dokümanlar riskli depolardır. Ayrıca ekip içinde secret paylaşımı “kimin eriştiği belli değil” problemine dönüşür; sonra bir olay olduğunda geri izlemek zorlaşır.

Botu kendi sunucunuzda çalıştırıyorsanız, secret’ı kodun içine gömmeyin. Kodu bir arkadaşınızla paylaştığınızda, repo yedeğinde veya log çıktısında secret görünür hale gelebilir. Daha güvenli yöntem: environment variable (ör. sunucuda .env) kullanmak ve bu dosyayı erişim izinleriyle kısıtlamak. Ek bir katman olarak .env dosyasını disk üzerinde şifreli tutmak (en azından OS seviyesinde kullanıcı izinleriyle) mantıklıdır. Bir başka pratik, secret’ın kendisini değil, secret’a erişim iznini korumaktır: sunucuya giriş 2FA/SSH anahtar ile, panel erişimi ise ayrı hesaplarla yapılmalıdır.

Paylaşım disiplini için “tek yön” kuralı koyun: Secret yalnızca borsadan sizin güvenli kasanıza gider; kasa dışına çıkmaz. Eğer bir ekip üyesi erişim istiyorsa, “aynı secret’ı paylaşmak” yerine “yeni bir API key üretmek ve izinleri sınırlamak” daha iyi bir pratiktir. Bu sayede kişi ayrıldığında veya görev değiştiğinde tek anahtarı iptal edersiniz; diğer sistemler etkilenmez. Bu mantık, hem bireysel hem kurumsal kullanımda düzen sağlar.

Anahtar Yaşam Döngüsü: İsimlendirme, Envanter ve 90 Günlük Rotasyon

Bir API key oluşturduktan sonra asıl güvenlik işi başlar: “unutulmaması” gerekir. En sık görülen sorun, aylar önce oluşturulmuş ve artık kullanılmayan bir anahtarın hâlâ aktif kalmasıdır. Bunun çözümü envanter tutmaktır. Basit bir tablo bile yeterli: anahtar adı, hangi uygulamaya ait, hangi izinler açık, hangi IP’lere whitelist’li, oluşturma tarihi, son kullanım tarihi, sorumlu kişi, planlanan iptal tarihi. Bu envanter, “kayıp anahtar” problemini ortadan kaldırır. Ayrıca anahtar adlandırmasını standartlaştırmak, borsa panelinde hızlı karar aldırır: “bot_adı_ortam(Prod/Test)_ürün(Spot/Futures)_tarih” gibi.

Rotasyon (anahtar değiştirme) güvenlikte sigorta gibidir: sızıntı “olursa” değil “ne zaman” perspektifiyle düşünülür. Birçok ekip 60–90 gün arası rotasyon uygular; bireysel kullanıcılar için 90 gün iyi bir başlangıç olabilir. Rotasyonun amacı sadece “yeni anahtar üretmek” değil, eski anahtarı güvenle devre dışı bırakmaktır. Rotasyon akışı: yeni anahtarı üret, izinleri minimal ayarla, botu yeni anahtarla çalıştır, test et, logları kontrol et, eski anahtarı iptal et. Bu akışı 30 dakikalık bir bakım görevi gibi düşünün; takvimde aylık/çeyreklik bir blok yapmak, ertelemeyi azaltır.

Unutulmaması gereken bir detay: aynı anda 2 anahtarın aktif olduğu “geçiş penceresi”ni kısa tutun. Örneğin 24 saat içinde yeni anahtara geçişi tamamlamak ve eskiyi kapatmak, saldırı yüzeyini büyütmemek açısından faydalıdır. Geçiş süresi uzadıkça, “hangisi kullanılıyor?” belirsizliği artar. Belirsizlik, güvenliğin düşmanıdır.

Loglar ve Alarmlar: Anomaliyi Erken Yakalamak İçin 7 Sinyal

API key güvenliği, sadece “kapıyı kilitlemek” değil “kapının zorlandığını anlamak”tır. Bu yüzden loglar ve alarmlar kritik. Birçok borsa API yönetim ekranında “son kullanım”, “istek sayısı”, “IP”, “hata kodları” gibi bilgiler sunar. Burada hedef, normal davranışın sınırlarını tanımlamaktır. Örneğin botunuz dakikada 5–10 istek atıyorsa, bir anda dakikada 60+ istek görmeniz anormal olabilir. Benzer şekilde, IP whitelist olmasına rağmen farklı IP denemeleri görüyorsanız, birileri key/secret ile deneme yapıyor olabilir. Bu sinyalleri görmek için her gün saatlerce bakmanız gerekmez; haftada 2 kez 3 dakikalık kontrol bile fark yaratır.

Takip edilecek 7 sinyal: (1) yeni IP’den deneme, (2) ardışık “signature invalid” hataları (secret yanlış kullanılıyor olabilir), (3) alışılmadık emir tipi (ör. hep limit kullanırken market yağmuru), (4) alışılmadık sembol/market (hep spot kullanırken futures denemesi), (5) aniden artan iptal emirleri (strateji sabote ediliyor olabilir), (6) gece saatlerinde beklenmedik aktivite (sizin uyku saatlerinizde), (7) API key ayarlarında değişiklik (izin eklenmesi gibi). Bu sinyallerden ikisi bile bir aradaysa, “hemen kontrol” moduna geçmek mantıklıdır.

Bildirim tarafında pratik bir yaklaşım: borsanın güvenlik bildirimlerini (e-posta/SMS/app push) açın ve “çekim girişimleri”, “yeni cihaz girişi”, “API key değişikliği” gibi başlıkları özellikle izleyin. Burada amaç, 24 saat sonra fark etmek değil, 5–15 dakika içinde fark etmektir. Erken fark edilen olaylar çoğu zaman “iptal + izolasyon” ile hasarsız kapanır.

Ekip/Kurumsal Hesaplarda Yetki Yönetimi: Rol Ayrımı ve Alt Hesaplar

Kurumsal veya ekip hesaplarında API key yönetimi, bireysel hesaptan daha zor; çünkü “kim neye erişiyor?” sorusu her an canlıdır. İlk kural: görev ayrımı. Emir gönderen botun anahtarı “trade only” olmalı; raporlama panelinin anahtarı “read only” olmalı; çekim/treasury işleri ise mümkünse API ile otomatikleştirilmemeli veya ayrı bir süreçle (onay + whitelist + zaman kilidi) yönetilmelidir. Tek kişinin hem trade hem çekim hem de anahtar yönetimini yapması, denetimsiz bir güç yoğunlaşmasıdır. Bu durum sadece saldırı riskini değil, iç operasyon hatası riskini de artırır.

Alt hesap (sub-account) mantığı çok işe yarar: Her strateji veya bot için ayrı alt hesap oluşturup, API key’leri o alt hesaplara bağlamak, hasarı doğal olarak sınırlar. Örneğin “grid bot” alt hesabında sadece o strateji için ayrılmış bir miktar bulundurmak, ele geçirilmede tüm portföyün etkilenmesini engeller. Bu yaklaşım, “her şeyi tek sepette tutma” hatasını düzeltir. Ayrıca alt hesaplar, risk yönetiminde netlik sağlar: bir alt hesapta günlük maksimum kaybı (ör. %2–%5 bandı) mental olarak bile sınırlandırabilirsiniz.

Ekipteki bir diğer kritik nokta, anahtar envanterinin “tek kişide” olmamasıdır. Envanterin kendisi de hassastır; ama hangi anahtarın nerede kullanıldığını bilmemek daha da büyük risktir. Pratik çözüm: envanteri erişimi kısıtlı bir yerde tutun ve sorumluluk atayın. Bir kişi anahtar üretir, başka biri (en azından) izinleri ve withdraw kapalı olduğunu kontrol eder. Bu “iki göz kuralı”, birçok kazayı daha oluşmadan engeller.

Şüphe Anı: 15 Dakikalık Acil Durum Planı (İptal + İzolasyon)

“Bir şeyler ters gidiyor” hissi geldiğinde zaman kritik. İyi haber: çoğu olayda ilk 15 dakika doğru yönetilirse hasar çok düşer. Acil planın ilk adımı, panik değil sıralı hareket: (1) Bot/uygulamayı durdurun (sunucuyu kapatmak yerine önce uygulamayı durdurmak genelde daha kontrollüdür), (2) borsanın API yönetim ekranına girin ve şüpheli anahtarı hemen devre dışı bırakın/iptal edin, (3) hesap parolasını değiştirin, (4) 2FA’yı kontrol edin (mümkünse yeniden kurulum), (5) açık emirleri ve açık pozisyonları kontrol edin, (6) çekim geçmişi ve bekleyen çekim taleplerine bakın, (7) güvenlik bildirimlerini tarayın. Burada en büyük farkı, anahtarı hızlı iptal etmek yaratır.

İkinci katman “izolasyon ve kanıt”tır: Sızıntının nereden olabileceğini anlamadan tekrar aynı hatayı yapmak kolaydır. Bot sunucusunda son değişiklikleri gözden geçirin, erişim loglarına bakın, son günlerde hangi dosyaların paylaşıldığını kontrol edin. Eğer secret’ın bir yerde düz metin olarak bulunma ihtimali varsa, o yeri temizlemek tek başına yetmez; ilgili anahtarı iptal edip yenisini üretmek gerekir. Birçok kullanıcı “secret’ı sildim, bitti” diye düşünür; oysa secret bir kez kopyalandıysa, siz silseniz de başka bir yerde kalmış olabilir.

Son katman “hasar sınırlama”dır: Eğer trade only bile olsa saldırgan pozisyonları bozmuş olabilir. Bu noktada aceleyle daha fazla işlem yapmak yerine, önce hesabın durumunu netleştirin: bakiyeler, açık emirler, son işlemler. Gerekirse borsanın destek kanallarını devreye alın ve hesabın güvenlik incelemesini talep edin. Bu adımlar yatırım kararı değildir; sadece güvenlik olayına tepki yönetimidir.

API Key Nasıl Kapatılır/İptal Edilir/Silinir? Adım Adım ve Sonrası

Borsalar arası arayüz farklı olsa da mantık aynıdır: hesap ayarları içinde “API Management / API Keys” benzeri bir sayfa bulunur. Buradan mevcut anahtarlar listelenir; genellikle her bir anahtarın adı, oluşturma tarihi, izinleri ve bazen de son kullanım bilgisi görünür. İptal etme/silme işlemi çoğu zaman tek tıklama değildir; borsalar güvenlik gereği 2FA kodu, e-posta onayı veya parola doğrulaması isteyebilir. Bu iyi bir şeydir: bir saldırgan panel erişimi olmadan sadece API anahtarıyla “anahtarı iptal edemez”, ama siz panelden hızlıca iptal edebilirsiniz. Pratik kural: “Şüpheli anahtarın iptali” için borsa hesabına erişiminiz her an hazır olmalı; e-posta ve 2FA erişimi kayıpsa, kriz uzar.

İptal işlemini yaptıktan sonra “sonrası” önemlidir. Birincisi, ilgili uygulamada/botta eski anahtarı temizleyin; aksi halde bot sürekli hata üretir ve loglar gürültülenir. İkincisi, yeni anahtar üretilecekse önce kök nedeni düşünün: sızıntı sunucudan mı oldu, paylaşım hatası mı, yanlış depolama mı? Kök neden çözülmeden yeni anahtar üretmek, kapıyı tekrar aynı şekilde aralamaktır. Üçüncüsü, envanteri güncelleyin: iptal tarihi, neden iptal edildi, yerine hangi anahtar üretildi. Bu kayıtlar, bir sonraki olayda “ne yaptım?” sorusuna 2 dakika içinde cevap verir.

Yanlışlıkla withdraw açık anahtar oluşturduysanız, en güvenli yaklaşım “düzenlemek” yerine “iptal edip yenisini üretmek”tir. Çünkü izinler bazen arayüzde değiştirilse bile siz fark etmeden bir şey açık kalabilir. Temiz bir sayfadan, trade only ve gerekirse read only ile yeni anahtar üretip IP whitelist’i doğru kurmak, zihinsel olarak da daha net bir güvenlik sağlar. Hedef, karmaşayı azaltmaktır.

Kapanış: API key güvenliği, tek bir ayar ekranından ibaret değil; izinleri doğru seçmek, anahtarı doğru saklamak, logları izlemek ve gerektiğinde hızlıca iptal edebilmekten oluşan bir sistem. “Trade only” bu sistemin temel güvenli varsayımıdır; “withdraw” ise ancak gerçekten şartsa, ayrı süreç ve ayrı anahtarla yönetilmelidir. Bugün tek bir adım atacaksanız, borsanızdaki API anahtarlarını açın, kullanılmayanları iptal edin ve aktif olanların izinlerini “minimum”a indirin.

SSS

API key ele geçirilirse param kesin gider mi?
Hayır; sonuç, anahtarın izinlerine, IP whitelist’e, borsanın güvenlik kısıtlarına ve sizin fark etme hızınıza bağlıdır. “Withdraw” kapalı ve whitelist doğruysa saldırganın hareket alanı ciddi şekilde daralır; yine de trade only ile zarar üretme ihtimali bulunduğu için log/alarmlar önemlidir.

Trade only ile de zarar verebilirler mi?
Evet. Market emirleriyle slippage yaratmak, komisyon maliyetini büyütmek, açık pozisyonları bozmak gibi yöntemlerle zarar üretilebilir. Bu yüzden limitler (max order/daily volume), anomali alarmları ve alt hesap yaklaşımı hasarı sınırlamada işe yarar.

IP whitelist şart mı?
Sabit IP’li bir VPS üzerinde bot çalıştırıyorsanız güçlü bir katmandır ve önerilir. Dinamik IP veya SaaS botlarda whitelist uygulaması zor olabilir; bu durumda minimum izin + limitler + sık log kontrolü ile denge kurulur.

API key’i iptal edince bot tamamen durur mu?
İptal edilen anahtar artık borsada çalışmaz; bot istekleri hata döndürür. Bu yüzden iptal sonrası bot konfigürasyonundan eski anahtarları temizlemek, yeni anahtara geçişi kontrollü yapmak gerekir.

Withdraw yetkisini yanlışlıkla açtım, kapatsam yeter mi?
Çoğu durumda güvenli yaklaşım iptal edip yeni, temiz bir anahtar üretmektir. Böylece izin karmaşası ortadan kalkar ve yeni anahtarı “trade only + gerekirse read only + whitelist” şablonuyla tekrar kurarsınız.

İç Linkler

• Bitcoin Nedir (2025)
• Halving
• Bitcoin Kaç TL
• Stablecoin
• Altcoin
• İngiltere Kripto Düzenlemesi 2027
• HashKey IPO
• Hot vs Cold Wallet
• Seed Phrase
• Dolandırıcılıklar Sözlüğü

© bitcoinkactl.com