システムテストにおけるセキュリティ要件とは？

近年のサイバー攻撃の増加を受け、システムのセキュリティ対策は企業にとって喫緊の課題となっています。

特に新しいプロジェクトで顧客の機密情報を扱う場合、システムテストにおけるセキュリティ要件の定義方法に漠然とした不安を感じている方もいるかもしれません。

セキュリティ要件が不明確なままでは、情報漏えいやWebサイトの改ざん、最悪の場合には情報システムの停止といった重大なリスクに直面する可能性があります。

そこで今回は、まずセキュリティ要件とは何かを明確にし、その定義を怠ることで発生しうるリスクについて解説します。

そして総務省やIPAが公開している具体的なガイドラインを参考に、どのようなセキュリティ要件があるのか、またそれらをどう定義すれば良いのかを具体例を交えて紹介します！

▼テスト計画・テスト設計についてはこちら▼

セキュリティ要件とは？

システムテストにおけるセキュリティ要件とは、システムが外部からの不正アクセスや情報漏洩といった脅威からいかに安全に機能するかを明確にするための目標です。

これは単に「安全であること」という漠然としたものではなく、具体的な数値や条件で定義されます。

開発の初期段階でこのセキュリティ要件を明確に設定することは、後々の手戻りを防ぎ、プロジェクト全体の成功に不可欠です。

たとえば、

といった項目が挙げられます。

これらの要件は国際的なセキュリティ標準や業界基準、そして組織自身のセキュリティポリシーに基づいて策定されます。

定義しないと起こりうる3つのリスク

情報漏えい

セキュリティ要件を明確に定義しないままシステムを運用すると、最も懸念されるリスクの一つが情報漏えいです。

顧客の個人情報、企業の機密情報、あるいは金融データなど、システムが扱う情報は多岐にわたります。

これらの情報が外部に流出すれば企業の信用は地に落ち、顧客からの信頼を失うだけでなく、損害賠償問題に発展する可能性もあります。

例えばSQLインジェクションやクロスサイトスクリプティング（XSS）といった脆弱性が放置されていると、悪意のある第三者によってデータベースから情報が盗み出されたり、Webサイトの利用者の情報が抜き取られる危険性があります。

定義が曖昧だと、開発者もテスト担当者もどのような情報がどのレベルで保護されるべきか判断に迷い、結果としてセキュリティホールが残ってしまうことがあります。

特に顧客の機密情報を扱う新しいプロジェクトでは万が一の事態を防ぐためにも、厳格な情報保護の要件を設定し、それに沿ったテストを実施することが不可欠です。

Webサイトや情報の改ざん

セキュリティ要件が不十分な場合、Webサイトやシステム内の情報が改ざんされるリスクも高まります。

これは企業の顔ともいえる公式サイトが書き換えられたり、データベース内のデータが不正に操作されたりする事態を指します。

改ざんによってユーザーが誤った情報にアクセスしたり、サービスが正常に機能しなくなるだけでなく、企業の信頼性そのものが大きく損なわれます。

例えば不正ログインによってシステム管理者権限が乗っ取られ、Webサイトのコンテンツが改ざんされるケースがあります。

また、DDoS攻撃によりシステムへの正規アクセスが妨害されると、復旧対応中に他の攻撃が行われるリスクもあります。

このような攻撃は企業のブランドイメージを著しく傷つけ、復旧には多大な時間とコストを要します。

セキュリティ要件でどのようなアクセス経路が許可され、どのような認証方法が必須であるかを具体的に定めていなければ、脆弱な部分が悪用される可能性が高まります。

情報システムの停止

セキュリティ要件の欠如は、最終的に重要な業務システムの停止やサービス提供の中断といった深刻な事態を招く可能性があります。

これはサービスが利用できなくなるだけでなく、企業のビジネス活動そのものが停止してしまうことを意味します。

ランサムウェアによるシステムロック、マルウェア感染による機能不全、DDoS攻撃によるサーバーダウンなど、様々な脅威によってシステムは機能不全に陥ることがあります。

例えばシステムの脆弱性を突かれてマルウェアに感染すると、データが暗号化されてアクセス不能になったり、システムリソースが消費され尽くして応答しなくなります。

システムが停止すれば顧客はサービスを利用できなくなり、売上機会の損失だけでなくビジネスパートナーとの信頼関係にも影響を及ぼします。

