[영상]'API 보안' 부스 세미나(3편) I API 보안을 위한 핵심기술

 

지난 4월 개최된
eGISEC 2022 전시회에서
파이오링크는 API 보안을 주제로
부스 세미나를 진행했습니다.
​
기본적인 API의 정의에서부터
주된 API 공격 유형 및
이에 대한 대응기술까지
함께 살펴보았는데요.

​API 보안에 대해
한 걸음 더 가까워질 수 있었던 시간 !
😀

​유익했던 강연 현장을
생생한 영상으로 만나보세요 :)

 

---

📣
영상은 총 3편으로
나누어 제공됩니다.

이번 3편에서는
API 보안을 위한 핵심기술에 대한
내용이 포함되어 있습니다.

 

 

 

[영상 내용📃]
파이오링크에서도 당연히 웹 애플리케이션에 대한 보안을 굉장히 신경쓰고 있습니다. 웹방화벽이라는 제품을 출시했구요. 국내 시장에서 열심히 플레이를 하고 있습니다. 그러면 API 보안은 웹방화벽으로 어떻게 대응할 수 있을까요? 현재 웹방화벽 기술 수준으로 가능한 것인가에 대한 얘기를 하고 싶은데요.

API도 웹과 되게 비슷하지만 전달하는 데이터 형태 등이 다르기 때문에 기존의 웹방화벽에서 몇 가지 기능을 고도화할 필요가 있습니다. 그 대표적인 내용들이 6가지 정도가 있어서 여러분들에게 말씀드려 보도록 하겠습니다.

# 1.
첫번째로 Mutual TLS라고 들어보셨나요? mTLS라고 흔히 많이 소개되고 있는데요. 이 용어가 올해 1분기에 참 많이 노출되었습니다. 그 이유가 마이데이터 서비스 때문입니다. 마이데이터에서 정보 수집에 대해서는 API 방식을 이용하라고 하고 있구요. API를 반드시 TLS로 암호화하라고 하고 있고, mTLS로 반드시 하라고 의무화를 하고 있습니다.

mTLS는 뭐냐면, 더 쉬운 용어로 SSL이라고 하면 아시겠죠. 일단은 전달하고자 하는 데이터를 암호화 하는 거구요. TLS에는 암호화하기 이전 단계에 중요한 기능이 하나 있습니다. HTTPS로 서비스하는 국민은행과 같은 금융권 사이트 등에 접속해보시면,  주소 창에 초록색으로 뜨거나 그런 표시들을 보신 적이 있으실 겁니다. 그게 바로 내가 접속하는 서버가 신뢰할 만한 서버라고 알려주는 거거든요. 서버에 접속할 때 인증서를 요구합니다. 이 인증서는 전세계에서 굉장히 신뢰받는 인증기관이 발급한 것으로써 인증서가 올바르면 내가 접속하려는 서버가 올바른 거에요. 

기존의 TLS는 이랬습니다. 클라이언트는 내가 접속하려는 하는 서버만 확인하면 됐어요. 그런데 mTLS는 조금 다릅니다. mTLS는 클라이언트가 서버를 확인했던 것 처럼 서버 역시 클라이언트를 확인합니다. 클라이언트가 신뢰받는 인증기관으로부터 인증서를 발급받은 클라이언트여야 데이터 통신이 가능합니다. 일단은 이 기능이 요즘 마이데이터 사업 때문에 API 구간에 반드시 들어가야 된다고 요구되고 있고, 웹방화벽에서 지원하고 서비스하고 있습니다.
​
# 2
두번째는 식별정보 클로킹이라고 해가지고 여러분들 여기 url을 보시면 하나의 물리적 서버에 식별정보로 인해서 사용자를 구분하고 있습니다. A 사용자가 자기들의 쇼핑몰에서 판매한 영업 이력들. 이익정보를 나열하고있는 서비스입니다. 이렇게 url에 자신의 마켓A의 식별정보를 담아서 보내게 됩니다. 그런데 클라이언트 A가 보니까 이것을 수정하게 되면 별다른 조치가 취해져 있지 않는 한 회사 사용자가 아님에도 불구하고 마켓의 이익정보가 그대로 전해질 수 있습니다. 애플리케이션을 잘 보안해서 만들면 잘 방어할 수 있습니다. 하지만 취약하다면 중간에 있는 저희 웹방화벽과 같은 장비들이 보호를 해줘야 할 필요성이 있는 것이죠. 

