Uygulamanıza Rol Tabanlı Erişim Kontrolü (RBAC) Nasıl Eklenir

Rol tabanlı erişim kontrolü eklemek için her kullanıcıya bir veya daha fazla rol verin (örneğin yönetici, editör, görüntüleyici), her rolün hangi eylemleri yapabileceğini tanımlayın ve bu izinleri her istekte sunucuda kontrol edin — yalnızca düğmeleri gizleyerek değil. Ayrıca erişilen kaydın kullanıcının hesabına veya ekibine ait olup olmadığını kontrol edin. Veritabanınızda birkaç sabit rolle başlayın ve başka bir kullanıcının verisine doğrudan erişmeyi deneyerek test edin.

Kimlik doğrulama ve yetkilendirme

Karıştırılan iki kelime:

• Kimlik doğrulama, sen kimsin? sorusudur — oturum açma. Uygulamanıza giriş nasıl eklenir rehberine bakın.
• Yetkilendirme, neleri yapmaya iznin var? sorusudur — oturum açmış bir kullanıcının hangi sayfalara, kayıtlara ve eylemlere erişebileceği.

RBAC, yetkilendirmenin en yaygın yoludur. Önemlidir: Eylül 2026 itibarıyla Broken Access Control, OWASP Top 10:2025'te 1 numaradadır; bu, web uygulaması güvenlik risklerinin en ciddilerini listeleyen yaygın kullanılan listedir. Tipik hatalar, kullanıcıların URL'deki bir kimliği değiştirerek başkalarının kayıtlarını okuması ya da sıradan kullanıcıların yalnızca yöneticiye ait API rotalarını çağırmasıdır.

Bir model seçin

Pratikte çoğu uygulama iki şeyi birleştirir: hangi tür eylemleri yapabileceğini belirleyen roller ve hangi kayıtlar üzerinde işlem yapabileceğini belirleyen sahiplik. "Editörler yazıları düzenleyebilir" bir rol kuralıdır; "…kendi çalışma alanlarındaki yazılar" bir sahiplik kuralıdır. İkisine de ihtiyacınız var.

Düşündüğünüzden daha basit başlayın. Yönetici, üye ve görüntüleyici, şaşırtıcı sayıda uygulamayı karşılar. Bir rolü daha sonra bölmek, kimsenin anlamadığı on rolü çözmekten daha kolaydır.

Kod yazmadan önce rolleri tasarlayın

Önce düz bir dille bir izin tablosu yazın. Bu, yapay zekâ için spesifikasyon ve test planınız olarak da işe yarar:

Uç durumlara da karar verin: son sahip ayrılabilir mi? Bir yönetici sahibi çıkarabilir mi? Çıkarılan bir kullanıcı ne görür?

Adım adım

1. Önce çalışan bir oturum açma sistemine sahip olun

RBAC, kimlik doğrulamanın üzerinde durur. Sunucu, her isteği kimin yaptığını güvenilir şekilde bilmelidir; bir oturumdan ya da doğrulanmış bir belirteçten — asla tarayıcının istek gövdesinde gönderdiği bir kullanıcı kimliğinden değil.

2. Rolleri veritabanında saklayın

Tek bir ekip için bir uygulamada, kullanıcılarda bir role sütunu yeterlidir. Ekipler için bir üyelik tablosu kullanın:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Kullanıcıların normal bir profil güncellemesiyle kendi rollerini belirlemesine asla izin vermeyin. Rol değişiklikleri, ayrı ve izin kontrolü yapılan bir uç noktadan geçmelidir.

3. İzinleri sunucuda, tek bir yerde kontrol edin

Bir yardımcı fonksiyon yazın — örneğin can(user, 'projects.delete', project) gibi — ve veriyi okuyan ya da değiştiren her API rotasında, sunucu eyleminde ve arka plan görevinde çağırın. Tek bir merkezi fonksiyon, dağınık kontrollerden daha kolay incelenir ve test edilir. Varsayılan olarak reddedin: hiçbir kural bir eylemi izin vermiyorsa, o eylem reddedilir.

4. Her sorguyu kapsamlandırın

Ekip verisi için her sorgu ekibi içermelidir: yalnızca where id = :id değil, where organization_id = :currentOrg. Bu, birinin /projects/123 adresini /projects/124 olarak değiştirip başka bir şirketin projesini görmesini engeller. Başka ekiplerdeki kayıtlar için "yasak" yerine "bulunamadı" yanıtı verin; böylece kayıtların var olduğunu ortaya çıkarmazsınız.

5. Önemli yerlerde veritabanı düzeyinde koruma ekleyin

Postgres satır düzeyi güvenlik (RLS), veritabanının her kullanıcının hangi satırları görebileceğini zorunlu kılmasını sağlar. Tarayıcının veritabanıyla doğrudan konuştuğu durumlarda (bazı barındırılan arka uçlarda olduğu gibi) bu gereklidir; diğer durumlarda hassas tablolar için kullanışlı ikinci bir katmandır.

6. Rolleri arayüze yansıtın

Şimdi kullanıcıların yapamadığı şeyleri gizleyin veya devre dışı bırakın; böylece uygulama kafa karıştırıcı olmaz. Bu yalnızca kullanılabilirlik içindir; koruma işini sunucu kontrolleri yapar.

