Advertise on podcast: サイバーセキュリティ新聞

PHP祭りの裏側で、インターネットの信頼基盤そのものを揺るがす事件が起きていました。 本エピソードでは、2026年10月に発覚したeMudhraの中間認証局（中間CA）秘密鍵問題を取り上げ、PHPの重大な脆弱性との違い、HTTPSの信頼構造、デジタル証明書の偽造リスク、そして第三者監査の限界について解説します。 取り上げる主なテーマ - PHP祭りとは何か - CVE-2026-109618・CVE-2026-109619 - eMudhra中間CA秘密鍵問題 - HTTPSとデジタル証明書 - ルートCAと中間CAの信頼構造 - 公開鍵・秘密鍵の仕組み - P-384楕円曲線暗号 - 秘密鍵の値が「4」だった問題 - 暗号鍵生成時の乱数品質 - TLS証明書とコード署名証明書 - 偽造証明書によるWebサイトのなりすまし - DNS・中間者攻撃 - 証明書透明性（CTログ） - ChromeのCRLSet - FirefoxのOneCRL - Sectigoによる交差署名 - API通信と証明書ストア - Python・Docker・Cloudflareへの影響 - HSMとFIPS 140-2認証 - 第三者監査と実装検証の限界 - 信頼の撤回とサイバーガバナンス PHPの重大な脆弱性は、攻撃者が未修正のサーバーで不正なコードを実行し、データを盗んだり、システムを乗っ取ったりする危険を生みます。 しかしeMudhraの問題は、異なる階層のリスクを突きつけました。 それは、インターネット上で「相手が本物である」と証明する仕組み自体が、偽造に利用できる状態になっていたことです。 今回問題となったのは、8件の中間CA証明書に対応する秘密鍵でした。 本来、極めて大きな乱数から生成されるべきP-384の秘密鍵が、すべて256未満という異常に小さな値になっていました。 そのうちの1つは、なんと「4」。 強力な暗号アルゴリズムを採用していても、鍵の生成過程に重大な欠陥があれば、安全性は失われます。 さらに恐ろしいのは、攻撃者が認証局のサーバーへ侵入する必要すらなかったことです。 公開証明書の情報から、秘密鍵を短時間で再現できる状態だったのです。 これにより、影響を受けた認証局を引き続き信頼するシステムでは、第三者が偽造した証明書を正規のものとして受け入れてしまう危険が生じました。 HTTPSは通信を暗号化します。 しかし、暗号化された通信の相手が本当に正しい相手なのかを確認できなければ、利用者は安全だと信じながら偽のサーバーへ情報を渡してしまう可能性があります。 今回、Google ChromeとMozilla Firefoxは緊急対応を実施しました。 証明書透明性、失効情報の配信、信頼ストアの更新など、複数の防御策が重要な役割を果たしています。 一方で、企業には別の課題があります。 ブラウザが保護されても、独自の証明書ストアを利用するAPI、業務アプリケーション、Dockerコンテナなどが同じ状態とは限りません。 OSをアップデートしただけで、すべての通信が安全になるわけではないのです。 そして、今回の事件が突きつけたもう1つの教訓があります。 認証されたハードウェアを使っていることと、そのハードウェアを通じて作られた成果物が安全であることは、同じではありません。 eMudhraは、FIPS 140-2 Level 3に適合するHSMを利用し、独立監査も受けていたと説明しています。 それでも、弱い秘密鍵の問題は見逃されました。 監査済みだから安全。 暗号化されているから安全。 有名な認証局だから安全。 こうした判断だけでは、十分ではありません。 重要なのは、何を信頼するかだけでなく、信頼の根拠が破綻したときに、その信頼をどれだけ迅速に撤回できるかです。 PHPの脆弱性とeMudhraの秘密鍵問題。 一方はサーバーの安全性、もう一方は通信相手の真正性を脅かす問題でした。 サイバーセキュリティは、侵入を防ぐことだけではありません。 私たちが何を根拠に、誰を信頼しているのか。 その信頼を、誰が検証し、誰が取り消せるのか。 インターネットの信頼基盤と、監査・認証・ガバナンスの本質を考えます。

