微服務鋪天蓋地的來,引入Spring Boot actuator框架是爲了服務作更好的監控與性能查看,Spring Boot actuator是一個爲原生端點增加了更多的指標和度量信息,分爲應用配置類,度量指標類。操作控制類,但是假如由於開發人員的疏忽把這些監控的請求地址都暴露出來了,攻擊者會通過服務的配置信息對服務進行攻擊,例如當我們訪問/mappings這個返回這個服務控制器映射關係報告,可以查詢到所有的服務接口信息包括參數信息,這樣太可怕了 都看到了。
那麼這麼解決呢
1.修改原始的訪問路徑(在Spring Cloud Eureka環境中)
endpoints.info.path=/appInfo
endpoint.health.path=/checkHealth
eureka.instance.statusPageUrlPath=/${endpoints.info.path}
eureka.instance.healthCheckUrlPath=/${endpoint.health.path}
2.角色管理
上面的思路還是感覺不妥只是重定向了~
思路是我把所有的actuator的訪問地址賦予一個角色,這個角色在賦予人 這個人就擁有訪問autuator的權限了。
可以使用Spring Cloud Security權限框架 和Shrio權限框架,當然可以寫過濾器和攔截器都只是前兩者更方便一些。
以Shrio配置爲例
filterChainDefinitionMap.put("/notice/refresh", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/pause", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/env", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/env/reset", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/restart", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/autoconfig", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/metrics", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/metrics/**", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/info", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/dump", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/logfile", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/beans", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/health", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/configprops", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/env", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/env/**", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/trace", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/mappings", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/heapdump", "userAuth,roleAuth");
filterChainDefinitionMap.put("/notice/resume", "userAuth,roleAuth");
3.配置管理端口(推薦)
配置管理端口該端口不對外暴露