API 探索による API スプロールの抑制方法
セキュリティの専門家であれば、スプロールという概念をご存知でしょう。潜在的な攻撃ベクトルの増殖が制御不能な状態になってしまうと、権限からパスワードに至るまで、スプロールに対処しなければならなくなります。
1980 年代の映画『グレムリン』に似たようなものです。確かに、最初はかわいらしい小さな毛玉を飼うことから始まるかもしれませんが、物語が進むにつれ、金切り声を上げたり物を壊したりする問題のある生き物の群れに囲まれていると気づくことになります。
映画の典型的な展開はさておき、多くの組織にとって経験のない無秩序の拡大があります。そして、それは一般的な攻撃ベクトルになりつつあります。それが API スプロールです。
グレムリン（または API スプロール）の管理
構築するアプリケーション、クラウドに移行するワークロード、そして従業員がコラボレーションに使用するツールのすべてにおいて、その裏側ではデータ交換を行う API が存在します。そして、技術革新のペースが速いことが、API をグレムリンモードに陥らせる原因となっています。
API スプロールは、複数の開発チームを抱え、多種多様なアプリケーションやサービスを運用する組織にとって一般的な問題です。より一層のイノベーションが求められるにつれ、より多くの API が作成されるようになり、それらの API の追跡、使用状況、呼び出し時に返されるデータのタイプを把握することがますます困難になっています。
API スプロールは、開発の非効率化、コストの増加、パフォーマンスの問題、リソースの浪費につながる可能性があります。また、特定の API の目的や使用方法が混乱を招き、開発者がニーズに合った API を見つけたり、API 間の相互関係を理解したりすることが困難になる可能性もあります。ビジネスが API に依存する度合いが高まるにつれ、API スプロールがどのようにして起こるのか、また、それをどのようにして防止または効果的に管理できるのかを理解する重要性がますます高まっています。
このブログ記事では、API スプロールがどのようにして発生するのか、また、その発生を防ぐために組織が何をすべきかについて説明します。これらの戦略を理解すれば、API をより適切に管理し、今後もアプリケーションの効率性と保守性を維持できるようになります。
API スプロールの発生原因
API スプロールは、API 管理の不備、ガバナンスの欠如、既存の API に対する可視性の不足、不十分なドキュメント化など、さまざまな理由で発生する可能性があります。適切なガバナンスと可視化がないと、組織は、使用されていない、あるいは適切に管理されていない API が大量に存在していると、後になって気づくことになります。
従業員の離職も、休眠 API、シャドー API、ゾンビ API が発生する大きな要因となっています。組織内で開発者が入れ替わる頻度を考えてみてください。退職日までに知識を引き継いだりプロジェクトを完了させたりする時間があるでしょうか？ どんなに誠意のある開発者でも、引き継ぎの際に抜け漏れが起きる可能性はあります。
さらに、合併や買収の結果として「継承」された API は、よく忘れ去られます。困難で複雑なシステム統合の作業中に、インベントリが失われる（あるいは、そもそも存在していない）場合もあります。被買収企業の API のドキュメント化が不十分であれば、企業は重大なリスク、たとえば未知のリスクに直面する可能性があります。
セキュリティが不十分であったり、既知の脆弱性がある古いバージョンの API がそのまま残されていることも珍しくありません。ソフトウェアのアップグレード中、新旧のバージョンが一定期間共存しなければならない場合もあります。また、適切なバーション管理と API の非アクティブ化を任された担当者が退職したり、新たな任務を与えられたり、あるいは前のバージョンの削除を忘れてしまうこともあります。
API スプロールがもたらす影響
セキュリティ面では、組織の API のセキュリティが適切に確保あるいは設定されていない場合、API スプロールは攻撃者が脆弱性を悪用する機会を増やしてしまいます。API が制御不能なほど増殖すると、組織はアプリケーション、システム、および機微な情報などのリソースの相互接続状況を把握できなくなり、アーキテクチャやインフラに関する情報に基づいた意思決定が妨げられます。API の正確な数を把握できなければ、API の利用状況を監視することはほぼ不可能です。
見えないもののセキュリティは、確保できないのです。
ビジネスへの影響という観点では、API スプロールはパフォーマンスの低下につながる可能性があります。複数の API を追加し、維持管理することは、それらの管理を複雑化させ、リクエスト時のレスポンスタイムの遅延やレイテンシーの増加につながります。さらに、API スプロールが発生すると、組織は API の管理に多くのリソースを投入しなければならなくなり、コストの増加につながる可能性があります。
API 探索とは何か。API 探索はどのように API スプロールを抑制するか
API 探索とは、組織が自社の API を識別、カタログ化、管理し、リスクを評価するプロセスと一連の機能です。API 探索を適切に実施することで、API スプロールを減らし、セキュリティ体制を改善することができます。
また、API 探索は、組織が現在の API の状況をよりよく理解し、今後の開発について情報に基づいた意思決定を行うのにも役立ちます。さらに、API へのアクセスの監視および制御を容易にし、承認されたユーザーのみがアクセスできるようにします。
手動での API 探索が選択肢にならない理由
API 監査を手動で完了させるには、必要なすべての入力を正確にドキュメント化するために、1 つの API につき最大 40 時間かかる可能性があります。また、発生状況の調査、被害の評価、是正措置の実施、根本原因の調査には、さらに多くの時間を要するおそれがあります。
リソースが逼迫してしまっているセキュリティチームにとって、自動化された手順を使用して使用中のすべての API を探索できることは、API 資産を守る上でのメリットと成り得ます。すべてのデジタルアクティビティにわたって、API ゲートウェイで管理されていない API や API ドメインも含め、すべての API を洗い出してインベントリを作成することが重要です。
Akamai が API 資産の分散を解消する方法
このブログ記事も終わりに近づいてきました。ここで少し立ち止まって周りを見渡してみましょう。この間、あなたの API グレムリンはさらに増殖したでしょうか？
API スプロールはかなり深刻な問題になり得ます。より良い質問は、次のようなものです。API 探索における組織の能力を向上させたいとお考えですか？もし答えがイエスであれば、私たちは喜んでお手伝いいたします。
Akamai API Security は、検出しにくいシャドー API も含め、すべての API の正確なインベントリを維持できるよう設計されています。API インベントリにおけるリスクを軽減し、信頼性を高めるのに役立つ機能の一部を以下にご紹介します。
Akamai のディスカバリーモジュールを使用すると、合理化されたユーザー体験を通じて、セキュリティチームはオンプレミスおよびクラウド環境にわたる無数のデータソースから完全な可視性を獲得できます。
Akamai API Security は、数百から数千のインフラにまで拡張でき、ロードバランサー、API ゲートウェイ、Web アプリケーションファイアウォールを監視して、HTTP、RESTful、GraphQL、SOAP、XML-RPC、JSON-RPC、gRPC など、あらゆるタイプの API を特定して分類します。
Akamai のデータ分類機能は、API トラフィックを監視し、API を通るデータのタイプを可視化します。これにより、クレジットカードデータ、電話番号、社会保障番号、その他の機微な情報にアクセスできる API の数をすぐに確認できます。