Kurumsal Blockchain Sızma Testi için Kural ve Üretim Güvenliği

Bu serideki ilk iki makale, 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 koydu. Bu makale, kurumsal bir çalışmanın nasıl hazırlandığına ve güvenli bir şekilde nasıl yürütüldüğüne odaklanıyor: çalışma 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ü.

Web3, üretim ortamında test yapmanın riskini belirli bir şekilde artırır: zincir üstü eylemler genellikle geri alınamaz, test etkinlikleri çoğu zaman zincir üstünde herkese açık şekilde görülebilir ve kapsam dahilindeki sistemler gerçek fonları hareket ettirebilir. Bu nedenle aşağıdaki önlemler, geleneksel bir çalışmaya kıyasla ortam seçimine, değer sınırlarına, anahtar yönetimine ve mutabakata çok daha fazla ağırlık verir.

İşletim yetkisi olarak RoE

ABD Ulusal Standartlar ve Teknoloji Enstitüsü'ne (NIST) göre, RoE güvenlik testi için yönergeleri ve kısıtlamaları belirler [1]. Kurumsal bir çalışma için RoE, test yapma kararını yetkilendirilmiş bir görevlendirmeye dönüştürür: tanımlı bir hedef, tanımlı bir kapsam ve harekete geçme yetkisine sahip isimlendirilmiş bir otorite.

Bu görevlendirme önemlidir, çünkü bir test ekibi yetkisini güvenli bir şekilde bir sözleşmeden veya varlık listesinden çıkaramaz. Değerlendirilen risk, dahil olan sistemler ve bunlardan sorumlu kişiler hakkında ortak bir karar olmadan, ekip yanlış bir yolu test edebilir, kritik bir bağımlılığı dışarıda bırakabilir veya önemli bir bulguyu doğrulama yetkisinden yoksun kalabilir.

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 ya da üçüncü taraf bir entegrasyonu değerlendirebilir. Bu hedef, önemli olan sistemleri, azaltılması gereken riski ve yönetimin karar vermesi için gereken sonucu belirler.

Hedef, işletim modelini takip eden 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 bir arada, müşterilerin ve dahili ekiplerin fonlarla ilgili eylemleri nasıl başlattığını, onayladığını, imzaladığını, yayınladığını ve mutabakatını yaptığını yönetir. Kurum ve test ekibi ayrıca ilgili bakış açısı üzerinde de anlaşmalıdır: harici bir saldırgan, normal bir kullanıcı, bir ortak, düşük ayrıcalıklı bir çalışan veya güvenliği ihlal edilmiş varsayılan bir kimlik.

Kapsam dahilindeki her sistem, hesap, arayüz ve etkinliğin isimlendirilmiş bir sahibi ve net bir yetkilendirme yolu olmalıdır. Bu durum, 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ıya ait ortamın test edilmesi, o sağlayıcının yazılı iznini gerektirir; kurumun tek başına verdiği yetkilendirme, sağlayıcının sistemlerine yönelik etkinliği yetkilendirmeyebilir.

Hedef, kapsam ve yetkilendirme yolu bir arada, ekibin neyi değerlendirebileceğini belirler. Bir sonraki adım, ekibin bu değerlendirmeyi nasıl gerçekleştirebileceğini kaydeder.

İşletim sınırları

İşletim sınırları, görevlendirme üzerinde anlaşmaya varıldıktan sonra uygulamayı yöneten yazılı kısıtlamalardır. Kapsam dahilinde olanı, izin verilen etkinlikten ayırırlar: üretim ortamındaki bir para çekme hizmeti, yetkilendirme yolu doğrulaması için kapsam dahilinde olabilirken, gerçek müşteri para çekme işlemleri, özel anahtar çıkarımı, 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. Bir üretim çalışması sırasında, kurumun 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 ele alınabileceğini önceden bilmesi gerekir. Aksi takdirde, yetkilendirilmiş bir test bile önlenebilir hizmet veya müşteri etkisi yaratabilir.

