DevOpsパイプラインにおけるセキュリティ

ソフトウェア開発とDevOpsプロセス（設計からデプロイまで）において、セキュリティは最優先事項でなければなりません。それを後回しにすれば、セキュリティ・インシデントがあなたを苦しめることになるでしょう。

この投稿では、GraphQL APIの開発者が犯しがちな重大な見落とし、つまり本番環境でイントロスペクション機能を有効にしてしまうこと、について取り上げます。イントロスペクションは、開発段階においてAPIの機能を理解しテストするための素晴らしい機能です。しかし、運用を開始する前に無効にしなければ、アプリケーションを重大な脆弱性にさらすことになります。DevOpsパイプラインのセキュリティを強化するためにあなたが取ることができる予防的なステップとともに、これがどのようにして重大なセキュリティリスクにエスカレートする可能性があるかについて説明します。

シナリオ

開発チームが組織のGraphQL API実装の陣頭指揮を執っているところを想像してみてください。GraphQLは強力なクエリ言語で、クライアントが1回のクエリで必要なものを正確にリクエストできるように設計されています。これは、複雑なデータと関係をまとめるために複数のリクエストを必要とする可能性がある従来のREST APIとは異なります。GraphQLのデータ構造はスキーマで定義され、データタイプ、クエリ、および利用可能な変異の概要が示されます。

開発チームは大規模な取り組みを行い、非常に素晴らしいものを作り上げました。このAPIは堅牢なだけでなく、チームが設計・構築した自動スケーリング機能のおかげで、毎分数百万のトランザクションを処理できるスケーラビリティを備えています。パフォーマンスとスケーラビリティに重点を置くことで、彼らはこのAPIが何の支障もなく巨大な負荷を処理できることを確認しています。

しかし、このピカピカの新しいGraphQL APIをデプロイして印象づけようと急ぐあまり、彼らは細かい点を見落としてしまいました。イントロスペクションは開発者にとって強力なツールであり、APIで利用可能なリソースを照会する方法を提供します。しかし、本番環境でアクセスできるように開放されるべきものではない。

その結果、何が起こるのでしょうか？

APIが需要を満たすためにスケールアウトすると、新しいインスタンスが増えるたびに潜在的なリスクは増大します。今、重大なセキュリティの脆弱性は増え続けるノード全体に広がっています。これによって、悪意ある行為者に悪用される可能性が出てきました。彼らはこのピカピカの新しいAPIの構造と能力に関する詳細な情報を発見するのに必要なものを全て持っています。

簡単なトグルを忘れたことで、チームは良かれと思った機能をセキュリティ上の欠陥に変えてしまいました。

脆弱性を理解する

イントロスペクションを有効にすると、開発者はGraphQL APIにクエリを実行して、すべてのデータ型、フィールド、クエリ、変異を含む完全なスキーマを確認することができます。これはAPIのすべての操作エンドポイントとデータ構造の詳細なマップを持つようなものです。これが開発者の手に渡ることは、非常に有益です。しかし、サイバー攻撃者の手に渡したくはないものです。

攻撃者があなたのGraphQL APIについて知るために、どのようにイントロスペクション機能を利用するかを考えてみましょう。まず、攻撃者はクエリー結果を読みやすくするためにフラグメントを定義することができます。

fragment FullType on __Type {     kind     name     description     fields(includeDeprecated: true) {       name       description       args {         ...InputValue       }       type {         ...TypeRef       }       isDeprecated       deprecationReason     }     inputFields {       ...InputValue     }     interfaces {       ...TypeRef     }     enumValues(includeDeprecated: true) {       name       description       isDeprecated       deprecationReason     }     possibleTypes {       ...TypeRef     }   }   fragment InputValue on __InputValue {     name     description     type { ...TypeRef }     defaultValue   }   fragment TypeRef on __Type {     kind     name     ofType {       kind       name       ofType {         kind         name         ofType {           kind           name           ofType {             kind             name             ofType {               kind               name               ofType {                 kind                 name                 ofType {                   kind                   name                 }               }             }           }         }       }     }   }

次に、 __schema フィールドをイントロスペクションするためのクエリを送信できます。GraphQLクエリは次のようになります：

{   __schema {     queryType {       name     }     mutationType {       name     }     subscriptionType {       name     }     types {       ...FullType     }     directives {       name       description       locations       args {         ...InputValue       }     }   } }

イントロスペクションを有効にしたGraphQL APIに、フラグメント定義とともにそのクエリーを送信することで、攻撃者はすべてのAPIの詳細を含む包括的なJSONオブジェクトのレスポンスを受け取ることになります。その後、GraphQL Voyagerのようなツールを使用して、GraphQL APIをインタラクティブなグラフとして表示することができます。

上で示したイントロスペクション・クエリに対するレスポンスに基づく、GraphQL APIの視覚化の例を以下に示します：

