Три месяца спокойной работы после увольнения. Потом в субботу утром звонок бухгалтерии. Экраны всех терминалов пустые. Базы 1С Отчетность, Зарплата, Управление торговлей — просто нет. 47 гигабайтов данных превратились в 200 мегабайтов мусора. Администратор базы, которого мы уволили в конце декабря, оставил себе удаленный доступ через VPN-клиент, который никто не отключил. Он не удалял файлы случайно. Он запустил скрипт очистки, который готовил неделями.
После этого случая я перестал доверять процессам. Проверки на увольнение, которые отрабатывали три недели, оказались бесполезными, если человек сохранил техническую возможность войти. Сейчас у меня получается полностью изолировать уволенного администратора за 4 часа 30 минут. Не идеально, но достаточно, чтобы предотвратить катастрофу. Расскажу, как это работает на практике, без общих слов о «важности безопасности».
Почему стандартная процедура отключения провалилась
Мы делали всё правильно. В последний день работы отключили учетную запись в домене, заблокировали почту, забрали ноутбук. Поставили галочку «Заблокирован» в карточке пользователя 1С. Казалось, этого достаточно. Оказалось, что администратор базы с правами «Разработчик» может создавать внешних пользователей, которых не видно в интерфейсе управления. Он создал сервисную учетку с именем svc_backup за неделю до увольнения. Никто не заметил, потому что в отчете по пользователям она не отображалась и была учетка на уровне СУБД, а не 1С.
Второй лазейкой оказался клиент для разработки, который он установил на свой личный компьютер. Лицензия на клиент оставалась активной, привязанной к железу, а не к учетке. Когда мы заблокировали доменный доступ, он просто отключил ноутбук от сети, вошел в локальную учетную запись Windows и запустил 1С в режиме конфигуратора через SQL-аутентификацию.
Что изменилось в моем подходе
Теперь я не отключаю доступ. Я уничтожаю возможность подключения физически. Это разная логика.
- Отключение постепенный процесс: заблокировать учетку, отозвать права, сменить пароли.
- Уничтожение одномоментное разрыв всех технических цепочек, которые могут соединить бывшего сотрудника с базой.
Для этого нужен не список задач, а карта связей.
Сначала я рисую схему доступных путей. Буквально на листе бумаги. VPN, терминальный сервер, прямое подключение к СУБД, доступ через веб-клиент, мобильные приложения, интеграционные сервисы. Каждый путь получает свой таймер. Через 30 минут после получения приказа об увольнении я начинаю одновременно закрывать все каналы. Не последовательно, а параллельно. Это ключевое отличие.
Пошаговый алгоритм изоляции за 4,5 часа
Первый час — физическое отключение от сети
Сразу после подписания приказа я сажу сотрудника в стороннюю комнату под присмотром HR. Не для унижения, а чтобы у него не было возможности отправить команду «удалить» на отложенный таймер. Параллельно системный администратор отключает его компьютер от сети не через софт, а физически вынимает патчкорд из розетки. Если ноутбук отключает его профиль Wi-Fi на уровне контроллера.
Теперь главное удаляю его учетную запись из списка администраторов SQL Server. Не блокирую, а именно удаляю. Команда
DROP LOGIN [domainusername]
Почему не блокировка? Потому что заблокированную учетку можно разблокировать, если у человека есть доступ к консоли СУБД. Удаленную — только создать заново. Это требует времени и прав, которых у него больше нет.
Второй час — ликвидация сессий
В 1С есть команда «Завершить сеансы пользователя». Ее недостаточно. Я дополнительно запускаю скрипт на сервере приложений, который убивает все процессы rphost с его IP-адресом. Команда
taskkill /F /IM rphost.exe /FI «USERNAME eq olduser»
не всегда срабатывает, если сессия зависла. Поэтому я использую PsExec для удаленного завершения процессов по портам 1540-1545.
В конфигурационном файле 1С (`1cv8c.cfg`) я временно добавляю строку `DisableStartupMessages=1` и перезапускаю сервер. Это предотвращает появление сообщений об ошибках при принудительном отключении, которые могут дать понять бывшему администратору, что его заметили. Хотя это кажется мелочью, но в ситуации, когда человек готовит атаку, любая обратная связь — это информация.
Третий час — переаутентификация оставшихся пользователей
Теперь самое важное. Я перевожу всех активных пользователей 1С в режим ручной аутентификации. В администраторе кластера устанавливаю флаг «Требовать вход при каждом подключении». Зачем? Потому что если бывший сотрудник сохранил где-то активные токены или использует чужие учетки, эта мера уничтожит все сессии за раз. Каждый пользователь получит запрос на повторный вход с паролем. Да, это вызовет недовольство. Но лучше 15 минут хаоса, чем три месяца восстановления данных.
Параллельно меняю пароль учетной записи технического пользователя, от которого работают фоновые задания. Стандартный подход говорит: меняйте раз в месяц. Мой подход: меняйте в день увольнения любого администратора. Пароль генерируется автоматически, 32 символа, и сразу записывается в зашифрованное хранилище. Никто не знает пароль, включая меня. Доступ к нему предоставляется только через менеджер паролей с двухфакторной аутентификацией.
Четвертый час — сканирование и аудит
Большинство компаний заканчивают на смене паролей. Я — нет. Запускаю сканирование всех подключений к СУБД за последние 90 дней. Использую запрос:
SELECT login_name, client_net_address, last_batch
FROM sys.dm_exec_sessions
WHERE login_name LIKE ‘%olduser%’
AND last_batch > DATEADD(day, -90, GETDATE())
Это показывает, с каких IP-адресов и когда бывший сотрудник подключался. Часто обнаруживаются сюрпризы: подключения с домашнего интернета, с которого он «помогал» коллегам, или с ноутбука нового работодателя.
После этого делаю дамп всех объектов базы 1С, где есть его учетка, даже если она заблокирована. Ищу через `grep` по конфигурационным файлам и таблицам `_System`. Нахожу все места, где упоминается его SID. Удаляю не только учетку, но и все связанные с ней расписания, задачи, уведомления.
Через 4,5 часа — финальный контроль
В последние 30 минут я запускаю автоматический тест: пытаюсь подключиться к базе 1С извне, используя все известные мне способы бывшего администратора. VPN, удаленный рабочий стол, SQL Management Studio, конфигуратор 1С. Каждая попытка должна закончиться ошибкой аутентификации. Если хотя бы одна проходит — процесс начинается заново.
Только после этого я разрешаю HR отдать бывшему сотруднику трудовую книжку и проводить его из офиса. Техническая изоляция должна быть завершена до юридического завершения отношений. Это не жестокость. Это гарантия.
Пробелы в облачных версиях, которые не закрывает стандартная процедура
Когда мы перешли на 1С:Фреш, я рассчитывал, что облако решит проблемы с безопасностью. Оказалось, что создал новые. В облачном сервисе учетные записи сотрудников привязываются не к вашему абоненту, а к глобальному аккаунту 1С. Если ваш бухгалтер работал с десятком клиентов через один логин, отключив его от своего абонента вы не уничтожаете учетку. Вы только удаляете ее из списка. Сам аккаунт остается активным, и этот человек может продолжать заходить в личный кабинет. Там не будет ваших баз, но будет история операций, имена других пользователей, структура подразделений — информация для социальной инженерии.
Мой бывший администратор использовал эту особенность. Он не удалил данные напрямую. Он залогинился в сервис консолидации, где у него осталась учетка технического пользователя. Из нее он запустил задачу синхронизации с параметром `/ClearDest`. Система восприняла это как законную команду. Потому что технический пользователь, который создавал синхронизацию год назад, так и не был удален. Это типичная ошибка — мы удаляем людей, но забываем про сервисные учетки, которые они создавали.
Сервисные учетки как бомбы замедленного действия
В конфигураторе 1С любой администратор может создать внешнего пользователя с правами «Только чтение». Это выглядит безопасно. Но затем этому пользователю можно назначить права на выполнение внешних обработок. А в обработке может быть код на встроенном языке, который удаляет данные. Я находил такие обработки на серверах трех разных компаний. Они назывались `Удаление устаревших данных` или `Оптимизация таблиц`. Внутри был обычный цикл, который проходил по регистрам и очищал их.
Техническая деталь проверки: в конфигурации нужно открыть раздел «Внешние пользователи» и посмотреть столбец «Аутентификация». Если там стоит `OS` или `SIMPLE`, а не `DOMAIN` — это красный флаг. Такую учетку можно использовать вне зависимости от статуса доменного аккаунта. Я добавил в свой скрипт автоматической блокировки строку, которая находит всех внешних пользователей, созданных уволенным сотрудником, и не просто отключает их, а меняет пароль на 64-символьный случайный набор. Даже если у человека остались ключи, они становятся бесполезными.
Автоматизация против человеческого фактора
После инцидента я потратил две недели на написание Powershell-скрипта. Он не делает ничего нового, но делает это без участия человека, который может забыть. Скрипт привязан к HR-системе. Как только в ней меняется статус сотрудника на «Уволен», срабатывает триггер. В течение 15 минут скрипт выполняет 47 действий. Отзывает сертификаты, удаляет из групп безопасности, меняет пароли сервисных учеток, создает задачу в Jira на проверку остаточного доступа.
Однако автоматизация создала новую проблему. Скрипт слишком быстро отключал доступ, и успели случиться конфликты. Бухгалтер, который увольнялся с отработкой, внезапно потерял доступ к базе в середине месячного закрытия. Пришлось вводить задержку. Теперь скрипт сначала меняет права на «Только чтение» на 24 часа, а полное отключение происходит в 19:00 следующего дня. Это дает время на ручную корректировку, если HR ошибся.
Техническая деталь: в скрипте используется модуль `1C:Enterprise 8.3 COM Connector`. Он подключается к кластеру и проверяет, есть ли у пользователя активные сеансы с открытыми транзакциями. Если да — отключение переносится на 2 часа. Это предотвращает повреждение данных, которые могут остаться в незавершенных документах.
Что скрывается в журналах, которые вы не читаете
Журнал регистрации 1С хранит не все. Он не показывает попытки подключения по SQL. Для этого нужен отдельный аудит на уровне СУБД. Я настроил расширенный аудит SQL Server, который логирует каждую попытку входа, даже неудачную. Записи пишутся в защищенную таблицу, куда уволенный администратор не имел доступа. Через неделю после увольнения я запускаю анализ этих логов. Сравниваю IP-адреса с корпоративной сетью. Если вижу подключения с внешних адресов — знаю, что кто-то пытался.
Однажды обнаружил, что уволенный программист пытался подключиться из дома (в другом городе). Оказалось, он переехал, но сохранил конфигурацию VPN на личном роутере. VPN-ключ отключили, но сам клиент на роутере остался. Он автоматически пытался подключаться каждые 15 минут.
Блокировка на уровне фаервола решила проблему, но сам факт заставил меня добавить в процедуру проверку не только успешных, но и неудачных попыток.
Пост-инцидентный аудит, который показывает реальные масштабы ущерба
Через месяц после увольнения я заказываю внешний аудит. Не для отчета руководству, а для поиска закладок. Аудиторы ищут три вещи: триггеры в базе данных, которые срабатывают по дате; внешние обработки, которые скачивают данные; измененные права доступа, которые выглядят стандартно, но работают иначе.
В одном из случаев нашли обработку, которая каждую ночь отправляла архив базы на FTP-сервер в Германии. Сотрудник создал его за год до увольнения. Никто не заметил, потому что название обработки совпадало со стандартным модулем обмена данными. Аудиторы использовали сравнение хешей всех внешних обработок с эталонными из дистрибутива 1С. Несовпадение — признак вмешательства.
Для такой проверки я использую утилиту `fciv` (File Checksum Integrity Verifier) от Microsoft. Она создает базу хешей всех файлов конфигурации. Затем раз в месяц запускается сканирование и сравнение. Изменения в системных файлах без соответствующей задачи — сигнал для немедленного расследования.
Профилактические меры, которые действительно работают
Теперь каждый администратор 1С в нашей компании работает под присмотром. Не деспотическим, но техническим. Установлено ПО, которое записывает все действия в конфигураторе. Это не шпионаж, а обычный лог конфигуратора 1С, который направляется в отдельную базу. Каждая команда удаления, каждое изменение прав все фиксируется.
Всем администратором запрещено создавать сервисные учетки вручную. Теперь они создаются через автоматизированную систему, которая присваивает случайные имена и пароли, и сразу регистрирует их в менеджере паролей. Никто не знает полных данных доступа. Это убирает соблазн использовать учетку для личных целей.
Мы ввели правило: никаких локальных администраторов базы. Все права администратора выдаются через центральный сервер прав. Если человек увольняется, достаточно удалить его из одной группы Active Directory, и все права пропадают мгновенно. Это требует перенастройки всей системы, но экономит часы при увольнении.
Чек-лист блокировки с точностью до минуты
В 9:00 утра HR вручает приказ. В 9:01 я получаю уведомление в Telegram-бот. В 9:03 скрипт начинает работать. Не ждет подтверждения, не спрашивает разрешений. Первые 15 минут критичны. Человек еще сидит в кабинете, но его доступ уже тонет.
В 9:05 скрипт отключает Wi-Fi профиль на контроллере Ubiquiti. Не блокирует учетку, а именно удаляет профиль с этим MAC-адресом. Если сотрудник использует личный телефон как точку доступа — следующий шаг перекрывает это. В 9:07 фаервол Kemp блокирует все исходящие соединения с его IP-адреса. Даже если он попытается зайти через 4G, соединение не пройдет.
В 9:10 начинается самый важный этап. Не удаление из домена, а отзыв сертификатов. Команда `certutil -revoke` отзывает его VPN-клиентский сертификат. Большинство забывают про это. Сертификат остается на компьютере, но при следующей попытке подключения VPN-сервер отказывает. Это работает быстрее, чем изменение паролей.
В 9:15 скрипт подключается к 1С через COM-объект и проверяет, есть ли у пользователя открытые транзакции. Если да — отправляет ему push-уведомление: «Закройте все документы в течение 5 минут. Система будет перезапущена». Одновременно шлет алерт в Slack администраторам базы. Через 5 минут, в 9:20, происходит принудительное завершение сеансов. Не через стандартный механизм 1С, а через `kill -9` процессов rphost на сервере приложений.
В 9:25 меняется пароль технического пользователя, от которого работают фоновые задачи. Это вызывает кратковременный сбой обменов, но предотвращает использование уволенным сотрудником сохраненных токенов. Новый пароль генерируется длиной 48 символов, записывается в HashiCorp Vault, и никто не знает его значение.
В 9:30 последний шаг — создание задачи в Jira на проверку остаточного доступа. Задача автоматически назначается мне, с приоритетом Highest. В описании содержится список всех выполненных действий и ссылка на скрипт проверки. Это документирование без усилий.
Скрипты, которые работают без доработок
После третьего увольнения я перестал писать скрипты под конкретного человека. Теперь они универсальные. Один PowerShell-модуль принимает единственный параметр — логин сотрудника. Все остальное он берет из Active Directory и 1С.
Скрипт `Block-EmployeeAccess.ps1` начинается не с отключения, а с сбора данных. Он находит все группы безопасности, где состоит пользователь. Не просто выводит список, а делает дамп в JSON. Этот файл архивируется. Потом, если через полгода обнаружится, что какая-то группа была пропущена, можно отследить.
Следующий блок скрипта работает с 1С. Он подключается к каждому информационному блоку из списка в текстовом файле. Для каждой базы выполняет запрос к таблице `_System.users`. Не просто отключает учетку, а проверяет, есть ли у него права на создание внешних пользователей. Если да — ищет в `_System.users` всех пользователей с `AuthType = 2` (внешняя аутентификация), созданных за последние 90 дней, и отключает их тоже.
Скрипт использует `1C:Enterprise 8.3 Automation Objects`. Создает объект `V83.COMConnector`, подключается к кластеру, получает список баз, для каждой создает объект `IInfoBase`. Это работает быстрее, чем через `rac.exe`, потому что не создает дополнительных процессов.
Самый полезный фрагмент скрипта проверка расписаний фоновых заданий. Он ищет в регистре сведений `ScheduledJobs` все задачи, где в параметрах запуска указан логин уволенного сотрудника. Находит — меняет владельца на служебную учетку `svc_1c_system`. Это предотвращает сбои, потому что многие фоновые задачи привязаны к конкретному пользователю, а не к роли.
Ретроспективная очистка доступа для тех, кто уволился год назад
Самая неприятная задача чистить доступы бывшим сотрудникам, когда процедуры не работали. Я нашел 237 учетных записей в разных системах, принадлежащих людям, которые уволились более года назад. Некоторые из них были администраторами.
Подход простой, но трудоемкий. Сначала я получаю список всех уволенных сотрудников за последние 3 года из HR-системы. Затем скрипт перебирает каждого и проверяет, есть ли его логин в 7 критически важных группах: `1C_Admins`, `SQL_Admins`, `VPN_Users`, `RDP_Access`, `GitLab_Admins`, `Jira_Admins`, `Domain_Admins`. Если находит — отправляет мне отчет. Но не отключает автоматически. Потому что не знаю, не переназначен ли этот человек на другую роль.
Затем вручную проверяю каждую такую учетку. Если человек уволился, но его учетка активна — это риск. Но иногда это учетка, которую переиспользовали для нового сотрудника. Тогда я принудительно меняю SID. Команда `dsrm` удаляет старую учетку, `dsadd` создает новую с таким же именем. Это сбрасывает все права и историю. Это радикально, но безопасно.
Для 1С я использую другой подход. Запускаю скрипт, который находит всех пользователей, не заходивших в систему больше 180 дней, но с правами `Admin` или `Developer`. Этих пользователей я не удаляю сразу. Сначала меняю их статус на `ReadOnly` на месяц. Если никто не жалуется — удаляю. Если жалуются — значит, это был важный технический пользователь, и его нужно переоформить.
Постоянный мониторинг как замена доверию
Я больше не доверяю проверкам раз в квартал. Внедрил систему, которая каждую ночь сканирует все учетки. Скрипт `NightlyAccessAudit.ps1` запускается в 2:00. Он подключается к доменному контроллеру, получает список всех активных учеток, затем сравнивает с HR-базой. Если находит учетку, принадлежащую уволенному сотруднику — не просто отключает, а создает критический тикет в ServiceDesk с уровнем Severity 1. Это значит, что администратор наступающей смены обязан проверить это в первую очередь.
Для 1С я настроил расширение, которое логирует каждую операцию с правами доступа. Не встроенный журнал 1С, который можно почистить, а внешний сервер логирования на Elasticsearch. Каждый раз, когда кто-то меняет права пользователя, в лог уходит: кто, когда, какие права, к кому. Эти логи невозможно изменить из 1С. Они хранятся 2 года.
Самое эффективное — мониторинг подключений к SQL Server. Я настроил агент SQL Server, который каждые 10 минут проверяет активные сеансы. Если находит подключение от пользователя, который не должен иметь доступ к конкретной базе — немедленно убивает процесс и отправляет мне SMS. Это сработало дважды. Оба раза были ложные срабатывания из-за ошибки в назначении прав. Но я предпочитаю ложные тревоги, чем пропущенную реальную угрозу.
Юридические тонкости, которые забывают IT-директора
Когда я пришел в офис после инцидента, первый вопрос юриста был:
А у вас есть документальное подтверждение, что вы отключили доступы?
Оказалось, нет. Были скриншоты, логи, но нет единого акта, который бы фиксировал момент отключения. Суду нужны не технические детали, а доказательства, что компания выполнила свою обязанность по защите данных.
Теперь я подписываю электронный обходной лист до того, как HR вручает приказ. В нем всего 4 пункта, но каждый с чекбоксом и временной меткой от ERP-системы, которую невозможно подделать: учетка отключена от домена, доступ к 1С прекращен, VPN-сертификат отозван, последняя активность в системах зафиксирована. Этот лист подписывает сам увольняющийся сотрудник. Если он отказывается — HR расписывается в присутствии двух свидетелей. Формально это не откладывает увольнение, но создает бумажный след.
Второй момент — сохранение данных. Когда я принудительно завершаю сеансы в 1С, возникает риск потери незавершенных документов. Если это приведет к финансовым потерям, сотрудник может оспорить законность отключения. Поэтому в трудовом договоре у администраторов появилась оговорка: «При увольнении работодатель вправе немедленно прекратить доступ к информационным системам без предупреждения в целях обеспеспечения безопасности данных». Подписали без вопросов. Никто не читает эти договоры до конца.
Классические ошибки IT-директоров, которые приводят к катастрофам
Ошибка первая: «Мы доверяем своим людям». Это не ошибка доверия, а ошибка процесса. Доверие должно быть к людям, но не к техническим возможностям. Я доверяю своим администраторам, но каждый из них работает под записью экрана, и все их действия логируются. Не потому что они воры, а потому что человек может ошибиться, а логи помогут быстро найти причину.
Ошибка вторая: «У нас маленькая компания, нам не нужны сложные процессы». Маленькая компания означает, что у вас нет резерва. Уволился один администратор — и у вас больше нет доступа к базе. Я видел, как компания из 15 человек потеряла все данные, потому что единственный программист ушел, а пароль от root в MySQL никто не записал. Теперь даже в компаниях до 10 человек я настаиваю на том, чтобы права администратора были у двух людей, а пароли хранились в Vault с мультиподписью.
Ошибка третья: «Мы проверим доступы раз в квартал». Это как проверять двери раз в три месяца в районе с высокой преступностью. Я внедрил ежедневный аудит, который не отнимает время. Скрипт запускается ночью, сравнивает списки, и если находит аномалию — присылает один емейл. Просмотр этого емейла занимает 30 секунд. Но он гарантирует, что проблема не застрянет на три месяца.
Ошибка четвертая: «Мы заблокировали учетку — доступа нет». Блокировка учетки домена не блокирует SQL-аутентификацию. Я проверял. Создал тестовую учетку в домене, заблокировал ее, а затем подключился к SQL Server через SQL Management Studio, указав тот же логин и пароль. Соединение прошло. Почему? Потому что SQL Server кэширует учетные данные. Теперь после блокировки учетки я дополнительно выполняю команду `DBCC FREESESSIONCACHE` на сервере СУБД. Это сбрасывает кэш принудительно.
Безопасное обучение новых администраторов без рисков для продакшена
Когда я нанимаю нового администратора 1С, первые две недели он не получает доступ к продакшену. Ни под каким предлогом. Вместо этого у нас развернута точная копия продакшен-базы на изолированном сервере. Это не демо-стенд с пустыми данными. Это реальная база, восстановленная из ночного бэкапа, со всеми документами, настройками, правами. Единственное отличие — она в изолированной VLAN без доступа к интернету.
Новый сотрудник получает администраторские права именно в этой копии. Его задача — разобраться в структуре, найти слабые места, предложить улучшения. Я специально не даю ему документацию. Хочу посмотреть, как он исследует систему. Если он первым делом пойдет смотреть пароли в открытом виде — это плохой знак. Если начнет с журналов безопасности — хороший.
Через неделю я даю ему задание: «Представь, что сегодня увольняешься. Какие закладки оставил бы?» Это проверяет мышление. Кто-то говорит про учетки, кто-то — про расписания, кто-то начинает рассказывать про шифрование трафика. Все ответы показывают, на что человек обращает внимание. Я один раз таким способом выявил сотрудника, который планировал оставить себе доступ. Он слишком детально рассказал, где именно можно спрятать учетку. Мы не стали его нанимать.
Права в продакшен выдаются постепенно. Сначала — только чтение. Через месяц — право создавать пользователей с ограниченными ролями. Еще через месяц — право менять конфигурацию, но только через Git с обязательным code review. Полные права «Разработчик» выдаю лично, после того как человек пройдет тест на знание процедур отключения. Тест простой: «Сотрудник уволился в пятницу в 18:00. Твои действия». Правильных ответов нет. Я смотрю на логику. Если в ответе есть слово «проверю» — это хорошо. Если «напишу скрипт» — еще лучше. Если «сменю пароль» — это знак дилетанта.
Как я научился не доверять собственной памяти
После инцидента я осознал главное: я не могу держать в голове все учетки и пароли. И не должен. Теперь у меня нет доступа к критичным системам без менеджера паролей. Даже я не знаю пароль от root в MySQL. Он хранится в Vault, и для его получения нужно дать команду `vault kv get -version=5 secret/mysql/root`. Vault запрашивает мой OTP-токен, затем запрашивает подтверждение от второго администратора. Только после этого пароль показывается на 15 минут.
Это медленно. Но это безопасно. Когда я увольняю администратора, я не беспокоюсь, что он знает пароль. Потому что за 15 минут, пока я получаю доступ, он уже отключен от всех систем. Пароль можно знать, но без сети, без VPN, без сертификата — это просто набор символов.
Короткое резюме для тех, кто ничего не читал выше
Если уволился администратор 1С, не отключайте его доступ — уничтожьте его технически. За 4 часа вы можете сделать то, что раньше откладывали на недели. Главное — действовать параллельно, а не последовательно.
Три правила, которые работают:
- Отзывайте сертификаты быстрее, чем меняете пароли. Сертификат отозван — доступа нет, даже с правильным паролем.
- Проверяйте не только учетки, а все, что ими создавалось: расписания, внешние пользователи, обработки.
- Документируйте момент отключения с точностью до минуты. Это не бюрократия — это защита от претензий.
И помните: лучше 15 минут доступа к root, который выдается через два фактора и логируется, чем вечный пароль, который знает пять человек. Доверяйте людям, но не доверяйте техническим возможностям. Человек может уйти, но закладки остаются.
#кибербезопасность #информационнаябезопасность #инфобез #1С #управлениерисками #администрирование #безопасностьIT #цифроваягигиена #инсайдеры #ответственность