통신 기본 계념과 보안 기본 계념

session ->인증이다

 

클라이언트와 서버가 계속 연결돼 있는 상황에선 session이 필요가 없다. 인증이 필요없기때문. 클라이언트가 요청 시에 서버는 많은 정보를 받게 된다. 어떤 것을 요청하는지부터 어떻게 요청을 하는지까지. 그럼 클라이언트가 정상적이지 않은 방법으로 요청을 할 수도 있다. 이 요청 시에는 서버에 레퍼럴 정보가 다 남는다. 만약에 이 레퍼럴 정보를 클라이언트가 조작을 하면 서버는 정상적으로 요청을 하는 줄 알기 때문에 아무리 구멍을 막는다고 해도 클라이언트가 레버럴정보만 속이면 다 뚫리게 된다.

자바에서 네이버에 크롤링을 요청할때 레퍼럴 정보를 수정해서 자바에서 요청을 했지만 브라우저가 요청한 것처럼 서버를 속여서 크롤링을 할 수 있게 되는 것.

이때 알아야 하는 중요한 지식이 httpHeader이다. htteHeader를 모르면 웹 개발자가 절대 될 수 없다. 

 

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

HTTP 헤더 - HTTP | MDN

위 내용은 꼭 알고 있어야 한다.

 

CORS

서버는 자바스크립트의 공격으로부터 대항을 해야 한다. 자바스크립트가 어떻게 공격을 하냐면, fetch를 활용해서 put, delete, post로 공격을 할 수 있기때문(XSS 검색하면 나온다), 그래서 서버는 자바스크립트의 요청을 원천적으로 막아놓는 것이 기본이다.

그래서 기본적인 정책이 같은 ip에서는 자바스크립트 요청은 허용이 된다. 예를 들어 같은 도메인이 아닌 다른 도메인의 접근은 다 막아버린다. 위와 같은 정책이 CORS정책이라고 한다.

CORS설정을 건드리면 꼭 같은 IP가 아니더라도 선택받은 도메인은 자바스크립트 요청이 가능해진다.

그래서 CORS설정을 하지 않는다면 서비스가 불가능해진다. 왜냐하면 브라우저에서 서버와 다른 도메인을 막아버렸기때문.

 

 

브라우저

서버는  클라이언트가 요청했을 때 STATFULL 한 것처럼 속이기 위해서 서버 session에 키값을 저장해 놓고 response해더에 서버에 저장된 키 값의 session아이디가 쿠키에 담아져서 브라우저에 쿠키가 자동 저장된다. 그럼 그다음 똑같은 클라이언트의 요청이 오면 자동으로 쿠키를 들고 서버로 가는 것이다. 서버에서 쉽게 말해 id카드를 주는 것이다.

안드로이드는 브라우저와 달리 위와 같은 정책이 없어서 위와같은 작용을 하기 위해서는 서버에서 돌려주는 쿠키를 저장하는 기능을 직접 구현해 줘야 한다.

 

 

session의 한계를 해결하기 위해서 생긴 Redis서버

트래픽이 올라가서 서버를 스케일업(성능을 올렸을 때) 했을 때 계속 스케일업을 하다 보면 더 이상 성능을 올리기 힘든 수준까지 간다. 그러면 스케일 다운을 해서 서버를 복제를 한다. 이때 복제된 서버가 여러 개이기 때문에 클라이언트가 어떤 서버를 요청해야 할지 정하게 해서는 안된다 그래서 L4라는 ip를 결정해주는 라우팅 기능이 있는 장비를 달아서 장비 입장에서의 컨트롤러를 달아준다. 그럼 클라이언트는 L4라는 라우팅 장비에 요청을 하면 여러 개의 서버를 보고 안정적인 서버로 리다이렉션 시킨다(이때 요청정보 유지를 위해서 request로 덮어 씌움)그리고 응답 시에 쿠키를 돌려받는다. 그리고 똑같은 클라이언트가 제 요청 시에 L4가 그전에 요청받았던 서버가아닌 다른 서버로 요청을 하게되면 그 서버의 입장에서는 이 클라이언트는 최초요청이 된는것이다. 그럼 그 서버는 최초요청으로 알고 다시 불필요하게 session에 저장을 하게되는것이다. 이를 해결하기위해서 session이 저장될때 모든서버에 저장하는방법과, L4에서 클라이언트의 최초요청시 라우팅해준 서버를 기억놨다가 제요청시에 똑같은 서버를 라우팅 해주도록 설정해주는 방법이 있다. 두방법다 문제 해결은 되지만 연산이 많이 일어나거나 한쪽으로 서버가 몰리는 일이 생길 수 있기 때문에 좋은 방법이 아니다.

