DIABOLIKSS
RehberlerHPE Morpheus RBAC ve Tenant İzolasyonu: Çok Kiracılı Güvenli Mimari Tasarımı
How-To Guide · HPE Morpheus · RBAC · Multi-Tenant · Güvenlik

HPE Morpheus RBAC ve Tenant İzolasyonu:Çok Kiracılı Güvenli Mimari Tasarımı

HPE Morpheus 8.xRBAC · Multi-Tenant · Politika YönetimiHaziran 2026

Morpheus'u birden fazla departman, iş birimi veya müşteri için ortak bir platform olarak kullanmak istediğinizde en kritik mimari karar, izolasyon sınırlarını doğru çizmektir. Yanlış yapılandırılmış bir tenant, başka bir birimin kaynaklarını görebilir; yetersiz RBAC, yetkisiz provisioning kapısı açar. Bu rehber; Master Tenant ile alt kiracı arasındaki görünürlük duvarından özel rollerin tasarımına, kaynak kotalarından denetim günlüklerine kadar Morpheus'un çok kiracılı güvenlik modelini katman katman ele alır. KDK uyumlu ve kamu altyapısı senaryoları dahil.

01

Morpheus Tenant Modeli

Morpheus'ta her şey bir Tenant (kiracı) bağlamında çalışır. İki düzey vardır: Master Tenant (sistem genelini yönetir) ve Sub-Tenant (izole kaynak ve kullanıcı alanı). Bu hiyerarşi, servis sağlayıcı modeli veya büyük kurumların bölüm bazlı izolasyon ihtiyacı için tasarlanmıştır.

🏛️
Master Tenant
Tüm sistemi görür
Altyapı, bulut, tüm tenant'lar
🏢
Sub-Tenant
Yalnızca kendisini görür
Kendi kaynak ve kullanıcıları
👥
Grup (Group)
Tenant içi mantıksal bölüm
Proje veya lokasyon bazlı
🔑
Rol (Role)
Yetki kümesi
Sistem veya tenant düzeyi
🚨
Temel izolasyon kuralı: Sub-Tenant kullanıcıları, başka bir Sub-Tenant'ın kaynaklarını (VM, imaj, ağ) hiçbir koşulda göremez. Master Tenant yöneticileri tüm Sub-Tenant'ları görebilir. Bu sınır Morpheus veri modelinde yerleşiktir ve arayüz üzerinden bypass edilemez. Yanlış yapılandırılmış grup veya rol paylaşımları bu sınırı dolaylı olarak delebilir — bu rehber bu riskleri ele alır.
NesneMaster Tenant Görür mü?Sub-Tenant A Görür mü?Sub-Tenant B Görür mü?
Sub-Tenant A VM'leri✓ Evet✓ Evet (kendi)✗ Hayır
Sub-Tenant B VM'leri✓ Evet✗ Hayır✓ Evet (kendi)
Paylaşılan Image'lar✓ Evet✓ Evet (paylaşıldıysa)✓ Evet (paylaşıldıysa)
Master Tenant VM'leri✓ Evet✗ Hayır✗ Hayır
02

Tenant Oluşturma ve Yapılandırma

1
Administration → Tenants → Add Tenant
# Tenant temel yapılandırması Tenant Adı : IT-Altyapı-Departmanı Kısa Ad (Code) : it-altyapi (URL alt alanı için kullanılır) Açıklama : BT Altyapı ve Operasyon ekibinin izole çalışma alanı Alt Alan Adı : it.morpheus.sirket.com (opsiyonel — tenant'a özel URL) # Kısıtlamalar Maks. Storage : 10 TB Maks. RAM : 2048 GB Maks. CPU : 500 vCPU # Varsayılan Rol Kullanıcı Rolü : IT-Standart-Kullanici (tenant'a yeni katılan kullanıcıların rolü)
2
Tenant Yöneticisi Oluşturun

Tenant oluşturulduğunda otomatik bir yönetici hesabı oluşturulur veya siz belirleyebilirsiniz. Tenant yöneticisi, kendi tenant'ı içinde tam yetkiliye sahiptir; ancak başka tenant'ları veya Master Tenant'ı göremez.

# Tenant yönetici hesabı Kullanıcı Adı : it.admin@sirket.com Rol : Tenant Admin (otomatik atanır) Kimlik Kyn. : Active Directory SSO (önceki rehberde yapılandırılan) # Tenant Admin'in yapabilecekleri: # - Tenant içinde kullanıcı oluşturma ve yönetme # - Tenant'a atanmış bulutlarda provisioning # - Tenant'a ait Instance, Image ve Ağları yönetme # - Katalog öğelerini kullanma # Yapamayacakları: # - Başka tenant'ları görmek # - Yeni bulut eklemek # - Global politikaları değiştirmek
3
Tenant'a Kimlik Kaynağı (Identity Source) Ekleyin

