1. 導入：なぜ「保証継続」が重要なのか
IT製品のライフサイクルにおいて、セキュリティ認証（JISEC等）を取得した製品であっても、不具合修正や環境変更といったアップデートは不可欠です。しかし、些細な修正のたびにゼロから再評価を行うのは、開発コストと期間の観点から非現実的です。
「保証継続」という枠組みを活用することで、既に評価済みのセキュリティ水準を維持しつつ、効率的に製品のアップデートを市場へ提供することが可能になります。本記事では、この枠組みを実務で活用するためのポイントを解説します。
2. 基礎知識：認証維持と再評定の違い
保証継続には大きく分けて2つのアプローチがあります。
認証維持（Assurance Continuity）
製品や開発環境に「変更」が加わった際、その変更がセキュリティ上の耐性に悪影響を与えないことを証明し、評価結果を維持する仕組みです。主にバグフィックスや動作環境の追加などが対象です。
再評定（Re-evaluation）
製品自体に変更はないものの、外部の脅威状況が変化した際に、現在の技術水準でも「初回と同等の耐性」を維持できているかを確認するプロセスです。
3. 実装/解決策：影響分析報告書の作成
認証維持を申請する際、最も重要なのが「影響分析報告書」です。開発者は、変更がセキュリティ機能に与える影響が「軽微（minor）」であることを論理的に証明しなければなりません。
分析のステップ:
1. 変更範囲の特定: 変更がセキュリティターゲット（ST）で定義された保証範囲外であることを確認します。
2. チェックリスト活用: IPAが提供する「認証維持適用のためのチェックリスト」を用い、客観的な判定を行います。
3. 事前レビュー: 申請前に認証機関へ依頼し、方向性の妥当性を確認します。
4. サンプルプログラム：変更影響判定のロジック
実務では、変更内容の管理が重要です。以下は、変更が「認証維持の対象となり得るか」を簡易判定するPythonのスクリプト例です。
変更内容の重要度を判定する簡易スクリプト
def check_impact(is_security_feature_affected, is_doc_only_change):
“””
is_security_feature_affected: セキュリティ機能の仕様に変更があるか
is_doc_only_change: ガイダンス等の軽微な変更のみか
“””
if is_security_feature_affected:
return “新規評価が必要です（Major Impact）”
elif is_doc_only_change:
return “認証維持の対象です（Minor Impact / 手続きへ）”
else:
# 詳細な分析が必要なケース
return “詳細な影響分析報告書の作成が必要です”
利用例
セキュリティ機能には影響がないが、機能仕様外の修正の場合
result = check_impact(False, False)
print(f”判定結果: {result}”)
この結果に基づき、影響分析報告書の根拠を記述します
5. 応用・注意点：現場で陥りやすい罠
実務で特に注意すべきは以下の点です。
「軽微」の解釈を誤らない
「機能自体は変わっていないから大丈夫」という思い込みは非常に危険です。たとえ不具合修正であっても、セキュリティ機能のロジックに影響を与える場合は、重大な変更（Major）とみなされる可能性があります。必ず「影響分析報告書 作成ガイダンス」を熟読してください。
事前レビューの徹底
申請書類を完成させてから不備を指摘されると、手戻りが非常に大きくなります。IPA等の認証機関が提供する事前レビュー制度は、必ず活用しましょう。
期限管理
認証維持・再評定の申請期限は「認証期限日の3か月前」です。この期限を過ぎると、たとえ製品に安全性が担保されていても、認証が失効するリスクがあります。余裕を持ったプロジェクト管理を心がけてください。
コメント