Инвентаризация корпоративных паролей перед миграцией: таблица и план работ

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

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

Начните с карты систем, а не с файлов паролей

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

Соберите карту рабочих сервисов: инфраструктура, хостинг, CRM, финансы, маркетинг, облачные площадки, резервное копирование, DevOps, внутренние панели администрирования. Затем спросите владельцев: какие аккаунты используются, кто выдаёт к ним права, где лежит действующая версия секрета, как происходит смена и можно ли восстановить доступ без конкретного человека.

Полезно провести несколько коротких интервью с ИТ, ИБ и бизнес-командами. Вопрос «где у вас пароли?» менее информативен, чем «что вы делаете, когда новый сотрудник просит открыть систему?» или «кто меняет доступ после ухода подрядчика?». По ответам часто находятся скрытые источники, не попавшие в предыдущие списки.

Сначала опишите критичный контур, чтобы заранее увидеть зависимости и согласовать контроль. Это приоритет инвентаризации, а не требование переносить самые важные секреты первыми: порядок миграции определяют после тестового импорта.

Что записывать в реестр и что туда не помещать

В подготовительной таблице достаточно метаданных. В ней не нужны сами пароли, API-ключи, резервные коды и другие данные, которые позволят войти в систему. Их сбор в один незашифрованный файл создаёт новую точку риска и противоречит задаче миграции.

Базовые поля: идентификатор записи, название системы, тип аккаунта, бизнес-владелец, технический ответственный, подразделение, критичность, способ текущего хранения, источник для проверки, наличие MFA, предполагаемая группа доступа и статус миграции. Дополните реестр датой последней проверки и ссылкой на внутреннюю заявку или карточку сервиса.

Поле	Пример значения	Зачем оно нужно
Система	CRM регионального офиса	Понятно, к чему относится доступ
Тип учётной записи	Общая рабочая	Видно, что права нельзя связать с одним человеком
Владелец	Руководитель отдела продаж	Есть кому согласовать будущие права
Ответственный	ИТ-администратор	Известно, кто выполнит технический перенос
Критичность	Высокая	Нужна осторожная миграция с проверками
Текущий источник	Согласованное хранилище отдела	Понятно, где брать действующую запись
Статус	Ожидает сверки	Не создаётся видимость завершённой работы

Используйте нейтральные имена записей: «администратор CRM — филиал 2», а не логины, содержащие персональные данные без необходимости. Доступ к реестру тоже ограничьте; сама карта сервисов и администраторов может быть чувствительной информацией.

Как проверить, что реестр не пропустил важное

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

Сопоставьте реестр с перечнем приложений, заявками в Service Desk, каталогом пользователей, доступными данными о сервисных аккаунтах и списком подрядчиков. Если политика позволяет, используйте сведения из конфигураций и секретных хранилищ, не извлекая сами пароли в открытую таблицу. Важно не собирать всё автоматически любой ценой, а находить несоответствия между источниками.

Признаки проблемы: система есть в инвентаризации инфраструктуры, но у неё нет ответственного за доступ; договор с подрядчиком завершён, а общая учётная запись продолжает использоваться; несколько команд называют разных владельцев одного кабинета. Эти случаи создают отдельную очередь выяснения обстоятельств.

Отмечайте степень достоверности: «подтверждено владельцем и тестом», «подтверждено одним источником», «требует проверки». Не смешивайте отсутствие сведений с отсутствием аккаунта. В отчёте лучше честно показать двадцать неизвестных записей, чем заявить о полном покрытии без оснований.

Дубликаты, устаревшие записи и пароли без владельца

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

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

Заброшенные аккаунты не нужно автоматически удалять. Сначала выясните, не работают ли под ними интеграции, задания по расписанию, резервные процессы или внешние подрядчики. В реестре укажите «кандидат на отключение», владельца проверки и дату. Для критичных систем решение должен подтверждать ответственный за сервис.

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

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

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

Очередность миграции: не всё критичное нужно переносить первым

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

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

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

При проверке форматов используйте безопасные тестовые секреты. Если обнаружена реальная компрометация, реагирование на неё нельзя откладывать ради удобства миграции. Массовая ротация, переназначение ролей и перенос в новый продукт одновременно усложняют поиск ошибки. Лучше отделить миграцию данных от обязательных действий по снижению рисков и явно указать зависимости между ними.

Проверьте импорт на выборке до массового переноса

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

В инструкции BearPass по импорту и экспорту описаны CSV, JSON и загрузка данных из KeePass и Пассворк. Для KeePass указан предварительный экспорт в XML; для CSV — заданный порядок полей и UTF-8. Экспорт BearPass описан в CSV и JSON; CSV содержит пароли в открытом виде, поэтому выгрузку нужно включить в перечень чувствительных временных файлов. Начиная с версии 2.26 импорт и экспорт выполняются в текущем выбранном пространстве. Перед загрузкой проверьте его отдельно: верный файл в неверном пространстве — тоже ошибка миграции. Перенос прав, истории и вложений проверяйте отдельно на выбранном способе.

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

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

Контроль старых копий и непрерывности работы

После переноса копии секретов могут остаться в прежних местах: резервные копии, файлы экспорта, личные заметки, архивы общих папок. Объявление нового менеджера паролей основным не означает, что эти копии исчезли. Составьте реестр временных экспортов и точек хранения с ответственными и сроками обработки.

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

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

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

Кто принимает результат и что измерять

В приёмке результата участвуют три стороны, а единственного ответственного за проект назначают заранее. ИТ подтверждает техническую корректность переноса, ИБ — ожидаемую модель доступа и безопасность временных файлов, бизнес-владельцы — сохранность рабочих процессов. Если одна сторона отсутствует, миграция может выглядеть успешной по количеству записей и неудачной по реальному использованию.

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

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

Если реестр уже составлен, используйте его как основу будущей ревизии прав: он пригодится и после миграции. Практический контур работы с доступами описан в материале BearPass об аудите паролей. Не превращайте инвентаризацию в разовую уборку перед запуском нового ПО.

Контрольная выборка после переезда. Через одну-две недели проверьте несколько записей каждой категории: персональные, общие, сервисные, высококритичные и переданные подрядчику. Подтвердите владельца, наличие актуальной версии и корректность доступа. Если новые пароли продолжают появляться в старой таблице, значит, проблема уже не в переносе данных, а в том, что сотрудники не приняли новое правило работы.

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

Рекомендуем к прочтению

• BearPass и KeePass: сравнение
• Менеджер паролей для DevOps-команды

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