Політика безпеки соцмереж: як команді ділитися паролями

Політика безпеки соцмереж для команди зводиться до п'яти правил: люди входять зі своїх облікових записів через вбудовані ролі кожної платформи; ті кілька логінів, які доводиться ділити, лежать у сховищі менеджера паролів (а не в таблиці чи гілці в Slack); кожен акаунт має 2FA, стійку до фішингу; за кожен акаунт відповідає одна названа людина; доступ забирають того ж дня, коли людина йде. Унікальні випадкові паролі — частина цього, але більшість захоплень акаунтів брендів стається через повторне використання паролів, фішинг і доступ, який ніхто не відкликав, а не через те, що хтось вгадав пароль.

Де насправді витікають акаунти брендів

Типова картина в команді, що росте: таблиця або закріплене повідомлення з логінами. Це працює, доки не станеться одне з трьох: пароль, що використовується ще десь, потрапляє у витік; хтось вводить логін у фішингову форму «вашу сторінку буде заблоковано»; фрилансер, який пішов кілька місяців тому, досі має відкриту таблицю. Агенції множать кожен із цих ризиків на кількість клієнтів.

  SPREADSHEET / CHAT MODEL                 VAULT + ROLES MODEL
  ┌──────────────────────────┐            ┌────────────────────────────┐
  │ "BrandX IG: Summer2025!"  │            │ native roles: own login,   │
  │  pasted in Slack + Sheet  │            │ own 2FA, removed in 1 step │
  │  → copied, screenshotted  │            │ vault (shared logins only):│
  │  → no record of who saw it│            │  ├─ random password        │
  │  → never changed          │            │  ├─ TOTP secret            │
  └──────────────────────────┘            │  └─ access per person      │
                                           └────────────────────────────┘

Ліворуч — модель із таблицею і чатом: пароль скопійовано, заскриншотено, ніхто не знає, хто його бачив, і його ніколи не змінюють. Праворуч — вбудовані ролі з власним логіном і 2FA, які прибираються одним кроком, і сховище лише для спільних логінів: випадковий пароль, секрет TOTP і доступ для кожної людини окремо.

У таблиці немає способу забрати доступ назад. Щойно пароль вставили в історію чату, єдиний вихід — змінити його всюди, і ніхто не знає, хто його скопіював. Друга модель дає одне місце, щоб видати доступ, одне місце, щоб його забрати, і короткий список паролів, які доведеться змінити.

Правило 1: спершу вбудовані ролі, спільні логіни в останню чергу

Більшість великих платформ дозволяють бізнесу додавати людей з їхніми власними обліковими записами й обмеженими правами. Коли людина йде, ви просто прибираєте її, і більше нічого не змінюється: не треба міняти пароль, не треба заново налаштовувати 2FA.

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

Спільний логін лишайте тільки там, де платформа не пропонує нічого кращого, і вважайте кожен такий логін винятком із названим відповідальним.

Правило 2: спільні логіни живуть у сховищі

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

Кожен пароль треба згенерувати, а не придумати. Пароль від акаунта бренду — окрема ціль для credential stuffing (підстановки викрадених облікових даних), тож головна вимога — унікальність і випадковість; додаткова довжина понад це — дешева страховка. Шістнадцять випадкових символів із 95 друкованих символів ASCII дають близько 105 біт. Навіть якби платформа злила його як MD5 без солі, одній RTX 4090 зі швидкістю близько 164 мільярдів спроб на секунду (hashcat 6.2.6) знадобилося б приблизно 8,5 × 10¹² років, щоб перебрати всі комбінації. Генератор паролів створює такий пароль одним кліком просто в браузері, нічого не надсилаючи на сервер, і його можна одразу вставити в запис сховища. Чому саме 16, пояснює стаття як створити надійний пароль.

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

Правило 3: 2FA, яка працює для команди

Кожна команда рано чи пізно питає, як п'ятьом людям ділити один другий фактор. Відповідь залежить від методу.

SMS підходить найгірше. Він прив'язує акаунт до номера однієї людини, перестає працювати, коли ця людина у відпустці чи звільнилася, і вразливий до SIM-swap (перевипуску SIM-картки шахраями). На X це вже навіть не варіант для безплатних акаунтів: з 20 березня 2023 року 2FA через SMS доступна лише платним підписникам, а безплатні акаунти використовують застосунок-автентифікатор або ключ безпеки.

TOTP (коди із застосунку-автентифікатора, RFC 6238) — практичний вибір за замовчуванням для спільного логіна. QR-код під час налаштування — це просто секретний ключ. Збережіть цей секрет у записі сховища поруч із паролем, і кожен, хто має доступ до запису, зможе отримати поточний код. Водночас секрет стає таким самим чутливим, як і пароль, тож поводьтеся з ним так само.

