В этом руководстве показано, как обеспечить безопасность вашего приложения и учетных данных пользователей.
Завершите проверку приложения OAuth.
Область действия OAuth 2.0 для Google Ads API классифицируется как ограниченная , что означает, что вам следует завершить процесс проверки приложения OAuth перед запуском приложения в производство. Для получения дополнительной информации см. документацию Google Identity , статью в Справочном центре о непроверенных приложениях и документацию по настройке экрана согласия OAuth .
Защитите учетные данные приложения.
Необходимо обеспечить безопасность идентификатора клиента OAuth 2.0 и секретного ключа вашего приложения. Эти учетные данные помогают пользователям и Google идентифицировать ваше приложение, поэтому с ними следует обращаться осторожно. Относитесь к этим учетным данным приложения как к паролям. Не передавайте их с помощью небезопасных механизмов, таких как публикация на публичных форумах, отправка файлов конфигурации, содержащих эти учетные данные, во вложениях к электронным письмам, жесткое кодирование учетных данных или их размещение в репозитории кода. По возможности рекомендуется использовать менеджер секретов, например, Google Cloud Secret Manager или AWS Secret Manager .
Если ваши секретные ключи клиента OAuth 2.0 скомпрометированы, вы можете их сбросить . Также можно сбросить токен разработчика.
Защитите токен разработчика
Токен разработчика позволяет совершать вызовы API к учетной записи, но не имеет ограничений на то, с какими учетными записями его можно использовать для этих вызовов. В результате, скомпрометированный токен разработчика может быть использован кем-то другим для совершения вызовов, приписываемых вашему приложению. Чтобы избежать этого сценария, примите следующие превентивные меры:
Относитесь к своему токену разработчика как к паролю. Не передавайте его с помощью небезопасных механизмов, таких как публикация на публичных форумах или отправка файлов конфигурации, содержащих токены разработчика, в качестве вложения в электронное письмо. По возможности мы рекомендуем использовать менеджер секретов, например, Google Cloud Secret Manager или AWS Secret Manager .
Если ваш токен разработчика скомпрометирован, вам следует его сбросить.
- Войдите в учетную запись Google Ads Manager, которую вы использовали при подаче заявки на Google Ads API.
- Перейдите в раздел Инструменты и настройки > Центр API .
- Нажмите на стрелку раскрывающегося списка рядом с пунктом «Токен разработчика» .
- Нажмите на ссылку «Сбросить токен» . Ваш старый токен разработчика должен немедленно перестать работать.
- Обновите конфигурацию вашего приложения для производственной среды, чтобы использовать новый токен разработчика.
Обеспечьте безопасность учетных записей служб.
Если вы используете служебные учетные записи, обеспечьте их безопасность следующим образом:
- Рассматривайте ключ учетной записи службы и JSON-файл как пароли. По возможности защитите их с помощью менеджера секретов, например, Google Cloud Secret Manager или AWS Secret Manager .
- Для обеспечения безопасности и управления учетными записями служб следуйте дополнительным рекомендациям Google Cloud.
Защитите пользовательские токены
Если ваше приложение авторизует нескольких пользователей, вам следует предпринять дополнительные шаги для защиты токенов обновления и доступа пользователей. Храните токены в защищенном состоянии и никогда не передавайте их в открытом виде. Используйте надежную систему хранения, подходящую для вашей платформы.
Обработка отзыва и истечения срока действия токенов обновления.
Если ваше приложение запрашивает токен обновления OAuth 2.0 в рамках авторизации, вы также должны обрабатывать его аннулирование или истечение срока действия. Токены обновления могут быть аннулированы по различным причинам , и ваше приложение должно корректно реагировать, либо повторно авторизуя пользователя при следующем входе в систему, либо удаляя его данные соответствующим образом. Автономные задачи, такие как задачи cron, должны обнаруживать и регистрировать учетные записи, у которых истек срок действия токенов обновления, вместо того, чтобы продолжать отправлять неудачные запросы. Google может ограничивать количество ошибок, генерируемых приложениями в течение длительного периода времени, чтобы поддерживать стабильность API-серверов.
Управление согласием для различных областей применения
Если ваше приложение запрашивает авторизацию для нескольких областей действия OAuth 2.0, пользователь может не предоставить все запрошенные вами области действия OAuth. В этом случае приложение должно обрабатывать отказ в предоставлении областей действия, отключая соответствующие функции. Повторный запрос пользователю следует отправлять только после того, как он четко укажет на намерение использовать конкретную функцию, требующую данной области действия. В таких случаях используйте поэтапную авторизацию для запроса соответствующих областей действия OAuth.
Если основные функции вашего приложения требуют наличия нескольких областей доступа, объясните это требование пользователю, прежде чем запрашивать его согласие.