覚醒必須:API の脆弱性を先回りして特定する

Wake up! Identify API Vulnerabilities Proactively, From Production Back to Code

2021/07/23 TheHackerNews — 20年以上の歳月を経て、ようやく公知となった言葉は APIs are everywhere だ。2021年の調査では、すでに 73% の企業が、50個以上の API を公開していると回答し、この数は常に増え続けている。いまや API は、ほぼ全ての業界で重要な役割を担っており、ビジネス戦略の最前線において、その重要性は着実に増している。これは驚くことではない。API は、異なるアプリケーションやデバイスをシームレスにつなぎ、これまでにないビジネスの相乗効果や効率化をもたらすからだ。しかし、他のソフトウェア・コンポーネントと同様に、API にも脆弱性がある。さらに、セキュリティの観点から厳密にテストされなければ、新たな攻撃の対象となり、これまでにないリスクに晒されることになる。とは言え、API の脆弱性の発見を待ってから、プロダクション環境に移行するとなると、大幅なビジネス上の遅延が発生する。

API の魅力は、企業と攻撃者の双方が分かっている

API は単にアプリケーション間をつなぐだけではなく、予測不可能な方法で機能を変化させることを覚えておくべきだ。API がもたらすユニークな弱点の多くを、ハッカーたちは知り抜いており、API を攻撃することで、基本的なデータや機能にアクセスするという、各種の方式を開発してきた。OWASP API Top 10 によると、正当な認証済みのユーザーが、正当に見えるが API 操作を目的とした呼び出しを利用して、API を悪用してしまうことは珍しくない。 ビジネス・ロジックを操作し、設計上の欠陥を悪用することを目的とした、この種の攻撃は、攻撃者にとって魅力的だ。つまり、すべての AP Iは独自に開発されているため、ソフトウェアのバグや脆弱性も独自のものであり、また、未知のものだ。ビジネス・ロジックやビジネス・プロセス・レベルでの攻撃につながるタイプのバグは、防御側として特定するのが極めて難しい。

APIのセキュリティテストに十分な注意を払っているか?

シフトレフトで前倒しでセキュリティに対応していく方式は、すでに多くの組織に受け入れられており、開発中の継続的なテストも可能である。しかし、API セキュリティ・テストは、しばしば見落とされることがあり、また、関連リスクを十分に把握せずに実施されることがある。その理由は、1つではない。

1. 既存のアプリケーション用のセキュリティ・テストツールは、従来からの Web アプリケーションの脆弱性を対象とした汎用的なものであり、API のビジネス・ロジックの複雑さを効果的に取り扱うことができない。
2. API には UI がないため、ウェブ/アプリ/モバイルの個別テストは行われても、API 自体はテストされない。
3. API のテストは手作業に依存することが多く、何百もの API を抱えるケースに対して拡張性がない。
4. API のテストは他のテストよりも複雑であるため、関連する経験や専門知識が不足する可能性がある。
5. レガシーな API では、すでに実装/運用されている API や、そのドキュメントに関する知識が得られない。

したがって、シフトレフト・セキュリティは、一般的には多くの組織で高く評価されているが、API セキュリティ・テストは DevSecOps の全体像から、取り残されていることが多い。最近の調査では、回答者の 63% が、API の脆弱性を修正するには時間が必要だと報告している。アプリケーションで API が急速に採用され、その依存度が高まっていることを考えると、この数字は増加していくだろう。ほとんどのセキュリティ・リーダーは、API セキュリティ・テストの重要性を認識しているが、その半数弱が、API セキュリティ・テストと開発パイプラインが、完全に統合されていないと答えている。

一般的なセキュリティ・テストで API をカバーできないのは何故か?

包括的なアプローチの第一歩として、今日のアプリケーション・セキュリティ・テストの最も一般的なスタイルである、静的セキュリティ・テストと動的セキュリティ・テストを検証することが重要だ。静的セキュリティ・テストはホワイト・ボックス的なアプローチを採用し、アプリケーション内をデータが通過するときにたどる多数の複雑なパスを含むかたちで、デザイン/アーキテクチャ/コードを確認することで、アプリケーションの既知の機能に基づくテストを作成する。

動的セキュリティ・テストは、ブラック・ボックス的なアプローチを採用し、内部処理や基礎的なコードの知識を無視して、特定の入力セットに対するアプリケーションのパフォーマンスに基づいてテストを作成する。API に関しては、開発者とセキュリティ・チームは、上記の方法のどちらが最適であるかについて頻繁に議論するが、両者を支持する主な理由は次のとおりだ。

