パッチ延期、SaaS権限、認証例外を期限付きで扱うためのセキュリティ例外申請テンプレート。理由、暫定策、承認者、再評価条件の残し方を整理する。
セキュリティ例外申請は「許可証」ではなく残リスクの記録
パッチをすぐ当てられない。古いSaaS連携を一時的に残したい。共有端末だけパスキーをまだ使えない。こうした例外は、現場では必ず発生する。問題は、例外が存在することではなく、理由、期限、暫定対策、承認者が曖昧なまま残り続けることだ。
セキュリティ例外申請は「このリスクを見なかったことにする書類」ではない。今すぐ標準ルールを満たせない理由を明確にし、残るリスクを誰がいつまで引き受けるのかを記録するための運用である。変更管理やリスク管理の台帳に残して、後から判断根拠を追える状態にする。
この記事では、情シス、CSIRT、開発組織の担当者向けに、パッチ延期、SaaS権限、認証方式、外部共有の例外をどう申請・承認・再評価するかを整理する。CVE対応の初動では CVE初動対応チェックリスト と、SaaS権限の確認では SaaS権限棚卸しチェックリスト と併用してほしい。MFA除外、場所例外、端末条件のようなIdPポリシー例外は、条件付きアクセス例外の棚卸しで確認順序を分けて整理している。
この記事は、防御・運用改善を目的にした例外管理の考え方を扱う。法務判断、契約上の通知義務、顧客報告の要否は、社内規程や専門部署の判断を優先する。
例外申請に必ず残す7項目
例外申請で一番避けたいのは、「業務都合のため」「影響が大きいため」のような一文だけで終わることだ。それでは、後から見直す人が何を判断すればよいか分からない。
最低限、次の7項目を1つのチケットや申請フォームに残す。
| 項目 | 書くこと | 書かないと起きること |
|---|---|---|
| 対象 | システム名、SaaS名、資産ID、対象ユーザー、対象バージョン | どこに例外が残っているか追跡できない |
| 標準ルール | 本来満たすべき設定、パッチ、認証方式、権限基準 | 何から外れているのか説明できない |
| 例外理由 | 今すぐ標準化できない理由と制約 | 「忙しいから」のような曖昧な保留になる |
| 残るリスク | 漏えい、権限濫用、停止、横展開などの影響 | 承認者が何を受け入れたか不明になる |
| 暫定対策 | 監視、送信元制限、権限縮小、WAF、手動レビューなど | 期限まで無防備な状態が続く |
| 期限 | 終了日、再評価日、次の判断条件 | 例外が恒久化する |
| 承認者 | リスクを受け入れる責任者、実施担当、再確認担当 | 事故時に責任と判断根拠を追えない |
ここでの承認者は、単なるシステム管理者とは限らない。業務停止の判断が必要なら事業責任者、顧客影響があるなら法務や広報、重大脆弱性ならインシデント責任者を巻き込む。セキュリティ担当だけで「受け入れた」ことにしない。
期限は日付だけでなく再評価条件まで決める
例外の期限は「2026年6月末まで」のような日付だけでは弱い。状況が変わったときに前倒しで見直せる条件も必要だ。
たとえば、パッチ延期の例外なら次のように書く。
| 再評価条件 | 見直す理由 |
|---|---|
| CISA KEVに追加された | 悪用確認済みとして優先度を上げる必要がある |
| ベンダーが追加アドバイザリを出した | 影響範囲や回避策が変わる可能性がある |
| 対象資産がインターネット公開になった | 攻撃者から到達可能になる |
| 代替システムの準備が完了した | 例外を終了できる可能性がある |
| 監視で不審な挙動を検知した | 例外継続ではなく初動対応へ切り替える |
SSVC の考え方を使う場合も同じだ。TrackやAttendで置いた判断が、KEV掲載、外部公開、悪用情報、資産発見によってAct相当へ変わることがある。詳しくは SSVCとは ─ 脆弱性対応をTrack/Attend/Actで決める方法 で整理している。
期限がない例外は、実質的には管理されていない残リスクになる。業務上どうしても長期化する場合も、少なくとも四半期ごとの再確認日と所有者を設定する。
パッチ延期の例外は「当てない理由」より「何で下げるか」を書く
脆弱性対応でよくある例外は、すぐにパッチを適用できないケースだ。検証環境がない、ベンダーが未対応、業務停止時間が取れない、古い依存関係が壊れる、といった理由は現実にある。
ただし、申請書に「パッチ適用は業務影響が大きいため延期」とだけ書いても、リスクは下がらない。必要なのは、延期期間中に何でリスクを下げるかだ。
| 状況 | 例外中に検討する暫定対策 |
|---|---|
| 外部公開された管理画面 | VPN限定、送信元制限、管理画面停止、追加認証 |
| Webアプリの既知脆弱性 | WAFルール、該当機能の停止、ログ監視、入力制限 |
| エージェントや管理ツール | 対象端末の限定、管理APIの制限、監査ログ確認 |
| サードパーティ依存 | 影響機能の切り離し、代替ライブラリ検証、SBOM更新 |
| パッチ適用待ち | ベンダー公式更新の監視、変更枠の予約、ロールバック準備 |
この判断では、KEV、EPSS、CVSS を別々の材料として見る。KEV入りしている、外部公開資産に該当する、認証基盤に近い、という条件が重なるなら、単なる延期ではなく緊急変更として扱う理由がある。
SaaS・認証例外は「便利だから」で残さない
SaaSや認証方式の例外は、最初は小さく見える。特定部署だけSSO対象外、共有端末だけMFA例外、委託先だけ外部ゲスト権限、古いOAuthアプリだけ管理者同意済み、といった形だ。
しかし、こうした例外は攻撃者にとって「標準ルールを迂回する入口」になりやすい。SaaS権限棚卸しの進め方 でも触れた通り、ユーザー一覧だけではOAuthアプリ、外部共有、APIトークン、Webhookを見落とす。
申請時には、次の観点を必ず分ける。
| 例外の種類 | 見るべきこと |
|---|---|
| SSO対象外 | 対象ユーザー、理由、代替MFA、ログ取得、終了条件 |
| MFA例外 | 端末、場所、対象アプリ、上長承認、短期期限 |
| OAuth同意 | 発行者、要求スコープ、利用者数、管理者承認、最終利用 |
| 外部共有 | 共有先、データ分類、有効期限、再共有可否、監査ログ |
| 管理者権限 | 付与理由、作業時間、JIT化可否、PAM対象、操作記録 |
パスキーやゼロトラスト導入でも同じだ。強い認証方式を入れても、復旧導線や例外アカウントが弱いままなら、攻撃者はそこを狙う。パスキー導入で失敗しやすい落とし穴 と 条件付きアクセス例外の棚卸し も合わせて確認してほしい。
申請テンプレート：判断できる粒度で書く
実務では、以下の形でチケット化すると扱いやすい。長い説明文より、判断項目が揃っていることが重要だ。
| 欄 | 記入例 |
|---|---|
| 件名 | GitHub管理者権限の期限付き例外申請 |
| 対象 | org: example-inc / team: release-ops / 対象者: 2名 |
| 標準ルール | 管理者権限はJIT申請、通常はMaintainerまで |
| 例外理由 | 本番移行期間中のみ、外部連携設定の変更が必要 |
| 残るリスク | 権限侵害時にリポジトリ設定とSecretsへ影響する可能性 |
| 暫定対策 | 対象者を2名に限定、MFA確認、監査ログを毎日確認、作業後に権限削除 |
| 期限 | 2026-05-31 18:00 JSTまで。移行完了または作業中止時点で即時終了 |
| 再評価条件 | 監査ログ異常、対象者変更、Secrets更新作業の発生、期限超過 |
| 承認者 | 開発責任者、セキュリティ担当、システムオーナー |
| 記録先 | 変更チケット、監査ログ、作業完了コメント |
重要なのは、例外を「申請して終わり」にしないことだ。承認後も、期限前のリマインド、作業後の権限削除、監査ログ確認、残リスクの再評価までを1つの流れにする。
よくある失敗：例外を棚卸し対象から外す
例外管理でよくある失敗は3つある。
1つ目は、例外を台帳の外で管理することだ。メールやチャットで承認した例外は、数か月後に誰も覚えていない。最低でもチケット、変更管理、GRCツール、SaaS台帳のいずれかに残す。
2つ目は、承認者が実務上のリスクを理解していないことだ。セキュリティ担当が技術的に許可し、事業側が業務上の必要性を承認し、システム担当が実施可能性を確認する。どれか1つだけでは判断が偏る。
3つ目は、例外終了の作業を忘れることだ。期限が来たら自動で安全になるわけではない。権限削除、設定戻し、監査ログ確認、チケット完了、再発防止の更新まで確認する。
月次または四半期のレビューで、期限切れ、所有者不明、暫定対策未確認の例外だけを抽出する。全件を毎回読むより、期限切れと高権限例外に絞る方が継続しやすい。
まとめ：例外は「後で直す」ではなく「いつ何で下げるか」
セキュリティ例外申請で残すべきなのは、例外を許可した事実だけではない。対象、標準ルール、理由、残るリスク、暫定対策、期限、承認者、再評価条件をそろえて、いつ何でリスクを下げるのかを説明できる状態にすることだ。
パッチ延期なら、CVE初動対応チェックリスト と KEVとは ─ CVE対応の優先順位を決める実務 を合わせて確認する。SaaSや認証例外なら、SaaS権限棚卸しチェックリスト と 条件付きアクセス例外の棚卸し を確認すると、MFA除外・場所例外・端末条件を具体的に見直しやすい。権限判断の前提は 認証と認可の違い と リスクマネジメントの基礎 に戻るのも有効だ。
例外は悪ではない。ただし、期限のない例外、所有者のない例外、暫定対策のない例外は、将来のインシデント候補になる。例外を「便利な抜け道」ではなく、期限付きの残リスク管理として扱うことが、実務で効くセキュリティ運用の第一歩になる。
