落实云端原生防护4C 纵深防御多层式力抗侵骇

云端原生运算是一种在云端内建构及执行可扩充式应用程式的软体开发方法,不论在公有云、私有云、企业内或混合云等环境,其结合了开放原始码与非开放原始码两种软体来部署应用程式,例如包装在个别容器中的微服务(Microservice)即是一例。

容器(如Docker容器)会将所有必要的软体和应用程式包装到隔离独立的处理程序内部。由于企业经常跨多台主机执行多个容器,因此还需要使用Kubernetes这类的容器协调系统,并透过持续整合∕持续交付(CI/CD)工具,遵循DevOps方法来管理和部署。最终,云端原生技术将使企业彻底发挥云端资源的效益,不仅能减轻负担、加快反应速度,而且管理起来也更轻松。

如同任何仰赖各种环环相扣的工具与平台的技术一样,云端原生运算环境的资安扮演着相当重要的角色。如果有什么是资安专家们一致认同的看法,那就是「今日没有任何现代化的复杂软体系统是『完全无法骇入』的,没有百分之百无法被渗透的系统、装置或环境。」也因此,才会衍生出一种所谓「纵深防御」的资安防御方法,这是一个从军事领域借用到网路资安领域的概念。

纵深防御的方法采用多层式控管,在企业内各个不同环节设置资安屏障来提供多重保障,以防万一某个环节失效或遭骇,还有其他环节可提供保护。云端原生防护就是采用这样的方式,如图1所示,将云端原生系统的防护策略划分成「云端原生防护4C」的四个不同层次。

虽然在每一个层次都设置资安控管相当重要,但由于每一层都是歹徒可利用的攻击面,且各层的防护又独立运作,所以应用程式还是可能遭到攻击。例如,当一个不安全的网站应用程式遭遇SQL资料隐码攻击(SQL Injection)时,除非使用了某种特殊功能的第三方软体,否则图1当中的其他防护层也无法发挥保护作用。

网路资安攻防的防御者,必须尽可能涵盖每一种可能的情况,尽量让系统防护面面俱到。虽然这听起来很难,但还是必须做到,因为有时骇客只须找到一个破口,就能入侵整个系统。以下将详细探讨云端原生系统的每一层最常出现的资安问题,并提供侦测及防范的秘诀。

云端防护

「云端」这一层,指的是伺服器执行时的底层基础架构。要在所选定的云端服务供应商(CSP)环境建立一台伺服器,将牵涉到许多不同服务,如图2所示。尽管这些服务(如作业系统、平台管理、网路组态)的安全责任绝大部分该由CSP来承担,但客户仍有责任检查并设好这些服务的组态设定,并且小心看守及保护自己的资料。企业在决定将企业内的运算资源和服务移转到云端时,很重要的一点就是要了解并且妥善运用这种共同分担资安责任的模式。

接下来,说明今日云端系统最常见的问题:

组态设定错误

随着各种云端架构组成元件的数量不断增加,预估组态设定错误的情况也会跟着增加。虽然组态设定错误通常只是使用者的疏忽或无心之过,然而这却是网路犯罪集团经常利用的弱点,并可能为企业带来庞大的财务甚至名誉损失。

组态设定错误的问题可说相当常见,其中一起案例就是,骇客藉由特斯拉(Tesla)公司Kubernetes系统管理主控台的组态设定错误,植入挖矿程式。许多服务和应用程式在建立时都使用预设的设定值,因此暴露在网际网路上。这让伺机而动的许多僵尸病毒和骇客变得有机可乘。骇客会攻击暴露在网路上的Redis执行个体,发动远端程式码执行(RCE)攻击,或者将它们变成虚拟加密货币挖矿僵尸。

自动化

自动化可以加快建立新系统与部署新应用程式的速度,但是如果没有经过仔细的检查或监督,也可能让错误和资安问题扩散得更快。除了威胁之外,威胁在不安全的连网系统或装置上的入侵速度也是另一项值得忧心的。根据一项研究发现,骇客只需52秒的时间就能扫描并骇入研究人员设置在诱捕网路中的不安全装置。因此,企业必须适当且有效地保护其架构的各个面向。

