制限付きスコープの検証

特定の Google API（を受け入れる API） Sensitive または 制限付き スコープ） 消費者データへのアクセス権限を求めるアプリに関する要件がある。 制限付きスコープの追加要件 許可されている種類の申請であることをアプリが証明し、 セキュリティ評価などの追加審査を実施します。

API 内の制限付きスコープの適用性は、アプリで関連する機能を提供するために必要なアクセスの程度（読み取り専用、書き込み専用、読み取りと書き込みなど）によって大きく異なります。

OAuth 2.0 を使って Google アカウントからこのデータへのアクセスを許可する際は、 スコープと呼ばれる文字列で、アクセスするデータの種類とアクセスのレベルを指定します。 できます。アプリが sensitive または restricted スコープの場合は、検証を完了する必要があります。 例外は認められません。

制限付きスコープは、機密性の高いスコープに比べて数が少なくなっています。<ph type="x-smartling-placeholder"> </ph> の確認 OAuth API の確認に関するよくある質問には、機密スコープと制限付きスコープの現在のリストが含まれています。 これらのスコープは Google ユーザーデータへの幅広いアクセスを提供するため、スコープの検証を受ける必要があります リクエストする必要があります。この要件について詳しくは、Google API サービスのユーザーデータに関するポリシーと特定の API スコープに関する追加要件、またはプロダクト固有の Google デベロッパー ページをご覧ください。制限付きスコープのデータをサーバーで保存または送信する場合は、セキュリティ評価を完了する必要があります。

制限付きスコープについて

アプリが制限付きスコープをリクエストしていて、例外の対象とならない場合は、Google API サービスのユーザーデータに関するポリシーの特定の API スコープの追加要件、またはプロダクトの Google デベロッパー ページに記載されているプロダクト固有の要件を満たす必要があります。この場合、より詳細な審査プロセスが必要になります。

スコープの使用状況を把握する

  • アプリで使用しているスコープまたは使用するスコープを確認します。既存のスコープの使用状況を確認するには アプリのソースコードを調べて、認可リクエストで送信されたスコープの有無を確認する。
  • リクエストされた各スコープが、アプリ機能の意図するアクションに必要かどうかを判断します 機能を提供するために必要な最小権限を使用します。Google API は通常 プロダクトの に関するリファレンス ドキュメント Google デベロッパー ページをご覧ください。このページには、 特定のプロパティを指定できますアプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。 For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
  • Google API から受け取るデータは、 実際にどのように API を使用するかを、アプリのアクションと 。
  • 各スコープの詳細については、API ドキュメントを参照してください。 sensitive or restricted ステータス。
  • アプリで使用するすべてのスコープを の OAuth 同意画面 構成スコープのページです指定したスコープは、機密性の高いスコープまたは制限付きスコープのカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
  • 統合で使用されているデータに最適なスコープを見つけて、その用途を理解する テスト環境ですべてが機能することを再度確認し、 確認します。

キャンペーンを立ち上げる計画では、適格性確認の完了に要する時間を考慮 新しいスコープを必要とする新機能に対して 自動的に適用されます以下の追加要件のいずれかに該当する： アプリがサーバーからまたはサーバーから Google のユーザーデータにアクセスする場合。イン そのような場合は、システムに対して 独立した第三者評価機関によるセキュリティ評価 Google によって承認されている 必要がありますこのため、制限付きスコープの確認プロセスでは、 完了するまでに数週間かかる場合があります。なお、すべてのアプリは ブランド 確認のステップを完了する（ブランディング情報の確認には通常 2 ～ 3 営業日かかります） は、最後に承認された OAuth 同意画面検証以降に変更されています。

許可されるアプリケーション タイプ

特定のアプリケーション タイプでは、各プロダクトの制限付きスコープにアクセスできます。詳しくは、 アプリケーションタイプに関する Google デベロッパー ページ（Gmail API ポリシーなど）。

アプリの種類を理解して決定することは、パブリッシャー様の責任となります。ただし、アプリのアプリケーションの種類が不明な場合は [no] を選択できます。 確認を受けるためにアプリを送信する際に、「どの機能を使用しますか？」の質問に回答する必要があります。 Google API の検証チームがアプリケーションの種類を判断します。

セキュリティの評価

Google ユーザーのアクセス権をリクエストするすべてのアプリ制限されたデータにアクセスし、 サードパーティ サーバーとの間で送受信されるデータは、Google でセキュリティ評価を受ける必要があります。 Google が主導するセキュリティ評価者。この評価により、Google ユーザーのデータを安全に保護する Google ユーザーデータにアクセスするすべてのアプリについて、データを処理する能力が実証されていることを ユーザーのリクエストに応じてユーザーデータを削除できます。

セキュリティ評価を標準化するために、 App Defense Alliance および 。

前述のとおり、検証済みの制限付きスコープへのアクセスを維持するには、アプリが セキュリティ評価を 12 か月ごとに 査定者の評価書（LOA）の承認日。アプリで新しい制限付きスコープを追加すると、 事前適用の対象範囲に含まれていなかった場合は、追加の対象範囲をカバーするためにアプリの再評価が必要になることがあります。 セキュリティ診断を行います

アプリの再認定が必要になりましたら、Google 審査チームからメールでお知らせします。新しい P-MAX キャンペーンを この年間適用について適切な担当者に通知し、追加の Google Cloud リソースに プロジェクトがオーナーまたは 。また、ユーザー サポートやデベロッパーの連絡先メールアドレスを、 Google OAuth の 。

適格性確認の準備の手順

Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、 ブランド確認を完了:

  1. アプリが 適格性確認の要件の例外
  2. 関連する API のブランディング要件にアプリが準拠していることを確認する。または、 説明します。たとえば、ブランドの取り扱いガイドラインをご覧ください。 有効にする必要があります
  3. プロジェクトの 承認済みドメイン Google Search Console。 プロジェクトにオーナーまたは編集者として関連付けられている Google アカウントを使用します。
  4. OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。

アプリケーション ホームページの要件

ホームページが次の要件を満たしていることを確認します。

  • ホームページは、サイトのログイン アクセスだけではなく、一般公開されている必要があります できます。
  • ホームページと審査中のアプリの関連性は明確でなければなりません。
  • Google Play ストアや Google Play の Facebook ページ上のアプリの掲載情報へのリンクは考慮されません。 有効なアプリケーションのホームページ

アプリケーション プライバシー ポリシー リンクの要件

アプリのプライバシー ポリシーが次の要件を満たしていることを確認してください。

  • プライバシー ポリシーは、 表示され、Google Cloud の OAuth 同意画面に 。ホームページには、アプリの機能の説明と、プライバシー ポリシーと利用規約（任意）へのリンクを含める必要があります。
  • プライバシー ポリシーでは、アプリが Google Cloud のデータにアクセスする、 Google のユーザーデータを保存、共有します。 The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Google のユーザーデータの使用は、お客様が公開した方法に限定する必要があります。 開示すること。
  • Review example cases of privacy policies that don't meet the Limited Use requirements.

検証用にアプリを送信する方法

プロジェクトは、 リソースをご覧ください。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ関連付けられた Google アカウント、有効な API のセット、それらの API の課金、認証、モニタリングの設定で構成されます。たとえば、プロジェクトに 1 つ以上の OAuth クライアントを含め、それらのクライアントが使用する API を構成し、アプリへのアクセスを承認する前にユーザーに表示される OAuth 同意画面を構成できます。

いずれかの OAuth クライアントが本番環境に対応していない場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは 。

