강력한 API 보안, 단편적인 접근 방법이 아닌 프로그램이 필요

API(Application Programming Interface)는 두 개의 애플리케이션이 상호 대화할 수 있도록 하는 프로그래밍 명령어와 표준, 프로토콜이 포함된 일종의 소프트웨어다. API는 기본적으로 두 시스템 사이에 데이터가 오가는 다리 역할을 한다.

포레스터 리서치의 부사장 겸 애플리케이션 개발 정보를 다루는 수석 분석가 랜디 헤프너에 따르면, API에서 이런 다리를 구축하는 방법은 여러 가지다.

개방형(혹은 퍼블릭) API는 개발자에게 공개적으로 제공된다. 이 외의 API는 비즈니스 관계가 있는 조직 간에만 공개되도록 제한된다(기존에 관계가 있거나 해당 API를 위해 관계 구축). 조직 내부 애플리케이션을 연결하는 데 사용되는 프라이빗 API도 있다. 일부 조직에서는 API를 제품으로 사용해 다른 방법으로는 제공이 불가능한 서비스를 구현하기도 한다.

헤프너는 기업이 내부 애플리케이션 상호 연결은 물론, 내부 애플리케이션과 비즈니스 파트너, 개발업체와 소비자 애플리케이션과의 연결을 위해서도 더 많은 API를 구축하고 있다고 말했다.

이들은 맞춤형 소프트웨어 및 아키텍처와 같은 더 전통적인 통합 프로세스보다 API를 사용해 시스템을 연결하는 편을 선호한다. API는 전통적인 접근 방식보다 뛰어난 속도와 민첩성을 제공하면서 안전한 데이터 경로까지 보장하기 때문이다.

적어도 목표는 그렇다. IT 컨설팅 업체 런치애니(LaunchAny) 창업자이자 CEO 제임스 히긴보텀은 "API를 잘 설계하면 작성해야 할 코드 양이 적고 두 가지 시스템의 작동 방식을 알아야 할 필요도 없으므로 통합 시간을 단축할 수 있다"고 말했다.

API, 완벽한 솔루션은 아니다
엔터프라이즈 IT 스택 내의 다른 요소와 마찬가지로 API 역시 적절히 설계, 관리되지 않을 경우 조직과 주주를 위험에 노출시킬 수 있다.

애플리케이션 네트워크 공급업체 뮬소프트(MuleSoft) CTO 유리 사리드는 "포괄적으로 말해 API는 단순한 하나의 기술이 아니라 비즈니스 동력으로 인식되는 지점에 이르렀으며 그 결과 API가 사실상 모든 것을 처리하고 있다"며, "API는 기업에서 큰 변화를 이끌었다. 'API를 사용해야 하나? API는 괜찮나? 어떤 데이터를 노출시켜야 하나?'에서 'API를 제대로 보호하는 방법은 무엇인가?'로 생각이 바뀌었다"고 말했다.

사리드는 "그러나 실질적인 문제는 하나의 API를 어떻게 보호하느냐가 아니라, 모든 API에 적절한 수준의 보안을 보장하기 위한 조직 문화를 어떻게 구축할 것인지다"고 지적했다.

사리드는 "잘못된 API 설계와 관리는 데이터와 시스템 보안의 취약점을 유발할 수 있으므로 이는 중요한 질문이다. 전문가들은 API가 불완전할 경우 전체가 아닌 일부 데이터에 접근할 권한이 있는 사용자에게 애플리케이션 서비스에 포함된 정보가 필요 이상으로 노출될 수 있다"고 설명했다. 또한 불완전한 API는 해커가 데이터를 훔치거나 조직의 IT 인프라를 공격하는 데 악용하는 약점이 될 수도 있다.

히긴보텀은 "이런 일이 이미 일어나고 있다"면서, 2014년 불완전한 틴더(Tinder) API 해킹으로 사용자의 정확한 위치가 노출된 사례와 2015년 부실한 에이전시 API로 인해 발생한 IRS 데이터 유출 사건을 언급했다.

코네티컷 대학 교수이자 보안 혁신을 위한 컴캐스트 센터 오브 엑설런스(Comcast Center of Excellence for Security Innovation) 회장인 아미르 허츠버그는 "문제는 기술로서의 API가 아니라 사람의 잘못된 설계"라고 주장했다.

