Почему бесплатная поддержка тоже должна давать настоящие ответы
Поддержка, которая даёт продуманные ответы только платящим клиентам, сообщает бесплатным пользователям, что их вопросы не стоят нормального решения.
Проблема API-ключей, которые никогда не истекают
Бессрочный ключ удобен именно тем, что о его существовании легко забыть. Его создают один раз, вписывают в конфигурационный файл или переменную окружения, и дальше он просто продолжает работать, бессрочно, и никто не пересматривает, нужен ли он. Спустя годы человек, создавший его, может уже уйти из компании, проект, для которого он создавался, может быть закрыт, а сам ключ может лежать на забытом сервере, в утёкшем репозитории или в старой резервной копии, по-прежнему полностью действительный, потому что система ни разу не попросила его доказать, что он всё ещё нужен.
Это реальная и недооценённая проблема безопасности, а не гипотетическая. Ключи утекают через закоммиченные конфигурационные файлы, через логи, которые случайно сохранили заголовок запроса, через старые резервные копии, пережившие проект, которому они принадлежали. Бессрочный ключ означает, что каждый из этих путей утечки остаётся опасным бессрочно и нет естественного момента, когда риск закрывается сам собой. Ключ, который периодически ротируется или пересматривается, по крайней мере ограничивает время, в течение которого конкретной утечкой можно воспользоваться, даже если саму утечку так и не обнаружили.
Мы не считаем, что решение в принудительных сроках действия, которые ломают интеграции без предупреждения, ведь это просто замена одной проблемы другой, столь же неприятной: ключом, который перестаёт работать посреди продакшена из-за политики ротации, о которой никто толком не сообщил. Решение в прозрачности и контроле, которые делают ротацию осознанным, взвешенным выбором, а не тем, что либо никогда не происходит, либо случается как незапланированный сюрприз. Заголовки квоты в каждом ответе, включая количество занятых IP-слотов ключа, дают постоянный сигнал о том, соответствует ли характер использования ключа тому, для чего он изначально выдавался, а это именно та информация, которая должна побуждать к периодической проверке «нужен ли ещё этот ключ».
Распространённая в отрасли привычка относиться к ключу как к постоянным учётным данным, которые достаточно установить один раз, происходит из приоритета удобства первичной интеграции над всем сроком жизни этих учётных данных. В первый день действительно проще создать ключ, который больше никогда не придётся трогать. Это удобство получают сразу, а цена, то есть старый, никем не контролируемый, не ротируемый ключ, который где-то лежит как постоянная угроза, откладывается на будущий инцидент, о котором в первый день никто не думает.
Мы считаем, что более здоровый подход по умолчанию состоит в том, чтобы относиться к ключу не как к неизменной установке, а как к учётным данным, у которых есть постоянная связь с аккаунтом: видимым в реальном времени через запросы, которые он делает, периодически пересматриваемым и отзываемым без лишней драмы, когда проект, которому он принадлежал, действительно завершился. Для всего этого не нужно никому навязывать срок действия. Нужно сделать так, чтобы увидеть, что на самом деле делает ключ, было достаточно легко и чтобы оставлять старый ключ навсегда перестало быть путём наименьшего сопротивления.