블로그 | 클라우드 위협하는 API 보안 문제, 현명하게 대처하는 방법

마이크로소프트 클라우드 컴퓨팅이 최근 먹구름에 휩싸였다. 인증을 악용하는 공격자의 표적이 되고 있을 뿐 아니라, 클라우드 서비스 전반에 인증과 관련된 문제가 있다는 테너블(Tenable)의 지적까지 받고 있기 때문이다. 마이크로소프트가 올린 게시물과 테너블이 작성한 글은 모두 클라우드 인증 문제와 몇 가지 약점을 조명했다.
 

테너블은 마이크로소프트의 클라우드 보안에 대한 투명성 부족을 비판했다. 테너블 CEO 아미트 요란이 설명했듯이 해당 문제는 “마이크로소프트 파워 플랫폼(파워 앱스, 파워 오토메이션) 맞춤형 커넥터가 만들어지고 운영되는 과정에서 실행되는 애저 펑션 호스트에 대한 불충분한 액세스 제어로 인해 발생”했다.

애저 URL을 추측으로 알아낼 수 있다면 인증하지 않아도 액세스 권한을 획득할 수 있다. 요란은 “따라서 맞춤형 커넥터와 연결된 애저 펑션의 호스트 이름을 알아낸 공격자는 인증 없이 맞춤형 커넥터 코드에 정의된 대로 함수와 상호작용할 수 있다. 호스트 이름을 확보한 공격자는 다른 고객의 맞춤형 커넥터와 연결된 애저 펑션의 호스트 이름까지 알아낼 수 있다. 이름에서 정수 하나만 다르기 때문”이라고 말했다.

마이크로소프트는 기술 노트를 통해 파워 플랫폼 맞춤형 코드 정보 공개를 취약성을 완화했으며, 마이크로소프트 365 관리자 센터(MC665159)를 통해 2023년 8월부터 영향을 받는 고객에게 해당 문제를 알렸다고 밝혔다. 알림을 받지 않은 고객은 아무런 조치도 할 필요가 없다.

클라우드 보안을 위협하는 API

이번 문제의 핵심은 사람의 로그인 없이 소프트웨어 요소 간 서비스 또는 연결을 제공하는 애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces, API)다. API에서는 별다른 일이 발생하기 전까지는 대체로 보안에 접근하기가 어렵다.

대부분 기업은 소프트웨어를 점검하고 뚜렷한 취약점이 없음을 확인하기 위해 전문 컨설턴트를 채용해야 한다. 오픈소스부터 사유 소프트웨어에 이르기까지 관련 전문가가 검토하기 않고 솔루션 업체 자체의 검토만으로는 문제를 발견하기 어렵기 때문이다.

국제 웹 보안 분야 비영리 재단 OWASP(The Open Web Application Security Project)이 10가지 주요 API 보안 위협을 정리한 문서에는 API를 다룰 때 주의해야 하는 중요 문제가 정리돼 있다. OWASP는 부실한 객체 수준 권한 부여부터 안전하지 않은 API 소비에 이르기까지, API 사용을 무턱대고 신뢰하는 경우가 너무 많다고 지적한다.

또한 많은 사람을 위한 서비스를 제공한다는 이유로 API 사용을 제한하지 않는 경우도 많다. 많이 사용되지 않는 API가 있다면 현재 베타 단계에 있는 부가적인 보호 및 방어 기술을 사용하는 방안을 고려해야 한다.

실시간 위협 완화에 도움이 되는 IP 방화벽

이런 솔루션 중 일부는 아직 널리 채택되지 않았고 여전히 공개 프리뷰 단계에 있다. 대표적인 예가 파워 플랫폼 환경에서 현재 프리뷰 단계로 제공되는 마이크로소프트의 IP 방화벽 솔루션이다. 마이크로소프트 문서에 명시된 바와 같이 IP 방화벽은 데이터 유출과 같은 내부자 위협을 실시간으로 완화한다. 마이크로소프트는 “악의적 사용자가 엑셀 또는 파워 BI와 같은 클라이언트 툴을 사용해서 데이터버스(Dataverse)에서 데이터를 다운로드하려고 시도하는 경우 IP 위치를 기반으로 데이터 다운로드가 차단된다”라고 설명했다.