クラウドが止まると、何が止まるのでしょうか。 本エピソードでは、クラウド基盤へのランサムウェア攻撃、委託先経由のシステム障害、APIやSaaSへの依存、そして事業継続の現実を解説します。 取り上げる主なテーマ クラウド基盤へのランサムウェア攻撃 共通基盤が止まるリスク IDCFクラウド事案 複数組織への連鎖影響 単一障害点としてのクラウド 日理物流・入出荷停止の事例 委託先経由のサイバー被害 第一興商・日本コロムビアグループの事例 APIと管理ツールのリスク スカイチケット、NewsPicks事案 Commune、ココナラ事案 システム停止だけでは封じ込めにならない理由 ログ保全と証拠保全 バックアップの独立性 シックス・アパートの復旧事例 大阪公立大学のランサムウェア対応 BCPと手動運用 効率化と冗長性のバランス サイバー攻撃は、もはや「自社のサーバーが侵入されたかどうか」だけの問題ではありません。 自社が直接攻撃されていなくても、利用しているクラウド、委託先、SaaS、API、物流管理システムが止まれば、業務は止まります。 トラックは動く。 倉庫には商品がある。 担当者も出社している。 それでも、出荷指示、在庫確認、配送先情報、顧客連絡先がクラウドの中に閉じ込められていれば、現場は動けません。 現代の企業は、効率化のために多くの業務を共通基盤へ集約してきました。 しかし、その便利さは同時に、巨大な単一障害点を生み出します。 同じクラウドに相乗りする。 同じSaaSに依存する。 同じ委託先にデータ処理を任せる。 同じAPIで複数の業務をつなぐ。 そこが止まれば、自社だけでなく、取引先、顧客、物流、教育、行政サービスまで連鎖的に止まる可能性があります。 重要なのは、システムを守ることだけではありません。 そのシステムが止まったとき、業務をどう続けるのか。 どの業務は何時間まで止められるのか。 どのデータを別環境に保管しているのか。 紙、電話、Excel、人手で代替できる手順はあるのか。 誰が代替運用への切り替えを決めるのか。 サイバーセキュリティは、侵入を防ぐ技術から、事業を止めない設計へと変わっています。 守るべきものは、サーバーではありません。 事業活動そのものです。 効率化を突き詰めた社会が、どこで脆くなるのか。 クラウド障害、委託先侵害、BCPの現実から考えます。

AIに、どこまでの権限を渡してよいのでしょうか。 本エピソードでは、ホワイトハウスで署名された「White House Accord on Super Intelligence」を手がかりに、フロンティアAI企業の責任、外部評価、取締役会監督、そしてAIエージェント時代の権限管理について解説します。 取り上げる主なテーマ - White House Accord on Super Intelligenceとは何か - フロンティアAI企業の自主的コミットメント - 超知能と安全性 - 内部統制 - 内部監視チーム - 独立した外部評価・外部監査 - 取締役会レベルの監督 - AIモデルの能力監視 - サイバーセキュリティとAI - AIが攻撃の道具になるリスク - AIシステム自体が攻撃対象になるリスク - 間接プロンプトインジェクション - 過剰なエージェンシー - AIエージェントへの過剰な権限付与 - ゼロトラスト - アクセス制御ゲートウェイ - モデル単体評価とシステム全体評価 - AIベンダー評価 - ログ・監査証跡・取締役会報告 - NIST CSF 2.0のGOVERN この合意は、AI企業が「安全に取り組んでいます」と宣言するだけの文書ではありません。 重要なのは、AIの能力が上がるほど、モデルそのものだけでなく、AIが接続するツール、API、データ、権限、承認手順まで含めて評価しなければならないという点です。 AIが危険になるのは、悪意を持ったときだけではありません。 人間の指示が曖昧だったとき。 外部資料に悪意ある命令が埋め込まれていたとき。 AIが文脈を読み間違えたとき。 本来不要な送信権限や書き込み権限まで与えられていたとき。 そのとき、AIは正規の権限を使って、想定外の行動を実行してしまう可能性があります。 だからこそ、AIの安全性は「モデルが賢いかどうか」だけでは決まりません。 AIにどのシステムを触らせるのか。 どのAPIを呼び出せるのか。 どのデータを読ませるのか。 どの権限をいつ、どの条件で渡すのか。 暴走したときに、どこで止めるのか。 その記録を、誰が後から検証できるのか。 これらを設計する必要があります。 外部評価を受けたAIだから安全。 有名企業のモデルだから安全。 合意に参加している企業だから安全。 そう考えるのは危険です。 評価されたのは、モデル単体なのか。 ツール連携を含む本番環境なのか。 外部送信権限を持たせた状態なのか。 自社のデータや業務フローに組み込んだ状態なのか。 利用企業側も、そこを確認しなければなりません。 AI時代のセキュリティは、AIに「してはいけない」と言い聞かせるだけでは不十分です。 AIからの要求を無条件に信用せず、システム側で権限を絞り、文脈に応じて実行を止め、ログを残し、取締役会や経営層が是正まで確認する。 超知能合意から、AIエージェント時代のガバナンスを考えます。

