SPA 보안은 팀워크가 핵심입니다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

수년간 제가 관찰해 온 흥미로우면서도 다소 답답한 점 중 하나는 네트워크 엔지니어와 애플리케이션 개발자가 앱을 바라보는 방식이 서로 다르다는 것입니다. 이는 네트워크 다이어그램에서 애플리케이션을 표현하는 방식과, 반대로 애플리케이션 아키텍처 다이어그램에서 네트워크를 표현하는 방식에서 확인할 수 있습니다.

말할 필요도 없이, 양측 모두 상대방을 지나치게 단순하게 바라봅니다.

이는 보안에도 마찬가지로 적용됩니다. 이제 보안은 네트워크와 애플리케이션뿐만 아니라 비즈니스 자체를 보호하는 데 있어 무엇보다 중요한 역할을 담당하게 되었습니다. 보안 팀은 애플리케이션을 제대로 이해하기 위해 일반적인 아키텍처 다이어그램의 틀에서 벗어나야 합니다. 상당수의 (성공한) 공격은 애플리케이션 계층에서 실행됩니다. 다양한 유형의 애플리케이션이 지닌 고유한 특성을 인식하지 못하는 기간이 길어질수록 해당 애플리케이션은 그만큼 더 오래 취약한 상태로 남게 됩니다.

오늘은 SPA에 초점을 맞춰 이야기해 보겠습니다. 이 특정 TLA가 무엇을 뜻하는지 궁금한 분들을 위해 설명하자면, "Single Page Applications(단일 페이지 애플리케이션)"의 약자입니다.

SPA 소개

싱글 페이지 애플리케이션은 말 그대로 애플리케이션과 관련된 모든 작업의 프레임워크 역할을 하는 하나의 웹 페이지입니다. 이 아키텍처는 웹 2.0 시대와 전체 페이지를 다시 로드하는 대신 개별 DOM(문서 객체 모델) 요소를 '새로 고침'하는 방식으로 AJAX가 등장했던 시기로 거슬러 올라갑니다. 이 기법을 통해 성능이 크게 향상되었으며, 이는 현대적인 싱글 페이지 애플리케이션의 전신이 되었습니다.

이러한 앱은 모바일 앱의 동작 방식과 더 유사합니다. 처음 열 때 클라이언트 UI가 로드되고, 서버와는 데이터만 주고받습니다. 즉, 서버를 호출할 때마다 데이터만 전송되며 UI 변경은 모두 클라이언트에서 이루어집니다. 따라서 주고받는 데이터의 양이 크게 줄어들어 성능이 향상됩니다. 이러한 종류의 앱은 API를 사용해 데이터를 교환합니다.

일반적으로 지금까지는 이러한 API 대부분이 REST 원칙에 따라 구현된다고 가정해 왔습니다. 즉, 각 객체(일반적으로 단일 UI 요소와 연결된 것으로 간주됨)에는 CRUD(생성, 읽기, 업데이트, 삭제) 작업을 실행하기 위해 호출할 수 있는 자체 API가 있습니다. 보안 관점에서는 특정 API(URI) 호출에 대해 정해진 형식의 데이터가 들어올 것으로 예상할 수 있으므로 보안 적용이 다소 수월해집니다. "/update/product/123"으로 전송되는 데이터는 항상 동일한 직렬화 객체인 반면, "/delete/order/4433"으로 전송되는 데이터는 다른 직렬화 객체입니다. 따라서 특정 정책을 특정 URI에 연결하는 기존 방식을 사용하여 해당 API를 보호할 수 있습니다.

단일 URI 패턴

이제 SPA는 이 패턴을 따를 수도 있고 따르지 않을 수도 있습니다. 새롭게 등장하는 SPA 관련 방식에서는 동일한 API를 사용해 트랜잭션을 처리할 수도 있고, 보다 전통적인 함수-URI 매핑 방식을 사용할 수도 있습니다. 단일 URI 패턴을 사용하는 SPA에서는 URI는 변경되지 않지만, 서버와 주고받는 직렬화된 객체는 변경됩니다.

이는 하나의 엔드포인트(URI)를 사용해 여러 함수를 호출하던 SOA/XML 트랜잭션을 연상시킵니다. 호출 대상 함수(엔드포인트)는 직렬화된 XML 데이터에 포함되거나 사용자 지정 HTTP 헤더에 삽입되기도 했습니다. 이 모델로 인해 요청을 수신하고 어떤 함수가 호출되었는지 확인한 후 올바른 엔드포인트(서버)로 라우팅하는 SOA/XML 게이트웨이가 필요해졌습니다.