7. Hassas eylemleri kaydedin

Rolleri kimin değiştirdiğini, verileri veya dışa aktarılan kayıtları kimin sildiğini ve ne zaman yaptığını kaydedin. Bir denetim günlüğü, destek soruları ve olaylar için yardımcı olur.

8. Bir saldırgan gibi test edin

Her rol olarak oturum açın ve izin tablosundaki her eylemi deneyin. Sonra çalışmaması gereken şeyleri deneyin: görüntüleyici olarak yönetici API rotalarını çağırmak, URL'lerdeki ve isteklerdeki kimlikleri değiştirmek, son sahip olarak kendinizi çıkarmak. Kurallar yerleştikten sonra izin tablosu için otomatik testler yazmaya değer.

İşe yarayan istemler

Rol tabanlı erişim kontrolü ekle. Kuruluş başına roller: owner, admin, member, viewer; bir memberships tablosunda saklanır. İzinler şu tabloda: [tablonuzu yapıştırın]. Tek bir sunucu tarafı can(user, action, resource) yardımcısı oluştur, varsayılan olarak reddet ve her API rotasında kullan. Her sorguyu organization_id ile kapsamlandır. Kullanıcının yapamadığı eylemleri arayüzde gizle, ancak güvenlik için bunlara asla güvenme.

Bu uygulamadaki her API rotasını ve sunucu fonksiyonunu incele. Her biri için hangi verileri okuduğunu veya değiştirdiğini, kullanıcının oturum açıp açmadığını, rolünü kontrol edip etmediğini ve sorguyu kuruluşuna göre kapsamlandırıp kapsamlandırmadığını listele. Eksik kontrolü olanları düzelt ve listeyi göster.

Sahibin üyelerin rollerini değiştirebileceği yalnızca yöneticiye açık bir /admin sayfası ekle. Son sahibin kaldırılmasını veya düşürülmesini engelle, her rol değişikliğini kimin ve ne zaman yaptığıyla kaydet ve rol değiştirme uç noktasının sahip olmayan herkesi reddetmesini sağla.

Sık yapılan hatalar

• Rolleri yalnızca ön yüzde kontrol etmek. API yine de herkese açıktır; onu çağıran herkes erişebilir.
• İstemciden gelen kimliklere güvenmek — oturum yerine istek gövdesindeki bir userId veya role.
• Kapsamsız sorgular — kayıtları yalnızca kayıt kimliğiyle getirmek.
• Sayfalarda kontrol edilen ama API rotalarında, dışa aktarmalarda, dosya indirmelerinde veya webhook'larda kontrol edilmeyen roller.
• Kodda sabit yazılmış bir e-posta adresiyle yönetici (if email === 'me@...'); unutması kolay, değiştirmesi zordur.
• Çok erken çok fazla rol — altı ay sonra kimsenin açıklayamayacağı roller.
• Eski oturumlar: düşürülmüş bir kullanıcı, oturumu kapatana kadar yönetici haklarını korur. Hassas eylemlerde rolleri veritabanından kontrol edin veya yenileyin.

RBAC kontrol listesi

• İzin tablosu düz bir dille yazıldı, uç durumlar kararlaştırıldı
• Sunucu kullanıcıyı oturumdan tanır, asla istek verisinden değil
• Roller veritabanında saklanır; kullanıcılar kendi rollerini değiştiremez
• Tek bir merkezi izin kontrolü, varsayılan olarak reddeder ve her rotada kullanılır
• Her sorgu kullanıcının kuruluşuna veya sahipliğine göre kapsamlandırılmış
• Tarayıcının veritabanına erişebildiği yerlerde satır düzeyi güvenlik var
• Arayüz, kullanıcıların yapamayacağı şeyleri gizliyor (yalnızca kullanılabilirlik için)
• Hassas eylemler kaydediliyor
• Her rol test edildi; doğrudan API çağrıları ve değiştirilmiş kimlikler dahil

Erişim kontrolü, daha uzun bir listedeki bir maddedir; AI ile oluşturulmuş uygulamalar için güvenlik kontrol listesi geri kalanını kapsar. Kendi personeliniz için bir araç geliştiriyorsanız, dahili araç nasıl oluşturulur rollerin nereye uyduğunu gösterir.

Mythex'te RBAC

Mythex, uygulamanızın kullanıcıları için yerleşik bir oturum açma veya rol sistemi sunmaz. Bir kimlik doğrulama kütüphanesi veya sağlayıcı seçersiniz, rolleri tarif edersiniz ve agent bunları kodunuza ve projenizin Postgres veritabanına bağlar (uygulamanıza giriş ekleme). Mythex'in kendi çalışma alanı rolleri, örneğin Owner ve Member, Mythex projelerinizi kimin düzenleyebileceğini kontrol eder; yayınladığınız uygulamayı kimin kullanabileceğini değil. İzin tablosunu inşa etmeden önce Plan modunda kabul edin, ardından yukarıdaki inceleme istemini kullanın ve yayınlamadan önce Önizleme'de her rolü test edin. Dokümanlardaki güvenlik istemleri iyi bir devam kaynağıdır.

Sorular