1.5 安全原则

0x00 前言

最后，我们来介绍一般性的指导方针，无论您对任何环境进行防护，这些原则都被认为是最佳的方法。

0x01 最小权限原则

您应该限制一个人或一个组件的权限，让它用最小的权限也可以完成工作。

例如：

• 若一个微服务的功能仅仅是在电子商务应用中对产品搜索；

那么，可以拥有的权限为：

• 以只读的方式访问产品的数据库数据；

这时，不能拥有的权限为：

• 访问用户信息；
• 访问支付信息；
• 写入产品信息；

0x02 纵深防御

接下来，我们将介绍多种方式可以提升您的部署环境及运行在该环境中的应用程序的安全性。

但该原则告诉我们：您应该使用多层防护机制，即如果攻击者能够突破一层防御，另一层防御则应该阻止他们对您的部署环境造成伤害或窃取你的数据。

0x03 减少攻击面

一般而言，一个系统越复杂，攻击成功的可能性就越高。因此，我们可以简化系统的复杂性，以减少系统的攻击面。例如：

• 尽可能地让接口小而简单，从而减少访问路径；
• 限制可以访问服务的用户和组件；
• 最小化代码量；

0x04 限制爆炸半径

将系统的安全控制分割成更小的子组件或单元。如果最坏的事情发生了，那么其影响范围就会受到限制。

容器就非常适用于该原则，因为您可以将架构划分为多个微服务的实例，然后使用容器来充当安全边界。

0x05 职责分离

该原则与前面的最小权限和限制爆炸半径相关，即尽可能地赋予不同的组件或人员所需的系统整体最小子集的权限。

这样可以确保要成功执行某个操作，必须拥有多个用户的权限，从而限制了单个特权用户被攻陷可能会造成的伤害。

0x06 应用

若您坚持学完本课程，您将看到：容器的细粒度非常适合应用这些安全原则。

• 最小权限

  您可以为不同的容器分配可以完成其任务的最小的权限集。

• 深度防御

  容器为应用程序提供了一个安全边界，我们可以在这个安全边界中强制地实施安全防护措施。

• 减少攻击面

  将单体应用拆分为简单的微服务，并在它们之间创建清晰的接口。

  微服务结构如果设计得当，可以减少系统的复杂性，从而可以减少供给面。但也有人认为，容器的编排调度会变得复杂，这又会引入另外一个供给面了。

• 限制爆炸半径

  如果容器化的应用程序被攻陷了，那么安全控制可以让攻击仅在容器内部发生，而不会影响到系统的其他部分。

• 职责分离

  权限和凭证只能传递到所需要的容器中，这样一组密钥的泄漏不一定意味着所有密钥都会被泄漏。

0x07 总结

这些原则听起来很不错，但是在实际使用中往往会被不良的错误系统配置、受污染的容器镜像成份或不安全的操作所抵消。我们希望可以通过本课程的学习，您将能够避免容器化部署环境中可能出现的安全陷阱，并充分利用其带来的好处。

经过《第 1 课 容器安全威胁建模》的学习，您已经对容器环境的攻击有了一个较高的层次的视角，并且了解了可以抵御这些攻击的安全原则。

接下来，我们将深入探讨支撑起容器的底层技术，以便于了解如何结合安全工具和最佳实践流程来实施这些安全原则。