2024年6月9日、KADOKAWAやニコニコ動画などを運営するドワンゴは、同グループの複数のWebサイトが6月8日未明より利用できない事象が発生と公表しました。システム障害の原因はランサムウエアによるもので、ニコニコ動画は復旧まで約2か月を要しました。またリークサイトから盗まれたとみられる情報を取得してSNSへ公開するなど悪質な情報拡散が確認されました。ここでは関連する情報をまとめます。 １．KADOKAWAグループのデータセンターでランサムウエア被害 公式及び報道より、データ暗号化の被害にあったのはKADOKAWAグループ企業 KADOKAWA Connectedのデータセンター（DC6）で運用されていたプライベートクラウドやそのクラウド上で稼働していたドワンゴ専用サーバー。またドワンゴの認証基盤であったActive Direcotryサーバーも攻撃者の制御下に置かれた。 侵害活動の拡
はじめに あえてどことは言いませんが、先日某サイトで「ネット速度を高速化する方法」としてDNSサーバの設定をpublic DNSサービスに変更する記事が出てました。その記事の結論としては「変更しても大差ない」というものでしたが、DNSでネットワークを高速化するというこのような記事は何年も前からときどき見かけます。いい機会なので、このあたりについてもう少し深く掘り下げて考えてみましょう。 ※この記事では、とくに明示しなければDNSサーバとはキャッシュDNSサーバ(フルサービスリゾルバ)を指すものとします。 DNS応答の速さ DNSの設定を変えることによりネットワークの速度が速くなるとすれば、(1)DNSそれ自体の応答が速くなるか、(2)その後のWebアクセスが速くなるか、のどちらか(または両方でしょう)。このそれぞれについて検討してみましょう。 前者が速くなると画像やJavascriptなど
もしもいま、インフラ技術をイチから学ぶならどうしたい？ 現役SRE・Yutaさんが考える学習ロードマップ - Findy Engineer Lab
めまぐるしく変化するテックの世界。技術を身に着けるうえで学ぶべきポイントや学習環境なども年々変わっています。 そこで「もしもいまの環境で、テックのことをイチから学び直すことになったら、自分はどんな風に勉強したいか」というIFストーリーを通じて、技術との向き合い方を考え直してみる企画「テック転生」。 今回は、FinTech企業のSREを務めるYutaさん（@Y0u281）に“自分だったらこう進めたい、インフラ技術の学習ロードマップ”を伺いました。 パブリッククラウドが当たり前になった今、インフラ技術を学ぶスタート地点は？ サーバー構築の次は、ネットワークと資格の勉強を Linuxとネットワークを学んだらいよいよAWSの学習へ 自分が学んだ時より学習コンテンツが豊富 コミュニティを活用すると情報が増えてモチベーションも高まる パブリッククラウドが当たり前になった今、インフラ技術を学ぶスタート地
はじめに この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉をレトロニムというそうです。 私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、この本を読んでいたという知識があった程度です。 ここではずっとオンプレミスのインフラ構築をしていた私がAWSに触れて最初に戸惑ったことを記事したいと思います。また、戸惑いましたということだけ書いても学びがないため対応したことも併せて記載します。AWSに慣れている人からすれば常識ですが
徳丸浩氏に聞く、クレカ情報の非保持化に潜む漏洩リスクとEC事業者の対策 ECサイトやWebサービスからの情報漏洩が相次いでおり、クレジットカード番号やセキュリティコードなど、機微な情報が漏洩する事案も散見されます。特に、クレジットカード情報は、2018年に施行された改正割賦販売法にもとづき、ECサイトやWebサービスの運営事業者では事実上、保持しないこと（非保持化）が義務付けられているなか、なぜ漏洩被害が発生してしまうのでしょうか。 本記事では、ECサイトからの漏洩事案を題材として、Webセキュリティの専門家である徳丸浩氏に「なぜクレジットカード情報の漏洩が起こってしまうのか」「ECサイト事業者はどのような対策をとるべきか」「漏洩が発生した場合、どんな流れで対応すべきか」などを伺いました。 この記事のポイント ECサイトでクレジットカード情報の漏洩事案が発生するのは、ECサイトの利用者がク
はじめに こんにちは。WEARバックエンド部SREブロックの春日です。普段はWEARというサービスのSREとして開発・運用に携わっています。本記事では、約60％のコスト削減に成功したNATゲートウェイの通信内容の調査方法と通信量の削減方法についてご紹介します。 目次 はじめに 目次 背景 コストの把握 NATゲートウェイの通信内容の把握 CloudWatchメトリクスでの確認 VPCフローログでの確認 リゾルバーでのクエリログでの確認 調査結果をもとにNATゲートウェイ経由での通信量を削減する AWSサービスとの通信 Datadogとの通信 WEARのAPIとの通信 ECRパブリックリポジトリとの通信 結果 まとめ 背景 ZOZOではより効果的な成長を目指してコストの最適化を進めています。コストの増大はサービスの拡大を鈍化させる原因となるため、常に最適な状態に保つことが必要です。WEARで
Chrome、FireFox、Safariといった主要ブラウザにおけるIPアドレス「0.0.0.0」の扱い方に問題があり、問題を悪用することで攻撃者が攻撃対象のローカル環境にアクセスできることが明らかになりました。問題を発見したセキュリティ企業のOligo Securityは、この脆弱(ぜいじゃく)性を「0.0.0.0 Day」と名付けて注意喚起しています。 0.0.0.0 Day: Exploiting Localhost APIs From the Browser | Oligo Security https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser Oligo Securityによると、主要なブラウザでは「『0.0.0.0』へのアクセスを『localhost (12
はじめに さくらのクラウドにはいくつかの開発チームがありますが、その中で私が所属しているガンマチームにおけるTerraformやAnsibleの活用というテーマで川井が発表させていただきます。 内容としては、まずこの発表の目的を説明し、IaC (Infrastructure as Code)とはそもそも何かという話をして、それからさくらのクラウドでTerraformをどのように活用しているか、またAnsibleをどのように活用しているかを発表します。 目的 今回はIaCの勉強会ということで、IaCの理解と実践を目的としています。この勉強会に参加することで皆さんがTerraformやAnsibleを理解し、インフラ構築に活用できるようになることを目指したいと思います。 IaCの理解と実践 この発表ではIaCを以下のように定義します。 「IaC(Infrastructure as Code)と
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KADOKAWAグループへのサイバー攻撃や悪質な情報拡散についてまとめてみた - piyolog
DNSを変更するとネットワークは速くなるか | IIJ Engineers Blog
オンプレエンジニアがAWSを触って思ったのと違うと感じたこと - Qiita
徳丸浩氏に聞く クレカ情報の漏洩が非保持化でも起こるワケ 2つの攻撃手法と対応策
NATゲートウェイの通信内容を調査して対策し、コストを約60％削減した話 - ZOZO TECH BLOG
「0.0.0.0」へのアクセスを悪用してローカル環境に侵入できる脆弱性「0.0.0.0 Day」が発見される
さくらの開発チームにおけるTerraform/Ansibleの活用 | さくらのナレッジ
メンテナンス画面の表示方法いろいろ | 外道父の匠