Ключі доступу (passkeys) і апаратні ключі безпеки — те, що мають використовувати власники й адміністратори. Вони стійкі до фішингу, бо браузер дозволяє автентифікатору підписувати запит лише для справжнього домену:

  TOTP CODE (phishable)                    PASSKEY (phishing-resistant)
  ┌────────────────────────────┐          ┌────────────────────────────────┐
  │ 1. User opens a fake page   │          │ 1. User opens a fake page       │
  │ 2. Types the 6-digit code   │          │ 2. Browser asks the authenticator│
  │ 3. Attacker replays it on   │          │    to sign for THIS domain      │
  │    the real site in ~30 s   │          │ 3. Domain ≠ registered origin   │
  │ 4. Attacker is logged in    │          │    → nothing to replay          │
  └────────────────────────────┘          └────────────────────────────────┘

Ліворуч код TOTP: людина вводить його на фальшивій сторінці, атакувальник за ~30 секунд повторює його на справжньому сайті і входить. Праворуч passkey: браузер просить автентифікатор підписати запит для поточного домену, домен не збігається з зареєстрованим, і повторювати нічого.

Код TOTP працює всюди, де його ввели, зокрема на підробленій сторінці входу, яка передає його далі в реальному часі. Саме акаунти власників і адміністраторів цікавлять фішингові набори, бо з них можна додавати інших адміністраторів і змінювати оплату. Перш ніж записувати passkeys у політику, попросіть кожного перевірити свій браузер і пристрій у Перевірці Passkey. Ширше порівняння методів є в статті 2FA чи MFA.

Правило 4: офбординг у той самий день

День, коли людина йде, хай то працівник, фрилансер чи агенція, яку ви замінили, і є перевіркою політики.

  OFFBOARDING (same day)
  ┌───────────────────────────────────────────────────────────┐
  │ 1. Remove vault access                  → one step         │
  │ 2. Remove native role on each platform  → per account      │
  │ 3. Change every shared password they saw → from the vault  │
  │ 4. Re-enroll TOTP on those accounts     → old secret known │
  │ 5. Sign out sessions, revoke app access → per platform     │
  └───────────────────────────────────────────────────────────┘

Чек-лист на день звільнення: (1) прибрати доступ до сховища; (2) прибрати вбудовану роль на кожній платформі; (3) змінити кожен спільний пароль, який людина бачила; (4) заново налаштувати TOTP на цих акаунтах, бо старий секрет відомий; (5) завершити сесії й відкликати доступ застосунків.

Кроки 1 і 2 займають кілька хвилин. Кроки 3 і 4 дорогі, і їхня вартість зростає з кількістю спільних логінів, що й є найсильнішим аргументом на користь правила 1. Зміна паролів тут не суперечить чинним рекомендаціям проти планової ротації: NIST SP 800-63B Rev. 4 каже, що сервіси не повинні вимагати періодичної зміни пароля, але мають вимагати зміну, коли є ознаки компрометації автентифікатора. Те, що пароль знає людина, яка з вами вже не працює, і є такою ознакою.

Запишіть політику безпеки соцмереж

Політика, яка існує лише в чиїйсь голові, не переживе першого напруженого тижня. Досить однієї сторінки, якщо вона відповідає на такі питання:

1. Які акаунти існують, хто відповідає за кожен і де працюють вбудовані ролі, а де спільний логін?
2. Де зберігаються спільні паролі й секрети TOTP і хто їх бачить.
3. Який метод 2FA обов'язковий для кожної ролі (passkey або ключ безпеки для власників і адміністраторів, щонайменше TOTP для всіх інших, без SMS).
4. Що відбувається в останній день людини і хто це робить.
5. Коли переглядають список доступів. Для більшості команд розумний ритм — раз на квартал.

Якщо той самий документ має покривати ще й правила довжини і зберігання паролів для решти компанії, Конструктор політики паролів перетворює правила довжини і складу символів на текст звичайною мовою (а також на JSON-схему і регулярний вираз для перевірки, якщо хтось робить внутрішні інструменти).

FAQ

Що таке політика безпеки соцмереж?

Правила, за якими команда отримує доступ до акаунтів бренду і втрачає його. Корисна версія коротка: вбудовані ролі замість спільних логінів, сховище для решти, 2FA, стійка до фішингу, один відповідальний за кожен акаунт і офбординг того ж дня. Довгий документ, який ніхто не читає, нічого не захищає.

Як команді безпечно ділитися паролями від соцмереж?

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

Як налаштувати 2FA, коли акаунтом керують кілька людей?

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

Що робити, коли людина з доступом до акаунтів іде з команди?

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

Якої довжини має бути пароль до акаунта бренду?

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