セキュリティ機能の設計・実装・構成管理

【趣旨】

「ソフトウェアが行うべきこと（What）」を定めたセキュリティの要件定義に 則って、「ソフトウェアが行う方法(How)」を設計し、この設計に基づいて確実 な実装を行わなければならない。

また、ソフトウェアの大規模化、複雑化が進むにつれて、開発の初期段階にお いて要件や設計を完全に定義することは困難となり、仕様の変更は避けられな い事象となりつつある。こうした変更は、セキュリティの脆弱性を生じさせる 原因となるおそれがあるため、適切な構成管理が重要である。

本項では、セキュリティ機能の設計と実装及び構成管理について解説する。

5.1 セキュリティの設計

ソフトウェアのセキュリティ要件定義により明確にされた要求事項を満たすソフトウェア を開発するためには、その要求を満たすための具体的な機能を設計しなければならない。こ の際、セキュリティの実装の段階で齟齬が発生しないように、設計書を正確に具体化してい く必要がある。

また、あらゆる脅威を想定し、それらに対して完全な措置を講ずることは、実際には困難 であることから、セキュリティが侵害された場合の対策をあらかじめ設計をしておく必要が ある。

    (1) セキュリティの設計

 ポリシー及び実施規程とセキュリティの要件定義に準拠してセキュリティの設計を 行うこと。

セキュリティの要件定義を精査した上でセキュリティに関する設計を行う。セキュリティ の設計は、セキュリティ要件定義を満たす網羅的な構成を取る必要がある。

加えて、セキュリティの設計は本学が遵守すべきセキュリティ事項を網羅しているポリシ ー及び実施規程を前提条件とした内容となっていることを確認しなければならない。これに よって、強力な認証やアクセス制御、妥当性の検証など、強固なセキュリティの設計を行う 必要がある。また、客観性や網羅性を保つ観点から、ポリシー及び実施規程に加えて、その 他の信頼できる文献を併用することも有益である。

≪参考文献≫

・ ISO/IEC 15408 Common Criteria (JIS X 5070)

IT 製品及びシステムのセキュリティ機能の開発を対象とした評価規格を示したもの。概 説（Part1）、セキュリティ機能要件（Part2）、セキュリティ保証要件（Part3）の三部か ら構成される。CC のPart2は、セキュリティ機能要件のセットであり、セキュリティ設 計・実装の参考書として有効に活用できる。

・ ISO/IEC 27002（JIS Q 27002）

組織の情報セキュリティマネジメントに基づいて推奨されるべきセキュリティコントロ ールを体系的に定めた規格を示したもの。

・ NIST Special Publication 800-53「Recommended Security Controls for Federal Information Systems」

米政府の各省庁における情報システムの分類された結果（Low/Moderate/High）に基づき 実施すべきセキュリティコントロールのベースラインセットを示したもの。

    (2) 設計書におけるセキュリティ機能の具体化

 セキュリティの設計を設計書において具体化し、記述すること。

ソフトウェアの設計は、作業段階に応じて基本設計から詳細設計へと具体化され、設計書 として文書化される。

ソフトウェアの開発規模、複雑性等によって、どのレベルまで詳細な設計書を必要とする かは異なるが、実装段階での齟齬を防止するため、セキュリティ機能を具体化し、明確に記 述しておく必要がある。

【セキュリティ機能として、セキュリティの管理機能が必要な場合】

    (3) セキュリティの管理機能の設計

 開発するソフトウェアが運用される際に利用されるセキュリティ機能の管理機能を 設計すること。

「管理機能」とは、真正確認、権限管理等のセキュリティ機能を管理するための機能のほ か、証跡保全の機能等の故障、事故、障害等の発生時に行う対処及び復旧にかかわる機能等 を指す。これらの機能をソフトウェアのセキュリティ要件に応じて、セキュリティの管理機 能をソフトウェアに組み込む必要がある。

【開発するソフトウェアに重要なセキュリティ要件がある場合】

    (4) ST評価・ST確認の実施

 重要なセキュリティ要件があるソフトウェアに対して、セキュリティ設計仕様書

（Security Target）の評価・確認を実施すること。

開発するソフトウェアに重要なセキュリティ要件があると判断されたソフトウェアについ ては、セキュリティ要件定義の結果を受けて、セキュリティ設計仕様書（Security Target）を 策定し、セキュリティ機能の設計において、第三者機関によるST評価・ST確認を受ける必 要がある。

【権限管理の設計が必要な場合】

5.2 設計のポイント - 権限管理

ソフトウェアにおいて要機密情報の漏えいなどを防止する手法のうち一般的なものとして、

権限管理機能がある。『権限管理』とは、識別と真正確認の結果である『認証』に対して、『ア クセス制御』すなわち、権限の割当てや制限を強制することである。

    (1) 権限管理対象とする情報の識別

 ソフトウェアで権限管理を行うべき情報を識別すること。

ソフトウェアのセキュリティ要件を定義する際に実施した当該ソフトウェアで取り扱う情 報の格付けの結果に基づき、「権限管理」すべき情報を識別しなければならない。その上で、

必要とされる権限管理の強度を慎重に判断する必要がある。

