Безопасность аккаунтов: как предоставить и вовремя закрыть гостевой доступ для подрядчика

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

Гостевой доступ к облачным сервисам безопасность проверяет не на уровне лозунгов, а на уровне привычек. Кто выдает права. На какой срок. Через личную почту или корпоративный домен подрядчика. С MFA или без. Есть ли владелец доступа. Есть ли дата отключения. Я много раз видела в продуктах одну и ту же пользовательскую боль: команда уверена, что «мы дали только нужное», а через полгода в Google Analytics, Notion, Microsoft 365 или рекламном кабинете все еще живут аккаунты людей, чьи договоры давно закрыты.

Почему подрядчики стали опасным, но недооцененным вектором

Риск внешнего доступа вырос не потому, что подрядчики стали хуже. Изменилась сама рабочая среда. Компании собирают стек из десятков SaaS-сервисов, где права часто выдаются в пару кликов, а отзываются уже вручную, по памяти и в конце проекта, когда всем хочется быстрее закрыть задачи.

В отчетах по инцидентам эта зона давно перестала быть второстепенной. По данным SecurityScorecard за 2025 год, 35,5% утечек данных в 2024 году были связаны с доступом третьих лиц. Это на 6,5% больше, чем годом ранее. Verizon DBIR 2024 оценивает масштаб еще шире: около 60% утечек так или иначе включают доступ третьих лиц, а среднее время обнаружения такого инцидента составляет 98 дней против 81 дня для штатных сотрудников.

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

На практике уязвимости появляются в нескольких типичных местах:

• подрядчику дают права администратора, потому что так быстрее пройти онбординг и не разбираться в ролях сервиса;
• доступ оформляют на личный Gmail или другую почту, которую компания не контролирует;
• пароль передают в мессенджере, таблице или письме, а потом забывают сменить;
• MFA остается опциональной, потому что «проект короткий»;
• у доступа нет срока жизни и владельца внутри компании;
• после завершения работ отключают только самый очевидный аккаунт, но забывают про интеграции, API-ключи, общие папки и рекламные кабинеты.

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

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

Наименьшие привилегии: давать не «доступ», а конкретное действие

Принцип Least Privilege звучит сухо, но в работе он очень прикладной: подрядчик получает только те права, без которых задача не будет выполнена. Не «доступ к Метрике», а просмотр отчетов по конкретному счетчику. Не «доступ к CRM», а экспорт сегмента или чтение карточек без возможности удалять сделки. Не «админ в Notion», а редактирование одной рабочей области.

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

В SaaS-инструментах роли часто выглядят похоже, но последствия разные.

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

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

Zero Trust: не доверять по умолчанию даже знакомому подрядчику

Zero Trust часто продают как большую архитектурную концепцию, но для управления гостевыми доступами в SaaS она сводится к понятной рабочей дисциплине: каждый вход должен быть проверен, каждое право должно быть оправдано, каждое исключение должно иметь срок.

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

Практически Zero Trust для внешних исполнителей собирается из нескольких слоев:

1. Отдельная учетная запись для каждого человека. Не «agency@», не общий логин, не один пароль на команду подрядчика. Персональная учетная запись дает аудит и понятную ответственность.

2. Фишинг-устойчивая MFA там, где это возможно. SMS-коды лучше, чем ничего, но их нельзя считать полной защитой. Более надежная модель — FIDO2/WebAuthn, аппаратные ключи или встроенные passkeys, если сервис и политика компании это поддерживают.

3. Контекст входа. Устройство, страна, риск сессии, новая локация, подозрительная активность. В Microsoft Entra ID и Microsoft 365 для этого используют политики условного доступа; в других экосистемах похожие механики могут называться иначе.

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

5. Разделение рабочих зон. Подрядчик не должен попадать во внутренний контур только потому, что ему нужен один файл или один отчет.

