Veri Yönetişimi (Data Governance) Nedir? Veriyi Yükten Varlığa Dönüştürmek

Çoğu kurumda veri, bilançoda görünmeyen ama her yıl büyüyen bir kalemdir. Doğru yönetildiğinde karar almayı hızlandıran, raporlamaya ve yapay zekâ projelerine temel olan bir varlıktır. Yönetilmediğinde ise disk ve yedekleme maliyeti üreten, birbiriyle çelişen raporlara yol açan ve bir KVKK denetiminde açıklanması zor sorulara dönüşen bir yüke dönüşür. İkisi arasındaki farkı belirleyen şey verinin miktarı değil, kimin sorumluluğunda olduğu, nasıl tanımlandığı ve nasıl korunduğudur. Bu çerçevenin adı veri yönetişimidir (data governance).

Bu yazıda veri yönetişimini politika belgeleri üzerinden değil, sahada en sık karşılaştığımız sorunlar ve veritabanı katmanında atılabilecek somut adımlar üzerinden ele alıyoruz.

Veri Ne Zaman Yüke Dönüşür?

Veri yönetişimi eksikliği kendini nadiren “governance sorunu” olarak gösterir. Genellikle bir raporlama krizi, uzayan bir yedekleme süresi ya da bir denetim bulgusu olarak ortaya çıkar. Bankacılık, kamu ve büyük ölçekli kurumsal yapılarda, yıllar içinde birikmiş legacy sistemleri modernize ederken karşılaştığımız tablo çoğunlukla aşağıdaki üç senaryodan birine benzer.

Aynı soruya iki farklı cevap

Bir ERP ya da veri ambarı modernizasyonunda en büyük kriz genellikle raporlama tarafında yaşanır. Finans departmanı verilerini, gece çalışan SQL Server Agent job’larıyla beslenen SSAS küplerinden alır. Satış ya da operasyon departmanı ise yıllar önce yazılmış ve doğrudan canlı veritabanını sorgulayan bir SSRS raporunu kullanmaya devam eder. İki kaynağın veri kesim zamanı farklıdır, iade ve iptallerin nasıl hesaba katıldığı farklıdır ve çoğu zaman bu farkları belgeleyen bir tanım da yoktur. Sonuçta aynı yönetim toplantısında aynı dönemin cirosu için iki farklı rakam masaya gelir ve tartışma, rakamın kendisinden önce hangi raporun doğru olduğu üzerine yapılır.

Bu durumun teknik bir arızayla ilgisi yoktur. Her iki rapor da kendi mantığı içinde doğru çalışır. Eksik olan, “ciro” kavramının kurum genelinde tek bir tanımının ve bu tanımdan sorumlu bir sahibinin olmamasıdır.

Kimsenin silmeye cesaret edemediği tablolar

Eski DBA’lerin ya da yazılımcıların _temp, _yedek_2018 ya da test_migration gibi adlarla açıp bıraktığı tablolar hemen her uzun ömürlü veritabanında bulunur. Bu tablolar yedekleme sürelerini uzatır, restore sürelerini dolayısıyla RTO’yu olumsuz etkiler ve diskte terabaytlarca yer kaplayabilir. Buna rağmen kimse “bu tabloyu silersem bir yer bozulur mu?” sorusuna güvenle cevap veremediği için bu veriler yıllarca sistemde kalır. Çoğu da üretim tablolarının bir kopyası olduğundan, içlerinde maskelenmemiş kişisel veri bulunur.

Etiketlenmemiş veri ve yapay zekâ

Bugün yönetişim eksikliğinin en pahalıya mal olduğu iki alan, yapay zekâ entegrasyonları ve KVKK denetimleridir. Hangi verinin hassas olduğu bilinmiyorsa, ne bir yapay zekâ asistanına hangi kaynakların verilebileceğine ne de bir denetçiye verinin yaşam döngüsünün nasıl yönetildiğine dair sağlıklı bir cevap verilebilir. Bu iki konuyu aşağıda ayrı başlıklar altında ele alıyoruz.

Veri Yönetişimi Nedir, Ne Değildir?

Veri yönetişimi, verinin kurum içinde kim tarafından sahiplenileceğini, nasıl tanımlanacağını, hangi kalite kurallarına uyacağını, kimlerin hangi koşullarda erişebileceğini ve ne kadar süre saklanacağını belirleyen roller, kurallar ve süreçler bütünüdür. Veri yönetimi (data management) ise bu kuralların teknik olarak uygulanmasıdır: yedekleme, entegrasyon, veri ambarı, güvenlik yapılandırması gibi. Yönetişim neyin, kim tarafından ve neden yapılacağını belirler; yönetim ise bunun nasıl yapılacağını.

Sahada en sık karşılaştığımız yanlış anlama, veri yönetişiminin bir yazılım satın alınarak ya da bir politika belgesi yayımlanarak tamamlanabileceği düşüncesidir. Bir veri kataloğu aracı ya da kapsamlı bir politika seti faydalıdır, ancak tablo sahipleri belli değilse, KPI tanımları yazılı değilse ve yetkiler gözden geçirilmiyorsa, bu araçlar yalnızca mevcut karmaşanın daha düzenli bir listesini üretir. Yönetişim bir proje değil, kalıcı bir işletim modelidir.

Veri Yönetişiminin Temel Bileşenleri

Kurumun ölçeğinden bağımsız olarak etkili bir veri yönetişimi yapısı aşağıdaki bileşenlere dayanır. Her birinin somut bir çıktısı olmalıdır; aksi hâlde yönetişim toplantılarda konuşulan ama sistemlere yansımayan bir kavram olarak kalır.

Yönetişim Veritabanında Başlar

Veri yönetişimi çoğunlukla iş birimlerinin konusu olarak görülse de, sahiplik ve sınıflandırma kararlarının uygulandığı ve doğrulanabildiği yer veritabanıdır. Aşağıdaki adımlar SQL Server üzerinden anlatılmıştır, ancak aynı yaklaşım diğer veritabanı platformlarında da geçerlidir.

1. Envanter: Hangi tablo ne kadar yer kaplıyor ve hâlâ kullanılıyor mu?

İlk adım, ad kalıbı ve kullanım bilgisine göre şüpheli tabloları listelemektir. Aşağıdaki sorgu, adında yedek, test ya da yıl ifadesi geçen tabloları boyutları ve SQL Server’ın kaydettiği son erişim zamanlarıyla birlikte getirir:

SELECT
    s.name AS sema_adi,
    t.name AS tablo_adi,
    t.create_date AS olusturulma,
    CAST(sz.toplam_sayfa * 8 / 1024.0 AS decimal(12,1)) AS boyut_mb,
    ua.son_erisim,
    (SELECT sqlserver_start_time FROM sys.dm_os_sys_info) AS istatistik_baslangici
FROM sys.tables AS t
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
CROSS APPLY (
    SELECT SUM(a.total_pages) AS toplam_sayfa
    FROM sys.partitions AS p
    JOIN sys.allocation_units AS a ON a.container_id = p.partition_id
    WHERE p.object_id = t.object_id
) AS sz
OUTER APPLY (
    SELECT MAX(v.erisim) AS son_erisim
    FROM sys.dm_db_index_usage_stats AS us
    CROSS APPLY (VALUES (us.last_user_seek), (us.last_user_scan),
                        (us.last_user_lookup), (us.last_user_update)) AS v(erisim)
    WHERE us.database_id = DB_ID() AND us.object_id = t.object_id
) AS ua
WHERE t.name LIKE '%temp%' OR t.name LIKE '%yedek%' OR t.name LIKE '%backup%'
   OR t.name LIKE '%test%' OR t.name LIKE '%old%' OR t.name LIKE '%[_]bak%'
   OR t.name LIKE '%[12][0-9][0-9][0-9]%'
ORDER BY boyut_mb DESC;

2. Bağımlılıkları doğrulamadan silmeyin

Bir tablonun kullanılmadığından emin olmak için veritabanı içindeki bağımlılıklara bakmak gerekir, ancak bu tek başına yeterli değildir. sys.dm_sql_referencing_entities yalnızca aynı veritabanındaki view, stored procedure ve fonksiyon gibi nesnelerin referanslarını gösterir; dinamik SQL’i, başka veritabanlarından gelen sorguları, uygulama kodunu, SSIS paketlerini ve SSRS raporlarını göstermez.

