Meta 应用开发
返回中文(简体)
文档已更新。
中文(简体) 译文尚未完成。
英语更新时间：4月29日

数据保护评估常见问题

数据保护评估是什么

  1. 数据保护评估是什么？

    1. 数据保护评估是访问某些数据类型的应用需遵守的一项年度要求。评估中包含的问题旨在确定开发者在使用、分享和保护开放平台数据方面是否遵守开放平台条款。

  2. 开放平台数据是什么？

    1. “开放平台数据”指您在同意本篇条款之前、当天或之后，通过开放平台或您的应用直接或间接地从我们这里获取的任何信息、数据或其他内容，包括对此等数据进行匿名化处理、汇总得到的或从此等数据中派生的数据。开放平台数据包括应用口令、页面口令、访问口令、应用密钥和用户口令。
    2. 您通过应用从 Meta 取得的所有数据均视为开放平台数据。例如，用户的 ID、邮箱和好友信息都属于开放平台数据。

  3. 这与应用审核和数据使用情况检查有何不同？

    1. 应用审核是一个前瞻性流程，用于请求对各项权限和功能的许可。
    2. 数据使用情况检查是每年都要进行的一项工作，要求开发者自行证明，他们通过 Meta API 对特定数据的使用和访问始终都遵循了我们的开放平台条款和开发者政策。
    3. 数据保护评估则是一项年度调查问卷，会向开发者询问其对于开放平台数据的使用、分享和保护情况。

  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 的回复。
    1. Meta 已在开发者文档网站上发布数据安全要求，但只有已登录 Facebook 帐户的用户才能访问该内容。如果您无法打开该页面并访问文档，请确保您已完成以下操作：
      1. 已登录 Facebook 帐户，并且
      2. 已接受此处的 Facebook 开发者条款。

提交

  1. 我有多少时间提交数据保护评估？

    1. 从第一条通知发出之日算起，您有 60 个日历日的时间完成数据保护评估。

  2. 我要多久完成一次数据保护评估？

    1. 这项评估每年进行一次。

  3. 问卷非常长，我是否可以保存进度，然后分批次完成里面的问题？

    1. 是。表单会自动保存，方便您之后从先前离开处继续作答。

  4. 如何查看答案提交状态？

    1. 以下是关于评估所有状态的定义：
      1. 未开始：开发者收到了需要进行数据保护评估的通知，这一评估设有未来的时间期限，但开发者并未开始填写表单。
      2. 已逾期：已超过需提交数据保护评估问卷答案的时间。开发者必须完成评估，否则应用将会受到限制。
      3. 已提交，需要更多信息：开发者提交了数据保护评估问题的答案，Meta 已开始审核，但需要开发者补充说明一些事项。
      4. 已提交，发现违规内容：开发者提交了针对数据保护评估问题的答案，Meta 已开始审核，并确认应用存在至少一条违反我们开放平台条款的情况。根据违规程度，开发者可能有机会在应用受到限制之前解决违规内容。不过，最严重的违规会不经警告而立即受到处理。
      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 天）内做出回应，将获得两次自动延期机会，从而总共有 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 天）内做出回应，将获得两次自动延期机会，从而总共有 15 个工作日的时间来做出回应。15 个工作日之后，您的应用将被强制执行。
        3. 如果您未能在这些期限内做出回应，应用可能会受到限制。在我的应用页面可以查看因违规而受限制的应用。
          1. 根据违规程度，您可能有机会在应用受到限制之前解决违规内容。不过，最严重的违规会不经警告而立即受到处理。若要解决违规内容，请在我的应用页面找到“解决问题”链接，然后根据列出的步骤操作。

  4. 如何申请延期回应违规内容？

    1. 对于每项违规内容，如果回应期限不超过 3 天时间，您将看到“申请延期”按钮。您有两次申请延期的机会，每次延期时长等同于警告期的时间跨度（警告期长度因违规内容而异）。延期申请会自动通过。

  5. 如何解决在数据保护评估中发现的违规内容？

    1. 如果发现违规内容并且应用已被限制，您可以通过回应违规内容，提交证据证明已修正违规内容，解除因违规而受的限制。提交回应的信息后，Meta 审核员会进行审核，并在“解决违规内容”表单中直接回复。

