介绍
DigitalOcean Cloud Firewall提供了一个中心位置,可防止未经授权的流量到达您的Droplet,易于配置,快速应用和自动化友好。 不过,组织基础架构可能很棘手。 一方面,如果您开始在没有计划的情况下创建防火墙,则可以使用几十种不太有意义的防火墙。 另一方面,过度复杂的规划可能导致分析瘫痪。
在本文中,我们将探讨组织云防火墙的初始策略,使其更易于使用和维护,并记录基础结构中的关系。
按角色拆分
要开始使用,我们将根据其规则提供的角色构建Cloud Firewall。
例如,如果我们有一个单一的Web应用程序,比如一个Droplet命名的website
运行一个PHP应用程序与本地的MySQL数据库,有两个不同的角色需要实现:
- Web服务器 - 这个面向公众的角色是Droplet的主要目的,Droplet向公众提供网页。
- 管理 - 管理角色允许管理员进行特权访问来维护服务器并部署应用程序。
我们可以有一个单一的云防火墙,具有允许这两个作业的规则,对于小型部署,它可以正常工作。 但是,如果我们期待将来扩展应用程序,我们现在可以分离这些问题,并创建两个不同的防火墙:
-
webserver-fw
:打开TCP端口80(如果允许未加密流量)和443(如果我们使用SSL))到所有源。 -
management-fw
:打开TCP端口22(SSH)到所有源。 如果我们想要限制我们办公室中特定位置,如IP范围的访问,那么我们还将在这个规则的来源中补充说。
以这种方式分离防火墙指示哪些访问权限用于管理员,哪些用于最终用户交互。 这些名称帮助记录系统,当不太熟悉其细节的人员需要加入时,这是非常有用的。当我们的基础设施变得更加复杂时,它变得更加有用。
随着应用程序的发展,我们可能希望跨多个服务器分割工作负载。 例如,通常将Web服务器和数据库分开,将每个数据库放在自己的Droplet上。 当我们进行这样的改变时,我们可以改变我们的防火墙策略如下:
- 维护
management-fw
无任何变化。 我们仍然需要使用SSH进行管理任务。 -
webserver-fw
维护webserver-fw
。 它的功能还是一样的。 - 创建名为
database-fw
的新云防火墙,其规则是打开源端Dropletwebsite
TCP端口3306 - MySQL的默认值。 - 将
database-fw
和management-fw
到新的Droplet。 管理员将能够进行工作,只允许website
服务器访问数据库端口。
我们的初始组织允许我们避免对先前创建的云防火墙进行更改,重用其中一个,清楚地指出在新database
Droplet上使用的服务,并通过添加严格要求的方式打开对每个服务器的访问。
使用标签
到目前为止,我们已经讨论了一个可以由一个或两个Droplet提供的小型应用程序,并且我们已经通过使用Droplet名称应用了防火墙。 当我们的流量增长,我们准备扩大规模时,使用Droplet名称就会变得笨拙。
我们可以选择保持我们的双服务器体系结构,并通过加强内存或处理能力的服务器来垂直扩展,以便跟上请求,但这并不会改变每一个仍然是单点故障的事实。 因为我们在云端工作,所以我们更倾向于在多个冗余服务器之间分配流量。 在这一点上,我们将需要开始使用工具和实践,使我们能够将Droplets视为可互换的资源。 云移动的这个转变在云端被称为“宠物与牛” ,并与配置管理工具(如可复制,Chef和Puppet)紧密相连。
当我们开始将我们的“Droplet”视为一组冗余,可互换的资源时,我们需要以团队为基础的方式与他们合作。 DigitalOcean促进使用标签进行基于组的管理,这些标签是我们附加到Droplets的文本标签,以对其进行分类。 一旦我们标记了Droplets,我们使用这些标签来创建其他DigitalOcean资源(如负载平衡器和云端防火墙)之间的关系。
在我们的例子中,我们可以创建两个标签, webserver
和database
,并在每个Droplet中添加适当的标签。 当我们这样做时,我们还会将“Droplet”重新命名为website-01
和database-01
,将其明确标示为可部署的部署。 然后,我们将更改我们的Cloud Firewall,如下所示:
-
management-fw
:将webserver
和database
标签添加到它们,并删除与特定Droplet名称的关联。 -
webserver-fw
:添加webserver
标签并删除website-01
Droplet -
database-fw
:添加database
标签并删除database-01
Droplet。 将TCP 3306规则上的源从命名的Droplet更改为使用标记webserver
。
随着这个标签的转变,每个Cloud Firewall的规则将被应用到任何标有这些标签的Droplet。 那里有几滴水就没关系。 如果我们要推出几个新的网络服务器Droplet,如website-02
和website-03
,他们将自动从webserver-fw
获取规则, webserver-fw
授予访问应用了database-fw
任何Droplet。 这样,我们可以专注于在云端防火墙处理安全控制时向上或向下缩放应用程序。
上述过程可以扩展到更复杂的应用程序。 例如,如果我们有一个子系统来排队请求或一组作为流程工作者的服务器,我们可以分别将它们标记为queue
和workers
,应用它们特有的防火墙规则,并分享诸如management-fw
类的常见方面。
使用标签来组织和记录我们的基础设施,澄清不同Droplet之间的关系,并使其更容易批量管理。 我们不限于每个Droplet的单个标签,因此我们可以应用其他标签来帮助自动化或记录流程。
命名
我们使用webserver
和management
作为Cloud Firewall名称的通用示例。 你应该使用对你和你的团队的具体上下文有意义的名字。 也许deployment
更management
。 如果是这样,请使用deployment
。
我们还在防火墙名称的末尾添加 - 在没有用户界面区分项目的情况下识别资源。 假设,例如,您有一个名为webserver
的Droplet, webserver
包含一个webserver
标签和一个名为webserver
的防火墙。 当你解析命令行工具的输出,如doctl ,哪个是? 在控制面板UI中通常会显示,但在其他情况下可能不是这种情况,因此使用命名策略进行区分可以增加清晰度和简化脚本。
结论
在本指南中,我们就如何命名和定义云端防火墙的范围提出了建议,以帮助您组织您的基础架构并使其更容易理解。 随着应用程序的变化和发展,您的经验随之发展,您可能会发现一种方法来组织您的防火墙,使您的具体用例更好。 当这种情况发生时,适应你学到的东西,你会更有成效。 考虑到这些组织策略,您已准备好创建您的第一个DigitalOcean Cloud Firewall 。