GMOの在宅勤務廃止は間違っていない？ ワサビのインシデントから考える企業防衛：侵入口は自宅ルーター

GMOインターネットグループの在宅勤務制度見直しをきっかけに、テレワークの是非が改めて議論されている。そうした中、ワサビが公表した不正アクセスでは、自宅の開発環境が侵入口となったことが判明した。この事例は、テレワークの危険性を示したものなのか。

[有限会社オングス,田渕聖人，＠IT]

　ワサビは2026年7月7日、開発環境端末への外部からの不正アクセスに関するセキュリティインシデントの調査結果を公表した。APIキーや管理者アカウント情報などが窃取されたが、顧客の個人情報や機密情報の漏えい、不正利用は確認されなかったという。同社は侵入経路や原因、実施した対策を詳細に公開している。

APIキーも窃取　それでも顧客情報流出を免れた理由

　不正アクセスは2026年7月4日に発生した。攻撃対象となったのは開発環境端末上で稼働していた「MySQL」データベースと「Redis」キャッシュサーバだった。攻撃者はデータベース内の情報を外部送信した後、データを削除し、ランサムノートを残した。

　流出した注文情報や顧客情報は、いずれもテスト用途で作成したダミーデータだった。実在する顧客の個人情報は含まれていなかったとしている。

　窃取された情報には、一部のAPIキーやアプリケーションID、テストデータ、ワサビ管理者アカウント情報が含まれていた。管理者アカウントのパスワードはソルト付きSHA-256でハッシュ化されており、平文では保存されていなかった。同社は全管理者アカウントを停止した上でパスワードを変更し、二次被害の防止を図った。

　また、窃取された情報には本番環境でも利用していたAPIキーとアプリケーションIDの一部が含まれていた。このためAPIキーは再発行するとともに旧キーを無効化した。不正利用は確認されていないという。

　アプリケーションIDについても再発行を開始した。対象となるAPIは「Luxclusif」「ヤフーショッピング」「併売ヤフオク」「競りナビ」「UPS」「Shopify」「Walmart」だった。

　同社は「アプリケーションIDだけでは注文情報や商品情報にアクセスできず、利用者が不審なサイトでOAuth認証を許可しない限り情報が取得されることはない」と説明している。

　攻撃者はデータ窃取後、Redisの設定を書き換えて暗号資産マイニングを試みた。しかし対象環境はコンテナ内で隔離され、実行ファイルも存在しなかったため、マイニングは実行されず、システムへの被害も発生しなかった。

　アプリケーションIDの再発行後は、利用者側で各モールの設定画面から再認証が必要になる。実施方法や日程は決まり次第案内するとしている。

侵入口は自宅の開発環境だった　Dockerとルーター設定が招いた事故

　同社によると、不正アクセスの原因は複数の設定不備が重なったことだった。

　まず、「Docker」コンテナのデータベースポートがローカル接続限定ではなく、外部から接続可能な状態になっていた。さらに、開発端末を接続していた自宅ルーターでも設定とファームウェアの不具合によって当該ポートが外部公開されていたという。攻撃者は公開ポートを探索するbotによって対象を発見し、不正アクセスに成功したとしている。

　インシデント発生後、同社は攻撃元の特定や影響調査を開始するとともに、管理者アカウント停止やセッション無効化を実施した。その日のうちにAPIキーなど緊急性の高い認証情報を再発行して無効化し、ソースコードの修正も完了した。その後、アプリケーションIDの再発行や管理者パスワードの変更を進めている。

　同社は再発防止策として、Docker公開ポートを127.0.0.1に限定して外部接続を遮断する他、MySQLやRedisの認証情報を定期的に更新した。開発用データに含まれるパスワードハッシュや認証情報はダミー値に置き換え、本番環境との関連付けを排除した。対象ルーターではUPnP機能を無効化し、ポート転送設定を削除する。開発担当者全員の端末に対して侵入テストを実施し、外部のセキュリティ専門企業による監査も受ける予定だ。

〜記者の目：問われるのは在宅勤務ではなく“自宅”のガバナンス〜

GMOインターネットグループの週1日の「在宅勤務の推奨」完全廃止に伴い、テレワークの是非に話題が集まっている。テレワークによるセキュリティリスクはこれまでも言われてきた。今回のワサビのインシデントも、自宅ルーターの設定やファームウェアの不具合が侵入の一因だったことから、「在宅勤務だから起きた事故」と受け止める人もいるだろう。

ただ個人的には、それは少し論点が異なる。今回の事例が示したのは、テレワークそのものの危険性ではなく、自宅の開発環境を企業システムの一部として管理できていたかどうかという問題だ。

開発者が自宅で業務をすることは珍しくない。一方で自宅ルーターやNAS、IoT機器、開発用PCは、企業のネットワーク境界の外側にあることから、管理が個人任せになりやすい。企業のセキュリティ担当者がEDRやMDMを導入していても、自宅ルーターのUPnP設定やポート開放状況、ファームウェアの更新状況まで把握しているケースは少ないだろう。

今回のインシデントでは、Dockerの設定不備だけでなく、自宅ルーターの設定とファームウェアの不具合が重なったことで、開発環境がインターネットに露出した。これは特殊な攻撃ではなく、複数の小さな設定ミスが連鎖して起きた典型的な事故だと言える。

むしろ評価すべきは、ワサビが侵入経路や原因をここまで具体的に公表した点だ。近年は「不正アクセスがありました」「調査中です」とだけ発表し、技術的な原因を伏せる企業も多い。対して同社は、自宅ルーターやDocker設定まで含めて説明したことで、他社にとっても参考になるインシデントレポートとなった。

今後、企業が議論すべきなのは「出社か在宅か」という二者択一ではない。テレワークを続けるのであれば、自宅ネットワークや開発環境をどこまで企業の管理対象に含めるかという運用設計が問われる。ゼロトラストを掲げる企業は増えたが、その「トラストの境界」が従業員の自宅まで本当に広がっているのか。今回の事例は、その問いを改めて突き付けた。（田渕聖人）