API'de erişim kontrolü ve RBAC

1) Neden API erişim kontrolü

Yetkilendirme,'bu aktör şimdi bu kaynak üzerinde bu eylemi gerçekleştirebilir mi? ». Hatalar, BOLA/IDOR sızıntılarına, hakların artmasına ve düzenleyici gerekliliklerin ihlal edilmesine yol açar. Amaç, çok seviyeli bir model oluşturmaktır: Perimeter - service mash - iş kuralları, nesne düzeyinde açık politikalar ve kontroller.

2) Yetkilendirme modelleri: ne zaman seçileceği

RBAC (Role-Based Access Control) - roller - izinler. Basit, istikrarlı, ama "rol patlaması" eğilimli.
ABAC (Öznitelik Tabanlı) - öznenin/nesnenin/bağlamın (ülke, KYC seviyesi, kaynak sahibi, risk) niteliklerine ilişkin karar.
ReBAC (İlişki Tabanlı) - ilişki grafiği (sahip, ekip üyesi, "proje yöneticisi"); Karmaşık hiyerarşileri çözer.
Kapsamlar (OAuth) - istemci ile kaynak sunucusu arasında "erişim alanı" hakkında bir sözleşme (örneğin, "ödemeler: yazma").
Uygulama: Temel matris için RBAC, bağlam ve kısıtlamalar için ABAC, karmaşık hiyerarşiler için ReBAC (klasörler, kuruluşlar, sınırlar ve podaccounts).

3) Kaynakların ve eylemlerin taksonomisi

Hiyerarşiler: 'Org> Proje> Cüzdan> İşlem'. Olası "sınırlayıcılar'ile yukarıdan aşağıya hakların mirası.
Eylemler: CRUD + etki alanına özgü ('onayla', 'geri ödeme', 'yerleşme').
Kaynak özellikleri: sahip, bölge, durum, risk etiketleri (AML/KYC), limitler.
Çoklu kiracılık: tüm çözümler 'tenant _ id' içerir; Varsayılan olarak reddet.

4) Mimarlık: kararın verildiği yer

PEP (Policy Enforcement Point) - doğrulama sitesi: gateway/API-gateway, sidecar mash, servisin kendisi.
PDP (Politika Karar Noktası) - politika motoru: merkezi (OPA-hizmet, Cedar-motor) veya yerleşik kütüphane.
PIP (Policy Information Point) - öznitelik kaynakları: kullanıcı/rol dizini, kiracı profili, CCP/risk, kaynak sahiplik haritası.
PAP (Policy Administration Point - Politika Yönetim Noktası) - politika sürüm oluşturma, yayınlama, denetleme.

Öneri: PEP'de merkezi PDP + yerel çözüm önbelleği; Alan değişmezlerinin varlığında hizmette karmaşık nesne kontrolleri.

5) Belirteçler, pullar ve kimlik

OIDC/OAuth2: 'sub' (konu tanımlayıcısı), 'aud' (hedef hizmet), 'scope'/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES imzası, kısa 'exp', yenileme ile yeniden yayın. PII koymayın; İptal/takip denetimi için 'jti' kullanın.
mTLS/HMAC: servisten servise ve ortaklar; Damgalar 'client _ id'tarafından dizinden çekilir.
Cihaz/Bağlam: IP/ASN, coğrafi, günün saati - ABAC çözümüne giriş yapın (örneğin, çalışma saatleri dışında yazmayı yasaklayın).

6) Nesne düzeyinde yetkilendirme (BOLA-first)

Her işlem "konunun sahibi/bu 'resource _ id' hakkına sahip mi?"

Mülkiyet kontrolü: 'kaynak. owner_id = = konu. id 'veya bir rol ile bir' org 'üyelik.
Filtre örnekleri: her zaman 'WHERE kaynağını kaplayın. tenant_id =: kiracı VE... '(satır düzeyinde güvenlik).
Referans işlemleri için (yol/gövde kimliği) - iş mantığını normalleştirin ve doğrulayın.

7) RBAC Tasarımı: Roller, İzinler, Kümeler

İzinler - atomik haklar: 'cüzdan. ',' cüzdanını oku. ',' yazın ödeme. Geri ödeme '.
Roller - adlandırılmış izin setleri: 'admin', 'support. ',' kasiyer ',' dolandırıcılık 'okuyun. Analist.

Kapsamlar - müşteriler için harici sözleşme (kapsam - izinler eşleme)

• temel roller + izin paketleri,
• ABAC kısıtlamaları (ülke/bölge/kiracı),
• "Tam Zamanında Erişim".

8) ABAC/bağlam kısıtlamaları

Geo/jurisdiction: Yasak ülkelerden yazma yasağı (yaptırımlar/düzenleyici).
Zaman/risk: Büyük operasyonlar için 'risk _ skor <eşik'.
ACC/limits: Pins> X için 'kyc _ level> = 2'; İşlemler arasında "soğuma" kontrolü.
"Güvenilir cihazlar": Tehlikeli rotalardaki ortaklar için mTLS gerektirir.

9) ReBAC ve hakların grafiği

Karmaşık iş yapıları için kullanışlıdır (gruplar, ekipler, markalar, şubeler).

İlişkiler: 'Üye', 'yönetici', 'sahip', 'görüntüleyici'.
Türetilmiş haklar: Kaynağın 'görüntüleyicisi', 'org'a ait olan projenin' üyesinden 'miras alınır.
Grafik depolama: bir ilişki matrisi, özel bir hizmet (Zanzibar yaklaşımının ruhunda) ile bir veritabanı. Cache 'check (özne, ilişki, nesne)' yanıtları.

10) Çözüm önbelleği ve performansı

