Главный риск разрозненных админок — вовсе не утечка паролей

Обычно консультанты по безопасности пугают владельцев бизнеса классической страшилкой: у вас уволится менеджер, унесет пароль на стикере и продаст базу конкурентам. Или еще банальнее — сотрудники тратят по 15 минут в день просто на то, чтобы вспомнить, в какой из шести панелей какой логин подходит. Это раздражает, но бизнес от этого не рушится.

Настоящий катастрофический риск разрозненных внутренних сервисов гораздо тише. Это фантомные доступы и полная невозможность понять, кто именно совершил критическое действие, когда всё полетит к чертям.

История про 11 400 клиентов и логин admin_2

В ноябре 2021 года я разбирал инцидент в логистической компании средней руки. Ребята росли быстро. За четыре года разработки у них сформировался типичный зоопарк: основная CRM, изолированная панель управления складом на Django, самописный скрипт для сверки платежей и Metabase для аналитики. У каждого сервиса — своя база пользователей и своя форма входа.

Увольняют руководителя отдела продаж. Увольняют шумно, со скандалом. Корпоративную почту на Google Workspace заблокировали через две минуты после разговора. Доступы к CRM закрыли в тот же вечер. Руководство поставило галочку: мы в безопасности.

Через три месяца база из 11 400 VIP-клиентов с историями отгрузок всплывает у прямого конкурента. Начинаем аудит. Выясняется: в старой Django-панели управления логистикой, висевшей на заброшенном поддомене, про экс-РОПа просто забыли. Его учетку никто не деактивировал, потому что у системного администратора банально не было единого реестра, где вообще у компании есть учетные записи.

Но самое циничное не это. Когда мы подняли логи сервера, оказалось, что под логином admin_2 за эти три месяца заходили 14 разных IP-адресов. В отделе так привыкли: кому нужно посмотреть статус груза — берут общий логин. В итоге компания не просто потеряла клиентуру — она даже не могла предъявить юридические претензии конкретному человеку. Доказать вину в суде при расшаренных аккаунтах невозможно.

Как плодится хаос: «Сделай быстро скрипт на коленке»

Как бизнес приходит к такой жизни? Очень просто и естественно. Разработчику дают задачу: «Нам нужен инструмент, чтобы операторы могли вручную подтверждать чеки». Разработчик за три дня пилит интерфейс. Чтобы не тратить месяц на проектирование сложной архитектуры, он прикручивает простую HTTP Basic-авторизацию или отдельную табличку users в локальной базе данных.

Затем появляется второй скрипт. Третий. Десятый.

Через год грамотная авторизация для бизнес-инструментов превращается в ад. Качественное объединение внутренних панелей требует переписывать код каждого сервиса с нуля: внедрять поддержку OAuth2, SAML или JWT. А на это у бизнеса никогда нет ресурса. Приоритет всегда у продуктовых фич, которые приносят деньги прямо сейчас, а не у техдолга в админках.

В итоге формируется токсичная привычка: один общий логин на отдел, учетки в текстовых файлах на рабочем столе и десятки «живых трупов» в базах данных от сотрудников, уволившихся еще два года назад.

Почему изолированные авторизации ломают аудит

Проблема не в том, что людям лень вводить пароли. Проблема в размытии ответственности. Когда у вас разрозненные системы:

Вы не управляете жизненным циклом сотрудника. Нанимаете человека — сисадмин тратит два часа, создавая 8 учеток в разных кабинетах. Человек уходит — закрывают три главных, а про остальные забывают. Эти учетки висят годами.

Полностью отсутствует сквозной аудит. Если менеджер изменил скидку в CRM, а потом через отдельный скрипт списал товар со склада, вы не можете сопоставить эти два действия в единую цепочку событий. Для системы безопасности это два разных анонима.

Возникает естественное сопротивление команды. Чем больше у сотрудника паролей, тем выше вероятность, что он начнет использовать один и тот же простой пароль везде или делиться своим входом с коллегой, которому срочно нужно посмотреть отчет.

Как решать проблему, не переписывая весь код

Главная ошибка, которую я наблюдал у IT-директоров — попытка заставить программистов переписать все внутренние сервисы под единый провайдер авторизации. Это проект на полгода с нулевым видимым результатом для бизнеса. Он почти всегда тонет в рутине.

Работающий инженерный подход — не трогать сам legacy-код, а вынести аутентификацию на уровень выше. Поставить авторизующий шлюз (Reverse Proxy) перед всеми внутренними ресурсами компании.

В такой схеме шлюз перехватывает запрос к любому внутреннему поддомену или скрипту, проверяет единую сессию сотрудника и только потом пропускает трафик дальше. Сервис вообще перестает запрашивать логин и пароль — он верит шлюзу. В итоге sso для внутренних систем внедряется без переписывания бэкенда этих самых систем.

Сотрудник логинится один раз утром в корпоративном портале. Сисадмин при увольнении нажатием одной кнопки блокирует доступ сразу ко всему зоопарку. А служба безопасности получает единый журнал действий.

Наш практический опыт

Мы в GuardLabs съели не один пуд соли на настройке таких контуров. Если вы устали от хаоса в доступах, постоянного восстановления забытых паролей и страха перед тем, что уволенный сотрудник выгрузит базу через forgotten-скрипт — не надо переписывать софт годами. Можно внедрить централизованную прослойку авторизации поверх существующей инфраструктуры за считанные дни.

Посмотрите, как мы настраиваем единый вход (SSO) для нескольких внутренних скриптов и панелей — напишите нам, покажем на живом примере, как закрыть дыры в безопасности и обеспечить единый вход на несколько сервисов без остановки работы вашей команды.