Linux VPS’te Kullanıcı, Grup ve sudo Mimarisi: Çoklu Proje ve Ekipler İçin Yetki Tasarımı

Linux VPS’te Yetki Tasarımını Doğru Kurmanın Gerçek Etkisi

Linux VPS üzerinde birden fazla proje, ajans yapısı veya ürün ekibi yönetiyorsanız, en kritik mimarilerden biri aslında CPU, RAM veya disk değil; kullanıcı, grup ve sudo mimariniz. Bir kapasite planlama toplantısında dakikalarca vCPU, NVMe ve bant genişliği tartışılırken, çoğu zaman şu soru atlanıyor: “Bu sunucuya kim, neye, hangi yetkiyle erişecek?”

DCHost ekibi olarak sahada en çok gördüğümüz problemler; yanlış yapılandırılmış sudo, herkesin her şeyi yapabildiği tek bir kullanıcı hesabı ve projeler arası karışan dosya izinleri. Sonuç çoğu zaman aynı: kimin hangi dosyayı bozduğunu bulamama, istemeden silinen loglar, yanlış sunucuda çalışan deploy script’leri ve en kötüsü, üretim ortamına sızan gereksiz ayrıcalıklar.

Bu yazıda, Linux VPS’inizde çoklu proje ve ekipler için tekrar kullanılabilir bir yetki tasarımı kurmanıza yardımcı olacağız. Kullanıcı ve grup yapısını nasıl modelleyeceğinizi, sudoers dosyasını komut bazında nasıl sade ve güvenli tasarlayacağınızı, geliştirme–staging–canlı ortam ayrımlarını yetkilerle nasıl hizalayacağınızı adım adım anlatacağım. Anlattıklarımızı, DCHost üzerinde barındırdığınız Linux VPS’lerde doğrudan uygulayabilirsiniz.

Eğer henüz temel güvenlik sertleştirme adımlarını atmadıysanız, bu yazıyı VPS güvenlik sertleştirme kontrol listemiz ve yeni VPS’te ilk 24 saatte yapılması gereken ayarlar ile birlikte düşünmenizi özellikle öneririm.

Kavramlar: Kullanıcı, Grup ve sudo Arasındaki İlişki

POSIX izin modeli hızlı özet

Linux’ta dosya ve dizin izinlerinin temelinde POSIX modeli vardır. Her dosya için üç ana başlık bulunur:

• Sahip (user): Dosyanın sahibi kullanıcı.
• Grup (group): Dosyaya ait birincil grup.
• Diğerleri (others): Sahip ve grup dışındaki herkes.

Her biri için okunabilir (r), yazılabilir (w) ve çalıştırılabilir (x) bitleri (ve bunların sayısal karşılığı olan 4, 2, 1) vardır. Bu konuyu detaylı anlamak istiyorsanız, ayrıca Linux dosya izinleri ve güvenli ayarlar yazımıza da göz atabilirsiniz.

Kullanıcı türleri: root, sistem kullanıcıları ve normal kullanıcılar

Yetki tasarımı yaparken üç ana kullanıcı türünü bilmek gerekir:

• root: Her şeye tam yetkili, süper kullanıcı. Hata affetmez.
• Sistem kullanıcıları: genellikle /usr/sbin/nologin ile giriş yapamayan, sadece servis çalıştırmak için kullanılan hesaplar (www-data, mysql, postfix vb.).
• Normal kullanıcılar: İnsanların (geliştirici, sistem yöneticisi vb.) giriş yaptığı hesaplar.

Doğru mimaride, insanlara doğrudan root erişimi vermezsiniz. Bunun yerine, normal kullanıcı + sudo ile gerektiğinde kontrollü ayrıcalık yükseltmesine izin verirsiniz.

sudo neden doğrudan root yerine tercih edilmeli?

sudo, belirli kullanıcılara belirli komutları, belirli kullanıcı kimlikleriyle (çoğu zaman root) çalıştırma izni veren bir mekanizmadır. Avantajları:

• Her komut loglanır (varsayılan ayarlarla /var/log/auth.log).
• Kullanıcı bazlı ince ayarlı yetki verebilirsiniz.
• Parola isteyerek (veya NOPASSWD ile) ek bir güvenlik/denetim katmanı sağlayabilirsiniz.
• Doğrudan root parolasını paylaşmak zorunda kalmazsınız.

Çoklu proje ve çok ekipli yapılarda, bütün mimariyi “herkes root ile bağlanıyor” şeklinde kurmak felaket senaryosuna davetiye çıkarmaktır. DCHost olarak kendi iç altyapımızda da ekipleri her zaman sudo merkezli bir modele göre kurguluyoruz.

Çoklu Proje ve Ekipler İçin Mantıksal Model

Hedef: En az ayrıcalık ve izlenebilirlik

Başarılı bir yetki tasarımının üç temel hedefi vardır:

• Least privilege (en az ayrıcalık): Her kullanıcı sadece işini yapmaya yetecek kadar hakka sahip olsun.
• Separation of duties (görev ayrımı): Geliştirici, operasyon, müşteri veya içerik ekibi aynı yetki seviyesinde olmasın.
• Auditability (izlenebilirlik): Hangi komutu kimin, ne zaman çalıştırdığını görebilin.

Basit bir örnek düşünelim: Aynı VPS’te üç proje barınıyor:

• Kurumsal web sitesi (marketing ekibi ve ajans erişiyor).
• E-ticaret sitesi (backend & frontend ekipleri, operasyon).
• İç dashboard (sadece iç ekip, kritik veriler).

Bu üç projenin hem kod tabanı hem de verileri birbirinden olabildiğince izole olmalı. Aynı zamanda, ortak görevler (örneğin sunucu güncelleme, log yönetimi) için rol bazlı erişimlere de ihtiyaç var.

Proje bazlı gruplar

İyi bir başlangıç noktası şudur: Her proje için en az bir grup tanımlayın. Örneğin:

• proj_corporate
• proj_shop
• proj_dashboard

Bu gruplar, ilgili projenin kod dizinlerine ve loglarına erişme hakkını belirler. Örnek dizin yapısı:

• /var/www/corporate (grup: proj_corporate)
• /var/www/shop (grup: proj_shop)
• /var/www/dashboard (grup: proj_dashboard)

Bu dizinlerin sahipliğini proje özelinde bir sistem kullanıcısıyla (ör. corporate-www, shop-www) veya web sunucu kullanıcısıyla (www-data vb.) birlikte tasarlayabilirsiniz. Burada önemli olan, grup üzerinden insan kullanıcıların yetki almasıdır.

Rol bazlı gruplar

Sadece proje bazlı grup yetmez. Bir de rol bazlı gruplar tanımlamalısınız:

• role_dev: Geliştiriciler.
• role_ops: Sistem & DevOps ekibi.
• role_ro: Sadece log okuma, konfigürasyon görüntüleme yetkisi olanlar.

Bir kullanıcının erişimi, “proje + rol” kombinasyonuyla belirlenir. Örnek:

• Ali: proj_shop + role_dev → sadece shop koduna yazabilir, shop için belirli sudo izinleri olabilir.
• Ayşe: proj_shop + proj_dashboard + role_ops → iki proje için de bakım yapabilir, sistem seviyesinde daha geniş sudo yetkisi olabilir.
• Ajans kullanıcısı: proj_corporate + role_ro → sadece corporate kodunu görebilir, log okuyabilir.

Umask ve varsayılan izinler

Bu mimaride, projenin kod dizini için grup yazma iznini açmanız gerekir. Örneğin /var/www/shop dizini:

chown -R shop-www:proj_shop /var/www/shop
chmod -R 2775 /var/www/shop

