Ajanslar İçin Hosting Paneli Erişim Yönetimi

Ajanslar İçin Hosting Paneli Erişim Yönetimi Neden Bu Kadar Önemli?

Ajans tarafında iş yükü büyüdükçe asıl zorluk çoğu zaman CPU, RAM ya da disk değil; erişim yönetimi oluyor. Farklı müşteriler, onlarca domain, WordPress kurulumu, FTP/SFTP hesapları, cPanel/DirectAdmin oturumları, DNS panelleri… Bir noktadan sonra “Kim, nereye, hangi şifreyle giriyor?” sorusu cevaplanamaz hale geliyorsa, hem güvenlik hem de operasyonel verimlilik ciddi risk altında demektir.

Bu yazıda ajanslar için hosting paneli erişim yönetimini, hesap ayrıştırma ve yetki sınırlandırma ihtiyaçlarından yola çıkarak adım adım ele alacağız. Odak noktamız üç kritik başlık olacak: müşteri hesaplarını mantıklı şekilde ayrıştırmak, doğru yetki seviyelerini tanımlamak ve uygulanabilir şifre/kimlik doğrulama politikaları kurmak. Amacımız; hem ekibinizin rahat çalışabildiği hem de müşterilerinizin verisinin korunduğu, denetlenebilir bir yapı kurmanıza yardım etmek.

Paylaşımlı hosting, reseller, VPS, dedicated ve colocation seçeneklerinde erişim yönetiminin kapsamı, planın sağladığı yetkilere ve sunucunun yönetim sorumluluğuna bağlıdır. Bu rehberde hesap ayrımı, rol dağılımı ve erişim iptali için örnek bir plan oluşturacağız.

Müşteri Hesaplarını Ayrıştırma Stratejileri

Tek Hosting Hesabında Tüm Müşteriler: Kolaylık ve Riskler

Bir ajansın başlangıçta “Hepsini tek cPanel hesabında toplayalım, hem kolay yönetiriz hem de maliyet düşük olur” yaklaşımını seçtiğini düşünelim. İlk 3–5 müşteri için bu pratik gelebilir; ancak müşteri sayısı arttıkça şu riskler ortaya çıkabilir:

• Bir müşterinin geliştiricisine verdiğiniz dosya erişimi ilgili proje diziniyle sınırlandırılmamışsa, diğer sitelerin dosyaları da erişilebilir hale gelebilir.
• Bir eklenti veya tema, tüm sitelerin ortak kullandığı bir klasörde tutulmuşsa, tek bir güvenlik açığı tüm portföyü etkileyebiliyor.
• Bir müşterinin sizden ayrılması gerektiğinde “Onun dosyalarını ayıralım” süreci kabusa dönüşüyor.

Özellikle ajans ölçeğiniz büyüdükçe, her müşteriyi ayrı bir hesapta izole etmek hem güvenlik hem de operasyon yönetimi açısından kritik hale geliyor. Bu noktada cPanel’de addon domain mi, ayrı hesap mı kullanmalı? sorusunu teknik ve uzun vadeli bakışla ele almak şart.

Ayrı Hesap Mantığı: cPanel/DirectAdmin’de İzolasyon

cPanel, DirectAdmin gibi panellerde temel prensip basit: Bir müşteri = Bir panel hesabı. Bu yaklaşımın ajanslar için avantajlarını özetleyelim:

• Dosya sistemi izolasyonu: Ayrı hesaplar dosya sahipliğini ve izinleri ayırmayı kolaylaştırır; ayrı /home dizinleri tek başına tam izolasyon garantisi değildir. Koruma, sunucudaki izin ve izolasyon yapılandırmasına bağlıdır.
• Kaynak limitleri: Seçilen altyapının hesap bazında CPU, RAM, IO ve giriş süreçleri (EP) sınırlandırmasını destekleyip desteklemediğini doğrulayın. Uygun limitler yoğun bir müşterinin diğerlerini etkilemesini azaltabilir; ortak sunucu kaynakları nedeniyle bu risk tamamen ortadan kalkmaz.
• Yedekleme yönetimi: Her hesabın ayrı yedeği alınabildiği için geri dönüş operasyonları daha temiz ve kontrollü olur.
• Hesap devri kolaylığı: Müşteri ajans değiştirdiğinde ilgili hesabı paketleyip yeni sağlayıcısına aktarmak çok daha basittir.

