Linux Sunucularda Sudo ve PAM ile Yetki Yönetimi ve Güvenlik Rehberi

Son Güncelleme: Haziran 2026

Sudo güvenliği ve PAM yapılandırması, Linux sunucularda kullanıcı yetkilerini kontrollü şekilde yönetmek için kritik öneme sahiptir. Özellikle çok kullanıcılı VPS, VDS, kiralık sunucu ve kurumsal hosting altyapılarında root erişimini sınırlamak, işlem kayıtlarını izlemek ve ayrıcalıklı komutları güvenli hale getirmek sunucu güvenliğinin temel adımlarındandır.

Bu rehberde sudo, sudoers, PAM yani Pluggable Authentication Modules (Takılabilir Kimlik Doğrulama Modülleri), yetki modeli, güvenli yapılandırma örnekleri, denetim yöntemleri ve pratik senaryoları ayrıntılı şekilde ele alacağız.

İçindekiler

• Sudo ve PAM Nedir?
• Neden Yetki Yönetimi Gereklidir?
• Sudo Temel Kavramları
• Sudoers Güvenli Yapılandırma
• PAM ile Kimlik Doğrulama Politikaları
• Loglama ve Denetim
• Örnek Kullanım Senaryoları
• Yaygın Hatalar ve Güvenli Alternatifler
• Sıkça Sorulan Sorular
• Sonuç

Sudo ve PAM Nedir?

Sudo, Linux ve Unix benzeri sistemlerde normal kullanıcıların belirli komutları geçici olarak başka bir kullanıcı yetkisiyle, çoğunlukla root olarak çalıştırmasını sağlayan bir yetkilendirme aracıdır. Sudo sayesinde her kullanıcıya doğrudan root parolası vermek yerine, hangi kullanıcının hangi komutu hangi koşullarda çalıştırabileceği merkezi olarak tanımlanabilir.

PAM, Pluggable Authentication Modules ifadesinin kısaltmasıdır ve Türkçede Takılabilir Kimlik Doğrulama Modülleri olarak açıklanabilir. PAM, Linux sistemlerde oturum açma, parola doğrulama, erişim kontrolü, hesap kısıtlamaları ve oturum politikaları gibi işlemleri modüler şekilde yönetir. sshd, login, su, sudo ve bazı grafik oturum yöneticileri PAM üzerinden kimlik doğrulama sürecini kontrol edebilir.

Bu iki bileşen birlikte kullanıldığında, bir sunucuda yalnızca kimin yetkili işlem yapabileceği değil, bu işlemlerin hangi doğrulama şartlarıyla, hangi zaman aralığında ve hangi kayıt politikasıyla yapılacağı da belirlenebilir. Örneğin bir sistem yöneticisine servis yeniden başlatma izni verilirken, veritabanı yedekleme işlemi için ayrı bir kullanıcıya sınırlı komut yetkisi tanımlanabilir.

Sudo ve su Arasındaki Fark

su komutu bir kullanıcının başka bir kullanıcıya geçmesini sağlar. Çoğunlukla root hesabına geçiş için kullanılır ve root parolasını bilmeyi gerektirebilir. sudo ise kullanıcının kendi parolasıyla, önceden tanımlanan izinler çerçevesinde tekil komutları çalıştırmasına olanak tanır. Bu yaklaşım hem izlenebilirlik hem de minimum yetki prensibi açısından daha güvenlidir.

Neden Yetki Yönetimi Gereklidir?

Sunucu yönetiminde en büyük güvenlik risklerinden biri, gereğinden fazla yetkiye sahip kullanıcı hesaplarıdır. Bir kullanıcının sadece web servislerini yeniden başlatması gerekiyorsa, bu kullanıcıya tüm dosya sistemini değiştirme veya ağ yapılandırmasını silme yetkisi verilmemelidir. Yetki yönetimi, kullanıcıların yalnızca görevleri için gerekli haklara sahip olmasını sağlayarak saldırı yüzeyini azaltır.

Corelux altyapısında kullanılan Sanal Sunucu, Kiralık Sunucu ve Linux Hosting çözümlerinde de güvenli yönetim yaklaşımı önemlidir. Sunucu sahibi, sistem yöneticisi, yazılım geliştirici ve destek ekibi gibi farklı roller aynı sistem üzerinde çalışıyorsa, her rol için ayrı yetki seviyesi planlanmalıdır.

