Japan
サイト内の現在位置
IoT製品のセキュリティラベリング制度(JC-STAR)のご紹介とユーザとしての認証制度活用について
NECセキュリティブログ2025年4月11日
NECサイバーセキュリティ技術統括部 セキュリティ技術センターの山田です。
本ブログでは、2025年3月25日に申請受付が開始したセキュリティ要件適合評価及びラベリング制度(JC-STAR)について概要のご紹介をします。また、これら認証を取得している製品・サービスをユーザとして利用する場合の注意点などについて考えてみたいと思います。
目次
JC-STAR
まずはじめに、JC-STARの概要についてご紹介します。
JC-STARとは
JC-STAR(Labeling Scheme based on Japan Cyber-Security Technical Assessment Requirements)はIoT製品を対象としてセキュリティ機能を評価、可視化することを目的として構築された日本の制度となります。[1]
本制度では4段階の適合基準が定められており、2025年3月25日に最低限のセキュリティ要件であるレベル1への申請が開始されました。今後、基準への適合が認められた製品はJC-STARラベルを使用し、ユーザへアピールすることができます。
適合基準のレベル
JC-STARではレベル1~4の4段階で適合基準が定められています。レベル4にて求められるセキュリティ要件が、JC-STARにて求められるセキュリティ要件の全体像となっており、そこから一部要件を除外したものがレベル3、さらに除外したものがレベル2というように、下位のレベルで求められるセキュリティ要件は上位のレベルのセキュリティ要件の部分集合という関係になっています。


(IPA セキュリティラベリング制度(JC-STAR)についての詳細情報より)
先日申請が開始されたレベル1はIoT製品にて共通して求められる最低限のセキュリティ要件と定義されており、暗号通信の利用、ソフトウェアアップデート機能といった実装面での要件や、脆弱性開示ポリシーに関する製品販売後の運用面での要件、さらには、廃棄や中古販売によって想定されるリスク、安全な廃棄手順をユーザに周知するといった、利用終了まで含めた情報提供が求められます。
レベル2以上の詳細な要件は現在公開されていませんが、製品類型ごとの特徴を考慮したうえで追加すべきセキュリティ要件が定められるようです。製品類型の例としては、スマート家電、防犯関連機器、通信機器などが挙げられています。
適合ラベル付与までの流れ
JC-STARの適合ラベルの付与までの流れは、レベル1、2とレベル3、4でそれぞれ異なります。
レベル1、2の認証を得る場合、製品ベンダーは自己評価に基づくチェックリストの作成が必要となります。レベルごとに求められるセキュリティ要件に対するチェックリストを作成し、セキュリティ対策の実施状況をIPAへ提出することで適合ラベルが付与されます。なお、チェックリストの提出時に証跡までの提出は不要ですが、改めてIPAによる検査などが行われる可能性があるため、適合ラベルの有効期間中は証跡を保管する必要があります。
レベル3、4は政府機関や重要インフラ事業者に向けた製品が想定されており、認証を受ける際には外部機関による評価を受ける必要があります。製品ベンダーの第三者による評価が行われるため、ユーザにとっては評価結果をより信頼しやすい形式となりますが、製品ベンダーとしては認証取得までのハードルが高くなると考えられます。


