数字化时代,数据越来越成为企业最重要的资产,数据保护(包括备份、迁移、容灾等)的重要性已不言而喻。但是当前,国内客户多数处在数字化转型的过程中,如业务上云、应用容器化改造、人工智能模型应用等都在并行推进,传统的系统架构仍在支撑企业核心业务的运转。因此,稳敏、新旧多种系统并存,这必然带来企业数据基础架构的多元性和复杂性,也为数据保护带来了极大的挑战。 从应对的角度而言,首先,没有银弹,希望用一套方案把企业所有的数据保护问题都一下子解决,肯定是不现实的,企业对这个复杂度要有充分认知;其次,历史上,系统建设的宝贵经验是可以借鉴的,比如“老的老办法,新的新办法,逐渐融合和过渡”,可能是更为务实的选择。 面向云原生的数据保护 数据侧技术(包括数据保护在内)是依附于计算生态的,计算生态每次重大的技术变革都会给数据侧带来全新的要求和挑战。云计算作为一个历史性的技术变革更是如此。尤其是云原生技术,它为混合多云而生,革命性地迭代了云计算的生态,对于数据保护提出了全新的需求。 以应用为中心 云原生是一个以应用为中心来设计的系统,计算、存储、网络等云基础实施被抽象成面对应用的“水、电、煤”服务。容器化的应用由 Kubernetes 平台分配资源,自动地在几百乃至上千台物理机或者虚拟机中进行调度。用户不关心,其实也很难去跟踪应用在哪个机器中运行,所以传统备份方案针对机器粒度进行备份保护就不能满足要求。 面向云原生的备份必须要以应用为粒度进行,对应用进行端到端的保护,包括应用的镜像、应用相关的配置信息,以及应用的数据;恢复时,也是把整个应用、配置和数据都完整地恢复回来。这与传统备份是非常不同的地方。 与云原生生态融合 云原生是一个全新的生态,有独特的设计思想、开发运维工具链和最佳实践,比如快速部署、弹性伸缩、高度自动化运维、声明式 API、与 Prometheus 和 ELK 的集成等。因此,备份服务本身也必须完全融入到这个生态中。 生来多云 云原生生来就是多云的。Kubernetes 屏蔽了多云底层基础设施的差异性,符合规范的应用可以在任何一个私有云或公有云的 Kubernetes 平台上运行。因此,云原生备份方案设计必须立足于多云。例如,在一个 Kubernetes 集群中备份的应用和数据,需要支持在其它云的 Kubernetes 平台上进行恢复;同时,可以在不同云的 Kubernetes 平台间进行应用和数据迁移等。 因此,在混合多云的云原生时代,需要有全新的数据保护解决方案,如青云科技 KubeSphere 云原生部与骥步科技联手打造的国内首个云原生备份容灾 SaaS 服务,就是以应用为中心、专门针对云原生生态的全新数据保护方案,可以满足企业用户对云原生应用日常备份恢复、跨集群迁移、异地容灾等场景的需求。 青云云原生备份容灾服务提供了“跨云容灾备份、核心业务保障、直观易用的管理”三大关键能力,可帮助企业快速建立备份恢复和容灾保护能力,实现对核心业务数据的有效保护,用户再也不用担心数据跑路。 安全合规“两手硬” 2019 年年底生效的等保 2.0 对于企业数据备份、容灾等技术规范给出了明确的要求。2021 年发布的《数据安全法》和《关键信息基础设施安全保护条例》更是从立法的角度对企业作为数据保护主体的责任进行了明确的界定,这些都必将对提高企业的数据备份意识和投入产生积极的影响。 北京信息灾备技术产业联盟的调查报告显示,我国信息系统灾备建设投资比例低于欧美两倍有余。重要的数据灾备建设“本地备份完备度低、缺乏容灾、严重缺乏异地灾备”,行业关键数据“有待充分分类分级并建立审查演练制度”。在这样的背景下,国家推出的一系列关于数据安全的法律法规必将对我国信息系统灾备建设产生重要的影响和有力推动。 网络安全与数据安全都是企业信息系统安全的重要组成部分,网络安全重预防,强调御敌于国门之外;数据安全重保障,强调即使遇到意外和灾难也不慌。只重视网络安全,是无法避免所有事故的,事后如果缺乏必要的恢复手段,依然无法做到安全无虞;只重视数据安全也不可行,企业在各种安全威胁面前会处处被动。所以在涉及企业信息系统安全建设的时候,一定要通盘考虑,做到两手抓,既要做好面对攻击的免疫系统,又要储备好遇到问题时的及时恢复能力。 青云 QKCP 企业级容器平台上推出了一体化的云安全解决方案,从主动到被动,全方位保障企业的核心数字化资产。QKCP 可以通过对容器内行为进行学习,建立安全模型。通过主机漏洞识别、主机入侵检测和合规审计,实现主机安全。同时还支持微服务安全,可自动发现云原生环境中存在的所有微服务,识别服务类型,扫描服务存在的安全漏洞。另外,还支持网络微隔离、安全合规,支持组件容器化部署。 不止是“上保险” 传统的备份手段往往只是为企业留存了数据保护的副本,这些副本除了用于数据和信息恢复之外,常常无法发挥更大的价值,所以只是作为企业为数据安全买的一份“保险”,从性价比的角度,这必然带来企业一定程度上的担忧。 现在,新的备份手段一般都强调采用数据的原始格式进行备份,这样备份下来的数据副本是可以直接访问和使用的。这样,数据备份的副本就不光是“保险”了,还是可以直接产生业务价值的数据源。例如,可以使用备份下来的数据副本完成测试环境的搭建、数据正确性验证、容灾模拟演练、数据抽取和分析等,全面盘活备份数据的价值。
Month: April 2022
Kubernetes 安全及配置问题检测工具 KubeEye 使用教程
前言 KubeEye 是一款 Kubernetes 安全及配置问题检测工具,针对部署在 K8s 集群中的业务应用进行配置检测使用 OPA,针对集群部署的 Node 使用 Node-Problem-Detector 进行检测,同时除了系统内置有根据大多数业界常见场景的预定义规则,还支持用户自定义规则来进行集群检测。 架构 KubeEye 通过调用 Kubernetes API,通过匹配资源中的关键字和容器语法的规则匹配来获取集群诊断数据,详见架构图。 其中针对 Node 节点的检测,需要在被检测 Node 主机上安装。 特点 特性 检查项 是/否 检查项 描述 级别 ✅ PrivilegeEscalationAllowed 允许特权升级 紧急 ✅ CanImpersonateUser role/clusterrole 有伪装成其他用户权限 警告 ✅ CanDeleteResources role/clusterrole 有删除 Kubernetes 资源权限 警告 ✅ CanModifyWorkloads role/clusterrole 有修改 Kubernetes 资源权限 警告 ✅ NoCPULimits 资源没有设置 CPU 使用限制 紧急… Continue reading Kubernetes 安全及配置问题检测工具 KubeEye 使用教程
K8s 安全策略最佳实践
随着 K8s 在生产和测试环境中用的越来越多,对安全性的关注也会越来越多,所以本次演讲主要是给大家分享以下内容: K8s 安全风险 这张图是 CNCF 金融用户小组总结的 K8s 信任边界图,它把在 K8s 环境中的信任边界划分成三大块儿。 我们根据不同的攻击类型划分,首先最容易规避的就是来自外部的攻击。通常情况下,来自外部的攻击会有 2 种类型。 一种是系统层面的漏洞,需要及时更新,及时跟进 K8s 社区和安全领域相关的最新消息,可以很好的规避。 第二个是应用本身带来的渗透或者是提权的风险,业务部署在 K8s 之上,应用的漏洞可能造成容器越权或者容器逃逸之类的风险。 借助恶意容器进行攻击也比较常见,在使用容器的过程种主要会面临以下风险: K8s 集群的规模变大,运维人员与终端用户也会变多,安全凭证的泄露,会对整个集群的安全造成威胁。 即使集群保护的非常好,在安全凭证没有泄漏的情况下,来自内部成员的恶意攻击也难以规避,即使是在测试环境也需要一定程度的租户隔离,避免来自内部的攻击、对数据的恶意访问。 K8s 安全机制 在 K8s 社区,安全问题的关注度是非常高的,在 K8s 的设计中,各组件都有安全相关的特性。在 API 认证层面,控制平面中各个组件之间,需要开启 mTLS 进行组件之间的互认证。 K8s 也支持丰富的认证、访问控制的机制,通常我们会借助 RBAC 对用户的权限进行限制。 K8s 还提供了针对容器能力的限制机制,我们可以通过 Security Context 去限制容器运行时的用户、用户组,对容器特权进行限制。 K8s 中 Pod Security Policy 可以为集群应用安全策略,但是这个特性会在 1.25 之后被后面提到的 pod security… Continue reading K8s 安全策略最佳实践