開発環境

Zephyrのビルド

• https://docs.zephyrproject.org/latest/develop/getting_started/index.html
• https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html

サンプルのビルド

以下のコマンドでサンプルアプリケーションをビルドします。

$ cd ~/zephyrproject/zephyr

$ west build -p always -b zc702 samples/hello_world

~/zephyrproject/zephyr/build/zephyr/以下にzephyr.binが作成されたことを確認します。

これがZephyrアプリケーションのバイナリになります。

$ ls ~/zephyrproject/zephyr/build/zephyr/

U-Bootの準備

Zynq-7000ではZephyrアプリケーションを実行する前にSoCの初期化をする必要があります。

ですので、SoCの初期化を行うプログラムを準備します。

今回は以下のXilinxのWikiにあるビルド済みのU-bootを使います。

• https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841732/Ubuntu+on+Zynq?view=blog  

$ cd ~

$ wget https://xilinx-wiki.atlassian.net/wiki/download/attachments/18841732/zynq-ubuntu-core-12.10-core-armhf-boot.tar.xz

$ tar Jxfv zynq-ubuntu-core-12.10-core-armhf-boot.tar.xz

展開したファイルにboot.binがあることを確認します。

これが最初にロードされるバイナリになります。

$ ls boot

SDカードの準備

SDカードをFAT32形式でフォーマットし、以下の準備したファイルを書き込みます。

boot.bin

zephyr.bin

Zephyrの起動

ボードのスイッチを操作してSDブートするようにし、ボードにSDカードをセットし、ボードの電源を入れます。

U-bootが起動したらオートブートを中断して、以下のコマンドを入力してZephyrアプリケーションのロードと実行を行います。

zynq-uboot> fatload mmc 0 0x0 zephyr.bin

zynq-uboot> go 0x0

Zephyrアプリケーションが以下のメッセージを出力することを確認します。

*** Booting Zephyr OS build v4.1.0-5075-gcf6170cbe605 ***

Hello World! zc702/xc7z010

ZC702にZephyrを移植できました。

DHCP

Zephyrのシェルを使ってDHCPを実行できます。

$ net ipv4 del 1 192.168.13.47

$ net dhcpv4 client start 1

$ net iface

実行すると以下のようなログが出力されます。

[00:00:45.867,000] <wrn> net_dhcpv4: DHCP server provided more DNS servers than can be saved

[00:00:45.867,000] <wrn> net_dhcpv4: DHCP server provided more DNS servers than can be saved

[00:00:45.867,000] <inf> net_dhcpv4: Received: 192.168.13.215

Default interface: 1

Interface eth0 (0x39560) (Ethernet) [1]

===================================

Link addr : DA:13:7A:1F:39:AC

MTU       : 1500

Flags     : AUTO_START,IPv4

Device    : ethernet@e000b000 (0x310d4)

Status    : oper=UP, admin=UP, carrier=ON

Ethernet capabilities supported:

        100 Mbits

        Promiscuous mode

Ethernet PHY device: <none> (0)

IPv4 unicast addresses (max 1):

        192.168.13.215/255.255.255.0 DHCP preferred

IPv4 multicast addresses (max 2):

        224.0.0.1

IPv4 gateway : 192.168.13.1

DHCPv4 lease time : 172800

DHCPv4 renew time : 86400

DHCPv4 server     : 192.168.13.1

DHCPv4 requested  : 192.168.13.215

DHCPv4 state      : bound

DHCPv4 attempts   : 1

DHCPv4 state      : bound

警告が出力されたり、「Ethernet PHY device」が「\<none\> (0)」になったりしていますが、Ethernetが動作するようになりました。

カーネルコンフィグ

アプリケーションのprj.confにネットワークの設定を追加します。

これでBSDソケット互換APIが利用できるようになりますが、このAPIは拡張されていて、簡単にTLSを利用できるようになっています。

CONFIG_MAIN_STACK_SIZE=2048

CONFIG_POSIX_API=y

CONFIG_NET_CONFIG_SETTINGS=y

CONFIG_NET_CONFIG_NEED_IPV4=y

CONFIG_NET_CONFIG_NEED_IPV6=n

CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.13.1"

CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

CONFIG_MBEDTLS_KEY_EXCHANGE_PSK_ENABLED=y

CONFIG_MBEDTLS=y

CONFIG_MBEDTLS_BUILTIN=y

CONFIG_MBEDTLS_ENABLE_HEAP=y

CONFIG_MBEDTLS_HEAP_SIZE=60000

CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=2048

アプリケーションソースコード

自己署名証明書を使うサーバーに接続するアプリケーションソースコードを書きます。

#include <stdio.h>

#include <zephyr/kernel.h>

#include <zephyr/logging/log.h>

#include <zephyr/net/socket.h>

#include <zephyr/net/tls_credentials.h>

LOG_MODULE_REGISTER(simple_tls, LOG_LEVEL_DBG);

int main(void)

{

    int ok = 0;

    int socket_ = -1;

   

    // ソケットを作成する

    {

        socket_ = socket(AF_INET, SOCK_STREAM, IPPROTO_TLS_1_2);

        if (socket_ < 0)

        {

            LOG_ERR("ERROR : socket : %d\n", errno);

            goto EXIT;

        }

       

        // 自己署名証明書のサーバーに接続する

        int verify = TLS_PEER_VERIFY_NONE;

        if (setsockopt(socket_, SOL_TLS, TLS_PEER_VERIFY, &verify, sizeof(verify)) < 0)

        {

            LOG_ERR("ERROR : setsockopt TLS_PEER_VERIFY : %d\n", errno);

            goto EXIT;

        }

    }

   

    // 接続する

    {

        struct sockaddr_in server = { 0 };

        server.sin_family = AF_INET;

        server.sin_port = htons(12345);

        inet_pton(AF_INET, "192.168.13.48", &server.sin_addr);

        if (connect(socket_, (struct sockaddr *)&server, sizeof(server)) < 0)

        {

            LOG_ERR("ERROR : connect : %d\n", errno);

            goto EXIT;

        }

    }

   

    // 送信する

    {

        char const * const message = "Hello from client";

        if (send(socket_, message, strlen(message) + 1, 0) < 0)

        {

            LOG_ERR("ERROR : send : %d\n", errno);

            goto EXIT;

        }

    }

   

    // 受信する

    while (1)

    {

        char message[128] = { 0 };

        int const return_value = recv(socket_, message, sizeof(message) - 1, 0);

        if (return_value < 0)

        {

            LOG_ERR("ERROR : recv : %d\n", errno);

            goto EXIT;

        }

        if (return_value == 0)

        {

            break;

        }

        else

        {

            LOG_INF("%s", message);

            continue;

        }

    }

   

    ok = 1;

    EXIT:

    // ソケットをクローズする

    if (socket_ != -1)

    {

        if (close(socket_) < 0)

        {

            LOG_ERR("ERROR : close : %d\n", errno);

            goto EXIT;

        }

    }

    LOG_INF("%s\n", ok ? "OK" : "NG");

    return 0;

}

実行

リビルドしたアプリケーションを実行すると、ユーザーが作成したアプリケーションコードが実行される前に、Zephyrが自動で諸々のネットワークの設定を行ってくれます。

*** Booting Zephyr OS build v4.1.0-5075-gcf6170cbe605 ***

[00:00:00.011,000] <wrn> net_sock_tls: No entropy device on the system, TLS communication is insecure!

[00:00:00.011,000] <inf> net_config: Initializing network

[00:00:00.011,000] <inf> net_config: Waiting interface 1 (0x51930) to be up...

[00:00:03.012,000] <inf> eth_xlnx_gem: ethernet@e000b000 link up, 100 MBit/s

[00:00:03.012,000] <inf> net_config: Interface 1 (0x51930) coming up

[00:00:03.012,000] <inf> net_config: Running dhcpv4 client...

[00:00:05.013,000] <wrn> net_dhcpv4: DHCP server provided more DNS servers than can be saved

[00:00:05.014,000] <wrn> net_dhcpv4: DHCP server provided more DNS servers than can be saved

[00:00:05.014,000] <inf> net_dhcpv4: Received: 192.168.13.215

[00:00:05.014,000] <inf> net_config: IPv4 address: 192.168.13.215

[00:00:05.014,000] <inf> net_config: Lease time: 172800 seconds

[00:00:05.014,000] <inf> net_config: Subnet: 255.255.255.0

[00:00:05.014,000] <inf> net_config: Router: 192.168.13.1

[00:00:05.072,000] <inf> simple_tls: Hello from server

[00:00:05.072,000] <inf> simple_tls: OK

ユーザーアプリケーションが実行され、TLSでメッセージの送受信ができました。

はじめに

2024年に大きな進展を見せ、成立・施行が目前に迫るEUサイバーレジリエンス法（Cyber Resilience Act: CRA）は、EU市場で流通する「デジタル要素を持つ製品（products with digital elements）」のサイバーセキュリティを強化するための包括的な法的枠組みです。本稿では、このCRAの概要、主要な規定、そして製造業者、輸入業者、販売業者、さらには消費者やサイバーセキュリティ市場全体に及ぼす多岐にわたる影響について詳細に解説します。特に、EU域外の企業、とりわけ日本企業が直面するであろう課題と取るべき対応策についても深く掘り下げ、今後の展望と残された課題を考察します。