Buradaki 2 (setgid biti), bu dizin altında oluşturulan yeni dosya ve dizinlerin, otomatik olarak direncin grubunu (proj_shop) almasını sağlar. Ayrıca kullanıcıların umask değerini (genelde 002) grup yazma iznine izin verecek şekilde ayarlamak gerekir ki ekip aynı projede rahatça çalışabilsin.

Adım Adım: Kullanıcı ve Grup Oluşturma Pratiği

Temel grup ve kullanıcıların oluşturulması

Örneğimizde iki geliştirici (ali, ayse) ve tek proje (shop) üzerinden gidelim. Önce grupları oluşturalım:

groupadd proj_shop
groupadd role_dev
groupadd role_ops

Sonra kullanıcıları ekleyelim:

adduser ali
adduser ayse

Kullanıcıları ilgili gruplara dahil edelim:

usermod -aG proj_shop,role_dev ali
usermod -aG proj_shop,role_ops ayse

Bu noktada:

• Ali: shop projesinde geliştirici.
• Ayşe: shop projesinde operasyon sorumlusu.

Elbette gerçek hayatta daha fazla proje ve rol olabilir, ancak mantık aynı kalır.

Proje dizini izinleri

Shop projesinin kod dizinini ayarlayalım:

mkdir -p /var/www/shop
chown -R shop-www:proj_shop /var/www/shop
chmod -R 2775 /var/www/shop

Artık projede çalışan herkes (proj_shop grubundakiler) bu dizine yazabilir. Fakat sistemdeki diğer kullanıcılar (örneğin başka bir projenin geliştiricisi) buraya erişemez.

Home dizinleri ve paylaşım stratejisi

Geliştiricilerin kişisel ~/ dizinlerini izole tutmak ve proje dosyalarını her zaman /var/www altında konumlandırmak iyi bir pratiktir. Böylece:

• Kullanıcı silerken sadece home dizinini temizler, projeye ait kodları dokunmadan bırakabilirsiniz.
• Yedekleme ve restore operasyonlarında proje dizinlerine odaklanabilirsiniz.

Yedeklemeyi tasarlarken, bu yapıyı object storage’a otomatik yedek alma stratejileri ile birleştirmeniz uzun vadede işinizi çok kolaylaştırır.

sudoers Tasarımı: Komut Bazlı Yetki Paylaşımı

sudoers dosyasına bakış

sudo kuralları /etc/sudoers ve /etc/sudoers.d/ altındaki dosyalarda tanımlanır. Asla sudoers dosyasını doğrudan bir editörle düzenlemeyin; her zaman visudo kullanın. Bu komut, dosya kaydedilmeden önce sözdizimini kontrol eder.

/etc/sudoers.d ile modüler yapı

Karmaşık yapılarda, tek bir büyük /etc/sudoers dosyası yerine, proje veya rol bazlı dosyalar oluşturmak işleri çok daha okunabilir hale getirir:

• /etc/sudoers.d/proj_shop
• /etc/sudoers.d/proj_corporate
• /etc/sudoers.d/role_ops_global

Her dosyanın başına şu satırı eklemek iyidir:

Defaults    env_reset

Böylece sudo ile komut çalıştırırken ortam değişkenleri temizlenir ve sürpriz davranışlar azalmış olur.

Alias kullanarak okunabilirlik

sudoers içinde alias tanımlamak, karmaşıklığı azaltır. Örneğin shop projesi için:

User_Alias   SHOP_DEVS = %proj_shop
User_Alias   SHOP_OPS  = %role_ops

Cmnd_Alias   SHOP_DEPLOY = /usr/local/bin/deploy_shop.sh
Cmnd_Alias   SHOP_SERVICE = /bin/systemctl restart php-fpm, 
                              /bin/systemctl restart nginx

Daha sonra bu alias’ları yetki tanımında kullanabilirsiniz:

SHOP_DEVS ALL=(root) NOPASSWD: SHOP_DEPLOY
SHOP_OPS  ALL=(root) NOPASSWD: SHOP_DEPLOY, SHOP_SERVICE

