Aws VPC 安全的十个最佳实践

随着越来越多的企业选择AWS之类的云计算服务，与此同时云计算环境也变得越来越复杂，因此企业必须制定全面、主动的安全策略，并从开始就建立起安全策略，并要随着基础架构的扩展而发展以保持系统和数据的安全。

AWS基础架构的安全性已被设计为当今最具灵活、最安全的云计算环境之一。它的设计目标就是提供一个高度可扩展、高度可靠的平台，使客户能够快速安全地部署应用程序和数据。AWS运行在“责任共担”的安全模型之下。AWS负责底层的云基础设施的安全,其用户负责保护部署在AWS上的工作负载。

 

在AWS的提供的基础设施之中，Amazon Virtual Private Cloud (VPC)承担了非常重要的角色。VPC为我们带来了强大的网络功能，包括静态私有的IP地址、弹性网络接口、安全的Bastion（堡垒）主机设置、DHCP选项、高级网络访问控制、VPN连接、内部IPs和NICs在实例之间的转移等等。在网络安全方面，Amazon VPC 提供了安全组和网络访问控制列表等高级安全功能，可在实例和子网级别启用入站和出站筛选功能。了解更多关于使用Amazon VPC的最佳实践，对于无论正在维护现有的VPC网络，还是计划迁移到AWS环境的企业，都将是有益的。

一、选择满足需求的VPC配置

VPC 是网络架构的基础。设计一个良好的VPC网络架构需要考虑子网、互联网网关、NAT网关、虚拟私有网关、对等连接、VPC终端节点等等的合理配置与安全管理，并要满足具体业务的需求。尽管已经有了更改VPC大小的手段，但考虑到VPC的复杂性以及对于系统的重要程度，强烈建议在规划VPC的时候，建议根据至少两年后的扩展需求来设计Amazon VPC的具体实施。

今天，当我们在AWS 管理控制台的“Amazon VPC”页面并选择“启动 VPC 向导”时，
您将会看到用于网络架构的四个基本选项：

1. 仅带有一个公有子网的 Amazon VPC
2. 带有公有和私有子网的 Amazon VPC
3. 带有公有和私有子网以及提供 AWS 站点到站点 VPN 访问的 Amazon VPC
4. 仅带有一个私有子网以及提供 AWS 站点到站点 VPN 访问的 Amazon VPC

我们要仔细的考虑之后再去选择最适合当前和将来要求的配置。

 

二、为VPC选择恰当的CIDR块

在设计Amazon VPC实例时，您必须考虑所需的IP地址数量以及与数据中心的连接类型，然后再选择CIDR块，其中包括 RFC 1918 或公有可路由 IP 范围。到目前为止，我们还无法更改或修改Amazon VPC设定的CIDR，因此最好选择具有更多IP地址的CIDR块。此外，在设计混合架构实现Amazon VPC与本地数据中心通信时，务必确保Amazon VPC中使用的CIDR范围不重叠或不会与本地数据中心中的CIDR块发生冲突。对于更改VPC大小的需求，可以通过向现有 VPC 添加4个辅助 IPv4 CIDR 来扩展 VPC。还可以通过删除已添加到 VPC 的辅助 CIDR 块来缩小 VPC。但是不能更改 VPC 的 IPv6 地址范围的大小。

 

三、隔离VPC环境

本地环境中存在的物理隔离也应该是云环境实践的一个重要原则。许多最佳实践表明，最好为开发、生产和预发布(Staging)创建一个独立的Amazon VPC。有许多人习惯在一个VPC中管理预发布、生产和开发等环境，不过管理之这样具有不同安全性/子网/隔离权重的Amazon VPC其难度之大时可想而知的。相比之下，我更建议为不同的环境使用独立的VPC。

 

四、增强对AWS VPC的保护

运行具有关键任务工作负载的系统需要多个层次的安全性。通过遵循以下一些有用的方法，可以有效的保护Amazon VPC：

• AWS WAF 是一种 Web 应用程序防火墙，可帮助保护部署在VPC上的Web 应用程序或 API 免遭常见 Web 漏洞的攻击，这些漏洞可能会影响可用性、损害安全性或消耗过多的资源。

• Amazon Web Services Marketplace提供了第三方提供的Web应用程序防火墙、防火墙以及可用于保护Amazon VPC的其他一些工具。
• 为了防止未经授权使用或入侵网络，可以配置入侵检测系统（IDS）和入侵防御系统（IPS）。
• 借助“ 配置特权身份”访问管理，可以审核和监视管理员对VPC的访问。
• 为了在不同区域之间的Amazon VPC之间或在Amazon VPC之间安全地将信息传输到本地数据中心，可以配置Site-to-Site VPN。
• 安全传输信息的另一种选择是将AWS Transfer用于安全的文件（AWS SFTP）。借助AWS SFTP，可以使用VPC终端节点，并避免使用公共IP地址或通过互联网。此外，AWS SFTP的VPC终端节点通过AWS PrivateLink利用安全功能，该功能在VPC和AWS服务之间提供专用连接。

五、理解VPC上的网络防火墙 – 安全组

AWS通过“安全组”提供了一种虚拟防火墙功能，可在实例级别控制入站和出站的数据流。但是管理AWS网络安全的方式与传统网络防火墙的使用方式有所不同。AWS防火墙的中心组件是“安全组”，基本上是其他防火墙供应商称为策略（或者规则的集合）的组。但是，需要了解安全组和传统防火墙策略之间的关键区别。

首先，在AWS中，安全组的规则中没有特定的“操作”来声明流量是允许还是丢弃。这是因为与传统的防火墙规则不同，AWS安全组中的规则缺省都是允许的的。

第二，AWS安全组规则可以指定流量来源或流量目的地，但不能在同一规则上同时指定两者。对于入站规则，有一个来源可以说明流量的来源，但没有目的地告诉流量该去向。对于出站规则，反之亦然：我们可以设定目标，但不能指定源。这样做的原因是，AWS安全组始终将未指定的一面（源或目的地）设置为使用该安全组的EC2实例。

AWS在允许应用这些安全组规则方面非常灵活。可以将传统安全策略应用于多个防火墙的方式相同，我们可以将单个安全组应用于多个实例。AWS还允许执行与之相反的操作 – 将多个安全组应用于单个EC2实例，这意味着该实例从与其关联的所有安全组中继承规则。这是AWS独特功能之一，使我们可以为特定功能或操作系统创建安全组，然后对其进行混合和匹配以适应业务需求。

六、如无需要，请勿打开0.0.0.0/0（::/0）

通过在安全组中开放0.0.0.0/0（IPv6下为::/0）的端口来允许VPC中的实例是很多专业人员在配置安全组时最常见错误。用户最终打开了他们的云网络，并将其云资源和数据暴露于外部威胁。制定安全组中的策略时需要遵循“最小权限原则”（POLP），仅开放所需的端口，而不是为了简化管理而此让网络暴露在威胁之下。

同样，我们还要关闭不必要的系统端口。

 

七、启用和配置VPC流日志

我们现在可以为VPC或子网或网络接口（ENI）级别启用AWS VPC流日志，可以捕获有关传入和传出 VPC 中网络接口的 IP 流量的信息。我们通常可以将AWS VPC流日志配置为捕获流经EC2、ELB和一些其他服务的ENI和安全组的接受和拒绝条目。通过扫描这些VPC流日志的条目，用以检测攻击模式，警告VPC内部异常活动和信息流。

我们不必担心VPC流日志对于生产环境网络的影响，流日志数据的收集是在VPC网络流量路径之外，因此不会影响网络吞吐量或延迟。

八、用好VPC对等 （VPC Peering）

VPC 对等连接是两个 VPC 之间的网络连接，通过此连接，您可以使用私有 IPv4 地址或 IPv6 地址在两个 VPC 之间路由流量。这两个 VPC 中的实例可以彼此通信，就像它们在同一网络中一样。

AWS 使用 VPC 的现有基础设施来创建 VPC 对等连接；该连接既不是网关也不是 VPN 连接，并且不依赖某一单独的物理硬件。没有单点通信故障也没有带宽瓶颈。

从安全性上来说，VPC对等的网络流量保留在私有 IP 空间中。所有区域间流量都经过加密，没有单点故障或带宽瓶颈。流量一直处于全球 AWS 骨干网中，不会经过公共 Internet，这样可以减少面临的威胁，例如常见漏洞和 DDoS 攻击。通常，VPC对等可满足许多需求，例如：

• 互连的应用程序需要在AWS内部进行私有和安全访问。通常，这可能发生在在单个区域中运行多个VPC的大型企业中
• 系统已由某些业务部门部署在不同的AWS账户中，并且需要共享或私有使用。某些大型组织为各个业务部门，部门和/或团队拥有不同的AWS账户，并且各组之间的通信需求也有所不同。
• 更好的系统集成访问，例如客户可以将其VPC与核心供应商的VPC对等

九、最廉价的安全工具– 标签(Tag)！

没看错，我说的就是“标签”。 在VPC中对资源的标记非常重要。 我们可以，并非常希望这样做，使用标记策略来有效地组织用于管理、报告、分析的的资源。 对于大型的复杂的网络基础设施，我们的管理会有很多角度，对安全问题尤其如此。 考虑到这一点，请通过使用任何标记策略来保持最佳做法，并在变化时及时进行修改。 当我们的采用越来越多自动化的工具的时候，你会意识到一个良好的标签设计将会为VPC的安全性、可管理性起到何种重要的作用。

 

十、将安全性集成到DevOps中

无可否认，云计算是一个全新的领域，云计算的安全面临的风险与挑战与日俱增。市场上没有足够的安全计算安全专家，企业也很难找到精通最新云计算技术的专业人员。即使团队雇用了优秀的安全人员，那些可以编写代码的人员也经常被用于开发而不是安全管理。

一个好的经验是，无论企业是否拥有安全运营中心（SOC）或者信息安全（Infosec）专家，都可以使实现安全。在现代化的组织中，安全性不仅应由安全专家或者SecOps团队负责，而应该是整个团队、自上到下的共同努力的目标。请记住这一点，团队中的工具和流程越好，所需的安全专家就越少。我的建议是：

• 建立具有安全性的DevOps文化，可以概括为“提高组织的安全文化”
• 全员进行安全培训。安全是每个人的工作—不仅仅是那些工作头衔上有安全的人的工作。
• 在企业中确立“人+责任 = 安全”的意识