近年の急速なデジタルトランスフォーメーション（DX）の進展は、私たちの生活や経済活動に多大な恩恵をもたらす一方で、サイバー攻撃のリスクをかつてないほど増大させています。特に、インターネットに接続されるIoT（Internet of Things）デバイスの爆発的な普及は、セキュリティの脆弱性を抱えた製品が市場に流通するリスクを高め、個人情報の漏洩、社会インフラの機能不全、経済的損失といった深刻な事態を引き起こす可能性をはらんでいます。

このような背景のもと、EUはサイバーセキュリティを経済安全保障の根幹と位置づけ、これまでにもNIS指令（ネットワークおよび情報システムのセキュリティに関する指令）やサイバーセキュリティ法（Cybersecurity Act）といった法整備を進めてきました。CRAは、これらの取り組みをさらに推し進め、製品ライフサイクルの初期段階（設計・開発）からセキュリティを組み込む「セキュリティ・バイ・デザイン（Security by Design）」の原則を法的に義務化し、製品の脆弱性への対応体制の構築、透明性の向上を通じて、EU域内のデジタル単一市場における信頼と安全の向上を目指すものです。

本稿は、CRAの複雑な規定内容を整理し、その影響範囲の広さと深さを明らかにすることで、関係者が適切な対応を準備するための一助となることを目的としています。

EUサイバーレジリエンス法の概要

CRAは、デジタル要素を持つ製品に関する統一的なサイバーセキュリティ要件を定めることで、EU市場の機能性を向上させ、消費者と企業双方の信頼を高めることを目的としています。以下にその主な特徴と構成要素を詳述します。

法的根拠と目的

CRAは、EUの製品安全規則の枠組みに基づいており、デジタル要素を持つ製品の自由な移動を確保しつつ、高度なサイバーセキュリティ水準を達成することを目指しています。主な目的は以下の通りです。

製品のライフサイクル全体を通じたセキュリティの確保

設計、開発、製造から廃棄に至るまでの全段階で、サイバーセキュリティ要件を満たすことを義務化します。

脆弱性管理の強化

製造業者に対し、製品の脆弱性を積極的に管理し、迅速に対応することを求めます。

透明性の向上

消費者やビジネスユーザーに対し、製品のセキュリティに関する情報を提供し、より安全な製品を選択できるよう支援します。

単一市場における調和

EU加盟国間で異なる規制が存在することによる市場の分断を防ぎ、統一されたルールを適用します。

適用範囲

CRAは、「デジタル要素を持つ製品」の製造業者、輸入業者、販売業者に適用されます。この「デジタル要素を持つ製品」とは、広義に解釈され、意図された用途において、データ処理を可能にするソフトウェアまたはハードウェアコンポーネントを直接的または間接的に接続するもの、またはそれ自体がそのようなコンポーネントである製品を指します。

具体的には、以下のような製品が対象となり得ます。

ハードウェア製品

スマートフォン、タブレット、PC、ルーター、モデム、IoTデバイス（スマート家電、ウェアラブルデバイス、産業用センサーなど）、ネットワーク機器、産業制御システム（ICS）コンポーネントなど。

ソフトウェア製品

オペレーティングシステム、ファームウェア、アプリケーションソフトウェア、モバイルアプリ、組み込みソフトウェアなど。ただし、SaaS（Software as a Service）のような継続的なサービス提供型のソフトウェアは、NIS2指令やDORA（Digital Operational Resilience Act）など他の法規制の対象となる場合があり、CRAの直接的な適用範囲からは一部除外される可能性がありますが、製品に組み込まれるソフトウェアや、製品の機能を決定づけるソフトウェアは対象となります。

オープンソースソフトウェア

商用活動の一環として提供されるオープンソースソフトウェアも、CRAの対象となる可能性があり、この点は法案策定過程で大きな議論を呼びました。最終的には、重要な製品や、製品のセキュリティ機能に不可欠なオープンソースコンポーネントを提供する法人は、CRAの義務を負うことになりました。

主な義務

CRAは、経済主体（製造業者、輸入業者、販売業者）に対して、製品のライフサイクル全体を通じた様々な義務を課します。

製造業者の義務

セキュリティ・バイ・デザインとデフォルトでのセキュリティ

製品の設計・開発段階からサイバーセキュリティリスクを評価し、適切な対策を講じること。出荷時には、デフォルトで安全な設定になっていること。

脆弱性管理プロセス

製品の市場投入後、発見された脆弱性を効果的に処理するためのプロセスを確立し、維持すること。これには、脆弱性の特定、分析、修正、ユーザーへの通知が含まれます。

情報提供と指示

製品のセキュリティ機能、安全な使用方法、脆弱性情報の入手方法などをユーザーに明確に提供すること。

適合性評価

製品がCRAの要件を満たしていることを示すための適合性評価手続きを実施し、EU適合宣言書を作成すること。

CEマーキング

適合性評価をクリアした製品にCEマークを付すこと。

脆弱性の報告

発見された脆弱性やインシデントについて、ENISA（欧州ネットワーク・情報セキュリティ機関）に24時間以内に報告する義務があります。

最低5年間のサポート

製品の市場投入後、少なくとも5年間（または製品の期待寿命まで）、セキュリティアップデートを提供し、脆弱性に対応する義務があります。

輸入業者の義務

EU域内に持ち込む製品がCRAの要件に適合していることを確認する義務。
製造業者が適切な適合性評価手続きを行い、技術文書を作成し、CEマークを付していることを確認する。
製品が安全でないと判断した場合、市場への提供を中止し、関係当局に通知する。
自身の名称、登録商号または登録商標、連絡先住所を製品に表示する。

販売業者の義務

製品を取り扱う際に、CRAの要件に注意を払う義務。
製品にCEマークが付され、必要な文書が添付されていることを確認する。
製品が安全でないと判断した場合、市場への提供を中止し、関係当局に通知する。

製品の分類と適合性評価

CRAは、製品のサイバーセキュリティリスクに応じて、製品をいくつかのクラスに分類し、異なる適合性評価手続きを要求します。

デフォルト（一般）クラス

リスクが低いと見なされる製品。製造業者は自己評価により適合性を宣言できます。

クリティカルクラスIおよびII

リスクが高いと見なされる製品。ルーター、ファイアウォール、産業用制御システム、スマートメーターなどが該当する可能性があります。これらの製品については、第三者機関（Notified Body）による適合性評価が必要となる場合があります。

適合性評価には、内部統制に基づく評価、EU型式審査、品質マネジメントシステムに基づく評価など、モジュールに応じた手続きが定められています。

市場監視と執行

EU加盟国の市場監視当局は、CRAの遵守状況を監督し、違反行為に対して是正措置や罰則を科す権限を持ちます。ENISAは、脆弱性情報の収集・分析、加盟国間の協力促進、ガイドライン策定など、中心的な役割を担います。

罰則は高額になる可能性があり、例えば、CRAの必須要件への違反に対しては、全世界の年間総売上高の最大1500万ユーロまたは2.5％のいずれか高い方が科される可能性があります。情報提供義務違反など、その他の違反に対しても、それぞれ罰金の上限が設定されています。

施行スケジュール

CRAは、EU官報に掲載されてから20日後に発効します。その後、多くの規定は段階的に適用が開始されます。

発効から21ヶ月後(2026年9月11日): 製造業者による脆弱性およびインシデントの報告義務が適用開始。
発効から36ヶ月後(2027年12月11日): その他のほとんどの義務が適用開始。

このスケジュールは、企業がCRAの複雑な要件に対応するための準備期間を考慮したものです。

EUサイバーレジリエンス法が及ぼす広範な影響

CRAの施行は、EU域内外の様々なステークホルダーに対し、広範囲かつ深遠な影響を及ぼすことが予想されます。本章では、企業（特に製造業者）、消費者、サイバーセキュリティ市場、そして国際関係への影響を詳細に分析します。

企業への影響

CRAは、デジタル要素を持つ製品を扱うあらゆる企業、特に製造業者にとって、事業戦略、製品開発プロセス、コスト構造、サプライチェーン管理に至るまで、抜本的な見直しを迫るものです。

製造業者（EU域内および域外）への影響

製品開発・設計プロセスの変革

• セキュリティ・バイ・デザイン／デフォルトの徹底

これまでアドオン的に対応されることの多かったセキュリティ対策を、製品の企画・設計段階から不可欠な要素として組み込む必要があります。脅威モデリング、リスクアセスメント、セキュアコーディング、脆弱性テストといった活動が、開発ライフサイクルの初期から体系的に実施されるようになります。

• ソフトウェア部品表（SBOM）の導入促進

製品に含まれるソフトウェアコンポーネント（オープンソースを含む）を網羅的に把握し、それぞれの脆弱性を管理するために、SBOMの作成と維持が事実上不可欠となります。CRAはSBOMの提供を直接的に義務付けているわけではありませんが、脆弱性管理義務を果たす上で極めて有効な手段となります。

• デフォルトでのセキュアな設定

製品出荷時の設定が、ユーザーによる追加設定なしに最大限のセキュリティを提供するように構成される必要があります。例えば、推測しやすいデフォルトパスワードの廃止、不要なポートの無効化などが求められます。

ライフサイクル全体を通じた脆弱性管理体制の構築

• 継続的な脆弱性監視と対応

製品出荷後も、新たに発見される脆弱性情報を継続的に収集・分析し、迅速に修正パッチを開発・提供する体制を構築・維持する必要があります。これには、専門チームの設置や外部サービスの活用が考えられます。

• ENISAへの報告義務

重大な脆弱性やインシデントを発見した場合、24時間以内にENISAおよび関係各国のCSIRT（Computer Security Incident Response Team）に報告する義務が生じます。これは、インシデント対応プロセスの迅速化と透明性の確保を求めるものです。

• 最低5年間のセキュリティサポート

製品の市場投入後、最低5年間（または製品の期待耐用年数）はセキュリティアップデートを提供し、脆弱性に対応する義務が生じます。これは、製品のライフサイクルが長期化するIoTデバイスなどにとって、特に大きな負担となる可能性があります。

コスト増への対応

• 開発コストの増加

セキュリティ専門家の雇用や育成、新たな開発ツールやプロセスの導入、第三者機関による評価などにより、製品開発コストが増加します。

• 適合性評価コスト

特にクリティカルクラスに分類される製品については、第三者機関による適合性評価が必要となり、その費用負担が発生します。

• 脆弱性管理コスト

継続的な脆弱性監視、パッチ開発、インシデント対応、ユーザーへの通知など、製品出荷後の管理コストも増加します。

• ドキュメント作成・維持コスト

技術文書、適合宣言書、ユーザー向け情報などの作成と適切な管理にもコストがかかります。

サプライチェーン全体でのセキュリティ確保

• コンポーネント供給元の選定基準の変化

自社製品に組み込むハードウェア・ソフトウェアコンポーネントの供給元に対しても、CRAへの適合性やセキュリティ体制の確認が求められるようになります。サプライヤーとの契約内容の見直しや、セキュリティ監査の実施が必要となる場合があります。

• サプライチェーンの透明性向上

製品のセキュリティは、最も脆弱なコンポーネントに左右されるため、サプライチェーン全体での情報共有と連携が不可欠です。

中小企業（SME）への影響

• リソースと専門知識の不足

中小企業にとっては、CRAが要求する高度なセキュリティ体制の構築や専門知識の獲得、適合性評価の実施などが大きな負担となる可能性があります。資金調達、人材確保、情報収集といった面で課題に直面しやすく、競争上の不利が生じる懸念があります。

• 支援策の必要性

EUや各国政府による、中小企業向けのガイドライン提供、技術支援、資金援助などの支援策が重要となります。

競争環境の変化

• セキュリティが競争優位性の源泉に

CRAへの適合は、単なるコンプライアンス対応に留まらず、製品の信頼性や安全性をアピールする要素となり得ます。セキュリティを重視する企業にとっては、市場での競争優位性を確立する好機となる可能性があります。

• 市場からの排除リスク

CRAの要件を満たせない企業は、EU市場へのアクセスが制限されたり、最悪の場合は市場から排除されたりするリスクがあります。

イノベーションへの影響

• 短期的な制約の可能性

厳格なセキュリティ要件や適合性評価手続きが、製品開発のスピードを遅らせたり、新しい技術やアイデアの導入を躊躇させたりする可能性が指摘されています。

• 長期的なイノベーション促進

一方で、セキュアな製品開発が標準化されることで、ユーザーの信頼が高まり、長期的には新たなデジタル技術やサービスの普及を後押しし、イノベーションを促進するという見方もあります。セキュリティを前提とした新しいビジネスモデルが生まれる可能性も期待されます。

グローバル市場への影響（ブリュッセル効果）

• 事実上の国際標準となる可能性

EUは巨大な経済圏であり、CRAがEU市場でビジネスを行う企業にとっての必須要件となることで、EU域外の企業もCRAに準拠した製品開発を行うようになり、結果としてCRAがサイバーセキュリティに関する事実上の国際標準（デファクトスタンダード）となる「ブリュッセル効果」が期待されています。これにより、グローバルレベルでの製品セキュリティの底上げが図られる可能性があります。

• 日本企業への直接的な影響

EU市場にデジタル要素を持つ製品を輸出している、あるいは将来的に輸出を計画している日本企業は、CRAの要件を遵守する必要があります。これは、自動車、家電、産業機械、医療機器、ソフトウェアなど、幅広い分野の日本企業に影響を及ぼします。

輸入業者・販売業者への影響

コンプライアンス確認義務の強化

輸入業者は、EU市場に製品を投入する前に、製造業者がCRAの義務（適切な適合性評価、技術文書の作成、CEマーキングなど）を果たしていることを確認する責任を負います。この確認を怠った場合、輸入業者自身が法的責任を問われる可能性があります。

サプライヤー管理の重要性

信頼できる製造業者を選定し、そのコンプライアンス状況を継続的に監視する必要性が高まります。

情報伝達の役割

製造業者から提供されるセキュリティ情報を正確に把握し、必要に応じて販売業者や最終顧客に伝達する役割が求められます。

不適合製品への対応

市場で不適合な製品を発見した場合、速やかに市場からの回収や関係当局への報告を行う義務があります。

販売業者も同様に、取り扱う製品がCRAの基本的な要件（CEマーキング、必要なドキュメントの添付など）を満たしているかを確認する注意義務を負います。

ソフトウェア開発者（特にオープンソースソフトウェア）への影響

CRAのオープンソースソフトウェア（OSS）への適用は、法案策定段階で最も議論を呼んだ点の一つです。最終的な条文では、完全に非営利で開発・提供されるOSSはCRAの直接的な義務の対象外となる一方で、「商用活動（commercial activity）」の一環として提供されるOSSは、その開発主体がCRAの製造業者としての義務を負うことになりました。

「商用活動」の解釈

何が「商用活動」に該当するかの解釈が重要となります。例えば、企業が開発を主導し、有償サポートや関連サービスと共に提供しているOSS、あるいは企業が自社製品の重要なコンポーネントとして開発・提供しているOSSなどが対象となる可能性があります。OSSプロジェクトをホストする財団なども、その運営方法や資金調達方法によっては、CRAの義務を負う主体と見なされる可能性があります。

OSSコミュニティへの影響

• 開発プロセスの変更

CRAの対象となるOSSプロジェクトは、セキュア開発ライフサイクル（SDL）の導入、脆弱性管理プロセスの確立、ドキュメント作成といった対応が必要となり、開発プロセスや体制の変更を迫られる可能性があります。

• 貢献者への影響

個々のコントリビューターに直接的な法的義務が課されるわけではありませんが、プロジェクト全体のコンプライアンス体制が強化される中で、コードの品質やセキュリティへの意識向上が求められるでしょう。

• OSSの利用企業への影響

OSSを利用する企業は、利用するOSSコンポーネントがCRAの対象となるか、また、開発元が適切に対応しているかを確認する必要性が生じます。SBOMの活用が一層重要になります。

• 懸念と期待

一部のOSSコミュニティからは、CRAがOSSの自由な開発やイノベーションを阻害するのではないかという懸念も表明されています。一方で、OSSのセキュリティと信頼性が向上し、企業がより安心してOSSを活用できるようになるという期待もあります。EUは、OSSコミュニティへの影響を考慮し、CRAの適用に関するガイドライン等で明確化を図っていくものと思われます。

消費者への影響

CRAは、消費者にとって多くのメリットをもたらすことが期待されます。

製品のセキュリティ向上

市場に流通する製品のセキュリティレベルが全体的に向上し、マルウェア感染、個人情報漏洩、不正アクセスといったリスクが低減します。

透明性の向上と情報に基づいた選択

製造業者は製品のセキュリティ機能やサポート期間に関する情報提供を義務付けられるため、消費者はより多くの情報を基に、安全な製品を選択できるようになります。

脆弱性への迅速な対応

製造業者による脆弱性管理と迅速なアップデート提供が義務化されることで、製品購入後も長期間にわたり安心して製品を使用できるようになります。

信頼性の向上

CEマーキングは、製品がEUの基本的なサイバーセキュリティ要件を満たしていることを示す一つの目安となり、消費者の信頼を高めます。

長期的なコスト削減の可能性

サイバー攻撃による被害からの復旧コストや、セキュリティ対策が不十分な製品を買い替えるコストなどが削減される可能性があります。
ただし、製品価格への転嫁や、一部のニッチな製品が市場から姿を消すといった可能性もゼロではありません。

サイバーセキュリティ市場への影響

CRAは、サイバーセキュリティ関連の製品やサービス市場に大きな変化をもたらし、新たなビジネスチャンスを生み出すと予想されます。

セキュリティ関連サービス・製品の需要急増

コンサルティングサービス

CRAへの対応支援（ギャップ分析、体制構築、ドキュメント作成支援など）

適合性評価・監査サービス

第三者機関による評価、内部監査支援

脆弱性診断・ペネトレーションテストサービス

• 製品の脆弱性検査
• セキュア開発ライフサイクル（SDL）導入支援ツール・サービス
• SBOM作成・管理ツール
• 脅威インテリジェンスサービス
• インシデント対応支援サービス
• セキュリティ人材育成・トレーニングサービス

新たな技術やソリューションの開発促進

CRAの要件を満たすための新しいセキュリティ技術や、コンプライアンスを効率化するソリューションの開発が活発化するでしょう。

市場の成熟と専門性の向上

サイバーセキュリティ市場全体の専門性が高まり、より高度で信頼性の高いサービスが求められるようになります。

認証ビジネスの拡大

適合性評価を行うノーティファイドボディ（Notified Body）の役割が重要となり、関連する認証ビジネスが拡大する可能性があります。

国際関係への影響

