gRPC API 보안 NGINX App Protect로 유지
NGINX App Protect 를 사용하시고 메시지 헤더 및 페이로드, 중첩 및 복잡한 데이터 구조에서 악성 데이터를 감지하고 gRPC API를 보호해보세요.
처음에는 모놀리스가 있었습니다. 모놀리스는 오랫동안 소프트웨어 개발자에게 유용했으며, 지금도 일부 사용 사례에서는 유용합니다. 하지만 애플리케이션이 증가함에 따라 모놀리스는 개발, 보안 및 유지 관리가 어려워졌습니다. 이에 대한 대안으로 등장한 것이 마이크로서비스, 모놀리스는 단일 비즈니스 기능을 수행하고 네트워크를 통해 통신하여 애플리케이션의 전체 기능을 제공하는 소규모의 자율적인 서비스로 나뉩니다. 처음에는 웹 개발자들이 통신 프로토콜로 SOAP를 사용하고 데이터를 인코딩하는 데 XML을 사용했지만, 많은 사람들이 이 조합을 번거롭고 느리다고 느꼈습니다. 그 결과 REST 기반 아키텍처로 전환하고 프로토콜과 데이터 직렬화 방법으로 각각 HTTP와 JSON을 광범위하게 채택하게 되었습니다.
그러나 모든 기술이 그렇듯이 개발자들은 SOAP 및 REST의 텍스트 기반 지향에 내재된 한계를 극복하기 위해 애플리케이션을 설계하는 더 나은 방법을 계속 모색했습니다. 이러한 시스템 중 하나가 구글이 방대한 독립적인 자율 서비스를 연결하기 위해 개발한 gRPC입니다. gRPC는 구조화된 데이터를 직렬화하기 위한 플랫폼 및 언어 중립적인 매커니즘으로 프로토콜 버퍼(protobufs)를 사용하고 통신 프로토콜로 HTTP/2를 사용합니다.
목차
1. gRPC의 이점
2. gRPC 보안
3. NGINX App Protect 로 gRPC API 보호하기
4. NGINX App Protect 를 무료로 사용해보세요.
1. gRPC의 이점
다른 API 프레임워크에 비해 지연 시간이 짧은 처리량, 여러 언어 지원, 간결한 데이터 표현, 실시간 스트리밍 등 gRPC의 장점은 마이크로서비스 간의 통신과 저전력, 대역폭 네트워크에 특히 적합하다는 점입니다. 최근 몇 년 동안 gRPC의 인기가 크게 높아진 이유는 새로운 서비스를 더 빠르고 효율적으로 구축할 수 있고, 안정성과 확장성이 높으며, 클라이언트와 서버 모두에 대해 언어 독립성을 유지할 수 있기 때문입니다.
오픈 소스 기술을 사용하여 API를 구축하고 제공하는 오픈 뱅킹은 third-party 개발자가 은행이나 기타 금융 기관의 고객에게 추가 서비스를 제공할 수 있도록 지원하는 대표적인 예입니다. 오픈 뱅킹의 전체 기반은 금융 정보를 보다 효과적이고 효율적으로 배포한다는 이상에 기반을 두고 있습니다. gRPC는 HTTP/2의 컴팩트한 형식의 프로토콜 버퍼와 멀티플렉싱을 통해 데이터를 수신할 때 약 7배, 데이터를 전송할 때 약 10배 더 빠르게 주어진 페이로드를 전송하기 때문에 이러한 목표를 달성하는 데 도움이됩니다. 그 결과, 금융 기관은 서비스 간 통신에 gRPC를 채택하여 더 빠르고 더 큰 효율성, 안정성, 확장성을 갖춘 서비스를 제공하고 있습니다.
gRPC의 속도가 큰 장점으로 작용하는 구체적인 사용 사례 중 하나는 오픈 뱅킹에서 성공에 가장 중요한 고객은 온보딩 프로세스입니다. 다른 API 프레임워크를 사용하면 금융 기관과 고객 모두 새 계정을 만드는 데 번거롭고 많은 시간이 소요될 수 있습니다. gRPC를 사용하면 데이터 전송 속도가 빨라 고객이 몇 분 안에 새 계좌를 만들 수 있습니다. 이는 고객 만족도를 크게 높이는 동시에 금융 기관의 비용을 크게 절감합니다.
2. gRPC 보안
gRPC 표준과 프로토콜 버퍼 형식은 오픈 소스 라이브러리로 구현되어 있습니다. 프로토콜 버퍼는 라이브러리 parser가 잘못된 요청을 거부하고 라이브러리 동작 방식을 더 주의 깊게 살펴보기 때문에 다른 데이터 표현보다 사이버 공격에 대해 더 안전한 것으로 간주됩니다.
하지만 gRPC를 공격할 수 있는 몇 가지 당황스러운 기회는 여전히 남아 있습니다. 예를 들어 parser는 다음과 같습니다:
- stream 키워드 없이 stream 메시지를 전송할 수 있도록 허용합니다.
- field가 반복 가능으로 선언되지 않은 경우에도 메시지에서 field의 여러 발생을 허용합니다.
- map 필드에서 반복되는 key를 확인하지 않으며, key의 마지막 발생만 고려합니다.
- 복합 유형 중 하나를 확인하지 않고 둘 이상의 필드가 존재할 수 있도록 허용합니다.
공격자는 이러한 gRPC 프로토콜의 취약점을 악용하여 애플리케이션을 손상시킬 수 있습니다. 프로토콜 버퍼를 사용하면 메시지 정의에 정의되지 않은 field도 생성할 수 있습니다. 이는 향후 확장된 버전의 메시지와 호환되는 설계 확장성을 보장하지만, 공격자가 애플리케이션에서 허용된 대로 명시적으로 코딩되지 않은 필드를 요청에 통합하는 스머핑 공격에 애플리케이션이 취약해질 수도 있습니다.
3. NGINX App Protect 로 gRPC API 보호하기
NGINX App Protect 는 서비스 애플리케이션에 더 가까운 최신 gRPC 기반 애플리케이션을 보호하도록 설계되었습니다. 이를 통해 앱 개발, 운영 개발, 개발 보안팀은 애플리케이션 보안을 코드로 관리하고 기본 도구를 활용할 수 있습니다.
예를 들어, 금융 기관과 금융 기관의 서비스가 서비스 간 통신을 위해 gRPC를 구현할 때 NGINX App Protect 는 오픈 뱅킹 표준을 준수하도록 보장합니다. NGINX App Protect 의 엔진은 유선 요청에 대한 gRPC 메시지를 심층 검사하고 프로토콜 버퍼 메시지를 구문 분석하며, 중첩되고 복잡한 모든 데이터 구조를 포함하여 미시지 헤더와 페이로드에서 악성 데이터를 탐지합니다. 검사는 모든 요청에 대해 수행되며 각 API 호출 매개변수에 대해 공격 탐지 메커니즘을 적용합니다.
gRPC API를 사용하면 gRPC 인터페이스를 사용하여 유형 라이브러리 파일(IDL 파일)과 프로토콜 버퍼에 대한 프로토 정의 파일에서 보안 정책을 설정할 수 있습니다. 업데이트된 파일이 로드되면 설정을 변경할 필요 없이 NGINX App Protect 가 즉시 새 보안 정책을 적용하기 시작합니다. gRPC 프로토 파일은 CI/CD 파이프라인의 일부로 자주 업데이트되므로 보안 정책을 업데이트해도 프로세스가 중단되거나 오버헤드가 추가되지 않으며 애플리케이션은 항상 가장 최신의 최신 정책으로 보호됩니다.
NGINX App Protect 는 gRPC 기반 마이크로서비스 간의 동서 트래픽을 보호할 뿐만 아니라 공개적으로 노출된 자산 간의 남북 트래픽도 보호합니다.
gRPC는 서비스 간 통신의 속도, 효율성, 규모를 향상시키지만, API 데이터(URLs, headers, payloads)와 gRPC API를 노출하는 애플리케이션 서비스를 보호하고 보안을 유지하는 것이 중요합니다. 이것이 바로 최신 애플리케이션 아키텍처에 NGINX App Protect가 필수적인 이유입니다.
4. NGINX App Protect 를 무료로 사용해보세요.
NGINX App Protect 의 gRPC 지원에 대한 자세한 내용은 가이드를 참조하세요.
gRPC API로 NGINX Plus 및 NGINX App Protect 를 사용해 보려면 30일 무료 평가판을 시작하거나 NGINX STORE에 문의하여 사용 사례에 대해 논의하세요.
NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.
