緊急変更35%と凍結期間パッチで起きた認証停止
地方銀行C社の情報システム部では、更改を伴う変更が月220件、うち緊急変更が35%、変更失敗率が14%、変更の平均リードタイムが18日、手戻り工数が月160時間に達している。CABは週1回2時間、12名参加で、1回の議題は約60件。審査の大半は「影響が小さいので承認」で、実質的な議論がない。標準変更の定義がなく、パスワード変更や軽微な設定変更までCABに回っている。緊急変更の定義は規程に「緊急を要するもの」とだけ書かれ、現場の判断で届け出られる。四半期決算の2週間は変更凍結期間だが、先月、セキュリティベンダーから緊急パッチの適用要請があり、現場判断で適用して事後報告とした。その結果、業務アプリの認証連携が一部停止し、翌朝の顧客向けサービスが30分停止した。構成管理DBの更新も変更後2週間遅れることが多く、CAB資料の構成情報が古い。CAB議長は企画部長で、技術判断は副議長のインフラ課長に集中している。経営層は監査対応から変更統制の強化を求めるが、現場は「CABがボトルネック」と反発している。
1. 緊急変更を削減するための見直しとして最も適切なものはどれか。 ア CABを週2回に増やし、全変更を引き続き審査する。 イ 変更を標準・通常・緊急に分類し、標準変更は事前承認済みの手順・範囲・権限を定義してCAB審査を省略する。緊急変更の定義を「サービス停止または重大なセキュリティリスク」に限定し、事後レビューを必須にする。 ウ 緊急変更を全面禁止し、決算期以外に一括適用する。 エ 変更に失敗した承認者を減給処分にして抑止する。
Read the worked answer
正解はイ。変更のリスクは一律ではなく、定型的で影響が限定された変更までCABに集めると、審査能力が枯渇し、重要な変更の議論が薄くなる。標準変更は手順・対象・権限・切戻しを事前に承認し、実施記録だけを残す。緊急変更は定義を厳格にし、事後レビューで原因と再発防止を確認する。CABは高リスク変更と例外に集中する。アは審査件数を増やすだけで、ボトルネックを悪化させる。ウは現場の抜け駆けを招き、統制が効かない。エは失敗の報告を隠すインセンティブになる。まず変更を分類し、月220件のうち標準化できる件数を見積もる。
2. 凍結期間中の緊急セキュリティパッチ適用の判断として最も適切なものはどれか。 ア 凍結期間は例外なく適用を禁止する。 イ 凍結の目的に照らし、脆弱性の悪用可能性、業務影響、切戻し可能性を評価したうえで、臨時のCABまたは権限者による承認、適用後の監視、事後報告を条件に例外適用を認める。 ウ 現場判断で適用し、翌営業日に報告する。 エ ベンダーの推奨なら無条件で適用する。
Read the worked answer
正解はイ。凍結期間はリスクを抑えるための統制であり、絶対的な禁止ではない。脆弱性が悪用される可能性、顧客影響、業務影響、切戻しの可否、代替統制を評価し、凍結の目的に照らして例外を判断する。承認は臨時CABまたは権限者とし、適用後の監視、切り戻し条件、事後報告をセットにする。アは重大な脆弱性を放置し、結果として更大的リスクになる。ウは今回の認証停止を再現する。エはベンダーの推奨を自社の環境で検証せず、責任分界も曖昧にする。例外の記録は監査対応にも使う。