[API] REST API 보안

1. 인증
- API 서비스를 사용하고자 하는 대상자가 서비스 사용이 가능한지 여부를 확인하는 것을 의미한다. (일반적인 웹서비스에 로그인과 동일한 기능이다.)

1-1. API Key

가장 기초적인 방법으로 서비스 제공자가 발급해준 KEY를 통해 인증을 하는 방식이다.
- API Key는 특정 사용자만 알 수 있는 일종의 문자열로 되어 있다. (예:aASDFasdf87AS5D4F2asddf234SDF234)
- API Key는 API 서비스 제공자가 제공하고 사용자는 API Key 정보를 메시지 안에 포함하여 호출한다.
- API Key는 한번 노출되면 전체 API가 뚫리는 문제가 발생할 수 있기 때문에 높은 보안 인증이 필요한 상황에는 적합하지 않는 방법이다.

1-2. API Token

Token을 활용하여 API 서비스 인증을 하는 것이다.
- ID, PW 입력하면 API 서비스 제공자는 사용할 기간이 유효한 Token을 사용자에게 발행하고 이 Token을 통해 사용자를 인증하는 방식이다.
- 장점 : Token을 사용하게 되면 Token이 외부에 노출되더라도 ID와 PW는 보호 될 수 있다는 장점이 있다.

1-3. HTTP Basic Auth

ID,PW 정보를 HTTP Header에 Base 64 인코딩 형태로 넣어서 인증에 사용하는 방법이다.
- 단, 이 경우에는 HTTPS 프로토콜을 사용해야 한다. 그렇지 않으면 Base 64 디코더를 통해 ID, PW 정보가 모두 노출 될 수 있는 위험이 있기 때문이다.

1-4. Digest access Authentication

서버에서 생성한 난수를 통해 ID, PW 정보를 Hash화 하는 방법이다.
- HTTP Basic Auth에 단점을 보강하기 위해 나온 인증 프로토콜이다.
- 서버에서 생성한 난수는 클라이언트와 서버가 모두 알고 있는 값이며 이 난수를 통해 HASH화 하여 클라이언트가 서버에 전송하기 때문에 ID와 PW가 노출될 위험을 줄일 수 있다.
- 난수를 통해 HASH화 한다고 하여도 HASH를 하는 방식(MD5, SRP6a등..)에 따라 보안 수준의 차이가 날 수 있다. 보안 레벨이 낮은 HASH 알고리즘을 사용시에는 HTTPS를 꼭 사용하는 것을 권장하며 보다 높은 수준의 보안을 원할 경우에는 높은 보안 레벨의 HASH 알고리즘을 사용하는 것이 좋다.
- 단, 서버에서 난수를 별도로 관리해줘야 하는 리스크가 발생한다.

1-5. 클라이언트 인증 추가

ID, PW 뿐만 아니라 Client ID와 Client Secret 정보를 추가로 입력 받아 API Token을 발급한다.
- API 서비스를 사용할 앱을 등록하여 사용함으로서 보안을 강화 할 수 있다.
- 트위터나 페이스북 개발자 사이트를 보면 개발할 앱 또는 웹에 대한 정보를 입력하고 인증하는 절차를 진행하는 경우가 있다. 이와 같은 절차가 여기에 해당한다.

1-6. 제 3자 인증 방식

직접 인증 절차를 진행하지 않고 제 3에 서비스에서 인증한 결과를 활용하는 방식이다.
- Facebook과 같이 제 3의 서비스에서 자신의 서비스를 이용할 수 있게 지원하고자 할 때 주로 인증하는 방식이다.
- 우리가 구축한 서비스가 Facebook이나 Google에서 제공해주는 기능을 사용하고자 할 때 Facebook이나 Google에 접근하기 위해서는 사용자 인증 정보가 필요할 것이다. 이때 사용자는 우리 서비스에 Facebook이나 Google에 ID / PW 정보를 공개하지 않고 Facebook과 같은 서비스에 인증을 할 수 있는 방식이다.
- 이러한 방식의 대표적인 구현체는 OAuth2.0이 있다.

1-7. IP White List를 이용한 터널링

API 서비스를 제공하고자 하는 아이피 정보를 별도로 관리함으로서 제공하고자 하는 아이피에서 온 요청만 처리하는 방식.
- 특정 서버간의 통신에서 많이 사용되며 서버 정보가 많이 변경되지 않는 경우에 사용됨.

1-8. Bi-diretional Certification(Mutual SSL)

가장 높은 수준의 인증 방식이며 서버에만 인증서를 두는 것이 아니라 클라이언트에도 인증서를 놓고 사용하는 방식이다.

2. 인가

API 서비스가 제공하는 기능별 사용자의 권한을 관리하는 것을 의미한다.