AIエージェントは、企業のデータ基盤をどう変えるのでしょうか。 本エピソードでは、津田通隆氏（Open Data Spaces Chief Architect／IPA AI&データアーキテクチャ戦略室長）によるデータ基盤の技術変遷に関する分析を手がかりに、ビッグデータの3Vから、GFS、MapReduce、NoSQL、JSON、データレイク、データウェアハウス、データレイクハウスまでの流れをたどります。 その上で、AIエージェント時代に、企業のデータ基盤がどのような新しいサイバーリスクを抱えるのかを解説します。 取り上げる主なテーマ - ビッグデータの3V - Volume・Variety・Velocity - Google File System - MapReduce - Hadoop - NoSQL - JSONとXML - データレイク - データウェアハウス - データスワンプ - データレイクハウス - コンピュートとストレージの分離 - Apache Parquet - Apache Iceberg - コントロールプレーンとデータプレーン - データカタログ - AIエージェントとデータ基盤 - ABAC（属性ベースアクセス制御） - 一時的なアクセス権限 - 間接プロンプトインジェクション - RAGとキャッシュ - ゼロコピーアーキテクチャ - AI時代のインシデント対応 この20年、企業はデータを集め、保存し、検索し、分析するための巨大な基盤を作ってきました。 かつての課題は、データの量、多様性、速度でした。 大量のデータをどう保存するか。 画像、動画、ログ、テキストのような非構造化データをどう扱うか。 リアルタイムに発生するデータをどう処理するか。 その結果、企業はデータレイクハウスという巨大な図書館を作り上げました。 しかし今、その図書館の読者が変わろうとしています。 人間のデータサイエンティストではなく、AIエージェントが、膨大なデータを読み、解釈し、APIを呼び出し、外部システムを操作する時代が来ています。 問題は、AIが賢いことではありません。 AIが読んだデータの内容によって、次に何を実行するかを自律的に判断してしまうことです。 メール、PDF、請求書、チャット、社内文書。 そこに悪意ある指示が埋め込まれていれば、AIはそれを業務指示として解釈するかもしれません。 だからこそ、AI時代のデータ基盤では、単にデータを集めるだけでは不十分です。 誰が、いつ、どの目的で、どのデータに、どれくらいの時間アクセスできるのか。 AIには何を読ませてよいのか。 AIが作った提案と、実際のシステム実行をどう分離するのか。 削除したはずのデータが、RAGやキャッシュに残っていないか。 事故が起きたとき、業務状態まで巻き戻せるのか。 AIエージェント時代のセキュリティは、モデルの性能だけでは決まりません。 データ基盤、権限管理、監査ログ、実行承認、インシデント対応を一体で設計できるかが問われます。 巨大な図書館を作った企業は、次に「誰に読ませるのか」「どこまで行動させるのか」を決めなければなりません。 データレイクハウスとAIエージェントの時代に、企業のサイバーセキュリティがどう変わるのかを考えます。 【参考資料】 1. 津田通隆「The 3Vsからデータレイクハウスまでの技術変遷【AIとデータ基盤 #1】」https://note.com/tsuda_michitaka/n/ncc877587ec8c 2. NIST “Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents” (2026)https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai 3. NIST / NCCoE “Accelerating the Adoption of Software and AI Agent Identity and Authorization Concept Paper” (2026)https://www.nccoe.nist.gov/publications/other/accelerating-adoption-software-and-ai-agent-identity-and-authorization-concept 4. OWASP “LLM06:2025 Excessive Agency”https://genai.owasp.org/llmrisk/llm062025-excessive-agency/5. NIST SP 800-207 “Zero Trust Architecture”https://csrc.nist.gov/pubs/sp/800/207/final 6. Databricks “Unity Catalog best practices”https://docs.databricks.com/aws/en/data-governance/unity-catalog/best-practices 7. Apache Polaris “CVE-2026-42809 — Stage-Create Credential Vending”https://polaris.apache.org/community/security-advisories/cve-2026-42809/ 8. AWS IAM “Disabling permissions for temporary security credentials”https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html 9. NIST SP 800-162 “Guide to Attribute Based Access Control (ABAC)”https://www.nist.gov/publications/guide-attribute-based-access-control-abac-definition-and-considerations-0 10. UK NCSC “Prompt injection is not SQL injection (it may be worse)”https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection 11. OWASP “Retrieval-Augmented Generation (RAG) Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html 12. OWASP “Transaction Authorization Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html 13. Beurer-Kellner et al. “Design Patterns for Securing LLM Agents against Prompt Injections” (2025)https://arxiv.org/abs/2506.08837 14. OWASP “AI Agent Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html 15. NIST SP 800-61 Rev.3 “Incident Response Recommendations and Considerations for Cybersecurity Risk Management”https://csrc.nist.gov/pubs/sp/800/61/r3/final 16. OWASP “Logging Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html 17. NIST “Cybersecurity Framework (CSF) 2.0”https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

