Реестр ИТ-активов компании: шаблон учёта сервисов, доступов и продлений

«У нас всё записано», — сказал собственник торговой компании на 60 человек и открыл файл. Двенадцать строк: домен, сайт, почта, 1С, банк-клиент и семь подписок. Через час выяснилось: домен оформлен на бывшего маркетолога, письма о продлении уходят на ящик, которым никто не пользуется, а зайти в кабинет хостинга может только подрядчик, с которым разошлись без акта передачи дел.

Файл был. Контроля не было. Это разные вещи.

Реестр ИТ-активов компании отвечает на один практический вопрос: кто сможет управлять доменом, почтой, CRM или облаком, если привычный администратор недоступен. Список оборудования на него не отвечает — отвечают ответственные, договорные данные, способ восстановления управления и результат его проверки. Термин перегружен, поэтому уточним: здесь под ИТ-активами понимаются рабочие ИТ-сервисы, домены, учётные записи и данные, а не цифровые финансовые активы и не медиатека маркетинга.

Коротко. Реестр ИТ-активов компании — это таблица рабочих ИТ-ресурсов, ответственных, сроков продления и способов восстановления управления. Пароли и токены в ней не хранят: указывают идентификатор записи в защищённом хранилище. Наличие резервного администратора подтверждают проверкой входа и полномочий, а не вписанным ФИО.

Эту таблицу мы собрали сами — под задачи, с которыми к нам приходят клиенты на ИТ-аутсорсинге и ИТ-аудите. Это наша разработка, и мы отдаём её бесплатно: файл Excel с рабочим листом реестра, справочником категорий, листом-примером, календарём продлений и сводкой. Кнопка скачивания — в блоке материалов к статье. Похожие таблицы в интернете, разумеется, есть; мы не утверждаем, что наша единственная, — мы собрали её под конкретные вопросы российского СМБ и сами поддерживаем.

Что реестр даёт и чем он не является

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

Три таблицы часто путают, поэтому разведём их.

Реестр — не аудит информационной безопасности и не подтверждение соответствия стандарту. Общий принцип учёта ресурсов, критичности и зависимостей описан в руководстве CISA и CIS Controls 1 и 2; наши поля — прикладная методика, а не официальный шаблон этих документов.

Двенадцать полей, которые заполняются в первую очередь

Первый экран рабочего листа — двенадцать колонок. Их достаточно, чтобы таблица заработала в тот же день.

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

Поля 4 и 5 — разные. Домен может быть оформлен на юридическое лицо, а панель управления — привязана к личной почте сотрудника. Доступ к админке сайта сам по себе не подтверждает контроль ни над доменом, ни над оплатой хостинга, ни над кодом. То же в почтовых платформах: в Яндекс 360 владелец организации — единственный, кто может передать владение и удалить организацию; в VK WorkSpace документация говорит, что владельцем может быть только пользователь с аккаунтом на внешнем домене, а администратором — только внутри домена. Кто у вас в этой роли — в материале о владельце корпоративной почты.

Аккаунт-владелец — поле сервиса, а не мнение о том, кто главный.

«Резерв назначен» — это ещё не «резерв проверен»

Это главная правка, которую мы внесли в свой же шаблон. В прежней версии формула считала резервирование по заполненности ячейки: есть ФИО — значит, актив закрыт двумя людьми. Так не работает. Вписанное имя означает лишь то, что кто-то счёл: этот человек мог бы войти. А он может не иметь прав, не помнить пароля, зависеть от того же телефона со вторым фактором или вовсе не знать о своей роли.

Поэтому в реестре три состояния, разнесённые по полям:

• не назначен — резерва нет, это открытый риск;
• назначен, не проверен — ФИО есть, вход не подтверждён; риск не снижается;
• вход и полномочия проверены — есть дата проверки, результат и ссылка на протокол.

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

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

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

Восстановление не должно зависеть от того, что вы восстанавливаете

Вторая правка того же порядка. В прошлой версии примера домен восстанавливался через адрес domains@company.ru, а почта на этом домене — через кабинет регистратора. Круг замкнулся: отказал домен — недоступна почта, недоступна почта — нечем подтвердить права на домен. В таблице это видно сразу:

Рабочий вариант: канал на ресурсе, которым компания управляет отдельно, — корпоративная SIM-карта, оформленная на юрлицо и физически находящаяся у финансового директора, плюс почтовый ящик на стороннем домене, доступный двум сотрудникам. Там, где восстановление идёт через подтверждение владения доменом (Яндекс 360 через admin.yandex.ru/restore, Google Workspace через запись в DNS), важно, чтобы доступ к DNS-зоне не зависел от того же ящика.

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

Что в реестр не вносим

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

При этом реестр без паролей всё равно чувствителен: это карта инфраструктуры и путей восстановления. Задайте читателей и редакторов, включите историю изменений, храните резервную копию и определите порядок выдачи реестра подрядчику. И да, сам реестр — тоже строка в реестре.

Как собрать реестр: шесть источников

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

1. Бизнес-операции. Начните не с плагинов, а с процессов, остановку которых компания заметит первой: как вы продаёте, нанимаете, платите, отгружаете, отвечаете клиентам. Для каждого выпишите цепочку ресурсов. Для заявок с сайта это домен, DNS, хостинг, код, форма, антиспам, почтовая доставка и CRM. Для 1С — база, сервер, СУБД, вход пользователей, лицензирование, внешние обработки и резервные копии. Такой обход находит зависимости, а не абстрактные «айти-активы», и вытаскивает бесплатные сервисы: отсутствие счёта не означает отсутствия зависимости.

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