开放平台条款 3（数据使用）

  1. 我的应用或用户所在的司法管辖区并没有相关法律要求我要应用户申请删除用户数据，例如在欧盟或加利福尼亚州。按照 Meta 政策，我的应用是否仍需要满足用户的数据删除申请，我是否仍需要在自己的隐私权政策里添加关于用户如何申请删除数据的内容？

    1. 是的，即使应用或用户所在的司法管辖区并没有要求您必须应用户申请删除用户数据，我们的开放平台政策仍要求您：1) 在用户申请时删除其有关的开放平台数据，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 开发者平台或开放平台数据。

  4. 按问题 4 所述，什么算是用于“其他”目的的书面协议？

    1. 书面协议的示例包括服务条款、标准非协商式协议或签字的合同。

开放平台条款 6（数据安全）

  1. 我需要做什么来证明自己符合 Meta 关于数据安全的开放平台条款第 6.a.i 条？

    1. 为证明您合规，我们会询问您是否拥有第三方审计机构发放的信息安全证书。这类证书不会强制要求提供，但属于证明合规的方法之一。我们也会询问您采取的具体保护措施。Meta 会根据内部标准评价您的回应，如果有其他疑问，或者需要您采取额外保护措施，我们会联系您。

  2. 我是否需要获得第三方审计机构提供的信息安全框架 (ISF) 或网络安全框架 (CSF) 认证？

    1. 不，我们不要求您必须获得审计机构的认证。拥有 SOC 2、ISO 27001、ISO 27018 或 PCI DSS 证书的组织可提交这些证书作为证据。
      1. 证书必须与开放平台数据存储和处理所在的数字计算环境相关。
    2. 请注意，无论您是否提交了安全证书，我们都会询问您落实的具体保护措施。

  3. 如果我没有提交安全认证，需要回答哪些有关数据安全保护措施的问题？

    1. 所有必须完成数据保护评估的开发者都会被问及是否落实了下述措施：
      1. 为所有开放平台数据存储空间（例如所有数据库文件、备份以及对象存储桶）执行静止数据加密
      2. 对存储于组织机构设备（例如丢失或被盗的笔记本电脑或可移动媒体）中的开放平台数据进行保护的技术类和/或管理类控制措施。有多种可接受的控制措施，例如，通过书面政策文件制定年度培训或提醒制度，强调开放平台数据不能存储在此类设备中；或者技术控制措施。
      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）存储开放平台数据，则此问题不适用。相反，您应在数据保护评估 (DPA) 的服务提供方部分描述这种关系。

  5. 我被问及如何避免将开放平台数据存储到组织或个人设备中。哪些是可接受的预防措施？

    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. 应用密钥和访问口令是 Meta API 安全的基础，因为它们提供对通过这些 API 存取的数据的访问控制。如果无授权方获得这些凭证的访问权，就能冒充真正的开发者调用 Meta API，并执行我们对应用授权的任何操作，例如从我们的 API 读取关于某位应用用户的数据。
    2. 开发者对 Meta 开放平台的使用包括访问敏感的凭证。具体包括：
      1. 应用密钥：Meta 会与开发者共享应用密钥，这是以开发者组织内仅受信任方（例如应用管理员）拥有密钥访问权为基础的
      2. 访问口令：用户向应用授权时，开发者会获得一种被称为访问口令的凭证，可用于后续的 API 调用
    3. 如果无授权方能够读取这些敏感的凭证，他们可能会假冒开发者，使用这些凭证调用 Meta API（这种行为有时被称为“令牌冒充”），从而在无授权的情况下访问开放平台数据。因此必须防止这些凭证遭到无授权访问，以免遭人冒充。
    4. 应用密钥：以下两项之一必须得到满足：
      1. 开发者不得将应用密钥暴露于安全的服务器环境以外，例如，应用密钥绝不能通过某个网络调用返回给浏览器或移动应用，并且此密钥不得嵌入到分发至移动或本地/桌面客户端的代码中
      2. 或者开发者必须以本地/桌面端的形式配置其应用，以便我们的 API 不再信任包含此应用密钥的 API 调用
    5. 访问口令：以下所有项都必须符合：
      1. 在客户端设备上：不得以能让其他用户或流程读取的方式编写 Meta 访问口令
      2. 在云端：如果开发者在云端处理或存储 Meta 访问口令，这些访问口令必须：
        1. 使用口令库或应用加密技术进行保护，解密密钥的访问权仅限于应用本身，且不得记录到日志文件中
        2. 或者使用适当的补偿性控制措施进行保护

  9. 我被问及我的组织是否至少每 12 个月测试一次安全事件响应系统和流程。这个问题的范围是什么？

    1. 对任何公司而言，数据安全事故都是不可避免的，不过是迟早的问题。因此，各组织机构有必要未雨绸缪，指定具体人员负责事故管控的具体事项、与利益相关方沟通、修复错漏和总结经验教训。如果发生数据安全事故，应有现成的应对计划或手册可参考，并且设有经过培训的专门小组来应对事故，这样能缩短事故的持续时间，并最终减少开放平台数据的泄露程度。
    2. 尽管不同组织的事故响应机制复杂程度并不相同，但我们要求至少要制定一个基础计划，涵盖一些关键活动：检测、反应、修复、复盘回顾，并指定具体人员承担特定职务和责任。您也应以文件的形式证明最近（12 个月内）对该计划进行了测试，并且计划提及的所有人员均参与了测试。

  10. 我被问及组织对于远程访问是否要求使用多重身份验证。这个问题的范围是什么？

    1. 不法分子获取机密数据访问权的常用手段之一是先获得开发者用于构建或运行其应用/系统的工具的访问权。有些复杂的工具可用于获取用户凭证（例如网络钓鱼攻击），从而破解仅用密码来保护的帐户。多重验证能额外提供一层安全保护，防范帐户风险。
    2. 软件开发者使用多种工具来构建、运行和管理其应用/系统。他们常常通过网络远程使用这些工具，例如员工在家办公，通过这些工具交付新的软件功能或更新云配置。使用单一验证（帐号和密码）的工具非常容易受到帐户接管攻击。例如，攻击者会使用各种工具，将从某个工具泄露的帐号和密码组合，用于尝试破解其他工具的访问权。多重验证会在帐户登录时，在密码之外要求额外的验证因素，例如由身份验证器应用生成的代码，从而防范这类攻击。
    3. 根据组织对开放平台数据的处理，对下述工具的远程访问必须使用多重验证来保护（即不能仅使用密码进行保护）：
      1. 用于运行和管理应用/系统的代码/配置变更的工具
      2. 对云或服务器环境的管理级访问工具（如适用）
      3. 具体包括：
        1. 协作/沟通工具，例如商务邮箱或 Slack
        2. 代码存储库，例如，GitHub 或用于应用/系统的代码/配置变更追踪的其他工具
      4. 此外，如果组织在云或服务器环境中处理开放平台数据，则包括：
        1. 软件部署工具：用于将代码部署到云或服务器环境的工具，例如 Jenkins 或其他持续集成/持续部署 (CI/CD) 工具
        2. 管理工具：用于管理/监控云或服务器环境的入口或其他访问工具
        3. 服务器远程访问工具：SSH、远程桌面或用于远程登录在云或服务器环境中运行的服务器的类似工具

  11. 我被问及组织是否设立系统用于维护帐户（分配、撤销以及审核访问权限和权限）。这个问题的范围是什么？

    1. 拥有良好的帐户管理习惯是防止帐户被未授权使用，继而杜绝开放平台数据泄露的重要一环。具体来说，开发者必须确保对各种资源或系统的访问权在访问结束后予以撤销。以帐户为基本单位，管理向用户授予系统、数据和管理功能访问权方面的工作。这些帐户被授予权限执行某些操作。建议的做法是仅向帐户授予满足其最低需求的权限，此即最低权限原则。
    2. 员工从组织离职后，务必立即禁用其持有的用户帐户，原因如下：
      1. 预防此人（前员工）访问帐户，以及
      2. 降低无授权人员偷偷使用此帐户的可能性。例如，不法分子可能会通过社交工程诈骗，让 IT 服务台为其重置被盗帐户的密码。如果此帐户属于在职员工，该员工就很可能会报告帐户无法登录的情况，而如果帐户属于离职员工但仍然可用，那么此帐户被盗用的情况很可能就无人发觉。
    3. 鉴于此，组织必须制定系统性的管理办法，用于管理帐户、授予访问权限/管理权限以及在不再需要时撤销权限
    4. 开发者必须拥有用于以下用途的工具/系统/应用的帐户管理工具或程序：
      1. Slack 或商务邮箱等用于与其他人沟通的工具或程序
      2. 交付软件，例如代码存储库，以及
      3. 用于管理或运行其系统（适用于处理开放平台数据）的工具或程序
    5. 开发者必须定期审核（频率不低于 12 个月一次）访问权授予情况，并设置在以下情形中撤销授权的程序：(1) 授权不再必要；(2) 不再使用授权
    6. 开发者还必须设置程序，用于在员工离职时，立即撤销此人对这些工具的使用权

  12. 我被问及组织是否设立系统用于更新系统代码和环境，包括服务器、虚拟机、发行版以及杀毒软件。这个问题的范围是什么？

    1. 软件组件会定期更新或打补丁来修补安全漏洞，而当这些组件最终不再受支持时，它们的生命周期将宣告结束。封装或依赖这些组件的开发者必须保持其及时更新，以避免软件带着已知漏洞运行。
    2. 应用开发者需要使用多种第三方软件来运行那些处理开放平台数据的应用/系统。以下为开发者使用的部分或全部第三方软件：
      1. 库、SDK、软件包 — 开发者会将他们的自定义代码封装起来，打造为一款应用
      2. 虚拟机映像、应用容器和操作系统 — 应用要在一个或多个这类容器中运行，从而获得虚拟化和网络及存储空间访问权等服务
      3. 开发者的员工/共享伙伴使用的浏览器、操作系统和其他应用程序 — 在移动设备和笔记本电脑上运行，供开发者用于构建和运行其系统的软件
    3. 安全漏洞通常出现在这些组件中，需要通过补丁进行修正。漏洞经过补丁修正后，就会在公开的数据库中披露，并说明其严重性等级（低、中、高或重大）。因此，使用我们平台的开发者必须采用系统化方式来管理补丁，具体操作包括：
      1. 确定与其应用或系统相关的补丁
      2. 根据漏洞暴露情况，优先处理紧急项
      3. 将打补丁作为日常的一项业务活动坚持去做
    4. 对于以下软件组件，如适用，开发者必须采取系统化措施，以便确定用于修正安全漏洞的可用补丁、优先处理风险等级高的事项以及日常打补丁：
      1. 用于云或服务器环境的库、SDK、软件包、应用容器和操作系统
      2. 用于客户端设备（例如在移动应用内）的库、SDK、软件包
      3. 由组织成员用于构建和运行其应用或系统的操作系统和应用程序，例如在工作人员笔记本电脑上运行的操作系统和浏览器

  13. 如果我没有采取其中一项或多项适当安全控制措施，但是实施了其他弥补性安全控制措施，我应该怎么做？

    1. 如果您认为 Meta 建议采取的某项控制措施不适用于您使用（例如存储或处理）Meta 开放平台数据的情况，或者您在使用补偿性控制措施来替代我们建议的一项或多项保护措施，请解释您的具体情况并提供证据，以解决此违规内容。如果您收到我们发出的关于合规要求的邮件，请根据邮件中的指示操作，在应用面板上进行回复。如果无法找到邮件通知，请访问我的应用页面或此应用的应用面板。

  14. 我被问及是否设置有可供公众向我们报告安全漏洞的方法。我们必须为此设置专门渠道吗？

    1. 虽然我们的政策没有要求提供用于报告安全漏洞的专门渠道（以及任何有人定期管理的联系方式，例如邮箱、联系表单或电话，均在此列），但是建议开发者为此实行结构清晰的计划，例如在 BugCrowd 或 HackerOne 开展漏洞披露计划 (VDP)。

  15. 在 DPA 审核团队发来的信件中，我发现他们引用了问题编号。这些编号代表什么？

    1. 您可能会在我们审核团队发来的信件中看到对问题编号的引用。这些编号主要用于内部审核流程，但以下具体的引用内容可供您参考：
      1. Q9：云端或服务器环境中的静止数据加密。
      2. Q10：保护组织或个人设备中的平台数据。
      3. Q11：通过传输加密保护平台数据。
      4. Q12：测试应用和系统的安全漏洞。
      5. Q13：保护 Meta 应用密钥和访问口令。
      6. Q14：建立事故响应计划并测试事故响应系统和流程。
      7. Q15：对远程访问设置多重验证。
      8. Q16：建立维护用户帐户的系统。
      9. Q17：保持软件及时更新。

  16. 我收到了来自 DPA 审核团队的信件，其中内容与政策或程序类证据缺失或不足有关。什么是政策或程序类证据？

    1. 您可能会收到与一个或多个数据安全问题相关的政策或程序类证据的后续问题，Meta 审核团队可能会使用以下某个编号来引用这些问题：Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17。

      在所有这些情况下，政策或程序类证据为书面文档，用于说明您的组织实施特定数据安全保护的方法。例如，您的组织可能存在以下书面文档：
      1. 身份验证政策文档，用于声明所有可以访问平台数据的业务、开发和系统管理工具都必须经多重身份验证保护。
      2. 加密政策，用于声明所有 Meta 平台数据都必须经过传输加密和静止数据加密保护。
      3. 修补程序，列明了必须采取相关步骤来识别影响组织云端应用的任何可用安全补丁的频率；如何对每个补丁执行影响评估；规定根据严重性而部署补丁的最长时间；以及如何部署补丁。
      在引用政策或程序文档回答相关问题时，上述事例均为可接受的形式。Meta 的 DPA 审核人员将审核您提供的文档，以确认您的方法符合我们的要求。如需了解更多信息，包括有关如何准备用于提交的政策证据的其他示例和详细信息，请参阅准备证据上的开发者文档。

  17. 我收到了来自 DPA 审核团队的信件，内容有关执行类证据缺失或不足。什么是执行类证据？

    1. 您可能会收到与一个或多个数据安全问题相关的执行类证据的后续问题。数据安全问题有时指以下编号：Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17。

      在所有这些情况下，将执行类证据包括在内对于证明您实施文档化的政策或程序十分重要。该证据可包含管理系统的屏幕截图和工具的输出内容，这些工具会显示组织如何实际执行其保护方法。可接受的执行类证据必须证明您组织的实施内容符合 Meta 在保护方面的要求。您必须针对每项保护方法提交至少一条执行类证据。

      如需了解详细信息，请参阅适用于每项保护方法的准备证据上的开发者文档：
      1. 云端或服务器环境中的静止数据加密。
      2. 保护组织或个人设备中的平台数据。
      3. 通过传输加密保护平台数据。
      4. 测试应用和系统的安全漏洞。
      5. 保护 Meta 应用密钥和访问口令
      6. 建立事故响应计划并测试事故响应系统和流程。
      7. 对远程访问设置多重验证。
      8. 建立维护用户帐户的系统。
      9. 保持软件及时更新。

  18. 我被问及如何保护组织和个人装置上的平台数据。Meta 有什么要求？

    1. 您可能会收到有关您的组织会如何保护存储在组织和个人设备上的平台数据以免丢失的后续问题。Meta 也会用编号 Q10a 或 Q10b 来表示这些问题。

      Meta 要求您证明至少已执行以下某项操作：
      1. 您的组织采取措施阻止访问包含 Meta 平台数据的系统，但满足以下一项或两项条件的设备除外：
        1. 所有设备都必须启用全磁盘加密，例如通过 FileVault 或 BitLocker 加密。
        2. 所有设备都必须运行端点 DLP 软件，例如 Microsoft Intune 或 Symantec DLP。
      2. 您的组织已制定相关政策，禁止组织内的任何人在任何组织或个人设备上存储 Meta 平台数据，并且您存有书面证据表明您组织内的人员有义务遵守该政策。
      3. 您的组织已制定相关规定：
        1. 仅那些需要访问权限并具有经授权业务目的的个人才能处理组织设备上的平台数据，并且
        2. 当经授权业务目的不再存在时，个人必须删除这些设备中的平台数据。
      4. 由于您软件的构建方式（例如，仅将 Meta 平台数据存储在最终客户设备的瞬时内存中），您组织中的任何人员都无法访问 Meta 平台数据

  19. 什么是 Facebook 或 Meta 应用密钥？

    1. 您可能会收到有关您的组织如何保护 Facebook 或 Meta 应用密钥的后续问题。Meta 也会用编号 Q13 来表示该问题。

      应用密钥是与 Facebook 应用相关联的参数，可用作某些 API 调用中的访问令牌，以更改应用的配置，例如配置 Webhooks 回调。您可以前往以下位置找到应用的 Facebook 应用密钥：“设置 > 基本”下的开发者面板。如需详细了解应用密钥，请参阅登录安全上的开发者文档。

      如需详细了解我们对于保护应用密钥和用户访问令牌（包括任何您可能需要提供的证据）的要求，请参阅保护 Meta 应用密钥和访问令牌。

  20. 我被问及如何管理和维护帐户。Meta 有什么要求？

    1. 您可能会收到有关您的组织是否已建立相关系统以管理帐户和一些相关流程的后续问题。该问题也可以用编号 Q16 来表示。
      1. 您必须建立一个工具或流程来授予和撤销访问相关应用和系统的权限，这些访问权限用于您的组织的内部通信、开发和发布软件以及管理您的系统/应用（在这些应用和系统适用于处理平台数据的范围内）。
      2. 至少每 12 个月一次，您必须建立一个程序来审核之前授予的访问权限并撤销不再需要和不再使用的授权。
      3. 您必须设置流程，用于在员工离职时，立即撤销此人对所有应用和系统的访问权限。
      如需了解详细信息，包括有关任何您需要提供的证据，请参阅我们的开发者文档：建立用于维护用户帐户的系统。

  21. 我被问及如何测试我的系统/软件的漏洞。Meta 有什么要求？

    1. 您可能会收到有关您的组织是否会测试系统/软件漏洞的后续问题。该问题也可以用编号 Q12 来表示。

      如果您的组织在云端环境（例如，在 AWS、Azure、GCP、Alibaba Cloud、Alibaba Cloud 中）中处理 Meta 平台数据，则您的组织必须满足以下条件：
      1. 您必须已通过以下方式测试云端软件的安全漏洞：
        1. 对应用或系统执行渗透测试或外部扫描；或
        2. 针对软件设置静态或动态分析安全工具；或
        3. 执行满足我们要求的漏洞披露计划
      2. 您还必须已通过以下方式测试云端素材配置的漏洞：
        1. 云端主机提供的工具；或
        2. 其他商业或开源工具；或
        3. 执行满足我们要求的漏洞披露计划
        4. 如果云端配置审核不适用于您的组织，则您在提交证明证据时必须附上相关内容，说明不适用的理由
      3. 您必须证明您已在过去 12 个月执行过上述两个操作。
      Meta 通常会要求您解决所有重大或高风险漏洞。

      如果您的组织在托管于其他处的服务器环境中处理 Meta 平台数据，则您的组织必须满足以下条件：
      1. 您必须已通过以下方式测试服务器软件的安全漏洞：
        1. 对应用或系统执行渗透测试或外部扫描；或
        2. 针对软件设置静态或动态分析安全工具；或
        3. 执行满足我们要求的漏洞披露计划
    Meta 通常会要求您解决所有重大或高风险漏洞。

    以下要求适用于所有其他组织：
    1. 您必须已通过以下方式测试客户端软件的安全漏洞：
      1. 执行渗透测试或外部扫描；或
      2. 设置静态或动态分析安全工具；或
      3. 执行满足我们要求的漏洞披露计划
    2. 您必须证明您已在过去 12 个月执行过上述操作
    Meta 通常会要求您解决所有重大或高风险漏洞。

    如需了解详细信息，包括任何您可能需要提供的证据，请参阅开发者文档：测试应用和系统以发现漏洞和安全问题。


  22. 我被问及如何保持系统及时更新。Meta 有什么要求？

    1. 您可能会收到有关您的组织是否已建立相关系统以更新系统代码和环境的后续问题。该问题也可以用编号 Q17 来表示。
      2. 您必须演示某个已定义及可重复流程，以作以下用途：
      1. 识别解决安全漏洞的补丁，并且这些补丁与您用来处理 Meta 平台数据的软件相关，
      2. 根据风险确定这些补丁的优先级，并且
      3. 将打补丁作为一项长期实行的活动。
      请务必包含足够详细的信息，说明您的软件如何处理平台数据，以便我们能够验证您的流程满足上述所有要求。例如，我们无法接受您仅说明您的组织已建立用于修补服务器操作系统的流程，而不说明您对堆栈的其他层（例如，虚拟化层、容器层、应用容器层、库或应用中的依赖项）所采用的方法。

      如需了解详细信息，请参阅开发者文档：保持软件及时更新。

请注意，这些常见问题旨在提供实用的信息和链接，以帮助您回复 DPA 团队。但是，DPA 的评估还是基于数据安全要求。这些常见问题仅供参考，阅读这些内容时不应违背或取代相关要求。

详细了解