API를 위한 엔드투엔드 보안: 개발부터 폐기까지

Akamai는 2024년 6월 Noname Security를 인수했습니다. 이 블로그 게시물은 2022년 10월 5일에 처음 게시되었습니다.

API(Application Programming Interface)를 적절히 보호하는 것은 보안을 넘어서는 프로세스입니다. 또한 보안 성과를 이끌어내는 IT 운영 및 아키텍처 문제와도 관련이 있습니다. API 보안에 성공하려면 전체 소프트웨어 수명 주기를 포괄하는 엔드투엔드 프로세스로 보아야 합니다. API 보안은 개발에서 시작해 런타임과 서비스 종료까지 계속됩니다.

API 보안은 몇 가지 오래된 가정에 도전하게 합니다. 예를 들어, 소프트웨어 개발은 코드를 프로덕션에 배포하는 것으로 끝난다고 생각할 수 있습니다. 이는 더 이상 사실이 아닙니다. 이제 소프트웨어 개발은 코드를 작성하는 기본 프로세스보다 더 오래 지속됩니다.

개발은 CI/CD(Continuous Integration/Continuous Deployment)라는 개념으로 구체화된 지속적인 프로세스입니다. 이와 더불어 소프트웨어는 소프트웨어 개발(Dev)과 IT 운영(Ops)을 통해 소프트웨어를 제품에 배포하는 이전의 순차적인 단계를 결합한 DevOps를 통해 존재하게 됩니다.

오늘날 DevOps 팀은 코드가 프로덕션에 배포되자마자 애플리케이션의 또 다른 렌디션 배포를 준비하느라 바쁩니다. 다음 배포는 한 시간 후가 될 수도 있습니다. DevOps에서는 개발이 곧 운영입니다. 프로세스의 운영 측면은 더 이상 개발 측면과 구분할 수 없습니다. 따라서 애플리케이션에 대한 보안은 개발과 운영의 연결된 단계에 걸쳐 이루어져야 합니다.

또한 최신 소프트웨어는 단순한 코드 그 이상입니다. 마이크로서비스, API, 코드 라이브러리 등과 같은 구성요소 간의 연결 집합이기도 합니다. API를 안전하게 유지한다는 것은 이러한 연결이 어떻게 작동하는지, 어디에 있는지, 악의적인 공격자에게 어떻게 취약할 수 있는지를 이해하는 것을 의미합니다. 이 요구사항에는 일반적인 보안 관행을 넘어 API 인벤토리 생성 및 API 트래픽 모니터링과 같은 운영 작업도 포함됩니다.

API 보안은 애플리케이션의 개발 단계, 런타임, 그 이후에도 전체 SDLC(Software Development Lifecycle)에 걸쳐 활성화되어야 합니다. 개발자는 개발 단계부터 애플리케이션에 API 호출을 통해 API 기능을 호출하도록 지시하거나 다른 소프트웨어 애플리케이션에 앱의 기능과 데이터를 노출하는 API를 만들 수 있습니다. 두 가지 API 작동 모드 모두 리스크에 노출될 수 있습니다.

API 보안 리스크는 다양한 이유로 발생하지만 대부분은 사용자 인증 및 권한 부여에 영향을 미치는 API 설정 문제와 관련이 있습니다. API를 잘못 설정하면 알 수 없는 사용자가 민감한 데이터에 접속할 수 있습니다. 또는 설정이 잘못되어 사용자가 허용된 범위를 넘어서는 데이터를 가져올 수 있습니다. 기타 설정 문제로 인해 공격자가 API에 호출을 과부하시켜 서비스 거부(DoS) 공격을 실행할 수 있습니다. 

개발 단계

API 보안 테스트는 개발 단계에서 이러한 API 리스크를 방어할 수 있습니다. 범용 애플리케이션 테스트는 API 설정 오류와 같은 문제를 포착하지 못하므로 테스트는 API에 특화되어야 합니다. 대신, 전용 API 보안 테스트 제품군은 소프트웨어가 배포되기 전에 API 취약점을 식별하고 쉽게 해결할 수 있어야 합니다.

API 보안 테스트가 제대로 작동하려면 개발 프로세스 초기에 배치해야 하는데, 이를 시프트 레프트 접근 방식이라고 합니다. 또한 테스트 제품군은 CI/CD 파이프라인과 통합되어야 합니다. 그렇지 않으면 보안 수정 프로세스가 너무 번거로워서 DevOps 팀원이 처리하기 어렵습니다.

