Identity & Access Management

მოკლე რეზიუმე

IAM არის პროცესების, პოლიტიკოსებისა და ინსტრუმენტების ერთობლიობა, რომლებიც უზრუნველყოფენ ვინ იღებს წვდომას რა, რა პირობებში და როგორ კონტროლდება. მიზნები: გადაჭარბებული უფლებების შემცირება, შეტევის ზედაპირის შემცირება, ონბორდინგისა და აუდიტის დაჩქარება, მოთხოვნების დაცვა (PCI DSS, GDPR და ა.შ.) და წვდომის გაზომვის საიმედოობა.

ძირითადი ცნებები

პირადობა: ადამიანი (თანამშრომელი, კონტრაქტორი), მომსახურება/პროგრამა, მოწყობილობა.
ავთენტიფიკაცია (AuthN): შემოწმება „ვინ“ (პაროლი - MFA - უფასო FIDO2/passkeys სქემები).
ავტორიზაცია (AuthZ): გამოსავალი „რა არის ნებადართული“ (RBAC/ABAC/ReBAC, პოლიტიკოსები).
ანგარიშები (კრედიტები): პაროლები, გასაღებები, ნიშნები, სერთიფიკატები (mTLS).
საიდუმლო მენეჯმენტი: KMS/HSM/Vault, როტაცია, მოკლე TTL, დინამიური საიდუმლოებები.
სასიცოცხლო ციკლი: Joiner-Mover-Leaver (JML) - შექმნა, როლების შეცვლა, მიმოხილვა.

IAM სამიზნე არქიტექტურა

თვითმფრინავი და როლები:

IDP (იდენტურობის მიმწოდებელი): SSO, MFA, კატალოგი, ფედერაცია (OIDC/SAML), რისკის პოლიტიკა.
PDP/PEP: Decision/Enforcement - პოლიტიკოსის ძრავა (OPA/Cedar) + გამოყენების წერტილები (API კარიბჭეები, მარიონეტული, სამსახურის მესა).
კატალოგები/HR სისტემა: ჭეშმარიტების წყარო თანამშრომლებისა და როლებისთვის.
Provizing: SCIM/Automation, წვდომის შექმნა/შეცვლა/გაწვევა.
აუდიტი: ცენტრალიზებული ლოგოები, UEBA, მოხსენებები როლებისა და წვდომის შესახებ.

წვდომის ნაკადი:

SSO (+ MFA) - ნიშნის გამოშვება (OIDC/JWT/SAML), PEP ამოწმებს ნიშანს/კონტექსტს, PDP წყვეტს პოლიტიკას (როლი/ატრიბუტები/რისკი), პროგრამა იძლევა/წვდომას.

ავთენტიფიკაცია: პაროლებიდან passkeys- მდე

პაროლები: მხოლოდ პაროლის მენეჯერებთან, მინიმუმ 12-14 სიმბოლოსთან, როტაციის გარეშე „კალენდრის მიხედვით“, მაგრამ სავალდებულო ინციდენტთან.
MFA ნაგულისხმევი: TOTP/WebAuthn/Push; თავიდან აიცილოთ SMS, როგორც მთავარი ფაქტორი.
უპრეცედენტო შესასვლელი: FIDO2/passkeys კრიტიკული დომენებისთვის.
ადაპტირებული AuthN: გაითვალისწინეთ რისკის სიგნალი (გეო, ASN, მოწყობილობა, ანომალიები), მოითხოვეთ დამატებითი ფაქტორი/დაბლოკვა.

საავტორო უფლებები: RBAC, ABAC, ReBAC

RBAC: ფუნქციების შესაბამისი როლები (მხარდაჭერა, Finance, DevOps). მარტივი და გასაგები, მაგრამ „იზრდება“.
ABAC: ატრიბუტის წესები (განყოფილება, რისკის დონე, დრო, ზონა, რესურსების ეტიკეტი). მასშტაბური.
ReBAC: ურთიერთობები „ვინ რას ეხება“ (პროექტების მფლობელები, გუნდების მონაწილეები). მოსახერხებელია მრავალმხრივი სცენარისთვის.

საუკეთესო პრაქტიკა:

დააკავშიროთ RBAC (საბაზო ბადე) + ABAC/ReBAC (კონტექსტი/საზღვრები).
JIT (Just-In-Time): დროებითი პრივილეგიების გაცემა მოთხოვნის/აპლიკაციის საშუალებით, ავტომატური მიმოხილვა.
JEA (Just-Enough წვდომა): ოპერაციის მინიმალური საკმარისი უფლებები.
PAM: იზოლირებული „ძლიერი“ წვდომა (BD/ღრუბლების ადმირალები) ბროკერის სესიებით, ეკრანის/ბრძანებების ჩაწერა და მოკლევადიანი კრედიტების გაცემა.

ფედერაცია და SSO

ოქმები: OIDC (JWT ნიშნები), SAML 2. 0 (XMLassertions) - გარე პროვაიდერების/პარტნიორებისთვის.
SSO: ერთი შესასვლელი წერტილი MFA- სთან, ფიშინგის შემცირება, ცენტრალიზებული მიმოხილვა.
B2B/B2C: ფედერაცია პარტნიორებთან, რეგიონების შეზღუდვა, აფეთქების ღუმელის პოლიტიკოსები.
mTLS/m2m: გამოიყენეთ მოკლე ცოცხალი x.509 (SPIFFE/SVID) ან OAuth2 Client Credentials მომსახურებისთვის.

სასიცოცხლო ციკლი (JML) და დებულებები

Joiner: ავტომატური SCIM დებულებების აღრიცხვა და ძირითადი როლები HR/კატალოგიდან.
Mover: როლები ავტომატურად იცვლება ატრიბუტებით (განყოფილება, პროექტი, ადგილმდებარეობა).
Leaver: დაუყოვნებლივი მიმოხილვა SSO, გასაღებები, ნიშნები, წვდომა საცავებზე/ღრუბლებზე/CI/CD.
პროცესები: წვდომის განაცხადები (ITSM), SoD მატრიცა (მოვალეობების გამიჯვნა), პერიოდული წვდომის მიმოხილვა.

საიდუმლოებები, გასაღებები და როტაცია

KMS/HSM: შეინახეთ ფესვი/კრიტიკული გასაღებები, ჩართეთ ოპერაციების აუდიტი.
Vault/Secrets მენეჯერები: დინამიური კრედიტები (BD, ღრუბლები), მანქანები TTL- ის დასრულების დროს.
როტაციები: OAuth ნიშნები, JWT ხელმოწერის გასაღებები, სერვისების პაროლები - გრაფიკით და ინციდენტებით.
mTLS: მოკლემეტრაჟიანი სერთიფიკატები (საათი/დღეები), ავტომატური გამოცემა.

პოლიტიკა და გადაწყვეტილებების ძრავა

დეკლარაცია: შეინახეთ პოლიტიკოსები გიტში; შეამოწმეთ CI (პოლიცია-ტესტი).
კონტექსტი: დრო/ადგილმდებარეობა/ASN/მოწყობილობის რისკის დონე/მდგომარეობა (MDM/EDR).

მაგალითი (რეგო, გამარტივებული):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

მონიტორინგი, SLO და აუდიტი

მეტრიკა:

AuthN/AuthZ- ის წარმატება (%), ლოგინის/გადაწყვეტილების დროის p95, MFA- ს წილი/ცუდი შესასვლელი.
JIT/PAM ესკალაციების რაოდენობა, შეღავათების საშუალო ხანგრძლივობა.
კომპლექსური მოწყობილობების გაშუქება, ხანმოკლე საიდუმლოებების წილი.

SLO (მაგალითები):