(예를 들어 관리자 권한을 가진 계정으로 로그인한 사용자가는 요금 정보를 볼 수 있지만 일반 사용자 계정으로 로그인한 사용자는 볼 수 없는 것과 같은 것이다.)

그렇다면 API 권한 인가는 어디서 하는 것이 좋을까?

클라이언트, API Gateway, API 서버와 같이 서비스가 제공하는 상황에 따라 다르게 구성할 수 있지만 API 서버에 위치하는 거을 권장한다. 자세한 사항은 아래 내용에서 같이 살펴보자.

2-1. API 권한 인가 처리 위치

2-1-1. 클라이언트에서 권한 처리하기
a. 클라이언트에서 자신의 권한을 판단하여 요청할 수 있는 API만 호출하는 방식이다.
b. 대부분 사용자 세션에 있는 ID정보와 서버의 권한 정보를 확인 후 API를 호출할지 여부 및 호출하고자 하는 API를 선정하는 방식을 사용한다.

2-1-2. API Gateway : API Gateway에서 권한을 처리 하는 경우
a. 공통 필드등으로 API 권한을 처리하는 경우에만 사용하는 것이 좋으며 그 이외에는 다소 어려움이 있다.
b. 앞서 이야기 했듯이 API Gateway에서 권한 처리를 구현하는 것이 쉽지 않기 때문에 API 서버에서 권한 처리를 하는 것이 일반적이다. 그 이유는 사용자 아이디 정보나 토큰, KEY 정보를 HTTP메시지로부터 가져오기 위해서는 디코딩, 파싱과 같은 작업을 해야 하는데 이와 같은 작업을 게이트웨이에 위치 시키게 되면 오버로드가 발생할 수 있기 때문이다.

2-1-3. API 서버 : 가장 일반적이고 보편적인 방법이며 API 서버의 비지니스 로직단에서 권한 처리를 하는 방식이다. API 메시지를 각각 파싱하여 사용하고 있기 때문에 API별로 권한 인가 로직을 구현하기가 용이하다.
[TIP : 권한 정보에 대한 정보를 Gateway에서 변환하여 API서버로 전달해주면 보다 효율적으로 사용할 수 있다.]


3. 네트워크 레벨 암호화 (Network-Level Encryption)
- 네트워크 프로토콜 단에서 사용자와 API 서비스 제공자 간에 주고 받는 데이터를 암호화 하는 기능을 의미한다. (일반적으로 HTTPS 기반의 프로토콜이 여기에 해당한다.)
- 정상적인 HTTPS 통신의 경우에는 서버에 있는 인증서 정보를 바탕으로 클라이언트와 암호화된 신뢰된 네트워크 연결을 만든다. 하지만 Man in the middle attack과 같은 이슈가 발생할 수 있으므로 인증서 사용시에는 공인된 인증서를 사용하는 것이 좋다.

• Man in the middle attack : 클라이언트와 서버간에 신뢰된 연결을 만들고자 할 때 인증서를 이용한다. Man in the middle attack은 클라이언트와 서버간의 신뢰된 연결 사이에 해커가 개입함으로서 메시지를 확인하고 변조하는 것을 의미한다.
https://ko.wikipedia.org/wiki/%EC%A4%91%EA%B0%84%EC%9E%90_%EA%B3%B5%EA%B2%A9


4. 메시지
- 사용자와 API 서비스 제공자간에 주고 받는 메시지 자체를 보호하는 내용을 알아보자.
4-1> 무결성 보장
- 사용자와 API 제공자 간에 주고 받는 메시지가 외부 요인에 의해 변경되지 않도록 하는 것을 의미한다.
- 주로 HMAC을 이용한 방식을 사용한다. https://hanee24.github.io/2018/04/22/hmac-authentication/
4-2> 암호화
- 특정 메시지 자체를 암호화 하여 중간에서 관련 내용을 알지 못하도록 하는 기능을 의미한다. (대부분 모든 메시지를 암호화 하지 않고 특정 일부분을 암호화 하여 사용한다.)
- 메세지를 암호화 하기 위해서는 클라이언트와 서버 모두 암호화 키를 가져야 한다. 암호화 키는 크게 대칭키, 비대칭키 두개의 알고리즘이 있다. (대칭키 : https://ko.wikipedia.org/wiki/%EB%8C%80%EC%B9%AD_%ED%82%A4_%EC%95%94%ED%98%B8, 비대칭키(공개키 암호화 방식) : https://ko.wikipedia.org/wiki/%EA%B3%B5%EA%B0%9C_%ED%82%A4_%EC%95%94%ED%98%B8_%EB%B0%A9%EC%8B%9D


* 참고 자료 : http://bcho.tistory.com/807