PEP düzeyinde PDP önbelleği (örneğin, bir ağ geçidinde): 'sub' tenant 'resource' action 'policy _ version'.
TTL kısa (saniye-dakika) + olaya göre sakatlık: rol/ilişki/kiracı değişikliği.
Listeler için toplu kontroller (toplu authz): PDP ücretlerini azaltın.
Gecikme çözümlerini ölçmek; Bozulma sırasında - sadece okumak için zarif bozulma (asla yazma/parasal için).

11) Politika örnekleri

11. 1 JWT damgaları - kaba PEP (sözde ağ geçidi)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Yargı yetkisi kısıtlaması (inkar listesi politikası)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 ReBAC Politikası (sözde)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Politika ve Sürüm Yönetimi

Tehlikeli değişiklikler için politika sürümleri ('policy _ version') ve kanarya.
"Kuru çalıştırma" (kuru çalıştırma/gölge kararları) - etki olmadan 'izin ver/reddet' günlüğü.
Politika ve Geçiş Dizini: Kim Ne Zaman ve Neden Değişti? olayları haritalamak.
Negatif senaryolar için testler (yasak durumlar) - CI'da gereklidir.

13) Gözlemlenebilirlik ve denetim

Karar günlükleri: 'trace _ id', 'subject', 'tenant','action ',' resource _ id ',' result ',' policy _ version ', başarısızlık nedeni.
Metrikler: 'authz _ decision _ latency', 'authz _ denied _ total {action}', BOLA girişimlerinin payı, önbellek isabet oranı.
Panolar: eylemlerin/kiracıların en büyük başarısızlıkları, politika yayınlarından sonraki eğilimler.

14) Güvenlik ve sürdürülebilirlik

Varsayılan olarak reddet: açık izin yok = reddet.
Fail-closed: PDP kullanılamadığında, kritik yazma yasaklanır (veya kesinlikle doğrulanmış rollerin "minimum kümesine" indirgenir).
Kritik değişmezlere yönelik hizmetler içinde yerel "koruma kontrolleri" (örneğin, "kiracı "/'mal sahibi").
JWT'deki ayırt edici özellikleri en aza indirmek; Hassas nitelikleri güvenli bir kanal üzerinden PIP üzerinden yükleyin.

15) iGaming/Finansın Özellikleri

Roller: 'kasiyer', 'kyc. Ajan ',' aml. Memur bey, dolandırıcılık. Analist ',' vip. Yönetici ',' risk. admin '.
Kısıtlamalar: ödeme işlemleri 'kyc _ level', sorumlu ödemelerin sınırları, AML durumu/yaptırımlara bağlıdır.
Kilit kayıtları: 'org/brand/device/payment _ instrument' - yazıdaki ABAC filtreleri.
KYC/AML/pin eylemleri için değiştirilmemiş denetim günlükleri; yasal sürelere göre depolama.
İş Ortağı API'leri: mTLS + rotalardaki sözleşme 'kapsamları', çevre üzerindeki coğrafi/ASN filtreleri.

16) Test ve doğrulama

Negatif matris: açık "yasak" durumları listeleyin ve testlerle düzeltin.
Fuzz yetkilendirme: 'tenant _ id', 'owner _ id' yerine, sayfalama/sıralama sırasında filtreleri atlayarak.
PDP yük testi: Önbelleklerin p95/p99'daki gecikmesini ve davranışını kontrol edin.
Politika açıklaması: kuru çalışma + kanarya + beklenen reddetme/izin verme ile otomatik test.
Olaylar: Standdaki istekleri politikaların doğru bir versiyonuyla tekrarlayın.

17) Antipatterns

Nesne kontrolleri (BOLA) olmadan yalnızca 'kapsam'a güvenin.
Merkezi bir model olmadan her işleyicide iş mantığını ve hak kontrollerini karıştırın.
UI ve güven istemci çözümlerinde Hardcode rolleri.
Veritabanına yapılan taleplerde 'tenant'/' owner' filtrelerinin bulunmaması (sızıntılı okumalar).
Rolleri/ilişkileri değiştirirken önbellek çözümü engeli yoktur.
Hatırlama/rotasyon olmadan uzun ömürlü JWT'ler.

18) Prod Hazırlık Kontrol Listesi

• Kaynaklar/faaliyetler, hiyerarşiler ve çoklu kiracılık tanımlanmıştır.
• Temel RBAC matrisi + ABAC sınırlayıcıları, gerektiğinde - ReBAC.
• PDP/PEP tasarlanmıştır; Yerel bir çözüm önbelleği ve sakatlığı var.
• Politikalar CI'da sürümlü, negatif senaryo testleridir.
• BOLA, her yazma/okumada belirli bir 'resource _ id' değerini kontrol eder.
• Minimum pullarla JWT, kısa 'exp'; 'jti' üzerinde denetim/hatırlama.
• Metrikler/karar günlükleri, gösterge panoları, inkar/gecikme ile uyarılar.
• Eleştirel yazı için Fail-closed; Geri dönüş modu belgelenmiştir.
• Müşteri belgeleri: 'kapsamlar', hata kodları (401/403/404/409), örnekler.

19) TL; DR

BOLA öncelikli yetkilendirme oluşturun: merkezi PDP + çözüm önbelleği, temel olarak RBAC, bağlam için ABAC, ilişkiler için ReBAC. Tüm talepler 'kiracı've belirli bir' resource _ id 'bağlamındadır; Varsayılan olarak reddet, kısa JWT, veritabanındaki nesne filtreleri. Sürüm ve test politikaları, gecikme/reddetme, tekrar olayları ölçmek. IGaming için - bireysel roller (KYC/AML/yazar kasa), sert ABAC sınırlayıcıları ve değiştirilemez denetim.