最大約55.8万人の医療従事者情報が漏えいした可能性のある旭化成「Pharma DIGITAL」事案を、公開された外形から読み解く。静的サイト化で守るべき境界はWebサーバからAPIへ移った――鍵（認証情報）を守るだけでなく、その鍵で開く範囲を狭め、外から触れられる鍵穴そのものを減らす設計を提言する。
2026年10月6日、旭化成セラピューティクスは、医療関係者向け情報提供サイト「Pharma DIGITAL」への不正アクセスを公表しました。
漏えいした可能性がある個人情報は、最大約55万8700人。
大きな数字です。
しかし、公表文を読んで私が最も気になったのは、56万人という人数ではありませんでした。
旭化成は、
「本ウェブサイトに連携する会員データベース」にサイバー攻撃による不正アクセスが確認された
と説明しています。
「データベースへの不正アクセス」と聞くと、攻撃者がDBサーバへ侵入し、SQLを実行して大量のデータを抜いた姿を想像しがちです。
しかし、公開されていたWebの構成を追ってみると、少し違う姿が見えてきました。
攻撃者は、データベースへ直接侵入する必要などなかったのかもしれません。
Pharma DIGITALの公開側を確認すると、Web画面はAWSのCDNとオブジェクトストレージから配信される、JavaScript中心のSPAとして観測できます。
表だけを見ると、
利用者
↓
CDN
↓
静的なHTML / JavaScript
という比較的シンプルな構成です。
静的配信には利点があります。
PHPやCMSのようなWebサーバ側の攻撃面を小さくできるからです。
しかし、Pharma DIGITALは会員サイトです。
ログインする。
利用者によって表示内容を変える。
会員情報を扱う。
こうした処理を、静的なHTMLだけで完結させることはできません。
その先にはバックエンドAPIがあります。
公開されていたJavaScriptを確認すると、サイト自身がバックエンドAPIを呼び出す構成が確認できました。
認証後の処理。
会員情報を扱うAPI。
その先の会員データを仲介する処理。
細かなURLや外部サービス名は、ここでは書きません。
重要なのは、
静的に配信されるJavaScriptから、バックエンドへ向かう経路を読み取れた
ということです。
JavaScriptはログイン前の利用者にも配られます。
つまり、フロントエンドに載せた時点で、そのAPIの存在や大まかな構造は秘密ではありません。
ただし、ここは誤解してはいけません。
APIが見えること自体は脆弱性ではありません。
ブラウザがAPIを呼ぶ以上、その通信先は利用者から観測できます。
本当に重要なのは、
そのAPIを誰が、どこまで使えるのか
です。
会員サイトは、概念的にはこう動きます。
利用者
↓
JavaScript
↓
API
↓
会員データ
利用者が自分のプロフィールを見るとき、ブラウザはAPIへ情報を要求します。
APIが会員データを取得し、その結果を返します。
この構成なら、攻撃者がDB管理者権限を取る必要はありません。
Webサイトが普段使っているAPIを使えば、その先のデータ取得はバックエンドが行ってくれます。
つまり、
DBを破るのではなく、DBを読むために最初から用意されている正規の道を使う。
という形が成立します。
ここで重要なのが、認証と認可の違いです。
認証は、
「あなたは誰ですか」
を確認する仕組みです。
認可は、
「あなたは何をしてよいですか」
を確認する仕組みです。
正しくログインできたとしても、それだけでは十分ではありません。
例えば、一人の会員としてログインした利用者が、APIへ渡すIDや条件を変えるだけで別の会員情報まで取得できたらどうでしょう。
ログイン自体は正常です。
鍵も本物です。
問題は、
その鍵を持つ人に、どのデータまで開けさせるのか
です。
もし一人の会員資格で他の会員まで読めるなら、それはDBの権限よりも、API側の認可の問題です。
旭化成の公表では、最大約51万4000人の氏名、所属施設名、施設住所、職種、診療科などが対象となり、そのうち約4万4000人についてはメールアドレスなども対象とされています。
さらに旭化成従業員約700人の情報も含まれます。
もちろん、この数字だけで認可不備が原因だったとは言えません。
実際の侵入経路も、内部構造もまだ公表されていません。
ただし、
一人の利用者向けのAPIが、その先で大量の会員データにつながっている
という構造は成立します。
だから今回の「会員データベースへの不正アクセス」を、
「DBサーバへ直接侵入された」
とだけ読む必要はありません。
ここはマンションに例えると分かりやすいと思います。
インターネットは公道です。
誰でもマンションの前までは来られます。
その先にオートロックがあり、エレベーターや共用廊下があり、最後に各部屋の玄関があります。
仮に玄関の鍵を盗まれても、オートロックを通れなければ、その鍵を使う場所まで辿り着けません。
攻撃者には、
VPNへ入る。
内部ネットワークへ侵入する。
管理端末を取る。
といった、もう一手が必要になります。
つまり、
鍵を持っていても、鍵穴まで届かなければ使えない。
これも重要な防御です。
一方、インターネットからAPIへ直接到達できる構成では事情が変わります。
正しい認証情報やトークンを持っていれば、攻撃者はサーバへ侵入しなくても、そのAPIを呼ぶことができます。
マンションで言えば、
外から直接、各部屋の玄関前まで来られる
ようなものです。
もちろん、玄関には鍵が掛かっています。
認証と認可が正しければ、それだけで破られるわけではありません。
しかし、鍵を盗まれたときに、その鍵をすぐ試せる。
内部ネットワークへ侵入するという一手間がありません。
さらに、一つの部屋の鍵を持つ人が、共用部の操作盤から他の部屋まで開けられたら、それは鍵の問題ではありません。
「その人が、その部屋を開けてよいのか」を確認していない認可の問題です。
Webでも同じです。
だから防御は三段階で考える必要があります。
まず、
鍵を盗ませない。
パスワード、セッショントークン、APIキー、サービスアカウント。
認証情報の管理です。
次に、
その鍵で開けられる範囲を狭くする。
一人の利用者は一人分。
一般ユーザーは一般ユーザーの機能だけ。
一覧取得、一括操作、管理機能には別の権限を要求する。
オブジェクト単位で認可する。
これが土台です。
そしてもう一つ。
そもそも、外から直接触れられる鍵穴を減らす。
これはURLを秘密にして守る、いわゆるSecurity by Obscurityの話ではありません。
URLはいつか分かります。
重要なのは、
到達可能な攻撃面そのものを減らす
ことです。
例えばブラウザには、
自分のプロフィールを読む。
自分の設定を変更する。
自分向けのコンテンツを取得する。
といった用途限定のAPIだけを見せる。
その先の、
会員全体を検索するAPI。
一括取得。
管理機能。
外部サービスとの連携。
強い権限を持つAPI。
こうしたものまで、ブラウザから直接到達できる場所に置く必要はありません。
BFF、Backend for Frontendのようなサーバ側の層を一枚入れ、
利用者
↓
静的フロント
↓
用途限定のBFF
↓
内部API
↓
会員データ
という形にすれば、ブラウザから見える攻撃面を小さくできます。
強いAPIや資格情報は、その内側へ閉じ込める。
そうすれば、仮に強い鍵が盗まれても、
攻撃者にはまず中へ侵入するという一手が残ります。
今回ここは特に重要だと思いました。
S3やCDNを使ってWebサイトを静的化することは、攻撃面を減らす有効な方法です。
しかし、
静的サイトにしたから安全なのではありません。
Webサーバの攻撃面を減らした結果、
セキュリティの境界がAPIへ移った
と考えるべきです。
会員サイトなら、データを取りに行く入口はどこかに残ります。
そのAPIをどこまで外に出すのか。
誰に何を許すのか。
その先のデータ層とどう分離するのか。
静的化とAPI設計は、セットで考えなければなりません。
今回もう一つ注目したいのが、発覚のきっかけです。
旭化成は10月2日、サイトの運営および情報管理を委託している企業から不正アクセスの報告を受けています。
その後サイトを停止し、
「本件の原因となった不正アクセスの経路は既に是正措置を講じている」
としています。
ただし、具体的な侵入経路や検知方法は公表されていません。
ここは続報で重要になります。
もし攻撃者が認可の弱いAPIを探していたなら、
存在しないIDを試す。
権限のないデータを要求する。
大量の条件を変えて試す。
といった探索の途中で、エラーや不自然なアクセスが出る可能性があります。
つまり、
脆弱性を探す行為そのものがノイズになる。
一方、最初から有効な強い認証情報を持っていた場合は違います。
正しい鍵で、
正しいAPIを、
正しい形式で呼べる。
エラーをほとんど出さず、正常系のアクセスとして大量取得できる可能性があります。
こちらの方が検知は難しい。
だから今後の続報で知りたいのは、
「どの脆弱性だったか」
だけではありません。
最初の異常を、何で検知したのか。
そこです。
旭化成は再発防止策として、
「委託先に対する管理・監督体制のさらなる強化」
を挙げています。
もちろん、委託先の運用管理は重要です。
認証情報をどう管理するのか。
APIキーをどこに置くのか。
管理者権限を誰に与えるのか。
ログをどう監視するのか。
しかし、それだけではありません。
仮に一つの鍵が盗まれたとしても、
その鍵でどこまで開けるのか。
その鍵をインターネットから直接使えるのか。
一般利用者向けのAPIから、どこまで会員データへ届くのか。
管理用、一括取得用、外部サービス連携用のAPIまで、同じ経路から到達できるのか。
開発・検証・本番はどこで分離されているのか。
これは運用だけではなく、
設計の問題です。
委託先管理とは、
「鍵をちゃんと管理してください」
と伝えることではないと思います。
その鍵を失ったとき、どこまで届く設計になっているか。
そこまで委託元自身が理解し、レビューする必要があります。
「鍵を盗ませるな」は運用です。
「鍵を盗まれても56万人へ届かせるな」は設計です。
そして、
その設計を委託先任せにせず、委託元自身が確認し、どこまでリスクを許容するか判断する。
そこがガバナンスです。
今回問われるのは、委託先の管理能力だけではありません。
発注する側が、
認証。
認可。
APIの公開範囲。
ネットワークの境界。
開発・検証・本番の分離。
一つの資格情報を失った場合の最大到達範囲。
こうした設計をどこまで理解し、レビューしていたのか。
そこまで含めて考える必要があります。
最大約56万人という数字は大きい。
しかし、今回の外形を追って私が気になったのは、その人数ではありませんでした。
静的に配られるWebサイトの先に、会員データへつながるAPIの入口があったこと。
そして、その入口がインターネット側にある以上、
守るべきなのは鍵だけではないということです。
鍵を守る。
その鍵で開けられる範囲を狭くする。
そして、
外から直接触れられる鍵穴を減らす。
静的サイトにしたことでWebサーバの攻撃面を減らしても、その先のAPIを広く外へ出していれば、守る場所が移っただけかもしれません。
今回の続報で知りたいのは、
攻撃者がどの鍵を手にしたのか。
どの入口まで外から来られたのか。
そして、
どの境界で、本来止めるべきアクセスを止められなかったのか。
そこです。
Aikido Community Japan
公開日: 2026/10/7
最終更新: 2026/10/7
セキュリティの最新情報をお届けします。