Back to Blog

Kurumsal Blokzincir Sızma Testi için Angajman Kuralları ve Üretim Güvenliği

Code Auditing
3 Eylül 2026
10 min read
Key Insights
  • Yararlı bir sızma testi çalışması başlamadan önce hazırlanır: net bir hedef, üzerinde anlaşılan bir kapsam, sorumlu sahipler ve yetkilendirilmiş erişim ile birlikte, süreç boyunca normal operasyonların sürdürülmesine yönelik bir plan—bu hazırlık, kurumun değeri nasıl hareket ettirdiğini ve kontrol ettiğini yansıtır.

  • Bir Katılım Kuralları (Rules of Engagement, RoE) belgesi, yetki, faaliyet sınırları, iletişim, üst düzeye taşıma (escalation) ve kanıt yönetimini belirleyerek çalışmayı uygulanabilir hale getirir.

  • Üretim ortamı testi, hizmet güvenlik önlemleri, ölçülebilir durdurma kriterleri, izleme, değişiklik koordinasyonu ve duraklatma yetkisi gerektirir; ayrıca çalışma, bulguların doğrulanmış iyileştirmelere dönüşmesi için düzeltme ve yeniden test aşamalarını da tanımlamalıdır.

Bu dizinin ilk iki makalesi, kripto kurumlarının neden blok zinciri sızma testine ihtiyaç duyduğunu (Bölüm 1) ve bu disiplinin ne olduğunu (Bölüm 2) ortaya koymuştu. Bu makale, kurumsal bir çalışmanın nasıl hazırlanıp güvenli bir şekilde yürütüldüğüne odaklanıyor: katılım kuralları, üretim güvenliği önlemleri ve bulguları düzeltmelere dönüştüren iyileştirme ve yeniden test süreci — aşağıda gösterilen çalışma yaşam döngüsü.

Şekil 1. Kurumsal sızma testi çalışması yaşam döngüsü.
Şekil 1. Kurumsal sızma testi çalışması yaşam döngüsü.

Web3, üretim testinin risklerini belirli bir şekilde artırır: zincir üstü işlemler genellikle geri alınamaz, test etkinliği çoğunlukla zincir üzerinde herkese açık olarak görülebilir ve kapsamdaki sistemler gerçek fonları hareket ettirebilir. Bu nedenle aşağıdaki önlemler, ortam seçimine, değer sınırlarına, anahtar yönetimine ve mutabakata geleneksel bir çalışmaya kıyasla çok daha fazla ağırlık verir.

İşletme yetkisi olarak RoE

ABD Ulusal Standartlar ve Teknoloji Enstitüsü'ne (NIST) göre, RoE güvenlik testi için kılavuzları ve kısıtlamaları belirler [1]. Kurumsal bir çalışma için bu, test etme kararını yetkilendirilmiş bir görevlendirmeye dönüştürür: tanımlanmış bir hedef, tanımlanmış bir kapsam ve hareket etmeye yetkili belirlenmiş bir otorite.

Bu görevlendirme önemlidir çünkü bir test ekibi, yetkiyi güvenli bir şekilde bir sözleşme veya varlık listesinden çıkaramaz. Değerlendirilecek risk, dahil olan sistemler ve bunlardan sorumlu kişiler hakkında ortak bir karar olmadan, ekip yanlış yolu test edebilir, kritik bir bağımlılığı hariç tutabilir veya önemli bir bulguyu doğrulamak için yetkiye sahip olmayabilir.

Başlangıç noktası, testin desteklemesi amaçlanan iş kararıdır. Bir hedef, lansman öncesi kamuya açık maruziyetle ilgili olabilir. Müşteri ve uygulama programlama arayüzü (API) yetkilendirmesine veya ayrıcalıklı bulut ve operasyonel sistemlerin erişilebilirliğine odaklanabilir. Ayrıca bir imzalama veya para çekme iş akışını test edebilir veya üçüncü taraf bir entegrasyonu değerlendirebilir. Bu hedef, önemli olan sistemleri, azaltılacak riski ve yönetimin karar vermesi için gereken sonucu belirler.

