Рекомендации платформы Google Карт по безопасности

Приложения и проекты, использующие API и SDK платформы Google Карт, должны использовать ключи API или, если поддерживается, OAuth 2.0 для аутентификации.

Эти рекомендации покажут вам, как защитить доступ к платформе Карт.

Если вы хотите использовать OAuth 2.0 для авторизации трафика между серверами , найдите раздел, посвящённый OAuth, в документации по вашему API. Подробнее см. в разделе «Использование OAuth для серверных приложений» .

Помимо ограничений, накладываемых на приложения и ключи API, соблюдайте все меры безопасности, применимые к конкретным продуктам платформы Google Карт. Например, см. раздел «Рекомендуемые ограничения на приложения и API» ниже, посвящённый Maps JavaScript API.

Если ваши ключи API уже используются, ознакомьтесь с рекомендациями ниже в разделе Если вы ограничиваете используемый ключ API .

Более подробную информацию о цифровых подписях, поддерживаемых Maps Static API и Street View Static API, см. в Руководстве по цифровым подписям .

Рекомендуемые лучшие практики

Чтобы повысить уровень безопасности и избежать выставления счетов за несанкционированное использование, следуйте этим рекомендациям по обеспечению безопасности API для всех API, SDK или сервисов платформы Google Карт:

Ограничьте свои ключи API

Используйте отдельные ключи API для каждого приложения

Удалить неиспользуемые ключи API

Проверьте использование вашего ключа API

Будьте осторожны при ротации ключей API

Разделите использование клиентской и серверной части на отдельные проекты

Отключить неиспользуемые службы

Дополнительные рекомендации для клиентских приложений

Используйте клиентские SDK

Безопасные вызовы клиентских веб-сервисов

Дополнительные рекомендации для веб-сайтов или клиентских приложений, использующих статические веб-API

Защитите использование статического веб-API

Дополнительные рекомендации для серверных приложений, использующих веб-сервисы

Защитите ключи API веб-сервиса

Используйте OAuth для серверных приложений

Если вы ограничиваете или ротируете используемый ключ API

  • Прежде чем менять ключ API, проверьте использование ключа API. Этот шаг особенно важен, если вы добавляете ограничения для ключа, который уже используется в производственном приложении.

  • После смены ключа при необходимости обновите все свои приложения, используя новые ключи API.

  • Если ваш ключ API не был скомпрометирован и не используется активно, вы можете перенести свои приложения на несколько новых ключей API в удобном для вас темпе, оставив исходный ключ API нетронутым до тех пор, пока не будете наблюдать только один тип трафика, а ключ API можно будет безопасно ограничить одним типом ограничений приложений, не вызывая непреднамеренных сбоев в обслуживании.

    Дополнительные инструкции см. в разделе Переход на несколько ключей API .

    Отслеживайте использование с течением времени и смотрите, когда конкретные API, типы платформ и домены были перенесены со старого ключа API, прежде чем ограничить его использование или удалить. Подробнее см. в разделах «Отчётность и мониторинг» и «Метрики».

  • Если ваш ключ API был скомпрометирован, вам следует быстрее принять меры по его защите и пресечению злоупотреблений. В приложениях для Android и iOS ключи не заменяются, пока пользователи не обновят свои приложения. Обновление или замена ключей на веб-страницах или в серверных приложениях гораздо проще, но всё равно может потребовать тщательного планирования и быстрой работы.

    Для получения дополнительной информации см. раздел Обработка несанкционированного использования ключа API .

Дополнительная информация

Рекомендуемые ограничения приложений и API

Ограничьте свои ключи API

Рекомендуется всегда ограничивать ключи API одним типом ограничений для приложений и одним или несколькими ограничениями для API. Рекомендуемые ограничения для API, SDK или службы JavaScript см. в разделе «Рекомендуемые ограничения для приложений и API» ниже.

  • Ограничения приложений Вы можете ограничить использование ключа API определенными платформами: приложениями Android или iOS, определенными веб-сайтами для клиентских приложений или определенными IP-адресами или подсетями CIDR для серверных приложений, выполняющих вызовы REST API веб-служб.

    Вы ограничиваете ключ, добавляя одно или несколько ограничений приложений тех типов, которые вы хотите авторизовать, после чего разрешены будут только запросы, исходящие из этих источников.

  • Ограничения API. Вы можете ограничить API, SDK или сервисы платформы Google Карт, в которых можно использовать ваш ключ API. Ограничения API разрешают запросы только к указанным вами API и SDK. Для любого ключа API вы можете указать любое необходимое количество ограничений API. Список доступных API включает все API, включённые в проекте.

Установить ограничение приложения для ключа API

  1. Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.

  2. Выберите ключ API, который вы хотите ограничить.

  3. На странице «Изменить ключ API» в разделе «Ограничения ключа» выберите «Установить ограничение приложения» .

    Страница редактирования ключа API

  4. Выберите один из типов ограничений и предоставьте запрашиваемую информацию, следуя списку ограничений.

    Тип ограничения Описание
    Веб-сайты Укажите один или несколько сайтов-источников перехода.
    • Универсально поддерживаемые схемы URL-адресов реферера — https и http . Корректная работа других схем не гарантируется, поскольку современные веб-браузеры из соображений конфиденциальности не отправляют заголовок `Referer` в исходящих запросах.
    • Всегда указывайте полную строку реферера, включая схему протокола, имя хоста и необязательный порт (например, https://google.com ).
    • Для авторизации всех поддоменов можно использовать подстановочные знаки. Например, https://*.google.com принимает все сайты, заканчивающиеся на .google.com .
    • Будьте осторожны при разрешении полных путей рефереров, например, https://google.com/some/path , поскольку большинство веб-браузеров в целях конфиденциальности удаляют путь из запросов к другим источникам.
    IP-адреса Укажите один или несколько адресов IPv4 или IPv6, или подсетей, используя нотацию CIDR. IP-адреса должны соответствовать адресу источника, который отслеживают серверы платформы Google Карт. Если вы используете преобразование сетевых адресов (NAT) , этот адрес обычно соответствует публичному IP-адресу вашего компьютера.
    Android-приложения

    Добавьте имя пакета Android (из файла AndroidManifest.xml ) и отпечаток сертификата подписи SHA-1 каждого приложения Android, которое вы хотите авторизовать.

    1. Выберите приложения Android .
    2. Нажмите + Добавить .
    3. Введите название пакета и отпечаток сертификата SHA-1. Например: 
      com.example.android.mapexample
      BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75
    4. Нажмите « Сохранить ».

    Существует два типа сертификатов:

    • Отладочный сертификат : используйте этот тип сертификата только с тестируемыми приложениями и другим непроизводственным кодом. Не пытайтесь опубликовать приложение, подписанное отладочным сертификатом. Инструменты Android SDK автоматически генерируют этот сертификат при запуске отладочной сборки.
    • Сертификат выпуска : используйте этот сертификат, когда будете готовы выпустить приложение в магазине приложений. Инструменты Android SDK генерируют этот сертификат при запуске сборки выпуска.

    Дополнительную информацию о подписи и сертификатах приложений Android см. в руководстве «Подпишите свое приложение» .

    Если вы используете Play App Signing , чтобы получить отпечаток сертификата подписи, см. раздел Работа с поставщиками API . Если вы управляете собственным ключом подписи, см. раздел Самостоятельное подписание приложения или инструкции для вашей среды сборки.

    приложения для iOS

    Добавьте идентификатор пакета каждого приложения iOS, которое вы хотите авторизовать.

    1. Выберите приложения iOS .
    2. Нажмите + Добавить .
    3. Добавьте идентификатор пакета, чтобы принимать запросы от приложения iOS с этим идентификатором.
    4. Нажмите « Сохранить ».

    Рекомендации по ограничению применения см. в разделе Рекомендуемое ограничение применения .

  5. Выберите Сохранить .

Установить ограничения API для ключа API

  1. Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.

  2. Выберите ключ API, который вы хотите ограничить.

  3. На странице «Изменить ключ API» в разделе «Ограничения API» :

    • Выберите Ограничить ключ .

    • Откройте Select APIs и выберите API или SDK, к которым ваше приложение должно получить доступ с помощью ключа API.

    Если API или SDK отсутствуют в списке, их необходимо включить. Подробнее см. в разделе Включение одного или нескольких API или SDK .

    Ограничить API на странице редактирования ключа API

  4. Выберите Сохранить .

    После этого шага ограничение становится частью определения ключа API. Убедитесь, что вы указали все необходимые данные, и нажмите кнопку «Сохранить» , чтобы сохранить ограничения ключа API. Подробнее см. в руководстве « Получить ключ API» в документации по интересующему вас API или SDK.

Рекомендованные ограничения API см. в разделе Рекомендуемые ограничения API .

Проверьте использование вашего ключа API

Если вы ограничиваете использование ключей API после их создания или хотите узнать, какие API используются ключом, чтобы можно было их ограничить, проверьте использование ключа API. Эти шаги покажут, в каких сервисах и методах API используется ключ API. Если вы видите какое-либо использование за пределами сервисов платформы Google Карт, проведите исследование, чтобы определить, нужно ли добавить дополнительные ограничения для предотвращения нежелательного использования. Вы можете использовать обозревателя метрик Google Maps Platform Cloud Console, чтобы определить, какие ограничения API и приложений следует применить к вашему ключу API:

Определите API, которые используют ваш ключ API.

Следующие отчёты по метрикам позволяют определить, какие API используют ваши ключи API. Используйте эти отчёты для следующих целей:

  • Посмотрите, как используются ваши ключи API
  • Обнаружение неожиданного использования
  • Помогите проверить, можно ли безопасно удалить неиспользуемый ключ. Подробнее об удалении ключа API см. в разделе Удаление неиспользуемых ключей API .

При применении ограничений API используйте эти отчёты для создания списка API для авторизации или для проверки автоматически сгенерированных рекомендаций по ограничениям ключей API. Подробнее о рекомендуемых ограничениях см. в разделе Применение рекомендуемых ограничений . Подробнее об использовании обозревателя метрик см. в разделе Создание диаграмм с помощью обозревателя метрик .

  1. Перейдите в обозревателе метрик консоли Google Cloud.

  2. Войдите в систему и выберите проект для ключей API, которые вы хотите проверить.

  3. Перейдите на страницу обозревателя метрик для вашего типа API:

    • Для ключей API, использующих любой API , кроме Maps Embed API : перейдите на страницу обозревателя метрик .

    • Для ключей API, использующих Maps Embed API : перейдите в Metrics Explorer .

  4. Проверьте каждый ключ API:

    1. Выберите ДОБАВИТЬ ФИЛЬТР .

    2. Выберите метку credential_id .

    3. Выберите значение , соответствующее ключу, который вы хотите проверить.

    4. Обратите внимание, для каких API используется этот ключ API, и подтвердите, что такое использование является ожидаемым.

    5. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.

  5. Повторите эти действия для всех оставшихся ключей.

  6. Ограничьте свои API-ключи только теми API, которые используются.

  7. Если вы обнаружили несанкционированное использование, см. раздел Обработка несанкционированного использования ключа API .

Выберите правильный тип ограничения приложения с помощью обозревателя метрик.

После проверки и принятия всех необходимых мер для того, чтобы убедиться, что ваш ключ API используется только для используемых им служб платформы Google Карт, также проверьте, имеет ли ключ API правильные ограничения по применению.

Если для вашего API-ключа предусмотрены рекомендуемые ограничения, примените их. Подробнее см. в разделе Применение рекомендуемых ограничений API-ключа .

Если ваш ключ API не имеет рекомендаций по ограничениям, определите тип ограничения приложения, который следует применить, на основе указанного platform_type с помощью обозревателя метрик:

  1. Перейдите в обозревателе метрик консоли Google Cloud.

  2. Войдите в систему и выберите проект для API, которые вы хотите проверить.

  3. Перейдите на эту страницу обозревателя метрик: Обозреватель метрик .

  4. Проверьте каждый ключ API:

    1. Выберите ДОБАВИТЬ ФИЛЬТР .

    2. Выберите метку credential_id .

    3. Выберите значение , соответствующее ключу, который вы хотите проверить.

    4. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.

  5. Повторите эти действия для всех оставшихся ключей.

  6. Указав тип платформы для ключей API, примените ограничение приложения для этого platform_type :

    PLATFORM_TYPE_JS : Применить ограничения веб-сайта к ключу.

    PLATFORM_TYPE_ANDROID : Применить ограничения приложений Android к ключу.

    PLATFORM_TYPE_IOS : Применить ограничения приложений iOS к ключу.

    PLATFORM_TYPE_WEBSERVICE : Для правильной настройки ограничений вам, возможно, придется полагаться на ограничения IP-адреса в ключе.

    Рекомендации по использованию Maps Static API и Street View Static API см. в разделе Использование Protect Static Web API .

    Рекомендации по API Maps Embed см. в разделе Веб-сайты с API Maps Embed .

    Мой API-ключ использует несколько типов платформ: ваш трафик невозможно надежно защитить с помощью одного API-ключа. Вам необходимо перейти на несколько API-ключей. Подробнее см. в разделе «Миграция на несколько API-ключей» .

Используйте отдельные ключи API для каждого приложения

Такая практика ограничивает область действия каждого ключа. Если один из ключей API скомпрометирован, вы можете удалить или ротировать затронутый ключ без необходимости обновления остальных ключей API. Вы можете создать до 300 ключей API для одного проекта. Подробнее см. в разделе «Ограничения на ключи API» .

Хотя один ключ API на приложение идеально подходит в целях безопасности, вы можете использовать ограниченные ключи для нескольких приложений, если они используют один и тот же тип ограничений приложений.

Применить рекомендуемые ограничения ключа API

Для некоторых владельцев проектов, редакторов и администраторов ключей API консоль Google Cloud предлагает определенные ограничения ключей API для неограниченных ключей API на основе их использования и активности на платформе Google Карт.

Если доступны, рекомендации отображаются в виде предварительно заполненных вариантов на странице учетных данных платформы Google Карт .

API и SDK платформы Google Карт, поддерживаемые автоматизированными рекомендациями

  • API JavaScript Карт, включая службу направлений (устаревшую), службу матриц расстояний (устаревшую), службу высот, службу геокодирования, класс Place, виджет автозаполнения Place (новый), API данных автозаполнения Place, библиотеку Places, службу Places, виджет автозаполнения Places и набор пользовательского интерфейса Places

  • Статический API Карт и статический API Просмотра улиц

  • API для встраивания карт

  • Maps SDK для Android, Navigation SDK для Android, Places SDK для Android и Places UI Kit для Android

  • Maps SDK для iOS, Navigation SDK для iOS, Places SDK для iOS, Places Swift SDK для iOS и Places UI Kit для iOS.

Причины, по которым вы можете не увидеть рекомендацию или увидеть ее неполной

Причины отсутствия рекомендаций

  • Вы (также) используете ключ API на сервисах, отличных от Google Maps Platform, или на сервисах Maps Platform, которые еще не поддерживаются автоматическими рекомендациями.

    Если вы видите использование других сервисов, не применяйте рекомендацию, не выполнив сначала следующие действия:

    1. Убедитесь, что использование API, которое вы видите в обозревателе метрик консоли Google Cloud, является законным.

    2. Вручную добавьте недостающие сервисы в список API, подлежащих авторизации.

    3. Вручную добавьте все отсутствующие ограничения приложений для служб, добавленных в список API. Если для других добавленных вами служб требуются другие ограничения приложений, см. раздел Переход на несколько ключей API .

  • Ваш ключ API не используется в клиентских SDK или API.

  • Вы используете ключ API в приложении или на веб-сайте с низкой посещаемостью, которые не использовались в течение последних 60 дней.

  • Вы недавно создали новый ключ или недавно развернули существующий ключ в новом приложении. В этом случае подождите ещё несколько дней, чтобы рекомендации обновились.

  • Вы используете ключ API в нескольких приложениях, которые требуют конфликтующих типов ограничений, или используете один и тот же ключ API в слишком большом количестве различных приложений или веб-сайтов. В любом случае рекомендуется перейти на несколько ключей. Подробнее см. в статье «Переход на несколько ключей API» .

Причины, по которым вы видите неполную рекомендацию

  • Вы используете ключ API в приложении или на веб-сайте с низкой посещаемостью, которые не использовались в течение последних 60 дней.

  • Вы совсем недавно начали использовать существующий ключ для нового API или сервиса, и система автоматического выдачи рекомендаций по ограничению использования ключей API ещё не обработала обновлённые метрики использования. Распространение метрик использования может занять несколько дней.

    Если вы видите использование других сервисов, не применяйте рекомендацию, не выполнив сначала следующие действия:

    1. Убедитесь, что использование API, которое вы видите в обозревателе метрик консоли Google Cloud, является законным.

    2. Вручную добавьте недостающие сервисы в список API, подлежащих авторизации.

    3. Вручную добавьте все отсутствующие ограничения приложений для служб, добавленных в список API. Если для других добавленных вами служб требуются другие ограничения приложений, см. раздел Переход на несколько ключей API .

    4. Если вам не нужно срочно ограничить доступ к ключу, например, из-за несанкционированного использования, вы можете подождать день или два, пока рекомендации не появятся.

Причины, по которым вы можете увидеть рекомендации, которые не видны на диаграммах

  • Ваше приложение или веб-сайт отправляли только очень короткие всплески трафика. В этом случае переключитесь с представления «Диаграмма» на представление «Таблица» или «Оба» , так как использование по-прежнему отображается в легенде. Подробнее см. в разделе «Отображение полных легенд диаграммы» .

  • Ваш трафик поступает из Maps Embed API. Инструкции см. в статье «Определение API, использующих ваш ключ API» .

  • Трафик из приложения или веб-сайта находится за пределами диапазона дат, доступного в обозревателе метрик консоли Google Cloud.

  1. Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.

  2. Если доступно, выберите Применить рекомендуемые ограничения .

    Применить рекомендуемые ограничения

  3. Выберите «Проверить использование API» , чтобы проверить, для каких служб используется ключ API. Если вы видите что-то, кроме служб платформы Google Карт, приостановите просмотр и вручную проверьте приведенные выше рекомендации. См. шаги по устранению неполадок в начале раздела «Применение ограничений рекомендуемых ключей API» .

  4. Еще раз проверьте, соответствуют ли предварительно заполненные ограничения веб-сайтам и приложениям, где вы планируете использовать свой ключ API.

    Рекомендация : задокументируйте и удалите все ограничения приложений или API, не связанные с вашими сервисами. Если что-то сломается из-за непредвиденной зависимости, вы сможете снова добавить необходимые приложения или API.

    • Если вы заметили, что в ваших рекомендациях явно отсутствует приложение, веб-сайт или API, добавьте его вручную или подождите пару дней, чтобы рекомендация обновилась.

    • Если вам нужна дополнительная помощь с предложенной рекомендацией, обратитесь в службу поддержки .

  5. Выберите Применить .

Что делать, если ваша заявка отклонена после подачи рекомендации

Если вы заметили, что приложение или веб-сайт отклоняется после применения ограничения, найдите ограничение приложения, которое необходимо добавить, в сообщении об ошибке ответа API.

Клиентские SDK и API

Приложения на основе браузера и веб-просмотра

Современные браузеры обычно редактируют заголовок Referer в кросс-доменных запросах из соображений конфиденциальности, часто оставляя его только в Origin . Однако точное поведение зависит от применяемой referrer-policy на хостинге и может различаться в зависимости от браузера пользователя и его версии.

Веб-приложения, использующие непрозрачные или локальные схемы URI для загрузки контента, как правило, требуют от браузера рендеринга или веб-представления полностью редактировать заголовок Referer из любых исходящих вызовов, что может привести к сбою запросов при использовании ключей API с ограничениями веб-сайта.

Дополнительные инструкции см. в разделе Размещение браузерных приложений на сервере .

Инструкции по устранению неполадок для браузерных и веб-приложений:

  • Подробную информацию об авторизации приложения для Maps JavaScript API см. в консоли отладки браузера.

    Экзотические схемы URI поддерживаются частично . Если некоторые части вашего приложения не работают с экзотической схемой URI даже после авторизации необходимого реферера, вам, вероятно, потребуется разместить приложение удалённо на сервере и загружать его по протоколу HTTPS (или HTTP).

    Если вам нужна помощь с экзотическими схемами URI, обратитесь в службу поддержки .

  • Другие API платформы Карт обычно возвращают реферер, который необходимо авторизовать, в ответе об ошибке API, предполагая, что клиент отправил эту информацию с отклоненным запросом.

    Экзотические схемы URI не поддерживаются.

Android-приложения

Используйте Android Debug Bridge (adb) или Logcat

приложения для iOS

См. Просмотр сообщений журнала.

Приложения, напрямую вызывающие веб-сервисы

Информацию о приложениях, вызывающих конечные точки HTTPS REST API или gRPC платформы Карт напрямую без клиентского SDK платформы Google Карт, см. ниже:

Приложения для Android и iOS

Если ваше приложение для Android или iOS напрямую обращается к службам платформы Карт, не используя ни один из доступных клиентских SDK платформы Google Карт, ознакомьтесь с разделами Приложения для Android и iOS , где вы найдете дополнительные советы по устранению неполадок, и с разделом Безопасные вызовы клиентских веб-служб, где вы найдете актуальные рекомендации по обеспечению безопасности для случаев использования на мобильных устройствах.

Если ваше приложение регистрирует ответы на ошибки API платформы Карт, приведенные выше инструкции для клиентских SDK также могут оказаться полезными для устранения неполадок аутентификации.

Серверные приложения

Серверные приложения, использующие ключи API, лучше всего защищаются с помощью ограничений по IP-адресам. Если вы применили ограничения по IP-адресам к своему ключу и ваш сервис регистрирует ошибки API платформы Карт, проверьте системные журналы для получения дополнительной информации. В ответе об ошибке будет указан IP-адрес сервера, который необходимо авторизовать.

Приложения на основе браузера или веб-просмотра

Хотя Maps Static API, Street View Static API и более поздние API платформы Google Карт также будут поддерживать ограничения реферера, следует отметить, что веб-браузеры или веб-представления, скорее всего, будут ограничивать заголовок Referer Origin для запросов между источниками и, скорее всего, вообще не будут отправлять его, например, для локально доступных ресурсов или для ресурсов, обслуживаемых по протоколам, отличным от HTTP или HTTPS.

Если вы не можете использовать Maps JavaScript API в своем приложении и ограничения веб-сайта не работают, ознакомьтесь со статьей Безопасные вызовы клиентских веб-служб, чтобы узнать, как безопасно выполнять вызовы веб-служб платформы Карт из клиентского приложения на основе браузера.

Советы по проверке ограничений API

Чтобы проверить требуемые ограничения API, см. раздел Определение API, которые используют ваш ключ API .

Если вы не можете определить, какие ограничения следует применить:

  1. Задокументируйте текущие ограничения для дальнейшего использования.
  2. Временно удалите их, пока вы исследуете проблему. Вы можете проверить использование API с течением времени, следуя инструкциям в разделе Проверка использования ключа API .
  3. При необходимости обратитесь в службу поддержки .

Удалить неиспользуемые ключи API

Прежде чем удалять ключ API, убедитесь, что он не используется в рабочей среде. Если трафик отсутствует, ключ, скорее всего, можно безопасно удалить. Подробнее см. в разделе «Проверка использования ключа API» .

Чтобы удалить ключ API:

  1. Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.

  2. Выберите ключ API, который вы хотите удалить.

  3. Нажмите кнопку «Удалить» в верхней части страницы.

  4. На странице «Удаление учетных данных» выберите Удалить .

    Распространение удаления API-ключа занимает несколько минут. После завершения распространения любой трафик, использующий удалённый API-ключ, отклоняется.

Будьте осторожны при ротации ключей API

Ротация API-ключа создаёт новый ключ, обладающий всеми ограничениями старого. В течение этого периода принимаются как старый, так и новый ключ, что даёт вам возможность перевести свои приложения на использование нового ключа.

Перед ротацией ключа API :

  • Сначала попробуйте ограничить ваши ключи API, как описано в разделе Ограничение ваших ключей API .

  • Если ограничение ключа API невозможно из-за конфликта типов ограничений приложения, выполните миграцию на несколько новых (ограниченных) ключей, как описано в разделе «Миграция на несколько ключей API» . Миграция позволяет контролировать процесс миграции и планировать сроки внедрения новых ключей API.

Если предыдущие предложения невозможны и вам необходимо сменить ключ API, чтобы предотвратить несанкционированное использование, выполните следующие действия:

  1. Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.

  2. Откройте API-ключ, который вы хотите ротировать.

  3. В верхней части страницы выберите Повернуть ключ .

  4. При желании измените имя ключа API.

  5. Выберите Создать .

  6. Обновите свои приложения, чтобы использовать новый ключ.

После того как вы обновите свои приложения для использования нового ключа, удалите старый ключ, нажав кнопку Удалить предыдущий ключ в разделе Предыдущий ключ на странице нового ключа API.

Переход на несколько ключей API

Чтобы перейти от использования одного ключа API для нескольких приложений к одному уникальному ключу API для каждого приложения, выполните следующие действия.

  1. Определите, каким приложениям нужны новые ключи :

    • Веб-приложения обновлять проще всего, поскольку вы контролируете весь код. Запланируйте обновление ключей всех ваших веб-приложений.
    • С мобильными приложениями все гораздо сложнее, поскольку вашим клиентам придется обновить свои приложения, прежде чем можно будет использовать новые ключи.

  2. Создайте и ограничьте новые ключи : добавьте ограничение для приложения и как минимум одно ограничение API. Подробнее см. в разделе «Рекомендуемые практики» .

  3. Добавьте новые ключи в свои приложения : для мобильных приложений этот процесс может занять несколько месяцев, пока все ваши пользователи не обновятся до последней версии приложения с новым ключом API.

Разделите использование клиентской и серверной части на отдельные проекты

Если вам необходимо вызывать службы платформы Google Карт как из серверных приложений, так и напрямую из клиентских приложений, работающих на устройствах конечных пользователей, Google рекомендует разделить использование между двумя отдельными проектами.

Такой подход позволяет вам применять соответствующие поминутные ограничения квот для каждого пользователя к большинству сервисов платформы Google Карт в вашем клиентском проекте, помогая гарантировать, что все конечные пользователи получат свою справедливую долю общей квоты проекта, не влияя друг на друга.

Однако, поскольку ограничения квоты на пользователя влияют как на клиентские, так и на серверные приложения, если вам также требуется высокая пропускная способность для задач на стороне сервера, создайте отдельный проект для этого варианта использования, настроив его на более высокий предел квоты на пользователя или вообще не настроив его.

Отключить неиспользуемые службы

Не оставляйте неиспользуемые сервисы включёнными в проекте, так как это может привести к злоупотреблениям, особенно если вы не ограничили доступ ко всем своим открытым API-ключам. Рекомендуется включать сервис в проекте только тогда, когда он необходим вашим приложениям.

Добавление ограничений API к ключу предотвращает его использование в сервисах, для которых он не был авторизован, но ограничения API применяются только к этому конкретному ключу. Отключите сервис на уровне проекта, чтобы предотвратить несанкционированное использование сервиса для любого ключа, связанного с проектом.

Используйте клиентские SDK

При использовании клиентских SDK Google Maps Platform вы всегда сможете применить соответствующие ограничения к своему ключу API, чтобы обезопасить использование сервиса.

Использование клиентских SDK также позволит вам внедрить более продвинутые механизмы безопасности, такие как Firebase App Check на поддерживающих его API-интерфейсах Maps Platform. Подробнее см. в статье «Использование App Check для защиты ключа API» .

Если клиентские SDK недоступны для вашей платформы, см. раздел Защита вызовов клиентских веб-сервисов .

Информацию о доступности клиентских SDK Google Maps Platform для различных платформ см. в разделе Рекомендуемые ограничения приложений и API .

Защитите использование статического веб-API

Статические веб-API, такие как Maps Static API и Street View Static API, аналогичны вызовам API веб-сервисов.

Оба вызова выполняются через HTTPS REST API, и URL-адрес запроса API обычно генерируется на сервере. Однако вместо возврата JSON-ответа статические веб-API генерируют изображение, которое можно встроить в сгенерированный HTML-код. Что ещё важнее, обычно именно клиентская часть , а не сервер, обращается к сервису платформы Google Карт.

Используйте цифровую подпись

Рекомендуется всегда использовать цифровые подписи в дополнение к ключу API. Также определите, сколько неподписанных запросов вы готовы разрешить в день, и соответствующим образом скорректируйте квоты на неподписанные запросы .

Более подробную информацию о цифровых подписях см. в Руководстве по цифровым подписям .

Защитите свой секрет подписи

Для защиты статических веб-API не встраивайте секреты подписи API непосредственно в код или в исходный код, а также не раскрывайте их в клиентских приложениях. Следуйте этим рекомендациям по защите секретов подписи:

  • Сгенерируйте подписанные URL-адреса запросов Maps Static API и Street View Static API на стороне сервера при обслуживании веб-страницы или в ответ на запрос из вашего мобильного приложения .

    Для статического веб-контента можно использовать виджет «Подписать URL сейчас» на странице учетных данных платформы Google Карт Cloud Console.

    Для динамического веб-контента см. доступные примеры кодов подписи URL-запросов.

  • Храните секреты подписи вне исходного кода и дерева исходного кода вашего приложения . Если вы помещаете секреты подписи или любую другую конфиденциальную информацию в переменные окружения или включаете файлы, хранящиеся отдельно, а затем делитесь своим кодом, то секреты подписи не включаются в общие файлы. Если вы храните секреты подписи или любую другую конфиденциальную информацию в файлах, размещайте их вне дерева исходного кода вашего приложения, чтобы ваши секреты подписи не попали в систему управления исходным кодом. Эта мера предосторожности особенно важна, если вы используете общедоступную систему управления исходным кодом, например GitHub.

Защитите ключи API веб-сервиса

Информацию о безопасном использовании API и служб платформы Google Карт из клиентских приложений см. в разделах Использование клиентских SDK и Безопасные вызовы клиентских веб-служб .

Храните ключи API вне исходного кода или дерева исходного кода вашего приложения . Если вы помещаете ключи API или любую другую информацию в переменные окружения или включаемые файлы, хранящиеся отдельно, а затем делитесь своим кодом, ключи API не включаются в общие файлы. Это особенно важно, если вы используете общедоступную систему управления исходным кодом, например GitHub.

To help shield your web service API key against accidental use, Google recommends applying API restrictions to any key used for Maps Platform. Furthermore, also applying IP address restrictions to your web service key will protect it against help protect it against unauthorized use from other source IP addresses, even if the key accidentally leaks.

Используйте OAuth для серверных приложений

OAuth 2.0 is an open standard for access delegation.

While the OAuth 2.0 protocol supports use cases, where an end user authorizes an application to access personal data on their behalf, the intended use case for OAuth 2.0 with Maps Platform is for the developer to utilize temporary access tokens for authorizing their application to call an API on behalf of their Google Cloud project service account with the permissions of the service account.

As a service account may have extremely broad permissions, OAuth 2.0 is recommended for authorizing server-to-server calls between a developer's trusted server-side applications and Google's Maps Platform servers.

For client-side applications running on end user devices, other authentication methods, such as API keys, are recommended.

If you want to use OAuth 2.0 to authorize server-to-server traffic, look for the OAuth topic in your API documentation.

For example, here is the OAuth topic for the Address Validation API .

Безопасные вызовы клиентских веб-сервисов

If client-side SDKs are not available, see the recommendations below.

Используйте прокси-сервер

Using a secure proxy server provides a solid source for interacting with a Google Maps Platform web service endpoint from a client-side application without exposing your API key, signing secret or Google Cloud service account to unauthorized users.

Ключевые моменты:

  • Construct your Google Maps Platform requests on the proxy server. Don't allow clients to relay arbitrary API calls using the proxy.

  • Post-process the Google Maps Platform responses on your proxy server. Filter out data that the client doesn't need.

For more information about using a proxy server, see Living Vicariously: Using Proxy Servers with the Google Data API Client Libraries .

Безопасные прямые вызовы мобильных веб-сервисов

If you are unable to set up a secure proxy server for your client-side app, secure your application using the following steps:

  1. Use HTTP headers:

    • Android : Use the X-Android-Package and X-Android-Cert HTTP headers.

    • iOS : Use the X-Ios-Bundle-Identifier HTTP header.

  2. Add the corresponding application restrictions to your Android or iOS key.

  3. Before you consider issuing calls directly from your mobile application to a Google Maps Platform REST API web service, verify that requests with incorrect Android or iOS application identifiers are rejected.

    If Android and iOS application restrictions are not supported on the tested endpoint, Google strongly recommends that you use a secure proxy server between your mobile clients and the Google Maps Platform web service endpoint.

Tips for Android applications:

  • Before you integrate your Android application with Google Maps Platform services, verify that your application ID (also called package name) is formatted correctly. For details, see Configure app module . in the Android documentation.

  • To pass X-Android-Package directly from your application, look it up programmatically using Context.getPackageName() .

  • To pass X-Android-Cert directly from your applications, calculate the required SHA-1 fingerprint of your application signing certificates, accessible through PackageInfo.signingInfo .

  • If you authorize your Android application using the Google Cloud console, note that the UI expects the SHA-1 fingerprint to be a colon-delimited string, eg, 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33 . However, the gcloud tool and the API keys API expect the hexadecimal string without delimiters.

Tips for iOS applications:

  • Before you integrate your iOS application with Google Maps Platform services, verify that your Bundle ID is formatted correctly .

  • You should typically always pass the Bundle ID of your main bundle in the X-Ios-Bundle-Identifier header, when authorizing your iOS application.

For further information, refer to articles Manage API keys and Use API keys to access APIs .

Размещайте свои браузерные приложения на сервере

Frameworks, such as Apache Cordova, allow you to conveniently create multi-platform hybrid apps running inside a webview. However, API key website restrictions are not guaranteed to work correctly, unless your web app is loaded using HTTP or HTTPS from a website that you control and have authorized.

Bundled resources, loaded locally from within a hybrid application, or accessed using a local file URL will in many cases prevent referrer based authorization from working as the browser engine powering your webview will omit sending the Referer header. To avoid this, host your web applications server-side, not client-side.

Alternatively, for mobile applications, consider using available native Google Maps Platform Android and iOS SDKs, instead of using a web based SDK.

Используйте App Check для защиты вашего ключа API

Certain Maps SDKs and APIs allow you to integrate with Firebase App Check . App Check provides protection for calls from your app to Google Maps Platform by blocking traffic that comes from sources other than legitimate apps. It does this by checking for a token from an attestation provider. Integrating your apps with App Check helps to protect against malicious requests, so you're not charged for unauthorized API calls.

App Check integration instructions:

Бороться с несанкционированным использованием ключа API

If you detect use of your API key that is unauthorized, do the following to address the problem:

  1. Restrict your keys : If you've used the same key in multiple apps, migrate to multiple API keys, and use separate API keys for each app. For more details, see:

  2. If you use the Places SDK or the Maps Javascript API, you can also use App Check to secure your API Key .

  3. Only replace or rotate keys if the following is true:

    • You detect unauthorized usage on keys that either cannot be restricted or are already restricted, and App Check is not applicable.

    • You want to move more quickly to secure your API key and stop the abuse, even if it might impact legitimate traffic from your application.

    Before proceeding, read through Be careful when rotating API keys .

  4. If you are still having issues or need help, contact support .

Рекомендуемые ограничения приложений и API

The following sections suggest appropriate application and API restrictions for each Google Maps Platform API, SDK or service.

Рекомендуемые ограничения API

The following guidelines for API restrictions apply to all Google Maps Platform services:

  • Restrict your API key to only the APIs you are using it for, with the following exceptions:

    • If your app uses the Places SDK for Android or Places SDK for iOS, authorize Places API (New) or Places API, depending on the SDK versions you use. 1

    • If your app uses Maps JavaScript API, always authorize it on your key.

    • If you also use any of the following Maps JavaScript API services, you should also authorize these corresponding APIs:

      Услуга Ограничение API
      Directions Service (Legacy) API маршрутов (устаревший)
      Distance Matrix Service (Legacy) API матрицы расстояний (устаревший)
      Служба подъема API высоты
      Служба геокодирования API геокодирования
      Place class, Place Autocomplete Widget (New) & Place Autocomplete Data API Places API (New) 2
      Places Library, Places Service & Place Autocomplete Widget Places API 2

1 For more details, see the Places SDK for Android and Places SDK for iOS documentation.

2 If you are unsure if you need to authorize Places API (New) or Places API, see the Maps JavaScript API documentation.

Вот несколько примеров:

  • You are using the Maps SDK for Android and Places SDK for Android, so you include the Maps SDK for Android and Places API (New) as API restrictions.

  • Your website uses the Maps JavaScript API Elevation Service and the Maps Static API, so you add API restrictions for all of the following APIs:

    • API JavaScript Карт
    • API высоты
    • Статический API Карт

Recommended application Restriction

Веб-сайты

For websites using Maps JavaScript API services, Maps Static API or Street View Static API or calling recent Google Maps Platform services directly over the HTTPS REST API or gRPC, use the Websites application restriction:

1 For mobile applications, consider using the native Maps SDK for Android and Maps SDK for iOS .

2 For mobile applications, consider using the native Places SDK for Android and Places SDK for iOS .

3 See also Protect Static Web API usage .

Websites with the Maps Embed API

While using the Maps Embed API is no charge, you should still restrict any used API key to prevent abuse on other services.

Best practice : Create a separate API key for Maps Embed API use, and restrict this key to only the Maps Embed API. This restriction sufficiently secures the key, preventing its unauthorized use on any other Google service. For full control over where your Maps Embed API key can be used from, Google recommends also applying Websites application restrictions.

If you are unable to separate your Maps Embed API usage to a separate API key, secure your existing key using the Websites application restriction.

Apps and servers using web services

For servers and client-side apps from trusted corporate internal networks using web services together with API keys, use the IP addresses application restriction.

Используйте для приложений и серверов, использующих следующие API:

4 Для мобильных приложений рассмотрите возможность использования Navigation SDK.

5 Для безопасного использования мобильного устройства используйте защищенный прокси-сервер .

6 Для клиентских приложений рассмотрите возможность использования собственной службы геолокации, предлагаемой платформой; например, W3C Geolocation для веб-браузеров, LocationManager или Fused Location Provider API для Android или фреймворк Apple Core Location для iOS.

7 Для мобильных приложений рассмотрите возможность использования собственного Places SDK для Android и Places SDK для iOS .

8 Для безопасного использования на стороне клиента используйте защищенный прокси-сервер .

Android-приложения

For apps on Android, use the Android apps application restriction. Use for apps using these SDKs:

Кроме того, предотвратите случайную проверку ключей API в системе контроля версий, используя плагин Secrets Gradle для внедрения секретов из локального файла, а не сохранения их в манифесте Android.

приложения для iOS

For apps on iOS, use the iOS apps application restriction. Use for apps and servers using these SDKs:

Дальнейшее чтение