Redis ACL ile Kullanıcı ve Yetki Yönetimi

default kullanıcı ve AUTH komutu

Her yeni bağlantı önce default adlı özel kullanıcıyla kimlik doğrulanmış sayılır. ACL WHOAMI komutu bağlantının o anki kullanıcı adını döndürür; hiç AUTH göndermemiş bir bağlantıda yanıt "default" olur. Belgedeki ACL LIST örneğinde bu kullanıcı user default on nopass ~* &* +@all satırıyla görünür: etkin, şifresiz, tüm anahtarlara ve kanallara erişebilen, tüm komutları çalıştırabilen bir kullanıcı. Yani ACL kurallarına hiç dokunmadığınız bir sunucuda bağlanan herkes her şeyi yapabilir.

AUTH komutunun iki biçimi vardır. Tek argümanlı eski biçim yalnızca şifre alır ve requirepass ayarıyla korunan sunucularda kullanılır; ACL etkinken bu biçim örtük olarak default kullanıcısını varsayar. İki argümanlı biçim ise AUTH kullanıcı şifre şeklindedir ve Redis 6.0 ile gelen ACL sistemindeki herhangi bir kullanıcıya geçmeyi sağlar. Doğrulama başarılıysa yanıt OK, değilse bir hatadır.

> ACL WHOAMI
"default"

redis-cli ile bağlanırken kimlik bilgilerini komut satırında verebilirsiniz: --user ve --pass seçenekleri kullanıcı adı ile şifreyi, --askpass ise şifreyi ekranda göstermeden istemi açarak alır. Belge, güvenlik nedeniyle şifrenin REDISCLI_AUTH ortam değişkeniyle verilmesini önerir; böylece şifre kabuk geçmişine ve süreç listesine düşmez. Bağlantı adresi biçimini tercih ederseniz redis://kullanıcı:şifre@sunucu:port/veritabanı kalıbı da kabul edilir. redis-cli seçeneklerinin tamamı redis-cli kullanımı yazısında anlatılıyor.

redis-cli --user uygulama --askpass
REDISCLI_AUTH="$REDIS_SIFRE" redis-cli --user uygulama PING

Bağlantı ilk komut olarak HELLO gönderiyorsa protokol sürümünü seçmek ve kimlik doğrulamak tek adımda yapılabilir: HELLO <sürüm> AUTH <kullanıcı> <şifre>. İstemci kütüphaneleri genellikle bu adımı bağlantı seçeneklerinden aldıkları bilgilerle kendileri yapar; bağlantı adresi ve havuz ayarları için bağlantı URL ve connection pool yazısına bakabilirsiniz.

ACL SETUSER nasıl çalışır

ACL SETUSER komutu verilen kullanıcı yoksa onu hiçbir yetkisi olmadan oluşturur, ardından argüman olarak gelen kuralları soldan sağa sırayla uygular. Kullanıcı zaten varsa yeni kurallar mevcut kuralların üzerine eklenir; eski kurallar silinmez. Bu yüzden aşağıdaki iki komutun sonunda virginia kullanıcısı hem SET hem GET çalıştırabilir:

ACL SETUSER virginia on allkeys +set
ACL SETUSER virginia +get

Bir kullanıcıyı önceki ayarlarından bağımsız olarak sıfırdan tanımlamak istediğinizde ilk kural olarak reset verin. Bu kural kullanıcıyı varsayılan hâline döndürür: etkin değil, şifresiz, hiçbir komutu çalıştıramayan, hiçbir anahtara ve kanala erişemeyen bir kullanıcı. Belgedeki örnek bunu açıkça gösterir:

> ACL SETUSER antirez reset
+OK
> ACL LIST
1) "user antirez off -@all"

Kurallar iki türdür: on, off, reset, allkeys gibi düz kelimeler ve bir özel karakterle başlayıp arada boşluk olmadan bir metinle devam edenler (+SET, ~nesne:*, >şifre). Tanınmayan bir kural yazarsanız komut hata döndürür ve kullanıcı değişmez:

> ACL SETUSER alan allkeys +@string +@set -SADD >alanpassword
+OK
> ACL SETUSER antirez heeyyyy
(error) ERR Error in ACL SETUSER modifier 'heeyyyy': Syntax error

