From a65357856d57d8b5058d24c1abdaa35764c704fe Mon Sep 17 00:00:00 2001 From: Nilgun Belma Buguner Date: Fri, 18 Sep 2009 00:37:11 +0000 Subject: [PATCH] New Turkish translation MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Translated by: Umut Samuk Reviewed by: Nilgün Belma Bugüner git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@816420 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/auth.html.tr.utf8 | 607 +++++++++++++++++++++++++++ docs/manual/howto/auth.xml.tr | 614 ++++++++++++++++++++++++++++ 2 files changed, 1221 insertions(+) create mode 100644 docs/manual/howto/auth.html.tr.utf8 create mode 100644 docs/manual/howto/auth.xml.tr diff --git a/docs/manual/howto/auth.html.tr.utf8 b/docs/manual/howto/auth.html.tr.utf8 new file mode 100644 index 0000000000..90d6785393 --- /dev/null +++ b/docs/manual/howto/auth.html.tr.utf8 @@ -0,0 +1,607 @@ + + + +Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi - Apache HTTP Sunucusu + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.3

+
+
<-
+

Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi

+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
+ +

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.

+
+ +
top
+
+

İ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.

+ + + +

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.

+
top
+
+

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.

+
+ +
top
+
+

Ö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.

+ +
top
+
+

Ç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.confdosyası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ştir ve çok daha güvenlidir. Güncel tarayıcılar, Özet + (Digest) kimlik doğrulama yöntemini + desteklemektedir.

+ +

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 + 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.

+
top
+
+

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ı 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. Bu yaklaşımın getirisi: + Apache iki dosya yerine sadece bir dosyaya bakar. + Götürüsü ise parola dosyalarından oluşan bir dosya demeti sağlamak + ve AuthUserFile + yönergesinde doğru dosyayı belirtmeyi unutmamak zorunda + kalmanızdır.

+ +
top
+
+

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.

+ +
top
+
+

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 dbd 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.

+ +
top
+
+

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.

+ +
top
+
+

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
+ <RequireNone> + + Require ip 192.168.205
+ Require host phishers.example.com moreidiots.example
+ Require host ke + + </RequireNone> + + </RequireAll> +

+ +

Yukarıdaki örnekte, <RequireNone> yönergesi içindeki + Require + yönergelerinin değiştirgeleriyle hiçbir bir eşleşme olmaması + durumunda erişime izin verilir.

+ + + +

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.

+ + + +
top
+
+

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.

+
+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.xml.tr b/docs/manual/howto/auth.xml.tr new file mode 100644 index 0000000000..22dd2167ab --- /dev/null +++ b/docs/manual/howto/auth.xml.tr @@ -0,0 +1,614 @@ + + + + + + + + + + Nasıllar ve Öğreticiler + + Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi + + +

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.

+ + + + +
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.confdosyası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ştir ve çok daha güvenlidir. Güncel tarayıcılar, Özet + (Digest) kimlik doğrulama yöntemini + desteklemektedir.

+ +

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 + 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ı 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. Bu yaklaşımın getirisi: + Apache iki dosya yerine sadece bir dosyaya bakar. + Götürüsü ise parola dosyalarından oluşan bir dosya demeti sağlamak + ve AuthUserFile + yönergesinde doğru dosyayı belirtmeyi unutmamak zorunda + kalmanızdır.

+ +
+ +
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 dbd 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
+ <RequireNone> + + Require ip 192.168.205
+ Require host phishers.example.com moreidiots.example
+ Require host ke + + </RequireNone> + + </RequireAll> + + +

Yukarıdaki örnekte, RequireNone yönergesi içindeki + Require + yönergelerinin değiştirgeleriyle hiçbir bir eşleşme olmaması + durumunda erişime izin verilir.

+ +
+ +
+ 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.

+ +
+ +
+ +
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.

+
+ -- 2.40.0