こんにちは、インフラエンジニアのryuです。
2026年9月11日から、EUのサイバーレジリエンス法（CRA）の報告義務が始まりました。
「EUの法律なら日本で働いている自分には関係ないのでは？」と思う方も多いと思います。
ですが、EUに製品を出荷している日本のメーカーやソフトウェア会社は、この日から報告義務の対象になっています。 そして報告に必要な情報（どのサーバーに何が入っているか、ログが残っているかなど）は、インフラエンジニアが管理していることが多いです。
この記事では、CRAで何が始まったのかと、インフラエンジニアとして準備しておきたいことをまとめます。 法律の細かい解釈ではなく、現場のエンジニアから見た整理として読んでください。
サイバーレジリエンス法（CRA）とは？¶
CRAは、EU市場に出回る「デジタル要素を含む製品」に、セキュリティの責任を求める法律です。 正式には Regulation (EU) 2024/2847 といい、2024年12月10日に発効しました。
サイバーレジリエンス法（CRA）とは、ネットワークにつながるハードウェアやソフトウェアを対象に、設計段階から販売後のサポート終了までセキュリティを確保することを、製造業者などに義務づけるEUの規則。
対象になるのは、ルーターやネットワークカメラ、スマート家電、業務用のソフトウェアなど、ネットワークにつながる製品です。 これらの製品を作っている会社は、販売した後もサポート期間中は脆弱性に対応し続ける必要があります。
いつから何が始まるのか¶
CRAは段階的に適用されます。
| 時期 | 起きること |
|---|---|
| 2024年12月10日 | CRAが発効 |
| 2026年9月11日 | 製造業者の報告義務が適用開始（悪用された脆弱性・重大インシデント） |
| 2027年12月11日 | セキュリティ要件への適合やCEマーキングなど、主な義務が全面適用 |
今回始まったのは、表の2行目の報告義務です。 製品のセキュリティ要件への対応など、大きな義務は2027年12月からになります。
注意したいのは、報告義務は2026年9月11日より前に市場に出た製品にも適用されるという点です。 新しく発売する製品だけでなく、すでに売っている製品も対象です。
対象になる製品とならない製品¶
対象は「デジタル要素を含む製品」で、ハードウェアもソフトウェアも含まれます。 一方で、純粋なSaaS（ブラウザから使うクラウドサービス）は、原則としてCRAの対象外です。
ただし例外があります。 製品が正しく動くために欠かせない「リモートデータ処理」は、製品の一部として扱われます。 たとえば、スマート家電を外出先から操作するためにメーカーが提供しているクラウド機能は、対象に含まれます。
| 例 | CRAの扱い |
|---|---|
| 家庭用ルーター、ネットワークカメラ | 対象 |
| 業務用のインストール型ソフトウェア | 対象 |
| スマート家電を遠隔操作するためのメーカーのクラウド | 製品の一部として対象 |
| 単独のSaaS（Webブラウザから使う業務サービス） | 原則として対象外（NIS2など別の規制で扱われる） |
インフラエンジニアに特に関係があるのは、3行目のケースです。 自社製品のクラウド側のサーバーを運用している場合、そのサーバーも報告の対象範囲に入る可能性があります。
報告義務の内容¶
では、具体的に何をいつまでに報告する必要があるのでしょうか。
報告の対象は次の2つです。 製品に含まれる「積極的に悪用されている脆弱性」と、製品のセキュリティに影響する「重大インシデント」です。
24時間・72時間・最終報告の3段階¶
報告は段階ごとに期限が決まっています。 一番短いものは把握してから24時間以内です。
| 段階 | 期限 | 主な内容 |
|---|---|---|
| 早期警告 | 把握から24時間以内 | 悪用やインシデントが起きていることの第一報 |
| 通知 | 把握から72時間以内 | 脆弱性や悪用の性質、講じた対策、利用者がとれる対策 |
| 最終報告（脆弱性） | 修正措置が利用可能になってから14日以内 | 深刻度と影響、原因、修正内容など |
| 最終報告（インシデント） | 72時間の通知から1か月以内 | 原因の見立て、実施中の緩和策など |
報告は、EUのサイバーセキュリティ機関であるENISAが運営する「単一報告プラットフォーム（SRP）」から行います。 提出した内容は、受け付けた国のCSIRTから、製品が販売されている他の加盟国の当局にも共有されます。
また、オープンソースソフトウェアの「スチュワード」と呼ばれる、OSSを継続的に支援する組織にも、一定の報告義務が定められています。
違反した場合の罰則¶
CRAには罰則もあります。 違反の内容によっては、最大1500万ユーロ、または全世界の年間売上高の2.5%のいずれか高いほうが上限とされています。
日本でも、24時間以内に報告できる体制を作る必要があると報じられています。
インフラエンジニアに関係する理由¶
ここまで読んで「法務やセキュリティ部門の仕事では？」と思った方もいるかもしれません。 実際に報告書を提出するのは、別の部署の場合が多いと思います。
ただ、24時間以内に第一報を出すには、次のようなことにすぐ答えられる必要があります。
- その脆弱性のあるソフトウェアは、どの製品の、どのバージョンに入っている？
- いつから悪用されていた？ログは残っている？
- 影響を受けたサーバーや利用者の範囲は？
こうした情報を持っているのは、多くの場合インフラエンジニアです。 報告の期限は、調査を始めた時点ではなく、把握した時点から数えます。 そのため、パッケージの一覧やログが普段から揃っていないと、期限内に報告するのはかなり厳しくなります。
事前に準備しておかないと間に合わない¶
24時間は、実際に対応してみるとかなり短いです。 脆弱性が見つかってから、全サーバーに入っているソフトウェアのバージョンを調べ始めていたら、それだけで1日が終わってしまうこともあります。
なので、普段から「どのサーバーに何が入っているか」を把握しておくことが、そのまま報告のスピードにつながります。
「積極的に悪用されている」かどうかの調べ方¶
報告の対象になるのは、すべての脆弱性ではありません。 「積極的に悪用されている」脆弱性です。
では、自社の製品に含まれる脆弱性が実際に悪用されているかどうかは、どうやって調べればいいのでしょうか。
自社で気づく場合と、外部の情報で知る場合¶
悪用に気づくきっかけは、主に2つあります。
一つは、自社の環境で気づくケースです。 監視のアラートや、見慣れないアクセスのログから、攻撃の痕跡が見つかることがあります。 製品のクラウド側を運用している場合は、そのサーバーのログが最初の手がかりになります。
もう一つは、外部の情報から知るケースです。 たとえば米国のCISAは、実際に悪用が確認された脆弱性を KEV（Known Exploited Vulnerabilities）カタログとして公開しています。 日本語で情報を確認するなら、JPCERT/CCとIPAが共同で運営している脆弱性情報ポータルのJVNが便利です。
| 情報源 | 分かること | 使いどころ |
|---|---|---|
| 自社の監視・ログ | 自分の環境で攻撃が起きているか | クラウド側の運用、社内の検証環境 |
| CISA KEVカタログ | 世界で悪用が確認された脆弱性の一覧 | 優先して対応すべきものの見極め |
| JVN | 日本語での脆弱性情報と対策 | 国内製品や日本語での情報共有 |
大事なのは、こうした情報と、後で紹介するパッケージの一覧を照らし合わせられるようにしておくことです。 両方が揃っていれば、「自社の製品が影響を受けるか」をすぐに判断できます。
製造業者以外も関係がある¶
CRAは、製品を作る製造業者だけでなく、EUに製品を持ち込む輸入業者や、販売する流通業者にも一定の義務を定めています。 自社は製品を作っていなくても、取引先の製品を扱っている場合は、脆弱性の情報を製造業者に伝える役割が求められることがあります。
また、自社の業務システムに使っている製品が対象になっていれば、メーカーから脆弱性の通知が届く機会も増えるでしょう。 通知が来たときに、社内のどのサーバーに影響があるかすぐ答えられるように、普段から把握しておくことが大切です。
現場で準備しておきたい3つのこと¶
ここからは、インフラエンジニアが実際に準備できることを紹介します。 どれもCRAの対象かどうかに関係なく、普段の運用でも役に立つものです。
1. サーバーに入っているソフトウェアの一覧を作る¶
2027年12月から全面適用される要件には、SBOM（ソフトウェア部品表）の作成も含まれています。 少なくとも最上位の依存関係を、機械で読める形でまとめておくことが求められます。
SBOMの考え方そのものは 2026年のソフトウェアサプライチェーン攻撃とSBOM／SLSAで守る新常識 で詳しく解説しました。 インフラの現場では、まずサーバーやコンテナに入っているパッケージの一覧を取れるようにしておくところから始めるといいと思います。
# RHEL系：インストール済みパッケージとバージョンを一覧にする
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\n' | sort > packages_$(hostname)_$(date +%F).tsv
# Debian/Ubuntu系：同じくパッケージとバージョンを一覧にする
dpkg-query -W -f='${Package}\t${Version}\n' | sort > packages_$(hostname)_$(date +%F).tsv
# コンテナイメージからSBOMを作る例（Syftを使う場合）
syft nginx:latest -o cyclonedx-json > sbom_nginx.json
一覧があれば、新しい脆弱性が公表されたときに、該当するパッケージが入っているかをすぐに確認できます。 一覧がないと、全サーバーにログインして調べるところから始めることになります。
2. ログの保管期間と時刻を確認する¶
「いつから悪用されていたか」を答えるには、ログが残っていることが前提です。 また、複数のサーバーのログを突き合わせるには、サーバー同士の時刻がずれていないことも必要です。
# 時刻同期ができているかを確認する（chronyの場合）
chronyc tracking
# ログのローテーション設定で、保管期間を確認する
grep -E 'rotate|daily|weekly' /etc/logrotate.conf
ログの読み方に自信がない方は、原因はだいたいログに書いてある。ログの読み方入門 も読んでみてください。
3. 報告の流れを一度試しておく¶
最後は技術というより、社内の段取りの話です。 脆弱性が見つかったときに、誰が誰に連絡して、どの情報を集めるのか。 この流れを一度訓練としてやっておくと、実際に起きたときに慌てずに済みます。
報告の期限は「調査が終わってから」ではなく「把握してから」数える。最初の数時間で集める情報は、事前に決めておいたほうがいい。
日本でも、2026年10月から基幹インフラ事業者にインシデント報告を義務づける仕組みが動き出します。 国内の動きは 能動的サイバー防御の法律がインフラエンジニアの現場に求めること でまとめています。 国内の報告でも海外の報告でも、必要になる準備はほぼ同じです。
基礎から勉強し直したい方へ¶
CRAのような規制に対応するには、「自分の環境に何が入っていて、何が起きたのか」を説明できる必要があります。 そのためには、Linuxやネットワークの基礎が分かっていることが前提になります。
InfraAcademy の Linuxロードマップ では、パッケージ管理やログ、時刻同期といった、今回紹介した準備に必要な内容を順番に学べます。 ネットワークの基礎を勉強したい方は ネットワークロードマップ もあわせてどうぞ。
また、チームで脆弱性対応や報告の流れを教えたい企業の方は、法人プラン もご覧ください。
まとめ¶
今回は、2026年9月11日に報告義務が始まったEUのサイバーレジリエンス法（CRA）について解説しました。
- CRAは、EU市場向けのデジタル要素を含む製品に、販売後まで続くセキュリティ責任を求める
- 悪用された脆弱性や重大インシデントは、把握から24時間以内の早期警告が必要
- すでに市場にある製品も対象で、日本企業も無関係ではない
- 期限内に報告するには、パッケージの一覧、ログと時刻、報告の段取りを普段から準備しておく必要がある
規制が増えると大変そうに見えますが、求められていることの多くは、普段の運用でもやっておきたいことです。 できるところから少しずつ準備していきましょう。
参考¶
- The CRA Single Reporting Platform is launched（ENISA）
- Single Reporting Platform (SRP)（ENISA）
- Cyber Resilience Act - Reporting obligations（European Commission）
- Cyber Resilience Act: the fine line between SaaS and digital products（DLA Piper）
- 欧州CRAが26年9月に脆弱性報告を義務化、24時間以内に報告できる体制が必要（日経クロステック）
- EU Cyber Resilience Act – Open Source Security Foundation
- Known Exploited Vulnerabilities Catalog（CISA）
- JVN（Japan Vulnerability Notes）
