Эта страница переведена с помощью Cloud Translation API.

Рекомендации платформы 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, см. в Руководстве по цифровым подписям .

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

Тип ограничения	Описание
Веб-сайты	Укажите один или несколько сайтов-источников перехода. Универсально поддерживаемые схемы 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, которое вы хотите авторизовать. Выберите приложения Android . Нажмите + Добавить . Введите название пакета и отпечаток сертификата 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 Нажмите «Сохранить» . Существует два типа сертификатов: Отладочный сертификат : используйте этот тип сертификата только с тестируемыми приложениями и другим непроизводственным кодом. Не пытайтесь опубликовать приложение, подписанное отладочным сертификатом. Инструменты Android SDK автоматически генерируют этот сертификат при запуске отладочной сборки. Сертификат выпуска : используйте этот сертификат, когда будете готовы выпустить приложение в магазине приложений. Инструменты Android SDK генерируют этот сертификат при запуске сборки выпуска. Дополнительную информацию о подписи и сертификатах приложений Android см. в руководстве «Подпишите свое приложение» . Если вы используете Play App Signing , чтобы получить отпечаток сертификата подписи, см. раздел Работа с поставщиками API . Если вы управляете собственным ключом подписи, см. раздел Самостоятельное подписание приложения или инструкции для вашей среды сборки.
приложения для iOS	Добавьте идентификатор пакета каждого приложения iOS, которое вы хотите авторизовать. Выберите приложения iOS . Нажмите + Добавить . Добавьте идентификатор пакета, чтобы принимать запросы от приложения iOS с этим идентификатором. Нажмите «Сохранить» .

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

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Выберите ключ API, который вы хотите ограничить.
На странице «Изменить ключ API» в разделе «Ограничения API» :
- Выберите Ограничить ключ .
- Откройте Select APIs и выберите API или SDK, к которым ваше приложение должно получить доступ с помощью ключа API.
Если API или SDK отсутствуют в списке, их необходимо включить. Подробнее см. в разделе Включение одного или нескольких API или SDK .
Выберите Сохранить .
После этого шага ограничение становится частью определения ключа 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 используйте эти отчёты для создания списка API для авторизации или для проверки автоматически сгенерированных рекомендаций по ограничениям ключей API. Подробнее о рекомендуемых ограничениях см. в разделе Применение рекомендуемых ограничений . Подробнее об использовании обозревателя метрик см. в разделе Создание диаграмм с помощью обозревателя метрик .

Перейдите в обозревателе метрик консоли Google Cloud.
Войдите в систему и выберите проект для ключей API, которые вы хотите проверить.
Перейдите на страницу обозревателя метрик для вашего типа API:
- Для ключей API, использующих любой API , кроме Maps Embed API : перейдите на страницу обозревателя метрик .
- Для ключей API, использующих Maps Embed API : перейдите в Metrics Explorer .
Проверьте каждый ключ API:
1. Выберите ДОБАВИТЬ ФИЛЬТР .
2. Выберите метку credential_id .
3. Выберите значение , соответствующее ключу, который вы хотите проверить.
4. Обратите внимание, для каких API используется этот ключ API, и подтвердите, что такое использование является ожидаемым.
5. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.
Повторите эти действия для всех оставшихся ключей.
Ограничьте свои API-ключи только теми API, которые используются.
Если вы обнаружили несанкционированное использование, см. раздел Обработка несанкционированного использования ключа API .

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

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

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

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

Перейдите в обозревателе метрик консоли Google Cloud.
Войдите в систему и выберите проект для API, которые вы хотите проверить.
Перейдите на эту страницу обозревателя метрик: Обозреватель метрик .
Проверьте каждый ключ API:
1. Выберите ДОБАВИТЬ ФИЛЬТР .
2. Выберите метку credential_id .
3. Выберите значение , соответствующее ключу, который вы хотите проверить.
4. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.
Повторите эти действия для всех оставшихся ключей.
Указав тип платформы для ключей 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. Если вам не нужно срочно ограничить доступ к ключу, например, из-за несанкционированного использования, вы можете подождать день или два, пока рекомендации не появятся.
  Совет: в экстренной ситуации см. раздел Действия при несанкционированном использовании ключа API .

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

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

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

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

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

Если вы заметили, что приложение или веб-сайт отклоняется после применения ограничения, найдите ограничение приложения, которое необходимо добавить, в сообщении об ошибке ответа 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 .

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

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

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

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

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

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Выберите ключ API, который вы хотите удалить.
Нажмите кнопку «Удалить» в верхней части страницы.
На странице «Удаление учетных данных» выберите Удалить .
Распространение удаления API-ключа занимает несколько минут. После завершения распространения любой трафик, использующий удалённый API-ключ, отклоняется.

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

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

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

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

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

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

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

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

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

Определите, каким приложениям нужны новые ключи :
- Веб-приложения обновлять проще всего, поскольку вы контролируете весь код. Запланируйте обновление ключей всех ваших веб-приложений.
- С мобильными приложениями все гораздо сложнее, поскольку вашим клиентам придется обновить свои приложения, прежде чем можно будет использовать новые ключи.
Создайте и ограничьте новые ключи : добавьте ограничение для приложения и как минимум одно ограничение API. Подробнее см. в разделе «Рекомендуемые практики» .
Добавьте новые ключи в свои приложения : для мобильных приложений этот процесс может занять несколько месяцев, пока все ваши пользователи не обновятся до последней версии приложения с новым ключом 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 Maps из клиентских приложений см. в разделах «Использование клиентских SDK» и «Безопасные вызовы клиентских веб-служб» .

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

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

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

OAuth 2.0 — это открытый стандарт делегирования доступа.

Хотя протокол OAuth 2.0 поддерживает варианты использования, когда конечный пользователь разрешает приложению получать доступ к личным данным от его имени, предполагаемый вариант использования OAuth 2.0 с платформой Карт заключается в том, что разработчик использует временные токены доступа для авторизации своего приложения для вызова API от имени своего сервисного аккаунта проекта Google Cloud с разрешениями сервисного аккаунта.

Поскольку учетная запись службы может иметь чрезвычайно широкие разрешения, OAuth 2.0 рекомендуется для авторизации межсерверных вызовов между доверенными серверными приложениями разработчика и серверами платформы Google Maps.

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

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

Например, вот тема OAuth для API проверки адреса .

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

Если клиентские SDK недоступны , см. рекомендации ниже.

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

Использование безопасного прокси-сервера обеспечивает надежный источник для взаимодействия с конечной точкой веб-службы платформы Google Maps из клиентского приложения без раскрытия вашего ключа API, подписи секретного аккаунта или учетной записи службы Google Cloud неавторизованным пользователям.

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

Создавайте запросы к платформе Google Maps на прокси-сервере. Не разрешайте клиентам ретранслировать произвольные вызовы API с помощью прокси.
Выполните постобработку ответов платформы Google Maps на своем прокси-сервере. Отфильтруйте данные, которые не нужны клиенту.

Дополнительную информацию об использовании прокси-сервера см. в разделе «Замещающая жизнь: использование прокси-серверов с клиентскими библиотеками API данных Google» .

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

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

Используйте HTTP-заголовки:
- Android : используйте HTTP-заголовки X-Android-Package и X-Android-Cert .
- iOS : используйте HTTP-заголовок X-Ios-Bundle-Identifier .
Добавьте соответствующие ограничения приложения в свой ключ Android или iOS.
Важно! Ограничения приложений Android и iOS могут не полностью поддерживаться в старых устаревших службах платформы Google Maps.
Прежде чем рассматривать возможность выполнения вызовов непосредственно из мобильного приложения в веб-службу REST API платформы Google Карт, убедитесь, что запросы с неправильными идентификаторами приложений Android или iOS отклоняются.
Если ограничения приложений Android и iOS не поддерживаются на тестируемой конечной точке, Google настоятельно рекомендует использовать безопасный прокси-сервер между вашими мобильными клиентами и конечной точкой веб-службы платформы Google Maps.

Советы по приложениям Android:

Прежде чем интегрировать приложение Android со службами платформы Google Maps, убедитесь, что идентификатор вашего приложения (также называемый именем пакета) отформатирован правильно. Подробности см. в разделе Настройка модуля приложения . в документации Android.
Чтобы передать X-Android-Package непосредственно из вашего приложения, найдите его программно, используя Context.getPackageName() .
Чтобы передать X-Android-Cert непосредственно из ваших приложений, рассчитайте необходимый отпечаток SHA-1 сертификатов подписи вашего приложения, доступный через PackageInfo.signingInfo .
Важно! Обязательно передайте дайджест SHA-1 сертификата подписи и преобразуйте полученный 20-байтовый дайджест в строку в кодировке Base16 (шестнадцатеричную) без каких-либо разделителей или префиксов при настройке заголовка, например, 00112233445566778899AABBCCDDEEFF00112233 .
Если вы авторизуете свое приложение Android с помощью консоли Google Cloud, обратите внимание, что пользовательский интерфейс ожидает, что отпечаток SHA-1 будет строкой, разделенной двоеточиями, например, 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33 . Однако инструмент gcloud и API ключей API ожидают шестнадцатеричную строку без разделителей.

Советы по приложениям iOS:

Прежде чем интегрировать приложение iOS со службами платформы Google Maps, убедитесь, что идентификатор пакета имеет правильный формат .
Обычно при авторизации приложения для iOS всегда следует передавать идентификатор основного пакета в заголовке X-Ios-Bundle-Identifier .

Дополнительную информацию см. в статьях «Управление ключами API» и «Использование ключей API для доступа к API» .

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

Платформы, такие как Apache Cordova, позволяют удобно создавать многоплатформенные гибридные приложения, работающие внутри веб-представления. Однако ограничения веб-сайта по ключу API не гарантируются корректной работой, если только ваше веб-приложение не загружается по протоколу HTTP или HTTPS с веб-сайта, который вы контролируете и авторизовали.

Связанные ресурсы, загружаемые локально из гибридного приложения или доступные с использованием URL-адреса локального файла, во многих случаях препятствуют работе авторизации на основе реферера, поскольку движок браузера, обеспечивающий работу вашего веб-представления, не будет отправлять заголовок Referer . Чтобы избежать этого, размещайте свои веб-приложения на стороне сервера, а не на стороне клиента.

В качестве альтернативы для мобильных приложений рассмотрите возможность использования доступных SDK для Android и iOS платформы Google Maps вместо использования веб-SDK.

Используйте проверку приложений, чтобы защитить свой ключ API

Некоторые SDK и API Карт позволяют интегрироваться с Firebase App Check . Проверка приложений обеспечивает защиту вызовов из вашего приложения на платформу Google Maps, блокируя трафик, поступающий из источников, отличных от законных приложений. Это делается путем проверки токена от поставщика аттестации. Интеграция ваших приложений с App Check помогает защитить их от вредоносных запросов, поэтому с вас не будет взиматься плата за несанкционированные вызовы API.

Инструкции по интеграции App Check:

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

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

Ограничьте использование ключей . Если вы использовали один и тот же ключ в нескольких приложениях, перейдите на несколько ключей API и используйте отдельные ключи API для каждого приложения. Более подробную информацию см.:
Если вы используете Places SDK или Maps Javascript API, вы также можете использовать проверку приложений для защиты своего ключа API .
Заменяйте или поворачивайте ключи только в том случае, если верно следующее:
- Вы обнаруживаете несанкционированное использование ключей, которые либо не могут быть ограничены, либо уже ограничены, и проверка приложений не применима.
- Вы хотите действовать быстрее, чтобы защитить свой ключ API и прекратить злоупотребления, даже если это может повлиять на законный трафик из вашего приложения.
Прежде чем продолжить, прочтите Будьте осторожны при смене ключей API .
Если у вас по-прежнему возникают проблемы или вам нужна помощь, обратитесь в службу поддержки .

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

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

Услуга	Ограничение API
Служба маршрутов (устаревшая версия)	API маршрутов (устаревшая версия)
Дистанционная матричная служба (устаревшая версия)	API матрицы расстояний (устаревшая версия)
Служба высотных работ	API возвышения
Служба геокодирования	API геокодирования
Класс Place, виджет автозаполнения места (новый) и API данных автозаполнения места	API мест (новое) ²
Библиотека адресов, служба адресов и виджет автозаполнения мест	API мест ²

Рекомендации платформы Google Карт по безопасности Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

Рекомендуется для всех вариантов использования API-ключа

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

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

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

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

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

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

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