Spring Security 구조에 대해서 - SecurityFilterChain

2023.12.09 - [웹/Spring] - Spring Security 구조에 대해서 - FilterChainProxy

Spring Security 구조에 대해서 - FilterChainProxy

이전에는 FilterChainProxy에 대해서 간단히 작성해봤는데요.

솔직히 이전 내용이 이해가 어려운 내용이었습니다. 일단 FilterChainProxy가 SecurityFilterChain에게 역할 위임한다는걸로 이해를 했습니다.

 

이번엔 SecurityFilterChain에 대해서 작성해보려고 합니다.

 

SecurityFilterChain은 요청에 대해 호출되어야하는 Spring Security Filter 인스턴스를 결정하기 위해 FilterChainProxy에서 사용됩니다.

즉 FitlterChainProxy를 사용하여 SecurityFilterChain을 요청한다는 말인듯합니다.

구조를 확인해보겠습니다.

그림에서도 보시면 FilterChainProxy에서 

SecurityFilterChain안에 SecurityFilter는 Bean들이 있습니다.

보시면 DelegatingFilterProxy대신에 FilterChainProxy로 등록됩니다.

 

 FilterChainProxy는 결국 SecurityFilter Bean을 등록해주는 역할이라고 생각하면 좀 편할것 같습니다(맞겟죠? 제가 이해한게 ㅎㅎ 틀리면 지적 부탁드립니다 ㅠ )

 

첫번째는 Spring Security의 모든 서블릿 지원에 대한 시작점을 제공합니다.

그 이유로는 만약에 Spring Security  서블릿 지원시 트러블 슈트(문제해결) 시도 한다면 FilterChainProxy에 디버그 포인트를 추가하는것이 시작히기에는 좋은 방법이다.

라고 하는데요. 즉 문제 해결을 위해서 Spring Security  서블릿 지원에 관련해서는 시작점에서 제공한다는 얘기 같습니다.

 

두번째는 FilterChainProxy는 Spring Security 사용되는건 필수적이기 때문에 필수적으로 보이지 않는 작업들도 수행할수 있습니다.

즉 Spring Security는 사용되는건 무조건인데 별로 필요없는것들도 함께 작업이 수행될수 있다는 의미인듯합나다.

예를들어 메모리를 leak(부족)을 회피하기 위해 SecurityContext를 비웁니다. 또한 특정 유형의 공격으로부터 애플리케이션을 보호하기 위해서 HttpFirewall을 적용합니다.

(여기서 HttpFirewall은 Spring Security에서 웹 애플리케이션을 다양한 웹 기반 공격으로부터 보호하기 위해 요청을 필터링하는 보안 기능입니다. 나중에 HttpFirewall 에 대해서도 작성해보도록 하겠습니다 지금은 보안해주는 역할정도로만 이해하도록 하겠습니다.)

또한, SecurityFilterChain이 언제 호출될지 결정하는데 더 큰 유영성을 제공합니다. 서블릿 컨터이너에서, 필터 인스턴스는 URL에만 근거하여 호출이 됩니다. 그러나 FilterChaingProxy는 RequestMatchr 인터페이스를 사용하여 HttpServletRequet내의 어떤 것에 근거하여 호출을 결정할수 있습니다.

(여기서 RequestMatchr는 특정 조건에 따라 보안처리를 결정하는데 사용된다고 합니다. 저도 정확한건 찾아보고나서 따로 설명해도록 하겠습니다.)

 

이번에 Multiple SecurityFilterChain 인스턴스들 이미지 입니다.

 

Multiple SecurityFilterChaind보시면 FilterChainProxy는 SecurityFilterChain을 사용하는데 결정합니다.

 매칭되는 첫번째는 SecurityFilterChain만 호출됩니다. 만약 api/message/url 요청딘다면, 이는 /api/ 패턴의 securityFilterChain0과 먼저 매칭되므로, SecurityFilterChain과도 매칭되더라도 오직 SecurityFilterChain(0)만 호출됩니다.

/message/url이 요청되면, 이는 /api/패턴의 SecurityFilterChain (0) 와 매칭되지 않으므로, FilterChainProxy는 다른 모든 SecurityFilterChain 을 시도합니다. 다른 어떤 SecurityFilterChain 인스턴스가 매칭되지 않는다면 SecurityFilterChain(n)이 호출됩니다.

 

그림을 보면

SecurityFilterChain(0)는 단 3개의 보안 필터 인스턴스만 설정되어 있음을 유의합니다. 그러나 SecurityFilterChain(n) 은 4개의 보안피러 인스턴스가 설정되어 있습니다. 각 SecurityFilterChain 은 고유할수 있으며, 독립적으로 구성할수 있습니다.

(즉  SecurityFilterChain 은 각각 역할로 url을 나눠서 필터링을 할수 있다는의미 같네요.)

실제로 어플리케이션이 특정 요청을 Spring Security가 무시하기를 원한다면 SecurityFilterChain 은 보안 필터 인스턴스 없이 구성할수 있습니다.

(음 보안 필터 없이 구성할수 있지만 왠만한 서비스는 전부 있어야는걸로 알고 잇어서 ㅎㅎ 악의적인 공격에 의해서 자칫하면 서버비 감당이 안되겟죠 ㅎㅎ) 

 

대략 정리하면 DelegatingFilterProxy(FilterChainProxy)=>호출=> URL 매칭 SecurityFilterChain 선택-> SecurityFilterChain(0)..... SecurityFilterChain  (N)  이런 느낌이네요.

다음엔 Securyt Filters에 대해서 알아보도록 하겠습니다.

 

참조:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-print-filters

Architecture :: Spring Security