AdAce AdsРотація API-ключа інтеграції з ШІ: інвентаризація та перевірка відкликання
Створення нового ключа — лише частина процесу ротації. Основне операційне завдання — знайти кожного споживача, замінити облікові дані без плутанини та переконатися, що старий ключ більше не діє. Цей регламент описує життєвий цикл процедури в AdAce Ads без повторення інструкцій зі створення ключів, розкриття секретів або припущень про підключення зовнішнього ШІ-клієнта.
Інвентаризація споживачів перед заміною
Почніть з інвентаризації облікових даних: зафіксуйте ID ключа або безпечний префікс, власника, простір, передбаченого споживача, області доступу, термін дії, посилання на місце збереження та контактну особу. Записуйте лише місце зберігання секрету, ніколи не саме значення. Розрізняйте ключі для звітних завдань і для інтерактивної роботи. Ключ без визначеного споживача є нерозв'язаним елементом інвентаризації; залишати його активним небезпечно. Дані про нещодавнє використання корисні, проте відсутність викликів не гарантує повної відсутності залежностей.
AdAce Ads зберігає хеш ключа, показує повний ключ лише під час створення та перевіряє його області доступу разом із поточними правами власника. Ротація має зберігати або звужувати необхідні межі доступу, а не додавати область propose лише тому, що випускається новий ключ. Для завдань зі створення звітів використовуйте відповідні права на читання. API-ключ і дозвіл OAuth — це різні типи облікових даних; заміна одного не змінює й не скасовує інший. Визначте фактичний шлях автентифікації перед початком.
Розглянемо приклад із двома споживачами: скриптом підготовки звітів і тимчасовою сесією аналітика. Скрипт потребує планової заміни; тимчасова сесія вже завершилася, тому її слід закрити, а не мігрувати. Регламент передбачає одне перемикання й одне видалення. Не слід копіювати один і той самий новий ключ на кожен відомий пристрій. Якщо неідентифікований споживач використовує старий ключ після ротації, це привід для розслідування, а не причина безстроково відновлювати старий ключ заради зручності.
Окремі перевірки для перемикання та відкликання
- Обирайте спосіб ротації залежно від причини. Планова заміна допускає короткий контрольований період одночасної дії обох ключів, якщо це підтримується; підозра на витік вимагає негайного відкликання та тимчасової зупинки сервісу. Не вважайте, що безперервність роботи важливіша за локалізацію загрози.
- Використовуйте матрицю верифікації зі старими обліковими даними, новими обліковими даними та зачепленими споживачами. Успішне читання за допомогою нового ключа підтверджує лише цей конкретний шлях. Це не свідчить про те, що старий ключ відкликано або що всі заплановані споживачі були оновлені.
- Фіксуйте в регламенті ідентифікатори й мітки часу, а не знімки екрана із секретними полями чи заголовками автентифікації. Звіт про ротацію має бути корисним іншому оператору, не стаючи при цьому новим каналом поширення конфіденційних даних.
Заміна, перевірка та завершення
- Визначте власника та всіх задокументованих споживачів. Перевірте необхідні області доступу та дозволи для клієнтів, після чого оберіть плановий або терміновий сценарій. Зафіксуйте відповідального за перемикання та умову завершення періоду перекриття.
- Створіть заміну за допомогою стандартного процесу керування ключами, якщо заміна необхідна. Перевірте поточні ліміти акаунта та права доступу, замість того щоб жорстко прописувати їх у регламенті. Збережіть нове значення безпосередньо у затвердженому сховищі секретів, не копіюючи його в нотатки, чати чи логи.
- Оновіть одного підконтрольного споживача та перевірте безпечне дозволене читання в призначеному просторі. Переконайтеся, що запит використовує належну область доступу та не викликає propose_change або інші інструменти для запису. Повторіть перевірку для кожного споживача, якщо облікові дані або середовища виконання відрізняються.
- Відкличте старий ключ через інтерфейс керування та переконайтеся, що ізольований запит на читання зі старими обліковими даними відхиляється. Використовуйте безпечні інструменти, які приховують заголовки запитів і секрети. Не вставляйте облікові дані в команди оболонки, URL-адреси, скриншоти або експортовані звіти тестування.
- Завершіть ротацію, зафіксувавши безпечні дані: ID нового ключа, ID старого ключа, результати перевірок споживачів, факт відкликання, ім'я оператора та час. Відстежуйте помилки споживачів, які намагаються використати колишній ключ, і вирішуйте їх через міграцію або закриття. Відкликаний секрет не повинен повертатися в роботу як засіб відновлення доступу.
Розуміння меж облікових даних, що змінюються
- Відкликання ключа запобігає подальшій автентифікації з його допомогою; воно не скасовує вже прочитані дані, не анулює окремі незалежні авторизації та не скасовує пряме членство в рекламній платформі. Перевіряйте ці межі окремо під час припинення співпраці.
- Це рекомендований операційний регламент, а не звіт про виконання ротації в реальному часі. Локальні тести та аналіз коду допомагають описати очікувану поведінку, але контрольні перевірки мають проводитися в реальному середовищі. Жоден із прикладів не вимагає запису в рекламний API.
Джерела й додаткові матеріали
Спробуйте на своїх кабінетах
Створіть робочий простір, підключіть Google або Meta в кілька кліків і побачте свої кабінети чітко. Зміни проходять погодження або дозволяються налаштованою вами політикою.
Створити простір