金融業界に求められるセキュリティー運用とは？監査対応・ID 管理・脆弱性管理の実務ポイント

対策シートが届いてから、社内を走り回ることになる

チェックシートの空欄を前にして、まず考えるのは「これ、誰に聞けば分かるんだろう」ということだと思います。

サーバーの台数は、表計算ソフトの台帳を見れば一応分かる。ただ、去年増設した検証用のマシンが載っているかは記憶が曖昧です。管理者アカウントを誰が持っているかは、当時の担当者が異動していて確認が取れない。脆弱性の対応履歴は、ベンダーとのメールのやり取りを遡ればたどれるはずですが、2 週間でそこまで整理できるかは分かりません。

結局、営業に「この取引先、どこまで本気で見てくるか分かる？」と聞き、総務に人事異動の記録を出してもらい、ベンダーに問い合わせて、なんとか埋める。埋まらなかった欄には「随時実施」と書いて出す。

こうした経験があると、次に同じシートが来たときには少し楽になります。ただ、根本は変わっていません。やっていないのではなく、答えられない。 この違いを一度整理しておかないと、照会のたびに同じ 2 週間が繰り返されます。

そして厄介なことに、この状態は担当者の記憶で吸収されています。誰がどの設定をなぜそうしたかを覚えている人がいる限り、時間さえかければ答えは出ます。その人が抜けた瞬間、答えが出なくなる。

なぜ、金融に関わると運用の「説明」まで求められるのか

自社は金融機関ではないのに、なぜこの手の照会が来るのか。理由は制度側の構造にあります。

金融庁が 2024 年 10 月に公表した「金融分野におけるサイバーセキュリティに関するガイドライン」は、守りの工程を 6 つに切り分けた構成をとっています。方針を決める段階、自社の弱点を洗い出す段階、攻撃を防ぐ段階、異変に気づく段階、起きた後に立て直す段階、そして委託先まで含めて見る段階です。全部で 176 の確認項目が並び、それぞれ「最低限やること」と「できれば望ましいこと」に仕分けられています。委託先を見る工程が独立して置かれていること。 これが、取引先への照会が増えている直接の背景です。

ただし、この 176 がそのまま自社に降ってくるわけではありません。ガイドラインは冒頭で、会社の大きさ、扱う業務の性質、抱えているリスクの重さを見て、自分たちに必要な水準は自分たちで決めてよい、という立て付けを取っています。金融庁自身も、項目を機械的に埋めることを目的にせず、中身のある対応をしてほしいという趣旨の注意書きを添えています。つまり、規模に応じて線を引いてよい。ただし、引いた理由は残しておく必要があります。

3 領域は横並びではなく、下から積み上がっている

監査対応、ID 管理、脆弱性管理を並べて考えると、どれから手を付けるべきかが見えにくくなります。管理層として捉え直すと、優先順位の判断がしやすくなります。

下の層が崩れていると、上の層の答えが濁ります。たとえば資産の一覧が実機と食い違っていると、EDR を導入していても「何台に入っているか」を正確に答えられません。導入率 100 パーセントと書いたつもりが、台帳にない端末が数台あった、という状態になります。

ID 管理を脆弱性管理より下に置いたのは、退職者のアカウントが残っていると、その上のすべての判断が揺らぐためです。深夜に不審な操作が検知されたとき、そのアカウントの持ち主が在籍しているかどうかが即座に分からなければ、対応が止まります。

ただ、これは「必ず下から順に着手せよ」という意味ではありません。すでに EDR が動いている環境なら、そこから資産の実態を吸い上げるほうが早いこともあります。自社でいちばん薄い層はどこか、という見方をしてみてください。

ID 管理 — 判断が割れる 3 つの分岐点

金融分野の照会で最も細かく聞かれるのが、この領域です。ガイドラインが求めているのは、要するに「渡しすぎない、放置しない、見返す」の 3 つです。権限は仕事に必要な分だけ渡す。アカウントは作った後も終わりまで面倒を見る。誰が何をしたかを定期的に見返す。サーバーの起動停止や設定変更まで踏み込める特権アカウントには、本人確認をもう一段厚くしたり、使える時間帯を絞ったりといった追加の手当てが挙げられています。

実務で判断が割れるのは、次の 3 点です。

反映の速さを、どこに設定するか

「退職日当日にアカウントを削除」と規程に書くのは簡単です。ただ、月末に退職が重なると数日ずれる、というのはよくある話だと思います。

ここで本当に問題になるのは、遅延そのものより、規程と実態が離れたまま何年も放置されることです。照会で「規程どおり運用していますか」と聞かれたとき、答えに詰まる原因はここにあります。当日削除が難しいなら、人事部門との連携を見直すか、規程を実行可能な内容に改めるか。どちらかを選び、選んだ理由をひと言残しておく。これだけで、次回以降の説明が変わります。

台帳運用を続けるか、仕組みに寄せるか

対象サーバーが十数台で、触る人が固定されているなら、台帳と申請フローでも回ります。一方、対象が数十台を超え、保守ベンダーが定期的に入れ替わる環境では、手作業だけで抜け漏れを防ぐのは難しくなってきます。

判断の目安は台数そのものより、「誰が、いつ、どのサーバーに、なぜアクセスしたか」を後から突き合わせる作業にどれだけ時間がかかっているかです。照会のたびに半日以上かかっているなら、仕組み化を検討する段階かもしれません。

申請者と承認者が同じ人になってしまう問題

これは少人数の情シスに特有の論点です。特権 ID の払い出しに申請と承認のフローを作っても、実際に作業するのが自分ひとりなら、自分で申請して自分で承認することになります。形式としては成立していても、統制としては機能していません。

この場合、承認を上長に上げるか、事後の報告を必須にするか、といった代替手段を考えることになります。どちらも手間は増えます。ただ、照会で「承認プロセスはありますか」と聞かれたときに、実態を説明できるかどうかは変わってきます。兼務体制であること自体は減点材料ではありません。 それを踏まえてどう補っているかが問われます。

なお、緊急対応の際に本来のゲートウェイを経由せず直接ログインしてしまう、いわゆる迂回アクセスをゼロにするのは、現場感覚として難しいと思います。禁止するだけのルールは、緊急時に守られず、記録も残らないという最も困る形になりがちです。迂回が起きたことを後から把握でき、なぜそうなったかを確認できる状態にしておくほうが、実務的には機能します。

脆弱性管理 — 「全部は無理」から始める

脆弱性診断を年 1 回実施している企業は少なくありません。手が止まるのは、その後です。

まず数に押されます。危険度が最も高い区分に入るものだけを数えても、年間で四桁に届きます。「最上位は即時対応」という物差しを掲げたところで、中身を読むだけで一日が終わります。そのうえ、この危険度は「もし破られたらどれだけ痛いか」を測ったものです。破りにきている相手が実在するかどうかは、この数字には入っていません。

そこを埋める物差しとして、近ごろ名前を聞くようになったものがいくつかあります。

どれかを入れれば手間が減る、という類のものではありません。深刻度の順に並んでいた一覧を、自社の業務と実際の危なさで組み替えるための手がかりが増える。 それだけです。並べ替える手は、やはり自分たちで動かすことになります。

人数が少ない現場なら、毎日目を通す体制を作ろうとするより、月に一度、半日だけ確認に充てる日をカレンダーに置くほうが根づくことがあります。間隔が空くぶんの危うさは残ります。ただ、三か月で崩れる仕組みより、細くても続く仕組みのほうが、あとから見返せる形で残ります。

止まっている業務に手を入れられない、だから今回は当てない。こういう決断は必ずどこかで出ます。それ自体は、状況次第では筋が通っています。ややこしくなるのは、なぜ見送ったのか、いつまた考え直すのかを書き残していないときです。半年も過ぎると当人ですら経緯を思い出せなくなり、そのまま何年も置かれ、最後は機器ごと寿命を迎えていた。よくある着地です。

照会で提示を求められるのは、実は当てた記録より、当てなかった判断のほうが多いという感覚があります。

EOL は、インフラの話ではなく説明責任の話として出てくる

サポートが切れた機器が社内に残っている。これは中小企業ではごく普通のことで、予算や業務への影響を考えれば、すぐに全部を入れ替えるのは現実的ではありません。

問題は、照会シートに「サポートの切れたソフトや機器を使っていますか」という趣旨の欄があるときです。

ここで迷います。正直に書いたら不利になるのではないか。かといって嘘は書けない。空欄で出すわけにもいかない。

実務では、伏せておくより、いまどうなっていて何で凌いでいるかを並べて書くほうが、相手に通じやすい印象があります。

記載例

生産管理に使っているサーバーが 2 台、期限を過ぎたまま動いている。
ただしこの 2 台は他の社内ネットワークとつながっておらず、外に出ていく通信も止めてある。
触れる端末も 3 台に絞ってある。
入れ替えは来期の予算で通す予定で、それまでは 3 か月に一度、動作を見に行っている。

これが「対応済み」でないことは変わりません。ただ、危ないと分かっているか、いま何で押さえているか、いつ抜け出せる見込みか。 この 3 つが並んでいます。聞いてきた側が知りたいのも、多くの場合はこの 3 つです。

ここで効いてくるのは、こういう文章を書くために必要な材料が、日々の運用のなかに残っているかどうかです。つないでいないという事実。触れる端末の台数。来期の予算に載せた経緯。どれも把握していれば書けますが、把握していなければ書けません。

つまり EOL の扱いは、機器を入れ替えるかどうかという話の前に、いまの状態を言葉にできるかどうかという話でもあります。もちろん、こう書けば必ず先方が納得するとは限りません。取引の中身によっては、期限を切った改善計画まで求められることもあります。

クラウドに移すと、責任範囲の説明が難しくなる場面がある

運用負荷を下げる手段として、クラウド移行を検討している方も多いと思います。ハードウエアの保守から解放され、EOL の管理も軽くなる。実際、そうした効果は見込めます。

ただ、説明責任という観点では、移行によって楽になるというより、説明の対象が変わるという捉え方をしておくほうが安全です。

金融の領域でクラウドを使うと、守りの手立てが二系統に分かれます。片方は自分たちで組んで自分たちで回すもの。もう片方は、事業者の側に最初から備わっていて、それを借りて使う形のものです。どちらに入るかは契約の書き方や、どこまでを事業者が持つかの線引きによって変わります。だからこそ、向こう側に何が備わっているのかを先に見ておく必要が出てきます。

いちばん分かりやすいのはデータを消すときの話です。利用者の側でできるのは、誰からも見えない状態にするところまで。ディスクから実際に消える時期を決めるのは事業者です。つまり、自社の一存では動かせない領域が生まれます。

危ないと言いたいわけではありません。消去の手順を尋ねられたとき、自分の言葉で答えられる範囲と、事業者が出している資料を持ってくるしかない範囲がある。その境目を自分で把握できていないと、社内に機器を置いていた頃より答えづらくなる場面が出てきます。

この辺りは業界団体も追いかけていて、クラウドならではの事情に合わせた手引きが試行版という形で出ています。まだ動いている領域なので、移行を考える時期には最新の状況を見ておくとよいと思います。

移行前に整理しておきたい 4 点

• どのデータが、どの事業者の、どのリージョンに置かれるか

• 監査に使う記録をどこまで自社で取れるか

• 権限の管理を自社側で完結できるか、事業者の設定に依存するか

• 事業者が出している準拠性の資料を、照会の回答にそのまま添えられるか

これらが決まっていないまま移行すると、移行後に「誰に聞けば分かるのか」という状態が、社内から社外に移るだけになりかねません。

ツールと外部委託に、どこまで期待できるか

「監視を外部に任せれば、夜間の呼び出しから解放されるのでは」。この期待は、実務ではしばしば裏切られます。

SOC サービスの多くは、見つけた異変を知らせるところまでが役目です。それが本当に手を打つべきものなのか、打つとして何をするのか。ここから先は使う側に戻ってきます。受け取る人が社内にいなければ、知らせは溜まっていくだけです。

深夜に重いアラートが飛んできたとして、誰を叩き起こすのか。どこまでなら自分の裁量で止めていいのか。ここが決まっていなければ、結局は翌朝まで何も動きません。月次のレポートも同じで、読んで自社のやり方に落とし込む人がいなければ、届いているだけになります。

外に出すほど、社内側の受け皿が要る。 この逆説は、規模が小さいほど強く出ます。人数が少ないと、受け皿を作る余力そのものが足りないからです。

なお、休みなく見張り続ける体制は、ガイドラインでは「あればなお良い」側に置かれた項目です。どの会社も必ず用意すべきものとしては書かれていません。自社が何を提供していて、そこにどんな危険が乗っているか。そこから逆算して決める話です。日中だけ見る形にとどめるという判断も、理由が言えるなら成り立ちます。

同じことがツール全般に言えます。効き目は、放り込む情報の正確さ次第です。台帳が古いまま EDR を入れても、どこまで守れているかを言えません。人の出入りが反映されていない状態で権限管理の道具を入れても、判断の土台になる数字が信用できません。

遠回りに見えても、材料のほうを先に整えるほうが結果的に早い。この領域では、そういうことがよく起こります。

相談や検討に入る前に、社内で埋めておきたいこと

外部に相談する前に、社内でひととおり答えを出しておきたい問いがあります。多くはそのまま照会シートの回答欄に流用できます。

手元にあるものが見えているか

社内で動いているサーバーや端末、ネットワーク機器、契約しているクラウドサービスを、いま何台あるか即答できるでしょうか。それぞれ、いつまでメーカーの面倒を見てもらえるのかは分かっているでしょうか。

誰が何に触れるかが整理できているか

強い権限を持っている人が何人いて、その顔ぶれを最後に見直したのはいつだったか。人が辞めたり異動したりしたとき、権限が実際に書き換わるまで何日かかっているか。

判断が残っているか

この 1 年で「今回は当てない」と決めた脆弱性があるなら、その理由はどこかに書いてあるでしょうか。特権 ID を出すときに首を縦に振るのは誰か。自分ひとりなら、それも含めて事実です。アラートが最初に届く先と、その次に相談する相手は決まっているか。記録はどこに、いつまで置いてあるか。

外との境目はどこか

仕事を任せている先はどこで、それぞれに何を預けているか。クラウドを使っているなら、自分たちで設定する部分と事業者に任せている部分の境目はどこか。そして前回の照会で埋められなかった欄は、どれだったか。

書き出してみると、たいてい何問かは「調べないと答えられない」で筆が止まります。止まった問いこそが、外に相談したときに最初に出すべき話です。 どこで詰まったかを書き添えておけば、初回の打ち合わせから中身に入れます。

先送りしたときに積み上がるもの、基盤を替えても残るもの

「今期は別の案件が優先で、来期に回したい」。この判断は、状況によっては合理的です。無理に着手して現場を止めるより安全な場面もあります。

ただ、この選択が数年続くと、いくつかの負債が静かに積み上がります。事故として表面化しないぶん、気づいたときには選択肢が減っている、というのがこの問題の性質です。

いずれも、起きてから対処すると選択肢が限られます。故障してから慌てて手配すれば、比較検討の時間が取れず、提示された条件で決めることになる。この構造は企業規模を問いません。

先送りは、それ自体が一つの意思決定です。意識的に選んでいるのか、判断を保留しているだけなのか。 ここを区別しておくだけでも、社内の議論の質は変わります。

そしてもう一つ。基盤を新しくしても持ち越されるものがあります。

たとえば、通信許可の設定に用途の分からないルールが 1 行だけ残っている。移行のとき、消してよいか判断がつかず、そのまま引き継いだ。これは機器を新しくしたことでは解決しません。「なぜその設定なのか」が記録されていないという状態が、場所を変えて存続しているだけだからです。

障害時の連絡先も、権限変更の承認ルートも、棚卸しの頻度も同じです。いずれも構成の問題ではなく、決めごとが文書になっていないことの問題です。新しい基盤の上でも、決めごとは自動的には生まれません。

外部の支援を使うという選択肢はあります。ただ、外部に任せれば社内の役割整理まで進むわけではない。この前提を持って検討に入れるかどうかで、数年後の姿は変わってきます。

よくある質問 ( FAQ )

Q1. 取引先から届いたチェックシート、答えられない項目は空欄で出してもいいですか