IP 방화벽은 구성된 IP 범위 바깥에서 이뤄지는 토큰 리플레이 공격을 차단하는 데도 도움이 된다. 설명에 따르면, 사용자가 토큰을 훔쳐서 이를 구성된 IP 범위 밖에서 데이터베이스에 접근하는 데 사용하는 경우 데이터버스가 실시간으로 액세스를 거부한다. IP 방화벽은 대화형 시나리오와 비대화형 시나리오에서 모두 작동하며 관리형 환경에서 사용 가능하고, 데이터버스가 포함된 모든 파워 플랫폼 환경에서 지원된다.

API 보안 문제에 대처하는 방법 : 기본에 충실하기

API 보안 문제는 결국 다음과 같은 기본적인 사항으로 귀결되는 경우가 많다.
 

• 권한. API 권한의 기본을 간과하지 말고 API에 클라우드 서비스에 대한 과도한 권한을 허용하지 말아야 한다. 사용자 액세스와 마찬가지로 권한은 노출 또는 공격으로 이어질 수 있다. 액세스 권한 사용을 필요한 최소한으로 제한해야 한다.
• 패치의 기본을 간과하면 안 된다. 종류를 불문하고 모든 소프트웨어는 업데이트해야 하며 클라우드 구현도 마찬가지다. 얼만큼의 최신 소프트웨어를 배포해야 하는지 인식하고 있어야 한다. 전통적인 패치 기법이 통하는 경우도 있지만 재배포가 필요한 경우도 있다. 선택할 수 있는 옵션을 벤더와 함께 검토해야 한다.
• 필요한 것만 활성화한다. 비용과 액세스 권한을 제한하려면 필수적인 기능만 활성화해야 한다. 기능을 활성화했더라도 이후 필요가 없어지면 비활성화해야 한다.
• 요청을 면밀히 점검해야 한다. 수신되는 요청과 로그 파일을 검토하고 요청이 이뤄지는 방식에 불일치하는 부분이 있는지 확인한다.
• 안전한 전송을 강제한다. 전송 계층 보안(Transport Layer Security, TLS) 활성화 등 안전한 전송의 기본 원칙을 따른다.
• 캐시 제어를 모니터링한다. 브라우저 및 기타 중개자가 웹 리소스를 캐시하고 검증하는 방법을 제어하는 보안 또는 캐시 제어 지시문 및 지침을 클라이언트에 대해 설정해야 한다.
• 정책을 감독한다. 교차 출처 리소스 공유에 대해 잘못 설정된 정책이나 누락된 정책이 있는지 파악한다.
• 오류 메시지의 내용은 무엇인가? 오류 메시지를 검토해서 민감한 정보 유출 가능성을 파악해야 한다.

잠재적 API 취약점 관리로 문제 예방하기

물론 API 역시 다른 모든 기술적 요소와 마찬가지로 악용될 가능성이 큰 비밀번호에 취약하다. 따라서 API는 약한 비밀번호를 허용하지 않고 자격 증명 스터핑에 노출되지 않도록 코딩해야 한다. 취약하게 해시되는 비밀번호 역시 차단해야 한다.

또한 데스크톱 애플리케이션부터 모바일, 상글사인온 구현에 이르기까지 애플리케이션에서 사용될 수 있는 모든 인증 흐름을 검토해야 한다. 정기적인 검토 일정을 마련해서 다양한 메커니즘을 검토하는 것이 좋다. 민감한 정보에 대한 액세스에는 부가적인 인증을 의무화하고 계정 정보 변경에 대한 액세스에도 의무적인 추가 인증을 도입해야 한다.

마지막으로, 다중 인증을 구현하고 어떻게 작동하는지 지속적으로 검토해야 한다. 다중 인증 방법으로 SMS를 제공하는 것만으로는 향후 요구사항을 충족하기에 부족하다. 어떤 방식이든 없는 것보다는 낫지만, 인증 방법을 개선하는 데 항상 관심을 기울여야 한다.

잠재적 API 취약점을 관리하는 방법에는 솔루션 업체에 인증을 강화하고 적시에 정보를 제공하도록 요청하는 것도 포함된다. 마이크로소프트가 더 잘해야 하는 것은 분명하다. 그런데 나머지 업체들은 과연 필요한 정보를 충분히 제공하고 있는가? 필자는 모두가 제 역할을 잘해야 한다고 생각한다.
editor@itworld.co.kr