Kripto Ödemeler için Anahtar Yönetimi ve Operasyonel Güvenlik

2025-2026'daki büyük olayların çoğu nihayetinde anahtarlara veya imzalamaya dayanır — ele geçirilmiş bir imza aracı, sızdırılmış bir yönetici anahtarı veya kimlik avına uğramış bir operatör. (Bu vakaları ayrıca yakın tarihli kripto ödeme hack'lerine bakışımızda ayrıca ele alıyoruz.) Ortak nokta, anahtarların nasıl yetkilendirildiği, saklandığı veya imzalamak için nasıl kullanıldığında yatıyor.

Sorun şu ki multisig, MPC, sıcak/soğuk cüzdanlar ve HSM, sanki aynı seviyede seçeneklermiş gibi tartışılıyor ve bunları birbirine karıştırmak seçim sürecini karmaşaya çeviriyor. Bunlar aslında birbirinden bağımsız üç boyuttur ve gerçek bir anahtar yönetimi kurulumu üçünün bir kombinasyonudur. Bu yazı her birini tek tek ele alıyor, ardından hibrit mimariyi, bunu bir arada tutan imza altyapısını ve operasyonel standartları ve çevresindeki daha geniş operasyonel yüzeyi kapsıyor — API ve altyapı izolasyonu, insanlar ve satıcılar, alan adları ve kimlik ve en yeni ve en az anlaşılan risk: fonlarınıza erişimi olan AI Ajanları.

Özel Anahtarlar, Kurtarma İfadeleri ve "Cihazımda" Olması Neden Güvenlik Değildir

Tüm bunların merkezinde özel anahtar vardır: kriptografik rastgele sayılardan oluşan bir dize. Ona sahip olan herkes işlemleri imzalayabilir ve ilgili adresteki fonları taşıyabilir. Bir adresin fonları üzerindeki nihai kontroldür — ve nihai tek risk noktası.

Kurtarma ifadesi (genellikle 12 veya 24 kelime, BIP-39 standardı), bu özel anahtarın insan tarafından okunabilir bir kodlamasıdır. "Hiyerarşik Deterministik" (HD) kuralı, tek bir kurtarma ifadesinden binlerce özel anahtar ve adres türetir. Bu, bir kurtarma ifadesini tek bir özel anahtar kadar hassas, hatta daha hassas yapar: bir özel anahtar sızdırırsanız bir adresi kaybedersiniz; kurtarma ifadesini sızdırırsanız tüm cüzdanı kaybedersiniz.

Burada doğrudan adlandırmaya değer yaygın bir yanlış anlama var: bazıları, imza cihazı ve cüzdan kendi ellerinizde olduğu ve anahtar çevrimdışı olduğu sürece hiçbir şeyin ters gidemeyeceğini varsayar. Sorun şu ki sıradan yazılım ve donanım cüzdanlarındaki özel anahtarlar ve kurtarma ifadeleri dışa aktarılabilir. Cihaza veya bir yedeğe dahili erişimi olan herkes özel anahtarı dışa aktarıp kopyalayabilir ve fonları her yerden kontrol edebilir — o "kendi" cihazınıza hiç dokunmadan.

Dolayısıyla "anahtar kendi cihazımda" ifadesi "başka kimse onu alamaz" anlamına gelmez. Asıl önemli olan özel anahtarın dışa aktarılıp aktarılamayacağıdır. Aşağıda göreceğiniz gibi, HSM donanım düzeyinde dışa aktarımı engelleyen tek seçenektir.

Üç Bağımsız Boyut, Tek Bir Spektrum Değil

Bir kurulum seçmeden önce, gerçekte yanıtladığınız üç soruyu ayırmak yardımcı olur.

Yetkilendirme Modeli: Tek İmza (Single-Sig), Çoklu İmza (Multisig) veya MPC/TSS

Tek imza (single-sig), her şeyi kontrol eden tek bir özel anahtar anlamına gelir — en basit kurulum ve en büyük tek hata noktası.

Multisig, N bağımsız özel anahtardan M tanesinin birlikte imzalamasını gerektirir (ör. 3-of-5) ve her imzacı tam, bağımsız bir özel anahtar tutar. Akıllı sözleşmeleri destekleyen zincirlerde, sözleşme tabanlı multisig (Safe fiili standarttır) bu mantığı bir sözleşmede uygular; imzalar ve eşik kuralları zincir üzerinde herkese açık olarak doğrulanabilir — ancak işlem başına daha yüksek gas maliyeti ve her imza sahibi değiştiğinde bir sözleşme yapılandırma düzenlemesi gerektirir. Burada kolayca gözden kaçan bir zayıflık da var: sözleşme tabanlı multisig için imza altyapısı hâlâ olgunlaşmamıştır. Bir Safe execTransaction çağrısı genellikle donanım cüzdanında uzun bir calldata dizisi olarak görünür; bu nedenle imzacılar gerçekte neyi onayladıklarını görmekte zorlanır ve Clear Signing ile işlem ayrıştırma için ekosistem desteği hâlâ sınırlıdır. Bu tam olarak Bybit olayında istismar edilen saldırı yüzeyidir; bu nedenle sözleşme tabanlı multisig'i benimseyen şirketlerin boşluğu doldurmak için genellikle üçüncü taraf işlem ayrıştırma ve çapraz doğrulama getirmesi gerekir. Bitcoin gibi zincirler ise bunun aksine multisig'i komut dosyası katmanında yerel olarak destekler ve sözleşme bağımlılığı yoktur.