3. Корпоративная почта. Поиск по общим ящикам и ящикам руководителей по словам «подтвердите», «регистрация», «ваш аккаунт», «счёт», «продление», «истекает», «invoice». Всплывут забытые сервисы и, что важнее, адреса, на которые они привязаны. Сюда же — правила пересылки в ящиках уволенных.

4. DNS и домены. По каждому домену — WHOIS: администратор, регистратор, paid-till, NS-серверы. Затем зона: MX показывает, где почта; каждая TXT- и CNAME-запись — след когда-то подтверждённой интеграции с почтой, рассылками, вебмастером, конструктором сайтов. DNS-запись — подсказка, а не доказательство: интеграция могла умереть, а запись остаться.

5. Кабинеты и роли. Выпишите, кто в каком сервисе кто: владелец организации в почтовой платформе, главный администратор в Битрикс24 (по документации это сотрудник, создавший портал, и только он подтверждает передачу прав), представители в рекламных кабинетах, пользователи маркетплейсов, пользователи и API-ключи в облаках, доверенности в государственных сервисах, создатели каналов и ботов. Отдельная тема — SSL-сертификаты: у них своя логика сроков и собственный реестр и порядок аудита, соседний инструмент того же семейства.

6. Люди и подрядчики. Чей номер стоит вторым фактором у регистратора, почтовой платформы, банка. Какие доступы есть у студии сайта, агентства, интегратора, предыдущего ИТ-подрядчика и на чьё имя оформлены сервисы, которые они «настраивали». Здесь же ловятся сервисы, заведённые в обход ИТ, — в том числе теневые ИИ-инструменты, про которые мы писали в отдельном разборе.

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

Учебный пример: три строки

Ниже — условные значения с отдельного листа «Пример». Это не клиентский кейс, все данные вымышлены; рабочий лист вы начинаете пустым.

Обратите внимание на третью строку: в реестр попадает не оценка «CRM небезопасна», а конкретная задача с датой. Пока она не закрыта, строка живёт с открытым ограничением — такие строки и выносят на встречу с ИТ-командой.

Как читать индикаторы

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

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

Календарь продлений — лист внутри той же книги, а не отдельный инструмент: та же строка, тот же ID, другой срез. Окно продлений в сводке считается накопительно, от 0 до 90 дней, а не только «61–90»: руководителю нужно видеть всё, что подходит к сроку, включая просроченное. Прежний счётчик ловил только дальний интервал и показывал ноль там, где стояла задача на следующую неделю, — это исправлено.

Для доменов в зонах .RU и .РФ — отдельный столбец со статусом идентификации. По Правилам регистрации, утверждённым постановлением Правительства РФ от 31.08.2026 № 1119, право администрирования осуществляется при условии ежегодной идентификации (пункт 28), заявку подают не ранее чем за 60 дней до истечения года или в течение 30 дней после (пункты 30 и 31), иначе регистрация аннулируется. Регистраторы формулируют это по-своему: Beget пишет, что без подтверждения личности домен и сайт продолжат работать, но операции — продление, смена администратора, передача другому регистратору — будут заблокированы. Порядок действий и сроки — в материале об идентификации домена через Госуслуги. В реестре храните нормализованный статус, дату проверки, зону и источник, а не свободный текст.

Кто ведёт реестр и что запускает обновление

Реестр устаревает в тот момент, когда его перестают вести. Нужен владелец таблицы и список событий, каждое из которых обязывает открыть файл: подключён новый сервис (строка заводится до оплаты); уволился сотрудник с доступами; сменился ИТ-подрядчик или директор; изменился способ оплаты; пришло письмо от регистратора; переносится инфраструктура.

Два события заслуживают отдельных регламентов, потому что в них реестр становится рабочим списком: отключение доступов при увольнении и передача дел при смене ИТ-подрядчика. Фильтр по столбцу «Основной администратор» снимает вопрос «а что ещё было на этом человеке».

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

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

Что дальше

Скачайте шаблон, заполните двенадцать основных полей по критичным процессам и отметьте, что не проверено. Дальше — по ситуации:

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

Обсудить: ИТ-аудит доменов, почты и доступов. Присылать заполненный файл через публичную форму не нужно.

Источники

• Постановление Правительства РФ от 31.08.2026 № 1119 «Об утверждении Правил регистрации доменных имён» — publication.pravo.gov.ru/document/0001202609010015 (с 01.09.2026), пункты 28, 30, 31, 34; часть 7 статьи 14.2 ФЗ № 149-ФЗ в редакции ФЗ от 29.12.2025 № 569-ФЗ — проверено 05.09.2026.
• Координационный центр доменов .RU/.РФ, новость от 02.09.2026 о переходе регистраторов — cctld.ru/media/news/kc/40971/; справка Beget о подтверждении личности администратора домена — проверено 05.09.2026.
• Справка Яндекс 360 для бизнеса: аккаунт владельца организации и восстановление через admin.yandex.ru/restore; документация VK WorkSpace: роли владельца и администратора — проверено 05.09.2026.
• Служба поддержки Битрикс24, «Главный администратор и передача прав» — helpdesk.bitrix24.ru/open/26764700/ — обновлено 23.07.2026, проверено 05.09.2026.
• Справка Google Workspace, восстановление доступа администратора — support.google.com/a/answer/33561 — проверено 05.09.2026.
• CISA, StopRansomware Guide; CIS Controls 1 и 2 — общий принцип инвентаризации ресурсов.