KVKK için VMware access control kurmak, vCenter üzerinde birkaç kullanıcıya admin yetkisi vermek veya yetki listesini daraltmak değildir. Sağlam model; kişisel veri işleyen VM'lere, vCenter nesnelerine, ESXi yönetim yüzeyine, servis hesaplarına ve log kayıtlarına kimin hangi gerekçeyle eriştiğini kanıtlanabilir hale getirir. Kısa cevap şudur: KVKK uyumlu VMware access control, yetki matrisi, en az ayrıcalık, görev ayrılığı, erişim logları ve periyodik review disiplininin vSphere rol modeliyle birlikte işletilmesidir.
Bu rehber özellikle şu ekipler içindir:
- VMware vSphere, vCenter ve ESXi ortamlarını yöneten sistem ekipleri
- KVKK teknik tedbirlerinden sorumlu BT ve bilgi güvenliği ekipleri
- Active Directory grup üyeliği, servis hesabı ve ayrıcalıklı erişim yöneten operasyon ekipleri
- kişisel veri işleyen sanal makineler için denetlenebilir erişim modeli kurmak isteyen kurumlar
Hızlı Özet
- KVKK'nın veri güvenliği yaklaşımı yetki matrisi, yetki kontrolü, kullanıcı hesap yönetimi, erişim logları ve ağ güvenliği gibi teknik/idari tedbirleri birlikte ele alır.
- VMware access control, yalnız vCenter'a kimin giriş yaptığı değil; hangi nesnede, hangi rolle, hangi privilege setiyle, hangi onay ve log iziyle işlem yaptığıdır.
- Broadcom KB
316596, vCenter SSO identity source için LDAPS kullanımının kimlik doğrulama kanalını şifrelemek amacıyla kullanılabileceğini gösterir. - Broadcom KB
380445, permission propagation ve child object üzerindeki doğrudan izinlerin beklenen erişim sonucunu değiştirebileceğini açıklar. - Broadcom KB
405145, çakışan Active Directory grup üyeliklerinin effective permission davranışını etkileyebileceğini gösterir. - KVKK için güçlü kanıt seti; rol matrisi, AD grup review çıktısı, servis hesabı envanteri, erişim logları, permission değişiklik kayıtları ve periyodik erişim gözden geçirmesinden oluşur.
İçindekiler
- KVKK Açısından VMware Access Control Neyi Kapsar?
- Yetki Matrisi VMware Nesnelerine Nasıl Çevrilir?
- vCenter Rol, Permission ve Inheritance Nasıl Tasarlanmalı?
- Ayrıcalıklı Erişim ve Servis Hesapları Nasıl Yönetilmeli?
- Erişim Logları ve Denetim Kanıtı Nasıl Hazırlanmalı?
- 90 Günlük Uygulama Planı
- İlgili İçerikler
- Kontrol Listesi
- LeonX ile Sonraki Adım
- Sık Sorulan Sorular
- Kaynaklar

Görsel: Wikimedia Commons - Door Access Control, Artechvideo, CC BY-SA 4.0. WebP formatına optimize edilmiştir.
KVKK Açısından VMware Access Control Neyi Kapsar?
KVKK açısından access control, kişisel veriye erişebilen teknik katmanlarda "kim, neye, neden ve ne kadar süreyle erişiyor?" sorusunun cevaplanmasıdır. VMware ortamında bu soru yalnız guest OS veya uygulama kullanıcılarıyla sınırlı değildir. vCenter ve ESXi üzerinde yetkisi olan bir kullanıcı; VM konsoluna bağlanabilir, snapshot alabilir, disk kopyalayabilir, network değişikliği yapabilir, datastore içeriğini görebilir veya backup entegrasyonları üzerinden kişisel veri içeren kopyalara erişebilir.
Bu nedenle VMware access control şu alanları birlikte kapsamalıdır:
- vCenter ve ESXi yönetici hesapları
- Active Directory veya diğer identity source bağlantıları
- vCenter rol ve privilege setleri
- datacenter, cluster, host, datastore, network ve VM folder seviyesindeki permission atamaları
- kişisel veri işleyen VM grupları için erişim sınırları
- backup, monitoring, SIEM ve otomasyon servis hesapları
- break-glass ve geçici ayrıcalıklı erişimler
- login, logout, permission ve role değişiklik logları
Bu çerçeve, VMware KVKK Teknik Tedbirler Rehberi içindeki erişim kontrolü, loglama, şifreleme, yedekleme ve ağ izolasyonu başlıklarının erişim yönetişimi tarafını derinleştirir.
Yetki Matrisi VMware Nesnelerine Nasıl Çevrilir?
KVKK rehberlerinde yer alan yetki matrisi mantığı, VMware tarafında doğrudan vCenter envanter hiyerarşisine bağlanmalıdır. Aksi halde belge üzerinde "yetki kontrolü var" görünür; fakat vCenter içinde eski proje grupları, fazla geniş admin rolleri veya unutulmuş servis hesapları aynı riski üretmeye devam eder.
Pratik bir başlangıç matrisi şöyle kurulabilir:
| VMware erişim alanı | Kim erişmeli? | KVKK açısından risk | Kanıt |
|---|---|---|---|
| vCenter global admin | sınırlı platform ekibi, break-glass sahipleri | tüm VM ve altyapı üzerinde tam etki | onay kaydı, MFA, oturum logu |
| kişisel veri işleyen VM folder | uygulama sahibi operasyon ekibi | konsol, disk, snapshot ve power action riski | rol matrisi, review çıktısı |
| datastore | storage ve platform ekibi | VM disk kopyası ve veri sızıntısı riski | datastore permission listesi |
| network port group | network/platform ekibi | segment atlama veya yanlış erişim yolu | change kaydı, firewall review |
| backup entegrasyonu | backup servis hesabı | yedek veri erişimi ve geri yükleme riski | servis hesabı envanteri |
| monitoring/SIEM | güvenlik ve izleme ekipleri | log görünürlüğü ve olay takibi | read-only rol, log hedefi |
Bu çalışma İş ve Yönetim Hizmetleri altında yer alan Siber Güvenlik Değerlendirme Hizmeti ile uyumludur. Teknik hesap yaşam döngüsü tarafında Kullanıcı, Grup ve Yetkilendirme Yönetimi ve kimlik entegrasyonu tarafında Active Directory ve Kimlik Yönetimi Otomasyonu da tamamlayıcıdır.
vCenter Rol, Permission ve Inheritance Nasıl Tasarlanmalı?
VMware access control tasarımında ilk hata, kişilere özel roller üretmek veya herkesi hazır Administrator rolünde toplamaktır. Daha savunulabilir model, göreve göre rol kataloğu oluşturmaktır.
Örnek rol kataloğu:
KVKK-VM-Operator: belirli VM folder içinde power action ve konsol erişimiKVKK-Security-ReadOnly: güvenlik ve denetim ekipleri için izleme amaçlı okumaKVKK-Backup-Service: backup yazılımının ihtiyaç duyduğu sınırlı privilege setiKVKK-Network-Change: yalnız gerekli port group ve network değişiklikleriKVKK-BreakGlass-Admin: acil durum için süreli ve izlenen ayrıcalıklı erişim
Broadcom KB 380445, vCenter permission propagation davranışının her permission ataması için ayrı yönetildiğini ve child object üzerindeki doğrudan izinlerin parent'tan gelen izinleri etkileyebileceğini açıklar. Bu nedenle access control review yalnız rol adlarını değil, rolün nerede başladığını ve alt nesnelere nasıl yayıldığını da kontrol etmelidir.
Review sırasında şu sorular sorulmalıdır:
- permission datacenter, cluster, folder, datastore veya network seviyesinde mi verildi?
- propagation açık mı kapalı mı?
- child object üzerinde doğrudan permission var mı?
- aynı kullanıcı birden fazla AD grubu üzerinden farklı role sahip mi?
- representative test kullanıcısı beklenen işlemleri yapabiliyor veya yapamıyor mu?
ISO 27001 tarafındaki benzer kontrol dili için ISO 27001 için VMware Access Control Nasıl Yapılır? yazısı, KVKK modeline kurumsal ISMS perspektifi ekler.
Ayrıcalıklı Erişim ve Servis Hesapları Nasıl Yönetilmeli?
Ayrıcalıklı erişim KVKK açısından iki nedenle kritiktir: kişisel veriye doğrudan veya dolaylı erişim sağlayabilir ve olay gerçekleştiğinde kimin hangi işlemi yaptığı kanıtlanamazsa veri güvenliği savunması zayıflar. Bu nedenle Administrator rolü günlük iş hesabı gibi kullanılmamalıdır.
Sağlam ayrıcalıklı erişim modeli şu kuralları içermelidir:
- named account kullanılmalı, paylaşımlı admin hesabı normal operasyon için kapatılmalı
- ayrıcalıklı rol ataması talep ve onaya bağlanmalı
- geçici yetkiler süre sonunda otomatik veya manuel review ile kaldırılmalı
- break-glass hesapları düzenli test edilmeli ama her kullanım olay olarak incelenmeli
- MFA veya güçlü kimlik doğrulama zorunlu hale getirilmeli
- kritik işlem logları SIEM veya merkezi log platformuna aktarılmalı
Servis hesapları ayrı yönetilmelidir. Backup, monitoring, otomasyon, replikasyon ve SIEM entegrasyonları için kullanılan hesaplar kişisel kullanıcı gruplarına eklenmemeli; ayrı role, ayrı sahiplik kaydına ve secret rotasyon planına sahip olmalıdır.
Broadcom KB 316596, vCenter Single Sign-On identity source için LDAPS yapılandırma adımlarını açıklar. Bu kaynak, AD tabanlı erişim modelinde kimlik doğrulama kanalının güvenli kurulmasının önemini gösterir. Broadcom KB 405145 ise çakışan Active Directory grup üyeliklerinin vCenter operasyonlarında beklenmeyen permission sonuçları doğurabileceğini gösterir. Bu iki nokta birlikte, KVKK için "AD grubu verdik, iş bitti" yaklaşımının yeterli olmadığını açıkça ortaya koyar.
Erişim Logları ve Denetim Kanıtı Nasıl Hazırlanmalı?
KVKK için access control, log kanıtı olmadan eksik kalır. Yetki matrisi doğru olabilir; fakat erişim değişiklikleri, başarısız girişler, role güncellemeleri veya servis hesabı kullanımı izlenmiyorsa kontrolün işletildiği gösterilemez.
İzlenmesi gereken temel olaylar:
- vCenter login success ve login failure
- logout ve oturum kapanış kayıtları
- permission added, updated ve removed event'leri
- role added, updated ve removed event'leri
- kullanıcı veya grup üyeliği kaynaklı erişim değişiklikleri
- kritik VM power action, console, snapshot, clone ve migration işlemleri
- servis hesabı ile yapılan otomasyon ve backup işlemleri
Broadcom KB 423205, vCenter login kayıtlarının LoginSuccess, LoginFailure ve Logout olaylarıyla takip edilebildiğini gösterir. Broadcom KB 432327, permission ve role event'lerinin SIEM'e gönderilmesi gereken güvenlik/audit log kategorileri arasında olduğunu listeler. Bu nedenle SIEM ve Güvenlik Olay Yönetimi Entegrasyonu, VMware access control kanıt zincirini güçlendiren önemli bir teknik katmandır.
Denetim dosyasında şu çıktılar yer almalıdır:
- vCenter identity source ve LDAPS yapılandırma standardı
- rol kataloğu ve privilege matrisi
- kişisel veri işleyen VM grupları için erişim matrisi
- AD grup üyelik review çıktısı
- servis hesabı envanteri ve secret rotasyon kaydı
- permission inheritance test sonuçları
- erişim talebi, onay ve kaldırma kayıtları
- login ve permission event'leri için SIEM arama çıktıları
- son 90 gün veya kurum politikasına göre belirlenmiş erişim review raporu
Bu başlık KVKK için VMware Audit Log Nasıl Yönetilir? ve KVKK için VMware Loglama Nasıl Yapılır? yazılarıyla birlikte ele alındığında daha güçlü bir teknik tedbir seti oluşturur.
90 Günlük Uygulama Planı
1-30 gün: Envanter ve risk görünürlüğü
- vCenter role, permission, identity source ve AD grup bağlantıları çıkarılır.
- kişisel veri işleyen VM folder, datastore, backup ve network objeleri işaretlenir.
Administratorrolündeki kullanıcılar, gruplar ve servis hesapları listelenir.- login, permission ve role event'lerinin mevcut log görünürlüğü kontrol edilir.
31-60 gün: Rol standardı ve temizleme
- görev bazlı rol kataloğu oluşturulur.
- eski proje grupları, gereksiz admin üyelikleri ve çakışan grup üyelikleri temizlenir.
- servis hesapları kişisel kullanıcılardan ayrılır ve sahiplik bilgisi eklenir.
- kritik VM folder ve datastore permission inheritance davranışı test edilir.
61-90 gün: Kanıt ve sürekli review
- erişim talep/onay/kaldırma kayıtları standart forma bağlanır.
- SIEM üzerinde login failure, permission change ve role change aramaları hazırlanır.
- 90 günlük erişim review raporu oluşturulur.
- break-glass hesapları test edilir ve kullanım prosedürü güncellenir.
Bu plan, VMware erişim kontrolünü tek seferlik yetki temizliği olmaktan çıkarıp KVKK için sürekli işletilen bir teknik tedbire dönüştürür.
İlgili İçerikler
- VMware KVKK Teknik Tedbirler Rehberi
- KVKK için VMware Audit Log Nasıl Yönetilir?
- KVKK için VMware Loglama Nasıl Yapılır?
- KVKK için VMware Network Isolation Nasıl Yapılır?
- ISO 27001 için VMware Access Control Nasıl Yapılır?
- VMware vCenter Güvenliği ISO 27001 Uyumu Rehberi
Kontrol Listesi
- vCenter identity source ve LDAPS yapılandırması doğrulandı
- kişisel veri işleyen VM folder ve datastore objeleri işaretlendi
- rol kataloğu kullanıcı yerine görev bazlı tasarlandı
-
Administratorrolü günlük operasyon dışına alındı - AD grup üyelikleri ve çakışan roller review edildi
- permission inheritance kritik objelerde test edildi
- servis hesapları ayrı sahiplik, role ve secret rotasyon planına bağlandı
- break-glass hesapları kullanım prosedürüyle yönetiliyor
- login, permission ve role event'leri merkezi loglama kapsamına alındı
- son 90 güne ait erişim review kanıtı hazırlanıyor
LeonX ile Sonraki Adım
KVKK için VMware access control, vCenter içinde birkaç rol oluşturma işi değildir; kişisel veri işleyen altyapıda kimlik, yetki, onay, log ve review süreçlerinin birlikte işletilmesidir. LeonX, İş ve Yönetim Hizmetleri kapsamında Siber Güvenlik Değerlendirme Hizmeti ve Ağ Güvenlik Politika Yönetimi ile erişim risklerini görünür hale getirir.
Teknik uygulama tarafında Kullanıcı, Grup ve Yetkilendirme Yönetimi, Active Directory ve Kimlik Yönetimi Otomasyonu, Kurumsal Sanallaştırma Platformları Satış ve Lisanslama ve SIEM ve Güvenlik Olay Yönetimi Entegrasyonu hizmetleri denetlenebilir erişim mimarisini tamamlar. Mevcut vSphere ortamınızı KVKK teknik tedbirleri açısından değerlendirmek veya teklif almak için İletişim sayfasından ilerleyebilirsiniz.
İlgili sayfalar:
- İş ve Yönetim Hizmetleri
- Siber Güvenlik Değerlendirme Hizmeti
- Ağ Güvenlik Politika Yönetimi
- Kullanıcı, Grup ve Yetkilendirme Yönetimi
- Active Directory ve Kimlik Yönetimi Otomasyonu
- Kurumsal Sanallaştırma Platformları Satış ve Lisanslama
- SIEM ve Güvenlik Olay Yönetimi Entegrasyonu
- İletişim
Sık Sorulan Sorular
KVKK için VMware access control neden ayrı ele alınmalıdır?
Çünkü vCenter ve ESXi üzerindeki yetkiler VM konsolu, disk, snapshot, datastore, backup ve network gibi kişisel veri işleme zincirini etkileyebilen alanlara erişim sağlayabilir.
Sadece Administrator rolünü azaltmak yeterli midir?
Hayır. Administrator rolünü azaltmak önemlidir; ancak AD grup çakışmaları, servis hesapları, permission inheritance, geçici yetkiler ve erişim logları da aynı kontrol modelinde yönetilmelidir.
VMware servis hesapları neden risklidir?
Servis hesapları genellikle backup, monitoring ve otomasyon için geniş yetkilere sahip olabilir. Sahiplik, privilege seti ve secret rotasyonu belgelenmezse kişisel veri erişim riski oluşur.
KVKK denetiminde hangi VMware access control kanıtları işe yarar?
Rol matrisi, AD grup review çıktısı, permission export, servis hesabı envanteri, erişim talep/onay kayıtları, login logları, permission event'leri ve periyodik review raporu birlikte güçlü kanıt üretir.
Erişim review ne sıklıkla yapılmalıdır?
Kurum politikasına göre belirlenmelidir; pratikte kritik VMware ortamları için en az 90 günlük veya çeyreklik review modeli güçlü bir başlangıçtır.
Kaynaklar
- KVKK - Veri Güvenliğine İlişkin Yükümlülükler
- KVKK - Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler)
- Broadcom KB 316596 - Configuring a vCenter Single Sign-On Identity Source using LDAPS
- Broadcom KB 380445 - vCenter hierarchical inheritance of permissions
- Broadcom KB 405145 - Some vCenter operations not available for users in AD groups
- Broadcom KB 423205 - How to find vCenter Server login record
- Broadcom KB 432327 - Identifying audit and security logs to forward to SIEM
- Wikimedia Commons - Door Access Control



