不久前我们又进行了一次GOST R 57580（以下简称GOST）要求的符合性评估。 客户是一家开发电子支付系统的公司。 系统很严肃：超过3万用户，每天超过200万笔交易。 他们非常重视那里的信息安全。
在评估过程中，客户随口宣布开发部门除了虚拟机之外，还计划使用容器。 但客户补充说，这样一来，就存在一个问题：在 GOST 中没有关于同一个 Docker 的任何文字。 我应该怎么办？ 如何评估容器的安全性？
确实，GOST 只写有关硬件虚拟化的内容 - 关于如何保护虚拟机、虚拟机管理程序和服务器。 我们要求央行作出澄清。 答案让我们很困惑。
GOST 和虚拟化
首先，让我们回想一下，GOST R 57580 是一项新标准，规定了“确保金融组织信息安全的要求”(FI)。 这些金融机构包括支付系统的运营商和参与者、信贷和非信贷组织、运营和清算中心。
自1年2021月XNUMX日起，金融机构必须进行 。 我们 ITGLOBAL.COM 是一家进行此类评估的审计公司。
GOST 有一个小节专门讨论虚拟化环境的保护 - 第 7.8 号。 其中没有指定术语“虚拟化”；没有硬件虚拟化和容器虚拟化的划分。 任何 IT 专家都会说，从技术角度来看，这是不正确的：虚拟机 (VM) 和容器是不同的环境，具有不同的隔离原则。 从部署VM和Docker容器的主机的漏洞来看，这也是一个很大的区别。
事实证明，对虚拟机和容器的信息安全评估也应该有所不同。
我们向中央银行提出的问题
我们把它们发给了央行信息安全部（我们以简短的形式提出问题）。
- 在评估GOST合规性时如何考虑Docker类型的虚拟容器？ 根据 GOST 第 7.8 条评估技术是否正确？
- 如何评价虚拟容器管理工具？ 是否可以将它们等同于服务器虚拟化组件并根据 GOST 的同一小节对其进行评估？
- 我需要单独评估Docker容器内信息的安全性吗？ 如果是这样，在评估过程中应考虑哪些保障措施？
- 如果容器化等同于虚拟基础设施并根据第7.8小节进行评估，那么如何实施GOST对实施特殊信息安全工具的要求？
央行的回应
以下是主要摘录。
“GOST R 57580.1-2017 规定了通过应用与 GOST R 7.8-57580.1 的以下措施 ZI 第 2017 款相关的技术措施来实施的要求，该部门认为，这些措施可以扩展到使用容器虚拟化的情况技术，考虑以下因素：
- 在实现对虚拟机和虚拟化服务器组件的逻辑访问时，用于组织识别、身份验证、授权（访问控制）的措施 ZSV.1 - ZSV.11 的实施可能与使用容器虚拟化技术的情况不同。 考虑到这一点，为了实施多项措施（例如ZVS.6和ZVS.7），我们认为可以建议金融机构制定实现相同目标的补偿措施；
- 用于组织和控制虚拟机信息交互的措施ZSV.13-ZSV.22的实施规定了金融组织计算机网络的分段，以区分实施虚拟化技术并属于不同安全电路的信息化对象。 考虑到这一点，我们认为在使用容器虚拟化技术时提供适当的分段是明智的（既与可执行虚拟容器有关，也与操作系统级别使用的虚拟化系统有关）；
- 组织保护虚拟机镜像的措施ZSV.26、ZSV.29-ZSV.31的实施也应类推，以保护虚拟容器的基本镜像和当前镜像；
- 用于记录与访问虚拟机和服务器虚拟化组件相关的信息安全事件的措施 ZVS.32 - ZVS.43 的实施也应与实施容器虚拟化技术的虚拟化环境元素相关。”
这是什么意思
央行信息安全部门的回应主要有两个结论：
- 保护容器的措施与保护虚拟机的措施没有什么不同；
- 由此可见，在信息安全的背景下，央行将两种类型的虚拟化等同起来——Docker容器和虚拟机。
回应还提到需要采取“补偿措施”来消除威胁。 只是尚不清楚这些“补偿措施”是什么，以及如何衡量其充分性、完整性和有效性。
央行的立场出了什么问题？
如果在评估（和自评估）时使用央行的建议，则需要解决一些技术和逻辑上的困难。
- 每个可执行容器都需要在其上安装信息保护软件（IP）：防病毒、完整性监控、日志处理、DLP 系统（数据泄漏防护）等。 所有这些都可以毫无问题地安装在VM上，但对于容器来说，安装信息安全是一个荒谬的举动。 该容器包含服务运行所需的最少量的“身体套件”。 在其中安装SZI与其意义相矛盾。
- 容器镜像也应该按照同样的原则进行保护，但具体如何实现还不清楚。
- GOST 要求限制对服务器虚拟化组件（即虚拟机管理程序）的访问。 就 Docker 而言，什么被视为服务器组件？ 这不是意味着每个容器都需要在单独的主机上运行吗？
- 如果对于传统虚拟化来说，可以通过安全轮廓和网段来划分虚拟机，那么对于同一主机内的 Docker 容器来说，情况就不是这样了。
在实践中，每个审核员很可能会根据自己的知识和经验，以自己的方式评估容器的安全性。 好吧，或者根本不评价它，如果两者都不存在的话。
为了以防万一，我们补充一下，从 1 年 2021 月 0,7 日起，最低分数必须不低于 XNUMX。
顺便说一下，我们会定期在我们的网站中发布监管机构对 GOST 57580 和中央银行法规要求的回应和评论。 .
怎么办
我们认为，金融机构解决这个问题只有两种选择。
1.避免实施容器
对于那些准备好只使用硬件虚拟化，同时又害怕 GOST 的低评级和中央银行罚款的人来说，这是一个解决方案。
加： 更容易遵守 GOST 第 7.8 款的要求。
减： 我们将不得不放弃基于容器虚拟化的新开发工具，特别是 Docker 和 Kubernetes。
2. 拒绝遵守GOST第7.8款的要求
但同时，在使用容器时应用确保信息安全的最佳实践。 对于那些重视新技术及其提供的机会的人来说，这是一个解决方案。 我们所说的“最佳实践”是指行业公认的确保 Docker 容器安全的规范和标准：
- 主机操作系统的安全性、正确配置的日志记录、禁止容器之间的数据交换等；
- 使用Docker Trust功能检查镜像的完整性并使用内置的漏洞扫描器；
- 我们不能忘记远程访问和整个网络模型的安全性：ARP 欺骗和 MAC 洪泛等攻击尚未取消。
加： 容器虚拟化的使用没有技术限制。
减： 监管机构很可能会对不遵守 GOST 要求的行为进行处罚。
结论
我们的客户决定不放弃容器。 与此同时，他必须重新考虑工作范围和过渡到 Docker 的时间（持续了六个月）。 客户非常了解风险。 他还了解，在下一次 GOST R 57580 合规性评估期间，很大程度上取决于审核员。
在这个情况下，你会怎么做？
来源： habr.com