Мультиаккаунтинг для DevOps: консоли AWS, GCP и Azure клиентов

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

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

Проблема, которую не решает вкладка в режиме инкогнито

У инженера, который обслуживает 10–15 клиентов, в среднем по 2–3 облачных аккаунта на каждого: продовый AWS, стейджинг, иногда отдельный biller. Добавьте сюда Cloudflare, Vercel, DigitalOcean, панели мониторинга вроде Datadog или Grafana Cloud — и получится 40–60 веб-консолей, в которые нужно заходить регулярно, часто с разных устройств и разными людьми в команде.

Стандартный способ — держать все сессии в одном браузере и переключаться между аккаунтами через logout/login или через расширения-свитчеры. Это работает, пока клиентов пять. На пятнадцати начинаются конкретные проблемы:

• Перекрёстные куки и кэш. Браузер хранит токены и локальные настройки консоли в общем профиле. AWS console иногда «подхватывает» последний использованный регион или IAM-роль от другого аккаунта — инженер меняет security group не там, где думал.
• MFA-коды вперемешку. Если TOTP-секреты лежат в одном менеджере паролей без привязки к конкретному контексту работы, легко ввести код не в то окно — особенно в конце смены.
• Нет аудита, кто и когда заходил. Когда у клиента case в саппорте «кто-то удалил S3-бакет в 23:40», ответ «кто-то из команды» никого не устраивает.
• Передача клиента другому инженеру. Увольнение, отпуск, ротация — и нужно быстро понять, в какие 8 консолей заходил человек, и либо забрать доступ, либо передать сессии коллеге без того, чтобы заново проходить MFA-регистрацию в каждой.

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

Чем отличается подход с профилями

Антидетект-браузер в этом сценарии не нужен для того, чтобы «обмануть» AWS или Cloudflare — никакого обхода правил тут нет и быть не должно: каждый клиентский аккаунт в облаке — это легитимный, отдельно оплачиваемый аккаунт, и агентство или фрилансер работает в нём по договору. Задача инструмента другая: дать каждому клиенту свой изолированный браузерный контейнер — отдельные куки, отдельное хранилище MFA, отдельную историю, — чтобы сессии физически не могли пересечься, а не полагаться на дисциплину и память инженера.

На практике это выглядит так: один профиль = один клиентский контекст (например, «Клиент А — AWS prod» и «Клиент А — AWS staging» отдельно, если риски разные). В GetAntik профиль хранит:

• cookies и локальное хранилище сессии консоли — не теряются между запусками, не нужно логиниться по новой каждый день;
• запись в хранилище 2FA-ключей конкретно для этого профиля — TOTP-код генерируется рядом с нужной консолью, а не в общем приложении-аутентификаторе, где легко перепутать строки;
• закладки на нужные разделы консоли — удобно для рутинных проверок биллинга или квот;
• при необходимости отдельный исходящий IP через привязанный прокси — актуально, если у клиента настроен allow-list по IP для доступа в консоль или если нужно проверить, как ведёт себя региональный edge Cloudflare.

Где это особенно окупается

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

Передача клиента между инженерами. Ротация на проекте — обычное дело: один специалист уходит в отпуск, другой подхватывает поддержку. Без изоляции по профилям это означает: собрать заново пароли, перепройти MFA-регистрацию в каждой из 5–8 консолей клиента, обновить доступ в трекере задач. С профилями — передача доступа оформляется как смена владельца профиля: коллега получает рабочую сессию со всеми закладками и сохранёнными ключами, прежний инженер теряет доступ в этот же момент.

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

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

Как организовать профили на практике

Для команды из 4–6 инженеров и 15–20 клиентов разумная схема такая:

1. Один профиль — один клиентский контур, а не один клиент целиком. Прод и стейджинг разводятся по разным профилям, если у клиента разный уровень доступа или разные ограничения по IP.
2. Группировка по клиенту, а не по платформе. Удобнее искать «Клиент Б» и видеть все его консоли — AWS, Cloudflare, Grafana — рядом, чем рыться по вкладке «AWS» среди двадцати разных клиентов.
3. Роль, а не общий пароль. В команде задаются роли: кто может только заходить в консоль и смотреть метрики, кто может менять инфраструктуру, у кого есть доступ к биллингу. Это не замена IAM-ролей внутри самого AWS — это фильтр на уровне «кто из команды вообще может открыть этот профиль».
4. Лимит профилей на человека. Стажёр или джуниор не должен иметь физическую возможность открыть прод-консоль клиента, с которым не работает — проще ограничить это на уровне профиля, чем полагаться на то, что он не найдёт пароль.

Про то, как выстроить эту структуру, когда профилей становится действительно много — не 20, а 200+ — есть отдельный разбор в материале про организацию больших пулов профилей.

Таблица: что меняется по сравнению с общим браузером

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

Один аккаунт root на всю команду. Соблазн завести одну общую учётку с правами администратора и раздать пароль всем — экономит время на старте и создаёт проблему на годы вперёд: невозможно понять, кто что сделал, нельзя отозвать доступ одному человеку, не сломав всем остальным. Даже если в самом облаке уже настроены отдельные IAM-пользователи, важно, чтобы и на уровне браузера у каждого инженера был свой контейнер с собственной MFA-привязкой, а не общий залогиненный профиль на расшаренном ноутбуке.

MFA-секрет в общем чате или таск-трекере. QR-код или TOTP-секрет для консоли клиента иногда пересылают в Slack «на всякий случай» — и он там остаётся навсегда, доступный всем, кто когда-либо был в этом канале. Привязка 2FA-ключа к конкретному профилю с шифрованием данных на устройстве снимает этот соблазн: ключ физически не нужно пересылать текстом, он хранится там же, где и сессия.

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

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

Что с этим делать начинающей команде

Если у вас 2–3 инженера и 8–10 клиентов, не нужно сразу строить сложную иерархию ролей. Разумный минимальный набор:

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

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

FAQ

Это не нарушает условия использования AWS или Cloudflare? Нет, если речь о легитимных отдельных аккаунтах клиентов, в которые у вас есть договорной доступ. Антидетект-часть браузера здесь просто изолирует сессии и отпечаток между профилями — это не попытка выдать один аккаунт за несколько или обойти блокировку, а способ не перепутать настоящие, отдельные учётки.

Нужен ли отдельный прокси для каждой консоли? Не всегда. Прокси нужен конкретно там, где у клиента настроен allow-list по IP или где регион входа имеет значение (например, проверка поведения CDN). Для обычных консолей без таких ограничений можно работать и без привязанного прокси — изоляция куки и MFA уже решает основную проблему.

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

Что делать с автоматическими проверками, которые должны идти без участия человека — например, ночные проверки биллинга? Для них подходит тот же профиль, что и для живой работы инженера, запускаемый через локальный API — через Puppeteer, Playwright или Selenium по CDP. Это не отдельная headless-сессия с нуля, которую консоль может посчитать новым подозрительным устройством, а продолжение той же сессии с теми же куки и отпечатком.

devopsмультиаккаунтингантидетект-браузероблачные консолибезопасность