目次
ある日、利用していたサービス事業者から「サプライチェーン攻撃を受けた」という公表がありました。自社が攻撃されたわけではありません。それでも、その事業者を経由して発行・保管していたAPIキーやトークンがある以上、受託側としては動かないという選択肢がありません。
このとき私たちが1日で実施したのが、関連するキーとトークンの全件ローテーションです。作業自体は地味ですが、やってみると「事前の備え次第で、かかる時間が何倍も変わる」ことがはっきり分かりました。
この記事では、実際の対応手順を時系列で整理し、あわせて「切っても業務が止まらないキー体系」と、事前に用意しておく棚卸し表の項目を紹介します。
この記事の結論
- 対応の順序は、ログ確認 → 洗い出し → 全件ローテーション
- 認証用と連携用を分けないと、差し替えで利用者が落ちる
- 棚卸し表があれば、洗い出しの時間はほぼゼロになる
APIキーのローテーションとは
APIキーは、システム同士をつなぐときの「合鍵」です。ローテーションとは、その合鍵を新しいものに作り替え、古い鍵を無効にする作業を指します。
重要なのは、自社が侵害されていなくても実施する場面があるという点です。鍵の管理を委ねていた先が攻撃を受けたなら、その鍵は「漏れたかもしれない鍵」として扱うのが原則です。漏れた証拠を探してから動くのでは遅く、証拠がない段階で切り替えるのが正解になります。
インシデント発生時の対応手順
実際に踏んだ5ステップです。
1. 影響範囲の確認（アクセスログ）
まず、自社の環境と、お預かりしている環境のアクセスログを確認します。見るのは、公表された時期の前後に不審なアクセスや設定変更がないか、見覚えのないIPや時間帯の操作がないか。ここで「何も起きていない」ことを確認できても、作業をやめる理由にはなりません。あくまで被害の有無を切り分けるための工程であり、次のステップと並行して進めます。
2. 対象キーとトークンの洗い出し
当該事業者を経由して発行、または保管していたキーとトークンを全件リストアップします。ここが一番時間を食う工程です。「どこに、いくつ、何のために置いたか」が頭の中にしかないと、この段階で半日が消えます。後述する棚卸し表があれば、この工程はリストを開くだけで終わります。
3. 全件ローテーション
洗い出したキーを、例外なく作り替えます。「これは使っていないから後で」と残すと、結局それが残り続けます。疑わしいものは全部切るのが、判断コストを下げる意味でも正しい進め方です。
4. 再表示できない設定と2要素認証の確認
差し替えた新しい値は、管理画面上で後から値を再表示できない設定（いわゆるSensitive扱い）に切り替えました。値を画面で確認できる状態は、それ自体が漏えい経路になります。あわせて、管理者アカウントの2要素認証が有効かどうかも確認します。鍵を替えても、管理画面に入られたら意味がありません。なお、こうした設定名や挙動は各サービスで異なり、仕様も変わるため、最新の内容は公式ドキュメントで確認してください。
5. 顧客への状況報告
最後に、お預かりしている環境について、何が起きて、何を実施し、影響があったかどうかを報告します。ここを省くと、後から別ルートで公表を知った顧客に不安だけが残ります。「対応済みである」という事実を先に届けるのが、信頼を落とさない唯一の方法です。
ローテーションで業務が止まる原因と対策
今回、作業して一番の学びになったのがここです。
キーの持ち方によっては、差し替えた瞬間にログインセッションが切れ、利用者が全員ログアウトされます。復旧作業のつもりが、現場から「ログインできなくなった」という連絡が飛んでくる状態になりかねません。
原因はシンプルで、認証（誰がログインしているか）と連携（システム同士のつなぎ込み）で同じ鍵を共有している設計にあります。
| キーの持ち方 | ローテーション時の影響 | 復旧の速さ |
|---|---|---|
| 認証用と連携用が同じ | 利用者が全員ログアウト | 遅い（再ログイン案内が必要） |
| 認証用と連携用を分離 | 連携が一時停止するのみ | 速い |
| 用途ごとに細かく発行 | 影響が該当機能だけに限定 | 最も速い |
つまり、平時の設計が、有事の復旧速度をそのまま決めます。切っても業務が止まらないキー体系にしておけば、インシデント対応は「切って作り直すだけ」の単純作業になります。逆に、1本のキーに全部の役割を持たせていると、切る決断そのものに時間がかかり、対応が後手に回ります。
用途ごとに鍵を分けるのは、作るときは少しだけ面倒です。ですがその面倒は、有事に「迷わず切れる」という形で返ってきます。
事前に用意しておく棚卸し表の項目
今回の対応で効いたのは、技術力よりリストがあるかどうかでした。次の項目を1行にまとめた表を、平時のうちに作っておくことをおすすめします。
| 項目 | 書く内容 |
|---|---|
| キー名 | 識別できる名前 |
| 発行元サービス | どのサービスで発行したか |
| 用途 | 何と何をつないでいるか |
| 保管場所 | どこに値を置いているか |
| 影響範囲 | 切ったとき止まる業務 |
| 再発行手順 | どの画面から作り直すか |
| 担当者 | 誰が作業できるか |
このうち特に効くのが影響範囲と再発行手順の2列です。インシデント時に判断を止めるのは、「これを切ったら何が起きるか分からない」という不安だからです。そこが表に書いてあれば、あとは上から順に作業するだけになります。
スプレッドシート1枚で十分です。新しい連携を作ったときに1行足す、という運用さえ回れば、有事の初動が数時間単位で変わります。
平時にやっておく3つのこと
- 棚卸し表を作る：まず現状のキーを全部書き出す。ここで「用途不明のキー」が見つかったら、その時点で消します。
- 用途ごとにキーを分ける：認証用と連携用は必ず分離します。切っても業務が止まらない状態が目標です。
- 値を再表示できなくする：管理画面で値が見える状態を減らします。設定名はサービスごとに異なるため、公式の案内を確認してください。
よくある質問
Q. 取引先でセキュリティインシデントが公表されたら、まず何をすべきですか？ 最初はログの確認です。自社と預かり環境のアクセスログを見て不審な操作がないかを確かめつつ、当該事業者を経由して発行・保管していたキーとトークンの洗い出しを同時に始めます。差し替えはその後です。
Q. APIキーをローテーションすると業務が止まることはありますか？ あります。ログインセッションの維持にそのキーを使っている設計だと、差し替えた瞬間に利用者がログアウトされます。認証用と連携用を分け、切っても業務が止まらない体系にしておくと復旧が速くなります。
Q. キーの棚卸し表には何を書いておけばよいですか？ キー名、発行元サービス、用途、保管場所、影響範囲、再発行手順、担当者を1行で持ちます。インシデント時はこの表がそのまま作業リストになり、洗い出しにかかる時間をほぼゼロにできます。
まとめ
- 自社が攻撃されていなくても、委ねていた鍵は漏れた前提で切り替える
- 手順は、ログ確認 → 洗い出し → 全件ローテーション → 権限確認 → 顧客報告
- 認証用と連携用が同じキーだと、差し替えで利用者がログアウトする
- 有事の速さを決めるのは技術力ではなく、平時の棚卸し表とキー設計
RENOYでは、システム連携の設計段階から「有事に切れるキー体系」を前提に組み立てています。「いま自社にどんなキーがあるか把握できていない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。