Spring Security 기본

프로젝트에 Spring Security를 설정하면 모든 것이 보호되고 필터 체인을 통해 인증과 권한 부여가 가능하다.

 

Spring Security 작동 방식

Spring으로 웹 애플리케이션이나 REST API를 빌드할 때 백그라운드에서 Spring MVC를 사용한다.

작동 방식은 Request => Dispatcher Servlet => Controller 순이다.

 

요청이 들어오면, 모든 요청을 먼저 디스패처 서블릿에서 처리한다.

디스패처 서브렛은 URL, 즉 요청 메서드를 확인한 후 컨트롤러로 라우팅한다.

 

DispatcherServlet : 디스패처 서브렛은 프론트 컨트롤러 역할을 한다. 모든 요청을 인터셉트 해서 해당하는 컨트롤러에 라우팅 해준다.

 

Spring Security를 사용하면 

Request => Spring Security => Dispatcher Servlet => Controller 순이 된다.

 

들어오는 모든 요청을 Spring Security가 인터셉트해서 Spring Security Filter chain을 설정하고 이 필터 체인으로 요청을 인터셉트한다.

그리고 Spring Security가 인증과 권한 요청을 확인하게 되면 요청이 디스패처 서브렛으로 전송된다.

즉 한번 걸러준다.

 

Spring Security Filter chain

1. Authentication: 인증 제공 (Basic Authentication Filter)

2. Authorization: 유저가 접근 권한 가지고 있는지 확인 (AutorizationFilter)

3.Other Features:

              CORS(Cross-Origin Resource Sharing),

              CSRF(Cross Site Request Forgery, 사이트간 요청 위조, Spring Security 추가시 default 설정)

              Translating exceptions into proper HTTP Responses 에러에 대한 응답처리 변환 (Exception TranslationFilter)

 

Filter의 순서

1. 기본 체크 필터 - CORS, CSRF ....

2. 인증 필터

3. 권한 필터

 

---

Form Authentication

Spring Security는 기본적으로 폼 인증 사용

기본 폼 로그인 페이지, 기본 로그아웃 페이지, 로그아웃 URL 제공. ( JSESSIONID라는 NAME의 쿠키  활용)

 

사용자가 로그인 하면 세션 ID 쿠키가 생성되고, 이 세션 ID 쿠키를 바탕으로 로그인 인증

아마도 서버측 세션에 접근할 수 있는 세션 ID인 것 같다.

 

Basic Authentication

 

REST API나 마이크로 서비스를 빌드할 때에 있어 가장 기본 옵션이다.

단점이 많아서 프로덕션 환경용으로는 부적합하다.

단점 1. Base 64 인코딩은 디코딩 하기가 쉽다.

단점 2. 헤더에 권한 부여 정보를 가지고 있지 않다. (username, password만 있음)

단점 3. 만료일이 없음

 

-과정 -

Base 64 인코딩 username과 password가 request header로 전송된다.

- Authorization: Basic incoded(USERNAME,PASSWORD)

---

 

보안시스템 생성의 6가지 원칙

(공항의 예)

 

1. 들어오는 모든 요청에 대해서 의심해야 한다.

시스템에 들어오는 모든 데이터와 정보에 대해서 검증해야 한다

( 1. 여권, 신분증으로 인증을 거친다. )

 

2. 최소 권한 할당.

시스템 설계할 때부터 보안을 염두에 두어야 한다. 프로젝트를 시작하자 마자 보안을 구상해야 한다.

각 사용자에게 필요한 사용자 역할과 액세스 권한 명확히 정해야 한다.

모든 레벨에서의 최소한의 권한만 할당해야 함. => application, Infrastructure(database, server...) 

( 2. 모든 사람이 할당된 이상으로 권한 남용하지 않게 각 레벨에서 보안검사 수행. (기관사, 승무원, 승객 등) )

 

3. 완벽한 조율 구축

요청이 들어올 때마다 액세스 권한 확인해야 함

( 3. 공항의 입구는 명확하게 정해져 있고 이 곳을 통해서만 들어올 수 있다. 입구에서 권한(여권, 티켓)을 확인받는다. 확인받은 이후에만 시스템에 들어올 수 있음. )

 

4. 심층 방어 구축

어플리케이션을 빌드할 때 여러 레이어를 고려해야 하듯이 보안도 여러 층으로 구축해야 함.

(전송 레이어, 네트워크 레이어, 인프라스트럭처 레이어), 운영체제 레벨, 애플리케이션 레벨

( 4. 공항에서 여권과 탑승권을 여러번 확인받는다. (입구, 보딩 전, 비행기 안) )

 

5. 메커니즘의 효율성

아키텍처가 간단해야 한다.

( 5. 공항의 보안 절차는 간단해서 모든 사람이 쉽게 준수할 수 있다. )

 

6. 설계의 개방성 보장

보안 표준 사용, (JWT)

( 6. 전 세계 모든 공항에서 보안 표준이 적용된다. )