기존의 웹방화벽은 서버에서 흘러나오는 데이터를 클로킹하는 기능은 가지고 있습니다. 개인정보에 대한 식별정보, 개인정보에 대한 유출을 우려해서 그럴 경우 막고는 있지만 사용자가 서버로 전달하는 데이터에 대한 클로킹은 없습니다. 그래서 이런 것들이 필요하구요. 
​
# 3
HTTP 프로토콜은 Stateless라고 말씀드렸다시피 API에서는 웹토큰을 이용한다고 말씀드렸는데요. 이 웹토큰이 중간에 유출되면 여러가지 피해가 예상됩니다. 그래서 웹방화벽은 중간에서 웹토큰이 클라이언트에게 제대로 전달되서 다시 사용되는지 확인을 합니다. 기존에 웹방화벽은 쿠키에 대한 것들은 잘되어 있어요. 웹 애플리케이션에 사용하는. 그런데 JSON Web Token에 대해서는 API에 대한 경험이 없으면 이런 것들의 기능을 확인해볼 필요가 있습니다.
​
# 4
그리고 네 번째로는 DoS 공격 중의 일환인데요. API 엔드포인트에서 서비스를 요청하면 서버는 요청을 처리하기 위해 CPU의 자원이 필요하고요. 또한 메모리, 스토리지 등의 자원이 필요합니다. 하지만 이러한 자원은 유한적인 거잖아요. 자원이 다 고갈되면 DoS 공격 상태로 빠지게 되는데. 그런 것들을 보호하려면 서버의 용량을 잘 알아야겠죠. 용량 이상의 콜이 유입되면 안되니까. 그런 것들을 기반으로 임계값 제한의 기능이 필요합니다.

# 5 
API는 전달하는 데이터 형태가 JSON. JSON 데이터 포맷 형태를 거의 취하고 있습니다. 그런데 애플리케이션 구현 형태에 따라 다르지만, 이런 경우가 비일비재해요. 클라이언트는 정보를 요청하는데 서버는 그것보다 과도한 정보를 줘요. 내가 필요한 정보를 서버가 필터링해서 주는 것이 아니라 클라이언트가 필터링해서 디스플레이해주는 형태로 개발이 그렇게 되고 있습니다. 편하게. 그런데 여기에 이제 민감한 정보가 많이 포함되어 있으면, 데이터 유출로 이어지게 되겠죠. 그래서 클라이언트가 진짜로 필요한 정보가 무엇인지 그거에 대한 응답 데이터를 판단할 수 있는 그거에 대한 응답 제어 기능이 필요합니다.
​
# 6
그다음에 마지막으로요, 엔드포인트별 요청 형식 검사가 필요합니다. JSON 형태의 데이터가 서버에서 돌아오는 것을 검사하는 기능이 있었다면 반대로 클라이언트도 데이터를 JSON 형태로 전달하거든요. JSON 형태의 데이터 검사가 취약해서 아래와 같은 식으로 서버 명령어가 커맨드 인젝션으로 포함되서 전달되게 되면 원하지 않는 피해를 받을 수 있습니다.  그래서 SQL 인젝션이나 커맨드 인젝션 같은 경우는 기존의 웹방화벽이 잘 탐지해내고 있었지만 JSON에서 고도화되서 많은 뎁스의 JSON 데이터 검사할 수 있는 기능이 필요하다는 의민입니다.

이러한 6가지 기능이 잘 보완되면 웹방화벽에서 OWASP API TOP 10에서 열거하고 있는 10가지를 훌륭하게 방어할 수 있다고 생각되고요. 파이오링크 웹방화벽은 이미 이제 이런 것들이 구비가 되어 제품화되어 있습니다.