Rol motoru

1) Yetkilendirme modelleri

RBAC (Rol Tabanlı Erişim Denetimi): özne rolleri alır, roller izinlerle ilişkilendirilir. Sadece idare et, tipik görevler için iyi.
ABAC (Öznitelik Tabanlı Erişim Kontrolü) - çözüm, öznenin, kaynağın, eylemin ve ortamın (zaman, IP, bölge, risk) niteliklerine bağlıdır. Esnek ve karmaşık kurallara ölçeklenebilir.
RBAC + ABAC hibrid: roller "temel'bir yetenek verir, nitelikler onu daraltır (koşullar).
(İsteğe bağlı) ReBAC/İlişki tabanlı: ilişki grafiği (sahip, ekip üyesi, temsilci), belgeler ve orglar için kullanışlıdır.

2) Mimari: PDP/PEP ve akışları

PEP (Policy Enforcement Point): çözümün uygulandığı yer (API ağ geçidi, arka uç yöntemi, SQL katmanı, UI).
PDP (Policy Decision Point - Politika Karar Noktası): 'ALLOW/DENY' değerini politikalar ve özniteliklerle hesaplayan hizmet/kitaplık.
PIP (Policy Information Point): öznitelik kaynakları (IdP/profil, kaynak meta verileri, risk oranı, coğrafi).
PAP (Policy Administration Point) - yönetim arayüzü/politika deposu (sürümler, taslaklar, yayınlar).

Akış: PEP - istek bir bağlam oluşturur - PDP eksik nitelikleri çeker (PIP aracılığıyla) - kararı hesaplar - PEP uygular (alanları etkinleştir/devre dışı bırak/kes) - denetim.

3) Veri modeli

• 'subject' (kullanıcı/hizmet) с атрибутами: 'tenant _ id', 'roles', 'departments', 'risk _ level', 'mfa _ verified', 'scopes', 'claims'.
• Tür ve niteliklere sahip 'resource': 'type', 'owner _ id', 'tenant _ id', 'classification' (public/confidential), 'region', 'tags'.
• 'eylem': 'okuma', 'yazma', 'silme', 'dışa aktarma', 'onaylama', 'kimliğe bürünme' и т. п.
• 'çevre': 'zaman', 'ip', 'cihaz', 'geo', 'auth _ strength', 'business _ context' (канал, тариф).

• 'roles (id, tenant_id, isim, miras [])' - hiyerarşileri ve kalıpları destekler.
• 'hatalar (id, resource_type, eylem, kısıtlama?)'.
• 'role _ permissions (role_id, permission_id)'.
• 'assignments (subject_id, role_id, scope)' - scope: global/by project/by object.

• 'politika (id, effect = allow' deny, target: {subject, resource, action}, condition: expr, priority, version, status) '.

4) Karar verme ilkeleri

Deny-overrides: Açık yasaklar izinlere öncelik verir.
En Az Ayrıcalık (PoLP): Minimum gerekli erişimi verin, koşullar aracılığıyla genişletin.
Görevlerin Ayrılması (SoD): Rol/eylem kombinasyonlarının yasaklanması (örneğin, "yaratılmış ödeme" ≠ "tutuklanan").
Bağlam bilinci: Gereksinimleri daha yüksek risk altında güçlendirin (MFA yok, şüpheli IP).
Determinizm: aynı bağlam - aynı yanıt; Politika versiyonunu kaydedin.

5) Uygulama kalıpları

5. 1 Hibrid RBAC - ABAC (şartlandırma)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Sıra/Alan Düzeyinde Güvenlik

Veritabanı düzeyinde: RLS ilkeleri ('tenant _ id', 'owner _ id'ile).
API düzeyinde: 'allow: read_sensitive_fields'' yoksa koleksiyonları ve maske alanlarını filtreleyin.

5. 3 Adım adım çözümler

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Geçici toleranslar

TTL ile hibe: 'ödev. expires_at', "pencerelere" erişin (kaynak bölgesinin çalışma saatlerinde).

6) Performans ve önbelleğe alma

Kısa TTL ile '(subject_hash, resource_key, eylem, policy_version)' anahtarına göre karar önbelleği.
Konu niteliklerinin kenar önbelleği (belirteçteki iddialar) + tembel-getir kaynak nitelikleri.
Artımlı geçersiz kılma: olaylar nedeniyle sakatlık (rol değişikliği, politika değişikliği, "gizli" kaynak aktarımı).
Toplu kontroller: listeler için - PDP'yi satır satır çekmemek için bir "filtre" (politika-tahmin pushdown) ile değerlendirin.

7) Çok kiracı

Her tabloda - 'tenant _ id'; Varsayılan politikalar bir kira içinde erişimi kısıtlar.
Kiralama yöneticileri yalnızca kiralamalarının rollerini/haklarını yönetir.
Çapraz kiralama erişimi - yalnızca açık davetler/açık reddetme-geçersiz kılma ile paylaşım yoluyla.

8) Politika Yönetimi ve Yaşam Döngüsü

Sürüm oluşturma: 'politika. PDP yanıtında sürüm, denetimde saklayın.
Ortamlar: Taslaklar - kanarya (trafik/gölge modunun parçaları) - prod.
Test matrisi: anahtar rollere/niteliklere göre doğruluk tabloları (sözleşme testleri).
Değişiklik yönetimi: Güvenlik/uyumluluk incelemeleriyle ilkeler için istekleri birleştirin.

9) Denetim ve gözlemlenebilirlik

Журнал решений: 'decision _ id', 'subject','action ',' resource _ ref ',' result ',' matched _ policies ',' policy _ version ',' attributes _ digest '.
Metrikler: QPS PDP, p95 gecikme süresi, isabet oranı önbelleği, hisse senedini reddetme, adım atma oranı, SoD olayları.
İzler: PDP çağrısı başına açıklık; API isteği ile korelasyon.
Yeniden oynatma: Politikanın yeni versiyonunda tarihsel kararları "yeniden oynatma" yeteneği (güvenlik kontrolü).

10) Kimlik doğrulama ve belirteçlerle entegrasyon

Kimlik - IdP'den (OIDC/SAML). Belirteçler minimum özellik taşır: 'alt', 'kiracı', 'roller', 'auth _ time', 'amr', 'kapsamlar'.
ABAC için, belirteci şişirmemek için'ağır "işaretleri sunucu tarafından (PIP) yukarı çekin.
İmzalı kaynak belirteçleri (yetenek/davetiyeler) - kesinlikle sınırlı delegasyonlar için.

11) PDP sözde kodu (basitleştirilmiş)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-desenler

"Rol = sayfa" (etki alanı modeli olmayan yüzlerce küçük rol).
Politikaları yalnızca sürümler/denetimler olmadan kodda depolayın.
Reddetme-geçersiz kılma ve SoD eksikliği - artan dolandırıcılık riski.
'User _ id' kurallarının sert listeleri (öznitelikler/ilişkiler yerine).
Yalnızca UI filtreli Veri Katmanı Filtreleme (RLS) yok.
Olaylar ve önbellek sakatlığı olmadan manuel komut dosyaları aracılığıyla rollerin senkronizasyonu.

13) Kılıflar ve tarifler

13. 1 Alan düzeyinde maskeleme:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Verileri yalnızca MFA ile dışa aktarın:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Delegasyon (sınırlı belirteç):

Capability belirteci' resource _ id', 'actions = [" read"]', 'expires _ at', 'aud' içerir. PEP imzayı ve son tarihi doğrular.

14) Test etme

Politikaların birim testleri: Büyük kombinasyonlarla doğruluk tabloları.
Özellik tabanlı: "delik" bulmak için rastgele niteliklerin oluşturulması.
Altın testler: Kritik uç noktalar için bir dizi çözümü düzeltmek.
Kanarya/Gölge: Tutarsızlıkların günlüğü ile politikaların eski ve yeni sürümlerinin paralel değerlendirilmesi.

15) "Mimari ve Protokoller" bölümünün ilgili yetenekleri

Kimlik Doğrulama ve Yetkilendirme (OIDC/OAuth2)

Rıza yönetimi

Tokenization ve Anahtar Yönetimi

Gözlemlenebilirlik: günlükler, metrikler, izler

Coğrafi yönlendirme ve yerelleştirme

Dinlenme/Transit Şifreleme Sırasında

16) Mimar kontrol listesi

1. Özne rolleri ve hiyerarşileri tanımlanmış mıdır?
2. Hibrit bir model var mı: roller + nitelikler üzerindeki koşullar?
3. Reddet-geçersiz kılmalar, SoD ve adım-up ile PDP Uygulanan?
4. PEP nerede? (ağ geçidi, arka uç, veritabanı, UI) - her yerde aynı mı?
5. Çözüm önbellekleri ve olay özürlülüğü yapılandırılmış mı?
6. Politikalar sürüm haline getirildi mi, test edildi mi, süreç tarafından dağıtıldı mı?
7. Denetim kararları, metrikler ve izler etkin mi?
8. Çoklu kiralama ve RLS/saha maskeleme destekleniyor mu?
9. Olaylar ve politika gerilemesi hakkında bir kitabınız var mı?

Sonuç

RBAC kontrol edilebilirlik sağlar, ABAC bağlam ve doğruluk sağlar. Rolleri nitelik koşullarıyla birleştirerek, PDP/PEP'i paylaşarak, önbellekleme, denetim ve politika testi uygulayarak, yetkilendirmeyi bir platform yeteneği olarak oluşturursunuz: ürün ve düzenleyici gereksinimler için öngörülebilir, doğrulanabilir ve ölçeklenebilir.