Minimum Yetki Prensibi

Minimum yetki prensibi, bir kullanıcının veya servisin yalnızca yapmak zorunda olduğu işlem için gerekli en düşük yetkiyle çalışması anlamına gelir. Bu prensip doğru uygulandığında, ele geçirilen bir kullanıcı hesabının verebileceği zarar önemli ölçüde sınırlanır.

• Geliştirici hesabı: Uygulama dizinlerinde dağıtım yapabilir, fakat sistem servislerini silemez.
• Destek hesabı: Log dosyalarını okuyabilir, fakat kritik yapılandırma dosyalarını değiştiremez.
• Yedekleme hesabı: Belirli yedekleme komutlarını çalıştırabilir, fakat kullanıcı parolalarını yönetemez.
• Veritabanı operatörü: Veritabanı servislerini yeniden başlatabilir, fakat firewall kurallarını değiştiremez.

Paylaşımlı Root Kullanımının Riskleri

Birden fazla kişinin aynı root hesabını kullanması, olay sonrası analiz sürecini zorlaştırır. Bir dosya silindiğinde, servis durduğunda veya güvenlik duvarı kuralı değiştirildiğinde işlemi kimin yaptığını tespit etmek güçleşir. Sudo ile her kullanıcı kendi hesabı üzerinden işlem yaptığı için komut geçmişi ve sistem logları daha anlamlı hale gelir.

Sudo Temel Kavramları

Sudo yapılandırması genellikle /etc/sudoers dosyası ve /etc/sudoers.d/ dizini üzerinden yönetilir. Bu dosyalar doğrudan metin editörüyle düzenlenmemeli, sözdizimi denetimi yapan visudo aracı kullanılmalıdır. Hatalı bir sudoers dosyası, yöneticinin sistemde yetkili komut çalıştırmasını engelleyebilir.

visudo Kullanımı

visudo, sudoers dosyasını güvenli şekilde düzenlemek için kullanılır. Dosya kaydedilmeden önce sözdizimi kontrol edilir ve hatalı yapılandırmaların etkinleşmesi engellenir.

sudo visudo

Belirli bir dosyayı /etc/sudoers.d/ altında düzenlemek için aşağıdaki yöntem tercih edilebilir:

sudo visudo -f /etc/sudoers.d/web-ekibi

Bu yöntem, ana sudoers dosyasını karmaşık hale getirmeden rol bazlı yetki tanımları yapmayı kolaylaştırır.

Sudoers Kural Yapısı

Temel bir sudoers satırı genellikle şu mantıkla okunur: kullanıcı, hangi makinede, hangi kullanıcı olarak, hangi komutları çalıştırabilir. Örnek basit bir kural aşağıdaki gibidir:

deploy ALL=(root) /bin/systemctl restart nginx

Bu kural, deploy adlı kullanıcının root yetkisiyle yalnızca nginx servisini yeniden başlatmasına izin verir. Ancak bu kullanıcının tüm sistemi yönetmesine izin verilmez.

Gruplar ile Yetki Vermek

Tek tek kullanıcılara yetki vermek yerine, Linux grupları üzerinden yetkilendirme yapmak daha sürdürülebilirdir. Örneğin webadmins grubundaki kullanıcıların web servislerini yönetmesine izin verilebilir.

sudo groupadd webadmins
sudo usermod -aG webadmins ayse
sudo usermod -aG webadmins mehmet

Sudoers tarafında grup kuralı yüzde işaretiyle tanımlanır:

%webadmins ALL=(root) /bin/systemctl restart nginx, /bin/systemctl reload nginx

Sudoers Güvenli Yapılandırma

Sudoers güvenliği, yalnızca komut izni vermekten ibaret değildir. Komut yollarının tam belirtilmesi, joker karakterlerin dikkatli kullanılması, parola politikalarının doğru ayarlanması ve tehlikeli komutların sınırlandırılması gerekir. Yanlış tanımlanan tek bir kural, kullanıcının root kabuğu elde etmesine yol açabilir.

Tam Komut Yolu Kullanımı

Sudoers dosyasında komutlar tam yoluyla yazılmalıdır. Komutun konumunu öğrenmek için which veya command -v kullanılabilir.

