참고
Session
NOTE
서버측에서 사용자의 상태정보를 저장하는 방식!
session을 활용한 로그인 흐름
⇒ 서버의 무상태성을 위해 session저장소를 따로두고 사용한다.
•
기존의 Session의 문제점 때문에(서버가 여러대인경우) DB(Redis)를 통해 Session을 저장했다
•
JWT를 사용하면 이 문제를 해결할 수 있다!
CIA(Confidentiality Intergrity Availbility)
NOTE
정보보호를 위해 지켜야하는 기본적인 3가지 원칙이다!
기밀성 - Confidentiality
A → B 통신에 C가 문서를 탈취한다 (기밀성 깨짐)
•
개인정보, 민감한 정보 등을 인가된 사용자에게만 허가해야 한다.
무결성 - Integrity
C가 문서를 탈취해서 위조한다 (무결성 깨짐)
•
내용의 변경이나, 훼손없이 정확하게 보존해야 한다.
가용성 - Availability
B가 위조된 문서를 받는다 (가용성 꺠짐)
•
항상 정상적으로 신뢰성 있는 서비스를 할 수 있는 상태
CIA를 지키는 방법(암호화, 수신 응답)
NOTE
보내는 문서를 암호화하고 정확하게 받았는지 응답해야 한다!
문서 암호화(열쇠전달 문제)
암호화를 했는데 B는 이걸 어떻게 열지..?
•
암호환 문서를 열 수 있는 열쇠를 어떻게 전달해야 하는가?
수신 응답(누가 보내는가 문제)
중간에 C가 탈취해서 데이터를 위조하면 잘못된 데이터를 받을 수 있다.
•
문서를 누가 보냈는지에 대한 문제가 있다.
RSA(Rivest, Shamir and Adleman, 비대칭 키 암호)
NOTE
공개키와 개인키를 이용한 암호화 방식!
•
RSA를 이용해서 위에서 언급한 CIA를 지키는 방법들에 대한 문제를 모두 해결할 수 있다.
RSA 특징
•
공개 키는 누구에게나 공개 되어있지만, 비밀 키는 개인이 잘 보관해야 한다.
•
공개 키를 사용해서 암호화한다(개인키로 만 열 수 있음)
•
비밀 키를 사용해서 복호화한다.(공개키로만 열 수 있음)
RSA가 CIA를 지키는 방법
가끔 헷갈리는데 A와 B의 공개키와 비밀키는 모두 다르다.
•
RSA의 전체적인 흐름
1.
A는 문서를 B의 공개키로 암호화한다. (암호화)
•
B는 자신의 개인키를 가지고 있으므로 열쇠전달 문제 해결
2.
A는 문서를 A의 개인키로 암호화한다. (서명 생성)
•
A의 공개키로만 복호화가 가능하므로 누가 보냈는가에 대한 문제 해결
3.
A는 문서를 B에게 보낸다.
4.
B는 문서를 A의 공개키로 복호화한다. (서명 확인)
5.
B는 문서를 B의 개인키로 복호화한다. (복호화)
RFC - Request for Comments
NOTE
인터넷 프로토콜이나 기술에 대한 개발 및 표준화를 문서이다!
저 많은 RFC가 정의되면서 인터넷이 발전되고 있는
•
RFC가 모여서 WWW가 만들어 졌다.
•
JWT는 RFC 7519에 정의되었다.