API 보안은 일반 애플리케이션 보안과 어떻게 다릅니까?
게시 됨: 2023-07-19때로는 동일하게 혼동되기는 하지만 애플리케이션 보안과 API 보안은 서로 다른 두 가지 분야입니다. 애플리케이션 보안은 전체 애플리케이션 보안을 의미하며, API 보안은 조직이 애플리케이션을 연결하고 데이터를 교환하는 데 사용하는 API 보안을 의미합니다. 따라서 조직은 두 분야에 대해 서로 다른 접근 방식을 취해야 합니다.
애플리케이션 보안이란 무엇입니까?
애플리케이션 보안(AppSec)은 인증, 암호화 및 보안 코딩 방식을 사용하여 사이버 공격으로부터 데이터와 시스템을 보호합니다. AppSec를 구현하는 조직은 데이터 침해 위험을 줄이고 민감한 데이터를 보호하며 애플리케이션이 업계 표준을 준수하는지 확인합니다.
ISACA는 AppSec 프로그램의 다섯 가지 주요 구성 요소를 다음과 같이 정의합니다.
- 보안 설계
- 보안 코드 테스트
- 소프트웨어 자재 명세서
- 보안 교육 및 인식
- WAF 및 API 보안 게이트웨이와 규칙 개발
API 보안이란 무엇입니까?
API 또는 애플리케이션 프로그래밍 인터페이스 보안은 사이버 공격으로부터 API를 보호합니다. 최근 몇 년 동안 API 사용이 폭발적으로 증가하여 애플리케이션 간 데이터 전송을 활성화함으로써 조직에 혁신의 기회를 제공했습니다. 불행하게도 API 사용이 증가함에 따라 이에 대한 공격도 시작되었습니다. Salt Security의 연구에 따르면 API에 대한 공격은 2022년 6월부터 12월 사이에 400% 증가했습니다.
애플리케이션 대 API 보안 위협
AppSec와 API 보안의 차이점을 이해하려면 각 분야의 주요 위협을 이해해야 합니다. 다행스럽게도 소프트웨어 보안 개선을 추구하는 비영리 조직인 OWASP는 애플리케이션 보안 및 API 보안에 대한 가장 심각한 위협에 대한 포괄적인 목록을 제공합니다. OWASP Top 10으로 알려진 이 목록은 OWASP의 글로벌 보안 전문가 커뮤니티의 정보를 수집하여 애플리케이션과 API에 대한 가장 중요한 위협을 식별합니다.
흥미롭게도 OWASP는 2003년에 상위 10개 웹 애플리케이션 보안 위험 목록을 발표했지만 2019년 말에야 상위 10개 API 보안 위험 목록을 발표했습니다. 이러한 불일치는 애플리케이션 보안과 API 보안 간의 또 다른 주요 차이점을 나타냅니다. 수많은 진화 단계를 거쳐 광범위하게 연구된 분야인 반면 API 보안은 그렇지 않습니다.
심층 분석을 할 시간은 없지만 각 목록을 간략하게 살펴보고 차이점을 확인하는 것이 좋습니다. 이를 통해 조직이 AppSec 및 API 보안에 접근하는 방법을 알 수 있습니다.
OWASP 상위 10대 애플리케이션 보안 위험(2021)
- 손상된 접근 통제 - 허가받지 않은 사용자가 제한된 정보나 시스템에 접근할 수 있는 경우
- 암호화 실패 – 암호화의 부족 또는 결함으로 인해 제3자가 특별한 의도 없이 민감한 데이터를 노출하는 경우
- 주입 – 공격자가 인터프리터에 전송된 명령의 의미를 변경하는 방식으로 애플리케이션에 데이터를 전송하려고 시도하는 경우
- 디자인이 안전하지 않음 – 아키텍처 및 디자인 결함과 관련된 위험
- 잘못된 보안 구성 - 보안 팀이 보안 제어를 부정확하게 구성하거나 보안 제어를 불안전하게 두는 경우
- 취약하고 오래된 구성 요소 – 조직이 구성 요소를 패치하지 않은 상태로 놔두는 경우
- 식별 및 인증 실패(깨진 인증 필요) - 애플리케이션이 인증 공격에 취약한 경우
- 소프트웨어 및 데이터 무결성 오류 – 코드 및 인프라가 무결성 위반으로부터 보호하지 못하는 경우
- 보안 로깅 및 모니터링 실패(불충분한 로깅 및 모니터링) – 조직이 부적절한 로깅 및 모니터링 절차로 인해 데이터 위반을 감지하지 못하는 경우
- 서버 측 요청 위조 - 방화벽, VPN 또는 다른 유형의 네트워크 액세스 제어 목록(ACL)으로 보호되는 경우에도 공격자가 응용 프로그램을 속여 조작된 요청을 예상치 못한 대상으로 보내는 경우
OWASP 상위 10대 API 보안 위험(2023)
- 손상된 개체 수준 권한 부여 – API 개체(예: 데이터베이스 또는 파일)에 적절한 권한 부여 제어가 없는 경우 무단 사용자 액세스 권한을 부여합니다.
- 손상된 인증 – 소프트웨어 및 보안 엔지니어가 API 인증의 경계와 구현 방법을 오해하는 경우
- 손상된 개체 속성 수준 권한 부여 - 과도한 데이터 노출과 대량 할당의 조합: 공격자가 개체 속성 수준에서 잠금 또는 부적절한 권한을 악용하는 경우입니다.
- 무제한 리소스 소비 – API 요청을 충족하려면 네트워크 대역폭, CPU, 메모리 및 스토리지가 필요합니다. 서비스 제공업체는 API 통합을 통해 이메일/SMS/전화 통화 또는 생체 인식 확인과 같은 기타 리소스를 제공하고 요청별로 비용을 지불합니다. 성공적인 공격은 서비스 거부 또는 운영 비용 증가로 이어질 수 있습니다.
- 손상된 기능 수준 인증에는 공격자가 노출된 API 엔드포인트에 합법적인 API 호출을 보내는 것과 관련됩니다.
- 민감한 비즈니스 흐름에 대한 무제한 액세스 – 이 위험에 취약한 API는 자동화된 방식으로 과도하게 사용될 경우 해당 기능이 비즈니스에 해를 끼칠 수 있는 방식을 보상하지 않고 티켓 구매 또는 댓글 게시와 같은 비즈니스 흐름을 노출합니다. 이것이 반드시 구현 버그로 인해 발생하는 것은 아닙니다.
- 서버 측 요청 위조 – API가 사용자 제공 URI의 유효성을 검사하지 않고 원격 리소스를 가져오는 경우 방화벽이나 VPN으로 보호되는 경우에도 공격자가 애플리케이션이 예상치 못한 대상으로 조작된 요청을 보내도록 강제할 수 있습니다.
- 잘못된 보안 구성 – API와 이를 지원하는 시스템에는 일반적으로 사용자 정의가 용이하도록 복잡한 구성이 포함되어 있습니다. 소프트웨어 및 DevOps 엔지니어는 이러한 구성을 놓치거나 구성과 관련된 보안 모범 사례를 따르지 않아 다양한 유형의 공격에 대한 문을 열 수 있습니다.
- 부적절한 재고 관리 – API는 기존 웹 애플리케이션보다 더 많은 엔드포인트를 노출하므로 적절하고 업데이트된 문서가 중요합니다. 더 이상 사용되지 않는 API 버전 및 노출된 디버그 엔드포인트와 같은 문제를 완화하려면 호스트 및 배포된 API 버전의 적절한 인벤토리도 필수적입니다.
- 안전하지 않은 API 소비 – 개발자는 사용자 입력보다 타사 API에서 받은 데이터를 더 신뢰하고 약한 보안 표준을 채택하는 경향이 있습니다. API를 손상시키기 위해 공격자는 대상 API를 직접 손상시키려고 시도하는 대신 통합된 타사 서비스를 공격합니다.
보시다시피 일부 중복되는 부분이 있기는 하지만 애플리케이션과 API는 주로 서로 다른 고유한 위협에 노출되므로 조직은 이에 따라 대응해야 합니다. 두 목록의 주요 차이점은 조직이 기존의 다목적 보안 도구 및 기술을 사용하여 애플리케이션 보안과 관련된 모든 중요한 위험을 완화할 수 있지만 API 보안은 다르다는 것입니다.
API 보안은 똑같이 현대적인 솔루션이 필요한 매우 현대적인 문제입니다. 조직은 애플리케이션과 기타 자산을 보호하기 위해 사용하는 도구가 API 보안 작업을 충족할 것이라고 기대할 수 없습니다. API 보안에는 API별 보안 도구가 필요합니다. API 게이트웨이 및 WAF(웹 애플리케이션 방화벽)와 같은 기존 보호 방법으로는 충분하지 않습니다.