Security 복습
1.새로운 클래스를 만들어서 UPAF 필터를 상속 받으면 파싱 전략을 X-WWW-FORM으로도 가능하다.
2.키 값이 username, password
3.x-form 파싱 전략으로 username, password를 파싱한것을 UPAT의 담는다.
패스워드가 해쉬가 안돼있음 터지는데 누가 잡지?
PRINCIPAL만 알면됨
principal → 사용자 또는 시스템의 신원
authentication을 바꾸면 session이 변경 된다.
user 객체를
권한
예시로
Authentication 객체랑 문서 보고 security가 일을한다.
프록시(Proxy)
리버스 프록시(Reverse Proxy)
- 자기 앞단에서 막는 것이다.
- 클라이언트와 웹 서버 간의 중개자 역할을 하는 서버이다.
- 보안 처리, 부하 분산 등의 기능을 수행한다.
델리게이팅 필터 프록시(Delegating Filter Proxy)
- 실제 보안 처리를 스프링의 빈으로 위임한다.
- 스프링의 ”DelegatingFilterProxy” 는 보안 관련 처리를 스프링의 빈에 위임하여, 필터 체인을 통해 보안을 관리한다.
만약 JSON으로 바꾸려는데 행위가 없다면?
→ 이때는 상속을 받아서 JSON으로 바꿔준다!
로그인 방식
- “formLogin” 을 사용하면 ”UsernamePasswordAuthenticationFilter” 가 활성화되어 폼 기반 인증을 처리합니다.
- “httpBasic” 을 사용하면 ”BasicAuthenticationFilter" 가 활성화되어 HTTP 기본 인증을 처리합니다.
JWT (JasonWebTocken)
여기서 전제로 스케일 아웃에서 서버는 컴퓨터를 얘기하는거다.
Scale-up, Scale-out
Scale-up은 기존 서버의 하드웨어 성능을 향상시키는 방법입니다.
Scale-out클라이언트는 서버에 IP를 알필요가 없다.
하드웨어의 IP만 알면된다.
- 스케일 아웃(서버가 늘어남):서버(컴퓨터)를 여러 대를 사용해서 분기처리로 일 진행
Scale-out일 때 세션을 관리하는 방법
- DB에 저장(session을 쓰지 않는다.)
- 시스템 방식
- 서버에서 JsessionId를 DB로 넘겨 각 서버가 DB를 공유
- 단점: I/O 발생(I/O작업이 많아질 수록 HD에 저장 및 로드 속도가 영향을 받는다.)
그림 설명(다시그리자^^)
- 메모리 DB
- 시스템 방식:
- 메모리에 세션 정보를 저장해서 사용하는 방식으로 빠른 접근과 I/O 부하 줄인다.
- 세션 동기화가 간편하고 성능이 좋은 장점이 있음
그림 설명
- sticky session
- 시스템 방식 -처음 접속 한 서버의 IP나 JsessionID를 기억하고 있다가 요청이 다시오면 그 해당 IP로 보내준다.
- 단점:해당 서버하고만 통신을 하다보니 서버의 과부하가 걸린다.
그림 설명
- JsessionId 복사
- 시스템 방식
- 단점:JSessionID 동기화가 이루어지는 동안 클라이언트가 다른 서버로 이동할 수 있습니다. 이 경우, 동기화되지 않은 새로운 서버에는 클라이언트의 세션 정보가 없으므로 세션 정보의 일관성이 깨질 수 있습니다.
-서버에서 프로세스 하나 만들어서 다른 서버로 요청(동기화된다.)
→시스코 장비 = L4(TCP/IP 영역에 있는 ) = 로드밸런서가 서버들이 동일한 jsessionid를 들고 있는걸 보고 동기적으로 일을 처리한다.
→균등하게 분산 시키는 기준점
서버의 현재 부하 상태: 로드 밸런서는 각 서버의 현재 부하 상태를 모니터링하고, 부하가 낮은 서버에게 우선적으로 요청을 전달합니다.
연결 수: 로드 밸런서는 각 서버에 연결된 클라이언트의 수를 추적하고, 연결 수가 적은 서버에게 우선적으로 요청을 전달합니다.
응답 시간: 로드 밸런서는 각 서버의 응답 시간을 모니터링하고, 응답 시간이 짧은 서버에게 우선적으로 요청을 전달합니다.
가중치: 로드 밸런서는 각 서버에 가중치를 할당하여 요청 분배에 반영할 수 있습니다. 가중치가 높은 서버는 더 많은 요청을 처리하게 되어
그림 설명
session의 단점(스케일 아웃 경우)
- 서버가 한 개 일 때는 상관이 없지만 서버가 여려 개로 늘어나는 순간 클라이언트의 I/O 속도가 느려진다.
- CPU랑 memory를 업그레이드 한다해서 I/O(input, output)의 속도가 개선되지는 않는다.
- HD에 input 할 때 cpu는 멍 때린다. 이유는 메모리는 100의 성능을 가지고 있으면 cpu는 1000의 성능을 가지고 있다.
cokie(session)단점 보완 방법
- NIO(Non-blocking I/O) (토큰 방법 선택)
- Selector, Channel, Buffer 등의 개념을 활용합니다. Selector는 여러 개의 Channel을 관리하고, 이벤트 발생 시 알림을 받아 해당 작업을 처리합니다. Channel은 입출력 작업을 수행하는 객체이며, Buffer는 데이터를 임시로 저장하는 공간입니다.
session 대신 jwt를 쓰는 이유를 알아야됨.
세션기반 인증 VS 스테이트 리스 인증
세션은 클라이언트 상태를 저장 해야 하고(스테이트풀), 토큰은 열쇠만 저장하고 있으면 된다(상태 정보를 가지고 있다). (스테이트리스)
세션 기반
- 세션기반 인증은 사용자의 상태(로그인 정보 등)를 서버에서 관리하는 스테이트풀(stateful) 방식이다.
- 사용자가 여러 요청을 할 때마다 서버는 세션 저장소에서 사용자의 정보를 조회하며 이는 추가적인 I/O 작업을 필요로 하고, 서버 간 세션 동기화의 복잡성을 불러올 수 있다.
스테이트 리스
- 스테이트 리스 인증 방식은 예를 들어 토큰 기반 인증은 서버가 사용자의 상태를 저장하지 않는다. 대신 사용자가 서버에 요청할 때마다 토큰을 함께 보내서 인증을 수행한다.
- 이 방식은 서버의 I/O를 줄이고, 스케일 아웃이 용이하며, 서버 간 세션 동기화 문제를 해결한다.
세션기반 인증이있는데 왜 스테이트리스의 인증 방식을 쓴건가?
I/O가 일어나는 컴퓨터는 논 블로킹(NonBlocking) I/O가 필요하다.
블로킹을 줄이는 방식으로 웹서버를 구현해야한다.
권한 위임
- 인증 대행 시스템 → 사용자가 중개인에게 인증을 위임합니다.
- 대칭키 시스템 → 하나의 키로 데이터를 암호화하고 동일한 키로 데이터를 복호화한다. ex) 대칭키를 문 열쇠로 생각하면 잠그고(발행), 풀고(검증)이 된다.
권한 위임은 상태를 저장할 필요 없으므로 “스테이트 리스”이다!
클라이언트가 로그인 요청을 하였을 때,
열쇠로 열리면 통과, 열쇠로 열리지 않으면 위조, 열쇠가 없으면 처음 방문 하였다로 처리
토큰과 대칭키 구별!
토큰에 클라이언트의 상태 정보를 기록해 둔다.
열쇠로 상태 정보를 잠그면 토큰이 되고 그 열쇠로만 정보를 열람이 가능하다.
이로 구분한다. (열리면 신뢰 할 수 있는 정보)
OAuth의 방식에는 2개가 있다
크리덴셜 방식 → 토큰을 받으면 반드시 전달하는 것
코드 방식 → 토큰을 주는 것이 아닌 코드와 302를 주고 이 정보를 전달한다.
어차피 대칭키면 둘 다 검증을 받아야한다!
공개키면 직접 연결하여 사용이 가능해서 전달한 서버에서 그대로 사용이 가능한데,
대칭키면 이 연결이 신뢰 할 수 있는지 확인하고 전달 받은 서버에서 직접 토큰을 생성하여 서로 연결을 유지한다.
문제해결 = 서버 모두하고 통신해야됨
방법
단점 권한 대행 안됨….
권한 대행(권한위임)
세션 시스템
고객이 중개인을 통해 은행의 업무 요청
그러나 은행 입장에서는 고객이 아니기 때문에 거절한다.
그럼 중개인이 고객의 JID를 은행에간다.(그럼 인증이됨)
결론:고객의 권한이있는 키를 중개인게 줘서 은행 업무를 중개인이 대신 본다.
토큰 시스템
버스 회사의 버스에 고객이 타려면 버스회사는 돈을 요구 할거다.
이때 버스회사에서 자체 토큰을 발행한다.
이것을 고객이 토큰을 받으면 토큰을 가지고 검증을 하면 버스를 탈 수 있다.
버스 탈 때마다 토큰을 받아야된다.
다른 버스를 타려고하면 또 다른 버스에서 토큰 검증을 해야되는데 이것을 대칭키(열쇠 1개) 시스템이라고한다.
대칭키 시스템:
대칭키(열쇠 1개)
잠그고(발행) 풀고(검증) 할 수 있음
세션은 상태를 저장해야 되고 토큰은 열쇠를 저장하는거다.
즉 토큰은 클라이언트의 상태를 저장할 필요가 없으니 스테이트 리스가 된다.
토큰에다가 클라이언트의 상태 정보를 기록한다.
-토큰 단점-
토큰전달하는 방법이 어렵다.
해킹 당할 수 있음
고객이 토큰을 정상적인지 확인하기 어려움
토큰 시스템은
서버마다 열쇠를 만들면됨.
PROXY에서 인증 처리 하고?
은행
고객이 중개인에게 은행으로 부터 받은 토큰을 주면
중개인은 이 토큰이 정말 은행에서 받은 토큰인지 확인해야된다.
이 확인은 은행에서한다.
은행은 토큰 발행을 비밀 키로 발행했다.
토큰 전달 해서 권한 위임 = OAUTH = 오픈어스
RSA(키 2개쓰기)
공개키로 잠그면 비밀 키로 열 수 있고
비밀 키로 잠그면 공개 키로 열 수 있다.
이 시스템을 RSA라고한다.
키를 클라이언트에게 전달하다 털릴 수 있다.
통신이 일어나면 누구나 해킹이 가능한 가능성이 생김
이상황을 해결하기위해 키2개를 쓰 ㄴ다
도둑(c)이 훔칠 공개키는 훔칠 수는 있지만 비밀키는 못 훔치기 때문에
A가 B의 공개 키로 데이터를 잠가서 전달하면 도둑은 데이터를 확인 못한다.
B만 열어 볼 수 있다.
신뢰성 문제
C가 A가 보내려는 정보를 훔쳐서 버리고 자기가 새로운 데이터를 B의 공개키로 잠가서 B에게 보내면B는 누가 보낸지 알방법이 없다?는데 해결방법이 있다.
해결방법 → A의 비밀키로 데이터를 한번 더 잠가 버리면 A가 봰ㅆ는지 알 수있다
왜냐하면 비밀키는 자기자신만 가지고있기 때문이다.
만약 B가 잠긴 데이터를 받았는데 A의 공개키로 열리지 않으면 잠긴 데이터를 버린다.
키는 자기가만든다. 그렇기때문에 A비밀키로 잠긴거면 A가 보낸 데이터라는거다.
그다음 신뢰성을 지키기 위해 받은 데이터를 확인 후 B의 비밀 키로 싸서 다시 A에게 보낸다.
보안의 3요소
무결성 I
암호화 C
신뢰성 A
셋 다 지킬 수있다
토큰은 DETAILS, 패스워드, 권한 이렇게 3개가 필요하다.
스케일 아웃 될 때 컴퓨터가 늘어난다
세션을 동기화 해야되는 문제가 있다
이때 ~DOUS사용
생성과 검증이 한곳에서 가능하면 대칭키를 쓰면된다.rsa
생성과 검증을 다른 곳에서 해야되는 경우가있다. 공개키 사용
장점
-키 전달 x
-암호화, 전자 서명(본인의 비밀키로 잠그는거)
-발행과 검증을 다른 곳 에서 가능
이것을 통해 오픈어스를 할 수있다. 대칭키 시스템에도 가능한데 두 개의 차이점은?
오어스 = 권한대행
principal =주체자 =브라우저
oauth는 자원에 접근할 수 있는 권한을 위임하는것
oauth 크리덴셜 방식
1.토큰전달 방식을 =크리덴셜 방식이라고한다.
2.코드 전달 방식 =토큰 전달 방식은 토큰을 주는게 아닌 코드를 준다.
두개 다름
토큰 방식은 브라우저에서 별로 안좋고 앱에서 좋다
코드 전달 방식은 브라우저에서 좋다.
이거의 핵심은 누가 관리하냐에 달린건데.
oauth를 하는건 결국 블로그서버에 권한을 줘서 브라우저랑 블로그 서버랑 통신하려는거다.
oauth 로그인 시스템
Share article
