开发者学堂课程【容器安全与 Palo Alto Networks 解决方案 ：容器的安全挑战及安全准则 NIST 800-190】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/628/detail/9875
容器的安全挑战及安全准则 NIST 800-190
目录：
一、云原生系统的特点
二、最近针对容器的 Graboid 蠕虫病毒爆发
三、容器服务客户的安全责任举例
四、NIST SP 800-190 应用程序容器安全指南
一、云原生系统的特点
容器化
改善整体开发，人员体验，促进代码和组件的重复使用，并简化云原生应用程序的运行操作.
动态化管理
极大地提高了机器效率和资源利用率，同时降低了维护和运营的成本
面向微服务
大大提高了应用程序的整体灵活性和可维护性
云原生环境的安全挑战
超大规模
大型网络应用需要部署两百万个容器。手动为每个实体创建和维护安全规则的旧方法对于保护如此大规模的部署是不切实际的。
快速变化
部署周期已从每季度一个发布缩短到每天几个发布。在每个发行版中，应用程序都可能进行细微更改，保护它们的安全规则需要跟得上这些变化。
生命周期
安全不再仅仅是单个团队或个人的职责范围。必须将其纳入持续的软件构建和部署自动化流程中。建立"质量”门，让安全团队注入安全规则的传统方法会阻塞软件构件和的自动化流程。
第一讲容器的安全挑战及安全准则 NIST 800-190。要想了解容器特有的安全挑战，简单回顾一下七个云原生环境的特点。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API、
容器化，可以改善整开发人员体验促进、代码和组件的重复使用。并简化云员生应用程序的运行操作。
动态化管理，极大的提高了机器效率和资源利用率。同时降低了维护和运营的成本。
面向微服务，大大提高了应用程序的整体灵活性和可维护性。
传统的网络安全部署是根据用户应用即IP地址和端口，人为设置安全规则。这样的传统方法，在容器环境下，变得无法实施。
第一个挑战是规模，大型网络应用，可能需要部署两百万个容器。手动为每个实体创建和维护安全规则对于保护如此大规模的部署是不切实际的。
第二个挑战，是环境的快速变化，传统的应用版本更新频率通常是一年一次。频繁的可能是一个季度一次。容器环境下基于微服务的应用部署周期，每天。可能发布几个版本是很常见的。在每个发行版中，应用程序都可能进行细微的更改。保护他们的安全规则，要跟得上这样频繁的变化不是容易的事。
第三个挑战，是安全不再仅仅是单个团队或个人的事。而是要从应用的生命周期来考虑。必须将安全纳入持续的软件构建和部署的自动化流程中。建立“质量”门，让安全团队注入安全规则的传统方法。会阻塞软件构件和的自动化流程。
二、最近针对容器的 Graboid 蠕虫病毒爆发
首次在 Docker Engine (社区版)中发现借助容器传播的加密挖矿蠕虫病毒
2000多台 Docker 主机因保护不力而受到感染2,034个易受攻击的主机-57.4%的 IP地址来自中国。
容器安全的普及，属于起步阶段。还存在着很多认识的缺失。正是由于上述这些挑战。在很多容器环境中缺乏有效的针对容器环境的安全部署。Docker worm 是目前最流行的容器开发工具,在百度搜索中输入 Docker worm，就会发现 Docker worm 是2019年10月，由安全专家发现的 Docker worm 蠕虫攻击。
这是首次在 Docker Engine 中发现借主助容器传播的加密挖矿蠕虫病毒。有两千多台主机，因不利而受感染，由于大多数传统端点保护软件都不会检查容器中的资源及动作。因此，这种恶意的动作难以被发现。2034个易受攻击的主机中，居然有57.4%的 IP 地址来自国内。可以看到国内的容器安全形式不容乐观。
如何才能有效保护容器环境，免受攻击呢，公有云的厂商都在安全上下了很大的功夫，也不断推出新的安全产品，如果把容器部署在一家安全做得好的公有云上是否就可以高枕无忧了。实际的情况。是不是这样呢？要想回答这个问题。使用公有云。安全职责是怎么划分的
发表在2019年阿里云安全白皮书中的阿里云安全责任共担，基于阿里云的客户应用，其安全责任由双方共担阿里云确保云服务平台的安全性，客户负责基于阿里云服务构建的应用系统的安全。阿里云负责基础设施物理设备，飞天分布是云操作系统及之上的各种云服务产品的安全控制管理和运营，为客户提供云盾安全服务，保护客户的应用系统。
客户负责以安全的方式配置和使用云服务器 ECS，数据库 RDS，及其他云产品，基于这些云产品。，以安全可控的方式，构建自己的应用，客户可选择使用云盾安全服务或者阿里云安全生态里第三方安全厂商的安全产品。
为其应用系统，提供安全防护，也就是说阿里云负责设施平台的安全，并提供安全设置工具，用户要对自己的配置、应用数据负责。如果对自己的云资源设置不当。比如说将密匙保管不当，或者对前面提到的蠕虫攻击，没有部署防范手段，就公有云厂商安全做得再好也无法保证用户不受攻击。
对于容器环境，公有云厂商的责任会包括，平台和应用的管理。用户还是要对自己的配置、应用和数据负责。如果用户的应用构建在有严重漏洞的基础影像上，或者对生产环境缺乏持续的漏洞监控，没有手段，监控应用之间的访问是否正常，对挖矿蠕虫攻击，没有识别的手段。在应用中嵌入了密室，这些都会对用户的容器环境造成严重的安全隐患。
三、容器服务客户的安全责任举例
控制镜像的来源
应用开发部署生命周期中持续的镜像漏洞扫描
现有镜像存在已知漏洞及其严重性
容器生产环境中的漏洞持续监控
那些存在漏洞的容器需要优先修复
特权容器有权访问主机操作系统，了解和控制特权容器的使用
了解和控制应用服务暴露在集群之外的容器
了解所有容器中运行的进程是否正常
了解所有容器中网络访问是否正常
了解所有容器中系统调用是否正常字了解所有容器中文件访问是否正常
甄别和阻断恶意容器攻击
对容器应用服务进行合规性的检查和监控
一些容器服务涉及到用户安全责任的例子
控制镜像的来源，是用户的责任，如何能建立机制让应用的开发、集成部署运行的生命周期中只使用可靠的来源呢？
用户有责任在应用的生命周期中持续的进行镜像漏洞扫描，漏洞发现是不断更新的。昨天安全的镜像可能今天就会因为新发现的漏洞，而成为骇客攻击的目标。用户有责任了解现有镜像存在的已知漏洞极其严重性，以制定修复优先次序，用户有责任监控和管理生产环境。包括容器漏洞持续监控，修复存在漏洞的容器。
特权容器有权访问主机操作系统，用户有责任了解和控制特权容器的使用。以防止骇客通过容器攻击主机。用户有责任了解和控制应用服务暴露在集群之外的容器。这些容器最容易受到轰击，用户有责任了解运行时中所有的容器。行为是否正常？运行的进程是否正常？网络访问是否正常？系统调用是否正常？文件访问是否正常？用户有责任对不正常的行为设置规则警告还是阻断。用户有责任甄别阻断恶意容器攻击，用户有责任对容器应用服务进行合规性的检查和监控。
容器环境位于原生应用的开发、集成、部署提供了灵活高效的架构。而保护容器环境免受骇客攻击并不容易。
四、NIST SP 800-190 应用程序容器安全指南
美国国家标准技术研究所(NIST)发布联邦政府使用的指南
联邦政府部门需要在 NIST 安全指南发布一年之内遵照执行
NIST 安全标准是工业界参考的最佳实践
NIST SP 800-190是业界为数不多的容器安全标准之一
NIST 800-190从以下方面描述了容器化应用程序可能的面临的安全风险和应对措施
镜像
镜像仓库
编排工具
容器
主机
由于在业界的声誉，Twistlock 的联合创始人 John Morello 被邀请
撰写
NISTSP 800-190 应用容器安全标准
容器核心部件中可能存在的安全隐患
镜像
漏洞，配置缺失，潜藏的恶意程序，嵌入的明码密匙，不可靠来源的镜像
镜像仓库
过时的镜像，不安全的访问链接，不充足的认证和授权限制
编排工具
不设限制的管理员权限，未授权访问，容器之间的访问缺乏隔离和控制，不同敏感级别的应用混合部署，编排工具设置缺失
容器运行时
运行时软件漏洞，缺省允许容器间的网络访问不，安全的容器运行时设置，应用中存在的漏洞，流氓容器
主机
网络暴露，操作系统和组件中的漏洞，共享主机内核，不当设置的用户访问权限，对主机文件系统的不当更改
有没有容器安全指南可以帮助了解容器环境存在的安全风险和应对措施呢？美国国家标准技术研究所 nist 发布的800-190应用容器安全指南正是这样一份为数不多的容器安全指南！
下面我们就来介绍一下 NIST SP 800-190，美国国家标准技术研究所 NIST 的职责之一是发布计算机网系安全标准和指南。美国联邦政府部门需要在 NIST 安全指南发布一年之内，遵照之行。NIST 安全标准，也是美国其他政府部门一些外国政府及工业界，采用的重要参考。NIST SP 800-190 是业界为数不多的容器安全标志，由于在业界的声誉 Twistlock 的联合创始人 John Morello 被邀请撰写 NISTSP 800-190应用容器安全标准。
NISTSP 800-190 从镜像、镜像仓库、编排工具、容器运行时、以及运行容器的主机等几个核心部件、描述了可能存在了安全隐患和应对措施。
讨论并演示如何应对这些安全隐患
这些安全隐患包括镜像中存在的漏洞、镜像配置缺失、镜像中潜藏的恶意程序，嵌入镜像的明码密匙或者使用不可靠来源的镜像。
与镜像仓库相关的隐患，造成的原因包括过时的镜像、不安全的访问连接，不充足的认证和授权限制、镜像仓库是容器环境的核心，一旦被骇客侵入就很容易导致下游的容器和主机出问题
与编排工具相关的安全隐患，造成的原因可能有：不设限制的管理员权限、未授权访问，对容器之间的网络访问缺乏隔离和控制，将不同敏感级别的应用，混合部署在同一个主机上。编排工具设置缺失导致未授权的节点主机加入集群，进而导致集群被入侵。
容器运行时，中存在的安全隐患，包括运行时软件漏洞、导致恶意软件从容器中逃逸进而攻击其他容器和主机、缺少允许容器间的网络访问、不安全的容器运行时设置、应用中存在的漏洞、流氓容器是环境中未经计划或未经批准的。往往是开发人员为测试临时部署。这些容器通常没有经过严格的漏洞扫描和正确配置，更容易受到骇客的攻击。
与主机相关的安全隐患包括有主机的网络暴露以及操作系统中的漏洞造成的扩大了的攻击面所有共享一个主机内核，从而消弱了容器间的隔离，主机操作系统中存在的漏洞可以导致主机上运行的所有容器被攻击，不当设置了用户访问权限，容许用户不通过编排工具而直接访问主题，对主机文件系统的不当更改造成主机以及容器运行故障或安全事故。
每个容器环境中的核心都有可能存在多种安全隐患，容器环境具有大规模，变化迅速的特点，管理权限分散在开发、测试、集成、运维、安全等多个团队。容器不使用网络地址和端口，传统的网络安全工具。对容器不再具备可视性。保护容器环境的安全需要全新的理念、工具和措施。第二讲讨论容器安全的风险应对策略。
