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

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

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

Почему через месяц, а не в день приёмки

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

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

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

Второе основание для месячного срока — данные. Через месяц в системе уже накопился журнал, по которому видно поведение в норме: во сколько люди заходят, сколько карточек открывают в обычный день, когда работает обмен. Без этого фона любое наблюдение бессмысленно: невозможно отличить аномалию от рабочего ритма, и проверка сводится к списку того, что включено, а не к тому, что происходит.

сравнениеproverki-bezopasnosti-posle-sdachi--01
Состояние системы в день приёмки и через месяц: 34 против 47 учётных записей

Сравнение в две колонки по шести строкам. Левая «День приёмки»: активных учётных записей 34, ролей 5, интеграций 4, временных доступов 0, служебных адресов без авторизации 0, правил пересылки на внешнюю почту 0. Правая «Через месяц»: активных учётных записей 47, ролей 5 плюс две выданные «на время», интеграций 6, временных доступов 3, служебных адресов без авторизации 1, правил пересылки на внешнюю почту 2. Изменившиеся значения в правой колонке выделены. Под колонками общая подпись: «два часа руководителя и час администратора — 4 800 ₽». Чертёжный стиль, подписи по-русски.

Ни одно из этих изменений не проходило через приёмку — она уже закончилась

Восемь проверок и норма по каждой

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

Что смотримКакНорма
1Активные учётные записиВыгрузить список активных записей и сверить со списком сотрудников и действующих договоровКаждой записи соответствует человек или названный процесс; записей вида test, demo, temp нет
2Права по ролямЗайти под учётной записью рядового сотрудника и попробовать выгрузить всю базу в файлВыгрузка не проходит; чужие сделки и суммы не видны
3Журналы за месяцОткрыть журнал действий и убедиться, что он ведётся и хранит хотя бы 30 днейЖурнал есть, глубина не меньше месяца, записи содержат автора и время
4Резервные копииПосмотреть дату последней успешной копии и спросить протокол проверки восстановленияКопия не старше суток, протокол проверки восстановления существует и датирован
5Ключи интеграцийЗапросить перечень действующих ключей: где лежат, кто знает, когда выпущеныПеречень существует, ключи подрядчика после сдачи перевыпущены, старые отозваны
6Служебные адресаОткрыть адреса отладочных страниц, точек обмена и выгрузок в браузере без входа в системуКаждый адрес возвращает отказ, а не страницу и не данные
7Исходящие запросы сайтаОтправить тестовую заявку с формы и посмотреть, каким внешним сервисам она уходитСписок получателей совпадает с тем, что описано в политике обработки данных
8Пересылка на личную почтуПроверить правила пересылки в почте и внешние адреса в настройках уведомлений системВнешних адресов нет; отчёты и уведомления уходят только на корпоративные ящики

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

Что делать с находками: три уровня срочности

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

УровеньЧто сюда попадаетСрокТиповое действие
Первый — в тот же деньОткрытый служебный адрес, действующий доступ уволившегося, выгрузка базы в личной почте, работающий ключ подрядчика после сдачиДо конца рабочего дняЗакрыть доступ или адрес, перевыпустить ключ, зафиксировать в протоколе время и исполнителя
Второй — в течение неделиТестовые и демонстрационные записи, лишние роли, отсутствие журнала, копия без проверки восстановления5 рабочих днейОтключить лишнее, включить журнал, провести первую проверку восстановления в отдельном контуре
Третий — в план на кварталНеописанные интеграции, отсутствие перечня ключей, пересылка отчётов на общий ящик отдела, роли, выданные шире, чем нужноДо следующей проверкиСоставить перечень, переписать роли, поставить владельца у каждой интеграции

Отдельная категория — то, что выглядит как находка, но ею не является. Ложных тревог обычно больше, чем настоящих проблем, и отличать их учит один вопрос: регулярно ли это происходит и совпадает ли с расписанием.

  • Входы в три часа ночи каждый день. Почти всегда это служебная учётная запись обмена, работающая по расписанию. Проверяется по имени записи и по регулярности: человек не заходит в систему ровно в 03:15 сорок дней подряд.
  • Всплеск чтения карточек в первый рабочий день месяца. Руководитель собирает отчёт. Норма для роли считается по медиане за 30 дней, и именно поэтому порог задаётся не абсолютным числом, а кратностью — подробный список порогов разобран отдельно.
  • Обращения с незнакомых адресов к сайту. Обычно это мониторинг доступности, поисковые роботы или сервис проверки сертификата. Настоящая находка выглядит иначе: обращение к служебному адресу, о существовании которого снаружи знать неоткуда.
  • Массовая выгрузка бухгалтером в конце квартала. Сверка, а не увод. Закрывается одним вопросом «что вы выгружали и зачем», и ответ на него занимает минуту. Смысл журнала не в том, чтобы подозревать, а в том, чтобы вопрос вообще можно было задать предметно.

