MyBRANDS漏えいか 委託先で使うキーで複製DBから外部送信の記録

サービスを止めて脆弱性に対応していたら、委託先で使っていたクラウドの管理キーが第三者に不正に使われた記録が出てきました。求人サイト「MyBRANDS」を運営するiDAが10月30日に公表した経緯です。複製したデータベースから外部へデータが送られた記録もあり、対象は退会者を含む最大約13万5千件にのぼります。

画面を止めても、クラウドの管理の経路は閉じません。委託先にクラウドの運用を任せている会社なら、MyBRANDSと取引がなくても、同じ経路が残っていないかを見ておきたいところです。

キーが使われてから4日後に判明

iDAのお知らせによると、キーが使われ、データが外部へ送られた記録があるのは10月21日〜22日です。判明は10月26日、公表は30日でした。22日から数えて判明まで4日、判明から公表までも4日。当サイトの10月の集計では、気づいた日から第1報までの中央値が3日ですから、公表が特別に遅いわけではありません。

送られたデータの中身は確認できていません。そこでiDAは、預かっていた情報のすべてを対象として知らせました。

対象は求職者と求人企業の担当者で、件数はアカウントの数です。項目は氏名、メールアドレス、電話番号、職歴などのプロフィール、ログイン用パスワードの変換した値などで、登録の内容によって違います。クレジットカードと銀行口座の情報は、もともと預かっていません。二次被害は確認されていないといいます。

止める手順に、キーと複製は入っているか

お知らせは、分かったきっかけを「サービスの停止中に脆弱性への対応を進めていたところ」と説明します。キーが使われた21日〜22日に、サービスがすでに止まっていたかどうかは、この文面だけでは判断できません。

ただ、どちらの順番でも、確認する点は変わりません。

Webサイトを止めると、利用者が入ってくる画面は閉じますが、クラウドの管理画面やAPIは別の入口です。権限のあるアクセスキーが有効なら、サイトを止めていてもデータベースの複製を作れます。

「複製したデータベース」をだれが作ったのかも、お知らせからは読み取れません。第三者が管理操作で作ったのなら、アプリのログインもWAFも通らない操作です。検証やバックアップのために前からあった複製なら、本番を止めても別のサーバーとして動き続けます。編集部は、どちらの場合でも、止める手順にキーと複製が入っていなければ同じ穴が残るとみています。

10月は、PHPの脆弱性への対応でサービスを予防のために止める例が相次ぎました（マイナカード総合サイトなど8件の戻り方）。iDAが対応していた脆弱性とPHPの関係は分かりません。それでも、自社が止めたあの日にキーと複製まで見たかどうかは、振り返っておく価値があるでしょう。

暗号化していても報告した理由

iDAは氏名、メールアドレス、電話番号、住所を暗号化して保存していました。それでも個人情報保護委員会へ報告し、警察に相談したのは、暗号を解くための鍵も取得されたおそれがあるからです。

個人情報保護委員会のガイドラインは、高度な暗号化などの秘匿化がされていれば報告を要しないとしています。ただしQ&Aは、暗号を解く手段が適切に管理されていることを条件に挙げました。たとえば次の形です。

暗号化した情報と復号鍵を分離するとともに復号鍵自体の漏えいを防止する適切な措置を講じていること

つまり暗号の強さだけでは足りず、鍵の置き場所まで問われます。データベースと復号鍵を同じ管理キーで読めるなら、キーが1本盗まれただけで両方に手が届きます。復号鍵の置き場所は、自社のシステムなら今日にでも確認できるはずです。

CINRA JOBとの差は、記録で言える範囲

クラウドの認証情報が入口になった事故は、この夏から相次ぎました。同じ求人サービスのCINRA JOBと、開発に使うクラウドで起きた日本経済新聞社の件を並べると、差が出るのは入口より、発表で言えた範囲です。

CINRAは「取られていない」と言い切れず、iDAは「何が出たか」を言えません。どちらも登録者の全体を対象にするほかありませんでした。日経は16日の時点で件数と内訳まで示しました。

iDAの説明は、通信の記録はあっても読まれた中身の記録がない状態に近いのではないか。編集部はそう推測します。記録を3段に分けて考えると、自社の穴も見えてきます。だれが複製を作ったかは管理操作のログ、どこへ送ったかは通信のログ、何を読んだかはデータベースの監査ログ。

ただ、複製された側のデータベースでは、監査の設定が元と同じとは限りません。たとえばAmazon RDSでは、スナップショットから復元したDBに、別のものを選ばない限り既定のパラメータグループが付き、独自のパラメータ設定は使えません。iDAの複製の設定は公表されていません。

だから、複製の操作そのものを起きた時点で知らせる設定が効いてきます。読まれたあとに中身を調べるより、作られた時点で気づくほうが、対象を絞れる余地が残ります。

MyBRANDSで採用している会社に影響する範囲

MyBRANDSで採用をしている会社は、担当者のアカウントが対象に入ります。iDAは、同じパスワードをほかのサービスで使っている場合の変更を呼びかけ、企業の担当者には社内のシステムも含めて見直すよう求めました。MyBRANDS側での手続きは要りません。

応募者やスカウト先から問い合わせが来たら、MyBRANDS事務局を案内します。iDAは、問い合わせ先は応募先やスカウトを受けた企業ではなく事務局だと明記しました。事務局からのメールにリンクは載せていないので、リンクつきの案内は疑ってかかれます。

社内への周知には少し配慮が要ります。全社に「MyBRANDSに登録している人は」と呼びかけると、転職活動を尋ねる形になりかねません。連絡は採用の担当部門に絞り、社員全体には一般的な不審メールの注意にとどめるのが無難でしょう。

MyBRANDS以外のiDAのサービスには影響しません。同社は「iDA（ida-mode.com）」や「MyBRANDS新卒」などを、今回の不正アクセスの対象外としました。

続報で見たい点

10月30日のお知らせから分からない点は次のとおりです。再開の時期を含め、新しい情報は同じページで知らせるといいます。

• キーが取得された経路と、対応していた脆弱性との関係
• 複製を作った者と、その複製がいつまで動いていたか
• 復号鍵の置き場所
• 委託先の社名と、使っていたクラウド
• パスワードの変換の方式と、暗号化の対象に挙がっていない職歴などの扱い

委託先のキーと複製の操作を確認する手順

例はAWSの画面の名前で、iDAが使っていたクラウドがAWSとは限りません。AzureならAzure Monitorのアクティビティログ、Google CloudならCloud Audit Logsで、同じ種類の操作を探せます。

1. 委託先が使うアクセスキーを一覧にします。IAMの認証情報レポートなら、キーごとに、作成または変更した日時と最後に使った日時が分かります。委託先が契約するアカウントなら、同じ内容の提出を頼んでください。
2. そのキーの権限に、データベースの複製や共有が入っていないかを見ます。日々の運用に要らなければ外し、長期のキーを一時的な認証情報に置き換えられないかも聞いてください。
3. CloudTrailのイベント履歴で、過去90日の操作を検索します。イベント履歴はリージョンごとに記録されるので、普段使わないリージョンも見てください。下の表の操作名に心当たりのないものがあれば、使われたキーと時刻を委託先に確認しましょう。
4. 同じ操作が起きたら、委託先と自社の両方に通知が届くようにします。AWSならEventBridgeのルールで、CloudTrailに記録された操作を拾えます。
5. 緊急停止の手順書に2行足します。「委託先を含むアクセスキーの確認」と「複製とバックアップの所在の確認」です。

見つかった場合、キーを止めるだけでは終わりません。盗まれたAWS認証情報の例では、攻撃者がIAMロールを新設していました。新しいロールや権限が増えていないかも、同じ検索で見ておきます。

緊急メンテナンスの手順書を開いて、「サービスを止める」の次の行を見てください。そこにキーの話がなければ、足すのは2行です。