SPA에서는 여러 API 호출을 처리할 수도 있고 몇 개만 처리할 수도 있습니다. 어느 경우든 특정 형식(아마도 XML이겠지만 JSON일 가능성이 더 높음)의 데이터를 보호해야 할 가능성이 큽니다. 즉, 콘텐츠 자체에 위험이 내재되어 있음을 인식해야 합니다. 일부 데이터는 UI 요소를 동적으로 생성하거나 클라이언트 측에서 DOM을 조작하는 데 사용될 수 있으므로, 제출될 때마다 잠재적인 악성 코드를 찾아 제거하는 것이 중요합니다.

보안 인식의 단절

안타깝게도 하나의 URI를 사용해 다양한 기능의 데이터를 교환하면 URI에 정책을 연결하는 기존 방식은 제대로 작동하지 않습니다. 실제로 이러한 정책은 특정 페이로드 형식을 예상하도록 학습되는 경우가 많기 때문에 보안이 무너질 수 있습니다. API 게이트웨이 역시 정책(라우팅, 사용량 측정, 액세스)을 특정 URI에 연결하는 경우가 많습니다. 즉, 소수의 URI(API 호출)만으로 서로 다른 데이터 형식을 사용하는 훨씬 더 많은 기능을 처리하는 방식은 기존 보안 체계를 무너뜨릴 수 있습니다.

이는 보안 담당자와 개발자(dev, DevOps가 아닌 개발자)가 코드의 첫 줄부터 배포에 이르기까지 더욱 긴밀하게 협력하는 것이 갈수록 중요해지는 이유를 보여주는 사례입니다. 개발자는 초기 단계에서 적절한 보호 조치를 더 쉽게 적용할 수 있도록 보안 담당자를 지원할 수 있습니다. 예를 들어, 올바른 정책을 실행할 수 있게 해주는 식별자를 HTTP 헤더에 삽입할 수 있습니다. "X-Code: 'order'"처럼 간단한 정보만 추가해도 보안 솔루션이 요청에 포함된 데이터를 식별하고 잠재적인 익스플로잇이 있는지 검사할 수 있습니다.

아키텍처 측면에서는 코드를 추출하고 URI를 재작성한 후 요청을 적절한 보안 솔루션(WAF, API Gateway 등)으로 라우팅할 수 있는 지능형 L7 프록시가 필요할 수 있습니다. 지능형 L7 프록시가 JSON과 같은 데이터 형식 언어를 이해할 수 있고, 개발자가 모든 데이터 교환에 적절한 위치로 재작성하고 라우팅하는 데 사용할 수 있는 코드나 엔드포인트 이름을 포함하는 경우에도 이 접근 방식이 효과적입니다.

가장 이상적인 방법은 애플리케이션 계층 보안을 앱 자체에 통합하여 성능과 보안 간의 최적의 균형을 이루는 것입니다. 하지만 이것이 항상 가능한 것은 아니며, 보안 목표를 달성하기 위해 때로는 창의적인 아키텍처 솔루션이 필요합니다.

보안은 팀 스포츠입니다

일반적으로 개발자가 클라이언트와 서버 간에 다양한 책임을 분담하는 방식이 바뀌면, 애플리케이션 서비스 인프라가 이후의 요청 및 응답과 상호 작용하는 방식에도 상당한 영향을 미칩니다. 보안 팀, 개발자 팀, 애플리케이션 서비스 인프라 팀이 전체 소프트웨어 개발 수명 주기(SDLC)에 참여하는 것이 중요합니다. 아키텍처 솔루션을 구현하는 데에도 시간이 걸립니다. 이를 "마지막까지" 미뤄 두면 출시까지 며칠, 몇 주, 심지어 몇 달이 더 걸릴 수 있습니다. 그렇지 않으면 보안 서비스 없이 제품을 출시하게 되며, 이 경우에도 그에 따른 위험과 결과를 감수해야 합니다.

개발 첫날부터 협업하는 것이 앱을 프로덕션 환경에 배포할 때 가용성과 속도, 보안을 보장하는 가장 효과적이고 빠른 방법입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물