なぜAPIのセキュリティに気を配る必要があるのかという話は、野菜を食べなければならないという話にちょっと似ています。野菜を食べるのが健康に良いことは誰でも知っていますが、実践できている人はどれくらいいるでしょうか？アプリケーションのセキュリティの場合も事情は似ています。セキュリティは、アプリケーションやビジネスの健全性にとっては不可欠ですが、新しいアプリケーションのクールな機能を構築するほどの面白さはありません。しかし、それがどれほど重要であるかは、最近のニュースの見出しを眺めるだけで十分に理解できます。
従来、アプリケーションやAPIのセキュリティの検証は、開発プロセスの最後に行われていました。しかし、これには根本的な問題があります。発見されたエラーを修正するには手遅れであることが通常だからです。問題を解決するにはリリース日が近すぎるかもしれませんし、チームが他のプロジェクトに移っているかもしれませんし、そもそもアプリケーションのアーキテクチャ自体が安全でないかもしれません。
さらに、今日のサービスとアプリケーションは、これまで以上に頻繁にリリースされ、1日に複数回リリースされることも珍しくありません。この速いリリースのペースについていくには、伝統的なアプローチでは不可能です。
継続的インテグレーションへの移行
この問題を解決するために、ソフトウェア業界がリリースサイクルを加速しながらソフトウェア品質問題に取り組むのに利用してきたソリューションに目を向けてみましょう――つまり、継続的インテグレーションです。継続的インテグレーションは、新しいコードがチェックインされるたびにビルドを生成し、各ビルドに対して静的解析および単体テストを実行することによって新しいコードを検証します。より合理化が進んだチームであれば、CIを使って自動機能テストを作成して実行しているかもしれません（機能テストは通常は実行に時間がかかるため、ビルドのたびにではないかもしれませんが、少なくとも1日1回のような特定の間隔で）。
CIワークフローに侵入テストを導入することで、この同じソリューションをAPIの自動セキュリティテストに適用できます。これにより、セキュリティの脆弱性が早期にテストされ、新しい問題が入り込んだとき、ただちにその問題を検出できるセキュリティ回帰テストを実現できます。しかし、侵入テストはコストが高く、実行に時間がかかる場合があるので、賢く行わなければなりません。スケーラブルかつ持続可能な方法で行う必要があります。
機能テストから始める
ここでは、チームがすでにAPIの自動機能テストを作成して実行していると仮定しています。 （機能テストが自動化されていなければ、そこから始める必要があり、まだセキュリティテストを自動化する段階ではありません）。APIの自動機能テストを実行している場合、通常の開発およびQAプロセスの一環として、セキュリティテストとして使用する機能テストのサブセットを指定することができます。このサブセットをセキュリティテストとして準備し、実行します。
Parasoft SOAtestとメジャーな侵入テストツールであるBurp Suiteとの統合を例として、これがどのように機能するかを説明しましょう。まず、データベースを消去する1つのセットアップテストと3つの異なるAPI呼び出しを行う3つのテストで構成される SOAtest のシナリオがあるとします。このシナリオで呼び出されている3つのAPIのそれぞれについて、侵入テストを実行します。
最初に、次の図に示すように、シナリオ内の各テストにBurp Suite Analysisツールを追加して、シナリオをセキュリティテストに使えるよう準備します。
SOAtest を使用してこのシナリオを実行します。各テストが実行されると、SOAtest はテストで定義されたAPIコールを作成し、リクエストとレスポンスのトラフィックを取得します。各テストのBurp Suite Analysis Toolは、別個に実行されているBurp Suiteアプリケーションのインスタンスにトラフィックデータを渡します。Burp Suiteアプリケーションは、独自のヒューリスティックを使用し、トラフィックデータに含まれたAPIパラメータに基づいてAPIの侵入テストを実行します。Burp Suite Analysis Toolは、Burp Suiteによって検出されたエラーを受け取り、APIにアクセスしたテストに関連するエラーとして SOAtest にレポートします。 SOAtest の結果は、Parasoft DTP の分析ダッシュボードにレポートされ、追加のレポート機能が提供されます。これがどのように機能するかについては、次の図を見てください。
機能テストをセキュリティテストとして再利用すると、次のような利点があります。
- すでに機能テストが作成されているので、既に行った作業を再利用して、時間と労力を節約できます。
- 特定のAPIを実行するには、データベースの準備や他のAPIの呼び出しなどの設定が必要な場合があります。すでに機能している機能テストから始めれば、この設定はすでに完了しています。
- 通常、侵入テストツールは、特定のAPI呼び出しに存在する脆弱性を報告しますが、関連するユースケースや要件についてのコンテキストは提供しません。SOAtestを使用してテストケースを実行する場合、セキュリティ脆弱性はユースケースのコンテキストで報告されます。シナリオが要件に関連付けられている場合、セキュリティエラーがアプリケーションに及ぼす影響に関して、さらにビジネスコンテキストを取得できます。
- エラーを簡単に再現したり、修正されたことを検証するためにテストシナリオを利用できます。
機能テストをセキュリティテストとして使用するための準備
侵入テストとして機能テストを再利用する場合、いくつか考慮すべき点があります。
- 機能テストシナリオをセキュリティテストシナリオとは別にメンテナンスし、別々のテストジョブから実行する必要があります。主な理由は、既存の機能テストに侵入テストを追加すると、機能テストが不安定になる可能性が高いからです。どの機能テストシナリオを自動化されたセキュリティテストにするかを選択し、機能テストのコピーを作成して別個のセキュリティテストとしてメンテナンスする必要があります。
- 侵入テストはコストが高いため、テストを厳しく選別する必要があります。テストの回数を最小限に抑えながら、カバーするAPIの攻撃面を最大限にしなければなりません。その際、以下を考慮します
- 侵入テストツールは、リクエスト/レスポンスのトラフィックを分析して、リクエスト内のどのパラメータがテスト可能かを把握します。APIへのすべての入力が確実に分析されるように、各APIのすべてのパラメータを実行する機能テストを選択する必要があります。
- 各シナリオ内で、どのAPI呼び出しに侵入テストを行うかを決定する必要があります。1つのAPIが複数のシナリオから参照されている場合があります。他のシナリオで侵入テストを行っているAPIを重複してテストしたくありません。Burp Suite Analysis Toolは、侵入テストの対象として適切なAPIテストにのみ追加するべきです。
- 実行時間を短くし、少なくとも1日に1回はセキュリティテストを実行できるようにするため、シナリオの数は多すぎてはいけません。
- 機能テストシナリオには、初期化またはクリーンアップを行うセットアップまたはティアダウンセクションが含まれる場合があります。これらには、通常、侵入テストを行う必要はありません。
- 機能テストがパラメータ化されている場合、それを削除する必要があります。侵入テストツールは、テストするべき対象を特定するために同じパラメータの複数の値セットを必要としないため、異なる値セットを送信すると、テストが重複して行われ、テスト実行時間が長くなるだけです。
- API機能テストには、通常、サービスからのレスポンスを検証するアサーションがあります。セキュリティテストとして使用する場合、これらのアサーションは失敗する可能性があり、結果を確認する際に妨げになります。セキュリティテストでは、検出されたセキュリティ上の脆弱性のみが問題だからです。すべてのアサーションを削除するべきです。前の例では、Test 3からJSON Assertorを削除することを意味します。
- 一部のAPIコールは、データベースにデータを追加します。このようなAPIに対して侵入テストツールを使用すると、侵入テストツールがAPIに向ける攻撃の数によっては、データベースのサイズが膨大になる可能性があります。ときには、予期しない副作用を引き起こす可能性もあります。私たちの開発チームの1つでは、特定のAPIが侵入テスト攻撃のために多くのデータを追加したときに、アプリケーションのパフォーマンスの問題が見つかりました。アプリケーションのパフォーマンスが非常に悪くなったため、自動化されたセキュリティテストの実行が妥当な時間内に終了しなくなりました。結局、問題が修正されるまで、そのAPIのセキュリティテストを自動実行から除外しなければなりませんでした。
安定したテスト環境のメンテナンス
機能テストとセキュリティテストを同じテスト環境で実行するか、別のテスト環境で実行するかを検討する必要があります。機能テストとセキュリティテストの実行の間に環境をリセットするか、別の環境を使用するとテストの安定性が向上しますが、これは通常は必須ではありません。同じ環境を再利用できる場合がほとんどですが、セキュリティテストが機能テストの環境を不安定にする可能性があるため、機能テストを最初に実行し、セキュリティテストを最後に実行します。異なる環境を使用する場合は、元になる機能テストシナリオは変数を使用して構成し、異なる環境の異なるエンドポイントに対して容易にテストを実行できる必要があります。SOAtest は、環境変数によってこれをサポートしています。
APIは、管理外の他のAPIにも依存している場合があります。これらの外部システムに依存しないように、サービス仮想化を使用して環境を隔離することを検討するとよいでしょう。これにより、テストを安定させると同時に、侵入テストによる外部システムへの意図しない影響を防ぐことができます。
まとめ
自動化プロセスの一環として、セキュリティテストを開発およびQAに移行することで、APIの品質を向上させることができます。既存のAPI機能テストを活用して自動化されたセキュリティテストを作成することで、プロセスの初期段階でセキュリティエラーを発見し修正することができます。そして、うまくいけば、会社の名前がニュースの大きな見出しに載るのを防ぐのに役立つでしょう…
（この記事は、開発元Parasoft社 Blog 「Move API Security Testing into Dev/QA as an Automated Part of the CI Process」2017年11月9日の翻訳記事です。）
Parasoft SOAtest/Virtualizeについて
>
SOAtest/Virtualizeは、APIの開発者／利用者に向けてテストの自動化とテスト環境の仮想化の2つの側面から開発を効率化します。SOAtest/Virtualizeは、APIのテストドライバーを提供し、開発中のAPIのテストを自動化する機能と、APIを利用するアプリケーションが必要とするAPIをスタブとして仮想化する機能を同梱して提供します。