Bu yaklaşımı ölçekli şekilde kurgulamak istiyorsanız, reseller mimarisi devreye girer. Burada her müşteriye özel paketler planlayabilirsiniz; disk ve e-posta kotaları ile CPU gibi kaynak limitlerinden hangilerini yönetebileceğiniz, panelin ve seçilen planın yetkilerine bağlıdır. Detaylı mimari örnekler için reseller hosting yönetimi, paket ve izolasyon rehberimizi mutlaka inceleyin.

Reseller Hesapları ile Ajans Mimarisi

Reseller hesabı, ajans gözünden bakınca “mini hosting şirketi” gibidir. Üstte ajansın reseller paneli, altta her müşteri için ayrı cPanel/DirectAdmin hesabı bulunur. Ajans için örnek bir yerleşim şöyle olabilir:

• Küçük siteler (kurumsal tanıtım, blog vb.) için: Reseller hesabı altında birden çok küçük paket.
• Orta ölçekli siteler (e-ticaret, yoğun içerik): Tek müşteriye özel, kaynak limitleri geniş bir paket.
• Kritik performans isteyen projeler için: Ayrı bir VPS veya dedicated sunucu, üzerinde panel + reseller katmanı.

20+ site yöneten bir ajans için reseller + VPS kombinasyonu değerlendirilebilir; en uygun seçenek site sayısından çok trafik, kaynak ihtiyacı, bütçe ve yönetim kapasitesine bağlıdır. Bu yapıda kaynak dağılımı, VPS kapasitesi ve kullanılan limit mekanizmalarıyla sınırlıdır. Örnek topolojiler için ajanslar ve freelancerlar için önerdiğimiz hosting mimarisi rehberini okuyabilirsiniz.

Yetki Seviyeleri: Kim, Neye, Ne Kadar Ulaşmalı?

Ajans İçindeki Roller ve Yetkiler

Erişim yönetimindeki risklerden biri, herkese “full erişim” vermektir. Yetki planında şu roller ayrı ayrı değerlendirilebilir:

• Ajans sahibi / operasyon yöneticisi: Hesap envanteri ve erişim onaylarını yönetebilir; bu sorumluluk tek başına tüm müşteri hesaplarında teknik yönetici yetkisi gerektirmez.
• Kıdemli geliştirici / DevOps: Sunucu, panel, SSH, DNS ve SSL yetkileri yalnızca sorumlu olduğu projeler ve işlemler için tanımlanmalı.
• Frontend geliştirici / içerik yöneticisi: Frontend geliştiriciye gerekiyorsa proje diziniyle sınırlı dosya erişimi verin. Yalnızca içerik düzenleyen kullanıcıya ise görevine uygun WordPress rolü tanımlayın; dosya erişimini varsayılan olarak eklemeyin.
• Freelancer / dış kaynak ekip: Zaman sınırlı, proje bazlı ve minimum gerekli yetki ile erişim verilmeli.
• Müşteri tarafı IT veya pazarlama ekibi: WordPress, e-posta veya DNS kaydı düzenleme yetkilerini görev ihtiyacına göre ayrı değerlendirin; tümünü birlikte vermeyin.

Bu rollerin hepsine aynı panel şifresini verirseniz, hem loglardaki işlemleri kişilere güvenilir biçimde bağlamak hem de bir ihlal durumunda sorumluluğu tespit etmek zorlaşır. Temel ilke şu olmalı: “İşini yapmak için gereken minimum yetki”.

Panel ve Alt Kullanıcı Yönetimi

Tek panel şifresini paylaşmak yerine, seçtiğiniz panel ve planın desteklediği ayrı kullanıcı ve yetki mekanizmalarını değerlendirin. Erişim tasarımında şu ayrımları kullanabilirsiniz:

• Reseller yönetici erişimi: Müşteri hesapları üzerinde geniş yetki sağlayan bu erişimi az sayıda yetkiliyle sınırlayın; destekleniyorsa her yöneticiye ayrı kimlik tanımlayın.
• Müşteri bazlı panel hesapları: Her müşteri için ayrı cPanel/DirectAdmin hesabı oluşturun. Ekip erişimini panel destekliyorsa kişiye özel alt kullanıcılarla, desteklemiyorsa görev için yeterli ayrı servis hesaplarıyla sağlayın; ana panel şifresini paylaşmayı varsayılan yöntem yapmayın.
• Dosya aktarım kullanıcıları: Her site için ayrı bir otomasyon (“deploy”) hesabı, insanlar için kişiye özel erişim planlayın. Şifreli aktarım kullanın; SFTP veya FTPS desteğini ve dizin kısıtlarının uygulanabildiğini doğrulayın.
• Veritabanı kullanıcıları: Her uygulama için ayrı DB user; tüm veritabanlarını gören “root benzeri” kullanıcıları minimumda tutmak.