command -v systemctl
command -v journalctl
command -v rsync

Güvenli bir kural örneği:

%webadmins ALL=(root) /bin/systemctl restart nginx, /bin/systemctl status nginx

Güvensiz bir yaklaşım ise kullanıcılara gereğinden geniş komut izni vermektir:

%webadmins ALL=(root) ALL

Bu kural, webadmins grubundaki kullanıcıların root olarak tüm komutları çalıştırmasına izin verir. Böyle bir yetki yalnızca tam sistem yöneticileri için ve dikkatli denetim altında kullanılmalıdır.

NOPASSWD Kullanımında Dikkat Edilmesi Gerekenler

NOPASSWD, kullanıcının sudo komutunu parola girmeden çalıştırmasını sağlar. Otomasyon sistemlerinde yararlı olabilir; ancak yanlış kullanıldığında ciddi güvenlik riski oluşturur. Özellikle kabuk açabilen, dosya düzenleyebilen veya komut çalıştırabilen araçlarda NOPASSWD kullanılmamalıdır.

Daha güvenli bir otomasyon kuralı şöyle olabilir:

backup ALL=(root) NOPASSWD: /usr/local/sbin/run-backup.sh

Burada kullanıcıya birçok komut yerine yalnızca kontrollü bir script çalıştırma izni verilir. Script dosyasının sahibi root olmalı ve normal kullanıcılar tarafından değiştirilememelidir.

sudo chown root:root /usr/local/sbin/run-backup.sh
sudo chmod 750 /usr/local/sbin/run-backup.sh

Komut Alias Kullanımı

Cmnd_Alias, benzer komutları gruplamak için kullanılır. Bu yöntem büyük ekiplerde sudoers dosyasının okunabilirliğini artırır.

Cmnd_Alias WEB_SERVICES = /bin/systemctl restart nginx, /bin/systemctl reload nginx, /bin/systemctl status nginx
%webadmins ALL=(root) WEB_SERVICES

Kullanıcı alias ve runas alias gibi yapılar da rol tabanlı erişim planlamasında kullanılabilir. Ancak küçük sistemlerde fazla karmaşık yapılandırmalar hata riskini artırabileceği için sade ve anlaşılır kurallar tercih edilmelidir.

requiretty, secure_path ve env_reset

Sudo güvenliğinde ortam değişkenleri de önemlidir. secure_path, sudo ile çalıştırılan komutlarda kullanılacak güvenli PATH değerini belirler. env_reset, kullanıcının ortam değişkenlerini sıfırlayarak beklenmeyen davranışları azaltır.

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

Bazı eski sistemlerde kullanılan requiretty seçeneği, sudo komutunun yalnızca TTY üzerinden çalıştırılmasını zorunlu kılar. Otomasyon araçlarıyla çakışabileceği için modern yapılandırmalarda ihtiyaca göre değerlendirilmelidir.

PAM ile Kimlik Doğrulama Politikaları

PAM, Linux sistemlerde kimlik doğrulama akışını modüler hale getirir. Bir servis için parola doğrulama, hesap süresi kontrolü, başarısız giriş sınırlama, oturum açıldığında kaynak limitleri uygulama ve ek güvenlik kontrolleri PAM üzerinden tanımlanabilir. Sudo da çoğu dağıtımda /etc/pam.d/sudo dosyası üzerinden PAM kurallarını kullanır.

PAM Dosya Yapısı

PAM yapılandırmaları genellikle /etc/pam.d/ dizini altında servis bazlı dosyalar halinde bulunur. Örneğin:

• /etc/pam.d/sshd: SSH oturum açma sürecinde kullanılan PAM kurallarını içerir.
• /etc/pam.d/sudo: Sudo kimlik doğrulama sürecinde kullanılan PAM kurallarını içerir.
• /etc/pam.d/su: su komutu için kimlik doğrulama kurallarını içerir.
• /etc/security/limits.conf: Kullanıcı ve grup bazlı kaynak limitleri tanımlamak için kullanılır.

PAM dosyaları düzenlenmeden önce mutlaka yedek alınmalıdır. Hatalı bir PAM kuralı, sistemde oturum açmayı veya sudo kullanmayı engelleyebilir.

sudo cp /etc/pam.d/sudo /etc/pam.d/sudo.bak
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