RoE, test başlamadan önce bu kararları kaydetmelidir. Ayrıca belge, her iki tarafın da çalışma sırasında temel soruları yeniden gündeme getirmeden hareket edebilmesi için yeterince 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 başlamadan önce çö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 koordinasyon sağladığı ve kanıtların nasıl ele alındığı. Bu, değiştirilmeden kopyalanacak genel bir kontrol listesi değildir; kaydedilen değerler kurumun işletim modelini, test bakış açısını ve üretim riskini yansıtmalıdır.

Yürütme sınırları üzerinde anlaşmaya varıldıktan sonra kurum, testin karşılaşacağı devreye alınmış sistemleri ve işletim koşullarını hazırlayabilir.

İşletim ortamı ve canlı hizmet koruması

İşletim ortamı, devreye alınmış sistem ve bunun 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, dahili operasyonları, imzalama yetkisini, bakiye değişikliklerini veya para çekme işlemlerini etkileyebilir. Canlı bir borsa, ödeme şirketi, saklama kuruluşu 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, mimariyi 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, planlanan sürümleri, değişiklik dondurma dönemlerini, 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. İşletim 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, onaylı test ortamını, test kimliklerini, bir imzalama veya para çekme iş akışı içindeki izin verilen adımları ve herhangi bir kontrollü doğrulama senaryosuna uygulanan önlemleri kaydeder. Bu parametreler, değerlendirmenin kurumun kontrolleri üzerine odaklanmasını sağlarken normal müşteri ve operasyonel etkinliği korur.

Avrupa Birliği'nin Dijital Operasyonel Dayanıklılık Yasası (DORA), yüksek düzeyde düzenlenmiş faydalı bir referans noktası sunar. 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ışarıdan temin edilen bilgi ve iletişim teknolojisi (ICT) hizmetleri dahil olmak üzere gerçekleştirilmesini şart koşar [2]. Bu, üretim ortamında test yapmak 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ını sağlar.

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 arasında imzalama ve para çekme iş akışları, ayrıcalıklı üretim erişimi, müşteri verisi işleme ve defter işlemleri bulunur.

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, hatalı bakiyeler, hassas verilerin ifşası veya test etkinliğiyle gerçek bir olay arasındaki karışıklığı da içerebilir. Bir kontrol arızasının fonları etkileyebileceği durumlarda, geri alma zor veya imkansız olabilir; bu nedenle bu sınırlar, bir testin istenmeyen veya yetkisiz herhangi bir fon hareketi oluşturmasını önlemelidir.

İmzalama ve para çekme iş akışları, kurumun bir talebi nasıl doğruladığını, politikayı nasıl uyguladığını, onayları nasıl yönlendirdiğini ve sonucun mutabakatını nasıl yaptığını doğrulayan kontrollü senaryolar gerektirir. RoE, belirlenmiş test hesaplarını, yetkilendirilmiş 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 ileri iş akışı adımını kaydeder: talep oluşturma, politika kararı, onay gösterimi, imzalama talebi, yayınlama kararı veya mutabakat. Test kimlikleri, üzerinde anlaşmaya varı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 kararlaştırılır; müşteri verilerine yalnızca gerekli olduğunda erişilir, kanıtlarda en aza indirilir ve gizlenir, ve onaylı kanıt deposu içinde tutulur.

Bu kontroller, hassas yolları sıradan uygulama işlevleri gibi ele almadan üretim ortamında test etmeyi mümkün kılar. Ayrıca operasyonlar 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şletim modelidir. Test devam ederken hizmet sahibini, güvenlik operasyonları ekibini, olay müdahale işlevini ve test liderini bir araya getirir.

