论文部分内容阅读
编译 Charles
某一天，由于基于云系统的配置不完善，又出现了一起数据泄露事件。在最近的一次事件中，Verizon的600多万名美国客户信息被泄露，这再次提醒我们，云供应商和企业应同时担负起云安全的责任。
有一种误解，认为是由云服务供应商负责云环境的安全，但这只是故事的一半。亚马逊、微软和谷歌等云安全供应商，负责其物理数据中心以及运行虚拟机的服务器硬件的安全，而让每个客户自己保护好虚拟机和应用程序。云供应商提供了一系列安全服务和工具来保证客户工作负载的安全，而实际由管理员去实施必要的防护措施。如果客户不能保护他们自己的网络、用户和应用程序，云供应商提供再多的安全防御措施也没什么用。
一家第三方服务供应商处理Verizon的后台和呼叫中心业务，在亚马逊网络服务（AWS）简单存储服务（S3）的数据存储桶中存储过去六个月内致电过呼叫中心的所有客户的呼叫数据，包括每一名Verizon客户的姓名、地址、电话号码，以及账号PIN码等。采集数据是为了帮助改进客户服务体验，但由于S3存储桶配置不正确，而允许外部访问，任何人只要有足够耐心弄清楚网络地址，就能够下载信息。拿到数据的骗子们假装成Verizon客户打电话，从而访问客户帐户。
这类错误太常见了。云安全公司RedLock的云基础设施安全研究小组最近的研究发现，40%的企业由于配置错误，不经意间已经至少暴露了一项公有云服务。
错误配置是严重的问题
Verizon只是由于配置错误而导致数据被暴露在公有云中的众多企业中的一家。就在几星期前，由于美国职业摔跤（WWE）协会把未加密数据库放在了AWS的S3存储桶中，而且没有进行访问控制和密码保护，导致3百多万摔跤爱好者的个人数据被泄露。六月，共和党全国委员会证实，1亿9千8百万注册美国选民的个人身份信息——大约占选民的60%，以明文方式被存储在数据分析公司Deep Root Analytics拥有的开放Amazon S3存储服务器中。由于把文件存储在S3存储桶中，国防承包商Booz Allen Hamilton属于五角大楼的6万份文件被暴露，包括与美国军事项目有关的敏感文件，6份未加密的安全证书。
云安全创业公司RedLock首席执行官和联合创始人Varun Badhwar说：“问题不在于云是不安全的，而在于最终是由顾客负责安全地配置他们的网络、应用程序和数据。如果采用这种服务的企业能够正确的进行配置，AWS等公有云基础设施是非常安全的。”
云安全公司Threat Stack分析了使用AWS的200家公司，发现73%的公司至少有一个关键的安全配置错误，例如，让未经授权的用户直接访问数据，错误配置的对象成为大规模攻击的一部分，通过登录AWS控制台来控制整个环境。这些泄露事件是由于基本的安全疏忽和未制定IT政策而造成的，而不是恶意对手主动攻击造成的。
不论是谁在做配置——是IT管理员、开发人员、工程师还是安全部门，有太多的人并没有完全理解怎样配置他们的云环境。企业再也不能把公有云视为存储信息的一种老方法，而应该采用以下安全措施，以确保未经授权的用户不能访问其云环境、应用程序和数据。
1.知道您要负责什么
所有云服务并不一样，要负起的责任也各不相同。软件即服务（SaaS）供应商会确保他们的应用程序受到保护，数据被安全地传输和存储，而云基础设施通常不是这种情形。例如，企业应完全负责其AWS弹性计算云（EC2）、亚马逊EBS和亚马逊虚拟私有云（VPC）的应用，包括配置操作系统、管理应用程序、保护数据等。
相反，亚马逊维护简单存储服务（S3）的操作系统和应用程序，而企业负责管理数据、访问控制和身份识别策略。亚马逊提供了为S3数据加密的工具，但这取决于企业在进入和离开服务器时是否启用了保护功能。应与供应商核实谁负责每一项云安全控制功能。
2.控制谁有权访问
RedLock的CSI发现公有云有31%的数据库是开放给互联网的。事实上，公有云环境中93%的资源对出站流量根本没有进行限制。9%的云工作负载既没有负载均衡器也没有受到防护主机的保护，能接受来自任何端口任何IP地址的数据流，这是非常可怕的。只有负载均衡器和防护主机能够直接出现在互联网上。
正是因为S3存储桶被设置为允许外部访问才导致Verizon数据被泄露。遗憾的是这类错误太常见了。Threat Stack公司在其研究中发现，37%的企业的S3存储桶允许所有人访问。很多管理员在公共子网中使用0.0.0.0/0，错误地启用了服务器的全局权限。连接完全放开了，每台计算机都能够进行连接。
对于AWS的情况，S3存储桶绝不应该有公共访问策略。
在Threat Stack的分析中，另一常见的错误是打开SSH，73%的企业都这样做了。Threat Stack公司还发现，13%的企业允许从互联网直接连接SSH，这意味着任何能找到服务器地址的人都可以绕过防火墙，直接访问数据。
主要云供应商都会提供身份识别和访问控制工具；请使用它们。应知道谁在何时访问了哪些数据。在创建身份识别和访问控制策略时，把最高权限限制在最小范围内，只在需要时临时授予额外权限。尽可能把安全组配置为最窄安全焦点，并在可能的情况下使用参考安全组ID。
亚马逊VPC允许管理员在AWS云中创建一个逻辑隔离的网络，以便在虚拟网络中启动服务器。这是保护产品环境不受开发和发布环境影响并保持数据隔离的一种方法。
3.保护数据
另一常见的错误是数据没有经过加密便放在了云上。RedLock的CSI发现，公有云中82%的数據库是不加密的。选民信息和敏感的五角大楼文件之所以被泄露，是因为数据没有加密，未经授权方能够访问服务器。把敏感数据存储在云中而没有对服务器的访问进行适当控制以保护数据，这样做是不负责任的，也是危险的。 尽可能控制好加密密钥。虽然可以让云服务供应商访问密钥，但底线是保护数据的责任在于企业。
WinMagic首席运营官Mark Hickman说：“这就类似于相信您的家庭装修人员，把家里的钥匙交给了他。您希望一切都没问题，但您永远都不能100%确定他们会锁上门，也无法确定他们的分包商会干些什么。那么，为什么还要冒险让他们一开始就能拿到您的钥匙呢？”
即使云供应商提供了加密工具和管理服务，很多企业实际并没有使用。加密是一种安全保障措施——即使安全配置失败，数据落入未授权方的手中，他们也不能使用数据。
4.保护证书
如OneLogin泄露事件所展示的，AWS访问密钥被泄露的情况并不少见。这些密钥会出现在公共网站、源代码库、未受保护的Kubernetes仪表板，以及其他一些论坛上。要把AWS访问密钥视为最敏感的宝贵资产，教育开发人员避免在公共论坛中泄露此类密钥。
为每一个外部服务创建唯一的密钥，并遵循最小特权原则限制对其访问。应限制密钥的访问权限，如果错误的落在别人手中，它们会被用于访问敏感的资源和数据。创建IAM角色来分配特殊特权，例如进行API调用。
一定要定期換密钥。RedLock发现63%的访问密钥超过90天都没有被换掉。这使得攻击者有时间截获密钥，作为特权用户渗透到云环境中。
不要使用root用户帐户，即使是要用于管理任务。可以使用root用户来创建具有指定权限的新用户。锁定root帐户（可以通过添加多重身份验证来实现），仅用于非常具体的帐户和服务管理任务。对于其他的，为用户提供适当的权限。
检查用户帐户，查找那些未被使用的账户，并禁用它们。如果没有人使用这些账户，何必给攻击者留下攻击的后门呢。
5.保证环境安全仍然很重要
对于云环境防护，深度防御尤其重要，因为即使一项控制功能失败，也会有其他安全功能保持应用程序、网络和数据的安全。
多重身份认证（MFA）功能在用户名和密码之上提供了额外的保护层，使攻击者更难入侵。应启用MFA，限制对管理控制台、仪表板和特权帐户的访问。Redlock发现，58%的root账户没有启用多重身份认证功能。Threat Stack发现，62%的企业至少有一个AWS用户没有启用多重身份认证功能。
6.增强可视化
主要云供应商都提供某种级别的日志记录工具，因此一定要启用安全日志记录和监视功能，看看是否有未经授权的访问和其他问题。亚马逊为审查AWS环境提供了CloudTrail，但很多企业最终并没有使用该服务。当启用后，CloudTrail会记录所有AWS API调用的历史，包括API调用者的身份、调用的时间、调用者的源IP地址、请求参数，以及AWS服务返回的响应数据。它还可以用于变更跟踪、资源管理、安全性分析和合规审查等。
不要让错误导致出现泄露
数据泄露并不总是由外部攻击者造成的，敏感数据也可能是由人为错误而被泄露的。忘记启用某项功能，或者认为某件事情已经完成了，但却不去检验一下，这些人为错误都会给攻击者敞开大门。企业应定期评估其云环境及其供应商和合作伙伴的安全性。正如Verizon泄露事件所示，第三方供应商犯下的错误成为企业头痛的问题。
共享安全模型的存在是有原因的——不管谁负责云工作负载的安全性，企业最终要对数据的一切负责。
Fahmida Y. Rashid是CSO的资深作家，其写作主题是信息安全。
原文网址：
http：//www.csoonline.com/article/3208905/cloud-security/top-cloud-security-controls-you-should-be-using.html
某一天，由于基于云系统的配置不完善，又出现了一起数据泄露事件。在最近的一次事件中，Verizon的600多万名美国客户信息被泄露，这再次提醒我们，云供应商和企业应同时担负起云安全的责任。
有一种误解，认为是由云服务供应商负责云环境的安全，但这只是故事的一半。亚马逊、微软和谷歌等云安全供应商，负责其物理数据中心以及运行虚拟机的服务器硬件的安全，而让每个客户自己保护好虚拟机和应用程序。云供应商提供了一系列安全服务和工具来保证客户工作负载的安全，而实际由管理员去实施必要的防护措施。如果客户不能保护他们自己的网络、用户和应用程序，云供应商提供再多的安全防御措施也没什么用。
一家第三方服务供应商处理Verizon的后台和呼叫中心业务，在亚马逊网络服务（AWS）简单存储服务（S3）的数据存储桶中存储过去六个月内致电过呼叫中心的所有客户的呼叫数据，包括每一名Verizon客户的姓名、地址、电话号码，以及账号PIN码等。采集数据是为了帮助改进客户服务体验，但由于S3存储桶配置不正确，而允许外部访问，任何人只要有足够耐心弄清楚网络地址，就能够下载信息。拿到数据的骗子们假装成Verizon客户打电话，从而访问客户帐户。
这类错误太常见了。云安全公司RedLock的云基础设施安全研究小组最近的研究发现，40%的企业由于配置错误，不经意间已经至少暴露了一项公有云服务。
错误配置是严重的问题
Verizon只是由于配置错误而导致数据被暴露在公有云中的众多企业中的一家。就在几星期前，由于美国职业摔跤（WWE）协会把未加密数据库放在了AWS的S3存储桶中，而且没有进行访问控制和密码保护，导致3百多万摔跤爱好者的个人数据被泄露。六月，共和党全国委员会证实，1亿9千8百万注册美国选民的个人身份信息——大约占选民的60%，以明文方式被存储在数据分析公司Deep Root Analytics拥有的开放Amazon S3存储服务器中。由于把文件存储在S3存储桶中，国防承包商Booz Allen Hamilton属于五角大楼的6万份文件被暴露，包括与美国军事项目有关的敏感文件，6份未加密的安全证书。
云安全创业公司RedLock首席执行官和联合创始人Varun Badhwar说：“问题不在于云是不安全的，而在于最终是由顾客负责安全地配置他们的网络、应用程序和数据。如果采用这种服务的企业能够正确的进行配置，AWS等公有云基础设施是非常安全的。”
云安全公司Threat Stack分析了使用AWS的200家公司，发现73%的公司至少有一个关键的安全配置错误，例如，让未经授权的用户直接访问数据，错误配置的对象成为大规模攻击的一部分，通过登录AWS控制台来控制整个环境。这些泄露事件是由于基本的安全疏忽和未制定IT政策而造成的，而不是恶意对手主动攻击造成的。
不论是谁在做配置——是IT管理员、开发人员、工程师还是安全部门，有太多的人并没有完全理解怎样配置他们的云环境。企业再也不能把公有云视为存储信息的一种老方法，而应该采用以下安全措施，以确保未经授权的用户不能访问其云环境、应用程序和数据。
1.知道您要负责什么
所有云服务并不一样，要负起的责任也各不相同。软件即服务（SaaS）供应商会确保他们的应用程序受到保护，数据被安全地传输和存储，而云基础设施通常不是这种情形。例如，企业应完全负责其AWS弹性计算云（EC2）、亚马逊EBS和亚马逊虚拟私有云（VPC）的应用，包括配置操作系统、管理应用程序、保护数据等。
相反，亚马逊维护简单存储服务（S3）的操作系统和应用程序，而企业负责管理数据、访问控制和身份识别策略。亚马逊提供了为S3数据加密的工具，但这取决于企业在进入和离开服务器时是否启用了保护功能。应与供应商核实谁负责每一项云安全控制功能。
2.控制谁有权访问
RedLock的CSI发现公有云有31%的数据库是开放给互联网的。事实上，公有云环境中93%的资源对出站流量根本没有进行限制。9%的云工作负载既没有负载均衡器也没有受到防护主机的保护，能接受来自任何端口任何IP地址的数据流，这是非常可怕的。只有负载均衡器和防护主机能够直接出现在互联网上。
正是因为S3存储桶被设置为允许外部访问才导致Verizon数据被泄露。遗憾的是这类错误太常见了。Threat Stack公司在其研究中发现，37%的企业的S3存储桶允许所有人访问。很多管理员在公共子网中使用0.0.0.0/0，错误地启用了服务器的全局权限。连接完全放开了，每台计算机都能够进行连接。
对于AWS的情况，S3存储桶绝不应该有公共访问策略。
在Threat Stack的分析中，另一常见的错误是打开SSH，73%的企业都这样做了。Threat Stack公司还发现，13%的企业允许从互联网直接连接SSH，这意味着任何能找到服务器地址的人都可以绕过防火墙，直接访问数据。
主要云供应商都会提供身份识别和访问控制工具；请使用它们。应知道谁在何时访问了哪些数据。在创建身份识别和访问控制策略时，把最高权限限制在最小范围内，只在需要时临时授予额外权限。尽可能把安全组配置为最窄安全焦点，并在可能的情况下使用参考安全组ID。
亚马逊VPC允许管理员在AWS云中创建一个逻辑隔离的网络，以便在虚拟网络中启动服务器。这是保护产品环境不受开发和发布环境影响并保持数据隔离的一种方法。
3.保护数据
另一常见的错误是数据没有经过加密便放在了云上。RedLock的CSI发现，公有云中82%的数據库是不加密的。选民信息和敏感的五角大楼文件之所以被泄露，是因为数据没有加密，未经授权方能够访问服务器。把敏感数据存储在云中而没有对服务器的访问进行适当控制以保护数据，这样做是不负责任的，也是危险的。 尽可能控制好加密密钥。虽然可以让云服务供应商访问密钥，但底线是保护数据的责任在于企业。
WinMagic首席运营官Mark Hickman说：“这就类似于相信您的家庭装修人员，把家里的钥匙交给了他。您希望一切都没问题，但您永远都不能100%确定他们会锁上门，也无法确定他们的分包商会干些什么。那么，为什么还要冒险让他们一开始就能拿到您的钥匙呢？”
即使云供应商提供了加密工具和管理服务，很多企业实际并没有使用。加密是一种安全保障措施——即使安全配置失败，数据落入未授权方的手中，他们也不能使用数据。
4.保护证书
如OneLogin泄露事件所展示的，AWS访问密钥被泄露的情况并不少见。这些密钥会出现在公共网站、源代码库、未受保护的Kubernetes仪表板，以及其他一些论坛上。要把AWS访问密钥视为最敏感的宝贵资产，教育开发人员避免在公共论坛中泄露此类密钥。
为每一个外部服务创建唯一的密钥，并遵循最小特权原则限制对其访问。应限制密钥的访问权限，如果错误的落在别人手中，它们会被用于访问敏感的资源和数据。创建IAM角色来分配特殊特权，例如进行API调用。
一定要定期換密钥。RedLock发现63%的访问密钥超过90天都没有被换掉。这使得攻击者有时间截获密钥，作为特权用户渗透到云环境中。
不要使用root用户帐户，即使是要用于管理任务。可以使用root用户来创建具有指定权限的新用户。锁定root帐户（可以通过添加多重身份验证来实现），仅用于非常具体的帐户和服务管理任务。对于其他的，为用户提供适当的权限。
检查用户帐户，查找那些未被使用的账户，并禁用它们。如果没有人使用这些账户，何必给攻击者留下攻击的后门呢。
5.保证环境安全仍然很重要
对于云环境防护，深度防御尤其重要，因为即使一项控制功能失败，也会有其他安全功能保持应用程序、网络和数据的安全。
多重身份认证（MFA）功能在用户名和密码之上提供了额外的保护层，使攻击者更难入侵。应启用MFA，限制对管理控制台、仪表板和特权帐户的访问。Redlock发现，58%的root账户没有启用多重身份认证功能。Threat Stack发现，62%的企业至少有一个AWS用户没有启用多重身份认证功能。
6.增强可视化
主要云供应商都提供某种级别的日志记录工具，因此一定要启用安全日志记录和监视功能，看看是否有未经授权的访问和其他问题。亚马逊为审查AWS环境提供了CloudTrail，但很多企业最终并没有使用该服务。当启用后，CloudTrail会记录所有AWS API调用的历史，包括API调用者的身份、调用的时间、调用者的源IP地址、请求参数，以及AWS服务返回的响应数据。它还可以用于变更跟踪、资源管理、安全性分析和合规审查等。
不要让错误导致出现泄露
数据泄露并不总是由外部攻击者造成的，敏感数据也可能是由人为错误而被泄露的。忘记启用某项功能，或者认为某件事情已经完成了，但却不去检验一下，这些人为错误都会给攻击者敞开大门。企业应定期评估其云环境及其供应商和合作伙伴的安全性。正如Verizon泄露事件所示，第三方供应商犯下的错误成为企业头痛的问题。
共享安全模型的存在是有原因的——不管谁负责云工作负载的安全性，企业最终要对数据的一切负责。
Fahmida Y. Rashid是CSO的资深作家，其写作主题是信息安全。
原文网址：
http：//www.csoonline.com/article/3208905/cloud-security/top-cloud-security-controls-you-should-be-using.html