ご覧のように、これは機密性の高い支払い操作に関連する多くの構造と詳細を明らかにする。これはAPIに侵入しようとする攻撃者にとって非常に有益な情報です。繰り返しになりますが、開発者にとっては素晴らしいことだが、残念ながら攻撃者にとっても素晴らしいことなのです。

本番でイントロスペクションを有効にしたままにしておくと、以下のようなリスクが生じます：

• 情報の暴露：詳細なスキーマ情報は、攻撃者にバックエンドシステム、データモデル、ビジネスロジックに関する洞察を与える可能性があります。攻撃者に城の設計図を渡すことで、標的型攻撃を容易に仕掛けることができるようになります。
• 攻撃の促進：攻撃者はAPIに関するこれらの詳細を武器に、脆弱性を悪用したクエリーを作成することができます。これはデータ漏洩やサービスの中断につながる可能性があります。
• リソースの枯渇：攻撃者はこの知識を利用して、サービス拒否（DoS）攻撃として悪意のあるクエリを作成することもできます。このような攻撃はリソースを枯渇させ、システムを完全にダウンさせる可能性があります。

しかし、心配はいりません！このリスクを軽減する手順はシンプルで明快です。自身を守る第一歩として、まずはOWASPが何を言っているのかを見てみましょう。

OWASP GraphQL Cheat Sheetからのガイダンス

OWASP GraphQL Cheat Sheetは、GraphQL API を保護するための貴重なリソースです。このチートシートは、以下の分野で役立つガイダンスを提供します：

• 入力の検証
• 高価なクエリの制限または防止
• 適切なアクセス・コントロールの確保
• イントロスペクションなどの安全でない設定の無効化。

チートシートには、IntrospectionとGraphiQLの特化したセクションがあります。GraphiQLは、GraphQLを探索するためのブラウザ内IDEです。イントロスペクション機能と同様に、GraphiQLはAPIの内部構造や設計に関する詳細な情報を公開することができます。

もしあなたがGraphQL APIを構築するのであれば、OWASPのチートシートに目を通しておくことをお勧めします。

インストロペクションのセキュリティ脆弱性を緩和する方法

OWASPのチートシートを参考に、本番環境や一般にアクセス可能な環境では、イントロスペクション・クエリを無効にするという指示に従います。これは、攻撃者に悪用される可能性のある詳細なスキーマ情報への不正アクセスを防ぐ上で極めて重要です。

どのように行うのでしょうか？

以下は、Apollo Serverを使用している場合に、本番環境でインストロペクションをオフにする方法を示すJavaScriptの簡単なコードスニペットです：

const { ApolloServer } = require('apollo-server'); const server = new ApolloServer({   typeDefs,   resolvers,  // Enable introspection only in development or test environments   introspection: process.env.NODE_ENV === 'development' ||                 process.env.NODE_ENV === 'test', }); server.listen().then(({ url }) => {   console.log(`Server ready at ${url}`); });

そう、基本的にはこれだけです。このシンプルなステップ（ の新しいインスタンスを構成する際に、 を introspection への false の新しいインスタンスを設定するときに ApolloServerに設定) を使用すると、ユーザがイントロスペクション・クエリを通じて詳細なスキーマ情報にアクセスできなくなります。これにより、機密情報が漏れるリスクを減らすことができます。

これをセキュアなDevOpsパイプラインの一部にする

こんなに簡単なステップなのに、なぜ開発者は忘れがちなのでしょうか？それは、彼らが他のことに集中し、重要な締め切りに間に合わせることに忙殺されているからです。一見些細な設定が、時折見落とされるのは驚くことではありません。

だからこそ、自動テストやDevOpsパイプラインがあるのです。 人為的なミスや忘れを防ぐために。

このセキュリティ対策をDevOpsパイプラインに統合するにはどうしたらよいでしょうか？ここに2つの提案があります：

• 本番デプロイ時にイントロスペクションが無効になるように、GraphQLサーバーの設定を明示的にチェックするデプロイ前テストを記述します。
• 本番環境でイントロスペクション・クエリを試行する、デプロイ後のテストを作成します。試行がエラー応答（たとえば Cannot query field '__schema' on type 'Query')であれば、テストは合格となります。

Jenkins、GitHub Actions、CircleCIなどのCI/CDパイプラインツールを活用し、CI/CDプロセスの一環としてGraphQL API設定をチェックするスクリプトを実行します。

結論　

GraphQL APIを構築することは、企業にとって革新的な素晴らしい方法になり得ますが、セキュリティの実践について積極的に取り組む必要があります。ちょっとした不注意がAPIを巨大な脆弱性にさらす可能性があります。この投稿では、その典型的な例として、本番環境へのデプロイメントにおけるイントロスペクションの無効化を取り上げました。これにより、攻撃者が貴社のGraphQLスキーマの詳細情報にアクセスできなくなります。

より詳細なガイダンスやリソースについては、Linodeのセキュリティ、GraphQL開発、https://www.linode.com/docs/guides/platform/ に関連する包括的なガイドライブラリーをご覧ください。