Парольна політика має ускладнювати отримання несанкціонованого доступу до облікових записів, не ускладнюючи при цьому безпечну поведінку користувачів. Найкращі політики є зрозумілими, практичними та відповідають тому, як люди насправді працюють. Вони заохочують використовувати довгі унікальні паролі, підтримують менеджери паролів, вимагають багатофакторну автентифікацію там, де це потрібно, і усувають застарілі правила, які підштовхують користувачів до передбачуваної поведінки.
У цій статті пояснюються рекомендації та антирекомендації сучасної парольної політики, що слід уникати, які кращі практики впроваджувати, а також ви знайдете шаблон для копіювання та адаптації у своїй організації.
Що таке парольна політика?
Парольна політика — це набір правил, які визначають, як створюються, зберігаються, використовуються, передаються, змінюються і захищаються паролі. Вона поширюється на співробітників, підрядників, адміністраторів, службові облікові записи та інколи клієнтів, залежно від охоплення систем.
Хороша парольна політика повинна відповідати на практичні запитання:
- Якою має бути мінімальна довжина пароля?
- Чи дозволені парольні фрази?
- Чи можуть користувачі вставляти паролі з менеджерів паролів?
- Коли пароль необхідно змінити?
- Чи обов’язкова багатофакторна автентифікація?
- Як поводитися зі спільними обліковими даними?
- Що робити, якщо є підозра на компрометацію пароля?
Мета — не створити найскладніший набір правил, а реально знизити ризики.
Рекомендації для сучасної парольної політики
Вимагайте достатньої довжини паролів
Довжина — одна з найефективніших захисних заходів проти атак перебором і вгадуванням. Єдиний мінімум для всієї організації зазвичай простіше для розуміння і впровадження, ніж різні вимоги для стандартних користувачів, адміністраторів чи особливих випадків. Практична вимога: мінімум 16 символів для всіх акаунтів користувачів. Довші паролі краще, коли використовуються менеджери паролів чи випадково створені парольні фрази.
Дозволяйте довгі паролі та парольні фрази
Користувачі повинні мати змогу створювати паролі, що значно довші за мінімум. Уникайте малих максимальних обмежень, наприклад, 16 чи 20 символів. Максимальна довжина в 64 символи — адекватний початковий рівень, а багато систем можуть підтримувати ще більше.
Парольні фрази дозволені, якщо вони довгі та не базуються на відомих цитатах, назвах компаній, піснях або передбачуваних фразах. Наприклад, фраза, складена з кількох випадкових слів, зазвичай краще за короткий пароль із примусовими замінами символів.
Вимагайте унікальності паролів
Кожний обліковий запис повинен мати унікальний пароль. Повторне використання паролів — одна з основних причин, через які злом одного сервісу призводить до захоплення акаунтів на інших. Менеджер паролів робить використання унікальних паролів реалістичним, оскільки користувачам не потрібно всі їх запам’ятовувати.
Підтримуйте менеджери паролів
Політика повинна явно дозволяти та заохочувати використання затверджених менеджерів паролів. Користувачі повинні мати можливість вставляти паролі у форму входу, використовувати автопідстановку і генерувати випадкові паролі. Заборона вставки може здаватися захисною, але часто заважає використанню довгих і сильних паролів через менеджер.
Перевіряйте паролі на наявність у скомпрометованих списках
Паролі мають відхилятись, якщо вони зустрічаються у відомих списках зламів, поширених паролів, або у внутрішніх списках блокування організації. Це ефективніше, ніж вимога мати одну велику букву, одну цифру й один символ.
Вимагайте MFA, де це технічно можливо
Багатофакторну автентифікацію слід вмикати всюди, де це можливо, особливо для адміністраторів, віддаленого доступу, хмарних сервісів, електронної пошти, менеджерів паролів, фінансових систем та інших критичних ресурсів. MFA не заміняє сильні паролі, але зменшує ризик при їх компрометації.
Віддавайте перевагу стійким до фішингу типам MFA, наприклад, passkeys, апаратним ключам безпеки чи автентифікаторам платформи. Додатки-автентифікатори зазвичай кращі за SMS. MFA на основі SMS не повинна використовуватись, якщо можливий будь-який інший спосіб, оскільки номери телефонів можуть бути перехоплені, замінені SIM-картки, здійснено перенесення номера чи зловживання відновленням акаунта.
Це не теорія. У 2018 році Reddit повідомив, що зловмисники перехопили SMS-коди двоетапної автентифікації та отримали доступ до внутрішніх систем: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. У 2021 році Coinbase повідомив про крадіжку криптовалюти у щонайменше 6 000 клієнтів після злому облікових даних і вразливості процесу відновлення через SMS: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
Змінюйте паролі після компрометації
Паролі повинні змінюватися, коли є докази чи обґрунтована підозра на їхній витік. Це — підозріла активність, фішингові атаки, наявність шкідливого ПЗ, витік у результаті зламу, випадкове розголошення.
Належно захищайте спільні акаунти
Спільних паролів слід уникати, якщо можливо створити персональні акаунти. Якщо спільного доступу не уникнути, паролі мають зберігатися в затвердженому менеджері, доступ мати лише уповноважені особи, а дії — фіксуватися за можливості.
Захищайте процеси скидання пароля
Процедури відновлення паролів часто є найслабшою ланкою безпеки. Процеси мають перевіряти особу користувача, посилання для скидання мають швидко втрачати чинність, для цього слід використовувати одноразові токени, а користувачів інформувати про зміну пароля.
Антирекомендації для сучасної парольної політики
Не змушуйте часто змінювати паролі без причини
Обов’язкове оновлення паролів кожні 30, 60 чи 90 днів часто призводить до створення слабших паролів — користувачі роблять передбачувані зміни (додають цифру, змінюють пору року тощо). Нові настанови NIST не рекомендують регулярну зміну паролів, а лише у випадках компрометації. Див. розділ 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Вимагайте зміни тільки при підозрі зламу, зміні ролі, відновленні або якщо пароль більше не відповідає політиці.
Не покладайтеся лише на правила складності
Правила на кшталт "має містити велику і малу букву, цифру та символ" не є гарантією стійкості. Password1! задовольняє багато вимог, але є слабким паролем. Пріоритет — довжина, унікальність, випадковість і відсутність у зламаних списках.
Не блокуйте копіювання та вставку
Заборона вставлення унеможливлює комфортне використання менеджерів паролів. Це штовхає користувачів до коротких паролів, які легше набрати вручну. Дозволяйте вставку та автозаповнення, якщо немає узгоджених причин це заборонити.
Не використовуйте підказки до паролів
Підказки часто розкривають надто багато інформації. Якщо користувач може пригадати пароль завдяки підказці, то й зловмисник може це вгадати. Краще використовуйте безпечні процеси відновлення.
Не зберігайте паролі у відкритому вигляді
Паролі не повинні зберігатися у відкритому вигляді чи оборотно зашифрованими. Використовуйте сучасні "повільні" алгоритми гешування з сіллю, такі як Argon2id, bcrypt, scrypt або PBKDF2, залежно від технічних і нормативних вимог.
Швидкі універсальні алгоритми: MD5, SHA-1, SHA-256, SHA-512 — не підходять для гешування паролів, бо вони спеціально розроблені для швидкої обробки, що полегшує перебір паролів після витоку бази. Детальніше — у нашій статті про еволюцію гешування паролів.
Не передавайте паролі через чат чи пошту
Не надсилайте паролі електронною поштою, в чаті, через тікети, документи або скріншоти. Використовуйте менеджер паролів із функціями безпечного обміну та контролю доступу.
Не використовуйте персональні дані чи передбачувані шаблони
Паролі не повинні містити імен, дат народження, назви компаній, патерни на клавіатурі, повторювані символи чи поширені заміни (@ замість a, 0 замість o тощо). Атакуючі тестують такі комбінації насамперед.
Кращі практики для організацій
Встановіть чіткі мінімальні вимоги
Вимоги мають бути простими:
- Мінімум символів (наприклад, 16 для всіх акаунтів користувачів)
- Дозвіл принаймні на 64 символи
- Дозволяйте пробіли та загальні символи
- Дозволяйте фрази та менеджери паролів
- Відхиляйте скомпрометовані та поширені паролі
Відрізняйте контроль за привілейованими акаунтами
Адміністраторські, службові та виробничі акаунти — окремий випадок. Вони мають мати сильніші паролі, MFA, обмежений доступ, моніторинг і негайну ротацію після зміни доступу.
Використовуйте рольовий доступ і принцип найменших привілеїв
Сильний пароль не компенсує зайві дозволи. Користувачі мають мати доступ лише до того, що їм потрібно в роботі.
Моніторте підозрілу активність
Виявляйте незвичні входи, неможливі пересування, багаторазові невдалі спроби, входи з нових країн, доступ не в робочий час. Парольна політика має підтримуватись моніторингом і реагуванням на інциденти.
Навчайте користувачів реалістичним загрозам
Навчальні програми мають фокусуватися на ризиках повторного використання паролів, фішингу, фейкових сторінок входу, втомі від MFA, безпечному обміну даними та як повідомити про підозру зламу. Не звинувачуйте користувачів — зробіть безпечну поведінку простою.
Тримайте політику короткою й зрозумілою
Парольна політика має бути зрозумілою. Якщо вона надто довга, загальна чи сувора — її будуть обходити. Найкраща політика — це та, яку реально виконувати і контролювати.
Шаблон парольної політики для копіювання
Використовуйте цей шаблон як основу. Налаштуйте секції у квадратних дужках відповідно до вашої організації, систем, рівня ризику та вимог законодавства.
Парольна політика
Версія: [1.0]
Власник: [Відділ безпеки / IT]
Дата набрання чинності: [YYYY-MM-DD]
Оглядовий цикл: [Кожні 12 місяців]
1. Призначення
Ця політика визначає вимоги для створення, використання, зберігання, передачі та зміни паролів у [Назва організації]. Мета — знизити ризик несанкціонованого доступу, крадіжки облікових даних, захоплення акаунта та втрати даних.
2. Область застосування
Політика поширюється на всіх співробітників, підрядників, тимчасовий персонал, постачальників послуг та будь-яких інших користувачів, які мають доступ до систем, застосунків, мереж, хмарних сервісів чи даних [Назва організації].
Політика стосується стандартних облікових записів, привілейованих, службових, спільних акаунтів та будь-яких систем, де пароль використовується для автентифікації.
3. Вимоги до створення паролів
Усі паролі повинні відповідати наступним вимогам:
- Облікові записи користувачів мають мати паролі не коротше 16 символів.
- Паролі повинні бути унікальними й не використовуватись повторно в особистих чи робочих облікових записах.
- Паролі не мають містити імен, імен користувача, назви компанії, дати народження, патерни клавіатури, повторювані символи чи іншу легко відгадувану інформацію.
- Паролі не мають базуватися на загальних фразах, цитатах, назвах пісень чи передбачуваних замінах.
- Паролі не повинні зустрічатись у відомих списках зламів чи поширених паролів.
- Паролі можуть містити пробіли, символи, цифри, великі та малі букви.
- Парольні фрази дозволені, якщо вони довгі, унікальні та не базуються на передбачуваних чи загальнодоступних фразах.
4. Менеджери паролів
[Назва організації] вимагає або наполегливо рекомендує використання затвердженого менеджера паролів для створення, зберігання й передачі паролів.
Користувачі можуть використовувати генератор паролів, автозаповнення, копіювання-вставку із затвердженого менеджера паролів. Забороняється зберігати паролі в браузерах, таблицях, документах, нотатках, email, чатах, скріншотах чи невідомих інструментах.
5. Багатофакторна автентифікація
MFA повинна бути включена всюди, де це технічно можливо, у тому числі:
- Електронна пошта
- Системи віддаленого доступу
- Акаунти менеджера паролів
- Хмарні сервіси
- Адміністративні акаунти
- Фінансові, HR та інші критичні системи
- Системи з класифікацією [конфіденційна / критична]
Якщо можливо, користувачі мають використовувати MFA, стійку до фішингу: passkeys, апаратні ключі, автентифікатори платформи. Додатки-автентифікатори кращі, ніж SMS. MFA через SMS заборонено, якщо технічно можливий будь-який інший варіант, і допускається лише при відсутності кращих опцій.
6. Зміна паролів
Паролі змінюються негайно, якщо:
- Відомо або підозрюється компрометацію пароля.
- Користувач ввів пароль на підозрілий (фішинговий) сайт.
- Пароль було передано сторонній особі.
- Виявлено шкідливе ПЗ чи несанкціонований доступ на пристрої користувача.
- Пароль опинився у відомому зламі даних.
- Змінилась роль або зайнятість акаунта з привілеями.
- IT або Безпека надали вказівку змінити пароль.
Регулярна зміна паролів не потрібна, хіба що вимагається законом, контрактом чи технічними обмеженнями. Не дозволяється змінювати пароль невеликими, передбачуваними модифікаціями.
7. Передача паролів
Паролі не дозволяється передавати через email, чат, тікети, документи, скріншоти, телефон чи усно.
Спільні облікові дані допустимі лише, якщо персональний акаунт технічно неможливий або якщо прямо дозволено [Безпекою / IT]. Затверджені спільні облікові дані зберігаються і передаються лише через менеджер паролів з обмеженим доступом для уповноважених.
8. Привілейовані акаунти
Привілейовані акаунти мають використовувати унікальні паролі, не використані для стандартних акаунтів. Привілейовані акаунти мають використовувати MFA і регулярно переглядатися.
Паролі має бути змінено при звільненні, зміні ролі, втраті необхідності в доступі чи при компрометації.
9. Службові акаунти та секрети застосунків
Паролі службових акаунтів, API-ключі, токени, секрети застосунків мають зберігатися у затвердженій системі керування секретами або у затвердженому менеджері паролів.
Службові облікові дані не повинні бути "зашиті" у вихідний код, конфігураційні файли, образи, документацію чи скрипти без захисту у процесах керування секретами.
10. Скидання пароля та відновлення акаунта
Процеси скидання пароля повинні перевіряти особу користувача до відновлення доступу. Посилання для скидання та тимчасові паролі мають бути одноразовими, швидко втрачати чинність і передаватися тільки через затверджені канали.
Користувача слід повідомляти про скидання чи зміну пароля. Тимчасовий пароль слід змінити при першому вході.
11. Технічний контроль
Системи, що зберігають чи обробляють паролі, повинні:
- Ніколи не зберігати паролі у відкритому вигляді.
- Гешувати паролі тільки відомим сучасним алгоритмом із сіллю: PBKDF2, scrypt, bcrypt або Argon2.
- Не використовувати MD5, SHA-1, SHA-256, SHA-512 тощо як алгоритм гешування самостійно.
- Захищати точки автентифікації rate limiting або рівнозначними засобами.
- Відхиляти поширені, слабкі й скомпрометовані паролі.
- Дозволяти користувачам вставку пароля з менеджера паролів.
- Підтримувати довгі паролі — мінімум 64 символи, якщо можливо.
- Логувати події автентифікації з безпековим значенням.
12. Повідомлення про підозру компрометації
Користувачі повинні негайно повідомляти [контакт Безпеки / IT] про підозру на злам, фішинг, незвичні вікна входу, MFA, які вони не ініціювали, чи випадкове розголошення пароля.
13. Винятки
Винятки з цієї політики мають бути задокументовані, оцінені за ризиками, обмежені в часі та погоджені [керівництвом Безпеки / IT]. Треба використовувати компенсаційні контролі там, де можливо.
14. Виконання
Порушення цієї політики може призвести до позбавлення доступу, обов’язкового проходження навчання з безпеки, дисциплінарних дій та інших заходів згідно політик [Назва організації] та вимог закону.
15. Огляд
Політика переглядається щонайменше раз на рік або після істотних змін у системах, загрозах, законодавстві або діяльності організації.
На завершення
Сильна парольна політика — це не про створення додаткових труднощів. Йдеться про усунення слабких звичок, підтримку менеджерів паролів, використання MFA і швидке реагування на компрометацію облікових даних. Тримайте політику практичною, виконуваною і сфокусованою на реальних загрозах: фішинг, повторне використання паролів, credential stuffing та зламані акаунти.
