Get best of the week

我们如何Google安全检查

为了确保用户数据的安全性，Google会仔细检查所有使用受限API范围并有权访问Google用户数据的应用程序。不久前，我们Snov.io经历了验证过程并获得了Google的批准，我们希望与他人共享。

新的申请规则


2018年10月9日， Google宣布了使用Google受限API范围的应用程序的新规则。它们包括两个验证阶段：

  • 验证您的应用符合Google API用户数据
  • 验证最低安全要求

受限制范围的应用程序验证可验证是否符合Google API用户数据政策以及“特定API范围的其他要求”中概述的其他一组政策。首先，我们将审查您的应用程序是否符合Google API服务：用户数据政策。之后，您将在2019年的剩余时间里展示对安全处理要求的遵守情况。

验证是否符合最低安全要求需要花费大量金钱-从15,000美元到75,000美元。
评估将由Google指定的第三方评估人员进行，费用可能在15,000美元至75,000美元（或更高）之间，具体取决于应用程序的复杂程度，并且由开发人员支付。无论您的应用程序是否通过评估，都可能需要支付此费用。

早在2019年1月9日，谷歌就计划使用Google API的应用程序严格了规定。对于较早使用Google API的应用程序，要求在2月15日之前提交申请进行验证。否则，从2月22日开始，新用户将无法访问该应用程序，而从3月31 日起，现有用户将无法使用该应用程序。

这种发展的后果将是令人不快的。这是由于以下事实：我们有大量用户（超过10万）使用Gmail。因此，我们只会失去这些客户。

对于需要采取措施的项目，您必须在2019年2月15日之前提交应用进行验证。否则，您将在2019年2月22日停用对新用户的访问权限，并在3月31日撤销对消费者帐户的现有拨款， 2019。

更新之前一切如何发生？


自2017年以来， 我们的Snov.io平台一直在使用Google API。我们的应用程序使用了几个受限制的范围：用于阅读传入的邮件和处理草稿。 

Google之前已经测试过使用Google API的应用程序。为了应用新的API范围，有必要将其添加到控制台并指明其用途。当Google员工检查该应用程序时，用户在屏幕上看到“此应用程序未经验证”通知： 



通常，这张支票花了我们2至3个工作日（尽管Google的一封信中指出，该过程最多可以持续7天），并且始终顺利通过。我们一直等到Google检查了我们的应用程序，然后才将功能注入到产品中，这样用户就不会看到“此应用程序尚未验证”的通知。 

第一阶段通过


首先，我们决定将重点放在验证的第一阶段，即我们的应用程序是否符合Google API用户数据政策。 

1月16日， “ 提交供验证”按钮出现在Google控制台中，我们发送了一个应用程序。出发前，我们确保遵守Google API用户数据政策中的所有规定。我们对隐私权政策进行了更改，特别是添加了“ Google用户数据”部分，其中详细说明了我们从Google API中存储了哪些数据，如何使用它以及何时删除它们。 

2月12日，我们收到了对提交申请的回复。我们被要求录制视频并显示我们如何使用所请求的受限API范围。 

结果，我们不得不放弃我们在Google Cloud上的两个项目，并将它们合并为一个。我们放弃了以测试模式工作的测试服务器的第一个项目，并使用了与产品相同的项目进行测试。我们还通过Google将第二个授权项目删除到系统中，而是使用需要验证的项目登录。 

2周后，Google代表在某处回复了我们的来信。对于问题，我们提供了引号而不是直接答案。在我们看来，他们有一个检查应用程序的特殊脚本。 

例如，提醒我们，我们使用具有一个ID的应用程序进入系统，而在连接电子邮件帐户时，使用具有不同ID的应用程序。我们故意这样做，因为这是两个完全不同的功能。登录应用程序不需要任何检查，我们不希望失败通过受限API范围的应用程序验证来禁用验证应用程序。



4月20日，我们终于通过了Google数据政策合规性检查的第一阶段！

第二阶段通过 


步骤1.选择一家公司以通过审核


在测试我们的应用程序的第二阶段，Google发送了两家公司的联系人供选择-Bishop Fox和Leviathan Security。只能与他们一起通过支票。截止日期为12月31日。

5月20日，我们致函两位独立专家，通过了审核。 Bishop Fox和Leviathan Security发送了有关我们的应用程序问题的问卷。有必要回答我们使用哪种类型的Google数据，每种编程语言编写多少行代码，以及有关我们的基础架构，软件部署过程和托管提供商的问题。我们填写了所有内容，并开始等待报价。



在与公司代表进行准备和初步沟通时，我们了解到服务器所在的主机不符合SOC2。为了成功进行验证，我们必须转移到适当的SOC2托管。长期以来，我们一直在考虑迁移到Amazon，因此我们开始了并行迁移的过程。 

我们还了解到，我们需要许多网站和软件开发人员提供的Bug赏金计划。有了它，人们就可以发现错误，尤其是与漏洞利用和漏洞相关的错误，从而得到认可和奖励。 

9月，我们从Bishop Fox和Leviathan Security获得了两个现成的合同。我们必须决定与谁签订合同。我们不知道选择专家的标准，但是与Leviathan Security达成的协议对我们来说似乎更加透明，尽管它的成本略高。

步骤2.签署合同并准备进行验证


10月8日，我们与Leviathan Security签署了一项协议。在签订合同时，我们尚未完成迁移到亚马逊的过程。因此，在我们的合同“托管”列中有一个空白，我们必须稍后输入。

我们还了解到验证将包括：

  • 外部网络渗透测试 
  • 应用程序渗透测试 
  • 部署审查 
  • 政策与程序审查 

以及以下步骤：

  • 制备 
  • 评定
  • 验证与确认
  • 总结报告

检查持续约一个月。它的价格包括消除发现的漏洞的时间。然后执行第二次检查。验证的结果是，我们应该已经收到评估书（LOA），然后需要将其发送给Google代表。但是，专家不能保证收到100％评估结果的LOA。 

10月23日， Leviathan Security发出了自我评估调查表（SAQ）。我们还与她一起提供了通过审核所需的政策：

  • 突发事件响应计划：确定突发事件发生时的角色，职责和行动
  • 风险管理政策：确定，减少和防止不良事件或结果
  • 漏洞披露政策：为外部各方提供报告漏洞的方法
  • Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
  • Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant

11月8日，举行了外部协调会议，在会议上我们讨论了所有组织问题，确定了通信的使者（Slack），并简短地讨论了我们的应用程序。我们被警告说有必要提供对源代码的访问-这对我们来说不是问题。 

在集会上，我们了解到需要使用KMS加密Oauth令牌，这是我们以前没有做过的。我们还讨论了检查的大概时间。我们可以放心，如果她是在今年年底被任命的，而我们没有时间通过​​，那么Leviathan Security将与Google谈判以延长我们的截止日期。

11月14日我们收到了有关计划开始检查的信息：12月下旬或1月初。Leviathan Security警告Google，我们可以在截止日期之前提供LOA。 

11月16日，我们收到了Google的确认，确认截止日期已推迟到3月31日。

步骤3.验证


12月13日，我们收到一封信，通知我们有关审核的开始时间-1月2日，要求我们满足以下要求： 

1.确认进行审核的可能性。

2.再次提供必要的信息。 

必须在扫描前一周将文档上载到OneDrive上的共享文件夹中，直到12月26日为止。除了必需的文件外，我们没有提供任何其他文件： 

  • 事件响应计划
  • 风险管理政策
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3.提供对源代码的访问。

4.邀请某些人使用Slack Messenger。

5.指出用于升级项目的电话号码和详细信息。

6.提供有关如何计费的信息。

7.通知内部安全团队，CDN和托管提供商，验证将于1月2日至1月27日进行。

8.在OneDrive上创建一个共享文件夹。

9.签出Google Checkout常见问题。 

12月30日举行了开工会议，几乎所有情况都与第一次集会相同。我们进行了自我介绍，用一系列技术描述了产品，并确认我们的系统是稳定的，并且在产品评估期间不会发布任何主要版本。它以问题和评论结尾。 

1月2日，开始进行安全检查。请注意，此操作没有太大困难。有时由于时区的不同而带来不便-在我们的非工作时间我们在Slack进行的所有通话和通讯。 

我们发现了许多漏洞-高和严重级别（高和严重）。此类漏洞需要修复。中级及以下级别的漏洞可能会自行纠正。更正了30天。但是，我们实际上是在第二天修复了它们。 

漏洞主要与加密用户数据和日志记录不足的方法有关。没有对我们的政策文件的投诉。利维坦安全政策部问了几个澄清的问题，并说它们看起来很扎实。

不乏沟通。我们可以在集会状态或松弛状态下澄清所有晦涩的问题。漏洞报告已得到充分记录，并包括修复建议。在评估的最后一天，修复并检查了所有严重，高以及某些中低漏洞。 

1月31日，我们收到了LOA并将其发送给Google代表。  

2月11日收到Google的确认确认。



对我们来说最困难的事情是未知数。期待什么？一切将如何发生？我们觉得自己像开拓者。没有其他公司如何通过此测试的信息，这促使我们与其他公司共享有关安全性检查的信息。

我们想对尚未接受这种检查的人说，它并不象看起来那样可怕。是的，该过程很耗时，但是修复所有漏洞的时间将非常可观。尽管我们花了一年时间进行Google Security Checkup，但这次并没有浪费。我们可以继续使用对我们至关重要的Google API，而且还可以关闭某些漏洞，这些漏洞随后可能对我们或我们的客户产生影响。

有些公司（例如Context.io）已决定不通过审核并已经关闭。有些人在无法访问API的情况下继续工作，但同时在用户眼中却失去了声誉。当然，每个需要测试的业务都必须独立权衡利弊。对于那些还没有盈利的年轻公司来说，最困难的事情是。但是，如果企业拥有通过测试的资源，那么绝对值得做。

希望我们的经验能为您提供帮助！

More articles:


All Articles