微服务的伟大承诺是自由。可以自由地将应用程序分解为独立部署的不同服务。可以自由地与不同的团队使用他们喜欢的编程语言、工具、数据库等构建这些不同的服务。简而言之，开发团队可以自由地用最少的官僚作风完成工作。
专题报告:微服务:未来企业应用的基础(免费PDF)
这本电子书基于最新的ZDNet / TechRepublic特性，探讨了微服务体系结构如何有潜力继承面向服务的体系结构(SOA)，使应用程序开发更快、更具可伸缩性和更灵活。
听起来不错,对吧?“全世界的开发者联合起来!”你没什么可失去的，除了你那铁板一块的应用程序链!”
除了安全部分。微服务体系结构将应用程序分解为独立的服务，这非常棒，但这也意味着更复杂;更多的服务需要保护。如果每个服务都有一个数据库(这里是MongoDB !亚马逊极光MySQL那里!你仍然需要管理好它们。所有这些都有技术策略，但实际上，有效的微服务安全从人开始(和结束)。
是的。那些混蛋。
人的问题从工作开始。或者说，不同的人有不同的工作，有不同的优先级。开发人员的任务可能是尽可能快地构建应用程序，以便赶上或超过竞争对手。与此同时，安全和操作团队正试图阻止应用程序变成垃圾箱火灾。在一个开发人员构建而其他所有人都承担清理任务的世界中，安全性始终是一个难题，无论我们讨论的是微服务还是单片应用程序。
然而,当开发人员承担更多责任的操作他们的代码(DevOps)和保护(DevSecOps),它使不同的行为相对于“设计,什么样的监测,什么样的工具,如何与系统接口,“根据陈柏宇,信息安全的副总裁Neflix, 2015年hisFuture堆栈。正如Chan所指出的，强大的微服务安全性是三个指导原则的功能，所有这些原则最终都是为了使开发人员和安全专家的生活更轻松:可跟踪性和开发、持续的安全可视性和划分。
最好的安全性不需要很多额外的工作，这就是为什么安全性的第一个关键是将其构建到您的持续交付工作流中。许多公司试图使用应用程序风险评估手动地对其服务组件进行分类，通常通过发送给开发人员的调查问题进行填充。听起来是不是很熟悉?它应该。长期以来，大多数公司都是这样处理安全问题的。
但这没有用。首先，有一门完整的科学来回答这些问卷，使开发人员能够在不提高安全性的情况下回避问题。即使他们没有试图通过安全团队，也不总是清楚这些问题的含义。换句话说，这些风险评估可能最终会产生“错误的安全感”，Chan指出，这是确保微服务(或其他任何东西)安全的完全错误的方法。
相反，他继续说道:“不……创造一堆新的工具和新的仪表板，人们必须去。[D]不…打断他们的工作流程。”相反，与开发人员已经使用的工作流和工具集成。例如，Netflix已经开放了其持续交付(CD) Spinnaker工具的源代码，为开发人员和操作/安全人员提供了应用程序及其组件的整体、通用视图，但是还有很多其他的工具(Ansible、Jenkins等)。
使用哪种工具并不重要，重要的是如何使用它。
在CD工作流中可以插入测试、部署区域的限制(以及部署时间)。这样做不仅使服务的交付自动化，而且还确保了可审核性。常用技术,确保新服务不会引入安全(或其他)问题是推出“金丝雀工作量”——一个新的生产工作负载启动一组有限的用户——如果看起来不错的(例如,不触发任何自动化的安全警报),CD工具自动卷成完整的生产。
通过在开发人员选择的工作流中工作，并尽可能地自动化，安全团队可以保持微服务的速度/敏捷性，同时仍然确保进行安全检查。这就引出了一个相关的原则，持续安全可见性。
几年前，迈克尔•尼加德(michael Nygardsaid)曾说过一些话，应该会引起任何试图获得微服务的人的共鸣:“一个微服务适合你的头脑，但它们之间的相互关系超出了任何人的能力。”自动化你的意识。”换句话说，如果它只是一个服务，那么跟踪对它的更改并保护应用程序就相当容易了。但是微服务的全部承诺是它们可能是自包含的，但是它们的价值来自于它们与其他服务的连接。
无论您的组织有多大，您永远不会有足够的安全资源来渗透测试每个应用程序，或者查看每一行代码。同样，微服务的主要优点之一是它们加速了应用程序内部和应用程序之间的更改。回顾那些开发人员的调查，公司曾经试图为每个应用程序或服务构建带有分数的电子表格，但是这有上面提到的问题，以及保持它最新的困难(即:不可能)。如果您有数百个(甚至几十个)应用程序一直在更改，那么依靠人们及时或准确地提供信息是不明智的。
你需要自动化。
通过使用服务发现工具(Netflix企鹅酥饼应用,但还有许多其他选项),您可以衡量一个特定的风险服务基于多少取决于其他服务(越依赖于它的服务,更高的风险评分),无论是公开给外部网络流量(边缘服务得到更高的风险评分),等等。这种自动化的安全风险评估因此产生了风险的分层，允许相对稀缺的安全人员将注意力集中在风险最大的微服务上。
这就引出了最后一个原则，划分。
这个原则对于分布式系统和组成它们的微服务非常重要，原因有两个。首先，考虑到所有安全性都可能在某个时刻失败，您希望限制失败的爆炸半径。第二个是关于保密性的:只保留那些需要知道的数据。
对于单片应用程序，所有东西都集中在一起。开发人员很难在不破坏过程的情况下对单个块进行迭代，而且每个断点都会引入新的安全问题。Chan说，对于单片应用程序，“你有非常敏感的系统，有很多输入和输出。,攻击表面。(具有较大)攻击面的应用程序(可以)得到保护，(但)做到这一点比较困难。”同样，要验证事情是否正常运行也更加困难。
但是，在微服务上下文中，安全性可以更好，因为“爆炸半径”并不是整个应用程序:它只是各个服务。许多安全转发公司选择使用令牌库进一步改进这种安全模型，令牌库是存储敏感数据的地方。令牌映射到这个敏感的数据，并且这些令牌可以在应用程序中传递，而不需要数据本身移动。令牌服务调用位于敏感数据和令牌之间的加密基础设施，以保护数据。Chan说，这种方法允许您实现更细粒度的访问控制，而且更容易跟踪正在发生的事情。
在这三个原则(可跟踪性、可见性和划分)的指导下，安全专业人员可以自动化他们的大部分安全工作负载，而不给开发人员增加负担。更好的是，随着越来越多的开发人员被要求保护他们自己的应用程序，他们愿意成为这项工作的合作伙伴。这让我们回到了人的问题上:如果它试图以旧的方式(电子表格、调查、或多或少平等地对待所有应用程序/服务)保护微服务，那么人与人之间的伙伴关系就会破裂，安全就无法发挥作用。但是通过自动化，人们(和机器)合作伙伴可以确保微服务的安全性。