ACL Nedir? Dosyadan Buluta Erişim Kontrol Listesi

ACL (Access Control List, erişim kontrol listesi), bir kaynağa kimin ya da neyin, hangi işlemle erişebileceğini sırayla yazan kurallar listesidir. Aynı fikir bir dosyanın izinlerinde, switch’in yönetim erişiminde, firewall kurallarında ve buluttaki ağ kurallarında karşınıza çıkar. Bu yazıda ACL’yi üç katmanda lab’da ölçüyorum: Linux ve Windows’ta dosya izni, bir switch’in yönetim erişimi. Bulut tarafını da sağlayıcının kendi belgesinden gösteriyorum.

Bir süpermarket şubesinin deposuna açılan kapıda bir görevli ve bir liste durur. Görevli gelen kişinin adını listede yukarıdan aşağı arar ve ilk bulduğu satır ne diyorsa onu yapar. Listede adı hiç olmayan içeri giremez. ACL’nin her katmandaki davranışı budur: liste, sıra ve listede olmayana ret.

Bu yazı siber güvenlik önlemleri rehberimizin erişim kontrolü katmanına aittir ve Siber Güvenlik hizmetimizin temel kavramlarından birini açar. Switch tarafındaki uygulaması switch yapılandırma rehberimizin 8. adımıdır.

ACL Nedir? Her Katmanda Aynı Üç Kural

ACL, bir kaynağa gelen her erişim isteğini sırayla okunan satırlarla karşılaştırıp izin ya da ret kararı veren kurallar listesidir. Bir ACL’nin her satırı üç şey söyler: kim (bir kullanıcı, bir grup ya da bir IP adresi), ne (okumak, yazmak, SSH ile bağlanmak) ve karar (izin ya da ret). Satırlar bir araya gelince liste olur ve liste üç kuralla işler:

1. Liste sırayla okunur. İsteğe uyan ilk satır kararı verir, gerisine bakılmaz.
2. Listede olmayan reddedilir. Hiçbir satıra uymayan istek için yazılı olmayan bir ret geçerlidir. Buna örtük ret (implicit deny) denir.
3. Liste bir kaynağa bağlanınca çalışır. Bir dosyaya, bir switch’in yönetim servislerine ya da bir alt ağa bağlanmamış liste hiçbir şeyi korumaz.

Bu üç kural dosya sisteminden buluta kadar değişmez. Değişen tek şey sıranın nasıl belirlendiğidir; aşağıda üç katmanda bunun üç ayrı biçimini göreceğiz.

ACL Neden Her Katmanda Karşınıza Çıkar?

ACL’yi bir ağ cihazı ayarı sanmak kolaydır, çünkü adı en çok router ve switch yapılandırmasında geçer. Oysa aynı mantık bir sistem yöneticisinin gününün büyük kısmını da belirler. Bir dosya sunucusunda muhasebe klasörünü kimin açabileceği bir ACL’dir; bunun kişiye değil gruba verilmesi gerektiğini dosya sunucusu yazımızda anlattık. Active Directory’de bir kullanıcının başka bir nesnenin izinlerini değiştirebilmesi de bir ACL kaydıdır ve yanlış verildiğinde gizli yönetici yetkisine dönüşür.

Ağ tarafında firewall’un kural tablosu, internetten gelen trafiğe uygulanan bir ACL’dir; firewall kurulumu yazımızda bu kuralların nasıl yazıldığını anlattık. Aynı sıra kuralının bir FortiGate’te nasıl işlediğini, genel bir iznin altında kalıp hiç çalışmayan ret kuralıyla birlikte FortiGate Firewall policy yapılandırması yazımızda ölçtüm. Bulutta bir alt ağa giren trafiği süzen ağ kuralları da aynı yapıdadır.

Bu yüzden ACL bir ürün özelliği değil, bir düşünme biçimidir: erişimi varsayılan olarak kapat, gerekeni tek tek aç ve listeyi sırasıyla oku. Sistem yöneticisi de, ağ yöneticisi de, bulutta çalışan ekip de aynı hatayı aynı yerden yapar. Hatalar ya sırada ya da listede unutulan bir satırda saklıdır.

Dosya Sisteminde ACL: Linux ve Windows

Linux’ta Tek Kişiye İzin: setfacl ve getfacl

Linux’ta her dosyanın klasik izinleri üç kişilik bir listedir: sahip, grup ve geri kalan herkes. Dosyayı üçüncü birine açmak için ya grubu değiştirmek ya da herkese açmak gerekir. ACL bu üç satırın arasına yeni satırlar eklemeyi sağlar.

Lab’daki Ubuntu sunucusunda yalnız root’un okuyabildiği bir dosya açtım ve normal bir kullanıcıyla okumayı denedim:

$ ls -l /srv/acl-ornek/rapor.txt
-rw-r----- 1 root root 12 Sep 23 15:41 /srv/acl-ornek/rapor.txt
$ cat /srv/acl-ornek/rapor.txt
cat: /srv/acl-ornek/rapor.txt: Permission denied

İlk denemede setfacl komutu bulunamadı. Lab sunucusunda (Ubuntu Server 24.04) ACL araçları kurulu değildi ve acl paketini kurmam gerekti (sudo apt-get install acl). Paketi kurduktan sonra yalnız bu kullanıcıya okuma izni ekledim:

$ sudo setfacl -m u:sercebilisim:r /srv/acl-ornek/rapor.txt
$ ls -l /srv/acl-ornek/rapor.txt
-rw-r-----+ 1 root root 12 Sep 23 15:41 /srv/acl-ornek/rapor.txt
$ cat /srv/acl-ornek/rapor.txt
gizli rapor
$ getfacl /srv/acl-ornek/rapor.txt
# file: srv/acl-ornek/rapor.txt
# owner: root
# group: root
user::rw-
user:sercebilisim:r--
group::r--
mask::r--
other::---

Bu çıktıda üç satır önemli:

1. ls -l sonundaki +, dosyada klasik izinlerin dışında bir ACL olduğunu söyler. Bu işareti görmeyen biri dosyanın yalnız sahibine ve grubuna açık olduğunu sanır.
2. user:sercebilisim:r--, eklediğim satırdır: bu kullanıcı okuyabilir, yazamaz.
3. other::---, listenin geri kalanı içindir. Aynı dosyayı syslog kullanıcısıyla okumayı denediğimde yine Permission denied geldi; listede adı olmayan için kapı kapalı kaldı.

Windows’ta NTFS ACL: Açık Ret Kalıtımı Yener

Windows’ta her dosyanın ve klasörün ACL’si ACE denen kayıtlardan oluşur ve çoğu kayıt üst klasörden kalıtımla gelir. Listenin tamamını arayüzden görmek için klasöre sağ tıklayıp Properties’i açın, Security sekmesinde Advanced’e basın. Lab’daki domain controller’da C:\Raporlar klasörü için açılan pencere şu:

Aynı listeyi komut satırında icacls verir. Komutu aynı klasörde çalıştırdım:

icacls C:\Raporlar

C:\Raporlar BUILTIN\Administrators:(F)
            NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
            BUILTIN\Administrators:(I)(OI)(CI)(F)
            BUILTIN\Users:(I)(OI)(CI)(RX)
            BUILTIN\Users:(I)(CI)(AD)
            BUILTIN\Users:(I)(CI)(WD)
            CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

İki liste aynı klasörü anlatıyor, ama satırları birebir örtüşmüyor ve fark öğretici:

1. Pencere altı, komut yedi satır verir. Users için komutta ayrı duran iki hak, AD (alt klasör oluşturma) ve WD (dosya oluşturma), pencerede tek bir Special satırında birleşir. Pencere okunaklı olsun diye kayıtları birleştirir; tek bir kaydı incelerken komuta bakılır.
2. (I) işareti Inherited from sütunudur. Komutta (I) taşıyan altı satır pencerede C:\’den gelir. İşaret taşımayan tek satır, ilk Administrators kaydı, pencerede None gösterir: o hak bu klasöre özel yazılmıştır.
3. Kalan işaretler Applies to sütunudur. Kaydın klasörün altındaki nesnelere de geçip geçmeyeceğini söylerler:

OI kaydın dosyalara, CI alt klasörlere geçtiğini söyler; IO ise kaydın klasörün kendisine uygulanmadığını, yalnız altına aktarıldığını gösterir.

Açık bir reddin bu listede nasıl çalıştığını görmek için iş istasyonumda bir deneme dosyası açıp listesini okudum:

icacls C:\Users\ilker\lab\acl-nedir\ntfs-ornek\rapor.txt

C:\Users\ilker\lab\acl-nedir\ntfs-ornek\rapor.txt NT AUTHORITY\SYSTEM:(I)(F)
                                                  BUILTIN\Administrators:(I)(F)
                                                  ILKER-EV\ilker:(I)(F)

Successfully processed 1 files; Failed processing 0 files

Üç kaydın üçü de kalıtımla gelmiş ve tam denetim (F) veriyor. Kendi kullanıcım dosyaya tam yetkili ve yazma denemesi başarılı oldu. Sonra aynı kullanıcı için açık bir yazma reddi ekledim:

icacls C:\Users\ilker\lab\acl-nedir\ntfs-ornek\rapor.txt /deny ilker:(W)

C:\Users\ilker\lab\acl-nedir\ntfs-ornek\rapor.txt ILKER-EV\ilker:(DENY)(W)
                                                  NT AUTHORITY\SYSTEM:(I)(F)
                                                  BUILTIN\Administrators:(I)(F)
                                                  ILKER-EV\ilker:(I)(F)

Successfully processed 1 files; Failed processing 0 files

Ret kaydı listenin en üstüne yerleşti ve yazma denemesi erişim reddedildi ile döndü. Kalıtımla gelen tam yetki, açıkça yazılmış retten sonra değerlendirildi. Microsoft’un belgesi bu sırayı böyle tanımlar: sistem kayıtları sırayla okur, açık kayıtlar kalıtımla gelenlerden, retler de izinlerden önce gelir (Order of ACEs in a DACL).

Ölçümde beklemediğim bir şey de oldu: yalnız yazmayı reddetmiştim ama dosyayı okumak da reddedildi. Get-Acl ile kaydın haklarına baktım:

IdentityReference      AccessControlType   FileSystemRights IsInherited
-----------------      -----------------   ---------------- -----------
ILKER-EV\ilker                      Deny Write, Synchronize       False
...

Ret kaydı yazmanın yanında Synchronize hakkını da reddediyor. Microsoft’un dosya erişim hakları belgesi bunun nedenini açıkça yazar: dosyalarda okuma ve yazmanın genel eşlemesi ikisi de SYNCHRONIZE hakkını içerir, bu yüzden yazmayı reddeden bir kayıt okuma isteğini de düşürür. Belgenin önerisi de açıktır: ret kaydı yazmak yerine yalnız izin verilen hakları izin kaydı olarak yazın (File Security and Access Rights).

Bu öneri ACL’nin genel ilkesiyle aynı yere çıkıyor. Reddetmek yerine izin verilecek olanı yazın, geri kalanını listenin dışında bırakın.

Ağ Cihazında ACL: Switch’in Yönetim Erişimini Daraltmak

Switch’in yönetim erişimi varsayılan olarak ağdaki her adrese açıktır: SSH portuna ulaşabilen herkes giriş ekranını görür. Yönetim erişim listesi bunu yalnız belirli adreslere indirir. Listenin switch’te adım adım nasıl kurulduğunu, bağlanınca açık oturumlara ne olduğunu ve reddedilen denemenin günlükte iz bırakıp bırakmadığını switch ACL yapılandırması yazımızda ölçtüm; burada yalnız üç kuralın switch’teki görünüşü var.

Lab switch’imde yalnız iş istasyonumun adresinden SSH’a izin veren bir liste yazıp yönetim erişimine bağladım. Switch listeyi gösterirken örtük reddi kendisi yazıyor:

gmsw01#show management access-list YONETIM-ACL
YONETIM-ACL
-----------
permit ip-source 192.168.1.115 mask 255.255.255.255 service ssh priority 10
! (Note: all other access implicitly denied)

İş istasyonumdan yeni bir SSH oturumu sorunsuz açıldı. Listede olmayan bir kaynaktan, lab’daki Linux sunucusundan ise durum şöyleydi:

$ ssh -o BatchMode=yes -o ConnectTimeout=10 gmsw01 exit
ssh: connect to host 192.168.1.2 port 22: Connection timed out
$ ping -c 2 -W 2 192.168.1.2 | tail -2
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 8.046/13.603/19.160/5.557 ms

SSH isteğine hiçbir cevap gelmedi; switch isteği sessizce düşürdü ve istemci, benim ayarladığım on saniyelik bekleme süresinin sonunda vazgeçti. Aynı sunucudan ping ise cevap aldı, çünkü bu liste yalnız yönetim servislerini kapsıyor. Ping’in cevap vermesi bir servisin açık olduğunu kanıtlamaz; bunun neden böyle olduğunu ICMP makalemizde anlattık.

Kural Sırası: Aynı İki Kural, Ters Sonuç

Bu switch’te sıra, her kuralın priority numarasıyla belirleniyor. Linux sunucusu için aynı adrese bir izin ve bir ret kuralı yazıp iki sıralamayı denedim. İlk denemede ret, izinden önce geliyordu:

deny ip-source 192.168.1.46 mask 255.255.255.255 service ssh priority 5
permit ip-source 192.168.1.115 mask 255.255.255.255 service ssh priority 10
permit ip-source 192.168.1.46 mask 255.255.255.255 service ssh priority 20
! (Note: all other access implicitly denied)

Sunucunun SSH isteği Connection timed out ile düştü. İkinci denemede aynı ret kuralını izinden sonraya, 30 numarasına koydum ve sunucu switch’in gmsw01> istemine ulaştı. Kuralların içeriği iki denemede de aynıydı, yalnız sıraları değişti. Depo kapısındaki görevli de listede adı hem “girebilir” hem “giremez” diye iki kez geçen kişi için yukarıdan ilk okuduğu satıra uyar.