MPC (eşik imzaları, TSS), "tam bir özel anahtarı parçalara bölmek" değildir. Gerçek MPC, dağıtık anahtar üretimi (DKG) kullanır: anahtar, yaratıldığı andan itibaren dağıtılır, her taraf bağımsız bir anahtar payı tutar ve hiçbir noktada tam bir özel anahtar bulunmaz. Her taraf kendi payından kısmi bir imza hesaplar ve bu kısmi imzalar kriptografik bir protokolle tek bir standart imzada birleştirilir — bu bir hesaplamadır, bayt dizilerinin birleştirilmesi değil — sonuç zincir üzerinde sıradan bir tek imzadan ayırt edilemez. Gas maliyeti normaldir, zincirler arası uyumluluk iyidir ve imzacıları veya eşiği değiştirmek bir sözleşmeye dokunmayı gerektirmez.

MPC/TSS'yi daha eski ve kolayca karıştırılan bir yöntemden ayırmak gerekir: Shamir Gizli Paylaşımı (SSS). SSS, zaten mevcut tam bir özel anahtarı n parçaya böler; imzalamak için yeterli parça toplanır ve imzalamadan önce tam özel anahtar bellekte yeniden oluşturulur — ve bu yeniden oluşturma anı tek hata noktasıdır. TSS asla yeniden oluşturmaz; tam özel anahtar asla ortaya çıkmaz. Onu SSS'den daha güvenli yapan da budur.

Multisig ve MPC'nin her ikisi de tek nokta riskini ortadan kaldırır, yalnızca farklı mekanizmalarla. Multisig, birden çok tam anahtar artı zincir üstü doğrulamadır: şeffaftır, ancak imzacıları değiştirmek maliyetli ve zahmetlidir. MPC, birden çok anahtar payı artı kısmi imzaların zincir dışı birleştirilmesidir: esnek ve ucuzdur, ancak koordinasyon sizin altyapınıza bağlıdır.

Donanım Koruması: Yazılım, Donanım Cüzdanı, TEE veya HSM

Yazılım depolama, özel anahtarı bir sunucuda veya yazılımda tutar — en kullanışlı seçenek ve en kırılgan olanı. Bir donanım cüzdanı (Ledger, Trezor ve benzerleri) anahtarı güvenli bir çipte tutar, cihazın içinde imzalar ve anahtarın cihazdan çıkmasına asla izin vermez.

TEE (Güvenilir Yürütme Ortamı) — Intel SGX, AWS Nitro veya Apple Secure Enclave'i düşünün — genel amaçlı bir CPU üzerinde izole, şifrelenmiş bir bellek bölgesi oluşturur; anahtarlar ve imza hesaplamaları, işletim sistemi kök erişimine sahip bir saldırganın bile erişemeyeceği şekilde kalır. Yazılım ile HSM arasında yer alır: güçlü mantıksal izolasyon, iyi performans ve rastgele kod çalıştırabilme (MPC protokolleri dahil) sunar; ancak fiziksel kurcalama direnci ve uyumluluk sertifikasyonu HSM'nin gerisinde kalır. Bu aynı zamanda MPC anahtar paylarını saklamanın en yaygın yoludur — kapsül içinde DKG tarafından üretilir ve asla dışarı çıkarılmaz. Örneğin Fireblocks, MPC anahtar paylarını birden çok buluttaki SGX kapsülleri arasında dağıtır.

HSM (Donanım Güvenlik Modülü), FIPS 140-2/3 gibi sertifikaları karşılayan kurumsal sınıf, kurcalamaya dayanıklı donanımdır; fiziksel kurcalama direnci ve müdahale durumunda otomatik silme özelliğine sahiptir. En güçlü garantisi şudur: özel anahtar donanımın içinde üretilir, dışa aktarılamaz olarak işaretlenir ve fiziksel olarak dışarı çıkamaz. Onu yazılım ve donanım cüzdanlarından temel olarak ayıran budur ve HSM'nin yüksek değerli tam özel anahtarların saklanması için uygun olmasının nedeni budur.

Bu boyut, yukarıdaki yetkilendirme modelinden bağımsızdır: bir multisig'deki her tam anahtar bir donanım cüzdanında veya HSM'de yaşayabilirken, her MPC payı genellikle bir TEE kapsülünde yaşar.

Fon Sıcaklığı: Sıcak, Ilık veya Soğuk

Bu boyut anahtarın nasıl saklandığıyla ilgilenmez — yalnızca özel anahtarın internete ne kadar maruz kaldığıyla, yani paranın ne kadar hızlı ve ne kadar otomatik hareket edebileceğiyle ilgilenir.

Sıcak cüzdanlar her zaman çevrimiçidir, anlık ödemeler ve otomatik ödemeler için kullanılır — en hızlı ve en yüksek riskli olanlardır, genellikle toplam fonların yalnızca tek haneli bir yüzdesini tutar. Ilık cüzdanlar çevrimiçidir, ancak özel anahtar korumalı bir ortamda (özel bir imza hizmeti veya HSM) izole edilmiştir ve imza döngüsünde bir insan gerektirir; bunlar günlük operasyonel mutabakatı yürütür. Soğuk cüzdanlar tamamen çevrimdışıdır ve ağ bağlantısı kesiktir; büyük rezervlerin uzun vadeli saklanması için kullanılır — en yüksek güvenlik, kullanımı en yavaş ve genellikle fonların çoğunu tutar.

