1. アーキテクチャ・設計・脅威モデリング要件

1.1. MSTG-ARCH-1

アプリのすべてのコンポーネントを把握し、それらが必要とされている。

1.1.1. コンポーネント

アプリのすべてのコンポーネントを把握して、不要なコンポーネントを削除すること。

主なコンポーネントの種類は以下の通り。

• Activity

• Fragment

• Intent

• BroadcastReceiver

• ContentProvider

• Service

1.2. MSTG-ARCH-2

セキュリティコントロールはクライアント側だけではなくそれぞれのリモートエンドポイントで実施されている。

1.2.1. 認証・認可情報の改竄

1.2.1.1. 適切な認証対応

認証・認可のテストを行う場合は、以下の手順で行う。

• アプリが使用する追加の認証要素を特定する。

• 重要な機能を提供するすべてのエンドポイントを特定する。

• すべてのサーバ側エンドポイントにおいて、追加要素が厳密に実施されていることを確認する。

認証バイパスの脆弱性は、サーバ上で認証状態が一貫して実施されておらず、クライアントが認証状態を改ざんできる場合に存在する。 バックエンドサービスは、モバイルクライアントからのリクエストを処理している間、リソースがリクエストされるたびに、ユーザがログインしているか、認可されているかを確認し、一貫した認可チェックを実施する必要がある。

OWASP Web Testing Guide の次の例を検討してください。 この例では、Web リソースは URL を介してアクセスされ、認証状態は GET パラメータを介して渡される。

http://www.site.com/page.asp?authenticated=no

クライアントは、リクエストと共に送られる GET パラメータを任意に変更することができる。
クライアントが単に authenticated パラメータの値を "yes" に変更することを妨げるものはなにもなく、効果的に認証をバイパスすることができてしまう。

これはおそらく実際には見られない単純な例だが、プログラマは認証状態を維持するために Cookie のような「隠れた」クライアント側パラメータに依存することがある。このようなパラメータは改ざんできないと想定している。例えば、Nortel Contact Center Manager における次のような典型的な脆弱性が考えられる。 Nortel のアプライアンスの管理 Web アプリケーションは、cookie の「isAdmin」に依存して、ログインしたユーザに管理権限を付与する必要があるかどうかを判断していた。 その結果、以下のようにクッキーの値を設定するだけで、管理者権限を取得することが可能であった。

isAdmin=True

セキュリティの専門家は、以前はセッションベースの認証を使用し、サーバ上でのみセッションデータを維持することを推奨していた。これにより、クライアント側でセッションの状態が改ざんされることを防ぐことができる。しかし、セッションベースの認証の代わりにステートレス認証を使用する要点は、サーバ上にセッションの状態を持たないことである。代わり、状態はクライアント側のトークンに保存され、リクエストごとに送信される。この場合、isAdmin のようなクライアント側のパラメータを見ることは、全く問題ない。

改ざんを防ぐために、クライアント側のトークンには暗号署名が付加されている。もちろん、うまくいかないこともあり、一般的なステートレス認証の実装は攻撃に対して脆弱である。例えば、いくつかの JSON Web Token(JWT) 実装の署名検証は、署名タイプを「None」に設定することで無効化することが可能である。この攻撃については、「Testing JSON Web Token」の章で詳しく説明する。

参考資料

• owasp-mastg Verifying that Appropriate Authentication is in Place (MSTG-ARCH-2 and MSTG-AUCH-1)

1.2.2. インジェクション欠陥

インジェクションの欠陥は、ユーザ入力がバックエンドのクエリやコマンドに挿入されたときに発生するセキュリティ上の脆弱性のことである。メタ文字を挿入することで、攻撃者は、コマンドやクエリの一部として誤って解釈される悪意のあるコードを実行できる。 例えば、SQL クエリを操作することで、攻撃者は任意のデータベースレコードを取得したり、バックエンドのデータベースの内容を操作したりすることができる。

このクラスの脆弱性は、サーバ側の Web サービスに最も多く存在する。モバイルアプリにも悪用可能な例があるが、発生頻度は低く、攻撃対象領域も小さくなっている。

例えば、アプリがローカルの SQLite データベースにクエリを実行する場合、そのようなデータベースは通常、機密データを保存しない（開発者が基本的なセキュリティプラクティスに従っている場合）。 このため、SQL インジェクションは攻撃ベクトルとしてふさわしくない。 それにもかかわらず、インジェクションの脆弱性が悪用されることもあるため、適切な入力検証はプログラマにとって必要なベストプラクティスであると言える。

参考資料

• owasp-mastg Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2)

ルールブック

• 適切な入力検証を実施する（必須）

1.2.2.1. SQLインジェクション

SQL インジェクション攻撃は、あらかじめ定義された SQL コマンドの構文を模倣して、入力データに SQL コマンドを統合する。 SQL インジェクション攻撃が成功すると、攻撃者は、サーバから付与された権限に応じて、データベースへの読み取りまたは書き込みが可能になり、管理コマンドを実行できる可能性がある。

Android と iOS のアプリは、ローカルデータストレージを制御および整理する手段として SQLite データベースを使用する。例えば、Android アプリが、ローカルデータベースにユーザ情報を保存して、ローカルユーザ認証を処理しているとする（例のために見過ごしている不適切なプログラミング手法である）。ログイン時に、アプリはデータベースにクエリを実行し、ユーザが入力したユーザ名とパスワードを使用してレコードを検索する。

SQLiteDatabase db;

String sql = "SELECT * FROM users WHERE username = '" +  username + "' AND password = '" + password +"'";

Cursor c = db.rawQuery( sql, null );

return c.getCount() != 0;

さらに、攻撃者が「ユーザ名」と「パスワード」の欄に以下の値を入力したとする。

username = 1' or '1' = '1
password = 1' or '1' = '1

これにより、以下のようなクエリが発生する。

SELECT * FROM users WHERE username='1' OR '1' = '1' AND Password='1' OR '1' = '1'

条件 '1' = '1' は常に true と評価されるため、このクエリはデータベース内のすべてのレコードを返し、有効なユーザ アカウントが入力されていなくても、ログイン関数は true を返す。 Ostorlab は、この SQL インジェクションのペイロードを使用して、adbを使用して Yahoo's weather mobile application のソートパラメータを悪用した。

Mark Woods 氏は、QNAP NAS ストレージ・アプライアンス上で動作する「 Qnotes 」および「 Qget 」 Android アプリ内で、クライアント側 SQL インジェクションのもう1つの実例を発見した。これらのアプリは、SQL インジェクションに対して脆弱なコンテンツプロバイダをエクスポートし、攻撃者が NAS デバイスの認証情報を取得することを可能にする。この問題の詳細な説明は、 Nettitude Blog にある。

参考資料

• owasp-mastg Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2) SQL Injection

1.2.2.2. XMLインジェクション

XML インジェクション攻撃では、攻撃者は XML メタ文字を挿入して XML コンテンツを構造的に変更する。 これは、XML ベースのアプリケーションまたはサービスのロジックを危険にさらすだけでなく、コンテンツを処理するXMLパーサーの操作を攻撃者が悪用できる可能性もある。

この攻撃の一般的な変種として、 XML eXternal Entity (XXE) がある。攻撃者は、URI を含む外部エンティティ定義を入力 XML に挿入する。XMLパーサーは、解析中に URI で指定されたリソースにアクセスし、攻撃者が定義したエンティティを展開する。

解析アプリケーションの完全性は、最終的に攻撃者の与えられる機能を決定し、悪意のあるユーザは次のいずれか（あるいはすべて） を行うことができる。ローカルファイルへのアクセス、任意のホストとポートへの HTTP リクエストの誘因、クロスサイトリクエストフォージェリ（ CSRF ）攻撃の起動、サービス拒否状態の誘因。 OWASP ウェブテストガイドには、 XXE に関する以下の例がある。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

この例では、ローカルファイル /dev/random が開かれ、そこで無限のバイトストリームが返されるため、サービス拒否が引き起こされる可能性がある。

現在のアプリ開発のトレンドは、XML が一般的でなくなってきているため、ほとんどが REST/JSON ベースのサービスに焦点を当てている。しかし、まれにユーザが提供したコンテンツや信頼できないコンテンツを使用して XML クエリを作成した場合、iOS の NSXMLParser などのローカル XML パーサーによって解釈される可能性がある。そのため、入力は常に検証する必要があり、メタ文字はエスケープする必要がある。

参考資料

• owasp-mastg Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2) XML Injection

ルールブック

• 入力は常に検証する必要があり、メタ文字はエスケープする必要がある（必須）

1.2.2.3. インジェクション攻撃ベクトル

モバイルアプリの攻撃対象は、一般的な Web アプリケーションやネットワークアプリケーションとは全く異なる。モバイルアプリは、ネットワーク上にサービスを公開することがあまりなく、アプリのユーザインターフェース上で実行可能な攻撃ベクトルは稀である。 アプリに対するインジェクション攻撃は、プロセス間通信（ IPC ）インターフェースを介して発生する可能性が最も高く、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃することがある。

潜在的な脆弱性を見つけるには、まず次のどちらかを行う。

