什么是云泄漏？
似乎每天都有新的客户数据泄露事件。信用卡和银行账号;病案;个人身份信息 （PII），例如地址、电话号码或 SSN——社交互动的几乎每个方面都有对应的信息，这些信息提供给第三方的社交访问让许多人觉得他们的隐私在暴露时受到了严重侵犯。
这种暴露发生的方式有很多种，但用来描述它们的名称经常随意互换，使一个大而微妙的问题变得浑浊。泄露、黑客攻击、泄漏、攻击 — 这些只是用于描述数据泄露事件的几个术语。但它们是什么意思呢？
- 攻击 - 攻击是指通过技术或社交手段故意造成损害或损失的攻击。攻击不一定会导致数据泄露。例如，拒绝服务攻击会中断正常作，但不会暴露信息。
- 泄露 - 成功的攻击能够保护敏感信息。
- 黑客攻击 - 一种利用技术漏洞来保护未经授权访问的攻击。可能导致违规，但也可能用于勒索软件（如 WannaCry）、建立僵尸网络或滥用计算资源。
- 泄漏 - 泄漏不需要外部参与者，而是由数据所有者的一方的某种作为或不作为引起的。
这里有一些光谱。例如，具有默认管理密码的 Internet 可访问数据库服务器几乎是一扇敞开的门，但需要明智的尝试才能使用。但在这四个术语中，泄漏与不是由第三方发起的泄漏不同。但是，有一种特定的泄漏是迄今为止许多最大和最危险的数据泄露的原因。我们称这些为“云泄漏”，因为它们发生在云存储没有与整个 Internet 进行适当分区时。
什么是云泄漏？
云泄漏是指存储在私有云实例中的敏感业务数据意外暴露在互联网上。云是 Internet 的一部分。不同之处在于，“云”提供了可用于执行企业规模 IT 运营的私有化空间。企业数据集通常由第三方信息分析公司处理，通常以未加密的方式存储在云中，并期望其数据位于这些私人口袋之一中。
但是像 Amazon 的 S3 这样的云存储选项允许用户向整个互联网开放他们的存储。这里需要强调的是，默认情况下，S3 存储桶是私有的。这意味着每个涉及 Amazon S3 存储实例的云泄漏都会在某个时候被处理数据的管理员更改其权限。当允许这些匿名公共权限时，“云 ”和 Internet 之间的界限就会消失。然后，任何人都可以访问这些数据，就像您最喜欢的网站一样。
但是，无论是 Amazon S3 存储桶、Azure 文件共享、配置错误的 GitHub 存储库，还是在云中设置的易受攻击的服务器，如果无法保证云实例的隐私，数据就会面临风险。一旦出现错误，组织就很难证明数据在某个时候没有被访问。大多数人不知道从哪里开始寻找，而具有足够技术知识的人可能会出于好奇而随意浏览，但实际上有两大类人正在扫描云泄漏：安全研究人员和寻求利用发现的信息来获取杠杆、个人利益或权力的人。
云泄漏示例
Verizon 合作伙伴 Nice Systems 向 Internet 公开了 600 万条客户记录
这些信息是从暴露的 Amazon S3 存储桶中泄露的，包括客户详细信息，例如姓名、地址和电话号码，以及一些用于向 Verizon 验证身份的账户 PIN。除了明显的隐私问题外，暴露的数据可能被恶意用于冒充客户，甚至绕过双因素身份验证。
RNC 供应商数据根分析公开了 1.98 亿条选民记录
有史以来最大的泄漏之一是在发现一个暴露的云系统时被发现的，该系统包含来自 Data Root Analytics 的收集和建模的选民数据，Data Root Analytics 是一家与 RNC 签约的公司，负责数据驱动的政治战略。数据集中代表了超过 1.98 亿个独立个体，包括个人详细信息、选民信息和建模属性，包括可能的种族和宗教。
政府承包商 Booz Allen Hamilton 泄露了地理空间数据和证书
另一个被曝光的云存储实例泄露了来自政府承包商 Booz Allen Hamilton 的数据。除了数据泄露之外，该存储桶还包含 BAH 工程师的加密密钥和“授予对至少一个数据中心作系统的管理访问权限的凭据。“ 在这种情况下，不仅信息遭到泄露，而且其他系统也可能遭到泄露，允许恶意行为者从公开暴露的云服务器跳到网络上的授权服务器。
作问题
云泄漏是企业的独特风险。导致这些错误的简单性与由此可能导致的后果的严重性形成鲜明对比。利用云，或雇用提供云的供应商，可以带来很多功能价值。但是，如果不考虑云技术固有的潜在问题，该功能将因无法信任它而受到破坏，这反过来又会导致无法信任使用它的公司。云泄漏是一个运营问题，必须在管理云中数据处理的 IT 流程中解决，才能有效缓解。
制作副本
要了解云泄漏是如何发生的以及它们为何如此普遍，我们需要退后一步，首先看看泄露信息最初是如何生成、纵和使用的。这些庞大的敏感数据集存在并且公司正在对它们进行一些处理，这几乎已成定局，但是当您检查信息处理的实践时，很明显，在规模上组织一个有弹性的流程变得相当困难;运营差距和流程错误会导致资产易受攻击，进而导致云泄漏。
数字数据的一大优点是它可以廉价地复制并且不会退化。除了在其业务流程中使用的生产数据副本之外，组织通常还拥有多个生产数据副本。备份、仓储、灾难恢复、开发和测试环境、内部分析、外包分析、某人将数据复制到的笔记本电脑，以便他们可以在家中工作——不胜枚举。关键是 data 既是 many 又是 one，就像 data 这个词本身是如何混淆复数和单数的。数据集可以存在多个副本，但只有一个可能的漏洞，即数据集暴露。数据集的副本越多，发生泄露的风险就越高。
信息经济
将数据视为通过监管链。数据的每个副本都位于服务器或磁盘阵列上，通过网络设备和防火墙，偶尔会落在工作站或笔记本电脑上。通常，它最终会在云中、在 Internet 托管的存储实例中，并且与链中的任何其他链接一样，如果配置不当，则存在潜在的暴露风险。
这些做法几乎在每个行业都有发生，并且随着规模的增长而增加。这不仅仅是政治竞选分析、电信或国防承包商，而是每个人。数字化是商业本身抽象概念的根本性变化，其影响影响着各行各业的公司。因此，一个专门致力于数据处理的整个行业如雨后春笋般涌现，以支持其他公司的信息需求。大多数公司不直接处理数据。他们处理汽车、金融、医疗保健或小工具。因此，与许多第三级业务需求一样，他们将数据处理外包给第三方，而第三方表面上具有更强的管理能力。
但是，数据复制的便利性以及公司可以从数据中提取的大量价值加速了数字化，增加了行为报告和其他类型的指标，并尽可能将基础设施推向更快的速度和更大的容量。没有太多关注这些关键的集中式数据存储所带来的业务风险，这些数据存储很容易复制和分发。
云的价值
在某种程度上，分析供应商和云计算之间存在相似之处 — 一个外包信息的劳动力（和风险），而另一个则外包技术。云的优势是众所周知的：整体基础设施优于小型数据中心;可以通过编程方式快速创建大量服务器，从而实现更好的流程自动化;云计算能力是弹性的，可以根据需求进行严格调整，并且可以轻松更改。但是，随着流程的加快和管理范围的扩大，运营差距随之出现，其中微小但关键的云配置错误会使生产数据暴露在公众面前。
在任何云环境（Amazon Web Services、Microsoft Azure、IBM Bluemix）以及任何 Internet 托管的基础设施中，敏感的企业信息都可能因意外、疏忽或错误而公开。这一点很关键：几乎所有的云设备（包括上面列出的设备）默认情况下都是私有的。这意味着，在某个时候，默认权限被更改为允许公共访问。云泄漏不是由特定于平台的软件漏洞引起的，而是由于缺乏必要的控制措施来保证安全结果的进程造成的。
过程决定安全性
处理信息的方式因地而异，而且往往因人而异。有一般准则——例如，如果您处于受监管的行业并且必须遵循 PCI DSS、HIPAA 或 FERPA 等标准。但是，最终决定是否会发生云泄漏的日常工作在组织之间和组织内部差异很大。
考虑以下场景：系统管理员正在使用 Amazon 的 S3 云服务为一家分析公司管理存储。系统管理员需要移动一些文件，因此生产数据会临时复制到未使用的 S3 实例，同时修改其他实例。一旦系统管理员最终修复了所有存储桶，生产数据就位了，一切都准备好了。除了 sysadmin 忘记从临时 S3 存储桶中删除数据副本，并且该 S3 存储桶恰好配置了完全公有访问权限。
这可能看起来像是人为错误。有人只是忘记做某事。发生在我们所有人身上，对吧？不完全是。这里的真正问题不在于一个人犯了错误——这是必然的——问题在于没有结构上有任何措施来防止错误，或者至少立即发现错误以便修复它。
云泄漏不是黑客造成的，也不是 IT 员工个人的错。它们是脆弱的业务流程的结果，无法处理云作的复杂性和规模，并依靠运气来弥补差异。通过隐蔽实现安全已经死了。例如，认为云实例是安全的，因为没有其他人知道 URL，这种想法既是不真实的，也是错误思维的产物。当信息像今天一样有价值，而全球企业运营足够脆弱，以至于只能向匿名的 Internet 浏览器开放数据时，将并且已经开发出利用这种情况的技术。这就是为什么必须将弹性内置到创建、管理和维护信息技术的程序工作中。
什么会泄露？
客户信息
云泄漏中最常见的信息类型是客户数据。这些数据因公司而异，但通常涉及一些常见因素：
- 身份信息 - 姓名、地址、电话号码、电子邮件地址、用户名、密码
- 活动信息 - 订单和付款历史、浏览习惯、使用详情
- 信用卡信息 - 卡号、CVV 代码、到期日期、账单邮政编码
此外，任何特定于公司的信息通常也会暴露。这可以是银行和投资集团的财务信息、医院和保险公司的医疗记录，而对于政府实体来说，客户信息可以包含任意数量的敏感文档和表格。
公司信息
但客户信息并不是故事的终点。当暴露在云泄漏中时，还有其他几种类型的数据会带来重大风险。公司信息也可能泄露。这可能包括：
- 内部通信 - 详细说明公司运营的备忘录、电子邮件和文档
- 指标 - 绩效统计数据、预测和收集的有关公司的其他数据
- 策略 - 消息传递详细信息、路线图、名片和其他关键业务信息
此类信息的曝光会阻碍公司项目，让竞争对手深入了解业务运营，并揭示内部文化和个性。公司越大，对此类数据的兴趣就越大。
商业秘密
>但是，在云泄漏中暴露的最危险的公司数据类型是商业机密。这是对企业本身至关重要的信息，其保密性使企业具有竞争能力，并且经常成为工业间谍的目标。商业秘密可以包括：
- 计划、公式、设计 - 有关现有或即将推出的产品和服务的信息
- 代码和软件 - 企业销售或为内部使用而构建的专有技术
- 商业方法 - 市场策略和联系方式
显然，这些数据只有在对竞争对手保密时才是有利的。这种类型的曝光对公司来说可能是灾难性的，会毁掉多年的研究和工作，使企业提供的产品和服务贬值。
分析学
最后，分析依赖于由多个信息源组成的大型数据集，以揭示全局趋势、模式和轨迹。尽管分析在为业务决策提供信息方面非常强大，但执行此类分析所需的数据在暴露时也是风险的载体。这种类型的一些数据包括：
- 心理数据 - 偏好、个性特征、人口统计、消息传递
- 行为数据 - 例如，有关某人如何使用网站的详细信息
- 建模数据 - 基于收集的其他信息的预测属性
这些信息非常强大，因为它能够将个人理解为一组数据点，然后以高度准确的方式预测与之相关的其他数据点。尽管这听起来很抽象，但考虑到这是收集的选民信息类型，有助于政治竞选活动更有效地大规模说服。
万事
业务数字化。任何事物都是某种类型的信息，如果没有适当的流程控制，这些信息可能会在云中泄露。上面的示例列出了一些类型的敏感和危险信息，但实际上一切都处于危险之中。企业业务（以及个人生活）的任何方面都有其信息集。当我们说云泄漏是一个业务问题时，我们的意思是信息和技术对现代企业如此重要，以至于它们的风险已经成为生存风险。
云泄漏是如何被利用的
你认识的魔鬼
在检查上述信息类型时，一些明显的威胁可能会立即出现。这些媒介已经存在了一段时间，无论信息是通过云泄露的，还是通过黑客或网络钓鱼电子邮件获得的，许多后果都是熟悉的。我们将简要介绍此类信息的常见利用方式，然后继续介绍更复杂的用途以及未来会怎样。
信用卡欺诈
利用泄露数据的犯罪的第一个也是最明显的例子是信用卡欺诈。通过在线订购，人们通过互联网和他们光顾的任何企业的系统传递他们的信用卡详细信息。人们已经非常关注交易过程，并在信息通过互联网时保护信息，但对数据存储后发生的事情的关注要少得多。正如我们在上一篇云泄漏文章中所看到的，数据会出于各种目的被重复复制，信用卡数据也不例外。撇渣器每天可能会收到 100 张信用卡，但涉及云泄漏的数据库可能包含数百万张信用卡，并且不需要安装和配置恶意软件撇渣器。
黑市销售
通常，获取数据的人和使用它的人是不同的一方。经济围绕黑市信息交易发展起来，其中被泄露的数据被出售给暗网上出价最高的人，使用难以追踪的加密货币，如比特币。在这种情况下，信息检索器专门通过社会工程从不安全的云实例、易受攻击的数据库获取数据，而信息购买者则专门使用这些信息 - 信用卡计划、SSN 和身份欺诈、垃圾邮件和网络钓鱼作。
敲诈勒索/羞辱
有时，暴露的信息被公司掌握在头上，要么是为了赎金，要么只是为了向公众羞辱该公司。WannaCry 等勒索软件攻击会锁定资产和数据，但云泄漏会将这些数据泄露给任何正在查看的人。希望破坏与他们意见相左的公司的活动家可能会发现分享他们的工资结构、内部沟通或商业计划是有利的。无论具体情况如何，事实是云泄漏为潜在对手提供了难以置信的杠杆作用。
竞争优势
除了犯罪分子之外，竞争对手还可以轻松利用云泄漏中暴露的信息。从客户列表到商业秘密，一切都为其他公司提供了访问资源和战略的权限。竞争洞察是每家公司在其营销运营中努力实现的目标，而云泄漏中暴露的信息使这种洞察更加敏锐。
如何利用云泄漏
社会工程学
我们之前提到了网络钓鱼攻击。最有效的网络钓鱼攻击被称为鱼叉式网络钓鱼，因为虚假电子邮件以激光聚焦于其收件人，使用已知信息更好地冒充权威人物或高管。网络钓鱼攻击的有效性取决于它们对阅读者的说服力。许多充斥着拼写错误并使用奇怪格式或 HTML 的程序很容易被发现，但其中最好的乍一看看起来很真实。云泄漏中暴露的信息，尤其是心理数据和其他行为分析，正是加强社会工程攻击的信息，使攻击者能够使用他们本不应该知道的目标信息。
针对
个人身份信息 （PII） 可用于信用卡欺诈以外的其他用途。获取某人的个人信息并在违背他们的意愿的情况下发布它是一种称为“人肉搜索”的做法，这样做的原因有很多，但总是让被人肉搜索的人容易受到未知数量的匿名者的掠夺。在政治极端主义、仇恨、骚扰或跟踪的情况下，暴露 PII 可能会导致对人们的实际伤害。云泄漏特别危险的是，它们不需要任何特殊的技术技能即可利用——只需去获取数据即可。这大大扩大了潜在发现者的群体。
监视和影响
当涉及到心理数据时，潜在的用途是无限的。获取心理数据的目的就是为了更好地预测人们的反应并塑造他们的反应。政治竞选活动利用它来赢得选票。企业使用它来赢得客户。仅考虑到此类分析的正常用例，就很容易看出有动机的第三方（另一家国有或私营企业）如何通过云泄漏获取这些数据，并将这些信息用于其目的。当 RNC 承包商泄露了几乎所有美国注册选民的选民数据时，这不仅侵犯了隐私，而且可能是一种新的纵媒介。
中断
最后，云泄漏将未经审查的信息直接暴露给公众，从而给业务运营带来麻烦。正如我们所看到的，云泄漏中暴露的信息可能会对公司甚至政府产生严重后果。破坏性攻击并不新鲜;拒绝服务攻击的目标是简单地阻止资源被使用。信息中断是这种类型的一类新类别。当公司信息暴露在云中时，它为该公司提供了脱轨的机会。这些攻击背后的动机可以是从激进主义到利润的任何事情，但与勒索场景一样，将这些数据暴露给全世界会让未知的第三方对商业利益产生巨大的影响力。
询问为什么云泄漏很重要，就像询问为什么数据很重要一样。答案是一样的 - 信息赋予人们和组织力量。这些数据无意中暴露给公众，让其他人有机会利用这种权力来对付数据的所有者。我们概述了这种情况的一些已知和可能的表现;但是，无论数据如何被利用，只要我们的经济、我们的通信和社会被数字化，数据就会很有价值。当涉及到客户数据时，云泄漏很重要的主要原因是数据代表了真实的个人，他们经常不得不承受泄露的影响。收集数据并使用它来改善业务的公司有责任谨慎处理这些数据。
如何防止云泄漏
当我们研究数据泄露、攻击、黑客攻击和泄漏之间的区别时，这不仅仅是一项学术活动。我们对这种现象的思考方式会影响我们对它的反应方式。简而言之：云泄漏是一个作问题，而不是安全问题。云泄漏不是由外部参与者引起的，而是由数据处理程序日常工作中的作差距引起的。公司创建和维护云存储的流程必须考虑公众暴露的风险。
验证
云存储为 IT 运营提供速度、可扩展性和自动化。公司根据需要将生产数据集移入和移出云存储，通常将同一个存储桶重复用于多个任务。如果不妥善保管，敏感数据集很容易被移动到不安全的存储桶中。这就是为什么应该在部署时以及在托管生产数据的整个过程中验证云存储配置的原因。持续验证使风险可见，甚至可以在允许公共访问时主动通知管理员。
为什么流程验证是防止云泄漏的关键的一个例子是，Amazon 的 S3 存储默认是私有的。这意味着必须在某个时间点更改权限集，才能向全世界公开存储桶。该更改（向 All Users 或 Authenticated Users 组添加访问权限）只有在没有适当的控制措施来验证权限是否准确时，才会无意中发生。同样，如果将敏感数据移动到已经公开的存储桶中，则不存在围绕数据处理的流程控制来检查移动过程中的权限。
导致云泄漏的人为错误不是。这是过程错误。人们每件事都会犯错。企业 IT 极其复杂，加剧了我们偶尔出错的自然倾向。这就是为什么必须实施过程级别的控制（结构、自动验证）来检查正在完成的工作。必须控制必须重复进行的作，以及如果作不当可能会危及公司的行为，以尽可能限制这种风险。
自动化
在企业范围内，只有当它能够适应高速工作流程时，才能实现验证。当配置验证成为流程的瓶颈时，它不太可能被尽职尽责地执行。如果它依赖于有人手动检查每个配置，那么它不仅不能足够快地完成，而且它遭受与原始设置相同的人为错误的可能性。计算机在保持序列之间的一致性方面比我们好得多。自动化流程控制应充当可执行文档，其中可以详细说明重要标准，例如确保所有云存储都是私有的，然后根据任何云存储实例的实际状态进行检查，以确保它们符合要求。
例如，如果我们在企业中预置 S3 存储桶，而不是在 AWS 控制台中手动创建存储桶并完成检查表，我们应该使用 Amazon 的 API 自动以编程方式创建存储桶，并在创建存储桶后将验证步骤引入流程中，以检查互联网暴露等关键设置。这样，当需要创建云存储实例时，管理员只需启动脚本并确保新创建的存储桶符合要求。
自动化还允许在资产的整个生命周期内连续执行配置验证。这可确保始终了解资产。企业数据中心内的变化是持续的;一个好的流程可以验证更改是否不违反基本标准，并在更改时立即提醒人们。
第三方风险
进一步掩盖问题的是云泄漏经常发生的距离：进行信息处理的第三方供应商意外地将信息暴露在云中。由于数据集在客户心目中与主要公司相关联，因此他们将对泄漏负责，就像它是他们自己的服务器一样。这使得评估和优化第三方网络风险与内部弹性同样重要。
与另一家公司合作处理敏感信息时，应始终需要评估该公司的做法，以便了解他们处理这些数据所带来的风险。在内部网络安全上花费数百万美元，只是为了将相同的数据外包给将其暴露在云中的人，这是没有意义的。供应商的选择和评估应与公司保护其内部资产和信息一样谨慎。
UpGuard 通过自动化云存储验证来解决云泄漏问题。公共访问是最危险的，但与任何数字表面一样，云存储的总配置状态决定了其弹性。UpGuard 不仅扫描存储实例以公开暴露，还检查云平台和服务器本身是否存在可能导致数据泄露的错误配置。UpGuard 还可以验证其他面向 Internet 的泄漏源，例如配置错误的 GitHub 存储库和易受攻击的 rsync 服务器。
借助 UpGuard 的可视化策略，管理员可以一目了然地知道哪些云存储实例是公共的，哪些是私有的。在配置过程中，可以使用 UpGuard 的 API 以及与 Puppet、Chef 和 Ansible 等工具的集成自动验证新存储桶。
借助 UpGuard Procedures，云配置和维护流程可以实现端到端的自动化和验证，从而降低运营风险。可执行文档在按流程安排时效果最佳，因此可以将过程步骤逻辑地链接在一起并依次进行验证。这会产生值得信赖的资产，并大大降低了错误配置的风险，例如意外的公开暴露。
例如，在 AWS 上自动创建新的 Linux Web 服务器的过程可以：
- 验证 S3 存储桶是否为私有且配置正确。
- 验证每个云服务器的 AWS 设置，例如实例类型和位置。
- 根据公司策略验证服务器设置。
- 根据 CIS 安全基准测试服务器。
- 验证特定的 Web 服务器配置，例如 http.conf 和 SSL。
与缺乏这些控制的云服务器和存储相比，以这种方式部署的云服务器和存储的数据泄露风险要低得多。
UpGuard 还提供外部供应商评估，分析和可视化负责处理您的数据的第三方带来的相对风险。将供应商和合作伙伴与类似公司进行比较，了解他们在各自领域的表现如何。我们的外部评估将互联网上可见的所有相关安全实践汇总到一个风险评分中。
这包括供应商所有 URL 的网站详细信息;电子邮件和域安全，例如防止网络钓鱼的协议;开放端口，例如 Microsoft 的 SMB，它已被 WannaCry 和 Petya 等勒索软件攻击利用，以及业务详细信息，包括员工满意度和 CEO 支持率。
结论
云泄漏是作错误的结果，而不是人为错误。过程缺少必要的控制，无法随着时间的推移可靠地产生良好的结果。防止云泄漏的方法是通过对所有关键资产进行自动验证来弥补这些运营差距。发生云泄漏的原因是没有人知道敏感数据暴露在互联网上。如上所述的流程控制可以保证这些知识立即浮出水面，以便在它成为更大的问题之前得到修复。
在 UpGuard，我们可以保护您的企业免受数据泄露，并帮助您持续监控所有供应商的安全状况。
您的企业是否存在安全漏洞风险？
点击这里 立即获取您的免费安全评级！