Google杀死SaaS创业公司的新方法
如果您由于Google安全浏览已将您的网站或SaaS列入黑名单而感到恐慌，请跳至描述如何处理情况的部分。
在过去，当Google（或Google释放的任何调优的AI）决定杀死您的业务时，通常会拒绝访问其多个围墙花园之一，仅此而已。您可能已经听过恐怖故事：
Android Apps已从Google Play商店中删除，无法联系到用户
最后但并非最不重要的一点是，上述所有方面的个人生活类似物：个人无法访问其GMail帐户和整个数字生活。
它们都适合同一模具。首先，企业选择使用Google服务，使其生存完全依赖于它们。其次，Google是Google的自动化庞然大物，它做了自己的事情：它曾经如此轻微地调整了自己在星球大小的皮革扶手椅上的对接位置，并且没有真正注意到，却碾碎了无数（相对）蚂蚁大小的东西。业务过程中。第三，也是最后，蚂蚁大小的企业拼命试图通知Google他们已经被压垮了，但它们只能到达一个自动建议框。
有时，蚂蚁大小的CEO在Google方面了解更多，因为他们是大学的好友，或者CTO撰写了蚂蚁大小的Medium帖子，以某种方式使其成为Hacker News土堆的首页。然后，Google注意到了蚂蚁大小的问题，有时认为它值得解决，通常是因为担心蚂蚁革命可能带来的监管影响。
由于这个原因，传统的蚂蚁大小的智慧表明，如果可能的话，您不应将自己的业务过分依赖于Google的服务。而且，如果您设法避免依靠Google的多个围墙花园生存，那您可能会没事的。
在今天的互联网中，互联网已不再是以前的样子了，让我们谈谈Google的新途径，可以无意中破坏不需要您使用的创业公司Google以任何（故意）方式提供服务。
您是否知道Google可能无缘无故将您的站点域列入黑名单，而且此黑名单不仅直接在Google Chrome浏览器中实施，而且还由其他一些软件和硬件供应商实施？您是否知道这些其他供应商会将清单与时间和解释的变化相结合，从而使解决任何问题都变得极度压力和不可预测？您是否知道Google审核黑名单报告的ETA（无论多么无效）以周为单位？
此黑名单的功能称为Google安全浏览，此处的图像描述了您的用户将看到的一个微妙消息，即您的某个域是否恰巧在安全浏览数据库中被标记。警告文字的范围从＆＃34;欺骗性网站前面＆＃34;到＆＃34;前面的站点包含恶意软件＆＃34; （请参阅此处以获取完整列表），但是它们都具有同样令人恐惧的红色背景设计，并且边界不可能的UI供人们跳过警告并继续使用该网站。
第一次遇到此问题时，我们从大量客户报告中得知了这一点，这些客户报告说他们在尝试使用我们的SaaS时看到红色警告页面。第二次，我们作了更好的准备，因此有一些空闲时间写这篇文章。
就上下文而言，InvGate（我们的公司）是一个IT部门的SaaS平台，它在AWS上运行，拥有1000多家SME和企业客户，为数百万最终用户提供服务。这意味着IT团队可以使用我们的产品来管理他们自己用户的问题和请求。您可以想象，当IT经理的IT票务系统突然开始向其最终用户显示这种不祥的安全警告时，IT经理会做出令人愉悦的反应。
当我们初次遇到此问题时，我们疯狂地试图了解正在发生的事情，并了解Google安全浏览（即现在的GSB）是如何工作的，而我们的技术支持团队则试图跟上报告该问题的客户。我们很快意识到用于服务静态资产（CSS，Javascript和其他媒体）的Amazon Cloudfront CDN URL已被标记，这导致整个应用程序因使用该特定CDN的客户实例而失败。对据称受影响的系统进行的快速检查显示，一切看起来都很正常。
当我们的DevOps团队在完全紧急模式下进行工作以设置新的CDN并准备将客户转移到新域时，我发现Google的文档声称GSB提供了有关标记该网站的原因的更多解释在有问题的网站的Google Search Console（从现在开始为GSC）中。我不会告诉您这些细节，但是为了访问此信息，您必须声明GSC中该网站的所有权，这要求您设置自定义DNS记录或将一些文件上传到违规域。我们争先恐后地做到了这一点，并在20分钟后设法找到了有关我们网站的报告。
该报告还包含“请求审核”。由于没有任何有关所谓问题的信息，因此我迅速单击了该按钮，而没有对该网站进行任何实际操作。尽管有文档表明示例性URL始终由Google提供，以帮助网站站长识别问题，但我还是提交了一条评论，指出没有列出有问题的URL。
大约一个小时后，在我们完成将客户移出该CDN之前，我们已从GSB数据库中清除了我们的网站。我收到一封自动发送的电子邮件，确认在此之后约2小时，审查已成功完成。首先，没有给出引起问题的原因的说明。
在此事件发生后的一个星期内，尽管已从安全浏览黑名单中清除了我们的URL，但我们仍然收到零星的报告，称公司无法访问我们的系统。
Google安全浏览提供了两种不同的API，供商业和非商业软件开发人员在其产品中使用黑名单。特别是，我们发现至少有一些使用Firefox的客户也遇到了问题，并且来自客户的防病毒/防恶意软件和网络范围内的安全设备也正在标记我们的网站，并在问题发生后的许多天阻止用户访问它解决。
我们继续将所有客户从以前列入黑名单的CDN转移到新客户，因此该问题得到了彻底解决。我们从来没有适当地确定问题的原因，但我们将其归因于Google总部对AI的某些攻击。
我的2美分：如果您使用具有可用SLA的SaaS业务来运营，那么无缘无故被Google安全浏览标记为业务连续性的真正风险。
令人遗憾的是，鉴于标记和查看网站的机制太过模糊了，我认为您无法完全防止这种情况的发生。但是，您当然可以设计您的应用程序和流程，以最大程度地减少发生这种情况的可能性，降低实际被标记的影响，并最大程度地减少在出现问题时规避该问题所需的时间。
明智的做法是，不要将所有鸡蛋放在一个篮子里。 GSB似乎标记了整个域或子域。因此，将您的应用程序分布在多个域中是一个好主意，因为这将减少标记任何单个域的影响。例如：针对您的网站的company.com，针对您的应用程序的app.company.net，针对欧洲客户的eucdn.company.net，针对美国东海岸客户的useastcdn.company.net等。
不要在您的主域中托管任何客户生成的数据。我在研究此问题时发现的许多列入黑名单的情况都是由SaaS客户在不知不觉中将恶意文件上传到服务器引起的。这些文件对系统本身无害，但是它们的存在会导致整个域都被列入黑名单。您的用户上传到您的应用程序的所有内容均应托管在您的主域之外。例如：使用companyusercontent.com存储客户上传的文件。
在Google Search Console中主动声明对您所有生产域的所有权。如果这样做，将不会阻止您的网站被列入黑名单，但是您会在发生这种情况时收到一封电子邮件，这将使您对问题迅速做出反应。这需要花一些时间，而且这是您真正处理影响客户的此类事件的宝贵时间。
如果需要，请准备好跳转域。这是最难的事情，但这是防止被列入黑名单的唯一有效工具：对系统进行工程设计，以便可以轻松地修改其引用的服务域名（通过使用脚本或编排工具来执行此更改），甚至还有其他名称可供使用和支持。例如，让eucdn.company2.net成为eucdn.company.net的CNAME，并且如果第一个域被阻止，请更新应用程序的配置，以使用工具从备用域中加载其资产。
如果您的SaaS应用或网站被Google安全浏览列入黑名单该怎么办
如果您可以轻松，快速地将您的应用切换到其他域名，那么唯一可以可靠，快速且伪确定地解决此事件的方法。如果可能，请执行此操作。完成了。
失败的是，一旦您确定了被阻止的域，请查看Google Search Console上显示的报告。如果您在此之前尚未声明拥有该域的所有权，则必须立即进行操作，这将需要一段时间。
如果您的网站实际上已被黑客入侵，请解决该问题（即删除有问题的内容或被黑客入侵的网页），然后请求进行安全审查。如果您的网站尚未遭到黑客入侵，或者“安全浏览”报告不合理，则无论如何都要求进行安全审查，并声明该报告不完整。
然后，假设停机时间对您的系统或业务至关重要，而不必费神地等待，而是继续着手转移到新域名。审查可能需要数周时间。
在第一次事件发生数月后的第二次，我们收到了来自Search Console的电子邮件，警告我们我们的一个域已被标记。作为G Suite域管理员，这份初始电子邮件报告几小时后，我收到了另一封有趣的电子邮件，您可以在下面阅读。
让我总结一下这是什么，因为它令人震惊。该电子邮件是指Search Console黑名单警报电子邮件。第二封电子邮件的意思是，G Suite的自动网络钓鱼电子邮件过滤器认为Google Search Console关于我们的域名被列入黑名单的电子邮件是伪造的。绝非如此，因为当我们收到电子邮件时，我们的域名确实被列入了黑名单。因此，Google甚至无法确定自己的有关网络钓鱼的电子邮件警报是否为网络钓鱼。 （大声笑？🤔）
对于从事技术工作的任何人来说，很明显，大型公司技术的庞然大物在很大程度上是Internet的守门员。但是我倾向于以一种宽松的，隐喻的方式来解释它。这篇文章中描述的“安全浏览”事件非常清楚地表明，无论您在何处以及如何操作，Google都会从字面上控制谁可以访问您的网站。 Chrome拥有大约70％的市场份额，并且Firefox和Safari在某种程度上都使用GSB数据库，因此Google可以单枪匹马地使几乎所有站点都无法访问Internet。
这是非凡的力量，不适合Google的力量。如果AI认为方便，则AI会审查您的问题。方法。
