პაროლის პოლიტიკა და MFA
1) მიზნები და მოქმედების სფერო
მიზანი: შეამციროს თანამშრომლების/პარტნიორების და მოთამაშეთა ანგარიშების კომპრომისების რისკი, უზრუნველყოს შიდა უსაფრთხოების სტანდარტების დაცვა და რეგულატორების მოთხოვნები.
გაშუქება: ყველა კორპორატიული ანგარიში (SSO/IDP), admin პანელები, გადახდის და KYC კონსოლები, მომსახურება/ბოტი ანგარიშები, ასევე მოთამაშეთა მომხმარებლის ანგარიშები.
2) ძირითადი პრინციპები
Phishing-resistant სტანდარტულად: FIDO2/WebAuthn - TOTP - Push - SMS/e-mail OTP (ეს უკანასკნელი მხოლოდ როგორც fallback).
Least Privilege + JIT: პრივილეგიები გაიცემა მინიმალური და დროებითი, MFA აუცილებლად იზრდება.
Passwords as last resort: აქცენტი პასფრაზებზე და პაროლის მენეჯერებზე; „სამახსოვრო“ მოკლე პაროლების აკრძალვა.
უსაფრთხოება Default: MFA ჩართულია ნაგულისხმევი; კრიტიკული ქმედებებისთვის - re-auth.
Observability: ავთენტიფიკაციის/განაცხადების/გამონადენის ყველა მოვლენა - აუდიტორულ ჟურნალებში.
3) პაროლების/პასფრაზების მოთხოვნები
3. 1 თანამშრომლები/ადმირალები
ფორმატი: პასფრაზას 14 სიმბოლო, დაშვებულია ხარვეზები; აკრძალულია 'A1' სირთულის მოთხოვნები!
ხელახალი გამოყენება: ბოლო 10 reuse აკრძალვა, გარე სერვისების კორპორატიული პაროლის აკრძალვა.
როტაცია: მხოლოდ კომპრომისზე/რისკზე; იძულებითი პერიოდული ცვლილება - არ გამოიყენება (სუსტი პაროლების თავიდან ასაცილებლად).
შენახვა: მხოლოდ პაროლების კორპორატიულ მენეჯერში; ადგილობრივი ფაილების/ბრაუზერის მანქანის შენახვის აკრძალვა MDM პროფილების გარეთ.
3. 2 მოთამაშეები
მინიმუმ 10-12 სიმბოლო ან აღდგომის გენერატორი; ძალის ვიზუალური მითითება; პოპულარული პაროლების სიების ბლოკი.
ჩართეთ „პაროლის ჩვენება“ და „მენეჯერის ჩანართი“; არ დააწესოთ არასტანდარტული შეზღუდვები (emoji/სიმბოლოები - შესაძლებელია).
4) ჰაშირება და საიდუმლოებები
ალგორითმი: Argon2id (მეხსიერება - 256 MB, გამეორება - 3, პარალელიზმი - 1); დავუშვათ bcrypt (კოდი 12), როგორც ლეგაზი.
მარილი: უნიკალური 16 + ბაიტი ჩაწერა. წიწაკა (პეპერი): სისტემური საიდუმლო HSM/KMS- ში.
განახლება: Legashi Heshi- ს შესასვლელში, გამჭვირვალეა მიმდინარე პროფილის „გადახრა“.
მომსახურების გასაღებები/API ნიშნები: არა „პაროლები“ - კონტროლი საიდუმლო მენეჯერის მეშვეობით, გრაფიკის როტაცია და ინციდენტების დროს.
5) MFA: ფაქტორები და პრიორიტეტები
დარწმუნდით:- სარეზერვო backup კოდები (10 ცალი, ერთჯერადი), ოფლაინის შენახვა;
- MFA-enforcement: ადმინისტრაციული წვდომისა და გადახდის მოქმედებებისთვის გამონაკლისის გარეშე;
- Number-matching push, აკრძალვა „ერთი დაჭერით შეთანხმდნენ“.
6) სესიების პოლიტიკა და re-auth
ხანგრძლივობა: ვებ 12 საათი (ინტერაქტიული), admin კონსოლი 8 საათი, კრიტიკული პანელები 4:- Idle Timeout: 15-30 წუთი ადმირალებისთვის.
- Re-aut ერთად MFA: API ნიშნების გადახდა/შეცვლა/შეცვლა/შეცვლა.
- მოწყობილობები: MDM/რეგისტრირებული მოწყობილობა თანამშრომლებისთვის; მოთამაშეებისთვის - სანდო მოწყობილობების დამახსოვრება რისკის შეფასებით.
7) ავთენტიფიკაციისთვის თავდასხმებისგან დაცვა
Credential stuffing: IP/Device/user-based rate-limits, დამცავი შეფერხებები, ქცევითი ანალიზი, გაჟღენთილი პაროლების შემოწმება.
Brute force: პროგრესული შეფერხებები/ქუდი N წარუმატებლობის შემდეგ; რბილი დაბლოკვა (დროებითი), მოთამაშეებისთვის გრძელი ჩაკეტვის გარეშე.
Password spraying: ანომალიების გამოვლენა (მრავალი ანგარიში ერთი პაროლით).
MFA-fatigue: push შეკითხვის ლიმიტი, number-match, მომხმარებლის შეტყობინებები.
Bot/anti automation: WebAuthn სასურველია, ქცევითი სიგნალები, TLS ფიქსაცია, mTLS admin პანელებისთვის.
8) პროცედურები (SOP)
8. 1 თანამშრომლის ონბორდი
1. SSO ანგარიში SCIM- ის საშუალებით;
2. FIDO2 გასაღების გაცემა (მინიმუმ 2: ძირითადი + სარეზერვო) და TOTP;
3. პაროლის მენეჯერის დაყენება;
4. სწავლის დადასტურება (ფიშინგი, MFA).
8. 2 მოწყობილობის დაკარგვა/MFA გადატანა
1. თვითგამორკვევა პორტალზე - სესიების დროებითი დაბლოკვა;
2. დოკუმენტების გადამოწმება + დადასტურება ხელმძღვანელის მეშვეობით;
3. ახალი ფაქტორების გამოშვება;
4. შესასვლელი ჟურნალის აუდიტი 30 დღეში.
8. 3 Break glass (სასწრაფო დახმარების დაშვება)
მხოლოდ აღდგენისთვის; ფაქტორი: HSM შენახული სამაგისტრო ნიშანი + მეორე პრეტენზია; დრო 30 წუთი; სესიის სრული ჩანაწერი; მარხვის უსაფრთხოება + DPO.
8. 4 მოთამაშის პაროლის გამოტოვება
არხი: ელ.ფოსტა/ტელეფონი, ერთჯერადი ბმული 15 წუთი; გამონადენის შემდეგ - სავალდებულო MFA კონფიგურაცია შემდეგ შესასვლელში (რბილი იძულება ბონუსით/მოტივაციით).
9) წესები სხვადასხვა კატეგორიის ბუღალტრული აღრიცხვისთვის
9. 1 თანამშრომლები/მოვაჭრეები
სავალდებულოა WebAthn + TOTP; აკრძალვა SMS-MFA.
დანამატებზე წვდომა მხოლოდ MDM მოწყობილობებით/კორპუსი-VPN; JIT პრივილეგიების გაზრდით.
ადგილობრივი „ზოგადი“ ანგარიშების აკრძალვა; მხოლოდ დასახელებულია.
9. 2 მოთამაშეები
MFA რბილად სავალდებულოა: სამოტივაციო ბანერები, ჩართვის პრემია; მკაცრად - მაღალი რისკის ქვეშ (გადახდები/პროსვიზიტების შეცვლა).
ხელმისაწვდომობის მხარდაჭერა: ძირითადი ფრაზები/ეკრანის მკითხველები, fallback არხები.
9. 3 მომსახურების ანგარიშები/API
პაროლის გარეშე; მხოლოდ ურთიერთგაგება (mTLS, OIDC client creds, ვებჰუკების ხელმოწერა).
გასაღებები საიდუმლო მენეჯერში; როტაცია და აუდიტი.
10) ინტეგრაცია IDP/SSO- სთან
ცენტრალური IDP (OIDC/SAML); ჯგუფური მითითება როლებისთვის (RBAC as code).
Adaptive MFA: გაძლიერდეს რისკის სიგნალების ფაქტორები (გეო/ახალი მოწყობილობა/ანომალიები).
SCIM პროვოცირება/დე-პროვოცირება; სამსახურიდან გათავისუფლების შემდეგ 15 წუთი დაეცა.
11) ჟურნალები და აუდიტი
События (аудит-обязательные): `LOGIN_SUCCESS/FAIL`, `MFA_ENROLL/VERIFY/FAIL`, `PASSWORD_RESET_REQUEST/COMPLETE`, `MFA_RESET`, `DEVICE_TRUST_ADD/REMOVE`, `BREAK_GLASS_START/END`, `ADMIN_LOGIN`, `RISK_UPGRADE`, `TOKEN_ISSUE/REVOKE`.
ასლი WORM- ში, ხელმოწერა/მძიმე ჯაჭვები; ბმული 'trace _ id', 'actor _ id', 'purpose'.
12) მეტრიკი და KPI/KRI
MFA adoption (თანამშრომლები): 100% WebAuthn, 100% TOTP, როგორც რეზერვი.
MFA adoption (მოთამაშეები): ევრო 30-50% 6 თვის განმავლობაში (დამოკიდებულია ბაზარზე).
Compromised logins: 0; პერიმეტრზე დაბლოკილი გაჟღენთილი პაროლების მცდელობების წილი 100% -ია.
Avg time to offboard: ≤ 15 мин.
Push fatigue alerts/1000 MAU: ↓ MoM.
Password reset success: 98% ევრო sport- ის გარეშე.
Re-aut coverage: 100% მაღალი დონის ოპერაციებისთვის.
13) პოლიტიკოსის მაგალითები (ფრაგმენტები)
13. 1 გაჟონვისა და გაჟონვის პოლიტიკა (ფსევდო-YAML)
yaml password:
min_length: 14 allow_spaces: true banned_lists:
- top100k_common
- organization_keywords breach_check: enabled # k-anonymity lookup rotation: on_compromise_only
13. 2 MFA Enforcent
yaml mfa:
required_roles:
- admin
- payments
- aml
- kyc required_factors:
- webauthn fallback:
- totp disallowed:
- sms
13. 3 Re-aut მგრძნობიარე ქმედებებისთვის
yaml reauth:
actions:
- change_payout_details
- approve_withdrawal
- change_email
- manage_mfa ttl_minutes: 5
14) სხვა მაკონტროლებლებთან ურთიერთობა
RBAC/ABAC/SoD: MFA სავალდებულოა როლების დანიშვნა/შეცვლა, JIT აწევა და ოპერაციები „APPROVE _“.
ჟურნალები და ლოგოების შენახვა: იხილეთ „აუდიტის ჟურნალები და წვდომის კვალი“, „ლოგოების შენახვის პოლიტიკა“.
ინციდენტები: კომპრომისზე ეჭვმიტანილი - დაუყოვნებელი password + token reset, სესიების მიმოხილვა, წინსვლა (იხ. „მონაცემთა გაჟონვის პროცედურები“).
15) ჩეკის ფურცლები
ავთენტიფიკაციის გამოშვებამდე
- WebAuthn შედის, TOTP, როგორც რეზერვი, გაიცემა backup კოდები.
- გაჟღენთილი პაროლებისა და ლექსიკური სიების შემოწმება.
- საბადოები და საკრედიტო ნაკადის დაცვა.
- Re-auth მგრძნობიარე ოპერაციებისთვის.
- ლოგები/აუდიტი და ალერტები SIEM- ში.
კვარტალი
- MFA მიღების ანალიტიკა; A/B მოტივატორები მოთამაშეებისთვის.
- შურისძიების პოლიტიკოსი Push დაღლილობა.
- მომსახურების გასაღებების როტაცია, წიწაკის შემოწმება/KMS.
- სწავლებები: FIDO2 გასაღების დაკარგვა, TOTP- ის უარყოფა, break glass.
16) გზის განხორციელების რუკა
კვირები 1-2: ავტორიზაციის აუდიტი, WebAuthn და TOTP ჩართვა, breach შემოწმების კონფიგურაცია, პაროლების (პასფრაზების) პოლიტიკის განახლება.
კვირა 3-4: შემოიღეთ re-auth high-risk, number-matching push, SIEM ალერტებისთვის; გადასცეს FIDO2 გასაღებები თანამშრომლებს.
თვე 2: ადაპტირებული MFA (რისკის სიგნალები), პაროლების სრული ფუნქციონალური მენეჯერი, გადინების სერვისის პორტალი, ყუთის კოდები.
თვე 3 +: A/B მოთამაშეთა MFA- ს პოპულარიზაცია, პერიოდული ვარჯიშები, UX ოპტიმიზაცია და MFA-fatigue- ის შემცირება, KPI ანგარიშგების ავტომატიზაცია.
TL; DR
ძლიერი ავთენტიფიკაცია = პასფრაზები + WebAuthn (აუცილებლად) + TOTP (რეზერვი) + re-auth სარისკო მოქმედებებისთვის, stuffing/brute- ისგან დაცვა, საიმედო ჰაშირება (Argon2id), პაროლის მენეჯერი და თითოეული ნაბიჯის აუდიტი. ეს ამცირებს ანგარიშების კომპრომისებს, ამარტივებს მოთხოვნების შესაბამისობას და თითქმის არა UX მესამედს, თუ სწორად გაკეთდება.