Veritabanında Görevler Ayrılığı: Politikadan Davranışa

Görevler ayrılığı, bir işlemin baştan sona tek kişinin kontrolünde tamamlanamamasıdır. Kulağa bürokratik gelir ve çoğu zaman bir politika belgesinde kalır. Oysa amacı bürokrasi değil, tek noktadan gelebilecek hatanın ve kötüye kullanımın önünü kesmektir. Bu yazı kuralı belgeden çıkarıp sistemin davranışına dönüştürmeyi anlatır.

Görevler Ayrılığı Gerçekte Neyi Engeller?

İki farklı riski engeller ve ikisi eşit önemdedir. Birincisi kötüye kullanımdır: bir kişi kendi işlemini onaylayabiliyorsa kontrol yok demektir. İkincisi ve pratikte daha sık görüleni hatadır: ikinci bir çift göz, ilk kişinin görmediğini görür. Kurumlar genellikle birinci riski konuşur ama günlük faydanın büyük kısmı ikincisinden gelir.

Veritabanı Tarafındaki Dört Çatışma

Dördüncü satır çoğu kurumda hiç düşünülmez. Süreç kurulur, kontroller tanımlanır ve sonra aynı kişi bir ayar ekranından kontrolü kapatabilir. Talep akışında dört göz uygulayıp ayar ekranını serbest bırakmak, kapıyı kilitleyip anahtarı kapının üstünde bırakmaktır.

Kontrol Yavaşlatır mı?

Görevler ayrılığına gelen ilk itiraz teknik değil, hız üzerinedir: "her şey iki kişiye bağlanırsa iş durur." Bu itiraz haklı bir gözlemden doğar ama yanlış bir denklem kurar. Yavaşlatan şey kontrolün varlığı değil, her değişikliğe aynı ağırlıkta kontrol uygulanmasıdır. Aşağıdaki dört kural hız kaybettirmez.

Bir: kimse kendi talebini onaylamaz. Bu kural hiçbir gecikme üretmez, çünkü onaylayacak ikinci kişi zaten ekiptedir. Kuralın sistemde uygulanması, belgede yazmasından farklıdır; belge bir tarif, sistem bir kapıdır.

İki: onaylayan ile çalıştıran ayrımı bir parametre olmalıdır. Bazı kurumlarda onaylayan kişinin çalıştırması kabul edilebilir, bazılarında değildir. Kuralı sabit kodlamak yerine ayarlanabilir yapmak, kurumun kendi risk iştahına göre karar vermesini sağlar. Önemli olan ayarın kendisi değil, kimin ve nasıl değiştirebildiğidir.

Üç: atlanamaz kural listesi kısa tutulmalıdır. Belirli kurallar tetiklendiğinde hiçbir hızlandırma geçerli olmamalıdır. Ancak bu liste uzarsa acil durumda sistem tamamen tıkanır ve ekip süreci büsbütün terk eder. Kısa bir liste uygulanır, uzun bir liste delinir.

Dört: ihlal engellenmiyorsa en azından görünmelidir. Talebi açan kişinin kendi talebini çalıştırdığı durum bazı kurumlarda kabul edilir. Kabul edilmesi ile görünmemesi aynı şey değildir: kabul edilen bir istisna kayda geçer, görünmeyen bir istisna denetimde bulguya dönüşür.

Bu dört kural yerine oturduğunda ölçülmesi gereken sayı da değişir: onay adımı sayısı değil, talebin açılışından çalıştırılmasına kadar geçen süre. Onay derinliğinin risk bandına göre belirlenmesi ve onay kurulunun neden tıkandığı ayrı bir yazının konusudur: onay kurulu darboğaza dönünce.

Küçük Ekipte Nasıl Kurulur?

En sık duyulan itiraz haklıdır: "üç kişiyiz, görevleri nasıl ayıralım". Cevap tüm çatışmaları birden engellemeye çalışmamaktır. Öncelik sırası şudur:

• Kesinlikle engellenmeli: kendi talebini onaylama. Bu, üç kişilik ekipte bile uygulanabilir ve en yüksek getiriyi verir.
• Kuruma göre karar verilmeli: onaylayanın çalıştırması. Küçük ekipte serbest bırakılabilir; önemli olan bu kararın bilinçli alınması ve kayıtlı olmasıdır.
• Otomasyonla telafi edilmeli: tek gözden geçiren. İnsan sayısı azsa kural motoru ikinci göz olur.

Bir de sayısal gerçek vardır: kendi talebini onaylama yasağı, kapsamdaki her yetkide en az iki kullanıcı bulunmasını gerektirir. Bu, ekip büyüklüğünden çok yetki dağılımıyla ilgilidir. Üç kişilik bir ekipte bile iki kişi aynı ekran yetkisini taşıyabilir.

Acil Durum İstisnası

Gece 02:00'de sistem durmuşsa ve onaylayacak kimse yoksa ne olacak? Bu sorunun iki yanlış cevabı vardır. Birincisi "istisna yok" demek; bu durumda ekip süreci tamamen atlar ve kayıt hiç oluşmaz. İkincisi istisnayı sessizce serbest bırakmak; bu durumda istisna kurala dönüşür.

Doğru cevap istisnayı görünür kılmaktır: kullanıldığında ayrı bir olay olarak kaydedilir, gerekçe istenir ve sayısı raporlanır. Ayda üç kez kullanılan bir istisna, süreçte düzeltilmesi gereken bir şey olduğunu gösterir. İstisna sayısı bir kalite göstergesidir.

Denetçi Neye Bakar?

Denetçi politikayı okur ama üç şeyi sistemde arar. Birincisi kuralın gerçekten uygulanıp uygulanmadığı: bir kullanıcı kendi talebini onaylamayı denediğinde ne oluyor? İkincisi kuralın geçmişteki hali: bugün açık olan kural altı ay önce de açık mıydı? Üçüncüsü istisnaların izi: kural ne sıklıkla atlandı ve kim atladı?

İkinci madde çoğu kurumu zorlar. Bugünkü yapılandırmayı göstermek kolaydır; geçmişteki yapılandırmayı kanıtlamak, kural setinin işlem anında dondurulmasını gerektirir. Bu yapılmadığında denetçiye verilecek cevap "sanırım açıktı" olur ve bu bir kanıt değildir.

Sık Sorulan Sorular

Üç kişilik bir ekipte görevler ayrılığı kurulabilir mi?

Kurulabilir, ama tanımı değişir. Küçük ekipte hedef her rolü ayrı kişiye vermek değil, aynı işte aynı kişinin iki kritik rolü üstlenmemesidir. Bir kişi bir talepte onaylayan, başka bir talepte çalıştıran olabilir. Kritik olan, kimsenin kendi talebini kendi onaylamamasıdır.

Acil durumda görevler ayrılığı askıya alınabilir mi?

Askıya alınmamalı, kısaltılmalıdır. Acil yolda onay adımı sayısı azaltılabilir ama en az bir adımın kalması ve o adımın nöbetçi bir role bağlanması gerekir. Kuralın tamamen kapandığı bir acil yol, zamanla normal yola dönüşür.

Denetçi görevler ayrılığının çalıştığını nasıl doğrular?

İki şeye bakar. Birincisi kuralın sistemde tanımlı olması; belge yeterli değildir. İkincisi ve daha önemlisi, kuralın çalıştığının kanıtı: engellenen girişimlerin kaydı. Hiç engellenmemiş bir kural için denetçi gerçekten çalışıyor mu yoksa hiç denenmedi mi sorusunu soramaz.