통합 앱 및 API 보안 전략 사례
앱과 API 보안이 더욱 전문화되었다는 것은 분명합니다. API는 더 이상 애플리케이션에 대한 단순한 URI 기반 진입점이 아닙니다. API는 성장하여 자체적인 보안 요구 사항을 가진 독립된 개체가 되었습니다.
이러한 보안 요구 사항의 대부분은 API 상호 작용의 특성과 관련이 있습니다. 따라서 API는 트랜잭션 단위로 권한을 부여해야 하며, 이는 일반적으로 세션 단위로 권한을 부여하는 앱과 확연히 다른 점입니다.
API의 경우 상호 작용 비율 역시 더 높으며, API 보안에 특별한 문제를 야기하는 다른 여러 특성도 있습니다.
| 앱 | API | |
|---|---|---|
| 메시지 형식의 유연성 | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, 바이너리, XML, 데이터 형식 |
| 상호 작용 | 정적이고 빈번하지 않은 변경 | 동적이고 빈번한 변경 |
| 데이터 | 구조화된 트랜잭션 | 구조화되지 않은/구조화된 스트리밍 및 트랜잭션 |
| 사용자 | 인간 | 소프트웨어, 인간 |
| 사용자 에이전트 | 브라우저, 앱 | 소프트웨어, 디바이스, 스크립트, 앱, 브라우저 |
| 인증 | 세션 기반 | 트랜잭션 기반(보다 ZT와 유사) |
| 프로토콜 유연성 | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
앱과 API를 비교하면 보안 요구 사항의 차이점을 알 수 있습니다.
하지만 보안 솔루션을 구현할 때 고려해야 할 앱과 API 모두에 공통적인 보안 위험이 있습니다. 예를 들어, 최근 업데이트된 2023 API Security Top 10에 애플리케이션과 공유되는 위험의 하위 집합이 명확하게 나와 있습니다.
- 취약한 인증 / 권한 제어
- 구성 오류
- 비즈니스 논리 악용(크리덴셜 스터핑, 계정 탈취)
- Server-Side Request Forgery(SSRF)
이러한 위험 외에도 가용성을 표적으로 하는 상당수의 공격이 계속되고 있습니다. 일반적으로 앱과 API가 TCP와 HTTP에서 동일한 종속성을 공유하기 때문에 DDoS 공격은 앱과 API 모두에 공통적으로 발생하며, 둘 모두 액세스 및 가용성을 방해하기 위해 설계된 다양한 공격의 대상이 됩니다.
앱과 API 및 이를 지원하는 인프라의 보안 문제를 해결하기 위한 한 가지 접근 방식은 봇 및 사기 방어, DDoS Protection, 앱 보안, API 보안 등의 여러 솔루션을 배포하는 것입니다. 이렇게 하면 보안 문제를 확실히 해결할 수 있지만 운영상의 문제가 발생하고 정책 변경 관리, 앱과 API 모두에 영향을 미치는 위협에 대한 대응 등 많은 보안 관련 작업이 더욱 복잡해집니다. 복잡성은 보안의 적일 뿐만 아니라 속도의 적이기도 합니다.
F5 연례 조사에 따르면 새로운 위협에 대응할 수 있는 속도가 서비스형 보안을 도입하는 가장 큰 이유입니다. 새로운 위협을 완화하기 위해 패치, 업데이트, 새로운 정책 배포가 필요한 각 솔루션은 소요되는 시간이 더 길어지고 잘못된 구성이나 실수가 발생할 가능성이 높아집니다. 따라서 특히 조직이 여러 환경(하이브리드 IT)에서 운영되고 환경별 보안 솔루션을 활용하는 경우 위협을 완화하는 시간이 복잡성과 함께 증가합니다. 솔직히 임박한 위협에 대응하는 시간이 길어지는 것은 좋은 일이 아니므로 선형으로 증가하는지 또는 기하급수적으로 증가하는지 계산을 해보진 않았습니다.
따라서 솔루션을 결합하여 위협에 대응하도록 설계된 기능에 대한 운영 및 보안 관리를 공유하는 동시에 앱과 API에 고유한 프로토콜과 페이로드를 처리할 수 있는 특정 보안 정책을 허용하는 것이 더 나은 접근 방식입니다.
이는 통합 애플리케이션 및 API 보안 전략으로 이어지며, 공통 기능이 공유되고 앱 또는 API에 근접하여 적용되는 세분성 및 구체성이 증가합니다. 봇은 결국 봇이며 데이터 품질, 딜리버리 비용, 앱 및 API의 위험 프로필에 미치는 영향은 공통의 문제입니다. DDoS는 DDoS입니다. 동일한 문제를 해결하기 위해 두 배의 서비스를 운영하는 것은 모든 지표에서 비효율적입니다.
통합 애플리케이션 및 API 보안 전략이 운영, 재무, 아키텍처 측면에서 합리적입니다.