Başlangıçta sunucuya yalnızca siz giriyorsunuz. Sonra bir geliştirici ekleniyor, ardından bir sistem yöneticisi, derken bir ajans. Ve fark etmeden, root parolasını dört kişi biliyor.
Bu, çalışan ama hesap verilemez bir düzendir. Bir şey bozulduğunda kimin yaptığı bilinmez; biri ayrıldığında erişimini kesmek için herkesin parolasını değiştirmek gerekir. Bu yazı, VDS sunucu üzerinde çok kullanıcılı erişimi düzgün kurmayı anlatıyor.
Temel İlke: Paylaşılan Hesap Yok
Kural tek cümledir: her kişinin kendi hesabı olmalı.
Bunun üç somut faydası vardır:
- İzlenebilirlik. Loglarda "root şunu yaptı" değil, "ahmet şunu yaptı" yazar.
- Ayrılabilirlik. Biri gittiğinde yalnızca onun hesabı kapatılır, kimse etkilenmez.
- Kademeli yetki. Herkese aynı yetkiyi vermek zorunda kalmazsınız.
Paylaşılan root parolası, bu üçünü birden ortadan kaldırır. Ayrıca parola bir kez paylaşıldıktan sonra nereye gittiğini takip edemezsiniz — mesajlaşma geçmişlerinde, not uygulamalarında ve eski çalışanların bilgisayarlarında kalır.
Parola Değil, Anahtar
Ekip erişiminde SSH anahtarı, paroladan her açıdan üstündür:
| Konu | Parola | SSH anahtarı |
|---|---|---|
| Paylaşılabilirlik | Kolayca paylaşılır | Özel anahtar kişide kalır |
| Kaba kuvvet saldırısı | Denenebilir | Pratikte imkânsız |
| Erişimi kaldırma | Parola değişimi, herkesi etkiler | Tek satır silinir |
| Kişi başına ayrım | Zor | Doğal |
Üçüncü satır operasyonel olarak en değerlisidir: bir kişinin erişimini kaldırmak, onun anahtarını yetkili anahtarlar listesinden silmekten ibarettir. Kimseye yeni parola dağıtmanız gerekmez.
sudo Politikası: Yetkiyi Ölçülü Vermek
Kullanıcı hesapları oluşturduktan sonraki soru şudur: kim, hangi yönetici işlemlerini yapabilecek?
Üç yaygın seviye vardır:
- Tam yetki. Kullanıcı her komutu yönetici olarak çalıştırabilir. Yalnızca sistem yöneticileri için.
- Sınırlı yetki. Yalnızca belirli komutlar — örneğin bir servisi yeniden başlatmak veya logları okumak. Geliştiriciler için uygundur.
- Yetkisiz. Kendi dizininde çalışır, sistem ayarlarına dokunamaz. Sınırlı görevler için yeterlidir.
Pratikte en çok işe yarayan ikinci seviyedir: bir geliştiricinin uygulamayı yeniden başlatabilmesi gerekir ama güvenlik duvarını değiştirebilmesi gerekmez.
Sınırlı yetki tanımlarken dikkat edilecek bir tuzak vardır: bazı komutlar dolaylı olarak tam yetki verir. Metin düzenleyici veya dosya kopyalama komutuna yönetici yetkisi vermek, kullanıcının sistem dosyalarını değiştirebilmesi demektir — yani fiilen tam yetki. Verilen izinleri bu gözle gözden geçirin.
Gruplarla Yönetim
Kişi sayısı arttıkça tek tek yetki vermek karmaşıklaşır. Grup kullanımı bunu sadeleştirir:
- Rol bazlı gruplar oluşturun. Geliştiriciler, sistem yöneticileri, salt okuma erişimi olanlar.
- Yetkiyi gruba tanımlayın. Kişiye değil role bağlı düşünün.
- Kişiyi gruba ekleyin. Yeni bir geliştirici geldiğinde tek işlem yeter.
- Dosya sahipliğini gruba verin. Uygulama dosyalarına ekip erişimi böyle sağlanır.
Dördüncü madde günlük çalışmayı kolaylaştırır: uygulama dizininin grubu "geliştiriciler" ise, gruptaki herkes root olmadan dosyaları düzenleyebilir.
Dış Taraflara Erişim Vermek
Ajans, danışman veya geçici destek ekibine erişim verirken ek önlemler gerekir:
- Ayrı hesap açın. Kendi hesabınızı paylaşmayın.
- Yalnızca gereken yetkiyi verin. "Ne olur ne olmaz" diye tam yetki vermeyin.
- Bitiş tarihi belirleyin. İş bitince erişimi kaldıracağınızı takvime yazın.
- Yaptıklarını loglayın. Yönetici komutlarının kaydı tutulmalı.
Üçüncü madde en çok unutulanıdır. Yıllar önce bir kerelik iş için açılmış ve hiç kapatılmamış hesaplar, sunucularda sıkça bulunur — ve bunlar genellikle en zayıf halkadır.
Düzenli Denetim
Altı ayda bir, on dakikalık bir kontrol yapın:
- Kimlerin hesabı var? Tanımadığınız veya artık çalışmayan biri var mı?
- Yetkili anahtarlar listesinde ne var? Kime ait olduğunu bilmediğiniz anahtar kalmış mı?
- Kimler yönetici yetkisine sahip? Bu liste gereğinden uzun mu?
- Parola ile giriş açık mı? Anahtar kullanıyorsanız parolayla girişi kapatın.
Bu denetim, ekip değişimlerinin sessizce biriktirdiği erişim borcunu temizler. Sanal sunucu yönetiminde en çok ihmal edilen ama en kolay yapılan güvenlik işlemlerinden biridir.
Sonuç
Çok kişili sunucu erişiminde tek kural belirleyicidir: paylaşılan hesap kullanmayın. Herkesin kendi hesabı ve kendi SSH anahtarı olsun; erişim kaldırmak tek satır silmeye dönüşsün. Yetkiyi role göre gruplar üzerinden verin ve sınırlı yetki tanımlarken hangi komutların dolaylı olarak tam yetki verdiğine dikkat edin. Dış taraflara açılan hesaplara mutlaka bitiş tarihi koyun — sunucularda en sık bulunan zayıf halka, yıllar önce açılmış ve unutulmuş bir hesaptır.
Sıkça Sorulan Sorular (SSS)
Ekiple root parolasını paylaşmak neden yanlış?
İzlenebilirliği yok eder — loglarda kimin ne yaptığı görünmez. Ayrıca bir kişinin erişimini kaldırmak için parolayı değiştirip herkese yeniden dağıtmanız gerekir. Ve paylaşılan parolanın nereye gittiğini takip edemezsiniz.
Geliştiriciye ne kadar yetki vermeliyim?
Genellikle sınırlı yetki yeterlidir: uygulamayı yeniden başlatmak, logları okumak, dağıtım yapmak. Güvenlik duvarı, kullanıcı yönetimi ve sistem ayarları için tam yetki gerekmez. Yetkiyi işin gerektirdiği kadar verin.
Sınırlı sudo yetkisinde tuzak var mı?
Evet. Metin düzenleyici, dosya kopyalama veya kabuk başlatabilen komutlara yönetici yetkisi vermek, kullanıcının sistem dosyalarını değiştirebilmesi anlamına gelir — yani fiilen tam yetki. İzin verdiğiniz komut listesini bu gözle gözden geçirin.
Ekipten biri ayrıldığında ne yapmalıyım?
Hesabını devre dışı bırakın ve SSH anahtarını yetkili anahtarlar listesinden silin. Ayrıca o kişinin bildiği paylaşılan parolalar varsa değiştirin. İşlemi aynı gün yapın — sonraya bırakılan erişim kaldırma işlemleri unutulur.
