Ролдук кыймылдаткыч

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

RBAC (Role-Based Access Control): субъект ролдорду алат, ролдор укуктарга байланыштуу (permissions). Жөн гана башкаруу, типтүү милдеттери үчүн жакшы.
ABAC (Attribute-Based Access Control): Чечим субъекттин атрибуттарына, ресурсуна, аракетине жана чөйрөсүнө (убакыт, IP, аймак, тобокелдик) көз каранды. Ийкемдүү жана татаал эрежелерге масштабдуу.
RBAC + ABAC гибриди: ролдор "негизги" жөндөмүн берет, атрибуттар аны тарылтат (conditions).
(Optional) ReBAC/Relationship-based: мамилелер тилкеси (ээси, команда мүчөсү, делегат), документтердин жана org структуралар үчүн пайдалуу.

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): башкаруу Interface/сактоо саясаты (версиялар, долбоорлор, жарыялоо).

Агым: суроо → 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: global/долбоор боюнча/объект боюнча.

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

4) Чечимдерди кабыл алуу принциптери

Deny-overrides: уруксат караганда ачык тыюу.
Least Privilege (PoLP): минималдуу зарыл жеткиликтүүлүгүн берүү, шарттары аркылуу кеңейтүү.
Duties Separation (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

DD деңгээлинде: RLS саясаты ('tenant _ id', 'owner _ id' боюнча).
API деңгээлинде: коллекцияларды чыпкалап, эгер жок болсо, талааларды жашырыңыз 'allow: read_sensitive_fields'.

5. 3 чечимдер "кадам"

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

5. 4 Убактылуу уруксаттар

TTL менен гранттар: 'assignment. expires_at', "терезелер" жетүү (ресурстук аймакта жумуш убактысында).

6) Аткаруу жана кэш

Кэш чечимдер (decision cache) ачкыч '(subject_hash, resource_key, action, policy_version)' кыска TTL менен.
Edge-кэш субьект атрибуттары (токендеги claims) + lazy-fetch ресурс атрибуттары.
Incremental invalidation: окуялардын майыптыгы (ролдорду өзгөртүү, саясатты өзгөртүү, ресурсту "confidential" которуу).
Batch-текшерүү: тизмелер үчүн - баа "чыпкасы" (policy-predicate pushdown) PDP сызык менен тартып эмес.

7) Көп ижара (Multi-tenant)

Ар бир таблицада - 'tenant _ id'; демейки саясаты ижара ичинде кирүүнү чектейт.
Ижара администраторлору өз ижара акысын/укугун гана башкарышат.
Cross-ижара мүмкүнчүлүгү - ачык чакыруу/ачык 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, жогорку-rate кэш, deny үлүшү, step-up жыштыгы, SoD окуялар.
Tracking: PDP чакыруу боюнча span; API суроо менен байланыш.
Реплика: Саясаттын жаңы версиясында тарыхый чечимдерди "кайталоо" мүмкүнчүлүгү (safety check).

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

IdP (OIDC/SAML). Токендер минималдуу атрибуттарды алып жүрөт: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
ABAC үчүн "оор" белгилерди серверден (PIP) тартыңыз.
Кол коюлган resource tokens (capability/чакыруу) - катуу чектелген өткөрүп берүү үчүн.

11) PDP Pseudo Code (жөнөкөйлөштүрүлгөн)

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' катуу тизмелери (атрибуттардын/мамилелердин ордуна).
маалыматтардын денгээлде чыпкалоо жоктугу (RLS) бир гана UI чыпкасы бар.
Иш-чаралар жана кэш майыптыгы жок кол скрипттер аркылуу ролдорду синхрондоштуруу.

13) учурларда жана Recipes

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) Сыноо

Unit-тесттер саясат: негизги комбинациялары боюнча чындык таблицалар.
Property-based: "тешиктер" издөө үчүн кокусунан атрибуттарды түзүү.
Алтын-тесттер: критикалык Enpoints үчүн чечимдердин топтомун бекитүү.
Canary/Shadow: айырмачылыктардын логикасы менен саясаттын эски жана жаңы версияларын параллелдүү баалоо.

15) "Архитектура жана протоколдор" бөлүмүнүн байланыштуу жөндөмдүүлүктөрү

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

Макулдуктарды башкаруу

Токенизация жана ачкычтарды башкаруу

Байкоо: Логи, метрика, Tracking

Гео-багыттоо жана локалдаштыруу

On Rest/In Transit шифрлөө

16) Архитектордун чек тизмеси

1. предметтик ролдору жана алардын иерархиясы аныкталган?
2. Гибриддик модель барбы: ролдор + атрибуттарда шарттар?
3. deny-overrides менен PDP ишке ашырылган, SoD жана кадам?
4. PEP кайда? (шлюз, backend, DD, UI) - бардык жерде бирдей?
5. Чечимдердин кэштери жана окуялар боюнча майыптык орнотулганбы?
6. Саясатчылар версияланат, сыналат, процесске айланат?
7. Чечимдерди аудит, метрика жана трасса кирет?
8. Көп ижара жана RLS/field-masking колдойт?
9. Окуялар жана регрессия саясатчылардын runbook бар?

Корутунду

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