データ保護評価に関してよくある質問

データ保護評価とは何か

1. データ保護評価とは何ですか？

   1. データ保護評価とは、特定の種類のデータにアクセスするアプリに毎年課される要件です。評価内の質問は、開発者が、プラットフォームデータの利用、共有、保護に関してプラットフォーム利用規約に準拠しているかどうかを確認することを目的としています。

2. プラットフォームデータとは何ですか？

   1. 「プラットフォームデータ」とは、開発者が本利用規約に同意した日より前であるか、当日であるか、その日より後であるかに関わらず、また直接間接を問わず、開発者がプラットフォームを通じてまたは開発者のアプリを通じて弊社から取得した情報、データまたは他のコンテンツを意味し、匿名化データ、集計データ、またはそのようなデータから派生したデータなどが含まれます。プラットフォームデータには、アプリトークン、ページトークン、アクセストークン、app secret、ユーザートークンが含まれます。
   2. アプリを介してMetaから受け取ったデータはすべて、プラットフォームデータとして見なされます。例えば、ユーザーID、ユーザーメール、ユーザーの友達はすべてプラットフォームデータです。

3. アプリレビューやデータの使用状況の確認との違いは何ですか？

   1. アプリレビューは、開発者が個々のアクセス許可と機能に対する承認をリクエストできる、先を見越したプロセスです。
   2. データの使用状況の確認は、開発者がMeta APIを介して行う特定のデータの継続的な利用とアクセスがプラットフォーム利用規約と開発者ポリシーに準拠していることを自己証明する年1回のプロセスです。
   3. データ保護評価は、プラットフォームデータに関してデータの使用状況、データの共有、データセキュリティについて開発者に質問する年1回のアンケートです。

4. データ保護評価に向けて準備するために何をすればよいですか？

   1. 確実に連絡が取れる状態にしておいてください。
      1. 開発者またはビジネスアカウント連絡先メールアドレスと通知の設定を更新します。
      2. アプリの基本設定ページで連絡先メールアドレスを更新してください。
      3. アプリにリストされている管理者を確認し、法務チームメンバーとデータセキュリティチームメンバーを管理者として追加し、これらのメンバーも質問に回答できるようにするかどうかを検討してください。
   2. データ保護の評価の質問を確認し、チームで連携してこれらの質問に最適な回答を導き出せるようにしてください。
   3. プラットフォーム利用規約および開発者ポリシーを確認してください。

データ保護評価が必要な理由

1. なぜデータ保護評価を実施する必要があるのですか？

   1. プライバシー規制に関する状況が絶えず変化しユーザーのプライバシーに対する脅威が絶え間なく進化する中で、関係者全員に、弊社の製品とサービスを利用するユーザーの信頼を築くべく徹底して努力する責任があります。この作業は、インターネット全体にわたってユーザーのデータが利用、共有、保護される方法に関する信頼の構築から始まります。
      1. 弊社のプラットフォーム上の特定の種類のデータにアクセスするアプリを所有する開発者は、データ保護評価を実行することが必要です。
      2. 弊社はすでに、弊社の規定のために新しいデータセキュリティ対策を実施した開発者の成功事例を確認しています。関係するパートナーが一丸となってこの問題に取り組めば、インターネット全体にわたる規定の水準を引き上げ、弊社のサービスを利用する世界中の数十億ものユーザーの信頼を得ることができます。

プロセス

1. データ保護評価を実施する必要があるかどうかは、どうすれば判断できますか？

   1. データ保護評価が必要なアプリの管理者である場合、[マイアプリ]ページ、アプリダッシュボード、アラート受信箱、開発者アカウントに関連付けられたメールで通知を受け取ります。
      1. 以下のステップを実行することで、評価に向けて準備するための通知が届きます。
         1. 確実に連絡が取れる状態にしておいてください。
            1. 開発者またはビジネスアカウント連絡先メールアドレスと通知の設定を更新します。
            2. アプリの基本設定ページで連絡先メールアドレスを更新してください。
            3. アプリにリストされている管理者を確認し、法務チームメンバーとデータセキュリティチームメンバーを管理者として追加し、これらのメンバーも質問に回答できるようにするかどうかを検討してください。
         2. データ保護の評価の質問を確認し、チームで連携してこれらの質問に最適な回答を導き出せるようにしてください。
         3. プラットフォーム利用規約および開発者ポリシーを確認してください。

2. どうすれば、データ保護評価に関連するメール通知を受信していることを確認できますか？

   1. データ保護評価が必要なアプリの管理者である場合、[マイアプリ]ページ、アプリダッシュボード、アラート受信箱、アプリ管理者アカウントに関連付けられたメールで通知を受け取ります。
   2. アプリ管理者の方は、確実に連絡が取れる状態にしておいてください。
      1. 開発者またはビジネスアカウント連絡先メールアドレスと通知の設定を更新します。
      2. アプリの基本設定ページで連絡先メールアドレスを更新してください。

3. データ保護評価を開始できるかどうかは、どうすれば判断できますか？

   1. データ保護評価が必要なアプリの管理者には、以下の方法で通知されます。
      1. お知らせ:
         1. 開発者またはビジネスアカウント連絡先メールアドレスにメールが送信されます。ここで個人用開発者通知の設定の編集を行います。
         2. アプリダッシュボードのアラート受信箱にメッセージが届きます。
         3. アプリダッシュボードを介してアプリ管理者に通知が届きます。
      2. 必要なアクションは次のとおりです。
         1. [マイアプリ]ページで、[データ保護評価]と呼ばれるアプリ情報カードに[必要なアクション]が表示されます。
         2. アプリダッシュボードの上部に[必要な操作]が表示されます。
         3. アプリの[基本設定]ページには、[データ保護評価]の記録が表示されます。

4. データ保護評価で取り上げられているトピックについて質問をすることはできますか？

   1. はい。データ保護評価の質問の内容を明確にする必要がある場合は、Metaに直接問い合わせることができます。
      1. データ保護評価内の左側には、[ヘルプが必要な場合]というタイトルのセクションがあります。このセクションの下にある[質問を送信]をクリックすると、より詳しい説明を求める質問を送信できるポップアップが表示されます。
      2. この機能にアクセスするには、ビジネスマネージャアカウントが必要であり、必ずアプリとアプリ管理者を追加する必要があります。詳細な手順のガイドについては、以下の各リンクを参照してください。
      3. メールアラートに加え、アプリダッシュボードの通知によってMetaから回答を受け取ります。

5. DPA審査チームから受け取った通信内容にヘルプページへのリンクが含まれるのですが、そのページにアクセスできません。このページにアクセスするにはどうすればいいですか？

   1. Metaの開発者向けドキュメンテーションサイトにはデータセキュリティ要件が公開されていますが、このコンテンツを利用できるのはFacebookアカウントでログパブリッシャーインしているユーザーだけです。このページを開いてドキュメントにアクセスすることができない場合は、以下のことを確認してください。
      1. 自分のFacebookアカウントにログインしていること。
      2. こちらにあるFacebookの開発者利用規約に同意したこと。

