時期尚早の感も拭えんが、ポストWordPressの候補として注視しておく価値はあるだろう。Cloudflareにデプロイした場合のコストも意外に安い。
触ってみた。その気になりさえすれば、このブログぐらいなら簡単に移転できると思う。その気になってないからやらんけど。
インポート＆エクスポートもできた。
よーし、食うに困ったらEmDashのカスタマイズで凌ごう。営業では「WordPressよりも安全」でゴリ押す。
プラグイン類も移植した。移転しても良い気がしてきた。
僕みたいなド三流が稼働しなきゃならないなんて世も末ですよ。
ろくにネットを使っていない父親（後期高齢者）からも、「何かセキュリティーで気をつけることはないか？」と連絡が来るような有様です。
消費者にできることなど限られています。
・メールのボタンやリンクを迂闊に開かない
・出所が分からないファイルをダウンロードしない
・知らない発信者から提供された短縮アドレスを開かない（偽サイトへの誘導によく使われます）
・Xに良くある「続きはこちら」「本編はこちら」といった誘導ポストに釣られない（ほぼ詐欺です）
・セキュリティーソフトを使用する（どれを使うかはav-test.orgなどを見て決めるのが良いです）
・企業に対し軽率に個人情報を与えない（与えていない情報は流出しません）
・怪しいサイトを閲覧しない（違法に動画を上げているようなサイトの倫理観を信用してはいけません）
・パスワードマネージャーを使う（僕は自分が使うパスワードを一つも覚えていません）
・パスキーを使う（全てのパスキーを特定のパスワードマネージャーに突っ込んでしまうとパスワードマネージャーのアカウントを喪失した際に認証ができなくなってしまうのでYubiKeyのようなものを併用しましょう）
・手持ちのデバイスにセキュリティーパッチが出ていたら速やかに当てる（攻撃者はパッチから脆弱性を知る場合があるため事実上のスピード勝負です）
・セキュリティーパッチの提供期限が切れているデバイス（スマホやルーターなど）を使わない
・上に書いている全てを行ったとしても守り切れないことを肝に銘じる
できることなど限られていると書いておきながら、挙げてみたら結構ありました。手間やお金がまあまあ掛かるでしょうから、考えうる最悪の事態とのバランスを考えて対応の程度を決めるのが良いと思います。
ストレッチをすれば痛みが和らぐかと思い、試したが体が曲がらない。かつてはオートフェラができたというのに、すっかり錆び付いてしまったよ。
【オートフェラの問題点（おさらい）】
男ならば誰しもが一度は憧れるオートフェラであるが、ストレッチを重ねて実現に至ったところで、適性の問題にぶち当たることになる。いわゆる「僕はフェラをする側なのかそれともされている側なのか問題」である。僕の場合は「している」という感覚が殆どで、されているように感じることができなかった。さらには、「『している』で抜くことができるどうか」という分岐もあった。「している」としか思えない人であっても、それで抜くことができるのであれば何の問題もなかろうが、僕はどちらにも当て嵌まらなかった。そこには「ケツや乳首でイケるかどうかはやってみるまで分からないし、数度の試行でそこへ至れるものでもない」というのと同じような構図もあるのだろうが、オートフェラに関しては、実現に至るまでに必要な鍛錬が過酷すぎるため、それ以上の鍛錬を受け入れられなかった。頑張った分のインセンティブは直ちに受け取れて良いはずだ。ストレッチにストレッチを重ねて辿り着く場所がゴールではなくスタートラインではあまりにも報われないではないか。
調べてみたのだが、口周辺（特に舌）は人体の中で最も敏感な部位であるらしい。「する」と「される」では「する」が勝るというのも腑に落ちる。キスでイケる体は作れるかも知れない。
以上、真面目なエントリが続いているのでキモいエントリでバランスを取りました。
お祭りになるやも知れません。皆さんにはどうでも良いかも知れませんが、僕の周辺は大忙しです。脆弱性の詳細は明かされていませんが、場合によっては漏洩祭りにブーストが掛かると思います。PHPのサイトって多いですからね。
Link: php2shell ：CVE-2026-109618 / 109619 RCE脆弱性と生存戦略
お疲れ様でございます。思いのほか大きな騒動になりましたね。僕も6サービスほど対応しました。
世の中にはまだ結構な数の未対応サイトがあると思います。横着のツケをしっかり払わされるのがネットの世界でございますから、頑張って尻を拭ってください。今回を乗り切ったら終わりではなく、更新できない状態を放置してきた運用そのものを見直してください。
まず、WordPressの上に業務システムを作ってしまっている会社さんは、これを機に考えを改めてください。業務システムとWordPressを一蓮托生にしてはいけません。WordPressはCMSであって、業務システムを作るためのフレームワークではありません。PHPにはLaravelといったフレームワークがあるのですから、そういうものを使っていきましょう。責務が異なるシステムの一方が他方の足枷とならぬよう、あらかじめ分離させてください。
また、WordPressに山ほどプラグインを積んで運用している会社さんも、これを機に考えを改めてください。プラグインの作者が皆さんの都合に合わせて保守を続けてくれる保証はありません。プラグインへの依存は、得てしてWordPressやPHPのアップデートの妨げとなります。導入時には無料でも、問題が起きた場合の対応や、使えなくなった場合のリプレースまで無料になるわけではありません。「プラグインが動かなくなるからバージョンを上げない」といった汚物のような言葉を、僕はもう聞きたくありません。
そして、これはそもそもの話になりますが、自社でサーバの保守を続ける体制がないのであれば、運用先を考え直してください。WordPressを動かす程度であれば、オンプレやら仮想マシンやらを使うよりも、大手レン鯖の共用サーバを使う方が安全かも知れません。OSやPHPといった基盤は業者がメンテしてくれますからね。WordPressの保守は必要ですが、自分たちで面倒を見なければならない範囲は幾らか減らせるはずです。共用サーバ以上に融通の利く環境を持ちたいのであれば、その自由に伴うリスクを引き受けなければなりません。自社で引き受けられないというのであれば、それができる所にお金を払いましょうね。
なお、僕はやりたくありません。抱えるサイトを増やすのは（気を張りながら生きていくはめになるため）命を削るに等しいのです。やるにしたって少額で請けられるようなものではありません。
こんなもんは防ぎようがなさそうですね。
Link: 米マイクロソフトが報告「中国系組織がAI自律ツールで世界規模のサイバー攻撃」（ビジネス+IT）
独力でこのような攻撃に対抗するのは難しいでしょうが、せめて以下の3つぐらいはやっておいた方が良いと思います。
① 持たざるを得ない個人情報は必ずエンベロープ暗号化する（可能であればメールアドレスもハッシュ化しましょう）
② 不要な情報を集めない（必要な情報であっても不要となったら直ちに捨てましょう）
③ Originを矢面に置かない（CDN/WAFに一次防衛を担わせましょう）
《①の補足: エンベロープ暗号化を1行で説明》
データを復号する鍵そのものを、外部サーバーで暗号化してしまう方法です。これにより、データベース内の情報だけでは、データを解読できなくなります。
《①の補足: メールアドレスのハッシュ化を2行で説明》
メールアドレスから2つのカラム（それぞれ「ハッシュ化されたメールアドレス」および「可逆暗号化されたメールアドレス」）を作成し、ハッシュ化されたアドレスの方をインデックスとしてください。
ハッシュ化には、ハッシュから元アドレスを推定されない方式を使用してください。具体的には、秘密鍵を使用するHMACのようなものを使ってください。
《③の補足: CDN/WAF <-> Origin間の経路は絞る必要があります》
例えばCloudflareを利用する場合、HTTP/HTTPSの経路は以下のページにあるレンジのみを許可するようにしてください。
Link: IP範囲（Cloudflare）
そしてopensslコマンド等でCA鍵（秘密鍵と証明書）およびクライアント鍵（秘密鍵と証明書）を作成し、Cloudflareの「SSL/TLS → オリジンサーバー → 認証済みオリジンプル」画面内の「ゾーンレベル」もしくは「ホスト名単位」のセクションにクライアント鍵を登録し、サーバーサイドにはCA証明書を設定して接続元を認証してください。
誰が読むんだこんなもん。
日本では現在、凄まじいペースで情報の漏洩事件が起きているようです。攻撃にはGLMが使われているのではないかと言われています。このような事件は世界中で起きていると思いますが、他国に比べて日本のITは殊更に脆弱であるとも聞きます。これは、おそらく事実です。
日本の企業の多くはセキュリティーに予算を割いていません。大して割いていないどころか、全く割いていなかったりします。僕の経験上、システムというものは開発以上に保全の方が手間です。OSのアップデートは頻繁にありますし、アップデートを行うたびにシステムの挙動をチェックする必要もありますし、そこで問題が発見されたならば対応する必要も生じます。これらを、月ごとどころか週ごとどころか、場合によっては数日置きにやるわけですよ。当然ながらコストが掛かるのですが、そのコストを当然に支払うべきものであると考える企業はそうありません。重大なインシデントが生じてようやく、後悔するはめになるわけです。
しかし、セキュリティー担当者がどんなに頑張ったとて、攻撃の試みを完全に防ぎきれるものでもありません。いわゆるセキュリティーパッチというものは既知の脆弱性への対応であって未知の問題には対応していませんし、アプリケーションの側にある脆弱性は開発者の側で塞がなければなりません。意識の高い企業はハッカーを雇って自らのシステムを攻撃させるなどして脆弱性の発見に努めていますが、そこまでしても完全とは言い切れないのです。それらは「侵入される可能性を可能な限り減らす努力」であって、安全を保証できるものではありません。ゆえに、入られることを前提とする備えというものが必要になるのです。
どうやら多くの企業は個人情報には価値があると思い込んでいるようですが、僕の認識は違います。個人情報は資産ではなく負債です。守り通すには十分なコストを支払い続ける必要がありますし、守れると言い切れるものでもありません。それが真に必要なものでなければ、そもそも持つべきではないのです。ところが、バカは情報を取りたがります。理由は文字通り、バカだからです。
仮にサーバー単位で万全の備えをしたとしても、それで安全が確約されるわけではありません。クラウドのハイパーバイザが侵されるなどした場合、クラウド内のサーバーは使い物にならなくなりますし、中身だって当然に読まれます。助かる道はリージョンをまたいでの冗長化およびエンベロープ暗号化ぐらいしかなさそうですが、全ての企業がそのような対策をしているわけではありません。さらに言うならばそのエンベロープ暗号化にしたって、「かなり安全」と言うことはできても、絶対に安全とは言えないのです。なお、この草稿をLLMに読ませたら「メモリ暗号化も要る」と言われました。その通りです。
何が言いたいかと言いますとね。端的には「金を使え」ってことですよ。加えて、「どんなに金を積んだとて限界はあるぜ」ということです。サービスを利用する側も「漏れる可能性はゼロにならない」ということを覚えておいた方が良いと思います。
ところで、セキュリティーの専門家でもないのにこんなエントリを書いてる僕って一体何屋さんなんだろね。
ネットワークセキュリティーは常に「何かを見過ごしているのかも知れない」といった不安と共にあるわけですが、「頑張ってリスクを抑えています」と言っても中々理解されないんですよね。多くの人は二分法的に（「言い訳なんか聞きたくない。結局、侵入されたじゃないか」といった風に）物事を評価しますから、「そんだけやってダメだったなら仕方ない」と思ってもらうのは大変そうです。このような行き違いは無理解から生じているものですから、今回の漏洩騒ぎを経てセキュリティーに対する知見の底が上がってくれると良いのですけどね。
企業が集めた個人情報を一番活かしているのは反社ではないかという考えには同意します。利用者に提示させる個人情報に見合う価値を提供しているサービスが、どれ程あると言うのでしょう。利用者にとっては多くの場合、情報を提供するリスクの方が勝ることになります。真っ当な神経を持つ企業であれば、利用者に不利益を齎しうる情報を「資産」などと見做せるわけがないのです。「最小限の情報は頂くが、本音を言えばそれさえも持ちたくはない」ぐらいに思ってもらいたいものです。
【FANZA利用者が生き残るには】
2015年にアメリカの不倫系出会いサイト「アシュレイ・マディソン」に登録された3,200万人分の個人情報が流出するという大事件がありました。流出元が不倫系出会いサイトということもあり、自死者まで出す大惨事となりました。これは、日本でも起きうることです。仮にFANZAで個人情報やら、それに紐付く購入リストやら、視聴履歴やらが流出した場合、社会的に終わってしまうであろう人の数は「アシュレイ・マディソン」の比ではないでしょう。しかし、既に使ってしまったものはどうにもなりません。アカウントを削除したところで、データベースから全ての情報を消してもらえているかどうかを利用者の側から確認することはできません。よって、開き直るしかないでしょう。利用者は覚悟しておいてください。ちなみにですが、僕自身も既に10万本を上回る数のAVを視聴しています。大抵のFANZA利用者は僕よりマトモでしょうから安心するが良いです。