CanonicalのCISOがEUサイバーレジリエンス法を完全解説

by Canonical on 15 August 2024

強力で対象の広い規制は、関係者の安全を確保する一方、不確定性をもたらす可能性があります。EUサイバーレジリエンス法(CRA)も例外ではありません。オープンソース関係者と技術業界全般にわたり、心配、不安、希望などさまざまな反応が見られます。

しかし怖がる理由があるのでしょうか? EUサイバーレジリエンス法が本当にオープンソースの状況を変えるのでしょうか? 企業はこの法律にどう備えれば良いのでしょうか? この記事ではEUサイバーレジリエンス法とその目的、要件、オープンソース関係者に対する影響を説明し、施行に備えたサイバーセキュリティ上のアドバイスをご紹介します。

EUサイバーレジリエンス法とは?

EUサイバーレジリエンス法(CRA)とは、欧州連合(EU)の法律で、EUのIT業界にサイバーセキュリティ、ドキュメント作成、脆弱性報告の厳しい要件を課すことで、デバイスの安全性を高めることを目的とします。同法は、ハードウェア、デバイス、ソフトウェア、アプリケーション、そのほか「デジタル接続要素を有する製品」の開発、販売、製造、小売企業に適用されます。同法の要件、規則、規制は、製品のライフサイクル全体を対象とします。

EUサイバーレジリエンス法(CRA)の目的は、デジタル要素を含む製品やソフトウェアを購入または使用する消費者と企業を守ることです。同法は、そのような製品の製造者や小売業者にサイバーセキュリティの必須要件を課すことで、セキュリティ機能の不備を防ぐとともに、ライフサイクル全体にわたって製品を保護します。」

EUサイバーレジリエンス法(CRA)

同法は以下を定めます。

  • デジタル要素を有する製品やソフトウェアを市場化する際の整合規則
  • 該当製品の計画、設計、開発、メンテナンスに関するサイバーセキュリティ要件の枠組み、およびバリューチェーンの各段階で満たすべき義務
  • 該当製品のライフサイクル全体にわたって注意義務を果たす義務

前もって読みたい方はEUサイバーレジリエンス法案全文をご覧ください。最も重要な点、要件のチェックリスト、自社との関連のみ知りたい方には、EUサイバーレジリエンス法附属書をおすすめします。

次にEUサイバーレジリエンス法の主な目的を見てみましょう。具体的な要件の理解に役立つはずです。

EUサイバーレジリエンス法の主な目的は?

EUサイバーレジリエンス法には4つの目的があります。

  1. 設計と開発の段階からライフサイクルが終わるまで、製造者にデジタル要素を有する製品のセキュリティを強化させる。
  2. 一貫したサイバーセキュリティの枠組みを作り、ハードウェアとソフトウェアのメーカーのコンプライアンスを促進する。
  3. デジタル要素を有する製品のセキュリティ特性の透明性を高める。
  4. 企業や消費者がデジタル要素を有する製品を安全に利用できるようにする。

規制対象製品の製造者や開発者にとって、これには以下の具体的な意味があります。

  • 製造者は、生産する前も販売した後もデバイスのセキュリティを確保し、維持する必要がある。
  • 市販するハードウェアとソフトウェアは新しいEUコンプライアンス基準を満たす必要がある。
  • ハードウェアとソフトウェアにはその構成要素、設計、セキュリティについて明確な情報とドキュメントが必要である。
  • 製造者とパブリッシャーは製品の重要な脆弱性を報告する必要がある。
  • 規制対象となるハードウェア、ソフトウェア、デジタルデバイスは増加している。

自社にとってEUサイバーレジリエンス法の意味は?

これは、製品がEUサイバーレジリエンス法のどの分類に入るかによって決まります。デジタルデバイスやサービスには複数のクラスがあります。最も一般的な「デジタル要素を有する製品」は自己評価が可能であり、クリティカルクラスI、IIには入りません。クリティカルクラスの場合は第三者による証明、場合によっては認証が必要です。カテゴリに関係なく、これには4つの大きな意味があります。

  1. 自社製品のライフサイクルの終わりまで、設計と更新スケジュールの両方で厳しいセキュリティ基準を満たす必要がある。
  2. リスク評価、ドキュメントへのアクセス、適合性評価、脆弱性報告など、多くの新しい要件を満たす必要がある。
  3. 時間がない。
  4. 新しい要件を満たさなければ重い罰則や罰金を受ける場合がある。

満たす必要のあるサイバーセキュリティの要件

基本的にEUサイバーレジリエンス法は、現在より厳しいソフトウェアとデジタル製品に関する「EU基準」を確立します。これらの新基準は(さまざまな程度で)開発者、製造者、輸入者、販売者に適用されます。

新しいセキュリティ基準の概要は以下のとおりです。

  • 何であれ可能な限り安全に構築する必要がある。攻撃対象領域は最小限に抑える。
  • デバイスや製品は堅牢化する必要がある。つまり不正アクセスをなくす、データを暗号化または保護する、データとコマンドが傍受や乗っ取りを受けないようにする。さらに、たとえDoS攻撃を受けても製品が機能を続ける、侵入を受けても他のデバイスを邪魔しない、デバイスのモニタリングや変更のログ記録によってセキュリティデータを提供することを意味する。
  • 製品はセキュリティ更新やロールバックを受信できる必要がある。これは、直接またはリモートでの更新、更新に関するユーザー通知、更新をロールバックまたは製品を工場出荷時/デフォルトの状態にリセットする機能も含む。

加えて、以下の文書についても要件があります。

  • 新しいドキュメントを提供する。そのドキュメントにアクセスできる場所も広く伝える。
  • 明確なソフトウェアサプライチェーンと正式なソフトウェア部品表(SBOM)を提供する。SBOMはアクセスしやすく、機械での読み取りに対応する必要がある。
  • 製品のリスク評価も行い、製品の適合性評価を完了する。
  • 製品にセキュリティ更新を提供し、ユーザーや関連のEU当局に製品の脆弱性について伝える明確な計画と手続きを定める。
  • 最大5年間(製品の寿命が5年より短い場合は寿命)は、EUサイバーレジリエンス法の適合性基準を満たさない製品をリコールまたは回収する必要がある。

設計、ドキュメント、適合性における新しい要件

EUサイバーレジリエンス法は以下の4つを義務付けます。

  1. リスク評価
  2. ドキュメント作成
  3. 適合性評価
  4. 脆弱性の報告

I. リスク評価

製造者/開発者は、製品のサイバーセキュリティのリスク評価を実行する必要があります。リスク評価では主に以下を判断します。

  • 攻撃可能な既知の脆弱性なしで製品を出荷できるか?
  • 「セキュアバイデフォルト」の状態で製品を出荷できるか?
  • 製品が処理するデータは最小限か?
  • 製品の攻撃対象領域は最小限か?
  • 製品はセキュリティ更新を提供し、ユーザーに更新を通知するか?

デバイスや製品が「非クリティカル」カテゴリに入った場合は、評価を自社で実行できます。ただし、クラスI、クラスIIの場合は独立した第三者による評価が必要です。

II. ドキュメント作成

EUサイバーレジリエンス法には、ドキュメント作成と製品情報について新しい要件があります。一般に製造者や開発者は以下を提供する必要があります。

  • 設計、開発、脆弱性取り扱い手順の説明
  • サイバーセキュリティリスクの評価
  • 製品が適合するEUサイバーセキュリティ整合規格のリスト
  • 上記の必須要件を満たしたという署名済みのEU適合宣言書
  • 製品の脆弱性と構成要素を文書化したソフトウェア部品表(SBOM)

II. 適合性評価

製品は、デバイスまたは製品のクラスに応じて適合性評価を受け、EUサイバーレジリエンス法の要件をすべて満たすことを確認する必要があります。