CRAは、EU域内にとどまらず、国際的な貿易やサイバーセキュリティ政策にも影響を与える可能性があります。

ブリュッセル効果の顕在化

前述の通り、EU市場の規模と影響力から、CRAがデジタル製品のサイバーセキュリティに関するグローバルスタンダードとなる可能性があります。EUに製品を輸出する多くの国や企業が、CRAの基準に準拠する動きを見せることで、世界的なサイバーセキュリティレベルの底上げが期待されます。

国際的な標準化への影響

CRAの要件が、ISOやIECといった国際標準化機関における議論に影響を与え、新たな国際標準の策定を促す可能性があります。

貿易摩擦の可能性

一部の国や企業からは、CRAが非関税障壁として機能し、自由な貿易を阻害するとの懸念が示される可能性もあります。特に、CRAの要件への対応が困難な開発途上国の企業にとっては、EU市場へのアクセスが難しくなるかもしれません。

各国における同様の法規制導入の動き

EUの先進的な取り組みに追随し、各国で同様のサイバーセキュリティ規制を導入する動きが加速する可能性があります。日本においても、経済産業省などがCRAの動向を注視しており、国内法整備の参考とする動きが見られます。

日本企業が取るべきEUサイバーレジリエンス法への対応策

EU市場でビジネスを展開する、あるいは将来的に目指す日本企業にとって、CRAへの対応は避けて通れない課題です。以下に、日本企業が取るべき具体的なステップと考慮事項を提示します。

現状分析とギャップ分析の実施

自社製品のCRA適用範囲の確認

自社が製造・販売する製品の中に、CRAの定義する「デジタル要素を持つ製品」に該当するものがどれだけあるか、正確に把握します。ハードウェアだけでなく、製品に組み込まれるソフトウェアや、単体で提供されるソフトウェアも対象となる点に注意が必要です。

現在のセキュリティ対策とCRA要件との比較

設計・開発プロセス、脆弱性管理体制、情報提供の仕組みなど、CRAが要求する項目と自社の現状を比較し、ギャップを明確にします。

製品のリスク分類の特定

自社製品がCRAのどのリスククラス（デフォルト、クリティカルI、クリティカルII）に該当するかを評価します。これにより、必要な適合性評価手続きが異なります。

サプライチェーンの確認

製品に使用しているサードパーティ製のコンポーネント（ハードウェア、ソフトウェア、OSS）の供給元や、そのセキュリティ体制についても把握し、リスクを評価します。

セキュリティ体制の構築・強化

セキュリティ・バイ・デザイン／デフォルトの導入

• 製品開発ライフサイクル（SDLC）にセキュリティ活動を統合する（セキュアSDLCの確立）。
• 開発の初期段階からの脅威モデリング、リスクアセスメントの実施。
• セキュアコーディング標準の策定と徹底、開発者への教育。
• 設計レビュー、コードレビューにおけるセキュリティ観点の強化。
• 脆弱性テスト（静的解析、動的解析、ファジング、ペネトレーションテストなど）の体系的な実施。

脆弱性管理プロセスの確立と運用

• 製品出荷後の脆弱性情報を収集・監視する仕組み（社内、外部情報源、ユーザーからの報告など）の構築。
• 発見された脆弱性の深刻度評価、トリアージ、修正対応、テスト、パッチリリースのプロセスを定義し、実行する専門チーム（PSIRT: Product Security Incident Response Teamなど）の設置または機能強化。
• 脆弱性情報をユーザーに適切に開示するためのポリシーと手順の策定。
• ENISAへの24時間以内の報告体制の整備。

ソフトウェア部品表（SBOM）の作成と管理

製品に含まれる全てのソフトウェアコンポーネントをリスト化し、バージョン情報やライセンス情報と共に管理する体制を整備します。SBOMは、脆弱性管理やサプライチェーンリスク管理の基礎となります。

インシデント対応計画の策定と訓練

サイバー攻撃や重大な脆弱性が発見された場合の対応手順を明確にし、定期的な訓練を通じて実効性を高めます。

ドキュメント作成と情報提供体制の整備

技術文書の作成と維持

CRAが要求する技術文書（設計資料、リスクアセスメント結果、テストレポート、脆弱性管理プロセスの説明など）を整備し、製品のライフサイクルを通じて最新の状態に維持します。

EU適合宣言書の作成

適合性評価手続きを完了した後、製品がCRAの要件に適合していることを示すEU適合宣言書を作成します。

ユーザー向け情報の提供

製品の意図された用途、セキュリティ機能、安全な設定方法、脆弱性情報の入手方法、サポート期間、セキュリティアップデートの提供方法などを、明確かつ理解しやすい形でユーザーに提供します。取扱説明書やウェブサイトなどを活用します。

サプライチェーン管理の見直し

サプライヤーに対するセキュリティ要求事項の明確化

部品やソフトウェアを供給するサプライヤーに対し、CRAへの適合性やセキュリティ体制に関する要求事項を明確に伝え、契約に盛り込むことを検討します。

サプライヤーの監査・評価

サプライヤーのセキュリティ体制や開発プロセスを評価し、必要に応じて監査を実施します。

OSSの利用ポリシー策定

商用利用するOSSについて、CRAの適用可能性を評価し、脆弱性管理体制が確立されているか、ライセンス条件は遵守されているかなどを確認するプロセスを整備します。

法務・コンプライアンス部門との連携強化

CRAの法規制内容を正確に理解し、社内規程やプロセスへの反映を進めます。
契約書（顧客向け、サプライヤー向け）にCRA関連の条項を盛り込むことを検討します。
市場監視当局からの問い合わせや、インシデント発生時の法的対応に備えます。

従業員教育と意識向上

開発者、製品管理者、品質保証担当者、営業担当者など、関連する全部門の従業員に対し、CRAの概要と自社への影響、各自の役割について教育を実施します。
サイバーセキュリティに関する意識を全社的に高め、セキュアな製品開発・提供が企業文化として根付くよう取り組みます。

専門家（コンサルタント、認証機関など）の活用

CRAへの対応には高度な専門知識が要求されるため、必要に応じて外部のコンサルタントやセキュリティ専門企業の支援を受けることを検討します。
クリティカルクラスの製品については、ノーティファイドボディ（認証機関）との連携が必須となります。早期にコンタクトを取り、適合性評価の準備を進めます。

業界団体や関連省庁との情報連携

業界団体が主催するセミナーやワーキンググループに参加し、CRAに関する最新情報や他社の対応事例を収集します。
経済産業省や総務省、情報処理推進機構（IPA）などが発信する情報を注視し、必要に応じて相談や支援を求めます。

今後の展望と課題

CRAは、デジタル化が進む現代社会において、サイバーセキュリティの重要性を改めて浮き彫りにし、製品の安全性を向上させるための画期的な試みと言えます。しかし、その施行と運用にはいくつかの展望と課題が存在します。

施行に向けた準備と円滑な移行

ガイドラインと標準化の進展

EU委員会やENISAは、CRAの具体的な運用に関する詳細なガイドラインや、関連する技術標準の整備を進めることになります。これらの情報が早期に、かつ明確に提供されることが、企業の円滑な対応には不可欠です。特に、中小企業やOSSコミュニティへの配慮が求められます。

ノーティファイドボディの体制整備

クリティカルクラス製品の適合性評価を担うノーティファイドボディの数や能力が、需要に対して十分であるかどうかが課題となります。体制整備が遅れれば、製品の市場投入に遅延が生じる可能性があります。

企業側の対応期間

CRAの多くの規定が適用開始となるのは発効から36ヶ月後ですが、製品開発サイクルやサプライチェーンの複雑さを考慮すると、決して十分な時間とは言えません。企業は早期に対応準備に着手する必要があります。

技術の進展と法規制の整合性

AI、機械学習、量子コンピューティングなどの新技術への対応

AI搭載製品や、将来的に量子コンピューティング技術を活用した製品など、新たなテクノロジーが登場する中で、CRAがそれらの特性に応じた適切なセキュリティ要件をカバーできるか、継続的な見直しとアップデートが必要となるでしょう。

ソフトウェアの進化の速さへの追随

ソフトウェアは常に進化し、新たな脆弱性が発見されるため、法規制が技術の進歩に遅れを取らないようにするための仕組みが重要です。

国際的な協調と調和の推進

グローバルな基準としての受容

CRAが「ブリュッセル効果」を発揮し、事実上の国際標準となるためには、EU域外の国々との対話と協力が不可欠です。相互認証の仕組みや、各国の規制との整合性を図る努力が求められます。

貿易障壁とならないための配慮

CRAが過度な負担となり、特に開発途上国の企業のEU市場へのアクセスを不当に制限する結果とならないよう、国際的な議論を通じて調整が行われることが期待されます。

残された課題と懸念点

中小企業への過度な負担

支援策が講じられるとしても、中小企業がCRAの要求に完全に対応することの困難さは依然として残ります。イノベーションの担い手である中小企業の活力を損なわないような運用が求められます。

OSSコミュニティとの建設的な対話

OSSへの影響については、今後も議論が続くと予想されます。OSSの持つオープン性やイノベーションの力を損なうことなく、セキュリティを向上させるためのバランスの取れたアプローチが必要です。

執行体制の均一性と実効性

EU加盟国間での市場監視や罰則の適用にばらつきが生じないよう、ENISAを中心とした連携強化と、実効性のある執行体制の確立が重要です。

「セキュリティ」と「イノベーション」のバランス

過度な規制がイノベーションを阻害するという懸念は常に存在します。CRAがセキュリティ向上に貢献しつつも、自由な発想や迅速な製品開発を過度に抑制しないような、適切なバランスを見出すことが長期的な課題となります。

まとめ：サイバーレジリエンス新時代への備え

EUサイバーレジリエンス法（CRA）は、デジタル製品のセキュリティ基準を大幅に引き上げ、EU市場における信頼性と安全性を向上させることを目的とした、野心的かつ包括的な規制です。その影響はEU域内にとどまらず、グローバルなサプライチェーン全体に及び、特にEU市場に製品を提供する日本企業にとっては、事業戦略の根幹に関わる重要な変化となります。

CRAが要求するセキュリティ・バイ・デザインの原則、ライフサイクル全体を通じた脆弱性管理、透明性の向上といった取り組みは、短期的には企業にとってコスト増となる側面があるものの、長期的には製品の競争力強化、ブランドイメージの向上、そして何よりもユーザーからの信頼獲得に繋がるものです。

日本企業は、CRAの動向を座して待つのではなく、これを自社の製品セキュリティと開発プロセスを見直し、強化する好機と捉え、早期に具体的な対応に着手することが求められます。現状分析から始め、セキュリティ体制の構築、サプライチェーン管理の見直し、そして全社的な意識改革を進めることが、このサイバーレジリエンス新時代を乗り切るための鍵となるでしょう。

CRAは、サイバー空間における安全・安心の実現に向けた大きな一歩であり、その成否は、規制当局、企業、そして我々一人ひとりの取り組みにかかっています。この新たな法的枠組みが、より安全で信頼性の高いデジタル社会の実現に貢献することを期待し、本稿がその一助となれば幸いです。

クラウドサービスの信頼を高める「FedRAMP」とは？

FedRAMPとは何か？

近年、政府機関においてもクラウドサービスの導入が加速しています。しかし、そこに求められるのは「利便性」だけではありません。機密性の高い情報を扱う以上、「セキュリティ」と「信頼性」は何よりも重視されるべき要素です。そこで登場するのが FedRAMP（Federal Risk and Authorization Management Program）――米国政府が定める、クラウドサービスに対する統一的なセキュリティ認証プログラムです。

FedRAMPの概要

FedRAMPは、2011年に米国政府のCIO評議会（Chief Information Officers Council）によって設立されました。その目的は、政府機関がクラウドサービスを安全かつ効率的に導入できるようにするための標準化されたセキュリティ評価プロセスを提供することです。

従来、各機関が独自にベンダーを評価していたため、コストや時間がかかり、重複作業が発生していました。FedRAMPはそれを一元化し、クラウドサービスプロバイダー（CSP）が一度認証を取得すれば、複数の政府機関で再利用可能な「認定済み」となるというメリットがあります。

FedRAMP認証のレベル

FedRAMPにはクラウドサービスの扱う情報の「機密度」に応じた3つのインパクトレベルが定義されています。

• Low（低）：公開情報など、損害が小さい情報を対象

• Moderate（中）：個人情報や業務情報など、損害が中程度の情報

• High（高）：国家安全保障や重要インフラに関わる、高度な機密情報

この分類に基づき、クラウドサービスはNIST SP 800-53（米国国立標準技術研究所が定めたセキュリティ基準）に準拠したセキュリティコントロールを実装し、第三者機関（3PAO）による評価を受ける必要があります。

FedRAMP取得のプロセス

FedRAMP認証を取得するには、主に2つの方法があります。

1. JAB P-ATO（Joint Authorization Board Provisional Authorization）
   　米国政府の主要3機関（DoD、GSA、DHS）による認定。影響力が高く、多くの機関で採用されやすいが、審査も厳格。

2. Agency ATO（Agency Authority to Operate）
   　個別の政府機関がCSPと直接契約し、評価・認可を行う方法。比較的柔軟性があるが、他機関への再利用には限りがある。

製造業におけるFedRAMP取得ステップ

【STEP 0】準備段階：取得の要否を明確にする

• 自社のクラウドサービスが米国政府機関向けかどうかを確認

• 対象システム（例：クラウド型IoT管理プラットフォーム）がFedRAMPの適用範囲にあるか確認

• 「Low」「Moderate」「High」どのインパクトレベルに該当するか判定

【STEP 1】社内体制とパートナーの選定

• FedRAMP対応のためのセキュリティ・認証チームの立ち上げ

• 以下の外部支援先を選定

  • コンサルタント（FedRAMP支援経験あり）

  • 3PAO（第三者評価機関）

【STEP 2】システム設計・セキュリティ文書作成

FedRAMPでは膨大な文書と詳細な設計が求められます。

必要な主な文書

• System Security Plan（SSP）：システムの構成、制御策、運用方針などの詳細

• Policies & Procedures：アクセス制御、変更管理、インシデント対応など

• Contingency Plan（CP）

• Configuration Management Plan（CMP）

セキュリティ要件の実装

• NIST SP 800-53（Rev.5）ベースの制御策に対応

• 製造業に特有のインターフェース（例：OT-IT連携部分、SCADAデータのクラウド送信）にも対応策を準備

【STEP 3】3PAOによる初期評価（セキュリティ評価）

• Pre-Assessment（事前評価）

• Security Assessment Plan（SAP）作成

• ペネトレーションテスト、脆弱性スキャン、構成チェックなどを実施

• 結果はSecurity Assessment Report（SAR）として提出

【STEP 4】FedRAMPへの申請（JABまたはAgencyルート）

• JABルート：JAB選定の対象に選ばれれば、広く展開できる（ただし競争が激しい）

• Agencyルート：製造業でよくあるのはこちら。すでに契約中の連邦政府機関があれば、その支援で申請可

【STEP 5】認可取得（Authorization to Operate：ATO）

• 全書類と評価結果を提出し、ATO（運用認可）を取得

• FedRAMP Marketplaceにサービスが掲載される

【STEP 6】継続的モニタリング（Continuous Monitoring）

• 月次・四半期・年次で以下を提出

  • セキュリティスキャン結果（OS・DB・Web等）

  • POA&M（Plan of Actions and Milestones）

  • 変更管理ログ

• インシデント対応報告義務あり

FedRAMPがもたらすメリット

• 政府調達のハードルをクリア
  　米国連邦政府機関との契約において、FedRAMPはほぼ必須条件です。

• セキュリティの信頼性が向上
  　NIST準拠の厳格な基準を満たすことで、セキュリティへの信頼性が高まります。

• 市場競争力の向上
  　一度の取得で複数機関への導入が可能になり、展開の効率が飛躍的にアップします。

日本企業への影響と展望

FedRAMPは米国内の制度ですが、米国市場に進出する日本企業や、政府系プロジェクトを対象としたSaaSプロバイダーにとっては、事実上の「パスポート」となる認証です。また、近年ではFedRAMPを参考にしたセキュリティ評価制度が、他国や民間でも導入されつつあり、国際的なセキュリティ基準としても存在感を増しています。

まとめ

FedRAMPは単なる「認証制度」ではなく、クラウド活用における信頼とセキュリティの保証を担保する重要な仕組みです。クラウドサービスが社会インフラとして定着する中、FedRAMPは今後さらに注目されるキーワードとなるでしょう。

StateRAMP: クラウドセキュリティ認証の新たな標準

近年、クラウドサービスの普及とともに、政府機関が利用するクラウドソリューションのセキュリティ確保が重要な課題となっています。米国では連邦政府向けのクラウドセキュリティ基準としてFedRAMP（Federal Risk and Authorization Management Program）が広く知られていますが、州政府や地方自治体にも適用可能なセキュリティフレームワークとして「StateRAMP」が登場しました。本コラムでは、StateRAMPの概要や目的、メリット、適用プロセスについて詳しく解説します。

StateRAMPとは？

StateRAMP（State Risk and Authorization Management Program）は、州政府および地方自治体が利用するクラウドサービスのセキュリティ基準を統一し、リスク管理を強化するためのフレームワークです。2020年に設立されたStateRAMPは、FedRAMPをモデルにしつつ、州および地方政府のニーズに対応できるように調整されています。クラウドプロバイダーはStateRAMPの認証を取得することで、複数の州政府や自治体に対してセキュアなサービス提供が可能になります。

StateRAMPの目的

StateRAMPの主な目的は、州政府および地方自治体におけるクラウドセキュリティの標準化と効率的なリスク管理です。具体的には、以下のような目的を掲げています。

1. クラウドセキュリティの向上: 統一されたセキュリティ基準を適用することで、州政府が利用するクラウドソリューションの安全性を高める。
2. リスク管理の一元化: 既存のセキュリティ評価を活用し、州政府間で情報を共有することで、セキュリティ評価の重複を避ける。
3. ベンダーの負担軽減: FedRAMPと共通の要件を持つことで、クラウドサービスプロバイダーが複数の政府機関向けに同一の基準を満たすことを容易にする。
4. 調達プロセスの効率化: 認証済みのクラウドサービスを利用することで、政府機関の調達プロセスを迅速化する。

StateRAMPのメリット

StateRAMPに準拠することで、政府機関とクラウドサービスプロバイダーの双方に多くのメリットが生まれます。

政府機関のメリット

