Skip to content
Artwork for サイバーセキュリティ新聞

サイバーセキュリティ新聞

OHA Shinbun

サイバーセキュリティ新聞

サイバーセキュリティ、AI、情報戦、国家安全保障、インフラ防衛、認知戦、OSINT、ランサムウェア、サプライチェーンリスクを、政策・経営・技術の交差点から整理・解説する音声メディアです。

本番組では、国内外の一次資料、公的機関レポート、政府発表、技術文書、研究論文、OSINT(公開情報分析)などをもとに、
ランサムウェア
ゼロトラスト
AIとサイバー防衛
ダークウェブ
国家支援型攻撃(APT)
インフラ・OTセキュリティ
サプライチェーン攻撃
偽情報・認知戦
半導体・通信・クラウド
ドローンと電子戦
サイバー政策・制度設計
SOC / CSIRT / フォレンジック
経済安全保障
地政学とテクノロジー
などを、非技術者にも分かるよう構造化して解説します。

「技術そのもの」だけではなく、
なぜ事故が起きるのか
なぜ組織は止まるのか
なぜ投資されないのか
なぜサプライチェーンが弱点になるのか
AIが社会・行政・安全保障をどう変えるのか
といった、「経営・政策・組織・社会構造」まで含めて扱います。

対象リスナーは、
省庁・自治体関係者
インフラ事業者
経営層
リスク管理部門
セキュリティ担当者
報道・政策関係者
AI・IT業界
サイバー安全保障に関心のある一般リスナー
です。

本番組は、防御・教育・制度理解・リスク管理・社会啓発を目的としています。