İlk satırdaki kullanıcı tüm anahtarlara erişebilir, string ve set kategorisindeki komutları çalıştırabilir, ancak SADD sonradan çıkarıldığı için set'e eleman ekleyemez. Kuralların sırası önemlidir: önce kategoriyi ekleyip sonra tek komutu çıkarmak, kategorinin geri kalanını açık bırakır.

Kullanıcı yönetimi kuralları: on, off, şifreler

Bir kullanıcının birden fazla etkin şifresi olabilir. Bu, şifre değiştirmeyi kesintisiz yapmanın yoludur: önce >yeniŞifre ile yenisini eklersiniz, uygulamalarınızı yeni şifreye geçirirsiniz, en son <eskiŞifre ile eskisini kaldırırsınız. > ile verilen şifre sunucuda düz metin olarak saklanmaz; ACL LIST çıktısında # ile başlayan SHA256 özeti olarak görünür. Bir yapılandırma dosyasına şifrenin kendisini değil özetini yazmak istiyorsanız #özet biçimini kullanabilirsiniz.

Şifreyi elle seçmek yerine ACL GENPASS komutunu kullanın. Komut, varsayılan olarak 256 bitlik rastgele veriyi 64 onaltılık karakter olarak döndürür; isterseniz 1 ile 1024 arasında bir bit sayısı verebilirsiniz ve sayı her zaman bir sonraki 4'ün katına yuvarlanır. AUTH sayfasındaki güvenlik notu, Redis çok hızlı olduğu için kısa sürede çok sayıda şifrenin paralel denenebileceğini, bu yüzden uzun ve güçlü şifre gerektiğini vurgular.

> ACL GENPASS
"dd721260bfe1b3d9601e7fbab36de6d04e2e67b0ef1c53de59d45950db0dd3cc"

> ACL GENPASS 32
"355ef3dd"

> ACL GENPASS 5
"90"

Son örnekte 5 bit istenmiş, değer 8'e yuvarlandığı için iki onaltılık karakter dönmüştür. Çıktı her çağrıda farklıdır; yukarıdaki değerler belgedeki örnek çıktılardır.

Anahtar ve kanal desenleri

Komut izni tek başına yetmez; kullanıcının komutun dokunduğu anahtara da erişimi olmalıdır. ~desen kuralı KEYS komutundaki gibi glob tarzı bir deseni kullanıcının erişebileceği anahtarlar listesine ekler ve hem okuma hem yazma izni verir. Aynı kullanıcıya birden çok desen ekleyebilirsiniz. allkeys, ~* ile aynı anlamdadır; resetkeys ise tüm desenleri kaldırır.

Redis 7.0 ve sonrasında izinleri okuma ve yazma olarak ayırabilirsiniz: %R~desen yalnızca okuma, %W~desen yalnızca yazma izni verir; %RW~desen ise ~desen ile aynıdır. Örneğin bir raporlama servisine %R~siparis:* vermek, o servisin sipariş anahtarlarını okuyup değiştirememesini sağlar.

Pub/Sub kanalları için ayrı bir desen listesi vardır (Redis 6.2 ve sonrası): &desen kanalı ekler, allchannels &* ile aynıdır, resetchannels listeyi boşaltır. Mesajlaşma tarafı Redis Pub/Sub yazısında anlatılıyor; ACL tarafında bilmeniz gereken, yalnızca komut iznine bakıp kanal desenini unutmamaktır.

Komut ve kategori kuralları

+komut komutu izin listesine ekler, -komut çıkarır. Alt komutlar | ile seçilir: +config|get yalnızca CONFIG GET komutuna izin verir; Redis 7.0 ve sonrasında -config|set gibi alt komut engellemesi de yapılabilir. +@kategori ve -@kategori bir kategorideki tüm komutları birlikte ekler ya da çıkarır. allcommands, +@all ile aynıdır ve modüllerle sonradan yüklenecek komutları da kapsar; nocommands ise -@all ile aynıdır. +komut|ilk-argüman biçimi belgede kullanımdan kaldırılmış olarak işaretlidir; yeni kurallarda kullanmayın.

Hangi kategorilerin bulunduğunu ACL CAT gösterir. Belgedeki örnek çıktı şöyledir:

> ACL CAT
 1) "keyspace"
 2) "read"
 3) "write"
 4) "set"
 5) "sortedset"
 6) "list"
 7) "hash"
 8) "string"
 9) "bitmap"
10) "hyperloglog"
11) "geo"
12) "stream"
13) "pubsub"
14) "admin"
15) "fast"
16) "slow"
17) "blocking"
18) "dangerous"
19) "connection"
20) "transaction"
21) "scripting"
22) "json"
23) "search"
24) "tdigest"
25) "cms"
26) "bloom"
27) "cuckoo"
28) "topk"
29) "timeseries"

ACL CAT dangerous ise bir kategorideki komutları listeler. Belgedeki çıktıda bu kategoride flushdb, flushall, keys, config, client, monitor, debug, save, bgsave, bgrewriteaof, shutdown, info, slowlog, latency, acl, replicaof, migrate, restore ve sort gibi komutlar yer alır. Belgenin önerdiği yaygın kalıp +@all -@dangerous şeklindedir: kullanıcıya her şeyi verip sunucu kararlılığını etkileyebilecek komutları geri almak. Kategori içeriği sürüme göre değişebileceği için kendi sunucunuzda ACL CAT dangerous çıktısını kontrol edin.

Seçiciler: farklı anahtarlara farklı izinler

Redis 7.0 ile kurallar parantez içinde ayrı gruplar olarak da yazılabilir; bunlara seçici (selector) denir. Bir komutun çalışabilmesi için ya kök izinlerin (parantez dışındaki kurallar) ya da seçicilerden birinin komutla eşleşmesi gerekir. Seçiciler kök izinlerden sonra, tanımlandıkları sırayla değerlendirilir.

ACL SETUSER virginia on +GET allkeys (+SET ~app1*)

Bu tanımda kök izin her anahtarda GET çalıştırmaya izin verir; seçici ise yalnızca app1 ile başlayan anahtarlarda SET izni ekler. Böylece kullanıcı her yeri okuyabilir ama yalnızca kendi alanına yazabilir. clearselectors kuralı kullanıcıya bağlı tüm seçicileri siler.

Kullanıcıları incelemek: LIST, USERS, GETUSER, DRYRUN

ACL LIST etkin kuralları her kullanıcı için bir satır olarak, redis.conf ya da harici ACL dosyasındaki biçimle aynı şekilde döndürür. Belgedeki örnek:

> ACL LIST
1) "user antirez on #9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 ~objects:* &* +@all -@admin -@dangerous"
2) "user default on nopass ~* &* +@all"

Bazı çıktılarda &* yerine allchannels, ~* yerine allkeys görebilirsiniz; bunlar takma adlardır. Yalnızca kullanıcı adlarını görmek için ACL USERS yeterlidir. Tek bir kullanıcının bayraklarını, şifre özetlerini, komutlarını, anahtar ve kanal desenlerini ve seçicilerini ise ACL GETUSER verir; kullanıcı yoksa RESP2'de nil, RESP3'te null döner:

> ACL SETUSER sample on nopass +GET allkeys &* (+SET ~key2)
"OK"
> ACL GETUSER sample
1) "flags"
2) 1) "on"
   2) "allkeys"
   3) "nopass"
3) "passwords"
4) (empty array)
5) "commands"
6) "+@all"
7) "keys"
8) "~*"
9) "channels"
10) "&*"
11) "selectors"
12) 1) 1) "commands"
       6) "+SET"
       7) "keys"
       8) "~key2"
       9) "channels"
       10) "&*"

Belge, ACL GETUSER çıktısının kullanıcının etkin izinlerini yansıttığını, bu yüzden tanımlarken yazdığınız kurallarla birebir aynı olmayabileceğini ama işlevsel olarak eşdeğer olduğunu belirtir. Bir kuralın gerçekten ne yaptığını görmenin en kolay yolu ise ACL DRYRUN komutudur: kullanıcıyı etkinleştirmeden ve komutun yan etkisini oluşturmadan, o kullanıcının bir komutu çalıştırıp çalıştıramayacağını simüle eder.

> ACL SETUSER VIRGINIA +SET ~*
"OK"
> ACL DRYRUN VIRGINIA SET foo bar
"OK"
> ACL DRYRUN VIRGINIA GET foo
"User VIRGINIA has no permissions to run the 'get' command"

Uygulamalı örnek: üç rolle kullanıcı tasarımı

Tipik bir web uygulaması için üç kullanıcı düşünelim: uygulamanın kendisi, sadece okuyan bir raporlama servisi ve sunucuyu izleyen bir araç. Aşağıdaki komutlar belgedeki kurallarla yazılmış kendi örneğimizdir; her biri başarılı olduğunda basit metin yanıtı OK döner. Şifre yerine ACL GENPASS çıktısını kullanın.

ACL SETUSER uygulama reset on >UZUN_RASTGELE_SIFRE_1 ~uygulama:* &bildirim:* +@read +@write -@dangerous
ACL SETUSER rapor reset on >UZUN_RASTGELE_SIFRE_2 %R~uygulama:* +@read -@dangerous
ACL SETUSER izleme reset on >UZUN_RASTGELE_SIFRE_3 +ping +info +config|get
ACL DRYRUN uygulama SET uygulama:sepet:7 x
ACL DRYRUN rapor SET uygulama:sepet:7 x

Her satır reset ile başladığı için komutu tekrar çalıştırmak kuralları çoğaltmaz, kullanıcıyı baştan tanımlar. uygulama kullanıcısında -@dangerous en sonda olduğu için, +@write ile gelen FLUSHDB gibi komutlar geri alınır. rapor kullanıcısı %R~ deseni nedeniyle anahtarları okuyabilir ama yazamaz; ikinci DRYRUN bu yüzden izin verilmediğini anlatan bir metin döndürmelidir. izleme kullanıcısına hiçbir anahtar deseni verilmedi; INFO ve PING anahtar almadığı için bu kullanıcı sunucuyu izleyebilir ama veriye dokunamaz. INFO çıktısını yorumlamak için INFO komutu yazısına bakın.

NOAUTH, WRONGPASS ve NOPERM hataları

Üç hata, kimlik doğrulama zincirinin üç farklı halkasını gösterir. NOAUTH, sunucu şifre istediği hâlde bağlantının henüz kimlik doğrulamadığı anlamına gelir; bu durumda sunucu PING dahil neredeyse her komutu reddeder.

> GET mykey
(error) NOAUTH Authentication required.
> AUTH <password>
OK
> GET mykey
"value"

WRONGPASS, AUTH ya da HELLO başarısız olduğunda döner. Güvenlik gereği mesaj üç durumda da aynıdır: şifre yanlıştır, kullanıcı yoktur ya da kullanıcı vardır ama off durumundadır. Hatanın tam metni WRONGPASS invalid username-password pair or user is disabled. şeklindedir. Belge önce uygulamanın kullandığı kimlik bilgilerini (başka ortamdan gelen şifre, sonda kalan boşluk ya da satır sonu, eksik kullanıcı adı) kontrol etmeyi, sonra ACL USERS ve ACL GETUSER ile kullanıcının varlığına ve off bayrağına bakmayı önerir. Kullanıcı adı verilmeyen AUTH, default kullanıcısının şifresini denetler.

NOPERM ise kimlik doğrulaması başarılı olmuş bir kullanıcının kurallarının istenen işleme izin vermediğini söyler. Mesaj neyin reddedildiğini belirtir: komut mu, anahtar mı.

> ACL SETUSER app on ><password> +get ~allowed:*
OK
> AUTH app <password>
OK
> SET allowed:1 "x"
(error) NOPERM User app has no permissions to run the 'set' command
> GET other
(error) NOPERM No permissions to access a key

NOPERM aldığınızda izlenecek yol belgede üç adımdır: yönetici olarak ACL LOG ile neyin reddedildiğini bulun, uygulamanın hangi kullanıcıyla bağlı olduğunu ACL WHOAMI ile kontrol edin, ardından ya yetkili bir kullanıcıyla bağlanın ya da kuralı ACL SETUSER ile genişletin. Diğer yaygın Redis hataları için hata mesajları yazısına bakabilirsiniz.

ACL LOG ile reddedilen istekleri izlemek

ACL LOG, son güvenlik olaylarını en yeniden eskiye doğru listeler: AUTH ya da HELLO ile başarısız girişler (reason değeri auth), izin verilmeyen komutlar (command), anahtarlar (key) ve kanallar (channel). Argüman verilmezse en fazla on kayıt döner; bir sayı vererek miktarı seçebilir, RESET ile kaydı temizleyebilirsiniz.

> AUTH someuser wrongpassword
(error) WRONGPASS invalid username-password pair
> ACL LOG 1
1)  1) "count"
    2) (integer) 1
    3) "reason"
    4) "auth"
    5) "context"
    6) "toplevel"
    7) "object"
    8) "AUTH"
    9) "username"
   10) "someuser"
   11) "age-seconds"
   12) "8.038"
   13) "client-info"
   14) "id=3 addr=127.0.0.1:57275 laddr=127.0.0.1:6379 fd=8 name= age=16 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=48 qbuf-free=16842 argv-mem=25 multi-mem=0 rbs=1024 rbp=0 obl=0 oll=0 omem=0 tot-mem=18737 events=r cmd=auth user=default redir=-1 resp=2"
   15) "entry-id"
   16) (integer) 0
   17) "timestamp-created"
   18) (integer) 1675361492408
   19) "timestamp-last-updated"
   20) (integer) 1675361492408

count alanı 60 saniyelik bir pencerede bu kayda toplanan olay sayısıdır; aynı hatayı tekrarlayan bir istemci log'u doldurmaz, sayaç artar. context olayın nerede yaşandığını (toplevel, multi, lua, module), object erişilemeyen kaynağı, client-info ise olaya yol açan bağlantının CLIENT LIST biçimindeki bilgisini verir. entry-id sunucu başladığından beri artan sıra numarasıdır; aradaki boşluklar kaybolan kayıtları fark etmenizi sağlar. Toplam sayıları INFO stats bölümündeki acl_access_denied_auth, acl_access_denied_cmd, acl_access_denied_key ve acl_access_denied_channel alanlarından da izleyebilirsiniz.

Kullanıcıyı kapatmak ve silmek

ACL SETUSER kullanıcı off yeni girişleri engeller, ancak o kullanıcıyla zaten kimlik doğrulamış bağlantılar çalışmaya devam eder. Bu bağlantıları da kesmek için CLIENT KILL USER kullanıcı filtresini kullanabilirsiniz; ayrıntılar CLIENT LIST ve CLIENT KILL yazısında. Diğer yol ACL DELUSER ile kullanıcıyı silmektir: bu komut kullanıcıyla doğrulanmış tüm bağlantıları da sonlandırır ve silinen kullanıcı sayısını tamsayı olarak döndürür. Listede olmayan adlar sessizce atlanır; default kullanıcısı ise hiçbir zaman silinemez.

> ACL DELUSER antirez
1

Kalıcılık: ACL SAVE ve ACL LOAD

ACL SETUSER ile yaptığınız değişiklikler bellektedir. Sunucu aclfile seçeneğiyle harici bir ACL dosyası kullanacak şekilde yapılandırılmışsa ACL SAVE bellekteki kuralları bu dosyaya yazar. Dosya yazılamıyorsa ya da sunucu harici ACL dosyası kullanmıyorsa komut hata döndürür; belgedeki örnekte bu hata sunucu günlüğüne bakmanızı söyler.

ACL LOAD ise ters yönde çalışır ve "ya hep ya hiç" davranışı gösterir: dosyadaki her satır geçerliyse tüm kurallar yüklenir, bir satır bile hatalıysa hiçbir şey yüklenmez ve bellekteki eski kurallar kullanılmaya devam eder. Redis 8.8 ile ACL dosyasında # ile başlayan yorum satırlarına izin verildi; ancak bu yorumlar yükleme sırasında atılır ve ACL LOAD ile ACL SAVE döngüsünden sonra korunmaz. Belge, yorumları saklamanın tek yolunun dosyanın yedeğini tutmak olduğunu belirtir.

> ACL LOAD
+OK

> ACL LOAD
-ERR /tmp/foo:1: Unknown command or category name in ACL...

ACL dosyasının nasıl yapılandırılacağı resmî belgelerde yönetim (operate) bölümündedir ve bu yazının kaynağı olan geliştirici belgelerinin dışında kalır. Burada bilmeniz gereken, ACL LIST çıktısının bu dosyayla aynı biçimde olduğu ve değişikliklerinizi kalıcı yapmak için ACL SAVE komutunu çalıştırmanız gerektiğidir.

