პრივილეგიების სეგმენტი
1) რატომ არის საჭირო სეგმენტი
პრივილეგიების სეგმენტი არის „blast radius“ შეცდომების შემცირების და ინსაიდერის ბოროტად გამოყენების გასაღები. ეს საშუალებას გაძლევთ ზუსტად შეზღუდოთ ვინ და სად შეუძლია შეასრულოს რა ქმედებები რომელ მონაცემებთან, ხოლო შეინარჩუნოთ ოპერაციების სიჩქარე და შესაბამისობა რეგულატორების მოთხოვნებთან.
მოგება:- ნაკლები ინციდენტი „ზედმეტი უფლებების“ გამო;
- გამოძიების დაჩქარება: ხელმისაწვდომობა გამჭვირვალე და გასაგებია;
- შესაბამისობა SoD/შესაბამისობაში დადასტურებული აუდიტი;
- უსაფრთხო ექსპერიმენტები და სწრაფი გამოშვებები პროდ ბირთვის რისკის გარეშე.
2) პრინციპები
Zero Trust: თითოეული მოქმედება შემოწმებულია კონტექსტურად; არ არსებობს „სანდო ტერიტორიები“.
Least Privilege: მინიმალური უფლებები გაიცემა მინიმალური ვადით (იდეალურად - JIT).
Context over Role: უფლებები დამოკიდებულია არა მხოლოდ როლზე, არამედ ატრიბუტებზეც (ტენანტი, რეგიონი, გარემო, რისკი).
Segregation of Duties (SoD): ჩვენ ვიზიარებთ წამოწყებას, მოწონებას, შესრულებას და აუდიტს.
Policy-as-Code: პოლიტიკა კოდით ვერსიით, ტესტებით და შურისძიებით.
3) წვდომის სიმწიფის მოდელი
1. RBAC (roles): დაწყება - ფიქსირებული როლები (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributes): ჩვენ დავამატებთ ატრიბუტებს: ტენანტი, რეგიონი, იურისდიქცია, პროდუქტი, არხი, გარემო (stage/dev), დრო, ოპერაციის რისკის კლასი, KRI სიგნალები.
3. PBAC (პოლიცია): ცენტრალიზებული პოლიტიკოსები „ვინ/რა/სად/როდის/რატომ“ + პირობები (მაგალითად, „გაყიდვაში - მხოლოდ JIT და თიკეტით“).
4) სეგმენტის დომენები (ღერძი ღერძის მიღმა)
4. 1 ტენანტი/კლიენტი
წვდომა და ოპერაციები შემოიფარგლება მხოლოდ კონკრეტული ბრენდის/ოპერატორის/აფილატის მიერ.
აკრძალულია ჯვარედინი ჩრდილოვანი მოქმედებები, გარდა PII- ის გარეშე მკაცრად განსაზღვრული ერთეულებისა.
4. 2 რეგიონი/იურისდიქცია
პოლიტიკოსები ითვალისწინებენ ადგილობრივ ლიცენზირებულ და KYC/AML წესებს.
ამ მოთამაშესთან ოპერაციები შემოიფარგლება მხოლოდ შენახვისა და დამუშავების გეოგრაფიით.
4. 3 გარემო (dev/stage/country)
იზოლირებული: ცალკეული კრედიტები, ქსელები, Bastion/PAM, „read-only ნაგულისხმევი“.
მხოლოდ JIT- ზე წვდომა, თიკეტი და ცვლილებების ფანჯრები.
4. 4 მონაცემთა კლასი
PII/ფინანსები/თამაშის ტელემეტრია/ტექნოლოგია - წვდომისა და შენიღბვის სხვადასხვა დონე.
PII- ის ექსპორტი მხოლოდ დამტკიცებული დაშიფვრის და TTL- ის საშუალებით ხდება.
4. 5 ოპერაციების კრიტიკა
კლასები P1/P2/P3: კოეფიციენტების გამოქვეყნება, სახელმძღვანელო კლასები, დასკვნები, PSP როუტინგის შეცვლა - საჭიროა სრული კონტროლი.
დაბალი კორუფციის ოპერაციები შეიძლება აღიჭურვოს პოლიტიკით.
5) პრივილეგიების დონე
Viewer: მხოლოდ დანაყოფების კითხვა და შენიღბული მონაცემები.
ოპერატორი: პროცედურების შესრულება ranbooks, კონფიგურაციის შეცვლის გარეშე.
კონტრიბუტორი: კონფიგურაციის შეცვლა არა კრიტიკულ დომენებში.
Approver: განაცხადების დამტკიცება და მაღალი რისკის ოპერაციები (არ არის შერწყმული შესრულებასთან - SoD).
Admin (JIT): მოკლევადიანი ზრდა იშვიათი პრობლემებისთვის, ორმაგი კონტროლისთვის და სესიის ჩაწერისთვის.
6) SoD და შეუთავსებელი როლები
შეუთავსებლობის მაგალითები:- დასკვნების წამოწყება და დამტკიცება და დასკვნით ჩატარება.
- შექმენით ბონუსის კამპანია, გააქტიურეთ გაყიდვაში და შეცვალეთ ლიმიტები.
- შეიმუშავეთ ხრიკი და გამოიყენეთ გამოშვება, გადაიტანეთ პროდ.
- მოითხოვოს PII- ის გადმოტვირთვის მოთხოვნა, დამტკიცდეს და გაშიფროს.
თითოეული წყვილისთვის - აკრძალვის ოფიციალური პოლიტიკა და გამონაკლისი გადასინჯვის თარიღით.
7) JIT წვდომა და PAM
Elevation მოთხოვნით: მითითებულია მიზანი/ticket/ვადა; გასვლის შემდეგ - მანქანის მიმოხილვა.
ორმაგი კონტროლი: P1/P2 მოქმედება - ორი დამხმარე სხვადასხვა ფუნქციიდან.
სესიის კონტროლი: კრიტიკული სესიების ჩაწერა, ანომალიების ალერტები, კოპიპასტის აკრძალვა PII- სთან მუშაობის დროს.
Break glass: გადაუდებელი წვდომა მკაცრი ლიმიტებით და სავალდებულო პოსტ-აუდიტით.
8) მომსახურების ანგარიშები და API ოფისები
მინიმალური ნაგავი; დაყოფა დავალებების/მიკროსერვისების მიხედვით; ხანმოკლე ნიშნები/სერთიფიკატები.
საიდუმლოების როტაცია, საიდუმლოების აკრძალვა; აკრძალვა „god-scope“.
Limites on rate/ítas, idempotence გასაღებები, Webhuks- ის ხელმოწერა (HMAC).
9) სეგმენტი ინფრასტრუქტურის დონეზე
ქსელები: სეგმენტების იზოლაცია (per-domain/per-tenant), ნაგულისხმევი აკრძალვა, mTLS.
Kubernetes/Cloud: neimespaces/per and domen პროექტები, Gatekeeper/OPA საშიში შაბლონების აკრძალვის მიზნით.
BD/Kashi: წვდომის ბროკერი (DB proxy/IAM), ნაგულისხმევი რეალობა, DDL აკრძალვა ფანჯრის გარეთ გაყიდვაში.
საცავი: სხვადასხვა კლავიშები/მონაცემთა ბაზები TTL და WORM პოლიტიკოსებთან აუდიტის მიზნით.
10) პოლიტიკა, როგორც კოდი (PaC)
პოლიტიკოსები საცავებში (Rego/YAML), PR შურისძიება, მანქანების ტესტები (unit/e2e), აუდიტი.
დინამიური კონტექსტი: დღის დრო, ადგილმდებარეობა, KRI დონე, რისკის ესკალაცია.
Allow/deny- ის გადაწყვეტილების განმარტება და პოლიტიკის მითითება აუდიტში.
11) ჟურნალები და აუდიტი
სისრულე: ვინ/რა/სად/როდის/რატომ, წინა/პოსტ-მნიშვნელობები, თიკეტის ID.
შეუსაბამობა: ცენტრალიზებული კოლექცია, WORM/immutable, ჩანაწერების ხელმოწერა.
კავშირი: ჯაჭვი API - BD - გარე პროვაიდერები.
SLA აუდიტი: რეაგირების სიჩქარე კონტროლის/რეგულატორის მოთხოვნებზე.
12) დაშბორდი და მეტრიკა (KPI/KRI)
KPI წვდომა: JIT მუდმივი უფლებების წილი, საშუალო შეღავათების ხანგრძლივობა, SoD- ით დაფარული%, განაცხადების დამუშავების დრო, რეცესიის დაფარვა.
KRI ბოროტად გამოყენება: მგრძნობიარე ოპერაციების ზრდა, მასობრივი გადმოტვირთვა, ატიპიური ადგილები/საათი, თანმიმდევრობა „განაცხადი - მოქმედება - დაბრუნება“.
Exec-dashboard: მაღალი რისკის როლების სტატუსის ტრეკი, ღონისძიებების break-glass, ტენდენციები.
13) პოლიტიკოსის მაგალითები (ესკიზები)
Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.
14) განხორციელების გზის რუკა (8-12 კვირა)
ნვე. 1-2: ოპერაციების/როლების/მონაცემების ინვენტარიზაცია, SoD მატრიცა, მონაცემთა კლასიფიკაცია და სეგმენტის დომენები.
ნვე. 3-4: RBAC ბაზა, როლების კატალოგი, JIT პრო-კონსოლებისთვის, დაწყება PaC (OPA/Gatekeeper).
ნვე. 5-6: ABAC: ტენანტის/რეგიონის/გარემოს/მონაცემთა კლასის ატრიბუტები; ნეიმსპეისის/პროექტების გამიჯვნა.
ნვე. 7-8: PAM (JIT-elevation, სესიების ჩანაწერი, break-glass), DDL აკრძალვა და BD ბროკერი, PII ექსპორტის პოლიტიკა.
ნვე. 9-10: PBAC მაღალი რისკის ოპერაციებისთვის (დასკვნები, პრემიები, PSP), ორმაგი კონტროლი, KRI ალერტები.
ნვე. 11-12: კვარტალური რეცესიფიკაცია, PaC- ის 100% მაღალი დონის ოპერაციების დაფარვა, ანგარიშები და ტრენინგი.
15) არტეფაქტები
Role Catalog: როლები, მინიმალური პრივილეგიები, მფლობელები.
SoD Matrix: შეუთავსებელი როლები/ოპერაციები, გამონაკლისები, override პროცესი.
Policy Pack: PaC პოლიტიკის ნაკრები ტესტებითა და მაგალითებით deny/allow.
Access Request Form: მიზანი, ვადა, ობიექტი (ტენანტი/რეგიონი/გარემო), რისკის შეფასება, აპრუნვერები.
სენსაციური Ops Register: P1/P2 მოქმედებების ჩამონათვალი, ფანჯრები, ორმაგი კონტროლის კრიტერიუმები.
Audit Playbook: ჟურნალების შეგროვება და მიწოდება, SLA პასუხი, როლები.
16) ანტიპატერები
მუდმივი admin უფლებები და ზოგადი ანგარიშები.
ჯვარედინი ჩრდილოვანი წვდომა „მოხერხებულობისთვის“.
იზოლაციის იზოლაციის არარსებობა/stage/dev.
პოლიტიკოსები ქაღალდზე enforce კოდის/კონსოლების გარეშე.
PII- ის ექსპორტი ხელით შეთანხმების გარეშე დაშიფვრის გარეშე და TTL.
რეცესიების არარსებობა და „შემცირებული“ უფლებები.
17) შედეგი
პრივილეგიების სეგმენტი არ არის მხოლოდ „სწორი როლები“. ეს არის მრავალგანზომილებიანი იზოლაცია (ტენანტი, რეგიონი, გარემო, მონაცემები, კრიტიკა) + დინამიური კონტექსტი (ABAC/PBAC) + პროცესები (SoD, JIT, რეცესიფიკაცია) + ტექნიკური იძულება (PaC, PAM, ქსელები/BD). ასეთი წრე მკვეთრად ამცირებს შეცდომების და ბოროტად გამოყენების რისკს, აჩქარებს უსაფრთხო ცვლილებებს და პლატფორმას უწევს მასშტაბის და რეგულატორების მოთხოვნებს.