Contents
만약 서버에 부하가 생긴다면?
상태정보를 저장하고 있어 stateful
Spring Security Authentication Architecture
secutiry문지기가 authentication 시큐리티컨피그를 보고 일한다
User를 Principal를 씌우기만하면된다
권한이 뭐있는지 확인
securitycontext는 스레드세이프(그 스레드만 들어갈수 있게 해줌)
인증을 했다는거는 authentication객체를 만들어서 사용한거
Login
프록시(proxy)
클라이언트와 서버 사이에서 중개 역할을 수행하는 서버
- 포워드 프록시 : 중국을 빠져나올때 막히는 것
클라이언트가 외부 리소스에 접근할 때 클라이언트의 요청을 받아 외부 리소스로 전달
- 리버스 프록시 : 중국을 빠져나가서 구글앞에서 막히는것
서버의 앞단에 위치하여 클라이언트의 요청을 받아 백엔드 서버로 전달
- 프록시 클래스 → 프록시 이메일을 바라보고 의존 → 프록시를 바꿔 끼울 수 있음
객체 지향 프로그래밍에서 다른 객체에 대한 접근을 제어하는 용도로 사용
- 델리게이트 필터 프록시 : 위임하는 프록시, 대리인
서블릿 필터의 동작을 대리(delegate)하며 필터의 처리를 커스터마이징할 수 있도록 지원
만약 서버에 부하가 생긴다면?
- 스케일 업
아무리 메모리를 늘려도 결국은 IO가 필요하다
웹특성상 IO가 많은데 memory가 HDD로 정보를 줄때/ 데이터를 끌어올릴때 IO로 올리기때문에 CPU 연산속도가 빨라도 소용이없음
- 스케일아웃
스케일 아웃을 할때 다른 서버에 저장된 jsessionid가 없는 문제점이 있음
해결법
- sticky sessions
로드밸런서에서 해당 서버가 가지고 있는 jsession아이디를 기억하고 해당 아이디를 호출할때 해당 서버로 간다
그치만 가지고 있는 서버에 접속자가 많으면 문제가 해결되지않는다
- 복제
모든 SESSION에 REQUEST요청을 해서 동기화시킴
폴링 : 주기적으로 세션 데이터를 검사하고 업데이트한다
하지만 실시간 성능이 보장되지 않는다
- DB에 JessionID 저장
하지만 IO가 일어나기 때문에 많은 시간이 걸림
- 메모리 DB에 JessionID저장
메모리를 쓰는 DB를 사용(Redis, MemCache)
3번의 DB 단점 극복하였다.
그렇지만 메모리를 사용하기 때문에 최소한의 정보를 저장해야함.
대칭키
세션을 상태를 저장하고 있지만 이 시스템은 열쇠를 가지고 있어
상태를 저장하지 않아 stateless이다
단점 : 다른버스에 열쇠를 주기 힘듬
통신으로 전달하면 해킹위험있음
토큰의 신뢰성검사는 버스회사에서만 할 수 있어 토큰 계속 쓸 수밖에없음
프록시를 이용하여 프록시가 열쇠를 가지게 만든다
→서버마다 키를 안가져도됨
세션은 유저정보를 지니고 있기때문에 만들 수 없음
공개키 시스템(RSA알고리즘)
대칭키는 통신이 일어나면 보안이 힘들어진다 대신 RSA알고리즘은 보안에 강하다
A에서 B로 암호를 전달하기 위해서 B공개키를 이용하여 잠그면 B비밀키를 이용해서 풀 수 있기 때문에 C에서는 접근할 수 없다 →기밀성을 지킬 수 있다
만약 C에서 암호를 가로채 버리게 된다면 가용성을 지킬 수 없게 된다→많이 보내면 가용성을 지킬 수 있음
만약 C가 A로 위장해서 B로 암호를 보낼 때
A에서 비밀키를 이용하여 한번 더 감싸준다 → 그러면 A가 보낸거를 알 수 있음
B에서는 1. A공개키를 이용하여 열고 2. B비밀키를 이용하여 연다
전자서명으로 사용할 수 있게 된다
보안의 3요소
기밀성(Confidentiality): 기밀성은 정보에 대한 접근을 제한하고, 인가되지 않은 사용자로부터 보호하는 것을 의미합니다. 기밀성을 유지하기 위해 암호화 기술과 접근 제어 메커니즘 등을 사용할 수 있습니다.
무결성(Integrity): 무결성은 정보가 변조되거나 손상되지 않았음을 보장하는 것을 의미합니다. 정보의 무결성을 유지하기 위해 데이터 무결성 체크, 전자 서명 등의 메커니즘을 사용할 수 있습니다.
가용성(Availability): 가용성은 시스템 또는 서비스가 정상적으로 작동하고, 필요한 시간에 정보에 접근할 수 있는 상태를 유지하는 것을 의미합니다. 가용성을 보장하기 위해 백업 및 복구 시스템, 재해 복구 계획 등을 준비할 수 있습니다.
OAuth(Open Authorization)
대칭키 방법
공개키 방법
코드방식
브라우저에서는 코드방식이 안전하다 브라우저에서 따로 토큰을 받지않고 토큰이 카카오에서 블로그서버로 받기 때문, 만약 계속 지니고 있는 앱에서는 상관없다
카카오에서는 브라우저가 필요한 토큰을 블로그 서버로 전달한다
크리덴셜 인증방식
토큰을 전달하는 방식, 토큰을 전달받아 카카오에 검증한 후 홍길동 정보에 접근할 수 있다.
코드방식과 크리덴셜인증방식은 대칭키, 공개키방식을 선택할 수 있다
대칭키 :생성과 검증을 한곳에서 가능
비대칭키 :발행과 검증을 다른곳에서 하면
비대칭키 장점
- 키 전달하지 않아도 됨
- 암호화, 전자서명
- 발행과 검증을 다른곳에서 할 수 있음
대칭키(Symmetric Key)
암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘
동일한 키를 주고받기 때문에, 매우 빠르다는 장점이 있음
but, 대칭키 전달과정에서 해킹 위험에 노출
공개키(Public Key)/비대칭키(Asymmetric Key)
암호화와 복호화에 사용하는 암호키를 분리한 알고리즘
대칭키의 키 분배 문제를 해결하기 위해 고안됨.(대칭키일 때는 송수신자 간만 키를 알아야하기 때문에 분배가 복잡하고 어렵지만 공개키와 비밀키로 분리할 경우, 남들이 알아도 되는 공개키만 공개하면 되므로)
자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개함
공개키 암호화 방식 진행 과정
- A가 웹 상에 공개된 'B의 공개키'를 이용해 평문을 암호화하여 B에게 보냄
- B는 자신의 비밀키로 복호화한 평문을 확인, A의 공개키로 응답을 암호화하여 A에개 보냄
- A는 자신의 비밀키로 암호화된 응답문을 복호화함
하지만 이 방식은 Confidentiallity만 보장해줄 뿐, Integrity나 Authenticity는 보장해주지 못함
- > 이는 MAC(Message Authentication Code)나 전자 서명(Digital Signature)으로 해결 (MAC은 공개키 방식이 아니라 대칭키 방식임을 유의! T=MAC(K,M) 형식)
대칭키에 비해 암호화 복호화가 매우 복잡함
(암호화하는 키가 복호화하는 키가 서로 다르기 때문)
대칭키 vs 공개키 암호화의 주요 차이점
특징 | 대칭키 암호화 | 공개키 암호화 |
키의 개수 | 하나의 키 (동일 키 사용) | 두 개의 키 (공개키와 비밀키) |
속도 | 빠름 | 느림 |
보안 | 키의 안전성에 의존 | 비밀키의 안전성에 의존, 키 관리 용이 |
키 관리 | 사용자 수가 많을수록 키 관리 복잡성 증가 | 상대적으로 키 관리 용이, 공개키만 배포하면 됨 |
응용 분야 | 대량 데이터 암호화 (예: 파일 암호화, VPN) | 키 교환, 디지털 서명, 이메일 암호화 |
대칭키와 공개키 암호화 방식을 적절히 혼합해보면? (하이브리드 방식)
SSL 탄생의 시초가 됨
1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄 2. B는 암호문을 받고, 자신의 비밀키로 복호화함 3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄 4. A는 자신의 대칭키로 암호문을 복호화함 5. 앞으로 이 대칭키로 암호화를 통신함
즉, 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것!
Share article