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

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

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

シナリオ

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

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

しかし、このピカピカの新しいGraphQL APIをデプロイして印象づけようと急ぐあまり、彼らは小さなディテールを見落としていた。Introspectionは開発者にとって強力なツールであり、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のチートシートに慣れることをお勧めする。

Introspectionのセキュリティ脆弱性を緩和する方法

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

どうすればいいのか？

以下は、Apollo Serverを使用している場合に、本番環境でintrospectionをオフにする方法を示す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を巨大な脆弱性にさらす可能性があります。この投稿では、その典型的な例である、本番デプロイメントで introspection を無効にすることで、攻撃者が GraphQL スキーマの詳細情報にアクセスできないようにすることを取り上げました。

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