制限付きスコープの検証

一部の Google API(機密性の高いスコープまたは制限付きスコープを受け入れる API)には、コンシューマ データへのアクセス許可を求めるアプリの要件があります。制限付きスコープに関する追加要件では、アプリが許可されたアプリケーション タイプであることを証明し、追加の審査(セキュリティ評価を含む場合あり)を受ける必要があります。

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

OAuth 2.0 を使用して Google アカウントからこのデータへのアクセス許可を取得する場合は、スコープと呼ばれる文字列を使用して、アクセスするデータの種類と必要なアクセス量を指定します。アプリが機密性の高いスコープまたは制限付きスコープをリクエストする場合は、アプリの使用が例外に該当しない限り、確認プロセスを完了する必要があります。

制限付きスコープは、機密性の高いスコープに比べて数が少なくなっています。OAuth API の確認に関するよくある質問には、機密性の高いスコープと制限付きスコープの最新のリストが記載されています。これらのスコープは Google ユーザーデータへの幅広いアクセスを提供するため、Google アカウントからスコープをリクエストする前に、スコープの確認プロセスを完了する必要があります。この要件については、Google API サービスのユーザーデータに関するポリシーと特定の API スコープに関する追加要件、またはプロダクト固有の Google Developer ページをご覧ください。制限付きスコープのデータをサーバーに保存または送信する場合は、セキュリティ評価を完了する必要があります。


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

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

スコープの使用について理解する

  • アプリで使用しているスコープ、または使用するスコープを確認します。既存のスコープの使用状況を確認するには、アプリのソースコードで、認可リクエストとともに送信されたスコープを確認します。
  • リクエストされた各スコープがアプリの機能の意図されたアクションに必要であり、機能を提供するために必要な最小権限を使用していることを確認します。通常、Google API には、エンドポイントのプロダクトの Google Developers ページにリファレンス ドキュメントがあります。これには、エンドポイントまたは特定のプロパティを呼び出すために必要なスコープが含まれています。アプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。たとえば、Gmail API のみを使用してユーザーに代わってメールを送信するアプリの場合、ユーザーのメールデータへのフルアクセスを提供するスコープをリクエストしないでください。
  • Google API から受け取るデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
  • 各スコープの詳細(機密または制限付きのステータスなど)については、API ドキュメントをご覧ください。
  • アプリで使用するすべてのスコープを、Cloud コンソールのデータアクセス ページで宣言します。指定したスコープは、機密性の高いカテゴリまたは制限付きカテゴリにグループ化され、必要な追加の検証がハイライト表示されます。
  • 統合で使用されるデータに一致する最適なスコープを見つけ、その使用方法を理解し、テスト環境ですべてが引き続き機能することを確認してから、検証のために送信する準備をします。

アプリのリリース計画や、新しいスコープを必要とする新機能のリリース計画には、確認を完了するために必要な時間を必ず含めてください。これらの追加要件の 1 つは、アプリがサーバーから、またはサーバーを介して Google ユーザーデータにアクセスする場合、またはアクセスする機能がある場合に発生します。このような場合、システムは、Google が承認した独立した第三者評価者による年次のセキュリティ評価を受ける必要があります。このため、制限付きスコープの確認プロセスが完了するまでに数週間かかることがあります。すべてのアプリは、まずブランド確認の手順を完了する必要があります。前回の承認済みの OAuth 同意画面の確認以降にブランディング情報が変更されている場合、通常は 2 ~ 3 営業日かかります。


許可されるアプリケーションの種類

特定のアプリケーション タイプは、各プロダクトの制限付きスコープにアクセスできます。アプリケーション タイプは、プロダクト固有の Google Developers ページ(Gmail API ポリシーなど)で確認できます。

アプリケーションの種類を理解して判断することは、お客様の責任となります。ただし、アプリのアプリケーション タイプが本当に不明な場合は、アプリを検証のために送信するときに、[使用する機能] の質問でオプションを選択しないでください。Google API の検証チームがアプリケーションの種類を判断します。


Security assessment

Google ユーザーの制限付きデータへのアクセスをリクエストし、サードパーティ サーバーから、またはサードパーティ サーバーを介してデータにアクセスできるすべてのアプリは、Google が任命したセキュリティ評価者によるセキュリティ評価を受ける必要があります。この評価は、Google ユーザーデータにアクセスするすべてのアプリが、データを安全に処理し、ユーザーのリクエストに応じてユーザーデータを削除する能力を実証していることを確認することで、Google ユーザーのデータを安全に保つために役立ちます。

セキュリティ評価を標準化するために、App Defense Alliance と Cloud Application Security Assessment フレームワーク(CASA)を使用しています。

前述のように、確認済みの制限付きスコープへのアクセスを維持するには、アプリのコンプライアンスを再確認し、評価者の評価書(LOA)の承認日から 12 か月以内にセキュリティ評価を完了する必要があります。アプリに新しい制限付きスコープを追加する場合、以前のセキュリティ評価に含まれていなかった追加のスコープをカバーするために、アプリの再評価が必要になることがあります。

アプリの再認定が必要になると、Google の審査担当者からメールが届きます。この年次違反措置の通知がチームの適切なメンバーに届くように、Cloud コンソール プロジェクトにオーナーまたは編集者として追加の Google アカウントを関連付けてください。また、Google Cloud コンソールの OAuth ブランディング ページで指定されているユーザー サポートとデベロッパーの連絡先メールアドレスを最新の状態に保つこともできます。


確認手続きの準備手順

Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、次の手順に沿ってブランド確認を完了する必要があります。

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

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

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

  • ホームページは、サイトにログインしているユーザーだけでなく、一般公開されている必要があります。
  • 審査対象のアプリとホームページの関連性が明確である必要があります。
  • Google Play ストアのアプリの掲載情報や Facebook ページへのリンクは、有効なアプリのホームページとは見なされません。

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

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

  • プライバシー ポリシーは、ユーザーに表示され、アプリケーションのホームページと同じドメイン内でホストされ、Google API Console の OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明、プライバシー ポリシーへのリンク、利用規約(省略可)へのリンクを含める必要があります。
  • プライバシー ポリシーでは、アプリケーションが Google ユーザーデータにアクセスし、それらを使用、保存、共有する仕組みを開示する必要があります。プライバシー ポリシーは、Google API サービスのユーザーデータに関するポリシーと、制限付きスコープの限定的な使用の要件に準拠している必要があります。Google ユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている取り扱いに限定する必要があります。
  • 限定的用途の要件を満たしていないプライバシー ポリシーの例を確認します。

ブランド確認のためにアプリを送信する方法

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

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

確認を申請する手順は次のとおりです。

  1. アプリが Google API の利用規約と Google API サービスのユーザーデータに関するポリシーに準拠していることを確認します。
  2. プロジェクトに関連付けられているアカウントのオーナーロールと編集者ロールを最新の状態に保ちます。また、Cloud コンソールで OAuth 同意画面のユーザー サポートメールとデベロッパーの連絡先情報も最新の状態に保ちます。これにより、チームの適切なメンバーに新しい要件が通知されます。
  3. Cloud コンソールの OAuth の [ブランディング] ページに移動します。
  4. [プロジェクト セレクタ] ボタンをクリックします。
  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
    

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

  6. [ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。変更内容はブランディングの下書きとして保存されます。

  7. [Verify Branding] ボタンをクリックして、評価プロセスを開始します。自動システムによる審査は通常、数分で完了します。

  8. 評価が完了したら、ステータスを確認します。成功すると、ステータスが [公開準備完了] に変わります。自動検証が失敗した場合は、検出された問題を確認して修正するか、手動審査をリクエストできます。

  9. [ブランディングを公開] ボタンをクリックして、新しいブランディングを公開します。

  10. アプリで機密性の高いスコープや制限付きスコープの確認も必要な場合は、OAuth 確認センターに移動してデータアクセス ステータスを追跡し、デモ動画などのリクエストされた追加情報を提供します。データアクセス確認をリクエストするには、ブランディング ステータスが公開済みになっている必要があります。

  11. [スコープを追加または削除] ボタンを使用して、アプリからリクエストされるすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは、非機密、機密、制限付きに分類されます。

  12. アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。

  13. 以降の手順で、アプリに関する追加情報を入力します。

    1. アプリが特定の API スコープに関する追加要件に準拠していることを確認します。これには、アプリがサードパーティ サーバーから、またはサードパーティ サーバーを介して、制限付きスコープの Google ユーザーのデータにアクセスする場合に、年 1 回のセキュリティ評価を受けることが含まれます。
    2. アプリが、特定の API スコープに関する追加要件ページの限定使用セクションで指定されている許可されたタイプのいずれかであることを確認します。
    3. アプリがタスク自動化プラットフォームである場合、デモ動画では、複数の API ワークフローがどのように作成され、自動化されるか、またユーザーデータがどの方向に流れるかを示す必要があります。
    4. ユーザーがリクエストされたスコープへのアクセスを開始して許可する方法を完全に示し、許可された機密性の高いスコープと制限付きスコープの使用方法をアプリ内で詳細に示す動画を準備します。動画を YouTube Studio にアップロードし、[公開設定] を [限定公開] に設定します。YouTube リンク欄にデモ動画へのリンクを入力する必要があります。
      1. ユーザーが体験する OAuth 権限付与プロセスを英語で表示します。これには、同意フローと、Google ログインを使用する場合はログインフローが含まれます。
      2. OAuth 同意画面にアプリ名が正しく表示されていることを示す。
      3. OAuth 同意画面のブラウザのアドレスバーに、アプリの OAuth クライアント ID が正しく含まれていることを示します。
      4. データがどのように使用されるかを示すため、リクエストする機密スコープと制限付きスコープごとに有効になる機能を示します。
      5. 複数のクライアントを使用しているため、複数の OAuth クライアント ID がある場合は、各 OAuth クライアントでデータにアクセスする方法を示します。
    5. [使用する機能] リストから、許可されているアプリケーション タイプを選択します。
    6. アプリで制限付きスコープをどのように使用するか、また、より限定的なスコープでは十分でない理由を説明します。

ブランディングを公開するか、データアクセス リクエストを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡が届くことがあります。[デベロッパーの連絡先情報] セクションのメールアドレスと、OAuth 同意画面のサポートメールで、追加情報の提供を求めるメールが届いていないか確認します。プロジェクトの [ブランディング] ページまたは [確認センター] ページで、プロジェクトの現在の審査ステータスを確認することもできます。これには、お客様の回答を待つ間に審査プロセスが一時停止されているかどうかも含まれます。

適格性確認の要件の例外

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

個人的な利用

ユースケースの 1 つは、アプリのユーザーが自分だけの場合や、アプリのユーザーが数人だけで、全員が個人的に知っている場合です。デベロッパーと少数のユーザーは、未確認アプリの画面を先に進めて、個人アカウントにアプリへのアクセス権を付与しても問題ない場合があります。

開発、テスト、ステージングの各階層で使用されるプロジェクト

Google OAuth 2.0 ポリシーに準拠するため、テスト環境と本番環境に異なるプロジェクトを用意することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを利用できるようにする場合にのみ、アプリを検証に送信することをおすすめします。したがって、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。

アプリが開発フェーズまたはテストフェーズにある場合は、[公開ステータス] をデフォルト設定の [テスト] のままにしておくことができます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加されたユーザーのみが利用できることを意味します。アプリの開発またはテストに関与する Google アカウントのリストを管理する必要があります。

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

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

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

サービス アカウントの概要については、Google Cloud ドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。

社内専用

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

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

アプリが Google Workspace または Cloud Identity 組織のユーザーのみを対象とし、常にドメイン全体のインストールを使用する場合は、アプリのブランド確認は必要ありません。ただし、アプリが制限付きスコープまたは機密性の高いスコープを使用している場合は、アプリの確認が必要です。これは、ドメイン全体にインストールすると、ドメイン管理者がサードパーティ製アプリケーションや内部アプリケーションにユーザーのデータへのアクセス権を付与できるためです。組織管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。

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