>
>
公開日
APIキー漏洩は、自社の設定ミスだけでなく、認証情報を預けた開発基盤や連携先の侵害でも起こります。Railway・Northflankなどの公表内容を基に、情シスが確認する対象、キーの失効・交換の優先順位、利用量と請求ログの確認、預け先台帳の項目、開発部門が使うSaaSの洗い出し方を解説します。
APIキー漏洩とは
APIキー漏洩とはサービスへのアクセスに使う認証情報が第三者に渡ることです。
本記事のポイント
預け先の侵害でもキーは漏洩します。
交換対象は預け先と発行元を対応させて整理します。
交換担当者と停止影響を台帳に記録します。
情報の基準日は2026年11月9日です。
対象は、開発部門が利用するクラウドの開発基盤やAI系SaaSと、そこに預けた認証情報を把握しきれていない企業の情シス担当者・管理者です。APIキーは、秘密に扱う情報の総称である「シークレット」の一種です。環境変数はプログラムに設定値を渡す仕組みで、APIキーを設定する場合もあります。環境変数の漏洩は、その値に含まれるキーの流出にもつながります。APIキー管理では、コードへの誤記載だけでなく、預け先と保持情報の対応も扱います。
漏洩の原因は、自社の操作ミスに限りません。2026年10月には、利用企業が環境変数を預けていた開発基盤のRailwayとNorthflankが相次いで侵害され、両社とも利用者に秘密情報の交換を求めました。預け先に認証情報を保存しているなら、そのサービスの侵害も対応対象に含めます。
2026年10月の開発基盤侵害と連携先経由の漏洩
2026年10月に発生・認知された4件を、11月9日時点の公表内容で整理します。利用企業が預けた環境変数・秘密情報が対象になったのはRailwayとNorthflankです。WorkOSは社内ツールの認証情報の扱いが原因で、営業・サポート情報が対象になりました。Who Gives A Crapは連携先ベンダー経由で顧客情報にアクセスされた事案です。時刻の記載がない日付は、発表どおりに載せています。
発表主体・出典 | 発生／認知／公表日時 | 影響対象 | 案内・実施された対応 |
|---|---|---|---|
Railway | 攻撃期間は10月20日13:58〜10月22日03:32 UTCです。日本時間では10月20日22:58〜10月22日12:32です。 | 同社は、環境変数が漏れた可能性があるのは最大で全ワークスペースの1.85％、約10万ワークスペースで、ユーザーアカウントへのアクセスはなかったとしています。 | 10月21日より前に登録したすべての利用者に、Railwayに保存したキーの交換を推奨しています。同社は、攻撃者の狙いをAIプロバイダのAPIキーだったと説明しています。 |
Northflank | 同社は、10月30日11:43 UTC／日本時間20:43にWizのアラートで認知したと説明しています。11月6日更新では、最初の復号を10月30日02:39〜03:08 UTC／11:39〜12:08と説明しています。 | 同社は、基盤を管理するコントロールプレーンの秘密情報が対象で、稼働中のワークロード、つまり実行中のアプリケーションなどには影響がないと説明しています。 | 10月30日13:58 UTC／日本時間22:58に、すべての環境変数が復号されたと想定し、すべてのキーを無効化・交換するよう案内しました。同じ日の更新で、複数の利用者からAIキーが使われたとの報告があったと書いています。 |
WorkOS | 初回アクセスは10月25日、検知は10月30日です。原因の説明は11月6日の更新で公表されました。 | 同社は、研究者のAIセキュリティエージェントがテスト環境を抜け、未移行だった旧基盤の社内ツールへアクセスし、営業・サポートシステムに保持されたデータが対象になったと説明しています。 | 原因として、APIの公開、本番に残ったローカル開発用の弱い認証情報、レート制限の欠如、検知の遅れの4点を挙げています。接続していた全サービスの認証情報を失効・交換したとしています。 |
Who Gives A Crap | 同報道では、アクセス開始は10月30日、検知は10月31日、遮断は11月1日です。 | ABC Newsは、米国のマーケティングSaaSベンダー経由で、氏名・メールアドレス・電話番号・住所・累計購入額にアクセスされたと報じています。決済情報とパスワードは含まれないとされ、ベンダー名は非公表です。 | 同社はベンダーとの接続を完全に切り、アクセス用の認証情報を変更したと報じられています。 |
Northflankの侵入経路・根本原因は、11月6日の更新時点で公表されていません。同社が影響なしとしているのは稼働中のワークロードで、コントロールプレーンに保存された秘密情報については交換を求めています。
利用企業が公表内容を読む際は、次の順で整理すると、確認済みの影響と予防的な交換案内を混同せずに済みます。
預けた情報が環境変数・認証情報なのか、営業・サポート情報や顧客情報なのかを分けます。
漏洩・復号が確認された範囲と、安全側に広く想定した交換対象を分けます。
自社が交換案内の対象なら対応対象に含め、対象と判断できなければ「影響なし」とせず未確定として管理します。
この区別を残したうえで、預け先ごとに自社の秘密情報と交換対象を照合します。
預け先の侵害によるAPIキーの不正利用リスク
預け先から取得された有効なAPIキーは、自社アカウントへのログインとは別に不正利用される可能性があります。
アカウントへのアクセスと秘密情報へのアクセスの違い
ユーザーアカウント、稼働中のアプリ、預けた認証情報は、別々に安全性を判断する対象です。自社で公開操作をしていないことや、アプリが正常に動いていることだけでは、APIキーの漏洩を否定できません。
Northflankは、狙われたのはコントロールプレーンに保持していた秘密情報で、稼働中のワークロードには影響がなかったと説明しています。アプリが動き続けていることは、預けた秘密情報が無事だった根拠になりません。
アカウントは、不審なログインや権限変更の有無で点検します。
稼働中のアプリは、停止や改変の有無で点検します。
預けた認証情報は、取得された可能性と交換対象の範囲で判断します。
暗号化された環境変数の復号
保存時の暗号化だけを理由に、秘密情報の交換を不要と判断しないようにします。環境変数はアプリの設定値を渡す仕組みで、APIキーなどの秘密情報を含む場合があります。
Railwayは、攻撃者が暗号化された秘密情報を取得し、CI環境の認証情報を使ってその一部を復号したと説明しています（Railwayの予備報告）。CircleCIも2023年1月のインシデント報告で、保存データは暗号化していたものの、攻撃者が実行中のプロセスから暗号化キーを取り出し、暗号化データにアクセスできた可能性があると説明しています（CircleCIのインシデント報告）。暗号化の有無だけでなく、復号に使う情報まで侵害されたかが判断を左右します。
AIキーの利用量と請求への影響
Northflankは、利用者がNorthflankに預けたAIのAPIキーが不正に使われたとの報告を受けたとしています。そのうえで、AIプロバイダの利用量と請求のログを確認し、不審な利用があれば同社と各プロバイダに報告するよう求めました。従量課金のAIプロバイダのキーを預けていた場合は、交換対象の特定と並行して、利用量・請求ログを確認します。
Northflankは11月2日の更新で、疑わしい利用が見つかっていなくても、すべての秘密情報を交換するよう求めています。「使われた証拠がない」と「取得されていない」は別の判断です。
攻撃分類の詳細はサプライチェーン攻撃、AIツール全般の管理策はClaude Code 企業利用の統制ガイドで整理しています。
開発基盤の侵害連絡後に行う点検とキー交換
侵害連絡を受けた場合は、悪用の兆候の有無にかかわらず、対象の秘密情報を発行元で失効させ、再発行と預け先への再設定を進めます（侵害連絡を伴わない定期ローテーションなら、新キーの反映と動作確認を終えてから旧キーを失効させる順序も取れます）。発行元での失効と、預け先での設定変更は別の作業です。預け先から値を削除するだけで対応を終えず、発行元で旧認証情報を無効にしたことまで確認します。
通知を受けた直後（最初の1時間〜当日中）の初動
通知メールやステータスページの原文を、受信日時・URLとあわせて保存します。後から対象期間や案内内容が更新されても、受領時点の記載を比較できるようにするためです。
通知に書かれた対象の組織・環境・期間を、自社の利用アカウントと突き合わせます。
各発行元の失効権限を持つ管理者と、預け先の設定変更ができる担当者を招集します。
預け先と発行元の監査ログの保持期間を各サービスの管理画面で調べます。期間が短ければ、ログが消える前に延長またはエクスポートします。
ベンダーには、対象の秘密情報の範囲、復号の有無、交換の期限、侵害期間中のログの提供可否を問い合わせます。
交換対象ごとの優先順位と担当欄
Northflankは11月2日の更新で、交換を始める順番としてAIプロバイダのキー、クラウドの認証情報、決済サービスのキー、秘密鍵を挙げ、データベースや他サービスの認証情報も含めるよう求めています。この順で対象を整理し、情シスを進行管理役、発行権限を持つ管理者を失効・再発行役、預け先の管理者を再設定役に割り当てます。表の担当者欄は役割の案であり、着手時に実際の担当者名へ置き換えます。
交換順・対象 | 発行元 | 預け先 | 交換担当者の案 | 停止影響の確認欄 |
|---|---|---|---|---|
1：AIプロバイダのキー | 利用中のAIプロバイダ | 対象基盤・連携アプリ | 発行元の管理者／アプリ担当者 | □ AI機能・処理の停止範囲 |
2：クラウドの認証情報 | 利用中のクラウド | 対象基盤・自動処理の設定先 | クラウド管理者／基盤担当者 | □ 配備・運用処理への影響 |
3：決済サービスのキー | 利用中の決済サービス | 対象基盤・決済連携アプリ | 決済管理者／サービス担当者 | □ 決済受付・関連処理の停止 |
4：秘密鍵 | 鍵を生成・管理する主体 | 対象基盤・鍵の利用先 | 鍵管理者／接続先の担当者 | □ 接続・署名処理への影響 |
追加点検：DB・その他 | DB・各サービスの管理主体 | 対象基盤・各連携先 | DB管理者／各サービス担当者 | □ 読み書き・連携処理の停止 |
管理者権限を持つキー、本番環境で使うキー、高額な従量課金が発生するキー、外部に公開された接続で使うキー、他の環境へ横展開できるキーは、表の順位にかかわらず先に交換します。対象外と判断する場合も、通知の対象範囲と照合した根拠を記録します。
旧認証情報の失効から切り替え完了までの手順
APIキーのローテーション、つまり旧キーを新キーへ交換する作業は、接続成功だけで完了にしません。シークレットのローテーションも同様に、パスワードや秘密鍵を含めて、旧認証情報が使えない状態まで確認します。
通知内容と対象環境の特定：通知に記載された対象期間・環境・秘密情報を整理します。停止が見込まれる場合は、この段階で情シスがサービス担当者と代替運用または利用停止を調整します。
発行元で旧キーを失効：発行権限を持つ管理者が実施し、実施時刻と対象の識別情報を記録します。秘密鍵など、失効方法が異なるものは、信頼先からの除外を含め旧認証情報を受け付けない状態にします。
新キーの作成：発行元の管理者が、利用目的に必要な権限で新認証情報を作成します。作業記録には秘密情報の値そのものを残しません。
各預け先への再設定：各担当者が対象環境の設定を更新します。同じ認証情報を複数の接続先で使っていた場合は、再設定済み・未設定を分けて管理します。
接続確認と旧キーの失効状態の確認：サービス担当者が新認証情報による処理を確認し、発行元の管理者が旧認証情報の失効状態を確認します。接続できなければ新設定や権限を調査し、漏洩疑いのある旧キーには戻しません。
Northflankも、発行元で既存の認証情報を失効させてから新しい認証情報を作るよう案内しています。失効で処理が止まる場合は、旧キーを残さず、止まる業務と再開の条件をサービス担当者が決めます。
発行元の管理画面で共通して見る項目
□ キー一覧の識別子・作成日・最終使用日時（表示される場合）：台帳の管理用識別子と対応しないキーがあれば、調査対象として台帳に追加します。
□ キーの権限範囲：管理者権限や本番環境への書き込み権限を持つキーがないかを確認し、あれば先に交換します。
□ 監査ログ・アクセスログ：通知の対象期間に見覚えのないIPアドレスや操作があれば、関連キーの利用調査へ進めます。
□ 利用量・請求の画面：通常時より利用量が増えていれば、記録を保存して発行元と社内担当へ連携します。
□ 失効後のキーの状態：旧キーが「無効」「削除済み」と表示されることを確認し、有効のままなら再度失効させます。
利用状況・公開接続とRailway利用環境の追加点検
Northflankは、アドオンの公開アクセスを止めることと、使えるところではIP制限と予算上限を設定することも求めています。対応機能がないサービスでは、当該接続の停止や利用範囲の縮小を検討します。予算上限は被害額を抑える手段で、不正利用そのものは防げません。
Railwayは、キーの交換に加えて次の確認を推奨しています（Railwayの予備報告）。
機密性の高い環境変数を失効させ、設定し直します。
データベースへの公開ネットワークアクセスを削除します。
GitHubの監査ログと、GitHubで許可しているすべてのアプリのアクセスを確認します。
Docker Hubなど、利用中のコンテナレジストリの監査ログを確認します。
▲ 侵害連絡を受けた際の対象環境特定から預け先への再設定までの作業手順です。
未利用の会社にも必要な預け先とキーの台帳
預け先とキーの台帳は、自社がどのAPIキーをどのサービスに預けているかを一覧にし、侵害されたサービス名から交換対象と担当者を特定するための記録です。紹介した開発基盤を使っていない会社でも、外部サービスに認証情報を預けている場合は、発行元と預け先の関係を整理するために使えます。
対象サービスの利用が判明している場合は、そのサービスに預けたキーの記入から始めます。利用サービス自体が不明な場合は、次章の利用者・利用部門の洗い出しから着手し、判明したサービスを台帳に追加します。
キーの発行元と預け先は分けて記録します。発行元は認証情報を発行・失効する側、預け先はその認証情報を保存・利用する側です。同じキーを複数のサービスで使っている場合は、共通の管理用識別子で結び付け、サービス名から交換先を逆引きできる形にします。
以下は転記して使える空欄のテンプレートです。預け先が複数ある場合は、同じ識別子で預け先ごとに記録を追加します。
項目 | 記入欄 |
|---|---|
管理用識別子 | |
キーの種類 | |
発行元 | |
預け先のサービス | |
管理者 | |
用途 | |
利用環境・開発／本番の区分 | |
移行前サービス・旧基盤の残存 | |
最終交換日 | |
交換担当者 | |
交換手順 | |
止めたときの影響 | |
接続停止・発行元での失効の実施記録 |
APIキーや秘密鍵の値そのものは台帳に貼り付けません。管理用識別子で秘密情報の保管先と照合する運用にします。台帳を共有する必要がある場合も、秘密情報まで同時に配布しないための区別です。停止影響には、止まる処理や業務、連絡する部門を記入します。
WorkOSは今回の原因として、社内ツールのAPIが公開されていたこと、ローカル開発用の弱い認証情報が本番に展開されていたこと、レート制限がなかったこと、初回アクセスから検知まで5日かかったことを挙げています。ツールは移行前の旧基盤に残っていました（WorkOSの更新）。台帳を作るときは、同じ点も確認します。開発用の認証情報が本番で使われていないか、公開されたAPIに認証とレート制限があるか、移行前の基盤にツールや接続が残っていないかを、台帳の点検欄に記録します。
台帳を作成する場合は、次の順で記入と照合を進めます。
サービス担当者が既存キーの種類、用途、管理者を記入します。担当者不明の場合は、利用部門の管理者が引き継ぎ先を割り当てます。
発行元の管理画面などと管理用識別子を照合します。対応関係を特定できないキーは、調査対象として残します。
複数の預け先と開発・本番の利用環境を追記します。移行済みでも旧サービスとの接続が残っていれば記録します。
交換担当者と手順、停止影響を確定します。最終交換日が分からない場合は「不明」と記録し、交換対象から除外しません。
ITmediaは、トヨタモビリティサービスについて、過去の別プロダクト用のAWSアクセスキーの無効化や消去を怠り、2024年2月に不正アクセスとデータ削除が判明したと報じています（出典：過去のアクセスキーの管理不備に関する報道）。
使わなくなったサービスや旧基盤がある場合は、台帳の行を削除して完了とせず、接続停止と発行元での失効をそれぞれ記録します。詳細はSaaS解約後の後始末を参照できます。利用先がまだ分からない場合は、次章で利用部門と管理者を洗い出し、台帳の記入先を確定します。
APIキー交換で避けたい失敗パターン
キー交換では、新しい値の設定だけでなく、旧キーの失効と全預け先への反映を完了条件にします。APIキー漏洩への対応は、設定変更の有無ではなく、不正利用できる状態が残っていないかで完了を判断します。
交換作業で起きやすい誤判断と、その直し方を整理します。
失敗パターン | 残るリスク | 修正行動 |
|---|---|---|
預け先の環境変数だけを書き換える | 発行元で旧キーが有効なまま残り、不正利用を封じ込められません。 | 設定変更だけで完了としていた場合は、発行元で旧キーの失効まで管理します。 |
疑わしい利用がないため交換を見送る | 利用の痕跡がないことを、漏洩していない証拠として扱ってしまいます。 | 漏洩が疑われるなら、利用調査と交換判断を切り離し、旧キーを失効対象にします。 |
アプリが動いているため影響なしと判断する | 稼働確認だけでは、旧キーの残存や一部接続の再設定漏れを判別できません。 | 稼働中でも、預け先ごとの反映状況と旧キーの失効状況を別々に判定します。 |
交換担当者や停止影響を決めずに作業する | 対応漏れや停止時の復旧判断を引き受ける担当者が不在になります。 | 担当が未定なら、交換担当者と停止影響の判断者を割り当て、未完了項目を引き継ぎます。 |
旧基盤と使われなくなった接続を台帳から外す | 利用終了を失効完了と取り違え、残存接続を追えなくなります。 | 失効の記録がなければ台帳に残し、残存接続の失効確認まで担当者を付けます。 |
緊急失効にはサービス停止が伴う場合があり、預け先が複数なら再設定漏れも起こり得ます。停止が見込まれる場合は復旧担当と影響業務を管理し、漏洩疑いのある旧キーを残して停止を避ける判断はしません。停止影響と不正利用の封じ込めを別々の管理項目にすれば、アプリの復旧だけで対応を閉じる誤りを防げます。
▲ 預け先の設定変更にとどまらず発行元での失効と無効化を確認する完了判断フローです。
開発基盤・AI系SaaSの利用部門と管理者の把握
預け先が分からない場合は、開発基盤・AI系SaaSの利用部門と利用者を洗い出し、キー台帳の担当者につなげます。
APIキー漏洩への備えでは、SaaSの利用実態と認証情報を別の管理対象として扱います。利用サービスが分かっても、預けたキーや交換担当者まで確定したとは限りません。部門への照会と会社アカウントによる利用情報を組み合わせ、サービスの発見から担当者の特定へ進めます。
まず開発部門へ利用中の開発基盤・AI系SaaSと業務用途を照会し、会社アカウントの利用情報と照合します。退職者や委託先にひも付くアカウントも、この時点で確認します。
用途と管理者を特定できたサービスは、キー台帳に登録します。キーを預けているかは、利用実績だけで判断せず、管理者から確認します。
用途や管理者が不明なサービスは、判明している利用者に照会します。担当が決まらない間は未確認として残し、部門責任者につないで管理者と交換担当者を確定します。
利用情報を起点に調べる方法はシャドーITの発見方法、管理権限を持つ担当者の整理は特権ID管理も参考になります。
SaaSの把握手段には、IdPのログインログで利用アプリと利用者を確認する方法（SSOを経由しない利用は拾えません）、CASBで通信先のサービスを把握する方法、SSPMで連携アプリと設定を確認する方法、経費精算の支払い履歴から有償サービスを抽出する方法があります。Adminaは、Google WorkspaceやMicrosoft 365／Entra IDと連携すると、社員が会社アカウントのGoogleログイン・Microsoftログインで使っているSaaSを検知し、サービスごとの利用者と最終アクセスを一覧で確認できます（Microsoft側はEntra ID P1／P2が必要）。開発基盤やAI系SaaSの利用部門・利用者を洗い出す起点に使えます。
管理対象 | 把握・作業する場所 | 実施内容 |
|---|---|---|
SaaSの利用実態 | Admina | 検知したサービスの利用者を確認し、部門への照会先を絞ります。 |
APIキーと設定内容 | 各サービス・発行元の管理画面 | APIキーや環境変数を点検し、対象キーの失効・再発行と利用先の再設定を担当者が進めます。 |
SaaSの検知を、キー交換の完了と取り違えないようにします。利用把握の画面を検討する場合の案内はAdminaのデモです。
退職者・委託先のアカウントに業務依存が残っている場合は、管理者と交換担当者を引き継ぎ、継続利用できる管理体制へ移します。不要な場合は、サービス側のアクセス停止と関連キーの失効を進めます。アカウント削除だけで対応を終えず、キーの失効状況も発行元で確かめます。
ログインとOAuth認可の違いはSAMLとOAuthの違い、OAuth連携アプリとベンダー資格情報の詳細はサードパーティ製アプリの権限棚卸しで整理します。ここで特定した利用者・管理者を、台帳上の交換担当者につなげます。
▲ SaaSの利用実態把握とAPIキー設定点検における確認場所と作業内容の比較です。
まとめ
APIキー漏洩は、自社の公開ミスだけでなく、キーを預けた外部サービスの侵害からも起こり得ます。侵害通知を受けたら、発行元と預け先を対応させ、どのキーを失効・交換するかを絞り込みます。利用部門と管理者も特定し、交換担当者とともに台帳へ記録します。
明日からの第一歩は、利用が判明している開発基盤・AI系SaaSを一つ選ぶことです。そのサービスに預けたキーについて、発行元・預け先・交換担当者・停止影響を台帳に記入し、誰が何を交換するかを明確にします。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