Ağ erişimi ve protected mode

ACL kuralları, sunucuya kimin bağlanabileceğini ağ düzeyinde sınırlamaz. Redis'te protected mode varsayılan olarak açıktır: bu mod etkinken ve default kullanıcının şifresi yokken sunucu yalnızca kendi bilgisayarından (127.0.0.1 ya da ::1) gelen bağlantıları kabul eder, diğerlerine DENIED hatası gönderip bağlantıyı kapatır. Belgenin önerdiği en güvenli çözüm protected mode'u kapatmak değil, şifre koymaktır. Protected mode'u kapatmayı yalnızca güvenilir bir ağda test ederken ve sunucunun internetten erişilemediğinden emin olduğunuzda düşünün. DENIED hatasının ayrıntısı OOM, MISCONF ve READONLY hataları yazısında, ağ katmanında erişimi kısıtlamak için güvenlik duvarı yazısında.

Sık yapılan hatalar

• Mevcut kullanıcıyı reset olmadan güncellemek: kurallar eklenir, eski izinler kalır. Rolü baştan tanımlamak istiyorsanız ilk kural reset olsun.
• Kategoriyi en sona eklemek: -@dangerous +@all sırası tehlikeli komutları geri açar. Kısıtlayan kural, açan kuraldan sonra gelmelidir.
• Komut iznini verip anahtar desenini unutmak: kullanıcı GET çalıştırabilir ama her anahtarda NOPERM No permissions to access a key alır.
• Kullanıcıyı off yapınca bağlantıların kesildiğini sanmak: mevcut oturumlar sürer; CLIENT KILL USER ya da ACL DELUSER gerekir.
• ACL SAVE çalıştırmamak: aclfile kullanılan bir sunucuda yeniden başlatmadan sonra bellekteki değişiklikler kaybolur.
• Şifreyi -a ile komut satırına yazmak: belge şifrenin REDISCLI_AUTH ortam değişkeniyle verilmesini önerir.

Sık Sorulan Sorular

ACL ile requirepass arasındaki fark nedir?

requirepass tek bir sunucu şifresi tanımlar ve tek argümanlı AUTH şifre ile kullanılır. ACL sisteminde ise birden çok kullanıcı, her birinin kendi şifreleri ve kendi komut, anahtar, kanal izinleri vardır. ACL etkinken tek argümanlı AUTH örtük olarak default kullanıcısını kullanır.

default kullanıcısını silebilir miyim?

Hayır. ACL DELUSER belgesine göre her yeni bağlantının kimlik doğruladığı default kullanıcısı sistemden kaldırılamaz. Ona şifre koymak, DENIED hatası sayfasında gösterildiği gibi CONFIG SET requirepass ile yapılabilir; kalıcı olması için aynı değeri yapılandırma dosyasına da yazmanız gerekir.

Bir kullanıcının belirli bir komutu çalıştırıp çalıştıramayacağını nasıl test ederim?

ACL DRYRUN kullanıcı komut argümanlar kullanın. Komut gerçekten çalışmaz, yan etki oluşmaz ve kullanıcının etkin olması gerekmez. İzin varsa OK, yoksa nedenini anlatan bir metin döner.

ACL değişikliği yeniden başlatmada kaybolur mu?

ACL SETUSER değişiklikleri bellektedir. Sunucu harici bir ACL dosyası (aclfile) kullanıyorsa ACL SAVE ile dosyaya yazmadığınız sürece yeniden başlatmada dosyadaki eski kurallar geçerli olur.

Hangi kullanıcıların sürekli yanlış şifre denediğini nasıl görürüm?

ACL LOG çıktısında reason değeri auth olan kayıtlara bakın; username denenen kullanıcıyı, client-info içindeki addr bağlantının adresini, count ise 60 saniyelik pencerede kaç deneme yapıldığını gösterir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Redis öğrenme rehberi · CLIENT LIST ve CLIENT KILL · CONFIG GET, SET ve REWRITE · OOM, MISCONF ve DENIED hataları · Güvenlik duvarı nedir