空欄より、現状と今後の予定を書くほうが説明として成立しやすい傾向があります。「未実施」と書くのが不利に感じるかもしれませんが、把握していないことを把握していない状態のほうが、後で問題になりやすいためです。未実施なら、その理由と、いつ検討するかを添えておく。それだけでも回答の性質は変わります。ただし、取引の内容によっては具体的な改善計画の提出を求められることもあります。

Q2. うちは金融機関ではないのに、なぜここまで求められるのでしょうか

金融庁のガイドラインで委託先まで見る工程が独立して置かれており、金融機関は取引先や再委託先まで含めてリスクを把握することが求められているためです。つまり、照会は取引を通じて外側からやってきます。ただし、金融機関と同じ水準を求められているわけではありません。自社の規模と扱う情報に応じた線引きが認められます。線を引いた理由を残しておくことが、実務上のポイントになります。

Q3. 特権 ID 管理は、表計算ソフトの台帳では駄目でしょうか

規模と入れ替わりの頻度によります。対象が十数台程度で担当者が固定されている環境なら、台帳と申請フローで回るケースもあります。判断の目安は台数より、「誰がいつどこにアクセスしたか」を後から確認する作業にかかる時間です。照会や監査のたびに半日以上かかっているなら、仕組み化を検討する段階かもしれません。ただし、ツールを入れる場合も、承認する人と承認基準が先に決まっていることが前提になります。

Q4. クラウドに移行すれば、セキュリティー管理は楽になりますか

ハードウエアの面倒を見る手間や、期限切れを追いかける負担は軽くなります。一方で、自分たちで組む部分と事業者に備わっている部分を分けて説明する必要が生まれます。たとえばデータがディスクから実際に消える時期は事業者が決めるため、こちらの都合では動かせません。軽くなる部分と、説明の仕方が変わる部分がある。そういう理解で検討されるとよいと思います。

Q5. SOC を外部委託すれば、夜間や休日の対応はなくなりますか

知らせを受けてからの判断と対応は、多くの場合、社内に残ります。SOC サービスの基本的な役割は異変を見つけて伝えるところまでで、本当に手を打つべきかの判断、実際の対応、業務部門との調整は委託範囲外となるケースが一般的です。検討する際は、知らせが最初に届く人と、その次に相談する相手、自分の裁量で止めてよい範囲を先に決めておくことをおすすめします。ここが空白だと、知らせが溜まるだけの状態になりがちです。

Q6. 情シスがひとりの体制でも、対応は可能でしょうか

可能ですが、優先順位を絞ることが前提になります。すべての項目に同じ強度で取り組むのは現実的ではないため、資産と権限の棚卸しを土台に据え、それ以外は段階的に進める形が現実的です。また、申請者と承認者が同一人物になるといった構造的な制約は、体制上どうしても生じます。これは減点材料というより、どう補っているかを説明できるかどうかが問われる部分だと考えられます。

まとめ

金融分野に関わるセキュリティー運用では、対策を導入しているかどうかより、運用を続けられているか、問われたときに説明できるかが見られます。要点を 5 点に整理します。

• 照会は取引を通じて外側から来る。
  自社が金融機関でなくても、委託先として確認される構造があります

• 規模に応じて線を引いてよい。
  ただし、引いた理由は残しておく必要があります

• 資産と権限の棚卸しが土台。
  ここが実態と合っていないと、上のどの対策も説明が濁ります

• EOL は伏せるより、いまの状態と当座の手当てを並べて書く。
  そのために、日々の運用で現状を言葉にできる状態にしておくことが効いてきます

• クラウド移行は説明が不要になるのではなく、説明の対象が変わる。
  自分たちで組む部分と事業者に備わっている部分の切り分けが必要になります

唯一の正解はありません。同じ規模でも、既存資産の状況と体制が違えば最適な選択は変わります。本記事の判断軸と問いが、自社の状況を整理する手がかりになれば幸いです。

横河レンタ・リース株式会社では、IT 基盤の設計、構築、運用支援から、ID 管理、監視、脆弱性対応を含むセキュリティー領域まで、横断してのご相談を承っています。「まず現状を棚卸ししたい」「照会に答えられなかった項目をどう埋めるか相談したい」といった段階からでも構いません。手が止まった箇所を、そのままお持ちいただければと思います。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース