Bilgi Varlığı Envanteri Nasıl Hazırlanır? Alanlar ve Sahiplik

Denetçi envanteri açar, bir satır seçer ve sorar: “Bu varlıktan hangi risk çıktı?” Muhasebenin demirbaş listesinden ya da BT’nin donanım dökümünden kopyalanmış bir envanter bu soruya cevap veremez. Oysa BGYS’de risk analizi, sınıflandırma ve erişim kararları bu listeye dayanır. Aşağıda envanterin hangi seviyede gruplanacağını, hangi alanları taşıyacağını, varlık sahibinin ne yapacağını ve listenin kaynak sistemlerle nasıl güncel tutulacağını sahada işleyen haliyle anlatıyoruz.

Bilgi varlığı ile BT varlığı arasındaki fark

ISO/IEC 27001:2022 Annex A 5.9, “bilgi ve diğer ilişkili varlıkların” envanterinin oluşturulmasını, sürdürülmesini ve varlıklara sahip atanmasını ister. Vurgu bilgidedir. Dosya sunucusu bir BT varlığıdır; üzerinde duran “müşteri teknik çizimleri” ise bilgi varlığıdır. Risk çoğunlukla bilginin gizlilik, bütünlük ve erişilebilirlik ihtiyacından doğar. Donanım bu bilgiyi taşıyan ortamdır, o kadar.

Sahada üç katmanlı düşünmek işi kolaylaştırır:

• Bilgi varlıkları: Personel özlük dosyaları, bordro verisi, müşteri sözleşmeleri, ürün tasarım verisi, finansal raporlar, kaynak kod.
• Destekleyici varlıklar: Uygulamalar (ERP, İK yazılımı, PDM), altyapı (sunucu, depolama, ağ cihazı), bulut hizmetleri, kullanıcı cihazları, basılı arşiv.
• Destekleyici unsurlar: Kritik bilgiyi bilen kişiler, tedarikçiler, fiziksel alanlar (arşiv odası, sistem odası).

Bu katmanlar ayrı listelerde durabilir; asıl iş aralarındaki bağı kurmaktır. “Bordro verisi” satırı hangi uygulamada işlendiğini, nerede barındırıldığını ve hangi tedarikçinin eriştiğini göstermelidir. Donanım listesi ayrıca tutulabilir. BGYS envanteri onun yerine geçmez, ona referans verir.

Doğru gruplama seviyesi

Sahada en sık gördüğümüz tasarım hatası yanlış ayrıntı seviyesidir. Her dizüstü bilgisayarı, her Excel dosyasını ayrı satır yapan liste birkaç ay içinde çürür; kimse güncellemez, ilk denetimde tarih sütunu ele verir. Tersi de aynı derecede işe yaramaz: “şirket verileri” diye tek satırlık bir grup, risk analizinde hiçbir ayrıma izin vermez.

Gruplama kuralı basittir: aynı sahibi, aynı sınıflandırması ve aynı koruma ihtiyacı olan varlıklar tek satırda toplanabilir. 180 standart kullanıcı dizüstü bilgisayarı “Kullanıcı dizüstü bilgisayarları (standart imaj)” olarak tek satırda yer alır; seri numaraları uç nokta yönetim aracında kalır. Tasarım ekibinin müşteri prototip verisi taşıyan iş istasyonları farklı koruma istiyorsa ayrı satır olur. Koruma farklıysa satır da farklıdır.

Seviye	Örnek	Değerlendirme
Çok kaba	“Tüm sunucular”	Risk farkı görünmez
Uygun	“ERP üretim veritabanı”	Sahip ve koruma ihtiyacı net
Uygun	“Standart kullanıcı dizüstüleri”	Ortak politika ile yönetilir
Çok ince	“Ayşe’nin 2024 bütçe dosyası”	Sürdürülemez

Envanter alanları ve örnek satırlar

Her sütun için tek soru sorun: bu alan hangi kararda kullanılacak? Hiçbir raporda, risk hesabında veya erişim kararında kullanılmayan sütun yalnızca bakım yükü üretir. Sahada 25 sütunlu envanterler görüyoruz; yarısı boş, diğer yarısı iki yıl önceki haliyle duruyor. Aşağıdaki çekirdek alanlar çoğu BGYS için yeterlidir:

Alan	Açıklama	Kullanıldığı yer
Varlık kimliği	Değişmeyen tekil kod (BV-012)	Risk ve SoA atıfları
Varlık adı ve türü	Bilgi, uygulama, altyapı, hizmet, kişi	Raporlama
Varlık sahibi	Kişi değil rol/unvan	Onay ve gözden geçirme
Sınıflandırma	Örn. Genel, Hizmete Özel, Gizli	Etiketleme ve erişim
Konum / barındırma	Yerel, bulut, tedarikçi	Tedarikçi ve yedek kapsamı
Destekleyici varlıklar	Bağlı uygulama ve altyapı kimlikleri	Bağımlılık analizi
Kişisel veri içeriyor mu?	Evet/Hayır, özel nitelikli mi	KVKK envanteri ile eşleme
Son gözden geçirme	Tarih ve gözden geçiren	Güncellik kanıtı