cPanel tarafında ekstra güvenlik ve rol bazlı ayarlar için cPanel güvenlik sertleştirme kontrol listemizi incelemenizi öneririz. Oradaki öneriler, ajans seviyesinde erişim yönetimi kurarken de doğrudan işinize yarar.

Geçici ve Denetimli Erişim Yönetimi

Ajansların günlük hayatında sık yaşanan bir durum: “Müşterinin kendi yazılımcısı kısa süreliğine sunucuya erişip bir şeyler düzenleyecek.” Bu durumda izlenecek en sağlıklı yol genelde şu:

1. Altyapı destekliyorsa ilgili müşteri için ayrı bir SFTP kullanıcısı oluşturun; erişimi proje diziniyle sınırlandırın ve diğer dizinlere erişemediğini doğrulayın. Bu kısıtlama sağlanamıyorsa ana hesap bilgilerini paylaşmak yerine desteklenen kısıtlı bir aktarım yöntemi seçin.
2. Erişim için bir bitiş tarihi ve iptal sorumlusu belirleyin. Otomatik süre sonu destekleniyorsa kullanın; aksi halde takvim kaydı oluşturup o tarihte erişimi elle kapatın.
3. Eğer SSH gerekiyorsa, kullanıcıdan yalnızca açık anahtarını isteyin; özel anahtarını istemeyin. Anahtarla doğrulama tek başına komutları kısıtlamaz; gerekli komutlarla sınırlı erişimi ayrıca yapılandırıp doğrulayın.
4. İş bittiğinde kullanıcı erişimini ve ona tanımlanan SSH anahtarı yetkilerini kaldırın, açık oturumları sonlandırın ve erişim loglarını gözden geçirin.

Bu pratik, hem müşterinin geliştiricisine esneklik sağlar hem de ajansın kontrolü elinde tutmasını mümkün kılar. Yönetici yetkinizin bulunduğu bir Linux VPS veya dedicated sunucuda, ayrı kullanıcıların dosya izinlerini grup bazlı izinler ile, gerekli ayrıcalıklı işlemleri ise dar kapsamlı sudo yetkileriyle düzenleyebilirsiniz.

Şifre ve Kimlik Doğrulama Politikaları

Güçlü Şifre Kuralları Nasıl Olmalı?

Zayıf veya tekrar kullanılan şifreler, hesapların ele geçirilmesi riskini artırır. Ajans içinde uygulanabilir bir şifre politikası için şu kriterleri en azından standart haline getirin:

• Uzunluk: Hosting paneli ve sunucu girişleri için rastgele parola üreteciyle oluşturulmuş en az 16 karakterlik parolaları ekip standardı olarak hedefleyin.
• Çeşitlilik: Büyük/küçük harf, rakam ve özel karakter kombinasyonu.
• Tekrar kullanmama: Aynı şifreyi hem hosting paneli hem e-posta hem de başka SaaS araçlarda kullanmamak.
• Yenileme: Sızıntı veya ele geçirilme şüphesinde şifreyi hemen değiştirin. Ayrılan bir çalışanın bildiği ortak şifreleri de yenileyin; takvime bağlı değişimi tek başına güvenlik önlemi saymayın.

Şirket içinde “şifre listesi” olarak tutulan Excel/Google Sheet dökümanlarını tamamen hayatınızdan çıkarmaya çalışın. Bunun yerine kurumsal bir parola yöneticisi kullanmak çok daha güvenli ve sürdürülebilir olacaktır.

Şifre Paylaşmama ve Rol Bazlı Hesap Kullanımı

Ajanslarda erişim yönetimini zayıflatan bir uygulama, tek bir cPanel kullanıcı adı/şifresinin tüm ekip ve hatta bazı müşterilerle paylaşılmasıdır. Bu durumda:

• Loglarda işlemi yapan kişiyi yalnızca ortak kullanıcı adına bakarak güvenilir biçimde ayırt edemezsiniz.
• Ekibinizden biri ayrıldığında şifre değişimi unutulursa, eski çalışan hâlâ bu hesabın yetkili olduğu müşterilere erişebilir.
• Bir şifre sızdığında, o hesabın erişebildiği tüm siteler risk altına girer; hesap tüm portföyü kapsıyorsa risk de portföyün tamamına yayılır.

Bu yüzden prensip şu olmalı: Hesap paylaştırmak yerine, rol bazlı yeni hesap açın. Örneğin; altyapı destekliyorsa her geliştirici için proje dizinleriyle sınırlı ayrı SFTP hesabı, her müşteri için ayrı panel hesabı, müşterinin farklı departmanları için görevlerine uygun yetkilerle ayrı WordPress kullanıcıları. Böylece hem güvenlik hem de denetlenebilirlik artar.

İki Faktörlü Doğrulama (2FA), IP Kısıtlama ve Sunucu Güvenliği

Şifreler ne kadar güçlü olursa olsun, phishing (oltalama) saldırılarıyla ele geçirilebilir. Bu nedenle kritik panellerde iki faktörlü doğrulama (2FA) zorunlu hale gelmeli. Mümkün olan her yerde aşağıdaki önlemleri devreye almanızı öneririz:

• Kritik cPanel/DirectAdmin oturumları için 2FA desteğini plan seçiminde doğrulayın ve desteklenen doğrulama yöntemini etkinleştirin. Zaman bazlı tek seferlik kodlar kullanılabilir; bunları oltalamaya karşı mutlak koruma olarak görmeyin. Kurtarma bilgilerini güvenli saklayın ve hesap kurtarma sorumlusunu belirleyin.
• SSH erişiminde kişiye özel anahtar kullanın; özel anahtarları koruyun. Anahtarla girişin ve acil durum erişiminin çalıştığını doğrulamadan parola ile girişi kapatmayın. SSH anahtarı kullanımı tek başına 2FA değildir.
• Panel ve altyapı destekliyorsa yönetim erişimini güvenilir IP’lerle sınırlayın; değişen IP’ler ve acil durumlar için kontrollü bir erişim yolu planlayın.
• Sunucu yönetim yetkiniz varsa güvenlik duvarında yalnızca gerekli portlara izin verin; bu yetki sağlayıcıdaysa gerekli kuralları onunla netleştirin. Değişikliklerden sonra gerekli servislerin ve yönetim erişiminin çalıştığını doğrulayın.

VPS ve dedicated sunucularda, bu ayarların nasıl yapılacağına dair detaylı pratikler için VPS sunucu güvenliği rehberimizi inceleyebilirsiniz. Yeni açılan projelerinizde temel güvenlik ayarlarını atlamamak adına da yeni web siteleri için hazırladığımız güvenlik check-list’ine göz atmanız faydalı olacaktır.

Ajans İş Akışında Erişim Yönetimi: Adım Adım Plan

1. Yeni Müşteri Onboarding Süreci

Yeni müşteri kabulünde erişim planını son ana bırakmak yerine standart bir onboarding şablonu kullanın. Önerilen adımlar:

1. Müşterinin mevcut altyapısını analiz edin: Domain nerede, DNS kimde, hosting kimin üzerinde?
2. Bu müşteri için ayrı bir hosting hesabı veya gerekiyorsa VPS/dedicated sunucu planlayın; seçilen planın gerekli hesap ayrımını, kişiye özel erişimi ve kritik panellerde 2FA’yı desteklediğini doğrulayın.
3. Müşteri adına açılan panel hesabı için güçlü bir şifre belirleyin ve 2FA’yı aktif edin. Kurtarma bilgilerini güvenli saklayın; hesap sahipliğini ve kurtarma sorumlusunu kaydedin.
4. Ajans içinden bu projede çalışacak kişilere, sadece ihtiyaç duydukları seviyede erişim tanımlayın.

DNS tarafındaki erişim planı da bu aşamada netleştirilmeli. Bu konuda daha ileri seviye yaklaşım arıyorsanız, ajanslar için DNS ve alan adı erişimi yönetimi rehberimizi uygulama rehberi olarak kullanabilirsiniz.

2. Proje Devam Ederken Erişim Yönetimi

Proje üretim ve bakım sürecine girdiğinde, erişim yönetimini “ya bir ara düzeltiriz” diye düşünmek yerine, küçük ama disiplinli adımlarla sürdürmek gerekir:

• Her yeni geliştirici veya içerikçi için, ortak şifre vermek yerine yeni hesap açın.
• Geçici çalışanlar için erişim bitiş tarihini proje takvimine not alın ve bu tarihte erişimi kaldıracak sorumluyu belirleyin.
• 3–6 ayda bir, hangi hesabın gerçekten aktif kullanıldığını gözden geçirin, gereksizleri kapatın.
• Kritik değişikliklerde (PHP sürümü değişimi, HTTP güvenlik başlıkları, SSL yenileme gibi) mutlaka kısa bir değişiklik notu tutun.

Bu yaklaşım, ileride çıkabilecek performans veya güvenlik sorunlarında “kim neyi, ne zaman değiştirdi?” sorusuna çok daha çabuk cevap bulmanızı sağlar.

3. Müşteri Ayrılışı (Offboarding) ve Hesap Devri

Müşteri ajans değiştirdiğinde veya projeyi kendi içinde sürdürmek istediğinde, baştan kurulmuş bir erişim planı devri kolaylaştırabilir. Önerilen offboarding adımları:

1. Önce devrin kapsamını belirleyin: Ajansın yönetim sorumluluğu tamamen mi bitecek, yoksa onaylı destek devam mı edecek? Müşteri hesabına ulaşabilen reseller, sunucu yöneticisi/root ve sağlayıcı yönetim yetkilerini envantere alın. Panel parolasını ve 2FA kaydını değiştirmek üst düzey yetkileri kendiliğinden kaldırmaz. Örneğin cPanel’de ilgili yetki verilmiş bir reseller, sahibi olduğu hesapların parolalarını değiştirebilir.
2. Tam ayrılışta hesabı ajansın reseller sahipliği ve yönetim kapsamından çıkarın. Ajans sunucuda yönetici/root yetkisini koruyorsa yalnızca reseller sahipliğini değiştirmek yeterli değildir; hesabı ajansın yönetmediği bağımsız bir altyapıya taşıyın veya ajansın ilgili üst yönetim yetkilerini de sonlandırın. Sağlayıcıyla birlikte kalan erişim yollarını doğrulayın. Yönetim devam edecekse kalan üst yetkilerin kapsamını, sorumlusunu, süresini ve iptal koşullarını müşterinin onayıyla belgeleyin.
3. İlgili hesabın sahipliğini ve panel erişimini müşterinin yetkilendirdiği kişiye güvenli bir kanaldan devredin. Yeni yetkilinin parolayı, 2FA kaydını ve kurtarma bilgilerini yenilemesini; eski oturumların sonlandırılmasını sağlayın.
4. Devredilen müşteriye ait sistemlerde ajansın panel/SFTP/SSH/WordPress erişimlerini kaldırın; ilgili SSH anahtarlarını ve API belirteçlerini de iptal edin. Devam eden destek için yalnızca müşterinin onayladığı, kapsamı ve süresi belirli ayrı erişimler bırakın. Devrin sonunda doğrudan hesap erişimlerinin yanı sıra reseller ve sunucu yönetici erişimlerinin de kararlaştırılan kapsamda sonlandırıldığını veya belgelendiğini kontrol edin.
5. Müşteriyle aranızdaki sözleşmeye uygun şekilde, log ve yedek saklama sürelerini netleştirin.
6. DNS ve alan adı erişimlerini, ajans taahhütleri bittikten sonra müşteriye veya yeni ajansa devredin.

Başından itibaren her müşteriyi ayrı hesap ve net yetkilerle yönetmeniz, hesap devrini ve sorumlulukların belgelenmesini kolaylaştırır; hukuki yükümlülüklerin yerine getirilmesi ayrıca değerlendirilmelidir.

Ajanslar İçin Örnek Erişim Mimarileri

Senaryo 1: 10–15 Siteli Kreatif Ajans

Birkaç kurumsal site, birkaç blog ve düşük trafikli bazı kampanya mikrositeleri yöneten bir kreatif ajans düşünelim. Bu yapı için, seçilen hizmetin gerekli panel ve yetkilendirme özelliklerini desteklemesi koşuluyla değerlendirilebilecek örnek mimari:

• 1 adet reseller hesabı (üstte ajans yönetimi).
• Her müşteri için ayrı cPanel/DirectAdmin hesabı.
• Her hesaba özel, sınırları net disk ve trafik limitleri.
• Gerekirse kritik projeler için ayrı PHP sürümü ayarları; her proje için uygulamayla uyumlu ve güvenlik desteği devam eden bir sürüm seçmek.

Bu yapıda ajans, reseller panelinden tüm müşterileri görebilir; ancak her müşteri kendi paneline, kendi kullanıcı bilgileriyle girebilir. Ajans içindeki ekibe ise yalnızca üzerinde çalıştığı projeler için kişiye özel, sınırlı erişim tanımlanır; ortak panel veya SFTP parolası dağıtılmaz. Bu mimariye ek olarak, çoklu PHP sürümü yönetimi rehberimizdeki ayarları, kullanılan panelin ve planın desteklediği ölçüde uygulayarak her müşteri için uyumlu ve güvenlik desteği devam eden sürümü seçebilirsiniz.

Senaryo 2: 50+ Siteli Performans ve SEO Ajansı

Çok sayıda WordPress ve e-ticaret sitesi yöneten bir ajans için kaynak yönetimi ve performans da erişim güvenliğiyle birlikte planlanmalıdır. Trafik, kaynak ihtiyacı ve sunucu yönetim kapasitesine göre değerlendirilebilecek örnek bir yaklaşım:

• 1 veya daha fazla güçlü VPS / dedicated sunucu (proje yoğunluğuna göre).
• Her sunucuda bir kontrol paneli ve onun üzerinde ajansa özel reseller katmanı.
• Yüksek trafik alan veya çok kaynak tüketen siteler için ayrı VPS’ler.
• Geliştirme/staging ortamlarını üretimden ayıran özel hesaplar.

Bu senaryoda, ajansın DevOps tarafı sunucu seviyesindeki ayarları (PHP-FPM, veritabanı optimizasyonu, önbellekleme, HTTP güvenlik başlıkları vb.) merkezi olarak yönetirken, proje ekiplerinin erişimleri yalnızca kendi panel ve uygulama alanlarıyla sınırlandırılır. Bu ayrım, performans ve güvenlik yönetimini destekler; sonuçlar kaynak boyutlandırmasına ve yetkilerin doğru uygulanmasına da bağlıdır.

Senaryo 3: KVKK ve Regülasyon Hassasiyeti Olan Müşteriler

Hukuk büroları, sağlık sektörü, finans ve kamu projeleri gibi regülasyon hassasiyeti yüksek müşterilerde erişim yönetimi standartlarınızı bir kademe daha sertleştirmeniz gerekecektir. Örneğin:

• Bu müşteriler için fiziksel veya mantıksal olarak ayrılmış sunucular (VPS/dedicated) kullanmak.
• SSH erişimini sadece ajansın çekirdek teknik ekibi ile sınırlamak.
• 2FA’sız panel erişimini tamamen yasaklamak.
• Log saklama sürelerini sözleşmelere ve regülasyonlara uygun şekilde belirlemek.

Bu müşterilerde erişim kontrollerini ağ ve veri merkezi katmanındaki önlemlerle birlikte değerlendirin. Hizmet seçerken sorumluluk dağılımını, veri konumunu ve log/yedek saklama koşullarını belgeleyin. Bu teknik önlemler tek başına KVKK veya sektörel mevzuata uyum sağlamaz; yükümlülükleri proje özelinde değerlendirmek gerekir.

Sonuç: Ajanslarda Denetlenebilir Erişim Yönetimi

Tüm müşterilere aynı kimlik bilgileriyle erişilmesi ve işlemlerin kişilere atfedilememesi, hem itibar hem de iş sürekliliği açısından risk yaratır. Erişim yönetimi bu nedenle proje sonunda değil, müşteri kabulünde başlamalıdır.

Bu rehberde, ajanslar için hosting paneli erişim yönetimini üç ana eksende ele aldık: müşteri hesaplarını ayrıştırma, rol bazlı yetki seviyeleri ve güçlü şifre/2FA politikaları. Bu kontroller, seçilen altyapıda doğru uygulanıp düzenli gözden geçirildiğinde güvenliği ve denetlenebilirliği destekler. Müşteri devrinde ise yalnızca kullanıcı hesaplarını değil, ajansın reseller ve sunucu yönetici yetkilerini de ayrılış kapsamına göre sonlandırmak veya onaylı biçimde belgelemek gerekir.

Uygulamaya başlamak için mevcut müşteri hesaplarını, bu hesaplara erişen kişileri ve yetkilerini envantere alın. Ardından hesap ayrımı, 2FA ve erişim iptali ihtiyaçlarını seçilecek hizmetin özellikleriyle karşılaştırın; sunucu yönetimi ile ajans içi yetkilendirmeden kimin sorumlu olacağını yazılı olarak belirleyin.