提出

1. データ保護評価提出期限までの期間はどのくらいありますか？

   1. データ保護評価の最初の通知から完了するまでには、60日間の猶予があります。

2. データ保護評価はどのくらいの頻度で提出する必要がありますか？

   1. 年に1回提出する必要があります。

3. このアンケートは回答に非常に時間がかかりますが、保存して複数回のセッションに分けて実施できますか？

   1. はい。このフォームは自動保存されるため、前回中断したところから再開できます。

4. 提出情報のステータスは、どうすれば確認できますか？

   1. 評価の全シナリオの定義は以下のとおりです。
      1. 未開始: 開発者はデータ保護評価が必要であることを伝える通知を受け取っており、期限はまだ先ですが、フォームへの記入に着手していません。
      2. 期限超過: データ保護評価フォームの提出期限が過ぎました。開発者が評価を実施する必要があり、実施しなければアプリの機能が制限されます。
      3. 提出済みだが、情報が不足: 開発者がデータ保護評価の質問に対する回答を提出し、Metaが審査を開始しましたが、詳しい説明が必要です。
      4. 提出済みで、違反発見: 開発者がデータ保護評価の質問に対する回答を提出し、Metaが審査を開始しましたが、アプリがプラットフォーム利用規約の1つ以上に違反していることが確認されました。この違反の重大度に応じて、アプリが制限される前に違反を解決する機会が与えられる可能性があります。ただし、最も重大な違反の場合は警告期間がありません。
      5. 提出済みで、審査中: 開発者がデータ保護評価の質問に対する回答を提出したか、詳細情報を求めるリクエストに応じています。Metaは審査を開始していますが、評価はまだ完了していません。
      6. 提出済みで、違反がなかった: 開発者がデータ保護評価の質問に対する回答を提出し、Metaが審査を完了し、アプリがプラットフォーム利用規約に準拠していることが確認されました。これ以上のアクションは必要ありません。

5. 昨年この評価を実施しました。その時の回答はどこからダウンロードできますか？

   1. 残念ながら、前回の評価の回答をダウンロードすることはできません。これは、評価内容をより明確にするために、アンケートを改訂しているためです。今回の評価に対する回答を提出した後、回答をPDFとして表示およびダウンロードできるようになります。

レビュー

1. Metaの審査担当者から、何らかの判断を下す前に、追加の質問をする目的で連絡があることはありますか？

   1. 回答の内容に基づく判断をするにあたって、Metaの審査担当者がより詳細な情報を必要とする場合、内容を明確にするための質問をすることがあります。この場合は、以下の方法で連絡します。
      1. お知らせ:
         1. 開発者またはビジネスアカウント連絡先メールアドレスにメールが送信されます。ここで個人用開発者通知の設定の編集を行います。
         2. アプリダッシュボードのアラート受信箱にメッセージが届きます。
         3. アプリダッシュボードを介してアプリ管理者に通知が届きます。
      2. 必要なアクションは次のとおりです。
         1. [マイアプリ]ページで、[データ保護評価]と呼ばれるアプリ情報カードに[必要なアクション]が表示されます。
         2. アプリダッシュボードの上部に、[必要な操作]が表示されます。
      3. ステータス: アクションが必要

2. Metaが詳細情報を求めていることを知らせるメールが届きました。なぜですか?

   1. これは、アプリがプラットフォーム利用規約に準拠しているかどうかを判断する前にMetaの審査担当者が確信を得る必要がある場合に、開発者が協力する機会になります。

3. Metaの審査担当者の質問に返信するにはどうすればよいですか？

   1. 受け取った通知(上記参照)には評価へのリンクがあります。このリンクからアクセスしたページの上部に、Metaの審査担当者が求めている追加情報に関する詳細が記載されています。フォームに回答し、必要に応じてドキュメントをアップロードしてください。回答が完了したら必ず[送信]をクリックしてください。

4. Metaの審査担当者の質問にはいつまでに返信する必要がありますか？

   1. 「追加情報要求」リクエストを受け取ったら、5営業日以内に回答する必要があります。最初の5営業日以内に回答しなかった場合、回答期間は2回延長されます(合計15営業日)。

違反への対応

1. プラットフォーム利用規約に違反している場合、アプリは制限されますか？

   1. はい。違反の内容に応じて、さまざまな制限がアプリに課される可能性があります。

2. 違反が見つかった場合、Metaの審査担当者から私に連絡がありますか？

   1. はい。評価に対する回答の内容に基づいて、Metaの審査担当者が違反を特定した場合、以下の方法で通知されます。
      1. お知らせ:
         1. 開発者またはビジネスアカウント連絡先メールアドレスにメールが送信されます。ここで個人用開発者通知の設定の編集を行います。
         2. アプリダッシュボードのアラート受信箱にメッセージが届きます。
         3. アプリダッシュボードを介してアプリ管理者に通知が届きます。
      2. 必要なアクションは次のとおりです。
         1. [マイアプリ]ページのアプリ情報カードに、[必要なアクション]が表示されます。
         1. 期限までに評価を提出できなかったことが違反の原因である場合、情報カードには「データ保護評価: 期限超過」と表示されます。
         2. データ保護評価が提出され、違反が見つかった場合、情報カードには「違反発見」と表示されます。
         2. アプリダッシュボードの上部に、[必要なアクション]が表示されます。
      3. ステータス: 違反発見

3. 対応しない場合はどうなりますか？

   1. 対応しない場合はプラットフォーム利用規約違反と見なされます。
      1. 60日以内に対応しなかった場合、アプリは利用解除されます。
         1. 評価を実施して提出し、アプリを復元してください。
         2. 「追加情報要求」リクエストを受け取ったら、5営業日以内に回答する必要があります。最初の5営業日以内に回答しなかった場合、回答期間は2回延長されます(合計15営業日)。15営業日が経過すると、アプリは施行の対象となります。
         3. これらの期限を過ぎると、アプリが制限される可能性があります。[マイアプリ]ページに移動すると、違反が原因で制限されているアプリを確認できます。
            1. この違反の重大度に応じて、アプリが制限される前に違反を解決する機会が与えられる可能性があります。ただし、最も重大な違反の場合は警告期間がありません。違反を解決するには、[マイアプリ]ページで[解決]リンクを見つけ、説明されているステップに従います。

4. 違反への対応の延長をリクエストするにはどうすればよいですか？

   1. 違反ごとに、対応への期限が3日以内になると、[延長をリクエストする]ボタンが表示されます。自動的に承認される警告期間(違反の内容に応じて異なります)と等しい期間の延長を2回リクエストできます。

