APIセキュリティツール：APIの保護は、APIのテストではありません

APIセキュリティツールの2つの系統

保護だけに頼ると破綻する箇所

ユーザーAがユーザーBの注文を読み取れてはならない、ということをゲートウェイは知り得ません。それはビジネスルールであり、コードの中に存在します。そしてそこを突くリクエストは、通信上はまったく正当に見えます。正しいメソッド、有効なトークン、整形式のパス。

オブジェクトレベルの認可は、実運用中のAPIで最も多く悪用される欠陥であり、まさにどの保護レイヤーからも見えない種類の問題です。リリース前に、サービスの内側で検証するしかありません。

それぞれの系統が実際にカバーする範囲

• ゲートウェイとファイアウォール： 既知の攻撃パターン、不正な形式のリクエスト、トラフィック量。確かな価値がありますが、ロジックは見えません。

• レート制限： 大量アクセスによる悪用。正しく整形された悪意あるリクエスト1本には、何の効果もありません。

• シークレット管理： 認証情報の漏洩。ここで挙げた他のどれとも独立した領域であり、備えておく価値があります。

• スキャナー： 依存関係の脆弱性、インジェクション系の欠陥、TLSの設定。

• 振る舞いの検証： 拒否すべきものをAPIが本当に拒否するか。最も低コストで、最も欠落していることが多い領域です。

なぜこの空白が残り続けるのか

認可の振る舞いを確認する作業は、低コストで効果も大きいにもかかわらず、広く欠落しています。この奇妙な組み合わせには説明が必要です。

原因は、2つの担当領域の間に落ちてしまうことです。セキュリティの仕事に見えるため、開発チームはセキュリティのプロセスがカバーしていると考えます。一方、セキュリティのプロセスの実体はスキャナーと年次のアセスメントであり、どちらも自社のビジネスルールを知りません。そのため、テストでカバーされているはずだと考えます。どちらの前提もその立場では筋が通っており、結果として空白は何年も残り続けます。

担当者を明確にすることが、解決のほとんどを占めます。エンドポイントを書いた人が、同じプルリクエストの中で、通常の作業の一部として認可の検証も書きます。そうすれば、誰がそのデータを見てよいのかを知っている唯一の人物に作業が置かれ、セキュリティチームの規模ではなくエンドポイントの数に応じてスケールします。

今週のうちに試す価値のある確認

アカウントを2つ作成します。一方でレコードを1件作成し、もう一方のトークンでそれを読み取ってみます。データが返ってきた場合、最も一般的で深刻なAPIの欠陥が存在しており、サービスの手前に置いたゲートウェイでは防げなかったということです。

そのうえで自動化します。この確認は新しいエンドポイントごとに繰り返す必要があり、誰も覚えていられないからです。

何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインでできるその他の操作は、すべてこちらにまとめています： CLIリポジトリ。

生成されるAPIプランには認可と境界値のカテゴリが含まれるため、これらの確認は四半期ごとの作業を待つのではなく、機能面のカバレッジと並んで実施されます。仕組みはこちらで説明しています： APIテストのドキュメント。

ダッシュボードからリポジトリを接続すれば、すでに運用しているデプロイを起点にテストが実行されます。あるいは、自社のワークフローにステップを追加する方法もあります。

検証の系統でTestSpriteがカバーする範囲

どの保護レイヤーにも実施できない、振る舞いの検証です。未認証アクセス、オブジェクトレベルの認可、ロールの境界、期限切れの認証情報、範囲外の入力値。生成されるプランには認可と境界値のカテゴリが含まれるため、先週追加したものも含め、すべてのエンドポイントが対象になります。

稼働中のサービスに対し、そのインターフェース経由で、ディスカバリと仕様定義を使って動作します。Auto-Authenticationは実行中のセッションを維持し、Dynamic Variablesは呼び出し間で値を引き継ぎ、Dependency Chainsは実行順序を導き出し、Auto-Cleanupはその実行で作成されたものだけを削除します。

得られるのは実行頻度です。これらの確認は難しいものではありませんが、40個目のエンドポイントでは忘れがちです。そして変更のたびに実行することが、実運用中のAPIで最も多く悪用される穴を塞ぐ方法です。ゲートウェイとスキャナーは、それぞれが得意なことを引き続き担います。