Hedef, işletme modelini izleyen bir kapsama dönüşmelidir. Bir kripto kurumunda bu genellikle şunları içerir: müşteriye yönelik web, mobil ve uygulama programlama arayüzü (API) hizmetleri; bulut hesapları ve kimlik ve erişim yönetimi (IAM); sürekli entegrasyon ve sürekli teslimat (CI/CD) sistemleri ve gizli bilgiler; operasyonel konsollar; cüzdanlar ve onay iş akışları; imzalama sistemleri; defter ve para çekme hizmetleri; ve bunları birbirine bağlayan tedarikçiler. Bu bileşenler birlikte, müşterilerin ve iç ekiplerin fonla ilgili eylemleri nasıl başlattığını, onayladığını, imzaladığını, serbest bıraktığını ve mutabakat sağladığını yönetir. Kurum ve test ekibi ayrıca ilgili bakış açısı üzerinde anlaşmalıdır: dış bir saldırgan, normal bir kullanıcı, bir ortak, düşük ayrıcalıklı bir çalışan veya varsayılan olarak ele geçirilmiş bir kimlik.

Kapsamdaki her sistem, hesap, arayüz ve etkinliğin belirlenmiş bir sahibi ve net bir yetkilendirme yolu olmalıdır. Aynısı, saklama sağlayıcıları, cüzdan arayüzleri, uzaktan yordam çağrısı (RPC) sağlayıcıları, hizmet olarak yazılım (SaaS) platformları, kimlik sağlayıcıları, kod barındırma hizmetleri ve yönetilen hizmetler dahil olmak üzere üçüncü taraf bağımlılıkları için de geçerlidir. Bir sağlayıcının sahip olduğu bir ortamı test etmek, o sağlayıcının yazılı iznini gerektirir; kurumun tek başına verdiği yetkilendirme, sağlayıcının sistemlerine karşı etkinliği yetkilendirmeyebilir.

Hedef, kapsam ve yetkilendirme yolu birlikte, ekibin neyi değerlendirebileceğini belirler. Bir sonraki adım, ekibin bu değerlendirmeyi nasıl yapabileceğini kayıt altına alır.

Çalışma sınırları

Çalışma sınırları, görevlendirme üzerinde anlaşıldıktan sonra yürütmeyi yöneten yazılı kısıtlamalardır. Kapsamda olanı, hangi etkinliğe izin verildiğinden ayırırlar: üretimdeki bir para çekme hizmeti, yetkilendirme yolu doğrulaması için kapsamda olabilirken, gerçek müşteri para çekme işlemleri, özel anahtar çıkarma, kalıcılık değişiklikleri ve yük oluşturan saldırılar yasak kalır.

Bu ayrım, belirsizliğin operasyonel bir riske dönüşmesini önler. Üretim ortamında bir çalışma sırasında kurum ve test ekibinin, hangi tekniklere izin verildiğini, etkinliğin ne zaman durdurulması gerektiğini, bu kararı kimin verebileceğini ve kanıtların nasıl işlenebileceğini önceden bilmesi gerekir. Aksi takdirde, yetkilendirilmiş bir test bile önlenebilir hizmet veya müşteri etkisi yaratabilir.

RoE, test başlamadan önce bu kararları kayıt altına almalıdır. Ayrıca, belge her iki tarafın da çalışma sırasında temel soruları yeniden açmadan hareket edebileceği kadar kesin olmalıdır.

Aşağıdaki tablo, yukarıda belirlenen test görevlendirmesini pratik bir RoE kaydına dönüştürür. Test öncesi çözülmesi gereken kararları gruplandırır: neyin değerlendirildiği, kimin yetkilendirildiği, hangi etkinliklerin ve sınırların geçerli olduğu, tarafların nasıl koordine olduğu ve kanıtların nasıl işlendiği. Bu, değiştirilmeden kopyalanacak genel bir kontrol listesi değildir; kayıtlı değerler kurumun işletme modelini, test bakış açısını ve üretim riskini yansıtmalıdır.

