Contents
1. 분산 처리
- 서버를 늘림
- 서버마다 세션이 있음 = Tomcat이 세션을 만드니까 Tomcat이 필요함
- 리버스 프록시(Reverse Proxy: 단일 진입점)가 필요함
클라이언트와 서버 사이에 위치
클라이언트의 요청을 받아들이고, 해당 요청을 내부 서버로 전달하는 서버
- 리버스 프록시의 주요 기능
로드 밸런싱(Load Balancing): 여러 서버에 대한 요청을 분산시켜 로드를 균형있게 분배
보안 및 인증(Authentication): 클라이언트의 요청을 받아 인증 및 보안 검사를 수행
캐싱(Caching): 요청에 대한 응답을 캐싱하여 동일한 요청에 대한 응답을 바로 캐시에서 제공
SSL 암호화(SSL Termination): SSL 암호화 해제, 내부 서버 통신은 암호화되지 않은 상태로 전달
접근 제어(Access Control): 특정 IP 주소나 네트워크에서의 요청을 차단하거나 허용
2. 하드웨어(Hardware)로 프록시 역할
- 소프트웨어적으로 프록시를 만들면 if로 해서 프로그램으로 처리해서 굉장히 늦음, 부화가 많음
- 다 HW로 처리 → 시스코 장비가 필요함
이런 장비들을 L4(OS단계에서 구현하는걸 HW에서),로드밸런스라고 함 : 부화 분산의 역할
요청이 들어오면 물리적으로 회로를 만들어서 전류가 들어오면 내부적으로 트리거 되서 때려줌
- 소프트웨어가 일하지 않음
3. 문제 : JSEEIONID가 없는 곳으로 가면 거부 당함
클라이언트는 왜 거부 당했는지 모름
4. 해결 방법
1) Sticky Session
L4에 세팅 : 로드 밸런서가 클라이언트 요청을 서버로 분배할 때,
특정한 클라이언트의 모든 요청을 항상 동일한 서버로 보내는 기능
⇒ 기억하고 있다가 항상 그 JSESSIONID가 있는 데로 보내줌
단점 : 해당 서버가 부화가 심해도 가게됨
2) 복제
모든 SESSION에 REQUEST요청을 해서 동기화시킴
폴링 : 주기적으로 세션 데이터를 검사하고 업데이트하는 방법
일정한 시간 간격으로 서버 간에 세션 데이터를 비교하고 업데이트하여 일관성을 유지
실시간 성능은 보장되지 않음
3) SESSION이 아닌 DB에 저장
DB공유하기
단점 : IO가 일어남
4) MEMORY DB에 저장
데이터베이스가 모든 데이터를 커밋하면 HDD에 기록하고 IO가 발생함
HDD를 안쓰고 메모리로만 일하는 MEMORY DB가 나타남
HD가 없어 영구히 기록은 안됨
→ SESSION은 영구히 기록할 필요가 없어 MEMORY DB를 사용
IO가 없는 레디스 DB, 맴 캐쉬를 만듦
레디스(Redis) : 메모리 기반의 데이터 저장소로서 사용되는 오픈 소스 데이터베이스
키-값(Key-Value) 형태의 데이터를 저장하고 관리
주로 캐싱, 세션 관리, 메시지 브로커 등 다양한 용도로 활용
맴 캐쉬(Memory Cache) : 주로 Redis가 데이터를 캐싱하는 데 사용되는 경우
저장되는 정보를 최소화해야 함
단점 : 권한 대행을 못함
5. 인증을 대신해주는 시스템
1) 대칭 키 시스템
- 발행하고 검증을 한다는 것은 열쇠가 하나라는 것
- 열쇠로 잠근 것 : 발행
그 열쇠로 열린다는 것 : 검증
- 세션이 상태를 저장하는 것과 달리 열쇠만 저장하면 됨 // STATELESS
토큰이 없으면 처음 온 사람
토큰이 있는데 열리면 인증 안열리면 미인증(위조)
→ 토큰에 클라이언트의 상태 정보를 기록해놓음
- 단점 : 통신으로 열쇠를 주면 해킹 당할 수 있음
토큰의 신뢰성 검사는 발행자만 할 수 있음
발행과 검증은 발행한 곳밖에 못함
- 장점 : 분기 처리할 때 열쇠만 복사해서 전달하면 됨
확장해도 열쇠 전달이 필요 없음
⇒ 프록시를 둬서 거기서 열쇠 검증하고 라우팅 처리해서 한 군데에서 다함 / 마이크로하게 쪼갬
SESSION은 인증 통과는 되지만 정보 전달이 안됨
ex) 버스 회사에서 토큰을 발행해서 고객이 그 토큰을 가지고 버스를 타려고 할때
그 토큰이 버스 회사에서 발행한 토큰이 맞는지 확인(검증)후 탈 수 있음
발행한 버스 회사에서만 토큰의 검증이 가능함
ex) 토큰에 개인정보에 위배되지않는 간단한 정보를 기록해서 고객에게 배포해서
토큰에서 고객의 정보를 저장하지 않도록 함
→ 키를 프록시 서버에 두면 서버마다 키를 안들고 있어도 됨
2) 공개키 시스템(RSA알고리즘)
- 열쇠가 두 개
공개키 : 공개되어 있고 누구나 알 수 있는 키
이 키를 사용하여 메시지를 암호화
암호화된 메시지는 비밀키로만 해독 가능
비밀키 : 비밀로 유지되어야 하는 키
이 키를 사용하여 암호화된 메시지를 해독
메시지를 비밀키로 암호화하면 공개키로만 해독 가능
- 장점 : 받는 사람외에 아무도 확인할 수 없음
* 크리덴셜(Credential) : 사용자가 자신을 인증하거나 권한을 부여받는 데 사용하는 정보나 자격 증명
- 단점 : 가용성이 안 좋음 / 쓰고 싶으나 누가 중간에서 버려서 쓸 수는 없음
무결성이 손상될 수 있음 / 중간에 누가 보냈는지 알 수 없음
* 가용성(Availability) : 시스템이 요청된 서비스를 제공할 수 있는 정도
* 무결성(Integrity) : 데이터가 원래의 상태를 유지하고 있으며, 변경이나 손상되지 않았음을 보증
- 극복 방안
많이 던지면 Credential, Availability 다 지켜짐
A의 공개키로 열어봄 → 안 열리면 신뢰성이 없음
A의 비밀키로 한번 더 잠그면 됨 → 전자 서명으로 사용
6. OAuth(Open Authorization)
- 사용자가 웹 및 모바일 애플리케이션을 통해 외부 웹 사이트 또는 애플리케이션에 대한
안전한 접근 권한을 부여하기 위한 개방형 표준 프로토콜
- 내 인증을 오픈 : 권한을 대행 : OAUTH
자신의 계정 정보를 직접 공유하지 않음
인증 서버에서 발급된 토큰을 사용하여 다른 애플리케이션에 대한 권한을 부여
- 토큰은 브라우저에도 저장되서 위험함
- 스프링 서버는 코드를 가지고 있음
클라이언트에게 인증 코드를 제공
이 코드를 사용하여 인증 서버에서 액세스 토큰을 요청
코드 교환 프로세스를 통해 사용자 권한을 대행, 클라이언트가 애플리케이션에 대한 접근을 관리
1) 생성과 검증이 한 곳에서 가능 : 대칭키
- 암호화, 복구화만 가능
- 단점 : 발행과 검증을 다른 곳에서 해야하는 경우가 있음
내가 데이터를 암호화해서 전달했으니까 열어봐야하는 경우 대칭키로 안됨
키 전달이 안됨 / 키 전달하다 키가 도난당할 수 있음
2) 키 전달 안하는 좋은 방법 : 공개키
- 키를 전달하지 않아도 됨
- 암호화, 전자 서명, 복구화가 가능함
* 전자 서명 : 웹에서 하는 모든 사인들
- 발행과 검증을 다른 곳에서 할 수 있음
ex) 은행에서 고객에서 비밀키로 토큰을 발행
고객은 중개인에게 토근을 전달하여 권한을 위임하고
중개인은 은행에 검증을 요청할 필요없이 은행의 공개키로 열어서 열리면 인증 성공
3) 토큰 방식
- 브라우저가 바로 토큰을 받는 방식, 브라우저가 토큰을 저장함
→ 보안에 신경을 많이 써야 함
- 대칭키면 굳이 토큰 방식을 쓸 필요가 있나? 그럼 코드 방식이 나음
- 단점 : 브라우저 클라이언트가 토큰을 관리, 보안에 취약함
폰은 내 기계장치 밖에 없으니 괜찮음
4) 코드방식
- 임시로 코드를 받았기에 코드로는 권한 대행이 안되서 카카오에서 코드를 주고 토큰을 받음
브라우저가 토큰을 받아 관리하지 않음
- 브라우저를 사용할때는 코드 방식이 안전함
5) 토큰을 누가 발행 받느냐가 중요함
대칭키, 브라우저 → 코드 // 코드 방식
코드 방식 : 바로 코드를 만듦
- 둘 다 대칭키면 한번 더 가서 검증 받고 공개키면 스스로 검증하면 됨
- OAuth면 권한 대행이 일어나 정보에 접근할 수 있다는 것
7. OAuth를 이용한 로그인 시스템
- 토큰의 발행 주체 : 카카오 , 대행자가 토큰에 신뢰성 인정 받음
- 브라우저가 요청하고 응답 받고 다시 요청하면 또 카카오 토큰을 주게 됨
- 공개키로 만들어주면 토큰만 있어도 카카오의 공개키로 풀어서 검증하고 통신하면 됨
- 공개키면 그대로 쓰기
대칭키면 블로그 서버의 토큰을 발행해야함 / 자기 서버에서 토큰 재발행
본인이 검증하고 발행할거니까
- 카카오가 내 개인정보를 가지고 있으니까 따로 정보를 입력하거나 인증할 필요가 없음
Share article
