Identity və access management

Breach-lərin əksəriyyəti hiyləgər exploit-lə başlamır. Onlar credential ilə başlayır: phishing-lə ələ keçirilmiş, təkrar istifadə olunmuş, leak olmuş, təxmin edilmiş və ya config faylında qalmış. Attacker identity əldə etdikdən sonra heç nəyi sındırmağa ehtiyac duymur; sadəcə login edir. Buna görə də identity və access management ən çox əhəmiyyət kəsb edən və ən çox səhv icra olunan control-dur.

Üç sual

Hər access qərarı üç suala ardıcıllıqla cavab verir:

Authentication: sən kimsən? (identity-nin sübutu)
Authorization: sənə nə etməyə icazə var? (permission-un yoxlanması)
Accounting: sən nə etdin? (hərəkətin qeydə alınması)

Bunları qarışdıran sistemlər, məsələn, "login olub" check-ini "icazəsi var" kimi qəbul edənlər, elevation-of-privilege bug-larının mənbəyidir.

Authentication

Password-lər

Password-lər hələ də hər yerdədir və hələ də ən zəif həlqədir. Risk-i həqiqətən azaldan qaydalar:

Mürəkkəblikdən çox uzunluq. Uzun passphrase simvollu qısa sətirdən üstündür. Dövri rotation-u məcbur etməyin; bu, proqnozlaşdırıla bilən variasiyalar yaradır.
Breach siyahıları ilə yoxlayın. Məlum leak-lərdə görünən password-ləri rədd edin.
Yavaş hash ilə saxlayın. Argon2id və ya bcrypt, hər password üçün ayrıca salt ilə. Heç vaxt sürətli hash, heç vaxt geri çevrilə bilən encryption, heç vaxt plaintext.
Cəhdləri rate limit edin və lock out edin, həm account, həm də mənbə üzrə, lakin qanuni istifadəçilərə qarşı denial of service-ə imkan yaratmamağa diqqət edərək.

Multi-factor authentication

MFA credential oğurluğuna qarşı ən effektiv control-dur. Factor-lar bildiyiniz (password), sahib olduğunuz (device, key) və ya olduğunuz (biometric) şeylərdir. İkinci factor-ların hamısı bərabər deyil:

SMS kodları: heç nədən yaxşıdır; SIM swapping və interception-a qarşı həssasdır.
Authenticator app-lər (TOTP): yaxşıdır; real-time phishing proxy-lərinə qarşı həssasdır.
Push notification-lar: rahatdır; attacker-lərin istifadəçi "approve" düyməsinə basana qədər prompt-ları yağdırdığı "MFA fatigue"-ə qarşı həssasdır. Number matching tələb edin.
Hardware key-lər / passkey-lər (FIDO2/WebAuthn): phishing-resistant-dır, çünki credential saytın origin-inə bağlıdır. Hədəf vəziyyət budur.

MFA-nı bütün əməkdaşlar və bütün admin access-i üçün məcburi edin, bütün istifadəçilərə isə təklif edin. Elevated access-i olan hər kəs üçün phishing-resistant factor-lara üstünlük verin.

Session-lar və token-lər

Authentication-dan sonra istifadəçi session identifier və ya token saxlayır. Ona əvəz etdiyi password kimi yanaşın:

Kriptoqrafik random mənbə ilə yaradın; təxmin edilməz olacaq qədər uzun.
Yalnız TLS üzərindən ötürün. Cookie-ləri Secure, HttpOnly, SameSite kimi işarələyin.
Expire edin. Qısaömürlü access token-lər, revoke edilə bilən refresh token-lərlə.
Fixation-un qarşısını almaq üçün login zamanı və privilege dəyişəndə session ID-ni rotate edin.
Aktiv session-ları görmək və revoke etmək imkanı verin.

JSON Web Token-lər rahatdır və tez-tez yanlış istifadə olunur: signature-i icazə verilən alqoritmlərin allowlist-i ilə validate edin, expiry-ni yoxlayın və heç vaxt payload-a secret-lər yerləşdirməyin. JWT expiry-dən əvvəl revoke edilə bilməz, yalnız denylist saxlasanız mümkündür, bu da onun stateless cazibəsinin böyük hissəsini aradan qaldırır.

Token-i qəbul edən hər service bu yoxlamaları özü aparmalıdır:

Yoxlama	Atlananda nə olur
Signature, sabit alqoritm allowlist-i ilə	`alg: none` və ya HS256/RS256 qarışdırılması ilə saxta token qəbul olunur
`exp` və `nbf`	Oğurlanmış token sonsuza qədər işləyir
`iss`	Başqa identity provider-in token-i qəbul olunur
`aud`	Başqa service üçün verilmiş token bu service-də də işləyir
Scope və ya permission claim-ləri	Yalnız oxumaq üçün verilmiş token yazmağa da imkan verir

Signing key-ləri token-in öz header-indən (jku, x5u) deyil, yalnız əvvəlcədən konfiqurasiya edilmiş mənbədən götürün. Əks halda attacker yoxlama üçün öz key-ini göstərir.

Timing attack-lər

Secret-i, token-i və ya HMAC-ı adi == ilə müqayisə etmək ilk fərqli simvolda dayanır. Cavab vaxtını ölçən attacker dəyəri simvol-simvol təxmin edə bilər. Bunun üçün constant-time müqayisə funksiyasından istifadə edin; demək olar ki, hər dilin crypto library-sində belə funksiya var.

Login də eyni problemi daşıyır. Mövcud olmayan istifadəçi üçün dərhal "səhv" qaytaran, mövcud olan üçün isə yavaş password hash-i hesablayan endpoint hansı account-ların mövcud olduğunu açır. Hər iki halda hash-i hesablayın və eyni error mesajını qaytarın.

Delegated access: OAuth 2.0 və OpenID Connect

İstifadəçi third-party application-a öz data-sına access vermək istəyəndə, ona password-unu verməməlidir. OAuth 2.0 bunu həll edir: istifadəçi authorization server-də authenticate olur, razılıq verir, application isə konkret scope-la məhdud, qısaömürlü access token alır. OAuth authorization protokoludur: "bu client-ə nə etməyə icazə var" sualına cavab verir.

OpenID Connect (OIDC) OAuth-un üzərinə identity qatı əlavə edir. ID token "bu istifadəçi kimdir" sualına cavab verir və SSO-nun əsasını təşkil edir. Ən çox rast gəlinən səhv access token-i identity sübutu kimi qəbul etməkdir. Access token API üçündür. İstifadəçinin kim olduğunu ID token deyir, onu da yalnız validate etdikdən sonra.

Bu gün tövsiyə olunan flow-lar:

Authorization code + PKCE: browser, mobile və server application-ları üçün. PKCE ələ keçirilmiş authorization code-un istifadəsinin qarşısını alır.
Client credentials: istifadəçi olmayan service-to-service çağırışlar üçün.
Device flow: klaviaturası olmayan cihazlar üçün.

Implicit flow və resource owner password flow-u deprecated sayılır. Birincisi token-i URL-də ötürür, ikincisi isə OAuth-un həll etmək istədiyi problemi, yəni password-un application-a verilməsini, geri qaytarır.

Implementation-da ən çox səhv olan yerlər:

Redirect URI dəqiq string uyğunluğu ilə yoxlanmalıdır. Wildcard və ya prefix uyğunluğu code-un attacker-in domain-inə göndərilməsinə səbəb olur.
state parametri CSRF-ə qarşı müdafiədir, nonce isə ID token-in replay-inin qarşısını alır. Hər ikisini yoxlayın.
Scope-lar minimal olmalıdır. "Hər şeyə access" istəyən application istifadəçilərə öz icazələrini qiymətləndirməyi öyrətmir.
Token-ləri browser-də saxlamaqdan qaçın. Mümkünsə token-ləri server tərəfində saxlayan və browser-ə yalnız HttpOnly session cookie verən backend-for-frontend pattern-indən istifadə edin.

OAuth-u özünüz implement etməyin. Yetkin identity provider və sertifikatlaşdırılmış client library seçin. Sizin işiniz onları düzgün konfiqurasiya etmək və token-ləri düzgün validate etməkdir. Token-lərin API-lərdə necə yoxlandığı Fəsil 7-də davam etdirilir.

Authorization

Model-lər

Role-based (RBAC): istifadəçilərin role-ları var; role-ların permission-ları var. Sadə, audit edilə bilən, kobud. Sistemlərin əksəriyyəti buradan başlamalıdır.
Attribute-based (ABAC): qərarlar istifadəçinin, resource-un və kontekstin (vaxt, məkan, device) attribute-larına əsaslanır. Çevik, lakin mühakimə etmək çətindir.
Relationship-based (ReBAC): permission-lar graph-dakı əlaqələri izləyir: "sənədin owner-i", "qovluğa sahib olan komandanın üzvü". Google Zanzibar-ın və müasir sənəd paylaşma sistemlərinin əksəriyyətinin arxasındakı model.

Təkrarlanmağa davam edən bug

Broken object-level authorization: API istifadəçinin login olduğunu yoxlayır, lakin istifadəçinin məhz bu obyektə access hüququnun olub-olmadığını yox. URL-dəki ID-ni dəyişin; başqasının data-sını görün. Bu, illərdir OWASP API siyahısının başında və ya ona yaxın yerdədir.

Həll strukturdadır: hər data access-i hərəkət edən istifadəçini və target-i qəbul edən funksiyadan keçir, və check-i unutmaq mümkün deyil, çünki onu atlayan yol yoxdur. Authorization-u mərkəzləşdirin; if user.is_admin ifadələrini codebase-ə səpələməyin.

ID-ləri təxmin olunmaz etmək, məsələn ardıcıl rəqəmlər əvəzinə UUID istifadə etmək, enumeration-u çətinləşdirir, amma authorization deyil. ID log-larda, URL-lərdə və paylaşılan link-lərdə leak olur. Check yenə də hər request-də aparılmalıdır. API-lərdə authorization-un üç səviyyəsi (object, property, function) Fəsil 7-də ətraflı izah olunur.

Prinsiplər

Default deny. Heç bir qayda uyğun gəlmirsə, access yoxdur.
Hər layer-də yoxlayın. UI düyməni gizlədir; API yenə yoxlayır; database mümkün olan yerdə row-level policy tətbiq edir.
Separation of duties. Request edən şəxs approve edən olmamalıdır. Deploy edən şəxs audit log-larını dəyişə bilən olmamalıdır.
Vaxtla məhdud elevated access. Admin hüquqları konkret tapşırıq üçün, saatlarla, approval ilə verilir, daimi deyil.

Machine identity-lər

Service-lərin, job-ların və agent-lərin də identity-yə ehtiyacı var, və əksər mühitlərdə onlar insanlardan çoxdur.

Kodda və ya config-də shared, uzunömürlü secret-lər olmamalıdır. Secrets manager istifadə edin və runtime-da inject edin.
Workload identity-yə üstünlük verin: platform (cloud provider, orchestrator) workload-a zəmanət verir və qısaömürlü credential-lar avtomatik issue olunur.
Service credential-larının scope-unu ehtiyac duyduqları konkret resource-larla məhdudlaşdırın. Reporting job-unun orders cədvəlinə write access-ə ehtiyacı yoxdur.
Avtomatik rotate edin. Heç vaxt rotate edilməmiş secret rotate edilə bilməyən secret-dir, və bunu incident zamanı kəşf edəcəksiniz.

Zero trust

Köhnə model şəbəkə perimeter-i daxilindəki hər şeyə etibar edirdi. O model ölüb: remote iş, cloud service-lər və attacker-lərin lateral movement-i "içəri" anlayışını mənasız etdi.

Zero trust şəbəkə yerini fasiləsiz verification ilə əvəz edir: hər request, haradan gəlməsindən asılı olmayaraq, identity, device health və kontekst əsasında authenticate və authorize olunur. Praktikada:

İstifadəçilər və workload-lar üçün güclü identity.
Access-dən əvvəl device posture check-ləri (patch olunmuş, encrypt olunmuş, managed).
Flat şəbəkəyə VPN əvəzinə per-application access.
Micro-segmentation, bir compromise olunmuş service-in hər şeyə çata bilməməsi üçün.
Hər access qərarının log-lanması.

Bu, product deyil, istiqamətdir. Ən yüksək dəyərli application-lardan və ən privileged istifadəçilərdən başlayın.

Accounting

Hər authentication hadisəsini, hər authorization uğursuzluğunu və hər privileged hərəkəti bu məlumatlarla log edin: kim, nə, nə vaxt, haradan və nəticə. Log-ları actor-un dəyişdirə bilmədiyi yerə göndərin. Fəsil 5 tamamilə bu data-nın mövcudluğundan asılıdır.

Tapşırıqlar

İnsanın sisteminizdə authenticate oluna biləcəyi bütün yolları sadalayın. Hansılar phishing-resistant-dır?
Object-level authorization-u yoxlayan funksiyanı tapın. Data-ya onu bypass edən kod yolu varmı?
Machine credential-larının inventarını aparın. Ən köhnəsi hansıdır? Sonuncu dəfə nə vaxt rotate edilib?
Token qəbul edən bir service seçin. Yuxarıdakı cədvəldəki beş yoxlamanın hər birini aparırmı? aud check-i olmadan başqa service üçün verilmiş token burada işləyərdimi?