随着容器的持续流行，将应用改造成云上的微服务，对于很多希望IT运营更加敏捷高效的企业来说是显而易见的下一步。但是，在容器化应用并且部署之前，需要首先确保你的应用是安全的。云托管的微服务所带来的安全挑战，和传统应用情况并不完全一样，我们必须妥善解决这些问题，避免暴露重大的安全漏洞。
1.什么让微服务如此不同
要理解为什么必须保护微服务，比如那些运行在Docker容器里的应用，你首先需要理解微服务和传统应用之间的主要区别。
传统来说，程序员构建“单体”应用。也就是说应用使用的整个软件堆栈被组织成一个单一的可交付的实体。比如，你的团队可能已经通过编写前端代码为应用构建了web应用，将其和MySQL数据库集成来存储数据，并且将所有东西打包到一个基于Linux的虚拟机镜像里，从而可以将其部署到公有云服务，比如AWS或者Azure上。
微服务方案通过将应用分解成模块化碎片改变了这一切。它们是分布式的，并且通常并不依赖于特定类型的操作系统来运行。这意味着上述描述的应用并不会以虚拟机镜像的形式分发。相反，前端代码可以被打包进一个容器镜像。数据库可以运行在单独的容器里。所有这些容器都在Docker或者其他容器平台上运行，并且底层操作系统或者托管它们的云环境和容器本身并不相关。
2.微服务和安全
微服务消除了一些和单体应用相关的安全挑战。它们让应用环境更加一致，简化了安全监控。它们还增加了应用不同部分之间的隔离性，降低了入侵应用的一部分就可以控制整个堆栈的风险。并且它们可以帮助提供抵御分布式拒绝服务攻击的弹性，因为容器可以带来更大的灵活性和可扩展性，并且能够更好地抵御通过向服务器发送过多请求来摧毁其基础架构的攻击。
保护微服务架构时也会遇到一些挑战。包括：
更大的攻击面。有更多的组件意味着有更多黑客可以利用的可能漏洞。比如，单体软件堆栈可能不依赖于网络在前端应用和数据库之间发送信息，而容器通常是这么做的。这带来了新的可能的攻击向量。
更少的内部一致性。微服务的优势之一是它们允许开发人员在开发语言和框架间轻松改变。比如，如果你目前用PHP开发应用，但是想切换成Go，那么当应用前端和堆栈其他部分解耦合时就很容易完成这样的切换。但是应用内部可以按照开发人员喜好频繁改动的事实也意味着更少的一致性。无论何时发生变化，也正是新的安全漏洞可能产生之时。
现有工具无法保护微服务。大部分目前可用的久经考验的安全工具都是在微服务变革之前设计的。新的方案正在涌现，但是目前的事实是，很多漏洞扫描工具在容器或者其他基于微服务的应用上无法正常工作。
全新的信任关系。容器化基础架构的优势之一是可以从公开存储库里免费快速地下载并且部署容器镜像。想要搭建MySQL数据库或者Ubuntu Linux服务器?一个简单的docker --pull 命令就能够在几秒内获得所需的容器镜像。缺点正是这些来自于公开存储库的容器镜像。这并不意味着这些镜像不安全，但是的确意味着如果使用这些镜像，你就和堆栈里的第三方软件合并了。你无法保证不受你控制的代码的安全性。
3.保护微服务的步骤
制定正确的策略，可以减轻在云上运行微服务架构的应用程序相关的安全风险。如下步骤特别有效：
保护内部环境。虽然微服务涉及更多部分，但是可以通过确保托管微服务的环境的尽可能安全来降低总体安全风险。如果在云上运行Docker 环境，这意味着确保除了你没有其他人能够访问你的云主机，并且除非必要，将 Docker容器配置成拒绝公开网络的连接。
使用安全扫描器。大部分传统的安全工具仍然在尝试适用微服务的过程中。但是已经有一些好用的工具可用，比如Docker Security Scanning和CoreOS的Clair。这些工具帮助你寻找并且解决容器内的安全漏洞。
使用访问控制。可以在软件堆栈的不同层面使用访问控制限制来降低安全风险。比如，在管理层面，必须确保能够运行Docker命令的用户才有执行Unix系统的Docker CLI工具的权限。还可以在大部分容器存储库里配置访问权限，避免公开的访问。
确保沟通。确保负责构建并且部署企业软件的团队的所有成员不断地沟通，而不是各自为战。这样能够确保运维的所有人都知道upstream或者downstream所发生的变化——以及可能的安全隐患。
越来越多的企业开始向基于DevOps的工作流和容器这样的技术转变，微服务的安全会变得越来越容易管理。但是，现在，微服务能使用的安全工具的缺失意味着企业需要特别前瞻性地保护计划在微服务架构下运行的软件。
本文作者：佚名
来源：51CTO
