セキュリティの注意喚起を受けて自社のシステムを調べようとしたものの、APIの接続先や管理担当が分からず、確認が止まっていないでしょうか。
まず、一つのサービスを選び、「どのアプリが、どのAPIに接続し、誰が管理しているか」を一覧にします。分からない項目は推測で埋めず、確認先を書き添えます。この記事では、そのための資料の集め方と記入例を紹介します。
ここでいう公開APIは、インターネットからアクセスできるAPIです。開発者向けに仕様を一般公開しているものだけでなく、自社アプリ専用のAPIも含みます。「インターネットから接続できること」と「認証なしでデータを取得できること」は別です。
A2B攻撃の記事では、公開アプリを手がかりに接続先のサーバが狙われる仕組みを説明しました。今回は、その接続先を社内で把握し、管理する作業を扱います。
1．アプリからデータベースまで、接続先をたどる
APIは、アプリやWeb画面がサーバと情報をやり取りする窓口です。たとえば、会員向けアプリが注文履歴を表示するときは、APIを通じてサーバに問い合わせます。
この接続先を、現在使っているアプリからたどってみてください。旧版アプリや取引先の連携システムが別のAPIを使っているなら、そちらも確認対象に加えます。
図1：棚卸しの対象を説明するために当社が作成した架空の構成例です。矢印は接続関係を示し、通信の応答は省略しています。画像を開くと拡大できます。
OWASPは、APIの稼働環境、アクセスを認める相手、バージョンを記録し、古いバージョンの廃止計画を管理することを推奨しています。古いAPIや検証環境が、現行環境と同じように管理されているとは限りません。出典：OWASP API9
ただし、古いという理由だけで不要とは判断できません。旧版アプリを使う利用者や、更新頻度の低い外部システムが接続している可能性があるためです。
2．仕様書だけでなく、現在の設定も確認する
新しい管理ツールを選ぶ前に、手元の資料と現在の設定を照合します。次の表は、確認する場所の例です。
| 確認するもの | 調べる内容 | その情報だけでは分からないこと |
|---|---|---|
| アプリの設定・API仕様書 | 接続先、APIのパス、用途、バージョン | 書かれていない旧環境の有無 |
| DNS・クラウドの構成・公開設定 | ドメインの接続先、公開用の入口、転送先 | 実際に利用しているアプリや業務 |
| アクセスログ | 記録期間内のアクセス、呼び出されたAPI | 保存期間外の利用、記録されていない通信 |
| 開発・運用の担当者や委託先 | 用途、変更履歴、保守対象、停止の判断者 | 引き継がれていない設定や未確認の変更 |
DNSはドメイン名と接続先を対応付ける仕組みです。DNSに登録があるだけでAPIの稼働や公開状態を断定せず、サーバやクラウド側の設定も確認してください。
たとえば、API Gatewayやロードバランサーを使っている場合は、そこからどのサーバへ転送しているかを調べます。管理画面を確認する権限がなければ、担当者に設定の確認を依頼します。
資料と設定が食い違っていたら、どちらかを正しいと決めつけず、相違点と確認日を記録します。「仕様書にない接続先がある」「担当者は停止済みと言うが設定が残っている」といった形で残すと、次に誰へ聞くべきかを決めやすくなります。
3．分かっていることと不明点を、一つの表にする
以下は架空の記入例です。最初はサービス・環境・バージョンごとにまとめ、詳細なAPI一覧や設定への参照を付けます。同じ接続先でも公開範囲や担当が異なる場合は、行を分けてください。
| 対象 | 用途・利用者 | 公開範囲と確認日 | 管理担当 | 不明点と次の確認 |
|---|---|---|---|---|
| 現行API／v2・本番 | 会員アプリの注文照会 | インターネットから接続可。10/20に設定確認 | 開発担当A | 認可テストの実施記録を確認する |
| 旧API／v1・本番 | 旧版アプリ向け。現在の利用者は不明 | 設定を未確認 | 開発委託先B | 利用状況と契約上の保守範囲を確認する |
| 検証API／test | リリース前の動作確認 | 接続制限を未確認 | 運用担当C | 公開設定と使用データを確認する |
実際の管理表には、接続先のホスト名・パスや設定資料へのリンクも記入します。詳細な構成情報を含むため、社内の権限を設定した保管先で管理し、パスワードやAPIキーは書き込まないでください。
公開範囲に加えて、認証方法（利用者を確かめる方法）と、認可（その利用者にどのデータの操作を認めるか）も別項目で確認します。「ログインが必要」という記録だけでは、他の利用者のデータを取得できないことまでは確認できません。
一覧ができたことは、安全性を確認できたこととは違います。 この表の役割は、確認対象と担当を整理することです。認可のテストや脆弱性の点検が未実施なら、その状態を残してください。
4．旧APIを止める前に、利用者と停止時の影響を確認する
アクセスログに記録がない場合も、それだけで停止を決めないでください。ログが有効か、どの期間が残っているか、対象の通信が記録されているかを確認します。月末処理など、特定の時期にしか動かない連携にも注意が必要です。
停止を検討するときは、次の項目を担当者と確認します。
- 接続しているアプリ・取引先・定期処理と、その利用周期
- 利用を続ける場合の保守担当、修正対象、代替APIへの移行方法
- 停止を承認する人、利用者への連絡、作業日時
- 停止後の確認方法と、問題が起きた場合の対応手順
脆弱性が見つかっているAPIでは、単純に元へ戻すと危険も戻る可能性があります。サービスへの影響とセキュリティ上の問題を合わせて、暫定対策や移行方法を決めます。
検証環境も、接続制限と使用データを確認します。OWASPは、非本番環境での本番データ利用を避け、避けられない場合は本番と同等の保護を行うよう推奨しています。出典：OWASP API9
5．変更と引き継ぎのときに、一覧を更新する
一覧には更新担当と最終確認日を付け、APIの追加・変更・廃止を行う作業の中で更新します。担当者や委託先が変わるときも、接続先、管理権限、未確認事項を引き継ぎます。
まず一つのサービスについて、確認が止まった項目を取り出してみてください。
- 接続先が分からない：仕様書とクラウド設定を照合する。
- 誰が管理しているか分からない：社内担当と委託先に、作業範囲を確認する。
- 止めてよいか分からない：利用者、利用周期、停止時の影響を確認する。
不明点を全部解消してから相談する必要はありません。どの項目で作業が止まったかを伝えれば、次に必要な確認を具体的に話せます。
バックアップや監視を含む運用全体の確認には、AWS運用で確認する5項目も参照してください。
公開API・クラウド環境の整理について相談する
「接続先の一覧を作れない」「旧環境の利用状況が分からない」「委託先との担当範囲を整理したい」といった場合は、現在の状況をお知らせください。
お問い合わせには、困っていること、現在の開発・運用体制、対応したい時期を分かる範囲でご記載ください。構成資料が揃っていなくても構いません。認証情報や顧客データの添付は不要です。
クラウド環境の調査、手順の整備、移行・運用支援について、対応可否・範囲・費用を個別に確認します。
参考資料
- OWASP API Security Top 10 2023：API1 Broken Object Level Authorization
- OWASP API Security Top 10 2023：API9 Improper Inventory Management
参考資料の確認日：2026年10月20日。棚卸しの手順、表、図は当社による作業例です。特定の顧客の構成や対応実績を示すものではありません。
