Кто на самом деле администратор сервера: наводим порядок в привилегированных учётках

За пятнадцать лет в IT-аутсорсинге я видел десятки серверов, где на вопрос «кто у вас админ» директор пожимает плечами. А потом мы находим пароль от Administrator, который знают восемь человек, включая уволенного год назад менеджера. Это не редкость — это норма для малого бизнеса. Расскажу, почему так получается и как это разгребать, не сломав работу компании.

Как вообще получается, что админом становится каждый второй

Обычно история такая. Пришёл первый айтишник, настроил сервер, сделал одну учётку Administrator с одним паролем — так проще. Потом он уволился, пароль остался у бухгалтера в файле «пароли.txt» на рабочем столе. Потом пришёл второй специалист, добавил ещё пару локальных админов, чтобы не звонить каждый раз. Потом сисадмина на аутсорсе сменили, а старому забыли отключить доступ.

Через три-четыре года у компании на 20-30 рабочих мест оказывается семь-восемь человек с полными правами на сервер. Причём половина из них там больше не работает. У одного клиента, торговой компании на Волгоградском проспекте, мы при аудите нашли доступ бывшего программиста, который ушёл в 2022 году. Пароль от Administrator за три года ни разу не меняли.

И самое неприятное — никто в компании не может сходу ответить, кто реально может зайти на сервер. Директор уверен, что доступ есть у него и у «айтишника». А по факту список из RDP-логов гораздо длиннее.

Почему общий Administrator — это бомба замедленного действия

Один пароль на всех — это не экономия, это отказ от контроля. Если что-то сломалось, удалилась база 1С или пропали файлы — вы никогда не узнаете, кто это сделал. В логах будет просто «Administrator», без привязки к конкретному человеку. Я сталкивался с ситуацией, когда у клиента случайно снесли расшаренную папку с документами за квартал — виновника искали неделю, потому что действовать мог кто угодно из восьми человек.

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

Третье — общий Administrator обычно живёт годами без смены пароля, потому что смена ломает все скрипты, RDP-ярлыки и автозапуски, которые на него завязаны. А пароль, который не меняли три года и который знают восемь человек, рано или поздно оказывается в переписке, в мессенджере, на бумажке в столе. Ко мне обращалась медклиника, где такой пароль случайно попал в чат с подрядчиком по ремонту — просто потому что с этого же ноутбука когда-то заходили в сервер.

С чего начинается аудит привилегированных учёток

Первый шаг — не «удалить всё лишнее», а сначала посмотреть, что вообще есть. Заходим на сервер, открываем группу «Администраторы» (Local Administrators или Domain Admins, если это контроллер домена) и выгружаем полный список. Отдельно смотрим группу Domain Admins, если у вас Active Directory — там часто прячутся учётки сервисов, о которых все забыли.

Дальше — сверяем список с реальными людьми. Кто это? Работает ли ещё в компании? Зачем ему полные права на сервер именно сейчас? У одной юрфирмы в такой список попала учётка «1cuser», созданная три года назад для настройки 1С одним подрядчиком — она давно никому не была нужна, но висела с правами локального админа и паролем «123456».

Параллельно проверяем RDP-логи — журнал событий Security, коды события 4624 и 4625, успешные и неуспешные входы. Это показывает не список «кто должен иметь доступ», а список «кто реально заходил» за последние месяцы. Разница между этими двумя списками обычно и есть источник проблем.

Как развести общий пароль на именные учётки без паники в офисе

Тут важно не устраивать революцию за один вечер, иначе бухгалтерия перестанет попадать в 1С в понедельник утром и будет звонить каждые пять минут. Делаем поэтапно. Сначала создаём именные учётки для всех, кому реально нужен административный доступ — обычно это один-два человека на компанию до 50 рабочих мест, изредка три.

Каждому — своя учётка, свой пароль, минимальный набор прав именно под его задачи. Программисту 1С не нужны права на управление DNS-сервером и Active Directory, ему нужен доступ к папке с базами и к SQL Server. Бухгалтеру не нужен RDP на сам сервер вообще — ему достаточно опубликованного приложения 1С. Разграничение прав — это не бюрократия, это просто способ ограничить ущерб, если у кого-то украдут пароль или заразят компьютер вирусом-шифровальщиком.

После того как именные учётки заведены и протестированы — вот тут уже можно менять пароль от Administrator, причём на сложный, длинный, который знает от силы один-два человека в самой компании и записан не на стикере, а в защищённом менеджере паролей вроде KeePass с мастер-паролем. У одного клиента мы это делали в пятницу вечером, чтобы за выходные все успели проверить, что ничего не отвалилось — RDP-подключения, автозапуски скриптов бэкапа, синхронизации.

Что делать с сервисными учётками и подрядчиками

Отдельная головная боль — учётки для служб. 1С, SQL Server, Veeam для бэкапов, КриптоПро для электронной подписи — у всего этого часто есть свои сервисные аккаунты, и по недосмотру им дают права локального администратора «на всякий случай, чтобы работало». В девяти случаях из десяти это лишнее — сервис 1С не обязан быть админом сервера, ему достаточно прав на конкретные папки и на СУБД.