Bağlı bir listenin neden düzenlenemediğini ve kurallara numarayı nasıl vereceğinizi switch ACL yapılandırması yazımızın değişiklik bölümünde anlattım.

Bulutta ACL: Sıra Aynı, Durum Farklı

Bulutta bu düzeni kendim kurmadım; aşağıdaki bilgiler bir bulut sağlayıcısının kendi belgesinden. Amazon Web Services’te bir alt ağa giren ve çıkan trafiği süzen listeye network ACL denir. Belge, kuralların numara sırasıyla okunduğunu açıkça yazar: kurallar en küçük numaradan başlayarak değerlendirilir ve trafik bir kurala uyduğu anda o kural uygulanır, sonrakilere bakılmaz. Aynı belge kurallara 10 ya da 100’lük artışlarla numara vermeyi önerir, böylece araya sonradan kural eklenebilir (Control subnet traffic with network ACLs).

Kural yazma rehberi, lab switch’inde ölçtüğüm sıra kuralını bir öneri olarak da yazar: geniş bir port aralığına izin verip içinden bazı portları reddedecekseniz, ret kuralına geniş izinden daha küçük bir numara verin (Network ACL rules).

Bulutun getirdiği fark durum takibidir. Belgeye göre network ACL’ler durumsuzdur (stateless): bir alt ağa gelen trafiğe izin verdiğinizde o trafiğin cevabına kendiliğinden izin verilmez, dönüş için ayrı bir kural gerekir. Aynı sağlayıcının güvenlik grupları (security group) ise durum takibi yapar (stateful) ve izin verilen isteğin cevabını kendiliğinden geçirir. İki yaklaşımın farkını aynı istekle lab’da ölçtüğüm firewall yazımızda görebilirsiniz. Durumsuz bir listede yalnız gelen yönü düşünüp dönüşü unutmak, bulutta en kolay yapılan ACL hatasıdır.

ACL’de Sık Yapılan Hatalar

• Kendini kilitlemek. Yönetim erişim listesine kendi adresinizi yazmadan listeyi bağlamak yeni bağlantılarınızı keser; lab switch’imde açık oturum sürdü. O oturumu kapatmadan düzeltin ve konsol erişiminin çalıştığından emin olun.
• Otomatik işleri unutmak. Yedek, izleme ve envanter betikleri de birer kaynaktır; lab’da yalnız kendime izin verdiğim listede yedek betiği switch’e ulaşamadı.
• Sırayı gözden kaçırmak. Dar bir ret, onu kapsayan geniş bir izinden sonra gelirse hiç çalışmaz.
• Reddetmeyi izin vermekle karıştırmak. Windows’ta yazmayı reddeden bir kayıt okumayı da düşürdü; izin verilecek olanı yazmak, reddedilecek olanı saymaktan güvenlidir.
• Ping’i kanıt saymak. Listenin kapsamadığı ICMP cevap verirken SSH düşebilir. “Ping gidiyor ama bağlanamıyorum” şikâyetinin nedeni bir ACL olabilir.
• Durumsuz listede dönüşü unutmak. Durum takibi yapmayan bir listede gelen trafiğe izin vermek, cevabın dönmesi için yetmez.
• Görünmeyen izni kaçırmak. Linux’ta ls -l çıktısındaki + işareti dosyada ek bir liste olduğunu söyler; bu işarete bakmayan biri dosyanın kime açık olduğunu yanlış okur.

Sonuç: Erişimi Kapat, Gerekeni Aç, Listeyi Sırasıyla Oku

ACL; dosya izninde, switch’in yönetim erişiminde, firewall kuralında ve bulutun alt ağ kuralında aynı üç kuralla çalışır. Liste sırayla okunur, listede olmayan reddedilir ve liste ancak bir kaynağa bağlandığında korur. Lab’da aynı iki kuralın sırası değişince sonuç tersine döndü. Windows’ta yazmayı reddeden bir kayıt okumayı da düşürdü, switch’e yazılan listede de otomatik yedek işi dışarıda kaldı.

Depo kapısındaki görevli listeye yukarıdan bakar ve adı olmayanı içeri almaz. Bir ACL yazarken sorulacak iki soru da hep aynıdır. Bu listeye kimi yazmayı unuttum? Bu satır doğru yerde mi?

ACL’nin katmanlı güvenlik içindeki yerini siber güvenlik önlemleri rehberimizde anlattık. Switch’te yönetim erişimini daraltmanın bir switch’i canlıya alma sırasındaki yeri switch yapılandırma rehberimizde duruyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn