[TR] HPE Morpheus Enterprise’da Appliance Yönetim Ayarları ve Detayları

HPE Morpheus Enterprise kurumların private cloud, public cloud, sanallaştırma platformları, Kubernetes cluster’ları ve otomasyon süreçlerini tek bir merkezi arayüz üzerinden yönetebilmesini sağlayan güçlü bir hibrit bulut yönetim platformudur.

Bu kadar merkezi bir rol üstlenen bir platformda Administration -> Settings ekranı, yalnızca birkaç temel sistem parametresinin tanımlandığı bir alan değildir aksine güvenlik, erişilebilirlik, entegrasyon, performans, kullanıcı yönetimi, bildirim mekanizmaları ve maliyet yönetimi gibi birçok kritik başlığın temelini oluşturur.

Bu nedenle Morpheus Settings ekranındaki her parametre dikkatle değerlendirilmelidir. Yanlış yapılandırılmış bir Appliance URL, agent iletişimini bozabilir; yetersiz parola politikası brute-force saldırılarına kapı aralayabilir; hatalı SMTP ayarı sistem bildirimlerinin kullanıcılara ulaşmasını engelleyebilir; gereğinden sık çalışan cloud sync süreçleri ise hem Morpheus appliance üzerinde hem de bağlı cloud platformlarında gereksiz API yükü oluşturabilir.

Bu makalede HPE Morpheus Enterprise’ın Administration -> Settings ekranında yer alan ayarlar; teknik açıklamalar, mevcut değerlerin anlamı, olası riskler ve önerilen en iyi uygulamalarla birlikte ele alınmaktadır.

Aşağıdaki başlıklar Settings ekranındaki sekmelerin yapısını birebir takip eder. Her bölümün sonunda kısa bir “production ortamı için önerilen yapılandırma” özeti bulacaksınız.

İlk kez kurulum yapıyorsanız sırayla mevcut sistemi gözden geçiriyorsanız doğrudan ilgili sekmeye atlayabilirsiniz.

A) Appliance Settings

Appliance Settings bölümü Morpheus appliance’ın temel çalışma davranışını belirleyen en kritik alanlardan biridir. Burada yapılan ayarlar, agent iletişiminden API erişimine, senkronizasyon sıklığından veri saklama politikalarına kadar birçok operasyonel süreci doğrudan etkiler.

1) Appliance URL

Appliance URL, Morpheus appliance’a erişim için kullanılan ana adrestir. Bu URL yalnızca kullanıcıların web arayüzüne eriştiği adres olarak düşünülmemelidir. Provision edilen sanal makinelerde kurulan Morpheus Agent da appliance ile haberleşirken bu adresi kullanır.

Ayrıca e-posta bildirimleri, webhook çağrıları, API bağlantıları ve bazı otomasyon süreçlerinde de bu URL referans alınır.

Bu nedenle production ortamlarında IP adresi yerine mutlaka anlamlı ve kalıcı bir FQDN kullanılmalıdır. Örneğin:

https://morpheus.company.com

Burada dikkat edilmesi gereken en önemli konulardan biri SSL sertifikasıdır. Kullanılan sertifika, Appliance URL ile birebir uyumlu olmalıdır.

Sertifika common name veya subject alternative name alanlarında bu FQDN yer almıyorsa agent bağlantılarında veya kullanıcı erişimlerinde sertifika hataları yaşanabilir.

Öneri: Production ortamlarında Appliance URL mutlaka DNS üzerinde doğru çözümlenmeli, geçerli bir kurumsal veya public CA imzalı SSL sertifikası ile desteklenmelidir. Self-signed sertifikalar yalnızca test ve lab ortamlarında tercih edilmelidir.

İlk kurulumda IP adresi girilip sonradan FQDN'e geçildiğinde, daha önce provision edilmiş VM'lerdeki agent'lar eski IP'ye bağlanmaya devam eder ve bir süre sonra "unmanaged" duruma düşer. 

URL değişikliği planlıyorsanız mutlaka önce DNS hazırlığını yapın, ardından mevcut agent'ları yeni URL ile yeniden konfigüre edin.

2) Internal Appliance URL for PXE

Bu alan özellikle bare-metal provisioning ve PXE boot senaryoları için önemlidir.

Morpheus appliance ile bare-metal sunucular farklı network segmentlerinde bulunuyorsa veya NAT arkasında çalışan bir mimari varsa PXE boot sırasında appliance’a erişim için alternatif bir URL tanımlanması gerekebilir.

Alan boş bırakılırsa Morpheus varsayılan olarak Appliance URL değerini kullanır. Ancak PXE boot yapan sunucular bu URL’e erişemiyorsa provisioning süreci başarısız olabilir.

Öneri: Bare-metal provisioning kullanılmayan ortamlarda boş bırakılması normaldir. Ancak fiziksel sunucu provisioning yapılan yapılarda PXE network’ünün appliance’a hangi adresten erişebildiği test edilmeli ve gerekiyorsa Internal Appliance URL ayrıca tanımlanmalıdır.

3) API Allowed Origins

API Allowed Origins alanı, CORS yani Cross-Origin Resource Sharing yapılandırması için kullanılır. Harici bir web uygulamasının Morpheus API’lerine tarayıcı üzerinden erişmesi gerekiyorsa, ilgili domain’lerin bu alana eklenmesi gerekir.

Bu ayar güvenlik açısından hassastır. Gereğinden geniş tanımlanmış CORS izinleri, Morpheus API’lerinin istenmeyen kaynaklardan çağrılmasına neden olabilir.

Tipik kullanım: DMZ’de duran ana appliance URL’ine izole bir provisioning VLAN’ından çıkış kontrollü olduğunda erişim mümkün olmayabilir. Bu durumda iç URL olarak doğrudan appliance’ın iç IP’sini veya iç DNS adını verebilirsiniz.

Öneri: Bu alan kesinlikle wildcard mantığıyla geniş bırakılmamalıdır. Yalnızca gerçekten API erişimi yapması gereken güvenilir domain’ler eklenmelidir. Örneğin:

https://portal.company.com

Bu alana asla * (wildcard) yazmayın. 
Yalnızca güvendiğiniz, kontrolünüz altındaki domain'leri ekleyin. Aksi takdirde XSS senaryolarında saldırgan, kullanıcının tarayıcısı üzerinden Morpheus API'sine yetkili çağrılar yapabilir hale gelir.

