サイバーセキュリティ📖 9分で読了

シンガポールPDPC罰金事例に学ぶ|2026年型セキュリティ失敗の本質と脆弱性基点のシステム開発戦略WAF未導入、RDPインターネット公開、SQLi脆弱性──HR SaaS企業への制裁が示す「基本対策の欠如」という構造的課題

シンガポールPDPC罰金事例に学ぶ|2026年型セキュリティ失敗の本質と脆弱性基点のシステム開発戦略

2026年1月、シンガポールPDPCがHR SaaS企業People Central社に罰金S$17,500と90日以内の是正命令を下した。約12万人分の個人データ漏洩の原因は、高度な攻撃ではなく「基本対策の欠如」──SQLi脆弱性の放置、RDPのインターネット公開、WAF未導入、暗号化不足、脆弱性診断が2年に1回のみという5つの欠陥だった。日本でも情報漏洩事故は4年連続で過去最多を更新(2024年:189件/1,586万人)。PDPCが命じた是正項目はOWASP・CIS準拠であり、日本企業にもそのまま適用できる。セキュリティは「後付け」ではなく「設計段階から組み込む」発想が重要だ。

「セキュリティ事故は"運が悪かった"では済まされない時代」──この言葉を裏付ける事例が、2026年1月に明らかになりました。

シンガポールの個人データ保護委員会(PDPC)は、HR SaaS企業 People Central Pte Ltd に対し、個人データ保護法(PDPA)違反として罰金S$17,500および90日以内の是正命令を下しました。

📄 一次情報(PDPC公式)


事件タイムライン(一次情報準拠)

日付

出来事

2024年4月29日

脅迫メール受信(DB削除・流出を示唆)

2024年5月3日

PDPCへ通知

2026年1月8日

S$17,500の罰金+90日以内の是正命令

出典:PDPC公式決定文書


注目すべきは、この事故の原因が「高度なゼロデイ攻撃」ではなく、SQLインジェクション(SQLi)脆弱性の放置、RDP(リモートデスクトップ)のインターネット公開、WAF(Webアプリケーションファイアウォール)の未導入など、いずれも「基本対策の欠如」だった点です。

本記事では、この事例から日本企業が学ぶべき教訓と、脆弱性を前提としたシステム開発の考え方について解説します。


この記事のポイント

事故原因は「高度な攻撃」ではなく「基本対策の欠如」

  • まず確認すべきは「RDP / WAF / SQLi / 暗号化 / 診断頻度」の5点

  • セキュリティは"後付け"ではなく"設計に組み込む"

  • PDPCが命じた是正項目は、日本企業にもそのまま適用できる


🔐 用語解説(知っておきたい3つのキーワード)

用語

意味

SQLi(SQLインジェクション)

Webアプリの入力欄から悪意あるSQL文を注入し、データベースを不正操作する攻撃

WAF

Web Application Firewall。Webアプリへの攻撃を検知・遮断する防御層

RDP

Remote Desktop Protocol。遠隔操作プロトコル。インターネット公開は高リスク


1. 事例の概要|People Central事件で何が起きたのか

1-1. 事件の経緯

2026年1月8日、シンガポールPDPCは、HR SaaS企業 People Central Pte Ltd に対する制裁を発表しました。同社は人事・給与管理システムをクラウドで提供する企業であり、今回のデータ侵害により以下の被害が発生しました。

項目

内容

影響を受けた個人データ

従業員データ約95,000人分、緊急連絡先・家族データ約24,700人分

漏洩したデータの種類

氏名、ID番号、給与情報、連絡先など

発覚のきっかけ

ダークウェブ流出を示唆する脅迫メールの受信(2024年4月29日)

制裁内容

罰金S$17,500(概算で100万円台後半〜200万円前後※為替により変動)、90日以内の是正措置義務

事故の発端は、外部からの不正アクセスでした。しかし、PDPCの調査で明らかになったのは、攻撃者が特別な手法を使ったわけではなく、基本的なセキュリティ対策の欠如が侵入を許したという事実です。

1-2. PDPCの判断根拠

PDPCは、People Central社が「個人データを保護するための合理的なセキュリティ措置を講じていなかった」と認定しました。これは、PDPA(Personal Data Protection Act)が事業者に求める「Protection Obligation(保護義務)」への違反にあたります。

章末サマリー

People Central事件は、約12万人分の個人データが漏洩したHR SaaS企業へのPDPC制裁事例です。高度な攻撃手法ではなく、基本的なセキュリティ対策の欠如が原因でした。


2. PDPCが問題視した5つの致命的欠陥(SQLi/RDP/WAF/暗号化/診断頻度)

PDPCの決定文書では、以下の5つのセキュリティ欠陥が指摘されています。

2-1. SQLインジェクション脆弱性の放置

SQLインジェクションとは、Webアプリケーションの入力フォームなどから悪意のあるSQL文を送り込み、データベースを不正に操作する攻撃手法です。OWASP(Open Web Application Security Project)が公開する「OWASP Top 10」でも、長年にわたり最も危険な脆弱性のひとつとして挙げられています。

People Central社のシステムでは、入力値の検証やプリペアドステートメント(パラメータ化クエリ)の実装が不十分であり、攻撃者がデータベースに直接アクセスできる状態でした。

2-2. RDP(リモートデスクトップ)のインターネット公開+2FA未実装

RDPは、遠隔地からサーバーやPCを操作するためのプロトコルです。本来は社内ネットワークやVPN経由でのみアクセスを許可すべきですが、People Central社ではRDPがインターネットに直接公開され、かつ2FA(二要素認証)が未実装でした。

これにより、攻撃者はブルートフォース攻撃(パスワード総当たり攻撃)やパスワードスプレー攻撃によって、管理者権限を取得するリスクにさらされていました。

2-3. WAF(Webアプリケーションファイアウォール)の未導入

PDPC決定文書では、People Central社に**WAFが導入されていなかった(did not have a WAF)**ことが明記されています。WAFは、Webアプリケーションへの攻撃を検知・遮断するセキュリティ製品であり、SQLインジェクションなどの一般的な攻撃パターンを防ぐ「防御層」として機能します。

2-4. 個人データの暗号化不足

データベースに保存された個人データが十分に暗号化されておらず、不正アクセスによって平文のまま情報が取得されるリスクがありました。

2-5. 脆弱性スキャンが2年に1回(侵入テスト未実施)

PDPCの調査では、People Central社の脆弱性スキャンは2年に1回しか実施されておらず、定期的なセキュリティ診断や侵入テスト(ペネトレーションテスト)が不足していたことが指摘されました。

指摘された欠陥

リスク

SQLi脆弱性の放置

データベースの不正操作・情報窃取

RDPのインターネット公開+2FA未実装

管理者権限の不正取得

WAFの未導入

攻撃の検知・遮断ができない

個人データの暗号化不足

漏洩時のデータ保護ができない

脆弱性スキャン2年に1回

脆弱性の発見・修正が遅れる

章末サマリー

PDPCが指摘した5つの欠陥は、いずれも「基本対策」に分類されるものです。高度な攻撃手法への対応以前に、基本的なセキュリティ措置が講じられていなかったことが問題視されました。


3. PDPCが命じた「90日でやれ」是正リスト

PDPCはPeople Central社に対し、90日以内に以下の是正措置を完了するよう命じました。この是正項目は、日本企業にとっても「最低限やるべきこと」のチェックリストとして活用できます。

📄 一次情報(PDPC公式)

📋 PDPCが命じた是正項目(一次情報準拠)

#

是正項目

補足

1

OWASP等のベストプラクティスに沿ったWebアプリの見直し

SQLi対策、入力検証の強化

2

適切に設定されたWAFの導入

攻撃検知・遮断の仕組み構築

3

年次の外部/内部ペネトレーションテスト完了

年1回以上の侵入テスト義務化

4

RDPアクセスへの2FA実装

二要素認証の必須化

5

全個人データフィールドの暗号化

DBレベルでの暗号化徹底

6

完了報告の提出

PDPCへの履行証明

出典:PDPC公式決定文書(2026年1月8日)

これらの項目は、CIS Controls(Center for Internet Security)やOWASPのベストプラクティスとも整合しており、グローバルスタンダードに沿った内容です。

章末サマリー

PDPCが命じた6つの是正項目は、OWASP準拠のWebアプリ見直し、WAF導入、年次ペンテスト、2FA、暗号化など。日本企業にとっても「最低限やるべきこと」のベンチマークになります。


4. 日本企業にとって「他人事ではない」理由

4-1. 国内のセキュリティ事故は増加傾向

東京商工リサーチの調査(2025年1月21日発表)によると、2024年に上場企業とその子会社が公表した個人情報の漏洩・紛失事故は189件(前年比8.0%増)で、調査開始以来4年連続で過去最多を更新しました。漏洩した個人情報は1,586万人分に上ります。

原因別では「ウイルス感染・不正アクセス」が114件(構成比60.3%)と最多であり、People Central事件と同様のサイバー攻撃が日本企業でも頻発していることがわかります。

4-2. IPAが警鐘を鳴らす10大脅威

IPA(情報処理推進機構)が2025年1月30日に発表した「情報セキュリティ10大脅威 2025」では、組織向け脅威の上位に以下がランクインしています。

順位

脅威

選出状況

1位

ランサム攻撃による被害

5年連続1位

2位

サプライチェーンや委託先を狙った攻撃

3年連続2位

3位

システムの脆弱性を突いた攻撃

5年連続選出

6位

リモートワーク等の環境や仕組みを狙った攻撃

5年連続選出

People Central事件で指摘されたRDPのインターネット公開は、まさに6位の「リモートワーク等の環境を狙った攻撃」に該当します。また、SQLi脆弱性は3位の「システムの脆弱性を突いた攻撃」の典型例です。

4-3. 日本企業に多い「構造的な課題」

多くの日本企業が陥りやすいパターンとして、以下のような判断があります。

よくある判断

実際のリスク

「開発スピード優先」

セキュリティ設計が後付けになり、脆弱性が残存

「SaaSだから大丈夫」

データ管理責任は事業者側にあり、委託先の事故でも責任を問われる

「WAFは後で導入する」

攻撃は待ってくれない。侵入は「今日」起きる可能性がある

「開発会社任せ」

運用・保守責任は自社にあり、委託先の対策状況を把握していない

章末サマリー

日本国内でも情報漏洩事故は4年連続で過去最多を更新しています(2024年:189件/1,586万人分)。IPAの10大脅威でも、People Central事件で指摘されたものと同種の脅威が上位にランクインしており、国内企業にとっても「他人事」ではありません。


5. 脆弱性基点のシステム開発という考え方

5-1. 「完成後にセキュリティを足す」発想の限界

多くの企業が陥る誤りは、システム開発の完了後にセキュリティ対策を「追加」しようとすることです。しかし、この発想には限界があります。

設計段階でセキュリティを考慮していないシステムでは、後から脆弱性を塞ごうとしても「パッチワーク」になりがちです。根本的な設計の問題は、表面的な対策では解決できません。

5-2. 脆弱性を前提とした設計

「脆弱性基点のシステム開発」とは、攻撃されることを前提に、検知・遮断・復旧の仕組みをアーキテクチャレベルで組み込む考え方です。

具体的には、以下のようなアプローチが含まれます。

要件定義段階

  • 脅威モデリングの実施(想定される攻撃パターンの洗い出し)

  • セキュリティ要件の明文化

設計・開発段階

  • WAF・認証・権限設計をアーキテクチャに内包

  • 入力値検証、プリペアドステートメントの標準化

  • ログ設計(不正アクセスの検知に必要な情報の収集)

運用段階

  • 年次の外部/内部ペネトレーションテスト(PDPCも年1回以上を命令)

  • 四半期ごとの脆弱性スキャン(CIS Controlsでも推奨)

  • インシデント対応手順の整備

5-3. SQLi対策の"最低限セット"(OWASP準拠)

PDPCの是正命令でも言及された「OWASPベストプラクティス」に沿ったSQLi対策の基本は以下の通りです。

対策

説明

パラメータ化クエリ(Prepared Statements)

SQLi対策の最も効果的な方法。入力値がSQL文として解釈されることを防ぐ

入力バリデーション(許容リスト方式)

許可された値のみを受け入れる設計

権限最小化

DBユーザー権限を必要最小限に制限

WAFの導入

補助的な防御層として機能(万能ではない点に注意)

参考:OWASP SQL Injection Prevention Cheat Sheet

5-4. 開発委託時に確認すべきポイント

システム開発を外部に委託する場合、以下の点を確認することが重要です。

  • 開発会社のセキュリティ体制(開発環境のセキュリティ、要員管理など)

  • セキュアコーディング規約の有無と遵守状況

  • 脆弱性診断の実施有無とタイミング

  • 納品後の保守・運用体制

💡 GXOのアプローチ

GXO株式会社は開発・運用を前提に「RDP / WAF / ログ / 権限」を設計に埋め込むアプローチを採用しています。後付け対応と比較して、総コストを抑えやすく、運用開始後のセキュリティリスクを低減できます。

章末サマリー

セキュリティは「後付け」ではなく「設計段階から組み込む」ことが重要です。OWASP準拠のSQLi対策、年次ペンテスト、四半期スキャンなど、PDPCが命じた是正項目を"最初から"実装することで、事故リスクを大幅に低減できます。


6. 今すぐ見直すべき5つのチェックポイント

自社のセキュリティ対策を点検するため、以下の5項目を確認してください。

✅ チェック1:RDPや管理画面がインターネットに露出していないか

RDPやSSH、管理画面などがインターネットから直接アクセスできる状態は、攻撃者にとって格好の標的です。VPNや踏み台サーバー経由でのアクセスに限定し、2FA(二要素認証)を必須化しましょう。

✅ チェック2:WAFは「導入している」ではなく「導入済み&適切に設定」か

WAFを導入していても、設定が不十分であれば効果を発揮しません。そもそもWAFが未導入の場合は、早急に導入を検討してください。

✅ チェック3:個人データはDBレベルで暗号化されているか

