Sebastien Rousseau
İletişime geç ›

Cloud Native Banking in 2026: Kubernetes, DORA, Sovereignty, and the End of the VM vs Container Divide

Cloud native for banks has matured from container adoption to regulated platform engineering: Kubernetes, VM coexistence, data portability, DORA supervision, cloud dependency reviews, and operational resilience now define the architecture.

7 dk okuma

2026'da Bulut Yerel Bankacılık: Kubernetes, DORA, Egemenlik ve VM ile Konteyner Ayrımının Sonu

2026'da bulut yerel (cloud-native) bankacılık, artık bankaların bulutu kullanıp kullanamayacağı tartışması değildir. Bu, düzenlenmiş bir platform mühendisliği disiplinidir: kritik hizmetlerin konteynerler, sanal makineler, veri dokuları, yapay zeka (AI) iş yükleri ve bulut sağlayıcıları üzerinde nasıl çalıştırılacağı ve aynı zamanda DORA ve benzer rejimler kapsamında operasyonel dayanıklılığın nasıl kanıtlanacağı meselesidir. IBM, 2026 yılını DORA'nın ilk gerçek denetim sınavı olarak tanımlamakta; bulut bağımlılığı incelemeleri, siber güvenlik teftişleri, tehdit odaklı sızma testleri ve kritik üçüncü taraf sağlayıcılar üzerindeki doğrudan denetim ile bu sürecin öne çıkacağını belirtmektedir (IBM).

Yönetici Özeti / Temel Çıkarımlar

  • DORA, bulut sohbetini değiştirdi. 2026, kritik üçüncü taraf sağlayıcıların doğrudan AB denetimini ve bankaların bulut hizmet sağlayıcısı bağımlılıklarının hedefli incelemelerini beraberinde getirmektedir (IBM).
  • Kubernetes platform katmanıdır; tek başına çözüm değildir. Bankaların esneklik, otomasyon ve AI/ML (yapay zeka/makine öğrenmesi) iş yükleri için Kubernetes'e ihtiyacı vardır; ancak çekirdek bankacılık, ödemeler, alım satım ve risk sistemleri hâlâ sertleştirilmiş sanallaştırılmış altyapılar üzerinde çalıştığından sanal makine (VM) ile birlikte yaşam da gereklidir (Red Hat).
  • VM ile konteyner arasındaki ayrım kapanmaktadır. Red Hat, OpenShift ve Portworx'u, VM'ler ile konteynerlerin politika, veri, yedekleme, felaket kurtarma ve yönetişim kontrollerini paylaştığı birleşik bir model olarak konumlandırmaktadır (Red Hat).
  • Bulut egemenliği artık bir tasarım kısıtlamasıdır. Bankalar, yargı yetkisi kontrolü, operasyonel özerklik, anahtar kontrolü, veri konumu ve bulut yoğunlaşma riskini yönetmek için egemenliği kullanmaktadır (Red Hat).
  • Yapay zeka, bulut yerel mimariyi aciliyet hâline getirdi. Dolandırıcılık tespiti, likidite analitiği, gerçek zamanlı kişiselleştirme ve düzenleyici raporlama, hassas verilere yakın esnek hesaplama gücüne giderek daha fazla ihtiyaç duymaktadır (Red Hat).
  • Çıkış stratejisi bir PDF değildir. Modern denetim beklentileri çerçevesinde bankaların test edilmiş taşınabilirlik, bağımlılık haritalaması, sözleşmeye dayalı kanıtlar, kurtarma prosedürleri ve kritik fonksiyonlar için gerçekçi göç yollarına ihtiyacı vardır.
  • Mimari hedef kontrollü bulut yerel mimaridir. Kazanan banka platformu; geliştiricilere kendi kendine hizmet teslimi sunarken denetim, şifreleme, veri ikametgâhı, dayanıklılık testi, görevler ayrılığı ve üçüncü taraf risk kontrollerini otomatik olarak uygular.

2026 Neden Bulut Yerel Denetim Yılıdır #

