コンプライアンス
安全を保つためのgRPC実装の注意点を解説
セキュアなRPC APIはアプリケーションセキュリティにおいて極めて重要な役割を果たします。本ブログ記事では、開発者がgRPCに移行し、プロジェクト内でgRPCを実装する際に懸念されるセキュリティの穴について解説します。また、脅威からgRPC実装を保護してリスク軽減するための推奨事項についてもご紹介します。
企業は未来を見据えたアプリケーション構築のため、マイクロサービスアーキテクチャに注目しています。マイクロサービスは企業のインフラストラクチャ管理を効率化し、アップデート・改善点を容易に展開できるようにするほか、ITチームを革新し、失敗から早く見識が得られるよう支援します。さらに企業はマイクロサービスを利用することで、要求に応じて拡張性の高いアプリケーションを簡単に作成できるようになります。これらの利点がある一方で、企業が、1つのモジュールで構成される従来のモノリシック型アプリケーションからコンテナ化によって分割構成されるマイクロサービスアーキテクチャに移行した場合、マイクロサービス間の効率的かつ堅牢な通信を確立する必要性が生じます。クライアントアプリケーションとサーバアプリケーション間で行われる重要かつ複雑な通信は、gRPCによって処理することができます。gRPCは、接続されたシステム間での通信を簡単に透過化・効率化するユニバーサルリモートプロシージャコール（RPC）フレームワークです。gRPCは2015年にGoogleが開発した比較的新しいRPCフレームワークですが、人気と需要が急速に高まっています。
セキュアなRPC APIはアプリケーションセキュリティにおいて極めて重要な役割を果たします。本ブログ記事では、開発者がgRPCに移行し、プロジェクト内でgRPCを実装する際に懸念されるセキュリティの穴について解説します。また、脅威からgRPC実装を保護してリスク軽減するための推奨事項についてもご紹介します。
■gRPCとは
現在では、サーバとクライアントの双方が複数のプログラミング言語をサポートしているため、正確性、効率性、言語非依存性を満たす新しいプロトコルの必要性が増しており、gRPCはその新しいプロトコルの設計に使用されています。これはクラウドネイティブ技術を推進する非営利団体「Cloud Native Computing Foundation（CNCF）」のプロジェクトであり、人気のビデオストリーミングサイト「Netflix」、金融サービス会社「Square」、プラットフォーム提供（PaaS）ベンダ「Docker」などの主要企業に採用されています。
gRPCは、SOAPやRESTなど他のRPCフレームワークと比較されます。RESTful APIは広く利用されており、通常はHTTPを使用してアプリやサービス、JavaScript Object Notation（JSON）のデータ形式の間でデータ交換が行われますが、パフォーマンス指向またはオブジェクト指向テキストベースにおいては制限があります。
多くの組織はAPIをRESTからgRPCに移行して、サービス間通信に最適なgRPCのバイナリプロトコルを利用しています。gRPCはデフォルトで、バイナリベースのプロトコルであるHTTP/2を下位レイヤーとして使用します。HTTP/2は、前身であるHTTP/1.0とは異なり、1つのTCP接続内で複数のストリームと要求をサポートします。HTTP/1.0は、「1つの要求に対して1つの応答を返す」という基本構造を持つよう設計されました。HTTP/1.1ではHTTPパイプラインの仕組みを利用することでHTTP/1.0の問題に対処し、クライアントは一度に複数の要求を送ることが可能となりました。後身のHTTP/2.0では「ストリーム」という仕組みが導入され、1つのコネクション内で複数の要求と応答を並行処理により双方向通信が可能となりパフォーマンスが向上、より多くのWebブラウザやWebサーバでサポートされています。
>図1：要求と応答において「HTTP/1.0」と「HTTP/2」で異なる点を簡略的に視覚化した図
gRPCは、構造化データをシリアル化するためにGoogleのプラットフォームと言語に依存しないメカニズムであるProtocol Buffers（protobuf）の上にビルドされています。シリアル化は、インメモリオブジェクトをバイトストリームに変換するプロセスです。オブジェクトをシリアル化したバイトストリームは、簡単にファイル内に保存したり、ネットワークを介して他のアプリケーションに送信したりできます。開発者はデータインターフェイスを一度記述してから、選択した言語のProtocol Buffersのコンパイラを使用してソースコードをコンパイルします。gRPCを利用する場合、Protocol BuffersはRPCインターフェイスを定義するためにも利用されます。
図2：APIを介して商品と支払いサービスが相互作用するオンライン小売アプリケーション内で動作するgRPCフレームワークを示す図
図3：string messageを送信するためのgRPCのサンプルコード「HelloWorld」
画像引用元：gRPC Quick Start
■脆弱性を生まないための着目点
gRPCは複数のプログラミング言語をサポートしています。サポートされている言語のうち使用される実装には以下の2種類があります。
| サポートされているプログラミング言語 | 実際の実装 |
| C/C++ | あり |
| C# | あり* |
| Dart | あり |
| Go | あり |
| Java | あり |
| Kotlin/JVM | あり |
| Node.js | あり** |
| Objective-C | なし |
| PHP | なし |
| Python | なし |
| Ruby | なし |
| WebJS | あり |
**純粋にJavaScript実装およびgRPC C-coreへのバインディング（C ++アドオンを使用）
■データ伝送チャネルおよびチャネル認証情報を安全に保つ
クライアントとサーバ間で通信されるデータが攻撃者の意図する不正サーバに転送される可能性はリモートプロシージャコール（RPC）中に高くなります。このため開発者は、安全なデータ伝送チャネルを優先して確立する必要があります。これを実践することで、データ漏えいを未然に防げるとともに、中間者（Man in The Middle, MiTM）攻撃を介したサービスデータの漏えい、あるいはサーバに影響を与える不正データを通信に注入される可能性を抑えることもできます。
データ漏えいによりサービスやインフラストラクチャ実装の詳細が明らかとなった場合、次なる攻撃によってサービスやインフラストラクチャの侵害につながる可能性さえあります。具体例として、セキュアでないgRPC呼び出しからキャプチャされたパケットの一例を以下に示します。
図4：セキュアでないgRPC呼び出しからキャプチャされたパケットの一例
gRPCは、基礎となるHTTP/2プロトコル全体でTransport Layer Security（TLS）や、さまざまな認証メカニズムをサポートします。安全な実装を選択するのは開発者の責任です。「InsecureChannelCredentials」のようなキーワードを含むコードパターンをコピーして貼り付けることは避けましょう。キーワードが示す通り、コードが安全でないことは明らかです。
トレンドマイクロはgRPCで一般に利用されるC ++言語に限定して、キーワード「InsecureChannelCredentials」をGithub.comでコード検索しました。検索の結果、11,000以上のコード結果が得られたことから、過去に行われた多くのコード検索の結果がこれらのデモやサンプルコードに関連付けられていると弊社は推測しています。ただし、これらの安全でないコードを使用するプロジェクトは今も存在しています。
図5：キーワード「InsecureChannelCredentials」を用いたコード検索結果
■手順の実施における懸念点
AWS Lambda関数などでも同様ですが、脆弱性は実際のリモートプロシージャ実装内に潜んでいることが多いものです。gRPCは複数のプログラミング言語をサポートしているため、経験の浅い開発者はメモリセーフな言語を使用して、バッファオーバーフローやリモートコード実行（RCE）につながる解放後使用（UaF）バグなどの影響の大きいメモリ管理のバグを予防することが推奨されます。
ただしメモリセーフな言語を使用した場合でも、コード内に表示される論理的なバグを軽減することはできません。そのため開発者は、プロセスを開発するための水準を高く設定した上で安全なソフトウェア開発に向けたベストプラクティスに一貫して従い、OWASPの「Secure Coding Practices」で公開されているOWASPのプロアクティブコントロールTop10で推奨される事項を実践してプロアクティブコントロールを実装する必要があります。
システムの重要部に一元化された認証メカニズムを用いることは、隔離されたネットワーク内やプライベートクラウドにおいても強く推奨されます。
設定ミスが原因でネットワーク環境内の脆弱性が悪用された場合、gRPCサービスに大きく影響を及ぼす不正アクセスの侵入経路として機能する可能性があります。
また弊社は、gRPC認証の詳細をサプライチェーン管理（SCM）システムにハードコードしたりコミットしたりしないことを推奨します。これは特に一般向けのものに対して言えます。他の認証情報と同様に、これらの情報は安全な場所に保存し、必要時のみアクセスするようにしましょう。GitHub上の検索結果で確認されたgRPC認証情報漏えいの一例を以下に示します。
図6：GitHub上で確認されたgRPCサービス認証情報の一例
■サービス拒否（Denial of Service、DoS）攻撃
最後に、DoS攻撃に関する弊社の調査結果について解説します。gRPCは隔離されたネットワーク環境内で、ブラウザ上に表示されない「hidden（隠れ）」メッセージングサービスとして機能するほか、JSON形式を使用して対外的に公開されているREST APIサービスのAPIの代替として機能します。
トレンドマイクロはC / C++ gRPCユーザに、サービスが再起動されるまでサービスの呼び出しを事実上拒否する既知の未修正バグについて注意喚起を行っています。このバグは、短時間に大量の接続要求があった場合にトリガーされます。実際このバグが発生する原因は、Linuxシステム上で処理できるファイル記述子の数に制限があるためです。
図7：gRPCライブラリのC / C ++実装内で確認されたDoS攻撃の一例
弊社の調査結果、このバグは、ソケットへの接続が短時間で大量に開かれた場合、および開かれたソケットが閉じられた後でもトリガーされます。弊社は、JavaやGoなどのC言語の関数でラップされていない他のプログラミング言語でこの実装を検証したところ、この問題による影響がないことを確認しました。
あるプラットフォームから他のプラットフォームに切り替えることができない場合は、DoS攻撃のリスクを軽減するために以下の回避策を推奨します。
- 「sudo ulimit -n expandedNumber」を実行して、ファイル記述子の制限を増やしましょう
- 外部ロードバランサ（負荷分散装置）およびウォッチドッグのサービスを使用して、単一インスタンスの負荷を減らし、サービスの稼動状態を監視しましょう
■結論
サービスの信頼性や拡張性を高めるためにgRPCフレームワークを使用する企業は増え続けています。このため企業は、リスクや脅威からプロトコルを保護する方法をより広く認識する必要があります。
gRPCはシステム間での効率的な通信を可能にしますが、これらのシステム間での通信の安全性を確保するのは開発者の責任であると再度認識する必要があります。gRPCには、サポートされている認証メカニズムに関する包括的なガイドがあり、Googleトークンベースの認証の有無にかかわらず、SSL / TLSなどのプロトコルで機能します。これは、開発者が準拠すべき内容です。また開発者は、認証プラグインAPIを介して独自の認証システムにプラグインすることもできます。
さらに開発者は、コンテンツを検証するセキュリティソリューションを使用して、クライアントとサーバ間で転送されるメッセージを介して不正なペイロードがシステム内に侵入できないよう対策を講じる必要もあります。
転送中の重要データを安全に保ち、サービスの稼働状況を監視、最小特権の原則に考慮した上で「認証と承認」を適用し、データを安全に保護する対策も企業にとって不可欠です。
gRPCフレームワークは、開発者や企業が、API、アプリケーション、マイクロサービスをビルドする際に効果的なツールです。しかし、前身であるHTTP / 1.0 同様に、リスクや脅威による影響がないわけではありません。このため、セキュリティソリューション、監視、および制御管理の必要性を再度認識する必要があります。
■トレンドマイクロの対策
トレンドマイクロは、アプリケーションを安全にビルドし、さまざまな環境に迅速にデプロイして実行するDevOpsチームを支援します。トレンドマイクロのHybrid Cloud Security製品群は、DevOps 体制を支えるセキュリティチームに対して、「XGen」アプローチにより、物理・仮想・クラウドの混在環境における最適なセキュリティを提供します。
「Trend Micro Cloud One™ Application Security」は、コードの脆弱性、サーバ上のデータ流出、およびその他のアプリケーションレベルの一般的な脆弱性攻撃への保護を提供します。幅広いアーキテクチャとネットワークトポロジに製品を導入できるため、アプリケーションのエンドユーザと機密データを保護できます。主要なポイントでお客さまのフレームワークに自動的に接続し、悪用しようとする試みを検出してハッキングを阻止し、脆弱性を保護します。
「Trend Micro Cloud One™ Conformity」は、システムに重大な影響を及ぼす可能性があるクラウドの設定ミスを見つけてより早く修復します。業界のコンプライアンス標準とクラウドセキュリティのベストプラクティスのルールに照らした何百もの自動化されたチェックによって、クラウドインフラストラクチャのためのセキュリティおよびコンプライアンスを継続的に支援します。
このほか、トレンドマイクロのセキュリティプラットフォーム「Trend Micro Cloud One™」には、以下の製品・サービスが含まれています。
- Workload Security: パフォーマンスを損なうことなく、データセンター、クラウド、 コンテナを保護するクラウド型セキュリティ
- Container Security: コンテナイメージを自動的にスキャンし、セキュアなCI/CDパイプラインを実現
- File Storage Security: クラウドファイル、オブジェクトストレージサービスのためのセキュリティ
- Network Security: マルチクラウド環境のための強力なネットワークレイヤのセキュリティ
Hybrid Cloud Securityソリューションの主要製品であるTrend Micro Deep Security™は、インスタンスを自動で検出し、エージェントを展開することで、クラウド環境全体を可視化し、保護します。また、多くの要件に対応し、監査証拠を効率的に収集して、継続的なコンプライアンスの実践を支援します。
参考記事：
- 「How Unsecure gRPC Implementations Can Compromise APIs, Applications」
by David Fiser (Security Researcher)
翻訳：益見 和宏（Core Technology Marketing, Trend Micro™ Research）