Burada ne elde ettik?

• Geliştiriciler sadece deploy script’ini çalıştırabiliyor.
• Operasyon ekibi deploy’a ek olarak servis restart edebiliyor.
• Hiç kimse genel bir sudo su - yetkisine sahip değil.

Şifre zorunluluğu vs NOPASSWD

Güvenlik–kullanılabilirlik dengesini, komut seviyesinde kurabilirsiniz:

• Sık kullanılan, düşük riskli komutlar için NOPASSWD verilebilir (ör. statik dosya clear script’i).
• Kritik komutlar için (örn. firewall restart, kullanıcı yönetimi) mutlaka parola isteyin.

Örneğin:

SHOP_OPS ALL=(root) NOPASSWD: SHOP_DEPLOY, SHOP_SERVICE
SHOP_OPS ALL=(root) /usr/sbin/ufw reload

Burada ufw reload için parola istenecektir (NOPASSWD tanımlı olmadığı için).

root erişimini tamamen mi kapatmalı?

Pratikte çoğu prod ortamda SSH ile doğrudan root girişi kapatılmalı, fakat sudo ile root olma ihtimali (örneğin acil durumlar için ops ekibinde) korunmalıdır. Bunun detaylarını, hem bu mimariyle uyumlu hem de daha geniş kapsamlı şekilde VPS sunucu güvenliği rehberimizde anlattık.

SSH, Anahtar Yönetimi ve sudo Modelinin Birlikte Çalışması

Parola yerine SSH anahtarı

sudo mimarisini doğru kursanız bile, zayıf bir SSH parolası tüm planı çöpe atabilir. Bu nedenle mümkün olduğunca yalnızca SSH anahtarı ile giriş kabul eden bir yapı kurmanızı öneririz. Bu konuda adım adım anlatım için SSH anahtar yönetimi ve yetki paylaşımı rehberimize göz atabilirsiniz.

Genel yaklaşım şu olmalı:

• Her ekip üyesi için ayrı bir Linux kullanıcısı oluşturun (ali, ayse vb.).
• Her kullanıcının kendi SSH anahtarını ~/.ssh/authorized_keys içine ekleyin.
• SSH üzerinde PasswordAuthentication no ve PermitRootLogin no ayarlarını yapın.
• sudo izinlerini az önce anlattığımız şekilde, roller ve projelere göre tanımlayın.

Bu model sayesinde, bir ekip üyesi ayrıldığında yapmanız gereken tek şey ilgili kullanıcıyı ve anahtarlarını kaldırmak; root parolasını değiştirmek ve herkese yeniden dağıtmak gibi zahmetler ortadan kalkar.

Çoklu ortamlar: dev, staging, prod

Özellikle SaaS veya e-ticaret projelerinde, genellikle en az üç ortam bulunur:

• Geliştirme (dev)
• Test/Staging
• Üretim (prod)

Bu ortamları tamamen farklı VPS’lerde tuttuğunuz senaryolarda bile, kullanıcı–grup–sudo modelinin isimlendirmesini aynı tutmak, ekiplerin kafasını karıştırmaz. Sadece yetki seviyelerini değiştirirsiniz. Örneğin:

• Dev ortamında geliştiricilere daha geniş sudo hakkı verilebilir.
• Prod ortamında geliştiriciler sadece deploy script’lerini çalıştırabilir, servis restart ve sistem ayarları yalnızca ops ekibine açık olabilir.

Tipik Senaryolar İçin Örnek Mimariler

Senaryo 1: Ajansın çoklu müşteri siteleri

Bir dijital ajans olduğunuzu ve DCHost üzerinde onlarca müşteri sitesini aynı VPS havuzunda yönettiğinizi düşünün. Her müşteri için ayrı bir proje grubu oluşturabilirsiniz:

• proj_markaA, proj_markaB, proj_markaC…

Ajans içi ekip rolleri:

• role_wp_dev (WordPress geliştiriciler)
• role_frontend
• role_ops (sunucu yöneten az sayıdaki kişi)

Bir geliştirici hem proj_markaA hem proj_markaB’de çalışıyorsa, iki proje grubuna da eklenir. Fakat role_ops grubunda değilse, sadece belirli deploy veya cache temizleme script’lerini çalıştırabilir. Daha kapsamlı ajans senaryosu için ajanslar için panel erişim yönetimi rehberimiz de iyi bir tamamlayıcı olacaktır.

Senaryo 2: Ürün şirketinde backend, frontend ve DevOps ayrımı

Bir ürün şirketinde genellikle şu roller vardır:

• Backend ekibi
• Frontend ekibi
• DevOps/SRE ekibi

Burada strateji:

• Backend ekibi: API kod dizinlerine yazabilir, belirli log dizinlerini okuyabilir, sadece deploy script’ini ve migration komutlarını sudo ile çalıştırabilir.
• Frontend ekibi: Sadece frontend build/deploy script’lerini çalıştırabilir, sunucu yapılandırmasına dokunamaz.
• DevOps ekibi: Servis restart, firewall, sistem güncelleme gibi görevler için daha geniş sudo yetkisine sahip olur.

Böylece, yanlışlıkla “tüm sunucuyu etkileyen” bir komutu çalıştırma riski backend veya frontend tarafında ciddi ölçüde azaltılmış olur.

Senaryo 3: Dış hizmet sağlayıcı veya freelance geliştirici

Dışarıdan destek aldığınız bir freelance geliştiriciye “geçici” ama kontrollü erişim vermek istiyorsanız:

• Sadece ilgili projeye ait gruba ekleyin (ör. proj_shop).
• role_dev veya role_ro gibi kısıtlı bir rol verin.
• sudo tarafında, sadece belirli script’leri çalıştırmasına izin veren minimal bir tanım ekleyin.
• İş bittiğinde kullanıcıyı silin, proje dizini ve loglar korunmaya devam eder.

Bu sayede tek bir “ortak root parolası” asla oluşmaz, erişim her zaman kişisel hesaplar üzerinden izlenebilir kalır.

Güvenlik Boyutu: Hangi Hatalardan Özellikle Kaçınmalısınız?

“Herkes için tek kullanıcı” modeli

En sık gördüğümüz anti-pattern, tüm ekibin ubuntu, admin veya benzeri tek bir kullanıcıyı, paylaşılan bir SSH anahtarıyla kullanması. Bu modelde:

• Kimin ne yaptığını loglardan bile ayırt edemezsiniz.
• Bir kişi ayrıldığında anahtarı değiştirmek zorundasınız; herkesi etkileyen operasyonel yük.
• sudoers üzerinden kişiye özel yetki tanımı yapamazsınız.

Bu modelden bir an önce uzaklaşmak gerekir. DCHost olarak yeni açılan VPS’lerde, ilk 24 saatte mutlaka kişisel kullanıcılar ve sudo modelinin devreye alınmasını öneriyoruz.

sudo ALL=(ALL:ALL) ALL dağıtmak

Bazen kolayına kaçılıp tüm geliştiricilere şu yetki veriliyor:

%dev ALL=(ALL:ALL) ALL

Bu, pratikte herkese tam root yetkisi vermektir. Prod ortamda bunu yapmak, hem güvenlik hem de operasyonel riskleri inanılmaz artırır. Bunun yerine:

• Hangi komutların gerçekten gerektiğini belirleyin.
• Bu komutları Cmnd_Alias ile gruplayın.
• Sadece bu alias’lara izin verin.

sudo ile ortam değişkeni manipülasyonu

Sudo kullanırken ortam değişkenlerinin (PATH, LD_PRELOAD, LD_LIBRARY_PATH vb.) istismar edilmemesine dikkat etmek gerekir. Bu yüzden sudoers içinde genellikle şunları kullanmak iyi bir pratiktir:

Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults    env_reset

