这是一个创建于 1645 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前运维架构基于传统的虚拟云主机和其他 IaaS 之上的，传统云主机运维的可以通过堡垒机保证操作都记录下来，满足等保要求。
如果运维架构迁移到 K8S 上之后应该怎样满足等保合规的要求？
如果运维架构迁移到 K8S 上之后应该怎样满足等保合规的要求？
 |
1
libook 2020-06-30 16:53:05 +08:00  1
堡垒机记录所有人工操作，那么不管你是登录到云主机还是容器环境内都是通过堡垒机做跳板的，堡垒机会记录所有操作。
现阶段等保只会以物理机或虚拟客户机作为一般意义上的服务器，可以不认为容器内部环境为服务器，当然这个在你上报设备信息的时候就得这么去分类。 K8s 产生的日志、K8s 的管理控制台操作日志，以及容器产生的日志，都要存档、异地备份、保存 180 天以上。 |
 |
2
joesonw 2020-06-30 18:35:05 +08:00
k8s 不是自带 audit 吗? https://kubernetes.io/docs/tasks/debug-application-cluster/audit/
|
 |
3
akira 2020-06-30 19:01:08 +08:00
安全公司一般都有提供等保咨询业务的，可以问一下
|
 |
4
defunct9 2020-06-30 20:07:10 +08:00 1
安全公司都是一群恶狼，张嘴都是 40-80 万起。
|
 |
5
ghostheaven OP |
|
6
ghostheaven OP @joesonw 审计功能肯定要开的，就是不知道 K8S 的管理方式能不能达到等保合规的要求。
|
|
7
libook 2020-07-03 17:02:13 +08:00
@ghostheaven 我们公司的三级等保快要做完了。
等保的国家标准其实是比较宽泛的，并没有针对各种情况进行细节上的规定，所以每一条标准都可能有不尽相同的解读以及执行测评的方案，当然各家测评机构会互相讨论这个以形成一个行业上的细节标准，但这个需要时间，特别是今年是第一年做等保 2.0，测评机构们也拿不准怎么做。 也就是说，测评机构提供的结果和意见是可以商量的，比如有的测评机构擅长传统私有机房的测评，对于公有云甚至云原生都还是套用传统的那一套，结果发现很多不符合等保要求，但实际上如果你挖掘标准条目的本意，然后合理使用各种证明来说服测评机构，也是有可能变为符合要求或者降低威胁等级（减少扣分）。 建议读一读相关执行标准，以便于更好地引导测评机构进行测评（网上有 PDF，大的新华书店可以买到纸质版）： 这个讲等保要求本身的：GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求 这个讲测评机构如何测评的：GB/T 28448-2019 信息安全技术 网络安全等级保护测评要求 比如按照标准中有对安全审计的要求，原文列出了若干项子要求，大体上就是你得有能力以可靠的方式随时查看任何人对系统做的任何操作，那么如果你不用堡垒机的话，有任何其他方案能够满足标准里规定的安全审计要求也可以，如果没有的话至少堡垒机是个专门针对这个要求的现成方案。 我接触的帝都这边的测评机构多是以传统私有机房的模式来做测评的，为了避免云原生的坑约踩越多，所以我们在提供设备信息的时候就不把容器作为设备，而是把容器的宿主机作为设备提交给测评机构做测评，测评机构在这些宿主机上做各测评，容器只是跑在设备上的软件。你可以把容器类比成 JVM，容器内的镜像是自己打的 Jar 包，K8s 相当于是个运维工具（或者运维控制台）。 K8s 暴露管理接口，相当于是管理工具暴露了接口，那么这个接口的使用方式得符合等保标准，比如网络安全边界划分合理，以及符合三权分立的基本原则。 如果你用阿里云的话可以提工单让他们给你指派一个安全架构师来帮你们解决等保测评的问题。 |
|
8
ghostheaven OP @libook 把宿主机作为设备确实是个好方案，多谢~
|
|
9
defunct9 2020-07-03 20:34:58 +08:00 via iPhone
@ghostheaven 等保 2.0，跟 1.0 不一样。我们刚过。
|
|
10
ghostheaven OP @defunct9 今年 2.0 对这方面有什么大的变化吗
|
Select Language