COBIT BAI06 ve ITIL 4: Veritabanı Katmanındaki Beş Kopma Noktası

Değişiklik yönetimi olgunluğunu ölçen iki çerçeve, kurumsal BT'de neredeyse her yerde karşımıza çıkar: COBIT 2019 ve ITIL 4. İkisi de değişiklik sürecinin nasıl işlemesi gerektiğini net biçimde tarif eder. İkisi de veritabanı katmanını ayrıca ele almaz. Bu yazı, her iki çerçevenin beklentilerini veritabanına dokunan iş üzerinden okuyor ve sürecin tam olarak nerede koptuğunu gösteriyor.

Çerçeveler Neden Veritabanını Ayrıca Yazmaz

COBIT ve ITIL teknoloji bağımsız yazılır. "Değişiklik" derken sunucu yapılandırmasını, ağ kuralını, uygulama sürümünü ve veritabanı nesnesini aynı kefeye koyar. Bu bilinçli bir tercihtir; çerçevenin ömrü teknolojinin ömründen uzun olsun diye yapılır.

Sonuç, uygulamada şu olur: kurum çerçeveyi uygular, uygular derken de aklındaki örnek uygulama sürümüdür. Süreç uygulama sürümü üzerinden tasarlanır, uygulama sürümü üzerinden test edilir ve uygulama sürümü üzerinden denetlenir. Veritabanı, sürecin kapsamındadır ama tasarımının konusu değildir. Kopma tam burada başlar.

COBIT BAI06 Ne Bekler

COBIT 2019'da BAI06, yönetilen BT değişikliklerini ele alan yönetişim hedefidir. Özü şudur: değişiklik talepleri kontrollü biçimde değerlendirilir, önceliklendirilir ve yetkilendirilir. Uygulama tarafında bu şunları içerir.

Kayıt ve sınıflandırma. Her değişiklik kaydedilir, kategorilendirilir, etkisi ve riski değerlendirilir, yetkilendirilir, planlanır ve zamanlanır. Bu adımların hepsi izlenebilir olmalıdır.

Acil değişikliklerin yönetimi. Acil değişiklikler için kontrollü bir yol tanımlanır ve bu yoldan geçen değişikliklerin uygun biçimde değerlendirildiği ve yetkilendirildiği sonradan doğrulanır. Acil olması kaydın yokluğu anlamına gelmez, kaydın sırasının değişmesi anlamına gelir.

Takip ve raporlama (BAI06.03). Değişikliklerin durumunu izleyen ve raporlayan bir sistem bulunur. Bu sistem reddedilen değişiklikleri de belgeler, onaylanan ve devam eden değişikliklerin durumunu iletir ve tamamlananları kapatır.

Buna MEA alanı eşlik eder: iç kontrol sisteminin sürekli izlenmesi ve dış düzenleyici gerekliliklere uyumun sürekli takibi beklenir. "Yılda bir kez denetim döneminde toplanan kanıt" bu beklentiyi karşılamaz; sürekli kelimesi metnin içindedir.

ITIL 4 Değişiklik Etkinleştirme Ne Bekler

ITIL 4, değişiklik yönetimi terimini değişiklik etkinleştirme olarak değiştirdi. Bu yalnızca isim değişikliği değildir; toplantı tabanlı kapı bekçiliğinden risk tabanlı değerlendirmeye geçişi ifade eder. Üç kavram belirleyicidir.

Değişiklik türleri. Standart değişiklik düşük riskli, tekrarlanan ve prosedürü önceden yetkilendirilmiş değişikliktir; her örneği için ayrıca onay aranmaz. Normal değişiklik daha seyrek, daha geniş kapsamlı veya kritik bir bileşene dokunan değişikliktir. Acil değişiklik hızla uygulanması gereken, hızlandırılmış onay yolundan geçen ve uygulama sonrası incelemesi zorunlu olan değişikliktir.

Değişiklik yetkilisi. Belirli değişiklik türlerini değerlendirip yetkilendirmekten sorumlu olan kişi, ekip veya otomatik mekanizmadır. Otomatik mekanizma ifadesi metnin içindedir: ITIL 4, yetkilendirmenin bir insan toplantısı olmasını şart koşmaz.

Yetki devri. ITIL 4, onay yetkisinin riske göre dağıtılmasını açıkça önerir ve standart ile küçük normal değişiklikleri merkezi onay kuruluna yönlendirmeyi bir hata deseni olarak niteler. Gerekçe basittir: bu, değişiklik kalitesini artırmadan darboğaz üretir.

Veritabanı Katmanındaki Beş Kopma Noktası

1. Değerlendirme yapılır ama yeniden üretilemez

Her iki çerçeve de değişikliğin etkisinin ve riskinin değerlendirilmesini bekler. Uygulamada bu, bilet formundaki bir açılır listedir ve listeyi dolduran kişi kendi tecrübesine göre seçim yapar. Aynı betiği iki farklı kıdemli veritabanı yöneticisi farklı sınıflandırır. Değerlendirme yapılmıştır ama yazılı bir gerekçesi yoktur, bu yüzden tekrar üretilemez.

Denetçi burada iki soru sorar: bu seviye neye göre belirlendi ve aynı betik yarın gelse aynı seviyeyi mi alırdı. İkisine de cevap yoksa kontrol kişiye bağımlıdır ve denetim dilinde bu bir zayıflıktır. Veritabanı tarafında bunu düzeltmenin yolu, riski betiğin kendi içeriğinden çıkaran kural tabanlı bir değerlendirmedir: hangi nesneye dokunuyor, koşulsuz güncelleme var mı, kritik nesne listesinde mi, geri alınabilir mi. Bu kurallar yazılı olduğu için karar tekrar üretilebilir olur.

2. Yetkilendirme kaydedilir ama uygulanmaz

Bilet sisteminde onay adımı vardır ve onay kaydı tutulur. Veritabanı tarafında ise betiği çalıştıran kişi, sunucuya bağlanabilen kişidir. Bilet sisteminde onay durumu ile veritabanı bağlantısı arasında teknik bir bağ yoktur. Yani onay bir kayıt üretir, bir kapı üretmez.

Aynı boşluk görevler ayrılığında da görünür. Politika onaylayan ile çalıştıranın farklı olmasını söyler; hiçbir teknik kontrol bunu zorlamıyorsa betiği yazan kişi çoğu zaman çalıştıran kişidir de. Kural belgede vardır, akışta yoktur.

3. Reddedilen talepler hiç kaydedilmez

BAI06.03 takip sisteminin reddedilen değişiklikleri de belgelemesini bekler. Veritabanı tarafında bu neredeyse hiç karşılanmaz, çünkü red genellikle bir konuşmadır. Veritabanı yöneticisi betiğe bakar, "bu böyle olmaz" der, geliştirici düzeltir ve yeni sürümü gönderir. Sistemde yalnızca kabul edilen son sürüm görünür.

Bunun denetimdeki sonucu ters yönde çalışır. Yalnızca onaylanmış taleplerin göründüğü bir kayıt, kontrolün titiz işlediğini değil, hiç eleme yapmadığını düşündürür. Reddedilen talep kaydı, kontrolün çalıştığının en güçlü kanıtıdır ve tam da o kanıt eksiktir.

4. Acil değişikliğin sonradan değerlendirmesi birikir

Her iki çerçeve de acil değişikliğin sonradan değerlendirilmesini ister: COBIT uygun biçimde değerlendirildiğinin ve yetkilendirildiğinin doğrulanmasını, ITIL uygulama sonrası incelemeyi bekler. Uygulamada acil müdahale gece yapılır, sabah durum düzelmiştir ve inceleme ertelenir. Erteleme kimseye görünmez çünkü bekleyen kayıtları sayan bir yer yoktur.

Ölçülebilir hale getirmenin yolu basittir: acil kanaldan geçen her değişikliğin, tamamlanması gereken bir sonradan değerlendirme kaydı üretmesi ve bu kaydın kapanana kadar açık listede durması. O liste uzuyorsa acil kanalı kısayola dönüşmüş demektir ve bu, panoda görülmesi gereken bir sayıdır.

5. Standart değişiklik kavramı veritabanında karşılıksızdır

ITIL standart değişikliği, prosedürü önceden yetkilendirilmiş tekrarlanan iş olarak tanımlar. Veritabanı tarafında bu tanımın karşılığı çoğu kurumda kurulmamıştır. İndeks yeniden oluşturma, istatistik güncelleme, bir arama tablosuna satır ekleme gibi işler ya her seferinde tam onay sürecinden geçer ya da hiç kayıt bırakmadan yapılır. İkisi de yanlıştır.

Doğrusu, düşük riskli ve tekrarlanan veritabanı işlerinin risk bandına göre önceden yetkilendirilmesi, ancak yine de kayıt bırakmasıdır. Böylece iş hızlanır, kayıt kaybolmaz ve onay kurulu yalnızca gerçekten değerlendirme gerektiren işleri görür. Bu, çerçeveden sapma değil, çerçevenin asıl söylediğidir.

Beklenti ile Kanıt Eşleşme Tablosu

Aşağıdaki tablo, denetim toplantısına girmeden önce doldurulmak üzere tasarlandı. Orta sütun kurumunuzda bugün ne olduğunu, sağ sütun denetçinin göstermenizi isteyeceği kanıtı içerir.

Uygulamaya Dönüştürme

Bu tablonun sağ sütunundaki kanıtların hiçbiri çerçeve okumakla üretilmez. Hepsi, veritabanına dokunan işin geçtiği ortak bir kayıttan çıkar. O kayıt üç şeyi aynı anda yaparsa altı satırın tamamı karşılanır.

Riski betikten çıkarır. Değerlendirme insan yargısı yerine yazılı kurallardan üretilir, gerekçesi kayda yazılır ve tekrar üretilebilir olur. Yeniden üretilebilirlik, kişiye bağımlılığı ortadan kaldıran tek özelliktir.

Onayı kapıya bağlar. Onay bir alan değil bir koşuldur: onay tamamlanmadan çalıştırma açılmaz, onaylayan kendi talebini çalıştıramaz ve risk bandı yükseldikçe gereken onay sayısı artar. Düşük riskli tekrarlanan işler için ise önceden yetkilendirme tanımlanır ve iş kurula hiç gitmez.

Kararı o günkü kuralla dondurur. Talep açıldığı anda yürürlükteki kural seti kayda yazılır. Kurallar sonradan değiştiğinde geçmiş karar hala kendi bağlamında okunabilir. Denetimin en zor sorusu olan "o gün hangi kural yürürlükteydi" böylece cevaplanabilir hale gelir.

SQL Change Guard bu üç davranışı veritabanına dokunan her iş için üretir ve mevcut bilet sisteminizle yan yana çalışır. Amaç çerçeveyi yeniden yorumlamak değil, çerçevenin zaten beklediği kanıtı elle toplamak zorunda kalmadan üretmektir.

Sık Sorulan Sorular

COBIT ve ITIL veritabanı değişikliğini ayrıca zorunlu kılıyor mu?

Hayır, ikisi de teknoloji bağımsız yazılmıştır ve veritabanı nesnesini diğer değişiklik nesneleriyle aynı kapsamda ele alır. Sorun buradan doğar: kapsam dahil olduğu halde süreç uygulama sürümü örneği üzerinden tasarlandığı için veritabanına özgü yollar tarif edilmemiş kalır. Denetçi çerçeveyi teknolojiye göre değil, kontrolün gerçekten işleyip işlemediğine göre okur; veritabanı da bu okumanın içindedir.

Onay kurulumuz her değişikliği görüyor. Bu daha güvenli değil mi?

ITIL 4 bunu açıkça bir hata deseni olarak niteler; gerekçesi değişiklik kalitesini artırmadan darboğaz üretmesidir. İki pratik sonucu vardır. Birincisi, kurul yüzlerce kalemi inceleyemez ve onay biçimsel bir tıklamaya dönüşür. İkincisi, bekleme süresi uzadıkça iş başka kanallara kayar. Daha güvenli olan model, yetkiyi riske göre dağıtmak ve kurulun kapasitesini gerçekten değerlendirme gerektiren işlere ayırmaktır.

Acil değişikliği önceden onaylamak mümkün değil. Çerçeve bunu nasıl bekliyor?

Çerçeve önceden onay beklemiyor; kaydın sırasının değişmesini bekliyor. Acil kanal tanımlı olur, o kanaldan geçen değişiklik kaydedilir, gerekçesi yazılır ve olaydan sonra uygun biçimde değerlendirildiği ve yetkilendirildiği doğrulanır. Kabul edilemeyen şey acele değil, aceleden sonra hiç geri dönülmemesidir. Ölçüsü de nettir: bekleyen sonradan değerlendirme sayısı sıfıra yakın kalmalıdır.

Reddedilen talepleri kaydetmek neden bu kadar önemli?

Çünkü bir kontrolün çalıştığını gösteren şey, ürettiği red kararlarıdır. Yalnız onayların göründüğü bir kayıt, kontrolün titizliğini değil yokluğunu düşündürür. COBIT'in takip ve raporlama beklentisi reddedilen değişikliklerin belgelenmesini açıkça içerir. Uygulamada bunu sağlamanın yolu, düzeltme turlarını sohbetten çıkarıp talebin kendi geçmişine yazmaktır.

Yeni bir araç almadan bu beklentileri karşılayabilir miyiz?

Bir kısmını karşılayabilirsiniz. Reddedilen talepleri kaydetmek, acil değişikliklerin bekleyen değerlendirmelerini saymak ve düşük riskli işleri standart değişiklik olarak tanımlamak süreç kararlarıdır ve bugün yapılabilir. Karşılanamayan kısım teknik olandır: çalışan metnin onaylanan metin olduğunu doğrulamak, onayı çalıştırma kapısına bağlamak ve riski betiğin içeriğinden üretmek için veritabanına dokunan işin geçtiği bir katman gerekir. Süreç kararlarıyla başlayıp teknik boşluğu ölçmek en sağlıklı sıradır.