セキュリティ要件でシステムの可用性や継続性をどのレベルで担保するかを明確にしておかないと、いざという時の復旧計画も立てづらく、結果として長期間のサービス停止に繋がりかねません。

このようなリスクを回避するためにはシステムの堅牢性を保証するセキュリティ要件の定義と、それに基づく徹底したテストが不可欠となります。

代表的なセキュリティ要件の種類

システム開発におけるセキュリティ要件は多岐にわたりますが、ここでは総務省の「セキュリティ要件ガイドブック」（2015）を参考に、特に重要な項目を解説します。

これらの要件を理解し、適切にシステムに組み込むことで強固なセキュリティ体制を築き、将来起こりうるリスクを未然に防ぐことが可能になります。

内部組織

内部組織に関する要件は、システム全体の安全性を担保するためにどのような組織体制を構築し、どのように運用していくかという点に焦点を当てています。

具体的にはプラットフォームのセキュリティに関する役割と責任を明確にし、適切なセキュリティ対策を実施する主体を定めることが求められます。

セキュリティ運用においてはこの組織が中心となり、誰がセキュリティ対策を担い、運用担当者や責任者は誰であるかを明確にし、責任の所在をはっきりとさせなければなりません。

この基盤がしっかりしていることで、セキュリティ問題が発生した際にも迅速かつ適切に対応でき、システム全体の信頼性を高めることに繋がります。

人的資源

人的資源のセキュリティ要件は、システムを管理・運用する従業員や外部の契約者など人に関わるセキュリティ対策を指します。

雇用契約書に守秘義務などのセキュリティに関する条項を明記することはもちろん、雇用期間中は定期的なコンプライアンス研修やセキュリティ教育・訓練を実施し、組織のガバナンスを維持する意識や、そのための手順・スキルを身につけさせることが重要です。

万が一、従業員による悪質な内部不正があった場合には、懲戒手続きを適切に執り行う必要があります。

また、雇用契約終了後も事業に関する機密事項を口外しないよう、雇用終了後についてもセキュリティ上の遵守事項を設定するなど、雇用前から雇用後まで長期的な視点での対策が求められます。

資産に対する責任

資産に対する責任の要件は、組織が保有する情報資産を適切に管理し保護するための対策です。

この要件を満たすためには、まず守るべき情報資産すべてを特定することから始めます。

これには、利用者の個人情報や、システムの基盤となる機器・ソフトウェアなどが含まれます。

特定した資産に対しては、適切な管理を実施し、資産利用の許容範囲に関する規則を明確にすることが不可欠です。

また従業員や委託業者に対しては、組織との契約が終了した際に関連する資産を速やかに返却するよう求めることも重要です。

資産の所在と状態を常に把握し、適切な管理体制を維持することで、不正な持ち出しや紛失のリスクを低減できます。

情報分類

情報分類とは、上記で特定した情報資産をセキュリティ上の重要性に応じて分類し、適切なラベル付けを行うことです。

これにより情報資産の重要度に応じたセキュリティ対策を講じることが可能になります。

例えば、「重要度の高いデータベースには、権限の高い人しかアクセスできないようにする」といった対策が考えられます。

また情報を適切に分類しラベル付けすることで、必要な時に必要な情報にアクセスできるという利便性も向上します。

利用者の個人情報については、個人情報保護法に則った法的対応が必要となり、学習記録データなども機密情報として厳重な保護が求められるため、その重要性に応じて情報を取り扱うことが必須となります。

アクセス制御

アクセス制御はシステムへのアクセスを適切に管理するための重要なセキュリティ要件です。

この要件には多岐にわたる項目が含まれますが、個人情報保護法にも配慮したアクセス制御方針の策定が基盤となります。

具体的にはシステム運用者および利用者に対して、アクセス権の割り当て、更新、削除を適切に実施すること、特にシステム運用者に対する特権的アクセス権限は厳しく割り当て・制限することが求められます。

またシステム運用者および利用者へパスワードを割り当て、それを保護するための対策も不可欠です。

定期的なアクセス権の管理と更新、そして安全なログオン手順（認証装置）の制御も重要です。

基本的な考え方として、「必要なときに、必要な人に、必要な情報だけアクセスできること」がアクセス制御の根本的な要件となります。