Başarısız Giriş Denemelerini Sınırlama

Modern Linux dağıtımlarında başarısız parola denemelerini sınırlamak için pam_faillock gibi modüller kullanılabilir. Amaç, kaba kuvvet saldırılarında aynı hesaba tekrar tekrar parola denenmesini zorlaştırmaktır. Dağıtıma göre dosya yolları ve varsayılan yapılandırmalar değişebileceği için değişiklik yapmadan önce sistem belgeleri ve test ortamı dikkate alınmalıdır.

Genel yaklaşım, belirli sayıda başarısız denemeden sonra hesabı geçici olarak kilitlemektir. Örnek bir kavramsal yapılandırma aşağıdaki gibi düşünülebilir:

auth required pam_faillock.so preauth silent deny=5 unlock_time=900
auth required pam_faillock.so authfail deny=5 unlock_time=900

Bu örnekte deny=5 beş başarısız deneme sonrası kilitlemeyi, unlock_time=900 ise kilidin 900 saniye sonra açılmasını ifade eder. Üretim ortamında uygulanmadan önce konsol erişimi hazır tutulmalı ve mevcut dağıtımın PAM yapısıyla uyumluluk kontrol edilmelidir.

su Komutunu Grup ile Sınırlandırma

Root hesabına geçişi daha kontrollü hale getirmek için su komutu belirli bir gruba sınırlandırılabilir. Örneğin yalnızca wheel grubundaki kullanıcıların su kullanmasına izin verilebilir.

sudo groupadd wheel
sudo usermod -aG wheel yonetici

PAM tarafında ilgili satır etkinleştirilebilir veya dağıtıma göre uyarlanabilir:

auth required pam_wheel.so use_uid

Bu yöntem, sudo politikasıyla birlikte kullanıldığında root oturumuna geçişleri daha izlenebilir ve sınırlı hale getirir.

Kaynak Limitleri ve Oturum Politikaları

PAM yalnızca parola kontrolü için değil, kaynak yönetimi için de kullanılabilir. pam_limits modülü ile kullanıcıların açabileceği dosya sayısı, süreç sayısı ve bazı oturum limitleri belirlenebilir. Özellikle paylaşımlı uygulama sunucularında, tek bir kullanıcının tüm sistemi tüketmesini önlemek için bu yaklaşım değerlidir.

# /etc/security/limits.conf
@developers soft nofile 4096
@developers hard nofile 8192
@developers soft nproc 1024
@developers hard nproc 2048

Bu örnekte developers grubundaki kullanıcıların dosya tanıtıcısı ve süreç limitleri belirlenmiştir. Yüksek trafikli projelerde Bulut Sunucu veya Türkiye VDS Sunucu gibi ölçeklenebilir altyapılar tercih edilirken, kullanıcı bazlı limitlerin de doğru planlanması gerekir.

Loglama ve Denetim

Yetki yönetiminin güvenli kabul edilebilmesi için yalnızca kural tanımlamak yeterli değildir. Yapılan ayrıcalıklı işlemlerin kaydedilmesi, incelenmesi ve anormal aktivitelerin tespit edilmesi gerekir. Sudo komutları birçok Linux dağıtımında /var/log/auth.log, /var/log/secure veya systemd günlükleri üzerinden izlenebilir.

Sudo Loglarını İnceleme

Debian ve Ubuntu tabanlı sistemlerde sudo kayıtları çoğunlukla /var/log/auth.log içinde bulunur:

sudo grep sudo /var/log/auth.log

RHEL, AlmaLinux ve Rocky Linux gibi sistemlerde kayıtlar /var/log/secure dosyasında yer alabilir:

sudo grep sudo /var/log/secure

Systemd kullanan sistemlerde journalctl ile sudo kayıtları filtrelenebilir:

sudo journalctl _COMM=sudo

Loglarda Nelere Bakılmalı?

• Yetkisiz sudo denemeleri: Kullanıcının izinli olmadığı komutları çalıştırmaya çalışması incelenmelidir.
• Beklenmeyen saatlerde işlem: Gece saatlerinde yapılan kritik değişiklikler alarm sebebi olabilir.
• NOPASSWD kullanım yoğunluğu: Parolasız çalışan komutların gereğinden fazla kullanılması risk göstergesidir.
• Servis durdurma işlemleri: Web, veritabanı veya güvenlik servislerinin durdurulması ayrıca takip edilmelidir.
• Kullanıcı değişiklikleri: Grup üyeliği, parola ve sudoers değişiklikleri düzenli kontrol edilmelidir.

Sudo I/O Loglama Mantığı

Bazı sudo sürümleri komut giriş ve çıkışlarını daha ayrıntılı kaydetmeye olanak tanır. Bu özellik dikkatli kullanılmalıdır; çünkü hassas bilgilerin loglara yazılması veri güvenliği açısından risk oluşturabilir. Denetim gerektiren kurumsal ortamlarda, hangi verilerin loglanacağı ve logların ne kadar süre saklanacağı önceden belirlenmelidir.

Defaults log_input, log_output
Defaults iolog_dir="/var/log/sudo-io"

Bu yapılandırma test edilmeden üretim ortamında etkinleştirilmemelidir. Özellikle parola, token, API anahtarı veya kişisel veri içerebilecek komut çıktılarında maskeleme ve erişim kontrolü planlanmalıdır.

Örnek Kullanım Senaryoları

Sudo ve PAM yapılandırmaları teorik olarak güçlü görünse de asıl değer, doğru senaryolarda uygulanınca ortaya çıkar. Aşağıdaki örnekler, farklı ekiplerin aynı sunucu üzerinde güvenli şekilde çalışmasına yardımcı olacak pratik modeller sunar.

Senaryo 1: Web Ekibine Servis Yeniden Başlatma Yetkisi

Bir yazılım ekibinin yalnızca Nginx yapılandırmasını test etmesi ve servisi yeniden yüklemesi gerekiyorsa, tüm root yetkisi vermek yerine sınırlı sudo kuralı tanımlanabilir.

sudo groupadd webops
sudo usermod -aG webops developer1

Cmnd_Alias NGINX_OPS = /bin/systemctl reload nginx, /bin/systemctl restart nginx, /bin/systemctl status nginx
%webops ALL=(root) NGINX_OPS

Bu model, Hosting veya özel uygulama sunucusu yöneten ekiplerde web servislerine sınırlı müdahale imkanı sağlar.

Senaryo 2: Yedekleme Kullanıcısına Sınırlı Script Yetkisi

Yedekleme süreçlerinde kullanıcıya doğrudan rsync, tar veya tüm dosya sistemine erişim izni vermek yerine, root tarafından sahiplenilen güvenli bir script üzerinden işlem yaptırmak daha kontrollüdür.

sudo install -o root -g root -m 750 run-backup.sh /usr/local/sbin/run-backup.sh

backup ALL=(root) NOPASSWD: /usr/local/sbin/run-backup.sh

Yedekleme stratejisi planlanırken Yedekleme Hizmeti gibi yönetilebilir çözümlerle birlikte kullanıcı yetkilerinin de sınırlanması önerilir.

Senaryo 3: Destek Ekibine Sadece Log Okuma Yetkisi

Destek ekibinin sorun gidermek için loglara erişmesi gerekebilir; ancak yapılandırma dosyalarını değiştirmesine gerek olmayabilir. Bu durumda journalctl veya belirli log okuma komutları için sınırlı izin verilebilir.

Cmnd_Alias LOG_READ = /bin/journalctl -u nginx, /bin/journalctl -u php-fpm
%support ALL=(root) LOG_READ

Komut argümanlarıyla çalışırken dikkatli olunmalıdır. Bazı araçlar kabuk açma veya dosya yazma özellikleri sunabilir. Bu nedenle izin verilen komutlar mutlaka test edilmelidir.

Senaryo 4: Uygulama Sunucularında Deploy Kullanıcısı

CI/CD süreçlerinde kullanılan deploy kullanıcısı genellikle uygulama dizinine yazma, servis yenileme ve belirli cache temizleme komutlarını çalıştırma yetkisine ihtiyaç duyar. Bu kullanıcıya tam root erişimi vermek yerine görev bazlı izinler tanımlanmalıdır.

deploy ALL=(root) /bin/systemctl reload php-fpm, /bin/systemctl reload nginx

Uygulama Sunucuları, Coolify Hosting veya N8N Hosting gibi ortamlarda otomasyon kullanıcılarının yetkileri düzenli aralıklarla gözden geçirilmelidir.

Yaygın Hatalar ve Güvenli Alternatifler

Sudo ve PAM güçlü araçlardır; ancak yanlış yapılandırıldıklarında sunucunun tamamen ele geçirilmesine neden olabilirler. Aşağıdaki hatalar, üretim sistemlerinde sık karşılaşılan riskli durumlardır.

Hata 1: Kullanıcıya Gereksiz ALL Yetkisi Vermek

En yaygın hata, kolaylık olması için kullanıcılara ALL=(ALL) ALL yetkisi vermektir. Bu yaklaşım kısa vadede hızlı çözüm gibi görünse de uzun vadede denetim ve güvenlik sorunlarına yol açar.

# Riskli örnek
developer ALL=(ALL) ALL

Güvenli alternatif, yalnızca ihtiyaç duyulan komutları tanımlamaktır:

# Daha güvenli örnek
developer ALL=(root) /bin/systemctl reload nginx

Hata 2: Yazılabilir Scriptlere Sudo Yetkisi Vermek

Bir kullanıcı, sudo ile çalıştırabildiği script dosyasını değiştirebiliyorsa, fiilen root yetkisi elde edebilir. Bu nedenle sudo ile çalıştırılan scriptlerin sahibi root olmalı ve yazma izni sınırlanmalıdır.

sudo chown root:root /usr/local/sbin/task.sh
sudo chmod 750 /usr/local/sbin/task.sh

Hata 3: Joker Karakterleri Kontrolsüz Kullanmak

Sudoers içinde joker karakter kullanımı beklenmeyen argümanların çalışmasına neden olabilir. Örneğin bir dosya silme komutuna geniş joker izinleri vermek tehlikelidir.

# Riskli yaklaşım
operator ALL=(root) /bin/rm -rf /var/www/*

Bunun yerine kontrollü script, sabit dizin doğrulaması ve güvenli parametre kontrolü tercih edilmelidir.

Hata 4: PAM Değişikliklerini Test Etmeden Uygulamak

PAM yapılandırmasındaki küçük bir hata, SSH veya sudo erişimini tamamen kesebilir. Değişiklik yaparken ikinci bir root oturumu açık tutulmalı, mümkünse konsol erişimi hazır olmalı ve önce test ortamında doğrulama yapılmalıdır.

sudo pamtester sudo kullanici authenticate

pamtester her sistemde kurulu olmayabilir; ancak test mantığı aynıdır: yapılandırma değişikliği sonrası kritik oturum açma ve sudo işlemleri doğrulanmalıdır.

Hata 5: Logları Toplamamak veya Korumamak

Sudo ve PAM logları yalnızca oluştuğunda değil, düzenli incelendiğinde değerlidir. Log dosyalarının sıradan kullanıcılar tarafından silinememesi, merkezi olarak yedeklenmesi ve gerektiğinde alarm mekanizmalarına bağlanması önerilir.

Sıkça Sorulan Sorular

Sonuç

Sudo ve PAM ile yetki yönetimi, Linux sunucularda güvenli yönetimin temel yapı taşlarından biridir. Doğru tasarlanmış sudoers kuralları, kullanıcıların yalnızca ihtiyaç duydukları komutları çalıştırmasını sağlar; PAM politikaları ise kimlik doğrulama, hesap kilitleme, oturum kontrolü ve kaynak limitleri gibi ek güvenlik katmanları sunar.

Güvenli bir yapı için root hesabının paylaşımlı kullanımından kaçınmalı, kullanıcıları gruplar üzerinden yönetmeli, NOPASSWD kurallarını sınırlamalı, PAM değişikliklerini test etmeli ve sudo loglarını düzenli olarak incelemelisiniz. Özellikle üretim ortamlarında küçük bir yetki hatası büyük kesintilere veya güvenlik ihlallerine neden olabilir.

Corelux, farklı ihtiyaçlara yönelik Sanal Sunucu, Kiralık Sunucu, Türkiye Kiralık Sunucu, Yedekleme Hizmeti ve SSL Sertifikası çözümleriyle güvenli, performanslı ve yönetilebilir altyapılar kurmanıza yardımcı olur. Linux sunucularınızda sürdürülebilir güvenlik için yetki yönetimini kurulum aşamasından itibaren planlamanız önerilir.