服务器访问控制微服务架构如何配

微服务架构下访问控制需分层设计：API网关统一拦截并鉴权（JWT/OAuth2、路径策略、动态权限校验）；服务间通信强制mTLS双向认证，配合证书自动轮换；服务内通过RBAC+ABAC混合授权实现资源级细粒度控制；注册与配置中心须独立加固鉴权及敏感信息加密。

微服务架构下的服务器访问控制，不是配一个开关就能生效的事，而是要分层、分角色、分通信链路来设计和落地。核心思路是：入口统一拦截、服务间可信通信、资源级细粒度校验。

API网关层做统一访问入口控制

所有外部请求必须经过网关，这是第一道防线。网关不只做路由和限流，更要承担身份鉴权与粗粒度权限裁决。

1. 集成OAuth 2.0或JWT验证，校验令牌有效性、签名、过期时间及scope范围
2. 配置路径级访问策略，例如/admin/**只允许ROLE_ADMIN角色
3. 调用权限服务（如自研PermissionService）动态判断当前用户对某接口是否有权，避免硬编码在网关规则里
4. 拒绝未携带合法令牌、签名失效或scope缺失的请求，直接返回401/403，不透传到后端服务

服务间通信启用双向TLS（mTLS）

内部服务调用不能依赖网络隔离，默认视为不可信环境，必须加密+双向认证。

1. 为每个服务签发唯一证书，注册中心（如Nacos/ZooKeeper）配合证书分发机制
2. 在RPC框架层（Dubbo、gRPC、Spring Cloud OpenFeign）开启mTLS选项，强制客户端和服务端互相校验证书
3. 禁用明文HTTP/HTTP2通信；Dubbo可配置dubbo.protocol.ssl=true，gRPC需设置ChannelCredentials
4. 证书有效期设为90天以内，并搭配自动轮换机制（如Vault + cert-manager）

微服务内部实现RBAC+ABAC混合授权

网关放行后，具体业务操作是否允许执行，由服务自身判断——这才是真正的权限落地点。

1. 基于角色（RBAC）：用@PreAuthorize("hasRole('ROLE_EDITOR')")控制控制器方法，角色信息从认证服务同步或本地缓存
2. 结合属性（ABAC）：对关键操作（如删除订单、修改价格）增加运行时校验，例如@PreAuthorize("@authService.canDeleteOrder(#id, #principal.username)")
3. 权限数据不写死在代码里，而是从统一权限中心（如Casbin或自研服务）按需加载，支持实时更新、无需重启
4. 敏感操作记录完整上下文（谁、何时、操作哪条数据、依据什么权限），用于审计追溯

注册中心与配置中心加固访问

注册中心（ZooKeeper/Nacos）和配置中心（Apollo/Nacos Config）本身也是攻击面，必须单独设防。

1. ZooKeeper启用SASL认证，或通过ACL限制world:anyone权限，仅允许服务节点IP白名单读写
2. Nacos开启鉴权（nacos.core.auth.enabled=true），对接LDAP或内置用户体系，禁止默认账号（nacos/nacos）直接使用
3. 配置中心敏感项（如数据库密码）必须启用加密存储，Apollo支持密文配置，Nacos需配合Secrets Manager或自研加解密插件
4. 所有管理后台（Dubbo Admin、Nacos Console、Kibana）强制HTTPS + 强密码 + 登录失败锁定 + 操作日志留存