さらにプログラムソースコードへのアクセスも制限し、不正な改ざんを防ぐことも含まれます。

物理的セキュリティ

物理的セキュリティは、施設や区画、装置などに対する物理的な脅威からシステムを守るための措置を指します。

これには地震や火災といった災害、停電、盗難、破壊などが含まれます。

物理的なセキュリティを高めるためには、例えばオフィスや重要設備が設置されている部屋に対して入退室制限を設けるなど、物理的なセキュリティ境界を設定しそれを厳格に運用することが重要です。

監視カメラの設置、警備員の配置、生体認証システム導入なども有効な対策となります。

物理的なアクセスを制限し、環境要因から保護することで、システムへの不正な侵入や機器の損傷を防ぎサービスの安定稼働を支えます。

運用のセキュリティ

運用のセキュリティとは、システムを安全に運用し続けるための実践的な対策です。

これにはヒューマンエラーを防ぐための仕組み作りが含まれます。

例えば操作ミスによって重要なデータが消去されることのないよう、分かりやすいマニュアルを用意し、従業員への周知徹底を図ることが挙げられます。

またシステムの安定的な運用を継続するためには、現在の利用状況だけでなく将来的な利用状況も考慮に入れた上で十分なシステムリソースやマシンスペックを用意することが推奨されます。

システムの監視体制を整え、異常を早期に検知し対応する仕組みも重要です。

定期的なバックアップの取得や、災害時・障害発生時の復旧手順の確立など緊急事態に備える対策も運用のセキュリティに欠かせない要素です。

セキュリティ要件定義書の記載例

セキュリティ要件を実際にシステムに適用するためには、その内容を明確に記述した「セキュリティ要件定義書」の作成が不可欠です。

総務省の「セキュリティ要件ガイドブック」（2015）では、具体的な記載項目が例示されています。

ここでは、その中でも特に重要な項目とその意味について解説します。

認証

認証に関する要件は、システムにアクセスするユーザーが正当な本人であることを確認するための仕組みを定めます。

単にIDとパスワードの組み合わせだけでなく、多要素認証（MFA）の導入や、パスワードポリシー（文字数、複雑性、有効期限など）の厳格化が含まれます。

例えば特定のアクションを行う際にパスワードとは別にスマートフォンアプリでの承認を求めるなど、複数の手段で本人確認を行うことで不正ログインのリスクを大幅に低減できます。

これによりシステムへのアクセスが確実に正当なユーザーに限定され、不正な侵入を防ぐ第一の砦となります。

認可（アクセス制御）

認可、すなわちアクセス制御の要件は、認証されたユーザーがシステム内でどのような操作を許可されるか、どの情報にアクセスできるかを細かく規定するものです。

部署や役職に応じて閲覧・編集・削除といった権限を明確に設定し、必要最小限の権限のみを付与する「最小権限の原則」を徹底します。

例えば一般社員には顧客情報の一部閲覧権限のみを与え、個人情報の編集や削除は特定の管理者のみに許可するなど役割に応じた厳格な権限設定を行います。

これにより、たとえ不正アクセスがあったとしても被害を最小限に抑えることが可能になります。

セッション管理

セッション管理の要件は、ユーザーがシステムにログインしている間の一連の通信（セッション）を安全に保つためのものです。

セッションIDの予測困難性、セッションタイムアウトの設定、セッションハイジャック対策などが含まれます。

例えば一定時間操作がない場合には自動的にログアウトさせる、セッションIDを推測されにくい複雑なものにする、通信経路を暗号化するといった対策が挙げられます。

これらが適切に設定されていないと、悪意のある第三者にセッションを乗っ取られ不正にシステムを操作される危険性があります。

パラメータ

パラメータに関する要件は、システムに送信されるデータ（パラメータ）が想定外の形式や内容でないかを検証するためのルールを定めます。

これには入力値の型、範囲、長さのチェックなどが含まれます。

例えば年齢入力欄に数値以外の文字が入力された場合や、想定外に長い文字列が入力された場合にエラーとする、といった対策です。

これにより、SQLインジェクションやクロスサイトスクリプティング（XSS）といった悪意のある入力によってシステムが攻撃されるのを防ぎます。

文字列処理

文字列処理の要件は、システムが受け取った文字列データを安全に処理するためのルールです。

特にユーザーからの入力をそのままデータベースに保存したり、Webページに表示すると、悪意のあるスクリプトが実行されるなどの脆弱性を生む可能性があります。

そのため入力された文字列に含まれる特殊文字のエスケープ処理（無害化）や、文字コードの適切な管理が求められます。

これによりWebサイトの改ざんや情報漏洩に繋がるクロスサイトスクリプティング（XSS）などの攻撃を防ぎます。

HTTPS

HTTPSに関する要件は、Webサーバーとクライアント（ブラウザなど）間の通信を暗号化し、盗聴や改ざんから保護するためのものです。

具体的には全ての通信をHTTPS化し、TLS（Transport Layer Security）バージョンを最新の安全なものに設定することなどが挙げられます。

SSL/TLS証明書の適切な管理や、証明書の有効期限切れによるリスク回避も含まれます。

これにより、通信経路上でのデータの盗聴や改ざんを防ぎ、ユーザーが安心してシステムを利用できる環境を提供します。

Cookie

Cookieに関する要件は、Webサイトがユーザーのブラウザに保存する情報（Cookie）を安全に管理するためのルールです。

これにはCookieのセキュリティ属性（HttpOnly, Secure属性など）の設定、有効期限の管理、保存する情報の制限などが含まれます。

例えばHttpOnly属性を付与することでJavaScriptからのアクセスを制限し、クロスサイトスクリプティング（XSS）攻撃によるCookieの窃取を防ぎます。

また個人情報などの機密情報をCookieに直接保存しない、保存する場合は暗号化するなど、情報保護の観点からの対策も重要です。

提出物

提出物に関する要件は、システムテストにおけるセキュリティ要件が最終的な成果物としてどのようにまとめられ、誰に提出されるべきかを定めます。

これにはセキュリティテスト計画書、テスト結果報告書、脆弱性リスト、修正計画などが含まれます。

これらの文書はセキュリティ対策が適切に行われたことの証拠となり、関係者間での情報共有を円滑に進める上で不可欠です。

定義されたセキュリティ要件が実際に満たされていることを客観的に証明するためにも、これらの提出物を正確かつ網羅的に作成することが求められます。

主なセキュリティ要件ガイドライン

システムテストにおけるセキュリティ要件を定義する上で、多くの組織が参考にするガイドラインが存在します。

これらのガイドラインは最新の脅威動向やセキュリティ技術の進展を考慮に入れ、システムの安全性を高めるための具体的な指針を提供しています。

ここでは特に日本国内で広く活用されている主要なガイドラインをいくつか紹介します。

総務省「セキュリティ要件ガイドブック」

総務省が発行している「セキュリティ要件ガイドブック」（2015年版）は情報システムの調達や開発において、セキュリティを考慮するための基本的な考え方や具体的な要件の例をまとめたものです。

このガイドブックは情報システムに関連する多様な脅威に対応できるよう、セキュリティ対策の全体像を捉える上で非常に役立ちます。

内部組織の体制、人的資源の管理、情報資産への責任、情報の分類、アクセス制御、物理的なセキュリティ対策、そして日々の運用のセキュリティに至るまで、幅広い領域で具体的な要件が提示されています。

これはシステム開発の初期段階でセキュリティ目標を設定する際に、非常に実践的な指針となるでしょう。

情報処理推進機構「IT製品の調達におけるセキュリティ要件リスト」

情報処理推進機構（IPA）が提供する「IT製品の調達におけるセキュリティ要件リスト」は、IT製品やサービスを調達する際に、考慮すべきセキュリティ要件をまとめたものです。

このリストは製品選定の段階からセキュリティの観点を取り入れることを促し、将来的なセキュリティリスクを低減することを目指しています。

具体的な技術要件から運用に関する要件まで多岐にわたる項目が網羅されており、特に外部からIT製品やサービスを導入する際に、それらが備えるべきセキュリティ機能や満たすべき基準を明確にする上で非常に有用です。

このリストを参考にすることで漠然とした不安を具体化し、調達段階からセキュリティを考慮したシステム構築を進められます。

情報処理推進機構「ユーザのための要件定義ガイド」

同じくIPAが発行する「ユーザのための要件定義ガイド」は、システム開発における要件定義のプロセスをユーザー側の視点から分かりやすく解説しています。

このガイドはセキュリティ要件に限らず、システム全体の要件を漏れなく、かつ明確に定義するための手順や注意点を示しています。

特にユーザー部門と開発部門との間で認識の齟齬が生じやすい要件定義フェーズにおいて、双方の理解を深め、円滑なコミュニケーションを促進するためのヒントが豊富に含まれています。

セキュリティ要件もユーザーが求める「安心」や「信頼」という漠然とした期待を、具体的な機能や対策に落とし込むための重要なステップであるため、このガイドを参照することは、より実践的なセキュリティ要件定義に繋がるでしょう。

セキュリティ要件定義のコツ

システムが抱えるセキュリティ脆弱性への不安を解消し堅牢なシステムを構築するためには、セキュリティ要件を明確に定義することが不可欠です。

しかし具体的にどのように進めれば良いのか迷うこともあるかもしれません。

ここでは効果的なセキュリティ要件定義のためのいくつかのコツを紹介します。

初期段階で検討する

まずセキュリティ要件は、システム開発の初期段階から検討を開始することが重要です。

開発プロセスのできるだけ早い段階でセキュリティの観点を取り入れることで、後からの大幅な手戻りを防ぎ、結果的に開発コストと時間を削減できます。

初期段階で関係者全員がセキュリティの重要性を共有し、共通認識を持つことが、成功への第一歩です。

具体的な形で記述する

次に、セキュリティ要件は漠然とした表現ではなく、具体的かつ測定可能な形で記述することが求められます。

例えば「システムは安全でなければならない」という抽象的な表現では、何を達成すべきかが不明確です。

「不正ログイン試行が5回連続で失敗した場合、アカウントをロックする」のように、具体的な数値や振る舞いを定義することで、開発者もテスト担当者もその要件を満たしているか否かを明確に判断できるようになります。

このような具体的な要件はテスト計画にも直接反映され、セキュリティテストの効率と精度を向上させます。

最新の情報をチェックする

また最新のセキュリティ脅威の動向を常に把握し、それらを要件定義に反映させることも不可欠です。

サイバー攻撃の手法は日々進化しているため、過去の知識だけに頼るのではなく継続的な情報収集と学習が求められます。

OWASP Top 10などの一般的な脆弱性リストを参照するだけでなく、業界特有の脅威やシステムが扱うデータの機密性に応じたリスクを評価し、それらに対する対策を要件に盛り込むことが重要です。

一度決めたら終わりではない！

サイバー攻撃の手法は日々進化しており、新たな脆弱性が発見されることもあります。

そのためシステム開発のライフサイクル全体を通じて、常に最新の脅威に対応できるよう見直しと更新が求められます。

特に新しいプロジェクトで顧客の機密情報を扱う際などは、その重要性が増します。

漠然とした不安を抱えるのではなく体系的にセキュリティ要件を定義し、それをテスト計画に組み込むことで、何が起きても安全なシステムをリリースできる状態を目指すことが重要です。

まとめ

システムテストにおけるセキュリティ要件は、単に「安全であること」という抽象的な概念ではなく、具体的なリスクを回避しシステムの信頼性を確保するための明確な目標です。

セキュリティ要件を定義しないままシステムを運用することは、情報漏えい、Webサイトや情報の改ざん、そして情報システムの停止といった重大なリスクを招く可能性があります。

これらのリスクを未然に防ぐためには、開発の初期段階からセキュリティ要件を明確にし、継続的に見直していくことが不可欠です。

総務省や情報処理推進機構（IPA）が提供するガイドラインは、セキュリティ要件を具体的に定義し、実践するための invaluable な指針となります。

これらのガイドラインで示されている認証、認可、セッション管理、パラメータ、文字列処理、HTTPS、Cookie、提出物といった具体的な項目を要件定義書に落とし込み、システムのライフサイクル全体を通じてセキュリティ対策を徹底することで、強固なシステムを構築できます。

常に最新のセキュリティ脅威の動向を把握し、要件定義に反映させること、そして具体的な数値や振る舞いで要件を記述することが、効果的なセキュリティ要件定義の鍵です。

この記事で解説した知識と実践的なコツを活用し、ぜひ自身の担当するシステムをより安全なものへと導いてください！

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