分類の暗記では説明できない「なぜ、その組合せか」
リスクへの対応方法を覚えても、ケースに複数の対策が並ぶと迷うことがあります。例えば、同じ受注サービスに認証強化、権限の見直し、保険、機能の停止が提案されたとき、どれか一つを選べば他は不要なのでしょうか。判断には、守る業務と対策が作用する場所を結び付ける必要があります。
現行SGシラバスVer.4.1の技能項目には、対策の実施状況、費用、残留リスクを考慮した優先順位と、責任者・完了予定・評価方法を含む対応計画があります。本記事はその学習を補う独自例で、特定の出題頻度や本番の正解を予測するものではありません。用語の基本はISMSとリスクの整理、台帳の項目はリスク台帳の作り方に分けています。
対策を実施する業務側と、独立・客観的に評価する監査側の違いはSGシステム監査のケース解説で、証拠・報告・フォローアップまで確認できます。
架空ケース:受注は続けたいが、顧客一覧の一括出力に弱点がある
架空の会社Kでは、受注担当者が顧客一覧を出力する機能を使っています。現在は担当者全員が全地域の情報を出力でき、通常業務で必要な範囲より広いことが分かりました。パスワードだけの認証も使っています。ここでは、認証情報の悪用と、権限を持つ利用者による過剰な出力を、別の経路として整理します。
業務責任者は受注の継続を求めていますが、一括出力を止めても、必要な地域の情報を承認付きで取り出す代替手順は使えるとします。対象はこの架空の条件に限ります。「忙しいから全権限を残す」「安全のため全業務を停止する」の二択にせず、必要な処理と不要な処理を分けて考えます。
検討中の案は、多要素認証の導入、地域別の出力権限と承認の設定、一括出力機能の一時停止、保険の補償内容の確認です。現時点ではどれも提案段階で、導入済み・効果確認済みとは置きません。実際の問題では、本文にない代替手順や権限を勝手に補ってはいけません。
対策の役割を比較し、一つで全経路を守れると考えない
多要素認証は、認証情報の悪用への備えとして検討できます。一方で、正規の利用者が認証に成功した後、全地域の一覧を出せる権限は、それだけで必要範囲に変わりません。権限設定と承認手順は、出力できる対象や操作を絞るための別の対応です。
一括出力を止める案は、その機能を使った出力経路をなくすためのものです。ただし代替手順での誤操作や、別画面からの閲覧など、他の経路が全て消えるわけではありません。保険も、補償条件に合う損失の負担に関わるもので、認証設定や出力権限を直す機能ではありません。
入口への対策
- 多要素認証などを検討
- 認証情報の悪用に備える
- 認証後の出力範囲は別に確認
操作・経路への対策
- 地域別権限と承認を設定
- 不要な一括出力を止める
- 代替手順のリスクも確認
損失負担への備え
- 保険の対象・免責等を確認
- 条件に合う金銭負担へ備える
- 漏えいや停止自体は防がない
どれか一つで全て解決とせず、守る経路と残る影響を対応させます。
当サイトの架空ケースの比較。対策の効果・保険の支払・個別サービスの安全性を保証する図ではありません。
二つの分類軸を混ぜない:技術的管理策だから「移転」ではない
組織的・人的・物理的・技術的という区分は、管理策をどの側面から実施するかを見るためのものです。回避・低減・共有・保有という対応の考え方は、リスクをどう扱うかを見るためのものです。例えば、技術的なアクセス制御と、組織的な承認手順を合わせて、一つの出力リスクを低減することができます。
IPAの中小企業向けガイドラインでは低減・保有・回避・移転の区分が示されています。SGシラバスでは共有の用語例に移転・分散が挙がり、NISTの用語集ではsharingとtransferringを別々に列挙する説明もあります。資料ごとの文脈を確認し、「どの資料でも分類数と用語は完全に同じ」とは覚えないでください。ケースでは分類の名前だけでなく、変わる経路や負担を説明する方が理解につながります。
暫定運用は「受容したから放置」ではなく、条件を付けて管理する
会社Kで権限改修に時間が必要なら、実施までの扱いも決めます。例として、一括出力を止めた状態で、承認付きの代替手順を使い、利用記録を確認する案を責任者へ提示できます。ただし、これだけで受け入れ可能と決まるわけではありません。代替手順の負担、確認漏れ、残る情報へのアクセスを整理して、組織の基準と照合します。
判断記録には、対象のリスク、現時点の対策、残る影響、判断者、期限、見直し条件を残します。「改修完了予定日を過ぎた」「新しい出力経路が増えた」「確認できない操作があった」といった条件で再評価する形です。担当者が忙しいことや、予算が足りないことを、そのまま受容の承認と置き換えないようにします。
既に漏えい等が疑われる場合は、通常の改善計画だけで処理せず、組織のインシデント対応手順に従います。また、受容の判断で法令上の義務や契約条件までなくなるものではありません。実務では情報管理・法務等の担当へ相談し、試験では本文で指定された基準と権限を優先します。
対策の実施状況と、残る影響を確認できているか?
未実施・未検証がある
予定を実績とせず、根拠・暫定策・責任者と期限を整理する
確認したが基準を満たさない
追加対策や方法変更を検討し、権限者へ判断を求める
基準と条件を満たすと判断
必要な承認と記録を残し、期限や変更時に見直す
不明点、基準との比較、承認を一つの「完了」にまとめないことが大切です。
独自の学習用整理。組織の規程や法令、個別インシデントの対応判断に代わるものではありません。
費用と期限を入れても、最安の案だけで決めない
説明のため、会社Kの初年度予算を40万円と置きます。認証強化の初年度総費用が10万円、地域別権限と承認の設定・確認が25万円なら、二つの合計は35万円で予算との差は5万円です。全て架空の見積りで、実際の商品価格ではありません。二つを同時に実施でき、各見積りの範囲が重ならず、追加作業がないという仮定での足し算です。金額が収まったことは、十分に安全だと確認できたことではありません。
ここへ保険の保険料を足す場合は、契約期間、初年度か継続年か、付随費用もそろえて比較します。保険料と事故時に支払われる保険金は別の値です。補償の上限額を、対策で削減できる損失として無条件に差し引くこともできません。リスクの発生確率や実損失をこの例では与えていないので、「この組合せの投資効果が最大」と数値で断定する根拠はありません。
また、35万円の案が翌日には全て導入できるとは限りません。対象利用者への展開、権限設定の試験、承認者の手順確認に必要な期間を見ます。期限までに一部しか終わらないなら、未完了の項目とその間の業務を別に判断します。価格や製品の知名度だけで候補を選ばず、対象の経路に効くか、実施できるか、残る影響が許容できるかを説明することが、このケースの中心です。
対応計画には「入れた」と「確かめた」を別の欄にする
会社Kの案を計画へ落とすなら、設定変更の実施項目だけでなく、誰がどの証拠で完了を判断するかも書きます。権限一覧の更新だけでは、実際の画面や出力先に反映されたか分かりません。承認手順の文書を作っただけでも、必要な担当者が使えるかは未確認です。
下表は当サイトの架空の確認例です。実在のシステムに許可なくアクセスしたり、本物の顧客データで試したりする手順ではありません。検証用データと許可された環境で確認し、判定に必要な範囲の記録を残す考え方を学びます。
例えば判断メモを「一括出力は停止を確認。地域別の画面出力は試験済み。ただし自動連携の出力経路は未確認のため、全経路の制限完了とは扱わない」と書くと、確認済みと残件の境界が分かります。曖昧な「権限対策は完了」という一文より、次に調べる対象を引き継げます。実際の記録には確認日と対象版も添え、後の変更で根拠が古くならないようにします。
| 計画の項目 | 会社Kでの確認例 | 未確認なら残すこと |
|---|---|---|
| 出力権限の変更 | 検証用利用者が担当外地域を出力できないか | 画面以外の出力経路は未確認など |
| 承認付き代替手順 | 申請・承認・記録がつながるか | 承認者不在時の扱いなど |
| 認証の強化 | 対象利用者と例外・復旧手順を確認したか | 対象外の入口や例外設定など |
| 保険等の備え | 補償対象・免責・上限・手続を契約で確認したか | 未確認の補償条件など |
| 見直しと責任 | 判断者・期限・変更時の再評価が決まったか | 誰が再判断するか未定など |
対策の予定、設定の反映、効果の確認、残留リスクの判断は別の状態です。費用だけを並べた一覧より、状態と根拠を分けた計画の方が、まだ判断できない点を発見できます。
条件が変われば、選ぶ対策や優先度も変わる
この例で代替手順が使えないなら、一括出力の停止による業務影響が変わります。認証は既に強化済みだが出力権限だけが過大なら、追加する対策の焦点も変わります。逆に、保険の対象外の損失が大きければ、補償を前提にした負担の見積りを修正する必要があります。
条件を一つ変えて理由を説明する練習は、答えの名前を覚えることとは違います。「どの被害経路か」「今ある対策は何か」「何が残るか」「誰が判断できるか」を短く書いてみましょう。本文が示していない効果や承認を、都合よく追加しないことも重要です。