[코드 스테이츠] 97일차, "14주차 복습 (1) - MongoDB, HTTPS, Hashing"

---

[ 오늘의 TODO ]

1. 코드 스테이츠) 월~수 내용 복습
   // MongoDB
   // HTTPS
   // Hashing
2. 패스트 캠퍼스) 인강 3개 이상 듣기 // optional
3. 생활) 물 1L 이상 마시기
4. 생활) 1시간 이상 걷기 

 

---

[ 오늘의 복습 ]

1. MongoDB

  MongoDB는 대표적인 NoSQL 도큐먼트 데이터베이스다. NoSQL 은 매우 넓은 범위로 사용되면 관계형 테이블의 방법을 사용하지 않는 데이터 저장소를 의미한다. NoSQL 에 대한 자세한 설명은 저번 주차 때 진행했으므로 오늘은 MongoDB 에 초점을 맞춰서 작성하고자 한다. Import, ExportCRUD, 연산자 공부한 것들은 따로 언급하지 않는다. 

 

1-1) Atlas Cloud

  MongoDB 는 아틀라스(Atlas) 를 이용해 클라우드 데이터 베이스 형식을 갖춘다. 아틀라스는 GUI, CLI 데이터를 시각화, 분석, 내보내기, 빌드를 할 때 사용된다. 아틀라스 사용자는 클러스터를 배포할 수 있고, 클러스터는 그룹화된 서버에 데이터를 저장할 수 있다.

 

  인스턴스는 특정 소프트웨어를 실행하는 로컬, 클라우드의 단일 머신이다. 클러스터는 인스턴스들의 모임으로 하나의 시스템처럼 작동한다.  쉽게 설명하면 데이터를 저장하는 서버 그룹이다. 여러 컴퓨터를 네트워크로 연결해서 하나의 컴퓨터처럼 동작하도록 제작된 것이다. 단일 클러스터에서 각각의 인스턴스는 동일한 복제본을 갖는데 이 모음을 레플리카라고 한다. 레플리카 세트는 인스턴스 하나에 문제가 생기더라도 데이터가 그대로 유지된다. MongoDB 의 데이터 베이스가 클라우드에서 실행되는 인스턴스에 해당하고, 클러스트를 이용해 배포하게 되면 자동으로 레플리카 세트를 형성한다. 

 

1-2) MongoDB Document

  도큐먼트(Document)는 객체와 비슷하다. 데이터를 필드-값 한 쌍으로 저장하는데 마치 key-value 와 유사한 형식이다. 여기서 사용되는 용어를 정리해보자. 

 

1. Documnet(도큐먼트): field - value 의 한 쌍으로 저장되는 데이터
   => 모두 중괄호로 시작한다
   
   
2. field(필드): 데이터 포인트를 위한 고유 식별자
   => 각 필드는 큰 따옴표로 사용해서 문자열로 표현한다
   
   
3. value(값): 식별자와 연결된 데이터
   => 필드와 값 한 쌍의 구분은 쉼표로 한다. 
   => 각 필드와 값 사이에는 콜론으로 구분한다 
   
   
4. collection(컬렉션): MongoDB 의 도큐먼트로 구성된 저장소. 일반적으로 도큐먼트 간의 공통 필드가 있다. 데이터 베이스 안에 많은 컬렉션이 존재하고 컬렉션 안에 많은 도큐먼트가 존재한다.

  JSON 형식은 읽기 쉽지만 파싱이 느리고 메모리 사용이 비효율적이다. 또, 기본 데이터 타입만을 지원하므로 사용할 수 있는 데이터 타입에 제약이 있다. 이런 문제들을 해결하기 위해 BSON 이 도입되었다. BSON 은 이진법에 기반을 두어 메모리 사용이 효율적이고, 빠르고, 가볍고, 유연하다. MongoDB는 JSON 형식으로 작성된 것이면 무엇이든 데이터베이스에 추가할 수 있고 쉽게 조회할 수 있는데, 저장된 내부에서는 BSON의 형태로 존재한다.

 

 

2.  HTTPS

1-1) HTTPS란?

  http 에 secure 의 앞 글자 s가 붙은 것이다. http 프로토콜 내용을 암호화해서 보안을 추가한 개념이다. 기존 HTTP 내용은 전송 과정에 누군가 내용을 들여다 보면서 개인 정보가 쉽게 노출될 수 있었다. 하지만, HTTPS 는 한 번 암호화를 시키므로 중요한 정보가 노출되더라도 정확한 키가 없다면 내용을 알 수 없게 된다. 그 암호화를 가능하게 하는 것이 인증서, CA, 비대칭 키 암호화다.

 

1-2) 인증서

  데이터를 제공한 서버가 정말 데이터를 보내준 서버인지를 인증하는 용도로 사용된다. 인증서 내용에는 서버 도메인 정보가 있어서 데이터 전송자가 맞는지를 비교 확인한다. 

 

  서버가 클라이언트로부터 요청을 받는다면 응답과 함께 인증서를 보낸다. 응답을 받은 클라이언트는 인증서에 작성된 도메인과 응답 객체에 작성된 도메인을 비교한다. 두 도메인이 같을 때 서버에서 제공해준 데이터가 맞다는 것을 확신하고 받아들인다. 그러나, 요청을 탈취해서 조작한다면 인증서의 도메인과 응답에서의 도메인이 달라질 수 있기에 서버가 보내준 응답이 아닌 것처럼 꾸며낼 수 있어 인증서만으로는 보안을 강화할 수 없다. 

 

