Почти всё, что подрядчик просит в начале проекта одной фразой «дайте полный доступ», закрывается ограниченной ролью и именной учётной записью с датой окончания. Настройка такой роли занимает 20–40 минут работы вашего администратора — это единственная причина, по которой просят полные права: так быстрее для обеих сторон. А отзыв доступов после сдачи — не обещание в конце письма, а процедура на 40 минут из двенадцати пунктов, где у каждого есть исполнитель и отметка о выполнении.
Инцидент в проектах автоматизации выглядит скучно и почти никогда не похож на взлом. Учётная запись, заведённая инженеру подрядчика на второй неделе проекта, продолжает работать через год после подписания акта. Ключ к базе лежит в переписке, потому что так было быстрее в момент отладки. Тестовый контур поднят на копии боевой базы и доступен из интернета, потому что «это же временно». Ни одно из этих трёх событий не требует злого умысла — достаточно того, что никто не отвечал за закрытие.
Дальше — разбор доступа как управляемого объекта с жизненным циклом: шесть этапов, матрица по десяти системам «что просят и чего достаточно», шаблон заявки, который сам становится журналом, чек-лист отзыва с минутами и расчёт в рублях. Модельная компания для всех примеров одна: оптово-производственная компания на 60 человек, проект внедрения CRM с интеграцией в 1С:УТ, подрядчик — три инженера, срок работ 10 недель. Ставки в расчётах: системный администратор 1 200 ₽/ч, сотрудник 900 ₽/ч, внешний инженер по расследованию инцидентов 3 500 ₽/ч.
Шесть этапов, которые превращают доступ в управляемый объект
Доступ — не разовое действие «завели пользователя», а объект со сроком жизни. Пока он живёт как одолжение в переписке, у него нет ни владельца, ни даты окончания, ни следа. Шесть этапов ниже занимают в сумме меньше часа на всю проектную команду и превращают доступ в то, что можно проверить.
- 11. Заявка с обоснованием
Не «нужен доступ к 1С», а «нужна роль на чтение справочников номенклатуры и контрагентов и на запись документов „Реализация“ в тестовой базе до 30 ноября, чтобы собрать обмен с CRM». Обоснование — не бюрократия: именно на этом шаге выясняется, что для задачи хватает чтения, а запись нужна только в тестовом контуре.
- 22. Именная учётная запись
Заводится на конкретного человека подрядчика с его фамилией, а не одна на команду. Логин вида ivanov_integrator, а не integrator. Если инженеров трое — учётных записей тоже трое, даже если они работают по очереди.
- 33. Срок действия
Дата окончания ставится в самой системе там, где это поддерживается: 1С, большинство CRM, панели хостинга, SSH-ключи с ограничением. Где не поддерживается — задача в календаре администратора на дату окончания работ. Срок ставится всегда, даже когда проект «точно закончится в срок».
- 44. Наблюдение
Пока подрядчик работает, раз в неделю просматриваются события по его учётным записям: выгрузки, входы в нерабочее время, изменения прав. Это 15 минут и восемь позиций для проверки — конкретный список ниже.
- 55. Продление
Проект сдвинулся — срок продлевается той же заявкой с новой датой, а не молчаливым бездействием. Продление на месяц с записью в журнале и вечный доступ по недосмотру внешне неразличимы, а по последствиям отличаются полностью.
- 66. Отзыв с фиксацией
В день подписания акта проходится чек-лист из двенадцати пунктов, каждый отмечается как выполненный, факт передачи и отзыва оформляется актом. Именно здесь заканчивается проект с точки зрения безопасности — не в момент, когда подрядчик перестал отвечать в чате.
Заявку кто-то напишет, учётную запись кто-то заведёт, наблюдение хотя бы иногда случается. А вот срок действия не ставят почти никогда — «мы же не знаем, когда закончим», — и ровно поэтому отзыв превращается из процедуры в воспоминание. Дата окончания в системе делает шестой этап автоматическим даже там, где о нём забыли.
Горизонтальная схема из шести блоков со стрелками: «Заявка с обоснованием» → «Именная учётная запись» → «Срок действия» → «Наблюдение» → «Продление» → «Отзыв с фиксацией». Блоки «Срок действия» и «Отзыв с фиксацией» выделены и подписаны «пропускают чаще всего». От блока «Продление» обратная стрелка к «Наблюдению» с подписью «новая дата, та же заявка». Под лентой подпись: «весь цикл — меньше часа работы администратора на проект». Чертёжный стиль, подписи по-русски.
Именная учётная запись: почему общий «integrator» ломает всё сразу
Общая учётная запись на команду подрядчика кажется удобной и экономит десять минут при заведении. Расплата наступает в двух точках, и обе неприятные.
- Расследование становится невозможным. В журнале написано, что документ распровёл пользователь integrator. Кто из трёх инженеров это сделал, был ли это вообще инженер подрядчика или кто-то, кому пароль переслали в чате, — установить нечем. Журнал есть, а следа нет.
- Отзыв превращается в выбор из двух плохих вариантов. Выключить общую учётку — остановить работу всей команды разом, включая тех, кто ещё нужен. Не выключать — оставить работающий вход, о котором через полгода никто не вспомнит.
- Ответственность размывается юридически. В поручении обработки персональных данных перечисляются лица, допущенные к данным. Строка «учётная запись подрядчика» этому требованию не соответствует, и при проверке отвечать за это будете вы как оператор, а не подрядчик.
- Пароль от общей учётки живёт вечно. Его знают все, кто когда-либо участвовал в проекте, включая уволившихся из компании подрядчика. Менять его никто не станет — это сломает работу остальным.
Учётная запись, закреплённая за одним конкретным человеком, с его фамилией в логине и с указанием, от какой организации он работает. Она не передаётся коллеге «на время», не используется для интеграций и не переживает человека: сотрудник ушёл из проекта — запись отключается в тот же день. Для интеграций заводится отдельный служебный пользователь, тоже именной, но привязанный к системе, а не к человеку.
Отдельно стоит развести две сущности, которые часто заводят одной. Человек-инженер и программная интеграция — это разные учётные записи с разными правами. Человеку нужен вход в интерфейс и права на настройку. Интеграции нужен только набор методов обмена и, как правило, вообще не нужен вход в интерфейс. Когда обе задачи закрыты одной учёткой, при отзыве доступа у человека ломается интеграция — и это единственная причина, по которой отзыв откладывают «до понедельника», а потом навсегда.
Единственный внятный аргумент в пользу общей учётки — лицензии. В 1С лицензии считаются по числу одновременных подключений, и три инженера подрядчика формально занимают три места. На практике это редко становится проблемой: работы идут в тестовой базе, для которой обычно достаточно имеющихся лицензий, а в боевой инженер бывает эпизодически. Если места действительно в дефиците, покупается один клиентский ключ на время проекта — это единичные тысячи рублей против невозможности разобрать инцидент. Экономить на этом так же разумно, как выдать всей смене один пропуск на проходную.
Сравнение в две колонки. Слева «Общая учётная запись integrator»: строки журнала одинаковые — «integrator: выгрузка 8 000 контактов», «integrator: изменение прав», под ними подпись «кто именно — неизвестно»; внизу пометка «отзыв = остановка всей команды». Справа «Три именных записи»: строки журнала «ivanov_integrator: выгрузка 8 000 контактов», «petrov_integrator: изменение прав», «sidorov_integrator: вход в 22:40», внизу пометка «отзыв = по одному, по мере выхода из проекта». Чертёжный стиль, подписи по-русски.
Матрица: что просят и чего на самом деле достаточно
Эта таблица — рабочий инструмент разговора с подрядчиком на старте. Слева то, что обычно звучит в первом письме, в середине то, чего действительно хватает для работы, справа — техническое средство, которым это ограничивается. Строки покрывают десять систем, к которым в проектах автоматизации просят доступ чаще всего.
| Система | Что обычно просят | Чего достаточно для работы | Чем ограничивается технически |
|---|---|---|---|
| 1С (УТ, Бухгалтерия, УНФ) | Полные права, «чтобы ничего не мешало» | Роль на нужные справочники и виды документов в тестовой базе; в боевой — чтение и запись без проведения | Профиль групп доступа, роль в конфигураторе, ограничение по организации и складу |
| CRM (Битрикс24, amoCRM) | Администратор портала | Роль интегратора: настройки полей, воронок и вебхуков без просмотра всей базы сделок | Права по воронкам, запрет экспорта, отдельный вебхук вместо ключа администратора |
| Телефония (Mango Office, UIS, Novofon) | Кабинет целиком, вместе с записями разговоров | Ключ API и права на настройку сценариев; записи — только по конкретным звонкам для отладки | Ключ с ограниченным набором методов, фильтр по адресу, роль без доступа к тарифам и оплате |
| Корпоративная почта | Ящик руководителя, «чтобы видеть переписку по заявкам» | Служебный ящик проекта и отдельный доступ на отправку уведомлений | Отдельный ящик, пароль приложения вместо основного, запрет делегирования |
| Сайт и админка CMS | Права суперадминистратора на боевом сайте | Роль разработчика на тестовой копии; на боевом — выкладка через согласованную процедуру | Отдельный аккаунт, копия сайта на закрытом поддомене, запрет индексации |
| Хостинг и панель сервера | Root по SSH и вход в панель | Отдельный пользователь с правами на нужные сервисы, вход по ключу | Ключ вместо пароля, повышение прав по списку команд, журнал этих команд |
| Регистратор домена и DNS | Доступ «на всякий случай, вдруг понадобится запись» | Ничего. Записи вносит ваш администратор по письменной заявке | Не выдаётся вообще; изменение записи — заявка по почте с фиксацией |
| Платёжный сервис, эквайринг, банк-клиент | Боевой ключ, «иначе не проверить оплату» | Только тестовая среда платёжного сервиса; боевой ключ вводит ваш сотрудник | Тестовые ключи у подрядчика, боевой — из вашего хранилища секретов, мимо подрядчика |
| ЭДО (Диадок, Saby, 1С-ЭДО) | Сертификат подписи, «чтобы протестировать обмен» | Тестовый контур оператора и учётная запись без права подписи | Роль без подписи; КЭП и машиночитаемая доверенность не передаются никому |
| База данных (PostgreSQL и другие) | Пароль от боевой базы | Обезличенная копия; к боевой — чтение ограниченного набора таблиц на срок отладки | Отдельная роль в СУБД, доступ только через туннель, порт закрыт из интернета |
Разговор по этой таблице занимает полчаса и почти всегда идёт одинаково. Подрядчик присылает список из шести-восьми пунктов со словом «полный» в четырёх из них. Вы отвечаете тем же списком, но с колонкой «под какую задачу и до какой даты». В ответном письме половина пунктов исчезает сама — они были в списке по привычке, из шаблона прошлого проекта. Оставшиеся уточняются до конкретных ролей за один созвон. Это не переговоры и не проверка на прочность: инженеру всё равно, под какой ролью работать, если она позволяет делать работу, и почти никогда не всё равно, ждать ли выдачи доступа три дня.
Из десяти строк права администратора не обоснованы ни в одной. В двух строках — регистратор домена и боевой платёжный контур — подрядчику не выдаётся вообще ничего, и это не признак недоверия: доступ к домену нужен на пять минут раз в проект, а его потеря стоит всего бизнеса разом. Практическое правило разговора: если запрос звучит как «дайте полный доступ», уточните задачу и срок. В девяти случаях из десяти после уточнения выясняется, что нужна одна роль в тестовом контуре на три недели.
Карта из десяти узлов вокруг центрального блока «Проект внедрения»: 1С, CRM, телефония, почта, сайт, хостинг, домен и DNS, платёжный сервис и банк, ЭДО, база данных. Узлы окрашены в три уровня: «чтение», «ограниченная запись в тестовом контуре», «не выдаётся». Узлы «Домен и DNS» и «Платёжный сервис и банк» помечены как «не выдаётся» и обведены отдельно с подписью «красная зона». На связях подписи, что именно передаётся: роль, ключ API, вебхук, туннель. Чертёжный стиль, подписи по-русски.
Красная зона: четыре доступа, которые не выдают никогда
Есть четыре позиции, по которым ответ не зависит ни от квалификации подрядчика, ни от длительности отношений с ним. Не потому, что подрядчик под подозрением, а потому, что цена ошибки в этих четырёх точках несоразмерна экономии времени.
- 1Регистратор домена и управление DNS. Потеря контроля над доменом — это одновременно потеря сайта, корпоративной почты и всех сервисов, привязанных к домену, а восстановление идёт через поддержку регистратора неделями. Изменение DNS-записи занимает у вашего администратора три минуты по письменной заявке, и это единственная нужная схема.
- 2Банк-клиент, боевой платёжный сервис, кабинет оператора связи с правом менять тариф. Всё, где есть кнопка «списать деньги», остаётся у сотрудников компании. Подрядчику для интеграции хватает тестовой среды платёжного сервиса; боевой ключ вводит ваш сотрудник — и вводит его в хранилище секретов, а не пересылает.
- 3Право удаления и распроведения в боевой базе. Это единственный класс операций, где ошибка не откатывается штатными средствами: распровели документы задним числом — поехали остатки, взаиморасчёты и отчётность. Подрядчику для отладки нужен тестовый контур; в боевой базе он работает без прав на удаление и проведение, а нужные действия делает ваш сотрудник.
- 4Боевая база в качестве тестового контура. Это самая частая уступка и самая дорогая: копия боевой базы с реальными телефонами клиентов уезжает на ноутбук инженера, живёт там после проекта и не попадает ни в один чек-лист. Тестовый контур поднимается на обезличенных данных — способы обезличивания и их трудоёмкость мы разбираем в отдельном материале раздела.
Отдельный вопрос — что делать, когда доступ в боевой контур всё-таки нужен по существу: ошибка воспроизводится только на живых данных, или требуется разово перепровести партию документов после сбоя обмена. Здесь работает сопровождаемый доступ: инженер подрядчика и ваш сотрудник открывают общий экран, инженер диктует действия, выполняет их ваш сотрудник под своей учётной записью. Времени уходит вдвое больше, зато в журнале остаётся ваш пользователь, а не чужой, и любое действие можно объяснить. Для разовых задач такой формат почти всегда дешевле, чем заводить временную учётную запись с правами на изменение боевых данных и потом её сопровождать.
Квалифицированная электронная подпись руководителя и машиночитаемая доверенность — не технический доступ, а юридическое действие от имени компании. Просьба «дайте флешку с подписью, мы протестируем обмен с ЭДО» решается иначе: у операторов ЭДО есть тестовые контуры, в которых подпись не нужна. Если подрядчик настаивает, что без боевой КЭП обмен не проверить, это повод задать вопрос о его опыте с конкретным оператором, а не повод везти флешку.
Заявка на доступ: семь полей, которые заодно становятся журналом
Заявка на доступ не требует системы заявок, согласований и отдельного сотрудника. Достаточно таблицы на общем диске или письма по шаблону — важна не форма, а то, что семь полей заполнены до выдачи, а не после инцидента. Эта же таблица потом работает журналом: из неё собирается чек-лист отзыва, и по ней проверяется, что ничего не забыли.
- 1Кто. Фамилия, имя, организация, роль в проекте. Не «команда подрядчика», а конкретный человек — иначе всё дальнейшее теряет смысл.
- 2К чему. Система и объём данных: какая база, какой контур — тестовый или боевой, какие справочники и документы нужны.
- 3Какой уровень права. Три значения: чтение, изменение, администрирование. Третье требует отдельного письменного обоснования и почти никогда его не получает.
- 4Зачем. Задача проекта, для которой доступ нужен. Формулировка вида «для работ по проекту» не годится — она не позволяет ни проверить достаточность прав, ни понять, когда доступ перестал быть нужен.
- 5До какой даты. Конкретное число, а не «до конца проекта». Дата ставится в системе там, где это поддерживается, и в календаре администратора там, где нет.
- 6Кто согласовал с вашей стороны. Один человек с именем — обычно руководитель проекта со стороны заказчика. Это тот, кому зададут вопрос, если через полгода учётка окажется живой.
- 7Отметка об отзыве. Пустая колонка, которая заполняется в день закрытия: дата, кто отозвал, чем подтверждается. Пока она пустая, проект по этой системе не закрыт.
Заполненная строка выглядит так: «Иванов И. И., подрядчик „Интегратор“, инженер. 1С:УТ, тестовая база. Изменение. Сборка обмена номенклатурой и заказами с CRM. До 30.11.2026. Согласовал Петров П. П., руководитель проекта. Отозвано 02.12.2026, Сидоров С. С., скриншот отключённого пользователя». Одна строка, минута заполнения — и вся история доступа на месте.
Нарисованная (не скриншот) карточка формы с семью полями сверху вниз: «Кто: Иванов И. И., подрядчик, инженер», «К чему: 1С:УТ, тестовая база», «Уровень права: изменение», «Зачем: обмен номенклатурой и заказами с CRM», «До какой даты: 30.11.2026», «Согласовал: Петров П. П.», «Отметка об отзыве: —». Последнее поле выделено пунктиром и подписано «пока пусто — проект по этой системе не закрыт». Справа сбоку узкая колонка «эта же таблица = журнал». Чертёжный стиль, подписи по-русски.
Наблюдение: восемь событий, на которые смотрят, пока идёт проект
Наблюдение нужно не для контроля за подрядчиком, а для того, чтобы отклонение стало заметно в течение недели, а не через год. Смотреть журналы ежедневно бессмысленно: это не работа руководителя и не работа администратора. Реалистичный формат — 15 минут раз в неделю по фиксированному списку из восьми пунктов.
- Массовая выгрузка. Экспорт больше сотни записей контрагентов, контактов или номенклатуры разом. У инженера бывают законные причины, но каждая такая выгрузка должна иметь объяснение в переписке.
- Входы в нерабочее время и в выходные. Не запрет, а повод спросить: у распределённых команд это норма, но всплеск ночных входов на неделе сдачи — уже сигнал.
- Вход с нового адреса или из другой страны. Особенно если раньше все входы шли из одного диапазона. Здесь чаще выясняется не злой умысел, а то, что подрядчик передал доступ субподрядчику, о котором вы не знали.
- Создание новых учётных записей. Инженер завёл ещё одного пользователя для «удобства тестирования» — типичная история, из которой рождается забытый доступ, не попадающий ни в один чек-лист.
- Изменение прав существующих записей, особенно повышение. Учётка, которая была на чтение, а стала администраторской, — самое частое тихое расширение доступа в проекте.
- Отключение или очистка журнала. Единственный пункт списка, который сам по себе означает разбор в тот же день, а не на недельной проверке.
- Обращения к боевой базе с тестового контура. Признак того, что тестовый контур подключён не туда, куда договаривались, — и что часть отладки идёт на живых данных.
- Новые интеграционные ключи и вебхуки. Каждый выпущенный ключ — это дополнительный вход в систему, который переживёт отзыв учётной записи человека, если его не внести в тот же журнал.
Полный разбор того, какие события в журналах требуют немедленной реакции, а какие терпят до недельной проверки, — тема отдельного материала этого раздела. Здесь достаточно одного правила: список наблюдаемых событий составляется до начала работ и не меняется в процессе, иначе он превращается в объяснение уже случившегося.
Есть ещё один поворот, который наблюдение вскрывает чаще всего. Проект длится 10 недель, за это время у подрядчика может смениться состав команды: один инженер ушёл из компании, вместо него пришёл другой. Со стороны заказчика это выглядит как ничего — учётные записи продолжают работать, задачи закрываются. Со стороны безопасности это означает, что доступ в вашу 1С имеет человек, которого вы не согласовывали, а иногда и человек, который уже не работает у подрядчика, но пароль помнит. Поэтому список привлекаемых лиц пересматривается не в конце, а каждый раз, когда в переписке появляется новое имя. Вопрос «это новый человек в команде?» стоит десяти секунд и закрывает целый класс забытых входов.
Отзыв за 40 минут: двенадцать пунктов
Отзыв доступов воспринимается как большая неприятная работа и поэтому откладывается. На деле для модельной компании с десятью системами это сорок минут, если список выданных доступов готов — а он готов, если заявки велись по семи полям. Ниже — чек-лист с исполнителем и временем на каждый пункт.
| Пункт | Кто делает | Время |
|---|---|---|
| 1. Отключить именные учётные записи подрядчика в CRM | Администратор CRM | 3 мин |
| 2. Отключить пользователей в 1С и снять профили групп доступа | Администратор 1С | 5 мин |
| 3. Отозвать ключи API и вебхуки, выпущенные на время проекта | Системный администратор | 5 мин |
| 4. Закрыть SSH-доступ и удалить ключи подрядчика с сервера | Системный администратор | 4 мин |
| 5. Снять доступ к панели хостинга и проверить регистратора домена | Системный администратор | 3 мин |
| 6. Отключить служебный ящик и снять делегирование почты | Администратор почты | 3 мин |
| 7. Убрать подрядчика из телефонии и из доступа к записям разговоров | Администратор телефонии | 2 мин |
| 8. Снять доступ к ЭДО, проверить, что доверенность не выдавалась | Бухгалтерия | 4 мин |
| 9. Удалить тестовые копии с боевыми данными и запросить их удаление у подрядчика | Системный администратор | 3 мин |
| 10. Сменить общие пароли и секреты, которые подрядчик видел | Системный администратор | 4 мин |
| 11. Забрать репозиторий и учётные записи в сторонних сервисах проекта | Руководитель проекта | 2 мин |
| 12. Заполнить отметки об отзыве в журнале и подписать акт передачи доступов | Руководитель проекта | 2 мин |
Сумма — 40 минут. Единственное, что превращает эти сорок минут в двухнедельную переписку, — отсутствие списка выданных доступов. Поэтому шестой этап жизненного цикла не существует отдельно от первого: заявки ведутся не ради порядка в бумагах, а ради того, чтобы в день закрытия было понятно, что именно закрывать.
Пункты 3 и 10 — единственные, которые могут остановить работу. Смена ключа обмена CRM с 1С без предупреждения обрывает синхронизацию заказов, и обнаруживается это в понедельник утром на десятке потерянных заявок. Правильный порядок: выпустить новый ключ, прописать его в интеграции, убедиться, что обмен идёт, и только потом отозвать старый. Это добавляет к процедуре 20–30 минут и снимает главный аргумент против отзыва — «мы боимся что-нибудь сломать».
Горизонтальная лента длиной 40 минут с делениями по 5 минут. На ленте двенадцать отрезков в порядке чек-листа с подписями и временем: CRM 3 мин, 1С 5 мин, ключи API 5 мин, SSH 4 мин, хостинг и домен 3 мин, почта 3 мин, телефония 2 мин, ЭДО 4 мин, тестовые копии 3 мин, общие пароли 4 мин, репозиторий 2 мин, журнал и акт 2 мин. Под каждым отрезком — исполнитель. Отдельной пометкой над отрезками «ключи API» и «общие пароли»: «плюс окно 20–30 мин: сначала новый ключ, потом отзыв старого». Чертёжный стиль, подписи по-русски.
Деньги: 9 840 ₽ в год против 297 600 ₽ за один инцидент
Порядок с доступами — одна из немногих практик безопасности, которую можно посчитать целиком, без гипотез о вероятности атаки. Сначала стоимость самого порядка для модельной компании на 60 человек с одним проектом внедрения в год.
Теперь другая сторона. Модельный инцидент: через восемь месяцев после сдачи проекта с забытой учётной записи подрядчика выгружена клиентская база — 8 000 карточек с телефонами и историей заказов. Кто именно это сделал, установить не удаётся, потому что учётка была общей. Считаем прямые расходы, без гипотез об упущенной выгоде.
В расчёт сознательно не включён отток клиентов: он есть, но его величина зависит от отрасли и от того, как быстро база всплывёт у конкурента, а выдумывать процент оттока мы не будем. Не включены и возможные последствия по линии персональных данных: при утечке оператор обязан уведомить регулятор в сжатые сроки, и это отдельная история со своими издержками. Даже без этих двух статей соотношение получается тридцатикратным, а сама процедура занимает меньше рабочего дня в год.
Столбиковая диаграмма из двух столбцов в рублях. Левый низкий столбец «Процедура доступов, год — 9 840 ₽» с разбивкой на пять сегментов: заявки, наблюдение, сверка, отзыв, окно смены ключей. Правый высокий столбец «Один инцидент — 297 600 ₽» с разбивкой на пять сегментов с подписями: расследование 84 000 ₽, смена секретов 48 000 ₽, простой 86 400 ₽, юрист 60 000 ₽, восстановление 19 200 ₽. Между столбцами подпись «×30». Под диаграммой пометка: «отток клиентов в расчёт не включён». Чертёжный стиль, подписи по-русски.
Что зафиксировать письменно: договор, поручение, акт
Технические меры не отменяют бумаг, а бумаги не отменяют технических мер: без роли в системе обязанность в договоре остаётся текстом, а без договора техническая мера не даёт вам никаких прав требования. Нужны три документа, и все три короткие.
- 1Договор: обязанности по доступам отдельным разделом
Минимум четыре пункта: подрядчик работает только под именными учётными записями и не передаёт их третьим лицам; список привлекаемых лиц согласовывается письменно; копии данных не выносятся за пределы согласованного контура; в день подписания акта подрядчик содействует отзыву доступов и подтверждает уничтожение копий. Что ещё стоит держать в договоре на разработку, мы разбирали отдельно — там же о приёмке и о гарантийных обязательствах.
- 2Поручение обработки персональных данных
Нужно всегда, когда подрядчик видит телефоны, имена или записи разговоров ваших клиентов, — то есть почти всегда. В нём перечисляются данные, действия с ними, требования к защите и срок. Оператором остаётесь вы, поэтому формулировки в поручении должны совпадать с тем, что реально происходит в проекте. Отдельный материал журнала разбирает восемь пунктов такого поручения и типичные пустышки в них.
- 3Акт передачи доступов и уничтожения копий
Подписывается вместе с актом сдачи работ. Содержит две таблицы: что передано вам (учётные записи, ключи, репозиторий, документация по настройкам) и что отозвано и уничтожено на стороне подрядчика (учётные записи, тестовые копии, выгрузки). День подписания акта — единственный момент, когда подрядчик максимально мотивирован закрыть хвосты, и именно поэтому чек-лист проходится в этот день, а не через неделю.
Отдельно про гарантийный период. После сдачи проекта подрядчику обычно нужен доступ для исправления дефектов, и это законное требование. Правильная схема — не оставлять постоянный доступ «на гарантию», а выдавать его заново по той же заявке на срок конкретной задачи: два-три дня, потом отзыв. Так гарантия работает, а вечных учётных записей не появляется. На странице гарантий описано, какие дефекты мы чиним за свой счёт и в какие сроки — доступ под каждый такой разбор запрашивается отдельно.
Схема из трёх блоков вдоль линии проекта. Слева блок «Договор: раздел о доступах» с четырьмя пунктами (именные записи, согласование лиц, запрет выноса копий, содействие отзыву), привязан к отметке «старт». В центре блок «Поручение обработки ПД» с подписью «пока идут работы с данными клиентов», от него стрелка вниз к пометке «оператор — вы». Справа блок «Акт передачи доступов» с двумя колонками — «передано вам» и «отозвано и уничтожено», привязан к отметке «день подписания акта». Под линией отдельная короткая ветка «гарантия: доступ выдаётся заново на 2–3 дня». Чертёжный стиль, подписи по-русски.
Когда этот порядок избыточен
Мы не считаем, что описанное нужно всем и всегда. Есть три ситуации, где полная процедура создаёт трение без снижения риска, и лучше сознательно сделать проще, чем формально расписать порядок и не соблюдать его.
- Компания до 10 человек с двумя системами. Когда весь ландшафт — это CRM и бухгалтерия в облаке, а администратор совмещён с собственником, семь полей заявки избыточны. Работающий минимум: именные учётные записи, дата окончания в системе и одна страница в заметках со списком, кому что выдано. Это займёт полчаса за весь проект.
- Разовая задача на два дня без доступа к данным клиентов. Настроить шаблон документа, поправить вёрстку письма, собрать отчёт по обезличенной выгрузке — здесь достаточно выдать доступ к тестовому контуру и закрыть его в тот же день. Полный цикл из шести этапов тут дороже самой задачи.
- Подрядчик работает на своей инфраструктуре и к вашим системам не подключается. Так бывает, когда вы отдаёте данные выгрузкой и получаете результат файлом. Здесь предмет разговора не доступы, а поручение обработки и порядок уничтожения выгрузок — то есть только бумажная часть.
Во всех остальных случаях главный аргумент за процедуру не в безопасности, а в управляемости. Компания, которая знает, кому и что она выдала, может в любой момент за сорок минут вернуть себе полный контроль над системами — при смене подрядчика, при конфликте, при уходе ключевого сотрудника или просто потому, что закончился проект. Компания, которая этого не знает, вынуждена договариваться каждый раз заново — и обычно с тем, кто уже не заинтересован ей помогать.
Доступ, у которого нет владельца и даты окончания, не выдан — он потерян в момент выдачи.
