原文地址：https://blog.cloudflare.com/talk-transcript-how-cloudflare-thinks-about-security/
原文标题：Talk Transcript: How Cloudflare Thinks About Security
原文作者：John Graham-Cumming
原文写于：2019/10/8 GMT+8 下午5:00:00
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
这是我(John Graham-Cumming,Cloudflare 的 CTO)于 2019 年 9 月 25 日，里斯本(Lisbon)，在人工智能翻译平台 Unbabel 的演讲上，所使用的文本。
(译者注：原文这里是葡萄牙语)大家早上好，我是 John Graham-Cumming，Cloudflare 的 CTO，我的演讲将使用英语
感谢您们邀请我谈论 Cloudflare ，以及我们如何看待安全问题。我正准备永久移居葡萄牙，我希望能在几个月内用葡萄牙语进行这次演讲。
我知道你们中大多数人的母语都不是英语，所以我会比以往的演讲更加谨慎。并且，我将提供此演讲的演讲稿供您阅读。
我没有准备幻灯片。
今天的演讲中，我将谈论 Cloudflare 如何对待内部安全、我们如何保护自己、以及如何确保日常的正常工作。这不是有关 Cloudflare 产品的讨论。
公司文化 | Culture
让我们从”公司文化”这个话题开始。
许多公司都有文化制度的声明。我认为几乎 100％ 都纯粹没有意义的。文化是您每天的行为方式，而不是墙上写的明文条款。
Cloudflare 公司文化中，一个重要组成部分是 内部安全事件(Security Incident) 邮件列表，公司中的任何人都可以向邮件列表发送消息。并且事实上他们会这样实践！本月到目前为止，该列表中有 55 封单独的报告安全问题的电子邮件。
这些邮件来自公司的各个部门。每天有两到三封邮件。每个邮件将由内部安全团队进行调查。在我们内部的Atlassian Jira 系统中，每个邮件都被分配了一个安全事件问题。
人们发送的邮件：报告说他们的笔记本电脑或手机被盗（需要立即废除账号凭证），怀疑他们收到了一封奇怪的电子邮件（可能是钓鱼邮件，或者附件中存在恶意软件），对物理安全性的担忧（比如，有人在办公室徘徊，并提出奇怪的问题），他们单击了错误的链接，丢失了门禁卡(access card)，除此而外，有时还担心我们的产品安全。
笔记本电脑和手机失窃或丢失之类的事情发生比您想象中的更多。我们似乎每个月有两次这样的丢失。因为这个及其他原因，我们在设备上使用全盘加密，复杂的密码，以及访问每项服务员工需要进行两步身份验证(two factor auth)。 并且，我们不鼓励任何人在我的笔记本电脑上存储任何东西，并要求他们主要使用云上应用程序进行工作。另外，我们集中管理机器，并可以远程擦除。
我们有一项 100％ 无罪的文化。您点击了一个奇怪的链接？我们会帮助你。手机丢了？我们会帮助你。您觉得可能被钓鱼了？我们会帮助你。
这导致了一种在出现问题时报告问题的文化，无论发生的问题多么微小。这是我们内部的第一道防线。
就在本月，我单击了一个链接，该链接使我的 Web 浏览器疯狂地通过重定向进行跳转，直到最终到达一个糟糕的地方。我已将其报告给邮件列表。
我从来没有在蕴含着如此强大文化的工作环境中工作过，无论报告的问题是大是小都是如此。
黑客 | Hackers
我们还使用 HackerOne 让人们从外部报告安全问题。本月，我们收到了 14 个有关安全问题的报告。说实话，我们通过 HackerOne 收到的大多数邮件的优先级都非常低。人们运行自动化扫描工具，并报告最微不足道的配置问题，或者是，经常，报告他们不了解但对他们来说看起来像安全问题的问题。但是，我们将它们分类并处理。
人们有时的确会报告需要我们解决的问题。
我们还有一个私人的有偿漏洞赏金计划，我们与一群单独的黑客（目前大约有150个）合作，我们为他们发现的漏洞付款。
我们发现，将公共负责的漏洞披露计划与私有的有偿计划结合起来是很好的方法。 我们邀请公共计划中最强的黑客进入我们的私有计划，与紧密合作。
身份 | Identity
因此，这一切都涉及人员、内部和外部，报告问题，漏洞或攻击。到那很近的一步就是要知道这些人是谁。
这就是身份和身份验证变得至关重要的地方。实际上，作为行业趋势，身份管理和身份验证是 CSO 和 CISO 花费最大的领域之一。Cloudflare 也不例外。
不过，不同之处在于，我们无需花费大量的身份和身份验证，而是构建了自己的解决方案。
我们并不是从一开始就具有良好的身份惯例。实际上，几年时间内，我们的系统使用不同的登录名和密码，这简直是一团糟。当新员工开始工作时，必须在 Google 上创建帐户以获取电子邮件和日历，在 Atlassian 上使用 Jira 和 Wiki，在 VPN 上，在 WiFi 网络上，然后在博客，HR，SSH 等众多其他系统上建立账号。
当有人离职时，所有这些都必须撤消。但是这些操作常常没有正确撤销做是不正确的。人们离职，帐户仍会运行一段时间。这对我们来说是一个巨大的麻烦，对每个公司而言，这都是一个巨大的麻烦。
我可以给这些公司一个提高安全性的建议，那就是：分类识别和认证。我们做到了，并且这样使事情变得更好。
这使得让某个员工入职和离职的过程变得更加流畅和一致。我们可以通过单独的一个控制面板，控制哪些人可以访问哪些系统。
我通过我们自己构建的名为 Cloudflare Access 的产品进行了一次登录，我可以访问几乎所有内容。在撰写本文时，我查看了我的 LastPass 密码柜，总共只有五个用户名和密码，其中两个需要删除，因为我们已将这些认证登陆系统迁移到 Access 来完成。
所以，是的，我们也使用密码管理器。我们使用优质的密码和双因素身份认证来安全锁定所有内容。 Cloudflare 的每个人都使用 Yubikey，并使用 TOTP（例如 Google Authenticator）。有三个黄金法则：使用密码管理器创建所有的密码，所有身份验证必须具有第二个因素，并且第二个因素不能为 SMS(手机短信)。
我们在公司范围内的年度静修会上开会，并且很高兴的引进了 Yubikeys。每年，Cloudflare 都会将整个公司的所有员工（现在有1000余人）聚集到一家酒店，进行两到三天的合作，向外部专家学习，并参加体育和文化活动。
去年，安全团队为每个人提供了一对实体的安全令牌（Yubikey 以及来自 Google 的用于蓝牙认证的 Titan Key ），并且在一次漫长而艰难的会话中，为每个人配置了帐户以使用它们。
注意：请勿试图同时让 500 个人同步同一房间中的 Bluetooth 设备。蓝牙无法应对这么大的用户量。
我们实现的另一项重要功能是，对系统访问的自动超时。如果您不使用对系统的访问权限，那么你会失去你的访问回话。这样，就不会存在可能访问敏感系统的帐户，这些敏感系统可能会被用于漏洞利用。
开放 | Openness
暂时回到文化主题，Cloudflare 的一个重要特征是开放。
也许有些人知道，早在 2017 年 Cloudflare 的软件中就有一个可怕的错误，后来称之为 Cloudbleed。 该错误造成从我们内部服务器的内存泄漏到人们的 Web 浏览中。某些网络浏览是由搜索引擎爬虫完成的，这些内存信息最终出现在 Google 等搜索引擎的缓存中。
我们必须做两件事：停止实际的错误（这相对容易，并且在一小时之内完成），然后清除相当于石油泄漏一般的数据。这花费了更加长久的时间（大约一周到十天）来完成，并且过程十分复杂。
但是从第一天晚上得知问题开始，我们就开始记录发生的事情和正在做的事情。 我在深夜里打开了 EMACS 编辑器，并开始进行记录。
该记录变成了一个庞大的披露博客帖子，其中包含我们所犯错误的详细信息，错误造成的后果，以及我们发现错误后如何应对。
几天后，我们进行了后续跟踪，进一步撰写了一篇博客文章，评估了涉及问题的影响和风险。
这种完全开放的方式对我们来说是巨大的成功。它增加了对我们产品的信任，并使人们希望与我们进行更多的合作。
我曾在去柏林，与一家大型零售商谈论 Cloudbleed，当我突然意识到我所要演讲的公司不是我们的客户时。然后我问销售人员我在做什么。
我们走近他们的工程团队，团队有上千人，全部聚在一起听我的演讲。之后，VP(工程副总裁)感谢我说，我们的透明性使他们希望与我们合作，而不是与现在的供应商合作。我的演讲真适合去推销产品。
同样，去年我在 RSA 上发表了关于 Cloudbleed 的演讲，一家大型公司的 CSO 出现了，并要求在内部使用我的演讲来鼓励他们的公司也要如此公开透明。
今年 7 月 2 日，我们发生了一次与安全无关的宕机，我们再次在博客中详细记录了所发生的事情。我们再次听到人们的消息，我们的透明度是如何影响他们的。
通过这样的事情，我们学到了，对错误保持开放可以增加信任。如果人们信任您，那么他们会倾向于在出现问题时告诉您。因为这样，我通过 Twitter 或电子邮件接受到了大量有关潜在安全问题的报告。
改变 | Change
在 Cloudbleed 之后，我们开始改变编写软件的方式。Cloudbleed 的造成，有部分原因，是因为使用了内存不安全的语言。在那种情况下，可能是 C 代码的运行越过缓冲区末尾。
我们不希望这种情况再次发生，因此我们优先考虑了根本无法发生缓冲区溢出的语言。例如 Go 和 Rust。我们曾以使用 Go 而闻名。如果您曾经访问过Cloudflare 的网站，或者使用了将我们用作其 API 的应用程序（由于我们的规模而使用），那么您首先要对其中一台服务器进行 DNS 查询。
这样的 DNS 查询将由名为 RRDNS 的 Go 程序响应。
Cloudflare 还编写了很多 Rust，并且我们正在使用它来开发一些新产品。例如，对我们的客户进行任意过滤请求的 Firewall Rules(防火墙规则)由 Rust 程序处理，该程序需要 低延迟，稳定和安全。
安全是公司的首要承诺 | Security is a company wide commitment
Cloudbleed 之后的另一个变化是，我们系统上的所有崩溃都从一开始就受到关注。如果某个进程崩溃，我个人会收到有关它的电子邮件。如果团队不认真对待那些软件的崩溃问题，这会让我敲打他们，直到他们认真为止。
我们错过了 Cloudbleed 使我们的计算机崩溃的事实，我们不会再让这种情况发生。我们使用 Sentry 来关联有关崩溃的信息，并且我早上的第一件事情就是查看 Sentry 的输出。
我认为，这一点很重要。我之前说过我们的文化“如果您看到奇怪的东西，就要说出来”，但同样重要的是，安全性必须自上而下。
我们的 CSO，Joe Sullivan，不向我报告，而是直接向 CEO 报告。这清楚地传递出一个信息，安全在公司中的地位。但是，安全团队本身并没有静静地坐在角落，来确保所有东西的安全。
他们正在制定标准，充当可信赖的顾问，并帮助处理事件。但是他们最大的作用是成为公司其他部门的知识来源。Cloudflare 的每个人都在确保着我们安全的方面发挥着作用。
您可能认为我可以访问我们所有的系统，有一张可以让我进入任何房间的通行卡，我的账号可以登录任何服务。但事实恰恰相反：我无法接触大多数事物。我不需要它来完成我的工作，所以我没有这些权限。
这使我对黑客的吸引力降低了，我们将相同的规则应用于所有人。如果您不需要工作访问权限，就不会得到它。身份和身份验证系统以及我们有关不使用服务时超时访问的规则，使事情变得容易得多。您可能从一开始就不需要这些权限。
我们所有人都拥有安全性的另一面是，故意做错事会带来严重的后果。
每个人难免会犯错。编写错误的代码、造成 Cloudbleed 的员工没有被解雇；编写了糟糕的正则表达式、造成我们的服务在 7 月 2 日宕机的员工仍然与我们在一起。
检测和响应 | Detection and Response
自然情况下，系统在内部确实会出错。并且没有被报告。为此，我们需要快速发现问题。这是安全团队确实拥有真正专业知识和数据的领域。
我们收集相关 endpoints（我的笔记本电脑，公司手机，网络边缘的服务器）运行状况的数据，并将其输入到一个内置的数据平台中，该数据平台使安全团队可以对异常发出警报。
他们还可以查看历史数据，以防之前发生的问题，或是为了了解问题何时开始。
最初，该团队打算使用商业化的数据平台或者是 SIEM，但他们很快意识到这些平台非常昂贵，他们可以以相当低的价格构建自己的平台。
另外，Cloudflare 处理大量数据。当您在 194 个城市的服务器上，加上每位员工的计算机上。查看操作系统级别的事件时，你面对的工作量是巨大的。商业化的数据平台喜欢按数据流的大小收费。
我们正在集成内部 DNS 数据，单台服务器上的活动，网络净流量信息，badge(徽章)读取器日志，和操作系统级别的事件，用来全面了解在我们拥有的所有服务器上的情况。
当有人入职 Cloudflare 时，他们将前往旧金山的总部进行为期一周的培训。该培训的一部分包括购买和安装笔记本电脑，并熟悉我们的内部系统和安全性。
在这培训阶段的其中一个星期中，一名新员工在安装笔记本电脑时，设法下载了恶意软件。我们的内部检测系统发现了这种情况，安全团队迅速赶到了指导室，并帮助员工重新恢复了笔记本电脑。
从下载到检测到恶意软件之间的时间大约为 40 分钟。
如果您不想自己制作类似的东西，请查看 Google 的 Chronicle 产品。非常酷。
关于你的组织真正丰富的数据源是 DNS。例如，您通常可以仅仅通过恶意软件在计算机上进行的 DNS 查询来发现恶意软件。如果您要这么做，请确保所有计算机都使用单独的一个 DNS 解析器，并获取其中的日志。
边界安全 | Edge Security
在某些方面，从安全角度来看，Cloudflare 最有趣的部分是最不有趣的部分。并非因为在 194 个城市中部署机器没有很大的技术挑战，而是因为我谈论过一些看似平凡的事情，但是其影响巨大。
身份，认证，文化，检测和响应。
但是，当然，边界服务器需要安全。并且，这是物理数据中心的安全性和软件的结合。
举一个例子，我们来谈谈 SSL 私钥。这些密钥需要分发到我们的机器上，以便在与我们其中一台服务器建立 SSL 连接时我们可以做出响应。但是 SSL 私钥是…私有的！
我们有很多这样的私钥。因此，我们必须安全地分发私钥。这是一个困难的问题。我们在静止时和运输过程中使用单独的密钥对私钥进行加密，该私钥安全地分发到我们的边缘计算机。
我们严格控制对该密钥的访问，因此没有人可以开始解密数据库中的密钥。而且，如果我们的数据库泄漏了，那么密钥将无法解密，因为所需的密钥是单独存储的。
并且，该密钥本身是由 GPG 加密的。
但是等等…还有更多的细节！
实际上，我们不希望解密后的密钥存储的任何过程可从 Internet 访问。因此，我们使用一种称为“ Keyless SSL”的技术，该密钥由一个单独的进程保存，并且仅在需要执行操作时才进行访问。(译者注：关于 Keyless SSL 的技术细节，可以参考 Keyless SSL: The Nitty Gritty Technical Details一文，本站将会在晚些时候给出翻译)
而且，Keyless SSL 可以在任何地方运行。例如，不必与处理 SSL 连接的程序位于同一台计算机上。甚至不必在同一国家/地区。我们的一些客户利用它来指定密钥的分发位置。
使用 Cloudflare 的产品来保护 Cloudflare | Use Cloudflare to secure Cloudflare
Cloudflare 的一项关键策略是我们使用我们自己研发的产品(eat our own dogfood，英语俚语，直译为：吃我们自己生产的狗粮)。您可能之前从未听说过这样的说法，但是这在美国很常见。这个想法是，如果您要为狗生产狗粮，那么您应该对狗粮的质量很有信心，以至于您可以自己食用。
Cloudflare 在安全性方面也是如此。我们使用自己的产品来保护自己。但是，更重要的是，如果我们发现我们的安全工具包中目前缺乏某种产品，那么我们将继续进行研发和构建。
由于 Cloudflare 是一家网络安全公司，因此我们与客户面临相同的挑战，但是我们可以努力来克服这些挑战。这样来看，我们的内部安全团队同样也是产品团队。 他们帮助研发产品，或是影响我们自己产品的方向。
内部安全团队同样也是 Cloudflare 的客户，他们使用我们的产品来保护我们的安全，并且我们在内部获得有关我们产品运行状况的反馈。这保护我们更加安全，使产品更强大。
客户的数据比我们自己的数据还要宝贵 | Our customers data is more precious than ours
通过 Cloudflare 网络传递的数据是私有的，并且通常是十分隐私的。你只需考虑网络浏览或者应用程序的使用。因此，我们会格外注意小心。
我们代表客户处理这些数据。客户们相信我们会谨慎处理，因此我们认为客户的数据比我们自己的内部数据更加宝贵。
当然，我们保护我们的客户和自己，因为一方的安全与另一方的安全性有关。但是值得考虑的是，您拥有的数据，在某种程度上属于您的客户，只能由您自己照看。
最后 | Finally
我希望这次演讲对您有所帮助。我试图让您了解 Cloudflare 如何考虑安全和运作方式。我们没有声称自己是安全的顶级天才，而是希望听到您的想法，意见和经验，这样我们会有所改进。
安全性并非永久不变的，这需要持续的关注，而其中的一部分关注是倾听他人的工作。
谢谢。