그래서 위 방법도 적합하지 않아서 생긴 방법이 db에 저장을 하는 것이다. 이때 io가 발생하는데 상당히 느려진다. 그래서 발명된 기술이 메모리 DB를 사용하는 것이다. 메모리 DB는 (Redis서버, memcache서버 등등, (json서버))메모리를 사용하는 이유는 빠르기 때문이다. io 없이 처리할 수 있기 때문이다.

 

메모리 DB이후에 최근에 나온 session방식은 token으로 인증을 하는 방식이다.

 

 

보안 3요소

CIA

C: 기밀성

전송하거나 응답받을 때 데이터의 내용 자체를 암호화하는 것

I: 무결성

전송하거나 응답받는 데이터가 일관성이 있어야 한다.

A: 가용성

원하는 시점에 데이터를 컨트롤할 수 있어야 한다.

위 세 가지가 완벽하게 지켜지면 보안을 지킬 수 있다

위 세 가지를 잘 지키면 통신을 잘할 수 있다는 뜻이다

그럼 어떻게 하면 CIA를 지킬 수 있을까?

 

대칭키

C를 유지하기 위해 A라는 공개키에 담아서 통신을 한다. 대칭키는 여는 키와 닫는 키가 같다. 대칭키로 통신을 할 때 단점은 키 전달을 하는 과정에서 보안이 취약하기때문 키 자체가 탈취 당하 거나한 일이 발생할 수 있다. 그리고 대칭키는 무결성 유지가 어렵다.

 

RSA :현존하는 최고의 암호화 알고리즘

RSA를 사용하면 CIA를 지킬 수 있다.

비대칭키

통신하는 양쪽의 대상이 서로 직접 두 개의 키를 만든다.각자 만든 두개의 키 중 하나는 공개키, 다른 하나는 비공개키로  설정해 놓는 것이다. 그럼 공개키는 비공개 키가 있어야만 열어볼 수 있다. 이때 기밀성 확보를 위해서는 통신을 받는 쪽의 공개키로 감싸서 데이터를 보내면 기밀성 확보가 가능해진다,중간에 탈취당하더라도 비공개키가 없어서 열어 볼 수 없다.

무결성을 유지하기 위해서 위 방법을 사용하면 통시를 보내는 쪽에서 비밀키로 데이터를 한 번 더 잠그는 것이다. 이런 상황을 전자서명이라고 함, 

위와 같이 통신을 하기 위해서는 프로토콜(약속)이 필요하다

보내는 사람의 프로토콜

1. 상대방의 공개키로 잠근다.

2. 잠근 데이터를 본인의 비밀키로 한 번 더 잠근다.(저자 서명)

받는 사람의 프로토콜

1. 보낸 사람의 공개키로 열어본다.

2. 본인의 비밀키로 열어본다.

우편을 보낼 때 등기로 보내야 하는 이유가 등기도 RSA시스템이랑 똑같기 때문에 중요한 문서는 등기로 보내야 한다.

 

해쉬 키가 좋은 이유

데이터를 항상 고정길이의 8개의 문자로 바꿔준다. 해쉬는 인코딩을 할 수 있지만 디코딩을 할 수 없다.

그래서 해쉬는 원본을 찾을 수 있게 해 준다. 해쉬로 인코딩을 해놓으면 데이터를 조금만 바꿔도 원본과 다른 해쉬값이 나오기 때문에 쉽게 말해 진품과 가품을 구분할 수 있게 해 주는 것이다