1-3) CA

  CA 는 공인 인증서를 발급하는 기관이다. 각 브라우저는 각자 신뢰하는 CA 정보를 갖는다. 그래서 각 브라우저마다 인증서의 차이가 존재한다.

 

1-4)  비대칭 키 암호화

 

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=godinus123&logNo=221086410707

  보안의 꽃이라 할 수 있다. 키는 두 가지가 있다. 하나의 키로는 암호화하고, 다른 키로는 복호화한다. A와 B는 한 쌍이고 A 키로 암호화했다면 B키로만 복호화할 수 있다. 그래서 https 프로토콜을 사용할시, 한 쌍의 키중 하나는 숨기고 다른 하나는 client 에 공개하여 데이터를 안전하게 전송한다. 

 

  통신 과정은 다음 세 단계로 나뉜다.

 

1. Hand Shake
   클라이언트와 서버가 서로를 확인하고 서버는 클라이언트에게 공개키 하나를 전달한다
2. 비밀 키 생성
   클라이언트는 전달받은 키를 이용해서 서버와 키를 만들어낼 임의의 정보를 암호화해서 전송한다. 서버는 클라이언트와 마찬가지로 임의의 정보를 암호화해서 전송한다. 클라이언트와 서버는 만들고 교환한 정보를 바탕으로 비밀키를 만들어낸다
3. 상호 키 검증
   각자 생성한 키를 바탕으로 클라이언트가 테스트용 데이터를 만들어낸 비밀키로 암호화해서 전달한다. 서버 역시 만들어진 비밀키로 복호화하고 다시 암호화해서 클라이언트로 전송한다. 만약, 클라이언트가 같은 내용을 복호화하는데 성공한다면 성공적으로 비밀키가 만들어진 것이다. 이 과정을 통해 HTTPS 연결이 성립된다.

 

  그러나 모든 통신이 공개 키 방식을 사용하지는 않는다. 많은 클라이언트를 대상으로 사용하기에는 복잡한 알고리즘인지라 통신 초창키에만 비밀키로 사용하기 위한 키를 만들어내기 위해 사용한다. 

 

 

3. Hashing(해싱)

3-1) 해싱이란?

  만약 인증 과정을 거치지 않고 이메일과 관련된 정보를 얻는다고 하면 간단하게 설계가 가능하다. 클라이언트에 어던 정보를 요청하고 서버에서는 이메일과 관련된 정보를 데이터베이스에서 가져온 후, 클라이언트가 정보를 확인한다.

 

  서버가 정보를 받고 정보를 DB 와 비교해서 맞다고 하면 DB에서 해당 이메일을 가지고 DB에서 관련된 정보를 요청해 다시 반환하는 과정을 겪게 된다. 그러나 비밀번호는 다른 사람에게 공개되서는 안 되는 자료고, 만약 해커가 비밀번호를 알게 된다면 심각한 개인 정보 유출, 남용이 이뤄질 수 있다. 이것을 막기 위해 암호화해서 전송하는 방식을 채택한다.

 

  암호화는 일련의 정보를 임의의 방식으로 사용해서 다른 형태로 변환한다. 해당 방식에 대한 정보를 소유한 사람 제외하고 이해할 수 없도록 알고리즘을 이용해서 정보를 저장한다

 

  db는 비밀번호를 스트링 형태로 그대로 저장하지 않고 어떤 알고리즘으로 db를 암호화한 후 저장한다. 서버는 암호화하는 알고리즘을 알고 있어서 요청이 들어오면 그 요청을 암호화시킨 후에 DB와 비교 작업을 하게 된다. 이렇게 하면 중간에 누가 끼어들더라도 암호화된 정보만을 파악하기에 문제가 발생하지 않는다. 이렇게 암호화하는 방식을 해싱이라고 한다. 해싱은 어떤 문자열에 임의의 알고리즘 연산을 적용해서 다른 문자열로 변환하는 과정이다.

 

  다음은 해싱의 세 가지 조건이다.

 

1. 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 한다
2. 모든 값은 고유한 해시 값을 가져야 한다. 그러나 매우 드물게 같은 암호가 발생할 수 있는데 그 경우를 막는 방법은 따로 존재해서 결국 암호화된 결과물은 고유해야 한다.
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다

 

3-2) Salt

  암호화해야 하는 값에 별도의 값을 추가해 해시 결과를 다르게 나오도록 하는 방법을 의미한다. 즉 해싱이 일어나기 전에 다른 값을 연산한 후 해싱하는 것이다. 

 

  Salt 를 사용할 때는 다음 네 가지의 주의사항이 존재한다.

 

1. Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다
2. 사용자 계정을 생성할 때, 비밀번호를 변경할 때마다 새로운 임의의 Salt 를 사용해서 해싱해야 한다
3. Salt 는 재사용하지 않는다
4. Salt 는 DB에 저장돼야 한다.