Мультиаккаунтинг для IT-аутсорсинга: доступ к SaaS-кабинетам клиентов

Редакция GetAntik · 7 октября 2026 г. · 8 минут чтения

Как MSP и IT-поддержка ведут десятки клиентских админ-консолей (Google Workspace, Microsoft 365, AWS) без путаницы сессий и лишних алертов безопасности.

Компания, которая обслуживает 30–50 клиентов на аутсорсе, рано или поздно сталкивается с одной и той же проблемой: у каждого клиента свой Google Workspace, свой Microsoft 365, своя консоль AWS или хостинг-панель, и всё это нужно администрировать из одного и того же браузера одного и того же техника. Разлогиниваться между клиентами десять раз в день — не вариант, держать отдельный ноутбук на каждого клиента — тоже. На практике команды либо живут в хаосе вкладок и постоянных logout/login, либо заводят изолированные профили браузера под каждого клиента. Второй путь работает заметно лучше, но у него есть свои тонкости, которые стоит понимать заранее.

Почему один браузер на всех клиентов — это не просто неудобно

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

• Автозаполнение и история подсказок. Браузер запоминает email, адреса, поисковые запросы внутри консолей. При работе с десятком клиентов автозаполнение начинает путать домены, пароли и настройки — техник на автомате вставляет не те данные не в то поле.
• Куки и локальное хранилище пересекаются. Некоторые консоли (особенно построенные на общих SSO-провайдерах вроде Okta или Azure AD) хранят токены сессии так, что открытие второй вкладки с другим клиентом обнуляет первую сессию или предлагает «продолжить как...» с чужим аккаунтом.
• Условный доступ реагирует на устройство и IP. Microsoft 365 и Google Workspace умеют триггерить security-алерты и даже блокировать вход при «нетипичном» для аккаунта устройстве, браузере или геолокации IP. Если техник входит в десять разных тенантов подряд с одного и того же отпечатка браузера и одного IP, часть клиентских политик Conditional Access расценит это как подозрительную активность и потребует MFA заново или вовсе заблокирует сессию.
• Расширения и локальные настройки одни на всех. Плагин для одного клиента (например, кастомный SSO-коннектор) может конфликтовать с настройками другого.

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

Что меняет изолированный профиль на клиента

Антидетект-браузер решает задачу буквально: один профиль = один клиент = свой набор кук, истории, автозаполнения, расширений и управляемого отпечатка (ОС, версия браузера, экран, часовой пояс и язык от IP). Для MSP это не про обход детектов рекламных платформ — это про чистую техническую изоляцию и про то, чтобы для систем клиента вход выглядел стабильно и предсказуемо.

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

1. Стабильный отпечаток — меньше повторных MFA-запросов. Если профиль клиента «А» всегда заходит с одного и того же набора параметров браузера и, при необходимости, с проксированного IP из региона клиента, система условного доступа видит знакомое устройство и не требует лишней верификации. Для клиентов с жёсткими политиками безопасности (банки, медицина, госсектор) это особенно заметно — без изоляции техники тратят по 5–10 минут на каждый вход, подтверждая личность заново.

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

3. Хранилище 2FA-ключей на клиента. У большинства консолей (Microsoft 365, Google Admin, AWS root, хостинг-панели) обязательна двухфакторная аутентификация. Держать коды в одном приложении-аутентификаторе на телефоне техника — плохая практика: при увольнении сотрудника компания теряет доступ к чужим 2FA или вынуждена вручную перевыпускать их у каждого клиента. В GetAntik 2FA-ключ хранится внутри самого профиля — он переезжает вместе с профилем, если доступ передаётся другому сотруднику.

4. Прокси под гео клиента — по необходимости, а не всегда. Это тот случай, где не нужно переусердствовать. Если клиент не использует строгие политики доступа по геолокации, прокси не обязателен — профиля с правильным часовым поясом и языком системы достаточно. Но если у клиента включены правила «вход только из страны регистрации компании» или настроен алерт на «invalid travel» (вход из одной страны через час после входа из другой), для такого клиента стоит держать прокси с подходящей геопривязкой, чтобы не плодить тикеты в их службу безопасности.

Какие консоли чаще всего требуют изоляции

Не каждая консоль требует отдельного прокси и строгого управления отпечатком — но изоляция кук, автозаполнения и 2FA полезна практически везде.

Как это организовать внутри команды

Для MSP на 5–15 техников подход обычно такой:

1. Один профиль на клиента, а не на сервис. Если у клиента и Microsoft 365, и AWS, и хостинг — логичнее держать их в одном профиле (одна вкладка — одна консоль), а не плодить три профиля на одного клиента. Исключение — когда к разным консолям должны иметь доступ разные техники (например, DevOps работает с AWS, а service desk — с Microsoft 365). Тогда профили разделяют по паре «клиент + область ответственности».
2. Роли и лимиты по специализации. Старшие инженеры получают доступ к root-консолям AWS и админкам Microsoft, сотрудники первой линии — только к тикет-системам и базовым панелям. В GetAntik это настраивается через роли и лимиты на члена команды — подробнее про настройку ролей и лимитов можно почитать в материале про передачу профилей и разграничение прав.
3. Передача профиля при смене ответственного. Клиентский аккаунт переходит от одного техника к другому вместе с профилем — настройками, куками, сохранённым 2FA-ключом и историей действий. Это снимает классическую проблему MSP, когда уволившийся сотрудник физически остаётся последним, кто помнит пароли от половины клиентских панелей.

1. Наблюдение за junior-специалистами. Live view и удалённое управление браузером коллеги — это не только контроль, но и реальный инструмент обучения: старший инженер может подключиться к сессии нового сотрудника во время первого прохода по клиентской консоли, подсказать и даже вмешаться, не прося расшарить экран через сторонний сервис.
2. Журнал действий для комплаенса. Если компания работает по SOC 2 или подобным требованиям, журнал активности по профилям — это готовый артефакт для аудита: кто, когда и в каком профиле заходил в клиентскую систему.

Где подход пересекается с другими задачами MSP, а где — нет

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

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

Частые ошибки

Один общий профиль «для всех мелких клиентов». Экономия выглядит разумно, пока в этом профиле не окажется десяток активных сессий MFA одновременно и не начнутся конфликты токенов. Разделение по профилям дешевле, чем час простоя клиентской системы из-за заблокированного входа.

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

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

Игнорирование шифрования данных профиля. Клиентские 2FA-ключи и куки сессий — чувствительные данные, их утечка с устройства техника или с сервера провайдера антидетект-браузера станет серьёзным инцидентом для MSP. В GetAntik данные профиля шифруются на устройстве паролем аккаунта, и сервер физически не может их прочитать — это снимает часть рисков при выборе инструмента. Подробнее о модели шифрования — в материале про безопасность профилей и 2FA-хранилище.

С чего начать

Для команды из 5–10 техников, обслуживающей 20–30 клиентов, разумная отправная точка — тариф с запасом профилей под текущих клиентов плюс 20–30% на рост (новые контракты, тестовые окружения). Посмотреть актуальные лимиты и цены можно на странице тарифов, а скачать приложение для macOS или Windows — на странице загрузки. Если в компании уже есть распределение по ролям (service desk, инженеры, DevOps), имеет смысл сразу настроить разграничение прав для команды, а не добавлять его постфактум, когда профилей станет 50+.

FAQ

Это нарушает условия использования Microsoft 365 или Google Workspace? Нет, если вы заходите в аккаунты клиентов с их ведома и в рамках договора на обслуживание. Изоляция сессий в отдельных профилях — это вопрос организации работы, а не обхода правил платформы. Платформы как раз заинтересованы в том, чтобы вход выглядел стабильно и не триггерил ложные алерты безопасности.

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

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

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

мультиаккаунтингmspit-поддержкаsaasбезопасность