Açık olmak gerekirse, sıcaklık temel olarak özel anahtarın çevrimiçi maruziyeti ve fonların ne kadar kolay hareket ettiğiyle ilgilidir; transfer sıklığı ve fon payı bunun sonucudur, tanımı değildir. Bu boyut da ilk ikisinden bağımsızdır: soğuk bir cüzdan multisig artı HSM kullanabilir ve sıcak bir cüzdan MPC kullanabilir.

Üçünü bir araya getirdiğinizde tam resmi elde edersiniz: yetkilendirme modeli, donanım koruması ve fon sıcaklığı bağımsızdır ve gerçek bir anahtar yönetimi kurulumu üçünü de birleştirir.

Yaygın Anahtar Yönetimi Kurulumları

Endüstri bu üç boyutu yaygın olarak şu şekilde birleştirir:

Seçimin amacı, fon sıcaklığına göre katmanlara ayırmak ve her katmanda en iyi kombinasyonu kullanmaktır. Sıcak cüzdanlar hız gerektirir, bu yüzden MPC'yi tercih edin. Soğuk cüzdanlar istikrar ve denetlenebilirlik gerektirir, bu yüzden multisig artı HSM'yi tercih edin. Yönetişim ve sözleşme ayrıcalıkları şeffaflık ve hesap verebilirlik gerektirir, bu yüzden sözleşme tabanlı multisig artı zaman kilidini tercih edin.

BlockSec'in Önerdiği Hibrit Mimari

BlockSec, sıcaklığa göre katmanlandırılmış bir hibrit mimari önerir.

Sıcak/ılık cüzdanlar: MPC imzalama. Özel anahtarın tek hata noktasını ortadan kaldırır, imza gecikmesini düşük tutar ve yüksek frekanslı ödemeler için uygundur. Paylar farklı fiziksel konumlara ve güvenlik alanlarına dağıtılmalıdır.

Soğuk cüzdanlar: çok taraflı kontrol artı zincir üstü denetlenebilirlik, büyük rezervler için uygundur. Hangi uygulamanın kullanılacağı, ekibinizin zincir üstü operasyonel yeteneğine bağlıdır — iki yol vardır:

• Maksimum şeffaflık ve olgun zincir üstü operasyonlar için: sözleşme tabanlı multisig (ör. Safe'in 3-of-5'i) kullanın; burada eşik kuralları ve her imza zincir üzerinde herkese açık olarak doğrulanabilir. Bitcoin'de, her imzacının kendi anahtarını bir HSM veya donanım cüzdanında koruduğu komut dosyası katmanı yerel multisig'ini kullanın. Sözleşme tabanlı multisig için imza ayrıştırma araçlarının hâlâ olgunlaşmadığını unutmayın; bu nedenle ekibin çapraz doğrulamayı kendisinin eklemesi gerekir — buradaki operasyonlar hafif değildir.

• Zincir üstü yürütmede daha az akıcı olan ve daha az operasyonel karmaşıklık isteyen ekipler için: payları TEE'de olan MPC eşik imzalaması kullanın ve ardından her imzadan önce bir işlem güvenlik kontrolü yapması için bağımsız bir üçüncü tarafı ortak imzacı olarak dahil edin. Bu, sözleşme tabanlı multisig araç eksikliğini önler ve bağımsız üçüncü taraf doğrulamasını doğrudan imza eşiğine yerleştirir.

Sözleşme yükseltmeleri ve politika değişiklikleri: multisig artı zaman kilidi. Ayrıcalık değiştiren her işlem, birden çok kişinin onayını ve bir zaman gecikmesi gerektirir.

Hangi yolu seçerseniz seçin birkaç parametre önemlidir. En az 3 imzacı kullanın ve eşik en az %50 ancak toplam sayının altında olsun — N-of-N'den kaçının, çünkü ulaşılamayan tek bir imzacı imzalamayı engeller ve fonları kilitler; ayrıca her imzacı vazgeçilmezse, her biri zorlama veya kaçırma için kritik bir hedef haline gelir. Toplamın altındaki bir eşik artıklık bırakır ve tek bir imzacıyı hedef almanın değerini düşürür. Her imzacı ayrıca her multisig'de yepyeni, özel bir adres kullanmalı ve bu adres diğer multisig'ler veya kişisel cüzdanlarla asla paylaşılmamalıdır; imzacılar coğrafya, organizasyonel rol ve tüzel kişilik açısından çeşitli olmalıdır — cüzdanın risk seviyesi arttıkça dağılım da artmalıdır.

Bu risk seviyesi resmi bir derecelendirmeden gelmelidir: her cüzdanı işletmeye finansal etkisi, protokol bağımlılığı ve itibar riskiyle değerlendirin ve her dereceyi farklı bir eşik, onay akışı ve izleme yoğunluğuyla eşleştirin. Derecelendirmeyi her 6 ayda bir ve büyük bir TVL değişikliği, sözleşme yükseltmesi veya güvenlik olayından hemen sonra gözden geçirin.

Kör İmzalama ve İmza Ortamı İzolasyonu

Kör imzalama, imza aracınızın size işlemin gerçekte ne yaptığını değil, bir calldata karması göstermesi anlamına gelir. Bu varsayımsal bir risk değildir: imza anında imzacı, işlemin gerçek anlamını arayüzden anlayamaz ve bu boşluk Bybit olayının doğrudan nedenlerinden biriydi; imzalamak için kullanılan ön uç veya arka uç ele geçirilmişti ve imzacılar, sözleşmelerin kendilerinde hiçbir hata olmamasına rağmen kötü amaçlı bir işlemi onaylamıştı.

