Экспертная статья с Артёмом Грачёвым, инженером бизнес-процессов компании «Первый Приятный Интегратор» (1PI.PRO)
«Блин, а мало ли...»
Примерно так часто начинается разговор о доступе интегратора к Битрикс24. В CRM лежит клиентская база, коммерческая информация, документы, задачи и внутренняя переписка. А человеку, с которым компания только начала работать, нужно зайти внутрь и что-то настроить.
Опасаться этого нормально. Ненормально — решать вопрос на доверии, пересылать пароль сотрудника в мессенджере и надеяться, что после проекта про доступ никто не забудет.
Мы поговорили с Артёмом Грачёвым, инженером бизнес-процессов 1PI.PRO, о том, как пригласить интегратора в Битрикс24 штатным способом, какие вопросы задать до начала работ и как сохранить контроль над порталом.
Артём, клиенты действительно часто боятся давать интегратору доступ?
Да, и это абсолютно нормальное опасение.
Клиент обычно не рассуждает терминами ролей и уровней доступа. Он спрашивает проще: «А вы там сможете что-нибудь изменить?», «Зачем вам вообще такие права?», «А если потом доступ останется?» или «Можно сделать так, чтобы вы ничего лишнего не видели?»
За этими вопросами стоит понятное желание сохранить контроль. В Битрикс24 хранится много чувствительной для бизнеса информации, поэтому клиент должен понимать, кто входит в систему, под какой учётной записью, зачем ему нужен доступ и когда этот доступ будет закрыт.
Какая ошибка здесь самая опасная?
Передать интегратору логин и пароль действующего сотрудника.
Такой вариант кажется быстрым: не нужно никого приглашать, настраивать роль и разбираться в интерфейсе. Но дальше начинается путаница. Интегратор работает под чужой учётной записью, и по истории действий уже сложно понять, кто именно внёс изменение — сотрудник или подрядчик.
Кроме того, пароль мог сохраниться в переписке, браузере или менеджере паролей. А если для входа потребуется код двухфакторной аутентификации, появляется ещё одна плохая идея — передать и его.
Логин, пароль и одноразовые коды сотрудника нельзя отдавать подрядчику. У каждого человека, который работает в Битрикс24, должна быть своя учётная запись.
Как тогда правильно пригласить интегратора в облачный Битрикс24?
В облачной версии есть штатная роль «Специалист по внедрению». Она создана именно для сотрудника компании-интегратора, который помогает настраивать Битрикс24.
Перед приглашением я бы сделал три вещи:
- Проверил компанию в официальном каталоге партнёров Битрикс24.
- Зафиксировал объём работ и понял, для чего специалисту нужен вход в портал.
- Пригласил специалиста через штатный механизм, а не создавал ему обычного администратора.
Официальный каталог партнёров Битрикс24:
Получается, у специалиста по внедрению будут только ограниченные права?
Здесь важно не создавать ложного ощущения безопасности. Само название специальной роли не означает, что интегратор ничего лишнего не увидит.
Поэтому до начала работ клиенту нужно прямо обсудить, с какими разделами и данными будет работать специалист. Если часть информации особенно чувствительна, это нужно учитывать в составе работ, договорённостях и организации доступа.
Редакционная справка 1PI.PRO. По актуальной документации Битрикс24 у специалиста по внедрению есть права администратора, но с двумя ограничениями: он не может назначать и увольнять администраторов и отключать двухфакторную аутентификацию сотрудников. Роль доступна в веб-версии облачного Битрикс24. При приглашении система проверяет принадлежность e-mail интегратору, а специалист должен включить двухфакторную аутентификацию в течение десяти дней.
Официальная инструкция Битрикс24:
Тогда что в этой схеме действительно защищает клиента?
Не одна галочка, а последовательность действий.
Во-первых, клиент работает с проверенной компанией, а не с человеком, который просто попросил дать ему права администратора.
Во-вторых, специалист входит под собственной учётной записью. Не под директором, не под менеджером и не под общим пользователем «Интегратор».
В-третьих, до старта понятен объём работ. Клиент знает, что именно будет меняться и зачем специалисту нужен доступ.
В-четвёртых, при необходимости подписывается NDA — соглашение о неразглашении.
И наконец, после завершения работ доступ закрывается. Без последнего пункта вся аккуратность на старте теряет смысл.
А если подрядчик просит просто сделать его администратором?
Стоит спросить, почему нельзя использовать роль специалиста по внедрению.
Сама просьба ещё не доказывает, что подрядчику нельзя доверять. Возможно, речь идёт о коробочной версии или о задаче с другими техническими условиями. Но причина должна быть понятной.
Если это облачный Битрикс24 и исполнитель является официальным партнёром, логично использовать штатный способ приглашения. Выдавать обычные права администратора неизвестному человеку без проверки точно не стоит.
О том, как проверить подрядчика до начала проекта, мы подробно рассказывали в статье «Как выбрать интегратора Битрикс24 и не пожалеть через месяц»:
NDA решает вопрос безопасности?
NDA — хорошая практика, но не волшебный щит.
Соглашение фиксирует обязательства сторон по работе с конфиденциальной информацией. Оно особенно уместно, когда специалисту могут быть доступны клиентская база, документы, коммерческие условия и внутренние процессы.
Но NDA не заменяет отдельную учётную запись, штатное приглашение и контроль пользователей. Бумага отвечает за договорённости, а технические настройки — за реальный доступ к системе. Нужны оба уровня.
Что компания может безопасно проверить сама до начала работ?
Я бы использовал короткий чек-лист:
- Найти исполнителя в официальном каталоге партнёров Битрикс24.
- Уточнить, кто именно из специалистов будет работать в портале.
- Согласовать перечень работ и ожидаемые изменения.
- Для облачной версии проверить возможность приглашения через роль «Специалист по внедрению».
- Убедиться, что не нужно передавать логин, пароль или код двухфакторной аутентификации действующего сотрудника.
- Определить, нужен ли NDA до начала работ.
- Заранее договориться, когда и кем будет закрыт доступ.
Ещё полезно открыть список пользователей и администраторов. Иногда там находятся старые учётные записи подрядчиков, о которых уже никто не помнит.
Если при такой проверке обнаружились лишние пользователи или непонятные администраторы, не стоит наугад менять всем права. Сначала нужно разобраться, для чего создана каждая учётная запись и какие процессы от неё зависят.
Подробнее о проверке ролей и доступов:
Для коробочной версии порядок такой же?
Нет, её нужно рассматривать отдельно.
Штатное приглашение специалиста по внедрению, о котором мы говорим, относится к веб-версии облачного Битрикс24. В коробочной версии способ подключения и возможности ограничения зависят от конкретной конфигурации, инфраструктуры и поставленной задачи.
Там могут потребоваться не только права внутри Битрикс24, но и доступ к серверу или другим компонентам. Поэтому универсальную инструкцию «поставьте одну галочку» для коробочной версии давать небезопасно.
Что обязательно сделать после завершения проекта?
Вернуться к списку пользователей и закрыть доступ специалиста.
В облачном Битрикс24 специалиста по внедрению можно уволить через его профиль. Не нужно оставлять учётную запись активной «на всякий случай». Если помощь снова понадобится, уволенного специалиста можно будет принять обратно.
Также стоит проверить:
- остался ли подрядчик в списке активных пользователей;
- нет ли лишних обычных администраторов;
- не создавались ли временные или общие учётные записи;
- завершены ли работы, для которых предоставлялся доступ;
- переданы ли заказчику описание настроек и необходимые материалы.
Штатный порядок увольнения специалиста описан в инструкции Битрикс24:
Был ли у вас отдельный показательный кейс по этой теме?
Нет, и придумывать его ради статьи не нужно.
У нас есть рабочий регламент безопасности, который применяется в проектах 1PI.PRO: специалист подключается штатным способом, при необходимости стороны подписывают NDA, а после завершения проекта доступ закрывается.
Это не история про один громкий инцидент. Это обычная дисциплина, благодаря которой инцидента как раз не должно случиться.
Когда лучше сразу обратиться к специалисту?
Когда непонятно, кого уже пригласили в портал, зачем некоторым пользователям выданы права администратора и какие доступы можно закрыть без последствий.
Помощь также нужна, если используется коробочная версия, требуется ограничить доступ к отдельным разделам или провести аудит пользователей и администраторов.
Главное — не начинать с массового удаления учётных записей и не выдавать новые права наугад. Сначала нужно восстановить картину: кто имеет доступ, для какой задачи он был предоставлен и нужен ли он сейчас.
Если вы собираетесь подключить интегратора или хотите проверить уже выданные доступы, напишите в чат поддержки 1PI.PRO. Мы поможем определить безопасный способ подключения, проверить пользователей и администраторов и зафиксировать порядок закрытия доступа после работ.
Частые вопросы
Как пригласить интегратора в облачный Битрикс24?
В веб-версии откройте виджет «Пригласить» и выберите «Специалист по внедрению». Укажите e-mail специалиста. Битрикс24 проверит, что адрес принадлежит интегратору, после чего специалист сможет войти в портал.
Какие права получает специалист по внедрению?
По официальной документации Битрикс24 специалист получает права администратора с ограничениями: он не может назначать и увольнять администраторов и отключать двухфакторную аутентификацию сотрудников.
Можно ли передать интегратору логин и пароль сотрудника?
Нет. Интегратор должен работать под собственной учётной записью. Нельзя передавать ему пароль действующего сотрудника или коды двухфакторной аутентификации.
Обязательно ли подписывать NDA с интегратором?
Это зависит от состава работ и правил компании, но при доступе к клиентской базе, документам и коммерческой информации NDA является разумной практикой. При этом оно не заменяет технический контроль доступа.
Как закрыть доступ специалиста после проекта?
В облачном Битрикс24 откройте профиль специалиста по внедрению и выберите «Уволить». После этого проверьте списки активных пользователей и администраторов.
Как подключить интегратора к коробочному Битрикс24?
Единой инструкции нет: способ подключения зависит от конфигурации коробочной версии, инфраструктуры и задачи. Перед выдачей доступа лучше определить его состав вместе со специалистом.
