Özel Anahtar Tutmak Dijital Varlık Güvenliği İçin Yeterli Değil

Çok taraflı hesaplama (MPC) cüzdanları, dijital varlıklarını kendi kendine saklamak isteyen kurumlar için hâkim yöntemdir. Genellikle bu, müşterinin cihazında bir anahtar payını, satıcının ise diğerini tuttuğu 2‑den‑2 imza şemasıdır. Sağlayıcıya tüm anahtarı güvenmek ve sağlayıcı, sorumluluklarını varlıklarla bire bir teminatlamıyorsa, bir varlık üzerindeki doğrudan mülkiyet iddiasını kısmi mülkiyet iddiasıyla değiştirmekten daha iyidir. Ancak bu, dijital varlıkların kontrol ve mülkiyetinin ne anlama geldiğinin yalnızca yüzeyini kazımaktadır. Mimaride, anahtar kullanımını (veya kötüye kullanımını) belirleyen birden fazla başka bileşen vardır ve şu anda bir SaaS kara kutu şeklinde sunulmaktadır. MPC cüzdanlarına ışık tutma ve sadece bir anahtar payını tutmanın, somut bir kontrol ya da kendi kendine saklama konusunda meşru bir iddia sağlamaktan ne kadar uzak olduğunu gösterme zamanı.

Kurumların Dijital Varlık Saklama Evrimindeki Rolü

Şaşırtıcı olmayan bir şekilde, büyük finans kurumları son birkaç yılı dijital varlık alanını izleyerek bu yanılgıyı ilk fark edenler oldu. Saklama söz konusu olduğunda, özel anahtar sorusunu, donanımın rolünü ve ayrıca MPC’yi hızla anladılar. Ancak tedarikçi yönetiminde risk temelli bir yaklaşım benimseyerek, başka hangi tedarikçi tarafı bağımlılıkların mevcut olduğunu anlamak istediler. Müşterilerin hâlâ birçok konuda, yazılımın normal hizmeti ya da kullanımı olarak nitelendirilebilecek şeyler için tedarikçiye büyük ölçüde bağımlı olduğu ortaya çıktı. Örnekler arasında cüzdandaki politikaların ve iş mantığının güncellenmesi, yeni blokzincirlerin eklenmesi, hesabın yumuşak ve sert kurtarılması ve ayrıca birçok başka rutin ve beklenen günlük operasyon yer alabilir. Bu, kullanıcı deneyiminde bir sağlayıcının hesap düzeyindeki değişiklikleri hizmete sunması veya cüzdandaki kuralları güncellemesi için birkaç gün alması şeklinde kendini gösterir; bu da nihayetinde müşterinin belirli tanımlanmış operasyonel risklere karşı ana kontrolünün geçici olarak kırıldığı ve yeniden sağlanana kadar devam ettiği anlamına gelir.
Bunu daha da ileri götüren, güvenlik odaklı paydaşlar bir anahtar payına sahip olduklarını anlıyor ancak aynı zamanda günümüzde MPC cüzdan yazılımı sağlamak için hâkim yöntem olan bir SaaS sağlayıcısı tarafından barındırılan saklama mimarisindeki diğer mantıksal bileşenlerin riskini de anlamak istiyor. Bu, şu sorulara yol açar:

1. Eğer bir sağlayıcı anahtar payı üretimini gerçekleştiriyorsa, bana anahtar payımın bir kopyasına sahip olmadıklarına dair ne tür teminatlar sunulur?
2. Eğer bir sağlayıcı politikalarımı barındırıyorsa, sağlayıcıyı bunları değiştirmekten ne alıkoyar?
3. Hizmet sağlayıcı tarafından barındırılıyorsa, hizmet kullanılabilirliğini ve iş sürekliliğini nasıl garanti edebilirim? 
4. Sağlayıcı çevrim dışı olduğunda, kurtarma süresi hedefime ne kadar hızlı ulaşabilirim?

Bu soruların yanıtları, müşterinin varlıkları üzerindeki kontrol ve mülkiyetine dair herhangi bir güven perdesini hızla delerek ortaya çıkar. Buradaki anahtar kelime “güven”dir; çünkü bu soruların tüm yanıtları, “Bize güvenin” şeklinde ayrıntılı bir biçimdir ve son piyasa olaylarıyla kanıtlandığı gibi geçmişte pek işe yaramamıştır. Kurumlar, 2024’e doğru operasyonel dayanıklılıklarını güçlendirirken, bu tür yaklaşımlardan uzaklaşmayı hedefliyor. Bu bağlamda, piyasa katılımcıları bu risklerin ve potansiyel işletme kayıplarının risk iştahları, düzenleyici yükümlülükleri veya risk ağırlıklı varlıklar için düzenleyici sermaye gereksinimleri getiren ilgili çerçevelerle nasıl uyum sağladığını düşünmeye başlıyor. Sonuçta hizmet sağlayıcılar, firmanın risk yüzey alanının bir uzantısıdır. Bir kurum bir fonksiyonu üçüncü bir tarafa devredebilir, ancak sağlam risk yönetimi veya düzenleyici yükümlülük sorumluluğunu devredemez. Bir şirketin üçüncü bir tarafa ne kadar bağımlı olduğu, MPC cüzdan sağlayıcısı durumunda olduğu gibi, o kadar fazla denetim ve güven gerektirir.  

Dijital Varlıklar Üzerindeki Kontrolü Artırarak Güvenliği Artırmak

Üçüncü taraf bağımlılıklarını azaltmanın bir yolu, kurumların yazılımı kendi veri merkezlerinde veya özel bulutlarında barındırmasıdır; bu durumda sağlayıcının sorumluluğu bakım ve yazılım güncellemeleri gibi görevlere indirgenir. Bu, birçok finans kurumunun tercih ettiği bir yaklaşımdır; çünkü sunucular yerinde bulunur, veri güvenliğini korur ve saklama operasyonları üzerindeki mülkiyet ve kontrolü gerçekten önceliklendirebilir. Ayrıca, müşterinin bir saklama yazılımı örneği çalıştırırken, sağlayıcı ya da başka bir üçüncü tarafın da bağlı bir ağda kendi örneklerini çalıştırmasına olanak tanıyan ortak‑barındırma modeli hakkında tartışmalar da mevcuttur. Bu, her iki taraf arasında (güven ama doğrula) mutabakatı sağlayacak şekilde yapılabilir; böylece sağlayıcı, bugün yaygın olan merkezi bir güvenilir gerçek sürümü olmaz. Bu dağıtık dağıtım modeli, hata toleranslarını da güçlendirir ve müşterilerin bugün saklama sağlayıcılarıyla çok az kontrol sahibi olduğu iş sürekliliği planlamasının kritik bir parçasını oluşturur. Bu sınırlamalar, MPC cüzdanlarının daha önceki bir dönemde inşa edilmesi ve farklı müşteri bilgileri göz önüne alınması nedeniyle var; SaaS ürünleri ise çok yönlü görüşlere sahip olduğundan, müşterinin eline daha fazla güç veren yeni bir gerçekliğe uyarlanmaları pek olumlu görünmüyor. Bu ihtiyaçlar giderek daha iyi bilinir ve talep edildiği için, piyasa sektördeki bir sonraki evrim döngüsüne girerken sağlayıcıların bu akımda yer almasını arıyor.

Sonuç olarak, kurumlar giderek bu kendi kendine saklama ürünlerinin yöneticileri olmak ve bunları güvenlik çevreleri içinde yönetmek isterken aynı zamanda yüksek hizmet kullanılabilirliği ve yanıt verme seviyelerini sağlamak istiyor. Bu süreçlerin nasıl gerçekleştiğine dair net yanıtlarla operasyonel dayanıklılık, iş sürekliliği ve felaket kurtarma kanıtı sunmaları gerekir. Kara kutu bir SaaS ürünü ya da “Bize güvenin” başlangıçta kabul edilemez. Bu nedenlerle, kendi kendine saklama teknolojisinde tedarikçi tarafı yönetimden müşteri tarafı yönetimine doğru bir geçiş yaşanmaktadır. Bu, özel anahtar paylarıyla başladı ve politika motoru, sunucular ve daha fazlasıyla devam edecek. Sağlayıcıyı aradan çıkarmak, müşteri için iyi bir şeydir; ancak sağlayıcı bu fonksiyonu tamamen dış kaynak kullanmak zorunda kalırsa, şirketin düzenlenmiş bir saklayıcıya ihtiyacı olabilir; çünkü bu sadece riski daha iyi etkileyip çözmenizi sağlamakla kalmaz, aynı zamanda yazılım lisansı belirli kullanım senaryoları veya ilgi duyulan blokzincir ağları için üstüne inşa etmeye izin veriyorsa iş iyileştirmeleri de sunabilir. Bu yaklaşım, 2024’te olgunlaşma yönündeki sektör çapındaki çaba ile tutarlıdır ve müşteriler, saklama teknoloji sağlayıcılarından bunu giderek daha fazla talep edecek veya bu istenen iyileştirmeleri sağlayabilecek bir sağlayıcıya geçiş yapacak.