タイの社内システムのハッキング対策と体制づくり

2026 年 10 月 21 日、PHP に重大な脆弱性が 2 件見つかり、修正版が日本時間の 23:00 (タイ時間 21:00) に公開されました。ログインしていない第三者にサーバー上でプログラムを実行される恐れがあるもので、当社が保守しているシステムでは、公開前に設定面の緩和策を入れ、公開後に順次更新しました (対応の報告)。

こうした緊急対応で手間取るのは、パッチを当てる作業そのものより、その前の確認です。どのサーバーで PHP が動いているのか。誰がそのサーバーを触れるのか。サイトを止めるかどうかを誰が決めるのか。答えがすぐに出ない会社ほど、夜のリリースに間に合いません。

Verizon が毎年公開している情報漏えいの調査 (2026 年版 DBIR) では、侵入のきっかけで一番多かったのが脆弱性の悪用で、全体の 31% でした。一方、悪用が確認されている重大な脆弱性のうち、完全に修正まで終わっていたのは 26% で、修正にかかった日数の中央値は 43 日です。攻撃する側が速くなる一方で、守る側の対応は追いついていません。

人に起因するリスク

同じ調査では、侵害の 62% に人の行動が関わっていました。メールのリンクを開いた、パスワードを使い回していた、設定を間違えた、といったものです。脆弱性を突かれた場合でも、そのあと被害が広がるかどうかは、人がどんなアカウントと権限を持っていたかで変わります。

タイの拠点でよく見かけるのは、次のような状態です。

• サーバーやクラウドの管理者アカウントを、社内の担当者と外部ベンダーで共有していて、パスワードが LINE で回っている
• 辞めた社員や、契約の終わったベンダーのアカウントが残ったままになっている
• 普段のメールやブラウザの作業を、管理者権限のアカウントで行っている
• 日本語・タイ語・英語のメールが混ざっていて、なりすましに気付きにくい

人はいつか間違えます。対策は、間違えても被害が広がらない作りにすることです。アカウントは一人に一つにして共有をやめる。管理者のアカウントには多要素認証を必ず付ける。退職や契約終了のときにアカウントを止める手順を決めておく。どれも新しい製品を買わずに始められます。

侵入後の横移動 (ピボット)

攻撃者は、最初に入り込んだサーバーをゴールにしません。そこを足場にして、同じネットワークにあるほかのサーバーへ移っていきます。これを横移動、あるいはピボットと呼びます。

たとえば、公開サイト、顧客データの入ったデータベース、社内の共有ファイルが 1 台のサーバーに同居していたとします。今回の PHP のような脆弱性で公開サイトに入られると、攻撃者は同じサーバーにあるものすべてに手が届きます。設定ファイルにメールや基幹システムのパスワードが書かれていれば、そこからさらに別のシステムへ進めます。

役割ごとにサーバーを分け、間の通信を必要なものだけに絞っておけば、公開サイトが破られても被害はそのサーバーの中で止まります。

サーバーの分け方

基本は、外から見えるものと、社内だけで使うものを同じ場所に置かないことです。そのうえで、次の点を確認します。

• 公開サイトのサーバーからデータベースへは、決めた接続元と決めたポートだけを通す
• 公開サイトのサーバーに、ほかのシステムの管理者パスワードや鍵を置かない
• サーバーの管理用の接続 (SSH やリモートデスクトップ) は、インターネットから直接つなげない
• バックアップは別の場所に置き、本番のサーバーから消せない形にする

クラウドなら小さなサーバーを分けて置けるので、分けることのハードルは以前より下がっています。気を付けたいのは共用のレンタルサーバーです。今回の PHP のように、事業者が更新するまで自分では手を出せません。顧客データや業務データを扱うシステムは、自分たちで更新できる場所に置くことをおすすめします。

役割ごとのアクセス権限

横移動を防ぐ考え方は、人のアカウントにもそのまま当てはまります。一人のアカウントが乗っ取られたとき、攻撃者が触れるのは、そのアカウントが触れるものすべてです。全員がすべてのサーバーと共有フォルダに入れる状態では、誰か一人のミスが会社全体の被害になります。

そこで、サーバーへのアクセスや共有ファイルの権限は、個人ごとではなく、仕事の役割ごとのグループに付けます。人には、どのグループに入るかだけを設定します。たとえば次のような形です (記入例)。

グループで管理しておくと、入社、異動、退職のときは所属するグループを変えるだけで済み、権限の付け忘れや消し忘れが減ります。タイの拠点は人の入れ替わりが多く、外部ベンダーや日本本社の担当者もアクセスするので、個人ごとに権限を付けていくと、すぐに誰が何に入れるのか分からなくなります。年に一度はグループの中身を見直し、もう使っていない権限を外します。

システム全体の把握

ここまでの対策を決めて動かすには、システムとインフラの全体が見えている必要があります。どのサーバーに何が載っているかだけでは足りません。ログインの認証をどこが担っているのか。社内の誰がどの情報を持って仕事をしているのか。どのシステムが、どのベンダーとどうつながっているのか。そこまでが一つの絵になっていることが大切です。

台帳にすると、たとえば次のような形です (記入例)。

この例からは、いくつか弱いところが見えてきます。コーポレートサイトは更新の対象から外れた PHP 8.1 で動いていて、共用サーバーなので自分では更新できません。会計システムは独自の ID でログインするので、退職した人の Microsoft 365 を止めても、会計システムには入れたままになります。開発会社は VPN で社内につながっているので、開発会社のアカウントが破られれば、そこが入口になります。

この全体を、決定権のある人が把握していることが重要です。今回のリリースはタイ時間の 21:00 でした。どのシステムが影響を受け、止めると誰の仕事が止まり、どのベンダーに連絡すればよいのか。それが分かっている人が判断すれば、夜でも迷わずに動けます。全体を知らない人が判断を担っていると、緊急時は確認に時間を取られ、普段の運用でも権限やベンダーの接続がいつの間にか増えていきます。対策を一つずつ足していくより、決定権のある人が全体を把握したうえで守る順番を決めるほうが、限られた予算と人で守れる範囲は広がります。

当社では、タイで稼働しているシステムの診断から、サーバー構成の見直し、アクセス権限の整理、システムとインフラの全体図づくりまでをお手伝いしています。自社のシステムの全体像がつかめていない段階でも、セキュリティ診断とアドバイザリからご相談ください。あわせて、タイ進出日系企業が見落としやすいサイバーセキュリティの 7 つの盲点もご覧ください。