Rol mühərriki

1) Avtorizasiya modelləri

RBAC (Role-Based Access Control): subyekt rolları alır, rollar hüquqları ilə bağlıdır (permissions). Sadəcə idarə, tipik vəzifələr üçün yaxşı.
ABAC (Attribute-Based Access Control): həll subyektin atributları, resurs, fəaliyyət və mühit (vaxt, IP, region, risk) asılıdır. Çevik və mürəkkəb qaydalara ölçülür.
Hibrid RBAC + ABAC: rollar «əsas» qabiliyyət verir, atributlar onu daraldır (conditions).
(İsteğe bağlı) ReBAC/Relationship-based: əlaqələr qrafiki (sahibi, komanda üzvü, nümayəndə), sənədlər və orqan strukturları üçün faydalıdır.

2) Memarlıq: PDP/PEP və axınlar

PEP (Policy Enforcement Point): həll tətbiq yeri (API-şlyuz, backend metodu, SQL-layer, UI).
PDP (Policy Decision Point): Siyasətlər və atributlar üzrə 'ALLOW/DENY' hesablayan xidmət/kitabxana.
PIP (Policy Information Point): atribut mənbələri (IdP/profil, resurs metadata, risk-skor, geo).
PAP (Policy Administration Point): inzibati interfeys/siyasət anbarı (versiyalar, layihələr, nəşr).

Axın: sorğu → PEP kontekstini formalaşdırır → PDP çatışmayan atributları çəkir (PIP vasitəsilə) → həll hesablayır → PEP tətbiq edir (icazə vermək/qadağan etmək/sahələri kəsmək) → audit.

3) Data modeli

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'resource' növü və atributları ilə: 'type', 'owner _ id', 'tenant _ id', 'classification' (public/confidential), 'region', 'tags'.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles (id, tenant_id, name, inherits [])' - iyerarxiya və şablonları dəstəkləyin.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subject_id, role_id, scope)' - scope: global/layihə/obyekt üzrə.

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

4) Qərar qəbul etmə prinsipləri

Deny-overrides: açıq qadağalar icazələrdən daha üstündür.
Least Privilege (PoLP): minimum lazımi giriş verin, şərtlər vasitəsilə genişləndirin.
Duties Separation (SoD): rol/fəaliyyət kombinasiyalarının qadağan edilməsi (məsələn, «ödəniş yaratdı» ≠ «ləğv etdi»).
Context-aware: artan risklə tələbləri artırın (MFA yoxdur, şübhəli IP).
Determinism: eyni kontekst → eyni cavab; siyasətin versiyasını jurnalda qeyd edin.

5) Satış nümunələri

5. 1 hibrid RBAC → ABAC (kondisioner)

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 Row/Field-Level Security

DB səviyyəsində: RLS siyasəti ('tenant _ id', 'owner _ id').
API səviyyəsində: kolleksiyaları süzün və 'allow: read_sensitive_fields' yoxdursa, sahələri maskalayın.

5. 3 «step-up» həlləri

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

5. 4 Müvəqqəti tolerantlar

TTL ilə qrantlar: 'assignment. expires_at', giriş «pəncərələri» (resurs bölgəsinin iş vaxtı).

6) Performans və caching

Cache solutions (decision cache) açar '(subject_hash, resource_key, action, policy_version)' qısa TTL ilə.
Subyekt atributlarının Edge-cache (tokendə claims) + resurs atributlarının lazy-fetch.
Incremental invalidation: hadisələrin əlilliyi (rolların dəyişdirilməsi, siyasətin dəyişdirilməsi, resursların «confidential» -a köçürülməsi).
Batch-check: siyahılar üçün - «filter» (policy-predicate pushdown) ilə PDP-ni xətt üzrə çəkməmək üçün qiymətləndirin.

7) Multi-tenant

Hər cədvəldə - 'tenant _ id'; siyasətlər kirayə daxilində girişi məhdudlaşdırır.
İcarə idarəçiləri yalnız icarə rollarını/hüquqlarını idarə edirlər.
Cross-icarə - yalnız açıq deny-override ilə açıq dəvətlər/paylaşma vasitəsilə.

8) Siyasətlərin idarə edilməsi və həyat dövrü