Yukarıdaki üç boyutu kilitlemek, yalnızca etraflarındaki imza süreci de en az onlar kadar sağlamlaştırılmışsa işe yarar. Kurulumdan bağımsız olarak geçerli olan birkaç standart vardır:

• Zorunlu imza donanımı. Tüm üretim multisig operasyonları, tam işlem özetini görüntüleyecek kadar büyük bir ekrana sahip, Clear Signing destekleyen, donanım yazılımı bütünlük doğrulamalı PIN koruması olan ve tedarik zinciri üretici veya yetkili satıcılarla sınırlı bir donanım cüzdanı kullanmalıdır — teslim alındığında orijinallik doğrulaması yapın.

• Fiziksel olarak izole edilmiş imza ortamı. İmzalama, günlük ofis ağını paylaşmayan, ağ bağlantısı kesilmiş cihazlarda çalışmalıdır; yüksek değerli operasyonlar özel imza cihazları gerektirir. İmza hizmetini, iş mantığından ve ön uçtan fiziksel olarak izole edilmiş bağımsız bir güvenlik alanında dağıtın. İmza düğümleri genel internete doğrudan maruz bırakılmamalıdır — bunlara yalnızca VPN veya özel hat üzerinden bağlanın. İmza operasyon günlükleri, iş sistemi tarafından değiştirilemeyecek şekilde ayrı olarak saklanmalıdır.

• Bağımsız işlem doğrulaması. İmzalamadan önce işlem içeriğini bağımsız bir kanaldan doğrulayın — özel bir terminal, bir donanım cihazı veya üçüncü taraf bir işlem simülasyonu/risk hizmeti. Bu kontrol en iyi, yalnızca kendi ön uç veya arka uç sistemleriniz değil, bağımsız bir üçüncü tarafça yapılır — yalnızca dahili sistemlere güvenmek başlı başına bir tek hata noktasıdır. Bybit'te olduğu gibi dahili ön uç veya arka uç ele geçirildiğinde, imzacının ekranda gördüğü şey kurcalanmış sahte bilgilerdir ve kendi kendinizi doğrulamak hiçbir şekilde doğrulama değildir. Özellikle ödeme yolu bu bağımsız savunma hattına ihtiyaç duyar.

• Clear Signing ve çapraz doğrulama. İşlem anlamını ayrıştıran araçlar kullanın; böylece imzacı bir calldata dizisi yerine "1.000 USDC'yi 0x1234... adresine aktar" ifadesini görür ve temel parametreleri — zincir kimliği, hedef adres, calldata, değer, nonce ve işlem türü — en az iki bağımsız araç veya arayüzde aynı olacak şekilde çapraz doğrulayın.

• İnsan artı otomatik çift kontrol. Otomatik bir kural motoru ilk aşama taramasını yapar ve büyük işlemler gönderilmeden önce bir insan onaylar.

• Sıfır güven ve yedekler. İmza hizmetini, iş mantığını ve ön uç arayüzünü farklı güvenlik alanlarında dağıtın ve birincil imza arayüzü, RPC ve blok gezgini için yedekler bulundurun; böylece tek bir satıcı veya hizmet arızası acil imzalamayı engelleyemez.

Multisig Operasyonel Standartları

Anahtar ve eşik seçimleri sizi yalnızca bir yere kadar götürür. Birkaç operasyonel standart da en az onlar kadar önemlidir.

Multisig kaydı. Her multisig için tek bir kayıt tutun; her kayıt en az şunları içermelidir: adres, zincir, imza eşiği, risk derecesi, amaç, imzacı adresleri, kontrol edilen sözleşmeler, zincir üstü roller ve son inceleme tarihi. Güvenlik açısından hassas değişiklikler kaydı 24 saat içinde, rutin değişiklikler 3 gün içinde güncellemelidir.

İmzacı yaşam döngüsü yönetimi. Katılımdan önce, aday adresin bağımsız bir araçla doğrulanan belirli bir mesajı imzalamasını sağlayarak adresleri doğrulayın. Ayrılan veya çıkarılan bir imzacının ayrıcalıklarını kaldırmak için risk derecesine göre SLA'lar belirleyin — acil durumlar için 48-72 saat, kritik durumlar için 7 gün, diğer her şey için 14 gün içinde. Her imzacının anahtarını hâlâ kontrol ettiğini doğrulamak için üç ayda bir erişim incelemesi yapın ve işlem doğrulama, acil durum prosedürleri ve sosyal mühendislik/kimlik avı savunmasını kapsayan imzacı eğitimini en az yılda bir yenileyin; ardından uygulamalı bir değerlendirme yapın.

Kurtarma ifadesi ve yedek koruması. Hiçbir tür dijital depolama olmamalıdır — bulut sürücüleri, fotoğraf albümleri veya belgeler yok. Yedekleri farklı coğrafi konumlara dağıtılmış şekilde saklayın; doğal afet, hırsızlık ve bir operatörün kaybolması durumlarına karşı kurtarılabilir olmalıdır. Hiçbir tek nokta, kurtarma bilgilerinin tamamını tutmamalıdır.