SPOF、つまり単一障害点とは、壊れやすい機械部品だけを指す言葉ではありません。 本エピソードでは、重要インフラに潜むSPOFを、設備・人・権限・認証・通信・ベンダー対応・組織設計の観点から解説します。 取り上げる主なテーマ - SPOFとは何か - 単一障害点 - 重要インフラの停止リスク - 物理的故障だけではないFailure - 侵害されたまま稼働するフェイルアンセーフ - 人間系SPOF - エース担当者依存 - ソフトSPOF - 待ち行列理論と過負荷 - 見せかけの冗長化 - 共通原因障害 - ヒースロー空港の電力障害 - 英国鉄道の復旧遅延 - 水処理施設の仮想シナリオ - 権限・技能・情報・認証・通信・独立性 - 職務代行と自動権限移行 - 代行者単独完遂率 - 権限委譲時間 - AI時代の不可視のSPOF SPOFは、単に「1台しかないサーバー」や「1本しかない回線」の問題ではありません。 車が壊れることより、車の鍵が1つしかないこと。 予備設備があることより、切り替え方法を知っている人が1人しかいないこと。 担当者がいることより、その人しか判断できず、その人しか認証トークンを持っていないこと。 こうした依存関係の集中こそが、重要インフラを止める本当の単一障害点になります。 さらに厄介なのは、人が倒れなくても組織が止まることです。 緊急時に問い合わせが集中し、判断が1人に詰まり、待ち時間が許容時間を超えた瞬間、担当者が生きていても、元気に働いていても、組織は機能停止します。 冗長化も、単に数を増やせばよいわけではありません。 Teamsとメールがあっても、同じ認証基盤に依存していれば同時に死にます。 データセンターが2つあっても、同じ変電所に依存していれば同時に落ちます。 正担当と副担当がいても、同じ権限・同じ鍵・同じ通信経路に依存していれば、代替にはなりません。 本当に必要なのは、同じ原因で同時に失われない設計です。 代行者には、名前だけでなく、権限、技能、情報、認証、通信、時間的・地理的独立性が必要です。 そのうち1つでも欠ければ、代替態勢は機能しません。 強い組織とは、エースが倒れない組織ではありません。 エースが倒れても、権限・情報・認証・技能の連鎖が切れず、別の人が迷わず安全に引き継げる組織です。 重要インフラを止めるのは、壊れた機械だけではありません。 誰が判断するのか。 誰が止めるのか。 誰が鍵を持っているのか。 誰がベンダーに連絡できるのか。 主担当が応答しないとき、何分で権限が移るのか。 SPOFを、機械ではなく組織設計の問題として考えます。

暗号は、ただの技術なのでしょうか。 本エピソードでは、1990年代の「暗号戦争」から、サイファーパンク、国家監視、バックドア論争、メタデータ、量子コンピューター時代の暗号移行までを解説します。 取り上げる主なテーマ - 暗号戦争とは何か - サイファーパンク - Eric Hughes - Tim May - John Gilmore - Hal Finney - Electronic Frontier Foundation - 法律によるプライバシー保護とコードによる保護 - データ最小化と選択的開示 - 暗号輸出規制 - 40ビット暗号と56ビットDES - Deep Crack - コードは言論か - Clipper Chip - バックドア論争 - 端末・クラウド・認証への攻撃移行 - メタデータの危険性 - Signalとシールドセンダー - 量子コンピューター - 耐量子暗号 - ML-KEM・ML-DSA - プライバシーと捜査のジレンマ サイファーパンクが目指したのは、国家や企業に「プライバシーを守ってください」とお願いすることではありませんでした。 強力な暗号によって、第三者がそもそも情報を読めない構造を作ること。 つまり、法律による保護ではなく、コードと数学による保護を実装することでした。 1990年代、アメリカ政府は強力な暗号を武器のように扱い、民間利用や輸出を制限しようとしました。 しかし、サイファーパンクやEFFは、弱い暗号がどれほど脆いかを実際に破って示しました。 40ビット暗号は短時間で解読され、56ビットDESも専用機によって現実的な時間で破られました。 その結果、暗号を意図的に弱くしておくという発想は後退し、現在ではAESのような強力な暗号が、スマートフォン、銀行取引、メッセージアプリ、クラウド通信に当たり前のように使われています。 しかし、暗号戦争は終わっていません。 暗号そのものが強くなったことで、攻撃者は暗号を正面から破るのではなく、端末、クラウド、認証、バックアップ、人間、そしてメタデータを狙うようになりました。 メッセージの中身が読めなくても、誰が、誰に、いつ、どれくらいの頻度で連絡しているかが分かれば、人間関係や行動パターンは推測できます。 さらに、量子コンピューターの登場によって、現在の暗号方式の前提も揺らぎ始めています。 暗号は善人だけを守り、悪人だけを解除することはできません。 だからこそ、プライバシー、捜査、国家安全保障、サイバー防衛のあいだで、社会は今も難しい選択を迫られています。 「善人だけが使えて、悪人が使ったときだけ政府が解除できる暗号」は存在するのか。 暗号戦争の歴史から、デジタル社会の自由と安全を考えます。