Her tenant için ayrı AD OU veya grup filtresi tanımlayabilirsiniz. Böylece IT-Altyapı tenant'ına yalnızca CN=IT-Altyapi-Users AD grubu üyeleri giriş yapabilir.

# Tenant → Identity Sources → Add → Active Directory AD URL : ldaps://dc01.sirket.com:636 Domain : sirket.com Servis Hes. : morpheus-svc@sirket.com Kullanıcı OU : OU=IT-Altyapi,OU=Departments,DC=sirket,DC=com # Rol eşlemesi CN=IT-Altyapi-Admins → Tenant Admin CN=IT-Altyapi-Users → IT-Standart-Kullanici CN=IT-Altyapi-Readonly → Sadece Goruntule (Read-Only)
03

Rol Hiyerarşisi ve RBAC Tasarımı

Morpheus rol sistemi iki katmanlıdır: Sistem Rolleri (Master Tenant düzeyi) ve Tenant Rolleri (Sub-Tenant düzeyi). Her rol, onlarca izin boyutundan oluşur.

RolKapsamVarsayılan YetkilerKullanım
System AdminMaster TenantHer şey — kısıtsızPlatform yöneticisi
Infrastructure AdminMaster TenantAltyapı + bulut yönetimi, kullanıcı yönetimi yokKıdemli altyapı mühendisi
Tenant AdminSub-TenantTenant içinde tam yetkiDepartman BT yöneticisi
User (Standard)Sub-TenantProvisioning + kendi Instance'larını yönetmeGenel kullanıcı
Read OnlyHer ikisiYalnızca görüntülemeDenetçi, raporlama
ℹ️
Temel rol yerine özel rol: Üretim ortamında hazır rolleri doğrudan kullanmak yerine bunları temel alarak özel roller oluşturun. Özellikle "User (Standard)" rolü bazı kurumlarda fazla geniş yetki içerir. Bir sonraki bölüm özel rol tasarımını ayrıntılı ele almaktadır.
04

Özel Rol Oluşturma

Morpheus rol izinleri yaklaşık 50 boyut içerir. Aşağıdaki tablo en önemli boyutları ve önerilen kısıtlama stratejisini sunar.

1
Administration → Roles → Add Role
# Örnek: Uygulama Geliştirici Rolü Rol Adı : App-Developer Rol Türü : User (Tenant düzeyi) Temel Rol : User (Standard) (başlangıç noktası) # İzin özelleştirmeleri (kısıtlamalar) --------------------------------------------------- Özellik : Tanımlı Değer --------------------------------------------------- Provisioning : Katalog Üzerinden (doğrudan hayır) Infrastructure : Yok (altyapı menüsünü görmez) Monitoring : Görüntüle (okuyabilir, değiştiremez) Logs : Görüntüle Operations : Yok Administration : Yok Library : Yok (Instance Type değiştiremez) Backups : Görüntüle Virtual Images : Görüntüle (imaj oluşturamaz) Network : Görüntüle Cloud : Görüntüle (bulut ekleyemez) # Özel erişimler: Katalog Öğesi : Yalnızca "Uygulama Sunucusu İste", "Test Ortamı İste"
2
Örnek Rol Matrisi — Kurumsal Senaryo
# Rol Matrisi — 5 farklı rol Rol : Uygulama Gel. | Ops Mühendisi | Güvenlik | Yönetici | Denetçi ------------------------------------------------------------------------------------- VM Oluşturma : Katalog Tam Hayır Tam Hayır VM Silme : Kendi VM Tam Hayır Tam Hayır Ağ Değiştirme : Hayır Tam Görüntüle Tam Görüntüle Kullanıcı Yönetimi : Hayır Hayır Hayır Tam Görüntüle Politika Yönetimi : Hayır Hayır Görüntüle Tam Görüntüle Maliyet Raporu : Kendi Tenant Hayır Tam Tam Denetim Günlüğü : Hayır Hayır Görüntüle Görüntüle Tam
3
Instance Silme Koruması

Kullanıcıların başkasının VM'ini yanlışlıkla silmesini önlemek için Instance Ownership politikası kullanın. Bu politikayla kullanıcılar yalnızca kendi oluşturdukları (veya sahipliği devredilen) instance'ları silebilir.

