დაშვების პოლიტიკოსები და სეგმენტები

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

მიზანი: შეამციროს გაჟონვის/თაღლითობის რისკი და მარეგულირებელი შედეგები მკაცრი კონტროლის საშუალებით „ვინ, რა და რატომ აქვს წვდომა“, აუდიტის მტკიცებულებებით.
პრინციპები: Least Privilege (მინიმალური უფლებები), Need-to-Know, Zero Trust, Duties Segregation (SoD), Just-in-Time (JIT), წვდომის კვალიფიკაცია და რეაგირება.

2) მონაცემთა კლასიფიკაცია და დაცვის დონე

3) წვდომის მოდელი: RBAC + ABAC

RBAC (როლები): ძირითადი მატრიცა „რეზოლუციის როლი“.
ABAC (ატრიბუტები): კონტექსტური წესები (მოთამაშის/ოპერატორის იურისდიქცია, გარემოს სეგმენტი, კომპლექტის მგრძნობელობა, შეცვლა/დრო, მოწყობილობა, KYC შემოწმების დონე, ოფიციალური დავალება/purpose).

• მარკეტინგის ანალიტიკოსს შეუძლია წაიკითხოს ცხრილები 'events _' მხოლოდ იმ ქვეყნებისთვის, სადაც არსებობს თანხმობა ანალიტიკაზე, მხოლოდ სამუშაო დღეებში 08: 00-21: 00 საათზე, მხოლოდ კორპორატიული ქსელიდან/MDM მოწყობილობებიდან, PII ველების გარეშე (შენიღბვა ჩართულია).

4) SoD - მოვალეობების გამიჯვნა (ანტიფროდი და შესაბამისობა)

5) JIT, break-glass и PAM

JIT (Just-in-Time): გაზრდილი უფლებები გაიცემა შეზღუდული ინტერვალით (15-120 წუთი) კონკრეტული დავალებისთვის და ავტომატურად გამოეხმაურა.
Break-glass: სასწრაფო დახმარების დაშვება ცალკეული პროცედურის საშუალებით (MFA + მეორე დადასტურება + სავალდებულო მითითება), სხდომის სრული ჩანაწერი და პოსტ-ფაქტორი.
PAM: Admin ანგარიშებისთვის - პაროლის საცავი, ქცევითი ანალიტიკა, გასაღებების/საიდუმლოებების როტაცია, სხდომის მარიონეტული ჩაწერა.

6) სეგმენტი: საშუალო, ქსელი და ლოგიკური

6. 1 გარემო: '' '' 'stage' 'dev'. Stage მონაცემები არ არის კოპირებული stage/dev; გამოიყენება სინთეზური ან ფსევდონიზებული ნაკრები.

• Edge/WAF/CDN არის მონაცემთა ზონის App ზონა (DWH/DB) Secrets/KMS.
• გადახდის პერიმეტრი (PSP/ბარათები) იზოლირებულია ზოგადი პირიდან; KUS/სანქციები ცალკე სეგმენტია.
• 6. 3 ლოგიკური სეგმენტი: სახელების სივრცეები (K8s), tenant-IDs, BD/მონაცემთა კატალოგების სქემები, ინდივიდუალური დაშიფვრის გასაღებები per tenant/რეგიონი.
• 6. 4 გეო-სეგმენტი: შენახვა/დამუშავება ადგილმდებარეობის მიხედვით (EC/UK/...); რეგიონში გუიდებისა და გასაღებების მარშრუტიზაცია.

7) ვენდორებისა და პარტნიორების წვდომა

მექანიკა: ცალკეული B2B ტენანტები/ანგარიშები, მინიმალური API სკოპი, mTLS, ალოუ-სია IP, დრო-ფანჯარა.
ხელშეკრულებები: DPA/SLA (ჟურნალები, შენახვის ვადები, გეოგრაფია, ინციდენტები, სუბპროცესორები).
ოფბორდი: გასაღებების მიმოხილვა, მოცილების დადასტურება, დახურვის აქტი.
მონიტორინგი: არანორმალური მოცულობის ალერტები, მასობრივი ექსპორტის აკრძალვა.

8) პროცესები (SOP)

8. 1 მოთხოვნა/დაშვების შეცვლა

1. განაცხადი IDM/ITSM პურითა და ვადით.
2. მანქანის მრჩეველი SoD/იურისდიქცია/მონაცემთა კლასი.
3. დომენის მფლობელის დამტკიცება + Security/Compliance (თუ Restricted +).
4. JIT/მუდმივი წვდომის გაცემა (მინიმალური ნაკრები).
5. ჟურნალები: ვინ/როდის/რა გაიცემა; გადასინჯვის თარიღი.

8. 2 პერიოდული გადასინჯვა

კვარტალი: მეპატრონეები ადასტურებენ ჯგუფების უფლებებს; გამოუყენებელი უფლებების ავტომატური მიღება (> 30/60 დღე).

8. 3 მონაცემთა ექსპორტი

მხოლოდ დამტკიცებული დანამატების/ფანჯრების საშუალებით, ფორმატის თეთრი სიების მიხედვით (CSV/Parquet/JSON), ნაგულისხმევი შენიღბვა, ხელმოწერა/ჰაში, გადმოტვირთვის ჟურნალი.

9) მოწყობილობების პოლიტიკა და კონტექსტი

MDM/EMM: Restricted/Highly Restricted- ზე წვდომა მხოლოდ კონტროლირებადი მოწყობილობებიდან.
კონტექსტური სიგნალები: გეო, მოწყობილობის რისკი, დღის დრო, MFA მდგომარეობა, IP რეპუტაცია - როგორც ABAC ატრიბუტები.
ბრაუზერის გაფართოებები/ეკრანის დაჭერა: კონტროლი და ჟურნალი, მგრძნობიარე კონსოლების აკრძალვა.

10) პოლიტიკოსის მაგალითები (ფრაგმენტები)

10. 1 YAML (ფსევდო) - ABAC მარკეტინგის ანალიტიკოსისთვის

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 SQL ნიღაბი (იდეა)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) მონიტორინგი, ჟურნალები და ალერტები

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs: წვდომა 'purpose' = 0 გარეშე; Highly Restricted- ის მცდელობები ფანჯრის გარეთ; წარუმატებელი SoD შემოწმებების წილი; არანორმალური გადმოტვირთვის.
KPI: JIT მოთხოვნის% 80% -ზე; წვდომის საშუალო დრო არის 4 საათი; საფარი 100% -იანი რესტრუქტურიზაციით.
SOAR playbuks: მანქანის მიმოხილვა მუქარით, გამოძიების თიკეტები.

12) მოთხოვნებთან შესაბამისობა (მოკლე რუკა)

GDPR/UK GDPR: შემცირება, Need-to-Know, DSAR თავსებადობა, PII აუდიტი.
AML/KYC: KUS/სანქციებზე წვდომა მხოლოდ გაწვრთნილი როლებისთვის არის, გადაწყვეტილებების ჟურნალი.
PCI DSS (თუ გამოიყენება): გადახდის ზონის სეგრეგაცია, PAN/CSC შენახვის აკრძალვა, ინდივიდუალური გასაღებები/მასპინძლობა.
ISO/ISMS: ოფიციალური წვდომის პოლიტიკოსები, ყოველწლიური აუდიტი და ტესტები.

13) PACI

14) სიმწიფის მეტრიკა

კრიტიკული მონაცემთა ნაკრების ABAC წესების დაფარვა 95% -ს შეადგენს.
JIT სესიები/უფლებების ყველა ზრდა 90% -ს შეადგენს.
offboarding- ზე წვდომის დრო 15 წუთია.
0 ინციდენტი „როლი - ფუნქცია“ (SoD).
ხელმისაწვდომობის ჟურნალების 100% ხელმისაწვდომია და გადამოწმებულია (ხელმოწერა/ჰაში).

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

15. 1 დაშვებამდე

• განსაზღვრულია purpose, მონაცემთა ვადა და მფლობელი
• SoD/იურისდიქციების შემოწმება დასრულდა
• მინიმალური სკოპი/ნიღაბი შედის
• MFA/MDM/ქსელის პირობები დაცულია

ჟურნალისტიკა და გადასინჯვის თარიღი

15. 2 კვარტალური მიმოხილვა

• ჯგუფებისა და როლების შერჩევა ორგანიზაციული სტრუქტურით

„ჩამოკიდებული“ უფლებების ავტომობილი

• არანორმალური ექსპორტის და break-glass- ის შემოწმება
• ტრენინგი და ტესტის ალერტები

16) ტიპიური სცენარები და ზომები

ა) ახალი როლი „VIP მენეჯერი“

VIP პროფილებზე წვდომა (შენიღბული), ექსპორტის აკრძალვა, JIT ერთჯერადი KYC სანახავად თიკეტის საშუალებით.

B) Wendor აუდიტი BI

PII, დროებითი VPN + allow-list, ადგილობრივად შენარჩუნების აკრძალვა, გადმოტვირთვის ჟურნალი.

C) DevOps- ის გადაუდებელი წვდომა Stream BD- ზე

break-glass - 30 წუთი, სესიის ჩაწერა, პოსტ-რემისია DPO/Compliance, CAPA დარღვევების დროს.

17) საგზაო რუკა

კვირები 1-2: მონაცემთა/სისტემების ინვენტარიზაცია, მონაცემთა კლასები, ძირითადი RBAC მატრიცა, SoD.
კვირები 3-4: შემოიღეთ ABAC (პირველი ატრიბუტები: გარემო, გეო, მონაცემთა კლასი), IDM ნაკადები, JIT/break-glass, PAM.
თვე 2: გადახდის სეგმენტი და KYC პერიმეტრი, ინდივიდუალური გასაღებები/KMS, ექსპორტის ჟურნალები, SOAR ალერტები.
თვე 3 +: კვარტალური რესტრუქტურიზაცია, ატრიბუტების გაფართოება (მოწყობილობა/რისკი), შენიღბვის ავტომატიზაცია, რეგულარული წვრთნები.

TL; DR

საიმედო წვდომის მოდელი = მონაცემთა კლასიფიკაცია - RBAC + ABAC, SoD + JIT/PAM - მკაცრი სეგმენტი - ჟურნალები და ალერტები. ეს ამცირებს გაჟონვისა და ბოროტად გამოყენების ალბათობას, აჩქარებს აუდიტს და ინახავს პლატფორმას GDPR/AML/PCI და შიდა სტანდარტებში.