• セキュリティの確保: 高水準のセキュリティ基準に基づいたクラウドサービスの導入が可能。
• コスト削減: 事前認証されたサービスを利用することで、個別のセキュリティ評価にかかるコストを削減。
• 迅速な導入: 既に認証を受けたサービスを活用することで、クラウドソリューションの導入スピードが向上。

クラウドサービスプロバイダーのメリット

• 市場アクセスの拡大: StateRAMP認証を取得することで、複数の州政府および自治体向けにサービス提供が可能。
• 認証の一元化: FedRAMPと類似の要件を持つため、連邦および州政府の両方に対応可能。
• 競争力の向上: セキュリティ基準を満たしていることを証明することで、競合他社との差別化が可能。

StateRAMPの認証プロセス

StateRAMPの認証プロセスは、FedRAMPと同様に、クラウドサービスプロバイダーがセキュリティ要件を満たしていることを証明するための手順を踏みます。

1. 登録（Registration）: クラウドサービスプロバイダーはStateRAMPに登録し、申請プロセスを開始。
2. 評価（Assessment）: 第三者評価機関（3PAO）が、サービスのセキュリティ対策を評価。
3. 承認（Authorization）: 評価結果をもとに、StateRAMPの運営組織または州政府が承認を行う。
4. 継続的なモニタリング（Continuous Monitoring）: 承認後も定期的な監査やセキュリティ評価を実施し、基準を維持。

StateRAMPとFedRAMPの違い

StateRAMPはFedRAMPと多くの共通点を持ちながらも、州政府および地方自治体向けに最適化されています。主な違いは以下の通りです。

まとめ

FedRAMPとStateRAMPは、どちらも政府機関向けのクラウドセキュリティ認証プログラムですが、対象機関が異なります。基本的なセキュリティ基準は共通していますが、州政府や地方自治体向けのStateRAMPは、より柔軟な認証体系を採用しています。

次回はFedRAMPにスポットを当てたコラムを予定しております。

RED 委任指令 (RED-DA) 整合規格の制限についてのお知らせ

RED 委任指令 (RED-DA) 整合規格について

この度、EU (欧州連合) において無線機能のある機器を販売しているお客様に対し、Commission Implementing Decision (EU) 2025/138が発効され、RED-DAの整合規格であるEN 18031-1、EN 18031-2、EN 18031-3の適用が変更された事について、以下の通りご案内申し上げます。

EN 18031-1、EN 18031-2、EN 18031-3は、制限付きで整合規格として扱われることになります。これは、これらの規格が特定分野において適合性を推定するものではないことを意味し、製造業者は完全な適合性を保証するためにNotified Bodyによる第三者検証を行う必要があります。

詳細は以下のコラムを確認ください。

RED-DA(欧州無線機器指令委託令)の整合規格指定について

Windows、Android、FireOS を使用している無線機器について

Windows、Android、FireOS などのオペレーティングシステム (OS) を搭載した無線機器は、RED-DA の対象となる場合があります。またこれらの OS は、ストア機能などで金銭等を取り扱うことが可能かつ、パスワードなしでのインターネット接続が可能となっており、またアカウント情報などの個人情報を取り扱うことでの使用が一般的となるため、弊社のパートナー認証機関の見解では、整合規格の指定での制限に該当し、自己適合宣言の適用ができない可能性が高いとの見解です。

なお、本告知に関する詳細は、、EU官報 Commission Implementing Decision (EU) 2025/138（https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202500138）をご参照ください。

はじめに

現代のビジネス環境では、サイバー攻撃の脅威がますます高まり、各国・各業界で厳格なセキュリティ認証規格が求められています。特に海外市場でビジネスを展開する企業にとって、サイバーセキュリティの認証取得は重要な課題です。本コラムでは、主要な海外のサイバーセキュリティ認証規格の種類と、それに対応するためのプロセスについて解説いたします。

主要な海外のサイバーセキュリティ認証規格

国際的なサイバーセキュリティ規格

• ISO/IEC 27001（情報セキュリティマネジメントシステム：ISMS）
  • 情報セキュリティ管理の国際標準。
  • 組織全体のリスクマネジメントを適用。
• ISO/IEC 27017（クラウドセキュリティ管理策）
  • クラウド環境向けの追加セキュリティ管理策。
• ISO/IEC 27018（クラウド個人データ保護）
  • クラウド上での個人データ保護指針。
• Common Criteria（ISO/IEC 15408）
  • IT製品のセキュリティ評価の国際基準。

米国のサイバーセキュリティ規格

• NIST Cybersecurity Framework（NIST CSF）
  • 米国国立標準技術研究所（NIST）が策定したサイバーセキュリティフレームワーク。
• FedRAMP（Federal Risk and Authorization Management Program）
  • 米国政府向けクラウドサービスのセキュリティ基準。
• CMMC（Cybersecurity Maturity Model Certification）
  • 米国防総省（DoD）契約企業向けのサイバーセキュリティ成熟度モデル。
• FIPS 140-3（暗号モジュール認証）
  • 政府機関および関連企業向けの暗号規格。

欧州のサイバーセキュリティ規格

• GDPR（General Data Protection Regulation）
  • EU一般データ保護規則。企業に厳格なデータ管理を要求。
• EU Cybersecurity Act
  • ENISA（欧州サイバーセキュリティ庁）が推進する認証枠組み。
• BSI IT-Grundschutz（ドイツ）
  • ドイツの国家情報セキュリティ基準。

業界特化型の認証規格

• PCI DSS（Payment Card Industry Data Security Standard）
  • クレジットカード取引に関するデータセキュリティ基準。
• SWIFT CSP（Customer Security Program）
  • 国際銀行間送金のセキュリティ基準。
• IEC 62443（産業用制御システム向け）
  • 重要インフラ・製造業向けのサイバーセキュリティ基準。

認証取得のプロセスと対応策

(1) 現状分析とギャップ分析

• 取得を目指す認証規格を選定。
• 既存のセキュリティ対策を評価し、不足部分を特定。

(2) 体制構築とポリシー策定

• セキュリティ管理体制を整備し、責任者を明確化。
• 内部ポリシーや手順を文書化。

(3) 技術的な対策の実施

• ネットワーク、エンドポイント、クラウドなどのセキュリティ強化。
• 暗号化、アクセス管理、脅威検出ツールの導入。

(4) 教育・トレーニングの実施

• 社員向けのサイバーセキュリティ研修を実施。
• インシデント対応訓練を行い、即応力を向上。

(5) 内部監査と外部監査の実施

• 定期的に内部監査を行い、コンプライアンスを確認。
• 認証取得のための第三者監査を受け、認証を取得。

(6) 継続的な改善

• セキュリティインシデントや新たな脅威に対応。
• 規格の更新に応じた対策の継続。

認証取得のメリット

• 海外市場での信頼獲得：国際的な取引や政府契約の要件に対応。
• サイバー攻撃リスクの軽減：強固なセキュリティ対策により被害を防止。
• 競争優位性の確保：他社との差別化要因となり、ビジネス拡大につながる。
• コンプライアンス対応の効率化：各国の規制に適合しやすくなる。

今後法規制が予定されている海外のサイバーセキュリティ認証規格と対応策

主要な海外の新規サイバーセキュリティ法規制と対応時期

(1) 欧州サイバーレジリエンス法（Cyber Resilience Act, CRA）

• 概要: CRAは、デジタル要素を含む製品（IoTデバイス、ソフトウェアなど）のサイバーセキュリティ強化を目的としたEUの新規制。
• 適用開始時期:
  • 2024年12月10日: 発効
  • 2026年9月11日: 一部義務適用開始
  • 2027年12月11日: 全面適用
• 対応策:
  • CRA適用対象製品の洗い出しとリスク評価
  • サイバーセキュリティ要件（脆弱性管理、更新義務など）への準拠
  • EU市場向け製品の開発・販売計画の見直し

(2) 無線機器指令（Radio Equipment Directive, RED）のサイバーセキュリティ要件

• 概要: REDはEUの無線機器向け規制で、サイバーセキュリティ要件（データ保護、ユーザー認証、不正アクセス防止）を強化。
• 適用開始時期: 2025年8月1日（当初の2024年8月1日から延期）
• 対応策:
  • 対象機器の技術仕様の見直し
  • EU市場での販売継続に向けた適合性評価と認証取得
  • GDPRやCRAと整合性のあるセキュリティ対策の実装

(3) EUサイバーセキュリティ認証制度（EU Cybersecurity Certification, EUCC）

• 概要: ICT製品のセキュリティ評価に関する共通基準（ISO/IEC 15408）に基づく新たなEU認証スキーム。
• 適用開始時期: 2025年以降（詳細な開始時期は未確定）
• 対応策:
  • EUCC対象製品の特定と適合計画の策定
  • ISO/IEC 15408認証プロセスの理解と準備
  • ENISA（欧州サイバーセキュリティ庁）による最新情報の追跡

(4) 米国国家サイバーセキュリティ戦略（National Cybersecurity Strategy）

• 概要: 米国政府が発表した国家戦略で、サプライチェーンセキュリティやソフトウェア開発のセキュリティ基準の強化を含む。
• 適用開始時期: 2023年以降段階的に実施中
• 対応策:
  • 米国政府および関連業界のセキュリティ要件を確認
  • ソフトウェア開発ライフサイクル（SDLC）へのセキュリティ組み込み
  • NISTフレームワーク（NIST CSF 2.0など）への準拠

企業の対応戦略

(1) 規制対象の特定と適合計画の策定

