.jpg)
.jpg)
API를 연결고리 삼아 많은 관계자들이 데이터에 접속 가능
접근 용이성과 보안성 균형 잘 맞추는 것이 보안 담당자들의 관건
[보안뉴스 문가용 기자] 애플리케이션 경제의 정체가 드러났다. 바로 API 경제다. 조직 내 API의 중요도가 점점 높아지면서 보안에 대한 걱정거리가 늘어나고 있기도 하다. API가 거래되는 때에 보안이 제대로 갖춰지지 않는다면, 소프트웨어 전체를 위험에 빠트리는 것이기 때문이다.
소프트웨어 혁신이 오늘날의 경제를 하루가 다르게 변혁시키고 있는데, 이는 비단 소프트웨어의 뛰어난 기능 때문만은 아니다. 서로 다른 소프트웨어와 기기들 간의 ‘조화’와 그로 인한 ‘시너지 효과’가 이 소프트웨어 시대의 진정한 비밀이다. 같은 조직 내 부서 간, 혹은 외부 플랫폼을 통하여 이뤄지는 파트너사와의 협업, 고객 기기와 내부 서버 사이의 연동을 가능케 하는 것이 소프트웨어로부터 요구되는 진정한 ‘파워’라는 것이다. 그 핵심은 바로 API라는 ‘풀’이다.
하지만 풀을 잘못 사용하면 엉뚱한 정보들이 묻어나갈 수 있다. API도 적절한 보호 장치 없이 공유되면 전에 없던 전혀 새로운 공격들이 가능하게 된다.
보안 업체 임퍼바(Imperva)의 CTO인 테리 레이(Terry Ray)는 “API는 기업의 데이터에 접근하고 싶어하는 해커들에게 새로운 기회들을 제공하기도 한다”고 말한다. “보안 리스크를 없애고 고객과 기업들을 성공적으로 지켜내려면 API를 사업에 꼭 필요한 웹 애플리케이션들을 보호하듯 보호해야 합니다.”
하지만 API에 보안 위험성이 존재한다고 해서 사용을 완전히 배재할 수는 없다. 사업 전략의 중요한 자원으로서 자리 잡아가고 있기 때문이다.
“API가 수익원으로서 잠재력이 큰 이유는 여러 플랫폼과 애플리케이션과의 연동을 통해 새로운 사업 모델을 빠르게 구현하거나 기존 사업 모델을 순식간에 확장시킬 수 있게 해주기 때문입니다.” 기업용 소프트웨어 전략 기업인 IQMS의 루이스 콜럼버스(Louis Columbus)의 설명이다.
게다가 API의 대두로 소프트웨어의 개발 및 구축 방법론부터 새롭게 바뀌고 있다. 발 빠른 출시와 가벼움이 소프트웨어 산업의 필수 덕목으로 자리 잡음에 따라 기존의 덩치 큰 코드들은 독립적인 작은 단위로 분해되기 시작했다. 이 작은 단위를 마이크로서비스라고 부른다. 요즘 개발 업체들은 이런 마이크로서비스를 벽돌처럼 사용해 애플리케이션을 만든다. 그래서 버그를 고치거나 오류를 잡다가 실수로 코드 전체에 영향을 주는 행위도 막아진다. 이 마이크로서비스들끼리 붙여주고 연결시켜주는 것이 API의 역할이다.
그렇기에 최근 임퍼바의 조사 결과로 일반 조직들이 평균 363개의 API를 관리하고 있다고 나온 것이 그리 놀랍지도 않다. 보안 담당자라면 이런 상황에서 ‘API가 가지고 오는 리스크란 무엇일까?’를 묻고 탐색해야 한다.
먼저 임퍼바의 조사 결과를 보면 조직들의 2/3 이상이 API들을 ‘전체 공개’한다고 한다. 외부 파트너들과 개발자들의 능력을 최대한 끌어내고 활용하기 위해서다. 사업적인 측면에서 이러한 방침은 큰 기회가 될 수도 있지만 위험한 결정일 수도 있다. 250명의 IT 및 봉나 전문가들에게 물었을 때 39%가 API에 가해지는 악성 봇과 디도스 공격을 걱정하는 것으로 나타났다. 이는 가장 큰 ‘걱정거리’인 것으로 나타났다.
또한 25%에 해당하는 응답자들은 인증 기술이나 정책을 도입시키는 방법에 대해 걱정하고 있었다. 즉, 민감한 데이터에는 접근하지 못하도록, 일부 데이터만 선별적으로 노출시키는 방법에 대한 고민이 많다는 것이다. 예를 들어 은행의 경우 자신들이 개발한 애플리케이션과 고객들이 사용하는 애플리케이션들과의 연동을 이루고 싶어 하지만, 고객들이 은행 앱에 로그인할 때 사용하는 크리덴셜까지 노출시키고 싶어 하지 않는다. 공유하고 연동하는 부분에 노출될만한 위협거리가 존재한다는 것이다.
현재 기업들의 약 76%가 “API 보안을 웹 보안 수준으로 하지는 않고 있다”고 답하기도 했다. 웹 애플리케이션 방화벽을 API 보호하는 데에 같이 활용하고 있다고 답한 조직은 63%였다. 비슷한 비율의 조직들이 API 게이트웨이를 사용하고 있다고 답하기도 했다. 하지만 런타임 애플리케이션 셀프 프로텍션(runtime application self-protection, RASP)을 사용해 공격을 막는다는 조직은 절반도 되지 않았다.
“웹 API를 노출시키고 있는 곳이라면 접근의 용이성과 접근의 통제 사이의 균형을 맞추는 것이 지상 과제입니다. 즉 보호는 보호대로 하면서, 사업성은 사업성대로 살려야 한다는 겁니다.” 가트너의 분석가인 마크 오네일(Mark O'Neill)의 설명이다. “은행 강도들은 은행에 돈이 있으니까 은행을 텁니다. API를 통해 주요 정보에 접근할 수 있게 된다면, 당연히 범죄자들이 꼬이게 될 겁니다.”
[국제부 문가용 기자(globoan@boannews.com)]
접근 용이성과 보안성 균형 잘 맞추는 것이 보안 담당자들의 관건
[보안뉴스 문가용 기자] 애플리케이션 경제의 정체가 드러났다. 바로 API 경제다. 조직 내 API의 중요도가 점점 높아지면서 보안에 대한 걱정거리가 늘어나고 있기도 하다. API가 거래되는 때에 보안이 제대로 갖춰지지 않는다면, 소프트웨어 전체를 위험에 빠트리는 것이기 때문이다.
[이미지 = iclickart]
소프트웨어 혁신이 오늘날의 경제를 하루가 다르게 변혁시키고 있는데, 이는 비단 소프트웨어의 뛰어난 기능 때문만은 아니다. 서로 다른 소프트웨어와 기기들 간의 ‘조화’와 그로 인한 ‘시너지 효과’가 이 소프트웨어 시대의 진정한 비밀이다. 같은 조직 내 부서 간, 혹은 외부 플랫폼을 통하여 이뤄지는 파트너사와의 협업, 고객 기기와 내부 서버 사이의 연동을 가능케 하는 것이 소프트웨어로부터 요구되는 진정한 ‘파워’라는 것이다. 그 핵심은 바로 API라는 ‘풀’이다.
하지만 풀을 잘못 사용하면 엉뚱한 정보들이 묻어나갈 수 있다. API도 적절한 보호 장치 없이 공유되면 전에 없던 전혀 새로운 공격들이 가능하게 된다.
보안 업체 임퍼바(Imperva)의 CTO인 테리 레이(Terry Ray)는 “API는 기업의 데이터에 접근하고 싶어하는 해커들에게 새로운 기회들을 제공하기도 한다”고 말한다. “보안 리스크를 없애고 고객과 기업들을 성공적으로 지켜내려면 API를 사업에 꼭 필요한 웹 애플리케이션들을 보호하듯 보호해야 합니다.”
하지만 API에 보안 위험성이 존재한다고 해서 사용을 완전히 배재할 수는 없다. 사업 전략의 중요한 자원으로서 자리 잡아가고 있기 때문이다.
“API가 수익원으로서 잠재력이 큰 이유는 여러 플랫폼과 애플리케이션과의 연동을 통해 새로운 사업 모델을 빠르게 구현하거나 기존 사업 모델을 순식간에 확장시킬 수 있게 해주기 때문입니다.” 기업용 소프트웨어 전략 기업인 IQMS의 루이스 콜럼버스(Louis Columbus)의 설명이다.
게다가 API의 대두로 소프트웨어의 개발 및 구축 방법론부터 새롭게 바뀌고 있다. 발 빠른 출시와 가벼움이 소프트웨어 산업의 필수 덕목으로 자리 잡음에 따라 기존의 덩치 큰 코드들은 독립적인 작은 단위로 분해되기 시작했다. 이 작은 단위를 마이크로서비스라고 부른다. 요즘 개발 업체들은 이런 마이크로서비스를 벽돌처럼 사용해 애플리케이션을 만든다. 그래서 버그를 고치거나 오류를 잡다가 실수로 코드 전체에 영향을 주는 행위도 막아진다. 이 마이크로서비스들끼리 붙여주고 연결시켜주는 것이 API의 역할이다.
그렇기에 최근 임퍼바의 조사 결과로 일반 조직들이 평균 363개의 API를 관리하고 있다고 나온 것이 그리 놀랍지도 않다. 보안 담당자라면 이런 상황에서 ‘API가 가지고 오는 리스크란 무엇일까?’를 묻고 탐색해야 한다.
먼저 임퍼바의 조사 결과를 보면 조직들의 2/3 이상이 API들을 ‘전체 공개’한다고 한다. 외부 파트너들과 개발자들의 능력을 최대한 끌어내고 활용하기 위해서다. 사업적인 측면에서 이러한 방침은 큰 기회가 될 수도 있지만 위험한 결정일 수도 있다. 250명의 IT 및 봉나 전문가들에게 물었을 때 39%가 API에 가해지는 악성 봇과 디도스 공격을 걱정하는 것으로 나타났다. 이는 가장 큰 ‘걱정거리’인 것으로 나타났다.
또한 25%에 해당하는 응답자들은 인증 기술이나 정책을 도입시키는 방법에 대해 걱정하고 있었다. 즉, 민감한 데이터에는 접근하지 못하도록, 일부 데이터만 선별적으로 노출시키는 방법에 대한 고민이 많다는 것이다. 예를 들어 은행의 경우 자신들이 개발한 애플리케이션과 고객들이 사용하는 애플리케이션들과의 연동을 이루고 싶어 하지만, 고객들이 은행 앱에 로그인할 때 사용하는 크리덴셜까지 노출시키고 싶어 하지 않는다. 공유하고 연동하는 부분에 노출될만한 위협거리가 존재한다는 것이다.
현재 기업들의 약 76%가 “API 보안을 웹 보안 수준으로 하지는 않고 있다”고 답하기도 했다. 웹 애플리케이션 방화벽을 API 보호하는 데에 같이 활용하고 있다고 답한 조직은 63%였다. 비슷한 비율의 조직들이 API 게이트웨이를 사용하고 있다고 답하기도 했다. 하지만 런타임 애플리케이션 셀프 프로텍션(runtime application self-protection, RASP)을 사용해 공격을 막는다는 조직은 절반도 되지 않았다.
“웹 API를 노출시키고 있는 곳이라면 접근의 용이성과 접근의 통제 사이의 균형을 맞추는 것이 지상 과제입니다. 즉 보호는 보호대로 하면서, 사업성은 사업성대로 살려야 한다는 겁니다.” 가트너의 분석가인 마크 오네일(Mark O'Neill)의 설명이다. “은행 강도들은 은행에 돈이 있으니까 은행을 텁니다. API를 통해 주요 정보에 접근할 수 있게 된다면, 당연히 범죄자들이 꼬이게 될 겁니다.”
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
