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

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

Почему один браузер связывает двадцать аккаунтов

Каждый вход из одного и того же профиля браузера отдаёт сайту назначения один и тот же хеш canvas, рендерер WebGL, список шрифтов и хранилище куки. Даже в раздельных профилях браузера, если они работают на одной машине, подложечный аппаратный отпечаток у всех одинаков. Площадке, следящей за аккаунтами с общей подписью устройства, не нужны общие куки, чтобы связать аккаунт клиента A с аккаунтом клиента B: одного аппаратного сигнала достаточно для кластеризации.

Почему браузер обычно не настоящая причина

Починка браузера закрывает один канал. Связывание, из-за которого аккаунты помечают вместе, чаще приходит из сигналов, которых не касается ни одна настройка браузера:

• Общая резервная почта или телефон. Если адрес вашего агентства указан контактом восстановления у нескольких клиентских аккаунтов, площадка видит этот общий идентификатор в момент любого сценария восстановления.
• Общий способ оплаты. Карта агентства, привязанная к рекламным кабинетам разных клиентов, - прямая связь между ними, доступная запросом, независимо от любых сигналов устройства.
• Все аккаунты впервые открыты с одного офисного IP. Создание и первый вход с одного адреса, даже однократно, - факт с меткой времени, который площадка записала ещё до того, как вы задумались об отпечатках.
• Одинаковые шаблоны создания. Аккаунты, созданные пачкой, названные по одному соглашению или заведённые в одно десятиминутное окно, читаются как один оператор с множеством аккаунтов - чем маркетинговое агентство и является, но чем аккаунт клиента не должен выглядеть для площадки.

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

Одна личность на клиента и залипающий прокси

То, что схема с браузером действительно чинит: дайте каждому клиентскому аккаунту свой постоянный профиль на своём резидентном выходном IP, закреплённом за этим клиентом, чтобы аккаунт не выглядел меняющим сети между сессиями. Это одна убранная переменная, а не вся картина. Работает только вместе с процессными исправлениями выше: контакты восстановления и способы оплаты должны принадлежать клиенту, а не агентству, а создание аккаунтов - быть растянутым во времени, а не пачкой.

Отключение клиента - шаг, о котором забывают все

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

• Снимите доступ агентства на стороне площадки - очевидный шаг.
• Передайте или уничтожьте локальный профиль, в котором жила сессия этого клиента. Профиль с ещё живыми куками, сохранёнными passkey и рабочей привязкой прокси - это постоянный доступ, переживший договор, независимо от того, помнит ли кто-нибудь о его существовании.
• Если клиенту нужна преемственность, экспортируйте профиль ему переносимым архивом, а не оставляйте его живым на инфраструктуре агентства.
• Убедитесь, что ничто в менеджере паролей агентства и в контактах восстановления больше не указывает на аккаунты этого клиента.

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

Вопрос о защите данных, который может задать клиент

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

Когда обычный профиль браузера - ответ лучше

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

Проверьте свою схему

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