Opinionニュース

Apify侵害でAPIトークンを更新。止まった自動処理を安全に戻す手順とは？

2026/11/13更新 2026/11/138分で読める

ウェブからデータを集める自動処理にApifyを使う企業は、APIトークンの更新だけで復旧を終えてよいのか。Apifyは2026年11月11日、内部システムへの不正アクセスを検知し、外部連携の一部を無効化した。翌12日には侵害された認証情報から一部アカウントへアクセスされたと公表した。[1]

影響を受けた利用者では、APIトークンやProxyのパスワードが変更され、二要素認証の再設定を求められた例もある。古い認証情報を使うデータ収集、AIエージェント、GitHub連携は止まる可能性がある。[2]

必要なのは、新しい鍵を配ることではなく、漏れた可能性のある鍵がどこで使われ、更新後にどの処理が動いたかを確認することだ。 復旧を急ぐほど、古いトークンの残存や過大な権限を見落としやすい。

侵入は11月9日と10日に起きた

Apifyのステータスページによると、不正な第三者は11月9日と10日、侵害された認証情報を使って同社の内部システムの一部へ入った。Apifyが活動を検知したのは11日12時13分（UTC）で、アクセス経路を閉じた後、同日以降に攻撃者の活動は検知していないという。12日17時16分（中央欧州時間）の更新では、個人情報または保存データへのアクセスを確認した顧客へ連絡したと説明した。[1]

ここで分けて読むべきなのは、Apify全利用者のデータが流出したという発表ではない点だ。同社は「影響を確認した顧客へ通知した」としており、通知を受けていないアカウントは、その時点で影響対象と特定されていない。調査は継続中で、最終的な範囲を示す事後報告もまだ出ていない。

BleepingComputerが確認した顧客通知では、影響を受けたアカウントのAPIトークンとApify Proxyのパスワードが変更された。別の通知では、二要素認証コードが露出した可能性がある利用者に再設定を案内した一方、パスワード自体は安全だと説明している。[2] 公開情報だけでは、影響した顧客数や認証情報の総数は確認できない。

トークン更新は業務停止として現れる

APIトークンは、人が毎回ログインしなくても外部プログラムからApifyを操作するための鍵である。社内のスクリプトだけでなく、MakeやZapierなどの自動化、AIエージェント、データ基盤、監視処理へ埋め込まれる。鍵が無効になると、不正利用を止められる一方、正規の処理も認証エラーで止まる。

たとえば、毎朝の競合価格を取得して表へ送る処理では、Apify側の実行が失敗するだけでなく、その後の集計や通知も動かない。エラーを握りつぶす設定なら、担当者は「更新対象がなかった」と誤認する。復旧確認ではApifyの実行履歴、呼び出し元のログ、出力先の更新時刻を一続きで見る必要がある。

青いランプが点灯するサーバー機器のイメージ — サーバー機器のイメージ。Apifyの設備や被害環境ではない。写真：panumas nikhomkhai / Pexels（Pexels License、トリミング・圧縮）

OAuth連携も接続し直す

Apifyは予防措置として、GitHubを含む外部サービスへのOAuth接続の一部を無効化した。調査では、これらの接続が侵入経路として使われた証拠は見つかっていないとしている。[1] それでも、GitHub上の非公開リポジトリからActorをビルドする運用では、接続を戻すまで更新や配布が止まる。

再接続の順番は、まずApifyから届いた通知の宛先と内容を確認し、次に公式コンソールを直接開く。メール内のリンクだけを頼りにしない。新しいトークンを発行したら、シークレット管理基盤やCI/CDの環境変数を更新し、旧トークンが無効であることを確かめる。その後にGitHubなどのOAuth接続を戻し、最小権限でテスト実行する。

二要素認証の再設定を案内された利用者は、復旧コードも更新する。複数人で一つの個人アカウントを共有しているなら、この機会に個人別のアカウントと権限へ分けるべきだ。誰がどの鍵を使ったか追えない運用では、次の事故時に影響範囲を絞れない。

復旧は三つの管理表で確かめる

企業側はトークン、処理、データの三つを対応づけると漏れを減らせる。トークン管理表には用途、保管先、権限、責任者、更新日を残す。処理管理表にはジョブ名、実行時刻、依存する外部サービス、失敗時の通知先を書く。データ管理表には取得元、保存先、保持期間、個人情報の有無を記録する。

Apifyのような自動化基盤は、一つの鍵が複数の処理へ広がりやすい。だから更新後の成功件数だけでなく、以前と同じ対象数、出力形式、更新間隔になっているかも比較する。認証エラーが消えても、権限不足で一部データだけ欠ける場合がある。

復旧の優先順位は処理の本数ではなく、停止した場合の影響で決める。顧客への通知、価格更新、在庫連携、請求判断に使う処理を先に戻し、試験用や個人の補助処理は後に回す。新しいトークンを全処理へ同時に配ると、どの変更で不具合が起きたか追いにくい。代表的な一件で取得から保存まで通し、監視が反応することを確かめてから対象を広げる。

管理表にない処理も探す必要がある。担当者の端末、共有スプレッドシート、退職者が作った自動化、検証環境に旧トークンが残ると、復旧後も認証エラーが続く。ソースコードだけでなく、CI/CD、シークレット保管庫、SaaS連携設定を横断して検索し、見つかった場所を管理表へ戻す。鍵の更新は運用の所有者を確定する作業でもある。

さらに、11月9日から遮断までの期間について、アカウントの実行履歴、トークン利用、設定変更、外部への転送先を確認する。Apifyが後日公開するとしている事後報告で対象や推奨対応が変われば、調査範囲も更新する。[1] 「通知がない」ことは現時点の判断材料だが、調査終了の証明ではない。

委託先の鍵も自社の復旧計画に入れる

今回の出来事は、SaaSの障害と情報セキュリティ対応が同時に起きる例である。外部事業者が鍵を失効させれば、利用企業の業務は止まる。失効させなければ、不正利用の時間を延ばす。どちらを選んでも影響が出るため、利用企業は平時から交換手順を持つ必要がある。

契約やセキュリティ質問票では、暗号化や認証方式だけでなく、緊急失効時の連絡先、監査ログの保持期間、顧客別通知の方法、復旧後に提供される情報を確認する。自社側ではトークンをコードへ直書きせず、期限と所有者を持つシークレットとして管理する。交換テストを年に一度でも行えば、鍵の所在が不明な処理を見つけられる。

Apifyは調査継続中であり、公開情報は更新されうる。現時点で確定しているのは、不正アクセスの期間、検知時刻、侵害された認証情報から関連アカウントへ入られたこと、一部OAuth接続と内部秘密情報を失効・更新したことだ。[1] 顧客ごとの影響は通知内容に従って判断し、一般報道の例を自社へ一律に当てはめないことが重要である。