암호화(양방향, 단방향, 대칭키, 비대칭키)

양방향 알고리즘

암호화된 암호문을 복호화 할 수 있다. 

알고리즘: 대칭키 방식, 비대칭키 방식

단방향 알고리즘

암호화 하되 복호화는 할 수 없다.

알고리즘: Hash 방식

HASH는 단방향 암호임. MD5, SHA 등의 해쉬 함수가 있음. 근데 MD5, SHA-1, HAS-180은 보안이 뚫렸기 때문에 SHA-256, 512를 써야 함. 

참고로 안좋은 HASH는 중복이 있기 때문에 중복이 적을수록 좋은 해시임.

보안을 더 철저히 하려면 salt값을 적용하는 방법 또는 Hash 함수를 여러번 돌리는 방법 등이 있음.

여튼 개발자는 어떤걸 잘 쓰면 될지를 알면됨

pbkdf2 : 솔트값과 해시함수의 반복횟수등을 지정할 수 있다. 

bcrypt : 패스워드를 위해 탄생해서 아주 강력한 해시 알고리즘이 적용됨. 마찬가지로 검색해서 사용 (Spring security에서 사용함)

대칭키 방식

암호화/복호화 시 동일한 키를 사용한다.

키는 비공개

속도가 빠르다

키 노출 우려 있다

DES

AES(취약점 보안을 많이 하여 안정성이 높다?)

비대칭키 방식

암호화/복호화 시 다른 키를 사용한다.

하나의 키는 공개키, 나머지 하나는 비공개(=대칭키)

키 안정성이 높다

상대적으로 느리다

RSA (디지털 서명)

키1, 키2라고 했을 때, 키1로 암호화 한 암호문은 키2로만 복호화 할 수 있고, 키2로 암호화 한 암호문은 키1으로만 복호화 할 수 있다.

중간자 공격(MITM: Man In The Middle Attack)에는 취약하단다. 

(중간에서 통신을 가로채어 수신자에게 송신자인척 하면서 대칭키까지 얻어냄..)

** 비대칭키 사용? TLS(Transport Layer Secure)에서 씀. RSA알고리즘 일듯.

TLS는 보편적인 Secure layer라고 보면 되고 HTTP에 TLS를 입히면 HTTPS가 되는 거임.

참고: https://jeong-pro.tistory.com/92

https://meetup.toast.com/posts/239?fbclid=IwAR2Pk1A969Jg_CK2D5KRzawvAJHQl1ZUscP50bSzLW5CAa8BjSUMWhXJqlA

JWT

Base64 URL-Safe 인코딩된 문자열(ASCII 로 변환해줌. 그냥 ASCII로 변환하면 플랫폼별로 8비트중 1비트 처리 방식이 다른 경우가 있어서 안좋은 모양)

ES256(키 생성 알고리즘으로 ECDSA(Elliptic Curve Digital Signature Algorithm, 타원곡선 디지털 서명 알고리즘) 중 하나인 ES256(P-256 + SHA256)을 사용한다. 블록체인에서 사용하는 알고리즘인데, JWT에서도 많이 사용하는 알고리즘인 것 같다.)

(SHA-256만 쓰면 단방향 암호화이기 때문에 위 알고리즘을 더 많이 쓰는 듯하다.)

JWT in MSA

1. Access Token 

일반적으로 권한 제어가 필요한 웹 서비스는  로그인을 통해 사용자 인증(Authentication)을 진행한다. 

액세스 토큰(Access Token)을 발급한다. 

참조 토큰(By Reference Token)이라 부른다. 

모놀리스(Monolith) 아키텍처에서는 참조 토큰을 액세스 토큰으로 사용해도 큰 문제가 없다. 

하지만 수많은 서비스 간 API 호출이 발생하는 MSA(Micro Service Architecture) 환경에서는 모든 서비스들이 권한 서비스와 통신을 해야 한다. 

권한 서버가 받는 부하는 늘어날 수 있다. 

확장성(Scalability)에 부담을 줄 수 있다.

2. JWT 

참조 토큰 대신 JWT를 액세스 토큰으로 사용할 수 있다. 

JWT는 자체적으로 필요한 정보를 모두 담을 수 있기 때문에 값 토큰(By Value Token)이라 한다. 

MSA 환경의 인증과 접근 제어에 적합하다. 

서비스는 JWT에 포함된 값을 기준으로 권한을 확인할 수 있다. 

서비스와 권한 서비스의 통신은 JWT 서명을 인증하기 위한 공개 키를 조회하는 게 전부다. 

단점으로는 사용자에 대한 권한이나 정보가 변경되는 경우 JWT를 새로 발급해야 하며, 경우에 따라 JWT의 크기가 커질 수 있다. 

그리고 JWT의 헤더나 페이로드는 디코딩(Decoding)하면 바로 내용을 확인할 수 있기 때문에 JWT의 모든 값들은 클라이언트에게 공개된다. 

외부에 노출되어서는 안되거나 민감한 값이 노출될 수 있어 보안 문제로 이어질 수 있는 단점이 있다.

클라이언트, 권한 서비스, 서비스 사이에 API Gateway를 위치시키면 JWT를 클라이언트에게 숨기면서 서비스간 통신 시 사용할 수 있다. 

API Gateway는 클라이언트에게 받은 액세스 토큰을 권한 서비스를 통해 JWT로 받아 액세스 토큰 대신 서비스로 넘겨준다.

spring filter, security, 좋은 글

http://blog.naver.com/PostView.nhn?blogId=kbh3983&logNo=220932183498&redirect=Dlog&widgetTypeCall=true