Linux Grup Yönetimi ile Ekip Erişim Kontrolü

Ekip büyüdükçe “herkese sudo ver, geç git” felsefesi er ya da geç sizi yakacak. Bir geliştirici yanlışlıkla production veritabanını siler, bir stajyer log dosyalarını temizler ya da birisi sistem servislerini kapatır. Bunların hepsi yaşandı, yaşanıyor ve yaşanmaya devam edecek. Linux grup yönetimi tam da bu noktada devreye giriyor: doğru yapılandırıldığında, her ekip üyesinin sadece kendi işini yapabildiği, başkasının alanına giremediği güvenli bir ortam oluşturabiliyorsunuz.

Linux Grup Sisteminin Temelleri

Linux’ta her kullanıcının bir birincil grubu (primary group) ve sıfır ya da daha fazla ikincil grubu (secondary group) bulunur. Dosya izinleri bu grup yapısı üzerine inşa edilmiştir. Bir dosya oluşturduğunuzda, o dosya otomatik olarak oluşturan kullanıcının birincil grubuyla ilişkilendirilir.

Sistem üzerindeki tüm gruplar /etc/group dosyasında saklanır. Yapısı şu şekildedir:

cat /etc/group
# grupadi:parola:GID:uye1,uye2,uye3
developers:x:1001:ahmet,mehmet,ayse
devops:x:1002:ali,veli

Parola alanındaki x genellikle kullanılmaz, GID ise grup kimlik numarasıdır. Sisteme yeni katılan bir sysadmin olarak bu dosyayı doğrudan düzenlemeye çalışmayın, bunun için komutlar var.

Mevcut grupları ve üyeliklerini hızlıca görmek için:

# Tüm grupları listele
getent group

# Belirli bir grubun üyelerini gör
getent group developers

# Mevcut kullanıcının üye olduğu grupları gör
groups

# Başka bir kullanıcının gruplarını gör
groups ahmet

# Daha detaylı bilgi için
id ahmet

Gerçek Dünya Senaryosu: Yazılım Geliştirme Şirketi

Diyelim ki orta ölçekli bir yazılım şirketinde çalışıyorsunuz. Şirketin şu ekipleri var:

developers: Uygulama geliştiriciler
devops: Sistem ve altyapı ekibi
qa: Kalite güvence ekibi
readonly: Sadece log okuma yetkisi olan destek ekibi
dba: Veritabanı yöneticileri

Her ekibin farklı dizinlere, farklı servislere ve farklı kaynaklara erişmesi gerekiyor. Hadi bunu adım adım kuralım.

Grup Oluşturma ve Yönetme

Yeni grup oluşturmak için groupadd komutunu kullanıyoruz:

# Temel grup oluşturma
sudo groupadd developers
sudo groupadd devops
sudo groupadd qa
sudo groupadd readonly
sudo groupadd dba

# Belirli bir GID ile grup oluşturma (tutarlılık için)
sudo groupadd -g 2001 developers
sudo groupadd -g 2002 devops
sudo groupadd -g 2003 qa

# Sistem grubu oluşturma (GID 1000'in altında)
sudo groupadd -r appservice

Grup bilgilerini değiştirmek için groupmod:

# Grup adını değiştir
sudo groupmod -n yeni_ad eski_ad

# GID değiştir
sudo groupmod -g 2010 developers

Grup silmek için groupdel:

sudo groupdel eski_grup

Dikkat: Bir grubu silmeden önce o gruba ait dosyaları kontrol edin. Silinen grubun GID’sine sahip dosyalar sahipsiz kalır.

Kullanıcıları Gruplara Ekleme

Kullanıcıları gruplara eklerken iki farklı yöntem var ve bu farkı bilmek kritik:

# Kullanıcıyı gruba ekle (mevcut gruplarını KORUYARAK)
sudo usermod -aG developers ahmet
sudo usermod -aG developers,qa mehmet

# DİKKAT: -a olmadan kullanırsanız mevcut gruplar SİLİNİR
# sudo usermod -G developers ahmet  <- Bunu yapma!

# gpasswd ile ekle
sudo gpasswd -a ahmet developers

# Kullanıcıyı gruptan çıkar
sudo gpasswd -d ahmet developers

-a parametresini unutmak çok yaygın bir hata. usermod -G komutunu -a olmadan çalıştırırsanız, kullanıcının tüm mevcut grup üyelikleri silinir ve sadece belirttiğiniz gruba eklenir. Bunu fark etmeden production’da çalıştırırsanız ciddi sorunlar çıkabilir.

