GH GambleHub

RBAC: рөлдерді және рұқсаттарды басқару

1) RBAC мақсаттары мен қағидаттары

Мақсаты: ақшаны/PII қорғау және талаптарды (GDPR/AML/PCI/ISO) сақтау үшін басқарылатын, тексерілетін және көлемі бойынша ең аз қолжетімділікті жасау.
Қағидаттар: Least Privilege· Need-to-Know· Separation of Duties (SoD)· Zero Trust· Revocability (жылдам пікір)· Auditability (дәлелденуі).

2) Құқықтар мен рөлдердің таксономиясы

Құқық түрлері (permissions):
  • Деректер: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED _ READ' (PII үшін әдепкі).
  • Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
  • Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
  • Интеграциялар: 'API _ CALL:', 'WEBHOOK _ SIGN', 'SERVICE _ CONFIG _ UPDATE'.
Рөлдер сыныптары:
  • Core (сквозные): `employee_basic`, `viewer_internal`, `auditor_privacy`.
  • Доменные: `support_agent`, `vip_manager`, `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `rg_specialist`, `bi_analyst`.
  • Жүйелік/техникалық: 'devops _ admin', 'dba _ admin', 'service _ account _', 'read _ only _ prod'.
  • Артықшылықты (PAM/JIT арқылы): 'break _ glass _ admin', 'prod _ db _ jit _ editor'.

3) Рөлдерді жобалау (role engineering)

1. Ресурстарды түгендеу: жүйелер/кестелер/эндпоинттер, деректер кластары (Public/Internal/Confidential/Restricted/Highly Restricted).
2. User stories функциялары бойынша: кім не істейді және не үшін (purpose).
3. Тапсырмалар маппингі → permissions: әрбір функцияға ең аз жиынтық.
4. Рөлдегі топтау: бір рөл = бір жауапкершілік домені; «суперрольдерге» жол бермеу.
5. SoD тестілеу: сәйкессіздіктерді тексеру (мысалы, 'payments _ ops' ≠ 'fraud _ rule _ admin').
6. Ұшқыш және өлшеу: уақытша шектеулі топқа береміз, аудиторлық ізін жинаймыз.
7. Нұсқалау: рөлдің әрбір өзгерісі - changelog бар CAB арқылы.

4) Өзара әрекеттесу RBAC, ABAC, SoD

RBAC «принципті түрде кім алады», ABAC - «қандай жағдайда» (орта, гео, құрылғы/MDM, уақыт, KYC деңгейі, 'purpose') деп жауап береді.
SoD рөлдердің қауіпті үйлесімділігіне тыйым салады және сыни әрекеттер үшін 4-eyes талап етеді.
Тәжірибе: әдепкі бойынша рөлдер PII-ге MASKED_READ береді; бүркемеленбеген кіру үшін 'purpose' + JIT төлсипаты және ABAC саясатының оң шешімі қажет.

5) Көп ареналылық және гео-контекст

Tenant-scope: рөлдер жалдауға/брендке/юрисдикцияға байланыстырылады ('role: payments _ ops @EEA').
Geo-keys: жеке шифрлау кілттері және per аймақ сегменттері (EC/UK/...).
Шекаралылық: 'region _ code' (RLS) бағаны бойынша және ойыншының юрисдикциясы бойынша сүзу.

6) Row/Column-Level Security және бүркемелеу

Стратегия:
  • RLS (жолдар): тек өз еліңіздің/брендіңіздің/командаңыздың жазбаларына қатынасу.
  • CLS (бағандар): сезімтал өрістер жасырын түрде қол жетімді; бүркемеленбеген - тек 'pii _ unmask' + 'purpose' артықшылығымен.
Шағын мысал (SQL идеясы):
sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, break-glass и PAM в RBAC

JIT: уақытша артықшылықты рөл (15-120 мин); автоматты түрде кері қайтарып алу; толық аудит.
Break-glass: MFA + екінші растауы және сессия жазбасы бар авариялық қолжетімділік; Security + DPO-мен пост-ревью.
PAM: құпия сақтау орны, сессиялық прокси, құпия сөздерді/кілттерді ротациялау.

8) Рөлдердің өмірлік циклі (SOP)

SOP-1: Рөлді жасау/өзгерту

1. домен иесі сұрау → тапсырмалар тізімі → mapping permissions → SoD-чек → ұшқыш → CAB → релиз + құжаттама.

SOP-2: Сұрау салу және рұқсат беру

1. Өтінім (IDM/ITSM) 'purpose' және мерзімі → авто-тексеру SoD/юрисдикциясы → деректер иесінің мақұлдауы + Security (Restricted + үшін) → беру (жиі JIT) → тізілімге жазылу.

SOP-3: Кері шақыру/оффбординг

Триггерлер: жұмыстан шығару, рөлді ауыстыру, белсенділіктің болмауы> 30/60 күн, JIT аяқталды.
Автоматты түрде шолу және журнал.

SOP-4: Қайта сертификаттау

Тоқсан сайын иелері пайдаланушылардың рөлдері әлі де қажет екенін растайды; жүйе «аспалы» құқықтарды алып тастайды.

9) Рөлдер матрицасының мысалы (фрагмент)

РөліРұқсаттар базасыЖасыруСыни әрекеттерSoD қайшылығы
`support_agent`READ профильдер, тикеттерИә (PII masked)с `kyc_operator`
`vip_manager`READ VIP, бонустарИәс 'payments _ ops' (мақұлдау)
`payments_ops`APPROVE_WITHDRAWAL, VIEW_TXPII masked`PAYMENT_APPROVE` (4-eyes)с `fraud_rule_admin`
`fraud_analyst`VIEW_RULES, HOLD_TXPII masked`CHANGE_FRM_RULE`с `payments_ops`
`kyc_operator`KYC_DECISIONmasked құжаттары (view-once via JIT)`KYC_APPROVE`с `support_agent`
`bi_analyst`READ агрегаттарыӘрқашан maskedСөрелер арқылы 'EXPORT'с `dba_admin`
`devops_admin`infra admin`BREAK_GLASS`бизнес рөлдерімен

10) Құралдар және сату (паттерндер)

Рөлдер каталогы код ретінде: YAML/JSON репозиторийде + CI-валидаторлар, changelog.
Орталық IdP/SSO: SCIM-провиженинг, топтық маппингтер 'group → role'.
Policy decision point: мәтінмәндік төлсипаттары бар саясат қозғалтқышы (ABAC).
Secrets/KMS: per орта/аймақ/тенант кілттерін оқшаулау.
Data gateway: DWH/BI/экспорт үшін бірыңғай бүркемелеу/аудит қабаты.
SIEM/SOAR: корреляция 'ROLE _ UPDATE '/' READ _ PII '/' EXPORT _ DATA', авто-тикеттер.

11) Аудит және журналға түсіру

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.
Талаптар: WORM көшірмесі, хэш тізбектері, пакеттердің қолтаңбасы, әр оқиғада 'purpose '/' ticket _ id', тайм-синхрондау.

12) Метрика және KPI/KRI

Coverage: RBAC жүйелерінің% ≥ 95%.
SoD violations: = 0; үйлеспейтін рөлдерді беру әрекеттері - авто-блок.
JIT rate: ≥ 80% өсу JIT сияқты жүреді.
Offboarding TTR: құқықтарды кері қайтарып алу ≤ 15 мин.
Masked reads ratio: ≥ 95% PII өтініштері жасырылған.
Recertification: 100% рөлдер тоқсан сайын расталған.
Exports signed: 100% экспорт қолтаңбасы/журналы.

13) RACI (ірілендірілген)

БелсенділікCompliance/LegalDPOSecuritySRE/ITData/BIProduct/EngDomain Owner
RBAC/SoD саясатыA/RCCCCCC
Рөлдер/құқықтар дизайныCCA/RRRRR
ABAC/JIT/PAMIIA/RRICI
Қайта сертификаттауCCARRRR
Экспорттау/жасыруCARRRCC

14) Чек парақтары

Рөлді жасау алдында

  • user-stories және 'purpose' сипатталған
  • Ресурстар мен деректер кластарының тізбесі
  • Ең аз permissions
  • SoD тексеру/қайшылықтар
  • Бүркемелеу саясаты және RLS/CLS
  • Қайта сертификаттау жоспары және иелері

Рұқсат берер алдында

  • Тіркелген 'purpose' және мерзімі
  • SoD/юрисдикция/MDM/MFA орындалды
  • Әдепкі жасыру, JIT көтерілгенде
  • Журнал және қайта қарау күні қосылды

15) Жиі қателер және қарсы үлгілер

ұсақ домендердің орнына кең құқықты «суперрольдер».
PII-ге бүркемелеусіз тікелей қатынау және 'purpose'.
'PAYMENT _ APPROVE '/' KYC _ APPROVE' үшін SoD/төртінші көздің болмауы.
Уақытша құқықтарды «мәңгі» ұзарту.
Prod деректерін dev/stage бағдарламасына көшіру.
Қолы мен журналы жоқ мөлдір емес экспорт.

16) Енгізу жол картасы

1-2 апталар: ресурстарды түгендеу/деректерді жіктеу; рольдердің бастапқы матрицасы; SoD кестесі.
3-4 апта: RBAC код (репозиторий), IdP-топтар/SCIM, ABAC-қозғалтқыш (негізгі атрибуттар: орта/гео/MDM/уақыт), JIT/PAM, DWH/BI үшін бүркемелеу қабаты.
2 ай: қайта сертификаттау, offboarding автоматтандыру, RBAC/SoD/ABAC бұзушылықтарға SOAR-алерталар, экспорт журналдары/WORM.
3-ай +: атрибуттарды кеңейту (құрылғы тәуекелі, KYC-деңгей), қол жеткізу bias-аудиті, құнды оңтайландыру және тұрақты tabletop-жаттығулар.

TL; DR

Күшті RBAC = ұсақ домендік рөлдер + атрибуттық шарттар (ABAC) + SoD және JIT/PAM + бүркемелеу және RLS/CLS + қатаң аудит және қайта сертификаттау. Бұл ағу/теріс пайдалану қаупін төмендетеді, аудитті жеделдетеді және платформаны құпиялылық пен комплаенс талаптарының шегінде ұстайды.

Contact

Бізбен байланысыңыз

Кез келген сұрақ немесе қолдау қажет болса, бізге жазыңыз.Біз әрдайым көмектесуге дайынбыз!

Telegram
@Gamble_GC
Интеграцияны бастау

Email — міндетті. Telegram немесе WhatsApp — қосымша.

Сіздің атыңыз міндетті емес
Email міндетті емес
Тақырып міндетті емес
Хабарлама міндетті емес
Telegram міндетті емес
@
Егер Telegram-ды көрсетсеңіз — Email-ге қоса, сол жерге де жауап береміз.
WhatsApp міндетті емес
Пішім: +ел коды және номер (мысалы, +7XXXXXXXXXX).

Батырманы басу арқылы деректерді өңдеуге келісім бересіз.