脅威モデリングとは、サイバー攻撃の手口をただ並べる作業ではありません。 本エピソードでは、脅威モデリングとは何か、なぜ経営者や事業責任者に必要なのかを解説します。 取り上げる主なテーマ - 脅威モデリングとは何か - セキュア・バイ・デザイン - 脆弱性診断・ペネトレーションテストとの違い - OWASPの4つの問い - 守るべき資産ではなく「許容できない結果」から考える - 信頼境界（Trust Boundary） - 攻撃者の期待利益 - 金銭目的の犯罪者と国家支援型攻撃者の違い - ランサムウェアと知的財産窃取 - 多層防御 - 残留リスク・残余リスク - CISOと事業責任者の役割分担 - リスク受容のガバナンス - 悪いKPIと良いKPI - STRIDEとチェックリスト化の罠 - 経済産業省・国家サイバー統括室のガイドライン - AI時代の脅威モデリング 脅威モデリングの本質は、未来の攻撃を完璧に予言することではありません。 自社にとって絶対に起きてはいけない結果は何か。 どこに信頼境界があるのか。 誰が、どの目的で、どの経路から攻撃してくるのか。 どのリスクを設計段階で消すのか。 残ったリスクを誰が引き受けるのか。 これらを、システムが完成する前に考えるためのプロセスです。 完成した家の窓や鍵を後から調べるのが脆弱性診断だとすれば、脅威モデリングは、最初の設計図の段階で「泥棒が届かない位置に窓を置く」「火事が広がらない区画を作る」ための作業です。 最新のEDRやゼロトラスト製品を導入しても、構造的な欠陥は後から簡単には直せません。 だからこそ重要なのは、攻撃者の視点から逆算し、事業への影響を基準に設計することです。 金銭目的の犯罪者は、早く利益を得るためにランサムウェアで業務を止めます。 国家支援型の攻撃者は、気づかれないように長期間潜伏し、設計図や知的財産を少しずつ盗みます。 同じ侵入口でも、相手によって必要な防御は変わります。 そして、どれだけ対策しても最後には残留リスクが残ります。 そのリスクを受け入れるのは、CISOだけではありません。 そのシステムで利益を得る事業責任者、経営層が、条件と期限を明確にして引き受ける必要があります。 脅威モデリングは、IT部門だけの作業ではありません。 不確実なリスクに名前をつけ、優先順位をつけ、誰が責任を持って前に進むのかを決めるための、経営の思考技術です。

個人情報は、本人の同意だけで本当に守れるのでしょうか。 本エピソードでは、個人情報保護法改正を起点に、医療データ、購買履歴、AI開発、データ独占、そして集団的プライバシーの問題を解説します。 取り上げる主なテーマ - 個人情報保護法改正 - 同意中心主義の限界 - 統計作成等の例外 - AI開発とデータ二次利用 - 課徴金制度 - 個人情報保護委員会の権限強化 - 特定生体個人情報 - 子どもの個人情報保護 - 匿名化の限界 - オントロジーと意味の地図 - 集団的プロファイリング - 医療データと購買履歴 - 住宅ローン・保険・採用への影響 - EUのEHDSとの比較 - Secure Data Environment - Findata - データ集中とサイバーリスク - データ領主 - データフライホイール - 公正取引委員会と競争政策 - グループ・プライバシー 今回の法改正は、単なる「同意なしでデータを使えるようになる話」ではありません。 より深い論点は、データの使い方が、本人同意の有無から、データの流れ、技術的な隔離、利用目的、事後監督、競争政策へと移っていることです。 名前や住所を消しても、データは完全に安全になるとは限りません。 深夜の購買履歴。 特定の診療科への通院。 健康食品の購入。 決済履歴。 位置情報。 生活パターン。 これらが組み合わされると、個人を直接名指ししなくても、「このような行動をする集団は、特定の病気や返済リスクが高い」と推論される可能性があります。 問題は、あなた個人が特定されるかどうかだけではありません。 あなたが属すると推定された集団が、保険、融資、採用、広告、価格設定で不利益に扱われるかもしれないことです。 さらに、医療機関や小売業のデータが、一部のAI企業に集中すれば、攻撃者にとっては高価値な標的になり、同時に市場では「データ領主」が生まれる可能性があります。 AIの精度は、データが集まるほど高まります。 精度が高まれば、さらに利用者が増えます。 利用者が増えれば、さらにデータが集まります。 このデータフライホイールが回り始めると、後発企業や中小企業は追いつけなくなります。 個人情報保護法改正は、AI開発の追い風になる一方で、技術的統制、セキュアデータ環境、競争政策、集団的プライバシーの設計を迫る制度変更でもあります。 私たちのデータは、社会全体を豊かにする公共的なインフラになるのか。 それとも、ハッカーの標的となり、一部企業の私有資産になるのか。 AI時代の個人情報保護とデータガバナンスを考えます。

生成AIに入力したそのプロンプトは、本当に「自分だけの画面の中」に留まっているのでしょうか。 本エピソードでは、生成AI時代のプロンプト入力、患者データ、機微情報、SaaSガバナンスについて解説します。 取り上げる主なテーマ - プロンプトは外部送信なのか - 生成AIとデータフロー - 患者データ・医療情報・メンタルヘルス情報の扱い - 日本の個人情報保護法とPPCの考え方 - HIPAAとBAA - ePHIとクラウド事業者 - 第三者提供と委託の違い - BetterHelp事案 - GoodRx事案 - 匿名化の罠 - 自由記載と再識別リスク - OpenAI、Azure OpenAI、Google Gemini、AWS Bedrockのデータ保持 - Web検索・音声・メモリー・スレッド機能のリスク - RAGと社内データ連携 - DLP・RBAC・監査ログ - SaaSのサイレントアップデート - AI導入前のガバナンス設計 生成AIの問題は、AIが正しい答えを出すかどうかだけではありません。 もっと手前にある問題は、何をAIに渡したのか。 そのデータはどこへ送られるのか。 どこに保存されるのか。 誰が見られるのか。 どの機能をオンにすると、外部検索、ログ保存、メモリー、音声処理、サードパーティ連携が動くのか。 プロンプト入力は、単なる文章作成ではありません。 多くの場合、それは外部SaaSへのデータ送信イベントです。 特に、患者情報、メンタルヘルス情報、診断名、服薬、通院歴、家族関係、職場の悩み、トラウマ、希死念慮などは、極めて感度の高い情報です。 名前を消しても安全とは限りません。 自由記載に残る文脈だけで、個人が再識別されることがあります。 重要なのは、「どのAIサービスなら安全か」ではありません。 どの機能を使うのか。 どのデータを入れてよいのか。 どのログが残るのか。 誰がアクセスできるのか。 事故が起きたとき、誰が止めるのか。 ブランド名ではなく、機能単位・契約単位・データ経路単位で管理することです。 生成AIを安全に使うとは、最新モデルを選ぶことではありません。 データを分離し、入力境界を決め、便利機能のスイッチを確認し、ログと緊急停止手順を整えることです。 そのプロンプトは、外部送信ではないのか。 AI時代の患者データ、機微情報、SaaSガバナンスを考えます。

生成AIを使った中学生が、大手動画配信サービスに大量の自動退会リクエストを送り、数万件規模のアカウントを強制退会させたとされる事件。 本エピソードでは、この事件を単なる「少年のいたずら」や「AIの悪用」として片付けず、生成AI時代のサイバー教育、API設計、企業側の防御、家庭でのガードレールについて考えます。 取り上げる主なテーマ - 生成AIを使った不正プログラム作成 - 未成年によるサイバー加害 - バンダイチャンネル大量退会事件 - APIへの自動リクエスト - レートリミットの重要性 - 退会・削除処理に必要な再認証 - セキュア・バイ・デザイン - OWASP ASVS - 生成AIによる実行ハードルの低下 - スクリプトキディとAI時代の違い - 不正アクセス禁止法 - 電子計算機損壊等業務妨害 - 被害防止から加害予防への教育転換 - 未成年者向けサイバー教育 - 家庭でのAI利用ルール - ガードレールとしてのフィルタリングと対話 - 技術的好奇心と倫理の境界線 生成AIは、子供たちに強力な学習ツールを与えました。 しかし同時に、かつては専門知識や経験が必要だった自動化スクリプトの作成を、誰でも短時間で実行できる環境も生み出しています。 問題は、子供たちの好奇心そのものではありません。 問題は、技術的に「できること」と、法律的・倫理的に「やってはいけないこと」の境界線を、社会が十分に教えられていないことです。 そして企業側にも課題があります。 退会処理、削除処理、個人情報変更、決済処理のような不可逆的でリスクの高い操作には、再認証、レートリミット、異常検知、取り消し可能な設計が必要です。 サイバー教育は、もはや「ネットでだまされないための教育」だけでは足りません。 これから必要なのは、子供たちが無自覚に加害者にならないための教育です。 技術の好奇心を否定せず、しかし超えてはいけない一線を具体的に教えること。 生成AI時代の未成年者サイバー教育と、企業のセキュア・バイ・デザインを考えます。