製品のクラス要件
非クリティカルの製品製造者/開発者が自社で適合性評価を実施できる。
クラスI、クラスIIの製品公認機関(notified body)、つまりEUが認定する独立した監査法人が評価を実行しなければならない。

IV. 報告と脆弱性の取り扱い

EUサイバーレジリエンス法は、ソフトウェアとハードウェアのメーカーが、脆弱性を欧州連合サイバーセキュリティ機関(ENISA)に24時間以内に報告することを定めています。

メーカーに対しては、製品のサイバーセキュリティ上の脆弱性の継続的なテスト、更新、ドキュメント作成に関連して、ほかにも多くの要件があります。開発者には以下が求められます。

  • 製品に影響を与える、または製品に含まれる脆弱性を特定し、文書化する。製品にはユーザーが将来的に脆弱性を報告するための明確な連絡先も必要。
  • 少なくともトップレベルの依存ファイルを記載したソフトウェア部品表(SBOM)。SBOMはアクセスしやすく、機械での読み取りに対応する必要がある。
  • 新しい脆弱性が発見された場合にデバイスを安全に更新できるようにする。更新は無料とし、ユーザーがどんな操作をすべきかの情報とともに、可能な限り早く送信する必要がある。
  • 製品を定期的にテストし、脆弱性は即座に修正する。修正を適用した後、修正した脆弱性が何だったかを一般に公開する(EUサイバーレジリエンス法に基づく新しい協調的脆弱性開示ポリシーに従う)。そこには以下を記載する。
    • 脆弱性とその重大性の説明
    • 対象のデジタル要素を有する製品をユーザーが特定するための情報
    • 脆弱性の影響
    • ユーザーが脆弱性に対処するための情報

時間がない

EUサイバーレジリエンス法に備える時間はあまりありません。同法は2024年の官報発行(5月初旬予定)から20日目に施行されます。施行されれば、ハードウェアとソフトウェアの製造者、輸入者、販売者は36か月以内に新しい要件に対応する必要があります(ただし製造者によるインシデント発生と脆弱性の報告義務については21か月の猶予期間がある)。36か月は長いように見えますが、製品や事業が複雑なほど適合は厳しくなります。

非コンプライアンスに対する新しい罰則と罰金

要件への不適合または違反が見つかった場合、罰金が課せられます。罰金は加盟国それぞれが独自に決定し、ENISAに報告するため、国によって異なる場合があります。しかし現在の目安では、違反の重大性に応じて500万~1,500万ユーロ、または世界売上高の1~2.5%のいずれか高いほうとされています。詳細は、EUサイバーレジリエンス法の第7章第52条「機密性」と第53条「罰則」をご参照ください。

EUサイバーレジリエンス法の対象デバイス/製品は?

EUサイバーレジリエンス法の対象範囲は広く、その影響はデバイスやソフトウェアのカテゴリによって異なります。デバイスとソフトウェアはサイバーセキュリティのリスク、行政機関へのアクセスレベル、機密性の高いインフラストラクチャ、ネットワーク、システムへの接続の程度に応じて、以下の3つのカテゴリに分類されます。

  • クリティカルでない:EUサイバーレジリエンス法によれば全製品の約90%。スマートスピーカー、ハードディスクドライブ、ゲーム、一部の高レベルのプログラミング言語(Python、React)など
  • クリティカルクラスI(低リスク):パスワードマネージャー、ファイアウォール、マイクロコントローラ、VPN、ネットワークやアプリの管理/設定システム、ウェブブラウザ、リモートアクセスソフトウェア、ID管理システムなど
  • クリティカルクラスII(高リスク):オペレーティングシステム、マイクロプロセッサー、産業用ファイアウォール、CPU、コンテナランタイムシステム、公開鍵インフラストラクチャおよびデジタル証明書発行者、ハードウェアセキュリティモデルなど

具体的な製品の詳細なリストや分類方法については、EUサイバーレジリエンス法附属書3をご覧ください。

上記のようなリストを見ると、自社製品がクリティカルのクラスには入らないと思うかもしれませんが、同法は以下のように脆弱性を非常に幅広く捉えています。

