📌 Time Index

1:28 왜 API 보안이 이슈인가

8:08 취약한 API 보안에 의한 침해 사고

12:22 API 보안이란 무엇인가?

17:26 왜 기존 보안솔루션으로는 해결이 안될까?

24:41 OWASP API Top10 2023 에 대한 해설

26:21 API 보안의 필수 요소

27:19 API 공격 사례 : BOLA 36:24 API 보안 성숙 모델

41:43 F5 의 API 보안 권고 디자인

48:20 적용 사례 : 글로벌 금융사

1:01:59 API 보안 솔루션 : F5 XC(Distributed Cloud) WAAP

1:11:48 마무리

📌 요약 정리

API 보안이 왜 지금 이렇게 이슈인가?

모던 애플리케이션, 마이크로서비스 등 쿠버네티스 개발과서비스 환경 하에서 모든 작업들은 API로 통신하고 연결됩니다. 퍼블릭 클라우드의 데이터나 서비스를 호출하고 사용하는 것도 모두 API 로 진행되죠. 이런 연결 상에서 엄청난 데이터가 오고가고, 그러니 해커들은 바로 이런 지점을 노릴 수 밖에 없는 거죠.

기존 보안 방식으론 막을 수 없다

API 공격의 많은 경우는 페이로드, 즉 데이터에 악성 코드가 없어요. 그러니 아무리 기존의 보안 방식으론 막을 수가 없는거죠. 다 우회해서 정보를 탈취해가게 됩니다. 그래서 어떤 이들은 API 공격을 비즈니스 로직 어택 (Business Logic Attack) 이라고 부르기도 합니다. 왜냐면 서비스나 비즈니스 모델의 취약점을 공격하기 때문인거죠.

알면서도 막지 못한다

API 보안에 취약한 이유는 또 있습니다. API 라고 하는 기능이 비즈니스하고 아주 밀접하게 연결되어 있다는 겁니다. 보안이나 기타 이유 등으로 API의 진행을 막는 순간 자칫 비즈니스 서비스에 문제가 발생할 수도 있고, 이건 사업적으로 자칫 커다란 문제가 될 수도 있는 거죠. 만약 은행 업무에서 이런 트랜잭션에 문제가 발생했다고 생각해보세요. 금전적인 손실 뿐 아니라, 사업의 존폐에도 영향을 줄 수도 있죠. 그러니 보안 담당자든 개발이든 누가 이 부분을 건드리려고 하겠어요?

API 보안 디자인 권고

엄청난 보안 위협에 손놓고 있을 수는 없죠. API 보안 디자인을 위해선 그래도 2가지 포인트를 구성하는 걸 제안합니다. 하나는 WAAP 레이어로, 행위탐지, API 디스커버리, 그리고 웹방화벽을 포함한 구성이 필요하구요. 또 다른 하나는 내부 API 게이트웨이 이외에 외부 인증시스템과 연결되는 외부 API 게이트웨이 레이어를 두라는 겁니다.

개발팀 그리고 보안팀

API 보안은 개발 그리고 운영 적인 측면 모두 철저히 대비해야 하는 보안 전략이 필요합니다. Shit-left approach로 일컫는 개발 방향에서의 보안 준수 정책과 운영이 하나이고, 또 다른 쪽은 Shift-right approach 로 부르는 런타임 프로텍션입니다. 현실적인 측면에서 우선 순위를 따지자면, 런타임 프로텍션을 먼저 잘 준비해서 API 보안의 측면을 강화하는 것이 더 필요하지 않을까 제안하고 있습니다.