Skip to main content

Command Palette

Search for a command to run...

Veritabanı Değişikliklerinde Görevler Ayrılığı (Separation of Duties) Neden Şart?

Published
2 min read
S

I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.

As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.

When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.

Feel free to connect or reach out at info@sqlchangeguard.com

"Aynı kişi hem değişikliği yazıyor hem onaylıyor hem de uyguluyor."

Bu cümle birçok kurumun mevcut durumunu özetliyor. Ve bu durum hem operasyonel hem de uyum açısından ciddi bir risk.


Görevler Ayrılığı Nedir?

Görevler ayrılığı (Separation of Duties - SoD), kritik işlemlerin tek bir kişi tarafından başından sonuna kadar yürütülmesini önleyen bir kontrol mekanizması.

Bankacılıkta iyi bilinen bir prensip. Bir ödemeyi başlatan kişi onu onaylayamaz. Kasayı sayan kişi kasayı teslim alan kişiyle aynı olamaz.

Veritabanı değişiklikleri için de aynı prensip geçerli.


Neden Tek Kişilik Süreç Riskli?

Hata riski artar: Değişikliği yazan kişi aynı zamanda gözden geçiren kişiyse kendi hatalarını görmesi zorlaşır. İkinci bir göz kritik.

İç tehdit riski: Aynı kişi değişikliği yazıp onaylayıp uygulayabiliyorsa, kasıtlı bir manipülasyon da aynı kolaylıkla yapılabilir.

Denetim açığı: Düzenleyici kurumlar SoD'u denetlemek istediğinde kanıt sunulamaz. "Hepini ben yapıyordum" açıklaması uyumsuzluk olarak değerlendirilir.


Veritabanı Değişikliklerinde SoD Nasıl Uygulanır?

Geliştirici: Değişikliği yazar ve sisteme yükler. Onaylama yetkisi yok.

DBA / Teknik Gözden Geçiren: Değişikliği teknik açıdan inceler. Riski değerlendirir. Onaylar ya da geri çevirir.

IT Yöneticisi / Değişiklik Yöneticisi: Yüksek riskli değişiklikler için ikinci onay seviyesi.

Deployment Yetkililisi: Onaylanan değişikliği production'a alır. Bu kişi değişikliği yazan kişi olmamalı.


Küçük Ekiplerde SoD

"Ekibimiz küçük, iki kişiyiz, nasıl görevler ayıralım?"

Bu gerçek bir kısıt ama çözümsüz değil.

İki kişilik bir ekipte bile minimum şu ayrım yapılabilir: kendi yazdığın değişikliği kendin onaylayamazsın. Diğer kişi onaylamalı. Bu bile SoD'un temel ruhunu karşılar.

Onay verecek ikinci kişi teknik uzman olmak zorunda değil. IT yöneticisi ya da ilgili birim müdürü de onay zincirinde yer alabilir.


SoD'un Sistemle Desteklenmesi

Manuel SoD politikası zayıf bir kontrol. Sistem bunu zorlamalı.

Değişiklik yönetim platformu şunu sağlamalı: değişikliği yükleyen kişi aynı değişikliği onaylayamasın. Bu kural sistemde tanımlandığında politika ihlali teknik olarak imkânsız hale gelir.


Sonuç

Görevler ayrılığı hem riski azaltır hem de denetim gereksinimlerini karşılar. Küçük ekiplerde bile minimum düzeyde uygulanabilir. Ve en önemlisi sisteme entegre edildiğinde insan iradesine değil, teknik kontrole dayanır.

Detaylı bilgi için: sqlchangeguard.com

More from this blog

S

SQL Change Guard

81 posts

Veritabanı Değişikliklerinde Görevler Ayrılığı (Separation of Duties) Neden Şart?