런타임 단계

런타임에서 API 보안은 실시간으로 위협을 차단하는 것을 의미합니다. 이를 위해서는 API 보안 모니터링이 필요합니다. API 보안 솔루션은 API 트래픽을 지속적으로 모니터링해 비정상적인 동작이나 공격 시그니처를 발견하면 관리자에게 알려야 합니다. 또는 솔루션이 위협을 탐지하면 API를 자동으로 차단하는 추가 단계를 수행할 수도 있습니다.

API 런타임 보안은 비교적 간단합니다. 하지만 API 보안 솔루션이 모든 API의 위치를 알고 있는 경우에만 작동합니다. 보안을 유지하려면 API는 API 검색 프로세스를 포함하는 API 체계 관리의 대상이 되어야 합니다. 보안 솔루션에 보이지 않는 API를 방어하는 것은 불가능하기 때문에 API를 인벤토리화해야 합니다. API 게이트웨이와 WAF(Web Application Firewall)는 사람들의 생각과 달리 환경의 모든 API를 자동으로 인벤토리화하지 않기 때문에 API 검색도 필요합니다.

악성, 좀비, 섀도 API: 세상에나!

API 검색 프로세스를 통해 IT 관리자는 필연적으로 자신의 환경에 '악성', '좀비', '섀도' API가 많이 포함되어 있다는 사실에 놀라게 됩니다.

• 악성 API 는 시간이 지남에 따라 어떻게든 사라진 API입니다. 아직 사용 중지되지 않은 이전 버전의 API일 수 있습니다. 아무도 알지 못하는 상용 패키지 소프트웨어 애플리케이션에 노출된 API일 수도 있습니다. 
• 좀비 API 는 레이더 화면에서 사라졌지만 정상적으로 작동하는 API입니다. 
• 섀도 API 는 누군가가 직접 API를 만들었지만 IT 부서에 알리지 않고 만든 것입니다.

세 가지 종류의 미발견 API는 모두 리스크에 노출됩니다. 보이지 않기 때문에 보안 정책을 적용할 수 없습니다. 보안을 위해 설정되지 않은 경우, 그리고 거의 항상 잘못 설정되거나 패치가 없는 경우 공격자에게 부적절한 접속을 허용하게 됩니다.

이전에 알려지지 않은 API를 어떻게 처리해야 할지 알기 어려울 수 있습니다. 이러한 API를 계속 운영하려면 설정, 인증 등과 관련된 정책을 준수해야 합니다. 방금 발견한 API를 차단하는 것이 최선의 선택일 수 있지만, 이로 인해 문제가 발생할 수 있습니다.

예를 들어, 이전 버전의 API가 교체되었음에도 불구하고 여전히 사용 중인 경우 이를 끄면 애플리케이션이 중단될 수 있습니다. API를 오프라인으로 전환하는 결정을 내렸다가 누군가가 곤경에 처할 수도 있습니다. 관리자가 올바른 결정을 내리는 데 필요한 정보를 제공하는 툴세트가 필요합니다.

엔드투엔드 방식으로 API 보안을 실행하려면 올바른 툴이 필요합니다. 효과적인 엔드투엔드 API 보안 솔루션은 API 보안 테스트, API 런타임 보안, API 보안 체계 관리, 인벤토리 관리를 처리할 수 있는 솔루션입니다. 대부분의 WAF와 API 게이트웨이는 개발, 테스트, 런타임 모니터링, 인벤토리를 지원하지 않기 때문에 기존 툴을 면밀히 살펴볼 필요가 있습니다.

또한 API 보안 솔루션은 네트워크나 API 성능에 영향을 미치지 않는 방식으로 작동하는 것이 이상적입니다. 예를 들어 Akamai API 보안 솔루션은 네트워크 트래픽의 사본을 모니터링하는 방식으로 작동합니다. 이 복사된 네트워크 트래픽에서 API 호출을 발견하고 그 과정에서 알려지지 않은 API와 보안 위협을 식별할 수 있습니다.

API 보안은 개발부터 런타임 및 폐기까지 API 수명의 모든 단계를 포괄해야 합니다. 보안은 API 인벤토리와 같이 기술적으로 보안과 관련이 없는 프로세스에서도 부분적으로 이루어집니다. 알려지지 않은 API는 리스크에 노출되므로 이를 식별하면 애플리케이션의 보안이 강화됩니다. 즉 엔드투엔드 제안입니다. API 보안 조치가 더 완벽할수록 전체 환경이 더 안전해집니다.