Kripto ödeme altyapısı sıcak cüzdan riskini nasıl sınırlar?

Saklamalı altyapı, bakiyenizi hareket ettirebilen bir anahtar tutar. Aşağıdaki hiçbir kontrol bunu değiştirmiyor.

Kontrollerin değiştirdiği şey, o anahtarın imzalamayı kabul edeceği isteğin kaç yoldan üretilebildiği. Her biri yollardan birini kapatır, ötekileri açık bırakır. Sınırı söylenmeden anlatılan kontrol, sınırıyla birlikte anlatılandan daha az işe yarar; çünkü insanı koyacağınız yer tam olarak o sınırdır.

Türk şirketi bunun kâğıt üstündeki karşılığını iyi bilir. İmza sirküleri kimin, hangi tutara kadar, münferit mi müşterek mi imza atabileceğini yazar. Sıcak cüzdanın etrafındaki kontroller ise başka bir soruyu cevaplıyor: kimin imzalayabileceğini değil, paranın nereye gidebileceğini. Benzetmeyi buraya kadar kullanın, ötesine değil.

Anahtarın sıcak olmasının sebebi sıradan. Satıcı, sağlayıcıda kimsenin uyanık olmadığı saat diliminde gece ikide ödeme çıkışını başlatır ve transferin yine de kurulup imzalanıp yayımlanması gerekir. Soğuk saklama tam olarak bunun yokluğudur: yanında insan isteyen anahtar, çıkış talebine cevap veremez. Talep üzerine ödeme yapan herkes, adını ne koyarsa koysun sıcak cüzdan çalıştırıyor.

Yani asıl soru anahtarın çevrimiçi olup olmadığı hiç olmadı. Soru şu: anahtar isteği görmeden önce o istek nelerden sağ çıkmak zorunda?

Kayıtlardaki en büyük hırsızlıkta anahtar kırılmadı

İşlemi, imzalaması gereken kişiler imzaladı.

21 Şubat 2025 dolaylarında Bybit'ten yaklaşık 1,5 milyar dolarlık sanal varlık çıktı ve beş gün sonra FBI hırsızlığı Kuzey Kore'ye atfetti.

Hırsızlıktan bir hafta sonra Safe Ecosystem Foundation yolu kendi açıklamasında tarif etti: Bybit Safe'ine yapılan saldırı ele geçirilmiş Safe{Wallet} geliştirici makinesi üzerinden gerçekleşmiş ve sonucunda kılık değiştirmiş kötü niyetli işlem önerilmişti.

Birkaç kişi onayladı. Çoklu imza işini yaptı, yalnızca yanlış işlemde yaptı ve imza sayısı hiçbir zaman değişken değildi. Aşağıdaki her kontrole uygulanacak test de bu: istek geldiğinde zaten meşru görünüyorsa, bu kontrol ne yapar?

Yalıtılmış imzalama neyi yalıtır?

İmzalayıcıyı, satıcının ya da alıcının ulaşabildiği yüzeylerden.

Giden Paymos işlemleri genel web yolunun dışında imzalanır ve ödeme çıkışı yalnızca satıcının önceden onayladığı hedefi yazabilir.

Yalıtım, erişilebilirlik özelliğidir. Anahtarın önüne istek koyabilecek şeylerin listesini kısaltır — gerçek bir iş, ama sözcüğün çağrıştırdığından azı, çünkü geçerli imzayla ön kapıdan gelen istek hakkında hiçbir şey yapmaz.

İmzalama yetkisini bölmez de; buradaki hiçbir cümle böyle okunmamalı. Bu yönetilen saklamadır: satıcı yetkilendirir, sağlayıcı imzalama ve yayımlama yolunu işletir ve bu takasın işletmenize uyup uymadığı, aşağıdaki hiçbir kontrolü okumaya değmeden önce verilmiş saklama modeli kararıdır.

Hazine tarafının ikinci sorusu kısa cevap alıyor: Paymos bakiyesi orada dururken kimseye ödünç verilmez ve Paymos'a getiri üretmez.

İki kimlik bilgisinden hangisi para hareket ettirir?

Yalnızca biri. Üstelik ayrım belgelenmiş değil, uygulanmış.

Satıcı, ortam başına bir Ödeme ve bir Çıkış kimlik bilgisi tutar.

Ödeme anahtarının erişimi faturaları ve ödeme kanallarını kapsar; Çıkış anahtarınınki transferleri ve çıkışın doğrulama için yaptığı okumaları. İkisi birbirinin alanına uzanmaz, dolayısıyla eklentiden, logdan ya da dizüstünden sızan ödeme anahtarı çıkış oluşturamaz — kötüye kullanacağı çıkış erişimi yoktur.

Kontrol tek yerde çalışır. Her komut istek hattındaki tek bir yetkilendirme adımından geçer; adım, çağıranın erişimini işlemin istediğiyle tartar ve yetersiz kalan kimlik bilgisi orada reddedilir, işleyiciye hiç ulaşmaz.

Yol başına yazılan kapsam kontrolü ise gelecek çeyrek eklenen yolda unutulan kontroldür.

Yanına iki şart daha düşüyor. Çıkış anahtarı IP listesi taşımak zorundadır ve listesi boş olan anahtar sınırsız sayılmaz, kimlik doğrulamada reddedilir; Ödeme anahtarı ise hiç liste taşıyamaz, çünkü ödeme trafiğinin müşterilerinizin bulunduğu her yerden çağrılabilmesi gerekir.

Site ya da servis başına anahtar da çıkarılmıyor: ortam başına her türden bir etkin anahtar, toplam dört; iptal de geri alınmıyor.

Bu, broşürden çok olay müdahale planına ait: sızıntı, sızdıran entegrasyonu iptal ederek çevrelenemez, çünkü o ortamdaki bütün entegrasyonlar aynı anahtarı taşır.

Beyaz liste neyi sınırlar?

Paranın nereye gidebileceğini. Ne kadarını, kimin istediğini ve adresin hâlâ sizin olup olmadığını değil.

Mekaniği tek yerde okunacak kadar kısa:

• Listede hiçbir şey yokken hiçbir şey çıkmaz. Boş liste "kısıt yok" diye okunmaz; transferleri kapatır.
• Kayıt, adres ve ağ grubuna göre tutulur. Tek bir EVM adresini onaylamak Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche ve Plasma'yı tek hamlede kapsar; Tron, TON ve Solana kendi gruplarıdır.
• Listeye yalnızca dört grup girer. NEAR ile Sui hiçbirine girmez; oraya ödeme gelir, çıkış gitmez.
• Kayıt silinmez, iptal edilir. Kime, ne zaman ödenebildiğinin izi böylece bütün kalır.
• Tek onay bin adrese kadar taşır, CSV dosyası başına bin satır geçer ve hesap en çok beş bin etkin kayıt tutar.
• Hiçbirinin API yolu yok. Liste panelde durur; Çıkış anahtarı hedefi doğrulamak için onu okur, ekleme yapamaz.

Son satırda durmaya değer. Parayı hareket ettiren kimlik bilgisi, paranın gidebileceği yerler kümesini genişletemiyor ve ayrım yanlış yapılandırmadan da sağ çıkıyor, çünkü bunu API üzerinden yapacak yol hiç kurulmadı.

Sonra sınırlar. Beyaz liste yönü söyler, mülkiyet hakkında hiçbir şey söylemez: satıcı, müşterisinin ya da oyuncusunun adresini bilerek onaylayıp oraya ödeme yapabilir; son kullanıcıya yapılan çıkışlar burada böyle çalışır.

Mart ayında, ayrılmakta olan bir yüklenicinin kontrolündeki cüzdan için onaylanan adres, eylülde de onaylı adrestir.

Büyüklüğe dair de hiçbir şey söylemez. Ödeme çıkışına iki hesap limiti uygulanır — tek çıkışın değer tavanı ve aynı anda kaç çıkışın yolda olabileceği — ve kalan hak, sonradan ret olarak gelmek yerine hiçbir şey yazılmadan önce çıkış formunda görünür.

Bunlar hareketi sınırlar; beyaz liste yönü. Çıkış ikisinin de rahatça içinde kalıp yine de bu sabah seçmeyeceğiniz yere gidebilir.

Hedefi kim ekleyebilir?

Oraya para gönderebilenlerden daha az kişi, bilerek.

Beyaz listeyi yönetmek temel yetkide hesap sahibindedir. Finans kullanıcısı, sahibin onayladığı hedeflere çıkış yapabilir ve hedef onaylayamaz; Yönetici'nin temel yetkide hiç çıkış izni yoktur.

NIST'in sözlüğü ilkeyi bordro üzerinden tek cümleye indiriyor: hiçbir kullanıcıya sistemi tek başına kötüye kullanmaya yetecek ayrıcalık verilmemeli, maaş ödemesini yetkilendiren kişi onu hazırlayabilen kişi olmamalı.

İmza sirkülerinden farkı burada ortaya çıkıyor. Sirküler başlangıç değil, imzalanmış belgedir; buradaki temel yetki ise başlangıç konumudur ve tek tek üyelere ek izin verilebilir.

Ayrım, kimse onu verip unutmadığı sürece duruyor; yani izinler ekranı bu kontrolün parçası.

O andaki ikinci katman ek doğrulamadır ve koşulsuz değildir. Ne TOTP'si ne passkey'i olan satıcı kullanıcısına hiç sorulmaz, çünkü ek doğrulama var olan faktörü güçlendirir ve olmayanı talep edemez.

Hesapta hazır duran savunma diye okunursa, öyle bir savunma yok. Her iki durumda da duran şey listedir: çıkış yalnızca listedeki adresi yazabilir, adres eklemek kendi başına kayda geçer ve boş liste çıkış yok demektir.

Doğrulamanın çalıştığı yerde ise onayladığı işleme bağlıdır; hesapta açık bırakılmaz, kullanıldığında harcanır.

Nerede durduğuna dikkat edin. Ödeme çıkışında doğrulama yok; listedeki değişiklikte var. Korunan şey kapının kendisi, kapıdan her geçiş değil — listeyi kısa tutmanın bütün gerekçesi de bu.

Yola çıkmış çıkışı ne durdurur?

Giderek daha azı — ve bunun biçimini önceden bilmek işe yarar.

İptal, başlangıçtaki penceredir; geri çağırma değil. Pencere created durumunda açık kalır ve yürütme başlayınca kapanır. İptal edilmiş çıkışı yeniden iptal etmek hata üretmez: 200 döner, kayıt değişmez.

O noktadan sonra transfer zincirin malıdır ve beyaz listenin, istekle geri alınamaz işlem arasındaki tek şey olduğu ortaya çıkar.

Dondurmalar tek çıkışın üstünde çalışır. Genel giden dondurma var, bir de tek varlık-ağ çifti için kendi kendini kaldırabilen dondurma: defterle cüzdan ayarlanmış toleranstan fazla ayrıştığında o çift, kimsenin fark etmesini beklemeden durur.

Bu, işini yapan emniyet mekanizması: muhasebe anlaşmazlığı, hangi tarafın yanıldığı çözülmeden önce anlaşmazlığın konusu olan şeyi durduruyor.

Ayrıca tek varlığın tek ağdaki çıkış rotası bir süreliğine kullanılamayabilir. Kuyruğa alınmaz, kapıda reddedilir: bu ikili, çıkış seçicisinde görünmez; onu yazan istek oluşturma sırasında reddedilir ve bakiyeye dokunulmaz.

Burada ret, kuruluşu gereği ucuz. Çıkış oluşturmak tutarı ağ ücretiyle birlikte beklemeye taşır; zincire çıkmadan biten çıkış o beklemeyi olduğu gibi, ağ ücreti dahil geri verir.

Yeniden çalıştırmak da ucuz: external_order_id satıcı başına tekildir ve oluşturmayı tekrar etmek ikinci bir transfer göndermek yerine var olan çıkışı döndürür — yarı yolda ölmüş mutabakat işini karşılar, gerçekten farklı bir istek hakkında hiçbir şey söylemez.

Gitmeyen çıkış neden bu kadar az şey söyler?

Çünkü alternatifi, ham iç metnin satıcının ekranına düşmesi.

Çıkışın neden başarısız olduğu satıcıya gösterilmez. Gösterilen şey durumdan türer — kapalı sonuç kümesi — ve panelde Bu transfer çıkışı gönderilmedi. diye okunur; yanında beklemenin serbest kaldığı satır ve nereye sorulacağı durur.

Arkasındaki alan ham imzalayıcı ve RPC metnini, iç rakamları ve operatör notlarını tutar. Desen şu: gösterim noktasında kapalı durum, asla daha aşağıdan gelen metin değil.

Maliyet satıcıya düşüyor ve eksik kalan tek şey gerekçe değil: gitmeyen çıkış ne e-posta gönderir ne de zile bir şey bırakır, başarısızlığı yalnızca webhook bildirir.

Çıkışın geri kalanı ne kadar sürer, o başka bir yazının konusu. Aynı ayrım nihai olmayan durumda da geçerli: ağ onayı henüz gelmemiş çıkış için panel Onaylanmadı yazar ve tutar Beklemede rakamının içinde kalır.

Saklamalı sağlayıcıya ne sorulmalı?

Hiçbir şey yapmadan duran bakiyeden başlayın, sonra insanlara geçin.

Orada dururken ödünç veriliyor mu, stake ediliyor mu, sağlayıcıya getiri üretiyor mu? Sonra: hedefi hangi rol onaylıyor, aynı rol oraya para da gönderebiliyor mu ve kimsenin ikinci faktör tanımlamadığı hesapta liste değişikliğindeki doğrulama ne yapıyor? İyi cevap rolün ve doğrulamanın adını verir, ekibin adını değil. En sonda da çıkış gitmediğinde size ne söylendiğini ve hangi kanaldan söylendiğini sorun — "her adımda e-posta atıyoruz" diyen taraf ya bizim kurmadığımız bir şey kurmuştur ya da kendi bildirim kodunu okumamıştır.

Yükü taşıyan kontrol tek: onaylı adresler listesi. Ne kadar kısaysa o kadar iyi çalışır ve korunmaya değer an, listenin değiştiği andır. Kontroller de bu yüzden orada toplanıyor. Değişikliği varsayılan olarak yalnızca hesap sahibi yapar, her biri kayda geçer, API'de karşılığı yoktur ve ikinci faktörü isteyen tek işlem odur — sonradan yetkilendirdiği ödeme çıkışı ise hiçbir şey istemiyor.