【IT】ヤフー 個人情報を別のIDに誤って上書き 最大約39万件 [ムヒタ★]
■ このスレッドは過去ログ倉庫に格納されています
ヤフーは、ＩＤの登録システムに不具合があり、住所や電話番号などの個人情報が別のＩＤに誤って上書きされていたと発表しました。
変更された可能性のあるＩＤは、最大でおよそ39万件に上るということです。
発表によりますと、ヤフーのＩＤを持つ利用者が名前や住所、それに電話番号などの個人情報を変更した際、他の利用者のＩＤに誤って上書きされる不具合が発生したということです。
不具合があったのは先月29日から今月4日までの間で、変更された可能性のあるＩＤの数は最大で38万7000件に上るということです。
利用者からの問い合わせで4日、不具合が起きていたことが分かりました。
会社で調べたところ、システムを更新したことが原因と分かり、システムを元の状態に戻して、現在は不具合は起きていないということです。
誤って変更された情報について会社では、削除したうえで、利用者に連絡をとって再入力するよう依頼しています。
この不具合で会社には、注文した荷物が届かなかったり、別の人が注文した荷物が届いたりしたケースが報告されているということです。
ヤフーは「多大なご迷惑をおかけし、深くおわび申し上げます」と謝罪したうえで、再発防止に努めるとしています。
2020年8月6日 23時47分
https://www3.nhk.or.jp/news/html/20200806/k10012555411000.html Tポイント関連でもヤフーIDやべーのやらかしてなかったか？ 人手不足なんだろうな
定期メンテナンス、保守業務のマニュアル化された部分を新人君やスキルの低い人間にやらせてみたらとんでもないヘマをやらかした
そんな感じなんじゃないの？ まじ？俺のアカウントが消えてるかも？楽天は何年も利用してないけど >>9
面倒だし、又トラブルりそうだし。外注雇う金が勿体ない。
客に入力させちまえや。
そうすりゃカネかからんし間違っても逆客の責任（笑） >>49
プログラマーとして使える奴を取ろうとすると、
プログラムしか能が無い人材しか居なくなる
報連相も無ければ挨拶も無い
ソフトバンク系って何年か前にも、クラウドデータぶっ飛ばしちゃうとかやらかしたしなあ。
業務利用にＳＢ系は危い。
ソフトバンク、Zホールディングスはじきになくなるな。
一気に消えそう。一気に。 >>1
バージョン管理システムとか使ってないのか？
リスクコントロールを知らぬ日本のような対応だ >>60
ITは外部に丸投げしてたりするから
コロナで仕事足りなくて派遣切りして
内部の人間にやらせたら一気に技術力落ちるよ 個人情報を取得して管理するやり方は時代遅れ。20世紀的。
日本国民１億３千万人が、孫正義を絶対に許さない理由！！
・ 不法入国の駅前乗っ取りパチ屋で本名は 「 安 」 のくせに、華僑を騙り偽造家系図まで作成
・ フジ 「 カスぺ！ 」 で露骨な偉人伝ステマ http://awabi.2ch.net/test/read.cgi/mnewsplus/1347940618/
・ Ｔ豚Ｓ 「 報道特集 」 で 「 広島長崎は、非戦闘員の大量虐殺でなく正義 」 と問題発言！！ 怒り怒り怒り
・ 「 日本人は遺伝子レベルで独創性がない 」 「 姦酷原発は安全。 脱原発は日本だけの罰 」 と姦酷で問題発言
・ 反日映画 「 アンブロークン」 製作に資金提供
・ レイプ犯で他球団がスルーした鬼畜選手を入団させ、さらなるレイプ事件を数十件も犯す
・ 震災義援金１００億円の半分が、相続税逃れの財団寄付。 残りも太陽光発電投資
・ 「 太陽光事業では利益とらない 」 と豪語も、政府に高値虚偽上申、不正利益を誘導。助成金で姦酷製太陽パネルを輸入
・ 姦酷経済が苦しいからと朴シネに朝貢、姦酷へ１０年間で４６００億円もの投資を決定
・ スプリント社買収で、競合企業へ出資しないよう投資銀行に圧力
・ 電気通信事業法 「 通信の秘密 」 を侵害する、ヤフーメール文面を盗み読みする広告ビジネス
・ あおぞら銀行を１０億円で買収後、数年でハゲタカに５００億円で売却
・ 独島ＣＭ反日企業のＤＣに顧客データを委託管理、子会社ベクターがクレカ情報３０万件流出
・ 過去最大規模で顧客データを復旧不可にしたレンタルサーバーが、関連会社なのに黙殺
・ ＳＢグループの新卒採用で、半島大学出身を優先採用。
・ 民団総連むけ格安 「 同胞割 」 プランを提供
・ 自ら企画した 「 犬の子 」 家族ＣＭ ⇒ 半島では蔑視表現で、意味を知らない日本国民を尻目にニヤ二ヤ
・ ＣＭで 「 鳥取は糸電話 」 とエリアヘイト発言
・ 店長が契約者個人情報を犯罪組織へ横流し。
・ 犯罪組織へのケータイ横流しが圧倒的にトップ。
・ 「 負債２兆円を半分以下に返済したニダ！ 」 と公表 ⇒ 転換社債を株式化して自己資本化しただけ。
・ 解約数も断トツで多いのに 「 寝かせ 」 で塩漬けし、 「 ○ヶ月連続純増数ニダ！ 」 偽装宣伝
・ ソフバンiPnone だと、未使用でもパケット数がダブルフラット底値を超える問題を、隠ぺい！
・ 設備投資を怠り通話低品質を放置。 東日本大震災ではＳＢだけが不通に！
・ 基地局２０万の筈が、総務省が約半分の１０万と公表 ⇒ ＳＢだけフェムトセルを含んだ過大偽装だった
・ 「 公正競争 」 が口癖のくせに、ＳＢだけプラチナバンド700/900MHz帯で２スロット占有 ( 欧米だと公取違反で免許返上 ) 。
・ 税引前純利益１兆五千億円をあげながら、法人税等支払額は２千億円。 実効税負担率は２％
・ 落とし穴だらけのiPadセット割りに非難轟々。割引期間１年なのに契約２年で、「 購入契約 」 なのに解約したら本体返却。
・ 日本ユニセフへのクリック詐欺で大炎上。毎月１万円を継続自動募金
８月５日に贈答品をスマホで注文した際に、注文確定前の確認画面で、送り先も、請求先も、
送り先の内容で表示されて、操作間違えかと思い、請求先を、当方で打直して、変更したが、
やはり不具合だったのかと。ＰＡＹＰＡＹ残高払いで、支払いは済ませているが、
もし気付かなかったら、お店には、請求先（当方）ではなく、送り先様が自宅で注文した
ことになっていたのかな。のし付けるとかあるから判明するが、普通の品ならわからんな。 ＞誤って変更された情報について会社では、削除したうえで、利用者に連絡をとって再入力するよう依頼しています。
なんでだよ
普通はバックアップから戻せば元に戻るだろ
上書きしてからアックアップ戻すまでに修正された内容については、戻っている可能性あるから見直せってのなら解るが 電話番号変わったりシステム側で消されたりしたら、修正時の2段階認証はどうなるんだろうな エンジニアとしてはこのエンジニアの心情を思うと吐きそう >>73
たとえ会社から何も言われなかったとしても、首吊りたくなるだろうな 大量のUpdate コマンド流し込んだんだろうな。そしてやばいとなってDBでロールバック。
目に浮かぶようだ。
他山の石とし、俺も気をつけよう。 まあでも今回大事に至ってないからいいんじゃないの？
もとに戻せたわけでしょ、こんくらいのトラブルはよくある
個人情報流失ではあるけど、比較的規模は小さいと思う >>78
> 注文した荷物が届かなかったり、別の人が注文した荷物が届いたりしたケースが報告されている
これはどう考えても大事だろ。 こういう時は法人にだけこっそり
莫大な損害賠償を支払っているんだよな
泣きを見るのはいつも個人 情報の漏洩は大丈夫なのか？
中国アプリだけじゃなくラインも省庁や市町村が使うの禁止して欲しい ヤホーなんかに住所や電話番号を登録するのが
そもそも情弱すぎて、もうね >>1
やっぱり信用できないな
Yahoo関係にクレカ、銀行は紐付けしてない
paypayもセブン銀行チャージしかしてない
ヤフオクもやってないし
どさくさに紛れて半島とかに流出させてそうだし >>35
・韓国におけるIT業界離れ
大韓民国においては、毎日のように午前1-2時まで残業がある状況の上に、
年収が3000万ウォンに満たない[2]労働環境や学歴と勤続年数から決まる時給に、
人月をかける開発費算定方法、斬新なアプリケーションソフトウェアのアイデアを出しても
全く見向きもされない風潮、経験年数が増えると時給が高くなるため、
開発に携わることができなくなり、管理職に上がれなければIT業界に残ることができない、
など理由から、IT業界離れやIT技術者の海外流出が進行している。 安倍晋三は、小型核兵器なら違憲ではないと繰り返し発言してきた。
://blogs.yahoo.co.jp/erath_water/65714609.html
>>29
whereな
ただ間違えたとしてもID変わるなんて無いだろ
IDも毎回UPDATEしてて、条件が他人のIDだったら有り得るが
更新元IDの保存にstatic変数でも使ったか？ EXCELでまちがって間違った条件でソートかけてコピーしたデータを貼り付けてしまったのかな >>90
ニワカDB知識だな。 普通は同じレコードを書きかえるんじゃなくて、同じユーザID
で新しいレコードを作る。 レコードを取得する際は、ユーザIDで絞り込んだ複数
レコードを更新日時順でソートして、最新のレコードからユーザ情報を取得する。 >>92
EXCELだと、相対と絶対演算式やvlookupの悲劇とかはあるな Yahoo Japanグループは信用してないわ。
グループ企業のYJFXに個人情報保護法に基づく個人情報削除を依頼したけど、技術的に一つも削除できない、の一点張り。
監督省庁の金融庁に苦情いれた。 別のIDに正確に書き込めているなら「それは仕様です」で言い逃れできるなｗ >>96
んな面倒な事せんだろ。
ユーザが更新掛ける度にinsert? >>96
素人が組んだゴミシステムでもない限り、普通はそうするわな
まあ、DBの知識というよりシステム設計の常識みたいな話だけど
こればっかりは実務経験してないと分からんかもね >>106
更新履歴は別テーブルでやるのが普通だと思う
ユーザーIDみたいなアクセス頻度の多いデータを複数持って毎回日付でソートとかありえんよ
>>107
恥の上塗り乙 >>104
insertとかupdateの話ではなく、ビジネスとして最低限必要な情報を整合性を保持しながら
いかに少ないデータ量で保持するかってのがDB設計の基本なんよ
例えば、注文履歴を6ヶ月保持するとして、俺が今日引越しして住所変えたら、3ヶ月前に
注文した注文の発送先も新しい住所になっていいのかって話
（注文履歴テーブルに住所を持つのはアホ過ぎて論外）
実は現場では純粋なDB技術よりこういう部分の知見の方が求められるんだけど、設計やった
ことのない若手とか、下流工程専門の安いエンジニアはそういうスキルがなくて、Webでも
手に入る小手先の技術に目が行きやすい >>108
高速化の為に最新世代だけ顧客テーブルにコピーしてもたせる場合もあるけど、
顧客IDとタイムスタンプや世代番号をPKにする場合も多いで ちょっとSQL間違っちゃった(*ﾉω・*)ﾃﾍ
ごめんちゃい<(_ _)> で、ヤフーはなにをしくじったのか教えて偉い人
このスレにはたくさんいるみたいだから誰でもいいよ 昔に設計したＤＢ屋さんは、ＤＢ移行のことはこれっぽっちも考えておらんかったｗ
新たに担当したＤＢ屋さんは、既存のＤＢを理解せず扱っていたｗ
まあ、よくある普通のことです。 さすがにDB側での実装ミスでは無いだろ。いくら何でも基本的すぎる。
セッション管理に何かしらの特殊条件で起きるバグがあったんでは？
その辺は公開すべきだとは思うけど、一体何処のSIが構築したんだろうなあ……
フロントならともかく、内部制御は全て自前では無いだろうし。 >>112
どうせ日経コンピューターがすっぱ抜くから楽しみに待っとけｗ
よくある例だとエンジニアがよく知らんでスレッドに依存する処理を使ってたとかね
再現性のないバグはテストだと洗い出せない事がある 何だこりゃ
もうこここ使わなくても良いから、どんだけ配信停止設定しても、送り付けてくるYahooのメールから解放してくれよ。 >>96
そういう業務システムはあるだろうけどやり方としては一般的ではないね
日本国民１億３千万人が、孫正義を絶対に許さない理由！！
・ 不法入国の駅前乗っ取りパチ屋で本名は 「 安 」 のくせに、華僑を騙り偽造家系図まで作成
・ フジ 「 カスぺ！ 」 で露骨な偉人伝ステマ http://awabi.2ch.net/test/read.cgi/mnewsplus/1347940618/
・ Ｔ豚Ｓ 「 報道特集 」 で 「 広島長崎は、非戦闘員の大量虐殺でなく正義 」 と問題発言！！ 怒り怒り怒り
・ 「 日本人は遺伝子レベルで独創性がない 」 「 姦酷原発は安全。 脱原発は日本だけの罰 」 と姦酷で問題発言
・ 反日映画 「 アンブロークン」 製作に資金提供
・ レイプ犯で他球団がスルーした鬼畜選手を入団させ、さらなるレイプ事件を数十件も犯す
・ 震災義援金１００億円の半分が、相続税逃れの財団寄付。 残りも太陽光発電投資
・ 「 太陽光事業では利益とらない 」 と豪語も、政府に高値虚偽上申、不正利益を誘導。助成金で姦酷製太陽パネルを輸入
・ 姦酷経済が苦しいからと朴シネに朝貢、姦酷へ１０年間で４６００億円もの投資を決定
・ スプリント社買収で、競合企業へ出資しないよう投資銀行に圧力
・ 電気通信事業法 「 通信の秘密 」 を侵害する、ヤフーメール文面を盗み読みする広告ビジネス
・ あおぞら銀行を１０億円で買収後、数年でハゲタカに５００億円で売却
・ 独島ＣＭ反日企業のＤＣに顧客データを委託管理、子会社ベクターがクレカ情報３０万件流出
・ 過去最大規模で顧客データを復旧不可にしたレンタルサーバーが、関連会社なのに黙殺
・ ＳＢグループの新卒採用で、半島大学出身を優先採用。
・ 民団総連むけ格安 「 同胞割 」 プランを提供
・ 自ら企画した 「 犬の子 」 家族ＣＭ ⇒ 半島では蔑視表現で、意味を知らない日本国民を尻目にニヤ二ヤ
・ ＣＭで 「 鳥取は糸電話 」 とエリアヘイト発言
・ 店長が契約者個人情報を犯罪組織へ横流し。
・ 犯罪組織へのケータイ横流しが圧倒的にトップ。
・ 「 負債２兆円を半分以下に返済したニダ！ 」 と公表 ⇒ 転換社債を株式化して自己資本化しただけ。
・ 解約数も断トツで多いのに 「 寝かせ 」 で塩漬けし、 「 ○ヶ月連続純増数ニダ！ 」 偽装宣伝
・ ソフバンiPnone だと、未使用でもパケット数がダブルフラット底値を超える問題を、隠ぺい！
・ 設備投資を怠り通話低品質を放置。 東日本大震災ではＳＢだけが不通に！
・ 基地局２０万の筈が、総務省が約半分の１０万と公表 ⇒ ＳＢだけフェムトセルを含んだ過大偽装だった
・ 「 公正競争 」 が口癖のくせに、ＳＢだけプラチナバンド700/900MHz帯で２スロット占有 ( 欧米だと公取違反で免許返上 ) 。
・ 税引前純利益１兆五千億円をあげながら、法人税等支払額は２千億円。 実効税負担率は２％
・ 落とし穴だらけのiPadセット割りに非難轟々。割引期間１年なのに契約２年で、「 購入契約 」 なのに解約したら本体返却。
・ 日本ユニセフへのクリック詐欺で大炎上。毎月１万円を継続自動募金
>>109
> （注文履歴テーブルに住所を持つのはアホ過ぎて論外）
いや、注文履歴テーブルに持つだろ
たいていの通販は注文毎に発送先変えられることも知らんのか？
発送先を自宅にしかできないとかそれこそアホすぎるわw >>110
レコード数が変更回数倍になるんだぞ
しかも最新以外のレコードはほとんどアクセスされない
俺がマネージャならそんな設計する奴いたらメンバから外すわw 個人情報を売買し収益を上げ
IDを書き換え、間違えましたとし
事実無根で惚けるき満々だろ >>123
中国から無差別に送り付けられてる種子の遠因だったりしてな マスターとトランザクション一緒くたにしてるやつがいて笑えるw >>109
注文履歴テーブルに住所持つのはありだと思うけど
あとから変わることは無いし変わったらまずい項目だから
これを持たないとなると、住所変更ごとにどんどんレコードが増えてくマスタが出来ちゃう >>120
話のレベルが違いすぎるやで
最低限、第三正規化くらいは勉強してからドヤ顔してもろて
>>121
>>127
履歴管理しない顧客情報DBとか見たことないで
CS、経理、統計分析、障害対応等にも使うからDB情報は時系列も含めて管理するのがセオリーやん
つーか、顧客情報なんかレコード数たいしたことないやろ
通販サイトとかなら、トランザクション発生数で考えれば顧客情報変更より注文とかの方が圧倒的に多いやん つーか、DB設計の基礎を知らん奴がDB作るから、日本企業はBIツールとか普及せんのよな
BIツールのDBにぶっ込むデータの整理整頓だけで凄い工数取られるから
このスレ見ただけでも闇深すぎる・・・ >>129
> 最低限、第三正規化くらいは勉強してからドヤ顔してもろて
第三正規化を理解してたら
> 普通は同じレコードを書きかえるんじゃなくて、同じユーザIDで新しいレコードを作る。
なんてアホな発想は出てこないはずなんだが…
まあそれっぽい用語を使えばビビるとでも思ってのかな？w
> 履歴管理しない顧客情報DBとか見たことないで
顧客情報の管理とその履歴管理は別
履歴の参照頻度はそれほど高くないから通常別テーブルにするのはほぼ常識
> つーか、顧客情報なんかレコード数たいしたことないやろ
お前ん所のしょぼいシステムのことは知らん
まあ今どきのシステムなら数百万件とかでも普通に動くけどわざわざ性能劣化設計させることもないしな 単純にストレージ買い足したくないから使われてないアカウントを事故ってことにして潰しただけでしょうか。すげーゴミ溜まってそうだし。 >>132
正規化する目的を理解できてないんだなって事だけはよく分かった
履歴のテーブルに同じ情報持つのに、最新情報だけ顧客情報のテーブルにダブらせて持つ理由はないやん
高速化するにしても、ユーザーIDが主キーの顧客情報のテーブルに、履歴テーブルのスーパーキーを
持たせればいいだけ
つーか、ヘッダテーブルとヒストリーテーブルのコンビは王道オブ王道な組み方やで >>130
データ構造の抽象化や汎用性の高いER分析が日本人は苦手なんだろうな
ver 1.0の仕様しか視野にない使いにくいDB作って後々の機能追加で困るのはよくあるパターン >>135
ん？
>>96が正規化も知らないアホって指摘してるのか？w
履歴を無理矢理正規化しないのは半ば常識だぞ
https://qiita.com/Hiroro0970/items/74f819b2020127000f87
実務やってたらすぐにわかると思うんだが… 正規化ってしらんかったから調べたけどただの構造かw
ECなんて最初から仕様決まってて大きな変更ないだろ？なんでそんな面倒なことになるのか理解できん。 >>96 だけど、qiita みたいな素人のチラシの裏を引き合いに出すのを
含めて、予想以上に馬鹿ばかりなのが良〜く判った。
実務経験あり:
ID:62L+/uXz
ID:akLEYRNo
設計経験なしか、糞システムしか関わったことなし:
ID:46BijMVC
ID:NqDjLjgD
ID:+vvd4GTX
ID:WMSEt2ZJ (==ID:oKSwdnyo ?)
未経験か、学生、グラムなんぼで売られる兵隊:
ID:C3OyDI9d
ID:ZPMYK1PA
ID:NPL9vNdh
ID:HvCJ9kon
かな？
プロマネだったら外すとかイキる、馬鹿な船頭がリーダーシップ(w
発揮するから炎上するのも当然だわな。
ID:WMSEt2ZJ
> 顧客情報の管理とその履歴管理は別
> 履歴の参照頻度はそれほど高くないから通常別テーブルにするのはほぼ常識
いったいどこの常識やら？
こういう勘違いの馬鹿が仕切るから、糞システムが出来上がる。 >>137
>>109が言ってることがそのqiitaに書いてある事なんだが・・・
話に付いてこれてない事がよく分かった
qiitaに書かれている問題点の解決法は>>110が書いてくれてるぞ
単純にリレーションキーが足りてないだけ
qiitaのレベルの回答ならオラクルマスターは当然として、IPAのデータベース試験すら受からんよ >>136
・Ver1.5を開発する時、使い難いVer1.0用DBの転用を諦めて、Ver1.5用のDBを新設する
（Ver1.0用DBとVer1.5用のDBでデータは重複管理する）
・そのうちVer1.0用DBとVer1.5用のDBのデータ同期が行われなくなる
・そのうち「Ver1.0用DBはデータが古くて信用できないデータだから気を付けろ」とか言われるようになる
・新人が項目の扱いを間違えてVer1.0用DBの古いデータでVer1.5用のDBを上書きするバグを作り込む
（テストではバレない）
・本番障害起こして、Ver1.0用DBとVer1.5用のDBのデータを試験環境に落とした上で、分析かけて
本来あるべきデータを生成して本番環境にパッチを当てる（もちろん連日残業）
・Ver2.0ぐらいでDBがぐちゃぐちゃだからシステムごと再構築した方がいいよねとか言われてDBを作り直す
この辺までがセットだなｗ >>141
バカの例としてわざわざ上げたんだけど、まさか気づいてなかったのか？
あとOracle Master Bronzeってそんなに難しくないぞ
まあオラクルマスターにレベルがあることも知らなかったんだろうけどw >>143
>>137
> 履歴を無理矢理正規化しないのは半ば常識だぞ
> 実務やってたらすぐにわかると思うんだが…
主張がブレ過ぎて何が言いたいのか分からなくなってきてるぞ
あと、まさかBronzeを資格としてカウントするとは思わなかったわ
ITパスポートとかCCNAとか持ってても経歴書の資格欄に書かない感覚でいた これが問題ないと思うなら
ヤフー管理者の個人情報をランダムに他のユーザーに上書きして見ろよ
どうせ自分達の情報は優先的に保護してんだろうなぁ >>59
最近でもソフバンだけ電話繋がらないとかあったよね >>145
> 主張がブレ過ぎて何が言いたいのか分からなくなってきてるぞ
はいはい、具体的には何も指摘できないってことでいいかな？
> あと、まさかBronzeを資格としてカウントするとは思わなかったわ
で、なんてオラクルマスターなんて書いたんだ？
レベルあること知ってたらオラクルゴールドとか書くはずなんだけど…
すごい車 = ベンツ って言ってるガキと変わらんぞw
> ITパスポートとかCCNAとか持ってても経歴書の資格欄に書かない感覚でいた
必死にググってご苦労さん ■ このスレッドは過去ログ倉庫に格納されています
