サイバーセキュリティ新聞
サイバーセキュリティ、AI、情報戦、国家安全保障、インフラ防衛、認知戦、OSINT、ランサムウェア、サプライチェーンリスクを、政策・経営・技術の交差点から整理・解説する音声メディアです。
本番組では、国内外の一次資料、公的機関レポート、政府発表、技術文書、研究論文、OSINT（公開情報分析）などをもとに、
ランサムウェア
ゼロトラスト
AIとサイバー防衛
ダークウェブ
国家支援型攻撃（APT）
インフラ・OTセキュリティ
サプライチェーン攻撃
偽情報・認知戦
半導体・通信・クラウド
ドローンと電子戦
サイバー政策・制度設計
SOC / CSIRT / フォレンジック
経済安全保障
地政学とテクノロジー
などを、非技術者にも分かるよう構造化して解説します。
「技術そのもの」だけではなく、
なぜ事故が起きるのか
なぜ組織は止まるのか
なぜ投資されないのか
なぜサプライチェーンが弱点になるのか
AIが社会・行政・安全保障をどう変えるのか
といった、「経営・政策・組織・社会構造」まで含めて扱います。
対象リスナーは、
省庁・自治体関係者
インフラ事業者
経営層
リスク管理部門
セキュリティ担当者
報道・政策関係者
AI・IT業界
サイバー安全保障に関心のある一般リスナー
です。
本番組は、防御・教育・制度理解・リスク管理・社会啓発を目的としています。
番組の魅力・推薦
このポッドキャストは未認証のため、最新エピソードのみ表示されます。
実録編#13丨PHP祭りより深刻な「証明書祭り」——eMudhra秘密鍵問題とHTTPS信頼基盤の危機
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の秘密鍵問題。一方はサーバーの安全性、もう一方は通信相手の真正性を脅かす問題でした。サイバーセキュリティは、侵入を防ぐことだけではありません。私たちが何を根拠に、誰を信頼しているのか。その信頼を、誰が検証し、誰が取り消せるのか。インターネットの信頼基盤と、監査・認証・ガバナンスの本質を考えます。
インフラ編#08丨クラウド障害はなぜ社会を止めるのか——共通基盤・委託先・BCPのサイバー防衛
クラウドが止まると、何が止まるのでしょうか。本エピソードでは、クラウド基盤へのランサムウェア攻撃、委託先経由のシステム障害、APIやSaaSへの依存、そして事業継続の現実を解説します。取り上げる主なテーマクラウド基盤へのランサムウェア攻撃共通基盤が止まるリスクIDCFクラウド事案複数組織への連鎖影響単一障害点としてのクラウド日理物流・入出荷停止の事例委託先経由のサイバー被害第一興商・日本コロムビアグループの事例APIと管理ツールのリスクスカイチケット、NewsPicks事案Commune、ココナラ事案システム停止だけでは封じ込めにならない理由ログ保全と証拠保全バックアップの独立性シックス・アパートの復旧事例大阪公立大学のランサムウェア対応BCPと手動運用効率化と冗長性のバランスサイバー攻撃は、もはや「自社のサーバーが侵入されたかどうか」だけの問題ではありません。自社が直接攻撃されていなくても、利用しているクラウド、委託先、SaaS、API、物流管理システムが止まれば、業務は止まります。トラックは動く。倉庫には商品がある。担当者も出社している。それでも、出荷指示、在庫確認、配送先情報、顧客連絡先がクラウドの中に閉じ込められていれば、現場は動けません。現代の企業は、効率化のために多くの業務を共通基盤へ集約してきました。しかし、その便利さは同時に、巨大な単一障害点を生み出します。同じクラウドに相乗りする。同じSaaSに依存する。同じ委託先にデータ処理を任せる。同じAPIで複数の業務をつなぐ。そこが止まれば、自社だけでなく、取引先、顧客、物流、教育、行政サービスまで連鎖的に止まる可能性があります。重要なのは、システムを守ることだけではありません。そのシステムが止まったとき、業務をどう続けるのか。どの業務は何時間まで止められるのか。どのデータを別環境に保管しているのか。紙、電話、Excel、人手で代替できる手順はあるのか。誰が代替運用への切り替えを決めるのか。サイバーセキュリティは、侵入を防ぐ技術から、事業を止めない設計へと変わっています。守るべきものは、サーバーではありません。事業活動そのものです。効率化を突き詰めた社会が、どこで脆くなるのか。クラウド障害、委託先侵害、BCPの現実から考えます。
AI編#16丨ホワイトハウス「White House Accord on Super Intelligence」とは何か——超知能合意・外部評価・AIエージェントの責任分界
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編#15丨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/ncc877587ec8c2. 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-ai3. 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-concept4. 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/final6. Databricks “Unity Catalog best practices”https://docs.databricks.com/aws/en/data-governance/unity-catalog/best-practices7. 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.html9. 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-010. UK NCSC “Prompt injection is not SQL injection (it may be worse)”https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection11. OWASP “Retrieval-Augmented Generation (RAG) Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html12. OWASP “Transaction Authorization Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html13. Beurer-Kellner et al. “Design Patterns for Securing LLM Agents against Prompt Injections” (2025)https://arxiv.org/abs/2506.0883714. OWASP “AI Agent Security Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html15. NIST SP 800-61 Rev.3 “Incident Response Recommendations and Considerations for Cybersecurity Risk Management”https://csrc.nist.gov/pubs/sp/800/61/r3/final16. OWASP “Logging Cheat Sheet”https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html17. NIST “Cybersecurity Framework (CSF) 2.0”https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
インフラ編#07丨SPOFとは何か——重要インフラを止める単一障害点と人間依存の罠
SPOF、つまり単一障害点とは、壊れやすい機械部品だけを指す言葉ではありません。本エピソードでは、重要インフラに潜むSPOFを、設備・人・権限・認証・通信・ベンダー対応・組織設計の観点から解説します。取り上げる主なテーマ- SPOFとは何か- 単一障害点- 重要インフラの停止リスク- 物理的故障だけではないFailure- 侵害されたまま稼働するフェイルアンセーフ- 人間系SPOF- エース担当者依存- ソフトSPOF- 待ち行列理論と過負荷- 見せかけの冗長化- 共通原因障害- ヒースロー空港の電力障害- 英国鉄道の復旧遅延- 水処理施設の仮想シナリオ- 権限・技能・情報・認証・通信・独立性- 職務代行と自動権限移行- 代行者単独完遂率- 権限委譲時間- AI時代の不可視のSPOFSPOFは、単に「1台しかないサーバー」や「1本しかない回線」の問題ではありません。車が壊れることより、車の鍵が1つしかないこと。予備設備があることより、切り替え方法を知っている人が1人しかいないこと。担当者がいることより、その人しか判断できず、その人しか認証トークンを持っていないこと。こうした依存関係の集中こそが、重要インフラを止める本当の単一障害点になります。さらに厄介なのは、人が倒れなくても組織が止まることです。緊急時に問い合わせが集中し、判断が1人に詰まり、待ち時間が許容時間を超えた瞬間、担当者が生きていても、元気に働いていても、組織は機能停止します。冗長化も、単に数を増やせばよいわけではありません。Teamsとメールがあっても、同じ認証基盤に依存していれば同時に死にます。データセンターが2つあっても、同じ変電所に依存していれば同時に落ちます。正担当と副担当がいても、同じ権限・同じ鍵・同じ通信経路に依存していれば、代替にはなりません。本当に必要なのは、同じ原因で同時に失われない設計です。代行者には、名前だけでなく、権限、技能、情報、認証、通信、時間的・地理的独立性が必要です。そのうち1つでも欠ければ、代替態勢は機能しません。強い組織とは、エースが倒れない組織ではありません。エースが倒れても、権限・情報・認証・技能の連鎖が切れず、別の人が迷わず安全に引き継げる組織です。重要インフラを止めるのは、壊れた機械だけではありません。誰が判断するのか。誰が止めるのか。誰が鍵を持っているのか。誰がベンダーに連絡できるのか。主担当が応答しないとき、何分で権限が移るのか。SPOFを、機械ではなく組織設計の問題として考えます。
こちらもおすすめ
IBUKI STATION
ここはアウトドア向けGPSトラッキング「IBUKI」にまつわる人々が集まる場所。 トレイルラン、登山、冒険、ランニング、自転車、ロゲイニング、、 スタイルは数あれど、共通しているのは自然を楽しみ、そして人とのつながりも楽しむ姿勢。 自然を目一杯楽しみ、苦しみながら、人と接する喜びにも気付く。 アウトドアを満喫するみなさんが、ほっとできるIBUKI STATIONです。 IBUKI https://ibuki.run/ 近藤淳也 IBUKIを提供する株式会社OND代表。ポッドキャストプラットフォーム「LISTEN」も展開 桑原佑輔 OND所属。IBUKI事業担当営業・テクニカルディレクター 中川和美 OND所属。IBUKI担当。トレイルランナー
歴史を面白く学ぶコテンラジオ （COTEN RADIO）
歴史を愛し、歴史を知りすぎてしまった歴史GEEK2人と圧倒的歴史弱者がお届けする歴史インターネットラジオです。 歴史というレンズを通して「人間とは何か」「私たち現代人の抱える悩み」「世の中の流れ」を痛快に読み解いていく！？ 笑いあり、涙ありの新感覚・歴史キュレーションプログラム！ ☆Apple & Spotify Podcast 部門別ランキング１位獲得！ ☆ジャパンポッドキャストアワード2019 大賞&Spotify賞 ダブル受賞！ ※正式名称は「古典ラジオ」ではなく「コテンラジオ」です ーーー COTEN RADIO is an entertainment radio talk program for history , published by the crazy history geeks group "COTEN" in Japan. ☆Apple & Spotify Podcast in Japan category ranking No.1 ! ☆Japan Podcast Awards 2019 Grand prize and Spotify prize !
桃山商事
コミュニケーション、男性性、恋愛、人間関係、ジェンダー、ケア、孤独、性欲、会社、友情、老い……メンバーがその時々で気になったテーマを１つ設定して、モヤモヤを言語化していくNEOな座談Podcastです。2011〜2016年「二軍ラジオ」(ApplePodcast)、2017〜2024年「恋愛よももやまばなし」(ニコ生→Podcast)を配信していました。清田隆之(文筆業)、森田(会社員)、ワッコ(会社員)、さとう(会社員)の４人でお届けします。
jkondoの朝の散歩
ポッドキャストプラットフォーム「LISTEN」や、GPSトラッキングサービス「IBUKI」、物件メディア「物件ファン」、京都の宿とコワーキング施設「UNKNOWN KYOTO」を運営する近藤淳也（jkondo）が、朝の散歩をしたりしながら、日々の出来事や考えたことを語ります。
近藤淳也のアンノウンラジオ
株式会社はてな創業者であり現在もITの第一線で働く近藤淳也が、京都の宿UNKNOWN KYOTOにやって来る「好きなことを仕事にしている人」を深堀りすることで、世の中の多様な仕事やキャリア、生き方・働き方を「リアルな実例」として紐解いていきます。 . 【ホスト：近藤淳也】 株式会社OND代表取締役社長、株式会社はてな取締役、UNKNOWN KYOTO支配人、NPO法人滋賀一周トレイル代表理事、トレイルランナー。 2001年に「はてなブログ」「はてなブックマーク」などを運営する株式会社はてなを創業、2011年にマザーズにて上場。その後2017年に株式会社ONDを設立し、現在もITの第一線で働く。 株式会社OND: https://ond-inc.com/ . 【UNKNOWN KYOTO】 築100年を超える元遊郭建築を改装し、仕事もできて暮らせる宿に。コワーキングやオフィスを併設することで、宿泊として来られる方と京都を拠点に働く方が交わる場所になっています。 1泊の観光目的の利用だけではなく、中長期滞在される方にも好評いただいています。 web: https://unknown.kyoto/ . こちらから本文を読んだりコメントが書けます！ https://listen.style/p/unknownradio
LISTEN NEWS
LISTENは、AI文字起こしとコミュニティで、ポッドキャストを「聴く・配信する・つながる」ためのプラットフォームです。 公式番組「LISTEN NEWS」では、開発の裏話や近況も交えつつ、最新情報をお届けします。 LISTENはこちら→ https://listen.style/