# Administration → Policies → Add Policy → Instance Ownership Kapsam : Tenant — IT-Altyapi Sahiplik Kuralı : Yalnızca oluşturan kullanıcı silebilir veya: Tenant Admin onayıyla silinebilir
05

Kaynak Paylaşımı ve İzolasyon

Morpheus'ta kaynaklar (bulutlar, imajlar, ağlar, datastore'lar) varsayılan olarak yalnızca Master Tenant'ta görünür. Sub-Tenant'larla paylaşmak için açıkça izin verilmesi gerekir.

1
Bulutu Tenant'larla Paylaşın
# Infrastructure → Clouds → [VMware Bulutu] → Edit # "Tenant Permissions" sekmesi Ortak mi? : Hayır (Public = tüm tenant'lar görür) Seçili Tenant'lar : IT-Altyapi, Yazilim-Ekibi # Bu iki tenant bu bulutu kullanabilir # Finans-Departmanı göremez # Resource Pool izolasyonu: # Her tenant farklı resource pool kullanabilir # IT-Altyapi → vmware-pool-altyapi # Yazilim-Ekibi → vmware-pool-yazilim
2
Paylaşılan Image Yönetimi
# Library → Virtual Images → [Image] → Edit Görünürlük : Public (tüm tenant'lar kullanabilir) # veya: Private (yalnızca Master Tenant) # veya: Seçili Tenant'lar # Önerilen strateji: # Onaylı temel imajlar (RHEL 9, Windows Server) → Public # Özel imajlar (uygulama şablonları) → Seçili Tenant # Güvenlik taranmış imajlar → Public (zorunlu standart) # NOT: Tenant'ların kendi imaj oluşturmasını engellemek için # "Virtual Images" iznini "None" yapın → yalnızca onaylı imajlar kullanılır
3
Ağ İzolasyonu
# Infrastructure → Networks → [Ağ] → Edit # Tenant izinleri bölümünde: VLAN100 (Üretim Ağı) → Yalnızca Ops-Mühendisi rolü erişebilir VLAN200 (Test Ağı) → IT-Altyapi tenant'ı kullanabilir VLAN300 (Yönetim Ağı) → Yalnızca Master Tenant görür # Bu yapılandırma ile kullanıcılar # provisioning sırasında yalnızca yetkili ağları görür
06

Kaynak Kotaları ve Politikalar

Morpheus politikaları (Policies), tenant veya rol düzeyinde kaynak kullanımını sınırlar. Her politika bağımsız çalışır ve birden fazla politika aynı anda uygulanabilir.

Politika TürüSınırladığı ŞeyÖrnek Değer
Max InstancesKullanıcı başına veya tenant'ta toplam VM sayısıKullanıcı başına 5 VM
Max HostsToplam fiziksel/sanal host sayısıTenant'ta max 10 host
Max MemoryToplam RAM kullanımı (GB)Tenant'ta 512 GB
Max StorageToplam disk kullanımı (GB)Tenant'ta 10 TB
Max CoresToplam vCPU sayısıTenant'ta 200 vCPU
Instance ExpirationVM'in maksimum yaşam süresiTest tenant'ında max 30 gün
Naming ConventionZorunlu isimlendirme standardı${tenant}-${type}-${sequence}
BudgetAylık harcama limiti5.000 USD/ay
Provision ApprovalHer provision için onay zorunluluğuÜretim ortamında zorunlu
1
İsimlendirme Politikası — Kaçınılmaz Standart
# Administration → Policies → Add Policy → Naming Convention Politika Adı : Kurumsal VM İsimlendirme Kapsam : Global (tüm tenant'lar) # İsimlendirme kalıbı (Morpheus değişkenleri): Sunucu Adı : ${cloud.code}-${type.code}-${sequence+3} # Örnekler: # vmw-rhel-001 (VMware üzerinde RHEL 9) # aws-win-004 (AWS üzerinde Windows) # az-rhel-012 (Azure üzerinde RHEL 9) # Kullanılabilir değişkenler: # ${cloud.code} : Bulut kısa kodu # ${type.code} : Instance Type kodu # ${tenant.name} : Tenant adı # ${user.initials} : Kullanıcı baş harfleri # ${sequence} : Otomatik sıra numarası (pad ile)
2
Test Tenant'ına Özel Kısıtlayıcı Politikalar
# Test ortamı için sert kısıtlamalar # 1. Instance Expiration Kapsam : Tenant — Test-Ortami Max Yaşam : 7 gün (haftasonları dahil) Uyarı : 2 gün kala e-posta gönder Süre Dolunca: Otomatik sil # 2. Max Instances Kapsam : Tenant — Test-Ortami Max : Kullanıcı başına 3 VM # 3. Service Plan Kısıtlaması Kapsam : Tenant — Test-Ortami İzin Verilen: Yalnızca "Küçük" plan (2 vCPU / 4 GB) Yasak : Orta, Büyük, Özel planlar
07

Kamu Altyapısı için İzolasyon Senaryosu

Kamu kurumlarına hizmet sunan altyapılarda (belediye, bakanlık, kamu hastanesi sistemleri) veri izolasyonu yasal yükümlülük taşır. Morpheus'un çok kiracılı yapısı bu senaryolar için birebir uygundur; ancak bazı ek önlemler alınması gerekir.

1
Kuruma Özel Tenant Mimarisi
# Örnek: Şehir Belediyeleri Ortak Altyapısı Master Tenant : Altyapı Operasyon Merkezi (yönetim) Sub-Tenant A : Büyükşehir Belediyesi (izole) Sub-Tenant B : İlçe Belediyesi X (izole) Sub-Tenant C : İlçe Belediyesi Y (izole) Sub-Tenant D : Bağlı Kuruluş Z (izole) # Her Sub-Tenant: # - Kendi VM'lerini yalnızca kendisi görür # - Kendi AD OU'su ile giriş yapar # - Ayrı resource pool kullanır # - Ayrı bütçe sınırı vardır # - Kendi raporlarını kendisi alır
2
Ağ Segmentasyonu ile Doğrulama
# Her tenant farklı VLAN'a atanır: Sub-Tenant A → VLAN 100 (10.100.0.0/24) Sub-Tenant B → VLAN 200 (10.200.0.0/24) Sub-Tenant C → VLAN 300 (10.300.0.0/24) # Morpheus ağ izinleri: # Tenant A kullanıcısı provisioning sırasında # yalnızca VLAN 100'ü görebilir # Ek güvenlik: NSX-T Mikro-Segmentasyon # Her tenant'ın ağı doğu-batı trafiğe kapalı
3
KDK ve Siber Güvenlik Uyumluluk Notları
# Türkiye Bilgi Güvenliği Yönetim Sistemi — BGYS gereksinimleri # ISO 27001 / Cumhurbaşkanlığı Siber Güvenlik Stratejisi 2023 # Morpheus'ta uyumluluk için: 1. Tüm API erişimlerini HTTPS ile zorunlu kılın 2. Denetim günlüklerini (audit logs) 2 yıl saklayın (6. bölüm) 3. Oturum zaman aşımını 15 dakika olarak ayarlayın 4. Çok faktörlü kimlik doğrulama (MFA) — Morpheus SAML/OIDC ile SSO 5. Ayrıcalıklı hesap yönetimi — Admin hesapları ayrı AD OU'sunda 6. Şifre politikası: Min. 12 karakter, karmaşık, 90 günde değişim # Administration → Settings → Security Session Timeout : 900 saniye (15 dakika) Password Min Len : 12 Require Complexity : Evet Max Login Attempts : 5
08

Denetim Günlükleri ve Uyumluluk

Morpheus, kullanıcı işlemlerini ayrıntılı denetim günlüğüne (audit log) yazar. Kim, ne zaman, hangi işlemi yaptı; başarılı mı başarısız mı? Bu veriler uyumluluk raporlaması ve güvenlik olayı araştırmaları için kritiktir.

1
Activity Log'u İnceleyin
# Operations → Activity — tüm sistem aktivitesi # Filtreler: Kullanıcı, Tarih, İşlem Türü, Tenant, Kaynak # Kritik olaylar için uyarı kurun: # - Kullanıcı silindi # - Rol değişikliği yapıldı # - Tenant oluşturuldu/silindi # - Başarısız giriş denemesi (5 kez) # - Üretim VM'i silindi # Morpheus API ile log dışa aktarımı: GET /api/activity ?startDate=2026-06-01T00:00:00Z &endDate=2026-06-30T23:59:59Z &userId=42 &activityType=delete
2
Syslog ile Merkezi Log Yönetimine Aktarın
# /etc/morpheus/morpheus.rb — Syslog yapılandırması # Morpheus günlüklerini SIEM'e gönderin (Splunk, ELK, Graylog) # Syslog forwarder (rsyslog örneği) # /etc/rsyslog.d/morpheus.conf :programname, isequal, "morpheus-ui" @siem.sirket.com:514 # Morpheus UI günlük konumu: # /var/log/morpheus/morpheus-ui/current # Elasticsearch günlükleri Morpheus'ta dahili tutuluyor # Administration → Settings → Logging → Retention: 90 gün
09