Böylece kullanıcı kendi PATH’ine kötü niyetli bir komut ekleyerek, sudo ile beklenmedik bir şey çalıştırma şansını azaltırsınız.

DCHost VPS Üzerinde Bu Mimariyi Nasıl Konumlandırabilirsiniz?

Planlama adımı: Kaynak değil, yetki de tasarlanmalı

DCHost’tan Linux VPS alırken çoğu müşterimiz önce vCPU, RAM ve disk planlamasını konuşuyor. Bunun yanında aynı ciddiyetle şu üç soruyu da planlama aşamasında yanıtlamanızı öneririz:

• Bu VPS’te kaç ayrı proje olacak?
• Bu projelere kimler, hangi rollerle erişecek?
• Hangi rollere hangi sudo komutları gerçekten gerekli?

Bu soruları netleştirdiğinizde, kullanıcı–grup–sudo mimarisini ilk günden doğru kurup, ileride büyüdükçe yama yapmaktan kurtulursunuz.

Önerilen ilk kurulum akışı

DCHost üzerinde yeni bir Linux VPS açtığınızda pratik bir akış şöyle olabilir:

1. SSH ile root olarak bağlanın (ilk erişim için).
2. Sistem güncellemesi ve temel güvenlik ayarlarını uygulayın.
3. Kendi kişisel kullanıcınızı oluşturun ve sudo yetkisi verin.
4. SSH’de root girişini kapatın, sadece anahtar ile girişe izin verin.
5. Proje gruplarını (proj_*) ve rol gruplarını (role_*) oluşturun.
6. Kullanıcıları bu gruplara yerleştirin, proje dizinlerini ve izinlerini ayarlayın.
7. /etc/sudoers.d altında proje/rol bazlı sudo kurallarını yazın.

Bu adımların bir kısmı, daha önce hazırladığımız VPS sunucu güvenliği için pratik yaklaşımlar rehberimizle de bire bir uyumludur.

Sonuç: Sağlam Bir Yetki Mimarisi, Sizi Yıllarca Taşıyabilir

Linux VPS’inizde kullanıcı, grup ve sudo mimarisini ilk günden doğru kurduğunuzda, bunun etkisini yalnızca güvenlik tarafında değil; operasyonel verimlilik, hata ayıklama hızı ve ekip içi huzurda da hissedersiniz. Hangi dosyayı kimin değiştirdiğini, hangi komutu kimin çalıştırdığını bilmek; üretim ortamında “kim ne yaptı?” paniğini ciddi ölçüde azaltır.

DCHost’ta kendi altyapımızı da aynı prensiplerle yönetiyoruz: proje bazlı gruplar, rol bazlı gruplar, minimal ve denetlenebilir sudo yetkileri, zorunlu SSH anahtar kullanımı ve root erişiminin sıkı kontrolü. Siz de çoklu proje, ajans yapısı veya SaaS ürünleri yönetiyorsanız, bu yazıdaki modeli kendi senaryonuza uyarlayarak başlayabilirsiniz.

Yeni bir Linux VPS planlıyorsanız, ekibinizin rol dağılımı ve projelerinizin yapısı hakkında bizimle paylaşacağınız birkaç bilgi, size özel bir yetki mimarisi önermemizi kolaylaştırır. DCHost üzerinden seçeceğiniz VPS, dedicated veya colocation çözümlerinde; kullanıcı, grup ve sudo tasarımını en başta birlikte kurgulamak, ileride yaşayabileceğiniz pek çok güvenlik ve operasyon probleminden sizi koruyacaktır.

Son adım olarak, bu yazıyı VPS izleme ve uyarı kurulum rehberi ile birleştirip, hem yetki modelinizin hem de sistem kaynaklarınızın sürekli gözetim altında olduğundan emin olmanızı öneririz.