DORA Ocak 2025'ten itibaren uygulanmaya başlamış olsa da, denetim gücünün görünür hâle geldiği yıl 2026'dır. IBM, ilk Kritik Üçüncü Taraf Sağlayıcılar listesinin Kasım 2025'te belirlendiğini ve 2026'nın Avrupa Denetim Otoriteleri ile doğrudan etkileşim, sözleşme incelemeleri, yerinde teftişler ve bulut bağımlılığı analizini beraberinde getirdiğini belirtmektedir (IBM).

Bu durum, ispat yükünü değiştirmektedir. Bir banka artık bir bulut kesintisinin yalnızca tedarikçi sorunu olduğunu söyleyemez. Kritik fonksiyonlar; hiperölçekleyicilere, SaaS (hizmet olarak yazılım) sağlayıcılarına, veri platformlarına ve yönetilen güvenlik hizmetlerine bağlı olsa bile, finansal kuruluş bu fonksiyonların dayanıklılığından sorumlu olmaya devam etmektedir.

2026 Bulut Yerel Bankacılık Temel Çerçevesi #

1. İşletim Katmanı Olarak Kubernetes #

Kubernetes, bankalara dağıtım otomasyonu, esneklik, politika uygulaması, konteyner orkestrasyonu ve özel bulut, kamu bulutu ile egemen ortamlar arasında ortak bir soyutlama sunar. Yeni iş yükleri için, özellikle AI tabanlı dolandırıcılık tespiti, gerçek zamanlı kişiselleştirme, likidite analitiği ve düzenleyici raporlama için bu, doğal kontrol düzlemi hâline gelmiştir (Red Hat).

Yapılan hata, Kubernetes'i nihai varış noktası olarak görmektir. Bankalar için Kubernetes, yönetilen bir geliştirici platformunun altında yer alan zemindir.

2. VM ve Konteyner Yakınsaması #

Çoğu banka temel altyapısını hızlıca yeniden yazamaz. Ödeme motorları, alım satım sistemleri, kredi puanlaması, risk modelleri ve çekirdek bankacılık platformları hâlâ sertleştirilmiş VM altyapılarına bağımlıdır. Red Hat, bankaların VM'ler ile konteynerlerin birlikte çalışabildiği, mimari tekrarı azaltan ve politika, depolama, yedekleme ile kurtarma kontrollerini hizalayan birleşik bir platforma ihtiyaç duyduğunu savunmaktadır (Red Hat).

Bu, eski sistem dayanıklılığı ile bulut yerel hız arasındaki pratik köprüdür. Bankaların önce çevresel hizmetleri taşımasına, veriye bağımlı AI iş yüklerini bir arada konumlandırmasına ve kritik sistemlere kırılgan yeniden yazımları dayatmaktan kaçınmasına olanak tanır.

3. DORA'ya Hazır Operasyonel Dayanıklılık #

IBM'e göre 2026 denetim öncelikleri arasında ICT (bilgi ve iletişim teknolojileri) güvenliği ile dış kaynak kullanımı eksikliklerinin takibi, siber güvenlik ile üçüncü taraf risk yerinde teftişleri, tehdit odaklı sızma testleri, ICT değişim yönetimi incelemeleri ve bulut bağımlılığı analizi yer almaktadır (IBM).

Bu, dayanıklılığın test edilebilir olması gerektiği anlamına gelir. Mimari şemalar yeterli değildir. Bankaların yedeğe geçiş tatbikatlarından, olay simülasyonlarından, yedek geri yüklemelerinden, bağımlılık haritalarından, kurtarma süresi testlerinden ve yönetişim iş akışlarından elde edilen kanıtlara ihtiyacı vardır.

4. Platform Yeteneği Olarak Egemenlik #

Bulut egemenliği yalnızca veri ikametgâhından ibaret değildir. Yasal kontrolü, operasyonel kontrolü, şifreleme anahtarı kontrolünü, destek personeli yargı yetkisini, iş yükü yerleştirmesini ve küresel bir sağlayıcı veya jeopolitik bir süreç kesinti yarattığında kritik hizmetleri sürdürebilme kapasitesini de kapsar. Red Hat, GDPR (Genel Veri Koruma Tüzüğü), DORA ve ulusal bulut kuralları gibi farklılaşan düzenlemelerle karşı karşıya kalan bankalar için egemenliği yargı yetkisi kontrolü ve operasyonel özerklik olarak çerçevelemektedir (Red Hat).