この際、ソフトウェアが取り扱う行政事務情報以外の重要な情報にも注意する必要がある。

特に識別子、パスワード、暗号鍵、ソースコード、パラメータ、セッション情報、監査ログ 等のシステム構成情報については、慎重な検討を要する。

    (2) 権限管理の設計

 ポリシー及び実施規程に準拠して、ソフトウェアのセキュリティ要件に応じた識別

（特定された一意の識別子など）、認証（知識・所有・生体による認証）に基づいた 権限管理機能及びそれを支援するための暗号、電子署名、証跡管理等の機能を設計 すること。

 ポリシー及び実施規程に準拠して、識別された要保護情報に適切な権限管理を行う こと。

 ポリシー及び実施規程に準拠して、プログラムが所有する特権を特定し、必要最小 限の権限に制限すること。

権限管理対象の識別結果に基づいて、権限管理の設計を行う。この際、情報システム運用・

管理規程「第七章  アカウント管理」に準拠した十分な強度の権限管理を設計し、識別され た情報を保護する必要がある。特に、システム構成情報はソフトウェアのセキュリティにか かわる情報であり、システム構成情報のセキュリティが侵害された場合、セキュリティ機能 が迂回されたり、無力化される可能性があるため、慎重な権限管理の設計が必要である。

また、権限管理の設計においては、必要な情報に適切な権限管理を行い、不要な権限を割 り当てないことが重要である。

【情報の妥当性の検証に係る設計が必要な場合】

5.3 設計のポイント - 情報の妥当性の検証

ソフトウェアは、入力された情報を正確に処理し、その結果を出力することをその基本的 な目的としている。この目的を確実に達成するため、妥当性の検証によって、処理の誤りや 悪用される可能性のある情報などから、情報と処理方法の完全性を保護する必要がある。

特に悪意のある情報の入力によってソフトウェアの完全性を侵害する攻撃は、現在ソフト ウェアに対する最も重大なセキュリティ脅威となりつつあり、その対応に注意が必要である。

    (1) 妥当性検証を行うべき情報の識別

 ソフトウェアで妥当性検証を行うべき情報を識別すること。

 利用者及び外部プログラムとやり取りするものを含めてすべての入力される情報に ついて、悪意ある情報が含まれると仮定した上で、妥当性の検証を行うこと。

「妥当性の検証」を行うべき情報を識別しなければならない。

この際、特にソフトウェアに「入力」される情報には注意を払う必要がある。入力される 情報は常に信頼できるものとは限らない。すべての入力される情報には悪意ある情報が含ま れると仮定した上で、識別子、パスワード、入力フォームといった開発者が「入力を想定し ている情報」だけではなく、「入力を許可している情報」に対しても識別を行わなければなら ない。

なお、外部の利用者による入力だけでなく、当該ソフトウェア以外の外部のプログラム等 とやり取りされる情報についても、ソフトウェアの内部で検証を行う必要がある。

    (2) 情報の排除

 悪用される可能性のある情報を識別し、排除すること。

情報の排除とは、悪用される可能性のある情報の型等を定義し、当該情報が含まれる場合 に不正な部分の除去、置換等の処理を行う手法である。

悪用される可能性のある情報としては、プログラム内部や最終的な出力において特別な意 味を有する特殊文字がある。情報の排除は、可能な限り手作業を排し、自動化されたプロセ スを実装することが望ましい。

なお、処理をOS やミドルウェアなど外部のプログラムに引き渡す場合は、情報を使用す るプログラムと検証するプログラムが異なることから、作業漏れが発生しやすい。こうした 場合においても悪用される可能性のある情報を確実に排除しておく必要がある。

    (3) 入力の制限

 入力を許可する情報の型等を定義して、合致した情報のみの入力を許可すること。

 悪用される可能性のある情報の型等を定義して、その定義に合致する情報の入力を 拒否すること。

 許可されない入力に対しては、リスクを想定して適切なエラー処理を実施すること。

入力の制限とは、許可した情報以外の入力を拒絶し、リスクに応じて適切なエラーの処理

（再確認、終了、警告等）を行う手法である。

これには、入力を許可する情報の型等を定義して、その定義に合致した情報のみの入力を 許可する手法と悪用される可能性のある情報の型等を定義し、その定義に合致した情報の入 力を拒否する手法がある。これらのうち、適切な手法について検討し、実施する必要がある。

5.4 セキュリティの実装を支援するための枠組み

セキュリティの実装は、個々のプログラマのスキルによって差異が生じがちである。責任 者の視点から重要な点は、プログラマ個々の知識に依存せず、コーディング規約の統一等に よって開発方法を標準化することで、実装時に混入する脆弱性を最小限に抑制する点にある。

    (1) コーディング規約におけるセキュリティ

 最新のセキュリティ技術を反映したセキュアコーディングに関する注意事項を記載 したコーディング規約を作成すること。

 セキュアコーディングに関する注意事項について、定期的にプログラマに教育を実 施し、その浸透を図ること。

プログラミング作業の品質と保守性を向上させるために、「コーディング規約」を作成する。

「コーディング規約」は命名、スタイル、コメント、改行・インデント、関数・クラス・変