Паролі в компанії: сучасні правила і як їх запровадити

Для чого і кому

Паролі в компанії досі часто тримаються на правилі «змінювати щомісяця або щокварталу», хоча для хмарних облікових записів Microsoft 365 у Password policy recommendations радять інше: не вводити строк дії паролів. Нижче: які правила працюють зараз і як запровадити їх так, щоб співробітники не чинили опір.

Причина в людській поведінці. За словами Microsoft, дослідження показують: майже кожне додаткове правило (довжина, спецсимволи, примусова зміна) призводить до «нормалізації» паролів. Люди вигадують передбачувані варіації, наприклад той самий пароль із цифрою в кінці, і такі паролі легше вгадати. Тому мета сучасної політики: щоб у компанії було багато різних паролів, які важко підібрати.

Другий орієнтир: NIST SP 800-63B. Документ написано для урядових систем, тож для бізнесу він не обов'язковий, але дає зрозумілу шкалу. На базовому рівні достатньо одного фактора, на другому потрібні два різні фактори й варіант автентифікації, стійкої до фішингу.

Кого це стосується

Насамперед компаній, які працюють із корпоративною поштою Microsoft 365 і мають хмарні (cloud-only) облікові записи: саме для них Microsoft дає конкретні поради. Для Google Workspace, локального домену, VPN чи 1С принципи ті самі, але потрібні налаштування шукайте в документації кожного продукту. Фізичний доступ до приміщень ці рекомендації не охоплюють.

Що це змінює для бізнесу

Пошта й хмарні сервіси відкриті з будь-якої точки, тому пароль залишається першим бар'єром. Якщо співробітник використав робочий пароль на стороннього сайті, зловмисник отримує шанс дістатися листування, документів і рахунків компанії. Для українського бізнесу з віддаленими працівниками й підрядниками це цілком практична ситуація, але закривається вона спокійно: короткими правилами й другим фактором. Якщо ж інцидент уже стався, дивіться нашу статтю про дії під час атаки програми-вимагача.

Що знадобиться

Права адміністратора в Microsoft 365 (або в системі, де ви керуєте політикою), перелік сервісів із паролями й тестовий обліковий запис без доступу до реальних даних. Також потрібна пам'ятка для співробітників на одну сторінку та пілотна група з 5–10 людей із різних відділів.

На налаштування вистачить кількох годин, на пілот буде потрібно кілька днів. Рішення про правила ухвалює керівник, адміністратор лише втілює їх у налаштуваннях.

Якщо немає адміністратора

Політику паролів можна налаштувати силами зовнішнього спеціаліста, і для цього не потрібно мати людину в штаті. Якщо у вашій компанії немає людини, яка стежить за обліковими записами й політиками доступу, ці налаштування та навчання користувачів можна передати команді TakeIT.

Кроки

Кожен крок містить дію й спосіб перевірити, що вона спрацювала.

1. Складіть перелік систем із паролями: пошта, VPN, віддалені столи, 1С, роутери, спільні облікові записи. Перевірка: навпроти кожної системи записано власника й тип входу (особистий чи спільний).
2. Задайте довжину й строк дії. Microsoft 365 вимагає мінімум 8 символів, але рекомендує 14. Для хмарних облікових записів політика фіксована, змінити можна лише строк дії, і Microsoft радить його не обмежувати. Тому 14 символів закріпіть правилом компанії (зручно пояснити це як довгу фразу з кількох слів), а строк дії вимкніть за інструкцією Microsoft «Set password expiration policy for Microsoft 365». Перевірка: у налаштуваннях паролі позначені як ті, що не спливають, а в пам'ятці вказано 14 символів.
3. Заблокуйте прості паролі на кшталт abcdefg, password, monkey, 123456. Для цього Microsoft згадує Microsoft Entra Password Protection; чи доступна функція у вашому плані, перевірте в документації. Перевірка: на тестовому обліковому записі спробуйте встановити 123456, система має відмовити.
4. Увімкніть обов'язкову реєстрацію другого фактора (MFA) і попросіть оновити контакти для відновлення: резервну пошту, телефон або пристрій для push-сповіщень. Перевірка: у звіті адміністратора всі активні облікові записи мають зареєстрований метод, а для керівників і бухгалтерії ви звіряєте це окремо.
5. Налаштуйте скидання пароля з підтвердженням через застосунок автентифікації та ризик-політики (identity protection risk policies, risk-based MFA): за підозрілого входу система попросить підтвердити особу. Доступність залежить від вашого плану, тож перевірте її в документації Microsoft. Перевірка: проведіть тестове скидання на пілотному обліковому записі й пройдіть підтвердження.
6. Проведіть пілот і розішліть пам'ятку. У ній мають бути прості правила: не використовувати робочий пароль деінде, не брати імена, дати народження, улюблені гурти й поширені фрази на зразок Iloveyou. Перевірка: пілотна група входить без звернень до підтримки, а після розсилки ви бачите, скільки запитів на скидання надійшло.

Пріоритет

Сьогодні: кроки 1 і 4, щонайменше для адміністраторів і пошти керівників. Цього тижня: кроки 2, 3 і 5. При плановому перегляді регламенту безпеки: крок 6 для всіх відділів, закріплення правил у регламенті та включення їх у вступний інструктаж для нових співробітників.

Як запровадити без опору

Опір виникає там, де людям забирають звичне й нічого не дають натомість. Тут навпаки: ви прибираєте регулярну зміну й вимоги до спецсимволів, а просите довший пароль і одноразове налаштування другого фактора. Скажіть про це прямо в пам'ятці, і правило сприйматиметься як полегшення.

Запускайте поетапно: спершу пілот, потім відділи по черзі. Питання й скидання паролів зручно збирати в одному каналі, наприклад у системі підтримки робочих місць і користувачів або в чаті з адміністратором.

Як перевірити результат

Через тиждень після пілоту пройдіться за короткою чергою перевірок. Слабкий пароль на тестовому обліковому записі відхиляється. У звіті про методи автентифікації немає користувачів без другого фактора. Тестове скидання пароля проходить без допомоги адміністратора.

Окремо порівняйте кількість звернень «забув пароль» з попереднім періодом. Якщо вона різко зросла, ймовірно, пам'ятка незрозуміла або хтось не оновив контакти для відновлення. Повторюйте тест слабкого пароля і звірку MFA раз на квартал, а також після кожної зміни ліцензій чи політик.

Типові помилки

Залишити примусову зміну паролів разом із новими вимогами. Люди відповідають на це передбачуваними варіаціями, і різноманітність, заради якої все затівалося, зникає.

Вимагати спецсимволи й складність без акценту на довжині. Microsoft прямо пише, що такі вимоги теж призводять до схожих паролів. Куди ефективніше довга фраза плюс заборона очевидних слів.

Увімкнути MFA, але не перевірити контакти для відновлення. Без актуальної резервної пошти чи пристрою користувач, який втратив доступ, звертається до підтримки, а зловмисникові легше видати себе за нього.

Лишити спільні облікові записи. NIST у SP 800-63B зазначає, що захист розрахований на крадіжку облікових даних, а не на добровільну передачу пароля колегам, і технічно виявити таке майже неможливо. Для спільних сервісів краще створити особисті входи.

Забути про службові облікові записи, роутери й VPN: навіть із ідеальною політикою для пошти вони залишаться слабкою ланкою. Підозрілі входи й спроби підбору допомагає помітити моніторинг і базова кібербезпека.

Висновок

Політика паролів сьогодні вкладається в чотири речі: довга унікальна фраза, відсутність примусової зміни, заборона очевидних варіантів і другий фактор. Почніть із простої перевірки: спробуйте на тестовому обліковому записі встановити 123456. Якщо система погодилася, у вас є з чого починати.