最佳安全实践

身份验证

AK和SK

AK(Access Key)和SK(Secret Key)是用于身份验证和访问控制的安全凭证,常用于云服务提供商和其他在线平台。AK是用户的访问密钥,类似于用户名,用于标识用户身份。SK是与AK关联的密钥,类似于密码,用于验证用户身份和生成数字签名以确保数据的安全性。在安全领域,正确管理和使用AK和SK非常重要。以下是一些关于AK和SK安全的最佳实践:

  1. 保密性:AK和SK应该被妥善保管,并仅在需要时向受信任的实体(如应用程序或服务)提供。不应将AK和SK存储在公开可访问的位置,如版本控制系统、公开的代码仓库或公开的文档中。
  2. 定期轮换:定期更换AK和SK是一种良好的安全实践,可以降低密钥被滥用的风险。推荐定期更换密钥,例如每隔几个月或根据安全政策和标准的要求。
  3. 权限控制:为每个AK和SK设置适当的权限和访问控制是至关重要的。仅授予所需的最小权限以执行特定任务,并定期审核和更新权限设置,以确保始终保持最小特权原则。
  4. 加密传输:在使用AK和SK进行身份验证时,应使用安全的传输协议(如HTTPS)来保护凭证的传输过程,防止被中间人攻击截获或篡改。
  5. 强密码策略:选择强密码并遵循密码策略是保护SK的重要措施。密码应具有足够的复杂性,包括大小写字母、数字和特殊字符,并避免使用容易猜测或常见的密码。

综上所述,保护AK和SK的安全性对于保障系统和数据的安全至关重要。严格遵循安全最佳实践,合理管理和使用AK和SK,可以降低安全风险并确保身份验证和访问控制的有效性。

AuthNode验证模块

  • 需求: 对Master主节点或者其他流程访问重要接口增加鉴权机制,避免未认证客户端及内部节点加入到集群中,当重要信息的拉取时需要校验。

  • 原理: Authnode 是为 CubeFS 提供通用认证和授权框架的安全节点。此外, Authnode 还充当对称密钥和非对称密钥的集中密钥存储。Authnode 采用并定制了基于票证的 Kerberos 认证思想。具体来说,当客户端节点( Master 、 MetaNode 、 DataNode 或 client 节点)访问服务时,首先需要在 Authnode 中展示用于身份验证的共享密钥。如果认证成功, AuthNode 将专门为该服务颁发一个限时票证。出于授权的目的,功能嵌入到票证中,以指示谁可以在什么资源上做什么 。

Image
  • 启动 在CubeFS中的配置步骤(可参考docker/run_docker4auth.sh)
  1. 超级管理员使用authnode的key,通过createKey API可以为各模块生成专属key,比如客户端是Ckey,以及master是Skey。同时AuthNode中会存储模块ID-Key的对应关系;
  2. 各模块配置ID及Key,启动服务。 扩大接口验证范围 Master接口涉及大量的卷维度和集群维度的运营管理,需要保护集群管理的安全,可以选择在Master启用配置“authenticate”,这样接口操作会到Authnode再次验证ckey的正确性。

授权政策及管理

权限分级

权限分admin权限和普通用户权限,admin权限具备普通用户的管理权限,卷的维度管理操作权限,在系统中以owner字段展示 普通用户权限,基于admin的授权固定的访问路径(可以是根目录)和操作权限(读、写),操作自己挂载目录及子目录下的文件或者目录

从卷的维度,用户分为两种类型:只读用户和读写用户。只读用户只能读取文件或目录,无法修改它们。此外,还支持限制用户仅能访问特定子目录中的文件。在挂载后,CubeFS 支持使用 Linux 用户、组和其他权限限制进行权限检查的功能。例如,给定以下文件权限:-rwxr-xr-x 2 service service f1,只有 "service" 用户可以修改该文件,而其他非 root 用户只能读取它。

用户管理:https://cubefs.io/zh/docs/master/tools/cfs-cli/user.html#%E8%8E%B7%E5%8F%96%E7%94%A8%E6%88%B7%E4%BF%A1%E6%81%AF

权限管理

创建申请走管控平台审批,可以收紧owner(admin)创建后的使用(有删除卷的权限),卷的admin账号由管控平台创建管理,基于命名规则自动生成,用一个否则不安全,普通账户返回给业务 例如: 对接中间件,授权一个普通账户给业务返回,由管控平台保存owner,删除需要同管控平台申请 ladp+自动挂载

