製品セキュリティの最前線【第2回】

製品セキュリティにおける「信頼」の前提をどう作るか　
― 要求事項を「設計の軸」に変えるために

※こちらのページに記載されている内容は、2026年4月時点の情報です。

CRA※³などのサイバーセキュリティ法規や、そこで参照されるさまざまな実装プロセスとして参照される規格などにおいては、データ暗号化、ソフトウエア更新、SBOM管理、脆弱(ぜいじゃく)性対応体制構築など、さまざまな要求事項が提示されています。しかも、要求はひとつではありません。

これらの要求事項の羅列を見ると、「やることが増えた」「要求が厳しくなった」と感じてしまうのも無理はありません。
しかし実際には、まったく新しいことが突然求められたというわけではないのです。
以前から重要だと言われていた、もしくはわかっていたセキュリティ対策が、第三者に説明できる形で整っているかを問われるようになった、というのが実態です。

言い換えれば、これからは「セキュリティ対策しているはずだからそれで大丈夫」ということではなく、この製品やそれを作っている企業は信頼できると言えるのかということを、製品設計とプロセス運用の両面から説明できるようにする必要が出てきた、ということになります。

では、製品における「信頼」とは、なにを指すのでしょうか。
セキュリティ要件にはいろいろなものがありますが、特に以下の4つを満たすことは非常に重要です。

ここまでをふまえると、識別・認証、暗号化、SBOM、更新、PSIRTといった製品に対するさまざまな要求事項は、個別にバラバラと対応すべきものではありません。
それぞれ「信頼を作り、維持するための部品」として、例えば次のように位置づけられます。

このように整理できると、「やる／やらない」という議論ではなく、信頼の説明責任を果たすためになにが必要かという観点で、製品そのものに実装すべきこと、製造プロセスとして対応すべきことを判断できるようになります。

特に①～③（本物・正しい状態・情報を守れる）を支えるのが「信頼の基点 (Root of Trust)」です。
「信頼の基点」とは、製品IDや暗号鍵、証明書などの重要な情報を、簡単には取り出せない形で保持し、製品が信頼できるかどうかを判断するための根幹となる部分です。
具体的には、以下の基本機能を持つことが求められます。

ネットワークにつながる機器は、これらの3つを適切に保護・運用することが必要不可欠です。

重要なのは、「信頼の基点」というのは特定の製品名や部品名を指すのではなく、設計上の役割だという点です。製品設計を行う際、これをどのような形で実装していくのかをあらかじめ考えておかなければなりません。

Root of Trustはセキュアエレメント等のハードウエアを用いて担保するのか、ソフトウエア的に安全に隔離された領域で担保するのか、クラウド側とどう役割分担するのか、検討が必要です。この判断は、製品の脅威モデル、コスト、製造条件、運用保守方針などと密接に結びつきます。

ここを曖昧にしたまま個別の要求事項に着手すると、後になって整合が取れなくなり、設計の手戻りが発生しやすくなります。

これまで、製品づくりにおいて、このようなことを意識せず、ただ動けばよいと思って開発していたことも多かったかもしれません。しかし、セキュリティ・バイ・デザインが求められる今、その根幹となる「信頼の基点」のことを始めからしっかりと考え、設計に盛り込むことが、製品を守るために非常に大事なことになってきたと言えるでしょう。

製品セキュリティの多くの要求事項が「信頼の基点」をベースにしているのは前述の通りですが、

といったことを正しく行うためには、信頼の基点ともうひとつ、「暗号技術」の活用が欠かせません。
知っていれば誰でも使える暗号を実際どのように使うのか、そこで使用する暗号鍵や証明書をどう安全に管理するかということが、実は法規対応に密接に関係してくるのです。

次回は、この「信頼の前提」を技術的に支える「暗号」にクローズアップし、暗号を使う上でどのようなことに気を付けたらよいのかを掘り下げていきます。