メーカーによるサポートや、修正パッチの配布が終了した古いOSを指す「レガシーOS」が残っていると、「攻撃に弱くなる」問題がじわじわ進みます。特に、サーバー担当の立場では、海外拠点や委託先も含めて運用しているほど、更新の遅れや例外対応が積み上がりやすいため、セキュリティ対策が欠かせません。
そこで本記事では、レガシーOSのリスクやセキュリティ対策として講じたい更改計画について解説します。
1. レガシーOSが危険な理由
まずは、なぜレガシーOSが危険なのかを、サポートと運用の観点から整理します。
1-1. 修正されない前提による攻撃リスクが高まる
OSのサポートが終了すると、セキュリティパッチが提供されなくなり、既知の脆弱性が「修正されない前提」になり、攻撃されるリスクが上がります。
例として、Windows Server 2008 R2は延長サポートが2020年1月14日に終了しています。以降、追加のセキュリティ更新を受けるには、ESU（拡張セキュリティ更新）のような別枠の対応が前提になります。
また、環境によって事情は違いますが、レガシーOSのサポート状況例は以下のとおりです。
・Windows Server 2012／2012 R2 ：サポート終了は 2023年10月10日
・CentOS 7 ：EOL（サポート終了）は 2024年6月30日
「サポートが切れているOSがどこにあるか」が分かるだけで、更改の優先順位づけが一気に進めやすくなります。
1-2. 海外拠点があるとリスクが増える
海外拠点があると、同じOSでもリスクが増えやすくなります。 国・拠点ごとに運用がばらつきやすくなり、セキュリティリスクが高まる点に注意が必要です。更新のタイミング、設定、監視の手順を揃えるセキュリティ対策を講じないと、「一部だけ古いまま」「例外だけが残る」といった穴が生まれます。
さらに、委託先が絡むほど境界が増え、権限や責任分界が曖昧になりやすい点も、グローバル運用での注意ポイントです。
2. レガシーOSで起きやすい具体的なセキュリティリスク
ここでは「何が起き得るのか」を、現場で想像しやすいシーンを3つに整理します。
2-1. 既知脆弱性の放置による侵入リスク
レガシーOSで生じるリスクは、パッチが出ない・適用できないことを理由に、公開済みの手法で侵入されうる点です。攻撃が特別に高度というより、守る側が更新できず「穴が塞がらない」状態になった結果、侵入リスクが高まってしまうケースです。
例えば、脆弱性情報が公開され、対策方法も出回っているのに、OS側の更新が止まっている場合、攻撃者は同じ弱点を繰り返し狙います。海外拠点を含む環境では、ネットワーク経路や委託先接続など入り口が増えるほど、残った弱点が見つかりやすくなります。
2-2. 古い暗号とプロトコルが引き起こす通信リスク
レガシーOSでは、通信の安全性が“仕様上”弱くなりやすいのも問題です。例えば、セキュリティ対策をしたくても、古いTLS（Transport Layer Security）や暗号方式しか選べず、推奨設定に合わせられないことがあります。また、古いリモート管理方式や認証方式を前提にしていて、強い認証に置き換えにくいケースも注意が必要です。
さらに厄介なのが、互換性のために設定を弱めたまま残ることです。
・古い機器やアプリがあるため、暗号設定を下げている
・一部だけ例外のポートを開けている
上記のような例外が積み重なると、想定外の経路で情報が見えたり、盗聴や改ざんのリスクが増えたりします。
2-3. 監視と検知が弱くなるリスク
侵入そのもの以上に困るのが、侵入に気づかない・追えないことです。レガシーOSは、サーバの不審な動きを検知するEDRや、新しい監視エージェント端末が対応していない場合があり、監視の“網”が薄くなります。
ログについても、形式が古かったり、取れる情報が少なかったりして、調査に必要な記録が残らないことがあります。センサーデータを自動的に収集し、中央システムへ送信・分析する「テレメトリ」が不足すると、情報を後追いできず、復旧や再発防止が長引きやすくなるのが難点です。
3. レガシーOSのセキュリティ対策
対策や更改を進める前に、まず「どこに何があり、どこから狙われるか」を把握しておくと、優先順位がぶれにくくなります。ここでは、最小の手数で把握するポイントを整理します。
3-1. 資産棚卸しとバージョン確定
最初は、海外拠点も含めて“同じ項目で”棚卸しします。細かな台帳づくりより、まずは最低限の情報を埋めることが目的です。
・OS／バージョン ：正確なバージョン
・役割 ：何を動かしているか
・設置場所 ：拠点・ネットワーク区分・クラウド／オンプレの別
・管理者 ：誰が変更できるか、夜間・休日の連絡先
・保守契約 ：サポートの有無・ベンダー連絡先・制約事項
・インターネット到達性 ：外部から直接届くか、VPNや踏み台が必要か
情報が揃うと、同じOSでも「重要度が高い」「露出が大きい」「誰も触れない」など、危険度の差が見えます。
3-2. インターネット公開面と横展開経路の可視化
次に、「入り口」と「広がり方」を確認します。ポイントは、直接インターネットに出ていなくても、どこか1点が破られると横に広がる経路が残っていないか、という視点です。
洗い出しの対象は、主に以下のような項目です。
・公開しているサービス（Web、メール、VPNなど）
・管理用のポート
・踏み台サーバー
・バックアップ経路
・拠点間VPN
・委託先からの接続経路
これらを並べて、「どこから入って、どこまで到達できるか」を1枚の図か表にすると、関係者と合意しやすくなります。
3-3. サポート可否と延命策を整理する
最後に、「今すぐ更改できるか／できないか」を現実的に切り分けます。例えば、ESUや延長サポートの有無、OSだけでなくミドルウェア（アプリやDBなど）の更改が必要か、を確認します。
どうしても残る例外がある場合は、放置せずに扱いを決めるのが有効です。具体的には、以下のような方針で整えていきます。
・ネットワーク的に隔離する
・到達できる経路を最小化する
・代替システムへ置き換える
「延命するなら、どの条件を満たすか」まで決めておくと、例外が増えすぎるのを防げます。
4. レガシーOS入れ替えまでの暫定対策と更改計画
更改が必要だと分かっていても、すぐに入れ替えられないケースは多いのが実情です。ここでは「更改までの守り方」と「海外を含む更改の進め方」を、現実的な順番で整理します。
4-1. 暫定対策で被害の発生確率と影響範囲を減少
暫定対策の狙いは、侵入されにくくすることと、仮に侵入されても被害を広げにくくすることです。全部を一度にやる必要はなく、露出が大きい項目から順に整えると効果が出やすくなります。
・ネットワーク分離・到達範囲の最小化 ：レガシーOSに到達できる経路を減らし、必要な通信だけ許可する
・踏み台の集約 ：管理操作は踏み台経由に寄せ、直接触れる人・端末を絞る
・強い認証 ：多要素認証などで、パスワードだけに頼らない運用にする
・特権ID管理 ：管理者権限の利用を申請制・期限つきにし、操作ログを残す
・アプリ許可制 ：実行してよいプログラムを限定し、不要な実行を抑える
・仮想パッチの考え方 ：OSを直せない代わりに、外側の機器や仕組みで攻撃パターンをブロックする
・バックアップ強化 ：復旧できる状態にする
「どれが正解か」より、自社の露出面に合う対策から積み上げることが重要です。なお、セキュリティ対策を講じる際、「何も信頼しない前提」であるゼロトラストの視点で整えていくことが推奨されています。
4-2. 海外を含む更改プロジェクトの進め方
海外拠点がある更改は、技術よりも段取りで詰まりやすい傾向です。時差や変更可能な時間帯（変更窓）を前提に、最初から段階移行の形式にしておくと進めやすくなります。
進め方の基本は、拠点またはシステム単位で小さく移行し、検証環境で手順を固めてから横展開する流れです。
ロールバックを用意し、現地作業が必要な部分は体制と連絡網を先に決めます。また、会議体・承認フロー・英語での手順書など、コミュニケーション設計も早めに用意すると手戻りが減ります。
4-3. 更改パターンの選び方
更改にはいくつかの型があり、システムの事情によって向き不向きがあります。各用語と、更改パターンのイメージは以下のとおりです。
・インプレースアップグレード ：同じサーバ上でOSを上げる
・リホスト ：別のサーバへ移して動かす
・リプラットフォーム ：OSやミドルウェアの前提を変えて動かす
・再構築 ：設計からやり直し、移行する
なお、以下4つの判断軸で実際に整えていくことが有効です。
・停止をどれだけ許容できるか
・依存関係がどれだけ強いか
・運用負荷を下げたいか
・将来クラウドへ寄せたいか
上記の判断軸で整理すると、関係者と合意が取りやすくなります。
まとめ｜レガシーOSはリスク把握と段階的な更改で対応しよう
まずはサポート状況を確定し、次に露出面を可視化すると、優先順位が明確になります。
すぐ更改できない場合でも、暫定対策で守り切る設計にしておくと、事故の可能性や被害範囲を下げられます。
最後に、海外拠点を含む環境では、段階的に更改しながら運用と手順を統一していく進め方が現実的です。
海外拠点をまたぐ更改の推進や、暫定対策を含めた運用設計で外部の力が必要な場合は、SYSCOMへご相談ください。グローバル前提のプロジェクト推進やセキュリティ運用メニューなどを提供します。