IT-аутсорсинг в России
Диагностика технического долга: аудит ИТ-инфраструктуры перед передачей на внешнее обслуживание
Смена ИТ-подрядчика часто вскрывает проблемы, которые годами не мешали работе только благодаря ручным действиям конкретного администратора. Неизвестные пароли, устаревшие прошивки, неподтвержденные резервные копии и сервисы без владельца превращают передачу инфраструктуры в аварийный проект.
Задача предварительного аудита — получить полную картину ИТ-активов, зависимостей и рисков, а затем определить безопасную последовательность передачи. Проверять нужно не только наличие оборудования и серверов, но и возможность управлять ими, восстанавливать их после сбоя и поддерживать без участия прежней команды.
Что должно быть известно до начала передачи
Инвентаризация считается полезной, если по каждому значимому объекту можно ответить на несколько практических вопросов: где он находится, кому принадлежит, какую функцию выполняет, от чего зависит, кто имеет доступ и как объект восстанавливается после отказа.
Состав реестра ИТ-активов
- Сетевое оборудование: маршрутизаторы, межсетевые экраны, коммутаторы, контроллеры и точки доступа, VPN-шлюзы, модемы и резервные каналы.
- Серверы: физические узлы, виртуальные машины, гипервизоры, системы хранения, терминальные серверы и серверы резервного копирования.
- Облачные ресурсы: виртуальные серверы, объектные хранилища, панели управления, учетные записи и подписки.
- Бизнес-сервисы: электронная почта, телефония, сайты, домены, DNS, файловые ресурсы, базы данных, учетные и производственные системы.
- Средства защиты: антивирусное управление, сбор журналов, фильтрация почты, сертификаты, системы контроля доступа и многофакторная аутентификация.
- Рабочие места: компьютеры, ноутбуки, мобильные устройства, принтеры и специализированное оборудование.
- Документы и права: лицензии, договоры, гарантии, инструкции, схемы, регламенты и контакты поставщиков.
Список из бухгалтерской системы или таблица закупок не заменяют техническую инвентаризацию. Оборудование может быть списано только формально, виртуальная машина — не отражена в документах, а важный домен — зарегистрирован на личную учетную запись бывшего сотрудника.
Пошаговая диагностика сети и серверов
-
Зафиксировать границы и правила аудита
Определите площадки, юридические лица, облачные среды и удаленные офисы, входящие в проверку. Назначьте ответственных со стороны бизнеса и технической команды. До любых изменений согласуйте окно работ и порядок действий при обнаружении критической уязвимости.
-
Собрать исходные документы
Запросите актуальные схемы сети, перечни оборудования и виртуальных машин, договоры с операторами, список доменов и сертификатов, инструкции по восстановлению, историю аварий и действующие регламенты. Отсутствие документа нужно отмечать как риск, а не восполнять предположением.
-
Сверить документы с фактической инфраструктурой
Проверьте серверные помещения, стойки, порты и подключения. Сопоставьте обнаруженные устройства с таблицами учета. Затем выполните разрешенное техническое обследование сети и сравните найденные адреса, имена узлов и открытые сервисы с заявленной схемой.
-
Проверить управляемость
Убедитесь, что административные интерфейсы доступны, учетные записи принадлежат организации, а не отдельным сотрудникам или подрядчикам. Проверьте права, многофакторную аутентификацию, аварийные учетные записи и возможность безопасной смены паролей.
-
Оценить состояние сети
Снимите конфигурации маршрутизаторов, межсетевых экранов, коммутаторов и Wi-Fi. Проверьте версии прошивок, поддержку производителем, VLAN, маршрутизацию, правила фильтрации, VPN, резервирование каналов, синхронизацию времени и отправку журналов.
-
Оценить серверную часть
Для каждого сервера зафиксируйте операционную систему, роль, ресурсы, установленное ПО, сетевые связи и владельца сервиса. Проверьте обновления, заполнение дисков, состояние массивов, ошибки оборудования, сроки сертификатов, события безопасности и зависимости между системами.
-
Проверить резервное копирование
Не ограничивайтесь статусом «задание выполнено». Определите, какие системы и конфигурации входят в копию, где она хранится, как защищена от удаления и шифрования, кто получает уведомления об ошибках. Выполните контролируемое тестовое восстановление выбранных данных и конфигураций.
-
Найти бесхозные сервисы
Сопоставьте открытые порты, DNS-записи, сертификаты, задания планировщиков, интеграции, учетные записи и сетевой трафик с реестром сервисов. Для каждого неизвестного компонента определите технического и бизнес-владельца. Не отключайте сервис только потому, что его назначение сразу не удалось установить.
-
Составить карту зависимостей
Отметьте, какие процессы зависят от DNS, каталога пользователей, баз данных, файловых ресурсов, лицензирования, VPN и внешних API. Карта зависимостей помогает избежать ситуации, когда смена пароля или перезапуск одного узла останавливает несколько подразделений.
-
Сформировать план перехода
Разделите найденные проблемы по критичности и трудоемкости. Сначала устраните риски, способные сорвать передачу: отсутствие доступа, неподтвержденные копии, единичные точки отказа и неизвестные критические зависимости. Остальной технический долг перенесите в согласованный план работ.
Критерии проверки
| Область | Что проверить | Признак приемлемого состояния | Признак риска |
|---|---|---|---|
| Инвентаризация | Оборудование, виртуальные машины, облака, лицензии и сервисы | Объекты сверены с фактической инфраструктурой и имеют владельцев | Неизвестные узлы, роли или места размещения |
| Доступы | Административные учетные записи, MFA и аварийный доступ | Доступы принадлежат организации, проверены и разграничены | Общие пароли, личные учетные записи или зависимость от одного администратора |
| Прошивки и ПО | Версии, обновления, сроки поддержки и известные ограничения | Статус поддержки известен, обновления включены в план | Неподдерживаемая версия или обновление без возможности отката |
| Конфигурации | Резервные копии сетевых устройств и критических систем | Копии актуальны, защищены и доступны уполномоченным сотрудникам | Конфигурация существует только на работающем устройстве |
| Резервное копирование | Полнота, хранение, защита и восстановление | Тест восстановления завершен и документирован | Есть только отчеты об успешном копировании |
| Сеть | Сегментация, фильтрация, VPN, Wi-Fi и резервирование | Правила соответствуют назначению сегментов и документированы | Избыточные разрешения, плоская сеть или неизвестные туннели |
| Мониторинг | Доступность, ресурсы, журналы и уведомления | Критические события контролируются, ответственные определены | О сбое узнают только после обращения пользователей |
| Зависимости | Связи между системами и внешними поставщиками | Для критических сервисов известны компоненты и порядок запуска | Изменения выполняются без оценки влияния |
| Документация | Схемы, инструкции, контакты и регламенты | Документы актуальны, доступны и имеют ответственных | Знания хранятся только у прежнего подрядчика |
Типовые ошибки при аудите и передаче
- Менять пароли сразу после получения списка доступов. Старые учетные данные могут быть прописаны в службах, скриптах, системах мониторинга и интеграциях. Сначала нужно выявить зависимости и подготовить порядок ротации.
- Обновлять все прошивки одновременно. Массовое обновление без проверки совместимости, резервной конфигурации и плана отката повышает риск простоя.
- Считать наличие резервной копии достаточным. Копия может быть повреждена, неполна или недоступна при аварии. Работоспособность подтверждает только восстановление.
- Удалять неизвестные учетные записи и сервисы без наблюдения. Непонятная запись может обслуживать обмен с банком, телефонию, лицензирование или производственную систему.
- Проверять только серверы. Домены, DNS, сертификаты, облачные кабинеты, каналы связи и сетевое оборудование могут находиться вне контроля компании.
- Принимать документацию без технической сверки. Схема сети быстро устаревает, если изменения выполнялись без формального учета.
- Передавать подрядчику общую административную учетную запись. Это мешает разграничивать права и разбирать инциденты.
- Пытаться устранить весь технический долг до смены подрядчика. Перед переходом важнее закрыть критические риски и обеспечить управляемость. Остальные изменения следует выполнять по согласованному плану.
Что должно остаться по итогам аудита
Результат диагностики — не общий отчет о «состоянии ИТ», а комплект рабочих материалов:
- проверенный реестр оборудования, программных и облачных активов;
- актуальная схема сети и карта зависимостей критических сервисов;
- перечень владельцев систем и ответственных за бизнес-процессы;
- реестр административных доступов без публикации паролей в отчете;
- сведения о версиях, поддержке и необходимых обновлениях;
- результаты проверки резервного копирования и восстановления;
- список бесхозных или неидентифицированных компонентов;
- реестр рисков с приоритетами, ответственными и условиями устранения;
- план передачи с контрольными точками и порядком отката.
Краткий вывод
Без предварительного аудита новый подрядчик принимает не только оборудование и учетные записи, но и неизвестные зависимости, накопленные ошибки и ответственность за них. Бесшовный переход начинается с фактической инвентаризации, проверки доступов и восстановления, а завершается приоритизированным планом устранения рисков.
Главный критерий готовности прост: организация знает состав инфраструктуры, контролирует административные доступы, понимает зависимости критических сервисов и может восстановить их без участия прежнего администратора.