Korelasyon Vergisi: Jira ve Veritabanı Logu Neden Yönetişim Değildir

Bir kurumda bilet sistemi vardır, dağıtım hattı vardır, veritabanı erişim izleme aracı vardır, log platformu vardır. Bunların her biri ayrı ayrı satın alınmıştır, ayrı ayrı çalışır ve ayrı ayrı doğru veriyi üretir. Buna rağmen denetçinin sorduğu tek bir soruya cevap vermek yarım gün sürer. Bu yazı, o yarım günün adını koyuyor: korelasyon vergisi.

Denetçinin Tek Sorusu

Denetim toplantılarında sorulan soru genellikle şu kadar basittir: "Salı günü 14:00'te üretimdeki müşteri tablosunda yapılan değişikliği kim istedi, kim onayladı ve çalışan metin onaylanan metin miydi?"

Soru basittir çünkü tek bir olay hakkındadır. Cevap zordur çünkü tek bir sistemde durmaz. Kurum bu soruya cevap veremediği için değil, cevabı bir araya getirmek zorunda kaldığı için zorlanır.

Dört Sistem, Dört Yarım Cevap

Cevabın parçaları dört yerde durur ve her parça diğerinin bilmediği bir şeyi bilir.

Bu tabloda eksik bir kayıt yoktur. Eksik olan bağdır. Bilet numarasını çalışan metne, çalışan metni onay kararına, onay kararını da o gün yürürlükte olan kurala bağlayan hiçbir alan yoktur.

Korelasyon Vergisi Nedir

Korelasyon vergisi, ayrı sistemlerde duran doğru kayıtları tek bir anlatıya dönüştürmek için harcanan insan emeğidir. Bu emek üç yerde ödenir.

Denetim döneminde. Denetçi örneklem seçer, her örnek için ekipten kanıt istenir, kanıt farklı sistemlerden ekran görüntüsü olarak toplanır. Kurumların çoğunda bu iş, denetim başına birkaç kişinin birkaç haftasını alır.

Olay incelemesinde. Üretimde bir şey bozulduğunda ilk soru "son 24 saatte veritabanında ne değişti" olur. Cevabı bulmak, birden fazla sistemin zaman damgalarını elle hizalamayı gerektirir. Bu sırada kesinti sürer.

Gündelik işte. "Bu değişiklik onaylandı mı" sorusunun cevabı bir mesajlaşma başlatıyorsa vergi her gün ödeniyor demektir. Bu kalem faturalandırılmaz, bu yüzden görünmez.

Neden Her Yıl Artar

Korelasyon maliyeti sistem sayısıyla doğrusal artmaz. Her yeni sistem, kurulması gereken eşleştirme sayısını artırır: üç sistem üç eşleştirme, beş sistem on eşleştirme gerektirir. Araç sayısı arttıkça kanıt üretme maliyeti hızlanarak büyür.

İkinci büyüme kaynağı zamandır. Kurallar değişir. Bugünkü onay politikası ile on sekiz ay önceki politika aynı değildir. Denetçi geçmiş bir olayı sorduğunda, o günkü kuralın ne olduğunu da göstermek gerekir. Kural setinin geçmiş hali hiçbir yerde saklanmıyorsa, geçmiş bir kararın doğru olduğunu kanıtlamak mümkün olmaz.

Vergiyi Ödememenin Yolu: Tek Kayıt

Korelasyon vergisinden kurtulmanın yolu araç sayısını azaltmak değildir. Araçlar yerinde kalabilir ve kalmalıdır. Değişmesi gereken şey, üretime giden her işin doğduğu anda tek bir kimlik alması ve o kimliğin bütün aşamaları taşımasıdır.

Tek kayıt modelinde şu alanlar aynı satırda durur:

• Talebi açan kişi, iş gerekçesi ve kurumun biçim kuralına uyan bilet numarası
• Betiğin kendisi ve hangi kuralların tetiklendiği
• Talep anında dondurulmuş kural seti ve risk değerlendirmesinin gerekçesi
• Politikanın ürettiği onay adımları, her adımı kimin ne zaman tamamladığı
• Çalıştırma anında hesaplanan betik özeti; onaylanan metinle çalışan metnin aynı olduğunun kanıtı
• Sonuç, hata varsa hata metni ve geri alma çalıştırıldıysa onun izi

