Плановая ротация серверных API-ключей
Версия 2.7
Инвентаризация потребителей
Соберите перечень приложений и фоновых заданий, которые обращаются к RouteDesk от имени вашей организации. Для каждого отметьте среду, требуемые области доступа, имя секрета в хранилище и ответственного. Включите задачи сверки, задания по выпуску этикеток и аварийные инструменты дежурных. По журналу приложения проверьте, какие потребители действительно активны, и учтите редко запускаемые задачи.
Подготовка нового ключа
В «Настройки → Интеграции» подготовьте замену с областями, необходимыми конкретному потребителю. Клиенту чтения статусов нужна `shipments:read`, обработчику создания — `shipments:write`. Обновите серверное хранилище секретов и задокументируйте имя настройки. Передача самого значения в задачах, скриншотах и истории команд создаёт копии, которые потом сложно отозвать.
Проверка перед отзывом старого ключа
Переключите один экземпляр потребителя и выполните штатную операцию, допустимую его областью. Для чтения используйте известное отправление. Для записи подготовьте согласованный контрольный заказ и проверьте, что повтор использует сохранённый Idempotency-Key. Когда все экземпляры обновлены, проверьте долгоживущие процессы: приложение может держать старую конфигурацию в памяти до перезапуска.
Отзыв и сверка
Отзывайте старый ключ после проверки всех потребителей согласно принятому плану. Проследите за задачами с отложенным запуском и ошибками доступа. Если сервис продолжает получать AUTH-403, проверьте область нового ключа и версию настройки на конкретном экземпляре. Запишите время переключения, имя потребителя и контрольный запрос. В журнале нужен идентификатор секрета в вашем хранилище или локальное имя, без его значения.
Если ключ мог быть раскрыт
При подозрении на компрометацию владелец отзывает затронутый ключ и проверяет доступы. Это аварийная процедура: срочность определяется риском доступа, а не обычным графиком ротации. Подготовьте время, организацию, затронутые интеграции и подозрительные действия для специалиста по безопасности. Если бывший сотрудник имел персональный ключ, проверьте его отдельно от отзыва роли в команде.
Дежурный график ротации
Выберите период, когда можно проверить каждого потребителя и быстро исправить ошибку конфигурации. Для редкой ночной задачи подготовьте контролируемый запуск или назначьте владельца проверки на ближайшее расписание. В плане зафиксируйте момент выпуска, распространения и отзыва, чтобы при расследовании ошибок можно было сопоставить отказ с конкретным шагом.
Признаки незавершённой замены
Старый секрет ещё может находиться в настройках резервного экземпляра, шаблоне контейнера или отложенной задаче. Проверьте эти места по принятому списку потребителей, затем обновите их на ссылку на действующую версию секрета. Если старый ключ уже отозван, подтвердите нормальную работу каждого возобновлённого процесса отдельной штатной операцией.