Здесь важно не уйти в тяжелую бюрократию. Если маркетологу нужно подключить агентство на запуск кампании, процесс не должен занимать неделю и пять согласований. Иначе люди вернутся к старому паттерну: «скинь пароль в Telegram, потом поменяем». Хороший Zero Trust в SaaS выглядит как бесшовный опыт: менеджер выбирает роль, срок, владельца, система сама применяет MFA и ставит напоминание на пересмотр.

Кстати, логика контроля внешних точек входа важна не только в корпоративных SaaS: даже в развлекательных и игровых онлайн-средах устойчивость сервиса зависит от того, как устроен существующий сетевой периметр и какие доверенные узлы допускаются к инфраструктуре.

Just-In-Time: временный доступ вместо вечного «на всякий случай»

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

Just-In-Time-доступ решает эту проблему иначе: права выдаются на ограниченное окно и продлеваются только при подтвержденной необходимости. Это особенно полезно для ролей с повышенными привилегиями: администрирование пользователей, экспорт данных, настройка интеграций, доступ к биллингу, управление API-ключами.

Я бы разделила временные доступы на три уровня.

В продуктах Microsoft Entra ID для внешних пользователей применяются Access Reviews и Conditional Access. Они помогают не держать гостевые учетные записи в вечном режиме ожидания: можно назначать проверки доступа, блокировать или удалять неактивных внешних пользователей, требовать MFA и ограничивать вход по условиям. Но здесь есть принципиальная деталь: облачный провайдер не обязан автоматически убирать всех неактивных гостей без настройки со стороны клиента. Политика должна быть включена, описана и привязана к владельцу.

В менее зрелых SaaS это можно имитировать процессом. Например, через заявку в Jira, Linear, YouTrack или ServiceNow: доступ создается только с полями «сервис», «роль», «владелец», «дата отзыва», «основание». Если компания небольшая, подойдет даже аккуратно настроенная таблица, но у нее должен быть владелец и регулярный ритм проверки. Иначе это будет еще один документ, который все открывали в день внедрения и забыли через месяц.

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

Автоматизация контроля: Access Reviews, журналы и владельцы доступа

В исследовании, опубликованном в PMC в октябре 2025 года, только 51,1% организаций ведут полный учет всех сторонних лиц, имеющих доступ к их сети. При этом 60% не проводят регулярный мониторинг их активности. Это ровно тот участок, где безопасность ломается не из-за отсутствия дорогого инструмента, а из-за отсутствия инвентаризации.

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

В хорошем реестре я ожидаю видеть не двадцать абстрактных колонок, а несколько рабочих полей:

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

Access Reviews хороши тем, что превращают пересмотр прав из героического ручного аудита в регулярный продуктовый сценарий. Владельцу приходит список внешних пользователей: подтвердить, изменить, отключить. Это снижает забывчивость и убирает токсичную ситуацию, когда ИТ-команда не знает, нужен ли подрядчик бизнесу, а бизнес не помнит, какие права ему выдали.

Журналы активности — второй слой. Их не надо читать каждый день глазами, если нет отдельной команды безопасности, но по высокорисковым действиям стоит настроить уведомления. Массовый экспорт. Добавление нового пользователя. Отключение MFA. Изменение биллинга. Создание API-ключа. Вход из нетипичной страны. Доступ к большому объему файлов. Для внешних пользователей такие события должны иметь более низкий порог внимания.

Отдельно стоит сказать про API-ключи и интеграции. В пользовательском интерфейсе подрядчик может быть отключен, но созданный им токен продолжит работать. Это частая слепая зона в SaaS. После проекта нужно смотреть не только список пользователей, но и приложения, вебхуки, сервисные аккаунты, подключенные расширения, OAuth-разрешения. Особенно если подрядчик занимался аналитикой, рекламой, CRM или автоматизацией.

Как выдавать доступ без передачи паролей

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

Рабочий процесс я бы строила так.

1. Сначала описать задачу, а не сервис. «Настроить цели в Метрике», «проверить структуру сделок в CRM», «обновить пять страниц базы знаний». Это помогает не выдать лишнее.

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

3. Создать персональный гостевой аккаунт. Почта должна принадлежать человеку или управляемому корпоративному домену подрядчика. Общие ящики — плохая основа для аудита.

4. Включить MFA до первого входа. Не после онбординга, не «когда будет время». Для внешних пользователей это базовое условие.

5. Поставить дату пересмотра и отключения. Лучше в самой системе. Если нельзя — в заявке, календаре или IAM-процессе.

6. Запретить передачу основного пароля. Если секрет все же нужен, использовать менеджер паролей с журналом, правами на уровне папки и обязательной ротацией после завершения работ.

7. Проверить, какие данные стали видны. Роль может называться «редактор», но фактически давать экспорт клиентской базы. Названия ролей в SaaS иногда успокаивают сильнее, чем должны.

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

Для малого бизнеса это может звучать избыточно, но именно небольшие команды часто работают с большим числом внешних исполнителей: таргетолог, дизайнер, разработчик, SEO-специалист, бухгалтерский сервис, интегратор. Там нет отдельного отдела безопасности, поэтому процесс должен быть простым и повторяемым. Один шаблон заявки. Один владелец. Один день в месяц на ревизию. Это уже резко лучше, чем «мы всем доверяем».

Как закрыть доступ после завершения проекта

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

Я обычно рекомендую проходить закрытие в несколько проходов, потому что один список пользователей не показывает всю картину.

Сначала отключаются персональные учетные записи подрядчика во всех SaaS, где они были созданы. Не удаляются вслепую, если нужны журналы для аудита, а именно блокируются или лишаются ролей по политике компании. Затем проверяются группы и общие папки: человек мог получить доступ не напрямую, а через группу «Marketing external» или через ссылку «все, у кого есть ссылка». После этого смотрят интеграции: OAuth-приложения, API-токены, вебхуки, сервисные аккаунты, ключи к рекламным кабинетам и аналитике.

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

Полезный порядок закрытия выглядит так:

1. Сверить список сервисов с исходной заявкой. Если доступа нет в реестре, но подрядчик фактически работал в сервисе, это сигнал для разбора процесса.

2. Отключить или удалить гостевые учетные записи по правилам конкретной платформы. В Microsoft 365, Google Workspace, CRM и таск-трекерах механика различается, но цель одна — внешний пользователь больше не входит.

3. Убрать пользователя из групп, пространств и папок. Особенно из облачных дисков и баз знаний, где ссылки живут годами.

4. Отозвать OAuth-разрешения и API-ключи. Это критично после работ по аналитике, интеграциям и автоматизации.

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

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

7. Закрыть заявку только после подтверждения владельца доступа. Не «кажется, отключили», а конкретная отметка в процессе.

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

Где процесс чаще всего ломается

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

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

Вторая поломка — отсутствие владельца. ИТ может создать аккаунт, но не всегда понимает, нужен ли он через месяц. Менеджер проекта понимает, но не всегда знает, где именно выданы права. Поэтому у каждого гостевого доступа должен быть бизнес-владелец. Не отдел. Не «маркетинг». Конкретный человек.

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

Четвертая — слепая зона ссылок. Современные SaaS любят шаринг: ссылка на документ, ссылка на доску, ссылка на отчет, ссылка на папку. Удобно, быстро, бесшовно. Но ссылка «доступно всем, у кого есть URL» иногда переживает и подрядчика, и проект, и смену команды. Для чувствительных данных такие ссылки должны быть временными, ограниченными доменом или закрытыми после этапа работ.

Практический вывод

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

Для небольшой команды я бы начала с трех вещей: перестать передавать основные пароли, завести реестр внешних доступов и назначать дату отключения при выдаче прав. Для компании со зрелым SaaS-стеком — добавить Access Reviews, Conditional Access, Just-In-Time для привилегированных ролей и мониторинг действий внешних пользователей.

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