Apache HTTP Sunucusu Sürüm 2.4
Kimlik Doğrulama ve Yetkilendirme
Kimlik Doğrulama istediğiniz kişileri teyid etme işlemidir. Yetkilendirme ise kişilerin nereye gireceklerine ve hangi bilgiye ulaşacaklarına müsaade edilmesi işlemidir.
Genel erişim denetimi için Erişim Denetimi Nasıl belgesine bakınız.
İlgili modüller ve Yönergeler
Kimlik Doğrulama ve yetkilendirme işlemi ile ilgili üç tür modül vardır. Genellikle her bir gruptan en az bir modül seçeceksiniz.
- Kimlik Doğrulama türü (bkz.
AuthType
yönergesi) - Kimlik Doğrulayıcı (bkz.
AuthBasicProvider
veAuthDigestProvider
yönergeleri) - Yetkilendirme (bkz.
Require
yönergesi)
Bu modüllere ek olarak, mod_authn_core
ve
mod_authz_core
modülleri bulunur. Bu modüller
yetkilendirme modüllerinin çekirdeğini oluşturan temel yönergeleri
gerçekler.
mod_authnz_ldap
modülü kimlik doğrulama ve
yetkilendirme işlemlerinin ikisini birden gerçekleştirir.
mod_authz_host
modülü bu işlemleri sunucu adına, IP
adresine ve isteğin karekteristiğine bağlı olarak gerçekleştirir.
Ancak kimlik doğrulama sisteminin bir parçası değildir.
mod_access
ile geriye uyumluluk için
mod_access_compat
diye bir modül daha vardır.
Muhtemelen göz atmak isteyeceğiniz Erişim Denetimi nasıl belgesi, sunucuya erişimlerin çeşitli yollarından bahsetmektedir.
Giriş
Sitenizde sadece küçük bir grup insana hitap eden ya da hassas bilgileriniz varsa, bu makaledeki teknikleri kullanarak dilediğiniz kişilerin sadece dilediğiniz sayfaları görüntülemesini sağlayabilirsiniz.
Bu makale sitenizin bazı parçalarını korumak için kullanacağınız "standart" yolları içermektedir.
Bilginize:
Eğer bilgileriniz gerçekten gizliliğe ihtiyaç duyuyorsa kimlik
doğrulamasına ilaveten mod_ssl
modülünü de
kullanabilirsiniz.
Ön gereksinimler
Bu makalede bahsi geçen yönergeler ya ana sunucu yapılandırma
dosyasında (genellikle <Directory>
bölümünde) ya da dizin içi
yapılandırma dosyalarında (.htaccess
dosyaları)
bulunmak zorundadır.
Eğer .htaccess
dosyalarını kullanmayı
tasarlıyorsanız, kimlik doğrulama yönergelerine bu dosyaların içine
koymaya izin veren sunucu yapılandırmasına ihtiyacınız olacaktır.
Bunun için, dizin içi yapılandırma dosyalarının içine hangi
yönergelerin konacağını belirleyen AllowOverride
yönergesi kullanılır.
Kimlik doğrulamadan sözettiğimize göre, aşağıda gösterilen
şekilde bir AllowOverride
yönergesine ihtiyacınız olacaktır:
AllowOverride AuthConfig
Yönergeleri doğrudan ana sunucunun yapılandırma dosyasına koyacaksanız bu dosyaya yazma izniniz olmalıdır.
Bazı dosyaların nerede saklandığını bilmek için sunucunun dizin yapısı hakkında biraz bilgi sahibi olmanız gerekmektedir. Bu çok da zor olmamakla birlikte bu noktaya gelindiğinde konuyu netleştireceğiz.
Ayrıca mod_authn_core
ve
mod_authz_core
modülleri ya httpd
çalıştırılabilirinin içinde derlenmiş olmalı ya da
httpd.conf
yapılandırma dosyası ile yüklenmelidir. Bu
iki modül HTTP sunucusunda kimlik doğrulama ve yetkilendirme
kullanımı ve yapılandırması için büyük öneme sahip temel yönergeleri
ve işlevselliği sağlar.
Çalışmaya Başlama
Burada, sunucu üzerindeki bir dizini parolayla korumak için gereken temel bilgiler verilecektir.
İlk olarak bir parola dosyası oluşturmalısınız. Bunu nasıl yapacağınız, özellikle, seçtiğiniz kimlik doğrulayıcıya göre değişiklik gösterir. Bunun üzerinde ileride daha fazla duracağız. Başlangıç için parolaları bir metin dosyasında tutacağız.
Bu dosya belge kök dizini altında olmamalıdır. Böylece başkaları
parola dosyasını indiremezler. Örneğin belgeleriniz
/usr/local/apache/htdocs
üzerinden sunuluyorsa parola
dosyanızı /usr/local/apache/passwd
dizininde
tutabilirsiniz.
Dosyayı oluşturmak için Apache ile gelen
htpasswd
uygulamasını kullanacağız. Bu uygulama
Apache'nin kurulumunda belirtilen bin
dizininde
bulunur. Eğer Apache'yi üçüncü parti paketlerden kurduysanız,
çalıştırılabilir dosyaların bulunduğu yollar üzerinde olmalıdır.
Bir dosya oluşturmak için şunları yazın:
htpasswd -c /usr/local/apache/passwd/passwords umut
htpasswd
size parola soracaktır arkasından da
teyit etmek için parolayı tekrar girmenizi isteyecektir:
# htpasswd -c /usr/local/apache/passwd/passwords umut
New password: parolam
Re-type new password: parolam
Adding password for user umut
Eğer htpasswd
normal yollar üzerinde değilse
çalıştırmak için dosyanın bulunduğu tam yeri belirtmeniz
gerekecektir. Dosyanın öntanımlı kurulum yeri:
/usr/local/apache2/bin/htpasswd
Bundan sonra, sunucuyu, parola sorması için ve kimlerin erişim
izni olacağını belirlemek için yapılandıracaksınız. Bu işlemi
httpd.conf
dosyasını düzenleyerek ya da bir
.htaccess
dosyası kullanarak yapabilirsiniz. Örneğin,
/usr/local/apache/htdocs/secret
dizinini korumayı
amaçlıyorsanız, şu yönergeleri kullanabilirsiniz. Bu yönergeleri
/usr/local/apache/htdocs/secret/.htaccess
dosyası içine
veya httpd.conf
içindeki <Directory
"/usr/local/apache/htdocs/secret"> bölümüne koyabilirsiniz.
AuthType Basic AuthName "Gizli Dosyalar" # (Aşağıdaki satırın kullanımı isteğe bağlıdır) AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" Require user umut
Bu yönergeleri tek tek inceleyelim.
AuthType
yönergesi
kullanıcının kimliğini doğrulamakta kullanılacak yöntemi seçer. En
çok kullanılan yöntem Basic
'tir ve bu yöntem
mod_auth_basic
modülüyle gerçeklenmiştir. Temel
(Basic
) kimlik doğrulamasıyla gönderilen parolanın
şifrelenmeyeceğini unutmayın. Bu yöntem, bu sebepten dolayı
mod_ssl
eşliğinde kullanılmadığı sürece yüksek
hassasiyete sahip bilgiler için kullanılmamalıdır. Apache bir başka
kimlik doğrulama yöntemini daha destekler: AuthType
Digest
. Bu yöntem mod_auth_digest
tarafından
gerçeklenmişti ve çok daha güvenli olacağı düşünülmüştü. Bu artık
geçerliliğini yitirdiğinden bağlantının bundan böyle
mod_ssl
ile şifrelenmesi gerekmektedir.
AuthName
yönergesi
ile kimlik doğrulamada kullanılacak Saha da
belirtilebilir. Saha kullanımının, başlıca iki işlevi vardır.
Birincisi, istemci sıklıkla bu bilgiyi kullanıcıya parola diyalog
kutusunun bir parçası olarak sunar. İkincisi, belirtilen kimlik
doğrulamalı alan için gönderilecek parolayı belirlerken istemci
tarafından kullanılır.
Örneğin, bir istemcinin "Gizli Dosyalar"
alanında
kimliği doğrulanmış olsun. Aynı sunucu üzerinde "Gizli
Dosyalar"
Sahası olarak belirlenmiş alanlarda aynı parola
özdevinimli olarak yinelenecektir. Böylece parola bir kere girilerek
aynı Sahayı paylaşan çok sayıda kısıtlanmış alana ulaşırken oluşacak
gecikmeden kullanıcı korunmuş olur. Güvenlik gerekçelerinden dolayı,
her sunucu adı değiştirilişinde istemcinin parolayı yeniden sorması
gerekir.
AuthBasicProvider
yönergesinin öntanımlı değeri file
olduğundan, bu
durumda, bu yönergenin kullanımı isteğe bağlıdır. Ancak, eğer kimlik
doğrulaması için mod_authn_dbm
ya da
mod_authn_dbd
gibi farklı bir kaynak seçecekseniz
bu yönergeyi kullanmanız gerekecektir.
AuthUserFile
yönergesi htpasswd
ile oluşturduğumuz parola
dosyasının yerini belirtmek için kullanılır. Eğer çok sayıda
kullanıcınız varsa her bir kullanıcıyı her kimlik doğrulama isteği
için kimlik bilgilerini bir metin dosyasında aramak gayet yavaş
olacaktır. Apache, kullanıcı bilgilerini hızlı bir veritabanı
dosyasında depolama özelliğine de sahiptir. Bu amaçla,
mod_authn_dbm
modülünün
AuthDBMUserFile
yönergesi kullanılabilir. Bu dosyalar dbmmanage
ve
htdbm
programı ile oluşturulabilir ve değiştirilebilir.
Apache modülleri
Veritabanı içindeki üçüncü parti modüllerinde çok sayıda
başka kimlik doğrulama türü de vardır.
Son olarak Require
yönergesi, sunucunun bu bölgesine erişimine izin verilen
kullanıcıları ayarlama işleminin kimlik doğrulamasıyla ilgili
kısmını sağlar. Bir sonraki bölümde Require
yönergesini kullanmanın
çeşitli yoları üzerinde duracağız.
Birden çok kişiye izin vermek
Yukarıdaki yönergelerle bir dizinde sadece bir kişiye
(umut
adlı kullanıcıya) izin verir. Çoğunlukla birden
çok kişiye izin verilmesi istenir. Bu durumda AuthGroupFile
yönergesi
devreye girer.
Eğer birden çok kişiye izin vermek istiyorsanız içinde kullanıcı isimlerinin olduğu bir grup dosyası oluşturmalısınız. Bu dosyanın biçemi gayet basittir ve bunu herhangi bir metin düzenleyici ile oluşturabilirsiniz. Bu dosyanın içeriği aşağıdaki gibi görünecektir:
GroupName: umut samet engin kubilay
Dosya, sadece, boşluklarla birbirinden ayrılmış gurup üyelerinin isimlerinden oluşan uzun bir liste içerir.
Varolan parola dosyasına bir kullanıcı eklemek için şunu yazın:
htpasswd /usr/local/apache/passwd/passwords birey
Evvelce almış olduğunuz yanıtı yine alacaksınız ama bu sefer yeni
bir dosya oluşturulmak yerine var olan bir dosyaya eklenecektir.
(Yeni bir parola dosyası oluşturmak için -c
seçeneği
kullanılır).
Şimdi, .htaccess
dosyanızı veya
<Directory>
bölümünüzü
aşağıda görüldüğü şekilde değiştirebilirsiniz:
AuthType Basic AuthName "Davete Binaen" # Satır isteğe bağlıdır: AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Require group Grupismi
Artık, Grupismi
gurubunda listelenmiş ve
password
dosyasında kaydı olan kişiye, parolayı doğru
yazdığı takdirde izin verilecektir.
Çoklu kullanıcıya izin veren biraz daha az kullanılan başka bir yol daha mevcuttur. Bir gurup dosyası oluşturmaktansa, şu yönergeyi kullanabilirsiniz:
Require valid-user
Require user umut
satırı ile parola dosyasında
listelenmiş ve parolayı doğru olarak giren herhangi bir kişiye izin
vermektense, her grup için ayrı bir parola dosyası tutarak grup
davranışını taklit edebilirsiniz.
Olası Sorunlar
Temel kimlik doğrulama yolu belirtildiği için, sunucuya yaptığınız her belge istediğinde kullanıcı adınızın ve parolanızın doğrulanması gerekir. Hatta aynı sayfayı yeniden yüklerken ya da sayfadaki her bir resim için bu yapılmalıdır (şayet korunmakta olan bir dizinden geliyorsa). Bu işlem hızı azaltacaktır. Yavaşlama miktarı parola dosyanızın büyüklüğü ile orantılı olacaktır, çünkü bu işlem sırasında dosya açılacak ve kullanıcıların arasında isminiz bulunana kadar liste aşağı doğru taranacaktır. Bu işlem sayfa her yüklenişinde tekrar edilecektir.
Buradan çıkacak sonuç, bir parola dosyasına konulan kullanıcı sayısında bir üst sınır olması gerekliliğidir. Bu sınır sunucunuzun başarımına bağlı olarak değişiklik gösterir. Bir kaç yüz kayıtın üstünde giriş yaptığınızda hız düşüşünü gözlemlebilirsiniz İşte bu anda kimlik doğrulama için başka bir yöntem aramaya başlarsınız.
Diğer parola depolama yöntemleri
Parolaları basit bir metin dosyasında depolamak yukarıda bahsedilen sorunlara yol açtığından parolaları başka bir yerde depolamayı düşünebilirsiniz; örneğin bir veritabanında.
mod_authn_dbm
ve mod_authn_dbd
modülleri bunu mümkün kılan iki modüldür. Depolama yönemi olarak
AuthBasicProvider
file yerine, dbm
veya dbd
kullanabilirsiniz.
Bir metin dosyası yerine bir dbm dosyası kullanım örneği:
<Directory "/www/docs/private"> AuthName "Private" AuthType Basic AuthBasicProvider dbm AuthDBMUserFile "/www/passwords/passwd.dbm" Require valid-user </Directory>
Başka seçenekler de mümkündür. Ayrınılar için
mod_authn_dbm
belgesine başvurun.
Birden çok tedarikçi kullanmak
Kimlik doğrulama ve yetkilendirme mimarisine dayalı yeni tedarikçiyi kullanarak tek bir yetkilendirme ya da kimlik doğrulama yöntemine kilitlenip kalmayacaksınız. Aslında birden çok tedarikçi ihtiyacınıza cevap vermek için bir arada kullanılabilir. Aşağıdaki örnekte dosya ve LDAP tabanlı kimlik doğrulama tedarikçileri bir arada kullanılmıştır.
<Directory "/www/docs/private"> AuthName "Private" AuthType Basic AuthBasicProvider file ldap AuthUserFile "/usr/local/apache/passwd/passwords" AuthLDAPURL ldap://ldaphost/o=yourorg Require valid-user </Directory>
Bu örnekte dosya tedarikçisi, ilk olarak kullanıcının kimliğini doğrulamaya teşebbüs edecektir. Kullanıcının kimliği doğrulanamıyorsa LDAP tedarikçisi çağırılır. Eğer kurumunuz birden çok kimlik doğrulama tedarikçisini yürürlüğe koyuyorsa bu, kimlik doğrulama faaliyet alanının genişletilmesini sağlar. Diğer kimlik kanıtlama ve yetkilendirme senaryoları tek bir kimlik doğrulaması ile birden fazla yetkilendirme türüne izin verebilir.
Çok sayıda kimlik doğrulama tedarikçisi uygulamaya konulabileceği gibi, çok sayıda yetkilendirme yöntemi de kullanılabilir. Bu örnekte dosya için hem dosyalı hem de LDAP grup kimlik doğrulaması kullanılmıştır.
<Directory "/www/docs/private"> AuthName "Private" AuthType Basic AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthLDAPURL ldap://ldaphost/o=yourorg AuthGroupFile "/usr/local/apache/passwd/groups" Require group GroupName Require ldap-group cn=mygroup,o=yourorg </Directory>
Kimlik doğrulama konusunu biraz daha genişletirsek, <RequireAll>
ve
<RequireAny>
gibi yetkilendirme taşıyıcısı
yönergelerle hangi iznin hangi sırayla uygulanacağını
belirlenebilir. Yetkilendirme Taşıyıcıları bölümünde bunun bir uygulama
örneğini görebilirsiniz.
Yetkilendirmenin biraz ötesi
Tek bir veri deposundan yapılacak tek bir sınamadan çok daha esnek kimlik doğrulaması yapılabilir. Sıralama, mantık ve hangi kimlik doğrulamasının kullanılacağını seçmek mümkündür.
Mantık ve sıralamanın uygulanması
Yetkilendirmenin hangi sırayla uygulanacağı ve nasıl
denetleneceği geçmişte biraz gizemli bir konuydu. Apache 2.2'de,
tedarikçi tabanlı kimlik doğrulamasının devreye girmesiyle asıl
kimlik doğrulama işlemini yetkilendirme ve destek işlevselliğinden
ayırmak mümkün oldu. Bunun faydalarından birisi de kimlik
doğrulama tedarikçilerinin yapılandırılabilmesi ve auth modülünün
kendi yükleme sırasından bağımsız olarak özel bir sırayla
çağrılabilmesidir. Bu tedarikçi tabanlı mekanizmanın aynısı
yetkilendirmeye de getirilmiştir. Bunun anlamı Require
yönergesinde hangi
izin yönteminin kullanılması gerektiğinin belirtmesinin yanında
hangi sırayla çağırılacaklarının da belirlenebildiğidir. Çok
sayıda yetkilendirme yöntemi kullanıldığında, bunlar, Require
yönergelerinin
yapılandırma dosyasında göründükleri sıra ile çağırılır.
<RequireAll>
ve <RequireAny>
gibi yetkilendirme
taşıyıcısı yönergelerin devreye girmesiyle yetkilendirme
yöntemlerinin ne zaman çağırılacağı ve çağırıldığında ve erişime
izin verirken hangi kuralların uygulanacağı konusunda denetim
yapılandırmanın eline geçmektedir. Karmaşık yetkilendime mantığını
ifade etmek için kullanılan bir örneği görmek için
Yetkilendirme
Taşıyıcıları bölümüne bakınız.
Öntanımlı olarak tüm
Require
yönergeleri, <RequireAny>
taşıyıcı yönergesinin içine konur. Başka bir deyişle eğer
belirtilen kimlik doğrulama yöntemlerinden herhangi biri başarılı
olursa yetkilendirme de sağlanmış olur.
Erişim denetimi için yetkilendirme tedarikçilerinin kullanımı
Kullanıcı adı ve parolasına göre kimlik doğrulama hikayenin sadece bir bölümüdür. Sıklıkla insanlara kim olduklarına göre değil birşeylere dayanarak izin vermek istersiniz. Örneğin nereden geldikleri gibi.
all
, env
, host
ve
ip
gibi yetkilendirme tedarikçileri ile, bir belgenin
istendiği makinenin IP adresi veya konak ismi gibi bazı özelliklerine
dayalı olarak erişime izin verip vermeyeceğinizi belirtebilirsiniz.
Bu tedarikçilerin kullanımı Require
yönergesinde açıklanmıştır. Bu yönergeler,
isteklerin işlenmesi sırasında yetkilendirme aşamasında
çağırılacak yetkilendirme tedarikçilerini kayda geçirir. Örneğin:
Require ip adres
Burada, adres bir IP adresidir (veya kısmi bir IP addresidir)
Require host alan_adı
Burada, alan_adı bir tam nitelikli alan adıdır (ya da kısmi alan adıdır); gerekirse çok sayıda alan adı veya IP adresi de belirtilebilir.
Örneğin, yorum alanını gereksiz iletilerle dolduran birini uzak tutmak istediğinizi varsayalım. Bu kişiyi uzak tutmak için şunları yapabilirsiniz:
<RequireAll> Require all granted Require not ip 10.252.46.165 </RequireAll>
Bu adresden gelen ziyaretçiler bu yönergedeki içeriği göremeyeceklerdir. Bunun yerine, elinizde IP adresi değil de makine adı varsa şunu kullanabilirsiniz:
<RequireAll> Require all granted Require not host host.example.com </RequireAll>
Eğer alan adının tamanıdan gelecek olan bütün erişimleri engellemek isterseniz adresin ya da alan adının bir parçasını belirtin:
<RequireAll> Require all granted Require not ip 192.168.205 Require not host phishers.example.com moreidiots.example Require not host ke </RequireAll>
<RequireAll>
yönergesini çok sayıda
<Require>
yönergesi ile birlikte kullanarak,
sadece not
ile olumsuzlanan tüm koşulları gerçekleyen
bağlantılara erişim verilir. Başka bir deyişle, olumsuzlanan koşulları
gerçeklemeyen bağlantıların erişimi engellenir.
Erişim denetimi ve geriye uyumluluk
Kimlik doğrulama için tedarik tabanlı mekanizma kullanımının
yan etkilerinden birisi,
Order
,
Allow
,
Deny
ve
Satisfy
erişim
denetim yönergelerine artık ihtiyaç duyulmamasıdır. Ancak eski
yapılandırmalarla uyumluluğu sağlamak için bu yönergeler
mod_access_compat
modülüne taşınmıştır.
Note
mod_access_compat
ile sağlanan yönergelerin
kullanımı artık önerilmemekte, mod_authz_host
modülündeki yönergeler önerilmektedir. Order
, Allow
veya Deny
ile
Require
gibi daha yeni
olanlarının yenilerle karışık kullanımı teknik olarak mümkünse de
önerilmemektedir. mod_access_compat
modülü, 2.4
yükseltmesini kolaylaştırmak için sadece eski yönergeleri içeren
yapılandırmaları desteklemek üzere oluşturulmuştur. Daha ayrıntılı
bilgi için yükseltme belgesine bakınız.
Kimlik Doğrulama Arabelleği
Zaman zaman kimlik doğrulama ağınızda veya sağlayıcı(ları)nızda kabul
edilemez yükler oluşturur. Bu çoğunlukla mod_authn_dbd
(veya üçüncü parti/özel sağlayıcıların) kullanıcılarını etkiler. Bununla
ilgilenmek için httpd 2.3/2.4, kimlik bilgilerini arabelleklemek ve özgün
sağlayıcıların yüklerini azaltmak için yeni bir arabellekleme sağlayıcısı
olarak mod_authn_socache
modülü ile gelmektedir.
Bu, bazı kullanıcılar için önemli bir başarım artışı sağlayabilir.
Daha fazla bilgi
Daha fazla bilgi için mod_auth_basic
ve
mod_authz_host
modüllerinin belgelerine bakınız.
AuthnProviderAlias
yönergesi ile bazı yapılandırmalarınızı basitleştirebilirsiniz.
Apache tarafından desteklenen şifrelerle ilgili bilgi için Parola Biçemleri belgesine bakınız.
Erişim Denetimi nasıl belgesinden de bazı bilgiler edinebilirsiniz.