İş Arkadaşına Hosting Erişimi; Neyi Verelim, Neyi Vermeyelim

Site yöneticisisiniz ve geliştiriciye veya iş arkadaşınıza erişim mi vermeniz gerekiyor? Bu rehber, hangi erişimin gerekli olduğunu, hangisini vermemeniz gerektiğini ve nasıl geri alacağınızı anlatır.

8 dk Güncellendi 7 Sep 2026

İş Arkadaşı Erişimi; Site Güvenliğinin Ekip Hızıyla Kesiştiği Nokta

İşe aldığınız geliştirici "İşe başlamak için cPanel kullanıcı adını ve şifresini ver" diyor. Sitenin önceki yöneticisi de gitmiş ve size hosting'den sadece içinde root şifresi veya kontrol paneline tam erişim olan bir karşılama e-postası bırakmış. Siz bir kararla baş başa kaldınız: Anahtarı vereyim mi, vermeyeyim mi?

Kısa cevap: Hayır. Asla. Ama bu, ekibin işinin duracağı anlamına gelmez. Bir geliştiricinin veya iş arkadaşının yapmak isteyeceği hemen her iş, sınırlı ve geri alınabilir bir erişimle yapılabilir. Sadece hangi erişimin hangi iş için olduğunu ve her seçimin maliyetini bilmeniz gerekir.

Bu makale, şu anda ekranın başında oturan ve bir saat içinde erişim vermesi gereken yönetici içindir. "Güvenlik temelleri" okumak isteyen biri için değil.

Önce Karşı Tarafın Tam Olarak Ne Yapması Gerektiğini Anlayın

İşi tanımlamadan erişim vermek, sadece içinden bir mektup alması gereken birine kasanın anahtarını vermek gibidir. Herhangi bir işlemden önce sorun: Bu kişi neyi değiştirecek? Üç yaygın durum vardır:

  • Site içeriğini değiştirme — makale yazmak, fotoğraf yüklemek, sayfaları düzenlemek. Bu iş, sunucu erişimi değil, içerik yönetimi erişimi gerektirir.
  • Kodu veya temayı değiştirme — PHP, CSS, JavaScript dosyalarını düzenlemek. Bu iş, dosya erişimi gerektirir (FTP veya dosya yöneticisi).
  • Sunucu ayarlarını değiştirme — sistem eklentisi kurmak, PHP sürümünü değiştirmek, servisi yeniden başlatmak. Bu iş, kontrol paneli veya SSH erişimi gerektirir.

"Tam erişim" adı altında gelen taleplerin çoğu aslında birinci veya ikinci türdendir. Karşı taraf tam olarak hangi dosyayı veya hangi ayarı değiştirmek istediğini söyleyemiyorsa, bu başlı başına bir uyarı işaretidir.

Bir kural: Erişim ne kadar yüksekse, kasıtsız hataya karşı açıklık da o kadar yüksektir. SSH erişimi olan birinin yapacağı yanlış bir rm -rf, sitenizi hiçbir uyarı vermeden boşaltır. Aynı işi FTP ile bu kadar kolay yapamazsınız.

FTP veya Dosya Yöneticisi Erişimi; Gerçekten İhtiyaç Duyduğunuz En Yaygın Durum

Geliştiricinin WordPress temasını düzenlemesi veya site dosyalarını taşıması gerekiyorsa, FTP erişimi yeterlidir. cPanel veya DirectAdmin'de yalnızca public_html klasörüne erişimi olan ayrı bir FTP hesabı oluşturun. Bu işlem cPanel'de FTP Accounts yolundan yapılır.

Önemli not: Yeni FTP hesabı için ayrı bir kullanıcı adı oluşturun. Ana cPanel kullanıcı adını FTP kullanıcısı olarak vermekten kaçının. Yeni FTP hesabını sitenin ana klasörüyle sınırlandırın ve etc veya logs klasörlerine erişim izni vermeyin.

Yükleme boyutunu da sınırlayın. Sadece tema değişecekse, 50 MB'lık bir sınır koyun. Bu, diskinizi dolduracak 2 GB'lık bir dosyanın yüklenmesini engeller.

FTP Ne Zaman İşe Yaramaz

FTP, tek tek dosyaları düzenlemek için harikadır, ancak veritabanıyla çalışmak veya PHP ayarlarını değiştirmek için işe yaramaz. Geliştirici "php.ini'yi değiştirmem lazım" veya "sistem eklentisi kurmam lazım" derse, FTP yardımcı olmaz. Bu durumda ya kontrol panelinden sınırlı bir erişim vermeli ya da genel anahtarlı SSH kullanmalısınız.

İnsanların hata yaptığı yer burasıdır: Çoğu kişi kolaylık olsun diye ana cPanel şifresini geliştiriciye verir ki "her işi kendisi yapsın". Birkaç hafta sonra iş birliği bittiğinde şifre değiştirilir, ancak eski geliştirici hâlâ FTP üzerinden siteye erişebilir, çünkü ayrı bir FTP hesabı oluşturulmamıştır ve o, ana kullanıcı adıyla giriş yapmıştır. Sonuç: Kimsenin varlığından haberdar olmadığı açık bir erişim.

SSH Erişimi; Sadece Genel Anahtarla, Sadece Belirli Bir İş İçin

Geliştiricinin Composer çalıştırması, kodu Git ile dağıtması veya uzun betikler çalıştırması gerekiyorsa, FTP yeterli değildir. SSH erişimi gereklidir. Ancak doğru yol, root şifresi vermek değildir.

Sınırlı erişime sahip ayrı bir sistem kullanıcısı oluşturun. cPanel tabanlı Linux hosting'de, Güvenlik bölümündeki SSH Access bölümünden yeni kullanıcı için bir genel anahtar kaydedin. Ardından /home/username/.ssh/authorized_keys dosyasına kısıtlayıcı seçenekler ekleyin:

command="/usr/local/bin/deploy-script.sh",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2E...

Böylece bu anahtar yalnızca belirli bir komutu çalıştırabilir. Ne rm, ne cat /etc/passwd, ne de başka bir şey. Geliştirici başka bir iş yapmak isterse, talep etmeli ve siz betiği geliştirmelisiniz.

Bu katı görünüyor ve öyle. Ancak bu katılığın maliyeti, bir veritabanı sızıntısıyla karşılaştırıldığında önemsizdir. Ekibiniz küçükse ve tam güven varsa, bu kısıtlamayı kaldırabilir ve yalnızca site klasörüne erişimi olan bir sistem kullanıcısıyla yetinebilirsiniz. Ama asla root vermeyin.

Veritabanı Erişimi; Root'tan Sonra En Riskli Erişim

Veritabanı, müşteri bilgilerinin, siparişlerin ve site içeriğinin bulunduğu yerdir. phpMyAdmin'e doğrudan erişim, giren herkesin tabloları boşaltabileceği veya tüm kullanıcıların şifrelerini değiştirebileceği anlamına gelir.

Geliştirici yalnızca veritabanı yapısını görmek veya bir sorgu yazmak zorundaysa, yalnızca okuma erişimi olan ayrı bir MySQL kullanıcısı oluşturun. cPanel'de MySQL Databases bölümünden SELECT erişimi olan yeni bir kullanıcı oluşturun ve onu ilgili veritabanına bağlayın. Bu kullanıcı INSERT veya DELETE yapamaz, yalnızca okuyabilir.

Gerçekten yazma erişimine ihtiyacı varsa, test ortamı için ayrı bir veritabanı oluşturun ve ana veritabanı üzerinde çalışmasına izin vermeyin. Geliştirici kopya üzerinde çalışsın ve onaydan sonra değişiklikleri siz ana veritabanına uygulayın.

Erişimi Geri Almak; Herkesin Unuttuğu Kısım

Erişim vermek işin sadece yarısıdır. Diğer yarısı, onu doğru zamanda geri almaktır. Bir geliştiriciyle iş birliği bittiğinde şu kontrol listesini uygulayın:

  1. Ana cPanel veya kontrol paneli şifresini değiştirin.
  2. O kişi için oluşturulmuş tüm FTP hesaplarını silin.
  3. SSH anahtarlarını authorized_keys dosyasından kaldırın.
  4. Onun için oluşturulmuş MySQL kullanıcılarını silin.
  5. E-posta servisine erişim verdiyseniz, e-posta şifresini de değiştirin.

Bu iş 15 dakika sürer. Ancak yapılmazsa, kimsenin haberdar olmadığı açık bir erişim kalır. En kötü senaryo, bir yıl sonra site hacklendiğinde günlüklerde eski geliştiriciye ait bir IP'den giriş yapıldığını görmenizdir.

Bu yüzden ilk günden itibaren verdiğiniz erişimlerin bir tablosunu tutmanızı öneririm: kime, hangi erişimi, ne zaman, hangi iş için. Bu tabloyu sunucu dışında güvenli bir dosyada saklayın. Ekipten biri ayrıldığında önce bu tabloyu kontrol edin.

Kontrol Paneli Erişimi; Sadece İhtiyaç Kadar, Sadece Sınırlı Süre İçin

PHP sürümünü değiştirmek veya sistem eklentisi kurmak gibi bazı işler yalnızca kontrol panelinden yapılabilir. Bu durumda, ana erişimi vermek yerine, yalnızca ilgili bölüme erişimi olan bir alt hesap (subaccount) oluşturun. cPanel bunu Sub Accounts ile sağlar.

Hosting'iniz bu özelliği desteklemiyorsa ve geçici erişim vermekten başka çare yoksa, iş bittikten sonra şifreyi değiştirin. Bunu "sonra"ya ertelemeyin. İş biter bitmez, hemen değiştirin.

Farklı hosting hizmetleri arasındaki seçim de bu konuyu etkileyebilir. Linux hosting ile sanal sunucu arasında kararsızsanız, Linux hosting, bulut sunucu ve özel sunucu hizmetlerinin karşılaştırmasını inceleyin. Paylaşımlı hostingde erişim yönetimi araçları hazırdır; sanal sunucuda ise kullanıcıları kendiniz oluşturup sınırlandırmanız gerekir.

İş Arkadaşı Erişimi Uygulamada; Önerdiğim Senaryo

Bir WordPress sitesi üzerinde çalışan iki ila beş kişilik bir ekip için benim yaptığım şudur:

  • Her kişi için public_html ile sınırlı, yükleme boyutu sınırı olan ayrı bir FTP hesabı.
  • Veritabanını görmesi gereken herkes için salt okunur bir MySQL kullanıcısı.
  • Yalnızca bir kişi için (ekibin kıdemli üyesi) ve yalnızca genel anahtarla SSH erişimi.
  • Kontrol paneli erişimi yalnızca site yöneticisi için, başka hiç kimse için değil.

Ekip daha büyükse veya proje daha hassassa, otomatik dağıtımlı Git gibi kod yönetimi araçlarına geçin. Bu durumda geliştiricinin sunucuya doğrudan erişimi yoktur; yalnızca kodu push eder ve sunucudaki bir betik onu dağıtır. Bu en temiz durumdur ancak ilk kurulumu zaman alır.

Ekip küçükse ve herkes aynı ofiste oturuyorsa, her kişi için FTP fazla olabilir. Ekip için ortak bir FTP hesabı yeterlidir ve şifresini yalnızca yönetici bilir. Bunun maliyeti, hangi dosyayı kimin değiştirdiğini anlayamamanızdır. Bu sizin için önemliyse, ayrı hesaplar oluşturun.

Erişim yönetiminde esneklik açısından paylaşımlı hosting ile sanal sunucu arasında seçim yapmak için hosting, sanal sunucu veya özel sunucu seçim rehberini okuyun. Yeni bir hizmet satın aldıysanız ve karşılama e-postasını henüz tam okumadıysanız, hosting karşılama e-postasını okuma rehberi hangi ayarları orada değiştirmeniz gerektiğini söyler.

Sıkça Sorulan Sorular

Geliştiriciye güvenli olacak hangi erişimi vereyim?

public_html klasörüyle sınırlı ayrı bir FTP hesabı ve veritabanına ihtiyacı varsa salt okunur bir MySQL kullanıcısı. SSH erişimi yalnızca genel anahtarla ve gerçekten gerekliyse. Root veya ana kontrol paneli şifresini asla kimseye vermeyin.

İş arkadaşı için FTP erişimini nasıl oluştururum?

cPanel'de FTP Accounts bölümüne gidin, yeni bir kullanıcı adı oluşturun ve Directory kısmında onu public_html ile sınırlandırın. Güçlü bir şifre seçin ve yükleme boyutunu sınırlayın. Bu hesabın sunucu ayarlarına hiçbir erişimi yoktur.

Geliştiricinin işi bittikten sonra ne yapayım?

Ana kontrol paneli şifresini değiştirin, FTP hesabını silin, SSH anahtarını authorized_keys dosyasından kaldırın ve onun için oluşturulmuş MySQL kullanıcılarını silin. Bunu iş birliğinin bittiği gün yapın, bir hafta sonra değil.

SSH erişimi mi daha iyi, FTP mi?

Dosyalarla çalışmak ve içerik yüklemek için FTP daha basit ve güvenlidir. Composer çalıştırmak, Git ile dağıtım yapmak veya uzun betikler için SSH gereklidir. SSH'yi ne için istediğinizi bilmiyorsanız, muhtemelen ona ihtiyacınız yoktur.

Bu sayfa yardımcı oldu mu?