API (Application Programming Interface)와 보안리스크

출처: What is an API? (API) Application Program Interface Definition (apifriends.com)

API는 Application Programming Interface의 약자로 서로 다른 응용 프로그램들(Applications)이 상호 연동이 가능하도록 연결시켜주는 매개체(a software intermediary that allows two applications to talk to each other)로서 사용자들이 원하는 결과를 얻을 수 있도록 도와준다. 

API를 이해하기 위해서는 함수 (Functions)와 라이브러리 (Library)에 대한 이해가 필요하다. 

• 함수 (Function): 프로그래밍에서도 반복되는 명령어들을 찾아 별도로 묶어 뒀다가 필요할 때마다 불러 쓸 수 있는데 이를 함수라 부른다. 함수의 내용을 하나하나 나열한 부분을 함수 정의라 하고, 함수가 실행될 위치를 표시하여 이 곳에서 해당 함수가 실행되도록 명령하는 것을 함수 호출이라고 한다. 
• 라이브러리 (Library): 반복적으로 사용되는 특정 함수들을 저장하는 곳. 이런 경우 똑같은 함수를 다시 만들 필요 없이 원하는 기능의 라이브러리 함수를 사용함으로써 보다 효율적인 프로그래밍이 가능하다.

API는 사용자들 또는 프로그래머들이 이러한 함수 라이브러이에 접근하기 위한 규칙들을 정의한 것이다. 다시 말해서, 프로그래머가 프로그램을 작성할때 기존의 함수를 다시 작성하거나 함수 구성요소를 이해할 필요 없이, 라이브러리에서 함수를 호출하여 API에 정의된 입력 값을 주고 결과값을 사용할 수 있도록 해준다.

이렇게 적어봐도 아직 헷갈리고 어렵게 느껴진다.

음식을 예로 들어 생각해보자.

항상 끼니때가 되면 우리는 '집에서 밥해먹을까 아니면 밖에서 사먹을까'라는 생각을 한다. 집에서 밥해먹는 것은 본인이 직접 요리를 해야한다는 뜻이다. 그만큼 시간이 들고, 요리하는 사람에 따라서 원하는 만큼 양질의 식사를 한다는 보장이 없다. 프로그래머로 치면 본인이 쓸 함수를 하나하나 정의하며 만들어가는 것을 말한다. 마찬가지로 시간도 많이 들고 양질의 프로그램을 만든다는 보장이 없다.

외식을 하게 되면 식당을 가서 메뉴판을 보고 원하는 음식을 골라 웨이터에게 주문을 한다. 웨이터는 주문받은 음식을 주방에 전달하고 음식이 주방에서 완성되면 웨이터는 손님에게 음식을 서빙한다. 주방에서 요리사들이 제공할 수 있는 음식을 담은 메뉴는 이용가능한 함수들이 보관된 라이브러리라고 생각하면 된다. 메뉴에서 원하는 함수를  고르면 이 요청을 주방 또는 라이브러리로 전달하는 웨이터는 API라 보면 되는 것이다. 이렇게 되면 짧은 시간에 원하는 양질의 함수를 가져와 보다 효율적으로 프로그래밍 작업을 할 수 있게 된다.

우리가 실제생활에서 관찰할 수 있는 예를 찾아보자. Pinterest에 회원 가입을 신청하면 아래와 같은 화면이 뜬다.

출처: Pinterest 가입화면

신규 회원 아이디와 패스워드를 입력하는 대신, 기존의 페이스북 또는 구글 계정을 이용하여 Pinterest에 가입할 수 있다. 이것은 페이스북과 구글이 계정이용에 관련된 함수를 API를 통해 Pinterest와 공유하면서 가능해진 것이다. 이렇게 서로 다른 응용프로그램, 데이터베이스, 서비스가 API를 통해 함수를 공유하는 것을 Open API라고 부른다.

API를 이용한 IT 기업들의 서비스확대가 주목받고 있다. 한국에서는 카카오톡을 기반으로 한 카카오 뱅크가 대표적이다. 미국은 최근 테슬라가 자율주행기능 사용회원 가입(Full Self-Driving Subscription)과 연계된 테슬라만의 자동차보험서비스를 이용할 수 있도록 해주는 스마프 애플리케이션이 API를 기반으로 개발되었다. 우리가 이용하고 있는 티스토리 역시 다음, 구글, 제3자 서비스를 기반으로 여러가지 플러그인을 제공하고 있다. 이러한 플러그인 역시 API를 기반으로 만들어진 것이다. 많은 기업들이 통합 API (Integrated API)나 서비스 API에 대한 투자를 강화하고 있다. 이에 따른 API 관련 리스크도 충분히 고려해야 한다.

많은 기업들이 여러 API 서비스를 이용하기 시작하면 해커들 역시 API 상에서 이용가능한 데이터를 이용해 기업 보안망에 침투하려 하고 있다. 가장 흔한 실수 중 하나가 기업 IT 부서가 API를 설치하고 난 후 이 API를 기업내 IT 자산 시스템 (Configuration Management Database; CMDB)에 등록시키지 않아 보안감시망 (Security Monitoring)에서 누락되는 것이다. 감시망에서 누락된다는 것은 적절한 보안통제활동이 전혀 이루어지지 않는 것을 뜻하게 되므로 해커들이 가장 뚫기 쉬운 관문이 될 수 있다. 

인터넷 보안 취약점을 전문적으로 연구하는 오픈소스 웹 애플리케이션 보안 프로젝트 (The Open Web Application Security Project: OWASP)에서는 2019년 12월 31일 API에 관련된 10개의 보안리스크를 발표한 후 지속적으로 업데이트를 해오고 있다. 

간단히 리스트를 요약해서 설명하면

• API1:2019 - 접근자들에 대한 적절한 인증 및 접근권한 관리 실패 (Broken object level authorization)
• API2:2019 - 암호(패스워드) 관리 실패 (Broken authentication)
• API3:2019 - 공공 웹싸이트상에 지나치게 많은 정보 유출 (Excessive data exposure)
• API4:2019 - 디도스나 무제한 공격에 취약한 환경설정 (Lack of resources and rate limiting)
• API5:2019 - 적절한 접근권한 및 관리자 계정관리 실패 (Broken functional level authorization)
• API6:2019 - 적절한 필터링 없이 받아들이는 대량정보 (Mass assignment)
• API7:2019 - API 서버 상 충분치 않은 보안환경설정 (Security misconfiguration)
• API8:2019 - API call 상에서 해킹을 위한 명령문 삽입 (Injection)
• API9:2019 - 자산관리 시스템 (CMDB)에서 API관련 서버 누락 (Improper assets management)
• API10:2019 - 보안관리 감시망에서 API 관련 서버 누락 (Insufficient logging and monitoring)

보다 자세한 정보를 원하다면 아래 링크를 이용하면 될 듯 하다.

OWASP API Security Top 10

OWASP API Security Top 10

 

이를 예방할 수 좋은 방법 중 하나는 API 설치 및 배포시 개발자들에게 하드코딩을 의무화시키도록 하면서 API 관련 서버를 자산관리 시스템 (CMDB)에 포함시켜 상시로 감시감독하는 것이다. 또한 데브세크옵스 (DevSecOps) 프로세스를 실행하여 보안관리가 API 개발 초기단계에 이루어지도록 해야 한다.

API에 대해 기초적인 이해와 어떻게 기업에 이용되고 있는지, 그리고 이에 따른 리스크를 인식하고 통제해야 하는지에 대해 간략히 살펴봤다. 나중에 시간되면 좀더 심층있게 다루어볼만한 주제인 듯 하다.

참고한 자료들 목록

1. API (naver.com) : 두산백과
2. API (naver.com) : 학생백과, 소프트웨어 어휘다지기
3. What is an API? (Application Programming Interface) | MuleSoft : Mule Soft API Strategy
4. Application Programming Interfaces (APIs) (kpmg.us) KPMG API 실행시 유의사항
5. OWASP API Security Top 10 OWASP 탑10 API 관련 리스크.