Kullanıcı birincil grubunu değiştirmek için:

# Birincil grubu değiştir
sudo usermod -g developers ahmet

Grup değişikliklerinin etkili olması için kullanıcının oturumu yeniden açması gerekir. Ama bunu beklemeden test etmek istiyorsanız:

# Yeni grup oturumu başlat
newgrp developers

# Kullanıcının mevcut grup oturumunu kontrol et
id

Dizin İzinleri ile Grup Erişim Kontrolü

Grupları oluşturduktan sonra asıl iş dizin izinlerini doğru ayarlamak. Önce proje dizin yapısını oluşturalım:

# Ana proje dizini
sudo mkdir -p /srv/projects/{app,logs,config,db_dumps}

# Sahiplik ve izinleri ayarla
sudo chown root:developers /srv/projects/app
sudo chmod 2775 /srv/projects/app

sudo chown root:devops /srv/projects/config
sudo chmod 2750 /srv/projects/config

sudo chown root:readonly /srv/projects/logs
sudo chmod 2750 /srv/projects/logs

sudo chown root:dba /srv/projects/db_dumps
sudo chmod 2770 /srv/projects/db_dumps

Burada kullandığım 2775 izin bitlerini açıklayayım:

2xxx: SetGID biti. Bu dizinde oluşturulan yeni dosyalar otomatik olarak dizinin grubunu miras alır. Ekip çalışması için şart.
7: Sahip için okuma + yazma + çalıştırma
7: Grup üyeleri için okuma + yazma + çalıştırma
5: Diğerleri için okuma + çalıştırma (sadece girip dosyalara bakabilir, yazamaz)

SetGID olmadan şu sorunla karşılaşırsınız: Ahmet /srv/projects/app içinde bir dosya oluşturur, bu dosyanın grubu ahmet olur, Mehmet bu dosyayı düzenleyemez.

# SetGID bitini doğrula
ls -la /srv/projects/
# drwxrwsr-x 2 root developers ... app
# 's' harfi SetGID'in aktif olduğunu gösterir

umask ile Varsayılan İzinleri Yönetmek

Tek tek dosya izni ayarlamak yorucu. umask değerini doğru ayarlarsanız, kullanıcıların oluşturduğu dosyalar otomatik olarak doğru izinlerle gelir.

# Mevcut umask değerini gör
umask
# 0022 -> Varsayılan: dosyalar 644, dizinler 755

# Ekip ortamı için daha uygun umask
umask 0002
# Dosyalar 664 (grup yazabilir), dizinler 775

Bu ayarı kalıcı yapmak için:

# /etc/profile.d/ altına dosya oluştur
sudo nano /etc/profile.d/team-umask.sh

#!/bin/bash
# Ekip üyeleri için umask ayarı
if id -nG "$USER" | grep -qw "developers|devops|qa"; then
    umask 0002
fi

ACL ile Gelişmiş Erişim Kontrolü

Standart Unix izinleri bazen yetersiz kalır. Örneğin, /srv/projects/logs dizinine readonly grubunun okuması ve devops grubunun yazması gerekiyorsa ne yapacaksınız? İşte burada ACL (Access Control List) devreye giriyor.

# ACL araçlarını yükle
sudo apt install acl          # Debian/Ubuntu
sudo rpm -q acl || sudo dnf install acl  # RHEL/CentOS

# Mevcut ACL'leri görüntüle
getfacl /srv/projects/logs

# devops grubuna yazma izni ver
sudo setfacl -m g:devops:rwx /srv/projects/logs

# readonly grubuna sadece okuma izni ver
sudo setfacl -m g:readonly:r-x /srv/projects/logs

# Yeni oluşturulan dosyalar için varsayılan ACL
sudo setfacl -d -m g:devops:rwx /srv/projects/logs
sudo setfacl -d -m g:readonly:r-x /srv/projects/logs

# ACL'leri kontrol et
getfacl /srv/projects/logs

Çıktı şöyle görünmeli:

# file: srv/projects/logs
# owner: root
# group: readonly
user::rwx
group::r-x
group:devops:rwx
group:readonly:r-x
mask::rwx
other::---
default:group:devops:rwx
default:group:readonly:r-x

ACL’yi kaldırmak için:

# Belirli bir ACL girişini kaldır
sudo setfacl -x g:devops /srv/projects/logs

# Tüm ACL'leri temizle
sudo setfacl -b /srv/projects/logs

