Suudi Kurumları için Bulut Geçiş Rehberi: NCA ECC ve Veri İkametgahı

Suudi Arabistan'da bulut geçiş (cloud migration) projelerinin çoğu ağ verimi veya Kubernetes olgunluğu yüzünden takılmıyor — veri ikametgahı (data residency) yüzünden takılıyor. Ekip, hangi veri kümesinin Bulut Bilişim Düzenleyici Çerçevesi (Cloud Computing Regulatory Framework – CCRF) kapsamında "Suudi Devlet Verisi" sayıldığını ve bunlardan hangisinin Krallık sınırlarını yasal olarak terk edebileceğini haritalamadan hyperscaler sözleşmesini imzalıyor. Sınıflandırma çalışması yapıldığında iniş bölgesi (landing zone) zaten yanlış bölgede kurulmuş, şifreleme anahtarları Krallık dışındaki bir kontrol düzleminden yönetiliyor, ve NCA Temel Siber Güvenlik Kontrolleri (NCA Essential Cybersecurity Controls – NCA ECC) boşluk analizi bir gözden geçirme değil, sıfırdan yeniden inşa haline dönüşüyor.

Bu sıranın ters çevrilmesinin maliyeti soyut değildir. Canlıya geçtikten sonra iniş bölgesini yeniden inşa etmek; kimlik yapılandırmasını, anahtar ihracını, ECC öz-değerlendirmesini ve bulut hizmet sağlayıcısıyla (CSP) veri işleme koşullarının yeniden müzakeresini gerektirir — ekibinizin zaten bir kez yaptığı işi, şimdi canlı bir üretim SLA'sı altında tekrar yapmak. Üzerine sektörel bir düzenleyici bindiğinde (finans kuruluşları için SAMA gibi — bkz. SAMA & NESA uyumluluk yazımız), denetim sırasında ortaya çıkan bir ikametgah bulgusu, düzeltme doğrulanana kadar veri göçünü durdurabilir; bu da teknik inşaatın diğer kısımları ne kadar iyi yürütülmüş olursa olsun programın tamamını kilitler.

Bu rehber, D-Elite Solutions mühendislik ve güvenlik ekibinin Suudi kurumları için bulut geçişlerini planlarken izlediği sıradır: NCA ECC bir bulut iş yükünden gerçekte ne bekler, CCRF verinin — ve onu koruyan anahtarların — nerede durabileceği konusunda ne söyler, NCA denetiminden geçecek bir iniş bölgesi nasıl kurulur ve doğru cevabın henüz göç etmemek olduğu durumlar hangileridir.

Önemli Çıkarımlar

• NCA'nın ECC-2:2024 güncellemesi, üçüncü taraf ve bulut gereksinimlerini bağımsız beşinci bir alan olarak tutmak yerine ana kontrol alanlarının içine entegre etti — CSP ile paylaşılan sorumluluk matrisinizin "CSP ISO 27001 sertifikalı" demekle yetinmeyip belirli ECC alt kontrollerine eşlenmesi gerekiyor.
• CCRF'nin kurduğu sınıflandırma modeline göre Suudi Devlet Verisi (top secret, secret, confidential ve public olmak üzere dört seviyeye ayrılır) yasa veya düzenlemeyle açıkça izin verilmedikçe geçici ya da kalıcı olarak Krallık'tan çıkamaz; Devlet Dışı Veri sınıflandırması ise abonenin kendi kararıdır ve CSP'nin beyan ettiği güvenlik seviyelerine göre yapılır.
• Eskiden CITC olarak bilinen kurum artık CST — Communications, Space & Technology Commission. Dayandığınız CCRF kaynaklı her belgenin güncel düzenleyici adını ve süresi dolmuş CCRF v3 metni yerine 2023 tarihli Cloud Computing Services Provisioning Regulations'ı referans aldığından emin olun.
• Fiziksel olarak Suudi Arabistan'da bulunan bir bölge, "yerel" olmak için gerekli ama yeterli değildir. KMS kök anahtarınız, destek araçlarınız veya yedekleme replikasyon yolunuz Krallık dışındaki bir kontrol düzlemine dokunuyorsa, ikametgah iddianız mimari şemanızın öne sürdüğünden daha zayıftır.
• Krallık içinde barındırılan bir anahtar deposunda tutulan, müşteri yönetimli anahtarlar (Customer-Managed Keys – CMK) — anahtar sorumlusu rolü veri sorumlusu rolünden ayrılmış şekilde — verinin kendisinin fiziksel konumu kadar önemlidir.
• Her iş yükü şimdi göç etmeye hazır değildir. Bazı veri sınıfları ve bazı ICS/OT ortamları, bölge olgunluğu ve kendi ECC seviyeniz yetişene kadar Krallık içinde yerinde veya hibrit modelde tutulmayı hak eder.

NCA ECC ve Bulut: Her Suudi Bulut Geçişi Kararının Arkasındaki Kontrol Alanları

Ulusal Siber Güvenlik Otoritesi (National Cybersecurity Authority – NCA), kapsam dahilindeki her Suudi kuruluşun karşılaması beklenen temel çizgi olan Temel Siber Güvenlik Kontrolleri'ni (ECC) yayımlar. Qualys ve SecurityWall gibi uyumluluk danışmanlığı firmalarının yayımladığı ikincil özetler, ECC-2:2024 güncellemesinin yapıyı dört ana alana yeniden düzenlediğini anlatıyor: Siber Güvenlik Yönetişimi, Siber Güvenlik Savunması, Siber Güvenlik Dayanıklılığı ve bu alanlara entegre edilmiş Üçüncü Taraf & Bulut Bilişim Siber Güvenliği gereksinimleri — yaklaşık 28 alt alan ve önceki ECC-1:2018 sürümündeki 114 kontrolden düşerek 108 ana kontrol, kuruluşunuzun rolünün hassasiyetine göre değişen katmanlı bir uyumluluk modeliyle (Essential, Advanced, Minimal) birlikte. Bu rakamı kesin değil yönlendirici kabul edin: resmi bir değerlendirmenin kapsamını belirlemeden önce NCA'nın kendi güncel ECC-2:2024 belgesini çekin, çünkü ikincil özetler otoritenin kendi güncellemelerinin gerisinde kalabilir.

Bir göç projesi için önemli olan kontrol sayısını ezberlemek değil, NCA'nın sizden beklentisinin nerede bittiğini ve CSP'nin yükümlülüğünün nerede başladığını bilmektir.

CSP ile paylaşılan sorumluluk dağılımı

Cloud Computing Regulatory Framework: Krallık'tan Ne Çıkabilir, Ne Çıkamaz

Suudi Arabistan'da bulut sektörünü Communications, Space & Technology Commission (CST) düzenler — bu, Aralık 2022'de yeniden markalanan, eskiden Communications and Information Technology Commission (CITC) olarak bilinen aynı otoritedir. Cloud Computing Regulatory Framework'ün üçüncü sürümü (CCRF v3), abone verisi için iki katmanlı bir sınıflandırma modeli kurmuştu: dört seviyeye ayrılan Suudi Devlet Verisi (top secret, secret, confidential, public) ve Devlet Dışı Veri. CCRF v3'e göre Suudi Devlet Verisi, yasa veya düzenlemeyle açıkça izin verilmedikçe hiçbir amaçla, geçici ya da kalıcı olarak Krallık dışına aktarılamıyordu. Devlet Dışı Veri'nin sınıflandırılması ise abonenin kendisine bırakılmıştı, CSP'nin beyan ettiği güvenlik seviyelerine göre yapılıyordu.

10 Ekim 2023'te CST, CCRF v3'ün yerini alan güncellenmiş Cloud Computing Services Provisioning Regulations'ı yayımladı. Bu 2023 düzenlemesinin devlet verisi ikametgahı metnini birebir koruyup korumadığını ya da değiştirip değiştirmediğini birincil CST kaynaklarından bağımsız olarak doğrulayamadık — "Suudi Devlet Verisi Krallık'ta kalır" ilkesini güvenli bir planlama temeli olarak ele alın, ancak bu ilkenin gevşetildiğini varsayan herhangi bir veri akışı şemasını kesinleştirmeden önce hukuk danışmanınızın CST'nin güncel yayımlanmış metnini çekmesini sağlayın.

Ayrıca, kuruluşunuz devlet kurumları için veya onlarla birlikte veri işliyorsa, Suudi Veri ve Yapay Zeka Otoritesi'ne (SDAIA) bağlı Ulusal Veri Yönetim Ofisi (National Data Management Office – NDMO) kendi ulusal veri yönetişimi ve sınıflandırma standartlarını uygular. Bu yazı için NDMO'nun güncel katman adlarını bağımsız olarak doğrulayamadık — NDMO'yu, kamu sektörü muhatabınız varsa CCRF'nin üzerine binebilecek ikinci bir sınıflandırma merceği olarak ele alın ve ikincil özetlere güvenmek yerine güncel NDMO belgelerini doğrudan edinin.

Operasyonel sonuç şudur: sınıflandırma, veri sahiplerinizin bölge veya CSP seçiminden önce verdiği bir karardır, sözleşme imzalandıktan sonra sonradan eklenen bir egzersiz değildir.

Krallık İçi Bölgeler: Sözleşmenizde "Yerel" Gerçekte Ne Anlama Gelir

Bölge kurulum takvimleri değişkenlik gösterdiğinden bu tabloyu durum tespitinin yerine değil, başlangıç noktası olarak ele alın. Müşteri sözleşmenizde bir ikametgah iddiasına bağlanmadan önce güncel genel kullanılabilirlik (GA) durumunu, kullanılabilirlik bölgesi sayısını ve ilgili hizmet için CST kayıt durumunu sağlayıcıdan doğrudan teyit edin.

"Yerel" haritadaki bir nokta değil, sözleşme maddesidir

Fiziksel olarak Suudi Arabistan sınırları içinde bir bölge, kapatmanız gereken birkaç sorudan yalnızca ilkini yanıtlar:

• Destek erişimi. CSP destek personeli sorun giderme amacıyla üretim verisine Krallık dışından erişebiliyor mu, hangi yetkilendirmeyle?
• Yedekleme ve felaket kurtarma replikasyon hedefi. Felaket kurtarma yapılandırmanız varsayılan olarak KSA dışındaki bir bölgeye mi replike ediyor?
• Telemetri ve günlükleme. CSP'nin kiracınızdan topladığı operasyonel telemetri, Krallık dışındaki küresel bir konsoldan mı geçiyor?
• CDN ve edge önbellekleme. İçerik dağıtım katmanınız düzenlenmiş veriyi KSA dışındaki edge noktalarında önbelleğe alıyor mu?
• Lisanslama. KSA bölgesini işleten spesifik tüzel kişilik, bu bulut hizmet kategorisini yurt içinde sunmak için CST'ye kayıtlı mı? Bu, veri merkezinin fiziksel konumundan ayrı bir sorudur.

Düzenlenmiş Suudi İş Yükleri için İniş Bölgesi Mimarisi

İniş bölgesi (landing zone), iş yüklerinin içine indiği, önceden kurulan yönetişimli çok hesaplı (veya çok abonelikli) yapıdır — herhangi bir düzenlenmiş iş yükü göç etmeden önce bir kez inşa edilir. Aşağıdaki yapı sağlayıcıdan bağımsızdır; ilkeleri AWS Organizations/Control Tower, Azure Management Groups veya GCP Resource Manager ile değiştirebilirsiniz.

Organization: KSA-Production
├── ou-security
│   ├── acct-log-archive        # değiştirilemez, yalnızca yazılabilir günlükleme, yalnızca Krallık içi bölge
│   └── acct-security-tooling   # SIEM iletici, anahtar yönetimi, tehdit tespiti
├── ou-workloads-regulated
│   ├── acct-prod-restricted    # Krallık içi ikametgah gerektiren veri (Devlet Verisi katmanları)
│   └── acct-prod-confidential  # "confidential" sınıflandırılmış Devlet Dışı Veri
├── ou-workloads-general
│   └── acct-prod-general       # ikametgah kısıtlaması olmayan iş yükleri
└── ou-sandbox
    └── acct-dev-test

Koruma kuralları (varsayılan olarak reddet):
  - Onaylı KSA bölge listesi dışında depolama kovası/hesabı oluşturmayı reddet
  - Onaylı KSA bölgesi dışında KMS anahtarı oluşturmayı reddet
  - Düzenlenmiş OU'larda genel ağ ACL genişletmesini reddet
  - Her depolama kaynağında "data-classification" etiketini zorunlu kıl

Bu koruma kurallarını, her dağıtımdan önce birinin hatırlayıp kontrol etmesi gereken manuel bir liste olarak değil, politika-kod (Policy as Code) olarak — servis kontrol politikaları, Azure Policy veya Kubernetes için OPA/Gatekeeper aracılığıyla — uygulayın. Bir insanın hatırlamasına bağlı bir koruma kuralı, NCA ECC kanıt dosyanızın güvenebileceği bir koruma kuralı değildir.

Kimlik, Şifreleme ve Anahtar Yönetimi: Anahtarın İkametgahı Verinin Kendisi Kadar Neden Önemli

Müşteri yönetimli anahtarlar (Customer-Managed Keys – CMK) — bazen Bring Your Own Key (BYOK) ve Hold Your Own Key (HYOK) modelleriyle birlikte tartışılır — verinizi koruyan şifreleme anahtarının yaşam döngüsünü, CSP'nin varsayılan yönetilen anahtarına güvenmek yerine sizin kontrol etmenizi sağlar. Bu önemlidir çünkü varsayılan yönetilen anahtarın yaşam döngüsü, CSP'nin küresel anahtar yönetim hizmeti (Key Management Service – KMS) tarafından kontrol edilir; şifrelenmiş veri KSA bölgesinde otursa bile, hizmete bağlı olarak bu KMS'nin kontrol düzlemi işlemleri Krallık dışındaki altyapıya dokunabilir.

Krallık içi bir KMS örneğine sabitlenmiş, anahtar sorumlusu rolü altyapı veya veri yöneticinizden ayrı birine atanmış (görevler ayrılığı — NCA ECC'nin Savunma alanında işlenen bir kimlik ve erişim teması) bir müşteri yönetimli anahtar, varsayılan anahtarın sağlamadığı üç şeyi sağlar:

1. Kimin şifre çözebileceğinin kanıtı — kriptografik güven köküne ait belgelenmiş, denetlenebilir bir gözetim zinciri.
2. Bağımsız bir iptal kaldıracı — CSP'nin kendi acil durum sürecine bağlı kalmadan şifre çözme erişimini kesebilirsiniz.
3. Daha güçlü bir denetim pozisyonu — CSP'nin kendi küresel kontrol düzlemi başka yerde olsa bile, kriptografik güven kökünün Krallık gözetiminden hiç çıkmadığını gösterebilirsiniz.

Pratik kurulum kontrol listesi:

• Kısıtlı veya gizli katmandaki iş yükleri için hizmetin desteklediği her yerde CMK kullanın.
• Anahtarları tanımlı bir programa göre döndürün ve her anahtar kullanım olayını SOC'nize kaydedin.
• Anahtar sorumlusu rolünü RACI'nizde ayrı belgeleyin — bu kişi iş yükünü yöneten kişiyle aynı olmamalı.
• Henüz bölge içi CMK desteklemeyen herhangi bir hizmet için bunu sonradan çözülecek bir dipnot değil, o spesifik hizmette sınıflandırılmış veri barındırmak için bir gidiş/gidiş-değil kapısı olarak ele alın.

Günlükleme, İzleme ve SOC Entegrasyonu

Olay günlükleme ve izleme, NCA ECC'nin hem Savunma hem de Dayanıklılık alanlarına yayılır — bu, bulut geçişine sonradan eklenen isteğe bağlı bir özellik değil, iniş bölgesi ön koşuludur. Kiracı düzeyindeki kontrol düzlemi ve veri düzlemi günlüklerini Krallık içindeki merkezi, değiştirilemez bir günlük arşivine yönlendirin ve bu arşivi — kurum içi veya bir MSSP aracılığıyla — SOC'nizin SIEM'iyle, her günlük kaynağı için tanımlı kapsamla entegre edin.

Günlük saklama süresini genel bir sektör varsayılanına göre değil, güncel NCA ECC kontrol metnine ve varsa sektörel bir üst katmana (örneğin finans kuruluşları için SAMA siber güvenlik çerçevesi) göre belirleyin. Saklama süresi, ECC revizyonları arasında en sık değişen rakamlardan biridir; bu yüzden önceki bir projeden taşınan bir sayı yerine değerlendirme sırasında düzenleyicinin metninden güncel asgari süreyi çekin.

Yedi Adımlık Göç Sıralaması

1. Veri keşfi ve sınıflandırma. Her veri kümesini herhangi bir bölge veya CSP kararından önce CCRF'nin Devlet/Devlet Dışı modeline — kamu sektörü muhataplar için ayrıca NDMO sınıflandırma merceğine — göre sınıflandırın.
2. NCA ECC boşluk analizi. Mevcut durumu, göç ettirmeyi planladığınız iş yükleriyle sınırlı olarak ECC-2:2024 alanlarına göre puanlayın. Sonuç geçer/kalır kapısı değil, düzeltme yedeğinizdir.
3. CST kayıt kontrolüyle CSP ve bölge seçimi. Yalnızca ihtiyacınız olan hizmet kategorileri için CST'ye kayıtlı, operasyonel durumu teyit edilmiş bölgelerdeki CSP'leri kısa listeye alın.
4. İniş bölgesi kurulumu. Herhangi bir iş yükü inmeden önce — ilk göçle birlikte değil — hesap yapısı, koruma kuralları, anahtar yönetimi ve günlük arşivi.
5. Düzenlenmemiş bir iş yükünde pilot göç. Önce sınıflandırılmamış bir şey üzerinde iniş bölgesini, koruma kurallarını ve izlemeyi uçtan uca doğrulayın.
6. Belgelenmiş bir veri koruma etki değerlendirmesiyle düzenlenmiş iş yükü göçü. Kısıtlı veya gizli iş yüklerini, yalnızca pilot koruma kurallarının sağlam olduğunu kanıtladıktan sonra, veri sahibi ve güvenlik ekibinin onayıyla göç ettirin.
7. Kesim, devre dışı bırakma ve sürekli uyumluluk izleme. Kaynak ortamı tanımlı bir programa göre devre dışı bırakın ve iş yükünü sürekli ECC öz-değerlendirmesine ve SOC kapsamına dahil edin — canlıya geçiş bitiş çizgisi değildir.

Tedarikçi ve CSP Durum Tespiti: Onay İş Akışı

• CSP, ilgili bulut hizmet kategorisi için CST'ye kayıtlı
• CSP, alt işlemci konumlarını belirten bir veri işleme eki sağlıyor
• CSP, üretim verisine destek/sorun giderme erişiminin bölge dışından yapılıp yapılamayacağını açıklıyor
• CSP, kullanmayı planladığınız hizmetler için bölge içi müşteri yönetimli anahtarları destekliyor
• CSP'nin olay bildirim SLA'sı yazılı olarak tanımlı ve iç eskalasyon zaman çizelgenizi karşılıyor
• CSP bir çıkış/taşınabilirlik planı sunuyor — veri dışa aktarma formatı, zaman çizelgesi ve varsa veri çıkış maliyeti tavanı
• Bağımsız beyan (ISO 27001, SOC 2 veya eşdeğeri) güncel ve yalnızca sağlayıcının küresel tüzel kişiliği için değil, kullandığınız bölge için kapsamlandırılmış
• İç onay zinciri — veri sahibi onayı, güvenlik mimarisi incelemesi, DPA'nın hukuki incelemesi ve CISO veya eşdeğerinin nihai onayı — denetim için kayıt altında

Aşamalı Yol Haritası

Süreler, iş yükü sayısına ve mevcut ECC olgunluğunuza göre ölçeklenen gerekçeli bir planlama tahminidir — belirli bir proje için sabit bir teklif değildir.

Maliyet ve Zaman Çizelgesi Gerçekçiliği: Hesaplanmış Bir Örnek

Planlama örneği olarak orta ölçekli düzenlenmiş bir iş yükü setini ele alalım: yaklaşık 40 sanal makine eşdeğeri işlem gücü, 15 TB sınıflandırılmış veri, sıfırdan kurulan bir iniş bölgesi. Bu, planlama amaçlı gerekçeli bir tahmindir, teklif değildir — gerçek rakamlarınız sağlayıcıya, bölgeye ve güncel fiyatlandırmaya bağlıdır:

• İniş bölgesi kurulumu (koruma kuralları, anahtar yönetimi, günlük arşivi, IAM): karma kıdemli bulut mühendisi/güvenlik mimarı çabasıyla yaklaşık 3–5 mühendislik haftası.
• ECC boşluk analizi ve düzeltme yedeğinin kapatılması: mevcut kontrol olgunluğunuza göre ölçeklenir — kısmi bir ECC-1:2018 temelinden başlayan bir ekip, genellikle sıfırdan başlayan bir ekibe göre önemli ölçüde daha az düzeltme taşır.
• Verinin kendisinin göçü (özel veya ayrılmış bağlantı üzerinden 15 TB): işlem gücü değil bant genişliği kısıtlıdır — aktarım penceresini kamuya açık internet verimini varsaymak yerine gerçek bağlantı hızınıza göre modelleyin.
• CMK ve KMS entegrasyonu: çoğunlukla bölgeye sabitlenmiş KMS'yi çağırmak için uygulama tarafı kod değişiklikleriyle yaklaşık 1–2 mühendislik haftası.
• Pilot artı düzenlenmiş kesim: özellikle düzenlenmiş iş yükü aşamasına %20–30 zaman çizelgesi tamponu ekleyin — DPIA onayı ve hukuki inceleme döngüleri genellikle takvimin en değişken kısmıdır, mühendislik işi değil.

Sınıflandırma ve ECC temeli baştan doğru yapıldığında orta ölçekli düzenlenmiş bir göç, uçtan uca genellikle dört ila yedi ay sürer — proje ortasında ortaya çıkan bir ikametgah bulgusundan sonra iniş bölgesinin yeniden inşa edilmesi gerektiğinde ise bu süre önemli ölçüde uzar.

Henüz Göç Etmeyin: Hibrit ve Krallık İçi Yerinde Barındırma Durumu

• Sınıflandırma çalışmanız iş yükünüzün önemli bir kısmını "top secret" veya "secret" Suudi Devlet Verisi katmanlarına yerleştiriyorsa — veya kamu sektörü muhatabınız eşdeğer bir NDMO katmanı uyguluyorsa — ve ihtiyacınız olan spesifik hizmet için bu ikametgah gereksinimini karşılayan CST'ye kayıtlı bir CSP seçeneği teyit edilemiyorsa, doğru karar umutlu bir takvimle hyperscaler göçü değil, Krallık içinde yerinde barındırma veya zaten onaylanmış bir devlet bulutudur.
• Kuruluşunuz kendi mevcut durum NCA ECC boşluk analizini henüz kapatmadıysa, önce göç edip kontrolleri sonradan düzeltmek doğru sırayı tersine çevirir. Çözülmemiş bir kontrol boşluğu taşıyan canlı bir üretim ortamını devralırsınız — bu, aynı boşluğun üretim öncesi bir iniş bölgesinde oturmasından maddi olarak daha kötü bir denetim pozisyonudur.
• Sert gerçek zamanlı kontrol döngülerine sahip ve doğrulanmış bir buluta bağlı yedekleme yolu olmayan ICS/OT ortamları varsayılan olarak hibrit bir durumdur: kontrol döngüsünü Krallık içinde yerinde tutun ve bulutu yalnızca gerçek zamanlı yolda olmayan historian, analitik ve raporlama katmanları için düşünün.
• Hedef CSP'nizin Krallık içi bölgesi ihtiyacınız olan hizmet için henüz müşteri yönetimli anahtarları desteklemiyorsa veya CSP destek erişimi sınırlarını yazılı olarak teyit etmiyorsa, özellikle sınıflandırılmış iş yükü göçünü erteleyin — mevcut takvimde varlığınızın düzenlenmemiş kısmını yine de göç ettirebilirsiniz.
• Maliyet, projeyi durdurmak için değil aşamalara ayırmak için meşru bir sebeptir. Yukarıdaki hesaplanmış tahmin, belirli bir iş yükü için kuruluşunuzun getiri eşiğini geçmiyorsa, açık işlem gücü veya ölçek faydası olan şeyi göç ettiren — sınıflandırılmış veriyi Krallık içinde yerinde tutan — hibrit bir yaklaşım, modernizasyon başarısızlığı değil savunulabilir bir stratejidir.

Sık Yapılan Hatalar

• Veri sınıflandırma çalışması tamamlanmadan CSP sözleşmesini imzalamak.
• "CSP'nin Suudi Arabistan bölgesi var" ifadesini, anahtar ikametgahını, destek erişim sınırlarını ve spesifik hizmet için CST kaydını kontrol etmeden "ikametgah yükümlülüğümüz karşılandı" ile eşdeğer saymak.
• Müşteri yönetimli anahtarların takvime bir sprint eklemesi yüzünden sınıflandırılmış iş yükleri için CSP'nin varsayılan yönetilen şifreleme anahtarlarını kullanmak.
• NCA ECC boşluk analizini yalnızca mevcut yerinde ortamınıza karşı çalıştırıp, iş yükleri temelde farklı bir paylaşılan sorumluluk modeline taşındığında sonucun hâlâ geçerli olduğunu varsaymak.
• Pilot göçü atlayıp düzenlenmiş bir iş yükünü doğrudan yeni iniş bölgesinde üretime almak.
• Günlük saklamayı ve SOC entegrasyonunu iniş bölgesi ön koşulu yerine canlıya geçiş sonrası bir görev olarak ele almak.
• 2023 Cloud Computing Services Provisioning Regulations'tan sonra CCRF v3'ün tam ikametgah metninin hâlâ birebir geçerli olduğunu, güncel CST metnini kontrol etmeden varsaymak.

Sıkça Sorulan Sorular

AWS veya Azure'u Suudi Arabistan'da düzenlenmiş veri için kullanmak yasal mı? Evet, belirli koşullarla: spesifik CSP tüzel kişiliğinin ilgili hizmet kategorisi için CST'ye kayıtlı olması, verinin CCRF modeline göre sınıflandırmasının ikametgah gereksinimlerini karşılayan bir bölge ve sözleşme koşullarıyla eşleşmesi gerekir; Suudi Devlet Verisi için ise açık bir yasal istisna olmadıkça veri genel olarak Krallık'tan çıkamaz.

NCA ECC ile SAMA siber güvenlik çerçevesi arasındaki fark nedir? NCA ECC, Krallık genelinde kapsam dahilindeki kuruluşlar için Temel Siber Güvenlik Kontrolleri'nin belirlediği ulusal temeldir. SAMA'nın siber güvenlik çerçevesi ise Suudi Merkez Bankası'nın denetlediği bankalar, sigorta şirketleri ve finans kuruluşları için sektörel bir üst katmandır ve tipik olarak NCA ECC'nin yerine değil üzerine ek gereksinimler ekler.

Suudi devlet verisi Suudi Arabistan dışında saklanabilir mi? CCRF'nin kurduğu sınıflandırma modeline göre, top secret, secret, confidential ve public katmanlarına ayrılan Suudi Devlet Verisi, yasa veya düzenlemeyle açıkça izin verilmedikçe geçici ya da kalıcı olarak Krallık dışına aktarılamaz. Herhangi bir istisnaya güvenmeden önce güncel metni CST ve hukuk danışmanınızla teyit edin.

CITC hâlâ var mı, yoksa artık CST mi? CITC, Aralık 2022'de uzay sektörü gözetimini de kapsayan genişletilmiş bir yetkiyle Communications, Space & Technology Commission (CST) olarak yeniden markalandı. Güncel bulut lisanslama veya CCRF ile ilgili belgeler düzenleyici olarak CST'ye atıfta bulunmalı.

Müşteri yönetimli anahtar nedir ve Suudi Arabistan'da buna ihtiyacım var mı? Müşteri yönetimli anahtar (CMK), CSP'nin varsayılan yönetilen anahtarına güvenmek yerine yaşam döngüsünü sizin kontrol ettiğiniz bir şifreleme anahtarıdır. Suudi Arabistan'da sınıflandırılmış veya kısıtlı katmandaki veri için, anahtar sorumlusu rolü altyapı yöneticinizden ayrılmış Krallık içi bir CMK, ikametgah ve denetim pozisyonunuzu ciddi ölçüde güçlendirir.

Bir Suudi kurumu için NCA ECC kapsamında bulut geçişi ne kadar sürer? Orta ölçekli düzenlenmiş bir iş yükü seti için, veri sınıflandırması ve NCA ECC boşluk analizi iniş bölgesi kurulumu başlamadan önce tamamlandığında uçtan uca yaklaşık dört ila yedi ay planlayın. Bu sıralamayı atlamak, çok aylık takvim kaymalarının en yaygın nedenidir.

İlgili İçerikler

• SAMA & NESA Siber Güvenlik Uyum Rehberi — Krallık'ta ve daha geniş Körfez'de finans kuruluşlarının NCA ECC üzerine ihtiyaç duyduğu sektörel üst katman.
• B2B DevSecOps Uyum Yol Haritası — iniş bölgesi değişikliklerinizi canlıya taşıyan pipeline'a uyumluluk kontrollerini nasıl gömersiniz.
• KVKK Veri Koruma Uyum Yol Haritası — Suudi göçünüz Türkiye'de işlenen veriye de değiyorsa faydalı bir karşılaştırma noktası.
• Monolitten Mikroservislere Geçiş Rehberi — düzenlenmiş bulut göçüyle sıklıkla paralel yürüyen mimari ayrıştırma çalışması.

D-Elite Solutions ile Görüşün

D-Elite Solutions mühendislik ve güvenlik ekibi, Krallık içinde faaliyet gösteren kuruluşlar için NCA ECC ve CCRF gereksinimlerine karşı iniş bölgeleri tasarlıyor ve denetliyor; finans hizmetleri ve sağlık dahil düzenlenmiş sektörler genelinde. https://www.d-elite.solutions/tr/free-consultation adresinden bir görüşme ayırtın; mevcut veri sınıflandırmanızı ve CSP kısa listenizi NCA ECC ile CST kayıt durumuna göre gözden geçirelim ve imzalamadan önce düzeltmeye değer ikametgah risklerini işaretleyelim — hiçbir yükümlülük olmadan.