4) Cloud Sync Interval

Cloud Sync Interval, Morpheus’un bağlı cloud platformlarından envanter ve durum bilgisi çekme sıklığını belirler. VMware, AWS, Azure, Google Cloud veya benzeri platformlardan gelen veriler bu periyotla güncellenir.

Mevcut değerin 300 saniye yani 5 dakika olması çoğu ortam için makul bir varsayılandır.

Daha düşük değerler daha güncel veri sağlar ancak API çağrı sayısını artırır.

Daha yüksek değerler ise API yükünü azaltır fakat Morpheus üzerindeki envanter bilgisinin gecikmeli güncellenmesine neden olur.

Örneğin 60 saniyelik bir değer küçük ve dinamik ortamlarda faydalı olabilir. Ancak çok sayıda cloud entegrasyonu binlerce VM veya yoğun API limitleri olan public cloud hesapları varsa bu değer performans sorunlarına yol açabilir.

Öneri: Küçük ve orta ölçekli ortamlarda 300 saniye uygundur.

Büyük enterprise yapılarda 600 saniye veya daha yüksek değerler değerlendirilebilir.

Public cloud API limitleri ve Morpheus appliance performansı düzenli izlenmelidir.

VMware ortamlarında binlerce VM'in olduğu büyük ölçekli kurulumlarda 300 sn'lik sync, vCenter üzerinde gözle görülür bir API baskısı yaratabilir. 

Böyle durumlarda 600 sn ile başlamak ve ihtiyaç olursa indirmek daha sağlıklıdır.

5) Cluster Sync Interval

Cluster Sync Interval, Kubernetes ve benzeri cluster ortamlarının senkronizasyon sıklığını belirler. Alan boş bırakıldığında Cloud Sync Interval değeri kullanılır.

Kubernetes cluster sayısı fazla olan yapılarda cluster API’lerine yapılan sürekli çağrılar hem Morpheus tarafında hem de cluster control plane üzerinde ek yük oluşturabilir.

Öneri: Çok sayıda Kubernetes cluster yönetiliyorsa bu değer Cloud Sync Interval’dan bağımsız olarak 600 saniye gibi daha kontrollü bir değere çekilebilir.

Kubernetes ve diğer cluster türlerinin senkronizasyon sıklığını ayrı olarak yönetir. 

Boş bırakıldığında Cloud Sync Interval değerini kullanır. 

Kubernetes ortamlarında pod ve node sayıları çok hızlı değişebildiği için bu alanı ayrı olarak yapılandırmak çoğunlukla mantıklıdır. 

Onlarca cluster yönetiyorsanız bu değeri 600 sn'ye çıkarmak hem Morpheus tarafında hem de Kubernetes API server tarafında nefes aldırır.

6) Usage Retainment

Usage Retainment, CPU, RAM, disk ve benzeri kaynak kullanım verilerinin ne kadar süre saklanacağını belirler. Bu veriler özellikle chargeback, showback, kapasite planlama ve geçmiş tüketim analizleri için önemlidir.

Çok kısa saklama süresi, geçmişe dönük maliyet ve kullanım analizi yapılmasını zorlaştırır. Çok uzun saklama süresi ise veritabanı boyutunu artırabilir.

Öneri: Chargeback veya showback kullanılan yapılarda en az 6-12 aylık kullanım verisi saklanması faydalıdır.

Finansal raporlama yapılan ortamlarda bu süre kurumun denetim ve raporlama politikalarıyla uyumlu belirlenmelidir.

Ayar	Etki Alanı	Varsayılan	Önerilen
Usage Retainment	CPU/RAM/Storage kullanım verisi	Varsayılan	180–365 gün
Invoice Retainment	Faturalama kayıtları	Varsayılan	12–24 ay
Incident Retainment	Monitoring olayları (incident)	30 gün	60–90 gün
State Retainment	Performans metrikleri (stats)	30 gün	30–60 gün
Reports Retainment	Oluşturulan rapor dosyaları	90 gün	90–180 gün

Burada dikkat edilmesi gereken nokta, Saklama süreleri uzadıkça veritabanı boyutu büyür ve yedekleme/restore süreleri uzar.

Özellikle State Retainment alanını 60 günün üzerine çıkarmak öncesi veritabanı diskinde yeterli kapasite olduğundan emin olun.

Chargeback/showback raporlamasının kritik olduğu ortamlarda ise Usage ve Invoice alanlarını cömert tutmaktan kaçınmayın, geçmişi geri getiremezsiniz.

7) Invoice Retainment

Invoice Retainment, faturalama verilerinin ne kadar süreyle saklanacağını belirler. Bu alan özellikle yıllık karşılaştırmalı maliyet analizleri, bütçe planlama, departman bazlı tüketim raporları ve denetim süreçleri için önemlidir.

Öneri: Kurumsal yapılarda 12-24 ay arası saklama süresi genellikle uygundur. Finans, IT ve denetim ekiplerinin ihtiyaçları birlikte değerlendirilmelidir.

8) Incident Retainment

Incident Retainment, monitoring sistemi tarafından oluşturulan olay kayıtlarının kaç gün saklanacağını belirler.

Mevcut değerin 30 gün olması temel operasyonel takip için yeterli olabilir.

Ancak SLA raporlaması, kök neden analizi veya uzun dönemli incident trend analizi yapılıyorsa 30 gün yetersiz kalabilir.

Öneri: Production ortamlarında minimum 90 gün, regülasyon veya SLA ihtiyacı olan yapılarda 180 gün veya daha uzun süreler değerlendirilebilir.

9) State Retainment

State Retainment, performans istatistiklerinin ve geçmiş metriklerin ne kadar süre saklanacağını belirler. Uzun süreli metrik saklama kapasite planlama için değerlidir ancak veritabanı boyutunu artırır.

Öneri: Ortam büyüklüğüne göre dengeli bir değer seçilmelidir. Büyük ortamlarda uzun süreli state retention kullanılacaksa veritabanı kapasitesi ve bakım süreçleri ayrıca planlanmalıdır.

10) Reports Retainment

Reports Retainment, oluşturulan raporların sistemde ne kadar süre tutulacağını belirler.

Mevcut değerin 90 gün olması çoğu operasyonel ortam için makul kabul edilebilir.

Öneri: Finansal veya denetim amaçlı raporlar üretiliyorsa, raporların yalnızca Morpheus içinde değil, harici bir doküman yönetim veya arşiv sisteminde de saklanması önerilir.

11) Denied Hosts

Denied Hosts alanı, HTTP task’ları veya REST datasource option list’leri gibi dış bağlantı kurabilen özellikler için erişimi engellenecek IP veya hostname listesini tanımlar.

Bu alan özellikle SSRF yani Server-Side Request Forgery saldırılarına karşı kritik bir savunma katmanı sağlar.

Kötü niyetli veya hatalı yapılandırılmış bir otomasyon, Morpheus appliance üzerinden hassas internal servislere erişmeye çalışabilir.

Engellenmesi önerilen bazı hedefler şunlardır:

• 169.254.169.254
• Cloud metadata endpoint’leri
• Internal management network IP aralıkları
• Vault, secret manager veya hassas API endpoint’leri

Öneri: Production ortamlarında Denied Hosts mutlaka değerlendirilmelidir. Özellikle public cloud ortamlarında metadata endpoint’lerinin engellenmesi önemlidir.

Neden bu kadar önemli?
Bir SSRF saldırısında saldırgan uygulamayı kandırarak iç ağdaki hassas servislere (örneğin AWS metadata endpoint'i 169.254.169.254) istek atmasını sağlayabilir. 

Bu yolla IAM credential'ları çalınabilir. 

Denied Hosts listesi bu tür kritik adresleri kara listeye alarak savunmanın ilk hattını oluşturur.

11) Approved Hosts

Approved Hosts, Denied Hosts’un tersine çalışan bir whitelist mekanizmasıdır.

Bu alan boş bırakılırsa yalnızca Denied Hosts listesi dikkate alınır.

Ancak Approved Hosts doldurulursa Morpheus yalnızca burada belirtilen host’lara erişebilir.

Bu yaklaşım yüksek güvenlik gerektiren ortamlarda oldukça değerlidir.

Örnek:

• api.company.com,
• internal-api.company.com,
• vault.company.com

Öneri: Finans, kamu, sağlık veya yüksek güvenlikli enterprise yapılarda mümkünse whitelist yaklaşımı tercih edilmelidir. Böylece otomasyonların yalnızca onaylı sistemlere erişmesi sağlanır.

Production ortamlarında mümkün olduğunda Approved Hosts (whitelist) yaklaşımını tercih edin. Bilinmeyen veya yanlışlıkla yazılmış adreslere yapılan çağrılar otomatik olarak engellenir. Liste yönetimini bir change management süreciyle birleştirin.

12) Exchange URL

Exchange URL, Morpheus Exchange içeriklerine erişim için kullanılan adrestir.

Varsayılan olarak https://share.morpheusdata.com kullanılır.

Bu platform üzerinden plugin’ler, entegrasyonlar ve community içerikleri alınabilir.

İnternet erişimi olmayan air-gapped ortamlarda bu URL değiştirilebilir ve kurum içi bir Exchange kaynağı kullanılabilir.

Öneri: İnternet erişimi olan ortamlarda varsayılan değer kullanılabilir. Ancak air-gapped veya regülasyon nedeniyle dış bağlantının yasak olduğu ortamlarda internal repository yaklaşımı tercih edilmelidir.

12) Skip Agent Install

Skip Agent Install ayarı provision edilen VM’lere Morpheus Agent kurulup kurulmayacağını belirler. Mevcut durumda kapalı olması, agent’ın otomatik kurulacağı anlamına gelir.

Morpheus Agent; guest OS metriklerinin toplanması, automation script’lerinin çalıştırılması, log toplama ve workflow task execution gibi birçok yetenek sağlar.

Bu ayar açılırsa agent kurulmaz. Sonuç olarak guest OS seviyesindeki birçok özellik devre dışı kalır.

Öneri: Production ortamlarında genellikle kapalı kalmalı yani agent kurulumu yapılmalıdır.

Yalnızca çok sıkı güvenlik politikaları bulunan veya agent kurulmasına izin verilmeyen özel sistemlerde açılması değerlendirilmelidir.

13) Enable SSL Verification of Agent

Bu ayar Morpheus Agent’ın appliance ile haberleşirken SSL sertifikasını doğrulayıp doğrulamayacağını belirler.

Mevcut durumda kapalı olması test ortamları için kabul edilebilir.

Production ortamlarında agent’ın appliance sertifikasını doğrulaması gerekir. Aksi takdirde man-in-the-middle saldırılarına karşı zayıf bir yapı oluşur.

Öneri: Production ortamlarında mutlaka açık olmalıdır. Bunun için Appliance URL ile uyumlu geçerli bir SSL sertifikası kullanılmalı ve agent’ların bu sertifika zincirine güvenmesi sağlanmalıdır.

Bu ayar OFF kaldığında agent ile appliance arasındaki trafik teknik olarak şifrelidir, ancak araya giren bir saldırgan kendi sahte sertifikasını sunabilir ve MITM (Man-in-the-Middle) saldırısı gerçekleştirebilir. Üretim ortamında geçerli bir CA tarafından imzalı sertifika yükleyip bu ayarı mutlaka ON yapın.

14) Disable SSH Password Authentication

Bu ayar provision edilen Linux VM’lerde SSH password authentication’ın devre dışı bırakılıp bırakılmayacağını belirler.

Kapalı olduğunda hem parola hem de SSH key ile bağlantı mümkün olabilir. Açıldığında yalnızca key-based authentication kabul edilir.

Öneri: Production Linux sistemlerde bu ayarın açılması güvenlik açısından güçlü bir adımdır.

SSH key yönetimi ise Morpheus Cypher, Vault entegrasyonu veya merkezi secret management çözümü ile birlikte ele alınmalıdır.

15) Default Appliance Locale

Default Appliance Locale, Morpheus arayüzünün varsayılan dilini belirler. Seçilmezse kullanıcı tarayıcı dili baz alınır.

Çok uluslu ekiplerde bu alanın boş bırakılması daha esnek olabilir. Ancak tek dil standardı olan kurumsal yapılarda örneğin İngilizce varsayılan dil olarak belirlenebilir.