「特定の条件下では、デジタル要素を統合した、または大きな電子情報システムに接続するすべての製品が、悪意ある者の攻撃ベクトルとなる可能性がある。」

つまり低クラスのハードウェアやソフトウェアでも、理論的には、接続する大きなデバイスやネットワークへの攻撃を容易にする可能性があります。法の対象から逃れることはできません。

したがって、それほどクリティカルでない製品を作っているとしても、同法の要件を満たす製品設計が求められる可能性が十分にあることを認識してください。通常は安全またはコンプライアンスの条件を満たしていても、脆弱性チェーン攻撃を受けた場合に自社ユーザーに影響を与えるような他のテクノロジー、製品、サービスに自社製品が依存している場合はなおさらです。

製品が開示または文書化すべき情報は?

上で述べたように、EUサイバーレジリエンス法は製品やサービスに関する大量の情報を文書化し、開示することを求めます。情報の大半は製品に添付する必要があります。それが不可能な場合は、製品のパッケージや説明書に含めます。新しい製品ステッカーや警告ラベルを作ったり、readme.txtやユーザーマニュアルに書き加えたりしてもかまいません。

製品に「デジタル要素」がある限り、最小限でも以下を文書化し、伝える必要があります。

Vメーカーの名称または登録商標V製品のセキュリティ情報と特性
Vメーカーの連絡先住所Vサイバーセキュリティ上の脆弱性が生じる危険のある状況
V製品のサイバーセキュリティ上の脆弱性を報告または情報を受け取る場所V製品のソフトウェア部品表とアクセス可能な場所
V製品、ユーザー、セキュリティ情報を特定するために必要なすべての情報(バッチまたはシリアル番号など)V製品のEU適合宣言書
V製品の想定される用途と基本的な機能Vすべてのメーカーサポート情報とセキュリティ更新情報
V以下に関する詳細情報(説明書またはインターネットアドレス): 製品を安全に使用するために必要な対策製品への変更がデータのセキュリティに与える影響セキュリティ関連の更新をインストールする方法デバイスからデータを削除する、またはデバイスの使用を中止する方法

EUサイバーレジリエンス法に備えてすべきこと

最高情報セキュリティ責任者(CISO)やセキュリティ/コンプライアンスチームと一緒に読む

どんな共通脆弱性識別子(CVE)やサイバーセキュリティ上の脆弱性でもそうですが、完全に理解しなければ備えることもできません。まずは法務、コンプライアンス、エンジニアリング担当者と一緒に発行されたEUサイバーレジリエンス法の最終的な文言を理解し、同法の規制が適用される分野を特定することです。規制の適用を過度に見積もることを恐れないでください。ドキュメントやサイバーセキュリティ対策を入念に作りすぎたほうが、「文言が自社を明確に意味していない」と甘くみて失敗するよりましです。

文書化する

ドキュメントは重要です。自社のソフトウェアがどこで作られ、何でできていて、どれだけ安全か(どうやって安全に維持するか)を顧客に明確に示しましょう。最低でも以下を文書化し、一般とEU当局に公開する必要があります。

  • 設計、開発、脆弱性取り扱い手順の説明
  • サイバーセキュリティリスクの評価
  • 製品が適合するEUサイバーセキュリティ整合規格のリスト
  • 上記の必須要件を満たしたという署名済みのEU適合宣言書
  • 製品の脆弱性と構成要素を文書化したソフトウェア部品表(SBOM)

サイバーセキュリティ対策の分析と再考

近年、セキュリティに議論の余地はありません。それは良いことです。まともな開発企業の大半が、NIS2やISO 27001など現行の義務を果たすだけで、EUサイバーレジリエンス法の基本的なサイバーセキュリティ要件を満たすということだからです。

しかし今こそ、自社の評価、計画、サイバーセキュリティの手順、設計基準をしっかり検討するチャンスです。自社のサイバーセキュリティ基準がEUサイバーレジリエンス法と比べてそれほど低くなくても、このような法律は大きな波の前兆です。あらゆるソフトウェア、デバイス、製品の生産者は、ユーザーや購入者が暗黙的に信頼できる、安全で脆弱性の少ない基盤を示すよう迫られています。

脆弱性を報告する確実な社内手続き

企業には、脆弱性を発見したらすぐに報告する明確な手続きが必要です。この手続きを社内のチームやポリシーにしっかり組み込んでください。社内にチーム(あるいは、理想的にはチーム内に報告の専任担当者を定める)を置き、最悪の事態が生じた場合に必ずEUサイバーレジリエンス法の当局に連絡し、できるだけ罰金を避けることをおすすめします。

コンプライアンス/適合性評価に備える

社外テスト、社内評価のいずれにしても、コンプライアンス/適合性評価に向けた明確な社内手続きとドキュメントが必要です。自社の証明書やドキュメントをどのように公開し、アクセス可能な連絡先(readme.txt、製品情報シート、デバイス自体など)をどこに記載するかも考えてください。

EUサイバーレジリエンス法はどのみち施行されるのですから、準備が必要です。製品の属するクラスによっては追加の評価、セキュリティ、ドキュメント、パッチ、コンプライアンス、報告が企業とチームに求められる可能性もあります。自社のデジタル製品やサービスがどこに分類されるかを知り、サイバーセキュリティ対策と設計基準を再検討すると同時に、社内手続きを綿密に見直し、ソフトウェアサプライチェーンと製品に関する情報を有効かつ速やかに公開する方法(新しい脆弱性を報告するとともに)を判断する必要があります。

https://jp.ubuntu.com/enterprise-support

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

Firefighting Supportを発表

新しいサービスでCanonicalの専門家が高度なクラウドサポートを提供 Canonicalのマネージドソリューションチームは、自社でインフラストラクチャの管理を行い、トラブルシューティングの必要があるときのみ専門家の対応を求める組織のために、新しいサービス「Firefighting Support」を発表しました。 Firefighting Supportでは、フルマネージドサービスを止めた、または厳しいセキュリティ規制によってサードパーティーに環境へのアクセスを許可できないお客様に対して、マネージドサービスレベルのサポートを提供します。このサービスはノードごとの年間料金で提供され、次のような内容です。 自己管理インフラストラクチャへの移行に理想的 現在の市場では、マネ […]

Linuxにセキュリティパッチを適用する頻度は?

セキュアな環境を維持するには定期的なパッチの適用が不可欠ですが、Linux環境を安全に保つための方法は環境によって異なります。運用の安定性を考えて、どのぐらいの更新頻度が妥当でしょうか? 最も制限が多く、規制が厳しい環境でも、準拠が保証され安全な方法で、セキュリティパッチの適用を自動化できる方針が存在します。セキュリティパッチの適用方針を定義するときは、Canonicalでのソフトウェア更新のリリーススケジュールを理解し、セキュリティパッチの適用の時間枠を知っておくことが不可欠です。私は最近、ライブのウェビナーとセキュリティの質疑応答を主催し、パッチ適用の回数を最小化するとともに、パッチが適用されていない脆弱性が悪用される回数も最小化する方法について解説しました。この記事 […]

SBI BITSとCanonical:OpenStack 導入と6年間の進化の物語

SBI BITSとCanonicalのパートナーシップは、SBIグループのITインフラを進化させ、事業継続性を確保しながら顧客満足度を向上させる成功事例として注目されています。本記事では、2018年のOpenStack/Ceph導入から6年にわたる協力の軌跡をたどります。 第1フェーズ:OpenStackの採用と初期導入 (2018年) 2018年、SBI BITSは従来の仮想化技術からOpenStack/Cephへの移行を決定しました。SBIグループ全体にITインフラを提供するSBI BITSは、リソースを迅速かつ効率的に配分する能力が求められていました。その解決策として選ばれたのが、CanonicalのOpenStack/Cephです。 この選択の理由は、以下の点にあ […]