• 信頼できない入力の可能性のあるエントリポイントを特定し、その場所からトレースして、宛先に潜在的な脆弱性のある関数が含まれているかどうかを確認する。

• 既知の危険なライブラリ/API 呼び出し (SQL クエリなど) を特定し、未チェックの入力がそれぞれのクエリと正常に連携しているかどうかを確認する。

手動のセキュリティ レビューでは、両方の手法を組み合わせて使用する必要がある。 一般に、信頼できない入力は、次のチャネルを通じてモバイル アプリに侵入する。

• IPCコール

• カスタムURLスキーム

• QRコード

• Bluetooth、NFCなどで受信した入力データ

• ペーストボード

• ユーザインターフェース

以下のベストプラクティスに従っていることを確認する。

• 信頼できない入力は、許容値のリストを使用して型チェックや検証を行う。

• データベースクエリを実行するときは、変数バインディング (つまり、パラメータ化されたクエリ) を使用する prepared ステートメントが使用される。 prepared ステートメントが定義されている場合、ユーザ提供のデータと SQL コードは自動的に分離される。

• XML データを解析するときは、XXE 攻撃を防ぐために、パーサーアプリケーションが外部エンティティの解決を拒否するように構成されていることを確認する。

• X.509 形式の証明書データを扱う場合は、安全なパーサーが使用されていることを確認する。 例えば、バージョン 1.6 未満の Bouncy Castle では、安全でないリフレクションによるリモートコード実行が可能である。

各モバイル OS の入力ソースや脆弱性の可能性のある API に関する詳細は、OS 固有のテストガイドで参照。

参考資料

• owasp-mastg Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2) Injection Attack Vectors

ルールブック

• 宛先に潜在的な脆弱性のある関数を含めない（必須）

• 未チェックの入力がそれぞれのクエリと正常に連携している（必須）

• 信頼できない入力を確認する（必須）

• パーサーアプリケーションは外部エンティティの解決を拒否するように構成する（必須）

• X.509 形式の証明書データを利用する場合は安全なパーサーを使用する（必須）

1.2.3. ルールブック

1. 適切な入力検証を実施する（必須）

2. 入力は常に検証する必要があり、メタ文字はエスケープする必要がある（必須）

3. 宛先に潜在的な脆弱性のある関数を含めない（必須）

4. 未チェックの入力がそれぞれのクエリと正常に連携している（必須）

5. 信頼できない入力を確認する（必須）

6. パーサーアプリケーションは外部エンティティの解決を拒否するように構成する（必須）

7. X.509 形式の証明書データを利用する場合は安全なパーサーを使用する（必須）

1.2.3.1. 適切な入力検証を実施する（必須）

インジェクションの脆弱性が悪用されることもあるため、適切な入力検証はプログラマにとって必要なベストプラクティスであると言える。

下記は入力検証の一例。

• 正規表現チェック

• 長さ/サイズチェック

これに違反する場合、以下の可能性がある。

• インジェクションの脆弱性が悪用される可能性がある。

1.2.3.2. 入力は常に検証する必要があり、メタ文字はエスケープする必要がある（必須）

ユーザが提供したコンテンツや信頼できないコンテンツを使用して XML クエリを作成した場合、ローカル XML パーサーによって XML メタ文字が XML コンテンツとして解釈される可能性がある。そのため、入力は常に検証する必要があり、メタ文字はエスケープする必要がある。

下記は入力検証の一例。

• 正規表現チェック

• 長さ/サイズチェック

下記はメタ文字の一例。

表 1.2.3.2.1 メタ文字一覧

文字	項目名	エンティティ参照による表記
<	右大なり	&lt;
>	左大なり	&gt;
&	アンパーサント	&amp;
"	ダブルクォーテーション	&quot;
'	シングルクォーテーション	&apos;

これに違反する場合、以下の可能性がある。

• ローカル XML パーサーによって XML メタ文字が XML コンテンツとして解釈される可能性がある。

1.2.3.3. 宛先に潜在的な脆弱性のある関数を含めない（必須）

信頼できない入力の可能性のあるエントリポイントを特定し、その場所からトレースして、宛先に潜在的な脆弱性のある関数（サードパーティ製の関数）が含まれているかどうかを確認する。

これに違反する場合、以下の可能性がある。

• プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。

1.2.3.4. 未チェックの入力がそれぞれのクエリと正常に連携している（必須）

既知の危険なライブラリ /API 呼び出し (SQL クエリなど) を特定し、未チェックの入力がそれぞれのクエリと正常に連携しているかどうかを確認する。 また、利用するライブラリ /API のリファレンスを確認し、非推奨でないことを確認する。

Android API リファレンス：https://developer.android.com/?hl=ja

これに違反する場合、以下の可能性がある。

• プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。

1.2.3.5. 信頼できない入力を確認する（必須）

一般に、信頼できない入力は、次のチャネルを通じてモバイルアプリに侵入するため、チャネルの利用箇所をソースコードから特定し確認する。

下記はチャネルの利用を特定するキーワードの一例。

• IPCコール： ContentProvider

• カスタムURLスキーム： scheme

• QRコード： qr, camera

• Bluetooth、NFCなどで受信した入力データ： bluetoothAdapter

• ペーストボード： ClipboardManager

• ユーザインターフェース：EditText

これに違反する場合、以下の可能性がある。

• プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。

1.2.3.6. パーサーアプリケーションは外部エンティティの解決を拒否するように構成する（必須）

XXE 攻撃を防ぐために、パーサーアプリケーションは外部エンティティの解決を拒否するように構成する必要がある。

XXE を防止する最も安全な方法は、常に DTD (外部エンティティ) を完全に無効にすることである。パーサーに応じて、メソッドは次のようになる。

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

DTD を無効にすると、パーサーは Billion Laughs などのサービス拒否 ( DOS ) 攻撃に対しても安全になる。 DTD を完全に無効にすることができない場合は、各パーサーに固有の方法で、外部エンティティと外部ドキュメントタイプの宣言を無効にする必要がある。

これに違反する場合、以下の可能性がある。

• XXE 攻撃に対して脆弱となる。

参考資料

• OWASP Cheat Sheet Series XML External Entity Prevention

1.2.3.7. X.509 形式の証明書データを利用する場合は安全なパーサーを使用する（必須）

X.509 形式の証明書データを扱う場合は、安全なパーサーを使用する。

下記は安全なパーサーの一例。

• Bouncy Castle （バージョン 1.6 以上）

これに違反する場合、以下の可能性がある。

• 安全でないリフレクションによるリモートコード実行等、インジェクション攻撃に対して脆弱となる。

1.3. MSTG-ARCH-3

モバイルアプリと接続されるすべてのリモートサービスの高次のアーキテクチャが定義され、そのアーキテクチャにセキュリティが対応されている。

※リモートサービス側での対応に関する章であるため、本資料ではガイド記載を省略

1.4. MSTG-ARCH-4

モバイルアプリのコンテキストで機密とみなされるデータが明確に特定されている。

機密情報の分類は、業界や国によって異なる。さらに、組織は機密データに対して制限的な見方をしている場合があり、機密情報を明確に定義するデータ分類ポリシーを持っている場合がある。
データ分類ポリシーが利用できない場合は、一般的に機密と見なされる情報の次のリストを使用する。

参考資料

• owasp-mastg Penetration Testing (a.k.a. Pentesting) Identifying Sensitive Data

ルールブック

• データ分類ポリシーに従い、機密データを識別する（必須）

1.4.1. ユーザ認証情報

ユーザ認証情報 (資格情報、PIN など)。

1.4.2. 個人識別情報

個人情報の盗難に悪用される可能性のある個人識別情報 (PII): 社会保障番号、クレジット カード番号、銀行口座番号、健康情報。

1.4.3. デバイス識別子

個人を特定できるデバイス識別子。

1.4.4. 機密性高いデータ

侵害されると風評被害や金銭的コストにつながる機密性の高いデータ。

1.4.5. 保護が法的義務であるデータ

保護が法的義務であるデータ。

1.4.6. 技術データ

アプリ (またはその関連システム) によって生成され、他のデータまたはシステム自体を保護するために使用される技術データ (暗号化キーなど)。

1.4.7. ルールブック

1. データ分類ポリシーに従い、機密データを識別する（必須）

1.4.7.1. データ分類ポリシーに従い、機密データを識別する（必須）

業界・国・組織で明確に定義されているデータ分類ポリシーに従い、機密データを識別する。データ分類ポリシーが利用できない場合は、一般的に機密と見なされる情報として以下のリストを使用する。

• ユーザ認証情報（資格情報、 PIN など）

• 個人情報の盗難に悪用される可能性のある個人識別情報（ PII）：社会保障番号、クレジット カード番号、銀行口座番号、健康情報。

• 個人を特定できるデバイス識別子

• 機密性高いデータ：侵害されると風評被害や金銭的コストにつながる機密性の高いデータ。

• 保護が法的義務であるデータ

• アプリ（またはその関連システム）によって生成され、他のデータまたはシステム自体を保護するために使用される技術データ（暗号化キーなど）。

「機密データ」の定義なしで機密データの漏洩を検出することは不可能な場合があるため、定義はテストを開始する前に決定する必要がある。