허츠버그는 이런 결함은 개발자들이 촉박한 기한을 맞추기 위해 생산을 서두르면서 발생하게 된다고 지적했다. 또한 API가 노출하는 시스템에 대한 프로그래머의 이해 부족도 원인이 된다. 때로는 라이브러리 코드 사용으로 인해 발생하기도 한다. 이런 코드가 필요한 수준의 보안을 제공하는지, 또는 보안 위협의 원인이 되는지 여부에 대한 확인없이 효율성을 이유로 현재 만들고 있는 API에 기존 모듈을 삽입하는 것이다.

허츠버그는 "API를 사용하면 위험이 따르지만 API를 사용하는 것 자체가 위험의 요인이 아니다. 문제는 API의 개념에 있지 않다"며, "제대로 설계된 API는 사실 전통적인 통합 방법에 비해 문제가 덜 발생하며 조직의 보안을 오히려 강화할 수 있다"고 설명했다. 그러나 이런 결과를 얻으려면 조직은 API를 제대로 설계하기 위해 노력을 기울여야 한다.

허츠버그는 "API는 보안을 위해 잘 설계되어야 한다. 실수 위험을 최소화하고 취약점을 최소화하는 API를 설계하면 API로 보안을 강제할 수도 있다"고 말했다.

API 보안 대책
허츠버그를 비롯한 보안 리더와 API 전문가들은 이런 결과를 얻으려면 API를 구축하고 관리하는 데 사용하는 규약을 강화해야 한다고 조언한다.

이를 위해 조직은 인증 및 암호화를 사용해 API를 통해 애플리케이션을 오가는 민감한 데이터를 보호하는 방안을 고려해야 한다. 사리드는 조직에서 API의 활동과 데이터 집합에 접근을 시도하는 잠재적인 이상 현상에 대한 가시성을 제공하는 접근, ID 및 이벤트 관리 기능도 둘 것을 권장했다.

헤프너는 "첫 번째 방어선은 API를 포함한 모든 요소를 위한 우수한 네트워크 보안 인프라다. 그 다음 API 내에 더 단순한 형태의 전략이 있다. 사용자 이름, 비밀번호, 디지털 서명과 같은 API 키 이상의 자격 증명이 여기에 해당된다"고 말했다.

사리드는 율속(rate limiting)과 스로틀링(throttling)을 사용해 한층 더 보안을 강화할 수 있다고 말했다. 이 두 가지는 일반적으로 보안 대책으로 간주되지 않지만 접근에 대한 부가적인 통제 수단을 구현함으로써 API를 더 효과적으로 보호하는 데 도움이 되기 때문이다.

헤프너는 누가 API를 사용할 수 있고 이런 API 사용이 언제, 어떤 방법으로 수행되는 지에 대한 규칙을 CIO가 명확히 해야 한다고 말했다.

헤프너는 "다양한 API 범주마다 서로 다른 수준의 보호가 필요하다"고 강조하며, "API를 사용하기 위한 등록 또는 파트너의 온보딩 프로세스를 어떻게 처리하느냐와 관계된 일이다. 사용자 커뮤니티를 사용하는 방법을 생각해야 한다. 예를 들어 B2B API를 사용해 얼마나 쉽게 작업을 할 수 있는가를 따져본다. 여기에서 관계는 기업과의 관계이며 기업에는 개발자가 있다. 그러나 개방형 API에서 개인은 사용자다. API를 대상으로 프로그램할 수 있는 비즈니스 직원, 고객에게 부여하는 통제 수단의 유형을 비즈니스 파트너가 어떻게 관리하느냐가 관건이다"고 설명했다.

히긴보텀은 이 외의 보안 대책으로는 API 관리 계층을 사용하는 것이 포함된다고 말했다. 이 경우 조직은 API에 대한 접근을 강제함으로써 예를 들어 악의적 공격을 더 정확히 탐지하고 적절한 승인이 완료될 때까지 접근을 차단할 수 있다.

보안 전문가들은 IT 조직은 거기서 멈추면 안 된다고 말한다. API 위의 보안 계층뿐만 아니라 API 자체가 구축되는 방법도 중요하다. 보안을 나중에 덧붙이는 부가적인 요소가 아니라 소프트웨어 자체에 내장하는 애플리케이션 개발 모범 사례에 따라야 한다. 허츠버그는 이를 위해 조직은 API에 구현되는 코드에 대해 심사숙고해야 한다고 말했다.