確認プロセスを送信する手順は次のとおりです。

  1. アプリが Google API 利用規約、 Google API サービスのユーザーデータ ポリシー。
  2. プロジェクトに関連付けられたアカウントのオーナーと編集者のロールを最新の状態に保ち、 OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報は、 。これにより、組織の適切なメンバーが チームに新しい要件が通知されます。
  3. OAuth に移動します。
  4. [プロジェクト セレクタ] ボタンをクリックします。

  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。特典を プロジェクト ID がわかっている場合は、次のようにブラウザで URL を作成できます。 形式:

    ?project=[PROJECT_ID]

    [PROJECT_ID] は、使用するプロジェクト ID に置き換えます。

  6. [Edit App] ボタンを選択します。
  7. OAuth 同意画面のページで必要な情報を入力し、[Save（保存） して続行] ボタンをクリックします。
  8. [スコープを追加または削除] ボタンを使用して、アプリがリクエストするスコープをすべて宣言します。「 Google ログインに必要なスコープの初期セットは、 非機密スコープ セクション追加されたスコープは、非機密の sensitive, or restrictedとして分類されます。
  9. アプリの関連機能に関連するドキュメントへのリンクを最大 3 つ指定します。

  10. アプリに関してリクエストされた追加情報については、後続の できます。

    1. Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.

    4. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
      5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
  11. 提供したアプリの構成で検証が必要な場合は、リクエストを送信できます。 確認する必要があります。必須フィールドに入力して [送信] をクリックし、 確認プロセスに進みます。

アプリを送信すると、Google の Trust &安全性チームは、 追加情報や必要な手順を記載します デベロッパーの連絡先情報セクションと OAuth 同意のサポートメール 追加情報を求める画面が表示されますプロジェクトの OAuth 同意画面ページで、プロジェクトの現在の審査ステータス（Google が回答を待機している間に審査プロセスが一時停止されているかどうかなど）を確認することもできます。

適格性確認の要件の例外

以降のセクションで説明するシナリオのいずれかでアプリを使用する場合、 審査のために送信する必要はありません。

個人的な利用

ユースケースの一例として、アプリのユーザーが自分だけの場合や、アプリを少数のユーザーしか使用しない リストがありますユーザーも少人数でも問題ないでしょう クラウド コンピューティングの 未確認アプリ 画面を開き、個人アカウントにアプリへのアクセス権を付与します。

開発、テスト、ステージング ティアで使用されるプロジェクト

目的 準拠するため、Google OAuth 2.0 のポリシーを 本番環境にデプロイできます。Google アカウントを持つすべてのユーザーがアプリを使用できるようにする場合にのみ、アプリの確認を送信することをおすすめします。そのため、アプリで が開発、テスト、ステージングのいずれかの段階にある場合、確認は必要ありません。

アプリが開発フェーズまたはテストフェーズの場合は、 公開ステータス デフォルトの テスト。この設定は、アプリがまだ開発中で、 テストユーザーのリストに追加したユーザーにのみ公開されます。Google アカウントのリストを管理する必要があります。 さまざまなプロセスについて説明します。

テスト中のアプリが Google で確認されていないことを示す警告メッセージ。
図 1. テスターの警告画面

サービス所有のデータのみ

アプリがサービス アカウントを使用して自身のデータにのみアクセスし、どのユーザーにもアクセスしない場合 データ（Google アカウントにリンクされているもの）がある場合は、確認のために送信する必要はありません。

サービス アカウントの概要については、このモジュールの 次のサービス アカウント: ドキュメントをご覧くださいサービス アカウントの使用方法については、以下をご覧ください。 サーバー間での OAuth 2.0 の使用 説明します。

社内専用

つまり、そのアプリは Google Workspace または Cloud Identity 内のユーザーのみが使用する 組織です。プロジェクトは組織が所有している必要があります。また、OAuth 同意画面は内部ユーザータイプ用に構成する必要があります。この場合、アプリは組織管理者の承認を必要とする可能性があります。対象 詳細については、以下をご覧ください。 その他の Google Workspace に関する考慮事項をご覧ください。

ドメイン全体のインストール

Google Workspace または Cloud Identity のユーザーのみをターゲットとするアプリの予定がある場合 常にドメイン全体で インストールの場合、アプリの確認は必要ありません。これはドメイン全体で インストールすることで、ドメイン管理者はサードパーティおよび内部のアプリケーションに ユーザーのできます。組織にアプリケーションを追加できるアカウントは、組織管理者だけです。 許可リストへの登録が必要です

アプリをドメイン全体のインストールにする方法については、よくある質問をご覧ください アプリケーションに 企業アカウントを別の Google Workspace ドメインから取得する。