株式会社N.H.R
株式会社N.H.R
2026年、日本国内の企業やサービスにおいて、大規模な個人情報の漏えい、あるいは漏えいの可能性が相次いで報じられている。
焼肉きんぐなどを展開する物語コーポレーション、カラオケのビッグエコーを展開する第一興商、タイムズカーを運営するパーク24など、一般消費者にとって身近なサービスも例外ではない。
報道等で示された影響規模を整理すると、次のようになる。
| 企業・サービス | 影響規模（概数） |
|---|---|
| 物語コーポレーション／焼肉きんぐ等 | 約1,078万件 |
| 第一興商／ビッグエコー | 約872万件 |
| パーク24／タイムズカー | 約660万件 |
| ローソンID | 約215万件 |
| MrMax | 約173万件 |
| Helpfeel／Gyazo | 約2,362万件 |
※上記は報道等で示された影響規模の概数であり、流出が確認された件数と、流出した可能性がある件数を区別する必要がある。掲載前に各社の最新の公式発表との照合が必要である。
これほど大きな規模の顧客情報が、一度のセキュリティインシデントによって危険にさらされること自体、システム設計の観点から考える必要がある。
一般的なセキュリティ対策では、外部からの不正アクセスをどう防ぐか、マルウェアへの感染をどう防ぐか、認証情報をどう保護するか、といった「侵入防止」に重点が置かれやすい。
もちろん、これらは重要な対策である。
しかし、ここで別の問いを立てたい。
仮に侵入を許してしまったとして、なぜ数百万件もの顧客情報に到達できてしまうのだろうか。
そして、もう一つ。
侵入を完全に防げなかったとしても、大量流出という結果を防ぐシステムは設計できないのだろうか。
本稿では、この二つの問いを起点に、外部公開API、担当者PC、システム間連携という三つの経路から、大規模流出を防ぐためのシステム設計を考える。
不正アクセスによって顧客情報が流出したという報道では、「どこから侵入されたのか」に注目が集まる。
脆弱性を悪用されたのか。認証情報を盗まれたのか。担当者のPCがマルウェアに感染したのか。
侵入経路を特定し、同じ手口を防ぐことは当然必要だ。
しかし、侵入に成功したことと、数百万件のデータを取得できることは、本来同義ではない。
例えば、ある担当者のPCが乗っ取られたとする。
その担当者が業務上扱う100件の顧客情報しか参照できなければ、攻撃者が正規の認証情報を悪用しても、少なくともその権限から直接到達できる範囲は限定される。
一方、その担当者の権限で全顧客情報を検索・出力できるなら、同じ一台のPCの侵害が数百万件の情報流出につながり得る。
両者の違いは、侵入防止製品の性能ではない。
侵害された権限に、どこまでのデータアクセスを許していたかという設計の違いである。
図1：侵入経路が違っても、被害を限定する設計は共通
この視点に立つと、セキュリティ対策の評価基準も変わってくる。
「不正アクセスを防げるか」という問いに加えて、「不正アクセスを許した場合、どれだけの情報が危険にさらされるか」を考えなければならない。
現代のWebサービスでは、APIを外部に公開することは珍しくない。
スマートフォンアプリ、会員サービス、ECサイト、予約システムなど、多くのサービスがAPIによる通信を前提としている。
APIは、利用者にとって便利なサービスを実現するための重要な仕組みだ。
したがって、セキュリティを強化するためにAPIを閉じればよい、という話ではない。
問題は、APIを公開していることではなく、そのAPIを通じてどの範囲の情報を取得できる設計になっているかである。
例えば、顧客情報を取得するAPIがあるとする。
一度の呼び出しで取得できる情報を1件に制限することは、比較的容易に実現できる。
しかし、それだけでは十分ではない。
顧客IDを任意に指定できる仕組みであれば、攻撃者はIDを変更しながらAPIを繰り返し呼び出すことで、大量の情報を取得できる可能性がある。
単純な件数制限やレート制限だけでは、時間をかけた情報収集を防ぎきれない。
必要なのは、取得件数の制限に加えて、誰が、誰の情報を取得できるのかをサーバ側で強制することだ。
図2：取得件数の制限と、アクセス可能な範囲の制御
例えば、一般利用者向けAPIであれば、リクエストに含まれる顧客IDを無条件に信用するのではなく、認証済みの利用者情報からアクセス可能なデータを決定する。
さらに、データベース側でも行単位・列単位のアクセス制御を適用できれば、アプリケーション側の実装ミスによる影響も抑えやすくなる。
もう一つ考えたいのが、大量データの取得機能をどこに配置するかという問題だ。
通常の会員サービスで、一般利用者が全会員情報を取得する必要はない。
それにもかかわらず、管理機能やバッチ処理の都合で、同じアプリケーションや認証情報から大量データを取得できる設計になっていれば、侵害時の被害範囲は広がる。
通常のAPIと大量エクスポート処理を分離し、それぞれ異なる権限を与える。
必要であれば、全件出力には別の実行環境や追加認証、承認手続きを設ける。
こうした構成は、決して新しい技術ではない。
既存の認証・認可機構、データベースのアクセス制御、アプリケーションの権限分離によって実現できる。
重要なのは、利用者の利便性を損なわず、通常のサービスが必要としない強大な権限を取り除くことである。
外部公開APIだけが侵入経路ではない。
担当者や委託先のPCがマルウェアに感染し、認証情報や業務システムへのアクセス権限が悪用されるケースも考えられる。
この場合、攻撃者は外部から不正な通信を送り込むのではなく、正規の担当者になりすまして操作できる可能性がある。
VPNへの接続に成功し、正規の業務アプリケーションへログインできたとしても、その操作が正当であるとは限らない。
ここでも問うべきなのは、侵害されたPCからどこまでアクセスできるかという点だ。
例えば、顧客対応を担当する社員が、日常業務で必要とするのは自分が担当する顧客の情報だけかもしれない。
その担当者が、全顧客情報を一括ダウンロードできる必要はあるだろうか。
管理画面にCSV出力機能があるからといって、すべての担当者にその機能を使わせる必要はない。
担当者ごとに参照可能な顧客を制限する。
一括出力機能は別の権限に分離する。
業務PCからデータベースへの直接接続を認めず、業務アプリケーションを通じてアクセスさせる。
さらに、通常とは異なる大量の参照操作を検知できるようにする。
これらを組み合わせることで、PCの侵害が直ちに全顧客情報の流出につながる構造を避けられる。
ただし、PC自体に大量の顧客情報が保存されている場合、その情報は別途危険にさらされる。サーバ側の権限制御とともに、端末へ保存するデータの範囲も考慮しなければならない。
VPNは、安全な通信経路を確保するための技術だ。
しかし、VPNで接続できたからといって、その利用者や端末にすべての情報へのアクセスを認める必要はない。
ネットワークへの接続権限と、業務データへのアクセス権限は別のものとして設計すべきだ。
担当者PCの感染を完全に防げないとしても、その一台から全顧客情報を取得できるシステムである必要はない。
この考え方は、社内の担当者だけでなく、業務委託先や外部の保守担当者にも当てはまる。
企業の情報システムは、一つのアプリケーションだけで完結しているとは限らない。
ECサイト、会員管理、ポイント管理、CRM、販売管理など、複数のシステムが情報を交換している。
こうしたシステム間連携では、サービスアカウントやAPIキーを利用して、自動的にデータを取得・更新することが多い。
問題は、その連携用アカウントにどこまでの権限を与えているかだ。
例えば、ポイント管理システムが必要とするのは、会員ID、購入情報、ポイント残高などに限られる場合がある。
それにもかかわらず、連携の容易さを優先して顧客データベース全体の参照権限を与えていれば、連携先の侵害が広範囲の情報流出につながる可能性がある。
ここで考えられる対策は、連携先ごとにアカウントを分離し、必要な項目とレコードだけにアクセスを限定することだ。
データベースのVIEW、行・列単位の権限制御、用途別のAPIなど、既存技術を組み合わせれば実現できる。
また、システム間連携の方式そのものを見直す余地もある。
ポイント管理システムが顧客DB全体を自由に検索する代わりに、購入やポイント更新が発生したとき、必要な情報だけを連携元から通知する方式が考えられる。
図3：全件参照型の連携と、必要なデータだけを通知する連携
この方式なら、日常的な処理のために連携先へ全件参照権限を与える必要がなくなる。
もちろん、イベント通知方式にすればすべて解決するわけではない。
連携先が停止している間のデータを保持する仕組みや、再送処理、重複処理への対応、差分再同期などが必要になる。
即時に整合性が必要な業務では、同期型APIの方が適切な場合もある。
大切なのは、特定の方式を採用することではなく、業務上必要な可用性を維持しながら、連携先に渡す権限とデータを最小限にすることである。
ここまでの対策を整理すると、侵入経路は違っても、考え方は共通している。
| 侵害される対象 | 見直すべき設計 | 目指す状態 |
|---|---|---|
| 外部公開API | 認証済み利用者ごとのアクセス範囲、取得件数、全件出力権限 | 一般利用者の権限で他人の情報を取得できない |
| 担当者PC | 担当範囲、業務権限、端末保存、一括出力権限 | 一台のPCの侵害が全顧客情報の流出につながらない |
| システム間連携 | サービスアカウント、データ項目、連携方式 | 一つの連携先に顧客DB全体の参照権限を与えない |
いずれも、侵入そのものを完全に防ぐ技術ではない。
しかし、侵害された一つの権限から到達できる情報を限定することで、被害の規模を抑えるための設計である。
セキュリティ対策を強化すると、サービスの利便性が低下する。
そのような印象を持たれることは少なくない。
しかし、今回取り上げた対策の多くは、一般利用者の操作を複雑にするものではない。
APIが取得するデータの範囲をサーバ側で制限しても、利用者が必要な情報を正しく取得できるなら、通常の操作性は変わらない。
担当者の業務権限を適切に分離しても、必要な業務を遂行できるなら、日常の作業を妨げるものではない。
システム間連携についても、適切な認証・認可と連携方式を選べば、全件参照権限を常時与えなくても業務を成立させられる場合がある。
もちろん、権限分離を細かくしすぎれば運用が複雑になるし、必要なデータまで取得できなくなれば業務に支障が出る。
したがって、単純に制限を増やせばよいという話ではない。
必要な機能は維持し、不要な権限だけを取り除く。
そのために、業務要件とシステム構造を理解したうえで、どこにアクセス制御を設けるべきかを判断する。
これこそがシステム設計の役割ではないだろうか。
ファイアウォール、WAF、EDR、認証基盤、監視製品など、侵入を防止・検知するための技術は進化している。
それらの導入は重要であり、否定されるべきものではない。
しかし、どれほど対策を重ねても、脆弱性の悪用、認証情報の窃取、内部端末の侵害など、すべてのリスクをゼロにすることは難しい。
そこで、セキュリティ対策の評価にもう一つの基準を加える必要がある。
「一つのアカウント、一台の端末、一つの連携システムが侵害された場合、最大で何件の顧客情報が取得され得るのか」
この問いに答えられるだろうか。
例えば、100万人分の顧客情報を管理するシステムで、一般利用者の認証情報が一つ盗まれた場合、取得できるのは本人の情報だけなのか。
担当者のアカウントが侵害された場合、担当顧客の情報だけなのか、それとも全顧客情報なのか。
連携用サービスアカウントが侵害された場合、連携業務に必要な情報だけなのか、データベース全体なのか。
この違いは、セキュリティインシデントが発生した際の被害規模を大きく左右する。
さらに、アクセス可能な範囲だけでなく、短時間に大量のデータが取得された際に検知・遮断できるか、正規の大量出力処理と異常な操作を区別できるか、といった点も重要になる。
アクセス権限の分離は、攻撃者が別の権限を奪ったり、アプリケーションやDBの脆弱性を突いたりする可能性まで消すものではない。
それでも、侵害された一つの権限から到達できる情報量を小さくしておくことには、明確な意味がある。
今回取り上げた技術は、決して目新しいものではない。
認証と認可の分離、ロールベースのアクセス制御、データベースのVIEW、行単位のアクセス制御、サービスアカウントの分離、メッセージキュー、監査ログ。
いずれも、長年利用されてきた技術や考え方だ。
新しいセキュリティ製品を導入することで解決できる問題もある。
しかし、既存システムの権限設計やデータの受け渡し方を見直すことで、被害を限定できる問題もある。
複雑な仕組みを追加する前に、そもそも通常の業務に必要のないアクセス権限が残っていないかを確認する。
全件取得が必要な業務があるなら、その権限を日常的な処理から分離できないか検討する。
外部公開API、担当者PC、システム間連携という異なる経路に対しても、基本的な考え方は共通している。
侵入を許した場合に、攻撃者が到達できるデータの範囲をできる限り小さくする。
不正アクセスを防ぐ技術と、侵入後の被害を抑える設計は、どちらか一方を選ぶものではない。
両方が必要なのだ。
大規模な個人情報流出が報じられるたびに、新たな攻撃手法や脆弱性への対策が議論される。
もちろん、それは必要なことだ。
しかし、今後はもう一歩踏み込んで考えるべきではないだろうか。
なぜ一つの侵害から、数百万件もの情報に到達できてしまうのか。
それは、システムの設計によって防げる問題ではないのか。
利用者に不便を強いることなく、既存の技術を適切に組み合わせることで、侵害時の被害を抑えられる余地はある。
セキュリティ対策を、侵入を防ぐための製品や機能の積み重ねとしてだけ捉えるのではなく、侵入された後の被害範囲まで含めたシステムアーキテクチャとして考える。
相次ぐ大規模な情報流出は、そうした基本設計を改めて問い直す機会でもある。
「侵入させない」だけでなく、「侵入されても大量に持ち出させない」。
この二つを両立することが、これからの情報システムに求められる重要な設計要件の一つではないだろうか。
※本稿は公開情報をきっかけとして、情報システムの設計上の課題を考察したものです。個別の企業について、特定の侵入経路やシステム構成を断定するものではありません。