С подрядчиками ещё интереснее. Если вы отдаёте IT на аутсорс — а у большинства компаний до 50 рабочих мест именно так — подрядчик должен заходить под своей именной учёткой, а не под общим Administrator. Это позволяет видеть, что именно он делал, и спокойно отключить доступ при смене подрядчика одной кнопкой, а не сменой пароля у всей компании. Если ваш нынешний подрядчик заходит под общим паролем — это тревожный звонок, и не по поводу подрядчика, а по поводу того, как построена вся система доступа.

Отдельно рекомендую заводить временные учётки для разовых работ — например, когда приходит специалист настраивать видеонаблюдение или новый сервер 1С. Создали учётку на неделю, дали нужные права, после работы удалили. Это пять минут работы, но закрывает целый класс проблем «а у нас, оказывается, три года назад заходил монтажник камер, и у него до сих пор есть доступ».

Двухфакторная аутентификация и мониторинг — та часть, которую все откладывают

Именные учётки и минимальные права — это база. Следующий уровень, до которого руки часто не доходят, — двухфакторная аутентификация на административные учётки. Да, это требует дополнительного приложения на телефоне и лишних тридцати секунд при входе. Но если пароль администратора утечёт — а он утечёт рано или поздно, через фишинг, через заражённый компьютер, через самого сотрудника, — 2FA не даст этим паролем воспользоваться.

Второе — логирование и оповещения. Настроить простое правило: если кто-то зашёл под учёткой Administrator или под доменным админом в нерабочее время, в выходной или ночью — приходит уведомление в Telegram ответственному. Это не требует дорогого SIEM, это можно собрать на PowerShell-скрипте и штатных средствах Windows буквально за пару часов работы. У одной торговой компании такое оповещение один раз реально спасло — сработало в 3 часа ночи в субботу, оказалось, что кто-то подобрал пароль через RDP, выставленный наружу без ограничений по IP.

Третье, что стоит сделать сразу, если у вас RDP торчит в интернет напрямую, — закрыть его и поднять VPN или хотя бы ограничить доступ по белому списку IP-адресов. Половина взломов малого бизнеса, с которыми мы разбирались, начиналась именно с перебора паролей по открытому RDP-порту 3389. Это самая дешёвая и самая частая дыра, которую я вижу.

Сколько это стоит и что вы получаете на выходе

Полный аудит привилегированных учёток на сервере с 20-30 рабочими местами занимает у нас обычно два-три дня работы: выгрузка списков, анализ логов, интервью с директором «кто на самом деле должен иметь доступ», составление плана разграничения. Само внедрение — создание именных учёток, настройка прав, смена паролей, тестирование — ещё день-два, в зависимости от того, сколько сервисов завязано на старую схему.

Дороже всего обходится не сам аудит, а разгребание последствий, если его не делать. Расследование инцидента с уже случившимся ущербом — удалённой базой, зашифрованными файлами, утёкшими данными клиентов — это счёт совсем другого порядка, плюс репутационные потери, которые в деньгах вообще не всегда посчитать.

На выходе вы получаете простую и понятную картину: у сервера есть конкретный список людей с админ-правами, у каждого своя учётка, права минимально достаточные под его задачи, а любое действие в логах можно привязать к конкретному человеку. Звучит скучно, но именно это отделяет компанию, которая переживёт попытку взлома без последствий, от компании, которая неделю будет разбираться, что случилось и кто виноват.

Частые вопросы

У нас маленькая компания, всего 10 рабочих мест — нам это точно нужно?
Именно небольшим компаниям это нужно в первую очередь, потому что у вас обычно нет отдельного айтишника в штате, который следит за порядком в фоновом режиме. Чем меньше компания, тем выше шанс, что доступом к серверу пользуются по остаточному принципу — «ну он же свой человек». А ущерб от простоя или утечки данных для маленькой фирмы часто пропорционально больнее, чем для крупной.

Мы работаем с аутсорс-подрядчиком по IT, разве это не его забота?
Это ваша ответственность в первую очередь, потому что данные и репутация — ваши. Хороший подрядчик сам предложит навести порядок в учётках, но спросить об этом стоит вам самим: попросите список всех, у кого есть административный доступ к вашему серверу, и посмотрите, совпадает ли он с вашими ожиданиями.

Сколько времени займёт переход с общего пароля на именные учётки без остановки работы офиса?
Обычно вся работа укладывается в несколько дней и делается в основном в нерабочее время или по частям, чтобы не мешать сотрудникам. Смена самого пароля от Administrator — тот момент, где может что-то временно сломаться, — лучше делать в пятницу вечером или на выходных, с проверкой всех автоматических процессов до понедельника.

Как понять, что у нас уже проблема с доступами, ещё до аудита?
Есть несколько тревожных признаков: пароль от сервера знают больше двух-трёх человек, его не меняли больше года, среди тех, кто его знает, есть уже уволенные сотрудники, а RDP на сервер открыт прямо в интернет без ограничений. Если хотя бы два пункта из этого про вас — аудит нужен уже сейчас, а не в теории.