tomo|インフラエンジニア (@MyTechBlogJP) header
tomo|インフラエンジニア (@MyTechBlogJP) profile picture

関西のインフラエンジニア(経験20年超)|NW・クラウド・セキュリティの設計構築・PM|CCIE Lifetime Emeritus / VCAP-DCA / Azure Solutions Architect Expert|セキュリティや AI の話題を、現場の目線で発信

Joined August 2012
Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)Photo by tomo|インフラエンジニア (@MyTechBlogJP)
個人的には「業務知識か、技術力か」の二択ではないと思っています。 どのデータが機微か、誰に何を許すかは、業務を知らないと決められない。 それを最小権限や既定の遮断に落とすのは、技術を知らないとできない。 AI が実装速くしても、「どこまで許すか」の判断は人に残ると考えます。
AI時代は実装力やスピードよりもドメイン知識って言説あるが、そういう主張する人は現状セキュリティインシデント出まくってる現状をどう捉えてるか気になる
19
脆弱性潰す前に、やられたときの影響範囲を見積もる。GMO の件でわかる重要な視点だと思います。 利用者が管理者権限を持つ環境は、侵害される前提で管理基盤と切り離す。1 台の侵害を全台に広げない設計が要点です。
GMOの件、みんな問題の本質を見誤ってると思う。 これ、AIを使った攻撃でも、未知の脆弱性でもない。 単純な設定ミスが何年も放置されてた、という話。 しかもただの情報漏洩じゃない。 「顧客のPCにマルウェアを送り込める状態」が続いてた。 サービスの利用者がそのまま攻撃の入り口になり得たってこと。これはだいぶ異常。 攻撃を受けたときに、これだけの影響性があるサービスは金融系サービスを除けばほとんどない。 そのへんのECサイトなんて、どんだけ攻撃したって、顧客に数万円の損害が出ることもない。この事故と比べたら顧客情報の漏洩がかわいく見える。 セキュリティ対策って、脆弱性を潰す前に「ここが破られたら何が起きるか」を試算するところから始まるんだけど、今回はその見積もりが根本的に小さすぎたんだと思う。 VPSみたいに顧客の環境そのものを預かる事業者は、普通のWeb事業者の何倍もセキュリティに投資すべき。 GMOの会見でも「会社規模が大きく認知出来なかった」という話があったけど、規模を広げる前にするべき投資が合ったという事実に他ならない。 それを怠ったなら、責任を問われるのはやむなし。
1
1
2
181
次は「AI の中に保存してました」が来そう。
【情シスあるあるエクセル編】 Aさん「Excelのファイルが消えました」 僕「どこに保存していたものですか?」 Aさん「Excelの中です」 (え、エクセルの中。。。) 想像もしてない答えが返ってくることあります。
142
ゼロトラスト(Cisco SSE)の構成で、最近はまったのがまさにこれ。 IPsec などのトンネルを挟むと特に起きやすく、症状も「止まる」より「不安定」に見えるのでやっかいです。 つながった後の、サイズを変えた確認まで事前検証に入れておきたいですね。
ネットワークで厄介なのが、MTUの不整合。 Pingは通るしSSHもOKでも、 大きなデータを送ると止まることも。 経路上で必要なパケットサイズを通せず、特定の通信だけ失敗することがある。 「つながるか」だけでなく、必要なサイズの通信まで確認することが大事ですね。
1
173
会見でもう一つ考えさせられたのは、脆弱性の指摘が経営トップに届いていなかった点です。 報道によると、2024年に子会社から報告を受けて緊急メンテナンスもしたものの抜本改善に至らず、社長には報告されていなかったとのこと。 指摘を受けることより、それを「誰が、どの基準で上げるか」の仕組みのほうが大事だと改めて感じます。 ログも報告も、取得より「届いているか」の確認が肝心です。
私も会見を見て、違和感が残りました。 特に引っかかったのは、ご自身の31年間の歩みや経営理念を語り、涙を流した場面です。 涙を流すこと自体が悪いとは思いません。 ただ、その感情が向けられていた先が、被害者ではなく、ご自身の思いや無念にあるように感じました。 また、以前からセキュリティ上の問題を指摘されていたことを考えると、掲げてきた理念が実際の行動に結びついていたのか、疑問が残ります。
121
私も会見を見て、違和感が残りました。 特に引っかかったのは、ご自身の31年間の歩みや経営理念を語り、涙を流した場面です。 涙を流すこと自体が悪いとは思いません。 ただ、その感情が向けられていた先が、被害者ではなく、ご自身の思いや無念にあるように感じました。 また、以前からセキュリティ上の問題を指摘されていたことを考えると、掲げてきた理念が実際の行動に結びついていたのか、疑問が残ります。
GMOインターネット会見終了、 約3時間半の記者会見でしたが、 「お客様の笑顔」「命の砂時計」と定性的で、同じ言葉の繰り返しに終始しており、何の説明にも具体性は感じられませんでした。 GMO社のサービスも利用している末端のお客様である当人としても、「笑顔にはなれない」不安になる会見で。 この不安な気持ちでドメインやサーバを借りてること自体が、命の砂時計を無駄遣いしているようにも、感じました。 個人的には、やはり技術的な知見をもって説明して欲しかったし。法的な解釈も必要で、顧問弁護士は最低限必要だったのと、広報責任者が記者からでるだろう想定質問集を軸として、この記者会見を組み立てるべきだったと思います。 フジテレビの、旧ジャニーズの会見と、色々と見てきた中でも、ロジカルさを欠いた、最も残念な会見になったかと感じています。正直、心配です。
1
216
これはこわい… AI で4コマにしてみました。 頭にのっているのは、うちのインコです 笑
🤖 Made with AI
こわ...。ChatGPT にログインした状態で共有リンクを開くだけで、アカウントを乗っ取れる穴があった、と Parameter Labs が報告(修正済み) parameter.ai/labs/we-found-a…
4
142
PHP の脆弱性「PHP2Shell」は QNAP 製品にも影響があり、QTS / QuTS hero などは修正版が公開されています。 ただし NDR 向けの QNE ADRA(1.0.7 以前)はまだ準備中。Container Station のコンテナ内の PHP も対象外なので、別途対応が必要です。 qnap.com/ja-jp/security-advi…
62
AWS の CVE-2026-98432 の告知、EC2 以外もサービスごとに対応が違います。 ・RDS / Aurora:DB ポートの非公開を確認。OS パッチは 11/3 提供予定 ・Fargate:既存タスクの入れ替えが必要 ・GameLift:フリートの作り直しが必要だが、修正済み AMI はまだ 告知の更新続いているので、こまめに確認を...
aws.amazon.com/jp/security/s… おはようございます。AWS における CVE-2026-98432 は「EC2の中身を更新すればいいんでしょ」ではないので気を付けましょう。結構中身が書き換わってきています。
15
104
22,171
「AI のハッキングボットは地道な作業の8割を担えるが、新しい攻撃経路を考えるには、まだ人の創造性と経験が必要」という話。 守る側も同じだと思います。 脆弱性スキャンやログ分析は自動化できても、「どれが本当に危ないか」を決めるのは人。
Anyone claiming they have a 100% automated “hackbot” that can breach any app with zero human touch is wrong, at least most of the time. Every app is different. Different stack, different logic, different weak points. You still need creativity + experience to invent fresh attack paths. A hackbot can handle ~80% of the grunt work. But you still have to: • Tune the tools • Know what you’re actually looking for • Keep your skills sharp Keep hacking 👍
79
認証局 eMudhra の弱い鍵の件。Kuman さんの要約が分かりやすいです。 Cloudflare の観測では、最新ブラウザはおおむね対応済みだが、Android WebView は30〜40%が、まだ問題の証明書を受け入れているとのこと。 なお、Cloudflare の通信が傍受された証拠は、今のところ見つかっていないそうです。
認証局のeMudhraが、インターネットを守る錠前に115桁の数を選ぶべき場面で「4」( 4桁ですらなく、ただの4) を選んでいた件。Cloudflareが1週間追いかけた記録。 ▼何が起きたか ・影響した中間認証局の秘密鍵は、公開されている証明書から誰でもほぼ即座に復元できた ・弱かった鍵は8つ。4、56、66、115、155、156、230、237 ・「同じ署名鍵を誰でも独立に復元でき、任意のドメインの証明書を作れる」 ▼Cloudflareの初動 ・10/19 影響の大きいシステムを即日パッチ。脆弱なeMudhra鍵を拒否するように ・着手から4時間で全体の分析を完了し、その日のうちにチームに確認を依頼 ・10/21 ログ収集の展開が完了 ▼1週間の観測 ・弱いeMudhra鍵を使った接続の試みが約22,000件 ・そのうち3分の2はテストサイトへの取得 ・160件ほどが、それとは別の挙動として目立った ・偽造証明書の1つは10/20 18:19 UTC付。Mozillaのバグ報告が公開されてから1時間以内 ▼パッチが届いていない側 ・最新のブラウザはおおむね対応済み。ただしボットと古いブラウザは別 ・5,000万件の調査で、Android WebViewは30〜40%がまだ受け入れる ・大規模なネットワークでは、半数以上が依然として侵害された証明書チェーンを受け入れる blog.cloudflare.com/emudhra-…
2
3
865
①は、クラウドの「責任共有モデル」と同じ考え方。 サーバー会社が守るのは基盤まで。どの PHP バージョンで動かすかは、利用者側の判断になることが多いです。
PHPのセキュリティ相談、最近本当に増えています。多い勘違いを4つ。 ①「サーバー会社が更新してくれる」→アプリ側のPHPのバージョンは自分の責任です。 ②「動いてるから大丈夫」→サポートが切れても普通に動きます。動く≠安全。特に先日のPHPの件だとこれがアウト。 ③「全部作り直すしかない」→使っていない機能を消すのが一番安い対策。サイトを閉じるのも選択肢の一つ。 ④「WordPressは最新です」→WordPressはPHPという言語でできています。だから最新だからといって、安全な訳では無い。
1
128
フランス下院で、配信事業者に「1GB あたり 0.055 ユーロ」を課す修正案が可決。 ただし僅差の可決で、まだ上院の審議前とのこと。 計測は ISP が事業者・CDN ごとに行う仕組みのようですが、ISP 内のキャッシュや CDN 経由の通信をどう振り分けるのか、ネットワーク屋としては気になります。
wtf this is absurd: France’s lower house backed a €0.055-per-GB tax on data sent to French users by providers like Netflix and Google. I seriously wonder if they don't understand that the higher costs will be passed directly on to the end customers.
104