Протокол на одну страницу

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

  1. 1Дата проверки и кто проводил. Две строки, но без них через полгода непонятно, к какому состоянию системы относятся цифры.
  2. 2Восемь строк по числу проверок, в каждой — значение, а не отметка «ок»: не «учётные записи в порядке», а «активных 47, из них без соответствия сотруднику или процессу — 3».
  3. 3Находки с уровнем срочности, ответственным по фамилии и датой устранения. Пустая графа даты означает, что находка открыта, а не что про неё забыли.
  4. 4Что изменилось по сравнению с прошлой проверкой. Одна строка на каждое изменившееся число. Именно эта часть делает протокол полезным начиная со второго прохода.
  5. 5Что решили не чинить и почему. Осознанно отложенная находка — нормальная запись, и она честнее, чем её отсутствие: через квартал будет видно, что решение принималось, а не терялось.
разбор экранаproverki-bezopasnosti-posle-sdachi--02
Нарисованный протокол проверки на одну страницу: восемь строк, находки и сравнение с прошлой

Нарисованный (не скриншот) бланк протокола на одну страницу. Шапка: «Проверка после запуска», поля «дата», «кто проводил», «система». Основная часть — таблица из восьми пронумерованных строк с колонками «что проверяли», «значение», «было в прошлый раз», «уровень». В нескольких строках вписаны значения: «активных записей — 47, было 34», «выгрузка под рядовым пользователем — не проходит», «служебных адресов без авторизации — 1, было 0». Внизу блок «находки»: три строки с колонками «уровень», «ответственный», «срок», у одной строки графа даты пустая и подписана «открыта». В самом низу строка «решили не чинить и почему». Чертёжный стиль, подписи по-русски.

Одна страница, восемь чисел и графа «изменилось с прошлого раза» — этого достаточно

Сколько это стоит и когда возвращаться к подрядчику

Ставки в расчёте: руководитель подразделения — 1 800 ₽/час, администратор — 1 200 ₽/час. Проверка проводится четыре раза в год: через месяц после запуска и дальше раз в квартал.

Один проход восьми проверок и год наблюдения
Восемь проверок и запись протокола: 2 ч руководителя × 1 800 ₽3 600 ₽
Выгрузка списков учётных записей, ключей и правил почты: 1 ч администратора × 1 200 ₽1 200 ₽
Один проход4 800 ₽
Четыре прохода в год19 200 ₽
Итого19 200 ₽ в год — 6,5 % от прямых расходов на разбор одного инцидента через забытую учётную запись

Сравнивать эти деньги имеет смысл не с абстрактным риском, а с посчитанным по строкам сценарием. Модельный инцидент через забытую учётную запись подрядчика — расследование, смена паролей в девяти системах, простой продаж и склада, юрист и восстановление данных — обходится в 297 600 ₽ прямых расходов; полный расчёт приведён в опорном материале про доступы подрядчику при внедрении.

графикproverki-bezopasnosti-posle-sdachi--03
Год наблюдения за 19 200 рублей против 297 600 рублей на разбор одного инцидента

Столбчатая диаграмма из двух столбцов с подписанными значениями. Левый, очень низкий: «Четыре проверки в год — 19 200 ₽», разбитый на четыре равных сегмента по 4 800 ₽ с подписями «через месяц», «квартал», «полгода», «девять месяцев». Правый, высокий: «Модельный инцидент — 297 600 ₽» с сегментами расследование, смена паролей в девяти системах, простой продаж и склада, юрист, восстановление данных. Между столбцами подпись «6,5 %». Ось — рубли. Чертёжный стиль, подписи по-русски.

Четыре прохода в год стоят 6,5 % от разбора одного инцидента
Как сформулировать возврат по гарантии

Часть находок — не изменение объёма работ, а несоответствие сданной системы тому, что было в договоре: открытый служебный адрес, отсутствие разграничения прав, действующий ключ подрядчика после подписания акта. Рабочая формулировка: «Проверка после запуска показала, что служебный адрес выгрузки отвечает без авторизации. Это несоответствие условию договора о разграничении доступа, а не новое требование. Просим устранить в рамках гарантийного срока до <дата>». Такое письмо закрывается в разы чаще, чем просьба «посмотрите, пожалуйста, у нас тут вопрос», — и то, что входит в передачу и в гарантию, полезно сверить со страницей гарантий до разговора.

Когда проверку можно не проводить

Два часа руководителя — недорого, но не всегда оправданно. Есть случаи, когда проверка не даёт находок по устройству ситуации.

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

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

Проверка без прошлого протокола отвечает на вопрос «что есть». Проверка с протоколом отвечает на вопрос «что появилось» — а опасно обычно именно появившееся.