Sektörel Bilişim Denetimlerinde Yazılım Mimarisi Kriterleri

Sektörel Bilişim Denetimlerinde Yazılım Mimarisi Kriterleri, yalnızca kullanılan teknolojiye bakılarak değerlendirilemez. Asıl soru şudur: Kurulan sistem, taşıdığı riske uygun kontroller üretiyor mu ve bu kontrollerin gerçekten çalıştığı kanıtlanabiliyor mu?

İyi bir mimari denetiminde güvenlik, performans, süreklilik, ölçeklenebilirlik ve sürdürülebilirlik aynı resmin parçalarıdır. Bu rehberde bilişim denetimlerinde yazılım mimarisi kriterleri nelerdir, kurumsal yazılım mimarisi denetimi nasıl yapılır ve teknik kontroller denetim kanıtına nasıl dönüştürülür sorularına uygulama odaklı yanıtlar bulacaksınız.

Özellikle yazılım mimarisi denetiminde güvenlik ölçeklenebilirlik performans ve sürdürülebilirlik kriterleri değerlendirilirken mimari diyagramdan CI/CD kayıtlarına, API güvenliğinden yedek geri dönüş testlerine kadar bütün zincirin birlikte ele alınması gerekir.

Sektörel Bilişim Denetimi Nedir?

Sektörel bilişim denetimi, bir kurumun bilgi sistemlerini yalnızca genel güvenlik prensiplerine göre değil, faaliyet gösterdiği alanın düzenleyici gereksinimlerine göre de değerlendiren risk odaklı bir süreçtir.

Bilgi Sistemleri Denetimi ile Yazılım Denetimi Arasındaki Fark

Bilgi sistemleri denetimi altyapı, süreç, erişim, operasyon ve yönetişimi kapsarken yazılım denetimi uygulama koduna, mimariye, veri akışlarına, entegrasyonlara ve yazılım yaşam döngüsüne daha fazla odaklanır.

Sektörel Denetim Neden Genel BT Denetiminden Farklıdır?

Çünkü finans, ödeme, sermaye piyasası, kamu veya kişisel veri işleme gibi alanlarda risk toleransı ve kanıt beklentisi farklıdır. Aynı teknik çözüm, iki farklı sektörde aynı uyum sonucunu vermeyebilir.

Yazılım Mimarisi Neden Denetim Kapsamına Girer?

Mimari kararlar kimlik doğrulama, yetkilendirme, loglama, veri saklama, hata toleransı ve değişiklik yönetimi gibi kontrollerin nerede ve nasıl uygulanacağını belirler. Bu nedenle mimari, kontrol ortamının teknik temelidir.

Denetimde Üç Temel Soru

Denetimde değerlendirme çoğu zaman üç basit soruya indirgenebilir: Kontrol doğru tasarlanmış mı, çalışıyor mu ve çalıştığı kanıtlanabiliyor mu?

Kontrol Doğru Tasarlanmış mı?

Kontrol, belirlenen riski azaltacak kapsam ve teknik derinliğe sahip olmalıdır.

Kontrol Gerçekte Çalışıyor mu?

Dokümanda yazması yeterli değildir. Production ortamında aynı kontrolün uygulanması gerekir.

Kontrol Kanıtlanabiliyor mu?

Log, konfigürasyon kaydı, test sonucu veya sistemsel kayıt olmadan çalışan bir kontrolün denetlenmesi zorlaşır.

Yazılım Mimarisinin Denetlenebilir Olması Ne Demektir?

Denetlenebilir mimari, kritik işlemlerin izlenebildiği, mimari kararların gerekçelerinin bulunduğu ve kontrollerin kanıt üretebildiği mimaridir.

Denetlenebilirlik (Auditability) Kavramı

Auditability, bir sistemde neyin, kim tarafından, ne zaman ve hangi kontrol altında gerçekleştiğinin sonradan güvenilir biçimde doğrulanabilmesidir.

Mimari Kararların İzlenebilirliği

Bir servis neden ayrıldı, neden belirli bir veri merkezi seçildi veya neden belirli bir yetkilendirme yöntemi kullanıldı sorularının kayıtlı cevapları bulunmalıdır.

İş Gereksinimi → Risk → Kontrol → Teknik Uygulama Zinciri

Denetimde güçlü bir model, her iş gereksinimini ilgili riskle, riski kontrolle ve kontrolü gerçek teknik uygulamayla eşleştirir.

Denetim Kanıtı Üretebilen Mimari

Örneğin yönetici yetkisi değiştirildiğinde yalnızca veritabanında yeni rolün görünmesi değil, değişikliği kimin yaptığına ilişkin audit kaydının oluşması beklenir.

Tasarım ile Gerçek Production Ortamı Arasındaki Tutarlılık

Diyagramda olmayan bir servis, kayıt dışı bir entegrasyon veya manuel açılmış bir firewall kuralı önemli kontrol boşluklarına neden olabilir.

Sektöre Göre Hangi Düzenlemeler Dikkate Alınır?

Uygulanacak düzenleme kurumun faaliyetine, tuttuğu veriye, sunduğu hizmete ve yasal kapsamına göre belirlenmelidir. Tek bir kontrol listesi bütün kuruluşlar için yeterli değildir.

Bankacılık

Bankacılık sistemlerinde kimlik doğrulama, işlem güvenliği, erişim kontrolü, iş sürekliliği ve bilgi sistemleri yönetişimi mimari incelemenin önemli parçalarıdır.

BDDK Bilgi Sistemleri Düzenlemeleri

BDDK'nın güncel mevzuat listesinde Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik ile bilgi sistemleri ve iş süreçleri denetimine ilişkin çeşitli düzenlemeler yer almaktadır. Mimari değerlendirme yapılırken kapsamın kurum özelinde belirlenmesi gerekir. :contentReference[oaicite:0]{index=0}

Sermaye Piyasaları

Sermaye piyasası kurumlarında bilgi sistemlerinin güvenli, etkin ve sürekli çalışması doğrudan operasyonel risk yönetimiyle ilişkilidir.

SPK Bilgi Sistemleri Düzenlemeleri

SPK'nın VII-128.9 sayılı Bilgi Sistemleri Yönetimi Tebliği ve III-62.2 sayılı Bilgi Sistemleri Bağımsız Denetim Tebliği, bilgi sistemlerinin yönetimi ve denetim yaklaşımı açısından temel referanslar arasındadır. SPK rehberinde denetim kapsamının risk ve önemlilik esasına göre belirlenmesi de vurgulanmaktadır. :contentReference[oaicite:1]{index=1}

Ödeme ve Elektronik Para

Ödeme akışları yüksek işlem hacmi, kullanıcı kimliği, entegrasyon ve kesintisizlik nedeniyle mimari denetimde özel dikkat gerektirir.

TCMB Bilgi Sistemleri Düzenlemeleri

TCMB'nin ödeme hizmetleri mevzuatı kapsamında bilgi sistemleri ile ödeme hizmetlerindeki veri paylaşım servislerine yönelik düzenlemeler bulunmaktadır. Bu nedenle API güvenliği, veri yerleşimi ve operasyonel süreklilik mimari denetimde öne çıkar. :contentReference[oaicite:2]{index=2}

E-Belge ve Özel Entegratörler

E-belge sistemleri işlem bütünlüğü, belge kaybının önlenmesi, kullanıcı hesaplarının yönetimi ve entegrasyon sürekliliği açısından değerlendirilmelidir.

GİB Gereksinimleri

GİB'in özel entegrasyon dokümanlarında entegrasyon testleri ve kullanıcı hesaplarının yönetimi gibi teknik beklentiler yer almaktadır. Mimari kontrol listesi hazırlanırken kullanılan e-belge türüne ait güncel teknik doküman ayrıca kontrol edilmelidir. :contentReference[oaicite:3]{index=3}

Kişisel Veri İşleyen Sistemler

Kişisel veri işleyen uygulamalarda veri akışları, erişim yetkileri, saklama süreleri, loglama ve üçüncü taraf veri aktarımları birlikte değerlendirilir.

KVKK Gereksinimleri

KVKK'nın veri güvenliği yaklaşımı, hukuka aykırı işlemeyi ve erişimi önlemeyi ve kişisel verilerin korunmasını sağlayacak teknik ve idari tedbirlerin alınmasını gerektirir. Kurum rehberinde log kayıtları, veri maskeleme, yedekleme ve anahtar yönetimi gibi teknik tedbir örnekleri de yer almaktadır. :contentReference[oaicite:4]{index=4}

Kamu Sistemleri

Kamu sistemlerinde bilgi güvenliği, hizmet sürekliliği, yetkilendirme, kayıt yönetimi ve veri sınıflandırması mimari tasarımın parçası olmalıdır.

Bilgi ve İletişim Güvenliği Rehberi

Kapsama giren kamu sistemlerinde ilgili rehber ve kurumun kendi güvenlik politikaları mimari kontrol setine çevrilerek uygulanmalıdır.

Uluslararası Çerçeveler

Uluslararası standartlar mevzuatın yerine geçmez. Ancak risk, yönetişim, güvenlik ve süreklilik kontrollerinin sistematik biçimde değerlendirilmesine yardımcı olur.

ISO/IEC 27001

ISO/IEC 27001:2022, bilgi güvenliği yönetim sistemi için gereksinimleri tanımlar ve bilgi güvenliği risklerinin yönetilmesi açısından kurumsal bir çerçeve sağlar. :contentReference[oaicite:5]{index=5}

ISO 22301

ISO 22301 iş sürekliliği yönetimine odaklanır. Mimari tarafta RTO, RPO, kurtarma yöntemleri ve kritik bağımlılıkların süreklilik hedefleriyle ilişkisini değerlendirmek için yararlıdır. :contentReference[oaicite:6]{index=6}

COBIT

COBIT, bilgi teknolojilerinin kurumsal yönetişimi ve yönetimi açısından süreç, sorumluluk ve kontrol yaklaşımının yapılandırılmasına yardımcı olabilir.

NIST

NIST Cybersecurity Framework 2.0, Govern, Identify, Protect, Detect, Respond ve Recover fonksiyonlarıyla siber risk yönetimini kurumsal süreçlere bağlayan bir yapı sunar. :contentReference[oaicite:7]{index=7}

OWASP

OWASP ASVS, web uygulamalarındaki teknik güvenlik kontrollerinin doğrulanması ve güvenli geliştirme gereksinimlerinin belirlenmesi için kullanılabilecek açık bir referanstır. Güncel kararlı sürüm olarak ASVS 5.0.0 yayımlanmıştır. :contentReference[oaicite:8]{index=8}

Regülasyon Gereksinimleri Teknik Mimariye Nasıl Dönüştürülür?

Burada en önemli iş, hukuki veya yönetsel bir cümleyi uygulanabilir ve test edilebilir teknik gereksinime çevirmektir.

Mevzuat Maddesini Teknik Kontrole Çevirmek

Örneğin yetkisiz erişimin önlenmesi gereksinimi, MFA, RBAC, oturum politikası ve erişim logları gibi birden fazla teknik kontrole dönüşebilir.

Kontrol Objective Oluşturmak

Kontrol objective, neyin korunmak istendiğini açıkça söyler. Teknik detay daha sonra bu hedefe bağlanır.

Teknik Acceptance Criteria Belirlemek

Bir kontrolün başarılı sayılması için test edilebilir koşullar belirlenmelidir. Örneğin ayrıcalıklı hesapların tamamında MFA zorunluluğu ölçülebilir bir kriterdir.

Denetim Kanıtını Önceden Tanımlamak

Kontrol tasarlanırken hangi logun, konfigürasyon çıktısının veya test raporunun kanıt olacağı da belirlenmelidir.

Compliance Traceability Matrix Oluşturmak

Traceability matrix, mevzuat ile gerçek sistem arasındaki bağı görünür hale getirir.

Regülasyon Maddesi

Kontrolün hangi düzenleme veya kurumsal gereksinimden kaynaklandığı yazılır.

Risk

Gereksinimin azaltmayı amaçladığı risk tanımlanır.

Mimari Kontrol

Riski azaltmak için mimaride hangi kontrolün tasarlandığı belirtilir.

Uygulama

Kontrolün hangi servis, altyapı veya bileşende uygulandığı gösterilir.

Kanıt

Denetçinin kontrolü doğrulamak için kullanacağı sistemsel çıktı belirlenir.

Sorumlu Ekip

Kontrolün işletilmesinden ve iyileştirilmesinden sorumlu ekip açıkça atanır.

Mimari Dokümantasyon Denetiminde Arananlar

Dokümantasyon yalnızca görsel anlatım değildir. Sistem sınırlarını, bağımlılıkları ve risk noktalarını görünür kılan kontrol aracıdır.

System Context Diagram

Sistemin kullanıcıları, dış aktörleri ve bağlı olduğu diğer platformlar gösterilmelidir.

Container ve Component Diyagramları

Uygulama bileşenlerinin sorumlulukları ve kritik iletişim kanalları anlaşılabilir olmalıdır.

Deployment Diagram

Servislerin hangi ortamda, hangi altyapı üzerinde ve hangi güvenlik sınırları içinde çalıştığı belirtilmelidir.

Network Diagram

Ağ segmentleri, internet çıkışları, güvenlik katmanları ve kritik bağlantılar görünür olmalıdır.

Data Flow Diagram

Verinin kaynaktan hedefe hangi servislerden ve güven sınırlarından geçtiği gösterilmelidir.

Trust Boundary'ler

Güven seviyesinin değiştiği sınırlar belirlenmeli ve bu noktalarda uygulanacak doğrulamalar tanımlanmalıdır.

Entegrasyon Haritası

API, mesaj kuyruğu, dosya transferi ve dış servis bağlantılarının tamamı envanterde yer almalıdır.

Kritik Dependency Haritası

Bir kritik servisin çalışmak için bağımlı olduğu veritabanı, kimlik servisi, DNS, queue ve dış servisler belirlenmelidir.

Dokümantasyonun Production ile Güncel Tutulması

Denetimde en sık sorunlardan biri, dokümanın geçmiş mimariyi anlatmasıdır. Otomatik envanter ve düzenli architecture review bu riski azaltır.

Architecture Decision Record (ADR) Denetimi

ADR Nedir?

ADR, önemli bir mimari kararın bağlamını, seçeneklerini, riskini ve gerekçesini kayıt altına alan kısa dokümandır.

Kritik Mimari Kararlar Neden Kayıt Altına Alınmalıdır?

Çünkü yıllar sonra bir kararın neden alındığını yalnızca ekip hafızasına güvenerek açıklamak sağlıklı değildir.

ADR'de Bulunması Gereken Alanlar

ADR sade olabilir fakat kararın denetlenebilmesi için temel bilgileri içermelidir.

Problem

Çözülmek istenen teknik veya iş problemi açıkça yazılmalıdır.

Alternatifler

Değerlendirilen seçenekler kayıt altına alınmalıdır.

Risk

Her seçeneğin güvenlik, maliyet, süreklilik ve işletim riskleri belirtilmelidir.

Karar

Seçilen yaklaşım net biçimde yazılmalıdır.

Gerekçe

Kararın hangi kriterlere dayanarak verildiği açıklanmalıdır.

Güvenlik ve Uyum Etkisi

Kararın erişim, veri, kayıt, mevzuat ve süreklilik üzerindeki etkileri değerlendirilmelidir.

Eski Mimari Kararların Yeniden Gözden Geçirilmesi

Yıllar önce kabul edilebilir olan bir risk bugün aynı seviyede olmayabilir. Kritik ADR kayıtları belirli aralıklarla tekrar değerlendirilmelidir.

Yazılım Mimarisinde Risk Değerlendirmesi

Varlıkları Belirleme

Kritik servisler, veriler, kimlik altyapıları ve iş süreçleri envantere alınmalıdır.

Tehditları Belirleme

Varlıkları etkileyebilecek yetkisiz erişim, veri kaybı, servis kesintisi ve manipülasyon senaryoları belirlenmelidir.

Zafiyetleri Belirleme

Eksik kimlik doğrulama, yanlış konfigürasyon veya desteklenmeyen bileşen gibi zayıflıklar tespit edilmelidir.

Olasılık ve Etki

Risk yalnızca teknik olasılıkla değil, iş etkisiyle birlikte değerlendirilmelidir.

Risk Sahipliği

Her kritik riskin karar verebilecek bir sahibi bulunmalıdır.

Risk Kabul Kriterleri

Hangi risklerin hangi koşullarda kabul edilebileceği kurum politikasıyla belirlenmelidir.

Residual Risk

Kontroller uygulandıktan sonra kalan risk ayrıca değerlendirilmelidir.

Mimari Değişiklik Sonrası Risk Analizini Yenilemek

Yeni servis, entegrasyon veya veri akışı ortaya çıktığında eski risk analizi otomatik olarak geçerli kabul edilmemelidir.

Threat Modeling Mimari Denetimin Parçası Olmalı mı?

Evet. Özellikle kritik veya dışa açık sistemlerde threat modeling, tasarım aşamasında güvenlik zayıflıklarını görmek için güçlü bir yöntemdir.

Tehdit Modelleme Nedir?

Sisteme zarar verebilecek senaryoların mimari tasarım üzerinden sistematik biçimde incelenmesidir.

Veri Akış Diyagramları Üzerinden Tehdit Analizi

Verinin nereden geldiği, hangi servisten geçtiği ve nerede saklandığı analiz edilerek saldırı yüzeyi değerlendirilir.

Trust Boundary Analizi

Her güven sınırı geçişinde kimlik, yetki, şifreleme ve doğrulama gereksinimleri kontrol edilir.

STRIDE Yaklaşımı

STRIDE; kimliğe bürünme, veri değiştirme, inkâr, bilgi ifşası, hizmet engelleme ve yetki yükseltme gibi tehdit sınıflarını düşünmek için kullanılabilir.

Abuse Case'ler

Sistemin normal kullanımından farklı olarak kötüye kullanım senaryoları tasarlanmalıdır.

Threat Model ile Test Senaryolarını Bağlamak

Belirlenen tehditlerin en azından kritik olanları güvenlik veya entegrasyon testleriyle doğrulanmalıdır.

Kimlik Doğrulama Mimarisi

Merkezi Kimlik Yönetimi

Dağınık kullanıcı depoları yerine merkezi kimlik yönetimi, erişim kontrolünü ve hesap kapatma süreçlerini kolaylaştırır.

Multi-Factor Authentication

Özellikle ayrıcalıklı ve kritik erişimlerde tek faktöre bağımlılık azaltılmalıdır. KVKK da kullanıcı güvenliğine ilişkin duyurularında iki aşamalı doğrulamayı tavsiye edilen önlemler arasında saymaktadır. :contentReference[oaicite:9]{index=9}

Single Sign-On

SSO merkezi kontrol sağlar ancak kimlik sağlayıcısını kritik bir bağımlılığa dönüştürdüğü için yüksek erişilebilirlik gerektirir.

OAuth ve OpenID Connect

Akış tipi, token kapsamı, redirect URI ve istemci güvenliği denetim kapsamına alınmalıdır.

Machine-to-Machine Authentication

Servislerin statik kullanıcı parolalarıyla değil, yönetilebilir servis kimlikleriyle doğrulanması tercih edilmelidir.

Servis Kimlikleri

Her servisin ayrı kimliği bulunmalı, ortak kimlikler azaltılmalıdır.

Token Lifecycle

Token güvenliği yalnızca üretim aşamasından ibaret değildir.

Issuance

Token yalnızca doğrulanmış ve yetkili istemcilere verilmelidir.

Rotation

Uzun ömürlü anahtar ve kimlik bilgileri için yenileme mekanizması bulunmalıdır.

Revocation

Ele geçirilen veya artık kullanılmayan token ve kimlik bilgilerinin iptali mümkün olmalıdır.

Expiration

Token geçerlilik süreleri risk seviyesine göre sınırlandırılmalıdır.

Yetkilendirme Mimarisinin Denetimi

Least Privilege

Kullanıcı ve servisler yalnızca görevlerini gerçekleştirmek için gerekli yetkilere sahip olmalıdır.

Need-to-Know

Bir kullanıcının sisteme erişebilmesi, bütün verilere erişebilmesi anlamına gelmemelidir.

Role-Based Access Control

Yetkiler roller üzerinden yönetildiğinde erişim incelemeleri daha anlaşılır hale gelir.

Attribute-Based Access Control

Departman, veri sınıfı veya işlem bağlamı gibi özelliklere göre daha dinamik erişim kararları üretilebilir.

Privileged Access

Ayrıcalıklı hesaplar normal kullanıcı hesaplarından ayrı yönetilmelidir.

Yetki Matrisleri

Rol, işlem ve veri erişimi ilişkisi merkezi bir matriste gösterilmelidir.

Periyodik Access Review

Yetkiler belirli aralıklarla iş birimi sahipleri tarafından yeniden doğrulanmalıdır.

Yetkisiz Privilege Escalation'ın Önlenmesi

Rol değişikliği ve ayrıcalık verme işlemleri onay ve audit log mekanizmalarına bağlanmalıdır.

Görevler Ayrılığı (Segregation of Duties)

Geliştirici Production'a Erişmeli mi?

Varsayılan model doğrudan ve sürekli erişim vermemektir. Gerekli durumlarda süreli, onaylı ve kayıtlı erişim uygulanabilir.

Kod Yazma ve Kod Onaylama Ayrımı

Kritik değişikliklerde kodu yazan kişinin tek başına değişikliği onaylamaması güçlü bir kontroldür.

Deployment Yetkilerinin Ayrılması

Deployment mümkün olduğunca pipeline üzerinden ve önceden tanımlanmış yetki modeliyle gerçekleştirilmelidir.

Database Yetkilerinin Ayrılması

Uygulama geliştirme rolü ile production veritabanı yönetim rolü ayrılmalıdır.

Acil Durum Yetkileri

Kesinti veya güvenlik olayı için geçici ayrıcalıklı erişim süreçleri tanımlanabilir.

Break-Glass Access

Break-glass erişim süreli, gerekçeli ve sonradan incelenebilir olmalıdır.

Privileged İşlemlerin Loglanması

Ayrıcalıklı kullanıcı işlemleri merkezi ve değiştirilemez kayıtlara gönderilmelidir.

Zero Trust Mimari Kriterleri

Network Konumuna Güvenmemek

Bir isteğin kurum ağı içinden gelmesi tek başına güven göstergesi sayılmamalıdır.

Her İsteği Doğrulamak

Kimlik, cihaz, servis ve işlem bağlamı dikkate alınmalıdır.

Service-to-Service Authentication

İç servis trafiğinde de karşılıklı kimlik doğrulama uygulanmalıdır.

Least Privilege

Servislerin gereksiz ağ, veri ve API yetkileri kaldırılmalıdır.

Network Segmentation

Kritik sistemler ağ seviyesinde diğer sistemlerden ayrılmalıdır.

Mikro Segmentasyon

Servis bazında iletişim izinleri tanımlanarak lateral movement riski azaltılabilir.

Sürekli Yetkilendirme

Uzun süreli güven varsayımı yerine oturum ve risk koşulları değiştikçe erişim tekrar değerlendirilebilir.

Veri Mimarisi Denetimi

Veri Sahipliği

Kritik veri kümelerinin iş ve teknik sahipleri belirlenmelidir.

Veri Sınıflandırması

Veriler hassasiyet ve iş etkisine göre sınıflandırılmalıdır.

Kritik ve Hassas Veri

Finansal, operasyonel veya güvenlik açısından kritik veriler daha güçlü erişim ve izleme kontrollerine tabi olmalıdır.

Kişisel Veri

Kişisel veri envanteri, uygulama veri modeli ve gerçek veri akışları arasında uyum aranmalıdır.

Veri Akışlarının Dokümantasyonu

Verinin kaynak, işleme, aktarım ve saklama noktaları belgelenmelidir.

Veri Yaşam Döngüsü

Veri mimarisi yalnızca saklamayı değil verinin bütün yaşam sürecini kapsamalıdır.

Oluşturma

Verinin kaynağı ve doğrulama yöntemi bilinmelidir.

İşleme

Verinin hangi amaçla ve hangi servislerde işlendiği kayıt altına alınmalıdır.

Saklama

Saklama ortamı ve erişim politikası veri sınıfına uygun olmalıdır.

Arşivleme

Arşivlenen verinin erişilebilirlik ve güvenlik koşulları belirlenmelidir.

Silme

Saklama süresi sona eren veriler için doğrulanabilir silme süreçleri bulunmalıdır.

Veri Bütünlüğü Kontrolleri

Input Validation

Dışarıdan gelen veriler tip, format, uzunluk ve iş kuralı bakımından doğrulanmalıdır.

Business Rule Validation

Teknik olarak geçerli ancak iş açısından hatalı işlemler engellenmelidir.

Referential Integrity

İlişkisel veri yapılarında bağımlı kayıtların bütünlüğü korunmalıdır.

Transaction Integrity

Birden fazla adım içeren kritik işlemlerde yarım kalan durumların önüne geçilmelidir.

Duplicate İşlem Önleme

Ödeme veya sipariş gibi işlemlerde tekrar gönderim sonucu çift kayıt oluşması engellenmelidir.

Idempotency

Aynı isteğin tekrar işlenmesi halinde öngörülebilir sonuç üretilmesi özellikle API sistemlerinde önemlidir.

Reconciliation

Farklı sistemlerde tutulan kritik işlem kayıtları düzenli karşılaştırmalarla doğrulanmalıdır.

Veri Kaybının Tespit Edilmesi

Sıra numarası, kayıt sayısı, checksum veya reconciliation gibi kontroller kullanılabilir.

Şifreleme Mimarisi

Data at Rest

Disk, veritabanı, yedek ve obje depolama katmanlarında hassas veri için uygun şifreleme uygulanmalıdır.

Data in Transit

Servisler arası ve dış iletişimde güvenli taşıma protokolleri kullanılmalıdır.

TLS Politikaları

Desteklenen protokol ve cipher politikaları merkezi olarak yönetilmelidir.

Alan Seviyesinde Şifreleme

Çok hassas veriler için yalnızca disk şifreleme yeterli görülmeyebilir.

Anahtar Yönetimi

Şifreleme güvenliği, anahtarların nasıl üretildiği ve korunduğuyla doğrudan ilişkilidir.

Key Generation

Anahtar üretimi güvenilir yöntemlerle gerçekleştirilmelidir.

Storage

Anahtarlar uygulama kodundan ve normal konfigürasyon dosyalarından ayrılmalıdır.

Rotation

Anahtar yenileme planı bulunmalıdır.

Revocation

Şüpheli veya artık kullanılmayan anahtarların hızlı biçimde iptali mümkün olmalıdır.

HSM ve KMS Kullanımı

Kritik anahtarlar için merkezi KMS veya uygun durumlarda HSM kullanımı değerlendirilebilir.

Anahtarla Şifrelenmiş Verinin Aynı Yerde Tutulmaması

Veri ve onu açabilen anahtarın kontrolsüz biçimde aynı güvenlik alanında tutulması koruma seviyesini düşürür.

Veri Yerleşimi ve Veri Egemenliği

Verinin Fiziksel Olarak Nerede Tutulduğu

Veri lokasyonu mimari envanterde bilinmelidir.

Primary Sistemler

Birincil sistemlerin fiziksel ve mantıksal lokasyonu kaydedilmelidir.

Secondary Sistemler

İkincil sistemlerin lokasyonu düzenleyici ve iş sürekliliği gereksinimleriyle uyumlu olmalıdır.

Backup Lokasyonları

Yedeklerin tutulduğu ülke, bölge ve sağlayıcı görünür olmalıdır.

Cloud Region Seçimi

Region kararı gecikme kadar mevzuat ve veri transferi açısından da değerlendirilmelidir.

Cross-Border Data Transfer

Yurt dışı veri akışlarının teknik envanteri ve hukuki dayanağı birlikte değerlendirilmelidir.

SaaS Sağlayıcılarının Veri Lokasyonları

SaaS kullanılırken ana veri kadar yedek, log ve destek verilerinin lokasyonu da sorgulanmalıdır.

API Mimarisi Denetimi

API'ler modern sistemlerde en geniş saldırı ve entegrasyon yüzeylerinden biridir.

API Envanteri

Aktif, eski ve kurum içi API'lerin tamamı kayıt altında tutulmalıdır.

Authentication

API'lerin çağrıyı yapan istemciyi doğruladığı gösterilmelidir.

Authorization

Kimlik doğrulanan her istemcinin bütün kaynaklara erişmesine izin verilmemelidir.

Input Validation

Request alanları beklenen schema ve iş kurallarına göre doğrulanmalıdır.

Rate Limiting

Kötüye kullanım ve kaynak tüketimi riskine karşı uygun limitler uygulanmalıdır.

Schema Validation

Beklenmeyen alan veya veri tipleri reddedilmelidir.

API Versioning

Eski sürümlerin ne zaman kapatılacağı ve nasıl destekleneceği tanımlanmalıdır.

Error Handling

Hata yanıtları saldırgana iç sistem detaylarını vermemelidir.

Hassas Verinin Error Response'a Sızmasını Önlemek

Stack trace, kişisel veri, token ve veritabanı sorguları hata yanıtında gösterilmemelidir.

API Audit Logs

Kritik API çağrıları kimlik, kaynak, işlem ve sonuç bilgisiyle kaydedilmelidir.

Mikroservis Mimarisi Denetim Kriterleri

Mikroservis monolith API veritabanı ve entegrasyon mimarisi teknik denetim kontrol listesi hazırlanırken teknoloji adına değil, oluşturduğu güvenlik ve operasyon modeline bakılmalıdır.

Service Ownership

Her servisin sahibi olan ekip belirli olmalıdır.

Service Boundary

Servis sınırları yalnızca teknik kolaylığa göre değil, iş sorumluluğuna göre de değerlendirilmelidir.

Servisler Arası Kimlik Doğrulama

İç trafik güvenilir kabul edilmemeli, servis kimlikleri doğrulanmalıdır.

Distributed Transaction Riskleri

Birden fazla servise yayılan işlemlerde yarım kalan süreçlerin nasıl yönetileceği tasarlanmalıdır.

Eventual Consistency

Geçici tutarsızlığın iş etkisi ve düzeltme mekanizması tanımlanmalıdır.

Audit Trail Korelasyonu

Bir işlem farklı servislerden geçse bile ortak correlation ID ile izlenebilmelidir.

Merkezi Olmayan Yetkilendirme Riskleri

Her servisin farklı yetki mantığı kullanması tutarsız güvenlik politikalarına yol açabilir.

Dependency ve Failure Propagation

Bir servisteki hatanın zincirleme biçimde diğer servisleri düşürmesi engellenmelidir.

Monolitik Mimari Denetim Kriterleri

Module Isolation

Tek uygulama içinde olsa bile modüller arasında sorumluluk ve erişim sınırları korunmalıdır.

Privilege Boundary

Bütün modüllerin aynı ayrıcalıkla çalışması gereksiz risk yaratabilir.

Ortak Database Riskleri

Ortak veritabanında tablo erişimleri ve veri sahipliği iyi yönetilmelidir.

Değişiklik Etki Alanı

Küçük değişikliğin bütün uygulamayı etkileyip etkilemediği analiz edilmelidir.

Release Riskleri

Tek paket dağıtımı geniş etki alanı oluşturabileceği için test ve rollback kontrolleri güçlü olmalıdır.

Tek Nokta Arızaları

Uygulama, veritabanı ve altyapı katmanındaki tekil bağımlılıklar tespit edilmelidir.

Monolit Olmanın Tek Başına Bir Denetim Bulgusu Olmaması

Monolitik yapı tek başına zayıflık değildir. Denetçi kontrol tasarımına, dayanıklılığa ve değişiklik yönetimine bakmalıdır.

Multi-Tenant Sistemlerde Denetim Kriterleri

Tenant Isolation

Müşterilerin veri ve işlemleri birbirinden güvenli biçimde ayrılmalıdır.

Row-Level Security

Paylaşılan veritabanlarında tenant filtresinin yalnızca uygulama koduna bırakılmaması değerlendirilebilir.

Tenant-Specific Encryption

Risk seviyesine göre tenant bazlı anahtar ayrımı kullanılabilir.

Cross-Tenant Data Leakage

Bir tenant'ın başka tenant verisine erişemediği negatif testlerle doğrulanmalıdır.

Cache İzolasyonu

Cache key yapısı tenant karışmasını önlemelidir.

Log İzolasyonu

Log görüntüleme yetkileri tenant sınırını ihlal etmemelidir.

Backup ve Restore Sırasında Tenant Ayrımı

Tek müşterinin geri yüklenmesi gerektiğinde diğer tenant verilerinin etkilenip etkilenmediği analiz edilmelidir.

Cloud Mimarisinin Denetimi

Shared Responsibility Model

Hangi kontrolün hizmet sağlayıcıda, hangisinin kurumda olduğu açıkça bilinmelidir.

Cloud Account Yapısı

Production, test ve yönetim ortamlarının hesap veya proje seviyesinde ayrılması değerlendirilebilir.

IAM

Kullanıcı, servis rolü ve ayrıcalıklı yetkiler merkezi olarak yönetilmelidir.

Network Segmentation

Cloud ağları açık erişime dayanmamalı ve kritik kaynaklar özel segmentlerde tutulmalıdır.

Encryption

Depolama ve aktarım katmanlarındaki şifreleme politikaları kontrol edilmelidir.

Logging

Yönetim paneli, IAM ve kaynak değişiklikleri merkezi log sistemine aktarılmalıdır.

Cloud Security Posture

Yanlış konfigürasyonların düzenli olarak tespit edildiği bir kontrol mekanizması kurulmalıdır.

Region ve Veri Yerleşimi

Kaynakların açıldığı region veri yerleşimi politikasıyla uyumlu olmalıdır.

Provider Bağımlılığı

Kritik hizmetlerde sağlayıcı kesintisi ve çıkış senaryosu önceden değerlendirilmelidir.

Dış Hizmet ve SaaS Mimarisinin Denetimi

Third-Party Risk Assessment

Dış hizmet sağlayıcının güvenlik ve süreklilik riski hizmet kullanılmadan önce değerlendirilmelidir.

Veri İşleyen Alt Yükleniciler

Hizmet zincirinde veriye erişebilen alt yükleniciler görünür olmalıdır.

SLA

Kritik hizmetler için kullanılabilirlik ve destek hedefleri açıkça belirlenmelidir.

Güvenlik Yükümlülükleri

Sözleşmede erişim, veri koruma ve olay yönetimi sorumlulukları yer almalıdır.

Denetim Hakkı

Gerektiğinde kontrol kanıtlarının incelenebilmesini sağlayan hükümler değerlendirilmelidir.

Incident Notification

Güvenlik olayının hangi sürede ve hangi bilgilerle bildirileceği tanımlanmalıdır.

Veri İade ve Silme

Sözleşme sona erdiğinde verinin iadesi ve silinmesinin nasıl kanıtlanacağı belirlenmelidir.

Exit Plan

Kritik SaaS hizmetinden çıkış senaryosu yalnızca sözleşmesel değil teknik olarak da planlanmalıdır.

Açık Kaynak Yazılımlar Denetimde Nasıl Değerlendirilir?

Open Source Kullanımı Bir Risk midir?

Açık kaynak kullanmak tek başına risk değildir. Asıl risk, kullanılan bileşenin bilinmemesi, güncellenmemesi veya kaynağının doğrulanmamasıdır.

Dependency Inventory

Uygulamanın kullandığı doğrudan ve dolaylı bağımlılıklar envanterde yer almalıdır.

Lisans Uyumluluğu

Lisans koşullarının kurum politikaları ve ürün dağıtım modeliyle uyumu değerlendirilmelidir.

Bilinen Zafiyetler

Bağımlılıklar bilinen güvenlik açıkları açısından düzenli taranmalıdır.

Bakımı Sonlandırılmış Projeler

Uzun süredir güncellenmeyen kritik paketler için değiştirme planı hazırlanmalıdır.

Güvenilir Kaynaktan Paket Alma

Build sistemleri yalnızca onaylı repository ve package registry kaynaklarını kullanmalıdır.

Dependency Pinning

Kontrolsüz sürüm değişikliklerini azaltmak için bağımlılık sürümleri yönetilmelidir.

Açık Kaynak ve İşbirliğinin Güvenli Yönetimi

Açık kaynak güvenliği, yalnızca paket taraması değildir. Katkı politikası, code review, sürüm takibi ve tedarik zinciri kontrolleri birlikte ele alınmalıdır. Diyarbakır Yazılım Topluluğu'nun açık kaynak güvenliği ve kurumsal adaptasyon yaklaşımını şu içerikte inceleyebilirsiniz: https://www.diyarbakiryazilim.com.tr/posts/acik-kaynak-teknolojilerinde-guvenlik-ve-kurumsal-adaptasyon

Software Bill of Materials (SBOM)

SBOM Nedir?

SBOM, yazılım paketinin içinde bulunan bileşenlerin ve bağımlılıkların makine tarafından işlenebilir envanteridir.

Hangi Dependency'ler Ürünün İçinde?

Üretime çıkan artifact içinde gerçekte hangi kütüphanelerin bulunduğu görülebilmelidir.

Transitive Dependency'ler

Doğrudan eklenmemiş fakat başka paketler üzerinden gelen bağımlılıklar da kapsama alınmalıdır.

CVE ile SBOM Eşleştirme

Yeni bir güvenlik açığı yayımlandığında hangi ürünlerin etkilendiği hızlıca belirlenebilmelidir.

SBOM'u CI/CD'de Otomatik Üretmek

Her build sırasında SBOM oluşturulması güncellik sorununu azaltır.

Denetçiye SBOM Kanıtı Sunmak

SBOM üretim tarihi, build kimliği ve artifact sürümüyle ilişkilendirilmelidir.

Software Supply Chain Güvenliği

Kaynak Kod Bütünlüğü

Üretime giren kodun onaylanmış repository içeriğiyle aynı olduğu doğrulanmalıdır.

Repository Access

Repository erişimleri rol bazlı ve kayıtlı olmalıdır.

Branch Protection

Kritik branch'lere doğrudan push sınırlandırılmalıdır.

Pull Request Approval

Production kodunda bağımsız gözden geçirme mekanizması kullanılmalıdır.

Dependency Security

Paket kaynakları ve sürümleri kontrol altında tutulmalıdır.

Build Server Güvenliği

Build sunucusuna erişim, secret kullanımı ve çalışma ortamı ayrıca denetlenmelidir.

Artifact Signing

Artifact imzalama, dağıtılan paketin kaynağını ve bütünlüğünü doğrulamaya yardımcı olabilir.

Provenance

Bir artifact'ın hangi kaynak koddan, hangi pipeline ve hangi build ortamından üretildiği izlenebilmelidir.

Güvenli Yazılım Geliştirme Yaşam Döngüsü (SSDLC)

Requirement

Güvenlik ve uyum gereksinimleri iş gereksinimleriyle birlikte tanımlanmalıdır.

Design

Threat model, veri akışı ve mimari kontrol kararları tasarım aşamasında ele alınmalıdır.

Development

Geliştiricilere güvenli kodlama standartları ve otomatik kontroller sağlanmalıdır.

Testing

Fonksiyonel testlerin yanında güvenlik ve kötüye kullanım testleri uygulanmalıdır.

Deployment

Dağıtım yetkileri ve onaylar pipeline üzerinden yönetilmelidir.

Operation

Loglama, izleme, patch ve olay yönetimi işletim aşamasının parçasıdır.

Retirement

Kapatılan servislerin hesapları, verileri ve dış erişimleri güvenli biçimde sonlandırılmalıdır.

Her Aşamada Güvenlik Kontrolü

Güvenliği yalnızca penetration test aşamasına bırakmak yerine yaşam döngüsünün tamamına yaymak daha güçlü kontrol ortamı oluşturur.

Source Code Management Denetimi

Versiyon Kontrolü Kullanılması

Production kodu merkezi versiyon kontrol sistemi üzerinden yönetilmelidir.

Commit İzlenebilirliği

Commit kaydı değişikliği yapan kişi ve iş kaydıyla ilişkilendirilebilmelidir.

Branch Protection

Korunan branch politikaları merkezi olarak uygulanmalıdır.

Code Owner

Kritik dizin ve bileşenler için sorumlu ekipler tanımlanmalıdır.

Pull Request Review

Değişikliklerin bağımsız gözden geçirilmesi hata ve kontrol ihlali riskini azaltır.

Kritik Kod İçin İki Kişi Onayı

Ödeme, kimlik veya yetkilendirme gibi kritik modüllerde ek onay katmanı düşünülebilir.

Repository Audit Log

Yetki, branch ve güvenlik politikası değişiklikleri kayıt altına alınmalıdır.

CI/CD Pipeline Denetim Kriterleri

Pipeline'a Kimler Müdahale Edebilir?

Pipeline tanımını değiştirme yetkisi sınırlı olmalıdır.

Build Kaynağının İzlenebilirliği

Her build belirli commit ve repository kaydıyla ilişkilendirilmelidir.

Test Gate'leri

Başarısız kritik testler production dağıtımını durdurmalıdır.

Security Gate'leri

Belirlenen önem seviyesindeki güvenlik bulguları deployment öncesinde politika kapsamında değerlendirilmelidir.

Approval Gate'leri

Riskli dağıtımlarda onay kayıtları otomatik süreçte tutulmalıdır.

Deployment Credentials

Deployment kimlik bilgileri kullanıcı bilgisayarlarında saklanmamalıdır.

Artifact Integrity

Test edilen paket ile production'a dağıtılan paketin aynı olduğu doğrulanmalıdır.

Production Deployment Logları

Kim, hangi sürümü, hangi ortama ve ne zaman dağıttı soruları kayıtlarla cevaplanabilmelidir.

Secrets Management

Şifrelerin Source Code İçinde Tutulmaması

Parola, token ve private key kaynak kod deposuna yazılmamalıdır.

Environment Variables'ın Sınırları

Environment variable kullanmak tek başına güvenli secret yönetimi anlamına gelmez.

Secret Vault

Merkezi secret yönetimi erişim, rotation ve audit kontrollerini kolaylaştırır.

Credential Rotation

Kimlik bilgilerinin yenilenmesi otomatik veya operasyonel süreçlerle mümkün olmalıdır.

Short-Lived Credentials

Mümkün olduğunda kısa ömürlü kimlik bilgileri kalıcı secret kullanımını azaltır.

Secret Access Logs

Kritik secret erişimleri kayıt altına alınmalıdır.

Sızmış Secret'ların İptali

Sızıntı halinde ilgili kimlik bilgisinin hızlıca iptal edilmesi ve yenilenmesi gerekir.

Infrastructure as Code Denetimi

Infrastructure Değişikliklerini Versiyonlamak

Ağ, IAM ve kaynak tanımları mümkün olduğunda kod olarak yönetilmelidir.

Peer Review

Kritik altyapı değişiklikleri ikinci kişi incelemesinden geçmelidir.

Policy as Code

Güvenlik politikalarının otomatik kontrol kurallarına dönüştürülmesi hata oranını azaltabilir.

Configuration Drift

Production ortamının onaylı tanımdan sapıp sapmadığı düzenli kontrol edilmelidir.

Manual Production Değişikliklerini Tespit Etmek

Konsol üzerinden yapılan değişiklikler otomatik olarak görünür hale getirilmelidir.

Infrastructure Değişikliklerinin Audit Trail'i

Kaynak değişiklikleri kullanıcı, zaman ve değişiklik içeriğiyle birlikte kaydedilmelidir.

Değişiklik Yönetimi

Change Request

Production değişiklikleri kayıtlı bir talebe dayanmalıdır.

Risk Analizi

Değişikliğin güvenlik, iş ve operasyon riski değerlendirilmelidir.

Etki Analizi

Hangi sistem, kullanıcı ve bağımlılıkların etkileneceği belirlenmelidir.

Test Kanıtı

Dağıtımdan önce ilgili testlerin başarılı sonuçları bulunmalıdır.

Onay

Risk seviyesine uygun onay mekanizması uygulanmalıdır.

Deployment

Dağıtım kontrollü ve izlenebilir kanaldan yapılmalıdır.

Post-Deployment Verification

Dağıtım sonrası servis sağlığı ve kritik işlemler doğrulanmalıdır.

Kapanış

Değişiklik kaydı test ve doğrulama sonuçlarıyla kapatılmalıdır.

Acil Değişiklikler Nasıl Denetlenir?

Emergency Change Nedir?

Hizmet kesintisi veya kritik güvenlik problemi nedeniyle normal onay süresinin beklenemediği değişikliktir.

Ön Onayın Mümkün Olmadığı Durumlar

Ön onay mümkün değilse kimlerin hangi koşullarda karar verebileceği önceden tanımlanmalıdır.

Break-Glass Mekanizması

Geçici yüksek yetki kontrollü biçimde açılmalıdır.

Sonradan Review Zorunluluğu

Acil değişiklik normal sürece göre geriye dönük olarak incelenmeli ve kanıtlanmalıdır.

Acil Değişikliklerin Normal Süreci Bypass Etme Aracına Dönüşmesini Önlemek

Acil değişiklik oranı düzenli izlenmeli ve olağan dışı artışlar incelenmelidir.

Release ve Deployment Mimarisi

Blue-Green Deployment

İki ortam arasında trafik geçişiyle daha kontrollü release ve geri dönüş sağlanabilir.

Canary Deployment

Yeni sürüm önce sınırlı kullanıcı veya trafik üzerinde doğrulanabilir.

Rolling Deployment

Servis örnekleri kademeli güncellenerek kesinti riski azaltılabilir.

Feature Flags

Yeni özellikler kod dağıtımından bağımsız açılıp kapatılabilir ancak flag yaşam döngüsü yönetilmelidir.

Rollback

Başarısız release için uygulanabilir geri dönüş yöntemi bulunmalıdır.

Database Migration Rollback

Veritabanı değişikliklerinin geri alınabilirliği uygulama rollback planıyla birlikte test edilmelidir.

Immutable Artifact

Aynı artifact testten production'a taşınmalı, dağıtım sırasında paket içeriği değiştirilmemelidir.

Yazılım Testlerinin Denetimi

Unit Testing

Kritik iş kuralları ve kod davranışları birim testlerle doğrulanmalıdır.

Integration Testing

Servis ve veri kaynakları arasındaki etkileşimler test edilmelidir.

System Testing

Sistem bütün olarak beklenen fonksiyonları yerine getirmelidir.

Acceptance Testing

İş gereksinimlerinin karşılandığı kullanıcı veya ürün kabul süreçleriyle doğrulanmalıdır.

Regression Testing

Yeni değişikliklerin mevcut fonksiyonları bozup bozmadığı kontrol edilmelidir.

Performance Testing

Kritik yük seviyelerinde yanıt süresi ve kaynak tüketimi ölçülmelidir.

Security Testing

Uygulama ve altyapı kontrolleri güvenlik testleriyle doğrulanmalıdır.

Disaster-Recovery Testing

Kurtarma mimarisinin yalnızca dokümanda değil gerçek testte çalıştığı gösterilmelidir.

Test Ortamlarının Denetimi

Development / Test / Production Ayrımı

Ortamlar yetki ve veri açısından birbirinden ayrılmalıdır.

Production Verisinin Testte Kullanılması

Gerçek production verisi test ortamına kontrolsüz biçimde kopyalanmamalıdır.

Data Masking

Test ihtiyacı varsa hassas alanlar uygun yöntemlerle maskelenmelidir.

Test Kullanıcıları

Test hesaplarının production ortamında aktif kalması engellenmelidir.

Test Credential'ları

Test secret'ları production kimlik bilgileriyle aynı olmamalıdır.

Production'a Eşdeğer Kritik Konfigürasyonların Doğrulanması

Test ortamı production ile birebir aynı olmak zorunda değildir ancak güvenlik açısından kritik farklar bilinmelidir.

Güvenlik Testleri

SAST

Kaynak kod veya derlenmiş çıktı güvenlik zayıflıkları açısından analiz edilebilir.

DAST

Çalışan uygulama dışarıdan test edilerek güvenlik açıkları aranabilir.

SCA

Açık kaynak bağımlılıkları güvenlik ve sürüm riski açısından taranmalıdır.

Secret Scanning

Repository içinde yanlışlıkla eklenen secret'lar otomatik bulunmalıdır.

Container Scanning

Container image içindeki paket ve konfigürasyon riskleri değerlendirilmelidir.

Infrastructure Scanning

Sunucu, ağ ve cloud kaynaklarındaki zayıflıklar düzenli taranmalıdır.

Penetration Testing

Kritik sistemler gerçek saldırı senaryolarına yakın yöntemlerle test edilmelidir.

Bulguların Kapatılma Süresi

Bulgular önem seviyesine göre tanımlanmış süreler içinde giderilmeli veya risk kabul sürecine alınmalıdır.

Performans ve Kapasite Mimarisinin Denetimi

Capacity Planning

Beklenen büyüme ve işlem hacmine göre kapasite planı bulunmalıdır.

Load Testing

Normal ve yüksek kullanıcı yüklerinde sistem davranışı ölçülmelidir.

Stress Testing

Sınır kapasite aşıldığında sistemin nasıl davrandığı görülmelidir.

Scalability

Kaynak artırımı veya yatay büyüme yöntemlerinin gerçek yük altında çalıştığı doğrulanmalıdır.

Resource Limits

CPU, bellek, connection ve queue limitleri kontrolsüz kaynak tüketimini önlemelidir.

Peak Load

Ay sonu, kampanya veya yoğun işlem saatleri gibi zirve senaryoları test edilmelidir.

Kritik Sistemler İçin Kapasite Marjı

Kapasite planı yalnızca ortalama yük üzerinden yapılmamalıdır.

İş Sürekliliği Mimari Kriterleri

Business Impact Analysis

Hangi sistemin ne kadar süre kesilebileceği iş etkisi üzerinden belirlenmelidir.

Kritik Sistemlerin Belirlenmesi

Her sistem aynı kurtarma önceliğine sahip değildir.

RTO

RTO, hizmetin kabul edilebilir en uzun geri dönüş süresini belirler.

RPO

RPO, kabul edilebilir veri kaybı aralığını ifade eder.

Mimari Tasarımın RTO/RPO'yu Karşılaması

Hedef iki saatlik RTO ise dört saat süren manuel restore süreci yeterli değildir.

Dependency'lerin RTO/RPO ile Uyumlu Olması

Kritik uygulama hızlı açılsa bile bağlı kimlik veya veritabanı servisi hazır değilse iş hedefi karşılanamaz.

High Availability ve Fault Tolerance

Single Point of Failure Analizi

Tek bileşen arızasının sistemi tamamen durdurabileceği noktalar belirlenmelidir.

Redundancy

Kritik bileşenler ihtiyaç halinde yedekli tasarlanmalıdır.

Load Balancing

Trafik birden fazla sağlıklı servis örneğine dağıtılmalıdır.

Database Replication

Replikasyon gecikmesi, failover ve veri bütünlüğü birlikte değerlendirilmelidir.

Queue ve Messaging Dayanıklılığı

Mesaj kaybı, tekrar işleme ve consumer kesintisi senaryoları test edilmelidir.

Failure Domain'ler

Yedek bileşenlerin aynı fiziksel veya mantıksal arıza alanında olmaması değerlendirilmelidir.

Otomatik Failover

Failover mekanizmasının hangi koşullarda devreye girdiği ve gerçekten çalıştığı test edilmelidir.

Felaket Kurtarma Mimarisi

Primary Site

Normal operasyonun çalıştığı ana ortam tanımlanmalıdır.

Secondary Site

İkincil ortamın kapasitesi ve hazır olma seviyesi iş hedefleriyle uyumlu olmalıdır.

Backup

Yedekleme felaket kurtarmanın tek unsuru değildir ancak temel kontrolüdür.

Replication

Veri replikasyonunun gecikmesi RPO hedefiyle uyumlu olmalıdır.

Failover

İkincil ortama geçiş adımları belirlenmeli ve test edilmelidir.

Failback

Ana ortama geri dönüş süreci de planlanmalıdır.

Disaster Recovery Testi

Planlı testler gerçek sistem bağımlılıklarını ortaya çıkarır.

Gerçek Restore Testinin Önemi

Yedek dosyasının var olması, içeriğin geri yüklenebildiğini kanıtlamaz.

Backup Mimarisinin Denetimi

Backup Scope

Hangi veri, konfigürasyon ve sistemlerin yedeklendiği belirlenmelidir.

Backup Frequency

Yedek sıklığı RPO hedefiyle ilişkili olmalıdır.

Encryption

Yedeklerde bulunan hassas veriler uygun biçimde şifrelenmelidir.

Immutable Backup

Belirli yedeklerin değiştirilemez tutulması saldırı ve yanlış silme riskini azaltabilir.

Offline Backup

Risk seviyesine göre production erişim alanından ayrılmış yedekler değerlendirilebilir.

Retention

Yedek saklama süreleri iş ve mevzuat gereksinimlerine göre belirlenmelidir.

Restore Testleri

Yedekten geri dönüş belirli aralıklarla gerçekten uygulanmalıdır.

Backup Başarılı Mesajının Tek Başına Kanıt Olmaması

Job sonucu başarılı görünse bile geri yükleme doğrulanmadıysa veri kullanılabilirliği kanıtlanmış sayılmaz.

Operasyonel Dayanıklılık

Bir Bileşen Çöktüğünde Sistem Ne Yapar?

Dayanıklılık denetiminin en değerli sorularından biri budur.

Timeout

Dış servislere yapılan çağrılar sınırsız beklememelidir.

Retry

Geçici hatalar için kontrollü tekrar mekanizması kullanılabilir.

Exponential Backoff

Tekrar denemeleri artan aralıklarla yapılarak servis üzerindeki yük azaltılabilir.

Circuit Breaker

Sürekli hata veren bağımlılığa istek göndermeyi geçici olarak durdurmak zincirleme arızayı azaltabilir.

Bulkhead

Kaynak havuzlarını ayırmak bir bileşenin diğer işlevleri tüketmesini engelleyebilir.

Graceful Degradation

Kritik olmayan özellikler kapanırken ana işlevin çalışmaya devam etmesi planlanabilir.

Failure Injection ve Chaos Testing

Kontrollü hata senaryoları, mimarinin gerçek arızalara verdiği tepkiyi ölçmek için kullanılabilir.

Log ve Denetim İzi Mimarisi

Hangi İşlemler Loglanmalıdır?

Risk taşıyan ve sonradan kanıtlanması gereken işlemler öncelikli olarak loglanmalıdır.

Kullanıcı İşlemleri

Kritik kullanıcı işlemleri kimlik ve işlem bağlamıyla kaydedilmelidir.

Yönetici İşlemleri

Yönetim paneli ve ayrıcalıklı operasyonlar ayrıntılı audit kaydına sahip olmalıdır.

Yetki Değişiklikleri

Rol ekleme, çıkarma ve ayrıcalık değişiklikleri kayıt altına alınmalıdır.

Veri Değişiklikleri

Kritik kayıtlarda yapılan değişikliklerin izlenebilirliği sağlanmalıdır.

Deployment İşlemleri

Production sürüm değişiklikleri audit kaydına dahil edilmelidir.

Güvenlik Olayları

Başarısız giriş, erişim reddi ve güvenlik kontrol ihlalleri izlenmelidir.

Kritik Business Transaction'lar

Ödeme, onay veya varlık transferi gibi kritik işlemler uçtan uca takip edilebilmelidir.

Audit Log'un Taşıması Gereken Bilgiler

Kim?

İşlemi yapan kullanıcı veya servis kimliği belirlenebilmelidir.

Ne Yaptı?

Gerçekleştirilen işlem açıkça kaydedilmelidir.

Ne Zaman?

Güvenilir zaman bilgisi bulunmalıdır.

Nereden?

Gerekli durumlarda kaynak IP, cihaz veya servis bilgisi kaydedilmelidir.

Hangi Kaynağa?

Etkilenen kayıt, nesne veya sistem belirlenebilmelidir.

Sonuç Ne Oldu?

İşlemin başarılı, başarısız veya reddedilmiş olduğu görünmelidir.

Önceki ve Sonraki Değer Gerekiyor mu?

Kritik veri değişikliklerinde eski ve yeni değerin kaydı risk bazlı olarak değerlendirilebilir.

Audit Log Bütünlüğü

Logların Değiştirilememesi

Logların kaynak sistem kullanıcıları tarafından kolayca değiştirilememesi gerekir.

Silme Yetkileri

Log silme yetkileri sınırlı ve kayıtlı olmalıdır.

Merkezi Loglama

Kritik sistemlerden logların merkezi platforma aktarılması korelasyonu kolaylaştırır.

Time Synchronization

Sistem saatlerinin uyumsuz olması olay sıralamasını bozabilir.

Retention

Log saklama süreleri risk ve düzenleyici gereksinimlerle uyumlu olmalıdır.

Log Erişimlerinin Loglanması

Çok hassas audit kayıtlarını görüntüleyen kullanıcıların erişimi de izlenebilir olmalıdır.

Hassas Verinin Loglanmaması

Parola, token ve gereksiz kişisel veri log içine yazılmamalıdır.

Observability Denetimi

Metrics

Kaynak kullanımı ve servis performansı ölçülmelidir.

Logs

Teknik ve iş olaylarını açıklayacak yeterli log üretilmelidir.

Traces

Dağıtık sistemlerde tek işlemin servisler arasındaki yolculuğu izlenebilmelidir.

Health Checks

Servisin gerçekten çalışıp çalışmadığını ölçen anlamlı sağlık kontrolleri bulunmalıdır.

Business Metrics

Yalnızca CPU değil, başarısız ödeme veya işlenemeyen sipariş gibi iş metrikleri de izlenmelidir.

Alerting

Önemli sapmalar doğru ekiplere zamanında bildirilmelidir.

Kritik Servislerin Görünür Olması

Operasyon ekibi kritik sistemlerin sağlık durumunu merkezi olarak görebilmelidir.

Incident Management

Incident Detection

Olayların kullanıcı şikâyetinden önce sistem tarafından fark edilmesi hedeflenmelidir.

Severity Classification

Olaylar etki ve aciliyete göre sınıflandırılmalıdır.

Escalation

Hangi olayın hangi ekibe veya yönetime aktarılacağı belirlenmelidir.

Containment

Olayın yayılmasını durduracak teknik adımlar tanımlanmalıdır.

Recovery

Hizmetin güvenli biçimde normale dönmesi sağlanmalıdır.

Root Cause Analysis

Yalnızca belirti değil, olayın temel nedeni araştırılmalıdır.

Post-Mortem

Olaydan çıkarılan teknik ve süreç dersleri kayıt altına alınmalıdır.

Regülatör Bildirim Süreçleri

Bildirim gerektiren olayların hangi sürede ve hangi sorumlulukla raporlanacağı önceden belirlenmelidir.

Denetim Kanıtlarının Yönetimi

Screenshot Yerine Sistemsel Kanıt

Ekran görüntüsü yardımcı olabilir ancak mümkün olduğunda doğrudan sistem çıktısı tercih edilmelidir.

Log Export

İlgili zaman aralığına ait loglar bütünlük korunarak dışa aktarılabilmelidir.

Configuration Export

Denetlenen kontrolün gerçek konfigürasyonu kayıt olarak sunulabilmelidir.

Pipeline Records

Build, test, onay ve deployment kayıtları birlikte saklanmalıdır.

Version-Control History

Değişikliğin ne zaman ve kim tarafından yapıldığı repository kayıtlarından doğrulanabilmelidir.

Test Report

Test raporunda kapsam, tarih, sürüm ve sonuç bilgileri bulunmalıdır.

Access Review

Periyodik yetki incelemelerinin kim tarafından onaylandığı kanıtlanmalıdır.

Backup Restore Report

Restore testinin hangi yedekle, ne kadar sürede ve hangi sonuçla yapıldığı kayıt altına alınmalıdır.

Continuous Compliance ve Evidence as Code

Denetim Kanıtını Yılda Bir Kez Toplamamak

Kanıtlar günlük operasyonun doğal çıktısı haline geldiğinde denetim hazırlığı daha sağlıklı olur.

Configuration'ı Otomatik Kontrol Etmek

Kritik konfigürasyonların politika dışına çıkması otomatik tespit edilebilir.

Policy as Code

Kontrol kuralları kod halinde ifade edilerek sürekli doğrulanabilir.

Compliance as Code

Uyum kontrollerinin ölçülebilen kısmı deployment ve altyapı süreçlerine dahil edilebilir.

CI/CD İçinde Uyum Kontrolleri

Gerekli güvenlik ve konfigürasyon kontrolleri release öncesi otomatik çalıştırılabilir.

Denetçiye Tekrarlanabilir Kanıt Sunmak

Aynı kontrol aynı yöntemle yeniden çalıştırılabiliyorsa kanıt kalitesi güçlenir.

Yazılım Mimarisinde Kontrol Tasarımı Nasıl Değerlendirilir?

Kontrolün Riskle İlişkisi

Her kontrol açık bir riske bağlanmalıdır.

Preventive Control

Olay gerçekleşmeden önce engellemeyi amaçlar.

Detective Control

Gerçekleşen veya gerçekleşmekte olan problemi tespit etmeyi amaçlar.

Corrective Control

Tespit edilen sorunun etkisini gidermeye veya sistemi düzeltmeye yöneliktir.

Manual vs Automated Control

Otomatik kontrol daha tutarlı olabilir ancak her risk otomasyonla çözülemez.

Compensating Control

Ana kontrol uygulanamadığında benzer risk azaltımını sağlayan alternatif kontrol tanımlanabilir.

Kontrol Etkinliği Nasıl Test Edilir?

Tasarım İncelemesi

Kontrolün riski teorik olarak karşılayıp karşılamadığı incelenir.

Doküman İncelemesi

Politika, prosedür, diyagram ve teknik tasarım belgeleri değerlendirilir.

Mülakat

Kontrolü işleten ekipten gerçek süreç hakkında bilgi alınır.

Örnekleme

Belirli işlem veya değişiklik örnekleri seçilerek kontrolün çalışması test edilir.

Teknik Test

Konfigürasyon veya erişim davranışı doğrudan doğrulanabilir.

Kaynak Kod Analizi

Kontrolün uygulama seviyesinde nasıl uygulandığı kod üzerinden incelenebilir.

Log İncelemesi

Kontrolün gerçek olaylar sırasında çalıştığı loglarla doğrulanabilir.

Yeniden Gerçekleştirme

Denetçi uygun olduğunda kontrolü bağımsız olarak yeniden uygulayarak sonucu karşılaştırabilir.

Denetimde Sık Görülen Yazılım Mimarisi Bulguları

Güncel Olmayan Mimari Dokümantasyon

Production ortamını yansıtmayan diyagramlar risk analizini zorlaştırır.

Production'a Doğrudan Geliştirici Erişimi

Sürekli ve kontrolsüz erişim görevler ayrılığı açısından risk oluşturur.

Kontrolsüz Deployment

Pipeline ve onay dışında yapılan dağıtımlar izlenebilirliği azaltır.

Hard-Coded Secret

Kod içinde tutulan kimlik bilgileri sızıntı riskini artırır.

Eksik Audit Trail

Kritik işlemlerin kimin tarafından yapıldığının belirlenememesi önemli bir denetim problemidir.

Paylaşılan Yönetici Hesapları

Ortak hesaplar bireysel sorumluluğu ortadan kaldırır.

Test Edilmemiş Backup

Restore edilmeyen yedeğin güvenilirliği bilinmez.

Tek Nokta Arızaları

Kritik tekil bağımlılıklar süreklilik riskini yükseltir.

Geri Dönüş Planı Olmayan Release

Başarısız deployment durumunda servis kesintisi uzayabilir.

Desteklenmeyen Library ve Framework Kullanımı

Güvenlik güncellemesi almayan bileşenler kontrol açığı oluşturabilir.

Modern Mimari Pattern'leri Denetim Riski midir?

Microservices

Mikroservisler iyi yönetildiğinde güçlü izolasyon sağlar, kötü yönetildiğinde servis ve erişim sayısını artırır.

Serverless

Sunucu yönetimini azaltabilir ancak IAM, secret ve event güvenliği önem kazanır.

Containers

Image güvenliği, registry kontrolü ve runtime yetkileri incelenmelidir.

Kubernetes

RBAC, network policy, secret yönetimi ve cluster erişimleri denetim kapsamına alınmalıdır.

Event-Driven Architecture

Mesaj bütünlüğü, tekrar işleme ve event izlenebilirliği kontrol edilmelidir.

API-First

API güvenlik standartlarının tasarım aşamasından itibaren uygulanması gerekir.

Cloud Native

Dinamik altyapı denetimde otomatik envanter ve policy as code ihtiyacını artırabilir.

Denetimin Teknolojiyi Değil Kontrol Modelini Değerlendirmesi

Bir teknoloji moda olduğu veya eski göründüğü için bulgu yazılmaz. Risk ve kontrol sonucuna bakılır.

Yapay Zekâ İçeren Yazılım Mimarilerinin Denetimi

Model Inventory

Hangi modellerin hangi sistemlerde kullanıldığı kayıt altında olmalıdır.

Veri Kaynağı

Model girdilerinin kaynağı, yetkisi ve veri sınıfı bilinmelidir.

Model Access

Modele ve model yönetim arayüzlerine erişim rol bazlı kontrol edilmelidir.

Prompt ve Output Logging

Risk ve veri koruma gereksinimine göre giriş ve çıkış kayıtlarının kapsamı belirlenmelidir.

Hassas Veri Sızıntısı

Kişisel veya kurumsal hassas verinin dış modele kontrolsüz gönderilmesi engellenmelidir.

Human Oversight

Yüksek etkili kararların uygun durumlarda insan kontrolüne tabi olması değerlendirilmelidir.

Model Değişiklik Yönetimi

Model sürümü ve konfigürasyon değişiklikleri normal değişiklik yönetimi süreçlerine bağlanmalıdır.

Üçüncü Taraf AI Servisleri

Veri kullanımı, saklama, bölge, sözleşme ve hizmet kesintisi riskleri incelenmelidir.

Mimari Denetimde Ölçülebilir KPI ve KRI'lar

Kritik Açık Sayısı

Açık kritik güvenlik bulgularının sayısı izlenebilir.

Patch Süresi

Kritik güvenlik güncellemelerinin ortalama kapanma süresi ölçülebilir.

Change Failure Rate

Başarısız veya geri alınan değişikliklerin oranı operasyon kalitesi hakkında bilgi verir.

Unauthorized Change Sayısı

Onaysız production değişiklikleri ayrı bir risk göstergesi olarak takip edilebilir.

Restore Başarı Oranı

Yedek geri dönüş testlerinin başarı oranı ölçülebilir.

RTO/RPO Test Başarısı

Süreklilik testlerinin hedef süreleri gerçekten karşılayıp karşılamadığı izlenebilir.

Privileged Access Sayısı

Gereksiz ayrıcalıklı hesapların artışı risk göstergesi olabilir.

Audit Log Coverage

Kritik işlem türlerinin ne kadarının yeterli audit kaydı ürettiği ölçülebilir.

Unsupported Dependency Oranı

Desteklenmeyen kütüphane ve platform oranı teknik risk göstergesidir.

Denetime Hazırlık İçin Mimari Kontrol Listesi

Sektörel Bilişim Denetimlerinde Yazılım Mimarisi Kriterleri için hazırlık yaparken yalnızca doküman toplamaya değil, production ortamındaki gerçek kontrol durumuna odaklanın.

Mimari Diyagram Güncel mi?

Gerçek servisler ve entegrasyonlarla karşılaştırın.

Kritik Veri Akışları Belgeli mi?

Hassas verinin bütün işleme ve aktarım noktalarını doğrulayın.

Trust Boundary'ler Tanımlı mı?

Güven seviyesinin değiştiği noktaları görünür hale getirin.

Kritik Risklerin Mimari Kontrolleri Var mı?

Risk register ile mimari kontrol listesini eşleştirin.

Geliştirici Production Erişimleri Kontrol Altında mı?

Sürekli, geçici ve acil erişimleri ayrı ayrı inceleyin.

CI/CD İzlenebilir mi?

Commit'ten deployment'a kadar zinciri tek örnek üzerinde doğrulayın.

Audit Loglar Yeterli mi?

Kim, ne yaptı ve sonuç ne oldu sorularına cevap verebildiğinizi test edin.

Backup Restore Test Ediliyor mu?

Son gerçek restore raporunu inceleyin.

RTO/RPO Gerçek Testlerle Doğrulanıyor mu?

Hedef değerleri tatbikat sonuçlarıyla karşılaştırın.

Üçüncü Taraf Dependency'ler İzleniyor mu?

SBOM, SCA ve destek durumu kayıtlarını değerlendirin.

Denetim Kanıtları Otomatik Üretilebiliyor mu?

Tekrarlanan kontrollerde otomatik kanıt üretimi önemli verim sağlar.

Sektörel Denetim Öncesi Gap Analysis Nasıl Yapılır?

Regülasyon Envanteri

Kuruluşun tabi olduğu düzenlemeleri listeleyin.

Kontrol Envanteri

Mevcut teknik ve yönetsel kontrolleri belirleyin.

Mimari Envanter

Servis, veri, altyapı ve entegrasyonları kaydedin.

Kanıt Envanteri

Her kontrolün hangi kanıtla doğrulanabildiğini belirleyin.

Gap Sınıflandırması

Her boşluğu aynı kategoriye koymak yerine problemin türünü ayırın.

Tasarım Eksikliği

Kontrolün hiç tasarlanmamış olmasıdır.

İşletim Eksikliği

Kontrol vardır ancak düzenli çalışmıyordur.

Kanıt Eksikliği

Kontrol çalışıyor olabilir fakat doğrulanabilir kayıt bulunmuyordur.

Uyum Eksikliği

Kontrol, ilgili düzenleme veya kurum politikasındaki beklentiyi karşılamıyordur.

Remediation Plan

Boşluklar etki, risk, efor, sorumlu ekip ve hedef tarihle birlikte plana dönüştürülmelidir.

Yazılım Mimarları ile Denetçilerin Birlikte Çalışma Modeli

Denetçiyi Projenin Sonunda Dahil Etmeme

Kontrol sorunlarının production sonrasında bulunması düzeltme maliyetini yükseltebilir.

Architecture Review

Kritik projelerde mimari tasarım erken aşamada gözden geçirilmelidir.

Security Review

Kimlik, veri, secret, trust boundary ve tehdit modeli değerlendirilmelidir.

Compliance Review

Regülasyon gereksinimlerinin teknik tasarıma yansıması kontrol edilmelidir.

Pre-Production Review

Canlıya geçmeden önce kritik güvenlik, test ve operasyon kanıtları doğrulanabilir.

Sürekli Kontrol İzleme

Production sonrası konfigürasyon ve güvenlik kontrolleri de izlenmeye devam etmelidir.

Yazılım Geliştirme Ekipleri İçin Denetim Kültürü

Denetimi Bürokrasi Olarak Görmemek

Doğru tasarlanan denetim kontrolleri hataları erken bulur ve ekiplerin sorumluluklarını netleştirir.

Security by Design

Güvenlik gereksinimleri tasarım kararlarının parçası olmalıdır.

Compliance by Design

Uyum beklentileri sonradan eklenen kontrol yerine mimari gereksinim olarak ele alınmalıdır.

Evidence by Design

Sistem, kontrolün çalıştığını doğal olarak kanıtlayacak kayıtlar üretmelidir.

Developer Self-Service Kontroller

Geliştiriciler güvenli şablon ve otomatik kontrollerle doğru yapıya kolayca ulaşabilmelidir.

Platform Engineering ile Guardrail Yaklaşımı

Merkezi platformlar izin verilen güvenli yolu varsayılan hale getirebilir.

Open Source ve İşbirliğinin Denetim Kültüründeki Rolü

Açık Kaynak Güvenlik Standartlarından Yararlanmak

Açık standartlar ekiplerin ortak güvenlik dili geliştirmesine yardımcı olur.

OWASP Ekosistemi

OWASP rehberleri ve doğrulama kriterleri uygulama güvenliği kontrol setleri oluştururken yararlı referanslardır. ASVS, web uygulaması teknik güvenlik kontrollerinin doğrulanması için açık gereksinimler sunar. :contentReference[oaicite:10]{index=10}

Ortak Security Baseline

Farklı ekipler aynı minimum güvenlik kurallarını kullanmalıdır.

InnerSource

Kurum içi ortak bileşenlerde açık işbirliği modeli kalite ve yeniden kullanım sağlayabilir.

Mimari Kararların Ekipler Arasında Paylaşılması

ADR ve teknik standartların ortak erişilebilir olması aynı problemlerin tekrar çözülmesini azaltır.

Güvenli Açık Kaynak Katkı Politikaları

Çalışanların dış projelere yaptığı katkılar veri, lisans ve kaynak kod politikalarıyla uyumlu olmalıdır.

Sık Sorulan Sorular

Bilgi Sistemleri Denetiminde Yazılım Mimarisine Bakılır mı?

Evet. Özellikle erişim, veri, iş sürekliliği, entegrasyon, değişiklik ve audit trail kontrolleri mimari kararlarla doğrudan ilişkilidir.

Denetçi Kaynak Kodu İnceleyebilir mi?

Denetim kapsamı ve yetkisine bağlı olarak belirli kontrollerin uygulanışını doğrulamak amacıyla kaynak kod incelemesi yapılabilir.

Mikroservis Mimari Denetimde Avantaj Sağlar mı?

Otomatik olarak sağlamaz. İyi servis sınırları ve güçlü kimlik yönetimi avantaj sağlayabilir, fakat dağıtık sistemler ek izleme ve entegrasyon riski getirir.

Monolitik Mimari Denetim Bulgusu mudur?

Hayır. Monolitik yapı tek başına bulgu değildir. Kontrol ortamı ve risk sonuçları değerlendirilir.

Geliştiriciler Production Ortamına Erişebilir mi?

İş ihtiyacı varsa kontrollü, süreli, onaylı ve kayıtlı erişim tasarlanabilir. Sürekli ve sınırsız erişim güçlü bir kontrol modeli değildir.

Audit Log ile Normal Application Log Aynı Şey midir?

Hayır. Application log operasyonel hata ve davranış bilgisi taşırken audit log kritik işlemlerin kanıtlanmasına odaklanır.

Yazılım Mimari Diyagramı Denetimde Zorunlu mudur?

Her düzenleme aynı doküman adını istemeyebilir. Buna rağmen sistem sınırları, veri akışları ve bağımlılıkların kanıtlanması için güncel mimari dokümantasyon güçlü bir gereksinimdir.

SBOM Neden Önemlidir?

Bir güvenlik açığı duyurulduğunda hangi uygulama ve sürümlerin etkilendiğinin hızlı belirlenmesini sağlar.

Open Source Yazılımlar Denetimde Risk Oluşturur mu?

Yönetilmeyen bağımlılıklar risk oluşturur. Açık kaynak olması tek başına olumsuz kriter değildir.

Cloud Kullanmak Sektörel Denetime Engel midir?

Tek başına değildir. Veri lokasyonu, IAM, sözleşme, yedekleme, loglama ve sağlayıcı sorumlulukları uygun şekilde yönetilmelidir.

İş Sürekliliğinde RTO ve RPO Nasıl Mimariye Dönüştürülür?

RTO kurtarma süresine, RPO ise kabul edilebilir veri kaybına çevrilir. Replikasyon, yedekleme, failover ve kapasite tasarımı bu hedeflere göre kurulmalıdır.

CI/CD Pipeline Denetimde İncelenir mi?

Evet. Kaynak koddan production'a kadar değişiklik zincirinin en önemli kontrol noktalarından biridir.

Hangi Testler Denetim Kanıtı Olarak Kullanılabilir?

Fonksiyonel, güvenlik, performans, restore, failover, DR ve erişim testleri kapsam ve tarih bilgileriyle kanıt olarak kullanılabilir.

Yazılım Mimarisi İçin En İyi Programlama Dili Var mıdır?

Hayır. Denetim açısından dil seçiminden çok destek, güvenlik, ekip yetkinliği, bağımlılık yönetimi ve kontrol uygulanabilirliği önemlidir.

Yazılımcı Olmak İçin Bilişim Denetimi Bilmek Gerekir mi?

Zorunlu değildir fakat risk, erişim, loglama ve değişiklik kontrolünü anlamak daha güvenilir sistemler tasarlamayı kolaylaştırır.

Open Source ve İşbirliği Denetim Yetkinliğini Nasıl Geliştirir?

Açık standartları, güvenlik rehberlerini ve ortak geliştirme süreçlerini incelemek farklı kontrol yaklaşımlarını görmeyi sağlar. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz.

Sektörel bilişim denetimlerinde yazılım mimarisi hangi kriterlere göre değerlendirilir?

Güvenlik, veri bütünlüğü, erişim kontrolü, süreklilik, performans, ölçeklenebilirlik, değişiklik yönetimi, loglama, üçüncü taraf riskleri ve düzenleyici gereksinimlere uyum temel kriterler arasındadır.

Yazılım mimarisinin güvenlik, ölçeklenebilirlik, süreklilik ve performans gereksinimlerine uygunluğu nasıl denetlenir?

Mimari dokümanlar production konfigürasyonlarıyla karşılaştırılır, erişim ve güvenlik kontrolleri teknik olarak test edilir, yük ve failover testleri incelenir ve sonuçlar belirlenen hedeflerle karşılaştırılır.

Bilişim denetimlerinde yazılım mimarisinin ISO 27001, COBIT ve sektörel mevzuatla uyumu nasıl değerlendirilir?

Önce uygulanabilir gereksinimler belirlenir. Ardından her gereksinim risk, kontrol, teknik uygulama, kanıt ve sorumlu ekiple eşleştirilir. Böylece yalnızca politika varlığı değil, gerçek teknik uygulama ölçülür.

Kurumsal yazılım mimarisinde denetlenebilirlik, loglama, erişim kontrolü ve veri bütünlüğü nasıl sağlanmalıdır?

Merkezi kimlik yönetimi, least privilege, değiştirilemez audit kayıtları, veri doğrulama kontrolleri, görevler ayrılığı ve otomatik kanıt üretimi birlikte tasarlanmalıdır.

Yakınımda sektörel bilişim denetimi ve yazılım mimarisi danışmanlığı veren firma nasıl bulabilirim?

Aramanız yazılım mimarisi denetimi ve IT audit danışmanlığı yakınımda şeklindeyse yalnızca konuma bakmayın. Danışmanın mimari tasarım, yazılım yaşam döngüsü, güvenlik, mevzuat eşleştirmesi ve denetim kanıtı üretimi konularında birlikte çalışabilmesine dikkat edin. Kurumsal yazılım mimarisi ve bilişim denetimi danışmanlığı yaklaşımı hakkında Diyarbakır Yazılım Topluluğu'nu https://www.diyarbakiryazilim.com.tr/about adresinden tanıyabilirsiniz.

Sonuç: Denetlenebilir Yazılım Mimarisi Nasıl Tasarlanır?

Sektörel Bilişim Denetimlerinde Yazılım Mimarisi Kriterleri değerlendirildiğinde güçlü sistemlerin ortak özelliği ortaya çıkar: Risk, kontrol, teknik uygulama ve kanıt arasında kopukluk bırakmazlar.

Regülasyonu Mimari Gereksinime Dönüştürün

Mevzuat maddesini teknik ekibin uygulayabileceği ölçülebilir kontrollere çevirin.

Güvenliği Tasarım Aşamasında Kurun

Kimlik, yetki, veri ve trust boundary kararlarını geliştirme başladıktan sonra değil, mimari tasarım sırasında ele alın.

Görevler Ayrılığını Teknik Olarak Zorunlu Hale Getirin

Politikada yazmak yerine repository, pipeline, IAM ve veritabanı kontrolleriyle uygulayın.

Değişiklikleri Uçtan Uca İzlenebilir Yapın

İş talebinden commit'e, testten deployment'a kadar tek zincir oluşturun.

İş Sürekliliğini Gerçek Testlerle Kanıtlayın

RTO ve RPO hedeflerini gerçek restore, failover ve kapasite testleriyle doğrulayın.

Audit Trail'i Mimari Özellik Olarak Tasarlayın

Loglamayı sonradan eklenen operasyon özelliği olarak değil, sistemin temel gereksinimi olarak görün.

Denetim Kanıtını Otomatik Üreten Sistemler Kurun

Pipeline, IAM, loglama ve altyapı kontrollerinin denetim için tekrar üretilebilir kanıt sağlamasını hedefleyin.

Mimariyi Teknoloji Trendine Değil Risk ve Kontrol Gereksinimlerine Göre Değerlendirin

Mikroservis, monolit, cloud veya container seçiminin tek başına iyi ya da kötü olduğunu varsaymayın. Doğru soru, seçilen mimarinin kurumun risklerini kabul edilebilir seviyede yönetip yönetemediğidir.

Yazılım mimarinizi güvenlik, denetlenebilirlik, performans, süreklilik ve sürdürülebilirlik açısından değerlendirmek, teknik kontrol listenizi oluşturmak veya mevcut yapınız için gap analysis çalışması planlamak istiyorsanız Diyarbakır Yazılım Topluluğu ile iletişime geçebilirsiniz: https://www.diyarbakiryazilim.com.tr