API Erişim Kontrolü

Morpheus REST API, aynı RBAC modeline tabidir. API token'ı olan bir kullanıcı, arayüzden yapabileceği her şeyi API üzerinden de yapabilir — ne fazlası ne eksiği. Bu nedenle API token yönetimi güvenlik açısından kritiktir.

1
API Token Güvenliği
# API token oluşturma — kullanıcı kendi tokenını oluşturur # User Settings → API Access → + Generate Token # Token türleri: # Access Token : Kısa ömürlü (varsayılan 24 saat) # Refresh Token: Token yenileme için # Token güvenlik kuralları: # 1. Her uygulama için ayrı kullanıcı ve token kullanın # 2. Token'ları kaynak koduna yazmayın — CI/CD secret olarak saklayın # 3. Kullanılmayan token'ları iptal edin (User Settings → Revoke) # 4. Hizmet hesapları için minimum yetkili rol oluşturun # Token'ı iptal etme (API): DELETE /api/access-token/{tokenId}
2
IP Beyaz Listesi ile API Erişim Kısıtlaması
# Morpheus doğrudan IP beyaz listesi sunmaz # Nginx ters proxy katmanında uygulayın: # /etc/nginx/conf.d/morpheus_api_restrict.conf location /api/ { # Yalnızca belirli IP'lerden API erişimine izin ver allow 10.10.10.0/24; # Yönetim ağı allow 10.20.30.40; # CI/CD sunucusu deny all; proxy_pass http://127.0.0.1:8080; } # morpheus-ctl reconfigure ile uygula
10

İzolasyon Testi ve Doğrulama

Çok kiracılı yapılandırmanızın doğru çalıştığını sistematik olarak test etmek zorunludur. Aşağıdaki test senaryolarını her büyük değişiklik sonrasında tekrarlayın.

  • Çapraz tenant görünürlük testi: Sub-Tenant A kullanıcısıyla giriş yap → Sub-Tenant B'nin VM'lerinin listede görünmediğini doğrula
  • Ağ izolasyon testi: Sub-Tenant A VM'inden Sub-Tenant B VM'ine ping atılamadığını doğrula
  • Rol testi — yetersiz yetki: "App-Developer" rolüyle altyapı menüsüne erişilemiyor mu?
  • Kota testi: Max Instance limitine ulaşıldığında yeni provisioning reddediliyor mu?
  • İsimlendirme testi: Yanlış formatta VM adı girildiğinde hata alınıyor mu?
  • Onay akışı testi: Provisioning talebi onaylayıcıya ulaşıyor mu?
  • API izolasyon testi: Sub-Tenant A token'ıyla Sub-Tenant B kaynaklarına API erişimi reddediliyor mu?
  • Denetim günlüğü testi: Test işlemleri Activity Log'a eksiksiz yazıldı mı?
  • AD grup testi: Yetkisiz AD grubu üyesi Morpheus'a giriş yapamıyor mu?
  • Bütçe aşım testi: Bütçe limitine ulaşıldığında bildirim geliyor mu, provisioning duruyor mu?
ESH Bilişim

HPE Morpheus RBAC ve Çok Kiracılı Mimari Danışmanlığı

ESH Bilişim, kamu kurumları ve kurumsal altyapılar için HPE Morpheus'ta çok kiracılı izolasyon tasarımı, RBAC yapılandırması, KDK uyumlu güvenlik politikaları ve denetim günlüğü entegrasyonu konularında saha danışmanlığı sunar.

Kaynaklar

  1. HPE Morpheus, "Multi-Tenancy and Role-Based Access Control" — docs.morpheusdata.com/roles
  2. HPE Morpheus, "Tenant Management" — docs.morpheusdata.com/tenants
  3. HPE Morpheus, "Policies Reference" — docs.morpheusdata.com/policies
  4. Cumhurbaşkanlığı Dijital Dönüşüm Ofisi, "Ulusal Siber Güvenlik Stratejisi 2023-2025" — cbddo.gov.tr
  5. NIST, "Role-Based Access Control" (SP 800-162) — csrc.nist.gov/SP800-162
HPE MorpheusRBACMulti-Tenant GüvenlikİzolasyonKDK Uyumu
↑ Başa Dön