企业若能确实遵照云端厂商的建议,定期执行稽核并确保一切设定都正确之后再部署到对外开放的生产环境,就能避免遭遇上述的问题。采用基础架构即程式码(Infrastructure-as-a-Code,IaC)是确保系统正确建立、正确设定组态的一项有效方法。IaC透过程式码将IT架构的正确配置自动化,如此就不必依赖DevOps工程师手动执行这项作业,进而减少人为疏失,只须遵循最佳实务原则即可。此外,像Terraform、Ansible和CloudFormation这类的工具,可定义基础架构的基准设定(包括防护设定),因此算是很方便的工具。除此之外,此类工具还可确保设定不会遭到非经授权的变更。

IaC未来将成为建构云端环境的新常态,它能让企业善用不同程度的自动化与部署的速度。今日,企业已经无须手动启动或设定伺服器,自动化已是云端架构安全的关键。

除此之外,也请务必遵照CSP的资安建议,详情请参考以下各家主流CSP的资安最佳实务原则:

‧Amazon Web Services:https://aws.amazon.com/security/

‧Google Cloud Platform:https://cloud.google.com/security/

‧Microsoft Azure:https://docs.microsoft.com/en-us/azure/security/azure-security

除此之外,一些可提供云端基础架构可视性并将防护与法规遵循检查自动化的解决方案,如Trend Micro Cloud One – Conformity,也能让这一层的防护简化及最佳化。

丛集防护

丛集防护的讨论重点主要是Kubernetes,因为它是今日最普遍使用的容器协调工具。不过,此处讨论的资安原则同样也适用于其他同类型的产品。关于丛集,企业最需要关注的有三点:

丛集元件

首先,要保护丛集的构成元件,对Kubernetes来说就是主要节点(Master Node)。丛集防护最重要的就是管控API伺服器的存取与限制「etcd」(也就是Kubernetes主要资料储存区)的直接存取等等。Kubernetes有一套完整的文件来说明如何防止丛集遭到意外或恶意的存取。趋势科技在一篇文章(https://t.rend.tw/?i=OTI5NA)提到,发现有3,000台主机的「etcd」公开暴露在网路上。为了避免这样的情况发生,建议云端系统管理员应该预设它禁止存取,仅允许经过核准的流量。除非拥有充足的人力或制定了严格的规范,否则建议采用Azure Kubernetes Service(AKS)、Elastic Kubernetes Service(EKS)或Google Kubernetes Engine(GKE)之类的丛集托管服务。

图1 云端原生防护4C。
丛集服务

其次,要藉由正确的组态设定与存取控管来保护丛集上执行的服务。为了这些服务的安全,Kubernetes建议应采取一些必要的防护措施,例如资源管理,还有以最低的权限来执行服务。请务必为自身的丛集设定适当的认证与授权机制,利用Transport Layer Security(TLS)将流量加密,并使用Kubernetes Secret来保护敏感资料。另外,也建议参考一下Center for Internet(CIS)Kubernetes评测来了解有关保护丛集服务的更多技术细节。

丛集网路

最后一点是要正确配置连接埠来支援容器、工作负载群组(Pod)与服务之间的通讯。使用一个容器网路介面(CNI)让使用者限制工作负载群组的流量,以确保Kubernetes网路模型的安全建置非常重要。趋势科技在Kubernetes威胁模型指南一文当中提供了更多有关保护容器协调平台的详细建议,有兴趣的人可于趋势科技官网搜寻阅读。

容器防护

丛集内的容器要能执行,需要一个称为「容器运行引擎」(Container Runtime Engine,CRE)的元件。尽管Docker是目前最流行的CRE,但Kubernetes也支援其他CRE,如containerd和CRI-O。在容器防护层次,企业要关心的主要有三个重点:

容器映像安不安全?

这一点基本上就是要确保容器随时维持更新、没有任何骇客可攻击的重大漏洞。企业不仅要保护容器映像,还要确定容器内执行的应用程式都经过扫描及确认。虽然网路上有一些开放原始码工具可以做到这点,但有些工具只能侦测作业系统的漏洞。要弥补这点,企业可采用一些能广泛侦测各种应用程式漏洞的解决方案,例如Deep Security Smart Check。

容器是否可信赖?

目前系统上执行的容器是否是从自己的容器映像登录档(Registry)中产生?如何确保这一点?可利用一些映像签署工具(如TUF或Notary)来签署自身的映像,建立一套系统来维护你对容器的信赖。

容器执行权限是否恰当?

针对这点,可采取最低授权原则(能不开放的权限就不开放)。尽量以执行工作时所需的最低必要作业系统权限的使用者身分来执行自身的容器。如果想了解为什么最好不要在Docker中执行特权容器以及骇客可能如何利用特权容器发动攻击,可以至趋势科技「资安趋势部落格」搜寻「为何在Docker中执行特权容器不是个好主意?」以获得进一步的了解。

程式码防护

这一层防护又称为应用程式防护,是企业最能掌控的一层。企业系统的主要核心就是系统程式码以及相关的资料库,而这些通常会暴露于网际网路上。所以,如果其他环节都找不到漏洞,那么骇客就会以这一层为目标。当企业每天都有数十、数百、甚至数千名程式设计师在撰写并部署程式码到生产环境时,企业如何确保自己的应用程式码都正确无误、安全无虞?

图2 云端防护。
首先,企业必须确保所有通讯都经过TLS加密,即使是在负载平衡器、应用程式伺服器、资料库等这类内部服务中传递也一样。若企业使用了Kubernetes之类的协调工具,那么可考虑采用类似Istio或Linkerd的服务。

企业只须尽量减少并监控暴露在外的服务、连接埠与API端点装置,就能大幅减少其系统的受攻击面。此外,同样重要的还有所使用的容器基础映像,以及执行丛集的系统。

可在开发流程当中加入各种程式码安全检查来确保自身程式码的安全性,例如以下几种:

静态应用程式安全分析

也就是「安全程式码分析」或「程式码稽核」,这仍是目前发掘程式码资安漏洞最快也最有效的方法之一。不论使用的是何种程式语言,至少要在开发流程当中加入一种静态分析工具,以便在开发人员送出新完成的程式码时检查是否有一些不安全的程式写法。开放网站应用程式安全计画(Open Web Application Security Project,简称OWASP)基金会制作了一份开放原始码工具与商用工具清单,里面介绍了各种专门用来分析原始程式码与编译后程式码的工具,协助侦测程式码的安全漏洞,也可以参考。

动态应用程式安全分析

虽然动态分析只能在应用程式执行时进行,但建议企业还是应该透过自动化的扫描与检查来测试一些常见的应用程式攻击手法,例如SQL资料隐码攻击(SQL Injection)、跨网站脚本攻击(XSS )以及跨站请求伪造(CSRF)。这些工具还可测试你的应用程式、容器与丛集在面对一系列非预期性的负载或不正确的请求时是否会无法招架。OWASP也提供了一个叫做OWASP Zed Attack Proxy(ZAP)的工具,可加入开发流程中进行自动化动态分析。

软体构成元件分析

约有70%至90%的云端原生应用程式是由程式库或第三方元件所构成。这些程式码有的可能不是内部人员所撰写,但却会在生产环境中执行,它们通常不会做过静态安全分析,因此可以利用OWASP相依性检查之类的工具来检查自身的程式码当中是否含有老旧或含有漏洞的程式库。此外,还有Snyk这个针对开放原始码专案设计的第三方免费程式码检查工具。

结语

以上云端原生系统的四个层次都是确保应用程式安全的重要关键,不论是哪一层的安全漏通,都会让骇客有机会入侵整个系统。确保云端原生系统的安全稳定,是将企业维持生产力的关键,而这最终将是企业生存的基础。采用专为云端设计的资安解决方案将有助于维护云端原生系统及各层次的安全,举例来说,趋势科技混合云防护是以Trend Micro Cloud One防护服务平台为基础,能为CI/CD流程及应用程式提供自动化防护,此外,也有助于提早发掘及解决资安问题,加速DevOps团队的应用程式交付时程。

Author: bwg