İki örnek satır alanların nasıl doldurulacağını gösterir. BV-012 · Bordro ve özlük verisi · Bilgi · Sahip: İK Müdürü · Gizli · Barındırma: İK yazılımı (SaaS) · Destekleyici: UY-07 İK uygulaması, TD-03 bordro hizmet sağlayıcısı · Kişisel veri: Evet, özel nitelikli veri içerir. İkinci örnek: UY-02 · ERP sistemi · Uygulama · Sahip: Finans Müdürü (iş sahibi), BT Müdürü (teknik sorumlu) · Hizmete Özel · Barındırma: yerel sanallaştırma kümesi · Destekleyici: AL-04 SQL Server kümesi, AL-01 sanallaştırma platformu.

ERP satırında iki rol var. İş sahibi bilginin kime açılacağına karar verir, teknik sorumlu sistemi işletir. Erişim onayının BT’ye değil iş birimine ait olduğunu belgelemenin en kısa yolu budur; denetimde “bu yetkiyi kim onayladı?” sorusu da buradan cevaplanır.

Varlık sahibinin sorumlulukları

ISO 27001’de “varlık sahibi” mülkiyet değil sorumluluk demektir. Sahip, varlığın yaşam döngüsü boyunca korunmasından hesap veren kişidir; bu yüzden genellikle iş biriminden seçilir. Sahipliği unvana bağlayın. Kişi adı yazılırsa her istifa ve görev değişikliğinde envanter yanlış hale gelir ve bunu kimse fark etmez.

Varlık sahibinin görev tanımına girmesi gerekenler:

• Varlığın sınıflandırmasını belirlemek ve değişiklik olduğunda güncellemek (Annex A 5.12).
• Erişim taleplerini onaylamak ve periyodik erişim gözden geçirmesini imzalamak.
• Risk analizinde varlığa ait etki değerlendirmesine katılmak ve risk sahibi olarak işleme kararlarını kabul etmek.
• Varlık kullanım dışı kaldığında güvenli imha veya iade sürecini başlatmak (Annex A 5.11, 7.14).
• Envanter satırını belirlenen periyotta gözden geçirip onaylamak.

Sahip işletme görevlerini BT’ye devredebilir. Hesap verebilirliği devredemez. Bu ayrımın matrise nasıl yazılacağı BGYS RACI matrisi rehberinde ayrıntılı anlatılıyor.

Envanteri güncel tutmak: kaynak sistemler

Elle tutulan envanter ilk denetimden sonra eskimeye başlar. Kalıcı çözüm, destekleyici varlıkları otomatik kaynaklardan beslemek ve elle bakımı yalnız bilgi varlığı satırlarıyla sınırlamaktır. Tipik kaynaklar:

• Active Directory / Entra ID: Bilgisayar ve sunucu nesneleri, servis hesapları, gruplar.
• Uç nokta yönetimi (Intune, SCCM vb.): Kullanıcı cihazları, işletim sistemi sürümleri, şifreleme durumu.
• Sanallaştırma platformu ve CMDB: Sanal makineler ve bağımlılık ilişkileri.
• Satın alma ve sözleşme kayıtları: SaaS abonelikleri ve tedarikçiler. BT’nin haberi olmadan alınan bulut hizmetlerini yakalamanın en güvenilir yolu muhasebedeki fatura listesidir.

AD’den dönemsel bir bilgisayar listesi ve uzun süredir oturum açmamış nesneler şu PowerShell komutlarıyla alınır (ActiveDirectory modülü gerekir):

Import-Module ActiveDirectory
Get-ADComputer -Filter * -Properties OperatingSystem,LastLogonDate |
  Select-Object Name,OperatingSystem,LastLogonDate |
  Export-Csv -Path .\ad-bilgisayarlar.csv -NoTypeInformation -Encoding UTF8

# 90 gündür oturum açmamış bilgisayar hesapları
Search-ADAccount -AccountInactive -ComputersOnly -TimeSpan 90.00:00:00 |
  Select-Object Name,LastLogonDate

Bu çıktı envanteri doldurmak için değil, mutabakat için alınır. AD’de olup envanterde olmayan sunucu “kayıt dışı sistem” sorusu doğurur; envanterde olup AD’de bulunmayan sunucu ise “imha kaydı eksik varlık” sorusu. Mutabakat sonucunu tarihli bir kayıt olarak saklayın; denetimde envanterin canlı tutulduğunun kanıtı budur. Bir uyarı: LastLogonDate değeri etki alanı denetleyicileri arasında gecikmeli çoğaltılan bir öznitelikten türetilir. Kesin tarih değildir. Yaklaşık gösterge olarak okuyun ve 90 günlük eşiği buna göre yorumlayın.

Envanterin risk analizine bağlanması