Versiyası: 'policy. version 'PDP cavabında, auditdə saxlayın.
Mühit: draft → canary (trafik hissələri/kölgə rejimi) → prod.
Test matrix: əsas rollar/atributlar üzrə həqiqət cədvəlləri (müqavilə testləri).
Change management: Təhlükəsizlik/komplayens rəyi ilə siyasətə merj-rekvestlər.

9) Audit və müşahidə

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Metriklər: QPS PDP, gecikmə p95, hit-rate cache, deny payı, step-up tezliyi, SoD hadisələri.
İzləmə: PDP çağırışında span; API sorğusu ilə korrelyasiya.
Replay: siyasətin yeni versiyasında (safety check) tarixi həlləri «təkrarlamaq» imkanı.

10) Autentifikasiya və tokenlərlə inteqrasiya

Identity - IdP (OIDC/SAML). Tokenlər minimum atributları daşıyır: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
ABAC üçün, tokeni şişirtməmək üçün serverdən (PIP) «ağır» işarələri çəkin.
Imzalanmış resource tokens (capability/dəvətlər) - ciddi məhdudlaşdırılmış nümayəndəliklər üçün.

11) PDP psevdokod (sadələşdirilmiş)

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-nümunələr

«Rol = səhifə» (mövzu sahəsi modeli olmadan yüzlərlə kiçik rol).
Siyasətləri yalnız versiyasız/auditsiz kodda saxlayın.
Deny-override və SoD → saxtakarlıq riskinin artırılması.
Qaydalarda 'user _ id' sərt siyahıları (atributlar/münasibətlər əvəzinə).
Yalnız UI-də filtr olduqda məlumat səviyyəsində (RLS) filtrasiya yoxdur.
Hadisələr və cache əlilliyi olmadan əl skriptləri vasitəsilə rolları sinxronizasiya.

13) Cases və reseptlər

13. 1 Sahə-səviyyə maskası:

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

13. 2 Yalnız MFA ilə məlumat ixracı:

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 Nümayəndəlik (məhdud token):

Capability tokenində' resource _ id', 'actions = [» read»]', 'expires _ at', 'aud' var. PEP imzanı və müddəti yoxlayır.

14) Test

Vahid siyasətçi testləri: əsas kombinasiyalara görə həqiqət cədvəlləri.
Property-based: «deşiklər» axtarmaq üçün təsadüfi atributlar yaratmaq.
Golden-tests: kritik end-pointlər üçün həllər dəsti fiksasiya.
Canary/Shadow: uyğunsuzluqların loginqi ilə siyasətin köhnə və yeni versiyalarının paralel qiymətləndirilməsi.

15) «Memarlıq və Protokollar» bölməsinin əlaqəli qabiliyyətləri

Autentifikasiya və avtorizasiya (OIDC/OAuth2)

Razılığın idarə edilməsi

Tokenizasiya və açar idarəetməsi

Müşahidə: log, metrika, izləmə

Geo-marşrutlaşdırma və lokalizasiya

At Rest/In Transit şifrələmə

16) Memarın yoxlama siyahısı

1. Mövzu rolları və onların iyerarxiyası müəyyən edilmişdir?
2. Hibrid model varmı: rollar + atributlarda şərtlər?
3. Deny-overrides, SoD və step-up ilə PDP həyata?
4. PEP haradadır? (şluz, arxa plan, DD, UI) - hər yerdə vahid?
5. Həllərin keşlərini və hadisələrə görə əlilliyi konfiqurasiya edirsiniz?
6. Siyasətçilər versiya olunur, sınaqdan keçirilir, prosesdə yuvarlanır?
7. Həllərin auditi, metrika və izləmə daxildir?
8. Multi-icarə və RLS/field-masking dəstəklənir?
9. insidentlər və regressiya siyasətçilər runbook var?

Nəticə

RBAC idarə, ABAC - kontekst və dəqiqlik təmin edir. Rolları özəllik şərtləri ilə birləşdirərək, PDP/PEP paylaşaraq, caching, audit və test siyasətlərini tətbiq edərək, platforma qabiliyyəti kimi avtorizasiya qurursunuz: proqnozlaşdırıla bilən, yoxlanıla bilən və məhsul və tənzimləmə tələbləri üçün ölçülə bilən.