Bunun bulut yerel mimariye yansıması; iş yükü yönlendirmesinin, sır yönetiminin, anahtar kontrolünün, veri sınıflandırmasının ve politika uygulamasının programlanabilir olması gerektiğidir.

Banka Platform Yığını #

Geliştirici Deneyimi Katmanı #

Banka düzeyinde bir bulut yerel platform, döşeli yollar sunmalıdır: altın yollar, şablonlar, hizmet katalogları, otomatik dağıtım hatları, gözlemlenebilirlik varsayılanları, kod olarak politika (policy-as-code), standart sır entegrasyonu ve onaylı veri yolları. Geliştiricilerin her sürüm için her kontrol sahibiyle pazarlık etmek zorunda kalmaması gerekir.

Platform, uyumlu yolu en hızlı yol hâline getirmelidir. Binlerce hizmet arasında ölçeklenebilen tek model budur.

Kontrol Katmanı #

Kontrol katmanı; kimlik, erişim yönetimi, görevler ayrılığı, şifreleme, anahtar saklama, ağ politikası, imaj imzalama, yazılım malzeme listesi, açıklık kapıları, çalışma zamanı güvenliği, günlükleme ve kanıt üretimini kapsar. DORA, NIS2 (Ağ ve Bilgi Güvenliği Direktifi 2), GDPR, dış kaynak kullanımı kuralları ve dahili model risk politikalarının uygulanabilir kontrollere dönüştüğü yer burasıdır.

Pek çok bankanın başarısız olduğu nokta da burasıdır. Konteynerleri benimserler ancak kontrolleri platform dışında manuel onaylar olarak bırakırlar.

Veri Katmanı #

Durumlu (stateful) iş yükleri, bulut yerel bankacılığın en zor kısmıdır. Red Hat'ın VM/konteyner yakınsama argümanı, büyük ölçüde birleşik bir veri dokusuna ve VM'ler ile konteynerler arasında politika güdümlü yedekleme, çoğaltma, yedeğe geçiş ve kurtarmaya dayanır (Red Hat).

Bankalar için veri katmanı üç soruyu yanıtlamalıdır: veri nerededir, anahtarları kim kontrol etmektedir ve altyapı arızalanırsa hizmet nasıl kurtarılır?

Mimari Tablosu: Bankalar için Bulut Yerel #

Yetenek Bulut Yerel Desen Bankacılık Kontrol Gereksinimi Başarısızlık Modu
Uygulama dağıtımı Kubernetes, GitOps, şablonlar Görevler ayrılığı, değişim kanıtı, geri alma Hızlı ancak denetlenemez sürümler
Eski sistem birlikteliği VM/konteyner birleşik platformu Politika tutarlılığı ve göç kontrolü Tekrarlanan riske sahip ikili altyapılar
Veri hizmetleri Durumlu operatörler ve veri dokusu Veri ikametgâhı, yedekleme, değişmezlik, test edilmiş geri yükleme Durumlu kırılganlığa sahip durumsuz platform
Dayanıklılık Çok bölgeli, çok bölgeli, yedeğe geçiş DORA kanıtı ve kritik fonksiyon haritalaması Bulut kesintisinin tedarikçi mazereti olarak ele alınması
Egemenlik Politika tabanlı iş yükü yerleştirme Yargı yetkisi ve anahtar kontrol kanıtı Operasyonel özerklik olmadan veri ikametgâhı
AI iş yükleri Veriye yakın esnek hesaplama Model yönetişimi, veri minimizasyonu, denetim Hassas verilerin onaysız AI hizmetlerine taşınması

Kurum Türüne Göre Bu Ne Anlama Geliyor #

Birinci Kademe Evrensel Bankalar #

Birinci kademe bankalar; sıkı kod olarak politika, veri sınıflandırması ve iş yükü yerleştirmesi ile birden fazla bulut üzerinde kontrollü dahili platformlar inşa etmelidir. Platform mühendisliğini meşrulaştıracak ölçeğe sahiptirler ve düzenleyiciler onlardan daha derin kanıtlar bekleyecektir.

Orta Kademe Bankalar #

Orta kademe bankalar, özelleştirmek yerine standartlaştırmalıdır. Güçlü bir yönetilen Kubernetes platformu, disiplinli bir bulut sağlayıcı seçimi, net çıkış stratejileri ve otomatik kanıt üretimi; kurumun işletemeyeceği yaygın bir çoklu bulut iddiasından daha değerlidir.

Finansal Piyasa Altyapıları #

FMI'lar (Finansal Piyasa Altyapıları) her şeyden önce dayanıklılık kanıtına ihtiyaç duyar. Bulut yerel mimariyi salt bir hız oyunu olarak değil; kurtarmayı, gözlemlenebilirliği ve kontrollü değişimi geliştirmenin bir yolu olarak ele almalıdırlar.

Fintech'ler ve PSP'ler #

Fintech'ler ve PSP'ler (Ödeme Hizmeti Sağlayıcıları) hızlı hareket edebilirler, ancak kontrol modellerinin ötesine geçmemeye dikkat etmelidirler. Sistemik açıdan önem kazandıkça, aynı dayanıklılık, üçüncü taraf risk, olay raporlama ve veri egemenliği beklentileri de gelecektir.

Sonuç #

2026'da bulut yerel bankacılık bir yönetişim mimarisidir. Kubernetes vazgeçilmezdir, ancak yeterli değildir. Başarılı olacak kurumlar; gerektiğinde VM'ler ile konteynerleri yakınsatacak, yeni iş yükleri için bulut yerel desenleri kullanacak, DORA kapsamında dayanıklılığı kanıtlayacak, platform katmanında veri egemenliğini kontrol edecek ve geliştiricilerin yönetilmeyen risk yaratmadan hızlı hareket edebilmesi için uyumluluğu yeterince otomatik hâle getirecek olanlardır.

Eski tartışma bankaların buluta geçip geçemeyeceğiydi. Yeni tartışma ise bankaların bulut yerel mimariyi, önem taşıyan hizmetleri çalıştırmak için yeterince güvenli, yeterince taşınabilir ve yeterince kanıtlanabilir hâle getirip getiremeyeceğidir.

Sıkça Sorulan Sorular #

DORA, bankaların bulutu kullanmasını engelliyor mu?

Hayır. DORA bulut kullanımını yasaklamamaktadır. Bulut ve diğer ICT sağlayıcılarına dayanan kritik hizmetlerin ICT riski, üçüncü taraf bağımlılığı, olay raporlaması, dayanıklılık testi ve yönetişimi konularında finansal kuruluşları sorumlu kılmaktadır (IBM).

Kubernetes gelecekse, bankalar neden hâlâ VM'lere ihtiyaç duyuyor?

Bankalar hâlâ ödeme motorları, çekirdek bankacılık sistemleri, alım satım uygulamaları ve risk platformları dahil olmak üzere kritik sistemleri VM tabanlı altyapılar üzerinde çalıştırmaktadır. Birleşik bir VM/konteyner modeli, kademeli göçe izin verirken tekrarlamayı azaltır (Red Hat).

Gerçek bir bulut çıkış stratejisi nedir?

Gerçek bir çıkış stratejisi; bağımlılık envanteri, veri dışa aktarma prosedürleri, alternatif çalışma zamanı seçenekleri, sözleşmesel haklar, kurtarma testi, anahtar kontrol planları ve kritik hizmetleri taşımak veya geri yüklemek için gerçekçi bir takvim içerir.

Bankaların yaptığı en büyük bulut yerel hata nedir?

En büyük hata, platform kontrolleri olmadan konteynerleri benimsemektir. Kubernetes dağıtım hızını artırırken kimlik, politika, denetim, veri ikametgâhı, kurtarma ve açıklık kontrollerini uygulamıyorsa, riski azaltmak yerine hızlandırır.

Kaynaklar #

Son inceleme .

Son inceleme .