安全组的配置，要牢记祖师爷的话

祖师爷的话

正所谓家有家法，行有行规。

鸡鸣灯灭不摸金，各路摸金校尉自打入行就把这规矩铭刻在心，行走江湖从无半点懈怠。

安全行业亦是如此，菜鸟入门时老司机都会反复强调安全领域的黄金法则---最小权限原则，即SbD（Secure by Default）或POLP(principle of least privilege)。

最小权限这条原则朴素简单易记，大伙从字面都能理解其意义，但同时它也是万千企业安全管理的滑铁卢，看看前段时间的Redis漏洞以及被勒索软件利用的MongoDB漏洞，其实它们都是违背最小权限原则的反面典型。

那最小权限原则都有哪些典型的应用场景？

审计部小刘的门禁卡只能刷开公司大门和审计部办公室，他到不了其他办公区域。

酒店客户进入电梯后只能通过刷自己房卡到达入住楼层，房卡只能进入自己房间。

这条原则在安全领域也孕育了最大的市场之一--防火墙市场，防火墙其实就是帮助用户实现最小权限的手段之一。

为什么要聊这个话题，最近安全圈又因为云上最小权限的事儿闹得沸沸扬扬，笔者也借这个机会好好捋捋用户上云的最小权限策略。

几个名词

经典网络（基础网络）：所有云上租户同处一个大内网，“原则上”租户之间可以互相访问，就如同一路由器下所有设备都是互通一样，但CSP为了安全，通过防火墙对租户进行了隔离。

VPC（私有网络／专有网络）：利用SDN技术进行二层网络逻辑隔离，租户可以自定义网络拓扑和IP，这类似酒店模式，每个房间默认都是隔离开的。

安全组：这个概念源自AWS，功能类似虚拟防火墙，它是不同实例所关联的一系列获得允许的in&out规则，基础网络和VPC环境下都包含安全组功能。

经典网络的最小权限实现需要依赖虚拟防火墙，而VPC则是通过类似MPLS VPN等底层技术来实现逻辑隔离，相比较而言，后者更灵活简便，新上云用户建议选用后者。

目前来看大多数CSP在云安全领域的策略基本是一致的。

AWS在VPC环境下创建的实例会默认关联至某安全组，而安全组默认策略是in方向上仅允许同一安全组的实例，out方向不做限制。在经典网络环境下只能在创建实例时配置安全组，安全组会跟特定region关联，这也意味着安全组只能关联同一region下的实例。

微软Azure的NSG基本功能与AWS的安全组类似，但它多了层次结构，NSG可应用给虚拟机、子网，或同时应用给两者。

阿里云的安全组功能也与AWS类似，经典网络环境下的实例启动时必须给实例指定安全组，安全组默认阻止所有内网间的访问，不同租户间默认无法互相访问。但从测试结果看，租户间的部分访问仍然存在，估计部分原因是用户配置了0.0.0.0/0的规则，这也是当下阿里云正加快推进VPC网络建设并引导用户虚拟机迁移的动力所在。

预计再过段时间，所有的CSP都将告别经典网络，云租户安全隔离迎来VPC时代。

云上安全组TIPS

第一，一定要遵循最小权限原则，别使用0.0.0.0/0的规则，不该映射的端口别放出去。

第二，将安全组作为白名单使用，默认是Deny ALL。

第三，新上云用户请优先考虑VPC网络，专网专用。

第四，建议经典网络场景，用户对"内网入方向"安全组规则最好使用"安全组访问"授权，避免开放0.0.0.0/0 或10.0.0.0/8网段的CIDR授权方式。

第五，慎重增加安全组，无论是新增实例还是新增访问需求，不然你会累趴。

第六， 按照应用的层级规划分配安全组，不同安全组之间利用"安全组访问"方式授信，不要把所有实例放到一个安全组里边，都挤一起会乱糟糟。

第七，不要把生产环境和开发环境塞进同一个VPC。

第八，没有第八了。

最后想问，安全行业的祖师爷应该是谁？