Öneri: Global ekiplerde boş bırakılması, standart kurumsal operasyon ekiplerinde ise ortak dilin seçilmesi daha doğru olur.

Provision edilen Linux VM'lerde SSH password authentication'ın devre dışı bırakılıp bırakılmayacağını belirler. ON yapıldığında yeni provision edilen sunucular yalnızca SSH key ile erişilebilir hale gelir.

Brute-force saldırılarına karşı en etkili savunma yöntemlerinden biridir. PCI-DSS, HIPAA gibi compliance gereksinimleri için de neredeyse zorunlu bir ayardır. Açmadan önce SSH key yönetiminizin (tercihen Cypher veya Vault entegrasyonu üzerinden) hazır olduğundan emin olun, yoksa kendi sunucularınıza erişimi kaybedebilirsiniz.

16) Default Console Gateway

Bu ayar VM konsol bağlantılarının belirli bir worker node üzerinden yönlendirilmesini sağlar. Özellikle appliance ve VM network’leri farklı segmentlerdeyse, DMZ üzerinden erişim gerekiyorsa veya konsol trafiği ayrı bir node’a yönlendirilmek isteniyorsa kullanılır.

Öneri: Büyük ve segmentli network yapılarında console gateway mimarisi planlanmalıdır. Küçük ortamlarda boş bırakılması normaldir.

17) Max Option List Size

Max Option List Size dropdown menülerde veya REST datasource option list’lerinde gösterilecek maksimum öğe sayısını belirler.

Mevcut değerin 1000 olması çoğu ortam için dengeli bir seçimdir.

Bu değer çok artırılırsa tarayıcı performansı ve sunucu yanıt süreleri olumsuz etkilenebilir.

Öneri: 1000 değeri genellikle korunmalıdır.

Çok büyük listeler için değeri artırmak yerine filtreleme, arama veya dinamik datasource yaklaşımı kullanılmalıdır.

Dropdown menülerde, REST datasource'larında ve option list'lerde gösterilebilecek maksimum öğe sayısıdır. Varsayılan değer 1000 olup, çoğu senaryo için optimaldir.

Bu değeri 10.000 üzerine çıkarmak hem tarayıcıyı hem de appliance'ı ciddi şekilde yavaşlatır. Çok büyük listelerle çalışmanız gerekiyorsa, dropdown yerine arama/filtreleme tabanlı bir form yaklaşımını tercih edin. Kullanıcıların 5000 öğe arasından scroll yapması zaten pratik değildir.

18) Dashboards to Display

Bu bölüm kullanıcıların Morpheus arayüzünde göreceği dashboard’ları ve sıralarını belirler.

Örneğin Default Home Dashboard, Cloud List Dashboard ve Cluster List Dashboard gibi ekranlar burada yönetilebilir.

Öneri: Dashboard sıralaması kullanıcı rollerine göre düşünülmelidir. Operasyon ekipleri için infrastructure ve monitoring odaklı dashboard’lar finans ekipleri için cost ve billing dashboard’ları; platform ekipleri için cluster ve automation dashboard’ları öne çıkarılabilir.

Pratik tavsiyem : Inventory Dashboard, Cost & Billing Dashboard ve Capacity Planning Dashboard‘ı da eklemek farklı rollerdeki kullanıcılar için faydalı olur. Finans ekibinizin günlük olarak baktığı bir Morpheus arayüzünde Cost Dashboard’un en üstte olması, ürünün benimsenmesini ciddi şekilde artırır.

B) Tenant Management Settings

Tenant Management Settings, Morpheus’un multi-tenancy yapısını kontrol eder.

Tek bir Morpheus appliance üzerinde birden fazla müşteri, departman, iş birimi veya proje ekibi izole şekilde yönetilebilir.

Bu bölüm özellikle MSP, büyük enterprise, holding yapıları ve çok departmanlı organizasyonlar için kritik öneme sahiptir.

1) Registration Enabled

Registration Enabled, kullanıcıların kendi tenant kayıtlarını oluşturup oluşturamayacağını belirler.

Mevcut durumda kapalı olması kurumsal ortamlar için doğru bir yaklaşımdır. Çünkü tenant oluşturma süreci genellikle kontrollü yapılmalı, kaynak erişimleri, roller ve kota politikaları admin ekipleri tarafından belirlenmelidir.

Öneri: Internal private cloud ortamlarında kapalı kalmalıdır. MSP veya self-service public cloud benzeri yapılarda açılması değerlendirilebilir.

Self-service tenant kaydı özelliğini kontrol eder. 

OFF konumunda sadece admin'ler yeni tenant oluşturabilir; bu, kurumsal ortamlar için doğru ayardır. 

ON yapıldığında kullanıcılar kayıt sayfası üzerinden kendi tenant'larını oluşturabilir ki bu daha çok MSP (Managed Service Provider) ve public cloud senaryolarına uygun bir yaklaşımdır.

Senaryo	Önerilen Değer	Gerekçe
Internal Private Cloud	OFF	Kontrollü tenant yönetimi şart
MSP / Service Provider	ON	Self-service onboarding hızı
University / Research	OFF	Manuel onboarding tercih edilir
Hybrid Cloud (Kurumsal)	OFF	IT governance açısından

2) Default Tenant Role

Default Tenant Role, yeni oluşturulan tenant’lara otomatik atanacak rol şablonunu belirler. Bu rol, tenant’ın hangi cloud’lara, gruplara, instance type’larına ve kaynaklara erişebileceğini kontrol eder.

Burada dikkat edilmesi gereken nokta: tenant role ile user role kavramlarının ayrılmasıdır. Tenant role tenant’ın platform seviyesindeki erişimini, user role ise kullanıcının tenant içindeki yetkilerini belirler.

Öneri: Least privilege yaklaşımı benimsenmelidir. Yeni tenant’lara geniş yetkiler vermek yerine sınırlı bir default rol atanmalı, ihtiyaç oldukça genişletilmelidir.

3) Default User Role

Default User Role, yeni tenant içinde oluşturulan ilk kullanıcıya atanacak rolü belirler. Genellikle Tenant Administrator, Standard User, Read-Only User veya Self-Service User gibi roller kullanılabilir.

