Рөлдік қозғалтқыш

1) Авторизация модельдері

RBAC (Role-Based Access Control): субъект рөлдерді алады, рөлдер құқықтармен байланысты (permissions). Жай ғана басқару, типтік міндеттер үшін жақсы.
ABAC (Attribute-Based Access Control): шешім субъектінің атрибуттарына, ресурсына, әрекетіне және қоршаған ортасына (уақыт, IP, өңір, тәуекел) байланысты. Икемді және күрделі ережелерге масштабталады.
RBAC + ABAC гибриді: рөлдер «базалық» қабілет береді, атрибуттар оны тарылтады (conditions).
(Қосымша) ReBAC/Relationship-based: қарым-қатынас бағаны (иесі, команда мүшесі, делегат), құжат және орган құрылымдары үшін пайдалы.

2) Сәулет: PDP/PEP және ағындар

PEP (Policy Enforcement Point): шешімді қолдану орны (API-шлюз, бэкенд-әдіс, SQL-қабат, UI).
PDP (Policy Decision Point): саясаттар мен атрибуттар бойынша 'ALLOW/DENY' есептейтін қызмет/кітапхана.
PIP (Policy Information Point): атрибут көздері (IdP/профиль, ресурстың метадеректері, тәуекел-жылдамдық, гео).
PAP (Policy Administration Point): әкімшілік интерфейс/саясат репозиторийі (нұсқалар, жоба жазбалар, жариялау).

Ағын: сұрау → PEP контекст қалыптастырады → PDP жетіспейтін төлсипаттарды тартады (PIP арқылы) → шешімді есептейді → PEP қолданады (рұқсат/тыйым салу/өрістерді кесу) → аудит.

3) Деректер моделі

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'resource' түрі мен атрибуттарымен: '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 [])' - иерархиялар мен үлгілерді қолдаңыз.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subject_id, role_id, scope)' - scope: жаһандық/жоба бойынша/нысан бойынша.

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

4) Шешім қабылдау қағидаттары

Deny-overrides: нақты тыйым салу рұқсаттардан басым.
Least Privilege (PoLP): ең аз қажетті қолжетімділікті беріңіз, шарттар арқылы кеңейтіңіз.
Separation of Duties (SoD): рөлдер/әрекеттер комбинацияларына тыйым салу (мысалы, «төлем жасады» ≠ «тоқтатылды»).
Context-aware: жоғары тәуекел кезінде талаптарды күшейтіңіз (MFA жоқ, күдікті IP).
Determinism: бірдей контексті → бірдей жауап; саясаттың нұсқасын журналға тіркеңіз.

5) Сату паттерндері

5. 1 RBAC → ABAC гибриді (ауа баптау)

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

БД деңгейінде: RLS саясаты ('tenant _ id', 'owner _ id' бойынша).
API деңгейінде: егер 'allow: read_sensitive_fields' болмаса, жиындарды сүзгілеңіз және өрістерді бүркемелеңіз.

5. 3 «step-up» шешімдері

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

5. 4 Уақытша рұқсаттар

TTL гранттары: 'assignment. expires_at', кіру «терезелері» (ресурс аймағының жұмыс уақытында).

6) Өнімділік және кэштеу

TTL қысқа '(subject_hash, resource_key, action, policy_version)' кілті бойынша шешімдер кэші.
Субъект атрибуттарының edge-кэші (токендегі claims) + ресурс атрибуттарының lazy-fetch.
Incremental invalidation: оқиғалар бойынша мүгедектік (рөлдерді өзгерту, саясатты өзгерту, ресурсты «confidential» -ге ауыстыру).
Batch-тексерулер: тізімдер үшін - PDP-ні жолма-жол тартпау үшін «сүзгімен» (policy-predicate pushdown) бағалаңыз.

7) Көп жалдаушылық (Multi-tenant)

Әрбір кестеде - 'tenant _ id'; әдепкі саясат жалдау ішіндегі кіруді шектейді.
Жалдау әкімшілері өздерінің жалдау рөлдерін/құқықтарын ғана басқарады.
Кросс-жалгерлік қолжетімділік - тек қана айқын шақыру/айқын deny-override бар шэринг арқылы.

8) Әкімшілендіру және саясаттың өмірлік циклі

Нұсқалау: 'policy. PDP жауабында version ', аудитте сақтаңыз.
Орталар: draft → canary (трафик бөлігі/көлеңкелі режим) → prod.
Test matrix: негізгі рөлдер/атрибуттар бойынша шынайылық кестелері (келісімшарттық тестілер).
Change management: қауіпсіздік/комплаенс рецензиясы бар саясатқа реквизиттер.

9) Аудит және бақылау

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Өлшемдер: QPS PDP, жасырын p95, hit-rate кэш, deny үлесі, step-up жиілігі, SoD инциденттері.
Трассировкалар: PDP шақыруына span; API сұрауымен корреляция.
Реплика: саясаттың жаңа нұсқасындағы тарихи шешімдерді «қайталау» мүмкіндігі (safety check).

10) Аутентификациямен және токендермен интеграциялау

Сәйкестігі - IdP-ден (OIDC/SAML). Белгілер «sub», «tenant», «roles», «auth _ time», «amr», «scopes» атрибуттарын алып жүреді.
ABAC үшін токенді үрлемеу үшін серверлік жақтан (PIP) «ауыр» белгілерді тартыңыз.
Қол қойылған resource tokens (capability/шақыру) - қатаң шектелген табыстаулар үшін.

11) PDP жалған құжаты (оңайлатылған)

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) Қарсы үлгілер

«Рөлі = бет» (пәндік саланың моделінсіз жүздеген ұсақ рөлдер).
Саясатты тек нұсқасыз/аудитсіз кодта сақтау.
deny-override және SoD → болмауы алаяқтық тәуекелін арттыру.
Ережелердегі 'user _ id' қатқыл тізімдері (төлсипаттар/қатынастар орнына).
Тек UI сүзгісі болған кезде деректер деңгейінде (RLS) сүзгілеудің болмауы.
Рөлдерді оқиғаларсыз және кэштерді кемсітусіз қол скрипттері арқылы үндестіру.

13) Кейстер мен рецептілер

13. 1 Деңгейлік бүркемелеу өрісі:

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

13. 2 Деректерді тек MFA-дан экспорттау:

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 Өкілдік ету (шектеулі токен):

Capability-токенінде' resource _ id', 'actions = [» read»]', 'expires _ at', 'aud' бар. PEP қолтаңбаны және мерзімін тексереді.

14) Тестілеу

Саясаттың юнит-тестілері: негізгі комбинациялар бойынша ақиқаттылық кестелері.
Property-based: «тесіктерді» іздеу үшін кездейсоқ төлсипаттарды жасау.
Golden-tests: күрделі эндпойнттарға арналған шешімдер жиынтығын бекіту.
Canary/Shadow: айырмашылықтарды логикалайтын саясаттың ескі және жаңа нұсқаларын қатар бағалау.

15) «Сәулет және хаттамалар» бөлімінің байланысты қабілеттері

Аутентификация және авторизация (OIDC/OAuth2)

Келісімдерді басқару

Токенизациялау және кілттерді басқару

Бақылануы: логия, метрика, трассировка

Гео-бағыттау және оқшаулау

At Rest/In Transit шифрлау

16) Сәулетшінің чек-парағы

1. Пәндік рөлдер мен олардың иерархиялары анықталды ма?
2. Гибридтік модель бар ма: рөлдер + атрибуттардағы шарттар?
3. deny-overrides, SoD және step-up бар PDP іске асырылды ма?
4. PEP қайда? (шлюз, бэкенд, ДБ, UI) - барлық жерде біркелкі ме?
5. Шешімдердің кэштері мен оқиғалар бойынша мүгедектігі орнатылды ма?
6. Саясаткерлер нұсқаланады, тестіленеді, процесс бойынша таратылады ма?
7. Шешімдер, метрика және трассировка аудиті қосылды ма?
8. Көп жалдау және RLS/field-masking қолдана ма?
9. Оқиғалар мен саясаттың регрессиясы туралы runbook бар ма?

Қорытынды

RBAC басқаруды қамтамасыз етеді, ABAC - контексті мен дәлдігі. Рөлдерді атрибуттық жағдайлармен біріктіре отырып, PDP/PEP бөлісіп, кэштеуді, аудитті және саясатты тестілеуді енгізе отырып, сіз авторизацияны платформалық қабілеттілік ретінде құрасыз: болжамды, тексерілетін және азық-түлік және реттеу талаптары үшін масштабталатын.