タグ

incidentに関するsomathorのブックマーク (233)

  • 正規番号でファックス誤送信が起きたNTT西の電話サービス故障についてまとめてみた - piyolog

    2020年6月30日、NTT西日は電話サービスの故障が発生(同日中に復旧)したと発表しました。このサービス故障の影響を受け、石川県や兵庫県の一部の回線で電話不通やファックス誤送信のトラブルが発生しました。ここでは関連する情報をまとめます。 正しい番号でファックス誤送信 なぜか、電話がつながらない。送ったファックスが見知らぬ人の所に届いている。見覚えのないファックスがたくさん届く。こんな不思議な現象が石川県で起きました。原因はNTTの #電話回線の故障。多くの個人情報が流出しましたが、詳しい原因は分かっていません。https://t.co/soUL5OKiLc pic.twitter.com/Ai8bW2O2jP— 北陸中日新聞 (@c_hocknews) 2020年6月30日 サービス故障の影響を受けた顧客の新規の着信不可、誤着信が発生。実際に電話やファックスが着信しない、誤った相手につ

    正規番号でファックス誤送信が起きたNTT西の電話サービス故障についてまとめてみた - piyolog
  • BYOD端末と撤去控えたサーバーが狙われたNTTコミュニケーションズへの2つの不正アクセスをまとめてみた - piyolog

    2020年5月28日、NTTコミュニケーションズは社内ネットワークや一部サービスが不正アクセスを受け情報流出の可能性があると発表しました。また、同年7月2日には発表済み事案の影響顧客に追加があったこと、そしてBYOD端末を経由した別事案を把握し、これも情報流出の可能性があると発表しました。ここでは関連する情報をまとめます。 NTTコミュニケーションズで起きた2つの事案 2つの事案概要を図に整理すると次の通り。両事案とも情報流出が発生した可能性がある。 2つの事案の概要図 事案① 複数の海外拠点を経由しNTTコミュニケーションズの一部サービスに侵入した事案。さらにそのサービスで運用されるサーバーを踏み台に、社内ネットワークへ侵入し、ADサーバーやファイルサーバーの操作を行った。サービス上で保管された工事情報等やファイルサーバー上の情報が流出した可能性がある。 事案② BYODとして使用してい

    BYOD端末と撤去控えたサーバーが狙われたNTTコミュニケーションズへの2つの不正アクセスをまとめてみた - piyolog
  • データベース障害による一部登録情報消失のご報告とお詫び – mocriサポート

    いつも mocri をご利用いただきまして、誠にありがとうございます。 2020年6月5日 22時50分頃より発生し、2020年6月11日 10時45分頃に復旧しました障害(以下、障害といいます)により、一部のご利用者様におきまして、「一部プロフィール情報の消失」または「登録情報全体の消失」が発生し、復旧不可能であることが判明致しました。 障害の詳細等について、下記のとおりご報告致します。障害により多大なるご不便とご迷惑をお掛けしますこと、深くお詫び申し上げます。 ◆障害の影響を受けるご利用者様 ※以下の「ログアウト」には、端末の初期化や、機種変更時にアプリのログイン情報を引き継いでいない場合も含まれます。 Twitter 連携をされているか、または Apple ID でご登録いただいている場合で、障害発生後にログアウトまたはアプリ削除をされた方 1. に該当する方 を御覧くださ

    データベース障害による一部登録情報消失のご報告とお詫び – mocriサポート
  • 国内外の工場に影響したホンダへのサイバー攻撃についてまとめてみた - piyolog

    2020年6月9日、ホンダがサイバー攻撃を受け工場稼働に影響が及ぶシステム障害が発生したと複数のメディアが報じました。ここでは関連する情報をまとめます。 PC動かず休暇取得呼びかけ サイバー攻撃によりホンダへ生じた影響は以下の通り。(6月10日時点) 社内ネットワーク ・メール送信やファイルサーバーへの接続ができない状況が発生。 ・9日もメール使用不可の状態継続のためPC使用制限を実施。(10日までに制限解除) ・間接部門社員はPC使用できないため6月9日当日は有給休暇の取得を呼び掛け。*1 ・社内サーバーに接続するPCを中心にマルウェア感染が確認されている。社内サーバーにはマルウェアをばらまくプログラムが仕掛けられており、この対応に約2日を要した。*2 ・対策として多くのPC初期化を実施、一部データを損失。*3 国内工場 完成車出荷前検査システム障害により次の2工場での出荷が一時停止。

    国内外の工場に影響したホンダへのサイバー攻撃についてまとめてみた - piyolog
  • February service disruptions post-incident analysis

    EngineeringProductFebruary service disruptions post-incident analysisIn-depth analysis of February service disruptions that impacted GitHub services. In late February, GitHub experienced multiple service interruptions that resulted in degraded service for a total of eight hours and 14 minutes over four distinct events. Unexpected variations in database load, coupled with an unintended configuratio

    February service disruptions post-incident analysis
  • GitHubが2月中に複数回のサービスダウン - その理由は

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    GitHubが2月中に複数回のサービスダウン - その理由は
  • 国内高校の半数が利用するClassiの不正アクセスについてまとめてみた - piyolog

    2020年4月13日、Classi(以下Classi社と記載)は同社のクラウドサービス「Classi」が不正アクセスを受け、IDや暗号化されたパスワード文字列などが閲覧された可能性があると発表しました。ここでは関連する情報をまとめます。 corp.classi.jp 2時間で122万人のIDなどが閲覧された可能性 不正アクセスの概要 Classiへの不正アクセスは4月5日 日曜日の昼過ぎから夕方にかけ発生。発生時間は2時間14分。 社内のデータベースで異常発生が検知されたことが発端。データベースが直接被害を受けていたのかは報じられていない。 Classi社の発表に「外部専門会社の協力を得て不審ファイルや通信ログを解析したところ」とあり、Classi上に何らかのファイルが蔵置されていた可能性がある。 第三者に閲覧された可能性のある情報は次の通り。 閲覧された可能性のある情報 Classi社は

    国内高校の半数が利用するClassiの不正アクセスについてまとめてみた - piyolog
  • パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず

    パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず CDNプロバイダのCloudflareは、世界協定時4月15日の午後3時31分から午後7時52分(日時間4月午前0時31分から午前4時52分)まで、ダッシュボードおよびAPIが使えなくなるという障害を発生していました。 Cloudflare Dashboard and API Outage on April 15, 2020https://t.co/zJctsOomVf — Cloudflare | #BuiltForThis (@Cloudflare) April 16, 2020 同社のブログ「Cloudflare Dashboard and API Outage on April 15, 2020」によると、同社の2つのコアデータセンターのうちの1

    パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず
  • 金曜日に本番デプロイして障害を発生させたことを反省するTwitter社

    Developers @XDevelopers | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| don't push to prod on Fridays |___________| (\__/) || (•ㅅ•) || /   づ

    金曜日に本番デプロイして障害を発生させたことを反省するTwitter社
  • ログ消去もされていた三菱電機の不正アクセスについてまとめてみた - piyolog

    2020年1月20日、三菱電機は自社ネットワークが不正アクセスを受け、個人情報等が外部へ流出した可能性があると発表しました。ここでは関連する情報をまとめます。報道によれば現在も三菱電機は不正アクセスへの社内調査等を進めています。 発端は研究所サーバーの不審ファイル動作 2019年6月28日に情報技術総合研究所のサーバーで不審なファイルが動作したことを社内で検知。 同じファイルが中国、及び国内他拠点で検出され内部侵害の被害を受けている可能性を受け調査を開始。 報道された出来事を時系列にまとめると以下の通り。 日時 出来事 2017年後半? 三菱電機の中国国内子会社でマルウェア感染。 2019年3月18日 三菱電機が中国拠点のウイルスバスター法人向け製品の脆弱性を悪用された攻撃を受ける。*1 : アップデート機能を悪用し中国拠点で侵害範囲が拡大。 2020年4月3日 中国拠点端末より国内拠点の

    ログ消去もされていた三菱電機の不正アクセスについてまとめてみた - piyolog
  • 相手が唸る障害報告とは? - Suguru's Soliloquies

    何故報告書が必要なのか? 公開されている情報だけでは、どうにも収まらない報告書。 何故、お客様は、そんなに細かい部分を気にして知りたがるんでしょうか? 運用部門や開発部門に情報を求めても、そんな事を要求してくるのは一部のお客様だけだと言われ、下手をするとお客様の期待値コントロールが出来ていないと怒られてしまうこともありますよね。 でも、お客様だって困っているんです。だって、誰かに報告しなきゃいけないんだもの。 そう。ほとんどの場合、報告書は更に報告されて行くのです。 報告書をお客様に渡した後、どこでどんな風に使われているのか考えてみましょう。 相手の報告先を想定しておくと、良い報告書のイメージが掴みやすいです。 主要な3つのポイント 1. 結局何が問題だったのか?(バグ?プロセス?オペミス?) 2. 何に対して謝るのか?(出来ていなかった事は何?) 3. 来あるべき姿は何なのか?(短期、

    相手が唸る障害報告とは? - Suguru's Soliloquies
  • トレンドマイクロ従業員の不正行為で発生したサポート詐欺についてまとめてみた - piyolog

    2019年11月5日、トレンドマイクロは同社従業員(当時)の内部不正行為で一部の顧客情報が流出し、その情報が同社のサポートになりすました詐欺電話に悪用されていたと発表しました。ここでは関連する情報をまとめます。 トレンドマイクロの発表 blog.trendmicro.com www.trendmicro.com 2019年8月上旬、ホームセキュリティソリューション利用者の一部がトレンドマイクロサポート担当者になりすました詐欺電話を受けている事実を把握。 詐欺犯が保持している情報を受け、同社が組織的な攻撃を受けている可能性を考慮。 顧客情報の流出は外部からのハッキングではなく、同社従業員による内部不正行為が原因であることを確認。 徹底的な調査は即行われたが、2019年10月末まで内部不正行為によるものと断定できなかった。 同社は洗練されたコントロールを行っていたが、計画的犯行により突破されて

    トレンドマイクロ従業員の不正行為で発生したサポート詐欺についてまとめてみた - piyolog
  • 三菱UFJ銀行が不正アクセスを受けた通信暗号化装置について調べてみた - piyolog

    三菱UFJ銀行は法人顧客向けに提供するローカルキャッシュマネジメントサービスの認証システムで利用する通信暗号化装置が不正アクセスを受け、海外拠点の顧客の口座情報等が外部に流出したと発表しました。ここでは関連する情報と発表で言及があった「通信暗号化装置」についてpiyokangoが調べた情報をまとめます。 不正アクセス原因は通信暗号化装置の脆弱性 [PDF] ローカルキャッシュマネジメントサービスの通信暗号化装置への不正アクセスによる台湾拠点の一部お客さま情報および第三者情報の漏えいについて 通信暗号化装置の具体的な製品名は記載無し。 インターネット経由でLCMSに接続する際にユーザー認証し、通信を暗号化するための装置といった説明。 外部からの不正アクセスはこの装置に対して行われた。原因は脆弱性が存在したため。 通信暗号化装置の脆弱性はバージョンアップにて対応された。 タイムラインの整理 関

    三菱UFJ銀行が不正アクセスを受けた通信暗号化装置について調べてみた - piyolog
  • INT 32 障害とその BOLD な対策 | メルカリエンジニアリング

    この記事は、 Mercari Bold Challenge Monthの11日目の記事です。 こんにちは。Mercariで、通知に関連するサービスの開発をしているNotificationチームへ所属している @sters です。 通知という広く大きい舞台でのマイクロサービス化を主に進めているチーム、という文脈でも語れることがあるのですが、それはまた別のどこかの機会でお届けします。 今回の記事では、とある日に起きたNotificationチームにも関連するインシデント=障害について、何が起きたのか、何が原因だったのか、実際にどのように対応をしたか、今後どのようにしていくかをご紹介します。 なお、インシデント対応については、少し前の記事でも紹介していますが、現在もここでの通り振り返りなどを行っています。 インシデント発生、一次対応まで とある日の夕方、あるお知らせが見えたり見えなかったりする、

    INT 32 障害とその BOLD な対策 | メルカリエンジニアリング
  • AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」

    AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」(1/3 ページ) 8月23日に起きたクラウドサービス「AWS」(Amazon Web Services)の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる

    AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
  • AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず

    AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず 報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。 8月23日午後に約6時間の障害。EC2だけでなくRDSも 報告によると、障害は日時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。 日時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一

    AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
  • AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog

    2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間(EC2) 約6時間 2019年8月23日 12時36分頃~18時30分頃(大部分の復旧) 障害発生時間(RDS) 約9時間半 2019年8月23日 12時36分頃~22時5分頃 障害原因(EC2) 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン(AP-NORTHEAST-1)の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊4データセンター群の内、1つで発生。 日国内のAWSの契約先は数十万件とみられる。*

    AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog
  • Capital Oneの個人情報流出事件に思うこと - プログラマでありたい

    2019年7月末に、米大手金融機関であるCapital Oneが不正アクセスによる1億人を超える個人情報の流出を発表しました。規模もさることながら、Capital OneはAWSから何度も事例に取り上げられるような先進的な企業だったので、個人的にかなり衝撃を受けました。また、攻撃手法についても、従来の単純な設定ミスを狙ったものではなく、より一歩踏み込んだ攻撃という印象を受けました。 攻撃手法 攻撃手法については、piyologさんのSSRF攻撃によるCapital Oneの個人情報流出についてまとめてみたが非常に解りやすいので、まずはご参照してください。 piyolog.hatenadiary.jp 攻撃手法を簡単にまとめると、WAFの脆弱性を利用してIAM Roleのクレデンシャル情報を取得し、それを手元から利用して情報を取得したという形です。piyologさんの図を、再描画させて貰いま

    Capital Oneの個人情報流出事件に思うこと - プログラマでありたい
  • SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog

    2019年7月29日、米金融大手 Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表しました。WAFの設定ミスに起因して、Server Side Request Forgery(SSRF)攻撃を許したことにより情報を盗まれたと見られています。ここでは関連する情報をまとめます。 Capital Oneによる公式発表 Information on the Capital One Cyber Incident(米国向け) Information on the Capital One Cyber Incident(カナダ向け) Frequently Asked Questions (1)影響範囲 影響が及んだ人数の内訳は以下の通り。 米国 約1億人 カナダ 約600万人 発表時点でCapital Oneは流出した情報が外部へ出回ることや、詐欺への使用は確認していない。

    SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog
  • 7payの不正利用についてまとめてみた - piyolog

    セブンイレブンで開始されたスマートフォン決済サービス「7pay」で、セブン&アイホールディングスは2019年7月3日頃より不正利用が発覚したと発表しました。ここでは関連する情報をまとめます。 公式発表 セブン&アイHD/セブン・ペイ 2019年7月1日 [PDF] セブン&アイのバーコード決済「7pay(セブンペイ)」日サービススタート! 2019年7月3日 【ご注意ください】ID・パスワードの管理について(削除済み) 7payに関する重要なお知らせ [PDF] 7pay に関する重要なお知らせ 2019年7月4日 チャージ機能の一時停止に関するお知らせ [PDF] 「7pay(セブンペイ)」一部アカウントへの不正アクセス発生によるチャージ機能の一時停止について 2019年7月5日 「7pay(セブンペイ)」に対する不正アクセスの件(第3報)セキュリティ対策の強化を目的とした新組織発足の

    7payの不正利用についてまとめてみた - piyolog