これに違反する場合、以下の可能性がある。

• ペネトレーションテストの結果から侵害される可能性のある機密データを機密データとして認識できず、リスクとして把握・対策出来ない可能性がある。

1.5. MSTG-ARCH-12

アプリはプライバシーに関する法律および規制に準拠している。

1.5.1. プライバシーに関する一般的な法律および規則

参考資料

• V6.1 Data Classification

• V6.1 データ分類

1.5.1.1. 個人情報・プライバシー

個人情報を扱っている場合、GDPR,個人情報保護法に準拠していること。

1.5.1.2. 医療データ

医療データを扱っている場合、HIPAA,HITECHに準拠していること。

1.5.1.3. 金融情報

クレジットカード情報

クレジットカード情報を扱っている場合、PCI DSSに準拠していること。

1.5.2. プライバシーに関する Google Play での規則

Google は、ユーザのプライバシーを保護し、安全な環境をユーザに提供するように努めている。虚偽のあるアプリ、悪意のあるアプリ、ネットワーク、デバイス、個人データを悪用または不正使用する意図のあるアプリは一切禁止している。

参考資料

• Google Play デベロッパーポリシーセンター プライバシー、詐欺、デバイスの不正使用

1.5.2.1. ユーザデータ

ユーザデータ（デバイス情報を含む、ユーザについての情報やユーザから収集する情報など）を扱う場合は、その処理方法を明らかにする必要がある。それには、アプリによるユーザデータのアクセス、収集、使用、処理、共有の方法を示すとともに、データの使用をポリシーに準拠した目的に制限することが求められる。ユーザの個人情報と機密情報の扱いについては、さらに下記の「ユーザの個人情報と機密情報」に示す要件も適用されることにご注意すること。これらの Google Play の要件は、プライバシー保護とデータ保護に関する適用法令が規定する要件に加えて適用される。

サードパーティのコード（SDK など）をアプリに含める場合には、アプリ内で使用するサードパーティのコードと、アプリでのサードパーティによるユーザデータの扱いが、使用と開示に関する要件を含め、Google Play デベロッパープログラムポリシーに準拠していることを確認する必要がある。たとえば、SDK プロバイダがアプリを通じてユーザの個人情報や機密情報を販売しないようにする必要がある。この要件は、ユーザデータがサーバに送信された後で転送される場合にも、サードパーティのコードをアプリに埋め込むことで転送される場合にも適用される。

ユーザの個人情報と機密情報

ユーザの個人情報や機密情報には、個人を特定できる情報、財務情報、支払い情報、認証情報、電話帳、連絡先、デバイスの位置情報、SMS や通話に関するデータ、健康に関するデータ、Health Connect のデータ、デバイス上の他のアプリの一覧、マイクやカメラなどのデバイスや使用状況に関するその他の機密情報が含まれますが、これらに限定される。アプリがユーザの個人情報や機密情報を扱う場合は、以下の要件を満たす必要がある。

• アプリを通じて取得した個人情報や機密情報のアクセス、収集、使用、および共有を、ユーザが合理的に予期する目的に適合するアプリとサービスの機能、およびポリシーにのみ許可すること。

  • ユーザの個人情報や機密情報を使用して広告を配信するアプリは、Google Play の広告ポリシーに準拠する必要がある。

  • サービスプロバイダが必要とする場合、あるいは政府機関による有効な要請や適用される法律を遵守するため、もしくは合併または買収の一環として必要な場合には、法的に適切な通知を行ったうえでデータを転送できる。

• 最新の暗号手法を使用して（HTTPS 経由などで）転送するなど、ユーザのすべての個人情報や機密情報を安全に扱うこと。

• Android の権限によって制限されているデータにアクセスする前に、可能な限り実行時の権限をリクエストすること。

• ユーザの個人情報や機密情報を販売しないこと。

  • 「販売」とは、金銭的対価を目的に第三者との間でユーザの個人情報や機密情報の交換または転送を行うことを意味する。

    • ユーザの個人情報や機密情報をユーザが転送すること（たとえば、ユーザがアプリの機能を使用して特定のファイルを第三者に転送したり、調査研究専用のアプリを使用したりすること）は、販売とは見なされない。

認識しやすい開示と同意の要件

アプリによるユーザの個人情報や機密情報のアクセス、収集、使用、共有が、対象のプロダクトや機能のユーザが合理的に予測できる範囲を超えている場合（たとえばユーザがアプリを操作していないときに、データの収集がバックグラウンドで行われるなど）には、以下の要件を満たす必要がある。

認識しやすい開示: データの収集、使用、共有について、アプリ内で開示する必要がある。アプリ内での開示に関する要件は次のとおり。

• アプリ内で開示すること。アプリの説明文やウェブサイトでの開示だけでは不十分である。

• アプリの通常使用時に表示すること。表示するのにメニューや設定に移動する必要のある開示方法では不十分である。

• アクセスまたは収集するデータの種類について説明すること。

• データをどのように使用、共有するかについて説明すること。

• 掲載場所を、プライバシー ポリシーや利用規約のみとしないこと。

• 個人情報や機密情報の収集に関係のない他の開示の中に掲載しないこと。

同意およびランタイム権限: アプリ内でのユーザによる同意のリクエストや、ランタイム権限のリクエストを行う場合は、その直前にこのポリシーの要件に沿ってアプリ内で開示される必要がある。同意を求める場合は、以下のようにする必要がある。

• 同意ダイアログは、あいまいにならないよう明確に表示する。

• 同意を示すための明確な操作をユーザに求める（例: タップで同意する、チェックボックスをオンにする）。

• 開示画面から他へ移動する操作（例: タップで移動する、戻るボタンやホームボタンを押す）を同意と見なさない。

• ユーザの同意を得る方法として、自動で非表示になるメッセージや閲覧期限付きメッセージを使用しない。

• アプリがユーザの個人情報と機密情報の収集やアクセスを開始するには、事前にユーザの許可を得る必要がある。

他の法的根拠（EU の GDPR における正当な利益など）に基づいてユーザの同意なく個人情報と機密情報を処理するアプリは、適用されるすべての法的要件を遵守するとともに、ユーザに対して、このポリシーで要求されるアプリ内開示を含む適切な開示を行う必要がある。

ポリシーの要件に準拠するには、認識しやすい開示に関する以下のサンプル フォーマットを必要に応じて参照することをおすすめする。

• 「[このアプリ] は、[機能] を可能にするために、[想定される状況]、[データの種類] を [収集 / 転送 / 同期 / 保存] する。」

• 例: 「Fitness Funds は、フィットネスの記録を可能にするために、アプリが閉じているときや使用されていないときでも、位置情報を収集する。また、位置情報は広告をサポートするためにも使用される。」

• 例: 「Call buddy は、組織への連絡を可能にするために、アプリが使用されていないときでも、通話履歴の書き込みと読み込みのデータを収集する。

デフォルトでユーザの個人情報と機密情報を収集するように設計されているサードパーティのコード（SDK など）がアプリに統合されている場合は、Google Play による要請を受けてから 2 週間以内に（Google Play によってそれより長い期間が与えられている場合はその期間内に）、アプリがこのポリシーの認識しやすい開示と同意の要件（サードパーティのコードを通じたデータのアクセス、収集、使用、共有に関する要件を含む）を満たしていることを示す、十分な根拠を提示する必要がある。

違反の例

• デバイスの位置情報を収集するにもかかわらず、このデータを使用する機能と、バックグラウンドでのアプリの使用について、認識しやすい開示で説明していないアプリ。

• データの使用目的を説明する認識しやすい開示が提示される前に、データへのアクセスを要求する実行時の権限が付与されているアプリ。

• ユーザのインストール済みアプリの一覧にアクセスできるにもかかわらず、そのデータを個人情報や機密情報として扱わず、上記のプライバシー ポリシー、データの処理、認識しやすい方法での開示、および同意の各要件を満たしていないアプリ。

• ユーザの電話機能や連絡帳のデータにアクセスできるにもかかわらず、そのデータを個人情報や機密情報として扱わず、プライバシー ポリシー、データの処理、認識しやすい方法での開示、および同意の各要件を満たしていないアプリ。

• ユーザの画面を記録するにもかかわらず、そのデータを個人情報や機密情報として、このポリシーに沿って扱わないアプリ。

• デバイスの位置情報を収集するにもかかわらず、上記の要件に沿ってその情報の使用について包括的に開示せず、同意を得ていないアプリ。

• 追跡、調査、またはマーケティングの目的などのため、アプリのバックグラウンドで制限付きの権限を使用するにもかかわらず、上記の要件に沿って各権限の使用について包括的に開示せず、同意を得ていないアプリ。

• ユーザの個人情報と機密情報を収集し、そのデータをこのユーザデータ ポリシーや、アクセス、データ処理（許可されていない販売を含む）、認識しやすい開示と同意の要件に沿って処理しない SDK を使用するアプリ。

認識しやすい開示と同意の要件について詳しくは、この記事を確認すること。

個人情報と機密情報へのアクセスに関する制限

上記の要件に加えて、特定の操作における要件を下表に記載する。

表 1.5.2.1.1 ユーザデータの特定の操作における要件

