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

祖师爷的话


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


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


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


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


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


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

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


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


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


几个名词


经典网络(基础网络):所有云上租户处于同一个资源池,“原则上”租户之间是可以互相访问,这类似青年旅舍的大通铺。

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

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


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


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


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


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


阿里云的安全组功能与AWS类似经典网络环境下的实例启动时必须给实例指定安全组安全组默认阻止所有内网间的访问不同租户间默认无法互相访问。


云上安全组TIPS


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

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

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

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

第五,不要把所有实例放到一个安全组里边,都挤一起会乱糟糟。

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

第七,没有第七了。


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

相关文章
相关标签/搜索