Öneri: Tenant self-service modeli kullanılmıyorsa bu alan dikkatli yapılandırılmalıdır. Her ilk kullanıcıya otomatik tam yetki vermek yerine, kurumun onboarding süreciyle uyumlu bir rol atanmalıdır.

Yeni oluşturulan tenant'lara otomatik atanacak rol şablonunu belirler. Burada önemli bir ayrım var: Tenant Role tenant'ın platform üzerindeki yetkilerini (hangi cloud'lara, gruplara, instance type'larına erişebileceğini) belirlerken, User Role kullanıcının tenant içindeki yetkilerini kontrol eder. İkisi farklı katmanlardır ve karıştırılırsa beklenmedik erişim sorunlarına yol açabilir.

Default rolü mümkün olduğunca kısıtlı tutun. "Tenant-Restricted" gibi minimum yetkili bir şablon tanımlayıp varsayılan olarak atayın. 

İhtiyacı olan tenant'lar için sonradan yetki yükseltebilirsiniz; ama gereksiz yetki vermek geri alınması zor bir güvenlik borcudur.

4) Docker Privileged Mode

Docker Privileged Mode, tenant’ların privileged container çalıştırıp çalıştıramayacağını belirler. Bu ayar güvenlik açısından son derece kritiktir.

Privileged mode açıldığında container, host sistem üzerinde çok geniş yetkilere sahip olabilir. Host kernel’a, device’lara ve bazı sistem kaynaklarına erişim riski doğar. Multi-tenant ortamlarda bu, tenant izolasyonunu ciddi şekilde zayıflatabilir.

Öneri: Multi-tenant production ortamlarında kesinlikle kapalı kalmalıdır. Yalnızca tek tenant kullanılan, izole, güvenilen ve özel sistem-level container ihtiyaçları bulunan ortamlarda dikkatli şekilde açılmalıdır.

 Bu ayara özellikle dikkat !!!
Bu Settings ekranındaki en kritik güvenlik anahtarlarından biridir. 

ON yapıldığında tenant'ların privileged Docker container çalıştırmasına izin verilir bu da container'ların host sistemin root yetkilerine erişebilmesi anlamına gelir.

Privileged mod açıldığında container'ların erişim alanı kabaca şu hale gelir;

•	Host kernel'a erişim — sistem-level müdahaleler mümkün olur.
•	Tüm device'lara doğrudan erişim — disklere, GPU'lara, ağ arayüzlerine ham erişim.
•	Container escape saldırılarının çok kolaylaşması.
•	Multi-tenant ortamda bir tenant'ın diğer tenant'ların container'larına müdahale edebilmesi.

Tavsiyem : Multi-tenant bir ortamda bu ayar kesinlikle OFF kalmalıdır. 
Yalnızca tek tenant kullanımı, Docker-in-Docker (DinD) test ortamları veya tamamen izole edilmiş, güvenilen lab kurulumlarında açılabilir. Bu kararı vermeden önce ekibinizdeki güvenlik mimarına mutlaka danışın.

C) User Management Settings

User Management Settings, Morpheus’un yerel kullanıcıları için parola politikaları, oturum süreleri ve hesap güvenliği ayarlarını içerir.

LDAP, Active Directory veya SAML gibi harici kimlik sağlayıcılar kullanılıyorsa bazı parola politikaları identity provider tarafından yönetilebilir. Ancak Morpheus üzerindeki local kullanıcılar ve fallback admin hesapları için bu alan yine de önemlidir.

1) Min Password Length

Mevcut minimum parola uzunluğunun 8 karakter olması temel bir güvenlik seviyesidir ancak modern production ortamları için artık zayıf kabul edilmektedir.

Günümüzde parola güvenliğinde uzunluk, karmaşıklıktan daha etkili bir faktördür. 8 karakterli karmaşık bir parola modern saldırı araçlarıyla daha kısa sürede kırılabilirken, 14-16 karakterlik bir passphrase çok daha güçlü koruma sağlar.

Öneri: Production ortamlarında minimum parola uzunluğu en az 12, ideal olarak 14-16 karakter olmalıdır.

Standart	Min. Uzunluk	Notlar
NIST SP 800-63B	8 karakter	Modern, length odaklı yaklaşım
PCI-DSS v4	12 karakter	Ödeme kart endüstrisi zorunluluğu
CIS Benchmark	14 karakter	Hardening standardı
ISO 27001	8–12 karakter	Risk değerlendirmesine bağlı
Morpheus varsayılan	8 karakter	Geçer seviye, yetersiz

NIST'in modern tavsiyesi açıktır: parola uzunluğu, karmaşıklığından çok daha önemlidir. 

8 karakterli karmaşık bir parola modern GPU'larla saatler içinde kırılabilirken, 14 karakterli görece basit bir parola pratik olarak kırılamaz. 

Üretim ortamı için minimum 12, ideal olarak 14–16 karakter belirlemenizi öneririz.

2) Min Password Uppercase, Numbers ve Symbols

Bu ayarlar parolada en az kaç büyük harf, rakam ve sembol bulunacağını belirler. Mevcut durumda her biri için 1 değerinin kullanılması klasik karmaşıklık politikasına uygundur.

Ancak yalnızca karmaşıklık kurallarına güvenmek yeterli değildir. Kullanıcılar çoğu zaman tahmin edilebilir şablonlar kullanır. Örneğin Password2026! teknik olarak karmaşık görünse de tahmin edilmesi kolaydır.

Öneri: Karmaşıklık kuralları korunabilir ancak asıl güvenlik artırımı minimum uzunluğu yükselterek ve mümkünse MFA kullanarak sağlanmalıdır.

3) Session Expires

Session Expires kullanıcının belirli süre inaktif kalması durumunda oturumunun otomatik kapatılmasını sağlar.

Mevcut değerin 20 dakika olması güvenlik ve kullanıcı deneyimi arasında makul bir dengedir.

Çok kısa süreler kullanıcı deneyimini olumsuz etkiler. Çok uzun süreler ise açık unutulan oturumlar nedeniyle güvenlik riski oluşturur.

Öneri: Genel enterprise ortamlarında 15-30 dakika arası uygundur. Finans, sağlık veya regülasyon yoğun ortamlarda 10-15 dakika tercih edilebilir.

