API의 (비)보안에 관한 통계는 차고 넘칩니다. 인터넷을 대충 검색해 보기만 해도 이 주제에 관해 원하는 관점의 자료를 거의 모두 찾을 수 있습니다. 요약하자면, (a) API 공격이 증가하고 있으며 (b) 그중 일부는 성공하고 있습니다.
또한 조직 내부 곳곳에 숨어 있는 모든 API를 단순히 찾아내는 것조차 쉽지 않다는 지적도 흔히 나옵니다. 이는 API가 코어, 클라우드, 엣지 전반에 분산되어 있기 때문만은 아닙니다. 널리 알려진 Open API Specification(OAS)을 제외하면 API를 찾는 것은 고사하고 정의하는 데 의존할 만한 실질적인 ‘표준’이 없기 때문입니다.
그렇다고 해서 그런 표준이 꼭 필요한 것은 아닙니다. 과거에는 SOAP, WSDL, UDDI가 있었고, 지금도 이를 사용하며 XML을 데이터 형식으로 활용하는 사람들이 있지만, 대부분은 REST, JSON, GraphQL, gRPC로 옮겨갔습니다.
표준이 있다고 해도 API의 보안을 확보하기 어렵다는 사실은 달라지지 않습니다.
그 이유는 API라는 용어가 포괄적인 개념이기 때문입니다. 예를 들어 OpenTelemetry API는 단순히 “OpenTelemetry의 기능을 개발자가 사용할 수 있도록 제공한다”는 의미입니다. ‘OpenTelemetry 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가 출시되면 해당 엔드포인트를 포괄하는 별도의 보안 정책 세트가 필요하며, 실제 엔드포인트에서 변경된 사항에 따라 일부 정책도 변경해야 한다는 의미입니다.
이는 디바이스 API를 통해 자동화가 이루어지는 IT 스택에서도 마찬가지입니다. 엔드포인트 수는 환경에 따라 크게 달라집니다. 관리하는 디바이스가 많을수록 관리하고 보호해야 할 엔드포인트도 늘어납니다. 아, 그리고 서로 다른 두 디바이스가 동일한 API를 사용하는 일은 없다는 점도 잊지 말아야 합니다. 말도 안 되는 일이겠죠? 마치 두 클라우드 제공업체가 동일한 API를 사용하기로 합의하는 것처럼요. 아마도 이 때문에 다양한 운영 작업을 자동화하지 않는 이유로 여전히 ‘복잡성’이 가장 많이 언급되는 것일 겁니다. 도구와 API가 너무 많으면 자동화하기도 어렵고 보안을 유지하기는 더욱 어렵습니다.
하지만 API 보안은 반드시 공격자가 이러한 엔드포인트를 통해 침입하기 때문에 이 모든 엔드포인트를 보호해야 합니다. 또한 각 엔드포인트에는 서로 다른 매개변수 집합이 필요하며, 이 매개변수들은 JSON(또는 XML, GraphQL, <여기에 형식 삽입> 객체) 형식으로 페이로드에 포함됩니다. 각 매개변수에 포함할 수 있는 내용에는 제한이 필요합니다. 영숫자입니까? 문자입니까? 값의 범위입니까? 길이는 얼마나 될 수 있습니까? 어떤 문자가 허용되지 않습니까? 이 모든 정보는 콘텐츠의 형식을 규정하는 정책으로 변환되며, 이를 통해 공격이 몰래 침투하는 것을 방지합니다.
Open AI API 하나만을 위한 정책을 수립하는 데도 어느 정도 시간이 걸립니다. 그런데 이는 단 하나의 API에 불과합니다. 곧 발표될 2024년 연구에 따르면 대부분의 조직은 평균 442.8개의 API를 보유하고 있으며, 초대형 조직의 경우 그 수가 급격히 늘어납니다. 이로 인해 얼마나 많은 엔드포인트와 엔드포인트 버전이 존재할 수 있는지 생각해 보면, API 보안이 왜 그토록 어려운지 금세 알 수 있습니다.
그리고 공격자들이 계속해서 이를 노릴 만큼 충분히 성공을 거두는 이유이기도 합니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
AI 시대의 새로운 애플리케이션 제공 원칙으로 복잡성 극복하기
보안, 일관성, 완전 자동화에 중점을 둔 애플리케이션 제공의 새로운 6가지 원칙을 도입하여 복잡성 없이 하이브리드 멀티클라우드의 유연성을 누리세요.
디지털 혁신을 가속화하는 6가지 기술 역량
오늘날의 엔터프라이즈 아키텍처에는 기술 변화를 주도하는 데 핵심적인 민첩성, 확장성, 보안 및 관찰 가능성이 부족하지만, 이 여섯 가지 핵심 역량은 기업이 디지털 혁신 전반에 걸쳐 위험과 과제를 관리하는 데 도움이 될 것입니다.
하이브리드 근무가 ID 중심 보안으로의 전환을 이끌고 있습니다
자동화와 디지털화의 폭발적인 성장에 하이브리드 근무 모델로의 전환 추세가 더해지면서, IP 기반 보안에서 벗어나 ID 기반 액세스 전략으로 전환하는 움직임이 더욱 가속화될 것입니다.
관점의 현대화: 애플리케이션에서 경험으로
그리스와 로마의 신들처럼, 여러 신화에서도 동일한 존재가 다양한 모습으로 나타나는 것을 볼 수 있습니다. 본질적으로 각각의 화신은 기존 존재가 새로운 얼굴로 드러난 것입니다. 디지털 세계에서도 이와 비슷한 양상이 나타납니다. 우리가 ‘애플리케이션’이라고 부르는 것들은 흔히 기존 기능이 새로운 형태로 구현된 것이라 볼 수 있습니다.
코로나19 이후 기업 결제의 디지털 전환
디지털 결제는 과거의 현금만큼이나 보편화되었습니다. 코로나19 팬데믹으로 인한 봉쇄 조치는 소비자의 디지털 결제 서비스 의존도를 더욱 빠르게 높였습니다. 기업의 디지털 결제 도입 역시 가속화되었습니다. 대중을 상대로 영업하든 하지 않든 기업에는 여전히 지급해야 할 대금과 받아야 할 대금이 있기 때문입니다.
공급망 해킹과 보안에서 하드웨어의 역할
수석 아키텍트 Dave Schmitt와 CTO 오피스가 최근 Bloomberg의 Super Micro 관련 기사를 계기로 하드웨어 보안 전문성의 중요성을 되짚어봅니다. 또한 이 글에서는 시스템이 안전하게 보호되고 있는지 확인하기 위해 공급업체에 물어봐야 할 질문도 소개합니다.