RoE konusu Test öncesi kaydedilecek karar
Hedef ve kapsam İş kararı, kapsamdaki sistemler ve arayüzler, sahipler ve test edilecek saldırgan bakış açıları.
Yetkilendirme Yazılı yetki, test kimlikleri, onaylanmış erişim yolları ve üçüncü taraf ortamlar için sağlayıcı onayları.
Test yöntemi ve tamamlanma İzin verilen teknikler ve ekibin durması gereken nokta; örneğin gösterilmiş erişim, ayrıcalık yükseltme veya kontrollü bir iş akışı simülasyonu.
Çalışma sınırları Test pencereleri, istek hızı ve eşzamanlılık sınırları, hesap işlem sınırları, veri erişim sınırları, değişiklik dondurma dönemleri ve onaylı bir senaryonun bir işlem kullandığı durumlarda izin verilen ağ, test adresleri, işlem türleri, maksimum test değeri ve gas bütçesi.
Yasaklanmış etkinlik Örnekler arasında hizmet reddi testi, sosyal mühendislik, gerçek müşteri varlığı hareketleri, özel anahtar dışa aktarma, kalıcılık veya onaylanmamış üretim değişiklikleri bulunur.
Hassas iş akışları Belirlenmiş cüzdanlar ve hesaplar, izin listesindeki hedefler, maksimum test değeri, onay katılımcıları, beklenen politika davranışı, mutabakat adımları ve doğrulamanın ulaşabileceği işlem kontrol zincirindeki en uzak nokta.
İletişim ve duraklatma Rutin bildirim modeli, korunan güvenlik kanalı, yükseltme kişileri, önemli bulgu eşiği, testi duraklatma veya devam ettirme yetkisine sahip belirlenmiş kişi ve onaylı bir kamuya açık işlem yayını için beklenen gözlemlenebilirlik ve uyarı işleme.
Kanıt işleme Gerekli minimum kanıt, veri minimizasyonu ve düzenleme, şifreleme, onaylı alıcılar, saklama süresi, imha onayı ve onaylı bir test işlemi için iç onay ve defter kanıtına bağlı işlem karması ve ağ meta verileri.

Yürütme sınırları üzerinde anlaşmaya varıldıktan sonra, kurum testin karşılaşacağı dağıtılmış sistemleri ve çalışma koşullarını hazırlayabilir.

Çalışma ortamı ve canlı hizmet koruması

Çalışma ortamı, dağıtılmış sistem ve etrafındaki iş etkinliğidir: güven sınırları, fon akışları, hizmet bağımlılıkları, operasyonel iş akışları ve her bileşenden sorumlu kişiler. Bu, bir test bulgusunun gerçek anlamını kazandığı bağlamdır.

Bu bağlam önemlidir çünkü aynı teknik zayıflık çok farklı sonuçlara yol açabilir. Bir API sorunu, bulut izni veya onay iş akışı zayıflığı; müşteri verilerini, iç operasyonları, imzalama yetkisini, bakiye değişikliklerini veya para çekme işlemlerini etkileyebilir. Canlı bir borsa, ödeme şirketi, saklama sağlayıcısı veya cüzdan sağlayıcısı için, test aynı zamanda ticaret, ödeme, para yatırma, para çekme, takas ve destek operasyonlarıyla bir arada var olmalıdır.

Güncel bir görünüm; varlık ve hizmet envanterini, mimari ve entegrasyon noktalarını, bulut ve kimlik modelini, operasyonel iş akışlarını ve üçüncü taraf bağımlılıklarını kapsamalıdır. Planlama ayrıca ilgili iş pencerelerini, planlanmış sürümleri, değişiklik dondurmalarını, yüksek hacimli dönemleri, sıcak cüzdan etkinliğini ve diğer operasyonel olayları belirlemelidir. Test sırasında gözlemlenen hizmet sağlığı sinyalleri; işlem ve API hacimlerini, yanıt sürelerini, hata oranlarını, kuyruk derinliğini, imzalama hizmeti sağlığını ve cüzdan hizmeti kullanılabilirliğini içermelidir. Çalışma ortamı, işlemleri başlatmak ve kontrol etmek için kullanılan üretim hizmetlerini, kimlikleri, operasyonel iş akışlarını ve harici bağımlılıkları içerir. RoE, onaylanmış test ortamını, test kimliklerini, bir imzalama veya para çekme iş akışı içinde izin verilen adımları ve herhangi bir kontrollü doğrulama senaryosuna uygulanan önlemleri kayıt altına alır. Bu parametreler, değerlendirmeyi kurumun kontrolleri üzerinde odaklı tutarken normal müşteri ve operasyonel etkinliği korur.

Avrupa Birliği'nin Dijital Operasyonel Dayanıklılık Yasası (DORA), yüksek düzenlemeli bir referans noktası olarak faydalıdır. Tehdit odaklı sızma testi için seçilen finansal kuruluşlar için Madde 26, testin kritik veya önemli işlevleri kapsamasını ve bunları destekleyen üretim sistemleri üzerinde, ilgili dış kaynaklı bilgi ve iletişim teknolojisi (ICT) hizmetleri de dahil olmak üzere gerçekleştirilmesini gerektirir [2]. Bu, üretim testi için genel bir yetkilendirme değildir; her kurumun yine de kendi yetkisine, önlemlerine ve geçerli yasal ve sözleşmeye dayalı onaylarına ihtiyacı vardır.

Bu üretim temeli, kurumun fonları veya müşteri erişimini doğrudan etkileyebilecek iş akışlarına daha spesifik önlemler uygulamasına olanak tanır.

Hassas iş akışları için sınırlar

Hassas iş akışları, normal işleyişi fonları, müşteri erişimini veya kayıtların bütünlüğünü doğrudan etkileyebilecek sistemler ve eylemlerdir. Bunlar; imzalama ve para çekme iş akışlarını, ayrıcalıklı üretim erişimini, müşteri veri işlemeyi ve defter işlemlerini içerir.

Bu iş akışları daha katı sınırlara ihtiyaç duyar çünkü gerçekçi bir test aksi takdirde bir kontrolü doğrulamaktan bir müşteri veya finansal sonucu değiştirmeye geçebilir. Risk yalnızca teknik kesinti değildir: yetkisiz fon hareketi, yanlış bakiyeler, hassas verilerin açığa çıkması veya test etkinliği ile gerçek bir olay arasındaki karışıklığı da içerebilir. Bir kontrol hatasının fonları etkileyebileceği durumlarda, geri alma zor veya imkansız olabilir, bu nedenle bu sınırlar bir testin herhangi bir istenmeyen veya yetkisiz fon hareketi üretmesini önlemelidir.

İmzalama ve para çekme iş akışları, kurumun bir isteği nasıl doğruladığını, politikayı nasıl uyguladığını, onayları nasıl yönlendirdiğini ve sonucu nasıl mutabakata bağladığını doğrulayan kontrollü senaryolar gerektirir. RoE, belirlenmiş test hesaplarını, yetkili katılımcıları, beklenen politika davranışını, senaryo için üst sınırı ve iş akışını doğrulamak için gereken kanıtı belirler. Ardından izin verilen en uzak iş akışı adımını kayıt altına alır: istek oluşturma, politika kararı, onay gösterimi, imzalama isteği, serbest bırakma kararı veya mutabakat. Test kimlikleri, üzerinde anlaşılan erişim süreci aracılığıyla sağlanır, kullanılır ve devre dışı bırakılır. Aynı disiplin ayrıcalıklı erişim, müşteri verileri ve defter işlemleri için de geçerlidir: erişim modeli, beklenen sistem davranışı ve kanıt sınırı test başlamadan önce üzerinde anlaşılır; müşteri verilerine yalnızca gerekli olduğunda erişilir, kanıtlarda minimize edilir ve düzenlenir ve onaylı kanıt deposunda tutulur.

Bu kontroller, hassas yolları sıradan uygulama işlevleri gibi ele almadan üretimde test etmeyi mümkün kılar. Ayrıca operasyonlara ve test ekibine canlı etkinliği koordine etmek için ortak bir temel sağlar.

Test ve koordinasyon

Test ve koordinasyon, çalışma için canlı işletme modelidir. Test devam ederken hizmet sahibini, güvenlik operasyonları ekibini, olay müdahale işlevini ve test liderini birbirine bağlar.

Bu model gereklidir çünkü beklenen test etkinliği ile gerçek bir güvenlik olayı birbirine benzeyebilir. İzleme, bildirimler veya duraklatma kararları net değilse, test etme olay müdahalesini geciktirebilir veya üretim eyleminin gerekli olup olmadığı konusunda belirsizlik yaratabilir.

