NGINX App Protect로 gRPC API 보호하기

Yaniv Sazman제품 관리 수석 매니저

처음에는 모놀리스가 있었습니다. 모놀리스는 오랫동안 소프트웨어 개발자들에게 유용했으며, 지금도 일부 사용 사례에서는 여전히 유용합니다. 하지만 애플리케이션이 커지면서 모놀리스는 개발하고 보안을 유지하며 관리하기가 어려워졌습니다. 마이크로서비스가 대안으로 등장했습니다. 모놀리스를 단일 비즈니스 기능을 수행하는 작고 독립적인 서비스로 나누고, 이 서비스들이 네트워크를 통해 통신하여 애플리케이션의 전체 기능을 제공하는 방식입니다. 초기 웹 개발자들은 통신 프로토콜로 SOAP을 사용하고 데이터 인코딩에는 XML을 사용했지만, 많은 이들이 이 조합이 번거롭고 느리다고 느꼈습니다. 이에 따라 REST 기반 아키텍처로 전환하고, 프로토콜과 데이터 직렬화 방식으로 각각 HTTP와 JSON을 널리 채택하게 되었습니다.

하지만 기술 분야에서 흔히 그렇듯이, 개발자들은 SOAP 및 REST의 텍스트 기반 방식에 내재된 한계를 극복하는 등 애플리케이션을 설계하는 더 나은 방법을 계속 모색했습니다. 그중 하나가 gRPC로, Google이 방대한 독립형 자율 서비스들을 연결하기 위해 개발했습니다. gRPC는 구조화된 데이터를 직렬화하기 위한 플랫폼 및 언어 중립적 메커니즘으로 프로토콜 버퍼(protobuf)를 사용하고, 통신 프로토콜로 HTTP/2를 사용합니다.

gRPC의 이점

다른 API 프레임워크와 비교했을 때 gRPC의 장점으로는 지연 시간이 짧은 처리 성능, 다중 언어 지원, 간결한 데이터 표현, 실시간 스트리밍 등이 있습니다. 이러한 특성 덕분에 gRPC는 마이크로서비스 간 통신과 저전력·저대역폭 네트워크를 통한 통신에 특히 적합합니다. 최근 몇 년 사이 gRPC의 인기가 크게 높아진 이유는 클라이언트와 서버 모두에서 언어에 구애받지 않으면서도 신뢰성과 확장성이 뛰어난 새로운 서비스를 더 빠르고 효율적으로 구축할 수 있기 때문입니다.

gRPC의 이점을 잘 보여 주는 대표적인 사례는 오픈 뱅킹입니다. 오픈 뱅킹은 오픈 소스 기술을 활용해 API를 구축하고 제공함으로써, 서드 파티 개발자가 은행이나 기타 금융 기관의 고객에게 부가 서비스를 제공할 수 있도록 합니다. 오픈 뱅킹의 근간에는 금융 정보를 더욱 효과적이고 효율적으로 제공한다는 이상이 자리 잡고 있습니다. 프로토콜 버퍼의 간결한 형식과 HTTP/2의 멀티플렉싱을 활용하면 동일한 페이로드를 REST API보다 훨씬 빠르게 전송할 수 있으므로 gRPC는 이러한 목표를 달성하는 데 도움이 됩니다. 데이터 수신 속도는 약 7배, 전송 속도는 약 10배 더 빠릅니다. 이에 따라 금융 기관들은 더 빠르고 효과적이며 안정적이고 확장 가능한 서비스를 제공하기 위해 서비스 간 통신에 gRPC를 도입하고 있습니다.

gRPC의 속도가 큰 이점으로 작용하는 구체적인 사용 사례 중 하나는 고객 온보딩 프로세스입니다. 이는 오픈 뱅킹의 성공에 매우 중요한 요소입니다. 다른 API 프레임워크를 사용할 경우 신규 계좌 개설은 금융 기관과 고객 모두에게 번거롭고 시간이 많이 걸릴 수 있습니다. gRPC를 사용하면 빠른 데이터 전송 덕분에 고객이 몇 분 만에 새 계좌를 개설할 수 있습니다. 이를 통해 고객 만족도를 크게 높이는 동시에 금융 기관의 비용을 대폭 절감할 수 있습니다.

gRPC 보안 강화

gRPC 표준과 프로토콜 버퍼 형식은 오픈 소스 라이브러리로 구현되어 있습니다. 라이브러리 파서가 잘못된 형식의 요청을 거부하고 라이브러리의 동작을 더욱 면밀히 검토하므로, 프로토콜 버퍼는 다른 데이터 표현 방식보다 사이버 공격에 더 안전한 것으로 간주됩니다.

하지만 gRPC를 대상으로 한 공격에 악용될 수 있는 몇 가지 우려스러운 여지는 여전히 남아 있습니다. 예를 들어 파서는 다음과 같은 문제가 있습니다:

• 키워드 없이 메시지 스트림을 전송할 수 있습니다. stream
• 필드가 반복 가능으로 선언되지 않은 경우에도 메시지에 해당 필드가 여러 번 나타날 수 있도록 허용합니다.
• 맵 필드에서 중복된 키를 검사하지 않으며, 해당 키가 마지막으로 나타난 값만 고려합니다.
• 검사하지 않음: oneOf 복합 유형에서 둘 이상의 필드가 존재하는 것을 허용함

공격자는 gRPC 프로토콜의 이러한 허점을 악용하여 애플리케이션을 침해할 수 있습니다. 또한 프로토콜 버퍼에서는 메시지 정의에 포함되지 않은 필드를 생성할 수 있습니다. 이는 설계의 확장성을 보장하여 향후 확장된 메시지 버전과의 호환성을 지원하지만, 애플리케이션에서 명시적으로 허용하도록 코딩되지 않은 필드를 공격자가 요청에 삽입하는 스머글링 공격에 애플리케이션이 취약해질 수도 있습니다.

NGINX App Protect로 gRPC API 보호

NGINX App Protect는 최신 gRPC 기반 애플리케이션을 서비스 애플리케이션에 더 가까운 위치에서 보호하도록 설계되었습니다. 이를 통해 AppDev, DevOps 및 DevSecOps 팀은 애플리케이션 보안을 코드로 관리하고 네이티브 도구를 활용할 수 있습니다.

예를 들어, NGINX App Protect는 금융 기관과 해당 기관의 서비스가 서비스 간 통신에 gRPC를 구현할 때 오픈 뱅킹 표준을 준수하도록 보장합니다. NGINX App Protect의 엔진은 네트워크 요청의 gRPC 메시지를 심층 검사하고, 프로토콜 버퍼 메시지를 구문 분석하며, 모든 중첩 및 복합 데이터 구조를 포함해 메시지 헤더와 페이로드에서 악성 데이터를 탐지합니다. 모든 요청을 검사하고 각 API 호출 매개변수에 공격 탐지 메커니즘을 적용합니다.

gRPC API에서는 gRPC 인터페이스를 사용하여 형식 라이브러리 파일(IDL 파일)과 프로토콜 버퍼용 proto 정의 파일에 보안 정책을 설정합니다. 업데이트된 파일이 로드되면 NGINX App Protect는 구성을 변경할 필요 없이 즉시 새 보안 정책을 적용하기 시작합니다. gRPC proto 파일은 CI/CD 파이프라인의 일부로 자주 업데이트되므로 보안 정책을 업데이트해도 프로세스가 중단되거나 추가적인 오버헤드가 발생하지 않으며, 애플리케이션은 항상 최신 정책으로 보호됩니다.

NGINX App Protect는 gRPC 기반 마이크로서비스 간의 동서 트래픽을 보호할 뿐만 아니라, 외부에 공개된 자산의 남북 트래픽도 보호합니다.

gRPC는 서비스 간 통신의 속도, 효율성 및 확장성을 향상시키지만, API 데이터(URL, 헤더 및 페이로드)와 gRPC API를 노출하는 애플리케이션 서비스를 안전하게 보호하는 것이 매우 중요합니다. 따라서 NGINX App Protect는 최신 애플리케이션 아키텍처에 필수적입니다.

NGINX App Protect와 함께 gRPC를 사용하는 방법에 대해 자세히 알아보려면 라이트보드 동영상을 확인하세요:

NGINX App Protect 무료 체험하기

NGINX App Protect의 gRPC 지원에 대한 자세한 내용은 문서를 참조하세요.

gRPC API에서 NGINX Plus와 NGINX App Protect를 사용해 보려면 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Yaniv Sazman제품 관리 수석 매니저

Yaniv Sazman의 다른 블로그 게시물