4) Session Warning

Session Warning, oturum kapanmadan önce kullanıcıya uyarı verilmesini sağlar.

Mevcut yapılandırmada Session Expires 20 dakika, Session Warning 15 dakika ise kullanıcıya kapanmadan yaklaşık 5 dakika önce uyarı verilmiş olur.

Öneri: Uyarı süresi oturum kapanmadan 2-5 dakika önce kullanıcıya bildirim verecek şekilde ayarlanmalıdır.

5) Expire Password After

Bu ayar parolaların belirli gün sonunda otomatik expire olmasını sağlar. Modern güvenlik yaklaşımlarında zorunlu periyodik parola değişimi her zaman önerilmez.

Çünkü kullanıcılar genellikle tahmin edilebilir parola varyasyonları üretir.

Örneğin:

Password1!Password2!Password3!

Bu durum güvenliği artırmak yerine zayıflatabilir.

Öneri: Compliance zorunluluğu yoksa bu alan boş bırakılabilir. Bunun yerine MFA güçlü parola politikası, sızdırılmış parola kontrolü ve hesap kilitleme mekanizmasına odaklanmak daha etkilidir.

6) Disable User After Attempts

Bu alan başarısız giriş denemelerinden sonra hesabın kilitlenmesini sağlar. Boş bırakılması ciddi bir güvenlik zafiyetidir çünkü sınırsız parola denemesine izin verebilir.

Öneri: Production ortamlarında mutlaka etkinleştirilmelidir. Standart kurumsal yapılarda 5 başarısız deneme, yüksek güvenlikli ortamlarda 3 başarısız deneme uygun olabilir.

Bu alanın boş bırakılması sınırsız brute-force denemesine açık olduğunuz anlamına gelir. 

Bir saldırgan otomatik araçlarla milyonlarca parolayı sırayla deneyebilir ve hesap hiçbir zaman kilitlenmez. 

Production ortamında bu alanın boş kalmaması bir tercih değil, bir zorunluluktur.

Risk Profili	Önerilen Deneme Sayısı
Yüksek güvenlik (finans, kritik altyapı)	3 deneme
Standart kurumsal	5 deneme
Internal / Lab	10 deneme

7) Send Warning Email Before Deactivating

Bu ayar uzun süre giriş yapmayan kullanıcıların hesapları devre dışı bırakılmadan önce uyarı e-postası gönderilmesini sağlar. Özellikle dormant account yönetimi için önemlidir.

Dormant hesaplar güvenlik riski oluşturur. Kurumdan ayrılmış, görev değiştirmiş veya uzun süredir kullanılmayan hesaplar saldırganlar için hedef olabilir.

Öneri: Production ortamlarında şu yapı mantıklıdır:

Disable User if Inactive For: 90 DaysSend Warning Email Before Deactivating: 7 Days

Ana kural şudur:

Warning Days < Disable Days

Yani kullanıcıya hesap devre dışı bırakılmadan makul bir süre önce uyarı gönderilmelidir.

Önerilen Standart Yapılandırma (Production)

Disable User if Inactive For: 90 Days Send Warning Email Before Deactivating: 7 Days

Yüksek Güvenlik Yapılandırması

Disable User if Inactive For: 45 Days Send Warning Email Before Deactivating: 7 Days

MSP / Service Provider Yapılandırması

Disable User if Inactive For: 60 Days Send Warning Email Before Deactivating: 14 Days

Mantıklı bir ilişki şart
Warning Days, Disable Days değerinden mutlaka küçük olmalıdır. 
"Disable: 30 gün, Warning: 30 gün" yapılandırması, uyarı geldiğinde zaten geç kalındığı anlamına gelir. "Disable: 30 gün, Warning: 60 gün" ise mantıksızdır  kullanıcı henüz dormant değilken uyarı tetiklenir. 

Temel kural basittir: Warning < Disable

Uyarı e-postasının kalitesi de çok önemlidir. Kullanıcıya net olarak şunları söylemelidir. hesabın hangi tarihte deaktive edileceği, hangi tarihten beri giriş yapmadığı, deaktivasyonu engellemek için ne yapması gerektiği ve sorularını kime iletebileceği. İyi yazılmış bir uyarı e-postası, help desk yükünü ciddi şekilde azaltır.

D) Email Settings

Email Settings, Morpheus’un SMTP yapılandırmasını içerir. Sistem bildirimleri, parola sıfırlama e-postaları, kullanıcı onayları, alarm bildirimleri, incident mesajları ve dormant account uyarıları bu yapılandırmaya bağlıdır.

SMTP yapılandırması yapılmamış veya hatalı yapılmış bir Morpheus ortamında operasyonel iletişim ciddi şekilde aksayabilir.

1) From Address

E-postaların hangi adresten gönderileceğini belirler. Varsayılan değer info@gomorpheus.com‘dur ve bu fabrika ayarıdır.

Production’da mutlaka kendi domain’inizden bir adres kullanın aksi takdirde e-postalar SPF/DKIM doğrulamasından geçemez ve spam klasörüne düşer.

Tipik bir kurumsal yapılandırma: morpheus@sirket.com veya no-reply-morpheus@sirket.com gibi servis hesabı adresleri.

Öneri: Kurumsal bir adres kullanılmalıdır. Örneğin:

morpheus@company.comcloud-platform@company.comno-reply-morpheus@company.com

Bu adres için SPF, DKIM ve DMARC kayıtlarının doğru yapılandırılması da önemlidir.

2) SMTP Server ve SMTP Port

SMTP Server, e-postaların gönderileceği sunucuyu belirtir. SMTP Port ise ilgili servisin dinlediği porttur.

Yaygın kullanım:

Port 25: Internal relay
Port 465: SSL SMTP
Port 587: STARTTLS SMTP

Öneri: Modern yapılarda genellikle 587 portu ve TLS Encryption tercih edilmelidir.

3) SSL Enabled ve TLS Encryption

SSL Enabled, bağlantının doğrudan SSL ile kurulmasını sağlar. TLS Encryption ise STARTTLS mantığıyla bağlantının sonradan şifrelenmesini sağlar.

Microsoft 365, SendGrid ve birçok modern SMTP servisi için yaygın kullanım:

SSL Enabled: OFF
TLS Encryption: ON
Port: 587

Öneri: SMTP trafiği şifresiz bırakılmamalıdır. Kurumsal SMTP relay kullanılsa bile mümkünse TLS etkinleştirilmelidir.

SSL Enabled (implicit SSL), bağlantının baştan şifreli kurulmasını sağlar port 465. TLS Encryption (STARTTLS / explicit TLS) ise bağlantı önce plain text başlar, sonra TLS'e yükseltilir port 587. Modern best practice: 587 + TLS Encryption kombinasyonudur.

4) SMTP User ve SMTP Password

SMTP kimlik doğrulaması gerekiyorsa bu alanlar doldurulur. Cloud tabanlı SMTP sağlayıcılarında çoğunlukla kullanıcı adı ve app password veya API key kullanılır.

Öneri: SMTP parolası kişisel kullanıcı hesabına ait olmamalıdır. Servis hesabı veya uygulama parolası kullanılmalıdır. Mümkünse parola rotasyonu uygulanmalıdır.

Yaygın Senaryolar İçin Hazır Yapılandırmalar

Senaryo 1: Internal Exchange Relay

From Address: morpheus@company.local 
SMTP Server:  smtp-relay.company.local 
SMTP Port:    587 
SSL Enabled:  OFF TLS 
Encryption: ON 
SMTP User:    morpheus-svc@company.local 
SMTP Password: [Güçlü parola — Vault'tan]

Senaryo 2: Microsoft 365

From Address: morpheus@company.com
SMTP Server:  smtp.office365.com
SMTP Port:    587
SSL Enabled:  OFF
TLS Encryption: ON
SMTP User:    morpheus@company.com
SMTP Password: [App Password — MFA hesabı için]

Microsoft 365 için kritik not !!!
MFA aktif hesaplarda doğrudan parola çalışmaz. Microsoft 365 admin panelinden App Password üretmeniz ya da OAuth2/Modern Authentication tabanlı bir relay yapısı kurmanız gerekir. Basic Authentication Microsoft tarafından deprecate edilmiştir.

Senaryo 3: SendGrid (Cloud Native)

From Address: morpheus@company.com
SMTP Server:  smtp.sendgrid.net
SMTP Port:    587
SSL Enabled:  OFF
TLS Encryption: ON
SMTP User:    apikey   (literal olarak "apikey" yazılır)
SMTP Password: [SendGrid API Key]

E-posta Gitmiyorsa Sorun Giderilmesi

SMTP yapılandırması doğru görünmesine rağmen e-posta gitmiyorsa, sorun giderme akışı genellikle üç adımdan oluşur:

1) Morpheus Loglarına Bakılması

# UI logları tail -f /var/log/morpheus/morpheus-ui/current   # Aranacak hata anahtar kelimeleri   – “SMTP”   – “MailService”   – “Authentication failed”   – “Connection refused”   – “SSL handshake”

2) Network Erişimini Test Edilmesi

# Appliance’tan SMTP sunucusuna port testi telnet smtp-relay.onecloudlab.local 587 nc -zv smtp.office365.com 587

3) DNS Çözümlemesini Doğrulanması

nslookup smtp.office365.com dig smtp-relay.onecloudlab.local

Çoğu durumda sorun ya bir firewall kuralının 587 portunu engellemesidir ya da kimlik doğrulama bilgilerinin (özellikle Microsoft 365’te App Password kullanılmadığı için) reddedilmesidir.

E) Twilio SMS Settings

Twilio SMS Settings, Morpheus’un SMS tabanlı bildirim gönderebilmesini sağlar. Kritik incident, alarm veya operasyonel uyarılar için e-posta dışında SMS bildirimi de kullanılabilir.

Twilio, bulut tabanlı bir iletişim platformudur (CPaaS — Communications Platform as a Service). Programatik olarak SMS, MMS, sesli arama, WhatsApp mesajı ve video iletişimi göndermenize olanak tanır. Morpheus tarafında üç alanın doldurulması yeterlidir.

Alan	Açıklama	Nereden Alınır
Account SID	Twilio hesabınızın benzersiz kimliği	Twilio Console → Dashboard
SMS From	Mesajların gönderileceği numara	Twilio’dan satın alınan numara
Auth Token	API kimlik doğrulama anahtarı	Twilio Console → Account Info

1) Account SID

Twilio hesabının benzersiz kimliğidir. Twilio Console üzerinden alınır.

2) SMS From

SMS’in hangi telefon numarasından gönderileceğini belirtir. Dokümandaki 5555555555 değeri örnek veya placeholder değerdir.

3) Auth Token

Twilio API erişimi için kullanılan gizli token’dır.

Öneri: Auth Token hassas bilgi olarak ele alınmalıdır. Yetkisiz kişilerle paylaşılmamalı, düzenli olarak rotate edilmeli ve mümkünse secret management yaklaşımıyla korunmalıdır.

SMS bildirimleri özellikle kritik sistemlerde faydalıdır ancak her alarm için SMS göndermek kullanıcıları yorabilir. Bu nedenle yalnızca yüksek öncelikli olaylar için SMS tercih edilmelidir.

Tüm alarmları SMS'e yönlendirmek, kullanıcıları kısa sürede bildirim yorgunluğuna sürükler ve gerçek kritik durumlarda tepki verilmemesine yol açar. 

SMS'i yalnızca P1/critical seviyedeki olaylar için (production down, kritik kapasite eşiği, güvenlik ihlali) kullanın. Geri kalanı için e-posta veya Slack/Teams entegrasyonu yeterlidir.

F) Proxy Settings

Morpheus’un dış dünyaya yaptığı tüm outbound (giden) trafiği için kullanacağı proxy yapılandırmasını içerir. Kurumsal ortamlarda, özellikle internet erişiminin merkezi proxy üzerinden geçtiği yapılarda kritik bir sekmedir. Yanlış yapılandırma, plugin güncellemelerinden cloud provider entegrasyonlarına kadar her şeyi sessizce kırabilir.

1) Temel Alanlar

