Я решил уже не опираться только на свой опыт и полез посмотреть, как подобные вещи реально организуют крупные компании и специалисты по безопасности. И выяснилась интересная вещь.
То, что многие считают “паранойей безопасников”, давно уже стало стандартной практикой у Microsoft, enterprise-интеграторов и крупных security-команд.
Например, у Microsoft есть отдельная концепция emergency access accounts или “break glass accounts” — аварийных доступов. Смысл простой: если у вас сломалась авторизация, умерла MFA, потеряли телефон, упал VPN или кто-то случайно заблокировал администраторов — у компании всё равно должен оставаться резервный способ получить контроль над инфраструктурой. Причём Microsoft прямо рекомендует иметь минимум два таких независимых аккаунта.
Эти аварийные доступы должны храниться отдельно от основной инфраструктуры, не зависеть от той же системы авторизации и использоваться только в экстренных случаях. Более того, после каждого использования пароль рекомендуется сразу менять. Иначе аварийный доступ превращается в обычный бэкдор.
Второй важный момент — just-in-time access. То есть временные доступы. Это уже стандартная практика в крупных системах. Подрядчику или сотруднику не выдают вечный root-доступ “на всякий случай”. Доступ выдаётся под задачу и на ограниченное время, после чего автоматически отзывается. Microsoft и системы класса PIM/PAM давно работают именно так.
Третья вещь — принцип минимально необходимых прав. Человек должен видеть только то, что ему реально нужно для работы. Не весь сервер, не всю инфраструктуру, не полный доступ ко всем резервным копиям компании. И это сейчас одна из базовых рекомендаций практически всех крупных security-framework’ов.
Четвёртое — аудит действий. Любой критичный доступ должен логироваться. Кто вошёл, когда, с какого IP, что менял. Потому что в момент инцидента фраза “мы не знаем кто это сделал” обычно начинает стоить очень дорого.
Пятое — ротация паролей после увольнений и завершения подрядных работ. Причём немедленная. Это вообще одна из самых частых рекомендаций у специалистов по безопасности. Потому что огромное количество проблем потом оказывается не “взломом”, а просто старым забытым доступом бывшего сотрудника.
Шестое — резервные копии должны храниться отдельно от основной инфраструктуры и иметь независимый доступ. Потому что backup рядом с тем же сервером — это не резервирование, а самоуспокоение.
Седьмое — критичные аккаунты не должны быть привязаны к личным почтам сотрудников или подрядчиков. Microsoft отдельно рекомендует создавать независимые cloud-only административные аккаунты, не завязанные на локальную инфраструктуру и конкретных людей.
И вот что забавно.
Когда начинаешь читать рекомендации серьёзных security-команд, внезапно понимаешь: большинство катастроф в бизнесе происходят не из-за “суперхакеров”, а из-за обычного человеческого разгильдяйства.
Пароль не поменяли.
Доступ забыли отозвать.
Backup не проверяли.
Телефон потеряли.
Подрядчику дали слишком много прав.
Никто не знает, где лежит инфраструктура.
Именно поэтому безопасность сегодня — это уже не “айтишная паранойя”. Это обычная управленческая дисциплина.
И отдельно — что делать небольшим компаниям и тем, кто только начинает.
Потому что когда люди читают про PAM, PIM, Zero Trust и enterprise-безопасность, у многих начинается ощущение, что без отдела ИБ и бюджета как у банка вообще нет смысла что-то делать. Это не так.
Для малого бизнеса главная задача — не построить “цифровой Форт-Нокс”, а убрать самые тупые и опасные точки отказа.
Если у вас маленькая компания — начните вообще с банального.
Сделайте отдельную таблицу инфраструктуры. Да, хоть Excel. Но нормальный. Где будет написано - где домен, где сайт, где сервер, кто оплачивает, у кого доступ, как восстанавливается доступ, где лежат резервные копии.
Удивительно, но уже это делает вас организованнее огромного количества компаний.
Дальше — перестаньте регистрировать всё подряд на личные почты сотрудников. Это одна из самых массовых проблем на рынке. Особенно у малого бизнеса.
Потом — поставьте нормальную систему хранения доступов. Не обязательно дорогую и “корпоративную за миллионы”.
Даже для маленькой компании это уже огромный шаг вперёд по сравнению с “пароль где-то в Telegram” или “сейчас Вася пришлёт доступ”.
Если говорить про российские решения и варианты, которые можно спокойно использовать внутри бизнеса, то многие сейчас смотрят в сторону:
— Пассворк;
— self-hosted Vaultwarden на своём сервере;
— коробочных решений внутри Битрикс24 и внутренних корпоративных баз знаний;
— KeePass с нормальной организацией хранения и резервирования.
Причём для небольших компаний тот же Vaultwarden или KeePass зачастую оказываются даже логичнее и надёжнее, чем сложные enterprise-системы, которые потом никто не умеет нормально сопровождать.
Главное тут вообще не “какой бренд выбрать”.
Главное — чтобы: доступы были централизованы, не висели на одном человеке,
имели резервный вариант восстановления, и не передавались через мессенджеры в духе “лови пароль”.
Следующая важная вещь — резервный доступ. У собственника или доверенного человека всегда должен быть способ восстановить контроль над инфраструктурой без конкретного сотрудника или подрядчика.
И самое главное — перестаньте раздавать всем полный доступ “для удобства”. Это, кстати, одна из самых любимых ошибок начинающих компаний.
Маркетологу не нужен root к серверу.
Контент-менеджеру не нужен доступ к резервным копиям.
Подрядчику не нужен пожизненный доступ к CRM.
Чем меньше лишних прав — тем меньше вероятность катастрофы.
И ещё один важный момент, который почему-то почти никто не проговаривает.
Маленькому бизнесу не нужно пытаться сразу копировать инфраструктуру корпораций. Потому что очень часто это заканчивается дорогой, сложной и никому не понятной системой, которую потом никто не поддерживает.
На старте безопасность — это прежде всего: порядок, учёт, резервирование, контроль доступа, и понимание, кто вообще управляет инфраструктурой компании.
Этого уже достаточно, чтобы избежать 90% проблем, которые потом превращаются в “у нас пропал сайт”, “не можем зайти в CRM” или “бывший подрядчик что-то заблокировал”.