Envanter, risk analizinin girdisi olduğu gün işe yarar. Varlık bazlı yöntemde her önemli bilgi varlığı için tehdit ve zafiyet eşleşmeleri değerlendirilir; senaryo bazlı yöntemde senaryolar etkilenen varlıklara atıf yapar. Yöntem seçimi varlık bazlı ve senaryo bazlı risk değerlendirmesi karşılaştırmasında tartışılıyor. Hangisini seçerseniz seçin, envanter kimlikleri risk kaydında referans olarak geçmelidir.

Bağı kurmanın somut adımları:

1. Risk kaydına “etkilenen varlık kimlikleri” sütunu ekleyin.
2. Envanterde “Gizli” sınıfındaki her bilgi varlığının en az bir risk kaydında geçtiğini kontrol edin; geçmeyen varlık, analizin eksik kaldığını gösterir.
3. Varlığın etki değerini (gizlilik, bütünlük, erişilebilirlik) envanterde tutup risk hesabında aynı değeri kullanın; iki yerde farklı etki puanı olmamalıdır.
4. Yeni varlık eklendiğinde veya sınıflandırması yükseldiğinde risk gözden geçirmesini tetikleyen bir kural tanımlayın.

İkinci adım basit bir filtreyle yapılır ve sahada neredeyse her seferinde boşluk çıkarır. Risk puanlamasının ve kayıtlarının nasıl yapılandırılacağı BGYS risk analizi rehberinin konusu. Envanter, risk analizi ve uygulanabilirlik bildirgesini tek bir izlenebilir zincir olarak kurmak için ISO 27001 risk analizi ve SoA çalışmasıyla birlikte ele alınabilir.

Sık yapılan hatalar ve kontrol listesi

Envanterle ilgili denetim bulgularının çoğu aynı birkaç hatadan çıkar:

• Sahip olarak “BT” yazılması: İş bilgisinin sahibi iş birimidir; BT çoğu zaman yalnızca teknik sorumludur.
• Bulut hizmetlerinin unutulması: SaaS uygulamaları, paylaşılan bulut depolama alanları ve tedarikçi portalları listede yer almaz.
• Basılı bilginin atlanması: Arşivdeki sözleşmeler ve personel dosyaları da bilgi varlığıdır.
• Tarihsiz liste: Son gözden geçirme tarihi ve onaylayan olmayan envanter, güncel olduğunu kanıtlayamaz.
• Sınıflandırma ile erişimin çelişmesi: “Gizli” işaretli bir klasöre “Domain Users” grubunun erişmesi, envanterin uygulamaya yansımadığını gösterir. Dosya sunucusunda NTFS izinlerine bakmak bunu beş dakikada ortaya koyar.

Yayına almadan önce kontrol edin:

• Her satırda unvan bazlı sahip ve sınıflandırma dolu mu?
• Kritik bilgi varlıklarının destekleyici varlıkları ve tedarikçileri bağlanmış mı?
• Kaynak sistemlerle son mutabakat tarihi ve sonucu kayıtlı mı?
• Envanter, doküman kontrolü kapsamında sürümlü ve erişimi kısıtlı mı?
• Kişisel veri içeren satırlar KVKK envanteri ile eşleştirilmiş mi?

Envanterin kurulması ve veri sınıflandırma şemasıyla birlikte işletilmesi için BT varlık envanteri ve veri sınıflandırması hizmet sayfasına bakabilirsiniz. Kontrolün resmi metni için ISO/IEC 27001 sayfası başlangıç noktasıdır.

Sık sorulan sorular

Bilgi varlığı envanteri ile demirbaş listesi aynı belge olabilir mi?

Olmamalı. Demirbaş listesi mali değeri ve fiziksel varlığı izler; bilgi varlığı envanteri ise bilginin sahibini, sınıflandırmasını ve koruma ihtiyacını gösterir. Envanter demirbaş listesine veya CMDB’ye atıf yapabilir, onun yerine geçmez.

Envanterde her kullanıcı bilgisayarını ayrı satır olarak yazmak gerekir mi?

Gerekmez. Aynı sahibi, sınıflandırması ve koruma ihtiyacı olan cihazlar tek satırda gruplanır. Cihaz bazlı ayrıntı uç nokta yönetim aracında tutulur ve envanterle periyodik olarak karşılaştırılır.

Varlık sahibi kim olmalıdır?

Bilginin iş açısından değerini ve kimin erişmesi gerektiğini bilen iş birimi yöneticisi. BT genellikle teknik sorumludur. Sahipliği kişi adına değil unvana bağlayın; personel değiştiğinde envanter bozulmasın.

Envanter ne sıklıkla gözden geçirilmelidir?

Standart bir sıklık vermez; kuruluş kendisi belirler. Yaygın uygulama yılda en az bir tam gözden geçirme, ayrıca yeni sistem devreye alma, tedarikçi değişikliği veya organizasyon değişikliği gibi olaylarda ara güncellemedir.