İletişim modeli, tam test planını kimin bildiğini, zamana duyarlı bildirimleri kimin aldığını ve etkinliği kimin duraklatıp devam ettirebileceğini belirler. Hedefe göre değişir: bazı testler hassas sistemler etrafında yakın güvenlik operasyon merkezi (SOC) koordinasyonu gerektirirken, sınırlı ifşalı testler izlemenin etkinliği tespit edip etmediğini ve yükseltmenin doğru kişilere ulaşıp ulaşmadığını değerlendirir. Kontrollü bir senaryonun işlemle ilgili bir iş akışını çalıştırdığı durumlarda, plan ayrıca saklama, cüzdan, işlem tarama ve izleme sağlayıcılarından gelen ilgili bildirimleri ve beklenen uyarıları da kapsar. Ayrı bir güvenlik iletişim kişisi ve belirlenmiş duraklatma yetkilisi her zaman ulaşılabilir kalır. Hizmet sahibi ve test ekibi; hata bütçesinden sapma, 95. yüzdelik (p95) yanıt süresinde veya kuyruk derinliğinde beklenmeyen artışlar, şüpheli hesap veya cüzdan etkinliği, önemli mutabakat tutarsızlıkları veya planlanmamış bir güvenlik uyarısı gibi ölçülebilir durdurma kriterleri üzerinde anlaşır.

Bu hazırlık aynı zamanda operasyonel dayanıklılığı da güçlendirir. Hong Kong Menkul Kıymetler ve Vadeli İşlemler Komisyonu (SFC), sanal varlık ticaret platformu operatörlerinin 7/24 izleme ve belgelenmiş yükseltme prosedürleri sürdürmesini ve ilgili üçüncü taraflarla acil durum ve iş sürekliliği tatbikatları yapmasını beklemektedir [3]. Bu düzenleyici referanslar örnek niteliğindedir, hukuki tavsiye değildir; uygulanabilirlik yargı yetkisine özgüdür ve avukatla teyit edilmelidir.

Şekil 2. Test ve koordinasyon kontrol döngüsü.
Şekil 2. Test ve koordinasyon kontrol döngüsü.

Diyagram, test devam ederken geçerli olan kontrol döngüsünü göstermektedir. Ana noktası, RoE sınırlarının yetkilendirmeyle sona ermediğidir: izleme ve güvenlik kanalı, bu sınırları devam ettirme, duraklatma, sınırlama veya doğrulanmış bir bulguyu düzeltmeye aktarma kararlarına dönüştürür. Bu, kapsamın erken tanımına veya üretim hazırlığına değil, canlı koordinasyona ait olduğu için burada yer almaktadır.

Aynı model kritik bulguları da yönetir: yetkisiz fon hareketine gösterilmiş bir yol, imzalama yetkisinin veya bir üretim kontrol düzleminin ele geçirilmesi, son derece hassas müşteri verilerinin açığa çıkması veya kritik bir hizmete yönelik önemli risk. Yanıt yolu; yükseltme eşiğini, bulguyu sınıflandıran kişileri, ilgili etkinliği duraklatma yetkisini ve sınırlama, iyileştirme ve doğrulama sürecini belirlemelidir. Sızma testi ekibi sorunu gösterir ve raporlar; kurum üretim kararları, müşteri iletişimi ve iyileştirme için yetkiyi elinde tutar. Önemli bir bulgu bildirimi öncelikle korunan güvenlik kanalını, ardından gereksiz istismar ayrıntısını açığa çıkarmayan üzerinde anlaşılmış yazılı bir kaydı kullanmalıdır.

Bir bulgu sınırlandırılıp atandıktan sonra, çalışmanın değeri kurumun bu sonucu doğrulanmış bir kontrol iyileştirmesine dönüştürüp dönüştüremeyeceğine bağlıdır.

İyileştirme, yeniden test ve normale dönüş

İyileştirme ve yeniden test, gösterilen bir zayıflığı doğrulanmış bir iyileştirmeye dönüştüren kapanış sürecidir. Normale dönüş de aynı sürecin bir parçasıdır: test erişimi, kontrollü senaryolar ve toplanan kanıtlar yeni, uzun ömürlü bir risk haline gelmemelidir.

Bu son aşama, çalışmanın riski azaltıp azaltmadığını veya yalnızca bir rapor mu ürettiğini belirler. Sahibi, iyileştirme yolu ve doğrulama koşulu olmayan bir bulgu, aynı saldırı yolu üretimde devam ederken açık kalabilir.

Test başlamadan önce, bulguların mühendislik, bulut, cüzdan operasyonları veya iş kontrolü iş akışlarına nasıl girdiğini; iyileştirmenin kimin sorumluluğunda olduğunu; ve hangi bulguların yeniden test gerektirdiğini belirleyin. Kapanışta, geçici test kimlikleri, izinleri ve kontrollü senaryolar amaçlanan yapılandırmalarına döner ve hizmet sahipleri ilgili sağlık göstergelerinin beklenen aralıkta kaldığını doğrular. Nihai kayıt, her bulguyu kanıtına, etkisine, sahibine, iyileştirme planına ve yeniden test koşuluna bağlar. Kontrollü bir işlemle ilgili senaryo için, ayrıca iş akışı referansını, test kimliğini, zaman damgasını, onay kaydını ve sonuçtaki defter girişini de bağlar; senaryo için oluşturulan herhangi bir geçici erişim, onay veya test yapılandırması devre dışı bırakılır. Kanıtlar yalnızca üzerinde anlaşılan süre boyunca saklanır, ardından güvenli bir şekilde imha edilir veya iade edilir.

Sonuç, bir güvenlik açığı listesi değil, kurumun bir sonraki işletme kararını destekleyebilecek test edilmiş, iyileştirilmiş ve yeniden test edilmiş bir kontrol setidir.

Sonuç

Blok zinciri sızma testine hazırlanmak kurumsal bir görevdir. Kurum; hedefi, çalışma bağlamını, yetkiyi, hizmet kısıtlamalarını ve yanıt modelini tanımlar; test ekibi bu hazırlanmış ortama düşmanca doğrulama uygular.

Bu unsurlar yerinde olduğunda, bir sızma testi çalışması teknik bir egzersizden daha fazlası haline gelir. Kurumun dağıtılmış sistemlerinin, insanlarının ve süreçlerinin saldırı altında nasıl dayandığını anlamanın kontrollü bir yolu haline gelir.

BlockSec, kurumların bu süreci hazırlamasına ve yürütmesine yardımcı olur: kapsamı tanımlamak, çalışma ortamını haritalamak, RoE ve üretim önlemlerini oluşturmak ve bulguları iyileştirilmiş ve yeniden test edilmiş kontrollere dönüştürmek. Bir sonraki testiniz için katılım kurallarını ve üretim güvenliği kontrollerini planlamak amacıyla bir kapsam belirleme görüşmesi talep edin; talep üzerine daha fazla bilgi mevcuttur.

Diziye devam edin:

Ayrıca bu dizide, yakında yayınlanacak:

  • Bölüm 5: Yetkilendirme ve İmzalama Güvenliği: Web, dApp'ler ve
  • Bölüm 6: Bulut ve CI/CD Güvenliği: Otomatik Operasyon Saldırı Yüzeyleri
  • Bölüm 7: Hazine Kontrol Düzlemi Güvenliği: İmzalama ve Para Çekme Onayları
  • Bölüm 8: Borsa Defteri Güvenliği: Hırsızlık Yolları ve Veri Düzlemi Mantığı

Blockchain Penetration Testing ana sayfası, çalışma düzeyinde bir görünüm sağlar.

Kaynaklar

İlk görünüm sırasına göre numaralandırılmıştır.

  1. Ulusal Standartlar ve Teknoloji Enstitüsü, Rules of Engagement (ROE), CSRC Sözlüğü.
  2. Avrupa Birliği, Tüzük (AB) 2022/2554 — Dijital Operasyonel Dayanıklılık Yasası (DORA), Madde 26.
  3. Hong Kong Menkul Kıymetler ve Vadeli İşlemler Komisyonu, Sanal Varlıkların Saklanmasına İlişkin Lisanslı Sanal Varlık Ticaret Platformu Operatörlerine Genelge (15 Ağustos 2025).

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit