APIセキュリティをSDLCに統合する
この記事にご興味があるということは、APIがどれほど普及しているか、そしてどれほど脆弱になり得るかをご存知でしょう。
APIを保護すべきだと仮定した場合、その保護はいつ実施すべきでしょうか？開発段階か、本番環境か？シフトレフトかシフトライトか、それともその中間か？SDLCにAPIセキュリティを統合することの長所と短所は何でしょうか？
これらの疑問への答えは、以下のセクションでご確認いただけます。適切なタイミングでセキュリティ対策を講じることで、API開発プロセス全体とセキュリティ体制が劇的に改善されることを学んでいただけます。
サイロ化されたアプローチ
サイロ思考は、開発とセキュリティの間の緊張関係の原因の一つであることに疑いの余地はありません。「開発者はセキュリティを気にかけているのか？」といった疑問は、サイロ化された環境で働くことに慣れたサイバーセキュリティ専門家にとっては正当に思えるかもしれません。しかし、むしろそれは、広く蔓延する部族的な文化の背景にある根深い前提や偏見を露呈しているに過ぎません。
この文化は開発者自身によっても助長される可能性があります。開発チームがセキュリティ専門家を「厄介者」（コードの欠陥を指摘される）、「効率的な作業の妨げ」（コードレビューを強制される）、「プロジェクト目標達成の阻害要因」（納期・予算制限の遵守や迅速な市場投入を妨げられる）と見なす場合、開発者側も同じ文化を育み、結果としてサイロ化されたアプローチを助長することになります。
解決策とは？
この難局を脱する方法は以下の通りです：
- 部門間の壁を取り除く。パートナーシップ、信頼、協働の環境を構築し、ソフトウェア開発ライフサイクルの初期段階から開発チームとセキュリティチームが連携して作業できるようにする。
- 体系的かつ継続的なセキュリティ研修を提供する。API開発におけるセキュリティ問題の多くが、セキュリティ研修の不十分さや完全な欠如に起因している事実に驚かれるでしょう。開発者にAPIセキュリティをその場しのぎで対応させるのは避けること：彼らは既に多くの業務を抱えている。
- 一貫性があり、再現可能で、文書化された開発プロセスを構築する。つまり、毎回同じ方法でAPIを作成し、従業員の異動でプロセスが失われることのないよう文書化すること。
- APIセキュリティツールに投資する。例えば、機械学習を活用した非レガシーな自動化APIセキュリティソリューションは、SDLCの作業負荷を大幅に軽減し、APIセキュリティリスクを最小限に抑えることができる。
API開発におけるセキュリティ責任者は誰か？
ソフトウェア業界の専門家たちは、ソフトウェア体験の進化において主に三つの要件とそれに対応する歴史的段階を概説しています：
- 機能性：初期段階では、アプリケーションに求められたのはその役割を十分に果たすことだけでした。
- 美学：iPhone革命は純粋な機能性に加え、新たな必須要件をもたらしました。それは美学、すなわち滑らかなユーザー体験です。
- セキュリティ：無数のセキュリティ攻撃やインシデントを経て、今日では第三の必須要件としてセキュリティ体験が加わりました。
ソフトウェア体験の進化を考察するこの試みの意味は、我々が暗黙裡に共有する認識を強化することにあります：セキュリティ体験は今日、極めて重要であり、もはや単一の専門家集団の責任では済まされません。
APIの開発と利用に関しては、誰もが安全なAPIを構築し、可能な限り優れたAPI体験を促進する責任を負います。つまり、開発者はセキュリティのベストプラクティスに従ってコードを記述し、セキュリティ専門家は適切な保護策を講じ、定期的なAPIセキュリティテストを実施し、開発者と連携して修正を行う必要があります。
しかし、責任はそこで終わりません。堅牢なセキュリティポリシーを実装するイニシアチブは、開発者やセキュリティ担当者の給与等級よりも上位から発せられる必要があります。その意味で、上級管理職はこのプロセスにおいて独特の役割を果たします。
経営陣がセキュア開発手法を重視しインセンティブを与え、適切な予算を承認し、セキュリティを全面的に統合した一貫性のある構造化された開発プロセスを徹底させる時、良い結果が生まれます。そうでなければ、数年後も我々は依然として同じOWASP APIセキュリティトップ10の脆弱性悪用手法に悩まされ続け、企業や組織に大混乱をもたらし続けるでしょう。
シフト・レフトかシフト・ライトか？
簡単に言えば、シフト・レフトは開発環境でのセキュリティテストを包含します。対照的に、シフト・ライトは本番環境でのセキュリティテストを推奨します。どちらが優れているのか？そして、これらは互いに排他的なのでしょうか？
シフト・ライトを支持する議論は、現実的な環境におけるセキュリティテストの重要性を強調します。ソフトウェアが稼働すると、SDLCの初期段階ではテスト不可能な新たな予期せぬ問題が発生すると主張します。
しかし、APIやWebアプリケーションの公開後にセキュリティテストが（たとえ時間がかかっても）必要不可欠であるという考えに反対する人はほとんどいないでしょう。その意味では、シフトレフトは、シフトライトの基本理念を否定するものではありません。問題は、シフトライトが提唱するこの事後対応型の方法論だけでは十分ではないということです。
SDLCの初期段階でAPIセキュリティテストを統合することは、時間と費用を節約し、多くの頭痛の種を回避できる先見的なアプローチです。これにより、修正が比較的容易かつ低コストで可能な段階で、APIのコード上の問題やセキュリティ脆弱性が確実にチェックされます。
さらに、シフトレフトの考え方と調和させるため、組織は開発者が最初のコードを書く前にセキュリティを考慮に入れる必要があります。APIが最初のユーザーに届く前に、包括的に検証され可能な限り安全であることを保証するため、SDLC全体を通じて継続的なセキュリティテストを実施すべきです。
シフトレフトがセキュリティ上の大惨事を回避するのにどのように役立つか
シフトレフトアプローチの要点をより鮮明に説明するために、API セキュリティに関する重大なインシデントの例を見てみましょう。
災害が発生してから初めてすべてを理解する、いわゆる「後知恵の達人」を好む人はいないでしょう。とはいえ、サイバーセキュリティの世界では、インシデント対応において「教訓」は重要な概念です。つまり、セキュリティインシデントが発生した後、何が問題だったのか、もっと良い対応はなかったのか、次回それを回避するにはどうすればよいのかを正確に把握するために、インシデントを分析するということです。
その観点から、オプタスのケースで何が問題だったのか、また、同社が継続的なセキュリティテストとシフトレフトの実践を主張していたら、状況はどのように変わっていたのかを見てみましょう。
オプタスデータ侵害事件
オプタスはオーストラリアの大手通信会社であり、2022年にAPI攻撃の標的になりました。
「Optusdata」という偽名で知られる攻撃者は、1,100万人以上のオプタス顧客の機密データ（氏名、住所、メールアドレスに加え、ID番号やパスポート番号）へのアクセス権を取得しました。
問題の根源は、外部ユーザーに無防備に公開された非本番環境の内部APIにありました。主な問題は、このAPIがカタログ化さえされていなかった点であり、これはOWASP API9:2023脆弱性「不適切なインベントリ管理」に該当します。
第二の問題は、APIに認証機能が一切存在せず、誰でもアクセス可能だったことです。この欠陥はOWASP API2:2023「破損した認証（Equixly Youtube Channel）」の典型例と言えます。
第三の問題は、APIに極めて脆弱な識別子が含まれていた点です。IDは連番方式で、例えば123という識別子のみを知っていれば、1を加算（124）または減算（122）することで他のアカウントにアクセス可能でした。この脆弱性はOWASP API1:2023—オブジェクトレベル認証の欠陥（BOLA）（Equixly Youtube Channel）に該当します。
オプタスがデータ漏洩を防ぐためにできたこと
オプタスがAPIセキュリティをSDLCに組み込んでいれば、このデータ漏洩は回避できたはずでした。API開発ライフサイクルの初期段階から継続的に適切なAPIセキュリティテストツールを使用していれば、認証が完全に欠如しているという明白な脆弱性を検知し警告できたはずです。
シフトレフトテストの本質は、APIの深層まで探査する適切な手法とツールを用いて、最も一般的かつ深刻なAPIセキュリティリスクの兆候を発見し、タイムリーに容易な修正を適用することにあります。オプタスデータのような事例がAPIの欠陥を露呈するのを待つ必要はありません。
認証に関する指摘は脆弱な識別子にも当てはまります。これもまた、APIセキュリティテストが探知する最も一般的な弱点の一つです。徹底的かつ定期的なテストでこれを逃し、最新のAPIテストツールが警告を発しない可能性はほぼ皆無です。
不適切な在庫管理に関して言えば、オプタスが当初から全てのAPIを文書化していなかったとしても、継続的なセキュリティテストを実施していれば、非本番環境のAPI（セキュリティ上のリスク要因）に関する警告が発生していたはずです。これにより、同社は非本番環境APIのセキュリティ強化、あるいはAPIの完全な廃止といった適切な対策をタイムリーに講じることができたでしょう。
APIセキュリティテストツール
手動テストと自動テスト
組織は、新しいコードが開発されるたびにAPIをテストすべきです。これだけは絶対に守ることです。
しかしこの実践には適切なツールが必要です。専門家によるペネトレーションテストなどの手動APIセキュリティテストは不可欠ですが、それだけでは不十分です。主な理由は、通常非常に高価で時間がかかる点にあります。
後者の点を示すと、40のエンドポイントを持つAPIの手動ペネトレーションテストには154時間かかります。問題は、それでもなお全ての入力とシーケンスの組み合わせを検証するには程遠く、重要な発見を見逃す可能性がある点です。
実際には開発ペースとペネトレーションテストは非同期であるため、CI/CDにおける頻繁な自動セキュリティテストこそが組織にとって最大の利益をもたらします。
APIセキュリティの自動化は、ソフトウェア開発の頻繁な変更に対応し、DevSecOpsチームの全体的な作業効率を向上させます。特に、APIツールが機械学習と大量の関連データによって駆動される場合には、その効果が顕著です。
優れたAPIセキュリティテストツールの条件とは？
APIセキュリティツールを選ぶ際に重視すべき基準は以下の通りです：
- 開発およびテスト環境へのシームレスな統合が必須です。標準ワークフローを妨げ、開発速度を著しく低下させるツールは実用性に欠けます。
- 開発者視点での設計が求められます。
- 最新のOWASP APIセキュリティトップ10脆弱性を検出できること。
- 検出された脆弱性や弱点に関するレポートを生成し、修正策を提案できること。
- APIファジング機能を備えていること。
DAST、SAST、およびSCA
APIセキュリティツールなら何でも良いわけではありません。APIゲートウェイやレガシーAPIツール、あるいはAPI向けに設計されていないWebアプリケーションセキュリティソリューションではほとんど役に立ちません。コードスキャナーも不十分です。通常、これらは侵害につながる主要な問題を検出できません。
一般的に、SDLCに有益なAPIセキュリティソリューションは3種類あります：
- DAST（動的アプリケーションセキュリティテスト）は現実的な攻撃をエミュレートし、脆弱性や設定ミスを探し、ゼロデイ攻撃を発見できます。
- SAST（静的解析セキュリティテスト）はソースコードの問題やパターンを検証しますが、その機能を発揮するにはAPIが記述されている言語をサポートしている必要があります。
- SCA（ソフトウェア構成分析）は依存関係を検証し、その結果を既知の脆弱性データベースと比較します。これにより既存のオープンソース脆弱性は発見できますが、ゼロデイ脆弱性やAPI固有の弱点は検出できません。
これらの3種類のツールはAPIの異なる側面に焦点を当てているため、互いに補完し合います。つまり、予算に余裕があり、深刻なツールの乱立に既に苦しんでいないのであれば、これらを組み合わせて使用するのが理想的です。そうでない場合は、前の小節で述べた基準などを考慮し、自身の状況に最も適したツールを選択してください。
結論
より適切な表現が見つからないため、DevSecOpsマニフェストの一部を引用します：
「コードの改善をスキャナーやレポートだけに依存しない。外部者の視点で製品やサービスを攻撃し、あなたが創り出したものを守る手助けをする。抜け穴を学び、弱点を探し、あなたが単独で解決すべき問題の長いリストではなく、是正措置を共に提供する。組織が過ちや攻撃者の犠牲になるのを待たない。既知の問題を見つけるだけでは満足せず、未検出の異常を探し続ける」
この言葉は、SDLCへのAPIセキュリティ統合の在り方と、APIセキュリティテストベンダーに求める姿勢を端的に示しています。
Equixlyは自動化されたAPIセキュリティテストツールであり、アプリケーションのビジネスロジックの脆弱性を発見し、エッジケースを特定し、盲点を明らかにします。
APIセキュリティをSDLCに統合する方法について、ぜひお問い合わせください。
※この記事はEquixly社ブログを日本語化したものです。
※この記事の無断複写及び転載を禁じます。
※原文：https://equixly.com/blog/2023/12/05/integrating-api-security-in-sdlc/
Carlo De Micheli
Director of Product Marketing
カルロ氏は、豊富な国際経験を持つ多才なプロフェッショナルです。サイバーセキュリティ、自動車、航空宇宙分野など、イノベーションへの情熱は多岐にわたり、先駆的なプロジェクトに積極的に取り組んでいます。航空宇宙工学の技術的バックグラウンドに加え、プログラミングとセキュリティに関する独学も積極的でした。国際会議の企画・発表や、シェアリングエコノミーやファッション関連のテクノロジー系スタートアップの設立を経て、マーケティングとセールスに携わるようになりました。