NGINX App Protect로 gRPC API 보안

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

하지만 기술의 경우와 마찬가지로 개발자들은 SOAP 및 REST의 텍스트 기반 방향에 내재된 한계를 극복하는 것과 같이 애플리케이션을 디자인하는 더 나은 방법을 계속 찾았습니다. 그러한 시스템 중 하나가 gRPC 입니다. Google은 이를 통해 다양한 독립적이고 자율적인 서비스를 연결하기 위해 개발했습니다. gRPC는 구조화된 데이터를 직렬화하기 위한 플랫폼 및 언어에 중립적인 메커니즘으로 프로토콜 버퍼 (protobufs)를 사용하고 통신 프로토콜로 HTTP/2를 사용합니다.

gRPC의 이점

gRPC가 다른 API 프레임워크에 비해 유리한 점으로는 저지연 처리량, 여러 언어 지원, 컴팩트한 데이터 표현, 실시간 스트리밍 등이 있습니다. 이 모든 것이 gRPC를 마이크로서비스 간 통신과 저전력, 저대역폭 네트워크 통신에 특히 적합하게 만듭니다. gRPC는 최근 몇 년 동안 인기가 크게 증가했습니다. 이는 더 높은 신뢰성과 확장성을 갖추고 클라이언트와 서버 모두에 언어에 대한 독립성을 제공함으로써 새로운 서비스를 보다 빠르고 효율적으로 구축할 수 있게 해주기 때문입니다.

gRPC의 이점을 잘 보여주는 대표적인 예는 오픈 뱅킹 입니다. 오픈 뱅킹은 오픈 소스 기술을 사용하여 API를 구축하고 제공하여 타사 개발자가 은행이나 기타 금융 기관의 고객에게 추가 서비스를 제공할 수 있도록 합니다. 오픈 뱅킹의 전체적 기반은 금융 정보를 보다 효과적이고 효율적으로 전달한다는 이상을 바탕으로 구축되었습니다. gRPC는 프로토콜 버퍼의 컴팩트한 포맷과 HTTP/2의 멀티플렉싱 덕분에 REST API보다 주어진 페이로드의 전송 속도가 훨씬 빨라져 이 목표를 달성하는 데 도움이 됩니다. 데이터를 수신할 때는 약 7배, 데이터를 전송할 때는 약 10배 더 빠릅니다. 그 결과, 금융 기관은 보다 빠른 속도, 더욱 높은 효율성, 안정성, 규모로 서비스를 제공하기 위해 서비스 간 통신에 gRPC를 도입하고 있습니다.

gRPC의 속도가 큰 이점이 되는 구체적인 사용 사례 중 하나는 고객 온보딩 프로세스입니다. 이는 오픈 뱅킹에서 성공에 가장 중요합니다. 다른 API 프레임워크를 사용하면 금융 기관과 고객 모두 새로운 계좌를 만드는 것이 번거롭고 시간이 많이 걸릴 수 있습니다. gRPC를 사용하면 빠른 데이터 전송이 가능하므로 고객은 몇 분 안에 새 계정을 만들 수 있습니다. 이를 통해 고객 만족도가 크게 향상되고 금융 기관의 비용이 상당히 감소합니다.

gRPC 보안

gRPC 표준과 프로토콜 버퍼 형식은 오픈 소스 라이브러리로 구현됩니다. 라이브러리 파서가 잘못된 요청을 거부하고 라이브러리의 동작 방식을 더욱 주의 깊게 살펴보기 때문에 프로토콜 버퍼는 다른 데이터 표현보다 사이버 공격에 대해 더 안전한 것으로 간주됩니다.

하지만 gRPC에 대한 공격에는 여전히 몇 가지 불안한 가능성이 있습니다. 예를 들어, 파서:

• 키워드 스트림 없이 메시지 스트림을 보낼 수 있습니다.
• 필드가 반복 가능한 것으로 선언되지 않았더라도 메시지에서 필드의 여러 번 발생을 허용합니다.
• 맵 필드에서 반복되는 키를 확인하지 않습니다. 키의 마지막 발생만 고려됩니다.
• 하나의 복합 유형을 확인하지 않으며 두 개 이상의 필드가 존재할 수 있습니다.

공격자는 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 프로토 파일은 CI/CD 파이프라인의 일부로 자주 업데이트되므로 보안 정책을 업데이트해도 프로세스가 중단되거나 오버헤드가 추가되지 않으며 애플리케이션은 항상 최신 정책으로 보호됩니다.

NGINX App Protect는 gRPC 기반 마이크로서비스 간의 동서 트래픽을 보호하는 것뿐만 아니라 공개적으로 노출된 자산 간의 남북 트래픽도 보호합니다.

gRPC는 서비스 간 통신의 속도, 효율성, 규모를 향상시키지만, gRPC API를 노출하는 API 데이터(URL, 헤더, 페이로드)와 애플리케이션 서비스를 보호하고 보안하는 것이 중요합니다. 그렇기 때문에 NGINX App Protect는 최신 애플리케이션 아키텍처에 필수적입니다.

NGINX App Protect를 사용한 gRPC에 대한 자세한 내용은 라이트보드 비디오를 확인하세요.

NGINX App Protect를 무료로 사용해 보세요

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

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