Güvenli iletişim. İmzacılar arasında farklı platformlardaki birincil ve yedek kanalları kullanarak koordinasyon sağlayın; her kanal MFA, uçtan uca şifreleme ve yalnızca davetli üyelik uygulamalıdır. İmzalamadan önce, bir imzacının kimliğini bağımsız bir kanaldan doğrulayın — bir video görüşmesi, bir parola ve kimliği doğrulanmış ikinci bir kanal — böylece ele geçirilmiş bir mesajlaşma hesabının bir imzacıyı taklit etmesi önlenir.

Acil müdahale SLA'sı. Olay ciddiyetine göre imzacı yanıt süreleri belirleyin; örneğin acil durumlar için 2 saatin altında, zamana duyarlı durumlar için 2-12 saat, rutin durumlar için 24-48 saat. İmzacıların ulaşılabilirliğini yalnızca kağıt üzerinde değil, üç ayda bir test edin ve yılda en az bir uçtan uca acil durum tatbikatı yapın; sızdırılmış anahtar, ulaşılamayan imzacı, ele geçirilmiş iletişim kanalı ve acil durum protokolü operasyonları gibi senaryoları kapsayın.

Multisig zincir üstü izleme. İmzacı/eşik değişikliklerini, eşik üstü transferleri, nonce boşluklarını, bilinmeyen adres etkileşimlerini, başarısız işlemleri, Module/Guard değişikliklerini ve anormal teklif veren cüzdan bakiyelerini izleyin. İzleme altyapısının kendisi kurcalamaya karşı dayanıklı olmalıdır.

API Güvenliği

API güvenliği, ödeme arka ucunuz için ilk savunma hattıdır. Bu, bir API anahtarı artı HMAC imzası veya FIDO2/WebAuthn aracılığıyla kimlik doğrulama, kaba kuvvet ve kötüye kullanımı önlemek için hız sınırlama, bir CDN/WAF hizmeti aracılığıyla DDoS koruması, enjeksiyonu önlemek için her girdi parametresinin sıkı doğrulanması ve her API çağrısının eksiksiz bir denetim izi üretmesi için günlük denetimi anlamına gelir.

İmza ortamları tüm bunlardan izole edilmelidir, yalnızca bunlarla korunmamalıdır — bu nedenle imza hizmeti, yukarıda ele alındığı gibi kendi güvenlik alanında yer almalıdır.

Operasyon Güvenliği: İnsanlar, Satıcılar ve Bağımsız Denetimler

2026'daki birçok büyük olay sosyal mühendislik içeriyordu — sahte işe alım, BT desteği taklidi ve AI yüz değiştirme bunlar arasındaydı. Buna karşı savunma, birlikte çalışan üç seviye gerektirir.

Eğitim ve değerlendirme önce gelir: imza sistemlerine, üretim kimlik bilgilerine veya hassas operasyonlara erişimi olan herkes, işe başlarken güvenlik eğitimini tamamlar, yıllık olarak yeniler ve herhangi bir süreç değişikliğinden sonra 30 gün içinde içeriği günceller.

Görev ayrılığı da en az o kadar önemlidir: başlatma, onaylama ve yürütme aynı kişi tarafından yapılamaz ve yönetici hesapları doğrudan ödeme yapamaz. İmzalama gibi yüksek hassasiyetli operasyonlar, tam disk şifreli, otomatik kilitlenen özel cihazlar kullanmalıdır; donanım cüzdanları kullanılmadığında bir kasada saklanmalı ve tüm uzaktan erişim bir VPN üzerinden yönlendirilmelidir.

Üçüncü taraflar da aynı disipline ihtiyaç duyar. Bir satıcı seçmeden önce gerekli özeni gösterin, kilit satıcıların uyumluluk ve güvenlik durumunu yıllık olarak yeniden inceleyin ve üçüncü taraf erişimine net bir kapsam, amaç ve sona erme süresi verin — süre dolduğunda veya proje bittiğinde erişimi derhal iptal edin. Herhangi bir erişim vermeden önce üçüncü taraf personelinin kimliğini bağımsız olarak doğrulayın.

Bunların hiçbiri yalnızca dahili öz denetimlere dayanmamalıdır. En azından sızma testi, red-team tatbikatları ve kod ile akıllı sözleşme denetimlerini kapsayan bağımsız üçüncü taraf güvenlik değerlendirmelerini düzenli olarak yapın. Bulguları tek tek düzeltin ve bir sonraki değerlendirme turunda kapatıldığını doğrulayın.

Geliştirme ve Altyapı Güvenliği

Son yıllardaki birçok büyük ödeme ve kripto olayı, ele geçirilmiş bir geliştirme sürecine dayanıyor — sözleşmeler ve imza mantığının kendileri tamamen sağlam olsa bile. Bu, geliştirme ve altyapı katmanının imza katmanıyla aynı ilgiyi hak ettiği anlamına gelir; dört alanda.

Geliştirme ortamı izolasyonu, geliştirme hesaplarını ayrıcalıklı hesaplardan (imzalama, bulut yönetimi) ayrı tutar, üretim kimlik bilgilerini geliştirme ortamının erişemeyeceği şekilde saklar ve geliştirme araçları ile uzantılarını bir onay listesine alır.

Kod depolarınız ve tedarik zinciriniz, ana daldaki dal koruması, imzalı commit'ler ve çok kişili inceleme gerektirir. Bağımlılıkları yalnızca resmi depolarından, sabitlenmiş sürümlerle ve typo-squatting kontrolleriyle çekin ve açığa çıkan herhangi bir anahtarı derhal iptal edip döndüren otomatik gizli tarama çalıştırın.

CI/CD'de, ardışık düzen yapılandırma değişiklikleri çok taraflı onay ve sürüm kontrolü gerektirir; yeniden üretilebilir derlemelerle olmalıdır. Sırlar, Vault veya bulut KMS gibi özel bir yöneticiden geçer — üretim sırları insanlar tarafından asla doğrudan erişilebilir olmamalıdır — ve SAST ile bağımlılık taraması, dağıtım için ön koşuldur, isteğe bağlı ekstralar değildir.

Altyapı ve bulut için, ayrıcalıklı erişimi tam zamanında sağlama, çok taraflı onay ve zaman sınırlarıyla verin. Acil durumlar için break-glass hesapları bulundurun, ancak her kullanımda uyarı verin. Eksiksiz denetim günlükleri, yönetici işlemlerinde gerçek zamanlı uyarılar ve düzenli olarak tatbik edilen yedekleme ile felaket kurtarma çalıştırın.

Alan Adı, DNS ve Kimlik: Hafife Alınan Saldırı Yüzeyi

Alan adı ve DNS, kriptoda ciddi şekilde hafife alınan bir saldırı yüzeyidir — birçok kimlik avı olayı ve hırsızlık, ele geçirilmiş bir kayıt kuruluşu hesabına veya ele geçirilmiş DNS'e dayanır. Kullanıcıların fon işlemleri başlattığı alan adlarını korumak, imza ortamının kendisini korumak kadar önemlidir.

Kayıt kuruluşu hesabınızı yüksek ayrıcalıklı bir hesap olarak yönetin: donanım anahtarı MFA'sını zorunlu kılın ve transfer, silme veya isim sunucusu değişiklikleri gibi kritik değişiklikler için bant dışı ikinci onay isteyin. DNS ve e-posta tarafında, kritik alan adlarında DNSSEC'i etkinleştirin, hangi CA'ların sertifika düzenleyebileceğini sınırlamak için CAA kullanın ve tüm gönderen alan adlarında SPF/DKIM/DMARC (p=reject) yapılandırın — göndermeyen alan adlarını da e-postayı açıkça reddedecek şekilde ayarlayarak sahteciliği önleyin.

İzlediği alan adına bağımlı olmayan bir izleme altyapısı kullanarak DNS kaydı değişikliklerini, isim sunucusu yetkilendirmesini ve anormal Sertifika Şeffaflığı günlüğü düzenlemelerini sürekli izleyin. Alan adı ele geçirme ve yetkisiz transfer için işleme sürecinizi belgeleyin, yıllık olarak tatbik edin ve kademeli sona erme uyarıları ile otomatik yenilemeyi ayarlayın; böylece süresi dolmuş bir alan adı bir giriş noktası haline gelmez.

Kimlik ve hesaplar, neredeyse tüm yanal hareketlerin giriş noktasıdır. Kurumsal hesapların eksiksiz bir envanteri ve sıkı bir MFA standardı, herhangi bir tek nokta savunmasından daha önemlidir.

Bir hesap envanteriyle başlayın: her kurumsal hesabı — sosyal medya, e-posta, SSO/IdP, kayıt kuruluşu, saklama platformları, kod depoları, bulut kök hesabı, kilit SaaS — net bir sahibiyle kaydedin ve düzenli olarak gözden geçirin. Yüksek ayrıcalıklı hesaplarda FIDO2/WebAuthn donanım anahtarlarıyla kimlik avına dayanıklı MFA uygulayın ve birincil faktör olarak asla SMS veya sese güvenmeyin — SIM swap, SS7 ve sesli kimlik avı bunların hepsini atlar. Bu, hesap ele geçirmeye karşı en etkili tek savunmadır.

Benzersiz güçlü parolalara sahip bir parola yöneticisi zorunlu kılın, paylaşılan girişleri yasaklayın ve kurtarma e-postası ile telefonunu kurumsal alan adıyla sınırlayın — kurtarma kodlarını kişisel e-posta veya bulut yerine güvenli depolamada tutun. Biri ayrıldığında, tüm erişimini 24 saat içinde iptal edin ve dokunduğu paylaşılan kimlik bilgilerini döndürün; ayrıca yüksek ayrıcalıklı hesaplarda aktif oldukları süre boyunca davranışsal ve kimlik bilgisi sızıntısı izlemesini sürdürün.

Bir AI Ajanının Mimarisi Neden Tasarım Gereği Güvensizdir

Ödeme şirketleri, geliştirme ve operasyonel verimliliği artırmak için giderek daha fazla AI aracı ve Ajan kullanıyor — ancak bu, kötü yönetilirse fonları doğrudan tehdit eden yeni bir saldırı yüzeyi açar.

Gözden kaçırılması kolay kısım şu: Bir AI Ajanı yalnızca soruları yanıtlayan bir model değildir. Dış içeriği okuyabilen, araçları çağırabilen, kimlik bilgilerini tutabilen ve eylemler gerçekleştirebilen bir makinedir. Riskin kökü, güvenilmeyen içerikten okunan metni yürütülecek talimatlar olarak ele almasıdır.

Bu, bir saldırganın hiçbir güvenlik açığına ve çalınmış bir hesaba ihtiyacı olmadığı anlamına gelir. Bir belgeye, web sayfasına, kod yorumuna veya PR açıklamasına gizlenen tek bir cümle, Ajan'ın davranışını ele geçirerek veri sızdırmasına veya yetkisiz eylemler gerçekleştirmesine neden olabilir. Buna prompt injection denir ve 2026'ya gelindiğinde doğrudan uzaktan kod yürütmeye dönüştüğü gösterilmiştir — Microsoft, bir Ajan çalıştıran makinede tek bir prompt'un bir program başlattığını gösterdi ve GitHub Copilot, Cursor ve MCP altyapısı, CVSS 9.6 veya daha yüksek olarak derecelendirilen RCE güvenlik açıklarını açıkladı.

Herhangi bir ayrıcalıklı şey için daha da kötüleşir. Bir geliştirme veya operasyon Ajanı, operatörünün dosya erişimini, kabuk ayrıcalıklarını ve veritabanı anahtarlarını varsayılan olarak devralır. 2026'da ana akım kodlama Ajanlarını kapsayan bir çalışma, hepsinin prompt injection ile kırılabileceğini ve uyarlanabilir saldırı başarı oranının %85'in üzerinde olduğunu buldu. Güvenilmeyen girdiyi işleyen herhangi bir Ajan, kimlik bilgilerinizi elinde tutan potansiyel bir içeriden kişi olarak ele alınmalıdır — ve tedarik zinciri de yüksek riskli bir halkadır: Mart 2026'da, zehirli bir AI ağ geçidi bağımlılığı 3 saat boyunca genel bir depoda durdu ve yaklaşık 47.000 kez indirildi.

Fon Kontrolünü Kaybetmeden AI Ajan Verimliliği Nasıl Elde Edilir

Yaklaşım, Ajan'ı güvenilmeyen koda uygulayacağınız aynı kısıtlamalara tabi tutmaktır; beş kontrol üzerinden:

• İzole yürütme — Ajan'ın araç yürütmesini bir sanal alanda çalıştırın; böylece prompt injection gerçek kabuğa, üretim anahtarlarına veya imza ortamına ulaşamaz.

• En az ayrıcalık — Ajan'ın araçlarına, veritabanı anahtarlarına ve MCP hizmetlerine yalnızca tek bir işlem için gereken minimum erişimi verin; asla "tam erişim" kimlik bilgisi vermeyin.

• Fon işlemlerinde insan kapısı — transferler, imzalama veya ayrıcalık değişiklikleri içeren her şey için Ajan yalnızca önerebilir, asla otomatik olarak yürütemez. Bağımsız insan onayı burada da geçerlidir; yukarıda ele alınan imza doğrulamasının arkasındaki aynı ilke.

• Güvenilir talimatları güvenilmeyen verilerden ayırın — bunu mimari düzeyde yapın ve modelin "bunları kendi başına ayırt etmesini" beklemeyin.

• Tedarik zinciri kilitleme — AI ile ilgili bağımlılıklara, normal kod depolarınıza uyguladığınız aynı sürüm sabitleme ve kaynak doğrulama kontrollerini uygulayın.

Bu kısıtlamalar yalnızca teorik kalmak zorunda değil. BlockSec'in açık kaynaklı Web3 Companion projesi, güvenli bir ajan cüzdanının referans uygulamasıdır (MIT lisansı, araştırma önizlemesi). Bir AI Ajanının, özel anahtarları ve nihai yetkilendirmeyi tamamen Ajan'ın erişemeyeceği şekilde tutarak kullanıcının zincir üstü işlemleri hazırlamasına yardımcı olmasını sağlar. Tehdit modeli Ajan'ın kendisini güvenilmez olarak ele alır — tüm sistem, tamamen ele geçirilmiş bir Ajan'ın bile kullanıcının fonlarını hareket ettiremeyeceğini garanti etmek zorundadır.

Mimari üç noktaya dayanır. Anahtar izolasyonu, özel anahtara yalnızca tek bir bağımsız imza modülünün (ayrı bir Go işlemi) dokunabileceği anlamına gelir — Ajan bir işlem niyeti kimliği alır, imza talep edebilir, ancak asla bir anahtar görmez. Anahtarlar zarf şifrelemesiyle (AWS KMS veya yerel AES-256) saklanır ve düz metin yalnızca imzalama anı için bellekte bulunur, ardından sıfırlanır.

Yayınlanmadan önce, bir işlem sırayla dört katmandan geçer ve her katman kendisinden öncekinin başarısız olduğunu varsayar: işlem simülasyonu (calldata'yı çözme, revert'ları tahmin etme), karşı taraf risk puanlaması, saf Go sert politika sınırları (işlem başına tavan, günlük bütçe, beyaz liste — hiçbirini Ajan değiştiremez) ve son olarak passkey insan onayı; yalnızca yazılımla yapılan bir saldırının taklit edemeyeceği bir WebAuthn parmak izi veya yüz taraması. Anahtar, politika ve passkey üç bağımsız güven sınırı oluşturur; birini ihlal etmek diğer ikisini sağlam bırakır.

Bir AI Ajanı gerçekten verimliliği artırabilir, ancak fonlar ve imzalama üzerinde tek başına kontrole sahip olmamalıdır. Onu bir asistan olarak en az ayrıcalıklı bir sanal alana koyun ve fonlar ile imzalama konusunda son kararı insanlara bırakın.

Her Şeyi Bir Araya Getirmek

Anahtar yönetimi tek bir karar değildir — bağımsız olarak alınan ve sonra birleştirilen üç karardır: kimin imzalaması gerektiği, anahtarın veya payın fiziksel olarak nerede yaşadığı ve internete ne kadar maruz kaldığı. Her fon katmanı için doğru kombinasyonu elde etmek, bunu sağlamlaştırılmış imza altyapısıyla desteklemek ve yukarıdaki operasyonel standartlarla bir arada tutmak, BlockSec'in 2025-2026'nın anahtar ve imzalamayla ilgili olaylarının çoğunun arkasındaki boşlukları kapatma çerçevesidir. Ve saldırı yüzeyi artık anahtarların ötesine — API'lere, insanlara, satıcılara, kod ardışık düzenlerine, alan adlarına, kimliğe ve AI Ajanlarına — uzandığı için, bunların her biri aynı muameleyi gerektirir: kendisinden önceki katmanın başarısız olduğunu varsayın ve fonların hareket edebileceği her yerde döngüde bir insan bulundurun.

Anahtar yönetiminin ve operasyonel güvenliğin, bir ödeme sisteminin uyum programının geri kalanıyla birlikte nereye oturduğuna dair tam resim için kripto ödeme güvenliği ve uyumluluk playbook'umuzu (PDF) indirin.

SSS

MPC ile multisig arasındaki gerçek fark nedir? Multisig, her biri zincir üzerinde ayrı ayrı doğrulanan birden çok tam özel anahtardır — şeffaftır, ancak imzacıları değiştirmek maliyetli ve zahmetlidir. MPC (eşik imzaları), hiçbir tam özel anahtarın var olmaması için üretilen birden çok anahtar payıdır; kısmi imzalar zincir dışında tek bir imzada birleştirilir — esnek ve ucuzdur, ancak koordinasyon altyapınıza bağlıdır.

Shamir Gizli Paylaşımı (SSS) MPC ile aynı mıdır? Hayır. SSS, zaten mevcut olan tam bir özel anahtarı parçalara ayırır ve imzalamak için tam anahtarı bellekte yeniden oluşturur; bu da yeniden oluşturma anını tek hata noktası haline getirir. Gerçek MPC (TSS) tam bir özel anahtarı asla yeniden oluşturmaz — her taraf yalnızca kendi payından kısmi bir imza hesaplar.

TEE ile HSM arasındaki fark nedir? TEE (Intel SGX, AWS Nitro veya Apple Secure Enclave gibi), genel amaçlı bir CPU üzerinde rastgele kod çalıştırabilen, MPC protokolleri dahil, izole ve şifrelenmiş bir bölgedir — güçlü mantıksal izolasyon sunar, ancak fiziksel kurcalama direnci ve sertifikasyonu HSM'den daha zayıftır. HSM, özel anahtarın içinde üretildiği, dışa aktarılamaz olarak işaretlendiği ve fiziksel olarak dışarı çıkamadığı özel, kurcalamaya dayanıklı donanımdır.

Ilık cüzdan nedir ve sıcak veya soğuktan nasıl farklıdır? Ilık cüzdan çevrimiçidir ancak özel anahtarı korumalı bir ortamda (özel bir imza hizmeti veya HSM) izole tutar ve imza döngüsünde bir insan gerektirir; günlük mutabakat için kullanılır — her zaman çevrimiçi, otomatik bir sıcak cüzdan ile tamamen çevrimdışı, ağ bağlantısı kesilmiş bir soğuk cüzdan arasında yer alır.

BlockSec özellikle soğuk depolama için ne öneriyor? Ekibin zincir üstü operasyonel yeteneğine bağlıdır: olgun zincir üstü operasyonlara sahip ekipler, her imzacının anahtarı bir HSM veya donanım cüzdanında olacak şekilde sözleşme tabanlı multisig (ör. Safe'in 3-of-5'i) kullanabilir; daha az operasyonel karmaşıklık isteyen ekipler, payları TEE'de olan MPC eşik imzalaması ve işlem güvenlik kontrolleri için bağımsız bir üçüncü taraf ortak imzacı kullanabilir.

Kör imzalama nedir ve neden tehlikelidir? Kör imzalama, bir imza arayüzünün işlemin gerçekte ne yaptığı yerine yalnızca bir calldata karması göstermesidir. İmzacı onayladığı şeyin gerçek anlamını doğrulayamaz; bu, Bybit olayının doğrudan nedenlerinden biriydi.

AI Ajanlara kripto ödeme işlemleri konusunda güvenilebilir mi? Tek başına kontrolle güvenilemez. Bir AI Ajanının yalnızca fon işlemleri önermesine izin verilmeli, asla otomatik olarak yürütmemelidir — transferler, imzalama ve ayrıcalık değişikliklerinin tümü, en az ayrıcalıklı bir sanal alanda çalışan Ajan ile bağımsız insan onayı gerektirir.

Prompt injection nedir ve ne kadar ciddidir? Prompt injection, bir AI Ajanının davranışını ele geçiren talimatları güvenilmeyen içeriğe — bir belge, web sayfası, kod yorumu veya PR açıklaması — gizler. 2026'ya gelindiğinde, ana akım kodlama araçlarını etkileyen ve CVSS 9.6 veya daha yüksek olarak derecelendirilen açıklanan güvenlik açıklarında uzaktan kod yürütmeye dönüşmüştür.

Hesap ele geçirmeye karşı en etkili tek savunma nedir? Kimlik avına dayanıklı MFA — yüksek ayrıcalıklı hesaplarda FIDO2/WebAuthn donanım anahtarlarını zorunlu kılmak ve birincil faktör olarak asla SMS veya sese güvenmemek; çünkü SIM swap, SS7 ve sesli kimlik avı bu kanalların hepsini atlayabilir.