サイオステクノロジー((DXSL)) の技術ブログ

全97件

2026/09/10

2026年10月1日、基幹インフラに攻撃の報告義務。ログを聞かれるのは誰か、そしてその準備

2026年10月1日、サイバー対処能力強化法（いわゆる能動的サイバー防御法）の主要部分が施行されます。届出と報告の義務がかかるのは、国に指定された基幹インフラ事業者（2026年7月1日時点で15分野258者）のうち、一定の重要システムを使う事業者だけです。ただ、この記事を読んでいただきたいのは、その事業者だけではありません。たとえば、こういう立場の方です。基幹インフラ事業者に、システムやサービスを納めている自社は指定されていないが、同じ業種で、規模だけが基準に届いていない今回は対象外だが、次の改正で対象になりそうだ（医療分野は、すでに追加が決まりました）グループ会社に、指定された事業者がある少しでも心当たりがあれば、ここから先はぜひ「自社の課題」としてお読みください。届出や報告の義務は課されません。しかし、説明を求められる側にはなる可能性があります。ここで扱うのは、難しい条文の解説ではありません。実務において最も重要となる一点に絞ってお伝えします。それは、「いざ報告を求められたときに、提出できるログが手元に残っているかどうか」ということです。目次 10月1日に何が変わるのか対象外の会社にも、話は届きますいま、日本で実際に起きていることなぜ、攻撃側だけが有利なのか「見えていない」理由は、能力ではなく構造ですでは、どう変えられるか 1. コスト:「絞る」必要をなくす 2. 見えない範囲:「全部残して、全部検索する」 3. 速度:「アラート」ではなく「調査結果」を受け取る日本では、ここが最初の条件になります「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ RFI・RFPに書くべき5項目いまお使いのSIEMを、止める必要はありませんまとめ出典 10月1日に何が変わるのか変わるのは「守り方」ではなく「説明責任」です。対象事業者にかかる主な義務は2つ。重要な機器の届出と、サイバー攻撃を受けたときの報告です。報告で注目したいのは、対象が被害発生時だけではないことです。その原因となり得る事象を知ったときも、報告の対象になります。異常な認証、見慣れない通信、消えたログ。気づける状態になっていなければ、報告のしようがありません。そして報告では、「どのシステムが影響を受けたのか」「どんな攻撃だったのか」「業務にどう影響したのか」を説明します。これを説明する土台が、ログです。侵入経路も、活動が始まった時期も、横移動の有無も、後から確かめるにはログが要ります。残っていなければ、「わかりません」と書くことになります。対象外の会社にも、話は届きますこれは推測ではありません。政府の基本方針にそう書かれています。本法に基づく措置は、特別社会基盤事業者はもとより、電子計算機の使用者に対する周知など中小企業も含めて広く様々な事業者が対象となり得るため、必要な周知・広報を行う。（内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月）届け方は、大きく2つです。 1. 供給する側は、すでに制度の中にいますサイバーセキュリティ基本法第7条第2項は、情報システムの供給者に対して、利用者の安全性に配慮した設計・開発と、維持管理に必要な情報の継続的な提供を求めています（努力義務）。経済産業省と内閣官房国家サイバー統括室は2026年3月31日に、こうした事業者を「サイバーインフラ事業者」と位置づけたガイドラインも策定しました。さらに、経済安全保障推進法の枠組みでは、基幹インフラ事業者が重要設備を導入・委託する際の「導入等計画書」に、供給者だけでなく委託の相手方や再委託の相手方についても同等の事項を記載します。会社名だけでなく、代表者や役員の情報まで含まれます。二次請けで入っているだけでも、すでに書類の中にいる可能性があるということです。 2. 報告のとき、ログを聞かれます侵入経路が自社の提供したシステムだった場合、そこで何が起きたかを確認できるのは、ベンダー側だけということがあります。「この時間帯の認証ログを見せてください」「この通信は正常ですか」、そうした確認を求められる可能性があります。そのときログが残っていなければ、「わかりません」と答えることになります。 ※ 制度の細部（対象事業者の範囲、届出内容、期限など）は、内閣官房・NISCおよび内閣府の公表資料で最新の内容をご確認ください。いま、日本で実際に起きていること現場の数字を見ておきます。すべて警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月公表）からの引用です。ランサムウェア被害報告は226件。高止まりが続いています。被害企業の約6割は中小企業です。「うちは狙われるほど大きくない」は成り立ちません。業種別では製造業が約4割。感染経路について回答が得られた組織では、VPN機器からの侵入が6割を超えました。メールの添付ファイルではありません。インターネットに露出した機器の未修正の脆弱性や、漏えいした認証情報から入られています。復旧に総額1,000万円以上かかった組織が5割を超えています。 1か月未満で復旧できたのは5割強。約半数が1か月以上、影響を受け続けています。なぜ、攻撃側だけが有利なのか警察庁の報告書は、RaaS（Ransomware as a Service）を被害拡大の背景として明記しています。 RaaSは、一言でいうと**攻撃の「フランチャイズ」**です。開発・運営グループが実行役に道具一式を渡し、身代金の一部を受け取ります。高度な技術的専門知識を有していない者であっても、ランサムウェア攻撃の実行が可能になるなど、攻撃者の裾野の広がりが見られている（警察庁）狙っているのは、天才ハッカーとは限りません。道具を借りてきた加盟店かもしれない、ということです。ここに非対称があります。攻撃側は道具代を一度払えば、何度でも試せます。一件成功すれば元が取れます。守る側は毎年払い続けても、「終わり」が来ません。速度も違います。CrowdStrikeの2026年版Global Threat Reportによると、金銭目的の攻撃の平均ブレイクアウトタイムは29分（侵入から横移動を始めるまでの時間）。最短27秒という記録も報告されています。侵入されてから隣のシステムへ移られるまで、30分ありません。この時計の差が、そのまま被害の大きさになります。「見えていない」理由は、能力ではなく構造ですログが見えていないと聞くと、担当者のスキル不足を思い浮かべるかもしれません。でも実務では、原因はたいていそこではありません。単年度予算がライセンス数を決める — 入れられなかった端末が、そのまま入口になる取り込み量への課金 — 予算に収めるには、取り込むログを減らすしかない保持期間が短い — ログが消えたあとに侵入が発覚すれば、見たい期間はもう手元にない製品がつぎはぎ — 攻撃者は壁を破らず、製品と製品の継ぎ目を通る「ログを取っていないのではありません。取れない値付けになっているだけです。」取り込んでいないログは、検知もできないし、報告もできません。では、どう変えられるか 1. コスト:「絞る」必要をなくす Elastic Cloud Hosted とセルフマネージドの構成では、使うリソース（ノードのメモリ量と稼働時間など）に対して課金されます。取り込んだデータ量そのものには課金されません。「取り込む量を増やすと、その分ライセンス費が上がる」という関係になりません。予算を理由にログソースを外す判断を、しにくくなります。 ※ Elastic Cloud Serverless の Security は取り込み量ベースの課金です（Essentials $0.09/GB〜、Complete $0.11/GB〜）。リソース課金なのは Hosted とセルフマネージドの構成です。 2. 見えない範囲:「全部残して、全部検索する」 Elasticの中核は検索エンジンです。古いデータを安いストレージ階層に置いたまま、復元作業なしでそのまま検索できます。「バックアップから戻すのに3日」がなくなります。調査は必ず過去にさかのぼります。10月1日以降は、説明のためにもさかのぼります。規模の目安として、米国カリフォルニア州雇用開発局（EDD）の事例があります。約14,000エンドポイント、月80,000件超のアラート、守っているレコードは 8,500億件です。 3. 速度:「アラート」ではなく「調査結果」を受け取る Attack Discovery は、バラバラのアラートを1つの攻撃のストーリーにまとめる機能です。従来アナリストが手作業でつなげていた部分を、AIが先にやります。「AIの判断を信じていいのか」という疑問は正しいです。Attack Discoveryでは、まとめの元になった関連アラートや元データをたどれます。アナリストが確認してから判断します。大事なのは、AIが答えを出すことではありません。調査を始める場所を、早く見つけられることです。日本では、ここが最初の条件になります日本で必ず出る質問があります。「そのデータはどこに置かれますか」です。 Elasticは、クラウドだけでなく、セルフマネージドやオンプレミス、閉域環境でも動きます。AIの部分も選べます。Elastic Managed LLM のほか、外部のLLMや、自社で管理するLLMを接続できます。AIを使うために、必ずデータを外部のLLMサービスへ送らなければならない設計ではありません。政府調達のISMAP、金融のFISC安全対策基準、医療の3省2ガイドライン。日本の要件はどれも「データの置き場所」と「説明できること」を問います。この2つは、機能の1つではなく入口の条件です。 ※ ISMAPへの登録有無は、ISMAPポータルの最新のクラウドサービスリストでご確認ください。ここでは要件の説明にとどめています。「Elasticって、本当にセキュリティの会社なの？」と疑問に思われる方へ Elasticは検索エンジンの会社として知られています。この疑問は自然です。そこでElastic自身の主張ではなく、第三者が公表した評価を並べます。評価レポート公表位置づけ Gartner® Magic Quadrant™ for SIEM 2025年10月 Visionary The Forrester Wave™: Security Analytics Platforms, Q2 2025 2025年6月 Leader （2回目）。14項目で最高点、Federated Searchでも最高スコア The Forrester Wave™: XDR Platforms, Q2 2026 2026年6月 Strong Performer IDC MarketScape: Worldwide SIEM 2026 （doc #US54126826） 2026年6月 Leader IDC MarketScape: Worldwide XDR Software 2025 （doc #US52997325） 2025年9月 Leader AV-Comparatives Business Security Test （2026年3〜6月期） 2026年7月 Malware Protection 100%（16製品中で唯一）。Real-Worldも399/400（99.8%）で最高スコアに並ぶ正確に書いておきたい点が2つあります。 Forrester XDRは Strong Performer です。すべての評価で1位、ではありません。 AV-Comparativesの誤検知について。一般的な業務ソフトを対象としたFalse Alarm Testは0件でしたが、Real-World Protection Testでは12件の誤検知が記録されています。「テスト全体で誤検知ゼロ」ではありません。そしてもう1つ。 Elasticの検知ルールとエンドポイント保護は、GitHubで公開されています（elastic/detection-rules、elastic/protections-artifacts）。買う前に「どこまで検知できるのか」を自分の目で監査できます。閉じた製品では、これができません。 RFI・RFPに書くべき5項目 RFI（情報提供依頼書）とRFP（提案依頼書）は、製品を選ぶときにベンダーへ出す文書です。大事なのは、RFPに書いていない条件には、ベンダーは答えないということ。書けば全社が必ず答え、できる会社とできない会社がその場で分かれます。以下は「Elasticの機能一覧」ではありません。どのベンダーを選ぶにしても、要件定義書に書いておくべき5項目です。全量の取り込み — すべてのログソースを対象にできる。予算の都合で外す必要がない全履歴の検索 — 数年分を1つのクエリで検索できる。復元作業を必要としない開かれた文脈 — 他社製品のアラートやテレメトリーも含めてAIが推論できる監査できるAI — 結論の元データをたどれる。アナリストにも監査部門にも説明できる設置場所を選べる — クラウド、オンプレミス、閉域環境第2項は、10月1日以降の説明責任に直結します。第5項は、閉域要件があるだけで候補が数社に絞られます。いまお使いのSIEMを、止める必要はありません「既存のSIEMにすでに投資していて、簡単には変えられない」、ほとんどの組織で当てはまります。 EASE（Elastic AI SOC Engine）は、既存のSIEMやEDRの上で動くサーバーレスのパッケージです。撤去は不要で、既存環境からアラートを取り込み、Attack DiscoveryとAIアシスタントを使えます。大きな稟議を通す前に、自社のアラートで結果を確かめられます。将来の移行には Automatic Migration があります。例えば、SplunkのSPLで書かれた検知ルールをES|QLに翻訳し、Elastic提供の1,300以上の検知ルールに対応付けます。ただし「部分的に翻訳」「翻訳できず」という状態もあり、手を入れてからでないと導入できないルールもあります。全部が自動で移るわけではありませんが、ゼロから書き直す手間はかなり減ります。まとめ 1. 問われるのは、守れているかではなく、説明できるかです。取り込んでいないログは、検知も説明もできません。 2. ログが見えていない理由は、能力ではなく構造です。取り込み量への課金が、そのまま可視性の穴になっています。 3. 判断材料は、他社の事例より自社のアラートです。既存のSIEMを止めずに検証できます。 10月1日、義務が始まるのは、ごく限られた事業者です。貴社ではないかもしれません。ただ、その事業者が報告書を書くとき、材料を求められるのは外側の会社です。政府の基本方針も「広く様々な事業者が対象となり得る」と書いています。義務がない側には、まだ準備する時間があります。出典統計・法制度記載出典ランサムウェア226件、中小企業約6割、製造業約4割、VPN機器6割以上、復旧費1,000万円以上が5割超、1か月未満の復旧5割強、RaaS 警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月） https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf ブレイクアウトタイム29分、最短27秒 CrowdStrike「2026 Global Threat Report」 https://www.crowdstrike.com/en-us/global-threat-report/ 届出・報告義務、「広く様々な事業者が対象となり得る」の引用内閣府「サイバー対処能力強化法に基づく基本方針の概要」令和7年12月 https://www.cao.go.jp/cybersecurity/pdf/kihonhoushin_gaiyou.pdf 15分野258者（2026年7月1日時点）、導入等計画書に委託・再委託の相手方も記載内閣府「経済安全保障推進法における特定社会基盤役務の安定的な提供の確保に関する制度（説明会資料）」2026年7月7日 https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/doc/infra_setsumeikai.pdf 医療分野の追加厚生労働省「基幹インフラ制度への医療分野の追加について」 https://www.mhlw.go.jp/content/10808000/001703605.pdf 供給者の努力義務、「サイバーインフラ事業者」ガイドライン（2026年3月31日）経済産業省・内閣官房国家サイバー統括室 https://www.meti.go.jp/press/2025/03/20260331001/20260331001.html Elasticの製品・事例記載出典 8,500億件、約14,000エンドポイント、月80,000件超のアラート EDD導入事例 Attack Discoveryの元データ確認とアナリストによる検証 Elastic Docs: Attack discovery 外部LLM・自己管理LLMの接続 Elastic Docs: LLM connectors 1,300以上の検知ルール、部分翻訳・未翻訳の状態 Automatic Migration ／ Elastic Docs EASEが既存SIEM／EDRの上で動く Elastic AI SOC Engine 発表 Serverlessの取り込み課金、Hostedのリソース課金 Serverless ／ Cloud Hosted The post 2026年10月1日、基幹インフラに攻撃の報告義務。ログを聞かれるのは誰か、そしてその準備 first appeared on Elastic Portal .

GitHub, セキュリティ, データ分析, 人工知能, インフラ, テスト, Serverless, 設計, オンプレミス, 統計

サイオステクノロジー((DXSL)) の技術ブログ

コンテンツ