2. 情報システムの企画・設計・開発・運用でのセキュリティ確保の推進又は支援に関すること(4/8)~セキュリティ機能の設計・実装~

情報処理安全確保支援士

2-4 セキュリティ機能の設計・実装

概要 (引用)

セキュリティ要件及びアーキテクチャに基づくセキュリティ機能の設計・実装について,必要な指導・助言を行い,支援する。

要求される知識

・ セキュリティ機能(認証,アクセス制御,暗号化,ログの取得,セッション管理など)に関する知識
・ ソフトウェア,ハードウェアに関する知識
・ ITセキュリティ関連の規格(CC/CEM,FIPS140など)に関する知識
・ ITセキュリティ関連の認証制度(JISEC,JCMVPなど)に関する知識
・ 耐タンパ性,サイドチャネル攻撃に関する知識

要求される技能

・ セキュリティ機能の設計書,テスト計画書をセキュリティの観点からレビューする能力
・ セキュリティ機能の実装方式を設計する能力

セキュリティ機能の設計・実装

情報処理安全確保支援士は、システム開発におけるセキュリティ機能の設計・実装フェーズにおいて、セキュリティ要件やアーキテクチャに整合した設計・開発がなされるよう助言・支援を行う役割を担います。これは、安全なシステムを構築する上で極めて重要な活動です。

1. セキュリティ要件・アーキテクチャに基づく設計支援

  • 支援士は、要件定義フェーズで定められた**セキュリティ要件(例:認証・認可、暗号化、ログ管理など)**と、アーキテクチャ構成に整合する形で、具体的なセキュリティ機能の設計を技術的に支援します。
  • 設計時の主な観点:
    • 最小権限の原則に基づくアクセス制御設計
    • 通信やデータの暗号化方式の選定(例:TLS、AES、公開鍵暗号など)
    • ログの取得要件と監査証跡の保持方針
    • セッション管理の設計(有効期限、再認証など)
    • セキュリティ例外発生時の適切なエラーハンドリング

      例:Webアプリにおいて、OAuth 2.0ベースの認可設計やCSRF/XSSの対策設計を助言

2. セキュアコーディング・実装支援

  • 実装フェーズでは、開発者に対してセキュアプログラミングの実践を指導・支援します。
  • 支援士が助言する具体例:
    • 入力値検証の実装(バリデーションの徹底、SQLインジェクション対策など)
    • パスワードのハッシュ化処理(例:bcrypt、PBKDF2)
    • 例外処理に機密情報を含めない
    • 脆弱なライブラリや非推奨APIの使用回避
  • さらに、**セキュリティテスト(静的解析、脆弱性スキャン)**の導入も支援します。

3. 実装全体のセキュリティ整合性の確認とレビュー

  • セキュリティ機能が要件・設計に基づいて正しく実装されているかどうかを確認するため、設計書やソースコードのレビュー支援を行います。
  • 特に、
    • 機能の実装漏れ
    • 設計との乖離
    • セキュリティ上のミス(認可漏れ、ログ未出力など)
      に注目します。

期待される成果と効果

  • 開発工程でのセキュリティ欠陥の早期発見と是正
  • システムリリース後の脆弱性起因のインシデント防止
  • 開発チームへのセキュリティ教育・スキル向上

まとめ

情報処理安全確保支援士は、セキュリティ要件とアーキテクチャに基づいて、セキュリティ機能の設計・実装が適切に行われるように助言・支援する役割を担います。これにより、システムの開発段階で脆弱性の少ない、安全性の高い構造を実現し、システム全体の信頼性向上に貢献します。

ITセキュリティ関連の規格

ITセキュリティ関連の規格は、情報システムや製品が備えるべきセキュリティ機能の基準や評価方法を定めたものであり、製品の信頼性や安全性を保証するうえで非常に重要です。以下に代表的な規格である CC/CEMFIPS 140 を中心に解説します。

Common Criteria(CC)

正式名称:ISO/IEC 15408
国際的に広く利用されている**IT製品のセキュリティ評価の共通基準(Common Criteria)**です。

  • 目的:IT製品が備えるべきセキュリティ機能とその保証レベル(信頼性)を国際的に共通の基準で評価すること
  • 評価対象:OS、ファイアウォール、スマートカード、暗号モジュールなど
  • 評価レベル(EAL:Evaluation Assurance Level)

    • EAL1~EAL7まで段階的に信頼性を定義
    • 高いEALほど高度な設計・検証が要求される(ただしコストや工数も増加)
