教育出版大手マグロウヒル、S3 バケットの誤設定で学生 10 万人以上のデータを公開状態にしていた 38
やらかし 部門より
米教育出版大手マグロウヒルが Amazon S3 バケットの誤設定により、同社のオンライン学習プログラムを利用する学生 10 万人以上のデータを公開状態にしていたそうだ (vpnMentorのブログ記事、 The Register の記事、 HackRead の記事)。
発見した vpnMentor は今年 6 月 12 日、マグロウヒルのものとみられる 2 つの S3 バケットが公開状態になっているのを発見。1 つは本番用バケットでデータ量 12 TB 以上、4,700 万個以上のファイルを含む。もう 1 つは開発用バケットでデータ量 10 TB 以上、6,900 万個以上のファイルを含んでおり、合計でデータ量は 22 TB 以上、ファイルは 1 億 1,700 万個以上におよぶ。
vpnMentor では倫理的なルールに従って調査を行い、少数のサンプルのみを確認したため全容は不明だが、推定で学生 10 万人分以上の個人を特定可能な情報 (PII) が含まれていたという。データは 2015 年からアクセス可能な状態にあったが、実際に悪意ある第三者がデータにアクセスしたかどうかは不明だ。マグロウヒルは米三大教育出版社の一つで以前からオンライン学習プログラムを開発していたが、COVID-19パンデミックを受けて事業の拡大が加速したとのこと。
vpnMentor はマグロウヒルへの連絡を 6 月 13 日から 7 月 4 日までに 9 回試みたが返信はなく、US-CERT への連絡も 6 月 27 日から 7 月 4 日までに 4 回試みたが返信はなかったという。そのため、マグロウヒルのウェブサイトでライブチャットを通じてサイバーセキュリティ責任者の連絡先を入手。9 月 8 日・19 日・21 日と電子メールを送り、9 月 21 日にようやく届いた返信で個人情報を 7 月 20 日に削除したと知らされたとのことだ。
ワイ上司、GitHubの誤設定で全リポジトリを公開状態にしていた (スコア:1)
部所で使用しているGitHub垢内の162のリポジトリすべてをご丁寧にも公開状態へと設定し直し、全世界に公開していたそうだ。
上司は自分の英語力では直読直解することは困難と判断、Google翻訳を用いてGitHub Docsに挑んだものの、
なにをどう勘違いしたのか無料プランのGitHub Pagesの説明書きをリポジトリ自体の説明と勘違い。
「publicにしないと(部所の)皆から見えなくなってしまう」という強い使命感の元、すべてのリポジトリを公開状態へ変更し直したとのこと。
顧客側社員のひとりが気づき、当社サポセンに連絡したものの、取り次いだサポセン主任は当初「弊社ではそのような運用はしておりません」
などと、まったく聞く耳を持たなかったもよう。しかし今年定年を迎える取締役の携帯電話に顧客側役員から直接電話が入り事件発覚。
現在、ワイ上司とサポセン主任による罪のなすり合いが開催されているとのこと。
尚、ワイ上司がいったいいつの時点でそんな暴挙に及んだのかという正確な日時については、上司は固く口を噤んでいるとのことだ。
昨夜の忘年会ではこの話で持ち切りとなっており、同部所で働いていたワイ、実はかなり楽しい。
少なくとも上司は年内懲戒解雇かなって噂。
# なぜこんな無能が上司だったのか?
「ワイ」の使い方間違ってない? (スコア:1)
「ワイ上司」は普通は「I am 上司」って意味だと思うんだ。
でもこの人は「my 上司」って意味で使ってたり
「同部所で働いていたワイ、実はかなり楽しい。」の部分で「I」の意味でワイを使ってたりで、一貫性がない。
> # なぜこんな無能が上司だったのか?
上司が無能なんじゃなくて社員全員が無能なんだと思いますよ。
Re: (スコア:0)
もしかしたら、「Y上司」なのでは。
Re: (スコア:0)
嘘松乙
Re: (スコア:0)
> Google翻訳
「みらい翻訳」だったなら…起きなかったんですかね?
もしくは、
技術者としての無能さは置いといて。
部下を持つのに、部下に翻訳させて、
ワイ上司「ワシ知らん」
と言い逃れできるような、日本流上司ロールプレイを
振る舞えなかった辺りが、上司としての無能さか。
Re: (スコア:0)
GitHubのログを見ればいつ設定したのかはわかるはず。
Re: (スコア:0)
そんな事したら真犯人ばれて、上司追い出せないじゃない。
Re: (スコア:0)
え、えん罪なんですか?
Re:ワイ上司、GitHubの誤設定で全リポジトリを公開状態にしていた (スコア:1)
上司ははめられたのでは。
# とういうか、顧客に指摘されるまで誰も気づかなかったんですかね。顧客からすればだれがやったにせよ、無能な部署だなと思ってるでしょうね。
# しかし、これが事実だとしたら、ACとは言え、よく自分が勤める会社の恥を外にさらせますよね。関係者がみればどこの会社かわかるかもしれませんし、顧客もこの程度の会社だったかと見限ってるかもしれませんね。
Re: (スコア:0)
ここまで書いていることが本人で正しいのだと仮定すると、
上司はハメられたのではなく、
上司をハメたほうの告白なんじゃないですかね。
Re: (スコア:0)
上司をハメたほうの告白であっても、上司がハメられたことにかわりないのでは。
Re: (スコア:0)
状況としてはそうですね。その通りです。
話の流れとしては①最初は無能な上司だと思っていたら②真犯人が別にいて③実はハメたほうの告白だったということでそう表現してみました。
ハメられた話(客観的な話)ではなくハメた話(主観的な話)だったということで。
Re: (スコア:0)
> ワイ上司とサポセン主任による罪のなすり合い
?なぜ、なすりつけ合いが発生するのか、文章を読んでもさっぱり分からず。
「サポセン主任」の問題点は、顧客からの問い合わせをインシデントとして処理しなかったこと、であって、
「ワイ上司」の問題点である、社内ルールに基づいたセキュリティ設定をしなかったこと、とは全く別件に見える。
「ワイ上司」と「サポセン主任」の間で、変更管理のプロセスとかに基づいてGitHubの設定情報を共有していたのなら話は別だけど。
…可能性があるとしたら、
「サポセン主任」の責任者と「ワイ上司」の責任者が同じで、「ワイ上司」が責任
Re:ワイ上司、GitHubの誤設定で全リポジトリを公開状態にしていた (スコア:1)
#新人をパワハラで死に追いやっても関係者が解雇にならないご時世だから、
顧客情報が漏洩した程度じゃ解雇されないんじゃないかなぁ。
毎年のように、漏洩だ~、踏み台にされた~、という話が聞こえてくるけど、
その処分は、せいぜい、迷惑かけた顧客に謝り倒しに行った、とか、
漏洩データが削除されたことをその場まで行って確認した、とかだけらしいし。
コメントが2行目以降漏洩してますよ
/*
あるあ、、ねぇよっ!
*/
Re: (スコア:0)
ここの処分一覧を見ると [roudoumondai.com]、パワハラ自殺で解雇になったケースがなさそうな。むしろ、ケガや恐喝とか被害者が生きてる方が解雇になってる。
…死人に口なしってか…
Re: (スコア:0)
サポセン主任が握りつぶさなければ顧客側「社員」と設定ミスの当事者だけで話が済んでいたけど、
放置したから顧客側「役員」から自社の取締役まで巻き込んだ騒動に発展してしまった。
ミスの大きさも相当だけど騒動の大きさの方も深刻で、
騒動を大きくしないとどうにもならない状況に顧客を追い込んで騒動を大きくした馬鹿と
そもそもがマヌケな設定をして騒動の原因作った馬鹿のどっちを吊るすかの話になってんでしょ。
サポセンってのは客にテンプレ叩き付けて話を握りつぶすのが仕事になりがちだけど、
適切にエスカレーションできなきゃ客が泣き寝入りして信用無くすか、
法的手段やコネを使った強制エスカレーションされるかに二極化するからそれだと不味いんよな。
個人的には、設定ミスは再発防止が必要な重大事故だけど、
握り潰しは部署全体の意識の持ち方から直さないとどうにもならん深刻さがあると思う。
Re: (スコア:0)
週明けに、ワイ上司とサポ主任が共同してワイ君を犯人にしたてあげるのを、まだワイ君は知らない。
Re: (スコア:0)
くっさいツリーだな
Re: (スコア:0)
ぶち撒けるのは全部の沙汰が終わってからでも遅くないのに。
お漏らし体質の強い使命感とやらはアナタにも受け継がれてるようですな。
US-CERTが返信しなかったように見える (スコア:1)
元記事のUSA-CERTという誤記を引っ張ってこなかったのはさすがですが、正確に記載するなら「US-CERT経由での連絡も 6 月 27 日から 7 月 4 日までに 4 回試みたが返信はなかった」かな。
マグロウヒルだけに (スコア:0)
セキュリティがマグロだったわけですね
日経BP社 (スコア:0)
小さい頃、日経マグロウヒル社というのがあったよな、と思ったら、
今の日経BP社がそうだったのか。
https://www.nikkeibp.co.jp/history/ [nikkeibp.co.jp]
マグロウヒル社とは1988年にとっくに資本提携を解消してたのね。
なんかいい防止方法あるのかな〜 (スコア:0)
Amazonから見りゃ正当な理由で公開にしてるのかなんてわかんないだろうし
S3設定者が気をつけるしか無いんだろうな
Re:なんかいい防止方法あるのかな〜 (スコア:1)
AWSからはフル公開のバケットについては時々確認を求めるメールが来ますよ。
あとはそれに気づけるかどうかですね~。
Re: (スコア:0)
初期設定非公開とかできんのかなと思う。
Re: (スコア:0)
昔は知らないですが、初期値は非公開です。
Re: (スコア:0)
S3のような簡単な設定で公開できてしまう場所に、機密情報を置かなきゃいいだけ。
Re: (スコア:0)
お気楽簡単運用しかしていなかったので、「そんな事できたの?」って逆にビックリしてる。
「意外にS3でも色々やろうと思えば出来るのね」と思いつつパケット公開する有効利用の方法がイマイチ想像できない。
proxy/パケットシェイプ系の実装をする時のデバッグ用とか?
Re:なんかいい防止方法あるのかな〜 (スコア:2)
「意外にS3でも色々やろうと思えば出来るのね」と思いつつパケット公開する有効利用の方法がイマイチ想像できない。
proxy/パケットシェイプ系の実装をする時のデバッグ用とか?
もしかして、Bucket [amazon.com]をpacketと勘違いしていませんか。
Re: (スコア:0)
公開用のものとそうでないものを同一サービスとして提供していることが、AWSの仕様上のセキュリティーホールといっても過言ではない。
何度もこういう事故が起きてるのにな。
Re: (スコア:0)
でも途中から公開したくなることはあるでしょ
Re: (スコア:0)
でも途中から公開したくなることはあるでしょ
途中から後悔したくなった案件ですし
Re: (スコア:0)
データ移せばいいだけじゃん
Re: (スコア:0)
それだと、あちこち直さなきゃいけないじゃん
Re: (スコア:0)
あちこちデータをお漏らしするのと、どちらが希望?
たった10万人。 (スコア:0)
↓ここを見て、日本では毎週どこかで1000人以上の漏洩が起きていて、
毎月のように10万人規模の個人情報漏洩が起きてることを知った方がいい。
https://cybersecurity-jp.com/leakage-of-personal-information [cybersecurity-jp.com]
S3や設定周りでニュースが目立つのは、自動車大手とかOS大手とかだけど、
ニュース記事に載らない漏洩事件の公表は多数ある。
対象者に連絡するとか発表では言いながら、連絡のない会社すらある。
被害アカウントを勝手に削除しているように見える会社もある。
上のリストだけでなく、
…たった1人分の情報漏洩を全世界に公表して、
それが富裕層だと分かってしまうから、
むしろその方が危ないんじゃね?っていう
変な会社も時々ある…。
タレコミ記事も変。 (スコア:0)
元記事見ずに、タレコミの文だけ読むと、「個人情報を 7 月 20 日に削除した」とあるので、本番用バケットまで削除したことになってしまう。
非公開化することが必要であって、データを削除する、という対応は変なのでは!?
Re:タレコミ記事も変。 (スコア:1)