• 各規制が適用される製品・サービスのリストアップ
• 自社のセキュリティ対策と規制要件のギャップ分析

(2) サイバーセキュリティ強化のための技術対策

• 安全なソフトウェア開発手法の導入（例: DevSecOps）
• クラウド・IoT・エンドポイントのセキュリティ管理強化
• 定期的な脆弱性診断とパッチ管理の徹底

(3) 認証取得プロセスの構築

• ISO/IEC 27001、ISO/IEC 15408、NIST CSFなどの標準に基づく内部管理体制の確立
• サードパーティ監査を活用し、適合性の確認

(4) 規制動向の継続的モニタリング

• EUや米国の政府機関の公式発表を定期的にチェック
• 業界団体や専門家とのネットワークを活用し、最新情報を収集
• 柔軟に対応できる体制を確保

まとめ

今後数年間で、EUや米国を中心にサイバーセキュリティに関する新たな法規制が本格的に適用されます。企業は、規制対象の特定、技術的対策の強化、認証取得プロセスの確立、そして継続的なモニタリングを通じて、規制対応をスムーズに進める必要があります。特に、欧州のCyber Resilience Act（CRA）や米国の国家サイバーセキュリティ戦略は、広範な影響を及ぼすため、早急な対応が求められます。

グローバル市場での競争力を維持するためにも、各国の法規制に適合するセキュリティ基準を満たし、信頼性の高い製品・サービスを提供することが不可欠です。

弊社では欧州向けサイバーセキュリティ対策をワンストップでお手伝いをしております。サービス内容につきましては、以下フォームよりお問合せください。

EN 18031 シリーズがRED-DA(欧州無線機器指令委託令) 3.3 (d/e/f)の整合規格に指定されたことをお知らせいたします。

この整合規格を活用することで、RED-DA(欧州無線機器指令)に対して自己適合宣言を行う事ができます。

但し注意点として、いくつかの制限付きでの整合規格としての指定になります。詳細はお問い合わせください。

なお、本告知に関する詳細は、EU官報（https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202500138）をご参照ください。

Article 3.3 (d) インターネットに接続された無線機器のセキュリティ要件に対応する整合規格に EN 18031-1:2024 が指定されました。

• 対象製品: インターネットに接続された無線機器
• 該当する必須要求: 無線機器指令 Article 3.3(d) (ネットワーク保護)
• 規格番号: EN 18031-1:2024
• 制限 : パスワードなし又はパスワード変更なしでの運用が可能な製品

Article 3.3(e) 個人データやプライバシーを扱う無線機器のセキュリティ要件に対応する整合規格に EN 18031-2:2024 が指定されました。

• 対象製品： インターネットに接続された無線機器、チャイルドケア機器、玩具、ウェアラブル機器
• 該当する必須要求： 無線機器指令 Article 3.3(e) (プライバシー保護)
• 規格番号: EN 18031-2:2024
• 制限 : パスワードなし又はパスワード変更なしでの運用が可能な製品、もしくはペアレントコントロールの機能が実装されていないチャイルドケア製品と玩具製品

Article 3.3(f) 仮想通貨や金銭的価値を処理する無線機器のセキュリティ要件に対応する整合規格に EN 18031-3:2024 が指定されました。

• 対象製品： 仮想通貨や金銭的価値を処理するインターネット接続された無線機器
• 該当する必須要求: 無線機器指令 Article 3.3(f) (詐欺行為の防止)
• 規格番号: EN 18031-3:2024
• 制限 : 全ての対象製品

JC-STAR（IoT製品セキュリティ要件適合評価及びラベリング制度）について

1. JC-STARって何？

JC-STARは、IoT製品のセキュリティレベルを可視化し、消費者や企業が安心してIoT製品を利用できる環境を整備するための、日本の制度です。経済産業省が策定した「IoT製品に対するセキュリティ適合性評価制度構築方針」に基づき、IPA（情報処理推進機構）が運営しています。

JC-STARは、国際的なIoTセキュリティ基準であるETSI EN 303 645やNISTIR 8425を参考にしながら、日本の状況に合わせて策定されています。これらの国際基準は、IoT製品のセキュリティに関する技術的な要件を詳細に規定しており、JC-STARの基準策定において重要な役割を果たしています。

2. 海外におけるセキュリティラベリング制度の動向は？

世界各国で、IoT製品のセキュリティに関する取り組みが活発化しており、
様々なセキュリティラベリング制度が導入されています。代表的なものとしては、シンガポール、英国、米国、EUなどが挙げられます。JC-STARは、これらの制度との相互承認を目指しており、日本のIoT製品が海外市場に進出する際の障壁を低減することを目指しています。

3. JC-STARの基準ってどうなっているの？

JC-STARの基準は、IoT製品の種類や機能によって異なりますが、
以下の4段階のレベルで評価されます。

★1（レベル1）: IoT製品共通の最低限の脅威に対応するための適合基準です。ETSI EN 303 645のベースライン要件を満たすことが求められます。
★2（レベル2）: IoT製品類型ごとの特徴に応じた適合基準です。ETSI EN 303 645の特定プロファイルに準拠することが求められます。
★3（レベル3）: より高度なセキュリティ機能が求められる製品に対する適合基準です。NISTIR 8425の要件を満たすことが求められます。
★4（レベル4）: 特定の分野や用途に特化した高度なセキュリティ機能が求められる製品に対する適合基準です。業界団体やコンソーシアムが策定したセキュリティガイドラインを満たすことが求められます。
評価方法

4. 適合が認められると？ 適合ラベルの取得方法

適合が認められると、製品に二次元バーコード付きの適合ラベルが付与されます。このラベルには、製品詳細や適合評価、セキュリティ情報・問合せ先等の情報が記載されており、調達者・消費者が簡単に情報を取得できるようになっています。

適合ラベルの取得方法は、製品のセキュリティレベルと、自己適合宣言か第3者評価かによって異なります。

‐自己適合宣言:
企業が、自社のIoT製品がJC-STARの基準を満たしていると自己申告する方法です。
主に★1、★2レベルの製品に適用されます。
企業が、JC-STARの評価手順に従い、自己評価を行い、その結果に基づいてIPAが適合ラベルを付与します。
‐第3者評価:
第三者機関が、IoT製品のセキュリティレベルを客観的に評価する方法です。
主に★3、★4レベルの製品に適用されます。
第三者機関が、IoT製品を評価し、その結果に基づいてIPAが適合ラベルを付与します。

5. 制度の運用時期は？

JC-STARは、2024年9月にIPA（情報処理推進機構）が公開し、
2025年3月から★１（レベル１）の申請受付開始運用が開始されます。

6. 任意制度？

JC-STARの制度は、企業は、自社の製品に適合ラベルを取得するかどうかを自由に選択することができます。適合ラベルを取得することで、製品の信頼性向上や、競合他社との差別化を図ることができます。

7.まとめ

JC-STARは、日本のIoT製品のセキュリティレベル向上を目指しています。この制度によって、消費者や企業は、IoT製品のセキュリティレベルを客観的に比較し、安心して製品を選択できるようになります。
弊社ではJC-STAR適合を検討する会社様へコンサルティングや、
ETSI EN 303 645認証取得試験サービスを提供しております。
より詳しく知りたい場合には、以下よりお問い合わせください。

より詳しく知りたい方へ
IPAのウェブサイト: https://www.ipa.go.jp/security/jc-star/detail.html

EU AI規制法(AI Act)とは
EU AI Act（Artificial Intelligence Act）は、欧州連合（EU）が提案した人工知能（AI）に関する包括的な規制枠組みで、2021年4月に欧州委員会が初めて案を公表しました。この法案は、AIシステムの利用によるリスクを管理し、信頼性と透明性を確保しながら、AIの発展を促進することを目的としています。

概要

AI Actは、AIシステムを使用するリスクに基づいて4つのカテゴリに分類されます

許容できないリスク（Unacceptable Risk）
人間の基本的権利を侵害するAIシステムは禁止されます。例：社会的スコアリング（中国の「ソーシャルクレジット」システムに類似）。

高リスク（High Risk）
医療、司法、雇用、教育、インフラ、安全性に関連するAI。厳格な要件を満たし、認証が必要。

限定リスク（Limited Risk）
特定の透明性要件が求められるAIシステム。例：チャットボットにはAIであることの通知が必要。

最小リスク（Minimal Risk）
ビデオゲームやスパムフィルタのようなリスクが低いAI。追加規制なし。

規制対象

EU域内で提供・使用されるAIシステムや、EU市場に影響を与える外国製AIシステムも規制対象。

目的

1. 安全で信頼性の高いAIの使用を推進。
2. 市民の権利とプライバシーを保護。
3. 技術革新を阻害せず、AI市場を育成。

詳細

1.高リスクAIの要件

• データガバナンス：公平性、正確性、偏りの防止を確保。
• 文書化：AIシステムの設計、開発、テストプロセスを詳細に記録。
• 透明性：ユーザーにAIシステムの使用目的や機能について情報を提供。
• 人間の監視：重要な意思決定は人間が関与するように設計。

2.禁止されるAIシステム

社会的スコアリング。
違法な監視活動（リアルタイムでの生体認証システムの無許可使用など）。
洗脳的な行動操作。

3.罰則

違反した場合には厳しい罰則が科される可能性があり、世界の年間売上高の7％または3500万ユーロのいずれか高い方の罰金が科せられる。

4.監督機関

各加盟国に監督機関を設置し、EUレベルでは「欧州AI委員会（European Artificial Intelligence Board）」が統括。

5.AIサンドボックス
技術革新を促進するため、安全な環境でのAIシステムのテストを可能にする「規制サンドボックス」を提供。

タイムライン

• 2021年4月21日
  • 初期提案の公表
    欧州委員会（European Commission）がAI Actの初期提案を発表。AIシステムをリスクベースで分類する規制枠組みを提案。
• 2022年後半 – 2023年初頭
  • 議論と修正
    欧州議会（European Parliament）および欧州連合理事会（Council of the EU）で法案の内容について議論。関係者からの意見を受け、修正が繰り返される。
• 2023年6月14日
  • 欧州議会による採択
    欧州議会がAI Actの法案を採択（第一読会）。その後、トリログ（欧州委員会、欧州議会、欧州連合理事会の三者間協議）で最終調整が進行。
• 2024年5月21日
  • 最終採択と公式発表
    EU理事会（閣僚理事会）は5月21日、人工知能（AI）を包括的に規制する規則案（AI法案）を採択。
• 2024年後半 – 2025年初頭（予定）
  • 施行
    AI Actは公表後20日後に正式に施行。ただし、実際の適用（強制執行）は、2年間の移行期間を経て開始される予定。
• 2026年頃（予定）
  • 適用開始
    高リスクAIの規制要件や禁止事項などが、EU加盟国および対象企業に強制的に適用される。

日本やその他の国への影響

EUのAI Actは、GDPR（一般データ保護規則）と同様に、EU域外の企業にも影響を及ぼす「域外適用」の特徴があります。そのため、日本の企業も、EUでAIシステムを提供・使用する場合、この規制を遵守する必要があります。これにより、AIシステムの開発や利用において、透明性やデータ管理の重要性が増しています。

今後の課題

1. 技術革新と規制のバランス

• 課題: AI Actは、安全性や倫理性を確保するための厳しい規制を導入していますが、過度な規制が技術革新を阻害する可能性があります。
• 具体例:
  • 中小企業やスタートアップが、規制に伴うコストや手続きの複雑さで競争力を失う可能性。
  • 特定分野（医療、金融など）での高リスクAI開発が抑制される恐れ。
• 対応策: 規制サンドボックス（AIシステムを試験的に運用できる環境）の活用や、中小企業向けの特例措置を充実させる必要があります。

2. 実施のためのリソース不足

• 課題: 加盟国ごとに監督機関を設置し、AIシステムのリスク評価や監視を行う必要がありますが、リソースや専門知識の不足が予想されます。
• 具体例:
  • 高度な技術知識を持つ人材が十分に確保できない。
  • 監査プロセスが遅延し、AIシステムの市場投入が遅れる可能性。
• 対応策: 各国の監督機関間での協力や、EUレベルの統一的な支援が求められます。

3. AI定義の曖昧さ

• 課題: AI Actの対象となる「AIシステム」の定義が広範囲であるため、どのシステムが規制対象に該当するかが明確でない場合があります。
• 具体例:
  • 機械学習アルゴリズムと単純な自動化システムの区別が曖昧。
  • 定義が広すぎると、低リスクの技術まで不必要に規制される可能性。
• 対応策: 定義をより具体化し、技術の進化に応じた柔軟な適用方法を採用する。

4. 国際的な競争力への影響

• 課題: EU域外の国々（特に米国や中国）と比べ、EU内のAI企業が競争力を失う可能性があります。
• 具体例:
  • 米中のAI開発環境は規制が緩やかであり、技術開発がより迅速に進む可能性。
  • グローバル市場でのEU製AIシステムの競争力低下。
• 対応策: 規制の実施と技術支援の両面で、国際的な調整や競争力強化策を講じる必要があります。

5. グローバルな調和と標準化

• 課題: AI ActはEU独自の規制であり、他国や国際機関の取り組みと整合性を取ることが求められます。
• 具体例:
  • 他国が異なる規制を採用した場合、企業が複数の規制を遵守する負担が増加。
  • グローバルなAI倫理基準の欠如による市場の分断。
• 対応策: 国際的な規制調整のため、ISO（国際標準化機構）やOECDとの協力が重要。

6. 実効性の評価とアップデート

• 課題: AI Actの効果を測定し、技術の進化や新たなリスクに対応するための定期的な見直しが必要です。
• 具体例:
  • 生成AI（例：ChatGPT）や新たな技術が普及した場合、規制が追いつかない可能性。
  • 長期的な影響を予測する困難さ。
• 対応策: 定期的なレビューと、アップデート可能な柔軟な規制枠組みを設ける。

7. プライバシーや基本権との調整

• 課題: AIシステムによる監視やデータ処理が、プライバシー権や基本的人権を侵害するリスクがあります。
• 具体例:
  • リアルタイムの生体認証技術の使用が市民の自由を制限する可能性。
  • データバイアスが特定の集団に不利益を与えるリスク。
• 対応策: GDPR（一般データ保護規則）との調和を図り、倫理的なAI運用を強化。

まとめ

AI Actの施行と適用には、多くの課題が残されています。特に、規制による技術革新への影響や、国際的な競争力との兼ね合いが重要な論点となるでしょう。これらの課題に対応するため、柔軟かつ実効的な規制と、技術開発を支援する枠組みの両立が求められています。

CentOSのEOL

CentOSは、長年にわたりサーバー環境や開発環境において最も利用されてきたLinuxディストリビューションの一つです。特に、その安定性とRed Hat Enterprise Linux（RHEL）とのバイナリ互換性により、無償で利用できる企業向けの選択肢として広く親しまれてきました。しかし、CentOSのEnd of Life（EOL）を迎えることは、ユーザーにとって大きな影響をもたらします。このEOLは、特にCentOS 7を使用している企業にとって、計画的な対応が求められます。

CentOS EOLの主な影響

1. セキュリティリスクの増加

   最も深刻な影響は、セキュリティのリスクです。CentOSがEOLを迎えると、セキュリティパッチやバグ修正が提供されなくなります。これにより、CentOSを使用しているシステムは新たに発見された脆弱性に対して無防備になり、攻撃者に悪用されるリスクが高まります。特に、企業や重要な業務システムでCentOSを使用している場合、このセキュリティリスクは業務の継続性に大きな影響を与える可能性があります。

2. 運用の混乱

   CentOSのEOL後、システムの更新やサポートを受けるために、他のディストリビューションへの移行を余儀なくされます。この移行プロセスは簡単ではなく、既存のシステムやアプリケーションとの互換性の問題、ダウンタイム、運用負荷の増加が懸念されます。特に、システムの規模が大きい企業にとって、これらの問題はリソースを大きく消費し、移行期間中の業務に支障をきたすことになります。

3. 代替ディストリビューションへの移行

   多くの組織が、CentOS Streamのようなオプションを検討しています。CentOS Streamはローリングリリースモデルを採用しており、より新しい機能が提供されますが、頻繁な更新が必要になるかもしれません。また、CentOSとバイナリ互換性がある他の代替ディストリビューションも直接的な代替として考えられます。

4. 延長サポートオプション

    一部の企業は、CentOS 7の延長サポートを提供しているため、移行を延期することができます。これにより、移行計画を立てる時間を確保できる一方で、セキュリティのリスクを引き起こす可能性があります。

5. コストとライセンス

   代替ディストリビューションへの移行は、追加のライセンス費用がかかる可能性があり、CentOSをコスト効果の高い解決策として使用してきた組織にとって、予算に影響を与えるかもしれません。

   

CentOSのEOLは、単なるディストリビューションのサポート終了以上の影響を及ぼします。

企業や開発者は、セキュリティリスクや運用の混乱を避ける為に、早急に代替ディストリビューションへの移行を検討する必要があります。

移行を急ぐ必要がある一方で、コストや運用負担を考慮した戦略的な移行計画を立てることが重要です。また、延長サポートを利用するなど、段階的な移行を選択する企業も増えると予想されます。

Wind River Studio Linux Servicesは、組込みLinuxプラットフォームの設計、実装、セキュリティ対策、ライフサイクルの管理を提供する サービスです。ニーズに応じた５つのサービスで、Linux開発・運用で直面する 課題を解決します。

主なサービス内容

1.セキュリティスキャン※無償CVEスキャンサービス実施中

組込みLinux開発特有のニーズに合わせたプロフェッショナルグレードのセキュリティ脆弱性（CVE）スキャンを提供しより高品質なソフトウェアの構築と導入時間の短縮を支援します。

2.セキュリティの解析とレメディエーション

開発コードの品質向上をはじめ、アプリケーションの迅速なデプロイに役立つセキュリティのスキャン、解析、修正プランサービスを提供します。

3.ライフサイクル・パフォーマンス・アシュアランス

Linuxプラットフォームのマネジメントサービスやお客様の組込みシステムプロジェクトに対応したボードサポートパッケージを提供します。

4.ライフサイクルセキュリティ

ソフトウェアの開発からデプロイまでライフサイクル全体にわたってLinuxプラットフォーム上のCVEを継続的に監視、緩和、管理します。

5.アーキテクチャと実装

システム要件の解釈、プラットフォーム設計、推奨案など包括的なソリューションサービスを提供します。

詳細は製品ページをご覧ください。

• Wind River Studio Linux Services「Linux開発・運用で直面する課題を解決」

詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。