Image
### ldap的作用 1. 用户身份验证:LDAP可用于验证用户的身份。用户的用户名和密码可以存储在LDAP目录中,当用户尝试进行身份验证时,系统可以通过LDAP协议与LDAP服务器通信,验证用户提供的凭据是否与存储在目录中的凭据匹配。 2. 单一登录(Single Sign-On):LDAP可以用作单一登录系统的认证后端。单一登录系统允许用户使用一组凭据登录到多个关联应用程序,而不需要为每个应用程序单独进行身份验证。LDAP作为认证后端,可以集中管理用户凭据,实现用户在多个应用程序间的无缝登录体验。 3. 用户授权和权限管理:LDAP目录可以存储用户组织结构、角色和权限信息。基于LDAP的认证和授权系统可以根据用户的身份和所属组织结构,授予用户适当的权限和访问权限。这样可以确保只有经过授权的用户可以访问敏感数据和资源,提高系统的安全性。 4. 集中式用户管理:LDAP提供了一个集中式的用户管理平台。组织可以在LDAP目录中存储和管理用户信息,包括用户名、密码、电子邮件地址、电话号码等。通过LDAP,管理员可以轻松地添加、修改或删除用户信息,而不需要在每个应用程序中单独进行操作,提高了管理效率和一致性。 ### 自动挂载的优势 AK和SK应该被妥善保管,并仅在需要时向受信任的实体(如应用程序或服务)提供。不应将AK和SK存储在公开可访问的位置,如版本控制系统、公开的代码仓库或公开的文档中。 避免ak、sk等信息泄露,提高密钥的安全可用 基于ip、用户做ldap验证,通过ldap做权限管理控制

网关

master ip不直接暴露,使用网关的域名方式,优势如下: 方便master节点更换,避免客户端配置变更,正常情况下上线业务变更配置重启比较麻烦 保障接口安全,域名开放必要的master接口,例如程序需要的分区信息等,但管理类接口不对外开放,保护了管理权限 作为监控、告警、成功率统计等 可增加缓存层

流量控制

卷维度流量QOS

大集群多租户运营模式中可提升资源利用率,降低成本,但也给系统稳定性带来了挑战,例如某租户下的一个卷的请求突增,流量对整个存储系统造成冲击: 不同卷的数据及元数据分区可能会放置在一台机器,甚至一个磁盘上,某个卷的过大的读写请求会影响到同节点节点和磁盘上的其它卷的访问。 带宽打满会影响集群节点间内部通讯,进而影响集群管理节点对数据节点状态判断,触例如数据均衡等行为,进一步加剧整个集群的抖动。 冲击集群上游交换机,不仅影响存储系统本身,还会影响同一交换机下其他非存储类系统。 因此,流量QoS是系统稳定运营的重要保障手段。

设计文档:https://mp.weixin.qq.com/s/ytBvK3MazOzm3uDtzRBwaw

使用文档:https://cubefs.io/zh/docs/master/maintenance/admin-api/master/volume.html#%E6%B5%81%E6%8E%A7

master请求接口QOS限制

Master的稳定性对于整个集群非常重要,所以为了防止意外(失败大量重试)或者恶意攻击,需要对Master的接口进行qps限流管理。 Master的接口限流为qps限流(每秒接受多少个请求),对于没有设置限流的接口,不做任何限制。对于设置了限流的接口,有一个限流等待超时时间可以设置,防止雪崩效应。

使用文档:https://cubefs.io/zh/docs/master/user-guide/qos.html

对象服务安全相关特性

S3鉴权能力

  • 为了保障CubeFS中的数据以及请求过程的安全性,所有请求要么是签名认证的,要么是匿名授权的。CubeFS的签名能够从如下维度保护用户数据的安全: 请求方身份认证
  • 请求签名要求您必须通过AK和Sk进行签名计算,服务端也能通过AK识别请求方的身份。

数据防篡改

  • 为了防止数据传输过程中被篡改,将请求元素也参与到请求签名的计算中。当收到请求后,服务端会通过接收到的请求元素进行签名计算,如果请求元素出现篡改,那么两边的签名比较将无法通过。
  • ObjectNode支持V2、V4和STS三种兼容S3协议的签名算法,同时兼容Header、Query和Form三种子签名方式,能够保障用户请求过程中的数据安全性。

权限管控

  • 权限管控是基于用户和资源的授权策略,对请求用户的行为进行访问控制,常用的应用场景有:对用户和 API 的组合控制、对客户端 IP、请求 Referer 等信息进行控制、内外网隔离访问控制等。
  • CubeFS 针对存储桶和对象的访问,主要提供了以下权限控制策略:Bucket Policy 和 ACL。在 CubeFS 的权限管控中,首先校验的是 Bucket Policy,只有 Bucket 没有设置 Policy 或者 Policy 中没有匹配到对应权限时,才会继续进行 ACL 校验。

WORM模式

  • 对象锁定(Object Lock)可以实现一次写入,多次读取 (WORM) 模式来存储对象。Object Lock可以帮助用户满足需要 WORM 存储的法规要求,也可以增加额外的保护来防止对象被更改和删除。 为用户提供设置(取消)和获取Bucket对象锁定配置的接口。用户配置Bucket对象锁定后,所有上传的新对象都遵从此配置,存量对象不受影响。
  • 为用户提供通过HeadObject以及GetObject获取对象的保留周期、保留模式的功能。
  • 在对象锁定保护期内,对象不会被删除和覆盖。

S3API QoS

为保证CubeFS服务的可用性和规避异常用户流量的影响,ObjectNode支持S3API级别下不同用户的并发/QPS/带宽维度的流控策略。

ACL IP黑名单

  • 加强端侧可控,为业务、运营管理者提供基于IP的可屏蔽策略。客户端挂载请求和已经挂载的客户端,所在IP加入黑名单后会无法继续服务。例如
  • 防止未经授权的访问:ACL IP黑名单可以用于阻止已知的恶意IP地址的访问,从而保护网络资源免受未经授权的访问或攻击。
  • 阻止恶意流量:阻止这些来源的恶意流量,例如分布式拒绝服务(DDoS)攻击、恶意扫描或爬虫等。

具体使用方法:

./cfs-cli acl
Manage cluster volumes acl black list
Usage:
  cfs-cli acl [command]

Aliases:
  acl, acl

Available Commands:
  add         add volume ip
  check       check volume ip
  del         del volume ip
  list        list volume ip list

防火墙端口范围

master、datanode、metanode、authnode、objectnode、lcnode等服务端都有监听端口范围 只开放必要的端口,关闭不必要的端口。这可以通过防火墙规则或系统配置来实现。例如,如果您只需要通过SSH进行远程管理,您可以关闭其他不必要的远程管理端口,如Telnet。

审计日志

挂载点的操作审计流水,审计日志存放在客户端本地指定目录,方便接入第三方的日志采集平台。 可以在客户端配置中开启或者关闭本地审计日志功能 Client 配置 可以通过http发送命令到客户端主动开启或者关闭日志功能,不用重新挂载 客户端审计日志记录在本地,日志文件超过200MB会进行滚动,滚动后的陈旧日志会在7天后进行删除。也就是审计日志默认保留7天的审计流水,每小时触发一次陈旧日志文件扫描删除

客户端默认开始审计(3.3.1)开始,审计日志从客户端审计日志转为服务端日志,服务端审计可以设置是否开启,默认是关闭的

删除保护

在卷维度下,设定一个文件或者目录创建后的禁止删除时间,这样文件或者目录,创建后在这个禁止时间内都不准许删除。 用户可以通过cli工具设置删除锁定周期,并判断传入的参数值是否大于0,若大于0,则用该值更新卷的删除锁定周期。 client会定期到master拉取卷信息并缓存,拉取完成之后,client才正式开启删除锁定功能。 客户端执行删除之前会判断缓存的卷信息中的删除锁定周期是否为0,若不为零则说明已开启删除锁定功能,此时需要进行判断。若当前卷上设置的删除锁定周期小于当前时间和文件或目录创建时间的差值,则允许执行删除的后续逻辑。 默认情况下,卷的删除锁定功能是关闭的,要打开该功能只需要在创卷或者更新卷的过程中指定删除锁定周期为一个正数即可。cli命令的使用:

创建卷:volume create [VOLUME NAME] --deleteLockTime=[VALUE]
更新卷:volume update [VOLUME NAME] --deleteLockTime=[VALUE]
在github上编辑