国立研究開発法人情報通信研究機構（NICT、理事長: 徳田 英幸）は、日本時間5月8日（水）10時41分以降、10日（金）2時44分までに、太陽面中央付近に位置する黒点群13663および13664で大規模な太陽フレア5回を含む複数回の太陽フレアの発生を確認しました。この現象に伴い、コロナガスが地球方向へ放出したことが複数回確認されました。コロナガスは、日本時間の5月10日（金）の夜以降、順次到来することが予測されています。 この影響で、地球周辺の宇宙環境が数日間大きく乱れる可能性があり、地球周辺の人工衛星の障害やGPSを用いた高精度測位の誤差の増大、短波通信障害などが生じる恐れがあり、宇宙システムの利用に注意が必要です。今後数日間は、この非常に活発な黒点群による同規模の太陽フレア及び関連現象の発生に注意が必要です。

Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛

2024年5月1日、太陽光発電施設の遠隔監視機器 約800台がサイバー攻撃を受けていたと報じられました。ここでは関連する情報を調べた内容についてまとめます。 監視機器を経由し不正送金 太陽光発電施設の遠隔監視機器がサイバー攻撃を受けているとして、報じたのは産経新聞の次の記事。コンテック社の遠隔監視機器が乗っ取られ、インターネットバンキングの不正送金に悪用されていたというもの。 www.sankei.com 攻撃を受けた機器には脆弱性（記事では「サイバー攻撃対策の欠陥」と表記）が存在。これを悪用されたことで機器上にバックドアが設置され、機器を経由（攻撃者が身元を隠すために踏み台にしたとみられる）して不正送金にかかる操作が行われていた。当該事案については既に静岡県警も不正アクセス禁止法違反の容疑で捜査中とされている。 SolarView Compactの脆弱性を悪用 脆弱性が悪用された監視機器

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

Redisをフォークした「Valkey 7.2.5」安定版が早くも登場。AWS、Google、Oracle、Heroku、Alibaba Cloudなど賛同が広がる RedisをフォークしたValkeyが早くも安定版「Valkey 7.2.5」をリリース。Valkeyブランドのためのコードの変更が行われた。AWS主導で始まったが、Google CloudやOracle、Heroku、Alibaba Cloudなど賛同が広がっている。 Valkey 7.2.5のリリースノートによると、このバージョンはフォーク元であるRedis 7.2.4からブランド名をValkeyへ変更するための変更をソースコードに対して行ったものであり、Redis 7.2.4からプロトコル、API、リターン値、データファイルフォーマットなどの変更は行われていないと説明されています。 ValkeyはRedisをフォークした

以下の文章は、コリイ・ドクトロウの「Someday, we’ll all take comfort in the internet’s “dark corners”」という記事を翻訳したものである。 Pluralistic プラットフォームは衰退する。競争、規制、広告ブロッカーやその他の敵対的な相互運用性、そして自社の労働者による制約を受けないテクノロジー企業の経営者は、必然的にプラットフォームを空洞化させ、超柔軟なデジタル技術を使ってエンドユーザやビジネス顧客から価値を吸い上げ、ユーザをロックインするために最低限の価値しか残さない。 https://pluralistic.net/2024/01/30/go-nuts-meine-kerle/#ich-bin-ein-bratapfel メタクソ化（enshittification）は、高いスイッチングコストの必然的な結末である。テクノロ

MFA認証を使ったAssumeRoleでシンプルにTerraformを実行する(aws configure export-credentials) Terraform実行時のMFA認証を使ったAssume Roleを楽にできる方法がないか調べていたら、以下のコメントを見つけました。 Doesn't ask MFA token code when using assume_role with MFA required #2420 どうやらツールや長いコマンドの実行なしで、MFA認証ありでも簡単にAssume Roleができそうです。 便利だったのでブログにしてみました。 TerraformのMFA認証事情は以下のブログをご確認ください。 結論 この方法では、aws-vaultやaws-mfaなどのツールは不要です。 以下のようにProfileを用意して、terraformのコマンドを打つだけ

海外サイト「IT之家」は4月12日（現地時間）、Appleのエンジニアリング担当副社長Kate Bergeron氏とMac製品マーケティングチームのEvan Buyze氏の独占インタビューを公開しました。そのなかでEvan Buyze氏は、Macの実行メモリ容量について興味深い発言をしています。 Macでは2015年以降、全モデルが最低でも8GBの実行メモリを搭載してきました。2020年以降に登場したApple Silicon搭載モデルでは、CPU、GPU、実行メモリを1つのチップに収めたユニファイドメモリとすることで、各チップが分離していた従来モデル（Intel Mac）と比べ、全体的な処理能力も向上しています。 一方、複数のチップをまとめた結果、購入後に実行メモリの容量を増やすという、Intel MacのハイエンドモデルやWindowsマシンではお馴染みのテクニックは使えなくなりました

AWSが長い間、最高のオープンソースプロジェクトを取り込み、常にそれらのコミュニティに還元することなく再利用し、再ブランド化することで非難されてきたことも周知の事実だ。 AWS gives open source the middle fingerOSSというのは、不思議なソフトウェアだ。世界中で何百万人もの人が一円にもならないのに開発に協力し、コミッタと呼ばれるエンジニアキャリアをOSSに賭ける人々が現れ、多くのユーザがユーザ会を組織し、時には大規模なイベントを開く。MicrosoftやGoogleといった大企業もOSS支援を表明している。GoogleにいたってはandroidとKubernetesという重要なOSSを世に送り出した企業でもあり、その貢献は計り知れない。 そんな中、OSSに対して敵対的、とまでは言わないにしても非常に冷淡な態度を取る企業がある。それがAWSである。本稿では

CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

HashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定 HashiCorpは昨年（2023年）8月、Terraformを含む同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表。これに反発し、ライセンス変更前のTerraformをフォークしたプロジェクトとしてLinux Foundation傘下で登場したのが「OpenTofu」です。 参考：Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名 しかしHashiCorpはこのOpenTofuを歓迎するつもりはまったくなかったようです。 HashiCorpがOpenTofuにコードの不正使用を警告 HashiCorpは

近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc

(4/14 表記揺れなどのコメントいただいたので、少し修正、追記しました。) ritouです。 私のタイムラインによく出てくる、この辺りの話っていつになってもしっくりこない人が多いと思います。 OAuth認証👮 : アプリケーションがユーザー情報取得を提供するAPIを叩いて受け取ったユーザー識別子を使って新規登録やログインさせてはいけない。OIDCのIDTokenを使え ユーザーIDが取得できればログインさせていいのではないか IDTokenはユーザーIDを含むJWTだが、どうしてこれは良いのか デジタル庁が進めるマイナンバーカードを用いた個人向け認証アプリケーション(以下、認証スーパーアプリ)の用途 マイナンバーカードを用いた本人確認は既にいくつかの民間サービスで使われているが、ログインに使えるとはどういう事なのか デジタル庁からは スマホ用電子証明書搭載サービス　という物も出ているが

AWS、Redisをフォークした「Valkey」を、同社サービスのElastiCacheとMemoryDBで採用すると明らかに Amazon Web Servicesは、同社のマネージドサービスとして提供しているAmazon ElasticCacheとAmazon MemoryDBで、インメモリデータストアのRedisをフォークした「Valkey」を採用すると、同社のブログに投稿した記事「Why AWS Supports Valkey」で明らかにしました。 Why #AWS Supports #Valkey. https://t.co/PMXv0Zv8B4 — Werner Vogels (@Werner) April 5, 2024 Valkeyの採用について、上記のブログで次のように記されています。 AWS is committed to supporting open source

3月12日火曜日に始まったPublickeyへのDDoS攻撃に対して、これまでサーバの強化、Cloudflareの導入とDDoS対策のための設定を行ってきました。 その結果、3月24日日曜日の夜に始まり3月27日水曜日の朝まで3日間連続で続いたDDoS攻撃のあいだもWebサイトの閲覧と記事更新などを問題なく行える状態となり、DDoS攻撃がWebサイトの運営の大きな障害ではなくなりました。 ちなみにそれ以後DDoS攻撃は止んでいますが、今後はいつDDoS攻撃を受けてもWebサイトの運営に支障がでることはなくなったと考えられます。この記事では結局どのような対策を行ったのか、実際に効果を発揮したDDoS対策を紹介していきます。 これまでの経緯は下記の記事をご参照ください。 Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ 続、Publickeyが受けたDoS攻撃、これまでの経緯と

日経BPから4月4日発売予定の『はじめて学ぶ最新サイバーセキュリティ講義　「都市伝説」と「誤解」を乗り越え、正しい知識と対策を身につける』の監訳を担当したので紹介させていただきます。 本書の原書は、ユージーン・H・スパフォード、レイ・メトカーフ、ジョサイヤ・ダイクストラの3名の共著として書かれた「Cybersecurity Myths and Misconceptions」で、米国Amazonのレビューでは4.6の高評価を得ています。また、「インターネットの父」ことヴィントン・サーフ氏が本書に前書きを寄せています（後述）。 はじめにサイバーセキュリティは、その短い歴史にも関わらず、神話や都市伝説に満ちています。古典的なものとして、本書の冒頭では、「ウイルス対策企業が自社製品を売るためにマルウェアを作って拡散した」が紹介されています。 本書は、このようなセキュリティの都市伝説や神話をとりあげ

2024年3月26日、データベース管理システムのPostgreSQLの開発やデータサーバーソリューション会社の2ndQuadrantの立ち上げに携わったソフトウェア開発者のサイモン・リッグス氏が亡くなりました。 PostgreSQL: Remembering Simon Riggs https://www.postgresql.org/about/news/remembering-simon-riggs-2830/ First picture of pilot who died in crash at Duxford aviation museum https://www.telegraph.co.uk/news/2024/03/27/plane-crash-imperial-war-museum-duxford/ 'Truly great' Bedfordshire man named

2024年3月29日、Linux向け圧縮ユーティリティとして広く利用されているXZ Utilsに深刻な脆弱性 CVE-2024-3094 が確認されたとして、研究者やベンダがセキュリティ情報を公開しました。この脆弱性は特定の条件下においてバックドアとして悪用される恐れがあるものとみられており、当該ソフトウエアのメンテナのアカウントにより実装されたソフトウエアサプライチェーン攻撃の可能性が指摘されています。ここでは関連する情報をまとめます。 脆弱性の概要 xzとは主要なLinuxディストリビューションに含まれる汎用的なデータ圧縮形式で、今回問題が確認されたのはその圧縮・解凍ユーティリティであるliblzma(API)を含むXZ Utils。CVE-2024-3094が採番されており、Red Hatによって評価されたCVSS基本値はフルスコアの10。影響を受けたライブラリをリンクしているssh