Google запроваджує обов’язкові passkeys під час створення нових токенів оновлення OAuth 2.0 через Google Ads API. Розгортання почнеться 5 серпня і поступово охопить усіх користувачів. Чинні токени продовжать працювати, а сервісні облікові записи зміна не зачіпає. Проте заспокійливе формулювання приховує операційний ризик: під час додавання нового користувача, заміни облікових даних або повторного підключення інтеграції непідготовлена схема доступу може зупинити роботу.
Це не лише оновлення для розробників. Воно перевіряє, наскільки зріло агентства, внутрішні команди та постачальники програмного забезпечення керують доступом. Passkey є персональним засобом автентифікації, прив’язаним до пристрою; його не можна передати колезі так само, як пароль або одноразовий код. Саме в цьому полягає перевага для безпеки, але водночас стають помітними процеси, що досі залежать від спільного облікового запису, телефона однієї людини чи доступу колишнього працівника.
Що змінюється, а що залишається без змін
Користувачам, які проходять автентифікацію для Google Ads API, знадобиться passkey під час створення нового токена оновлення. За інформацією Google, пароля, SMS-коду або одноразового коду з автентифікатора для цього етапу буде недостатньо. Якщо passkey ще немає, система запропонує його створити.
Чинні токени мають працювати й надалі, тому негайно перепідключати всі акаунти не потрібно. Сервісні облікові записи також не підпадають під нову вимогу. Водночас новостворений passkey може пройти додатковий період перевірки, перш ніж система повністю йому довірятиме. Через це підключення в останню хвилину перетворюється на ризик для запуску.
Чому спільний агентський логін став операційною вразливістю
Спільний логін не дає зрозуміти, хто схвалив доступ, хто створив токен і чий пристрій потрібен для відновлення. Passkeys навмисно ускладнюють таку модель, бо кожен засіб автентифікації належить конкретній людині. Агентству варто надати кожному фахівцеві іменний доступ, використовувати ролі керівного акаунта та документувати власника кожної інтеграції.
Найпростіша реакція — створити passkey на спільному пристрої. Це лише переносить стару проблему в нову систему. Стійка модель відокремлює персональну автентифікацію від безперервності бізнесу: працівники входять під власними обліковими записами, агентство керує ролями, а щонайменше два підготовлені адміністратори можуть відновити доступ без використання чужої особи.
Чекліст готовності з п’яти частин
1. Інвентаризуйте всі процеси, що створюють токени
Складіть перелік внутрішніх скриптів, систем звітності, платформ керування ставками, сховищ даних, Google Ads Editor, Ads Scripts, Looker Studio та передавання даних у BigQuery. Для кожного підключення зафіксуйте обліковий запис, бізнес-власника, технічного відповідального та наслідки збою.
2. Замініть спільні облікові записи на іменний доступ
Запрошуйте працівників через їхні робочі адреси й надавайте мінімально потрібну роль. Не видаляйте застарілий доступ, доки не переконаєтеся, що від нього не залежить інтеграція. Для безперервності залиште двох адміністраторів, але не роздавайте надмірні права лише заради зручності.
3. Створіть passkeys до термінової потреби
Кожен, хто може авторизувати новий токен, має заздалегідь створити passkey на сумісному пристрої та перевірити вхід з іншого пристрою. Google підтримує сучасні версії Windows, macOS, ChromeOS, Android та iOS, а також апаратні ключі FIDO2. Для корпоративної техніки варто узгодити з ІТ-відділом браузери, Bluetooth і правила керування пристроями.
4. Опишіть відновлення доступу та звільнення працівників
Зафіксуйте порядок дій на випадок втрати телефона, несправності passkey або звільнення працівника. Відповідь не може звучати як «зателефонуємо тому, хто все налаштовував». Відомості про власника мають бути в реєстрі інтеграцій, резервні адміністратори — підготовлені, а залежності токенів — включені до процедури закриття доступу.
5. Перевірте підключення на акаунті з невисоким ризиком
До 5 серпня пройдіть повний процес авторизації на тестовому або другорядному акаунті. Виміряйте тривалість створення passkey, перевірки довіри, погодження та підключення застосунку. Успішного входу недостатньо: переконайтеся, що застосунок отримав очікуваний рівень доступу, а журнал дій показує правильного користувача.
Запитання до постачальника маркетингової технології
- Підключення використовує користувацький OAuth чи сервісний обліковий запис?
- Хто створює токен і які права запитує застосунок?
- Чи може інший адміністратор відновити інтеграцію без первинного користувача?
- Де зберігається токен, як його шифрують і замінюють?
- Яке сповіщення надходить у разі втрати авторизації?
- Як швидко відновиться збирання історичних даних після підключення?
Висновок для керівника
Нова вимога сама по собі не поліпшить результати реклами. Вона зменшить ризик фішингу й захоплення акаунта та змусить команду чітко визначити власників доступу. Найкраще підготовлені компанії сприйматимуть 5 серпня як термін для впорядкування рівня ідентифікації під звітністю й автоматизацією, а не як чергове вікно автентифікації.
Проведіть інвентаризацію, запровадьте іменний доступ і перевірте відновлення. Це кілька годин операційної роботи. Інакше під час запуску, міграції чи підключення клієнта може виявитися, що єдина людина, здатна авторизувати інтеграцію, недоступна, а новий passkey ще не пройшов перевірку довіри.
Джерела
- Search Engine Land: Google робить passkeys обов’язковими для Google Ads API
- Довідка Google Ads: використання passkey для чутливих дій
- Google Ads API: вимоги безпеки