Alan	Anlamı
Proxy Host	Proxy sunucusunun adresi (IP veya FQDN)
Proxy Port	Proxy’nin dinlediği port (genelde 3128, 8080)
Proxy User	Kimlik doğrulama için kullanıcı adı
Proxy Password	Kimlik doğrulama parolası
Proxy Domain	NTLM authentication için Windows domain adı
Proxy Workstation	NTLM için workstation/computer adı

2) NTLM Authentication Notu

Proxy Domain ve Proxy Workstation alanları yalnızca NTLM authentication kullanan proxy’ler içindir. Modern kurumsal ortamlarda genellikle basic authentication veya Kerberos tercih edilse de hâlâ NTLM proxy’leri kullanan ortamlar vardır. Workstation alanı, NTLM protokolüne client identity bildirmek için kullanılır ve audit/logging amaçlı önemlidir.

3) No Proxy — En Sık Atlanan Alan

Bu alan ihmal edilirse… Morpheus’un kendi iç servisleri ve internal network kaynakları için proxy’yi bypass etmesi gerekir. Aksi takdirde appliance kendi worker node’larına ya da iç DNS sunucularına dahi proxy üzerinden ulaşmaya çalışır. Sonuç: timeout’lar, gecikmeler ve anlaşılması güç bağlantı hataları.

No Proxy alanına eklenmesi gereken tipik adresler:

• Localhost ve loopback: localhost, 127.0.0.1
• İç domain’ler: *.sirket.local, *.internal.sirket.com
• İç IP bloğu: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12
• Morpheus worker’ları ve veritabanı sunucuları (varsa)
• İç cloud entegrasyon endpoint’leri (vCenter, internal API’ler)

Örnek bir No Proxy değeri:

localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12, 192.168.0.0/16,.sirket.local,vcenter01.sirket.local

G) Currency Settings

Currency Settings, Morpheus’un döviz kuru entegrasyonlarını yönetir. Multi-cloud ve multi-currency ortamlarda maliyet yönetimi için önemli bir bölümdür.

Kurumsal yapılarda farklı platformlardan gelen maliyetler farklı para birimlerinde olabilir. Örneğin AWS faturası USD, Azure faturası EUR, yerel veri merkezi maliyetleri TRY olabilir. Ancak finans departmanı tüm maliyetleri TRY cinsinden görmek isteyebilir.

Multi-Currency Neden Gerekli?

Tipik bir kurumsal senaryo şöyle görünür: AWS’de aylık $50.000 maliyet, Azure’da €18.000 maliyet, on-premise VMware envanterinde aylık 2.500.000 TL operasyonel maliyet. Yıllık bütçe TL cinsinden yapılıyor, ancak fatura kaynakları farklı para birimlerinde. Currency provider entegrasyonu olmadan her ay manuel dönüşüm yapmak hem hatalı hem de denetlenebilirliği zayıf bir süreçtir.

Morpheus otomatik döviz kuru güncellemesi ile bu sorunu çözer. Bir currency provider seçildiğinde, sistem belirlenen sıklıkta API üzerinden güncel kurları çeker ve tüm cost raporlarında otomatik dönüşüm uygular.

Currency Provider

Currency Provider, döviz kuru verisinin hangi harici sağlayıcıdan alınacağını belirler. Open Exchange Rates veya Fixer.io gibi servisler kullanılabilir.

Provider API Key

Seçilen currency provider API’sine erişim için gereken anahtardır.

Öneri: Currency provider seçimi yapılırken API limitleri, güncelleme sıklığı, desteklenen para birimleri ve güvenilirlik değerlendirilmelidir. Finansal raporlama için kullanılan kurların hangi kaynaktan geldiği dokümante edilmelidir.

API rate limit'lere dikkat
Ücretsiz tier'ların çoğunda aylık veya günlük çağrı limiti vardır (örneğin Open Exchange Rates ücretsiz planı genellikle ayda 1000 çağrıyla sınırlıdır). 

Morpheus varsayılan sync sıklığında bu limit yeterlidir, ancak çoklu currency takibi yapıyorsanız plan yükseltmeyi değerlendirin.

H) Enabled Clouds

Enabled Clouds bölümü Morpheus üzerinde hangi cloud veya hypervisor platformlarının kullanıcı arayüzünde görünür olacağını belirler.

Morpheus çok sayıda cloud ve sanallaştırma platformunu destekler. Ancak kurum tüm bu platformları kullanmıyorsa, Add Cloud menüsünde gereksiz seçeneklerin görünmesi kullanıcı deneyimini zorlaştırabilir.

Öneri: Yalnızca kurumda gerçekten kullanılan veya kullanılmasına izin verilen cloud türleri etkin bırakılmalıdır. Bu yaklaşım hem operasyonel karmaşıklığı azaltır hem de kullanıcıların yanlış platform ekleme riskini düşürür.

Örneğin yalnızca VMware, Azure ve Kubernetes kullanılan bir ortamda diğer cloud türleri gizlenebilir.

Pratik UX kazancı
VMware ve AWS dışında bir şey kullanmıyorsanız kullanıcılarınıza her cloud ekleme ekranında 24 seçenek arasında "VMware"ı aratmanın bir faydası yok. 

Yalnızca aktif kullanılan cloud'ları enable ederek arayüzü ciddi şekilde sadeleştirir ve yanlış cloud türü seçilmesinden kaynaklanan hataları engellersiniz.

HPE Morpheus Enterprise Administration Settings ekranı platformun yalnızca temel davranışlarını değil, aynı zamanda güvenlik duruşunu, operasyonel verimliliğini, entegrasyon kabiliyetlerini ve kullanıcı deneyimini belirleyen merkezi bir yapılandırma alanıdır.

Bu ayarların “varsayılan değerlerle bırakılması” özellikle production ortamlarında doğru bir yaklaşım değildir. Her kurumun güvenlik politikası, network mimarisi, kullanıcı yönetimi modeli, cloud stratejisi ve compliance gereksinimleri farklıdır. Bu nedenle Morpheus appliance yapılandırması da bu ihtiyaçlara göre bilinçli şekilde uyarlanmalıdır.

Doğru yapılandırılmış bir Morpheus ortamı daha güvenli agent iletişimi, daha kontrollü tenant yönetimi, daha etkili kullanıcı politikaları, sağlıklı bildirim mekanizmaları, optimize edilmiş cloud senkronizasyonu ve daha doğru maliyet raporlaması sağlar.