ブログ

災害のレシピ: APIファースト、セキュリティラストの戦略

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2019年4月22日公開

API の需要が高まっています。 モバイル アプリを有効にしてデジタル経済の推進に貢献する場合でも、自動化やオーケストレーションの取り組みを通じて社内の生産性を向上させる場合でも、API はあらゆる場所で活用されています。

多くの組織が「API ファースト!」というデジタルスローガンを採用しています。 つまり、Cloud Elements の2018 年 API 統合状況調査の回答者の大多数 (60%) は、API をあらゆる開発者に利用できるようにしています。 それは報われています。 驚くべきことに、85% の組織が API および API 関連の実装から少なくとも何らかの収益を生み出しています。 大部分 (59%) は、組織の収益の 11 ～ 50% を生み出しています。 10 社中 1 社以上 (11%) が、収益の半分以上を API から得ています。 ( MuleSoft の API の価値の高まり)

しかし、API はあらゆる開発者に公開されているということを思い出してください。 善意のある開発者ではなく、あらゆる開発者です。

今日の API エコノミーのオープンな性質は、API ファースト戦略にセキュリティ ラスト戦略が伴うことがあまりにも頻繁に起こるという残念な理由の 1 つです。

著名な組織が関与する API 関連のセキュリティ インシデントは、実に数多く、比較的簡単に見つけることができます。 Forbes で言及されたか、当社の F5 Labsによって発見されたかにかかわらず、これらの組織は、十分に理解されたセキュリティ プラクティスとツールによって防ぐことができた API 関連のセキュリティ侵害に見舞われました。

F5 Labs の主任脅威調査エバンジェリストである Ray Pompon は、API セキュリティに関する調査で次のように述べています。

「…アプリケーション セキュリティにおいて、これまで常に存在してきた同じ古典的な問題、つまりブルート フォース攻撃や盗まれた資格情報によって攻撃者がアクセスを取得するという問題に関連するパターンが見られます。 さらに、API に認証されると、攻撃者は過度に広範囲に割り当てられた権限を悪用しました。」

< https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents > より

同じ、古典的な問題。 結局のところ、API はほとんどの場合、JSON または XML データのペイロードを運ぶ HTTP 転送 URI として実装されるからです。 これは、POST されたフォーム データのペイロードを運ぶ HTTP 転送 URI とそれほど違いはありません。

API はコードへのインターフェースにすぎないことを忘れないでください。 WhiteHat アプリケーション セキュリティ統計に基づくと、10 万行のコード (LOC) あたり平均 39 個の脆弱性があるコード。 待ってください、それは従来のアプリの場合です。マイクロサービス アーキテクチャを使用してインターフェイス(API) を実装した場合、100K LOC あたり 180 はどうでしょうか。 いずれにせよ、脆弱性はたくさんあります。

API には、その相手である Web アプリと同じ脆弱性が伴います。つまり、セキュリティに関しては Web アプリケーションと同じ注意を払う必要があるということです。

しかし、API セキュリティに置かれる重要性は、今日の Web アプリケーションに置かれる重要性と同等ではありません。少なくとも、セキュリティ テストの実行に対する不十分なアプローチを明らかにする実存的証拠に基づくと、その重要性は同等ではありません。 SmartBear による非公式の世論調査によると、現在「広範囲にわたる」 API セキュリティ テストを実施しているのは回答者のわずか 12% でした。 そのほぼ 2 倍 (正確には 23%) は、API セキュリティ テストをまったく実施していませんでした。 これは、 SmartBear が実施したより正式な調査と一致しており、回答者の 80% が API をテストしていることがわかりました。

それでも、そうでない人が 20% 残ります。

API ファーストは、デジタル経済に参入し、ビジネスと運用の両方をスリムで強力なデジタル マシンに変革するための優れた方法です。 しかし、セキュリティを後回しにすることは、それをTwitterでトレンドの辛辣なハッシュタグに変えてしまう素晴らしい方法です*。 そして誰もそれを望んでいません。

したがって、API ファーストを目指すのであれば (そうすべきです)、セキュリティを第一に考慮する必要があります。 API に対してセキュリティを優先する戦略を採用しないでください。

始めるのに役立つ簡単な手順をいくつか紹介します。

  1. 存在する場合はテストします。
  2. ユーザー入力がある場合は、それを信頼しないでください。
  3. ユーザー ログインがある場合は、ブルート フォース攻撃やクレデンシャル スタッフィング攻撃から保護します。
  4. API が基盤とするシステムとサービスを保守し、パッチを適用する必要性に留意してください。 彼らの脆弱性はあなたの API の脆弱性です。

安全に気をつけてお過ごしください。