320 Milyon Dolarlık Liquid Network Olayının Ardından: Bir Savunma Hattı Düştü, Dijital Varlık Platformları Neyi Koruyabilir?
Son dönemde art arda yaşanan güvenlik olayları, dijital varlık sektörünü yine tanıdık bir soruya geri getirdi: Bir platform tam olarak ne zaman "güvenli" sayılır?
Eylül başında, Bitcoin yan zinciri Liquid Network'te büyük bir güvenlik olayı yaşandı. Saldırganlar, Elements yazılımındaki bir doğrulama açığını kullanarak, olay anındaki fiyatla yaklaşık 320 milyon dolar değerinde olan yaklaşık 4.000 BTC'nin transfer edilmesine neden oldu. Dikkat çeken nokta, ilgili PAK ve Federation keys'in kendilerinin ele geçirilmemiş olmasıydı. Bu da tartışılması gereken daha önemli bir soruyu gündeme getirdi: Anahtarlar ele geçirilmemişken, gerçekleşmemesi gereken bir varlık transferi sistemi nasıl aşabildi?
Benzer riskler başka alanlarda da ortaya çıktı. Ağustos ayında saldırganlar, Cosmos EVM'deki kritik bir güvenlik açığını kullanarak birden fazla ağa saldırdı; toplam 6 ağ fiilen istismar edildi ve ilgili açık daha önce bir bug bounty programı aracılığıyla bildirilmişti. Temmuz ayında ise Triple-A, bir sosyal mühendislik atağına maruz kaldı; saldırganlar ilgili personelin kimlik bilgilerini ele geçirip operasyon ortamına sızdı ve sonuçta şirketin kendi varlıklarının bir kısmı transfer edildi. Ancak müşteri fonları, ihlal edilen operasyon ortamından ayrı olarak trust hesaplarında tutulduğu için etkilenmedi.
Üç olayın nedenleri farklı olsa da hepsi daha gerçekçi bir soruna işaret ediyor: Güvenlik olaylarını tamamen önlemek belki zor, ancak kod, insan veya yetki halkalarından biri aşıldığında risk tam olarak nerede durur?
Asıl korunması gereken sadece "ele geçirilmemek" değil, riskin ne kadar ilerleyebileceğidir
"Saldırıya uğrayıp uğramadığı" sorusundan daha önemli olan soru şudur: İlk güvenlik hattı düştükten sonra saldırgan ne kadar ilerleyebilir? Bir hesabın ele geçirilmesi, kritik varlık işlemlerini tamamlamak için yeterli midir? Bir yetki aşıldığında, daha çekirdek sistemlere erişim devam edebilir mi? Çevrimiçi ortamda bir sorun çıktığında, saldırı yolunda gerçekte ne kadar kritik varlık açığa çıkar?
Bu, son dönemdeki olayların ortaya koyduğu önemli bir derstir: Bir saldırının nihai etkisi, yalnızca saldırganın neyi aştığına değil, aynı zamanda aşmanın ardından sistemde kaç savunma hattının kaldığına da bağlıdır.
Bir hesap ele geçirildiğinde doğrudan çekirdek yetkilere ulaşılabiliyorsa; çevrimiçi ortamda bir sorun çıktığında çok sayıda kritik varlık doğrudan etkilenebiliyorsa, o zaman herhangi bir zayıf halka hızla büyütülebilir. Buna karşılık, yetkiler, kritik işlemler, risk izleme ve varlık saklama arasında çok katmanlı yalıtım varsa, tek bir ihlal mutlaka tam bir çöküşe dönüşmeyebilir.
Başka bir deyişle, bir platformun güvenlik kapasitesini ölçerken sadece "ilk güvenlik kapısının dayanıp dayanamayacağına" değil, aynı zamanda şuna da bakmak gerekir: İlk güvenlik kapısı düştükten sonra arkada kaç kapı daha var?
Saldırı zinciri boyunca bakıldığında, BIT'in "bir sonraki kapısı" nerede?
Son dönemde, küresel dijital finansal hizmet platformu BIT (eski adıyla Matrixport), "BIT Güven Beyaz Kitabı" V2.0'ı yayımladı (https://www.bit.com/whitepaper). Bu beyaz kitabı "ilk savunma hattı düştükten sonra ne olur?" sorusuyla yeniden okuduğumuzda dikkat çeken bir nokta var: BIT'in güvenlik sistemi tek bir savunma hattına dayanmıyor; kimlik, yetki, işlem ve varlıklar arasında çok katmanlı koruma sağlıyor.

Örneğin, bir hesap kimlik bilgisinin ele geçirilmesi, saldırganın kritik varlık işlemlerini tamamlamak için gereken tüm yetkilere sahip olduğu anlamına gelmez. Beyaz kitapta, BIT'in en az yetki ilkesiyle çalışanların erişebileceği sistemleri ve işlem kapsamını sınırladığı; varlık transferi, hesap güvenliği, yetki değişikliği, işlem emri oluşturma ve onaylama gibi kritik işlemlerin en az iki yetkili kişinin ortak katılımını gerektirdiği açıklanıyor. Cactus Custody örneğinde olduğu gibi, bu katmanlı yaklaşım kurumsal dijital varlık saklama senaryolarına da uzanıyor.
Kimlik doğrulamasından geçmek, sonraki işlemlerin tamamen "yeşil ışık" alacağı anlamına da gelmez. BIT, anormal girişler, anormal cihazlar ve anormal para çekme gibi davranışları sürekli olarak izler; varlık tarafında ise dijital varlıkların büyük çoğunluğu soğuk cüzdanlarda tutulur, böylece çevrimiçi ortamda bir sorun çıktığında kritik varlıkların maruziyeti daha da azalır.
Bu mekanizmalar bir araya getirildiğinde, BIT'in güvenlik mantığı daha net hale gelir: Bir kimliğin aşılması, tüm yetkilerin elde edilmesi anlamına gelmez; bir yetkinin elde edilmesi, kritik işlemlerin bağımsız olarak tamamlanabileceği anlamına gelmez; kimlik doğrulamasından geçmek, sonraki davranışların artık risk analizine tabi olmayacağı anlamına gelmez; çevrimiçi ortamda bir sorun çıkması, tüm kritik varlıkların aynı anda açığa çıkacağı anlamına gelmez.
Bir saldırının nihai olarak ne kadar ilerleyebileceğini belirleyen şey tam da bu "eşit değildir" ifadeleridir. Bu, hiçbir saldırının tamamen önlenebileceği anlamına gelmez; ancak bir savunma hattında sorun çıksa bile, anormalliği tespit etme, yetkileri kısıtlama veya riski yalıtma fırsatının hâlâ var olduğu anlamına gelir.
Güvenlikteki fark, çoğu zaman ilk güvenlik kapısı düştükten sonra gizlidir.
Risk tespit edildiğinde, gerçekten "durdurma düğmesine" basma yetkisi kimde?
Ancak birkaç teknik savunma hattı eklemek her şey değildir. Cosmos EVM olayında dikkat çeken bir ayrıntı, ilgili açığın daha önce bir bug bounty programı aracılığıyla bildirilmiş olması, ancak o dönemdeki bilgilere göre başlangıçta bilinen üretim ağı yapılandırmalarında fon kaybına yol açmayacağı şeklinde değerlendirilmiş olmasıdır.
Bu da sıklıkla göz ardı edilen başka bir sorunu ortaya çıkarıyor: Bir riskin tespit edilmesi, riskin doğru bir şekilde değerlendirildiği ve yeterince ele alındığı anlamına gelmez.
Bir açık bildirildikten sonra, ne kadar ciddi olduğuna kim karar verir? Güvenlik ekibi riskin kabul edilemez olduğunu düşünüyorsa, ürünün yayına devam etmesini engelleme yetkisine sahip midir? İş takvimi ile güvenlik değerlendirmesi çatıştığında, son kararı kim verir?
"BIT Güven Beyaz Kitabı" V2.0, ürün planı, gereksinim, mimari veya yayın değişikliğinde önemli bir güvenlik riski bulunduğunda ya da güvenlik taban çizgisi ve uyumluluk gereklilikleri karşılanmadığında, güvenlik ekibinin "tek taraflı veto yetkisine" sahip olduğunu; ilgili faaliyetleri durdurabileceğini, düzeltme ve yeniden inceleme talep edebileceğini ve ancak ondan sonra devam edilebileceğini açıklıyor.
Bu mekanizmanın asıl dikkat çekici yanı, yalnızca bir onay adımı eklemesi değil, çok pratik bir soruya yanıt vermesidir: Risk gerçekten ortaya çıktığında, "hayır" deme yetkisine sahip biri var mı? Bir güvenlik sistemi için sorunları tespit etme yeteneği elbette önemlidir, ancak güvenlik değerlendirmesinin iş kararlarını gerçekten etkileyebilmesi de bir savunma hattının yalnızca kâğıt üzerinde mi kaldığını yoksa gerçekten işlev görüp görmediğini belirler.
İşler giderek karmaşıklaştıkça, "güvenlik" yalnızca cüzdandaki varlıklardan ibaret değildir
Dijital finans platformları aynı anda dijital varlıklar, ABD hisse senetleri, RWA gibi farklı türde varlıkları ve finansal altyapıları birbirine bağlamaya başladığında, güvenlik sorunları da artık yalnızca cüzdan ve hesap düzeyinde yaşanmıyor. Varlıkları kimin işlediği, hangi kurumlardan geçtiği, nerede takas edildiği ve saklandığı da kullanıcıların risk değerlendirmesinin önemli bir parçası haline geliyor.
Bu, "BIT Güven Beyaz Kitabı" V2.0'ın güvenlik ve güven sistemini daha da genişlettiği noktadır. Risk kontrolü ve güvenlik önlemlerinin yanı sıra beyaz kitap, farklı iş birimlerine karşılık gelen düzenleme, denetim ve bağımsız doğrulama düzenlemelerini de açıklayarak dış dünyanın şunları daha iyi değerlendirmesine olanak tanır: Kim neyden sorumlu, hangi mekanizmalar doğrulanabilir ve bu mekanizmalar nereye kadar uzanıyor?
BIT'in ABD hisse senedi işini örnek alırsak, menkul kıymet işleri Matrix Gelephu Pte. Ltd. tarafından yürütülmekte ve GFSO tarafından denetlenmektedir; ilgili işler aynı zamanda ABD'de lisanslı finans kurumlarına ve ilgili takas ve saklama altyapılarına bağlıdır.
Sıradan kullanıcılar için karmaşık görünen bu finansal düzenlemeler aslında birkaç basit soruya indirgenebilir: Varlıklarımı kim işliyor? Hangi aşamalardan geçiyor? Farklı kurumlar neyden sorumlu? Bu kurumların kimlikleri ve düzenleyici durumları doğrulanabilir mi?
"Doğrulanabilirlik"in gerçek anlamı da buradadır; güvenlik yalnızca platformun kendi söylediklerine dayanamaz, aynı zamanda kullanıcıların ve dış dünyanın neyi doğrulayabildiğine de bağlıdır.
Liquid Network, Cosmos EVM ve Triple-A olaylarına dönüp baktığımızda, üç olayın giriş noktaları tamamen farklı olsa da hepsi piyasaya aynı şeyi hatırlatıyor: Hiçbir savunma hattının asla çökmeyeceği varsayılmamalıdır. Güvenlik farkını asıl yaratan şey, tek bir güvenlik teknolojisinin kendisi değil; kimin kimlik, yetki, işlem, varlık ve organizasyonel karar alma arasında yeterli izolasyon ve denge kurabildiği, böylece yerel bir ihlalin tam bir çöküşe dönüşmesini zorlaştırdığıdır.
Bu açıdan bakıldığında, "BIT Güven Beyaz Kitabı" V2.0'da dikkat çeken şey yalnızca kaç güvenlik önlemi listelediği değil, bu önlemlerin eksiksiz bir savunma hattı oluşturup oluşturamadığıdır: Bir halkada sorun çıkarsa bir sonraki katman devreye girer; bir sonraki katmanda da sorun çıkarsa riski tespit etme, engelleme ve izole etme fırsatı hâlâ vardır.
Dijital varlık platformları için "hiç saldırıya uğramadık" demek kalıcı bir taahhüt olmayabilir. Ancak sürekli olarak inşa edilebilecek başka bir şey vardır: Gerçek güvenlik, bir savunma hattı çökse bile tek bir ihlalin kolayca tam bir çöküşe dönüşmesine izin vermemektir. Ve bu savunma hatları yalnızca var olmakla kalmayıp dış dünya tarafından sürekli olarak doğrulanabildiğinde, "güven" artık yalnızca platformun kendi söylediği bir söz olmaktan çıkar.
Bu içerik yalnızca bilgilendirme ve eğitim amaçlıdır ve BTCC ile ilgili yatırım tavsiyesi teşkil etmez. BTCC yukarıdaki içeriğin doğruluğunu, kesinliğini veya özgünlüğünü garanti etmek için elinden geleni yapmaktadır ancak bu konuda garanti veremez.