Как безопасно передать доступы ИТ-подрядчику

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

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

Что вообще придётся передать

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

Обычно в него входит:

• административный доступ к серверам и к системе виртуализации;
• учётные записи в 1С с правами администратора;
• панель управления доменом и почтой;
• доступ к роутеру, межсетевому экрану и Wi-Fi;
• личный кабинет провайдера и хостинга;
• учётные записи в облачных сервисах, которыми пользуется компания;
• доступ к системе резервного копирования;
• права локального администратора на компьютерах сотрудников.

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

Частая находка на старте

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

Правило первое: отдельные учётные записи, а не ваши личные

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

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

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

Правило второе: ровно столько прав, сколько нужно

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

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

Правило третье: пароли не живут в переписке

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

Как правильно:

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

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

Правило четвёртое: у каждого изменения должно быть основание

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

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

Поэтому у каждой операции с доступами должно быть документальное основание от вашей компании. Именно так это устроено у нас.

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

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

Почему это может показаться неудобным

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

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

Правило пятое: договоритесь о расставании заранее

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

Что стоит проговорить и зафиксировать в договоре:

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

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

Короткий чек-лист

Перед тем как передавать первый пароль:

1. Составьте полный список доступов, которые есть в компании.
2. Заведите подрядчику отдельные учётные записи — по одной на специалиста.
3. Выдайте права под конкретные задачи, а не «на всякий случай».
4. Передайте пароли через защищённый канал, а не в переписке.
5. Спросите, где подрядчик их хранит и кто внутри его компании имеет к ним доступ.
6. Узнайте, по какому основанию подрядчик меняет доступы, и убедитесь, что устного звонка недостаточно.
7. Зафиксируйте в договоре конфиденциальность, порядок возврата доступов и передачу документации.
8. Через месяц работы попросите список активных учётных записей подрядчика и сверьте его.

Если сейчас в доступах беспорядок

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

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

Если хотите посмотреть, как обстоят дела у вас, — напишите или позвоните нам. Начнём с картины, а не с обязательств.