・API には UI がないため、ビジネス・ロジック内部で、何が起こっているのかを知る必要がある。
・ユニット・テストは静的モデルを用いることで、パイプラインの初期段階で既に完了しているため、動的テストが必要になる。

盛り上がっているところ申し訳ないが、両者の主張は、どちらも部分的に正しいだけだ。実際のところ、幅広いカバレッジを確保し、さまざまな可能性のあるシナリオに対応するためには、両方のアプローチが必要となる。とりわけ、API ベースの攻撃が増加している現在、スケーラビリティ/深度/頻度に関して、あらゆる機会を見逃すことはできない。その点で、グレイ・ボックス型の API セキュリティ・テストは、興味深い選択肢を提供するかもしれない。

UI が無いにしても、アプリケーションの内部動作 (パラメータや戻値の型など) の知識があれば、ビジネス・ロジックに焦点を当てた機能テストを、効率的に作成することが可能だ。理想的には、API セキュリティ・テストのアスペクトを組み合わせることで、それぞれのアプローチの弱点を補う、グレー・ボックス型ソリューションの作成に近づく。このようなビジネス・ロジックのアプローチは、他のテスト・タイプの結果をインテリジェントに検証し、改良されたテストを自動/手動で適用することが可能だ。

今こそ、ビジネス・ロジック API セキュリティ・テストのアプローチを

この業界では、API をセキュリティ管理の中心に据え、そのライフサイクル全体にわたって、API を保護していく必要性があると認識されつつある。そのためには、組織における API セキュリティ・テストを簡素化/効率化する方法を見つけ、開発サイクルの中で API セキュリティ・テストの基準を、統合/実施する必要がある。この方式は、ランタイム・モニタリングを伴うものであり、すべての既知の脆弱性を、セキュリティ・チームはシングル・ポイントで可視化できる。

それに加えて、API セキュリティ・テストのシフトレフト化に踏み切ることで、コストは削減され、また、修復までの時間は短縮される。さらに、テストのワークフローが自動化されると、再テストもサポートされるようになる。つまり、テスト/修正/再テスト/デプロイというサイクルで、パイプラインをスムーズに走らせ、ボトルネックを完全に回避できる。API セキュリティ・テストを前提としたビジネス・ロジックのアプローチは、Full Lifecycle API Security プログラムの成熟度を高め、セキュリティ態勢を改善することにつながる。

しかし、この最新のアプローチでは、アプリケーションの構造やロジックに関する洞察を得るために、ランタイム・データを取り込み、時間の経過とともにパフォーマンスを向上させながら、学習していくツールが必要となる。そのためには、実行中に学習できる適応型テスト・エンジンを作成し、API の動作に関するより深い知識を身につけて、隠された内部構造をインテリジェントにリバース・エンジニアリングする必要がある。ランタイム・データとビジネス・ロジックの情報を利用することで、ブラック・ボックスとホワイト・ボックスの両方の長所を活かし、自動化による可視性と制御性を高めることができる。

まとめ

API は、その人気の高さ故に、Web アプリケーションに大きな脆弱性をもたらす。多くの組織は、自社の API と脆弱性がどの程度のものかさえ把握していない。既知の弱点も未知の弱点も、利用可能な API を介して、ハッカーたちに簡単に探り当てられてしまう。しかし、API のセキュリティ・テストは見落とされがちであり、また、Web アプリケーションと同じように扱われている。ブラック・ボックやホワイト・ボックスのテストといった、ほとんどのテスト手法は API テストには適していない。自然言語処理と人工知能の組み合わせが、API セキュリティ・テストの複雑なプロセスを、自動化/拡張/単純化するグレイ・ボックスの選択肢を提供する。

ちょっと抽象度の高いロジックが、延々と展開されるので、訳すのが大変でしたが、なかなか面白い記事でした。こういう記事が出てくる背景には、もちろん、多発するサプライ・チェーン攻撃という問題があります。先日も、この領域のセキュリティについて友人と話しましたが、彼のようなリスク管理の専門家でも、この領域は難しいようです。と言うか、専門家だからこそ、難しさの本質が分かるのでしょう。それと、タイトルの覚醒必須という書き出しですが、原題が Wake up! だったので、こうなってしまいました。

%d bloggers like this: