公開S3バケットで86,000件超の医療記録・PIIが露出した「看護師版Uber」ESHYFT事件
(websiteplanet.com)- ニュージャージー拠点のHealthTech企業 ESHYFT に関連する公開データベースで、86,341件の記録と108.8GBのデータが露出していた。このプラットフォームは29州で医療施設と看護人材をつないでいる
- 露出した資料には、プロフィール・顔写真、月次勤務スケジュールのCSV、専門資格証、勤務割り当て契約書、職務経歴書と追加のPIIが含まれていた
- 一部のファイルは、欠勤や病気休暇の理由を証明するためにアプリへアップロードされた医療文書とみられ、診断・処方・治療情報が含まれており、HIPAA規制の対象となる可能性がある
- 研究者による責任ある開示通知の後、データベースへのアクセスは1カ月以上経って制限されたが、管理主体・露出期間・第三者によるアクセスの有無は確認されていない
- 医療人材プラットフォームには、機微データの暗号化、定期的なセキュリティ監査、最小限の保存と匿名化、機微度別の分離保存、MFA、侵害対応計画と通報チャネルが必要である
ESHYFTの公開データベースで確認された露出
- サイバーセキュリティ研究者のJeremiah Fowlerが、パスワード保護や暗号化のないデータベースを発見し、Website Planetに共有した
- データベースには ESHYFT に属するとみられる86,341件の記録があり、全体のサイズは108.8GBだった
- データベース名と内部文書は、それらの記録がESHYFTの所有物であることを示しており、文書の大半は「App」フォルダ内にあった
- ESHYFTはニュージャージー拠点のHealthTech企業で、医療施設と医療人材をつなぐモバイルアプリプラットフォームを運営している
- 対象人材には、Certified Nursing Assistants（CNAs）、Licensed Practical Nurses（LPNs）、Registered Nurses（RNs）が含まれる
- アプリはApple App StoreとGoogle Play Storeで提供されている
- Google Play Store上のダウンロード数は50,000回を超える
- Appleは現在、ユーザー統計を提供していない
露出したファイルと医療情報の機微性
- 限定的なサンプル確認で、複数種類のファイルが見つかった
- ユーザーのプロフィールまたは顔写真
- 月次勤務スケジュールログが入った.csvファイル
- 専門資格証
- 勤務割り当て契約書
- CVと職務経歴書、追加の個人識別情報（PII）
- 1つのスプレッドシート文書だけで、800,000件以上の項目が含まれていた
- 看護師の内部ID
- 施設名
- シフト勤務の時間と日付
- 勤務時間など
- アプリにアップロードされたとみられる医療文書も確認された
- 個々の看護師が勤務を欠いたり病気休暇を取ったりした理由を証明するためのファイルである可能性がある
- 医療報告書には、診断、処方、治療情報が含まれていた
- これらの情報はHIPAA規制の範囲に入る可能性がある
通知後の対応と残る不確実性
- 研究者はESHYFTに責任ある開示通知を直ちに送った
- データベースは1カ月以上経ってから公開アクセスが制限された
- ESHYFT側の返答は「Thank you! we’re actively looking into this and working on a solution」だった
- まだ確認されていない点が残っている
- データベースをESHYFTが直接所有・管理していたのか、第三者の契約業者が管理していたのか
- 研究者が発見する前にどれほど長く露出していたのか
- 他者がアクセスしたのか
- 追加アクセスや不審な活動の有無は、内部のフォレンジック監査でのみ特定できる
医療人材プラットフォームの成長に伴い増すセキュリティ負担
- ESHYFTは、看護師が自分のスケジュールに合った勤務を選べるようにし、医療施設には検証済みのW-2看護人材へのアクセスを提供するとしている
- プラットフォームは米国29州で提供されている
- AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
- Health Resources & Services Administration（NCHWA）の報告書は、2027年までに米国全土で登録看護師の不足率が10%に達すると予測している
- 医療人材の需要が高まるなか、ESHYFTのようなプラットフォームは人材不足を補う役割を担っている
- オフライン業務を行う看護人材もオンライン技術と統合されることで、HealthTech企業にはより強力なプライバシー保護策が必要になっている
- 病院と医療従事者がデータ保存、診療管理、雇用にテクノロジーをより多く依存するほど、業界全体のサイバーセキュリティ負担も増す
- 病院は重要インフラとみなされており、近年、複数のネットワークが深刻なランサムウェア攻撃を受けている
潜在的リスクと必要なセキュリティ対策
- 看護専門人材の個人識別情報、給与情報、勤務履歴が露出すると、個人と雇用先の医療施設の双方にリスクが生じる可能性がある
- 運転免許証やSocial Securityカードのような身分証のスキャンデータが住所・連絡先情報と組み合わさると、なりすましや金融詐欺に悪用される可能性がある
- 個人情報・専門情報の露出は、実際の情報を利用した標的型フィッシングにつながる可能性がある
- 雇用詐欺で被害者をだましたり、追加の個人情報・金融情報を開示させたりする可能性がある
- ただし、ESHYFTのデータやユーザーデータが詐欺または不正行為に実際に悪用されたという意味ではない
- HealthTech企業と医療ソフトウェア提供者は、以下の対策を検討すべきである
- 機微データに対する必須の暗号化プロトコル
- 内部インフラの脆弱性を特定するための定期的なセキュリティ監査
- 機微データの保存制限と、可能な場合の匿名化
- 使われなくなったデータへの有効期限の設定
- 文書の機微度に応じた分離保存
- この事例では、ユーザーファイルが機微度の基準で分離されず、単一フォルダにアップロードされていたように見える
- ユーザーのプロフィール画像は機微度が低い可能性がある
- 医療検査の証明は機微度が高い可能性がある
- 2つの文書は理論上、同じフォルダに保存されるべきではない
- 機微データの分離と暗号化は、偶発的な露出や悪意ある攻撃が発生した際に追加の保護層を提供する
- 機微情報や文書にアクセスできるアプリケーションには MFA が必要である
- ユーザー名とパスワードのような認証情報が露出しても、アプリケーションやユーザーダッシュボードへすぐにアクセスしにくくする
- HealthTech企業は、データ侵害対応計画と、潜在的なセキュリティ事故を報告するための専用コミュニケーションチャネルを備えるべきである
- カスタマーサポートや営業窓口だけでは、データ侵害時に対応すべき重要担当者への伝達が遅れる可能性がある
- 機微データが公開露出した場合、緩和と復旧の遅れは致命的になり得る
- データ事故の後には、直接影響を受ける可能性のあるユーザーに対し、適時に責任ある開示通知を提供すべきである
- ユーザーには、そのアプリケーションやサービスに関連するフィッシングの試みを見分ける方法を案内すべきである
- Shiftster LLC dba ESHYFT、契約業者、関連会社に違法行為があったという意味ではなく、内部データやユーザーデータが差し迫った危険にあったと主張するものでもない
1件のコメント
Hacker News のコメント
この会社は仕事を提示する前に、信用報告書でどれだけ借金があるか、つまりどれだけ切羽詰まっているかを判断し、その情報を使って提示時給を引き下げるという話を最近聞いた
この流出で何らかの不利益を被るなら、それ以上の報いを受けても当然に見える
呼び出しを受けると位置追跡アプリをオンにしなければならず、渋滞にはまったり携帯の電波が切れたりしてもペナルティが積み上がり、そのペナルティが賃金低下につながる、という仕組みだった
すでに患者が多すぎ、補助人員は不足し、12時間勤務の後にも記録作業をしなければならない劣悪な看護環境を武器化しているようなものだ。妻が看護師なので、より現実味を感じる
特に熟練看護師なら、賃金を買いたたくひどいアプリを使う理由はなく、どんな医療機関でもほぼすぐ採用されるはずだし、RNなら遠隔医療の選択肢も広そうに見える
配偶者がいるかもしれないし、親がクレジットカード代を払ってくれるかもしれないし、信用が悪い人があまり気にしないこともあるし、実家に資産があるかもしれない
借金が少なくても仕事に切羽詰まっていることはあり得るので、これが実際に機能するのか疑問だ
プライバシーポリシーのData Securityセクションには、収集・保管する情報の完全性とセキュリティを高めるために物理的・管理的・技術的な保護措置を用いるが、完全または侵入不可能なセキュリティは存在せず、漏えい・閲覧・公開・改ざん・破壊が起きないことは保証しない、と書かれている
特にこのサービスは、HIPAA上の保護対象保健情報を保存または保護するようには設計されていないと明記しているが、「HIPAA準拠システムとして作っていないので申し訳ない」で責任が消えるのかは分からない
0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...
記事では、看護師たちが欠勤や病欠の理由を証明するため、診断・処方・治療情報を含む医療文書をアプリにアップロードしていたようで、これが保護対象保健情報に該当する可能性があるとされている
この会社がHIPAAの適用対象かどうかは、covered entityまたはbusiness associateに当たるかによるが、プライバシーポリシーを見る限り、Business Associate Agreementを結んでいた可能性は低そうだ
付け加えると、HIPAA自体もセキュリティ標準として理想的ではなく、大企業がGmailはHIPAA準拠だという理由で、大量の保護対象保健情報をやり取りしていることもある
0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
おおまかには保険を受け付ける医療提供者や保険会社が該当し、保険を受け付けない医療提供者はHIPAAに従う必要がない
ここではESHYFTは労働力を提供する業者にすぎないため、HIPAAとは直接関係がなさそうで、人員補強サービスを提供する大手コンサルティング会社と大きくは変わらない
ただし、期待されるより適用範囲は狭く、罰則も弱い。Facebookが追跡ピクセルのようなものを設置させて個人の医療データを抜き取っても、法違反ではない可能性が高く、請求できるとしても流出を生じさせた側に対してだけのように思う
この件もHIPAAで損害を限定するのは簡単ではなさそうだ。医師が患者データをGoogle Driveにアップロードし、それがGoogleの下請け業者やハッキングによって漏れたケースに近い
ESHYFTのサービスにはHIPAAが保護するデータは必要でも有用でもないため、HIPAA違反で簡単に勝つのは難しそうだが、別の損害賠償責任はなおあり得る
医療従事者が持つ権威のせいで混同しやすいが、医師や病院に社会保障番号は絶対に渡さないほうがよい
彼らには必要ない。身分証確認も、スキャンや撮影を意味するわけではない
医師・病院・診療所は情報セキュリティが最悪の部類で、教育もほとんどなく、失敗しても処罰は軽く、そうした情報は結局、請求書を払わなかったときに追跡する用途に近い
S3バケットがどれだけ古いものなのか気になる。ある時点からAWSは新しいS3バケットをデフォルトで非公開にした
だとすれば古いバケットか、モバイルアプリ・サービスでファイルのアップロード/ダウンロードができず、無謀にも公開状態にしていた可能性が高い
タイトルに実際の会社名ではなく、なぜ「看護師向けUber」と書いたのか疑問だ
先週は Firebase のせいにしていたのに、今度は AWS のせいにするつもりなのかと思う
午前3時に友人に見せるために雑に作るもの向けのセキュリティ手順が、個人識別情報をホスティングするプロダクトにそのまま適用されてはいけない。基本的なデータセキュリティは運営者が自ら実装すべき
開発者がデフォルトに従うだけで安全になる、成功の落とし穴にはまるようにすべき
この場合、S3 バケットはデフォルトで非公開・暗号化されていて、開発者が明示的にオフにしなければならない構造であるべき。今はそうできるかもしれないが、昔はそうではなかった
医療業界は最初から最後まで壊れていて、その周辺のテック企業まで無能に見える
安上がりな企業所有の病院が看護師を W2 従業員として雇いたがらないため、看護業務が Uber 化し、病院のけち臭さがこうしたひどいアプリ選択につながった可能性が高い
承認した管理者にリベートが渡っていたのかもしれないし、ESHYFT はこの件で破産すべきだが、実際には何も起こらない可能性のほうが高そう
役員が刑務所に行かない限り、こういうことは続くだろう。誰かが情報セキュリティに投資せず、この事業で大金を稼いだ可能性が高い
コストを削った代償は、利益とは無関係な人たちが払った。数年後、その役員たちが成功する会社の作り方を講演して回っているかもしれない
こうした行為に何の結果も伴わなければ、公共が私的利益の代償を払い続けることになる
大規模な医療システムは、自前のフロート看護師プールや内部オファーシステムを持っている
休暇・欠員対応の仕組みにアクセスできる点は、大規模システムに売却される際の説得材料にもなる
不正を知っている人たちこそ、その恩恵を受けている人たちなので、是正するインセンティブがほとんどない
いまだに、こういうことに対処できる機能する規制機関があると信じているふりをしているのかと思う
なぜこういうことが繰り返されるのか分からない。毎月、開いたままの S3 バケットから新たな流出が出ている気がする
より重要なのは、大規模に探し続ける強い動機を持つ人が多い点。最近は GitHub、IP、ドメインなどインターネットを走査するのが非常に簡単で、「誤った S3 設定」の検出も誰でも使えるスクリプト程度なので、高度なプログラミング能力は必要ない
そのポリシーが後で本番環境に合わないことがある。正しいという意味ではなく、実際にそういうふうに物事が起きるという意味
インフラを作った人が疲れ切った状態で構築して、朝になってこの件を見て目が覚めたのだとしたら、本当に気の毒なことだ