sudo ile Grup Tabanlı Yetki Yönetimi

Grup yönetiminin en kritik kısımlarından biri sudo yetkilerini gruplar üzerinden ayarlamak. Bu sayede bireysel kullanıcılara sudo vermek yerine gruba veriyorsunuz, kullanıcı eklenince veya çıkarılınca otomatik olarak yetki de değişiyor.

sudo visudo
# veya
sudo nano /etc/sudoers.d/team-permissions

# DevOps ekibi - sistem yönetimi için tam yetki
%devops ALL=(ALL) ALL

# Geliştiriciler - sadece uygulama servisini yönetebilir
%developers ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, 
                                 /bin/systemctl stop myapp, 
                                 /bin/systemctl start myapp, 
                                 /bin/systemctl status myapp

# QA ekibi - test ortamını yönetebilir
%qa ALL=(ALL) NOPASSWD: /usr/bin/docker-compose, 
                         /usr/bin/docker ps, 
                         /usr/bin/docker logs *

# DBA ekibi - veritabanı servislerini yönetebilir
%dba ALL=(ALL) NOPASSWD: /bin/systemctl * postgresql, 
                          /bin/systemctl * mysql

Sudoers dosyasını doğrulamak için:

sudo visudo -c
# /etc/sudoers: parsed OK

Toplu Kullanıcı Yönetimi ile Zaman Kazanma

Gerçek hayatta 50 kişilik bir ekibi tek tek eklemek istemezsiniz. İşte işinizi kolaylaştıracak bir script:

#!/bin/bash
# ekip-kurulum.sh - Toplu ekip üyesi ekleme scripti

DEVELOPERS="ahmet mehmet ayse fatma"
DEVOPS="ali veli"
QA="zeynep burak"
DBA="kemal"
READONLY="destek1 destek2 destek3"

# Grupları oluştur
for grup in developers devops qa dba readonly; do
    if ! getent group "$grup" > /dev/null 2>&1; then
        groupadd "$grup"
        echo "Grup oluşturuldu: $grup"
    fi
done

# Kullanıcıları gruplara ekle
for kullanici in $DEVELOPERS; do
    if id "$kullanici" &>/dev/null; then
        usermod -aG developers "$kullanici"
        echo "$kullanici developers grubuna eklendi"
    else
        echo "UYARI: $kullanici kullanıcısı bulunamadı"
    fi
done

for kullanici in $DEVOPS; do
    id "$kullanici" &>/dev/null && usermod -aG devops "$kullanici"
done

for kullanici in $QA; do
    id "$kullanici" &>/dev/null && usermod -aG qa "$kullanici"
done

# Sonucu doğrula
echo "--- Grup Üyelikleri ---"
for grup in developers devops qa dba readonly; do
    echo "$grup: $(getent group $grup | cut -d: -f4)"
done

Grup Üyeliklerini Denetlemek ve Raporlamak

Her sysadmin periyodik olarak “kim hangi gruba üye?” sorusuna yanıt verebilmeli. Özellikle güvenlik denetimleri için:

#!/bin/bash
# grup-raporu.sh - Grup üyelik raporu

echo "=== GRUP ÜYELİK RAPORU ==="
echo "Tarih: $(date)"
echo ""

KRITIK_GRUPLAR="sudo wheel docker developers devops dba"

for grup in $KRITIK_GRUPLAR; do
    if getent group "$grup" > /dev/null 2>&1; then
        uyeler=$(getent group "$grup" | cut -d: -f4)
        if [ -n "$uyeler" ]; then
            echo "[$grup]"
            echo "$uyeler" | tr ',' 'n' | sed 's/^/  - /'
            echo ""
        fi
    fi
done

echo "=== SUDO YETKİSİ OLAN KULLANICILAR ==="
grep -v '^#' /etc/sudoers | grep -v '^$' | grep '%|ALL'

echo ""
echo "=== SON 7 GÜNDE OTURUM AÇANLAR ==="
last -n 20 | head -20

Bu scripti cron’a ekleyerek haftalık rapor alabilirsiniz:

# Her Pazartesi 09:00'da çalıştır
0 9 * * 1 /opt/scripts/grup-raporu.sh | mail -s "Haftalık Grup Raporu" [email protected]

Yaygın Hatalar ve Çözümleri

Yıllar içinde gördüğüm en sık yapılan hataları paylaşayım:

newgrp’yi Unutmak

Kullanıcıya yeni bir grup eklediniz ama kullanıcı hala “permission denied” alıyor. Neden? Çünkü grup değişikliği aktif oturum için geçerli değil. Kullanıcı çıkıp girmeli ya da newgrp grupadi çalıştırmalı.

Sahipsiz Dosyalar

Bir kullanıcıyı sildikten sonra o kullanıcıya ait dosyalar sahipsiz kalır. Bu dosyaları bulmak için:

# Geçersiz UID'ye sahip dosyaları bul
find / -nouser -print 2>/dev/null

# Geçersiz GID'ye sahip dosyaları bul
find / -nogroup -print 2>/dev/null

# Sahipsiz dosyaların sahipliğini düzelt
find /srv/projects -nouser -exec chown root:developers {} ;

SetGID Bitinin Kaybolması

chmod komutunu yanlış kullanırsanız SetGID biti kaybolabilir:

# YANLIŞ - SetGID bitini kaybedebilir
chmod 775 /srv/projects/app

# DOĞRU - SetGID'i koru
chmod 2775 /srv/projects/app
# veya
chmod g+s /srv/projects/app

Docker Grubu Güvenlik Riski

docker grubuna kullanıcı eklemek aslında o kullanıcıya root yetkisi vermek anlamına gelir. Docker daemon root olarak çalışır ve grup üyeleri bu daemon üzerinden sisteme tam erişim sağlayabilir. Bunu gerçekten düşünerek yapın.

Gruba Özel Ortam Değişkenleri

Bazı durumlarda belirli grupların farklı ortam değişkenlerine ihtiyacı olabilir. Bunu /etc/profile.d/ altında yönetebilirsiniz:

sudo nano /etc/profile.d/group-environments.sh

#!/bin/bash

# DBA ekibi için veritabanı ayarları
if id -nG "$USER" | grep -qw "dba"; then
    export PGHOST="db01.internal"
    export PGPORT="5432"
    export DB_BACKUP_PATH="/srv/projects/db_dumps"
fi

# Developers için geliştirme ortamı
if id -nG "$USER" | grep -qw "developers"; then
    export APP_ENV="development"
    export LOG_LEVEL="debug"
    export DEV_HOME="/srv/projects/app"
fi

# DevOps için yönetim araçları
if id -nG "$USER" | grep -qw "devops"; then
    export ANSIBLE_HOSTS="/etc/ansible/hosts"
    export TERRAFORM_DIR="/srv/terraform"
fi

Audit ile Grup Erişimlerini İzlemek

Güvenlik için sadece erişim vermek yetmez, kimlerin ne zaman neye eriştiğini de izlemelisiniz:

# auditd yükle
sudo apt install auditd

# Kritik dizine erişimi izle
sudo auditctl -w /srv/projects/config -p rwxa -k config-access
sudo auditctl -w /srv/projects/db_dumps -p rwxa -k db-access

# Grup değişikliklerini izle
sudo auditctl -w /etc/group -p wa -k group-changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers-changes

# Logları incele
sudo ausearch -k config-access | tail -20
sudo ausearch -k group-changes

Bu kuralları kalıcı yapmak için /etc/audit/rules.d/team-access.rules dosyasına ekleyin.

Sonuç

Grup tabanlı erişim kontrolü, Linux’un en güçlü ve en az kullanılan özelliklerinden biri. Çoğu sysadmin iş yoğunluğu nedeniyle “şimdilik sudo ver, sonra düzeltiriz” yolunu seçiyor. Bu yazıda gördüğünüz yapıyı baştan doğru kurarsanız, ilerleyen dönemlerde ciddi zaman ve baş ağrısından kurtulursunuz.

Özetlemek gerekirse: Gruplarınızı iş gereksinimlerine göre planlayın, SetGID bitini unutmayın, ACL’yi standart izinlerin yetersiz kaldığı yerlerde kullanın, sudo yetkilerini kullanıcı bazlı değil grup bazlı verin ve periyodik denetim yapın. Bu dört ilkeyi uygulayan bir sistem, hem güvenli hem de yönetimi kolay olacak.

Son bir not: Sisteminizi kurduktan sonra mutlaka test edin. Gerçek bir developer kullanıcısıyla giriş yapın, izinlerin beklediğiniz gibi çalıştığını doğrulayın. Kağıt üzerinde doğru görünen pek çok yapılandırma, gerçek kullanımda beklenmedik davranışlar sergileyebilir.

Linux’ta Grup Yönetimi ile Ekip Erişim Kontrolü