5. データ保護評価で特定された違反を解決するにはどうすればよいですか？

   1. 違反が見つかってアプリが制限された場合、違反が修正されたことを示す証拠を提出して対応することで、違反を解決できます。対応して提出すれば、Metaの審査担当者がこれを審査し、[違反を解決する]フォームで直接対応します。

プラットフォーム利用規約3 (データ使用)

1. アプリの拠点の管轄区域またはユーザーの拠点を管轄区域には、ユーザーがユーザーデータの削除をリクエストしたときに(欧州連合やカリフォルニア州などのように)削除を求める権利を保障する適用法がありません。その場合でも、アプリはMetaポリシーに基づいてユーザーからの削除リクエストに従う必要がありますか？また、ユーザーが削除をリクエストする手順をプライバシーポリシーに含める必要がありますか？

   1. はい、アプリの拠点の管轄区域またはユーザーの拠点の管轄区域ではユーザーからユーザーデータの削除をリクエストされたときに開発者が削除する義務がない場合でも、弊社のプラットフォーム利用規約では、開発者は、1)ユーザーからプラットフォームデータの削除がリクエストされたときにプラットフォームデータを削除すること、2)ユーザーによる削除のリクエスト方法をプライバシーポリシーで説明することが必要です。ただし、適用法またはまたは規制により、これら2つのMetaの要件に従うことができない場合は除きます。

2. 私の会社は、プラットフォームデータを使って、ユーザーがデートアプリでのマッチング用として目的の基準を選択できるようにしたり、特定のコンテンツ(アルコールの販売など)を年齢制限して未成年のユーザーがアクセスできないようにしたりしています。これは、当社がプラットフォームデータを使って、特定のユーザーを人種、民族、肌の色、国籍、宗教、年齢、性別、性的指向、性同一性、家族構成、障害、医学的状態、遺伝子状態などに基づいて不利な立場に置いていることになりますか？

   1. いいえ、データ保護評価では、プラットフォームデータを使って、ユーザーがデートアプリで基準を設定できるようにしたり、コンテンツを年齢制限したりすることは、特定のユーザーを人種、民族、肌の色、国籍、宗教、年齢、性別、性的指向、性同一性、家族構成、障害、医学的状態、遺伝子状態などに基づいて不利な立場に置くこととは見なされません。

3. データを自動的に削除する機能がないために、Metaから要求される一部またはすべてのシナリオにおいて私のアプリでプラットフォームデータが削除されない場合、どうなりますか？

   1. 削除を自動的に行う必要はありません。特定のシナリオにおいてプラットフォームデータを削除するかどうかに関する質問にデータ保護評価で回答する場合、開発者のポリシーでは手動でまたは自動的に削除することになっている場合は肯定的に回答してください。

4. Metaの利用規約では、ユーザーが私のアプリでアカウントを削除するときに私がユーザーのプラットフォームデータを削除する必要があると定められています。しかし、私のアプリには、ユーザーがFacebookアカウントを削除したかどうかを認識するのに必要なコールバック機能がないため、私には削除することができません。これは、私のアプリがMetaの利用規約に違反していることになりますか？

   1. いいえ、これは、アプリがMetaの利用規約に違反していることにはなりません。コールバック機能は必要ありません。ただし、コールバック機能が用意されている場合、ユーザーによってFacebookアカウントが削除された時点でプラットフォームデータを削除する必要があります。また、ユーザーによってアプリ内アカウントが削除されたときもプラットフォームデータを削除する必要があります。

プラットフォーム利用規約4 (プライバシーポリシー)

1. 私のアプリのプライバシーポリシーには、ユーザーがデータの削除をリクエストできることをユーザーに伝える記述があります。これで十分ですか？

   1. この記述だけでは十分ではありません。ユーザーから開発者へのリクエストの送信方法に関する手順を含める必要があります。

プラットフォーム利用規約5 (サービスプロバイダーと技術提供者)

1. サービスプロバイダーとは何ですか？

   1. サービスプロバイダーとは、開発者がプラットフォームまたはプラットフォームデータに関するサービスを提供するために使用するエンティティを意味します。一般的な大手のサービスプロバイダーの例として、Google CloudやAmazon Web Services (AWS)などがあります。

2. サブサービスプロバイダーとは何ですか？

   1. サブサービスプロバイダーとは、別のサービスプロバイダーがプラットフォームまたはプラットフォームデータに関するサービスを提供するために使用するサービスプロバイダーです。

3. 技術提供者とは何ですか？

   1. 技術提供者は、ユーザーがプラットフォームまたはプラットフォームデータにアクセスして使えるようにすることを主な目的とするアプリの開発者を意味します。通常、技術提供者の主な目的は、ユーザーがMeta for Developersまたはプラットフォームデータを対象としてMetaにアクセスして使えるようにすることです。

4. 質問4で説明されている「その他」の目的の、書面による契約として適格であるものは何ですか？

   1. 書面による契約の例には、利用規約、標準的な交渉によらない契約、または署名された契約などがあります。

プラットフォーム利用規約6 (データセキュリティ)

1. Metaのデータセキュリティプラットフォーム利用規約6.a.iへの準拠を実証するには何を行う必要がありますか？

   1. 準拠を実証するため、第三者監査人から発行された情報セキュリティ証明書を開発者が所有しているかどうかが尋ねられます。このような証明書を所有することは義務ではありませんが、これは準拠を実証する1つの方法となります。開発者が実装している特定の保護手段についても尋ねられます。Metaは、社内基準を使用して開発者の回答を評価し、不明な点がある場合や開発者にその他の保護対策を実施することを求める場合、開発者をフォローアップします。

2. 情報セキュリティフレームワーク(ISF)またはサイバーセキュリティフレームワーク(CSF)認定資格を第三者監査人から取得する必要がありますか?

   1. いいえ、監査人の認定資格を取得する必要はありません。SOC 2、ISO 27001、ISO 27018、またはPCI DSSの証明書がある組織は、これらのいずれかを証明として提出できます。
      1. 証明書は、プラットフォームデータが保存または処理されているコンピューティング環境に関連するものである必要があります。
   2. セキュリティ証明書を提出したか否かに関わらず、実装している特定の保護対策について開発者は質問を受けることにご注意ください。

3. セキュリティ証明書を提出しない場合、データセキュリティ保護対策についてどのような質問に回答するよう求められますか？

   1. データ保護評価の実施を求められているすべての開発者は、以下を実装しているかどうか質問されます。
      1. すべてのプラットフォームデータのストレージ(すべてのデータベースファイル、バックアップ、オブジェクトストレージバケットなど)に対する保存データの暗号化の実施
      2. 組織のデバイス(紛失したか盗まれたノートパソコンまたはリムーバブルメディアなど)に保存されているプラットフォームデータを保護するための技術的コントロールや管理コントロール。例えば、年に1回のトレーニングが実施される書面によるポリシードキュメント、プラットフォームデータをこのようなデバイスに保存してはならないことを伝えるリマインダー、または技術的コントロールなど、さまざまなコントロールが認められます。
      3. プラットフォームデータが伝送されるすべての公開ネットワーク接続でのTLS 1.2以上の暗号化の実施
   2. さらに、リスクの高いデータにアクセスするアプリの開発者は、次の追加のセキュリティ保護を実施しているかどうか質問を受けます。
      1. 少なくとも12か月ごとに実施するアプリとシステムの脆弱性とセキュリティ問題に関するテスト
      2. 認証情報やアクセストークンなどの機密性の高いデータの保護
      3. データセキュリティインシデント(データ漏洩、サイバー攻撃など)に対処するためのシステムとプロセスのテスト
      4. リモートアクセスに対する多要素認証の義務化
      5. アカウントの維持(アクセスと権限の割り当て、撤回、確認)用のシステムの実装
      6. システムコードと環境(サーバー、仮想マシン、ディストリビューション、ライブラリ、パッケージ、ウイルス対策ソフトウェアを含む)を最新の状態に維持するためのシステムの実装
      7. 注: このリストはすべてを網羅したものではなく、開発者の組織の適切な情報セキュリティプログラムに取って代わるものではありません。

4. すべてのプラットフォームデータストレージで保存時の暗号化を強制しているかどうか質問を受けています。この質問の対象範囲には何が含まれますか？クラウドストレージとクライアントストレージの両方に当てはまりますか?

   1. 保存データの暗号化により、別の復号鍵がなければデータを解読できないようにすることでプラットフォームデータを保護します。これにより、不正な読み取りアクセスに対する別の保護レイヤーが提供されます。
   2. アプリのすべてのユーザーに関するプラットフォームデータが集中する傾向があるサーバー上またはクラウド環境内では、保存データの暗号化によってデータ漏洩のリスクが軽減されます。例えば、保存データの暗号化により、本番環境データベース自体ほどは厳重に防御できない可能性がある、データベースのバックアップに対する不正アクセスなどの脅威を防御します。
   3. 開発者の組織がプラットフォームデータをクラウドに保存している場合、開発者は、保存データの暗号化、または適切な補完コントロールを使用してこのデータを保護する必要があります。アプリケーションレベルの暗号化(データベース内の特定の列のソフトウェアによる暗号化/復号化など)またはフルディスク暗号化が認められます。業界標準の暗号化(AES、BitLocker、Blowfish、TDES、RSAなど)の使用を推奨しますが、特定のアルゴリズムや鍵の長さについて要求することはしません。
   4. 開発者の組織がプラットフォームデータをクラウドに保存していない場合、この要件は該当しません。
   5. 疑義を避けるため明記すると、開発者のサービスの個々のユーザーのウェブクライアントまたはモバイルクライアント内に保持されているデータは、この質問の対象外となります。
   6. 開発者の組織がクラウドIaaS製品(AWS EC2、Microsoft Azure IaaS、Google Compute Engineなど)を介してプラットフォームデータを保存している場合、開発者が自己ホスティングを使っている場合、または開発者がハイブリッドアプローチを使っている場合には、この質問の対象となります。
   7. ただし、SaaS製品の使用など、特別な事例であるその他のバックエンドホスティングモデルが存在します。開発者の組織がSaaS製品(MailChimpやSalesforceなど)を介してプラットフォームデータを保存している場合、この質問の対象外となります。代わりに、この関係をデータ保護評価のサービスプロバイダーセクションに記入する必要があります。PaaSホスティングの使用 - 開発者の組織がPaaS製品(AWS Elastic Beanstalk、Google App Engine、Force.comなど)を介してプラットフォームデータを保存している場合、この質問の対象外となります。代わりに、この関係をデータ保護評価のサービスプロバイダーセクションに記入する必要があります。BaaSホスティングの使用 - 開発者の組織がBaaS製品(AWS Amplify、Azure Mobile Apps、Azure Playfab、Google Firebase、MongoDB Switchなど)を介してプラットフォームデータを保存している場合、この質問の対象外となります。代わりに、この関係をデータ保護評価のサービスプロバイダーセクションに記入する必要があります。

5. プラットフォームデータが組織と個人のデバイスに保存されることをどうやって防止しているかという質問を受けています。どのような種類の防止対策が認められますか？

   1. 開発者は、組織のデバイス(紛失したり盗まれたりする可能性があるノートパソコンまたはリムーバブルメディアなど)に保存されているプラットフォームデータを保護するために、技術的コントロールや管理コントロール(ポリシーやルールなど)を適用する必要があります。例えば、書面によるポリシードキュメントと年1回のトレーニングの実施、プラットフォームデータをこのようなデバイスに保存してはならないことを伝えるリマインダー、または技術的コントロールなど、さまざまなコントロールが認められます。

6. プラットフォームデータを伝送するすべてのネットワーク接続について、TLS 1.2以上を有効にしているか質問されています。この質問の対象範囲には何が含まれますか？

   1. この質問は、プラットフォームデータが関係するインターネット経由データ転送が対象となります。それには、ウェブまたはモバイルクライアントから自分のクラウド環境への転送と、クラウド環境間でのインターネット経由の転送が含まれます。
   2. インターネットで転送されるプラットフォームデータには、ネットワークトラフィックを観察できる誰もがアクセスできます。したがって、このようなデータは暗号化によって保護し、不正な人物がデータを読み取ることができないようにする必要があります。送信中のデータを暗号化することにより送信元のデバイスや送信先のデバイス以外では解読不能にすることで、信頼できないネットワーク(インターネットなど)を経由して送信されるプラットフォームデータを保護します。つまり、送信の途中に存在する人物がネットワークトラフィックを観察できる場合でも(中間者攻撃とも呼ばれます)、プラットフォームデータを読み取ることができません。TLSは、ブラウザーが銀行などのウェブサイトとの通信の安全を確保するために使用するテクノロジーであるため、送信中のデータを暗号化するための最も一般的な形式です。
   3. 以下の図は、プラットフォームデータの送信が関わる可能性があるネットワーク接続を示しています。黄色の点線は、開発者がTLS暗号化を使用して安全を確保する責任を負う接続です。
      
      
      プライベートネットワーク内で完結するデータの送信(AWSやGCPバーチャルプライベートクラウド(VPC)など)の場合、TLSが推奨されますが、必須ではありません。
      
      
      以下の表に、Metaプラットフォームデータの転送に関するTLS暗号化の要件をまとめます。

      つながり	TLSポリシー
      エンドユーザーデバイス(携帯電話、PC、タブレットなど)と、自社サーバーまたはクラウドインフラストラクチャとの間	互換性のあるデバイスに対してTLS 1.2以上を有効にする必要があります 古いデバイスとの互換性のためにTLS 1.0および1.1を有効にすることができます
      自社サーバーまたはクラウドインフラストラクチャと、リモートのサーバー、クラウドインフラストラクチャ、または第4者サーバーとの間	TLS 1.2以上が有効でなければならない
      自社プライベートデータセンター、サーバー、またはクラウドインフラストラクチャの中で完結するコンポーネント間	プライベートクラウドネットワーク内で完結するプラットフォームデータ転送の場合、TLS暗号化をおすすめします(必須ではありません)
      Facebookと、任意のデバイス、サーバー、またはクラウドインフラストラクチャとの間	データ保護評価の適用範囲外 - これらの転送については、FacebookによりTLSポリシーが管理されます

      アプリケーションに適した暗号化およびその他の補完コントロールのガイドについては、最高情報セキュリティ責任者(CISO)または組織内の同等の役職、または要件を満たすサイバーセキュリティ会社に相談してください。

7. アプリとシステムに脆弱性とセキュリティ上の問題の有無を少なくとも12か月ごとにテストしているかどうか質問を受けています。どのような種類のテストが認められますか？

   1. Metaのプラットフォームにアクセスするアプリ開発者は、プラットフォームデータにアクセスして処理するためのソフトウェアを作成し、このソフトウェアを使用してユーザーにサービスを提供します。このソフトウェア(および関連するシステム構成)には、悪意のあるハッカーが悪用できるセキュリティの脆弱性が含まれる可能性があり、これはプラットフォームデータへの不正なアクセスにつながります。したがって、開発者は、脆弱性とセキュリティの問題についてテストし、これらを事前に発見できるようにしなければなりません。セキュリティインシデントが発生する前に防御するのが理想的です。
   2. アプリのライフサイクル全体を通して、さまざまな形のセキュリティテストを行えます。通常、特に個人情報などの機密データを処理する場合は、単純な脆弱性スキャンから、アプリケーションセキュリティスキャン、侵入テストにいたるまで、複数のテスト手法を組み合わせます。
   3. 開発者は、ソフトウェアの侵入テストまたは脆弱性スキャン/静的分析を実施することで、プラットフォームデータを処理するために使用するソフトウェアのセキュリティの脆弱性をテストしておく必要があります。テスト結果では、解決されていない重大な脆弱性または深刻度の高い脆弱性がないことが示されている必要があります。テストは、過去12か月以内に完了している必要があります。
   4. また、開発者の組織がプラットフォームデータをクラウドで処理している場合は、認められるセキュリティ脆弱性テストでアプリ/システムの侵入テスト、または脆弱性スキャン/静的分析のいずれかを実施することにより、クラウドソフトウェアのセキュリティ脆弱性をテストしておく必要があります。さらに、クラウド構成のセキュリティの問題のテストも必要です。この要件は、ホスティングアプローチ(BaaS、PaaS、IaaS、自己ホスティング、またはハイブリッドなど)に関わらず該当します。

8. 認証情報やアクセストークンなどの機密性の高いデータを保護しているかどうか質問を受けています。この質問の対象範囲には何が含まれますか?

   1. app secretおよびアクセストークンは、MetaのAPIを介して使用可能なデータへのアクセス制御を提供する点において、MetaのAPIのセキュリティの基盤となっています。不正な人物がこれらの認証情報にアクセスできる場合、この人物は(本物の開発者になりすまして) MetaのAPIを呼び出し、弊社がアプリに許可している任意のアクション(アプリのユーザーに関するデータを弊社のAPIから読み取るなど)を実行できる可能性があります。
   2. 開発者は、Metaのプラットフォームの使用の一環として機密認証情報にアクセスできます。具体的な内容は以下のとおりです。
      1. app secret - Metaは、開発者の組織内の信頼できる人物(アプリ管理者など)しかapp secretにアクセスしないことを期待して開発者とapp secretを共有します。
      2. アクセストークン - アプリが承認されると、開発者は、それ以降のAPI呼び出しで使用されるアクセストークンと呼ばれる認証情報を取得します。
   3. これらの機密認証情報を読み取ることができる不正な人物は、開発者を偽装して(トークンのなりすましとも呼ばれます)、これらの情報を使ってMetaのAPIを呼び出すことができます。そうすると、結果としてプラットフォームデータへの不正なアクセスにつながります。したがって、これらの認証情報を不正なアクセスから保護し、なりすましを防ぐ必要があります。
   4. app secret - 以下の2つのどちらが該当する必要があります。
      1. 開発者は、セキュリティが確保されたサーバー環境外でapp secretを公開しない(例: app secretがネットワーク呼び出しによってブラウザーまたはモバイルアプリに返されない、モバイルまたはネイティブ/デスクトップクライアントに配信されるコードにapp secretが埋め込まれない)
      2. 開発者は、ネイティブ/デスクトップタイプでアプリを構成し、app secretが含まれるAPI呼び出しを弊社のAPIが信頼しないようにする
   5. アクセストークン - 以下のすべてが該当する必要があります。
      1. クライアントデバイス上 - Metaのアクセストークンは、別のユーザーまたはプロセスが読み取ることができるように作成してはならない
      2. クラウド内 - 開発者がMetaのアクセストークンをクラウド内で処理または保存する場合、これらのアクセストークンは、次の条件を満たしていなければならない。
         1. 資格情報コンテナまたはアプリケーションの暗号化によって保護される必要がある。この場合、復号鍵へのアクセスはアプリケーションに限定され、ログファイルに書き込んではならない
         2. または、適切な補完コントロールによって保護される必要がある

9. 少なくとも12か月ごとにセキュリティインシデント対応システムとプロセスをテストしているかどうか質問を受けています。この質問の対象範囲には何が含まれますか?

   1. セキュリティインシデントはすべての会社でいつかは発生するものなので、インシデントの抑制、関係者との連絡、復旧、発生した事態からの教訓の学習のために、誰が何を行うか組織が事前に計画しておくことが重要です。セキュリティインシデントが発生した場合、(対処方法のトレーニングを受けているチームと一緒に)プランまたはプレイブックを準備しておくと、インシデントの期間を短縮し、最終的にはプラットフォームデータの露出を制限できます。
   2. 組織が異なればインシデントへの対応の洗練度のレベルも異なりますが、弊社では、少なくとも、主な活動(検知、対応、復旧、審査)とともに、役割と責任が割り当てられて指名された人員が含まれる基本的な計画を必要としています。また、開発者は、その計画が最近(過去12か月以内に)テストされていること、およびその計画で指名されている人員がテストに参加したことを示す証拠を文書化しておく必要があります。

10. リモートアクセスで多要素認証を必須としているかどうか質問を受けています。この質問の対象範囲には何が含まれますか?

    1. 攻撃者が機密データにアクセスするために使用する一般的な技術は、開発者がアプリ/システムを構築または操作するために使用するツールにアクセスすることから始まります。パスワードのみによって保護されたアカウントに不正アクセスする目的でユーザーの認証情報を取得する(フィッシング攻撃など)ための高度なツールが存在します。多要素認証を使用すると、このリスクを防止するためのセキュリティレイヤーが強化されます。
    2. ソフトウェア開発者は、さまざまなツールを使ってアプリやシステムを構築、展開、管理します。これらのツールは、インターネットを介してリモートで使用するのが一般的です(例えば、従業員が在宅勤務で新しいソフトウェア機能を納品したり、クラウド構成を更新したりします)。単一要素認証(ユーザー名とパスワード)を使用して保護されているツールは、アカウントの乗っ取り攻撃を非常に受けやすくなります。例えば、攻撃者は1つのツールから流出したユーザー名とパスワードの組み合わせをさまざまなツールで試し、別のツールにアクセスできるかもしれません。多要素認証では、ログイン時にパスワード以外の別の要素(認証システムアプリによって生成されたコードなど)を義務化することで、このような攻撃から保護します。
    3. 組織によるプラットフォームデータの処理に関しては、これらのツールに対するリモートアクセスを多要素認証によって(つまり、パスワードのみの認証ではなく)保護する必要があります。
       1. アプリ/システムに対するコード/構成の変更を展開および管理するために使用するツール
       2. クラウドまたはサーバー環境への管理アクセス(該当する場合)
       3. 具体的には以下のとおりです。
          1. コラボレーション/通信ツール - ビジネスメールやSlackなど
          2. コードリポジトリ - アプリ/システムのコード/構成に対する変更を追跡するために使用するGitHubまたは別のツールなど
       4. 組織がクラウド/サーバー環境内でプラットフォームデータを処理する場合については、次のものが該当します。
          1. ソフトウェア開発ツール - クラウド/サーバー環境にコードを展開するために使用するツール(Jenkinsまたは別のContinuous Integration / Continuous Deployment (CI/CD)ツールなど)
          2. 管理ツール - クラウド/サーバー環境を管理/監視するために使用するポータルまたはその他のアクセス
          3. サーバーへのリモートアクセス - クラウド/サーバー環境内で動作するサーバーにリモートでログインするために使用するSSH、リモートデスクトップ、または同様のツール

11. アカウントを管理(アクセスと特権の割り当て、取消、審査)するためのシステムがあるかどうか質問を受けています。この質問の対象範囲には何が含まれますか?

    1. 優れたアカウント管理対策を講じることは、プラットフォームデータにアクセスするためのアカウントの不正な使用を防止する重要な要素の1つです。特に、開発者は、リソースまたはシステムへのアクセスが必要なくなったときにアクセス権を取り消すことを徹底する必要があります。アカウントは、ユーザーに対するシステム、データ、管理機能へのアクセス権の付与の管理における基本単位です。アカウントには、特定のアクションを可能にするアクセス許可が付与されます。このため、アカウントが必要とする最小限のアクセス許可を付与することを推奨します。これは、最小権限の原則と呼ばれます。
    2. 誰かが退職した場合、次のような理由により、ユーザーアカウントをすみやかに無効にすることが重要です。
       1. この人物(元社員)によるアクセスを防止する。
       2. 不正な人物がこのアカウントを気付かれずに使用する可能性を低くする。例えば、悪意のあるハッカーがソーシャルエンジニアリングを使用して、ITヘルプデスクにこのアカウントのパスワードをリセットさせる可能性があります。このアカウントが現在の社員に属している場合、この社員はログインできないことを報告する可能性が高いですが、このアカウントが退職した社員に属していて依然としてアクティブのままの場合、気付かれる可能性は低くなります。
    3. 組織は、この点を念頭に、アカウントの管理、アクセス許可または権限の付与、不要になったアクセスを取り消すための体系的な方法を構築する必要があります
    4. 開発者には、以下の各ツール/システム/アプリのアカウントを管理するためのツールまたはプロセスが必要です。
       1. 互いに連絡を取るために使用するもの(Slackやビジネスメールなど)
       2. ソフトウェアを納品するために使用するもの(コードリポジトリなど)
       3. システムを管理および操作するために使用するもの(プラットフォームデータの処理に適したもの)
    5. 開発者は、アクセス権を定期的(少なくとも12か月ごと)に審査し、(1)アクセスが不要になったとき、および(2)アクセスが使われなくなったときにアクセス権を取り消すプロセスを構築する必要があります
    6. また、開発者には、誰かが退職したときにこれらのツールへのアクセス権をすみやかに取り消すプロセスも必要です。

12. サーバー、仮想マシン、ディストリビューション、ウイルス対策ソフトウェアなど、システムコードと環境を最新の状態に維持するシステムがあるかどうか質問を受けています。この質問の対象範囲には何が含まれますか?

    1. ソフトウェアコンポーネントは、セキュリティの脆弱性を解決するために定期的に更新またはパッチ適用されており、これらのコンポーネントは最終的にサポートされなくなると廃止されます。これらのコンポーネントをパッケージに含める開発者またはそれらを利用する開発者は、既知の脆弱性があるソフトウェアの実行を回避するため、常に最新の状態を維持する必要があります。
    2. アプリ開発者は、プラットフォームデータを処理するアプリ/システムを実行するためにさまざまなサードパーティのソフトウェアを使用します。例えば、開発者が以下の一部またはすべてを使用することが考えられます。
       1. ライブラリ、SDK、パッケージ - 開発者は、これらを独自のカスタムコードとともにパッケージ化してアプリを構築します
       2. 仮想マシン画像、アプリコンテナ、オペレーティングシステム - アプリがこれらの1つ以上のコンテナ内で動作し、これらのコンテナが仮想化やネットワークとストレージへのアクセスなどのサービスを提供します
       3. 開発者の会社の社員/貢献者が使用するブラウザー、オペレーティングシステム、その他のアプリケーション - 開発者がシステムを構築および実行するために使用するモバイルデバイスやノートパソコン上で動作するソフトウェア
    3. セキュリティの脆弱性はこれらのコンポーネントで定期的に発見されており、その結果としてパッチがリリースされています。その後、パッチによって修正された脆弱性が重大度評価(低、中、高、重大)とともにパブリックデータベース内で開示されます。したがって、弊社のプラットフォームを使用する開発者には、以下の方法によってパッチを管理する体系的な手段が必要です。
       1. アプリ/システムに関連するパッチを特定する
       2. 露出に基づいて緊急性に優先順位を付ける
       3. 継続中のビジネスアクティビティとしてパッチを適用する
    4. 以下のソフトウェアコンポーネントの場合、開発者は必要に応じて、セキュリティの脆弱性を解決するために使用可能なパッチを特定する、リスクに基づいて優先順位を付ける、継続中のアクティビティとしてパッチを適用する体系的な手段を策定する必要があります。
       1. クラウドまたはサーバー環境で使用されるライブラリ、SDK、パッケージ、アプリコンテナ、オペレーティングシステム
       2. クライアントデバイス上(モバイルアプリ内など)で使用されるライブラリ、SDK、パッケージ
       3. アプリ/システムなどを構築および操作するために組織のメンバーが使用するオペレーティングシステムとアプリケーション(社員のノートパソコン上で動作しているオペレーティングシステムとブラウザー)