操作	要件
個人の財務情報、支払い情報、政府発行の個人識別番号をアプリが扱う場合	財務処理、支払い処理、政府発行の個人識別番号に関する個人情報や識別情報は一切公開 してはならない。
非公開の電話帳や連絡先情報をアプリが扱う場合	個人の非公開の連絡先を許可なく公開または開示することは認められない。
ウイルス対策、マルウェア対策、セキュリティ関連の機能など、ウイルス対策機能やセキ ュリティ機能を持つアプリの場合	アプリ内での開示と併せて、アプリが収集、転送するユーザデータの種類と内容、使用 方法、共有先について説明するプライバシー ポリシーを掲載する必要がある。
アプリが子供を対象とする場合	子供向けサービスで使用が承認されていない SDK をアプリに含めてはならない。ポリシー のすべての文言と要件については、子供向けやファミリー向けにアプリを設計するを確認すること。
永続的なデバイス識別子（IMEI、IMSI、SIM のシリアル番号など）を収集またはリンクするアプリの場合	永続的なデバイス識別子を、他の個人情報と機密情報、またはリセット可能なデバイス識別子にリンクしてはならない。ただし、以下を目的とする場合を除く。 ・SIM 識別子にリンクされた通話機能（例: 携帯通信会社アカウントにリンクされた Wi-Fi 通話機能） ・デバイス所有者モードを使用するエンタープライズデバイス管理アプリ これらの使用方法は、ユーザデータに関するポリシーの規定に沿って、ユーザが認識しやすいように開示する必要がある。 その他の一意の識別子については、こちらのリソースを確認すること。 Android 広告 ID に関する追加のガイドラインについては、広告ポリシーを参照すること。

データ セーフティ セクション すべてのデベロッパーは、すべてのアプリについて、ユーザデータの収集、使用、共有に関する詳細な説明を、データセーフティセクションに明瞭かつ正確に記載する必要がある。デベロッパーには、ラベルを正確に記載し、ラベルの情報を最新の状態に保つ責任がある。データセーフティセクションは、該当箇所において、アプリのプライバシーポリシーで開示されている内容と一致する必要がある。

データセーフティセクションへの入力に関する追加情報については、こちらの記事を参照すること。

プライバシー ポリシー

すべてのアプリで、プライバシーポリシーのリンクを Google Play Console 内の所定の欄に掲載し、アプリ内にはプライバシーポリシーのリンクまたはテキストを掲載する必要がある。プライバシーポリシーでは、アプリ内での開示内容と併せて、当該アプリでユーザデータ（プライバシー ラベルで開示されているデータに限定されない）がどのようにアクセス、収集、使用、共有されるかを包括的に開示する必要がある。これには以下の情報が含まれる。

• デベロッパー情報、およびプライバシーに関する連絡先または問い合わせを行う方法。

• アプリがアクセス、収集、使用、共有するユーザの個人情報や機密情報の種類、およびユーザの個人情報や機密情報の共有先の開示。

• ユーザの個人情報や機密情報を安全に処理するための手順。

• デベロッパーのデータ保持ポリシーおよびデータ削除ポリシー。

• プライバシー ポリシーであることが明瞭にわかるラベル付け（たとえば、タイトルに「プライバシー ポリシー」と記載する）。

アプリの Google Play ストアの掲載情報に記載されている主体（デベロッパーや会社等）がプライバシーポリシーに明記されている、もしくはアプリ名がプライバシー ポリシーに明記されている必要がある。ユーザの個人情報や機密情報にアクセスしないアプリであっても、プライバシー ポリシーを掲載する必要がある。

プライバシーポリシーは必ず、どの国からもアクセスできるよう、アクセス制限のない一般公開の有効な URL（PDF ではない）で参照可能、かつ編集不可にすること。

アプリセット ID の使用

Android では、分析や不正防止などの重要なユースケースに対応するために、新しい ID が導入される。この ID を使用するための規約は以下のとおり。

• 使用: アプリセット ID を広告のパーソナライズと広告の測定に使用することはできない。

• 個人を特定できる情報またはその他の識別子との関連付け: 広告を目的として、アプリセット ID を Android の識別子（例: AAID）または個人情報や機密情報に関連付けることはできない。

• 透明性と同意: アプリセット ID を収集および使用することと、この規約を遵守していることを、法的に適切なプライバシーに関するお知らせ（デベロッパー独自のプライバシー ポリシーを含む）を通じてユーザに開示する必要がある。必要に応じて、ユーザから法的に有効な同意を得る必要があります。Google のプライバシー基準について詳しくは、ユーザデータに関するポリシーを確認すること。

EU-U.S., Swiss Privacy Shield（EU-US スイス プライバシー シールド）

Google が公開している、欧州連合またはスイスにおいて収集された直接または間接的に個人を特定できる個人情報（「EU 個人情報」）にアクセスする場合や、そうした個人情報を利用、処理する場合は、以下の義務がある。

• 適用のある法域におけるプライバシー、データ セキュリティ、データ保護に関するあらゆる法律、指令、規制、ルールを遵守すること

• EU 個人情報のアクセス、使用、処理は、その EU 個人情報に関連する人物が同意した目的の範囲内に限って行うこと

• データの消失、不正使用、不正または違法アクセス、漏えい、改変、破壊などから EU 個人情報を保護するために適切な組織的および技術的な措置をとること

• Privacy Shield（プライバシー シールド）原則で要求されているものと同水準の保護を確保すること

上記の義務を遵守していることを定期的に監視し、上記の条件を満たせない（または満たせなくなるリスクが高い）場合は、直ちに data-protection-office@google.com 宛てのメールで Google に通知するとともに、直ちに EU 情報の処理を停止するか、適切な水準の保護を確保するための合理的かつ適切な措置を講じなければならない。

2020 年 7 月 16 日をもって、Google では、欧州経済領域または英国から米国へのデータ転送において EU-U.S. Privacy Shield（EU-US プライバシー シールド）の利用を終了した（詳細）。詳しくは、デベロッパー販売 / 配布契約の第 9 条を参照。

参考資料

• Google Play デベロッパーポリシーセンター ユーザデータ

1.5.2.2. 機密情報へのアクセスに関する権限と API

機密情報にアクセスする権限や API のリクエストは、ユーザにとって理に適うものでなければならない。そのため、機密情報にアクセスする権限や API をリクエストできるのは、アプリで現在提供している機能やサービスの実装に必要で、それらが Google Play ストアの掲載情報に掲載されている場合に限られる。ユーザデータやデバイスデータへのアクセスを必要とする機能や目的が公開されていないもしくは実装されていない場合、または認可されていない場合には、機密情報にアクセスする権限や API は利用できない。機密情報にアクセスする権限または API を通じてアクセスした個人情報や機密情報を販売したり、販売を促進する目的で共有したりすることは禁止されている。

データにアクセスするために、機密情報にアクセスする権限または API をリクエストする場合は、アプリが権限をリクエストする理由をユーザが理解しやすいように状況に合わせて（段階的にリクエストする形で）行うようにする。データの使用は、ユーザが同意した目的に限って行わなければならない。後になって他の目的でデータを使用する必要が出てきた場合は、その追加の用途に関して、あらためてユーザにリクエストし、同意を得る必要がある。

制限付きの権限

上記に加えて、制限付きの権限とは、「Dangerous」、「Special」、「Signature」と指定される権限、または下記のような権限である。これらの権限には、以下に示す追加の要件と制限が適用される。

• 制限付きの権限を通じてアクセスされたユーザデータやデバイスデータは、ユーザの個人情報および機密情報と見なされ、ユーザデータに関するポリシーの要件が適用される。

• ユーザが制限付き権限のリクエストを承認しない場合はその決定を尊重すること。重要でない権限についてユーザに同意するよう誘導または強制することも認められない。機密情報に関わる権限へのアクセスを許可しないユーザにも対応する（たとえば、ユーザが通話履歴へのアクセスを制限している場合であれば電話番号を手動で入力できるようにするなど）よう、合理的な努力を尽くす必要がある。

• Google Play のマルウェアに関するポリシー（昇格させた権限の悪用を含む）に違反する権限の使用は、明示的に禁止されている。

一部の制限付き権限には、下記の追加要件が適用されることがある。これらの制限の目的は、ユーザのプライバシーを守ることにある。ただし、非常にまれなケースですが、アプリがきわめて必要性の高いまたは重要な機能を提供していて、その機能を実現する他の手段が現時点で他に存在しない場合には、下記の要件について例外が認められることがある。例外の申請があった場合は、ユーザに対して想定されるプライバシーまたはセキュリティ上の影響を考慮して審査する。

SMS と通話履歴の権限

SMS と通話履歴に関する権限は、ユーザの個人情報と機密情報と見なされ、個人情報と機密情報に関するポリシーおよび以下の制限が適用される。

表 1.5.2.2.1 制限付きの権限と要件

制限付きの権限	要件
通話履歴に関する権限グループ（例: READ_CALL_LOG、WRITE_CALL_LOG、PROCESS_OUTGOING_CALLS）	ユーザのデバイスで、アプリがデフォルトの電話ハンドラまたはアシスタント ハンドラとして能動的に登録されている必要がある。
SMS に関する権限グループ（例: READ_SMS、SEND_SMS、WRITE_SMS、RECEIVE_SMS、RECEIVE_WAP_PUSH、RECEIVE_MMS）	ユーザのデバイスで、アプリがデフォルトの SMS ハンドラまたはアシスタント ハンドラとして能動的に登録されている必要がある。

デフォルトの SMS ハンドラ、電話ハンドラまたはアシスタントハンドラとしての機能をアプリが備えていない場合、マニフェストで上記の権限の使用を宣言することはできない（マニフェスト内のプレースホルダ テキストである場合を含む）。また、ユーザに上記の権限の許可をリクエストする前に、アプリがデフォルトの SMS ハンドラ、電話ハンドラまたはアシスタントハンドラとして有効に登録されている必要がある。アプリがデフォルトのハンドラではなくなったときは、直ちに該当する権限の使用を停止しなければならない。許可されている使用方法と例外については、ヘルプセンターのこちらのページを確認すること。

アプリが使用できる権限は、承認済みの重要なアプリの機能を提供するために必要な権限（およびその権限で取得したデータ）のみである。重要な機能とは、アプリの主たる目的である機能を言う。いくつかの機能のセットである場合もあり、そのすべてがアプリの説明文の中に認識しやすい形で明記されている必要がある。その機能がなければアプリが「壊れている」、使用できない、と見なされるような機能が「重要な機能」にあたる。このデータの転送、共有、またはライセンス下での使用は、アプリ内で重要な機能やサービスを提供することのみを目的として許可されるものであり、その他の目的（他のアプリやサービスの改善、広告、マーケティング目的など）でデータを使用することはできない。通話履歴や SMS に関連する権限に基づくデータを取得するために、他の権限、API、第三者の提供元など、代わりの方法を使用することはできない。

位置情報の利用許可

デバイスの位置情報は、ユーザの個人情報および機密情報と見なされ、個人情報と機密情報に関するポリシー、バックグラウンドでの位置情報に関するポリシー、および以下の要件が適用される。

• アプリで現在の機能やサービスを提供する必要がなくなった後は、位置情報の権限（ACCESS_FINE_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_BACKGROUND_LOCATION など）で保護されているデータにアプリからアクセスすることはできない。

• 広告や分析のみを目的として、ユーザに位置情報の利用許可をリクエストしてはなりません。このデータの許可された利用の範囲を広告配信にも適用するアプリは、広告ポリシーを遵守していなければならない。

• アプリがリクエストするアクセスのレベルは、位置情報を必要とする現在の機能やサービスを提供するうえで必要最低限に留め（つまり、高精度よりも低精度、バックグラウンドよりもフォアグラウンド）、そのレベルの位置情報が機能やサービスに必要であることをユーザが合理的に予期できる必要がある。たとえば、バックグラウンドで位置情報をリクエストまたは利用することに合理的な根拠がないアプリは承認されない可能性がある。

• バックグラウンドで位置情報が利用できるのは、ユーザにとってメリットがあり、かつアプリの重要な機能に関連する機能を提供する場合のみである。

アプリからフォアグラウンド サービスの権限で（たとえば「使用中」のみ許可されるなど、フォアグラウンドでのアクセス権でのみ）位置情報にアクセスするのが認められるのは、以下の場合である。

• アプリ内でユーザが開始したアクションの続きとして位置情報の利用が開始され、かつ

• ユーザが開始したアクションの意図されたユースケースが完了した後、直ちにその利用が終了する場合

子供を主な対象とするアプリは、ファミリー向けポリシーを遵守する必要がある。

ポリシーの要件について詳しくは、こちらのヘルプ記事を確認する。

すべてのファイルへのアクセス権限

ユーザのデバイス上のファイルとディレクトリの属性は、ユーザの個人情報および機密情報と見なされ、個人情報と機密情報に関するポリシーおよび以下の要件が適用される。

• アプリがリクエストするアクセスの対象は、アプリが機能するうえで不可欠なデバイス ストレージに限定する必要がある。ユーザ向けの不可欠なアプリ機能と関係のない目的で第三者のためにデバイス ストレージへのアクセスをリクエストしてはならない。

• R 以降を搭載している Android デバイスでは、共有ストレージ内のアクセスを管理するには、MANAGE_EXTERNL_STORAGE 権限が必要である。R をターゲットとし、共有ストレージへの幅広いアクセス（「すべてのファイルへのアクセス」）をリクエストするアプリは必ず、公開前に適切なアクセスに関する審査に合格する必要がある。この権限の使用を許可されたアプリは、[特別なアプリアクセス] 設定で [すべてのファイルへのアクセス] を有効にするように求めるメッセージを、ユーザにはっきり表示する必要がある。R のこの要件について詳しくは、こちらのヘルプ記事を確認する。

パッケージ（アプリ）の公開設定権限

デバイスにクエリして入手したインストール済みアプリのインベントリは、ユーザの個人情報および機密情報と見なされ、個人情報と機密情報に関するポリシーおよび以下の要件が適用される。

デバイス上の他のアプリを起動、検索、相互運用することが主要な目的であるアプリは、以下で概説するように、デバイス上の他のインストール済みアプリに対して、スコープに応じた可視性を得ることができる。

• 広範なアプリの可視性: 広範な可視性とは、アプリがデバイス上のインストール済みアプリ（「パッケージ」）を幅広く（「広範に」）見渡せる（可視性が与えられている）ことを指す。

  • API レベル 30 以降をターゲットとするアプリの場合、QUERY_ALL_PACKAGES 権限によってインストール済みアプリについて広範な可視性が得られるのは、特定のユースケース（当該アプリが機能するためにデバイス上のすべてのアプリを認識するか、それらのアプリと相互運用する必要がある）に制限される。

    • スコープを絞ったパッケージの可視性を宣言（広範な可視性をリクエストせず、特定のパッケージをクエリしてやり取りするなど）して動作させることが可能なアプリでは、QUERY_ALL_PACKAGES を使用しない。

  • QUERY_ALL_PACKAGES 権限に関連する広範な可視性レベルに近い別の方法の使用も同様に、ユーザ向けの主要なアプリ機能と、その別の方法によって検出されたアプリとの相互運用に制限される。

  • QUERY_ALL_PACKAGES 権限を使用できるユースケースについては、こちらのヘルプセンター記事を確認する。

• 限定的なアプリ公開設定: 限定的な公開設定とは、アプリが、よりターゲットを絞った（「広範」ではない）方法を使って特定のアプリのクエリを行うことによりデータへのアクセスを最小限に抑える場合（アプリのマニフェスト宣言を満たす特定のアプリのクエリを行う場合など）を指す。アプリが相互運用性に関するポリシーを遵守している場合や他のアプリの管理を担っている場合は、この方法でそれらのアプリのクエリを行える。

• デバイス上のインストール済みアプリのインベントリに対する公開設定は、アプリの主要な目的やユーザがアプリ内でアクセスする主要な機能に直接関連する必要がある。

Play で配信中のアプリにクエリして入手したアプリインベントリのデータを、分析や広告収益化の目的で販売、共有することは禁止されている。

Accessibility API

Accessibility API を次の目的で使用することはできない。

• ユーザの許可なくユーザ設定を変更したり、ユーザがアプリまたはサービスを無効化またはアンインストールできないようにしたりする。ただし、保護者による使用制限を使用するアプリを通じて親権者または保護者の許可を得るか、エンタープライズ マネジメント ソフトウェアを通じて認定済み管理者の許可を得た場合を除く。

• Android の組み込みのプライバシー管理とプライバシー通知を回避する。

• 不正な方法または Google Play デベロッパー ポリシーに違反するその他の方法で、ユーザ インターフェースを変更または利用する。

Accessibility API は、リモート通話の音声録音用には設計されておらず、そのようなリクエストを受けることもできない。

Accessibility API を使用する場合は、Google Play のストアの掲載情報に記載する必要がある。

IsAccessibilityTool に関するガイドライン

障がいのあるユーザを直接サポートする機能が主体になっているアプリは、IsAccessibilityTool を使用して、ユーザ補助アプリとして公式に表明できる。

IsAccessibilityTool の対象とならないアプリはこのフラグを使用できないが、ユーザ補助に関連する機能をユーザが認識しにくいため、ユーザデータに関するポリシーに規定されている「認識しやすい開示と同意」の要件を遵守する必要がある。詳しくは、AccessibilityService API のヘルプセンター記事を確認する

Accessibility API を使用しなくても必要な機能を提供できるのであれば、より限定された範囲の API と権限をアプリで使用すること。

パッケージ インストールのリクエスト（REQUEST_INSTALL_PACKAGES）権限

REQUEST_INSTALL_PACKAGES 権限を使用すると、アプリからアプリ パッケージのインストールをリクエストできる。この権限を使用するには、アプリのコア機能に以下が含まれている必要がある。

• アプリ パッケージを送信または受信する機能、および

• ユーザが自発的にアプリ パッケージのインストールを開始する機能

たとえば次のような機能が許可されています。

• ウェブのブラウジングまたは検索

• 添付ファイルをサポートするコミュニケーションサービス

• ファイルの共有、転送、管理

• 企業向けデバイスの管理

• バックアップと復元

• デバイスの移行または電話の転送

コア機能とは、アプリの主要な目的を果たすために必要不可欠な機能を指し、そのすべてがアプリの説明文に認識しやすい形で明記されている必要がある。

REQUEST_INSTALL_PACKAGES 権限は、デバイス管理を目的とする場合を除き、自動更新、修正、アセット ファイル内での他の APK のビルドには使用できない。パッケージの更新とインストールにおいては、常に Google Play のデバイスやネットワークでの不正行為に関するポリシーに準拠しなければならず、ユーザが自発的に操作する必要がある。

Android の権限によるヘルスコネクト

ヘルスコネクト権限を通じてアクセスされたデータは、ユーザの個人情報および機密情報と見なされ、ユーザデータに関するポリシーおよび以下の追加要件が適用される。

ヘルスコネクトのアクセス方法と使用方法

ヘルスコネクトを通じてデータにアクセスするためのリクエストは、明確にわかりやすく記述すること。ヘルスコネクトは、該当するポリシーと利用規約を遵守したうえで、このポリシーによって規定されている承認された用途に限り使用できる。これはつまり、権限へのアクセスをリクエストできるのは、アプリまたはサービスの用途が、承認されているいずれかの用途に該当する場合に限られることを意味する。

ヘルスコネクト権限へのアクセスを承認される用途は次のとおり。

• ユーザの健康とフィットネスにとって有益な 1 つ以上の機能をユーザ インターフェースを通じて利用できるアプリまたはサービス。ユーザが自分の身体活動、睡眠、心身の健康、栄養、健康状態の測定値、身体的特徴、および / または健康とフィットネスに関連するその他の記述や測定値を直接記録、レポート、モニタリング、および / または分析できる。

• ユーザの健康とフィットネスにとって有益な 1 つ以上の機能をユーザ インターフェースを通じて利用できるアプリまたはサービス。ユーザが自分の身体活動、睡眠、心身の健康、栄養、健康状態の測定値、身体的特徴、および / または健康とフィットネスに関連するその他の記述や測定値をスマートフォンおよび / またはウェアラブルに保存して、用途に適合するその他のオンデバイス アプリとデータを共有できる。

ヘルスコネクトは、ユーザが Android デバイス内のさまざまなソースから健康とフィットネスに関するデータを集めて、特定の第三者と共有できる、汎用のデータ ストレージおよびデータ共有プラットフォームである。データは、ユーザが任意に選択したソースから集めることができる。デベロッパーは、ヘルスコネクトが意図する用途に適しているかを評価するとともに、特定の目的に関連して、また特に調査、健康、または医療上の用途について、ヘルスコネクトからのデータのソースと質を精査する必要がある。

• ヘルスコネクトを通じて取得したデータを使用して、健康関連の被験者調査を実施するアプリは、被験者（未成年者の場合は保護者）の同意を得る必要がある。そのような同意事項には、（a）調査の性質、目的、期間、（b）調査手順、被験者に対するリスクおよび利点、（c）データの機密性および取り扱い（第三者との共有を含む）に関する情報、（d）被験者の質問に対応する問い合わせ先、（e）取り消し手順が含まれるものとする。ヘルスコネクトを通じて取得したデータを使用して、健康関連の被験者調査を実施するアプリは、（1）被験者の権利、安全、心身の健康を保護する目的を持ち、（2）被験者調査を精査、変更、承認する権限を有する、独立した委員会による承認を得る必要がある。要請があった場合には、そのような承認の証明を提出しなければならない。

• デベロッパーは、ヘルスコネクトの用途、およびヘルスコネクトを通じて得られたデータの用途に基づいて適用される、規制または法律上の要件を遵守する責任がある。Google の特定のプロダクトまたはサービスについて、Google が提供するラベルまたは情報に明示的に記載されていない限り、Google は、特に調査、健康、医療用途に限らず、いかなる用途または目的でも、ヘルスコネクトに含まれるデータの使用を推奨し、その正確性を保証することはありません。Google は、ヘルスコネクトを通じて取得されたデータの使用に関連する、いかなる責任も負わない。

限定的な使用

適切な用途でヘルスコネクトを使用する際には、ヘルスコネクトを通じてアクセスするデータも、以下の要件を遵守して使用する必要がある。これらの要件は、ヘルスコネクトから取得した元データと、元データから集計、匿名化、または取得されたデータに適用される。

• ヘルスコネクトのデータの使用は、リクエスト元アプリのユーザ インターフェースに明確に表示される、適切な用途または機能の提供もしくは改善に限定される。

• 以下の目的がある場合を除き、ユーザデータを第三者に譲渡してはならない。

  • ユーザの同意に基づき、リクエスト元アプリのユーザ インターフェースに明確に表示される、適切な用途または機能を提供もしくは改善する場合。

  • セキュリティ上の目的で必要な場合（不正使用の調査など）。

  • 適用される法律および / または規制を遵守するために必要な場合。

  • ユーザから事前に明示的な同意を得た後で、デベロッパーの合併、買収、または資産売買の一環として行う場合。

• 以下の場合を除き、人にユーザデータが読まれないようにする必要がある。

  • 特定のデータを読まれることに、ユーザが明示的に同意している場合。

  • セキュリティ上の目的で必要な場合（不正使用の調査など）。

  • 適用される法律を遵守するために必要な場合。

  • データ（派生データを含む）を集計し、適用されるプライバシー要件および地域のその他の法的要件を遵守した、内部オペレーションのために使用する場合。

ヘルスコネクト データのその他の譲渡、使用、または販売は、以下の行為を含めてすべて禁止されている。

• 広告プラットフォーム、データ ブローカー、または情報リセラーなどの第三者にユーザデータを譲渡または販売すること。

• パーソナライズ広告やインタレスト ベース広告など、広告の配信を目的としてユーザデータを譲渡、販売、または使用すること。

• 信用力を判断するため、または貸与目的でユーザデータを譲渡、販売、または使用すること。

• 連邦食品・医薬品・化粧品法のセクション 201(h) に基づく医療機器と見なされるプロダクトまたはサービスを使用して、規制対象の機能を実行するために、ユーザデータを譲渡、販売、または使用すること。

• Google から書面による事前の承認を得ている場合を除き、（HIPAA によって定義される）保護対象保健情報に関連する目的で、方法を問わず、ユーザデータを譲渡、販売、または使用すること。

このポリシー、またはヘルスコネクトについて適用されるその他の利用規約またはポリシーに違反する形で、ヘルスコネクトにアクセスしてはならない。これには以下を目的とする場合が含まれる。

• ヘルスコネクトの使用または障害によって、死亡、人身傷害、もしくは環境上または財産上の損害に至ることが合理的に予想されるようなアプリ、環境、またはアクティビティ（核施設、航空管制システム、生命維持装置、兵器の作成または操作など）については、その開発、あるいはそれらに組み込む目的で、ヘルスコネクトを使用してはならない。

• ヘルスコネクトを通じて取得したデータに、ヘッドレス アプリを使用してアクセスしてはならない。アプリでは、アプリトレイ、デバイスのアプリ設定、通知アイコンなどに、明確に特定できるアイコンを表示する必要がある。

• 対応していないデバイスまたはプラットフォーム間でデータを同期するアプリで、ヘルスコネクトを使用してはならない。

• 子供だけを対象としているアプリ、サービス、または機能にヘルスコネクトを接続することはできない。主に子供を対象としているサービスでヘルスコネクトを使用することは承認されていない

ヘルスコネクトのデータの使用が、限定的な使用に関する制限を遵守していることを示す確認的陳述書を、アプリ内、あるいはウェブサービスまたはアプリに関連するウェブサイト上で開示する必要がある。たとえばホームページで、専用ページまたはプライバシー ポリシーに関する注記へのリンクを示し、「ヘルスコネクトから受け取った情報の使用については、限定的な使用に関する要件を含む、ヘルスコネクト権限ポリシーを遵守してください」などと記載する。

最小範囲

アクセス権限をリクエストできるのは、アプリまたはサービスの機能を実装するために不可欠な場合に限る。

これは次のことを意味する。

• 必要のない情報へのアクセス権限はリクエストしないこと。プロダクトの機能またはサービスの実装に必要なアクセス権限のみリクエストできる。プロダクトで特定のアクセス権限を必要としない場合、そのアクセス権限はリクエストしないこと。

通知と管理の透明性と正確性

ヘルスコネクトは健康とフィットネスに関するデータを扱うが、それには個人情報と機密情報が含まれる。すべてのアプリとサービスについてプライバシー ポリシーを規定し、アプリまたはサービスがユーザデータを収集、使用、共有する方法を包括的に開示する必要がある。開示する情報には、ユーザデータを共有する当事者の種類、データの使用方法、データの保存と保護の方法、アカウントが無効になるか削除された場合のデータの扱いが含まれるものとする。

適用される法律で規定されている要件に加えて、デベロッパーは以下の要件を遵守する必要がある。

• データのアクセス、収集、使用、共有について開示する必要があります。開示については次のことが求められる。

  • ユーザデータへのアクセスを求めるアプリまたはサービスの識別情報を正確に示す。

  • アクセス、リクエスト、および / または収集するデータの種類に関して、明確かつ正確な情報を提供する。

  • データを使用、共有する方法を示す。1 つの目的でデータをリクエストしながら、別の目的でもデータを使用する場合には、ユーザに両方の用途を通知する必要がある。

• ユーザがアプリ上で個人データを管理または削除する方法を示すヘルプ ドキュメントを提供する。

安全なデータ処理

ユーザデータはすべて安全に扱う必要があります。デベロッパーは合理的かつ適切な手順に沿って、ヘルスコネクトを使用するすべてのアプリケーションまたはシステムを、不正または違法なアクセス、使用、破壊、紛失、改変、開示から保護する必要がある。

推奨されるセキュリティ対策としては、たとえば ISO/IEC 27001 などで規定されている情報セキュリティ管理システムを実装して維持することで、アプリまたはウェブサービスを堅牢にし、OWASP トップ 10 に示されているセキュリティ上の一般的な問題がない状態を確保することが挙げられる。

デベロッパーのプロダクトによってユーザが所有するデバイスからデータが転送される場合には、使用している API、ユーザによる権限付与の数、またはユーザ数に応じて、アプリまたはサービスについて定期的なセキュリティ評価を受け、指定した第三者による評価文書を取得する必要がある。

ヘルスコネクトに接続するアプリに関する要件について詳しくは、こちらのヘルプ記事を確認する。

VPN サービス

VpnService は、アプリが独自の VPN ソリューションを拡張、構築できるようにするための基本クラスである。VPN がコア機能であり、VpnService を使用するアプリのみが、リモート サーバへのデバイスレベルのセキュアなトンネルを作成できる。ただし、次のようなコア機能を実装するためリモート サーバを必要とするアプリは例外となる。

• 保護者による使用制限や企業による管理を実装するアプリ。

• アプリの使用状況をトラッキングするアプリ。

• デバイス保護アプリ（ウイルス対策、モバイル デバイス管理、ファイアウォールなど）。

• ネットワーク関連ツール（リモート アクセスなど）。

• ウェブ ブラウジング用アプリ。

• テレフォニーサービスまたは接続サービスを提供するために VPN 機能の使用を必要とする携帯通信会社のアプリ。

VpnService を次の目的で使用することはできない。

• 認識しやすい開示および同意機能を実装せずに、ユーザの個人情報や機密情報を収集する。

• 収益化を目的として、デバイスでの他のアプリからのユーザ トラフィックをリダイレクトまたは操作する（ユーザの国とは異なる国から広告トラフィックをリダイレクトするなど）。

• アプリの収益化に影響を与えられるように広告を操作する。

VpnService を使用するアプリは、次のすべての要件を満たす必要がある。

• VpnService を使用することを Google Play の掲載情報に記載する。

• デバイスから VPN トンネル エンドポイントに送信されるデータを暗号化する。

• 広告の不正行為、権限、マルウェアに関するポリシーを含む、すべてのデベロッパープログラムポリシーに準拠する。

参考資料

• Google Play デベロッパーポリシーセンター 機密情報へのアクセスに関する権限と API

1.5.2.3. デバイスやネットワークでの不正行為

ユーザのデバイスやその他のデバイス、パソコン、サーバ、ネットワーク、アプリケーション プログラミング インターフェース（API）、サービスなど（デバイス上の他のアプリ、Google サービス、許可された携帯通信会社のネットワークを含む）を妨害、阻害、破損する、またはそれらに無断でアクセスするアプリは認められない。

Google Play に公開するアプリは、Google Play のアプリの中核品質に関するガイドラインに定めるデフォルトの Android システム最適化要件を遵守している必要がある。

Google Play で販売または配布されるアプリについては、Google Play の更新機能以外の方法によりアプリ自体の変更、差し替え、更新を行うことはできない。同様に、Google Play 以外の提供元から実行コード（dex、JAR、.so などのファイル）をダウンロードすることもできない。この制限は、Android API への間接アクセスを提供する仮想マシンまたはインタープリタ（WebView またはブラウザ内の JavaScript など）で実行されるコードには適用されない。

アプリまたはサードパーティのコード（SDK など）でインタープリタ言語（JavaScript、Python、Lua など）が実行時に読み込まれる場合（たとえば、アプリにパッケージされていない場合）、それらが Google Play ポリシーに違反する可能性があってはならない。

セキュリティの脆弱性を組み込むまたは悪用するコードは許可されない。デベロッパーに報告された最近のセキュリティに関する問題については、アプリセキュリティ向上プログラムを確認すること。

FLAG_SECURE の要件

FLAG_SECURE は、アプリのコードで宣言される表示関連のフラグである。アプリの使用中、UI に含まれるセンシティブ データの表示場所をセキュアなサーフェスに限定することを示せる。このフラグは、センシティブ データがスクリーンショットに表示されたり、セキュアでないディスプレイで閲覧されたりするのを防ぐために設計されている。デベロッパーは、アプリのコンテンツがアプリやユーザのデバイスの外部で閲覧されたり、外部にブロードキャストまたは送信されたりできないようにする場合に、このフラグを宣言する。

セキュリティおよびプライバシー保護のため、Google Play で配信されるすべてのアプリが、他のアプリの FLAG_SECURE 宣言を尊重しなければならない。つまり、他のアプリでの FLAG_SECURE の設定を回避する手段を作成または促進してはいけない。

ユーザ補助ツールとして認められるアプリは、FLAG_SECURE で保護されたコンテンツをユーザのデバイスの外部でアクセスするために転送、保存、またはキャッシュに保存しない限り、この要件の対象外となる。

よくある違反の例

• 広告を表示して他のアプリをブロックまたは妨害するアプリ。

• 他のアプリのゲームプレイに影響を与えるようなゲームチートアプリ。

• サービス、ソフトウェア、ハードウェアのハッキング方法や、セキュリティ保護の回避方法を推進または説明するアプリ。

• サービスや API に対してその利用規約に違反する方法でアクセスまたは利用するアプリ。

• システムの電源管理を迂回しようとするアプリのうち許可リストへの登録が認められないもの。

• 第三者に対するプロキシ サービスの利用を支援するアプリのうち、その利用支援がアプリのユーザ向けの主たる基本目的ではないもの。

• アプリまたはサードパーティのコード（SDK など）のうち、Google Play 以外の提供元から実行可能コード（dex ファイル、ネイティブ コードなど）をダウンロードするもの。

• ユーザの事前の同意なしに他のアプリをデバイスにインストールするアプリ。

• 不正なソフトウェアにリンクするアプリや、その配信やインストールを推進するアプリ。

• アプリまたはサードパーティのコード（SDK など）のうち、信頼できないウェブ コンテンツ（http:// URL）、または信頼できないソースから取得された未検証の URL（信頼できないインテントで取得された URLなど）を読み込む JavaScript インターフェースが追加された WebView を含むもの。

参考資料

• Google Play デベロッパーポリシーセンター デバイスやネットワークでの不正行為

1.5.2.4. 虚偽の振る舞い

ユーザを欺こうとするアプリや不正行為を助長するアプリは認められない。たとえば、機能的に不可能だと判断されるアプリが含まれますが、これに限定されない。アプリは、メタデータのあらゆる部分で、アプリの機能に関する説明、画像または動画を正確に開示しなければならない。オペレーティング システムや他のアプリの機能または警告であるかのように装うことも認められない。デバイスの設定を変更する場合は、ユーザに通知して同意を得ること、およびユーザが簡単に元に戻せることが必要である。

誤解を与える表現

アプリの説明、タイトル、アイコン、スクリーンショットなどに、虚偽のまたは誤解を招くような情報や宣伝文句を含めたアプリは認められていない。

違反の例

• 機能の説明が誤っている、または不正確でわかりにくいアプリ:

  • アプリの説明やスクリーンショットにはレーシング ゲームのように記載されているのに、実際は自動車の絵のブロックパズル ゲーム。

  • ウイルス対策アプリのように記載されているのに、ウイルスを削除する方法を説明したテキストガイドしか含まれていないアプリ。

• 虫よけアプリなど、実現できない機能を宣伝するアプリ（いたずら、フェイク、冗談として表示されているものも含まれる）。

• レーティングやカテゴリなど（これらに限らず）について、不適切に分類されたアプリ。

• 選挙の投票プロセスに影響を与える可能性のある、明らかに虚偽のコンテンツ。

• 政府機関との協力関係があるように偽るアプリ、あるいは適切な認可を受けずに行政サービスを提供または支援するアプリ。

• 定評のある組織の正式なアプリであるかのように偽るアプリ。「ジャスティン ビーバー公式」のようなタイトルは、必要な許可や権利を得ていない限り、認められまない。

デバイス設定の不正な変更

ユーザの理解や同意を得ずに、アプリ外でユーザのデバイスの設定や機能を変更するアプリは認められない。デバイスの設定や機能には、システムやブラウザの設定、ブックマーク、ショートカット、アイコン、ウィジェット、ホーム画面でのアプリの表示などがある。

その他、次のようなアプリは認められない。

• ユーザの同意を得るが、簡単には元に戻せない方法でデバイスの設定や機能を変更するアプリ。

• サードパーティへのサービスとして、または広告表示を目的として、デバイスの設定や機能を変更するアプリや広告。

• ユーザを欺いて、サードパーティ アプリの削除や無効化、またはデバイスの設定や機能の変更を誘導するアプリ。

• セキュリティ サービスの一環として確認可能な場合を除き、サードパーティ アプリの削除や無効化、またはデバイスの設定や機能の変更をユーザに促したり、報奨付きで奨励したりするアプリ。

不正行為を助長する

人を欺くことを可能にするアプリや機能的に虚偽の振る舞いをするアプリは認められない。たとえば、ID カード、社会保障番号、パスポート、卒業証書、クレジット カード、銀行口座、運転免許証などを偽造できる、または偽造を補助するアプリが該当する（ただし、これらに限定されません）。アプリは、アプリの機能や内容に関してタイトル、説明、画像または動画を正確に開示し、ユーザが期待するとおり合理的に正確に機能しなければならない。

追加のアプリリソース（ゲームアセットなど）は、ユーザによるアプリの利用に不可欠な場合にのみダウンロード可能である。ダウンロードされるリソースは Google Play のすべてのポリシーを遵守する必要がある。また、ダウンロード開始前に、ユーザにメッセージを表示し、ダウンロード サイズを明確に開示する必要がある。

アプリが「いたずら」や「娯楽目的」などである、と主張する場合でも、アプリがポリシーの適用対象外となることはない。

違反の例

• 他のアプリやウェブサイトを装ってユーザに個人情報や認証情報を開示するようにだますアプリ。

• 同意を得ていない個人や団体の、未確認のまたは実在する電話番号、連絡先、住所、個人情報などを表示するアプリ。

• ユーザの地域、デバイス パラメータ、またはその他のユーザに応じたデータに基づいて、主たる機能が異なり、その違いについてストアの掲載情報でユーザに明確に宣伝していないアプリ。

• バージョン間で大幅に変更され、その変更についてユーザに（「最新情報」欄などで）通知をせず、ストアの掲載情報も更新しないアプリ。

• 審査時の動作を変更した、またはごまかしているアプリ。

• ダウンロードにコンテンツ配信ネットワーク（CDN）を利用しているのに、ダウンロードの前にユーザにメッセージを表示してダウンロード サイズを開示しないアプリ。

操作されたメディア

虚偽のまたは誤解を招くような情報や宣伝文句を画像、動画、テキストを通じて伝えることを助長する、またはその作成に役立つアプリは認められない。誤解を招く、または虚偽であることが明らかな画像、動画、テキストを助長、または固定化し、配慮が求められる事象、政治、社会問題など、社会的関心事に悪影響をもたらす可能性があると判断されたアプリは認められない。

メディアを操作または改変するアプリでは、明瞭さや品質の改善を目的とした慣習的で編集上許容される範囲の調整を超え、メディアが改変されていることを一般的な人が明確に識別できない可能性がある場合は、そのことを明示するか、改変したメディアの透かしを入れなければならない。ただし、公共性が高い場合や、風刺やパロディーであることが明らかな場合は例外として認められることがある。

違反の例

• 政治的に配慮が求められるイベント中のデモに著名人を登場させるアプリ。

• 配慮が求められるイベントに登場した著名人やメディアを利用して、アプリストアの掲載情報でメディア改変機能を宣伝するアプリ。

• メディアクリップを改変してニュース番組を模倣するアプリ。

参考資料

• Google Play デベロッパーポリシーセンター 虚偽の振る舞い

1.5.2.5. 不実表示

以下のようなアプリやデベロッパー アカウントは許可されない。

• 他の人や組織になりすましたり、オーナーや主目的を偽装、隠ぺいしたりしている。

• ユーザに誤解を与えるような組織的行為に関与している。たとえば、配信元の国を偽装、隠ぺいしたり、コンテンツを別の国のユーザに配信したりするアプリやデベロッパー アカウントなどが該当する。

• 政治や社会問題、公衆の関心事に関連するコンテンツを扱っている場合に、他のアプリやサイト、デベロッパー、アカウントと連携して、デベロッパーやアプリの重要情報（身元など）を隠ぺい、偽装している。

参考資料

• Google Play デベロッパーポリシーセンター 不実表示

1.5.2.6. Google Play の対象 API レベルに関するポリシー

ユーザに安全で保護されたエクスペリエンスを提供するため、Google Play ではすべてのアプリに対し、以下の API レベルを対象とすることを義務付ける。

新規アプリとアプリアップデートは、Android の最新のメジャー バージョンのリリースから 1 年以内にその Android API レベルをターゲットにする必要がある。この要件を満たさない新規アプリとアプリ アップデートは、Google Play Console からのアプリの送信ができなくなる。

アップデートのない既存の Google Play アプリ: Android の最新のメジャー バージョンのリリースから 2 年を過ぎてもその Android API レベルをターゲットにしていないアプリは、それ以降のバージョンの Android OS を搭載したデバイスの新規ユーザからアクセスできなくなる。そのアプリを以前に Google Play からインストールしたユーザは、アプリでサポートされていればどのバージョンの Android OS でも、引き続きアプリを検索、再インストール、使用できる。

対象 API レベルの要件を満たす方法についての技術的なアドバイスについては、移行ガイドを確認すること。

具体的なスケジュールについては、こちらのヘルプセンター記事でご確認すること。

参考資料

• Google Play デベロッパーポリシーセンター Google Play の対象 API レベルに関するポリシー

1.5.3. 知的財産権・知的所有権に関する Google Play での規則

アプリやデベロッパーアカウントが他者の知的所有権（商標権、著作権、特許権、企業秘密、その他の専有的権利を含む）を侵害する行為は認められない。知的所有権の侵害を助長または誘導するアプリも認められない。

Google では、著作権を侵害しているとする明確な通知を受けた場合には、それに対し適切に対応する。 DMCA に基づく申し立てを行う方法など、詳しくは、著作権に関する手続きを確認すること。

アプリ内での偽造品の販売または宣伝について申し立てを行うには、偽造品の報告を行うこと。

Google Play のアプリがご自身の商標権を侵害していると思われる場合は、該当のデベロッパーに直接連絡して、問題の解決にあたることを推奨する。デベロッパーと問題を解決できない場合は、こちらのフォームから商標権侵害を申し立てすること。

アプリ内またはストアの掲載情報で第三者の知的財産（ブランド名、ロゴ、画像および映像など）を使用する許可を受けていることを証明する文書がある場合は、知的所有権の侵害を理由にアプリが否承認となることがないよう、アプリを送信する前に Google Play チームに連絡すること。

参考資料

• Google Play デベロッパーポリシーセンター 知的所有権

1.5.3.1. 著作権で保護されているコンテンツの無断使用

著作権を侵害するアプリは認められない。著作権で保護されているコンテンツを改変することも違反となる場合がある。著作権で保護されているコンテンツを使用する場合は、その権利の証拠を示すよう求められることがある。

著作権で保護されているコンテンツをアプリ機能のデモとして使用する場合は、注意が必要である。オリジナルのものを作成することが、通常は最も安全な方法である。

違反の例

• 音楽のアルバム、ビデオゲーム、書籍のカバーアート

• 映画、テレビ、ビデオゲームのマーケティング画像

• マンガ、アニメ、映画、ミュージック ビデオ、テレビのアートワークや画像

• 大学やプロのスポーツチームのロゴ

• 有名人のソーシャル メディア アカウントから取得した写真

• 有名人のプロによる画像

• 著作権で保護されているオリジナル作品と区別がつきにくい複製または「ファンアート」

• 著作権で保護されているコンテンツの音声クリップを再生するサウンドボードを持つアプリ

• パブリック ドメイン以外の書籍の完全な複製や翻訳

1.5.3.2. 著作権侵害の助長

著作権侵害を誘導または助長するアプリは認められない。アプリを公開する前に、著作権の侵害をアプリが助長することにならないかどうか確認し、必要に応じて法律上の助言を受けること。

違反の例

• 著作権で保護されているコンテンツのローカルコピーをユーザが許可なくダウンロードできるストリーミングアプリ。

• 音楽や動画などの著作権で保護されているコンテンツを、該当する著作権法に違反して、ユーザがストリーミングやダウンロードすることを助長するアプリ

1.5.3.3. 商標権侵害

他者の商標を侵害するアプリは認められない。商標とは、商品やサービスの提供元を識別する語句、シンボル、またはその組み合わせです。商標権を取得した所有者には、特定の商品やサービスにその商標を使用する独占的な権利がある。

商標権の侵害とは、商品の提供元を混同させる可能性のある方法で、同一または類似の商標を不正にまたは無断で使用することである。こうした紛らわしい方法で他者の商標を使用するアプリは、公開が停止されることがある。

1.5.3.4. 偽造品

偽造品の販売や宣伝を行うアプリは認められない。偽造品とは、他の商標と同一、またはほとんど区別がつかない商標やロゴを使用している商品を指す。このような商品は、真正品と偽って販売するために、対象商品のブランドの特徴を模倣したものである。