情報セキュリティ例外の承認・期限管理｜リスク受容と代替統制を放置しない運用
情報セキュリティの例外は、満たせない標準要件と対象資産を特定し、残るリスク、代替統制、承認者、有効期限、標準へ戻す条件を一組で管理します。「業務上必要だから」という承認だけで終わらせず、期限前に再審査し、不要になった権限や設定を実際に閉じるところまで確認することが重要です。
パッチの適用を保守日まで延期する、古い連携方式を移行期間だけ残す、特定の端末に限って標準設定を外す。こうした判断には、業務継続とリスク低減の両方が必要です。一方で、例外申請を出しただけで許可されたと思い込んだり、担当者の異動で承認の条件が失われたりすると、期限付きの措置が恒久化します。
2026年9月8日時点で確認したNIST SP 800-53 Rev.5の公式機械可読カタログでは、RA-7が組織のリスク許容度に沿った対応と理由を伴うリスク受容を、CA-5が是正計画と進捗の更新を、CM-3が変更の承認・記録・監視を扱っています。以下の申請項目や手順は、これらを参考にした運用設計例です。NISTが一律の例外期限や、この書式の利用を要求しているという意味ではありません。
本記事のポイント
- セキュリティ例外は、対象・残余リスク・代替統制・承認者・有効期限を一組にし、許可範囲を限定します。
- 延長は自動更新せず、是正の進捗と対策の証拠を確認して再承認し、前提が変われば期限前でも見直します。
- 期限が過ぎただけでは終了にせず、標準設定への復帰と一時的な権限・設定の整理を確認して台帳を閉じます。
例外承認で決める範囲と、承認だけでは変えられないこと
例外は、具体的な標準要件を、限定した対象と期間について満たせない状態を管理するものです。例えば「サーバー全体を例外にする」ではなく、「資産IDが特定された2台の特定パッチについて、互換性確認と保守作業が終わるまで適用期限を延ばす」と書きます。対象台数や日数は実際の申請内容で決め、過去案件の条件を流用しません。
リスク受容とは、対策後にも残る影響を、権限を持つ責任者が理由とともに引き受ける判断です。代替統制は、標準の対策をそのまま実施できない間にリスクを下げる別の措置を指します。監視を増やすこと、利用経路を限定すること、アクセス元を絞ることは候補になりますが、どの脅威をどこまで減らすかを説明できなければ十分とはいえません。
| 判断 | 記録する内容 | 避けたい扱い |
|---|---|---|
| 標準どおりに是正する | 是正内容、担当者、実施予定、確認方法 | すぐ直せるものまで例外にする |
| 期限付きで条件を付けて許可する | 対象、残余リスク、代替統制、期限、取消条件 | 許可後の設定確認を省く |
| 申請を差し戻す・認めない | 不足する根拠、許容できない影響、代替案 | 申請中だから利用を続けてよいとみなす |
| 利用を止める・別手段へ移す | 停止範囲、業務代替、通知先、再開条件 | 停止による業務影響を確認しない |
社内承認だけで法令上の義務や顧客との契約条件を免除することはできません。どの要件を誰の権限で変更できるのかを、申請時に法務・契約管理の担当者と確認します。取引先への説明は、セキュリティチェックシートの回答根拠管理と連携させ、例外中の状態を標準適合として回答しないようにします。
NISTのRA-7は、リスクの軽減、理由を伴う受容、共有・移転、回避といった対応を示しています。例外を申請したら受容しか選べないわけではありません。追加対策で標準を満たせるか、対象の利用を止められるかも同じ場で比較します。
申請台帳は「誰が、何を、いつまで」に証拠を結び付ける
台帳は一つの表でもチケットでも構いません。重要なのは、申請、承認、実際の設定、是正作業、終了確認を同じ例外IDでたどれることです。申請文を上書きし続ける方式では、何を前提に承認したのかが分からなくなるため、延長や対象追加は履歴として残します。
| 項目群 | 最低限残す項目 | 確認できる状態 |
|---|---|---|
| 対象と理由 | 例外ID、標準の条項、資産・システムID、利用部門、満たせない理由 | 別の資産や利用者へ許可が広がらない |
| 影響と対策 | 脅威、影響を受ける業務・情報、代替統制、対策後の残余リスク | 監視だけで予防したことになっていない |
| 責任と承認 | 申請者、業務責任者、技術確認者、リスク受容者、判断日時 | 設定する人と受容を決める人が分かる |
| 期限と見直し | 開始日時、終了日時とタイムゾーン、再審査日、取消条件 | 通知日と失効日を混同しない |
| 是正と終了 | 標準復帰の作業票、節目、確認証拠、完了確認者、閉鎖日時 | 台帳上の完了と実際の復帰が一致する |
「代替統制あり」のチェックだけでは、実効性を確認できません。アクセス制限なら許可対象と設定の確認結果、監視なら検知条件・確認者・対応期限、有人承認なら代行者と未処理時の扱いを添えます。秘密情報、トークン、認証用の復旧コードそのものは台帳へ記載せず、閲覧権限を限定した証拠保管先への参照にします。
承認者は役職名だけで固定せず、組織の権限規程に沿って影響の大きさで分けます。部門内の影響を超える例外、顧客データに関わる例外、他社との接続を含む例外では、部門責任者だけでは判断できないことがあります。NISTのPM-9も組織全体で一貫したリスク管理と許容度を扱っています。現場の都合だけで例外ごとに基準が変わらないようにします。
申請から標準復帰までを7段階で回す
流れは、申請、条件付き承認、期限前の再審査、標準への復帰です。延長が必要な場合は、再審査から承認へ戻ります。通知を出したことや、延長の申請を受け付けたことを、自動的な許可更新として扱いません。
1．満たせない要件と対象を限定する
標準の条項、資産ID、利用者、接続先、データの種類を確認します。理由が「工数不足」だけなら、必要工数、代替案、業務停止の影響まで具体化します。担当者が違えば判断が変わる状態を減らすため、申請対象に含まれない資産も明記すると有効です。事後申請が見つかった場合は、既に起きた未承認変更として扱う手順と、今後の例外判断を分けて記録します。
2．脅威と業務影響を評価する
何が起きると、誰に、どんな損失が生じるかを記述します。脆弱性の深刻度だけでなく、外部から到達できるか、権限がどこまで及ぶか、扱う情報が何か、停止時に代わりの業務手段があるかを確認します。過去の被害パターンは主要なセキュリティインシデントの事例と教訓も参考になりますが、対象環境への当てはまりを個別に評価します。
3．代替統制を実施し、効果と限界を確かめる
例えば、パッチ適用の猶予を検討する場合、対象通信の制限や不要機能の停止などを候補として評価します。単に監視ログを増やしても、攻撃そのものを防げるとは限りません。対策の動作確認結果と、それでも残るリスクを分けて記録します。対策の実施が承認条件なら、設定完了を確認するまで例外利用を開始しません。
4．権限を持つ責任者が条件と期限を承認する
技術担当者は対策の妥当性を確認し、業務責任者は停止や代替運用の影響を確認し、権限を持つリスク受容者が最終判断を残します。一人が複数の役割を担う小規模組織でも、何を確認し、どの立場で承認したかは分けて書きます。終了日時、再審査日、取消条件、連絡先を承認記録に含め、申請者へ返します。
5．設定と期限を監視する
開始後は、承認範囲と実際の設定を照合します。期限通知を担当者一人のメールに依存させず、未確認なら代行者や責任者へ回します。例えば終了14日前と3日前に通知する設定は運用例であり、一律の推奨期限ではありません。変更に必要な期間とリスクの大きさから日程を決め、短い例外ではそれに合わせて前倒しします。
6．条件が変わったら、期限を待たずに再審査する
新たな悪用情報、対象のインターネット公開、取扱データの追加、担当者の異動、代替統制の停止などは再審査のきっかけです。「まだ期限内」であっても、承認時の前提が変われば許可条件の確認が必要になります。個人データの扱いが変わる場合は、プライバシー影響評価の実施タイミングとも結び付けます。
7．標準復帰を検証してから閉鎖する
パッチ適用、標準認証への移行、例外アクセスの削除など、目的に応じた復帰を検証します。作業票の完了だけでなく、構成、利用者、接続の実態を照合します。例外のために設けた一時アカウントや許可ルールも、必要性を再確認して整理します。監視強化策を残すかどうかは別途判断し、不要な設定だけを削除します。
例外の終了は、承認期限が過ぎた時点ではなく、許可条件を外して標準へ戻ったことを証拠で確認した時点で記録します。期限超過のまま稼働しているものは、期限切れ・未是正として責任者へ上げ、閉鎖済みにしません。
期限切れ・延長・緊急対応を放置しない
延長申請では、新しい終了日だけを書き換えません。是正が遅れた理由、現在の利用範囲、代替統制の稼働証拠、残余リスクの変化、次の是正予定を再提出します。前回と同じ内容でも、確認日時と判断者を新しく残します。同じ例外が繰り返される場合は、標準の適用方法やシステム更改、必要予算の問題として扱い、承認回数の積み上げで済ませないことが必要です。
期限切れ時の動作は、開始前に決めておきます。一時アクセスを自動失効できるものは、その設定と業務影響を検証します。停止が他の重大な被害を招く可能性があるシステムでは、期限当日に場当たり的な電源断を行うのではなく、事前に承認された縮退運転や代替手段へ移る手順を用意します。いずれも「返事がないから延長」は認めず、継続の判断者と条件を明確にします。
緊急対応にも専用の短い経路を作ります。最低限の対象・理由・リスク・責任者・終了時刻を残して判断し、通常記録の補完期限を決めます。申請者が不在であることと、承認済みであることは別です。緊急措置を事後に記録するときは、実施時刻と承認時刻を正確に分け、過去に承認があったように書き換えません。
管理状況は、期限超過件数だけでなく、承認者不明、代替統制の証拠不足、対象の増加、繰り返し延長、標準復帰までの滞留で見ます。件数を減らすために台帳から消すのではなく、何が是正を止めているかを把握します。是正に時間が必要なら、CA-5の考え方に沿って、担当者と節目を持つ計画として追跡します。
よくある質問
情報セキュリティ例外は何日まで認められますか？
一律の日数では決められません。対象のリスク、契約や法令、標準へ戻す作業に必要な期間を確認して終了日と再審査日を決めます。NISTの管理策を根拠に、特定の日数が共通の許可期間であるとは扱いません。
代替統制として監視を増やせば十分ですか？
監視は検知を助けますが、攻撃や不正利用を防げるとは限りません。防ぎたい脅威との関係、監視担当者、確認頻度、異常時の対応を確認し、残余リスクを評価します。
部門長が承認すれば契約要件も例外にできますか？
社内承認だけで契約上の義務を免除することはできません。契約変更や相手方の同意が必要かを契約管理・法務担当者に確認し、権限の範囲内で判断します。
延長申請中に期限を超えてよいですか？
申請中であることは許可ではありません。期限前に判断を終え、間に合わない場合は事前に定めた停止・縮退・代替運用へ移ります。継続が必要なら、権限を持つ責任者が条件を明示して判断します。
緊急時の事後承認はどう記録しますか？
実施時刻と承認時刻を分け、誰がどの情報で対応を決めたかを残します。通常の申請記録を補完する期限を決め、実施前に承認があったように履歴を書き換えません。
例外を終了した証拠には何を残しますか？
対象に応じた標準設定への復帰、パッチ適用、例外アクセス削除などの確認結果を残します。作業票と構成・権限の実態を照合し、確認者と閉鎖日時を記録します。
セキュリティ例外の台帳や承認・期限通知を業務に合わせて整えたい場合は、ファネルAiへのご相談をご利用ください。
管理策の詳細は、NIST公式のSP 800-53 Rev.5カタログ（RA-7、CA-5、CM-3、PM-9）をご確認ください。各管理策の趣旨を運用へ取り入れる際は、自社に適用される要件と責任分担に合わせて具体化します。
