Ключи API необходимы для приложений и проектов, в которых используются API и SDK платформы Google Карт. Чтобы обеспечить безопасный доступ и упростить работу, настраивайте защиту ключей API сразу при их создании.
Настроить параметры безопасности для ключа API можно и после его создания, но в этом случае вы можете столкнуться с различными ограничениями (в зависимости от того, как используется ключ). Сложнее всего обновлять и заменять ключи в мобильных приложениях (для Android и iOS): пока все пользователи не обновят приложение, у некоторых из них будут оставаться старые ключи. Обновлять и заменять ключи для решений на базе JavaScript и веб-приложений намного проще, но даже в таких случаях иногда нужно тщательно спланировать переход и действовать максимально быстро.
Рекомендации по обеспечению безопасности для отдельных продуктов платформы Google Карт (таких как Maps JavaScript API) приведены в разделе Дополнительная информация.
Как ограничить действие ключей API
Создавая ключ API впервые, задайте ему ограничение по приложениям и одно или несколько ограничений по API.
Ограничение Допустимый тип приложений позволяет использовать ключи API только для определенных платформ (Android, iOS) или сайтов (публичных IP-адресов, URL). Для каждого ключа API можно задать только один тип приложений.
Ограничение Допустимые API позволяет использовать ключи только для конкретных API или SDK платформы Google Карт. Если настроить для ключа такие ограничения, то будут обрабатываться только запросы для выбранных API или SDK. Для одного ключа можно задать любое количество допустимых API.
Если при создании ключа API вы не задали для него настройки безопасности, создайте дополнительные ключи API с нужными настройками безопасности и обновите все свои приложения так, чтобы в них использовались новые ключи API. Из соображений безопасности рекомендуется использовать по одному ключу в каждом приложении. Однако вы можете использовать в нескольких приложениях один и тот же ключ, если заданные для него ограничения не вызовут проблем с совместимостью в этих приложениях.
Если вы настроили ограничения для ключа API после его создания, проверьте, правильно ли работают функции ваших приложений, связанные с этим ключом.
Перейдите на страницу Metrics (Показатели) в Google Cloud Console.
Выберите Show filters (Показать фильтры).
В пункте Grouped By (Способ группировки) выберите Credential (Учетные данные). Вы увидите, с какими сервисами Google используются те или иные ключи API.
Нажмите Credential (Учетные данные).
Отмените выбор для всех учетных данных.
Выберите ключ и нажмите ОК. Повторите это для всех отображаемых ключей.
В пункте Grouped By (Способ группировки) выберите API. Вы увидите, какие ограничения по API можно применить к ключу.
Если выбрать в пункте Grouped By (Способ группировки) вариант API method (Способ вызова API), то полученные данные помогут узнать, какое из ограничений по типу приложений лучше подходит для того или иного ключа.
Как настроить ограничение по типу приложений для ключа API
- Перейдите на страницу Credentials (Учетные данные).
Выберите нужный ключ API. Откроется страница со свойствами ключа API.
В разделе Key restrictions (Ограничения для ключа) нажмите Application restrictions (Допустимый тип приложений).
Выберите тип ограничения и укажите всю нужную информацию.
Тип ограничения Описание HTTP-источники перехода Укажите один или несколько сайтов – источников перехода. Можно использовать подстановочные знаки для авторизации всех субдоменов (например, если ввести значение *.google.com, то будут допускаться все сайты, у которых названия доменов оканчиваются на.google.com). Укажитеhttps://иhttp://в исходном виде. Для других типов протоколов URL источников перехода нужно использовать специальное представление. Например,file:///path/to/нужно отформатировать как__file_url__//path/to/*. Включив источники перехода, обязательно отслеживайте использование, чтобы убедиться, что оно соответствует вашим ожиданиям. Поддерживаются следующие протоколы источников перехода:about://, app://, applewebdata://, asset://, chrome://, content://, file://, ftp://, ionic://, local://, ms-appx://, ms-appx-web://, ms-local-stream://, prism://, qrc://, res://, saphtmlp://.IP-адреса Укажите один адрес IPv4 или IPv6 или подсеть в формате бесклассовой адресации (CIDR). Поскольку запрос веб-сервиса проверяет внешний IP-адрес на соответствие ограничениям ключа API, используйте общедоступный IP-адрес сервера. Приложения для Android Добавьте цифровой отпечаток сертификата для подписи SHA-1 и название пакета Android из файла AndroidManifest.xml.Приложения для iOS Выберите под списком типов нужный идентификатор пакета iOS. Нажмите Save (Сохранить).
Как задать ограничение по API для ключа API #
Перейдите на страницу Credentials (Учетные данные).
Выберите нужный ключ API. Откроется страница Restrict and rename API key (Добавление ограничений и изменение названия ключа API).
В разделе API restrictions (Допустимые API):
Нажмите Restrict key (Применить ограничения для ключа).
В раскрывающемся списке Select APIs (Выберите API) укажите нужные API или SDK. Приложение будет использовать ключ API для доступа к ним.
Если определенных API или SDK нет в списке, включите их.
Нажмите Save (Сохранить).
Заданное ограничение будет добавлено в определение ключа API. Если вы не укажете обязательные данные или не нажмете Save (Сохранить), ограничение не подействует. Более подробные сведения можно найти в руководстве по получению ключа API для нужного API или SDK.
Как удалить неиспользуемые ключи API
Проверьте, получает ли он трафик. Если трафика нет, скорее всего, ключ можно удалить.
Чтобы удалить ключ API, выполните следующие действия:
Перейдите на страницу Credentials (Учетные данные).
Выберите ключ API.
Нажмите кнопку Delete (Удалить) вверху страницы.
В появившемся диалоговом окне Delete credential (Удаление учетных данных) выберите Delete (Удалить).
После удаления ключа API может пройти несколько минут, прежде чем изменение распространится в системе. Когда этот процесс завершится, система начнет отклонять трафик с ключом API, который был удален.
Другие способы обеспечения безопасности ключей API
Будьте внимательны при повторной генерации ключей API.
При повторной генерации создается новый ключ API, имеющий те же ограничения, что и старый. При этом также запускается 24-часовой таймер на отключение старого ключа API.
В течение этого времени система принимает и старый, и новый ключ, чтобы вы могли настроить приложения на использование нового ключа. Все приложения, использующие старый ключ API, перестанут работать через 24 часа.
Откройте страницу API keys (Ключи API).
Выберите Revert to previous key (Восстановить предыдущий ключ).
В диалоговом окне Revert API key (Восстановление ключа API) нажмите Revert key (Восстановить ключ).
После отката та версия ключа, которая раньше считалась новой, становится предыдущей версией. Для нее запускается новый 24-часовой таймер на отключение. Пока новый ключ не будет сгенерирован, вы можете вносить изменения в обе версии ключа.
При новой генерации старая неактивная версия ключа будет перезаписана.
Как отслеживать использование API
Чтобы проверить, как используются ваши ключи API, выполните следующие действия:
Перейдите на страницу Показатели.
Нажмите Show filters (Показать фильтры).
В пункте Grouped by (Способ группировки) выберите API method (Способ вызова API).
В пункте Response code (Код ответа) выберите 2xx, чтобы проверить, есть ли успешно выполненные запросы с этим ключом.
Если вы обнаружили несанкционированное использование, выполните следующие действия:
Добавьте ограничения для ключей.
Если в ваших приложениях применяется один и тот же ключ, попробуйте использовать несколько ключей API. Рекомендуем настроить отдельный ключ для каждого приложения.
Если несанкционированное использование будет продолжаться, удалите эти ключи или сгенерируйте новые.
Зачем использовать разные ключи API в разных приложениях
Это ограничит область действия ключей. Если кто-то получит несанкционированный доступ к одному ключу, его можно будет удалить и сгенерировать новый, не затрагивая остальные.
Как перейти на использование нескольких ключей API
Если у вас общий ключ API для нескольких приложений, но вы хотите начать использовать разные ключи, выполните следующие действия:
Узнайте, для каких именно приложений нужно создать новые ключи.
- Веб-приложения обновлять проще других, так как вы контролируете весь код. Планируйте обновить ключи для всех веб-приложений.
- Изменять ключи в мобильных приложениях намного сложнее, поскольку нужно, чтобы все пользователи обновили приложение, прежде чем вы начнете использовать новые ключи.
Создайте новые ключи и задайте для них ограничения.
- Задайте и ограничение по типу приложений, и хотя бы одно ограничение по API.
Добавьте новые ключи в свои приложения.
- В случае мобильных приложений могут пройти месяцы, прежде чем все пользователи перейдут на версию с новым ключом API.
Методы защиты приложений с использованием Maps Web Service API и Static Web API
Храните ключи API и секреты для подписания вне репозитория исходного кода вашего приложения.. Если вы поместите ключи API и другие конфиденциальные данные в переменные среды или включаемые файлы, хранящиеся отдельно, то когда вы предоставите кому-то доступ к файлам с кодом приложения, в этих файлах не будет ключей API и секретов для подписания.
Храните ключи API и секреты для подписания в файлах, не входящих в дерево исходного кода вашего приложения. Если вы храните подобную конфиденциальную информацию в файлах, не добавляйте их в дерево исходного кода, иначе эта информация может оказаться в системе управления кодом. Это особенно важно, если вы используете общедоступную систему управления кодом, например GitHub.
Методы защиты мобильных приложений с использованием Web Service API и Static Web API.
Используйте прокси-сервер. Прокси-сервер обеспечивает безопасное взаимодействие с API платформы Google Карт. Подробнее о том, как использовать прокси-серверы с клиентскими библиотеками Google Data API…
Используйте обфускацию или шифрование. Так злоумышленникам будет сложнее извлечь из приложения ключи API, секреты для подписания и другую конфиденциальную информацию.
Дополнительная информация
В этих таблицах указаны ограничения для ключей API и рекомендации по обеспечению безопасности для каждого API, SDK и сервиса платформы Google Карт.
Сайты с Maps JavaScript API, Embed API и Static API
Приложения и серверы, использующие веб-сервисы
| API/SDK/сервис | Допустимый тип приложений (1) | Допустимые API (1) | Рекомендации |
|---|---|---|---|
| Address Validation API | IP-адреса(4) | Address Validation API | |
| Directions API | IP-адреса(4) | Directions API | |
| Distance Matrix API | IP-адреса(4) | Distance Matrix API | |
| Elevation API | IP-адреса(4) | Elevation API | |
| Geocoding API | IP-адреса(4) | Geocoding API | |
| Geolocation API | IP-адреса4 | Geolocation API | |
| Places API (5) | IP-адреса(4) | Places API | |
| Roads API | IP-адреса(4) | Roads API | |
| Time Zone API | IP-адреса(4) | Time Zone API |
Приложения для Android
| API/SDK/сервис | Допустимый тип приложений (1) | Допустимые API (1) | Рекомендации |
|---|---|---|---|
| Maps SDK для Android | Приложения для Android | Maps SDK для Android | |
| Places SDK для Android | Приложения для Android | Places API |
Приложения для iOS
| API/SDK/сервис | Допустимый тип приложений (1) | Допустимые API (1) | Рекомендации |
|---|---|---|---|
| Maps SDK для iOS | Приложения для iOS | Maps SDK для iOS | |
| Places SDK для iOS | Приложения для iOS | Places API |
1Чтобы использовать ключ API с любыми SDK или API платформы Google Карт, не обязательно настраивать для него ограничения. Однако мы настоятельно рекомендуем это сделать, особенно в следующих случаях:
тестовая среда является или будет общедоступной;
приложение, использующее ключ API, готово для перевода в рабочую среду.
2Для мобильных приложений рекомендуем использовать нативные пакеты Maps SDK для Android и Maps SDK для iOS.
3Для Maps Static API и Street View Static API требуется задать не только ключ API, но и цифровую подпись, чтобы можно было превышать квоту в 25 000 загрузок карты в день.
Если вы подписываете запросы, настройте дневную квоту неподписанных запросов.
4Ограничение по IP-адресам не всегда полезно. Например, его не стоит настраивать для мобильных приложений и облачных сред, работающих на основе динамических IP-адресов. В этих случаях для приложений с Maps Web Service API используйте прокси-сервер или обфускацию.
5Для мобильных приложений рекомендуем использовать нативные пакеты Places SDK для Android и Places SDK для iOS.