Bu model gereklidir, çünkü beklenen test etkinliği ile gerçek bir güvenlik olayı birbirine benzer görünebilir. İzleme, bildirimler veya duraklatma kararları net değilse, test etkinliği 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 duraklatabileceğini veya sürdürebileceğini belirler. Bu hedefe göre değişir: bazı testler hassas sistemler etrafında yakın güvenlik operasyon merkezi (SOC) koordinasyonu gerektirirken, sınırlı bilgilendirmeli testler izlemenin etkinliği tespit edip etmediğini ve yükseltmenin doğru kişilere ulaşıp ulaşmadığını değerlendirir. Kontrollü bir senaryo işlemle ilgili bir iş akışını çalıştırdığında, 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 noktası ve isimlendirilmiş duraklatma yetkisi her zaman ulaşılabilir durumda kalır. Hizmet sahibi ve test ekibi; hata bütçesinden sapma, 95. yüzdelik dilim (p95) yanıt süresi veya kuyruk derinliğinde beklenmedik 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, 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ı yürütmesini beklemektedir [3]. Bu düzenleyici referanslar açıklayıcı niteliktedir, hukuki tavsiye değildir; uygulanabilirlik yargı bölgesine özgüdür ve bir avukatla teyit edilmelidir.

Diyagram, test devam ederken geçerli olan kontrol döngüsünü göstermektedir. Buradaki temel nokta, RoE sınırlarının yetkilendirmede sona ermediğidir: izleme ve güvenlik kanalı, bu sınırları sürdürme, duraklatma, kontrol altına alma veya doğrulanmış bir bulguyu iyileştirmeye devretme kararlarına dönüştürür. Burada yer almasının nedeni, bu kararların daha önceki kapsam tanımına veya üretim hazırlığına değil, canlı koordinasyona ait olmasıdır.

Aynı model kritik bulgular için de geçerlidir: yetkisiz fon hareketine giden kanıtlanmış bir yol, imzalama yetkisinin veya bir üretim kontrol düzleminin ele geçirilmesi, son derece hassas müşteri verilerinin ifşası veya kritik bir hizmet için önemli bir risk. Müdahale yolu, yükseltme eşiğini, bulguyu sınıflandıran kişileri, ilgili etkinliği duraklatma yetkisini ve kontrol altına alma, 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 konusunda yetkiyi elinde tutar. Önemli bir bulgu bildirimi öncelikle korumalı güvenlik kanalını kullanmalı, ardından gereksiz istismar ayrıntısı ifşa etmeyen, üzerinde anlaşmaya varılmış yazılı bir kayıt izlemelidir.

Bir bulgu kontrol altına alındıktan ve sorumluya 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, kanıtlanmış 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 ve uzun ömürlü bir risk haline gelmemelidir.

Bu son aşama, çalışmanın riski azaltıp azaltmadığını yoksa 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 gireceğini; iyileştirmenin kime ait olduğunu ve hangi bulguların yeniden test gerektirdiğini belirleyin. Kapanışta, geçici test kimlikleri, izinler ve kontrollü senaryolar amaçlanan yapılandırmalarına geri döner ve hizmet sahipleri ilgili sağlık göstergelerinin beklenen aralık içinde 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ü, işlemle ilgili bir senaryo için ayrıca iş akışı referansını, test kimliğini, zaman damgasını, onay kaydını ve ortaya çıkan defter kaydını da bağlar; senaryo için oluşturulan geçici erişim, onay veya test yapılandırması devre dışı bırakılır. Kanıtlar yalnızca üzerinde anlaşmaya varı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şletim kararını destekleyebilecek, test edilmiş, iyileştirilmiş ve yeniden test edilmiş bir dizi kontroldür.

Sonuç

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

Bu unsurlar yerine oturduğunda, bir sızma testi çalışması teknik bir alıştırmadan daha fazlası haline gelir. Kurumun devreye alınmış sistemlerinin, insanlarının ve süreçlerinin bir 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, işletim ortamını haritalandırmak, RoE ve üretim önlemlerini oluşturmak ve bulguları iyileştirilmiş ve yeniden test edilmiş kontrollere dönüştürmek. Bir sonraki testiniz için çalışma 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.

Seriye devam edin:

• Bölüm 4: Web3 Saldırı Yüzeyleri: Sızma Testine Genel Bakış

Bu serinin yakında yayınlanacak diğer bölümleri:

• Bölüm 5: Yetkilendirme ve İmzalama Güvenliği: Web, dApp'ler ve Mobil
• 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 sunar.

Referanslar

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

1. Ulusal Standartlar ve Teknoloji Enstitüsü, Çalışma Kuralları (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).