프로그래머는 API를 포함한 새 애플리케이션을 만들면서 기존 코드를 사용하는 경향이 있는데, 해당 코드의 출처나 보안 상태에 대해 잘 모르고 사용하는 경우도 있다. 따라서 CIO는 이 관행 자체를 금지하려는 생각을 하기 쉽다. 그러나 허츠버그는 프로그래머는 어차피 전면적인 금지를 피해갈 방법을 찾을 가능성이 높으므로 이 방법을 권하지 않는다.

허츠버그는 "합리적으로 대처해야 한다. 조직에서 사용하는 코드 모듈을 승인하는 일종의 메커니즘을 갖춰야 한다는 의미다"고 말했다.

공식적인 API 프로그램
이런 단계는 API 보안을 강화하는 데 도움이 될 수 있지만 전문가들은 IT 리더가 이런 단계를 단편적으로 구현하는 데 그쳐서는 안 된다고 지적했다.

그 대신 비즈니스 파트너와 함께 비즈니스 혜택과 위험을 바탕으로 API가 조직의 전략적 계획에 어떻게 들어맞을지, 언제 어떤 방법으로 사용해야 하는 지를 생각하고 API가 처리하는 데이터의 종류와 트랜잭션의 보안 필요성을 고려해야 한다.

사리드는 "API에 대해 일회성이 아닌 '이렇게 API를 보호한다'고 말할 수 있는 전체적인 접근 방법이 필요하다"고 말했다.

공식적인 API 프로그램은 API를 설계하고 배포하는 방법, API가 노출하는 데이터 및 그 용도, API가 조직의 보안을 위태롭게 하지 않고 강화하도록 보안 관점에서 API를 검토하는 방법에 대한 명확한 프로세스를 수립함으로써 모든 요소를 하나로 묶는다.

히긴보텀은 "견고한 API 프로그램을 보유한 기업은 생산되는 API가 이러한 규칙과 규정에 따르고 보안 검토를 거친다는 것을 입증하는 프로세스를 두고 있다. 간단해 보이지만 어떤 데이터가 노출되는지, 누가 그 데이터를 요청하는지, 데이터가 어떻게 사용되는지, 어떤 규정이 적용되는지를 살펴보기에는 충분하다"고 말했다.

또한 전문가들은 공식적인 API 프로그램이 보안을 확보하는 것 외에 비즈니스 목표와 API의 정렬을 강화하는 역할도 한다고 말했다.

히긴보텀이 설명한 대로, 강력한 API 프로그램을 보유한 CIO는 API가 어디에, 어떤 이유로 필요하며 어떤 시스템이 연결되고 어떤 데이터가 흐르는지를 명확히 해야 한다. 이런 통찰은 CIO와 그 비즈니스 동료가 API를 명확히 이해하는 데 도움이 된다. 조직의 목표가 출시 시간 단축이든 새로운 기회 포착이든 그 목표를 달성하는 데 도움이 되는 도구다.

히긴보텀은 "기술적인 관점뿐만 아니라 비즈니스 관점에서도 접근해야 한다. 그렇지 않으면 이런저런 API가 뒤섞여 비즈니스를 위험에 빠트리게 된다"고 말했다. 히긴보텀은 API 프로그램을 둔 기업은 API가 단순히 IT 배관의 일부가 아니라 전략적으로 적용하고 보호해야 하는 비즈니스 도구라는 점을 이해한다고 강조했다.

히긴보텀은 "일반적으로 제대로 하는 기업은 'API는 중요하고, 대처해야 할 비즈니스와 조직의 모든 측면을 나타내는 디지털 발자국을 나타낸다'는 점을 명시하는, CEO부터 시작되는 이니셔티브를 둔다"고 말했다.

사리드도 같은 의견이다. 사리드는 "API 보안에 대해 심사숙고할수록 더 많은 API를 사용해 비즈니스를 이끌 수 있고 이것이 CISO와 CIO가 원하는 것"이라며, "아니요라고 말하는 것이 능사가 아니라 더 신중하게 예라고 말하는 것이 중요하다"고 말했다. editor@itworld.co.kr