Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему должны существовать квоты и на уровне аккаунта, и на уровне сети
Квота на уровне аккаунта отвечает на простой вопрос: сколько израсходовал этот конкретный ключ. Это естественное первое, что стоит учитывать, но само по себе этого недостаточно, потому что ключ это всего лишь учётные данные, а учётные данные можно размножить. Тот, кто твёрдо намерен превысить лимит на уровне аккаунта, часто может просто создать ещё один аккаунт, сгенерировать ещё один ключ и начать с новой квотой, если только что-то другое не отслеживает параметр, который не сбрасывается просто потому, что были выданы новые учётные данные.
Именно для этого и нужны квоты на уровне сети. Каждая сеть, то есть один блок /24 для адресов IPv4 или один блок /48 для IPv6, получает общую бесплатную квоту в 2 500 запросов в день, которая учитывает и трафик без ключа, и все ключи, зарегистрированные из этой сети. Один только лимит на уровне аккаунта позволил бы бесконечно генерировать новые ключи, чтобы снова и снова обнулять бесплатную квоту. Лимит на уровне сети закрывает именно эту брешь, потому что он отслеживает, откуда на самом деле приходит трафик, а не только то, какие учётные данные к нему оказались привязаны.
Ни одной из этих мер по отдельности недостаточно, и стоит чётко сказать, от чего защищает каждая, поскольку они решают разные задачи. Учёт на уровне аккаунта защищает от того, что одни учётные данные используются намного больше, чем должны, а это важно для точности биллинга и для выявления утёкшего ключа, который используется там, где не должен. Учёт на уровне сети защищает именно от размножения бесплатной квоты через повторные регистрации, а это другой сценарий сбоя, который один лишь учёт на уровне аккаунта не видит, поскольку каждый новый аккаунт по отдельности выглядит совершенно нормально.
Совместное использование обоих способов действительно создаёт обоснованное затруднение: несколько настоящих пользователей в одной сети, например компания за небольшим числом публичных IP-адресов, теоретически могут упереться в потолок на уровне сети, который никак не связан с фактическим использованием отдельного пользователя. Мы решаем это с помощью скользящих IP-слотов, то есть фиксированного числа разных адресов, с которых можно использовать ключ, и заголовков квоты, которые точно показывают, сколько из этих слотов занято относительно лимита. Так добросовестная общая сеть видит своё реальное положение, а не упирается в непрозрачную стену без каких-либо объяснений.
Мы считаем, что это тот случай, когда более простой дизайн, учитывающий только один параметр, был бы на самом деле хуже для честных пользователей, а не просто слабее защищал бы от злоупотреблений. Лимит только на уровне сети наказывал бы аккаунт за чужую, не связанную с ним активность в той же сети. Лимит только на уровне аккаунта оставил бы бесплатную квоту открытой для бесконечного размножения любым, кто готов создать достаточно аккаунтов. Использовать оба способа, с видимостью каждого через заголовки ответа, значит иметь больше движущихся частей, но именно такой вариант действительно защищает то, что должна защищать бесплатная квота, не наказывая втихую тех, кто пользуется ею по назначению.