- 글 작성 순서
- 1. JWT
- 2. Security
- 3. No SQL과 Redis
- 4. 조사 후 이해한 결과
1. JWT ( JSON WEB SOCKET ).
- 웹에서 사용되는 JSON 형식 토근에 대한 표준 규격
- 인증( Authentication ) 또는 인가( Authorization ) 정보를 서버와 클라이언트 사이에서 교환하기 위해 사용
- 구조
- <헤더>.<페이로드>.<서명> 으로 이루어짐
- 각 부분은 Base64으로 인코딩 되어있다
- 헤더( Header )
- 알고리즘과 토근의 타입에 대한 정보를 가짐
- alg( 알고리즘 ), typ( 토큰타입 )
- 페이로드( Payload )
- 클레임( Claim )이 담김 클레임은 키/값의 형태로 된 값을 가짐
- 저장되는 정보에 따라 등록된 클레임( registered claim ), 공개 클레임( public claim ),
비공개 클레임( private claim )으로 구분
- 등록된 클레임( registered claim )
- 토큰에 대한 정보를 담기 위한 클레임, 이름이 이름이 등록되어 있다.
- 공개, 비공개 클레임에 포함될 수 있다.
- iss( 토큰 발급자 )
- sub( 토큰 제목 )
- iat( 토큰 발급 시간 )
- exp( 토큰 만료 시간 )
- aud( 토큰 대상자 )
- nbf( 토큰 처리 시작 시간 )
- jti( 고유 식별자 = 일회용 토큰 )
- 공개 클레임( public claim )
- 공개되어있는 클레임
- 공개되어도 상관없는 정보를 전달하는데 사용( 예: 이름, 이메일 등 )
- 비공개 클레임( private claim )
- 비공개되어있는 클레임
- 로그인 정보같은 민감한 정보를 전달하는데 사용( 예: Id, Pw 등 )
- 장점
- 사용자의 정보를 저장하는 기존 Cookie나 Session 에 비해 차지하는 용량이 일반적으로 적다.
- 인증에 대한 정보를 클라이언트에서 저장하고 서버는 비밀키 정보를 가지므로 서버는 검증 후 권한여부만
확인하면 된다.
- 단점
- 입력 데이터가 많아져 토큰의 크기가 커지게 되면 전송에 사용되는 네트워크 대역폭이 커질 수 있다.
- 클라이언트에서 jwt를 저장하므로 탈취의 위험이 있다.
- 서버가 사용자에게 토큰을 주게 되면 수정, 폐기가 불가하다( Access Token, Refresh Token을 사용해 보완가능 )
- 서명( Signature )
- 헤더에서 선언한 알고리즘과 Key를 이용해 암호화 한 값
- 헤더에서 선언한 알고리즘으로 디코딩 후 서버 측과 비교하여 일치해야한다.
2. Spring Security
- 스프링 기반의 웹 애플리케이션의 인증과 인가를 처리하는 역할을 하는 프레임워크
- 보안 관련 기능을 구현하는 서비스 개발에 사용된다.
- DispatcherServlet 앞에 있는 Filter 단에서 기능을 수행한다.
- 인증( Authentication ) 과 인가( Authorization )
- 인증( Authentication )
- 사용자의 신원을 검증하는 행위
- 인가( Authorization )
- 사용자에게 권한을 부여하는 행위
- Security Filter Chain
- Security Filter의 리스트
- Security Filter 종류
- WebAsyncManagerIntergrationFilter
- 비동기 요청을 지원하기 위한 필터
- 비동기 요청 시에도 SecurityContext를 사용가능하도록 한다.
- SecurityContextPersistenceFilter
- SecurityContext가 없을 시 만들기 위한 필터
- SecurityContext : Authentication( 인증 ) 객체를 보관하는 인터페이스
- HeaderWriterFilter
- 응답에 보안과 관련된 헤더를 설정하는 필터
- 포함된 5가지 종류
- X-Content-Type-Options : 서버에서 요청하는 MIME을 따르도록 지시( MIME 타입 스니핑 공격을 방지 )
- X-Frame-Options : 서버가 제공하는 페이지가 다른 프레임에서 로드되지 않도록 지시( 클릭재킹 공격 방지 )
- 설정 가능한 값
- DENY : 금지
- SAMEORIGIN : 같은 출처의 프레임( 동일 페이지 )에 한해서 허용
- ALLOW-FROM : 전부 허용
- X-XSS-Protection : 브라우저에 내장된 XSS 필터를 활성화하도록 지시( 1; mode=block 를 같이 사용 )
- Content-Transport-Security : 로드되는 출처를 제한하여 XSS 공격을 방지( 스크립트 안에 넣어져 실행되는 쿼리 방지 )
- Strict-Transport-Security : HTTPS 통신을 사용하도록 지시
- CsrfFilter
- 허가된 사이트나 요청인지 확인
- LogoutFilter
- 사용자의 요청이 로그아웃을 원하는지 체크
- UsernamePasswordAuthenticationFilter
- 아이디, 패스워드로 로그인 가능한지 체크하고 승인이 될 시 인증을 부여, 설정한 페이지로 이동
- AuthenticationManager을 통한 인증을 실행하고 성공하면 생성한 인증객체를 SecurityContext에 저장
- 성공 시, AuthenticationSuccessHandler를 실행 실패 시, AuthenticationFailureHandler 실행
- ConcurrentSessionFilter
- 동시 접속 허용 여부 체크
- BearerTokenAuthenticationFilter
- 인가 헤더에 Basic 토큰을 인증해주는 역할
- RequestCacheAwareFilter
- 인증 후, 원래 요청했던 정보로 재구성 해주는 필터
- SecurityContextHolderAwareRequestFilter
- 보안 관련 Servlet 3 스펙을 지원하는 필터 => HttpServletRequest 및 HttpServletResponse를 제공하고 SecurityContextHolder를 공개
- RememberMeAuthenticationFilter
- 인증이 안된 경우 RememberMe 쿠키를 검사하여 인증처리 => 로그인 유지
- AnontmousAuthenticationFilter
- RememberMeAuthenticationFilter로도 인증이 안되었으면( 로그인 상태 아니면 ) 익명 사용자의 상태로 인증하는 역할
- 인증객체를 새로 생성
- SessionMangementFilter
- SessionId를 계속 변경하여 사용자에게 주므로 세션 변조 공격을 방지
- 1개의 sessionId 당 최대 동시 접속 수 설정
- 유효하지 않은 세션으로 접근 시, URL 핸들링
- ExceptionTranslationFilter
- 인증/인가 예외가 발생한 경우 예외처리 하는 필터
- FilterSecurityInterceptor
- 인가를 결정하는 AccessDecisionManager에게 접근권한이 있는지 확인
- 요청에 인가 정보가 있는지 체크하고 없을 시, ExceptionTranslationFilter로 예외처리
- Filter Chain이 적용되는 URL 설정
- authentication() : 인증된 사용자의 접근을 허용
- permitAll() : 모든 사용자 허용
- denyAll() : 모든 사용자 거부
- hasRole( Role ) : 해당 권한에 해당되는 사용자만 허용
- hasAnyRole( Role... ) : 권한 목록 중 하나라도 해당되면 허용
- hasIpAddress : 해당 IP를 가지고 있는 사용자인 경우 허용
- 3. No SQL과 Redis
No SQL
- Not Only SQL의 약자로 Oracle, MariaDB 같은 관계형 DB가 아닌, 비관계형 DB
- 대량의 분산된 비정형 데이터를 처리하는데 특화되어 빅데이터 처리, 분산 시스템 환경에 적합
- 가용성( Availablity )와 확장성( Scalability )에 중점이 맞추어짐
- 특징
- 비관계형을 가지므로 Join 연산이 불가
- RDBMS보다 더 대용량의 데이터를 저장 가능
- 분산형 구조를 가지고 있어 분산처리 및 병렬처리 가능
- 가변적인 테이블 스키마와 다양한 일관성 모델을 이용해 일관성 처리
- 종류
- 키-값 데이터베이스
- 키-값 쌍으로 데이터를 저장
- 스키마가 없을 수 있음
- 주로 실시간에 사용되는 데이터 처리에 사용
- 대표적인 DB : Redis
- 문서형 데이터베이스
- 데이터를 JSON이나 XML같은 형식으로 데이터를 저장
- 각 문서는 고유한 키를 가지고 필드와 값으로 구성
- 각 문서는 서로 다른 구조를 가질 수 있음
- 대표적인 DB : MongoDB
- 열 지향 데이터베이스
- 관계형 데이터베이스와 같은 행으로 데이터를 저장하는 방식과 달리 열 기반으로 데이터를 저장
- 각 열은 다른 키-값의 집합으로 구성되며 노드 간 분산되어 대량의 데이터를 나눠 저장할 수 있고
빠르게 조회할 수 있다.
- 대표적인 DB : HBase
- 그래프 데이터 베이스
- 노드와 엣지의 집합으로 데이터를 표현
- 복잡하게 연결되어 있는 데이터를 관리하는데 특화
- 노드 : 객체/엔티티
- 엣지 : 노드 간의 관계
- 대표적인 DB : Amazon Neptune
- 시계열 데이터 베이스
- 시간에 따라 정렬된 데이터를 저장하고 쿼리하는데 특화된 데이터베이스 센서, 로그, 이벤트 데이터와 같은
시계열 데이터를 처리하는데 유용
- 대표적인 DB : Prometheus
Redis
- No SQL 의 종류 중 하나인 키-값 데이터베이스
- 디스크가 아닌, RAM에 저장되는 방식인 인 메모리 방식 사용
- 인증한 사용자의 정보를 다시 사용하려할 때 DB를 거치지 않기 위해 사용( 캐시서버 )
- 인 메모리 방식을 사용하므로 전원이 꺼지면 데이터가 휘발되지만 이를 방지하기 위한 방식을 가짐
- AOF( Append On File )
- Redis의 모든 Write / Update 연산을 로그파일에 기록
- RDB( Snapshotting )
- 순간적으로 메모리에 있는 내용 전체를 디스크에 담아 저장
- 다양한지원 데이터 타입
- String : 문자열
- Lists : 연결 리스트
- Sets : Set
- Sorted Sets : 정렬된 Set
- Hashes : Hash
- Streams : 시계열 데이터(?)
- Bits( Bitmaps ) : BitMap
- HyperLogLog( PF ) : ??
- GEO( Heospatial ) : Sorted Set을 활용해 데이터 저장
- BloomFilter : ??
- 4. 조사 후 이해한 내용
- 1. 사용자가 로그인 시, 서버의 Spring Security에서 인증 체크 후 정보가 있다면 redis에 계정정보 저장 후 인증 상태 처리
- 2. 인증이 성공이라면 사용자에게 토큰 발급
- 3. 그 후 사용자의 요청을 받을 때 사용자가 jwt 토큰을 이용해 서버에게 요청할 시, 서버는 사용중인 비밀키를 이용해 요청을 한 사용자가 정말로 인증상태로 처리한 사용자가 맞는지 비밀키와 Redis에 저장된 정보를 이용해 확인
- 3-1. 맞다면 인가 여부 확인 후 처리
- 3-2. 아니라면 요청 거부