API 엔드포인트 보호로 API 보안이 어려워짐
API의 (비)보안 과 관련된 통계는 부족하지 않습니다. 인터넷을 잠깐 검색하면 당신이 원하는 주제에 대한 거의 모든 관점을 얻을 수 있습니다. (a) API 공격이 증가하고 있으며 (b) 일부 공격은 성공적이라고만 말할 수 있습니다.
조직이 조직 내에 숨어 있는 모든 API를 찾는 데 어려움을 겪는 것도 일반적인 현상입니다. 이는 해당 API가 코어, 클라우드, 에지에 걸쳐 퍼져 있기 때문만은 아닙니다. 잘 알려진 Open API Specification(OAS) 외에는 API를 정의하거나 찾는 데 의지할 수 있는 실제 "표준"이 없기 때문입니다.
그렇다고 해서 그들이 필요하다는 것은 아닙니다. 결국, 우리는 SOAP, WSDL, UDDI를 가지고 있었고, 사람들은 여전히 그것들을 사용하고 데이터 형식으로 XML에 의존하고 있지만, 대부분의 세계는 REST, JSON, GraphQL, gRPC로 옮겨갔습니다.
표준이 있더라도 API를 보호하기 어렵다는 사실은 바뀌지 않습니다.
API라는 용어는 포괄적인 용어이기 때문입니다. 예를 들어, OpenTelemetry API는 단순히 "우리는 OpenTelemetry의 기능을 개발자에게 제공하고 있습니다"라고 말하는 방식입니다. "the" Open Telemetry API를 포괄할 수 있는 보안 정책이 있는 것은 아닙니다. 그게 이상적이고 모든 것을 훨씬 더 쉽게 만들 것입니다. 하지만 우리가 가진 것은 그게 아니죠. 우리가 갖고 있는 것은 OpenTelemetry API 엔드포인트를 포괄하는 보안 정책입니다.
그것에 대해 좀 더 자세히 알아보도록 할까요?
API 및 엔드포인트
지금은 모두가 생성 AI에 열광하고 있으므로 Open AI API를 예시로 사용해 보겠습니다.
가장 먼저 깨닫게 될 것은 API가 "하나"뿐이지만 엔드포인트는 많다는 것입니다. 몇개요? 이 숫자는 새로운 기능이 도입될 때마다 변경됩니다.
다음은 (포괄적이지 않은) 목록입니다.
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
멀티모달 생성 AI는 콘텐츠 유형 목록에 미디어(오디오 및 비디오)를 추가하지만 처리 요청을 처리하기 위한 새로운 엔드포인트를 추가합니다. 도구 사용과 같은 추가 기능을 사용하면 엔드포인트 수도 늘어날 수 있습니다. 모든 발전, 즉 우리가 기대하는 모든 새로운 기능은 일반적으로 API에 또 다른 엔드포인트를 추가합니다.
해당 엔드포인트에서 "v1"도 확인할 수 있습니다. 즉, v2가 출시되면 이러한 엔드포인트를 포괄하는 또 다른 보안 정책 세트가 필요하며, 이러한 정책 중 일부는 실제 엔드포인트에서 변경된 내용에 따라 변경되어야 합니다.
이러한 현상은 IT 스택에도 적용되며, 장치 API를 통해 자동화가 달성됩니다. 엔드포인트의 수는 주로 환경에 따라 달라집니다. 관리하는 장치가 많을수록 관리하고 보호해야 할 엔드포인트도 많아집니다. 아, 그리고 두 기기가 같은 API를 사용하지 않는다는 걸 잊지 마세요. 미친 짓이겠죠, 그렇죠? 두 클라우드 제공자가 동일한 API를 사용하기로 동의한 것과 거의 같습니다. 이것이 아마도 "복잡성"이 다양한 운영 작업을 자동화 하지 않는 가장 많이 언급된 이유로 남아 있는 이유일 것입니다. 도구와 API가 너무 많으면 자동화하기 어렵고 보안을 강화하는 것도 더 어렵습니다.
하지만 API 보안은 공격자가 침투하는 경로인 모든 엔드포인트를 처리 해야 합니다 . 그리고 각 엔드포인트에는 JSON(또는 XML, GraphQL 또는 <여기에 형식 삽입> 객체) 형태로 페이로드에 저장되는 서로 다른 매개변수 집합이 필요합니다. 각 매개변수에 포함될 수 있는 내용에는 제한이 있어야 합니다. 영숫자인가요? 캐릭터? 다양한 값? 얼마나 오래 걸릴 수 있나요? 어떤 문자가 허용 되지 않나요 ? 이러한 모든 정보는 콘텐츠의 모양을 적용하는 정책으로 변환되어 침입을 방지합니다.
Open AI API에 대한 정책을 구축하는 데는 시간이 좀 걸릴 겁니다. 그리고 그것은 단지 하나의 API일 뿐입니다. 우리의 다가올 2024년 연구에 따르면 대부분 조직은 평균 442.8개의 API를 가지고 있으며, 그 숫자는 매우 큰 조직의 경우 엄청나게 늘어납니다. 이는 얼마나 많은 엔드포인트와 엔드포인트 버전을 의미할 수 있는지 생각해 보면 API 보안이 왜 그렇게 어려운지 아주 빨리 알 수 있습니다.
그리고 공격자들이 그들을 계속해서 표적으로 삼을 만큼 성공적인 이유.