Play
  • 26 episodes
  • Avg 22 min
  • Japanese
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • S3 · E9
    Yesterday · 23 min

    インフラ編#09丨軍事衛星はゼロトラストで守れるのか——PWSA・宇宙光通信・地上システムの盲点

    宇宙の軍事衛星を守るうえで、最大の弱点は本当に宇宙空間にあるのでしょうか。 本エピソードでは、米国宇宙開発局(SDA)が推進する衛星コンステレーション「PWSA」を取り上げ、宇宙光通信、ソフトウェア定義衛星、米国防総省(DoD)のゼロトラスト戦略、地上システムへのサイバー攻撃、そして軍事任務の継続性について解説します。 取り上げる主なテーマ - 衛星コンステレーションとは何か - SDAとPWSA(Proliferated Warfighter Space Architecture) - ロッキード・マーチンと軍事衛星開発 - ソフトウェア定義衛星(SDS) - 衛星間光通信とレーザー通信 - 近赤外線・光C帯と通信規格 - 光通信の傍受耐性と限界 - NEBULAネットワークと暗号化 - 光地上局の天候リスク - 電波通信へのフォールバック - 通信容量とレイテンシの違い - DoDゼロトラスト戦略と2027年度目標 - NIST SP 800-207 - 認証・認可・最小権限 - 宇宙空間での通信断絶とゼロトラスト - 分散認証と鍵失効の問題 - SpiderOakのOrbitSecure - ソフトウェア更新とサプライチェーン攻撃 - 共通基盤への依存と単一障害点(SPOF) - GAOによるPWSAの開発・試験体制への指摘 - デジタルツインと地上試験 - 2022年のViasat KA-SATサイバー攻撃 - VPN設定不備と管理ネットワーク侵害 - AcidRainワイパーマルウェア - GPSスプーフィングとセンサーデータの真正性 - 衛星の自動隔離と任務継続のジレンマ - ミッション・アシュアランス(任務保証) 米国では現在、多数の低軌道衛星をネットワークで結び、ミサイルの探知・追尾や軍事通信を支える新しい宇宙インフラの構築が進められています。 その中核となる技術の1つが、衛星同士をレーザーで接続する宇宙光通信です。 光通信は、従来の電波通信よりもビームの指向性が高く、通信を傍受できる場所を限定しやすいという利点があります。 しかし、光通信だから絶対に盗聴されないわけではありません。 通信が暗号化されていても、正規の管理者アカウントが乗っ取られたり、地上の運用システムが侵害されたりすれば、別の経路から衛星システムが危険にさらされる可能性があります。 そこで重要になるのが、ゼロトラストです。 ゼロトラストとは、ネットワークの内側にいることや、正規の認証情報を持っていることだけを理由に、すべての操作を無条件に許可しない考え方です。 誰が、どの衛星に、どの権限で、どの操作を要求しているのか。 それを継続的に検証し、必要最小限のアクセスだけを認めることで、侵害が発生しても被害の拡大を抑えることを目指します。 しかし、宇宙空間では地上と異なる難題が生じます。 衛星は高速で移動し、通信経路が頻繁に変わります。 地上との接続が途絶えた場合にも、限られた時間の中で重要な判断と制御を継続しなければなりません。 すべての操作に地上とのリアルタイムな確認を要求すれば、通信が途絶えたときに必要な任務まで停止する可能性があります。 一方で、通信断絶中の操作を無条件に許可すれば、攻撃者に悪用される危険があります。 さらに、衛星を大量に配備することと、システム全体の耐障害性を確保することは同じではありません。 数百機の衛星が物理的に分散していても、共通のソフトウェア、更新基盤、署名鍵、地上管制システムに依存していれば、その共有部分が単一障害点になる可能性があります。 2026年の米国政府監査院(GAO)の評価でも、PWSAの開発・試験体制には継続的に検証すべき課題が指摘されています。 ソフトウェアを更新できる衛星では、新しい機能を追加するたびに、安全性への影響を評価することが重要です。 ここで教訓となるのが、2022年2月24日に発生したViasatのKA-SATネットワークへのサイバー攻撃です。 攻撃者は宇宙空間の衛星を直接乗っ取ったのではありません。 地上のVPN機器の設定不備を悪用して管理ネットワークへ侵入し、正規の管理機能を利用して多数の利用者向けモデムを機能停止に追い込みました。 被害はウクライナから欧州各地へ波及しました。 この事件は、宇宙インフラの安全性が、地上の認証、管理権限、ネットワーク構成、ソフトウェア運用にも大きく依存していることを示しています。 さらに、通信の暗号化や認証が正常に機能していても、センサーが取得した情報そのものが正しいとは限りません。 GPS信号の偽装やセンサーへの妨害によって誤った観測値が生成されれば、その情報が正規の通信経路を通じて送られ、誤った判断につながる危険があります。 つまり、通信経路の安全性と、データの真正性は別の問題なのです。 軍事衛星に求められるのは、単に侵入されないことではありません。 攻撃を受けたときに、どこまで被害を封じ込められるのか。 地上との通信が途絶えても、安全に必要な機能を継続できるのか。 異常を検知したとき、自動隔離によって重要な任務そのものを停止させてしまわないか。 侵害された機能を、どのような手順で安全に復旧できるのか。 これらを含む、システム全体の任務保証が問われます。 宇宙光通信も、ゼロトラストも、ソフトウェア定義衛星も、それぞれ重要な技術です。 しかし、その導入だけで衛星ネットワークの安全が保証されるわけではありません。 究極のセキュリティとは、すべてを遮断することなのか。 それとも、一部の機能を失っても、必要な任務を安全に継続できることなのか。 次世代の軍事衛星と宇宙インフラを題材に、ゼロトラストの限界と、サイバー攻撃を受けても任務を遂行するための設計思想を考えます。

  • S1 · E25
    Yesterday · 23 min

    入門編#25丨量子技術とは何か——量子アニーリング・QKD・PQCとサイバーセキュリティの現実

    量子コンピューターは、企業の業務を最適化し、通信を安全にする万能の技術なのでしょうか。 本エピソードでは、2026年11月15日時点の量子技術とサイバーセキュリティの動向を取り上げ、量子アニーリングによる業務最適化、量子鍵配送(QKD)、耐量子計算機暗号(PQC)の仕組みと限界について解説します。 取り上げる主なテーマ - 量子コンピューターとは何か - 量子アニーリングとゲート型量子計算 - D-Waveの量子コンピューティング技術 - 古典コンピューターとのハイブリッド最適化 - NTTドコモの商用ネットワーク最適化事例 - 位置登録信号65.3%削減とページング信号7.0%削減 - 最適解と事業継続性の違い - 冗長性・予備能力・制約条件の設計 - 量子技術導入の投資対効果 - HNDL(今盗んで、後で解読する攻撃) - 量子鍵配送(QKD)とは何か - 盗聴検知の原理と秘匿性増強 - 量子通信の認証問題 - QKD装置の実装上の脆弱性 - 中継拠点と信頼の問題 - サービス妨害(DoS)と可用性 - 耐量子計算機暗号(PQC)とは何か - RSA暗号と量子コンピューター - NIST FIPS 203・204・205 - ML-KEM・ML-DSA・SLH-DSA - NSAと英国NCSCの見解 - KDDIによる57.6Tbpsの大容量伝送実証 - TOPPAN・NICT・ISARAによるPQC移行実証 - 暗号アジリティと将来の暗号移行 - 通信メタデータとAIによる行動推定 量子技術は、すでに一部の実ビジネスで利用されています。 例えばNTTドコモは、量子アニーリングを活用したネットワーク最適化によって、特定エリアで位置登録信号のピーク値を65.3%、ページング信号のピーク値を7.0%削減したと発表しました。 しかし、量子アニーリングは、あらゆる問題について必ず厳密な最適解を出せる万能の計算機ではありません。 さらに、計算結果が数学的に優れていても、現実の事業運営にとって望ましいとは限りません。 物流のコストを最小化する。 待機時間を削減する。 設備の稼働効率を高める。 その一方で、予備のトラックや保守時間、復旧のための余力まで削減してしまえば、小さな障害が重大な事業停止につながる可能性があります。 これは量子技術特有の欠陥ではなく、最適化の目的と制約をどう定義するかという経営上の問題です。 そして、量子技術はサイバーセキュリティにも新しい課題を突きつけています。 将来、高性能な量子コンピューターが実現すれば、現在利用されている一部の公開鍵暗号が危険にさらされる可能性があります。 そのため、攻撃者が現在の暗号化通信を保存し、将来の解読技術を待つHNDLという脅威が懸念されています。 そこで注目されているのが、量子鍵配送(QKD)です。 QKDは、光子などの量子状態を利用して暗号鍵の素材を共有する技術です。 しかし、「量子だから絶対に盗聴されない」という説明は正確ではありません。 実際のシステムには、自然雑音、装置の実装上の弱点、通信相手の認証、鍵の保管、中継拠点への信頼といった問題が残ります。 2010年には、商用QKD装置の光検出器の弱点を利用し、盗聴を検知させずに秘密鍵を取得する攻撃が実験的に示されました。 さらに、通信への妨害によって鍵の生成が停止する可能性もあります。 機密性を守るために、事業継続性を失っては意味がありません。 一方、耐量子計算機暗号(PQC)は、専用の量子通信設備ではなく、量子コンピューターに対しても解読が困難と考えられる数学的問題を利用します。 NISTは2024年、ML-KEM、ML-DSA、SLH-DSAを含む最初の3つのPQC標準を正式に公開しました。 PQCは、既存の通信網やコンピューターを活用して移行を進められるため、幅広い企業にとって重要な選択肢です。 ただし、QKDとPQCは完全な二者択一ではありません。 KDDIの商用ネットワークを利用した大容量伝送実証や、TOPPAN・NICT・ISARAによる認証基盤の移行実証は、技術を組み合わせる可能性を示しています。 企業に必要なのは、「量子対応済み」という製品の宣伝文句を信じることではありません。 どの通信区間を保護するのか。 通信相手をどう認証するのか。 端末が侵害された場合はどうなるのか。 鍵の生成や通信が停止した場合、業務をどう継続するのか。 既存の暗号方式をどこで使用しているのか。 将来、暗号方式を安全に交換できるのか。 これらを確認することです。 量子コンピューターが強力になっても、経営判断やサイバーセキュリティの責任が消えるわけではありません。 最も重要なのは、技術の性能だけでなく、その技術を組み込んだシステム全体の安全性と持続可能性です。 量子技術は何を解決し、何を解決できないのか。 量子アニーリング、QKD、PQCを通じて、企業がこれから備えるべきサイバー防衛と技術投資のあり方を考えます。

  • S2 · E14
    November 1 · 22 min

    実録編#14丨HTTP2Shellとは何か——Brotliの重大脆弱性・Node.js・ソフトウェア更新の盲点

    外部から直接侵入できない社内システムでも、危険なデータを自ら取得した瞬間、攻撃を受ける可能性があります。 本エピソードでは、2026年10月に公表された重大な脆弱性「HTTP2Shell(Node2Shell/CVE-2026-111497)」を取り上げ、Brotliの圧縮データ展開処理に潜む欠陥、Node.jsなどへの影響、リモートコード実行の危険性、そして企業が直面するパッチ適用と運用管理の難しさについて解説します。 取り上げる主なテーマ - HTTP2Shell・Node2Shellとは何か - CVE-2026-111497 - Google Brotliとデータ圧縮 - HTTP/2とHTTPSの違い - 境界外書き込み(CWE-787) - バッファオーバーフロー - リモートコード実行(RCE) - メモリ破損と情報漏洩 - Node.jsの脆弱性とセキュリティ更新 - Impervaによる攻撃実証 - CISAの悪用確認済み脆弱性(KEV) - 外部からのリクエストと内部からのデータ取得 - URLプレビュー・API通信を通じた攻撃経路 - HTTPSによる暗号化の限界 - AWS Lambdaとクラウドの責任共有モデル - Dockerコンテナと再ビルド - ソフトウェアの多層的な依存関係 - SBOM(ソフトウェア部品表) - VEX(脆弱性影響説明) - CVSSと実際の事業リスク - WAFによる防御の限界 - パッチ適用と本番環境での修正確認 - オープンソースの公共インフラとしての役割 今回の問題は、HTTP/2という通信規格そのものの欠陥ではありません。 データを小さく圧縮するBrotliという技術の、圧縮データを元に戻す処理に存在する欠陥です。 攻撃者が細工した圧縮データをシステムに処理させることで、メモリの破損、情報漏洩、異常終了、さらには不正なプログラムの実行につながる可能性があります。 しかも危険なのは、外部から直接サーバーへ攻撃される場合だけではありません。 社内のチャットツールがURLのプレビューを取得する。 業務システムが外部APIからデータを受け取る。 自動処理プログラムがWebサイトへアクセスする。 こうした日常的な処理の中でも、攻撃者が用意した圧縮データを読み込めば、脆弱性に到達する可能性があります。 ファイアウォールで外部からの侵入を防いでいても、内部システムが自ら危険なデータを取得する経路は残り得るのです。 さらに、HTTPSで通信を暗号化していても、その通信で受け取ったデータ自体が安全とは限りません。 今回の事件が浮き彫りにしたのは、もう1つの深刻な問題です。 脆弱性を修正するプログラムが公開されても、それだけでは企業のシステムは安全にならないという現実です。 現代のソフトウェアは、無数の部品が複雑に組み合わされて構築されています。 開発者が直接Brotliを使っていなくても、Node.jsや各種フレームワーク、通信ライブラリ、コンテナの内部に組み込まれている場合があります。 そのため、最初に必要なのは、自社のどこに問題の部品が存在するのかを把握することです。 SBOMで構成部品を可視化し、VEXなどの情報も参考に実際の影響を判断する。 次に、攻撃者が制御するデータが脆弱な処理へ到達するかを確認する。 そして影響を受ける環境について、修正版への更新、アプリケーションの再ビルド、コンテナの再配置、本番環境での適用確認を行う必要があります。 WAFによる遮断は、補助的な防御にはなります。 しかし、内部システムが外部から取得する応答データなど、WAFの監視対象にならない経路もあります。 根本的な修正の代わりにはなりません。 また、脆弱性の深刻度を示すCVSSの点数だけで、企業の優先順位を決めることもできません。 そのシステムはどのデータにアクセスできるのか。 どの業務を動かしているのか。 攻撃された場合、どのような事業損失が発生するのか。 誰が更新し、誰が稼働確認まで責任を持つのか。 これらを含めた判断が求められます。 そして最後に、より大きな問いがあります。 世界中の企業、クラウドサービス、業務システムが、少数の共通したオープンソース部品に依存しています。 その部品に重大な欠陥が発見されたとき、社会全体が膨大な修正コストを負担します。 私たちは、こうしたソフトウェアを道路や橋と同じように、社会を支える共通インフラとして考える必要があるのではないでしょうか。 守るべきものは、単にプログラムの正常動作ではありません。 脆弱性を把握し、影響を判断し、修正を届け、本番環境で確認するという、組織の防御能力そのものです。 HTTP2Shellから、現代のソフトウェア依存とサイバーセキュリティの構造的課題を考えます。

  • S2 · E13
    October 22 · 24 min

    実録編#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の秘密鍵問題。 一方はサーバーの安全性、もう一方は通信相手の真正性を脅かす問題でした。 サイバーセキュリティは、侵入を防ぐことだけではありません。 私たちが何を根拠に、誰を信頼しているのか。 その信頼を、誰が検証し、誰が取り消せるのか。 インターネットの信頼基盤と、監査・認証・ガバナンスの本質を考えます。

  • S3 · E8
    October 10 · 26 min

    インフラ編#08丨クラウド障害はなぜ社会を止めるのか——共通基盤・委託先・BCPのサイバー防衛

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

  • S4 · E16
    September 30 · 22 min

    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エージェント時代のガバナンスを考えます。

  • S4 · E15
    September 23 · 25 min

    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/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

  • S3 · E7
    August 21 · 22 min

    インフラ編#07丨SPOFとは何か——重要インフラを止める単一障害点と人間依存の罠

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

  • S2 · E12
    August 16 · 17 min

    実録編#12丨暗号戦争とは何だったのか——サイファーパンク、国家監視、バックドア、量子時代のプライバシー

    暗号は、ただの技術なのでしょうか。 本エピソードでは、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のような強力な暗号が、スマートフォン、銀行取引、メッセージアプリ、クラウド通信に当たり前のように使われています。 しかし、暗号戦争は終わっていません。 暗号そのものが強くなったことで、攻撃者は暗号を正面から破るのではなく、端末、クラウド、認証、バックアップ、人間、そしてメタデータを狙うようになりました。 メッセージの中身が読めなくても、誰が、誰に、いつ、どれくらいの頻度で連絡しているかが分かれば、人間関係や行動パターンは推測できます。 さらに、量子コンピューターの登場によって、現在の暗号方式の前提も揺らぎ始めています。 暗号は善人だけを守り、悪人だけを解除することはできません。 だからこそ、プライバシー、捜査、国家安全保障、サイバー防衛のあいだで、社会は今も難しい選択を迫られています。 「善人だけが使えて、悪人が使ったときだけ政府が解除できる暗号」は存在するのか。 暗号戦争の歴史から、デジタル社会の自由と安全を考えます。

  • S1 · E24
    August 15 · 21 min

    入門編#24丨脅威モデリングとは何か——攻撃者の行動から逆算するセキュア・バイ・デザイン

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

  • S4 · E14
    July 26 · 21 min

    AI編#14丨同意だけでは守れない——個人情報保護法改正・医療データ・AI覇権の行方

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

  • S4 · E13
    July 13 · 25 min

    AI編#13丨そのプロンプトは、外部送信ではないのか——生成AI時代の患者データ・機微情報・SaaSガバナンス

    生成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ガバナンスを考えます。

  • S2 · E11
    July 7 · 22 min

    実録編#11丨生成AIで4万件を退会させた中学生——バンダイチャンネル事件とサイバー教育の盲点

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

  • S4 · E12
    July 1 · 24 min

    AI編#12丨ペンタゴン・ピザ指数とは何か――AI時代のOSINTと予測の罠

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

  • S4 · E11
    June 25 · 22 min

    AI編#11丨そのAIミスに保険は下りるのか——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時代のリスク、責任、保険、そして企業統治を考えます。

  • S2 · E10
    June 20 · 22 min

    実録編#10丨民主主義はどこから攻撃されるのか——選挙、偽情報、ハック・アンド・リーク時代のサイバー防衛

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

  • S4 · E10
    June 18 · 21 min

    AI編#10丨サイバー防御ガイドラインは公開すべきか——フロンティアAI時代の「見せる情報」と「守る情報」

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

  • S1 · E20
    June 17 · 15 min

    入門編#20|Active Directoryとは何か——会社のIDと権限を支配する中枢システム

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

  • S1 · E19
    June 17 · 20 min

    入門編#19|SIEMとは何か|大量のログからサイバー攻撃の兆候を見つける仕組み

    SIEMとは、単なるログ保管庫ではありません。 企業のサーバー、端末、クラウド、認証基盤、VPN、EDR、ファイアウォールなどから大量のログを集め、サイバー攻撃や不審な動きの兆候を見つけるための仕組みです。 本エピソードでは、SIEMとは何か、なぜ多くの企業が導入しても運用でつまずくのか、そしてログを「集めること」と「意味を読み取ること」の違いを解説します。 取り上げる主なテーマ - SIEMとは何か - ログ管理と証跡管理 - SOCとの違い - アラート疲れ - 正規化 - 相関分析 - Entra ID・OktaなどIDログの重要性 - VPN、クラウド、端末ログの統合 - Target事案 - Marriott / Starwood事案 - M&A時の監視ギャップ - 全ログ主義の落とし穴 - ホットデータとコールドデータ - Microsoft Sentinel - Splunk - Google SecOps - Elastic - MDR・管理型SOC - SOAR・XDRとの関係 - AIによるSecOps支援 - セキュリティと従業員監視の境界線 SIEMは、事故が起きたときに「何が起きたのか」「どこから侵入されたのか」「被害はどこまで広がったのか」を説明するための、組織の記憶です。 しかし、ログを集めるだけでは会社は守れません。 アラートが鳴っても誰も見ていなければ、侵入は止まりません。 ログが集まっていても、相関分析できなければ攻撃の流れは見えません。 すべてのログを無差別に入れれば、コストとノイズでSOCは疲弊します。 重要なのは、どのログを優先して見るのか。 どのアラートに誰が責任を持つのか。 どこまで自動化し、どこから人間が判断するのか。 SIEMは、放置しておけば守ってくれる魔法の箱ではありません。 ログという「点」をつなぎ、攻撃の「線」を見つけ、有事に事実を説明するための経営インフラです。 サイバー攻撃を受けたとき、推測ではなく証拠に基づいて動ける組織になるために、SIEMの基本を整理します。 経営層、情報システム部門、セキュリティ担当者、SOC・CSIRT体制を検討している企業に向けた、SIEM入門です。

  • S1 · E18
    June 17 · 18 min

    入門編#18丨SOCとは何か——サイバー攻撃を見張る組織の管制塔

    SOCとは、サイバー攻撃を見張るための「監視ルーム」ではありません。 異常に気づき、判断し、必要な部署を動かし、被害が広がる前に止めるための、組織の管制塔です。 本エピソードでは、SOC(Security Operations Center)とは何か、なぜ現代の企業に必要なのかを、経営者・管理職にもわかる形で解説します。 取り上げる主なテーマ - SOCとは何か - 外部通報で発覚するサイバー侵害 - 内部検知の重要性 - 攻撃者の滞留時間 - 日本年金機構事案 - ログ監視 - SIEM・EDR・XDR・SOARとの関係 - MITRE ATT&CK - AIによるSOC支援と限界 - 内製SOCと外部委託SOC - MDR・マネージドSOC - ハイブリッド型SOC - SOCに必要な人材と24時間365日体制 - 検知後に動けない組織のリスク - コロニアル・パイプライン事案 - Norsk Hydro事案 - 東京2020大会のサイバー防衛 - MTTD・MTTR - 内部検知比率 - ログ改ざんと監視の信頼性 サイバー攻撃は、もはや「侵入されるかどうか」だけの問題ではありません。 重要なのは、侵入されたときに自社で気づけるか。 外部から指摘される前に異常を見つけられるか。 被害が広がる前に止められるか。 多くの組織では、攻撃者がネットワーク内に潜伏していても、自社では気づけず、外部機関や取引先からの通報で初めて発覚します。 SOCの価値は、攻撃を完全に防ぐことではありません。 ログ、ID、端末、クラウド、メール、ネットワークの情報を集め、異常を検知し、優先順位をつけ、必要な初動対応につなげることです。 ただし、SOCは高価なツールを導入すれば完成するものではありません。 ログが取れていなければ見えません。 アラートを判断する人がいなければ動けません。 端末を隔離する権限がなければ止められません。 夜間休日に意思決定できるルートがなければ、攻撃者の速度に追いつけません。 SOCとは、サイバー攻撃を完全に防ぐ魔法ではなく、異常を見つけ、判断し、組織を動かすための危機管理機能です。 サイバー攻撃を事業継続リスクとして捉えたい経営者、情報システム部門、リスク管理担当者、広報・法務・監査に関わる方に向けた、SOC入門です。

Showing 1–20 of 26 episodes