Kimlik doğrulama ve yetkilendirme, güvenlik literatüründe en sık karıştırılan iki kavramdır. İkisi arka arkaya çalışır ama farklı soruları yanıtlar: kimlik doğrulama “sen kimsin?”, yetkilendirme “bunu yapmaya iznin var mı?” sorusunu sorar.

Sıralama önemlidir. Bir sistem önce kullanıcının iddia ettiği kimliği doğrular, ardından o kimliğe tanımlı hakları kontrol eder. Doğrulanmamış bir kimliğe yetki verilmesi ya da doğrulanmış her kimliğin her şeye erişebilmesi, iki ayrı ciddi tasarım hatasıdır.

Kimlik Doğrulama ve Yetkilendirme Farkı Nedir?

Kimlik doğrulama (authentication) kullanıcının kim olduğunu kanıtlama sürecidir; yetkilendirme (authorization) ise doğrulanmış kimliğin hangi kaynaklara, hangi düzeyde erişebileceğine karar verme sürecidir.

Üçüncü bir kavram olan kimlik belirleme (identification) de sürece dahildir: kullanıcının kim olduğunu iddia etmesi. Kullanıcı adını yazmak kimlik belirlemedir, parolayı doğru girmek kimlik doğrulamadır, o hesapla ilgili dosyayı açabilmek ise yetkilendirmedir.

Kimlik Doğrulama Nasıl Yapılır?

Kimlik doğrulama üç faktör ailesine dayanır: bildiğin bir şey (parola), sahip olduğun bir şey (donanım anahtarı, telefon) ve olduğun bir şey (parmak izi, yüz). Bu ailelerden ikisinin birlikte kullanılması çok faktörlü kimlik doğrulama olarak adlandırılır ve parola merkezli saldırıların büyük kısmını etkisiz kılar.

• Bildiğin bir şey: parola, PIN, güvenlik sorusu
• Sahip olduğun bir şey: donanım anahtarı, telefon, akıllı kart
• Olduğun bir şey: parmak izi, yüz, ses gibi biyometrik veriler
• Bağlam bilgisi: konum, cihaz sağlığı, davranış örüntüsü

Modern sistemlerde doğrulama tek seferlik bir kapı olmaktan çıkıp sürekli değerlendirilen bir güven seviyesine dönüşmüştür. Oturum sırasında cihazın uyumu bozulur ya da olağandışı bir konumdan istek gelirse, kullanıcıdan yeniden doğrulama istenebilir.

Yetkilendirme Nasıl Çalışır?

Yetkilendirme, doğrulanmış kimliğe hangi hakların tanındığını belirler. En yaygın model rol tabanlı erişim kontrolüdür; kullanıcılar rollere, roller izinlere bağlanır. Daha esnek senaryolarda özniteliklere göre karar veren modeller kullanılır: kullanıcının departmanı, verinin gizlilik sınıfı ve erişim saati birlikte değerlendirilir.

Yetkilendirmenin en az yetki ilkesine göre kurulması esastır. Kullanıcıya işini yapması için gereken en dar yetki verilir, geçici ihtiyaçlar için süreli haklar tanımlanır ve haklar düzenli olarak gözden geçirilir.

Karıştırıldığında Ne Olur?

İki kavramın karıştırılması gerçek zafiyetler doğurur. Bir uygulamanın kullanıcıyı doğrulayıp ardından yetki kontrolü yapmaması, saldırganın kendi hesabıyla başkasının verisine ulaşmasına yol açar; bu, IDOR ve bozuk erişim kontrolü zafiyetlerinin özüdür.

Sağlıklı bir tasarımda her istek için yetki kontrolü sunucu tarafında yeniden yapılır. Arayüzde butonun gizlenmesi yetkilendirme değildir; yetki kararı her zaman güvenilen tarafta verilmelidir. API’lerde bu kural daha da kritiktir, çünkü istemci tamamen saldırganın kontrolündedir.

Uygulamada Nelere Dikkat Edilir?

Kimlik doğrulama ve yetkilendirme kararlarının kaydı tutulmalıdır: kim, ne zaman, hangi kaynağa erişti ve hangi istek reddedildi. Reddedilen istekler çoğu zaman başarılı olanlardan daha değerlidir; bir hesabın sürekli yetkisi olmayan kaynakları denemesi, ele geçirilmiş olabileceğinin ilk işaretidir.

Kimlik Doğrulamada Güç Seviyeleri

Her doğrulama yöntemi aynı güveni sağlamaz. NIST SP 800-63 bu farkı kimlik doğrulama güvence seviyeleriyle tanımlar: tek faktörlü bir parola en alt seviyede kalırken, donanım tabanlı kriptografik bir anahtarla yapılan doğrulama en üst seviyeyi karşılar. Kurumlar hangi sistemin hangi seviyeyi gerektirdiğini önceden belirler.

Seviyelendirme pratik bir fayda sağlar: her uygulamaya aynı ağır doğrulamayı dayatmak kullanıcıyı yorar ve gölge çözümlere iter. İnternete açık yönetim panelinde donanım anahtarı zorunlu tutulurken, iç ağdaki düşük riskli bir uygulamada tek faktör yeterli görülebilir.

Kimlik avına dayanıklılık da bu seçimde belirleyicidir. SMS ile gönderilen tek kullanımlık kodlar araya girme saldırılarına açıktır; FIDO2 ve geçiş anahtarı gibi yöntemler ise kimlik bilgisini siteye bağladığı için bu saldırı sınıfını yapısal olarak engeller.

SSO, OAuth ve Yetkilendirme İlişkisi

Modern uygulamalarda kimlik doğrulama ve yetkilendirme çoğu zaman ayrı sistemlere devredilir. Tek oturum açma çözümleri kimliği bir kez doğrular ve uygulamalara güvenilir bir kimlik iddiası taşır. OAuth 2.0 ise aslında bir yetkilendirme protokolüdür: kullanıcının kimliğini kanıtlamaktan çok, bir uygulamaya sınırlı bir erişim izni vermeyi düzenler.

Bu ayrımın atlanması yaygın bir tasarım hatasıdır. OAuth erişim belirteci elde etmek, kullanıcının kimliğini doğrulamış olmak anlamına gelmez; kimlik doğrulama için OpenID Connect gibi bir katman gerekir. Belirteçlerin kapsamı dar tutulmalı, süresi sınırlandırılmalı ve her uygulama yalnızca ihtiyaç duyduğu izni istemelidir.

Sık Yapılan Hatalar

• Yetki kontrolünü yalnızca arayüzde yapmak, sunucu tarafında tekrarlamamak
• Kimliği doğrulanan her kullanıcıyı otomatik olarak yetkili saymak
• Yönetici yetkisini gündelik hesaplarda taşımak
• Belirteç ve oturum sürelerini gereğinden uzun tutmak
• Servis hesaplarına insan hesaplarıyla aynı geniş hakları vermek

Bu hataların ortak noktası, güvenin yanlış yerde kurulmasıdır. Güven kararı her zaman kontrol edilebilen tarafta verilmeli; istemciden gelen hiçbir bilgi doğrulanmadan yetki gerekçesi sayılmamalıdır.

Ayrıca oturum yönetimi ihmal edilmemelidir. Oturum kimliklerinin güvenli üretilmesi, çıkışta gerçekten sonlandırılması ve makul sürelerde zaman aşımına uğraması, doğrulama ve yetkilendirmenin sürdürülebilirliğini sağlar.