SSO/IDP წვდომა 99. თვეში 95%.
p95 AuthZ decision ≤ 50 мс.
100% ანგარიშის გათიშვა 15 წუთის შემდეგ ხდება.
აუდიტი და UEBA: ცენტრალიზებული უცვლელი ლოგოები (წვდომა, როლების შეცვლა, წარუმატებელი შეყვანა, PDP გადაწყვეტილებები), ქცევითი ანალიტიკა და განგაშის ანომალიები.

საპასუხო ინციდენტი IAM- ში

ტოქსინების/გასაღებების კომპრომისზე: დაუყოვნებლივი მიმოხილვა, იძულებითი ლოგო, ხელმოწერის გასაღებების როტაცია, მოკლე საიდუმლოებების re-issue.
უფლებების ბოროტად გამოყენება: ანგარიშის შეჩერება, JIT/JEA- ს დაბლოკვა, მეზობელ ერთეულებზე წვდომის განხილვა.
IDP მიუწვდომელია: ოფლაინ რეჟიმები (მოკლე TTL- ის ტოქსინების დროებითი ქეში), აღდგენის პრიორიტეტული პროცედურები.
ფიშინგი: სავალდებულო MFA, სესიების რისკის შემოწმება, მომხმარებლებისთვის შეტყობინებები, ტრენინგი.

ღრუბლები და კუბერნეტები (ნიმუშები)

Public Cloud IAM: გამოიყენეთ მშობლიური როლები გრძელი პირადი პრინციპით; „მარადიული“ გასაღებების ნაცვლად - სამუშაო დატვირთვა OIDC ფედერაციასთან ღრუბელთან (IRSA/Workload Identity).
Kubernetes: RBAC ნეიმსპეისებზე/როლებზე, შეზღუდეთ 'cluster-admin'; საიდუმლოებები - გარე მენეჯერების მეშვეობით; სერვისი-mesh + OPA L7 პოლიტიკოსისთვის; Admission კონტროლერები (ხელმოწერილი სურათები, აკრძალვა „: latest“).
API კარიბჭეები: JWT/mTLS შემოწმება, სიჩქარის შეზღუდვა, მოთხოვნის ხელმოწერა (HMAC) მგრძნობიარე ენდოინტებისთვის.

პრაქტიკა iGaming/fintech

წვდომის დომენები: გადახდები, ანტიფროდი, PII, შინაარსის პროვაიდერები - როლებისა და ქსელის სეგმენტების იზოლირება.
SoD: კონფლიქტური როლების გაერთიანების აკრძალვა (მაგალითად, პრომო + გადახდის დამტკიცება).
PAM და JIT: PSP/Banks- სა და Prod BD- ში შესასვლელად - მხოლოდ სხდომების ბროკერის საშუალებით, ჩანაწერით და მანქანის მიმოხილვით.
შესაბამისობა: PCI DSS - MFA, მინიმალური პრივილეგიები, CHD ზონის სეგმენტი; GDPR არის მონაცემთა შემცირების პრინციპი და PII წვდომის წერტილოვანი ლოგოები.
შინაარსის პარტნიორები და პროვაიდერები: ფედერაცია და მთავარი პოლიტიკა; ხანმოკლე ნიშნები და IP/ASN allow-list.

ტიპიური შეცდომები

„მარადიული“ გასაღებები და ნიშნები: არ არსებობს როტაცია და TTL - გაჟონვის მაღალი რისკი.
ხელით დაბლოკვა: უფლებების გაწვევის შეფერხებები „მოჩვენებითი“ წვდომაა.
მონოლითური როლები: კომპოზიციისა და ატრიბუტების ნაცვლად ერთი „სუპერ როლი“.
MFA მხოლოდ განყოფილებაში: MFA უნდა იყოს ყველა შესასვლელი და კრიტიკული ოპერაციისთვის.
Logs „არსად“: არ არსებობს ცენტრალიზაცია და UEBA - ინციდენტების მოგვიანებით გამოვლენა.

IAM საგზაო რუკა

1. მომხმარებელთა/სერვისების/რესურსების ინვენტარიზაცია; მონაცემთა და მგრძნობელობის რუკა.
2. SSO + MFA ყველასთვის, მოიცავს phishing-resistant ფაქტორებს.
3. როლის მოდელი: ძირითადი RBAC + ატრიბუტები (ABAC) კონტექსტისთვის; SoD მატრიცა.
4. SCIM დებულებები: HR/კატალოგიდან უფლებების შექმნა/შეცვლა/გაუქმება; განაცხადები და აფრები ITSM- ში.
5. PAM და JIT/JEA: პრივილეგირებული წვდომისთვის; სესიების ჩაწერა მოკლე TTL.
6. საიდუმლო მენეჯმენტი: სტატიკური გასაღებების უარყოფა; დინამიური საიდუმლოებები, როტაცია, mTLS მოკლე სერთიფიკატებით.
7. პოლიტიკოსები Git + CI- ში: წესების ტესტები, ცვლილებების კონტროლი, პოლიტიკოსის კანარის განლაგება.
8. დაკვირვება და SLO: AuthN/AuthZ დაშბორდები, ალერტები, რეგულარული წვდომის მიმოხილვა.

არტეფაქტების მაგალითები

AWS IAM პოლიტიკა (მინიმუმ S3 ანგარიშის კითხვისთვის)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (namespace-scoped დეველოპერი)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: განცხადებები ABAC- სთვის (მაგალითი)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

პოლიტიკა შეიძლება მოითხოვდეს 'მოწყობილობას _ კომპლექსს = ნამდვილ „და' tenant“ რესურსს.

საკონტროლო სია (შემოწმების სია)

SSO შედის ყველა პროგრამაში; MFA ნაგულისხმევი, passkeys პრიორიტეტულია.
RBAC განსაზღვრულია; ABAC/ReBAC ემატება კონტექსტს; განხორციელდა JIT/JEA.
PAM იცავს პრივილეგირებულ წვდომას; სხდომები იწერება.
SCIM დებულებები HR- დან; offboarding მთლიანად ავტომატიზირებულია.
დინამიური საიდუმლოებები, მოკლე TTL; როტაცია ავტომატიზირებულია.
პოლიტიკოსები ვერსირებულია Git- ში, ტესტირება ხდება CI- ში; არსებობს კანარის გამოთვლები.
დაშბორდი და SLO AuthN/AuthZ; ცენტრალიზებული ლოგოები და UEBA.
პერიოდული წვდომა და SoD შემოწმება; მოხსენებები კომპლენსისთვის.

FAQ

სჭირდება ReBAC ყველას?
არა. მარტივი მედიისთვის საკმარისია RBAC + ABAC. ReBAC სასარგებლოა რესურსების და მრავალმხრივი საკუთრების რთული იერარქიით.

შესაძლებელია თუ არა ადგილობრივი ანგარიშების დატოვება?
მხოლოდ break-glass და offline სცენარებისთვის, მკაცრი შეზღუდვებითა და პერიოდული შემოწმებით.

როგორ შევამციროთ „როლების აფეთქება“?
რესურსების მარცვლეულის ამაღლება, AVAS/შაბლონების გამოყენება, შურისძიების ავტომატიზაცია და გამოუყენებელი როლების მიტოვება.

შედეგი

სექსუალურ IAM არქიტექტურა არის SSO + MFA, მინიმალური საჭირო უფლებები, ავტომატიზირებული JML, ცენტრალიზებული პოლიტიკოსები და დაკვირვება. RBAC- ს შერწყმა ატრიბუტით და რელიეფური მოდელებით, JIT/JEA და PAM- ის გამოყენებით, ასევე საიდუმლოებების ნავიგაციისა და როტაციის ავტომატიზაციით, თქვენ მიიღებთ კონტროლირებად, დამოწმებულ და მასშტაბურ წვდომას, რომელიც აკმაყოფილებს უსაფრთხოების და ბიზნესის მოთხოვნებს.