RBAC: როლებისა და რეზოლუციების მენეჯმენტი

1) RBAC- ის მიზნები და პრინციპები

მიზანი: ფულის/PII და მოთხოვნების დასაცავად კონტროლირებადი, დამოწმებული და მინიმალური მოცულობის დაშვება (GDPR/AML/PCI/ISO).
პრინციპები: Least Privilege· Need-to-Know· SoD· Zero Trust· Revocability (სწრაფი მიმოხილვა)· Auditability (დადასტურება).

2) უფლებებისა და როლების ტაქსონომია

უფლებების ტიპები:

მონაცემები: '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 _ განახლება'.

როლების კლასები:

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 _'.
პრივილეგირებული (PAM/JIT- ის საშუალებით): 'break _ glass _ admin', 'medb _ db _ jit _ editor'.

3) როლების დიზაინი (როლის ინჟინერია)

1. რესურსების ინვენტარიზაცია: სისტემები/ცხრილები/ენდოპოინტები, მონაცემთა კლასები (საზოგადოებრივი/შიდა/კონფიდენციალური/კონფიდენციალურობა/მაღალი აღდგენა).
2. მომხმარებელთა ისტორიები ფუნქციებში: ვინ აკეთებს და რატომ (purpose).
3. დავალებების mapping - permissions: მინიმალური ნაკრები თითოეული ფუნქციისთვის.
4. ჯგუფი როლში: ერთი როლი = ერთი პასუხისმგებლობის დომენი; „სუპერ როლების“ თავიდან აცილება.
5. SoD ტესტირება: შეუთავსებლობის შემოწმება (მაგ., 'payments _ ops' "fraud _ rule _ admin ').
6. მფრინავი და განზომილება: ჩვენ ვაძლევთ დროებით შეზღუდულ ჯგუფს, ვაგროვებთ აუდიტის კვალს.
7. ვერსია: როლის თითოეული ცვლილება - CAB- ის მეშვეობით changelog- ით.

4) RBAC - ABAC - SoD ურთიერთქმედება

RBAC პასუხობს „ვინ შეიძლება პრინციპში“, ABAC - „რა პირობებში“ (გარემო, გეო, მოწყობილობა/MDM, დრო, დონე KYC, „purpose“).
SoD კრძალავს როლების საშიშ კომბინაციებს და მოითხოვს 4-eyes კრიტიკულ ქმედებებს.
პრაქტიკა: სტანდარტულად, როლები იძლევა MASKED _ READ PII- ს; მიუწვდომელი წვდომისთვის საჭიროა 'purpose' + JIT ატრიბუტი და ABAC პოლიტიკის დადებითი გადაწყვეტილება.

5) მრავალმხრივი და გეო კონტექსტი

Tenant-scope: როლები უკავშირდება იჯარას/ბრენდს/იურისდიქციას ('role: payments _ ops @ EEA').
Geo-keys: დაშიფვრის ცალკეული გასაღებები და რეგიონის პერის წვდომის სეგმენტები (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 + - სთან მეორე დადასტურებით და სხდომის ჩაწერით; მარხვა უსაფრთხოების + DPO.
PAM: საიდუმლოების საცავი, სესიის მარიონეტული, პაროლების/გასაღებების როტაცია.

8) როლების სასიცოცხლო ციკლი (SOP)

SOP-1: როლის შექმნა/შეცვლა

1. დომენის მფლობელის მოთხოვნა - დავალებების ჩამონათვალი - mapping permissions - SoD ჩეკი - CAB მფრინავი - გამოშვება + დოკუმენტაცია.

SOP-2: მოთხოვნა და წვდომის გაცემა

1. განაცხადი (IDM/ITSM) 'purpose' - ით და SoD/იურისდიქციის გადამოწმების ვადა - მონაცემთა მფლობელის დამტკიცება + უსაფრთხოება (Restricted + - ისთვის) - გაცემა (ხშირად JIT) - ჩანაწერი რეესტრში.

SOP-3: მიმოხილვა/ოფშორული

გამომწვევი: თანამდებობიდან გათავისუფლება, როლის შეცვლა, საქმიანობის არარსებობა> 30/60 დღე, JIT ამოიწურა.
ავტომატური მიმოხილვა და ჟურნალი.

SOP-4: R- სერტიფიკაცია

კვარტალურად, მეპატრონეები ადასტურებენ, რომ მომხმარებლების როლები ჯერ კიდევ საჭიროა; სისტემა ამოიღებს „ჩამოკიდებულ“ უფლებებს.

9) როლების მატრიცის მაგალითი (ფრაგმენტი)

როლი	ნებართვის ბაზა	შენიღბვა	კრიტიკული მოქმედებები	SoD კონფლიქტი
`support_agent`	READ პროფილები, თიკეტები	დიახ (PII masked)	—	с `kyc_operator`
`vip_manager`	READ VIP, პრემია	დიახ	—	s 'payments _ ops' (დამტკიცება)
`payments_ops`	APPROVE_WITHDRAWAL, VIEW_TX	PII masked	`PAYMENT_APPROVE` (4-eyes)	с `fraud_rule_admin`
`fraud_analyst`	VIEW_RULES, HOLD_TX	PII masked	`CHANGE_FRM_RULE`	с `payments_ops`
`kyc_operator`	KYC_DECISION	Masked დოკუმენტები (view-once via JIT)	`KYC_APPROVE`	с `support_agent`
`bi_analyst`	READ აგრეგატები	ყოველთვის მასკეტი	'EXPORT' ფანჯრების საშუალებით	с `dba_admin`
`devops_admin`	infra admin	—	`BREAK_GLASS`	ბიზნეს როლებით

10) ინსტრუმენტები და განხორციელება (ნიმუშები)

როლების კატალოგი, როგორც კოდი: YAML/JSON საცავებში + CI შემსრულებლები, changelog.
ცენტრალური IDP/SSO: SCIM-provigening, ჯგუფური mappings 'group'.
policy decision წერტილი: პოლიტიკოსის ძრავა (ABAC) კონტექსტის ატრიბუტით.
Secrets/KMS: გასაღების იზოლაცია/რეგიონი/ტენანტი.
Data gateway: ნიღბების/აუდიტის ერთი ფენა DWH/BI/ექსპორტისთვის.
SIEM/SOAR: კორელაცია 'ROLE _ განახლება '/' 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: PII- ს მიმართვის 95% -ზე მეტი შენიღბულია.
რეკონსტრუქცია: როლების 100% დადასტურებულია კვარტალურად.
Exports signed: ექსპორტის 100% ხელმოწერით/ჟურნალით.

13) RACI (გაფართოებული)

აქტივობა	Compliance/Legal	DPO	Security	SRE/IT	Data/BI	Product/Eng	Domain Owner
პოლიტიკა RBAC/SoD	A/R	C	C	C	C	C	C
როლების/უფლებების დიზაინი	C	C	A/R	R	R	R	R
ABAC/JIT/PAM	I	I	A/R	R	I	C	I
Re- სერტიფიკაცია	C	C	A	R	R	R	R
ექსპორტი/შენიღბვა	C	A	R	R	R	C	C

14) ჩეკის ფურცლები

როლის შექმნამდე

აღწერილია user-მოთხრობები და 'purpose'
რესურსების და მონაცემთა კლასების სია
Mapping მინიმალური permissions
SoD შემოწმება/კონფლიქტები
შენიღბვის პოლიტიკა და RLS/CLS
სასერთიფიკატო გეგმა და მფლობელები

დაშვებამდე

დაფიქსირდა 'purpose' და ვადა
SoD/იურისდიქცია/MDM/MFA დასრულებულია
შენიღბვა ნაგულისხმევი, JIT
ჟურნალი და გადასინჯვის თარიღი

15) ხშირი შეცდომები და საწინააღმდეგო ნიმუშები

„სუპერ როლები“ ფართო უფლებებით, მცირე დომენების ნაცვლად.
პირდაპირი წვდომა PII- ზე შენიღბვის გარეშე და 'purpose'.
SoD/მეოთხე თვალის არარსებობა 'PAYMENT _ APPROVE '/' KYC _ APPROVE'.
დროებითი უფლებების გახანგრძლივება „სამუდამოდ“.
dev/stage მონაცემთა კოპირება.
გაუმჭვირვალე ექსპორტები ხელმოწერის გარეშე და ჟურნალი.

16) გზის განხორციელების რუკა

არგუმენტები 1-2: რესურსების ინვენტარიზაცია/მონაცემთა კლასიფიკაცია; როლების შავი მატრიცა; SoD ცხრილი.
კვირები 3-4: RBAC, როგორც კოდი (საცავი), IDP ჯგუფი/SCIM, ABAC ძრავა (ძირითადი ატრიბუტები: გარემო/გეო/MDM/დრო), JIT/PAM, ნიღბის ფენა DWH/BI.
თვე 2: re- სერტიფიკაცია, ავტომატიზაცია, SOAR ალერტები RBAC/SoD/ABAC დარღვევებისთვის, ექსპორტის ჟურნალები/WORM.
თვე 3 +: ატრიბუტების გაფართოება (მოწყობილობის რისკი, KYC დონე), წვდომის bias აუდიტი, ღირებულების ოპტიმიზაცია და რეგულარული tabletop სავარჯიშოები.

TL; DR

ძლიერი RBAC = მცირე დომენის როლები + ატრიბუტული პირობები (ABAC) + SoD და JIT/PAM + ნიღაბი და RLS/CLS + მკაცრი აუდიტი და რეპროდუქცია. ეს ამცირებს გაჟონვის/ბოროტად გამოყენების რისკს, აჩქარებს აუდიტს და ინახავს პლატფორმას კონფიდენციალურობისა და შესაბამისობის მოთხოვნების საზღვრებში.

RBAC: როლებისა და რეზოლუციების მენეჯმენტი

დაშვებამდე

TL; DR

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით