サプライチェーン攻撃とID保護：委託先・APIキーも含めた確認方法
背景と概要
業務委託先やクラウドサービスへ必要以上の権限が残っていると、どこか一つの認証情報が侵害された際に影響が広がります。会社の外か内かではなく、誰が何へ、どの条件でアクセスできるかを確認します。
人以外のIDも台帳へ
従業員アカウントだけでなく、APIキー、サービスアカウント、連携アプリ、共有メールボックスもIDとして扱います。所有者、用途、権限、有効期限、最終利用日、失効方法を記録します。
MFAだけに頼らない
MFAは重要ですが、偽サイトへ誘導するフィッシングなどに対して方式ごとの違いがあります。可能であればFIDO2やパスキーなどフィッシング耐性を考慮した方式を検討し、端末状態や接続場所も組み合わせます。
委託・連携開始時の確認
- 個人共有ではなく専用アカウントを発行する
- 契約業務に必要な権限だけを付与する
- 再委託先とデータ保存場所を確認する
- 契約終了時のアカウント停止日を決める
- 事故時の連絡先、ログ提供、報告期限を合意する
定期棚卸しを行う
異動、退職、契約終了、システム変更のたびに権限を見直します。長期間使われていないIDを停止し、強い権限は期限付きにします。
確認資料
実務で深掘りしたい確認点
委託先アカウント、APIキー、保守用VPN、共有管理者IDをひとまとまりの管理対象として捉えます。通常と異なる時間帯や接続元、契約範囲を超える操作、休眠IDの再利用を検知します。 単発の警告だけで判断せず、利用者・端末・時刻・変更履歴を関連付けると、通常業務との違いを説明しやすくなります。
発見時の初動と影響確認
委託先単位で接続を遮断し、鍵を更新し、契約先と共同でログと変更履歴を調査します。 復旧を急ぐ場合も、後から原因と影響範囲を説明できるよう、時刻、担当者、実施した操作、保全した証拠を残します。外部への通知や専門家への相談が必要かも、扱うデータと業務影響から判断します。
継続運用へ落とし込む方法
契約開始・更新・終了時に権限棚卸しを行い、責任分界と事故連絡時間を合意します。 導入時だけで終わらせず、例外件数、検知から対応までの時間、再発、利用者からの相談を定期的に確認します。訓練や実際の対応で見つかった手順の曖昧さを更新し、責任者不在時にも動ける状態を維持します。
契約と技術をつなぐ確認
委託先の安全対策を質問票だけで終わらせず、実際に発行したID、接続元、利用時間、保守作業の記録と照合します。再委託の有無、事故時に共有されるログ、認証情報を失効する責任者も契約時に決めます。緊急停止の連絡先が休日や夜間にも機能するか、共同訓練で確かめておくことが重要です。