データベースに保存される個人データが暗号化されていれば、万が一データが流出しても情報の悪用リスクを低減できます。全フィールドの暗号化と鍵管理の状況を確認しましょう。

✅ チェック4:年1回以上の侵入テストを実施しているか

PDPCも「年次の外部/内部ペネトレーションテスト」を命じています。2年に1回では不十分です。発見された脆弱性を速やかに修正する体制が整っているかも確認しましょう。

✅ チェック5:開発会社任せになっていないか

システム開発を外部に委託している場合、委託先のセキュリティ対策状況を把握していますか?契約書にセキュリティ要件が明記され、定期的な報告を受けているか確認しましょう。

1つでも不安がある場合は、People Central社と同様の事故リスクを抱えている可能性があります。

章末サマリー

5つのチェックポイント(RDP露出+2FA、WAF導入、暗号化、年次ペンテスト、委託先管理)のいずれかに不安がある場合、専門家への相談をおすすめします。


7. まとめ|事故を起こさせない設計のために

People Central事件が示しているのは、セキュリティ事故の多くは「高度な攻撃」ではなく「基本対策の欠如」によって起きるという事実です。

本記事のポイント

  1. PDPCが指摘した5つの欠陥は、いずれも「基本対策」の範疇

    • SQLi脆弱性、RDP公開+2FA未実装、WAF未導入、暗号化不足、スキャン頻度不足

  2. 日本企業でも同様の事故リスクが高まっている

    • 情報漏洩事故は4年連続で過去最多を更新(2024年:189件/1,586万人分)

    • IPAの10大脅威でも同種の脅威が上位にランクイン

  3. PDPCが命じた是正項目は、日本企業にもそのまま適用できる

    • OWASP準拠のWebアプリ見直し、WAF導入、年次ペンテスト、2FA、全フィールド暗号化

  4. 「脆弱性基点」の設計思想が重要

    • 攻撃されることを前提に、検知・遮断・復旧を設計段階から組み込む

    • 後付け対応より総コストを抑えやすい

セキュリティ対策は、「事故が起きてから対応する」のではコストも信用回復も莫大になります。事故を起こさせない設計という発想で、システム開発・運用に取り組むことが求められています。


お問い合わせ

⚠️ こんな状況なら、優先度は高いです

  • 管理画面やRDP/SSHの入口が増えた

  • WAFはあるがチューニングしていない(または未導入)

  • 脆弱性診断が年1回未満


💬 30分で「露出リスク」をフィードバック(無料相談)

GXO株式会社では、システム開発とセキュリティを一体で設計するアプローチを重視しています。

  • 既存構成のヒアリング

  • RDP / WAF / 認証設計の露出リスクを口頭でフィードバック

  • 新規開発時のセキュリティ設計相談

まずは30分のオンライン相談からお気軽にどうぞ。

👉 無料相談を予約する


FAQ

Q1. People Central事件の罰金額は、日本円でいくらですか?

A. 罰金額はS$17,500で、概算で100万円台後半〜200万円前後です(為替レートにより変動)。ただし、金額以上に重要なのは、90日以内の是正措置義務と、事故公表による信用低下のリスクです。

Q2. SQLインジェクション対策として、具体的に何をすればよいですか?

A. OWASPが推奨する対策として、最も効果的なのは「プリペアドステートメント(パラメータ化クエリ)」の使用です。これにより、ユーザー入力がSQL文として解釈されることを防ぎます。また、入力値のバリデーション(許容リスト方式)、DBユーザー権限の最小化、WAFの導入も併せて実施することが推奨されます。

Q3. 小規模なSaaSでも、同様の制裁を受ける可能性はありますか?

A. 企業規模に関わらず、個人データを取り扱う事業者は法令上の保護義務を負います。日本の個人情報保護法でも「安全管理措置」が求められており、漏洩事故が発生した場合は報告義務や行政指導の対象となる可能性があります。

Q4. 侵入テストはどのくらいの頻度で実施すべきですか?

A. PDPCはPeople Central社に対し「年次の外部/内部ペネトレーションテスト」を命じています。CIS Controlsでも年1回以上の侵入テストと、四半期ごとの脆弱性スキャンが推奨されています。「2年に1回」ではリスクを見逃す可能性が高いため、最低でも年1回の実施をおすすめします。

Q5. 開発を外部委託している場合、責任はどちらにありますか?

A. 法的には、データの管理責任は委託元(発注者)にあります。委託先でセキュリティ事故が発生した場合でも、委託元は適切な監督義務を果たしていたかを問われます。契約時のセキュリティ要件明確化と、定期的な監査・報告が重要です。


参考資料

この記事についてもっと詳しく知りたい方へ

GXOでは、サイバーセキュリティに関する詳しい資料を無料で提供しています。導入事例や成功事例、具体的な導入手順を詳しく解説しています。