怎样做联盟网站,电子工程网络工程维修记录次数,网站建设需要学那些,旅游网站自己怎么做简介#xff1a; 本文讨论了自建Nacos和阿里云MSE的配置安全原理。并提出配置安全最佳实践。
作者#xff1a;鲁严波
前言 配置管理作为软件开发中重要的一环#xff0c;肩负着连接代码和环境的职责#xff0c;能很好的分离开发人员和维护人员的关注点。 Nacos的配置管理…简介 本文讨论了自建Nacos和阿里云MSE的配置安全原理。并提出配置安全最佳实践。
作者鲁严波
前言 配置管理作为软件开发中重要的一环肩负着连接代码和环境的职责能很好的分离开发人员和维护人员的关注点。 Nacos的配置管理功能就很好地满足了云原生应用对于配置管理的需求既能做到配置和代码分离也能做到配置的动态修改。 在1月份Nacos出了一个安全漏洞外部用户能够伪装为Nacos-server来获取/修改配置 https://github.com/alibaba/nacos/issues/4593 。确认问题后Nacos火速修复了漏洞而阿里云的微服务引擎MSE也已在1月末将修复方案反向移植到MSE上的Nacos实例上。 在本文中我们将会从全局视角入手讨论如何才能保证Nacos配置的安全性security即如何保证配置信息不被恶意用户获取或者泄漏。
Nacos配置架构 Nacos配置部分的整体架构如下 对于上图中的每一条链路都需要考虑有没有两个基本的安全动作认证Identification和鉴权Authentication 从上图可以看到配置信息可能的泄漏方式有 通过Nacos-client获取配置通过控制台获取配置通过服务器之间的通信协议获取配置直接访问持久化层比如DB获取配置
可能的泄漏点如下 认证 鉴权 Nacos 客户端 未登录用户通过客户端获取/修改配置 用户通过客户端获取/修改了未授权的配置 配置控制台 未登录用户通过控制台获取/修改配置 用户通过控制台获取/修改了未授权的配置 Nacos集群内 用户伪装为Nacos集群获取/修改配置 不需要 持久化层 用户直接查DB获取/修改配置 不需要 Nacos客户端场景的认证和鉴权 在Nacos客户端尝试从服务端获取配置时服务端需要确认客户端的身份并确认该身份有权限获取配置。 开源版本的Nacos 在默认的Nacos server配置中不会对客户端鉴权即任何能访问Nacos server的用户都可以直接获取Nacos中存储的配置。比如一个黑客攻进了企业内网就能获取所有的业务配置这样肯定会有安全隐患。 所以需要先开启Nacos server的鉴权。在Nacos server上修改application.properties中的nacos.core.auth.enabled值为true即可 nacos.core.auth.enabledtrue 如上设置后Nacos客户端获取配置时需要设置上对应的用户名和密码才能获取配置
String serverAddr {serverAddr};
Properties properties new Properties();
properties.put(serverAddr, serverAddr);
properties.put(username,nacos-readonly);
properties.put(password,nacos);
ConfigService configService NacosFactory.createConfigService(properties); 上面讲了如何认证用户即如何确定现在是哪一个用户在访问但还需要识别用户的权限当用户访问没有权限获取对应配置的时候比如库存服务尝试获取支付服务的配置时就会失败。 我们可以在开源的Nacos控制台上创建用户、设置权限。步骤如下 首先访问 localhost:8848/nacos 并登录在权限控制-用户列表页面添加用户 在权限控制-角色管理绑定用户和角色 给对应角色添加权限在权限控制-权限管理页面添加权限 经过如上配置后readonly-user就只能访问public命名空间下的配置了。 阿里云MSE-AK/SK 对于小团队用用户名和密码来做认证鉴权是足够的。但对于中大型团队密码的定期更换、人员的频繁变动等都会导致用户名和密码频繁变动。 这时使用用户名和密码认证鉴权就需要频繁修改并发布应用。为了解决这个问题Nacos也提供了基于ak/sk的认证方案、ECS关联Ram角色的方案可以避免用户名和密码修改导致的频繁发布问题。 以阿里云MSE为例阿里云用户已经普遍使用了阿里云访问控制服务RAM作为权限系统如果MSE和开源一样使用用户名和密码实现认证和鉴权的话那么用户就需要在RAM和MSE Nacos两个地方配置权限。这样既不方便用户权限的统一管理、审查也给用户带来了不一致的体验。 所以MSE微服务引擎提供了基于ak/sk的认证方式操作示例如下 首先在MSE上申请一个Nacos实例并记下实例id然后在实例详情-参数设置界面将ConfigAuthEnabled配置鉴权参数设置为true这样匿名用户就无法获取配置 然后就可以在阿里云RAM系统上配置相关权限。RAM子账号的权限系统可以简单表示如下 第一步创建RAM权限策略如下 图中mse:Get*、mse:List*、mse:Query*表示能读取配置mse:*表示所有权限包括修改权限。 acs:mse:*:*:instance/${instanceId}表示授权到实例级别acs:mse:*:*:instance/${instanceId}/${namespaceId}表示授权到命名空间级别。 第二步创建用户并赋予权限 填写用户名称 然后获取到用户的ak/sk 给这个用户对应的权限 最后只需要在代码中添加ak/sk就可以了 String serverAddr {serverAddr};
Properties properties new Properties();
properties.put(serverAddr, serverAddr);
properties.put(PropertyKeyConst.ACCESS_KEY, ${accessKey});
properties.put(PropertyKeyConst.SECRET_KEY, ${secret});
ConfigService configService NacosFactory.createConfigService(properties); 经过如上配置客户端在访问MSE上购买的Nacos实例的时候MSE会校验AK和签名确认该用户是合法的用户并校验权限否则拒绝提供服务。 阿里云MSE-基于ECS的Ram角色认证 当然在上面的使用方式中还是要在初始配置比如srping-cloud-alibaba-nacos-config中的bootstrap.yml文件中配置AK/SK。黑客入侵内网、或者源码泄漏时也会存在AK/SK泄漏导致配置信息泄漏的风险。 在这种情况下推荐使用ECS关联的RAM角色来做认证。 ECS关联RAM角色对应的授权模型如下 上述的关键步骤在角色扮演。只有关联了RAM角色的云服务器才能成功扮演角色从而获取操作MSE Nacos实例的权限。 如果黑客只获取了代码也无法成功扮演RAM角色无法操作MSE Nacos实例。
如果机器被攻破那也能在阿里云控制台上取消云服务器关联的角色及时止损。
具体的操作步骤如下 第一步创建MSE Nacos实例并创建对应的权限策略上文有说明此处不赘述。 第二步创建RAM角色并授权 创建RAM角色 创建角色后为该角色添加对应的权限策略 第三步将该角色和ECS关联 在对应的ECS详情页面点击授予/收回RAM角色 选择对应的角色并授予 最后一步在代码中指定RAM角色即可 String serverAddr {serverAddr};
Properties properties new Properties();
properties.put(serverAddr, serverAddr);
properties.put(PropertyKeyConst.RAM_ROLE_NAME, StoreServiceRole);
ConfigService configService NacosFactory.createConfigService(properties);
经过如上配置Nacos客户端在获取配置时云服务器会扮演指定的RAM角色阿里云临时安全令牌Security Token ServiceSTS来访问MSE Nacos实例。 如果攻击者获取代码也无法在其他机器上运行因为攻击者的机器没有扮演RAM角色的权限。 如果攻击者获取扮演之后的认证信息由于STS失效较短默认是1小时攻击者拿到后很快就失效有效减少了攻击面。 如果需要撤销授权只需要在阿里云控制台上就可以操作不需要重新发布应用。 相比于AK/SK方式的认证鉴权ECS关联角色的认证鉴权更可控、更安全所以推荐使用这种认证鉴权方式。
配置控制台场景的认证和鉴权 开源版本的Nacos 开源版本的Nacos控制台在登录的时候会通过控制台的login接口获取临时的accessToken然后后续的操作都是以accessToken来做认证鉴权。 比如前文提到的readonly-user用户登录后就只能看到public命名空间下的配置信息无法修改、无法查看其他命名空间下的配置信息。 另外如果需要创建命名空间、删除命名空间则只能管理员登录才可以。
开源版本Nacos的认证鉴权可以参考该文档https://nacos.io/zh-cn/docs/auth.html
阿里云MSE
阿里云MSE由于是对企业提供服务所以在权限的划分上会更加精细。 资源的分为实例级别acs:mse:*:*:instance/${instanceId}和命名空间级别acs:mse:*:*:instance/${instanceId}/${namespaceId}。 对资源的操作也更加精细比如 Action 说明 CreateEngineNamespace 创建命名空间 DeleteEngineNamespace 删除命名空间 mse:Get*,mse:List*,mse:Query* 读取配置Nacos 客户端和控制台 mse:* 所有权限包括修改、删除配置 mse:QueryNacosConfig 客户端读取配置 mse:UpdateNacosConfig 客户端修改配置 比如只允许读取一个命名空间下的配置不允许修改。那权限策略就可以写 {Action: [mse:Get*,mse:List*,mse:Query*],Resource: [acs:mse:*:*:instance/${instanceId}/${namespaceId}],Effect: Allow
} 服务器之间的认证 Nacos服务器之间需要同步一些信息这时也需要认证对方身份以确认对方真的是Nacos-server而不是伪装的。 在1.4.1之前是通过User-Agent这个header来认证的这种原始的认证方式很容易被伪造。本文开头提到的1月份Nacos爆出的漏洞就是这个原因。 所以1.4.1及之后的版本认证的header以及对应的值可以自己配置。在application.properties中修改如下值即可 # 不使用User-Agent来认证
nacos.core.auth.enable.userAgentAuthWhitefalse
# 认证header的key
nacos.core.auth.server.identityAuthorization
# 认证header的value
nacos.core.auth.server.identity.valuesecret 这样只有发送了header Authorization: secret 的请求才能确认对方是服务端才能同步集群信息否则就拒绝同步。 由于Nacos-server需要全部权限才能同步配置数据所以对于Nacos-server之间则不需要做鉴权。 这样就能让服务器之间的通信也能做到安全可信了。 阿里云MSE上购买的Nacos实例也已经将上述方案反向移植到了1.2版本上也不会有对应的安全问题。 持久化层的安全 Nacos的配置信息都是存储在持久化层的。比如Nacos默认的持久化层是MySQL。
为了防止通过git或者其他方式将MySQL的用户名和密码泄漏出去我们需要定时修改MySQL的用户名和密码。 通常的做法是使用两个数据库用户比如UserA和UserB。如果要更新密码则按照如下方式操作 将Nacos server访问数据库的用户从UserA切换到UserB更新UserA的密码将Nacos server访问数据库的用户从UserB切换回UserA更新UserB的密码作为阿里云产品MSE都有定时修改数据库用户名密码的策略所以如果您购买了MSE实例则不需要担心此问题。
配置安全最佳实践 捋了一遍Nacos配置安全的关键点那么怎么才能保证配置安全呢。只需要做到如下最佳实践就可以了 定期修改密码和ak/sk在使用Nacos用户名密码或者ak/sk认证的情况下比如使用开源Nacos认证方式如果恶意用户拿到了Nacos的用户名和密码或者ak/sk那么他就有可能拿到应用的配置。但如果定期修改了密码或者ak/sk的话就能有效限制配置泄漏的时间段减少攻击面。 使用ECS角色推荐用法当然在上面的解决方案中还是会有Nacos用户名密码或者ak/sk在配置中的而且这些信息的也有可能泄漏泄漏后的修改也需要重新发布才可以。所以推荐使用阿里云的ecs角色所有的权限管理都是在阿里云控制台上完成。 轮转Nacos内部认证的key前文有提到Nacos服务器之间的认证是通过nacos.core.auth.server.identity来完成的但如果恶意用户入侵也会导致泄漏从而导致配置泄漏。 所以对于自建Nacos需要定期更换nacos.core.auth.server.identity.value确保恶意用户无法伪装为Nacos server来获取、修改配置。 当然如果您使用的是MSE托管的Nacos实例的话MSE会自动轮转您可以不用担心这一点。 轮转持久化层的用户名和密码为了防止配置从持久化层泄漏出去所以需要定时修改持久化层的认证信息。通常Nacos的持久化层都是DB所以需要定时修改数据库的用户名和密码。 对于MSE用户则不需要做任何操作MSE内部会定时修改数据库的用户名和密码。 设计安全预案并定时执行有了如上重重保险理论上万无一失但是因为人的操作总有失误所以还是需要指定安全预案 定时检查配置的监听列表确认没有未授权的机器在获取配置ak/sk泄漏时该如何更新ak/sk如何撤销泄漏的ak/sk自建Nacos服务器被攻破后如何修改nacos.core.auth.server.identity.value的方案总结 开源的Nacos在配置管理、权限管理上能基本满足中小企业需求。 而对于中大型企业阿里云产品MSE支持更加精细、更加灵活的权限配置、安全管理也能利用和其他阿里云产品一起做到更加安全的配置能力。 当然不论是自建Nacos还是使用阿里云MSE都需要关注上述提到的安全点防止配置信息泄漏造成业务损失。最后提到的配置安全最佳实践也能能保证配置泄漏后有能力及时修复做到防患未然。
原文链接
本文为阿里云原创内容未经允许不得转载。