(IPA セキュリティラベリング制度(JC-STAR)についての詳細情報より)
ユーザとしての認証制度活用
制度認証を取得している製品・サービスであれば、個別のセキュリティ対策状況の確認を省略したり、システム構築時の要件などとして認証制度を活用されている方々もいらっしゃるかと思います。
ここからは、JC-STARに限らず制度認証を取得している製品・サービスをユーザとして利用する際の利点と、気を付けるべき点について考えてみます。
認証制度活用の利点
ユーザとして制度認証を取得している製品・サービスを活用する利点として自身によるセキュリティ対策状況の審査を省力化できる点が挙げられます。利用しようとしている製品・サービスが自組織の求めるセキュリティ要件を満たしているかを毎回個別に確認するのは時間と労力が必要となりますし、事業者によっては公開情報以上の回答を得られない場合もあります。そこで、製品・サービスが取得している認証を確認すれば、満たされているセキュリティ要件を容易に把握することができますので、個別に確認する手間を軽減することが可能です。
また、特定事業や情報を扱うために認証制度への対応が必須となる場合もあります。
例えば、クレジットカード業界の国際基準であるPCI DSS[2]はクレジットカード会社だけでなく、決済手段としてクレジットカードを扱う加盟店も対応が必須となります。この際、PCI DSSに準拠した事業者を選定することでクレジットカード情報を取り扱う業務の一部を外部委託することもできます。
他にも、政府機関等のサイバーセキュリティ対策のための統一基準[3]では、クラウドサービスの選定に関する部分にて「原則としてISMAP等クラウドサービスリストからクラウドサービスを選定すること。」という文言が記載されています。このため、政府機関向けのサービスではISMAP対応が必要となりますが、既にISMAPクラウドサービスリスト
[4]に掲載されているサービスを利用することで、自社での責任範囲を絞り込むことができます。
セキュリティ要件の確認
各セキュリティ認証制度では、制度制定時に想定される脅威に基づき、必要とされるセキュリティ要件が定められます。このため、特定の状況下における脅威が考慮されていない場合や、時間の経過によって新たな脅威が発生し対応ができていない場合があります。ですので、制度認証を受けた製品・サービスを利用する場合、信頼できる組織による認証制度であっても、その内容が自組織に合ったものか1度は検証する必要があります。
例えば、ある認証制度において自組織にて想定される脅威が網羅されていない場合は、独自の項目を別途ベンダーへ確認することや、別の認証制度を活用することが必要になります。
また、自組織にとって過剰なセキュリティ対策を要件とする認証制度のみを認めるような組織のルールを定めてしまうと、無闇に製品・サービスの選択肢を狭めることやコストの増加にも繋がってしまうため、自組織にて求めるセキュリティ要件のベースラインを事前に定めておくことが重要です。
審査体制の確認
セキュリティ要件の他に、認証取得時の審査体制も確認する必要があります。
今回ご紹介したJC-STARのレベル1、2のように製品ベンダーのセルフチェック結果を元に認証がされる制度もあります。このような場合、制度維持のために製品ベンダーのセルフチェック以外の監査が行われるかという点が、認証結果を信頼できるかの1つの観点となります。
JC-STARの場合、適合ラベルの適用期間中、申請内容に疑義が生じた場合は検査を行い、製品ベンダーはセキュリティ要件に関する証跡を提出することが求められます。このように、制度主管組織が制度維持のための活動を行っているかはセルフチェックによる認証を信頼できるかの重要な点となります。
場合によっては、製品・サービスベンダーが取得している他の認証や、コンプライアンスレポートなどと併せてベンダーとしての信頼性を確認することで、セルフチェックによる認証への信頼度を評価することも1つの手段かと思います。
一方、セルフチェックではなく第三者機関による評価を認証の要件とする制度もあります。このような認証の場合は、セキュリティ対策の証跡も含めて監査が行われたうえでの認証の取得となりますので、認証結果の信頼性は非常に高くなります。ただし、第三者による監査はコストが大きく、要件は満たしていても認証取得を見送る製品・サービスも存在するかと思います。
また、セルフチェック、第三者機関による評価どちらの場合も、製品・サービスの利用期間中に認証がはく奪されていないか、インシデントが発生していないかといった定期的なチェックは必要です。
まとめ
今回は、IoT機器のセキュリティ要件適合評価制度であるJC-STARのご紹介と、ユーザとして制度認証を取得している製品・サービスを活用する際に注意すべき点について記載しました。
JC-STARによって、IoT機器の満たしているセキュリティ要件が可視化され、ユーザとして安全な製品選定が容易になります。
一方、認証制度の内容を理解しないまま製品・サービスを信頼してしまうことは、自組織に必要なセキュリティ対策の漏れや、逆に過剰なセキュリティ要件を求めることによる利便性の低下にも繋がってしまうため注意が必要です。
参考文献
- [1]IPA 独立行政法人 情報処理推進機構 セキュリティ要件適合評価及びラベリング制度(JC-STAR)
https://www.ipa.go.jp/security/jc-star/index.html
- [2]日本カード情報セキュリティ協議会 PCI DSSとは
https://www.jcdsc.org/pci_dss.php
- [3]政府機関等のサイバーセキュリティ対策のための統一基準(令和5年度版)
https://www.nisc.go.jp/pdf/policy/general/kijyunr5.pdf
- [4]ISMAPポータル ISMAPクラウドサービスリスト
https://www.ismap.go.jp/csm?id=cloud_service_list
執筆者プロフィール
山田 道洋(やまだ みちひろ)
セキュリティ技術センター 実装技術レギュレーションチーム
NECグループのセキュア開発・運用を推進。主にクラウドのセキュアアーキテクチャ検討、リスクアセスメントに従事。
JNSA調査研究部会インシデント被害調査ワーキンググループメンバーとして活動し、2021年度JNSA賞受賞。
CISSPを保持。

執筆者の他の記事を読む
アクセスランキング
2025年4月6日~4月12日に読まれた記事のランキング