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

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

Ниже — форма из 15 пунктов с дословными формулировками и признаком выполнения к каждому, правила передачи секретов, разбор поручения обработки персональных данных, порядок работ на тестовом контуре и расчёт стоимости всего порядка. Сквозной пример один на всю статью: оптово-розничная компания, 38 человек, восьминедельный проект на 1 100 000 ₽, подрядчик из трёх человек — инженер, аналитик и тестировщик. Системы: 1С:УНФ, RetailCRM, телефония Mango Office, почтовый домен и сайт. Ставки модельные: инженер подрядчика 3 000 ₽/час, руководитель подразделения 1 800 ₽/час, системный администратор 1 200 ₽/час, штатный юрист 1 400 ₽/час.

Пятнадцать пунктов формы

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

Формулировка пунктаПризнак выполнения
1Каждый сотрудник подрядчика работает под собственной именной учётной записью; записи вида integrator, podryadchik, test не создаютсяСписок из трёх записей с фамилиями во всех системах
2Учётные записи заведены нами; подрядчик приглашён в наши системы, а не владеет имиВ списке владельцев и администраторов только наши сотрудники
3У каждой записи проставлен срок действия: дата окончания работ плюс 5 рабочих днейДата в карточке каждой из трёх записей
4Права выданы по ролям под конкретные задачи; роль администратора не выдана никому без письменной заявки с обоснованиемТаблица «система — роль — задача» на одну страницу
5Право на выгрузку клиентской базы целиком снято у всех записей подрядчикаПопытка экспорта под записью подрядчика завершается отказом
6Разделы заработной платы, закупочных цен и договоров с поставщиками недоступныВход под записью подрядчика: три раздела не открываются
7Пароли и ключи переданы через менеджер паролей ссылкой с ограниченным сроком; переписка и почта для этого не использовалисьСсылка истекла, в переписке паролей нет
8Каждый секрет выдан персонально, а не команде общим сообщениемЖурнал выдачи: секрет, кому, когда, до какой даты
9Для интеграций выпущены отдельные ключи подрядчика, не совпадающие с боевыми ключами наших обменовСписок ключей с назначением и владельцем
10Журнал действий включён во всех системах и открывается нами без обращения к подрядчикуОткрыть журнал и увидеть вчерашние действия по трём записям
11Назначен наш сотрудник, который раз в неделю просматривает события по записям подрядчикаФамилия в форме и отметки о восьми просмотрах
12Работы, не требующие настоящих данных клиентов, выполняются на тестовом контуре с обезличенной копиейПеречень работ с пометкой «боевой» или «тестовый»
13Подписано поручение обработки персональных данных с перечнем, целью, сроком и мерами защитыПодписанное приложение к договору
14Дата отзыва доступов назначена заранее и записана в договоре условием подписания актаПункт договора с датой
15После завершения проведена проверка: вход под записями подрядчика невозможен, ключи перевыпущены, обмены работаютПротокол проверки на одну страницу с отметками времени

Пункты 1–3 закрывают половину всех проблем и занимают полтора часа. Пункты 4–6 требуют разговора с подрядчиком о том, что ему действительно нужно: подробная матрица «что просят и чего достаточно» по десяти системам разобрана в опорном материале про доступы подрядчику при внедрении — здесь она свёрнута в три строки формы, чтобы документ оставался рабочим.

схема процессаchek-list-bezopasnosti-peredachi-dostupov--01
Схема шести групп формы: от заявки на доступ до протокола отзыва

Горизонтальная схема из шести последовательных блоков с номерами пунктов внутри. Блок 1 «Учётные записи — пункты 1–3»: три именные карточки с датами. Блок 2 «Объём прав — 4–6»: таблица ролей с двумя перечёркнутыми строками «экспорт базы» и «закупочные цены». Блок 3 «Передача секретов — 7–9»: значок ссылки с песочными часами и подписью «срок действия». Блок 4 «Журналирование — 10–11»: разлинованный лист с отметками по неделям. Блок 5 «Данные и 152-ФЗ — 12–13»: два контура «боевой» и «тестовый», между ними документ «поручение обработки». Блок 6 «Срок и отзыв — 14–15»: календарная отметка и протокол. Сквозная стрелка снизу подписана «первый пароль выдаётся только после блока 2». Чертёжный стиль, подписи по-русски.

Шесть групп идут по порядку: сначала кто и на сколько, потом что можно, и только потом пароль

Именные записи: почему без них журнал бесполезен

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

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

Как передавать пароли и ключи

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

СпособГодитсяПочему
Менеджер паролей: ссылка с ограниченным сроком и числом открытийДаСекрет исчезает сам, видно, кто и когда открыл
Приглашение в систему на почту подрядчика без пароляДаПароль задаёт сам человек, вы его не видите и не храните
Ключ интеграции, выпущенный отдельно под подрядчикаДаОтзывается независимо от остальных, не ломает боевые обмены
Сообщение в мессенджере, в том числе удалённоеНетКопии остаются в истории и резервных копиях с обеих сторон
Письмо на почту, файл в облаке, таблица с паролямиНетЖивёт вечно, попадает в поиск и в выгрузки
Диктовка по телефонуНетЗаписывается на стороне телефонии и попадает в расшифровки

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

Смена секретов после проекта обязательна независимо от способа

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

Персональные данные: когда нужно поручение обработки

Что это значитПоручение обработки персональных данных

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

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

  1. 1Перечень данных. Не «персональные данные клиентов», а список: фамилия и имя, телефон, адрес доставки, история заказов, записи разговоров. Общая формулировка не защищает ни одну из сторон.
  2. 2Цель и действия. Зачем подрядчик их обрабатывает и что именно делает: просмотр, изменение, перенос, обезличивание. Выгрузка целиком должна быть либо явно разрешена под конкретную работу, либо явно запрещена.
  3. 3Срок. Обычно совпадает со сроком договора плюс период гарантии. По истечении — обязанность удалить копии и подтвердить это актом.
  4. 4Меры защиты. Именные записи, отсутствие копий на личных устройствах, работа на тестовом контуре там, где это возможно. Формулировки берутся из вашей политики, а не сочиняются подрядчиком.
  5. 5Запрет на третьих лиц. Подрядчик не привлекает субподрядчиков и не использует внешние сервисы для обработки ваших данных без письменного согласия. Пункт особенно важен, когда в проекте участвует облачная языковая модель: тогда трансграничная передача становится отдельным вопросом.

Тестовый контур вместо боевого

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

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

Обезличенная копия делается один раз и стоит 4–8 часов работы: имена и телефоны заменяются на заглушки того же формата, суммы и даты остаются — они нужны для проверки логики. Дальше копия обновляется по мере надобности. Как устроен сам порядок переноса и что записывается в план, разобрано в материале про план миграции данных.

Сколько стоит весь порядок

Сумма ниже покрывает весь восьминедельный проект: заполнение формы, заведение записей, передачу секретов, поручение обработки, еженедельный просмотр событий и отзыв с проверкой.

Порядок с доступами на восьминедельный проект
Заполнение формы и согласование объёма прав по трём системам: руководитель проекта, 1,5 часа × 1 800 ₽2 700 ₽
Заведение трёх именных записей с ролями и сроком, снятие права экспорта: администратор, 2 часа × 1 200 ₽2 400 ₽
Выпуск отдельных ключей интеграций и передача через менеджер паролей: администратор, 1 час × 1 200 ₽1 200 ₽
Поручение обработки персональных данных приложением к договору: юрист, 1,5 часа × 1 400 ₽2 100 ₽
Еженедельный просмотр событий: 8 недель × 15 мин = 2 часа × 1 200 ₽2 400 ₽
Отзыв доступов и протокол проверки: администратор 1 час × 1 200 ₽ и руководитель 0,5 часа × 1 800 ₽2 100 ₽
Итого9,5 часа и 12 900 ₽ на весь проект — около 1 % бюджета в 1 100 000 ₽

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

этапыchek-list-bezopasnosti-peredachi-dostupov--02
Восемь недель проекта: форма до первого пароля, восемь просмотров, отзыв и пять дней хвостов

Горизонтальная лента на восемь недель. Слева до нулевой отметки блок «День −1: форма на 15 пунктов, 2 700 ₽» с пометкой «первый пароль не выдан». На нулевой отметке «День 0: три именные записи, ключи, поручение обработки — 5 700 ₽». По ленте восемь равных засечек с подписью «просмотр событий, 15 мин». В конце ленты блок «День закрытия: отзыв, перевыпуск ключей, протокол — 2 100 ₽» и хвост в пять рабочих дней со штриховкой и подписью «срок действия записей истекает сам». Снизу итоговая плашка «9,5 часа, 12 900 ₽ — 1 % бюджета проекта». Чертёжный стиль, подписи по-русски.

Форма закрывается до выдачи первого пароля, отзыв назначается в тот же день, что и дата акта

Отзыв в тот же день: семь действий

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

  1. 1Отключить три именные учётные записи во всех системах, не удаляя их: удалённая запись уносит с собой историю действий.
  2. 2Перевыпустить ключи интеграций, выданные подрядчику, и убедиться, что обмены не встали — проверка занимает десять минут.
  3. 3Сменить пароли служебных записей, к которым подрядчик имел доступ, даже если пользовался ими один раз.
  4. 4Отозвать доступы к внешним сервисам: почтовому домену, хостингу, панели телефонии, репозиторию.
  5. 5Забрать права владельца там, где они успели уехать: домен, аккаунт в платёжном сервисе, кабинет провайдера.
  6. 6Подписать акт передачи доступов и акт об уничтожении копий данных — оба короткие, оба нужны.
  7. 7Провести проверку: попытаться войти под каждой отозванной записью и записать результат в протокол на одну страницу.

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

Когда пятнадцати пунктов слишком много

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

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

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