SELECT referencing_schema_name, referencing_entity_name
FROM sys.dm_sql_referencing_entities(N'dbo.musteri_yedek_2018', N'OBJECT');

SSRS kullanan ortamlarda, hangi raporun ne zaman ve ne sıklıkla çalıştırıldığını ReportServer veritabanından görebilirsiniz. Bu sorgu hem kullanılmayan raporları hem de birinci senaryodaki gibi canlı sistemi sorgulamaya devam eden eski raporları bulmak için iyi bir başlangıçtır. Varsayılan ayarlarda yürütme günlüğünün yalnızca son 60 günü tuttuğunu unutmayın.

USE ReportServer;
SELECT
    c.Path AS rapor,
    COUNT(e.TimeStart) AS calisma_sayisi,
    MAX(e.TimeStart) AS son_calisma
FROM dbo.Catalog AS c
LEFT JOIN dbo.ExecutionLog3 AS e ON e.ItemPath = c.Path
WHERE c.Type = 2   -- rapor
GROUP BY c.Path
ORDER BY son_calisma;

Şüpheli bir tabloyu silmeden önce en güvenilir yöntem, ona yapılan erişimleri bir iş döngüsü boyunca, yani en az bir ay sonu ve tercihen bir çeyrek sonu kapsayacak şekilde, SQL Server Audit ile kayıt altına almaktır:

USE master;
CREATE SERVER AUDIT Audit_LegacyTablolar
    TO FILE (FILEPATH = N'D:\SQLAudit\');
ALTER SERVER AUDIT Audit_LegacyTablolar WITH (STATE = ON);
GO
USE SatisDB;
CREATE DATABASE AUDIT SPECIFICATION Audit_LegacyTablolar_Spec
    FOR SERVER AUDIT Audit_LegacyTablolar
    ADD (SELECT, INSERT, UPDATE, DELETE ON OBJECT::dbo.musteri_yedek_2018 BY public)
    WITH (STATE = ON);
GO
-- Kayıtları okumak için:
SELECT event_time, server_principal_name, client_ip, application_name, statement
FROM sys.fn_get_audit_file(N'D:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT);

3. Hassas veriyi etiketleyin

Hangi kolonların kişisel ya da finansal veri içerdiğini bilmeden ne maskeleme ne de erişim politikası tasarlanabilir. SQL Server, SSMS’teki Data Discovery & Classification özelliğiyle kolon adlarına göre öneriler sunar ve kolonları etiketlemenizi sağlar. SQL Server 2019 ve sonrasında bu etiketler T-SQL ile yönetilebilir ve sys.sensitivity_classifications görünümünden sorgulanabilir:

ADD SENSITIVITY CLASSIFICATION TO dbo.Musteri.TCKimlikNo
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'National ID', RANK = CRITICAL);

SELECT
    SCHEMA_NAME(o.schema_id) AS sema_adi,
    o.name AS tablo_adi,
    c.name AS kolon_adi,
    sc.label,
    sc.information_type,
    sc.rank_desc
FROM sys.sensitivity_classifications AS sc
JOIN sys.objects AS o ON o.object_id = sc.major_id
JOIN sys.columns AS c ON c.object_id = sc.major_id AND c.column_id = sc.minor_id;

Önerilerin yalnızca kolon adlarına dayandığını göz önünde bulundurmak gerekir. aciklama ya da not gibi serbest metin alanlarında tutulan kişisel veriler bu taramada görünmez; bu alanların iş birimleriyle birlikte gözden geçirilmesi gerekir.

4. Görünürlüğü kısıtlayın

Etiketlenen veriler için ikinci adım, kimin neyi görebileceğini sınırlamaktır. Dynamic Data Masking (SQL Server 2016 ve sonrası), yetkisi olmayan kullanıcılara sorgu sonucunda veriyi maskeli gösterir. SQL Server 2022 ile UNMASK yetkisi kolon, tablo ve şema düzeyinde verilebilir hâle gelmiştir:

ALTER TABLE dbo.Musteri
    ALTER COLUMN TCKimlikNo ADD MASKED WITH (FUNCTION = 'partial(2,"*******",2)');

-- SQL Server 2022 ve sonrası: yalnızca bu kolon için maskesiz erişim
GRANT UNMASK ON dbo.Musteri(TCKimlikNo) TO RiskAnalizRolu;

Satır bazında kısıtlama gerektiğinde, örneğin bir bölge müdürünün yalnızca kendi bölgesinin müşterilerini görmesi gerektiğinde, Row-Level Security kullanılabilir. Kimlerin hangi role sahip olduğunu düzenli olarak gözden geçirmek ise bu yapıların etkili kalmasının ön koşuludur; bu konuyu SQL Server güvenlik sıkılaştırma rehberimizde ayrıntılı olarak ele aldık.

Tek Bir Doğru: KPI Tanımlarını Sahiplendirmek

Birinci senaryodaki SSAS ve SSRS çelişkisinin çözümü yeni bir rapor yazmak değildir. Önce “ciro” gibi kritik kavramların hesaplama kuralı, veri kesim zamanı ve hangi işlemlerin dahil edildiği yazılı olarak tanımlanır ve bu tanımın bir iş sahibi belirlenir. Ardından bu tanıma uygun tek bir onaylı veri kaynağı, genellikle veri ambarı ya da semantik model, tüm departmanların ortak kaynağı hâline getirilir. Canlı veritabanını doğrudan sorgulayan eski raporlar ise ReportServer kullanım verisine göre ya emekliye ayrılır ya da onaylı kaynağa taşınır.

Bu yaklaşımın bir yan etkisi de performanstır. Operasyonel veritabanını gün içinde ağır sorgularla yükleyen raporlar ortadan kalktığında, canlı sistemdeki bloklanma ve kaynak tüketimi de belirgin şekilde azalır. Raporlama mimarisinin bu şekilde kurgulanmasında iş zekâsı hizmetlerimiz kapsamında destek veriyoruz.

Yapay Zekâ Projelerinde Yönetişim Eksikliği

Şirket içi belgeleri ve veritabanını sorgulayabilen bir RAG (Retrieval-Augmented Generation) asistanı geliştirdiğinizi varsayalım. Arka planda PostgreSQL, pgvector ve Azure OpenAI embedding modelleri kullanılıyor olsun. Teknik açıdan sistem sorunsuz çalışabilir; ancak verileriniz etiketlenmemişse ve erişim politikalarınız sıkılaştırılmamışsa, model bir sorunun cevabını ararken eski bir ERP servisinin bıraktığı log tablolarından ya da güvenlik sıkılaştırması yapılmamış bir rapor klasöründen maskelenmemiş T.C. kimlik numaralarını veya finansal risk raporlarını okuyup, bu bilgilere erişim yetkisi olmayan bir çalışana özetleyebilir.

Bu riskin kaynağı modelin kendisi değil, modele verilen veridir. Bu nedenle RAG projelerinde iki kural kritik önemdedir. Birincisi, yalnızca sınıflandırılmış ve sahibi tarafından onaylanmış kaynaklar indekslenmelidir. İkincisi, erişim kontrolü sorgu anında, veri katmanında uygulanmalıdır. PostgreSQL’de bu, embedding tablosuna Row-Level Security politikası tanımlanarak yapılabilir; böylece vektör benzerlik araması yalnızca kullanıcının görmeye yetkili olduğu satırlar üzerinde çalışır:

ALTER TABLE belge_parca ENABLE ROW LEVEL SECURITY;

CREATE POLICY belge_erisim ON belge_parca
    FOR SELECT
    USING (erisim_grubu = ANY (string_to_array(current_setting('app.kullanici_gruplari', true), ',')));

-- Uygulama, kimliği doğrulanan kullanıcının gruplarını her işlemde oturuma aktarır
BEGIN;
SET LOCAL app.kullanici_gruplari = 'satis,operasyon';
SELECT id, icerik
FROM belge_parca
ORDER BY embedding <=> $1
LIMIT 5;
COMMIT;

Burada dikkat edilmesi gereken nokta, uygulamanın veritabanına tablonun sahibi olan bir rolle bağlanmamasıdır. PostgreSQL’de tablo sahibi ve superuser rolleri, FORCE ROW LEVEL SECURITY tanımlanmadıkça bu politikalara takılmaz. Prisma gibi bir ORM ile tek bir veritabanı kullanıcısı üzerinden çalışan uygulamalarda, kullanıcı bağlamının her işlemde oturuma doğru şekilde taşındığı ayrıca test edilmelidir. Yapay zekâ projelerinin veri hazırlığı tarafını veri analitiği ve yapay zekâ hizmetlerimiz kapsamında ele alıyoruz.

KVKK ve Denetimler: Veri Yaşam Döngüsünü Kanıtlayabilmek

KVKK kapsamında veri sorumlusunun yalnızca veriyi koruması değil, verinin hangi amaçla işlendiğini, ne kadar süre saklandığını ve süresi dolduğunda nasıl imha edildiğini de gösterebilmesi beklenir. VERBİS’e kayıt yükümlülüğü bulunan veri sorumluları kişisel veri envanterine uygun bir saklama ve imha politikası hazırlamak zorundadır. İlgili yönetmeliğe göre periyodik imha aralığı en fazla altı ay olabilir ve silme, yok etme ya da anonimleştirme işlemlerine ait kayıtların en az üç yıl saklanması gerekir.

Kâğıt üzerinde bu politika çoğu kurumda mevcuttur. Sorun, politikanın veritabanındaki gerçeklikle örtüşmemesidir. Bir veritabanı sağlık kontrolünde ya da sızma testinde, kişisel veri içeren ve kimsenin sahiplenmediği _yedek tabloları veya diskte unutulmuş sahipsiz veritabanı dosyaları bulunduğunda, bu verilerin envanterde yer almadığı ve imha sürecine hiç girmediği ortaya çıkar. Verinin yaşam döngüsü kanıtlanamadığında konu teknik bir bulgu olmaktan çıkar; ciddi uyarılar ve idari para cezası riski doğuran bir uyum sorununa dönüşür.

Bu nedenle KVKK envanteri ile veritabanı envanteri birbirine bağlanmalıdır. Sınıflandırılmış kolon listesi, envanterdeki veri kategorileriyle eşleştirilmeli; legacy tablo temizliği de imha sürecinin bir parçası olarak kayıt altına alınmalıdır. Kişisel veri içeren tablolara kimlerin eriştiğini SQL Server Audit ile kayıt altına almak, denetimlerde sorulan “bu veriye kim erişti?” sorusunun da cevabını verir.

90 Günde Gerçekçi Bir Başlangıç

Veri yönetişimi çalışmalarının en sık başarısız olma nedeni, kurumun tüm verisini aynı anda kapsamaya çalışmasıdır. Daha gerçekçi bir yaklaşım, iş açısından en kritik 10 ila 20 veri öğesiyle başlamak ve bunlar üzerinde sonuç aldıktan sonra kapsamı genişletmektir.

• İlk 30 gün: Görünürlük. Kritik veritabanlarının envanterini çıkarın, şüpheli legacy tabloları ve kullanılmayan raporları listeleyin, hassas veri içeren kolonları etiketleyin. Yönetimin en çok tartıştığı 10 ila 20 KPI’ı belirleyin.
• 31–60. günler: Sahiplik ve tanım. Her kritik veri öğesi ve KPI için bir iş sahibi atayın, tanımları yazılı hâle getirin ve onaylatın. Yetki matrisini çıkarıp gereğinden fazla yetkiyi kaldırın, şüpheli tablolar için audit başlatın.
• 61–90. günler: Kontrol ve süreklilik. Onaylı tanımları tek bir raporlama kaynağına taşıyın, maskeleme ve erişim kurallarını uygulayın, audit sonuçlarına göre legacy temizliğini kayıtlı şekilde yapın. Veri kalitesi kurallarını ve aylık gözden geçirme toplantısını rutin hâline getirin.