13. 挙げられているセキュリティ管理ではなく、それらに相当するものを実装している場合はどうすべきですか?

    1. Metaから実行するよう求められているコントロールの1つがMetaのプラットフォームデータを使用(保管や処理など)する上で意味のないものであると開発者が考えている場合、または開発者がこれらの1つ以上の保護のために補完コントロールを実装している場合、状況について説明し、違反を解決するために証拠を提出してください。コンプライアンス要件に関して弊社からメールが届いた場合、メールに記載されている指示に従ってアプリダッシュボードで対応する必要があります。メール通知が見つからない場合は、このアプリの[マイアプリ]ページまたはアプリダッシュボードにアクセスしてください。

14. ユーザーからセキュリティ上の脆弱性に関する報告を受けるために一般公開されている方法があるかどうかについて質問を受けています。その対応のために特定のチャンネルが必要ですか？

    1. 弊社のポリシーでは、セキュリティの脆弱性を報告するために個別のチャンネルは必要ありません(また、定期的に監視されているメールアドレス、お問い合わせフォーム、またはスマートフォンなどの連絡先情報はポリシーに準拠しています)。ただし、開発者が例えばBugCrowdやHackerOne上で脆弱性開示プログラム(VDP)を運用することで、この目的のために構造化されたプログラムを導入することが推奨されています。

15. DPA審査チームから受け取った通信内容の中に、質問番号のことが書かれています。それらは何の番号ですか？

    1. Meta審査チームから受け取る通信内容に質問番号のことが書かれているかもしれません。それらの番号は主に社内レビュー処理用ですが、参考としてその説明を下記に示します。
    1. Q9 - クラウド環境またはサーバー環境における保存データの暗号化。
    2. Q10 - 組織や個人のデバイス上のプラットフォームデータの保護。
    3. Q11 - プラットフォームデータ転送時の暗号化による保護。
    4. Q12 - アプリとシステムのセキュリティ脆弱性についてのテスト。
    5. Q13 - Metaのapp secretとアクセストークンを保護する。
    6. Q14 - インシデント対応計画を立て、インシデント対応のシステムと処理をテストする。
    7. Q15 - リモートアクセスでの多要素認証を義務化する。
    8. Q16 - ユーザーアカウント維持のためのシステムを用意する。
    9. Q17 - ソフトウェアを最新の状態に保つ。

16. DPA審査チームから、ポリシーや手順の証拠資料が欠落しているか、または不十分であるというフィードバックを受け取りました。ポリシーや手順の証拠資料とは何ですか？

    1. データセキュリティのための質問のうちの1つ以上に関連して、ポリシーまたは手順の証拠資料についてのフォローアップ質問がなされることがあります。それらが、Meta審査チームによって、Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16、Q17のうちのいずれか1つの番号により参照されていることがあるかもしれません。
       
       いずれの場合も、ポリシーまたは手順の証拠資料というのは、特定のデータセキュリティ保護を実装するために組織が採用するアプローチについて説明するために作成されたドキュメントのことです。例えば、組織には次の文書があるかもしれません。
    1. 認証ポリシードキュメント。これは、プラットフォームデータにアクセスできるようなビジネス、開発、システムの管理ツールは、すべて多要素認証によって保護する必要があるということなどを述べるドキュメントです。
    2. 暗号化ポリシー。これは、Metaプラットフォームデータのすべてを、転送時に暗号化により保護し、さらに保存中も暗号化により保護する必要があることなどを述べるものです。
    3. パッチ手順。これは、組織のクラウドアプリに影響するセキュリティパッチが利用可能かどうかを確認するための手順をどれほどの頻度で実施する必要があるか、それぞれのパッチの影響評価を実施する方法、重大度に応じてパッチをデプロイするための最大時間、パッチをデプロイする方法などを述べるものです。
    これらすべては、関連する質問に対するポリシーまたは手順についてのドキュメントとして受け入れられる形を示す例です。取られているアプローチがMetaの要件を満たしていることを確認するため、MetaのDPAレビュアーは、提供された書類を審査します。付加的な例や提出するポリシーの証拠を準備する方法の詳細など、詳しくは、Metaの開発者向けドキュメントの証拠資料の準備をご覧ください。

17. DPA審査チームから、実装の証拠資料が欠落しているか、または不十分であるというフィードバックを受け取りました。実装の証拠資料とは何ですか？

    1. データセキュリティのための質問のうち1つ以上に関連する実施の証拠資料について、フォローアップ質問を受ける場合があります。データセキュリティのための質問が、Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16、Q17のいずれかの番号で参照されることがあります。
       
       いすれの場合も、ドキュメントに示されているポリシーや手順の実装について示すため、実装の証拠資料を含めることが重要です。証拠資料には、管理者システムのスクリーンショットや、組織が実際にどのように保護アプローチを実行したかを示すツールからの出力を含めることができるでしょう。実装の証拠資料が受け入れられるには、組織の実装が保護に関するMetaの要件を満たしていることを示していなければなりません。保護のそれぞれについて、少なくとも1つの実装の証拠を提出する必要があります。
       
       詳しくは、各保護の証拠資料の準備に関する開発者向けドキュメントをご覧ください。
    1. クラウド環境またはサーバー環境における保存データの暗号化。
    2. 組織や個人のデバイス上のプラットフォームデータの保護。
    3. プラットフォームデータ転送時の暗号化による保護。
    4. アプリとシステムのセキュリティ脆弱性についてのテスト。
    5. Metaのapp secretとアクセストークンを保護する
    6. インシデント対応計画を立て、インシデント対応のシステムと処理をテストする。
    7. リモートアクセスでの多要素認証を義務化する。
    8. ユーザーアカウント維持のためのシステムを用意する。
    9. ソフトウェアを最新の状態に保つ。

18. 組織と個人のデバイス上にあるプラットフォームデータをどうやって保護しているのかという質問を受けています。Metaの要件はどのようなものですか？

    1. 組織と個人のデバイス上にあるプラットフォームデータが失われないよう組織がどのように保護しているかについて、フォローアップ質問を受ける場合があります。それらの質問について、Q10aまたはQ10bで言及されていることがあります。
       
       Metaでは、以下のうち少なくとも1つを示すことを求めています。
    1. Metaプラットフォームデータを含むシステムへのアクセスをブロックするための手順を組織として実施していること。ただし、次のいずれか、または両方が当てはまるデバイスを除く。
       1. すべてのデバイスで、FileVaultやBitLockerなどによりディスク全体の暗号化が有効になっている必要がある。
       2. すべてのデバイスで、Microsoft IntuneやSymantec DLPなど、エンドポイントDLPソフトウェアが実行されている必要がある。
    2. 組織内の誰かがMetaプラットフォームデータを組織または個人のデバイス上に保管することを禁じるポリシーが、組織として確立されていること。かつ、組織内の人はそのポリシーに従う義務があることを述べる文書としての証拠資料があること。
    3. 次のことを述べるポリシーが、組織にあること。
       1. 組織デバイス上のプラットフォームデータを処理できるのは、そこへのアクセスを必要としており、認定されたビジネス目的のある個人だけであること
       2. 認定されたビジネス目的が存在しなくなった場合、各個人がそれらのデバイスからプラットフォームデータを削除する必要があること。
    4. ソフトウェアのビルド方法(Metaプラットフォームデータの保存先がエンド顧客のデバイスの一時メモリー内だけ、など)に関わらず、Metaプラットフォームデータが組織内の誰からもアクセス可能にならないこと

19. FacebookまたはMetaのapp secretとは何ですか？

    1. FacebookまたはMetaのapp secretを保護する方法について、フォローアップ質問を受けることがあるかもしれません。この質問は、番号Q13でも言及されることがあります。
       
       app secretは、Facebookアプリに関連する1つのパラメーターであり、Webhookコールバックを設定する場合など、特定のAPI呼び出しの中でアプリの設定を変更するためにアクセストークンとして使うことができます。アプリのFacebook app secretは、開発者ダッシュボードの[設定] > [基本]で確認できます。app secretについて詳しくは、Metaの開発者向けドキュメントのログインセキュリティをご覧ください。
       
       app secretとユーザーアクセストークンを保護するためのMetaの要件(提出する証拠資料を含む)については、Meta app secretとアクセストークンを保護するをご覧ください。

20. アカウントの管理と維持の方法についての質問を受けています。Metaの要件はどのようなものですか？

    1. 組織にアカウントの管理のためのシステムや関連するプロセスがあるかどうかについて、フォローアップ質問を受けることがあります。この質問は番号Q16でも言及されることがあります。
    1. 組織内でのコミュニケーション、ソフトウェアの開発と配信、システムやアプリケーションの管理のために組織で使うアプリやシステムへのアクセスを、これらのアプリやシステムがどの程度プラットフォームデータの処理に適用されるかに応じて、許可したり取り消したりするためのツールまたはプロセスが必要です。
    2. 少なくとも12か月に1回、以前に付与されたアクセスを再検討し、不要になり使わなくなったものを取り消すための手順が確立されていなければなりません。
    3. 誰かが退職した際にすべてのアプリとシステムへのアクセス権をすみやかに取り消すプロセスも必要です。
    提出する証拠資料の詳細など、詳しくは、Metaの開発者向けドキュメント、ユーザーアカウントを維持するためのシステムを用意するをご覧ください。

21. システム/ソフトウェアの脆弱性に関するテスト方法について質問されています。Metaの要件はどのようなものですか？

    1. 組織でシステム/ソフトウェアの脆弱性に関してテストをしているかどうかについて、フォローアップ質問を受けることがあります。この質問は番号Q12で言及されることがあります。
       
       組織がMetaプラットフォームデータをクラウド環境で処理する場合(AWS、Azure、GCP、Alibaba Cloud、Tencent Cloud内など)、
    1. 次のいずれかによるクラウドソフトウェアのセキュリティ脆弱性に関するテストが実施済みであることが必要です。
       1. アプリやシステムの侵入テストまたは外部スキャン
       2. ソフトウェアの静的または動的分析セキュリティツール
       3. Metaの要件を満たす脆弱性開示プログラムを実施する
    2. 次のいずれかによるクラウドアセット設定の脆弱性に関するテストが実施済みであることも必要です。
       1. クラウドホストが提供するツール
       2. 別の商用ツールまたはオープンソースツール
       3. Metaの要件を満たす脆弱性開示プログラムを実施する
       4. クラウド設定審査が自分の組織に該当しない場合、該当しない理由を、実証済みの証拠資料の一部として説明する必要があります
    3. 上記の両方のアクティビティを過去12か月以内に実施していることを示す必要があります。
    Metaでは、通常、深刻な脆弱性または重大度の高い脆弱性がすべて解決済みであることを求めています。
    
    ホスティング方法の違うサーバー環境でMetaプラットフォームデータを処理する組織では、
    1. 次のいずれかによるサーバーソフトウェアのセキュリティ脆弱性に関するテストが実施済みであることが必要です。
       1. アプリやシステムの侵入テストまたは外部スキャン
       2. ソフトウェアの静的または動的分析セキュリティツール
       3. Metaの要件を満たす脆弱性開示プログラムを実施する
    Metaでは、通常、深刻な脆弱性または重大度の高い脆弱性がすべて解決済みであることを求めています。
    
    その他のすべての組織の場合、
    1. 次のいずれかによるクライアントソフトウェアのセキュリティ脆弱性に関するテストが実施済みであることが必要です。
       1. 侵入テストまたは外部スキャン
       2. 静的または動的分析セキュリティツール
       3. Metaの要件を満たす脆弱性開示プログラムを実施する
    2. このアクティビティを過去12か月以内に実施したことを示す必要があります
    Metaでは、通常、深刻な脆弱性または重大度の高い脆弱性がすべて解決済みであることを求めています。
    
    提出することが必要な証拠資料など、詳しくは、Metaの開発者向けドキュメント、アプリとシステムの脆弱性とセキュリティの問題をテストするをご覧ください。




22. システムを最新の状態に保つ方法について質問されています。Metaの要件はどのようなものですか？

    1. 組織にシステムコードと環境を最新の状態に保つためのシステムがあるかどうかについて、フォローアップ質問を受けることがあります。この質問は番号Q17でも言及されることがあります。
    次のことを反復実行するための処理を定義してあることを示す必要があります。
    1. セキュリティ脆弱性を解決するパッチのうち、Metaプラットフォームデータを処理するために実際に使っているソフトウェアに関係のあるものを特定する。
    2. リスクに基づいてそれらのパッチの優先順位を定める。
    3. 継続中のアクティビティとしてパッチを適用する。
    上記の要件すべてを満たした処理がなされていることを確認できるよう、ソフトウェアがプラットフォームデータをどう処理するかについて十分な詳細を含めてください。例えば、スタックの他のレイヤーに対するアプローチ(アプリ内での仮想化レイヤー、コンテナレイヤー、アプリケーションコンテナレイヤー、ライブラリ、依存性など)についての説明がないと、組織にサーバーOSのパッチ処理のためのプロセスがあると説明されても受け入れられません。
    
    詳しくは、Metaの開発者向けドキュメント、ソフトウェアを最新の状態に保つをご覧ください。

これらのよくある質問(FAQ)は、DPAへの対応に役立つ情報とリンクを提供することを目的としたものですが、MetaにおけるDPAの評価方法を制御しているのはデータセキュリティ要件です。よくある質問(FAQ)はガイドにすぎず、要件に反することをしたり、要件を置き換えたりするために読むべきではありません。

詳しくはこちら

• データ保護評価ガイド
• Meta for Developers – プラットフォーム利用規約