ピザの注文は、戦争や危機を予測できるのでしょうか。 本エピソードでは、ワシントンD.C.周辺で語られてきた「ペンタゴン・ピザ指数」を出発点に、OSINT、行動データ、AI予測、サイバー防御の危うさを考えます。 取り上げる主なテーマ - ペンタゴン・ピザ指数とは何か - 湾岸戦争前夜のピザ注文逸話 - Google Mapsの混雑データ - OSINTと行動データ - 代理変数の危うさ - 確認バイアス - 外れた予測が見えにくい問題 - サイバー防御における外部シグナル - SOCにおけるアラート優先度付け - 行動OSINTと脅威インテリジェンス - 偽情報検出と現実世界データ - AIによる多変量分析 - 説明可能AI（XAI） - EU AI Actと透明性 - 個人情報・プライバシーのリスク - RAGとデータ混入リスク - 物理空間を使ったAIへのノイズ注入 - 監視社会とサイバー防衛の境界線 ペンタゴン周辺のピザ店が深夜に混むと、世界で何かが起きる。 一見すると都市伝説のような話ですが、そこには現代のAI時代に通じる重要な論点があります。 人間は、重大な危機の前に行動を変えます。 深夜まで働く。 周辺の飲食店が混む。 交通量が変わる。 SNSの話題が変わる。 ログに出る前に、現実世界の行動に兆候が出る。 こうした弱いシグナルを、AIがサイバー攻撃のアラート、脅威インテリジェンス、ニュース、OSINTと組み合わせれば、危機の優先順位付けに使える可能性があります。 しかし、そこには大きな危うさもあります。 ピザ店が混んでいる理由は、本当に国家危機なのか。 ただの観光客、イベント、大学生の集まりではないのか。 事件が起きた後に、都合のよいデータだけを拾っていないか。 攻撃者がわざと物理空間にノイズを流し、防御AIを誤作動させる可能性はないのか。 AI予測は、未来を当てる魔法ではありません。 重要なのは、弱いシグナルを盲信することではなく、なぜそのリスクスコアが上がったのかを説明できることです。 デジタル空間を守るために、現実世界の行動データまで読み取る時代。 その便利さと危うさを、ペンタゴン・ピザ指数から考えます。

AIが起こした損害に、保険は下りるのでしょうか。 生成AIや自律型AIエージェントが業務に入り込む一方で、AIの誤判断、ハルシネーション、データ漏えい、自動処理の失敗が起きたとき、誰がその損害を負担するのかという問題が浮上しています。 本エピソードでは、AI保険市場と「サイレントAIリスク」の最前線を解説します。 取り上げる主なテーマ - AI保険とは何か - サイレントAIリスク - 既存のサイバー保険・賠償責任保険の限界 - AI免責条項 - 生成AI除外フォーム - Munich ReのaiSure - Lloyd’s市場のAI専門保険 - AIモデルの性能保証 - 技術的デューデリジェンス - モデルカード - 監査ログ - キルスイッチ - ヒューマン・イン・ザ・ループ - AI事故と責任分界 - Air Canadaチャットボット事案 - AIサプライチェーンと責任の押し付け合い - EU AI Act - 米国保険市場の分裂 - 英国ロイズ市場と実験的商品 - 日本の生成AI保険と損保各社の動き - AIガバナンスと保険取得可能性 AI保険は、何でも肩代わりしてくれる魔法の杖ではありません。 むしろ、保険会社が「この企業はAIを安全に運用できているか」を審査する、外部ガバナンスの仕組みになりつつあります。 どのAIを使っているのか。 どの業務に組み込んでいるのか。 どのデータを入力しているのか。 AIの判断を誰が監視しているのか。 事故が起きたときに止める権限は誰にあるのか。 ログと証拠は残っているのか。 これらを説明できない企業は、いざ事故が起きたときに「AIに起因する損害は補償対象外です」と突き返される可能性があります。 AI保険の本質は、単なるリスク移転ではありません。 AIを業務に使う企業が、自社のガバナンス、監査、責任分界、インシデント対応をどこまで整えているかを問われる時代が来ています。 AIを使う企業は、保険で守られる前に、まず保険会社から審査される。 AI時代のリスク、責任、保険、そして企業統治を考えます。

