DevSecOps 向け API セキュリティ

2024 年 6 月、Akamai は Noname Security を買収しました。Noname Security 製品は現在 Akamai API Security になりましたが、このアーカイブされたブログ記事では、製品名と機能名は当初の公開日である 2022 年 9 月 29 日のものを反映しています。

DevSecOps は、DevOps（開発と運用）の一種であり、ソフトウェア開発ワークフローにセキュリティを追加したものです。アプリケーション・プログラミング・インターフェイス（API）のセキュリティは、DevSecOps の一部に組み込む必要があります。

この記事では、DevSecOps がどのように機能し、DevSecOps プロセスに従って開発されるアプリケーションを可能な限り安全にする上で、API セキュリティが果たす役割をご紹介します。

DevSecOps の概念を理解するためには、まず DevOps についてしっかりと理解する必要があります。DevOps とは、DevSecOps の基盤となる原形です。DevOps とは、ソフトウェア開発（dev）と IT 運用（ops）という、従来別々の 2 つのプロセスを組み合わせたものです。従来、開発部門はコードを作成し、それを IT 運用部門に渡して本番環境に導入してきました。この仕組みは、ウォーターフォール型の開発が主流で、新しいバージョンのアプリケーションを数か月、または数年かけて完成させていた時代には有効でした。

しかし、アジャイル開発手法と CI/CD の普及に伴い、開発と運用を分離するという古い考え方はもはや現実的ではなくなりました。新しいコードが 1 時間ごとにとまではいかないものの、毎日のように運用部門の手に渡り、リリースする必要がありました。

障害を起こさずに全てを実行する唯一の方法は、開発と運用のワークフローを統合することでした。統合されたプロセスには、統合チームが必要でした。

新しい DevOps 環境では、開発者と運用担当者が協力して、コードを迅速に本番環境にリリースします。こうした経験したことのないパートナーシップによって開発チームと運用チームの間ではむしろ緊張が高まり、十分な説明や指示なしで仕事を任せるような（旧態依然とした）やり方により、生産性が低下しました。DevOps では、責任分担モデルを導入することで、このダイナミクスを変えました。

サイバー脅威の増加に対応するため、DevOps ワークフローにセキュリティを組み込むことが自然な選択となりました。こうして、DevOps は DevSecOps になりました。これに伴い、開発プロセスを遅延させる「交通巡査」として敬遠されがちだったセキュリティ部門との緊張関係も緩和されます。DevSecOps により、新しい連携方法が生まれます。セキュリティは、開発サイクルをより迅速かつ安全に行うための成功要因になりました。

DevSecOps で成功を収めることは容易ではありません。複数のチームとワークフローでは、それぞれの目標を追求しながらも、役割分担や連携が求められます。DevSecOps で人とプロセスの複雑な調整を実現するためには、ツールとプロセスを慎重に組み合わせる必要があります。テクノロジーは、その双方に対応し、譲歩しながら妥協点を見つけ出さなくてはなりません。リーダーシップもここに含まれます。

DevSecOps を成功させるには、セキュリティチームは新しい CI/CD の世界に合わせてテスト方法を調整する必要があります。その代わり、DevOps チームは、少なくとも機能的な問題を扱うのと同じく厳格に、セキュリティ問題に対処する必要があります。実際、慎重さを欠くプログラムにはセキュリティ上の問題があり、未処理案件の中で古くなり消えていきます。さらなる成功のためには、DevOps ワークフローのできるだけ早い段階でセキュリティ業務を実施するシフトレフト戦略の採用が必要です。

DevSecOps で API のセキュリティを確保するためには、開発中に API セキュリティテストを実行し、API が運用段階に入った後に API 監視を実行する必要があります。API セキュリティテストは、DevSecOps の他のセキュリティテストと同等ですが、いくつかの顕著な違いがあります。たとえば、静的テストはコードの脆弱性を検出するのに役立ちますが、すべての API の脆弱性を特定する際には効果的ではありません。

代わりに、DevSecOps の API セキュリティテストでは、ビジネスロジックを用いたブラックボックステストの実行に重点を置く必要があります。このアプローチでは、アプリケーションの導入時に API が実際にどのように動作するかを明らかにします。

Noname Active Testing などの API セキュリティテストツールでは、この種のテストを実行できます。こうした製品によって、Open Web Application Security Project（OWASP）API Security Top 10 リスクに記載されている脆弱性を検知することができます。これには、オオブジェクトレベルの認可の不備、制限のないリソース消費、セキュリティ設定のミス、不適切なインベントリ管理などが含まれます。これらの脆弱性が存在し、緩和されていない場合、API を攻撃する攻撃者が機密データに不正アクセスできてしまう可能性があります。

Noname Active Testing は、高度にカスタマイズ可能なテストスイートをサポートしているため、CI/CD パイプラインとの統合が可能です。このツールは、複数の CI/CD システムとの統合を通じて、シフトレフトスタイルのテスト実施を可能にします。この 2 つの要因によって、本ツールのユーザーは API に関して「Sec」を DevSecOps に組み込めるようになります。CI/CD 統合は不可欠です。なぜなら、これによって最新のアプリケーションのセキュリティを維持するために必要な、継続的かつ迅速な API セキュリティテストが可能になるからです。

DevSecOps における API セキュリティは、開発段階に留まりません。ベストプラクティスは、API セキュリティのプロセスを本番環境でも継続することです。本番環境の API を監視することにより、DevSecOps の「Sec」部分では、例えば運用段階で管理者による再設定や誤設定などによって脆弱化した API を早期に検知し対処することができます。検知された API の脆弱性は、DevSecOps ワークフローの一部として修復できます。

DevSecOps は実装が困難な場合があります。すべてのプロセスを全員で迅速に進めるためには、多くの人々やプロセスが密接に連携しなくてはなりません。API セキュリティによって、DevSecOps が複雑化し、スムーズな運用が中断する恐れもあります。しかし、安全なアプリケーションの開発には、API セキュリティテストが不可欠です。DevSecOps で API セキュリティを適切に機能させるには、専用の API セキュリティのテストおよび監視ツールを使用する必要があります。