レベル 内容の例
EAL1 機能が存在することの確認
EAL4 市販製品として妥当な保証レベル(実用でよく使われる)
EAL7 形式的な設計と高保証(高度な証明が必要)

Common Evaluation Methodology(CEM)

  • CCの評価方法を定めたガイドライン
  • 各評価レベルに対する審査基準・手順・証拠の種類などを詳細に規定
  • 評価機関がCC評価を行う際の共通手順書として機能

FIPS 140(Federal Information Processing Standards 140)

概要

  • アメリカ国立標準技術研究所(NIST)が定めた暗号モジュールのセキュリティ要求仕様
  • 現在は「FIPS 140-3」が最新版(FIPS 140-2は移行中)

目的

暗号モジュール(例:暗号化ライブラリ、ハードウェアセキュリティモジュール)に対して、機密性・完全性を確保するための機能や物理的保護の基準を明確に示す。

セキュリティレベル(Level 1~4)

レベル 特徴
Level 1 最低限のセキュリティ機能(ソフトウェア実装可能)
Level 2 改ざん検出、ロールベースアクセス制御
Level 3 不正アクセス時のキー消去(鍵の自動破棄)など
Level 4 最も厳格。環境攻撃(温度・電圧など)にも耐性あり
  • 多くの政府機関や金融機関は、FIPS 140-2/3 Level 2以上の準拠を要件とする

その他の関連規格(参考)

規格名 概要
ISO/IEC 27001 情報セキュリティマネジメントシステム(ISMS)の国際標準
ISO/IEC 19790 FIPS140と同様の暗号モジュールの国際規格(FIPS 140-3のベース)
NIST SP800シリーズ 暗号・リスク管理などに関するNISTのガイドライン集

ITセキュリティ関連の認証制度

ITセキュリティ関連の認証制度は、情報システムやIT製品が一定のセキュリティ基準を満たしていることを第三者機関が評価・認証する制度です。製品やサービスの安全性を客観的に示すために活用されます。ここでは代表的なJISECJCMVPを中心に説明します。

JISEC(Japan Information Technology Security Evaluation and Certification Scheme)

日本情報セキュリティ評価・認証制度

  • 概要
     日本におけるCommon Criteria(CC:ISO/IEC 15408)に基づくIT製品のセキュリティ評価・認証制度
  • 運営主体
     IPA(独立行政法人 情報処理推進機構)と認定評価機関
  • 評価対象
     OS、ファイアウォール、暗号化製品、ICカード、ミドルウェアなど

特徴

項目 内容
評価基準 ISO/IEC 15408(Common Criteria)
評価レベル EAL1~EAL7(※通常はEAL4までの取得が多い)
国際相互承認 CCRA(Common Criteria Recognition Arrangement)により、他国でも認証が通用する
認証マーク 認証された製品にはJISECロゴが付与され、信頼性を示す

JCMVP(Japan Cryptographic Module Validation Program)

暗号モジュール検証制度(日本版FIPS 140)

  • 概要
     日本で運用されている暗号モジュールの検証制度であり、FIPS 140-2に準拠
  • 運営主体
     **NICT(情報通信研究機構)**が実施、**評価は認定された第三者機関(評価機関)**が担当
  • 評価対象
     暗号ライブラリ、HSM(ハードウェアセキュリティモジュール)、VPN機器など

特徴

項目 内容
評価基準 FIPS 140-2(国際的な暗号モジュールのセキュリティ要件)
レベル Level 1~4(レベルが上がるほど物理的・論理的保護が強化)
対象 主に官公庁や重要インフラ事業者が使用する製品での要件に使用される
相互承認 日本国内での認証にとどまる(米国NISTによるFIPS 140-3とは別)

その他の参考制度

制度名 概要
FIPS 140(米国) 米国NISTによる暗号モジュール検証制度。JCMVPのベース
ISO/IEC 19790 暗号モジュールの国際規格(FIPS 140-3と整合性あり)
ISMAP 政府向けクラウドサービスのセキュリティ評価・登録制度(日本)
PCI DSS クレジットカード業界におけるセキュリティ基準(民間主導)