民主主義は、どこから攻撃されるのでしょうか。 投票箱でしょうか。 選挙システムでしょうか。 それとも、私たちが毎日見ているニュースフィードやSNSのタイムラインでしょうか。 本エピソードでは、サイバー攻撃、偽情報、ハック・アンド・リーク、ディープフェイクが、民主主義の土台である「信頼」をどのように揺さぶるのかを解説します。 取り上げる主なテーマ - サイバーセキュリティと民主主義 - 選挙へのサイバー攻撃 - 民主主義のサプライチェーン - 選挙管理機関・政党・メディア・委託先のリスク - 日本年金機構、ProjectWEB、JAXA事案から見える信頼の毀損 - DNCハッキング - MacronLeaks - ハック・アンド・リーク - 本物の文書に偽物を混ぜる情報操作 - Liar’s Dividend（嘘つきの配当） - ディープフェイクと真実の暴落 - 能登半島地震時の偽救助要請 - SNS上の偽情報と認知戦 - 外国干渉と選挙の正当性 - CISA、ENISA、DSAから見る制度設計 - 能動的サイバー防衛と言論統制の境界線 - 民主主義を守るレジリエンス 現代の攻撃者は、必ずしも投票結果を直接書き換えるわけではありません。 狙われるのは、投票箱そのものではなく、選挙を支える周辺システムです。 政党、行政機関、メディア、クラウド委託先、SNS、災害時の情報流通。 そこに侵入し、情報を盗み、偽情報を混ぜ、社会の不信感を増幅させる。 その目的は、特定の嘘を信じ込ませることだけではありません。 「何が本当なのか分からない」状態を作り、選挙や行政やメディアへの信頼を少しずつ削ることです。 一方で、偽情報対策を名目に、政府が「真実の裁判官」になってしまえば、それは言論統制の入り口にもなります。 民主主義を守るためのサイバー防衛には、攻撃から社会を守る仕組みと、防衛を名目に権力が肥大化しない仕組みの両方が必要です。 サイバー攻撃は、もはやパスワードやサーバーだけを狙うものではありません。 私たちの認識、信頼、判断そのものが攻撃対象になる時代に、民主主義をどう守るのかを考えます。

サイバー防御のガイドラインは、どこまで公開すべきなのでしょうか。 すべて公開すれば、攻撃者に攻略本を渡すことになる。 すべて隠せば、利用者や中小企業は安全な製品を選べなくなる。 本エピソードでは、フロンティアAI時代におけるサイバーセキュリティ情報の公開・制限共有・時間差公開について解説します。 取り上げる主なテーマ - サイバー防御ガイドラインは公開すべきか - 「全部公開」と「全部非公開」の限界 - 攻撃者にとって価値がある情報とは何か - 一般原則と具体的な弱点の違い - MFA、ポート閉鎖、脆弱性報告窓口 - パッチ遅延・例外設定・未修正脆弱性の危険性 - フロンティアAIによる情報処理コストの破壊 - CVE情報と攻撃コード生成 - Patch-to-PoC - TLP 2.0 - 一般公開・業界内共有・要保護留保・厳格制限 - SBOMの公開範囲 - 生成AIへの機微情報投入制限 - 時間差公開 - 秘密指定の乱用防止 - 中小企業を排除しない制度設計 - EBPMとしての段階的導入 重要なのは、「防御法を非公開にすること」ではありません。 公開すべきなのは、社会が安全性を判断するために必要な原則、最低要件、責任分界、脆弱性報告窓口、サポート期間です。 一方で、制限すべきなのは、攻撃者の探索・選定・実行コストを具体的に下げる情報です。 どの製品のどのバージョンが未修正なのか。 どのシステムだけMFAの例外になっているのか。 どの環境なら脆弱性が成立するのか。 どの緩和策がまだ未実施なのか。 こうした情報は、AIによって瞬時に結びつけられ、攻撃対象の選定に使われる可能性があります。 だからこそ必要なのは、情報を隠すことではなく、情報の粒度、共有先、公開時期を設計することです。 サイバーセキュリティは、公開か非公開かの二択ではありません。 何を、誰に、どの粒度で、いつ共有し、いつ公開へ移すのか。 フロンティアAI時代の「見せる情報」と「守る情報」を考えます。

会社のセキュリティで、最も重要な急所はどこにあるのでしょうか。 ファイアウォール、VPN、社員のパソコン。 もちろんそれらも重要です。 しかし、多くの企業にとって本当の心臓部は、Active Directory、通称ADです。 本エピソードでは、Active Directoryとは何か、なぜ会社のIDと権限を支配する中枢システムなのか、そしてなぜランサムウェア攻撃者が真っ先にADを狙うのかを解説します。 取り上げる主なテーマ - Active Directoryとは何か - IDと権限の一元管理 - シングルサインオン - Kerberos認証 - ドメイン管理者権限 - グループポリシーの悪用 - VPN・RDP経由の侵入 - ラテラルムーブメント - ランサムウェアとAD乗っ取り - 大阪急性期・総合医療センター事案 - 岡山県精神科医療センター事案 - MFA、ログ、バックアップ - Entra IDとハイブリッド環境 - ゼロトラストへの入り口 ADは、会社の会議室、金庫、社長室、ファイルサーバー、業務システムの鍵をまとめて管理する「マスターキー」です。 便利である一方、攻撃者に奪われれば、会社の正規ルールを使って会社自身を破壊される危険があります。 重要なのは、非技術者のリーダーが技術者になることではありません。 ドメイン管理者権限は誰が持っているのか。 多要素認証は本当に入っているのか。 バックアップはADが乗っ取られても壊されないのか。 ログは監視されているのか。 正しい問いを投げかけることが、組織の心臓部を守る第一歩になります。