Bu alanlar aynı kayıtta durduğunda denetçinin sorusu bir arama işine dönüşmez. Talep numarası verilir, kayıt açılır ve cevabın tamamı orada bulunur.

Kaydın kendisine güvenilmesi için iki şart gerekir. Birincisi, kaydın değiştirilemez olması: denetim izinin gizli bir anahtarla imzalanması ve ayrı bir veritabanında ikinci kopyasının tutulması. İkincisi, kaydı üreten sistemin kaydı silme yetkisine sahip olmaması. Bu iki şart sağlanmadan tek kayıt modeli sadece daha derli toplu bir liste olur.

Kendi Kurulumunuzu Ölçün

Korelasyon vergisini ödeyip ödemediğinizi anlamak için bütçeye bakmaya gerek yok. Şu beş soruyu ekibinize sorun ve cevabın kaç dakikada geldiğini ölçün.

1. Geçen ay üretimde çalışan değişikliklerden rastgele birini seçin. Betiğin son halini, onaylayanı ve onay gerekçesini tek ekranda gösterebiliyor musunuz?
2. Aynı değişiklik için çalışan metnin onaylanan metinle aynı olduğunu nasıl kanıtlarsınız?
3. O tarihte hangi onay politikasının yürürlükte olduğunu gösterebiliyor musunuz?
4. Üretim veritabanına değişiklik ulaştıran kaç ayrı yol var ve kaçı aynı kayda düşüyor?
5. Kaydı tutan ekip kaydı değiştirebilir mi? Değiştirilmediğini bağımsız olarak doğrulayabiliyor musunuz?

Beş sorunun üçüne dakikalar içinde cevap veremiyorsanız sorun araçlarınızda değildir. Araçlarınız kendi işlerini doğru yapıyor. Eksik olan, hepsinin üstünde duran ve kararı kanıta bağlayan katmandır.

Sık Sorulan Sorular

Bilet sistemimize alan ekleyerek bu sorunu çözemez miyiz?

Kısmen. Bilet sistemine betik alanı eklenebilir, hatta onay adımları tanımlanabilir. Çözülemeyen kısım şudur: bilet sistemi veritabanında ne çalıştığını göremez. Onaylanan metin ile çalışan metnin aynı olduğunu doğrulayabilmek için çalıştırma anında hesaplanan bir özet gerekir. Bu, bilet sisteminin görev alanı dışındadır.

SIEM zaten olayları ilişkilendiriyor. Fark ne?

SIEM olmuş olayları ilişkilendirir ve bunu iyi yapar. Ancak bir olayın izinli olup olmadığını bilmez, çünkü izin kararı SIEM'e hiç ulaşmaz. SIEM "bu sorgu çalıştı" diyebilir; "bu sorgunun çalışması için gereken onay alınmıştı" diyemez. Yönetişim katmanı bu ikinci cümleyi üretir ve SIEM'in yerine geçmez.

Bu katman süreci yavaşlatmaz mı?

Yavaşlatan şey kontrol değil, her değişikliğe aynı ağırlıkta kontrol uygulamaktır. Risk bandına göre kapı kuran bir model, sıradan değişiklikleri hızlandırırken yalnızca yüksek riskli olanları tam süreçten geçirir. Ölçülmesi gereken sayı, onay adımı sayısı değil, bir talebin açılışından çalıştırılmasına kadar geçen süredir.

Nereden başlamak gerekir?

Tek bir üretim sunucusundan. Tüm ortamı kapsayan bir program yerine, en kritik sunucuda üretime giden bütün yolları tek kayda bağlayın. Bir çeyrek sonra, o sunucu için denetçinin sorularına dakikalar içinde cevap verildiğini görürsünüz; kapsamı bu kanıtla genişletmek çok daha kolaydır.