セキュリティ要件の決め方とは？定義すべき項目一覧を解説

現代のビジネス環境において、企業活動はITシステムと切り離せない関係にあります。デジタルトランスフォーメーション（DX）が加速する一方で、サイバー攻撃は年々多様化・巧妙化しており、企業が保有する情報資産は常に深刻な脅威に晒されています。このような状況下で、自社の貴重な情報資産を守り、事業を継続していくためには、場当たり的な対策ではなく、体系的かつ網羅的なセキュリティ対策が不可欠です。

その根幹をなすのが「セキュリティ要件定義」です。セキュリティ要件とは、システムや情報をどのような脅威から、どのように守るのかを具体的に定めたルールのことです。この要件を明確に定義することで、はじめて効果的なセキュリティ対策を計画・実行し、その実効性を評価できます。

しかし、「セキュリティ要件と言われても、何から手をつければいいかわからない」「具体的にどのような項目を決めれば良いのかイメージが湧かない」と感じる担当者の方も多いのではないでしょうか。

この記事では、セキュリティ要件の基本的な考え方から、その重要性、具体的な決め方のステップ、そして定義すべき項目の一覧までを網羅的に解説します。セキュリティ対策の第一歩を踏み出し、自社の情報資産を確実に保護するための羅針盤として、ぜひ最後までご一読ください。

1 セキュリティ要件とは
2 セキュリティ要件が重要視される理由
3 セキュリティ要件を定義する3つのメリット
4 セキュリティ要件の決め方4ステップ
5 セキュリティ要件で定義すべき項目一覧
6 セキュリティ要件定義を成功させるためのポイント
7 まとめ

セキュリティ要件とは

セキュリティ要件とは、企業が保護すべき情報資産を、様々な脅威から守るためにシステムや組織が満たすべき具体的な基準やルールのことを指します。これは、情報セキュリティポリシーという企業全体の基本方針を、より具体的なシステム開発や運用、組織運営のレベルに落とし込んだものです。

簡単に言えば、「誰が、どの情報に、どこまでアクセスして良いのか」「システムは、どのような攻撃に耐えられなければならないのか」「万が一、問題が発生した際に、どのように検知し、対応するのか」といった、セキュリティに関する「決めごと」の総体と言えます。

これらの要件は、技術的な側面に留まらず、物理的な環境、従業員の行動規範、組織の体制といった幅広い領域をカバーします。効果的なセキュリティ体制を構築するためには、まずこの「セキュリティ要件」を明確に定義することがすべての出発点となります。

セキュリティ要件の具体例

言葉の定義だけでは、具体的なイメージが掴みにくいかもしれません。ここでは、セキュリティ要件が実際にどのような形で定められるのか、いくつかの具体例を挙げて解説します。

認証に関する要件
- 例1： 業務システムへのログインには、IDとパスワードに加え、スマートフォンアプリによるワンタイムパスワード認証（多要素認証）を必須とする。
- 例2： パスワードは最低12文字以上とし、英大文字、英小文字、数字、記号をそれぞれ1文字以上含む必要がある。また、過去5世代以内に使用したパスワードの再利用は禁止する。
- 解説： これらは、なりすましによる不正アクセスを防ぐための要件です。特に多要素認証は、ID・パスワードが漏洩した場合でも不正ログインを防ぐ強力な手段となります。
アクセス制御に関する要件
- 例1： 顧客個人情報が格納されているデータベースへのアクセスは、個人情報管理責任者が許可した特定の担当者（3名）のIPアドレスからのみ許可する。
- 例2： 営業部門の従業員は、自身が担当する顧客の情報のみ閲覧・編集が可能とし、他部署の顧客情報へのアクセスは原則として禁止する。
- 解説： これらは「知る必要のない情報にはアクセスさせない」という、権限分離の原則（最小権限の原則）に基づいています。内部不正や、アカウントが乗っ取られた際の被害拡大を防ぐ上で非常に重要です。
データの保護に関する要件
- 例1： ノートPCに保存するすべてのファイルは、ディスク全体を暗号化する機能（BitLockerなど）を有効にしなければならない。
- 例2： 顧客向けのWebアプリケーションとブラウザ間の通信は、すべてTLS 1.2以上のプロトコルを使用して暗号化する。
- 解説： PCの盗難・紛失時や、通信経路上での盗聴による情報漏洩を防ぐための要件です。特に機密性の高い情報を取り扱う際には必須の対策となります。
ログ管理に関する要件
- 例1： サーバーやネットワーク機器の操作ログ、認証ログはすべて収集し、改ざん不可能な状態で最低1年間保管する。
- 例2： 機密情報へのアクセスがあった場合や、認証に5回連続で失敗した場合には、即座に管理者へアラート通知を行う。
- 解説： 不正アクセスやインシデントが発生した際に、その原因を調査し、被害範囲を特定するためにログは不可欠な情報源です。また、異常を早期に検知するための仕組みも重要な要件となります。

これらの例からもわかるように、セキュリティ要件は抽象的な目標ではなく、誰が読んでも解釈の齟齬が生じない、具体的で実行可能なレベルで定義される必要があります。

セキュリティ要件とシステム要件の違い

システム開発の現場では、「システム要件」という言葉がよく使われます。このシステム要件とセキュリティ要件は密接に関連していますが、その目的と観点が異なります。

システム要件とは、開発するシステムが「何をすべきか（機能要件）」と「どのような品質であるべきか（非機能要件）」を定義したものです。

機能要件： システムが提供すべき具体的な機能に関する要件です。「ユーザー登録ができる」「商品を検索できる」「レポートを出力できる」といった、システムの動作そのものを定義します。
非機能要件： 機能以外のすべての要件を指し、性能、信頼性、拡張性、保守性、そしてセキュリティなどが含まれます。「1秒間に100件のアクセスを処理できる（性能）」「24時間365日停止しない（可用性）」といった品質に関する要求です。

この関係性からわかるように、セキュリティ要件は、非機能要件の一部として位置づけられるのが一般的です。システム要件が「家を建てる」ことに例えるなら、機能要件は「リビングや寝室、キッチンといった間取り」を、非機能要件は「耐震性や断熱性、そして防犯性」を決めるようなものです。セキュリティ要件は、この「防犯性」に特化した詳細な仕様書と言えます。

以下の表は、両者の違いをまとめたものです。

項目	システム要件	セキュリティ要件
目的	システムが実現すべき機能や性能を定義する	システムや情報資産を脅威から保護する方法を定義する
観点	「What（何ができるか）」「How well（どれくらいの性能か）」	「How to protect（どう守るか）」
具体例	・ユーザー登録機能・1秒あたり100件のトランザクション処理	・パスワードポリシーの強制・不正アクセス検知・データの暗号化
位置づけ	機能要件と非機能要件に大別される	非機能要件の一部として定義されることが多い

重要なのは、システム開発の初期段階、つまりシステム要件を定義する際に、セキュリティ要件も併せて検討することです。開発が完了してから後付けでセキュリティ対策を施そうとすると、大幅な手戻りや追加コストが発生したり、根本的な対策が打てずに脆弱性を残してしまったりする可能性があります。セキュリティは後から付け加える「オプション」ではなく、設計段階から組み込むべき「必須要素」であるという考え方（セキュリティ・バイ・デザイン）が、現代のシステム開発では主流となっています。

セキュリティ要件が重要視される理由

なぜ今、これほどまでにセキュリティ要件の定義が重要視されているのでしょうか。その背景には、企業を取り巻くIT環境や脅威の劇的な変化があります。ここでは、セキュリティ要件の重要性を高めている4つの主要な理由について詳しく解説します。

多様化・巧妙化するサイバー攻撃

かつてのサイバー攻撃は、技術力を誇示するための愉快犯的なものが主流でした。しかし現在では、金銭の窃取や機密情報の奪取、事業活動の妨害などを目的とした、明確な意図を持つ犯罪組織による攻撃がほとんどを占めています。

独立行政法人情報処理推進機構（IPA）が毎年発表している「情報セキュリティ10大脅威」を見ると、その深刻さがよくわかります。2024年版（組織向け）では、「ランサムウェアによる被害」が4年連続で1位となっています。ランサムウェアは、企業のデータを暗号化して身代金を要求するだけでなく、近年ではデータを窃取し「身代金を支払わなければ公開する」と二重に脅迫する「二重恐喝（ダブルエクストーション）」の手口が一般化しています。

参照：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2024」

その他にも、特定の組織を狙い、業務メールを装ってウイルス付きファイルを送りつける「標的型攻撃」や、サプライチェーンの脆弱性を悪用してセキュリティ対策の甘い取引先を踏み台にする「サプライチェーン攻撃」など、その手口はますます巧妙化しています。

こうした高度な攻撃に対して、ファイアウォールやアンチウイルスソフトを導入するだけの断片的な対策では、もはや対抗できません。自社が直面している脅威は何かを正確に分析し、それに対抗するための多層的な防御策を、セキュリティ要件として体系的に定義・実装していくことが不可欠なのです。

DX推進によるIT環境の変化

デジタルトランスフォーメーション（DX）の推進は、企業の競争力向上に不可欠ですが、同時に新たなセキュリティリスクを生み出しています。

クラウドサービスの普及： サーバーやソフトウェアを自社で保有するオンプレミス環境から、AWSやMicrosoft Azureなどのクラウドサービスへ移行する企業が増加しました。クラウドは利便性が高い反面、設定ミスによる情報漏洩のリスクが常に伴います。誰にどのような権限を与えるのか、どのような設定が安全なのかといった要件を明確に定義しないまま利用すると、意図せず機密情報がインターネット上に公開されてしまう事故につながります。
リモートワークの定着： 働き方の多様化により、従業員が自宅やカフェなど、オフィス以外の場所から社内システムにアクセスする機会が急増しました。これにより、従来のような「社内は安全、社外は危険」という境界線が曖昧になりました。自宅のWi-Fiルーターの脆弱性や、個人のデバイス利用（BYOD）など、管理者の目が届きにくい場所でのリスクが増大し、ゼロトラスト（すべての通信を信頼せず、都度検証する）の考え方に基づいたセキュリティ要件が求められるようになっています。
IoTデバイスの増加： 工場の生産設備やWebカメラ、スマートデバイスなど、様々なモノがインターネットに接続されるようになりました。これらのIoTデバイスは、PCに比べてセキュリティ対策が不十分な場合が多く、攻撃者にとって格好の侵入経路となり得ます。

このように、IT環境が複雑化・分散化する中で、従来の「境界型防御」モデルは限界を迎えています。変化した環境に合わせて、データ中心のアクセス制御や、すべてのアクセス元を検証するといった、新たな前提に立ったセキュリティ要件の再定義が急務となっています。

サプライチェーンリスクの増大

自社のセキュリティ対策を完璧に行ったとしても、それだけでは安全とは言えません。現代のビジネスは、多くの取引先や業務委託先との連携によって成り立っており、この連鎖（サプライチェーン）全体でセキュリティレベルを維持する必要があります。

近年、セキュリティ対策が強固な大企業を直接狙うのではなく、比較的対策が手薄な中小の取引先企業を踏み台にして、最終的な標的である大企業へ侵入する「サプライチェーン攻撃」が深刻な問題となっています。

例えば、システム開発を委託している会社や、部品を供給してくれるメーカーがサイバー攻撃を受け、そこから自社ネットワークへの侵入を許してしまうケースが後を絶ちません。

このようなリスクに対応するため、多くの企業では、取引を開始する際に相手方のセキュリティ体制を厳しくチェックするようになりました。セキュリティ対策に関するアンケートへの回答を求められたり、ISMS（ISO27001）などの第三者認証の取得を取引条件とされたりするケースも増えています。

つまり、セキュリティ要件を明確に定義し、適切な対策を講じていることは、自社を守るだけでなく、取引先からの信頼を獲得し、ビジネスを継続・拡大していくための必須条件となりつつあるのです。

コンプライアンス・法律への対応

企業活動を行う上で、様々な法律や規制を遵守すること（コンプライアンス）は当然の責務です。情報セキュリティの分野においても、遵守すべき法律やガイドラインが数多く存在します。

個人情報保護法： 日本国内で事業を行うすべての企業に適用され、個人情報の適切な取り扱いを義務付けています。法律では、個人データを保護するための「安全管理措置」を講じることを求めており、その具体的な内容は、組織的、人的、物理的、技術的な観点から定められています。これらは、まさにセキュリティ要件として定義すべき項目そのものです。万が一、重大な個人情報漏洩が発生した場合には、個人情報保護委員会への報告と本人への通知が義務付けられており、違反した場合には厳しい罰則が科される可能性があります。
GDPR（EU一般データ保護規則）： EU域内にいる個人のデータを扱う企業に適用される規則です。日本企業であっても、EU圏の顧客を持つ場合や、現地に従業員がいる場合は対象となり、違反した際には巨額の制裁金が科されることで知られています。
サイバーセキュリティ経営ガイドライン（経済産業省・IPA）： これは法律ではありませんが、経営者がリーダーシップを発揮してサイバーセキュリティ対策を推進するための指針を示しています。特に、サプライチェーン全体のセキュリティ対策の重要性や、インシデント発生時の情報開示の在り方など、経営レベルで認識すべき重要事項がまとめられています。

これらの法規制やガイドラインが求める要求事項を満たすためには、自社がどのような情報を保有し、それに対してどのような対策を講じているのかを、セキュリティ要件として明確に文書化し、実行していることを証明できる状態にしておく必要があります。これは、法的リスクやレピュテーションリスクを回避するために不可欠な取り組みです。

セキュリティ要件を定義する3つのメリット

セキュリティ要件を時間と労力をかけて定義することは、企業にどのような恩恵をもたらすのでしょうか。それは単に「安全になる」という漠然としたものではなく、ビジネスの継続性と成長に直結する、明確で具体的なメリットです。ここでは、その代表的な3つのメリットについて解説します。

① セキュリティリスクを低減できる

セキュリティ要件を定義する最大のメリットは、組織全体のセキュリティリスクを体系的に低減できる点にあります。

場当たり的な対策からの脱却
多くの組織では、ウイルス感染が発覚してからアンチウイルスソフトを導入したり、不正アクセスがあってからファイアウォールの設定を見直したりと、インシデント発生後に対策を講じる「もぐら叩き」のような対応に陥りがちです。しかし、セキュリティ要件を定義するプロセスでは、まず自社が守るべき情報資産は何か、どのような脅威が存在するのかを網羅的に洗い出します。これにより、潜在的なリスクを事前に特定し、計画的かつ包括的な対策を講じることが可能になります。これは、インシデントの発生そのものを未然に防ぐ「プロアクティブな対策」への転換を意味します。
セキュリティレベルの標準化と一貫性の確保
要件が定義されていない状態では、対策のレベルが担当者の知識や経験に依存してしまい、部署ごと、システムごとにバラバラになりがちです。明確なセキュリティ要件を設けることで、組織全体で遵守すべき最低限のセキュリティレベル（ベースライン）が確立されます。例えば、「すべてのサーバーは、OSのセキュリティパッチをリリース後1ヶ月以内に適用しなければならない」という要件があれば、どの部署が管理するサーバーであっても、一貫した脆弱性対策が実施されるようになります。
インシデント発生時の迅速な対応
どれだけ対策を講じても、インシデントの発生を100%防ぐことは不可能です。しかし、「インシデントを検知した場合、30分以内にCSIRT（インシデント対応チーム）へ報告する」「復旧は、システムの重要度に応じてRPO（目標復旧時点）4時間、RTO（目標復旧時間）24時間以内に行う」といった要件を事前に定めておくことで、有事の際に誰が何をすべきかが明確になり、混乱なく迅速かつ的確な対応が取れるようになります。これにより、被害の拡大を最小限に食い止めることができます。

② 顧客や取引先からの信頼性が向上する

現代のビジネスにおいて、セキュリティ対策は自社のためだけに行うものではありません。強固なセキュリティ体制は、顧客や取引先からの信頼を獲得し、維持するための重要な要素です。

対外的な説明責任の遂行
顧客から個人情報を預かるサービスや、他社と共同でシステム開発を行うプロジェクトなどでは、自社のセキュリティ対策について説明を求められる場面が頻繁にあります。その際に、単に「対策しています」と答えるだけでは、相手を安心させることはできません。「弊社では、ISO27001に基づき、アクセス制御、暗号化、ログ管理に関する詳細なセキュリティ要件を定めており、第三者機関による定期的な監査を受けています」のように、定義された要件に基づいて具体的に説明できることで、説得力が増し、信頼関係を構築できます。
ビジネスチャンスの創出と維持
前述の通り、サプライチェーン攻撃への警戒感から、取引先を選定する際の条件として、セキュリティ体制を厳しく評価する企業が増えています。特に、政府調達や大手企業との取引では、特定のセキュリティ認証（ISMS認証やPマークなど）の取得が必須条件となることも珍しくありません。これらの認証取得の基礎となるのが、明確に文書化されたセキュリティ要件と、それに基づいた運用実績です。しっかりとしたセキュリティ要件を整備しておくこと自体が、競合他社に対する優位性となり、新たなビジネスチャンスの獲得につながるのです。
ブランドイメージの保護
情報漏洩やシステム停止といったセキュリティインシデントは、直接的な金銭的被害だけでなく、企業の社会的信用を大きく損ないます。一度失った信頼を回復するのは容易ではありません。「あの会社はセキュリティが甘い」という評判が立てば、顧客離れや株価下落、取引停止など、事業の根幹を揺るがす事態に発展しかねません。セキュリティ要件を定義し、継続的に対策を実践することは、企業の最も重要な資産の一つである「ブランドイメージ」と「信頼」を守るための投資と言えます。

③ 対策に必要なコストを把握できる

セキュリティ対策にはコストがかかります。しかし、その投資額は闇雲に決めるべきではありません。セキュリティ要件を定義するプロセスは、セキュリティ投資の最適化と、経営層への説明責任を果たす上で極めて重要な役割を担います。

適切な投資判断の根拠となる
セキュリティ要件定義の過程では、情報資産の価値や、各リスクの発生可能性と影響度を評価します。これにより、「どの資産を、どのレベルのリスクから守るために、どのような対策が必要か」が明確になります。その結果、「このシステムは会社の生命線だから、最高レベルの対策にコストをかけるべきだ」「こちらの情報は機密性が低いので、最低限の対策に留めておこう」といった、リスクの大きさに応じたメリハリのある投資判断が可能になります。
過剰投資・過少投資の防止
「何となく不安だから」という漠然とした理由で、高価なセキュリティ製品を次々と導入してしまうのは「過剰投資」です。逆に、リスクを正しく認識できていないために、本来必要な対策を怠ってしまうのが「過少投資」です。どちらも健全な経営とは言えません。リスク評価に基づいたセキュリティ要件は、「なぜこの対策にこれだけのコストが必要なのか」を論理的に説明するための強力な根拠となり、不要な投資を避け、本当に必要な対策にリソースを集中させることができます。
予算計画の策定とROIの可視化
定義された要件に基づいて必要な対策（製品導入、人材育成、外部サービス利用など）をリストアップすることで、短期・中期的なセキュリティ関連の予算計画が立てやすくなります。また、対策によって「年間で想定される損失額（ALE）」をどれだけ低減できるかを試算することで、セキュリティ投資に対するROI（投資対効果）をある程度可視化し、経営層の理解を得やすくなります。これにより、セキュリティ対策が単なる「コスト」ではなく、事業継続のための戦略的な「投資」であるという認識を、組織全体で共有できるようになるのです。

セキュリティ要件の決め方4ステップ

それでは、実際にセキュリティ要件を定義するには、どのような手順を踏めば良いのでしょうか。ここでは、一般的かつ効果的なアプローチとして、4つのステップに分けてそのプロセスを具体的に解説します。このプロセスは、リスクアセスメント（リスク特定、リスク分析、リスク評価）とリスク対応の考え方に基づいています。

① 保護すべき情報資産を洗い出す

すべてのセキュリティ対策は、「何を守るのか」を明確にすることから始まります。守るべき対象が曖 ઉば、有効な対策は立てられません。この最初のステップでは、組織が保有するすべての情報資産を網羅的に洗い出し、その重要度を分類します。

ステップ1-1：情報資産の定義と洗い出し
まず、「情報資産」とは何かを定義します。情報資産は、データそのものだけでなく、それに関連する様々な要素を含みます。
- 情報・データ： 顧客情報、個人情報、財務情報、技術情報、ノウハウ、人事情報など。
- ソフトウェア： OS、業務アプリケーション、データベース管理システム、各種ツールなど。
- ハードウェア： サーバー、PC、ネットワーク機器、ストレージ、スマートフォン、USBメモリなど。
- 無形資産： 企業のブランド、信頼、各種サービスの利用権など。
- 人：従業員、役員、委託先担当者など（知識やスキルも資産と捉える）。
洗い出しの方法としては、各部署の業務内容をヒアリングしたり、既存のIT資産管理台帳やネットワーク構成図を確認したり、情報システム部門が管理するサーバーやアプリケーションの一覧からリストアップしたりする方法があります。見落としがないよう、複数の部門を巻き込んで多角的な視点で行うことが重要です。
ステップ1-2：情報資産の分類と重要度の決定
洗い出したすべての情報資産に対して、その価値を評価し、重要度を決定します。この評価軸として最も広く使われるのが、情報セキュリティの3大要素であるCIA（機密性・完全性・可用性）です。
- 機密性（Confidentiality）： その情報が漏洩した場合の事業への影響度。
- 完全性（Integrity）： その情報が改ざんされた場合の事業への影響度。
- 可用性（Availability）： その情報やシステムが利用できなくなった場合の事業への影響度。
これら3つの観点から、各情報資産を例えば「高・中・低」の3段階で評価します。例えば、「顧客のクレジットカード情報」は機密性が「高」、「会社のWebサイトのトップページ」は可用性が「高」、「過去のプレスリリース情報」はすべての評価が「低」といった具合です。
この評価結果を基に、情報資産を「極秘」「秘」「社外秘」「公開」のようにランク付けします。このランク付けが、後のステップでリスクの大きさを判断し、対策の優先順位を決める際の重要な基準となります。

② 脅威と脆弱性を分析する

守るべき情報資産が明確になったら、次にその資産を危険に晒す「脅威」と、その脅威による攻撃を成功させやすくする「脆弱性」を分析します。

ステップ2-1：脅威の洗い出し
脅威とは、情報資産に損害を与える可能性のある、好ましくない事象の原因のことです。脅威は意図的なものから偶発的なもの、技術的なものから物理的なものまで多岐にわたります。
- 意図的な脅威： 不正アクセス、マルウェア感染（ランサムウェア、ウイルスなど）、標的型攻撃、DoS攻撃、内部不正（情報の持ち出し、設定変更）、盗難、破壊行為など。
- 偶発的な脅威： 操作ミス（ファイル誤削除、メール誤送信）、設定ミス、故障、紛失・置き忘れなど。
- 環境的な脅威： 地震、火災、水害、停電などの自然災害や事故。
これらの脅威を洗い出す際には、IPAの「情報セキュリティ10大脅威」や、NISC（内閣サイバーセキュリティセンター）が公表している注意喚起情報、業界団体から発信されるレポートなどを参考にすると、自社に関連性の高い脅威を効率的にリストアップできます。
ステップ2-2：脆弱性の洗い出し
脆弱性とは、脅威が利用する可能性のある、情報資産や管理体制の弱点・欠陥のことです。
- 技術的な脆弱性： OSやソフトウェアの既知の脆弱性（パッチ未適用）、ファイアウォールの不適切な設定、推測されやすいパスワードの使用、暗号化の不備など。
- 物理的な脆弱性： サーバールームの施錠が不十分、監視カメラがない、重要な書類が机の上に放置されている（クリアデスクの不徹底）など。
- 人的・組織的な脆弱性： セキュリティ教育の不足、情報セキュリティポリシーが未整備、インシデント対応体制がない、内部不正の動機（不満など）を放置しているなど。
脆弱性の分析には、脆弱性診断ツールによるシステムのスキャンや、セキュリティ専門家によるプラットフォーム診断、従業員へのアンケート調査などが有効です。このステップでは、「もし、〇〇という脅威が発生したら、△△という脆弱性があるために、□□という情報資産に被害が及ぶ」といった具体的な脅威シナリオを想定することが重要です。

③ リスクを評価する

情報資産、脅威、脆弱性が明らかになったら、次はいよいよ「リスク」の大きさを評価します。リスク評価とは、洗い出した脅威シナリオが、実際にどのくらいの確率で発生し、発生した場合にどれくらいの損害をもたらすのかを分析し、対応の優先順位を決定するプロセスです。

リスクの大きさは、一般的に以下の式で表されます。

リスク = 資産価値 × 脅威の発生可能性 × 脆弱性

これをよりシンプルに、「リスク = 発生可能性 × 影響度」として評価することが多いです。

ステップ3-1：発生可能性と影響度の評価
②で作成した脅威シナリオごとに、「発生可能性」と「影響度」を評価します。
- 発生可能性： その脅威が、自社の脆弱性を突いて実際に発生する可能性の度合い。「高（年に数回）」「中（数年に1回）」「低（10年に1回未満）」のように定義します。
- 影響度： そのシナリオが発生した場合に、事業に与える損害の大きさ。ステップ①で評価した資産の重要度（CIA）を基に、「甚大（事業継続が困難）」「大（事業に深刻な支障）」「中（事業に一定の支障）」「小（軽微な影響）」のように定義します。
ステップ3-2：リスクレベルの算定と優先順位付け
評価した「発生可能性」と「影響度」を掛け合わせ、リスクレベルを算出します。これを視覚的に分かりやすくするために、「リスクマトリクス」という図を用いるのが一般的です。

影響度：小影響度：中影響度：大影響度：甚大

発生可能性：高 中高高極高

発生可能性：中 低中高高

発生可能性：低 低低中中

このマトリクス上で「極高」や「高」と評価されたリスクが、優先的に対策を講じるべき対象となります。また、このプロセスで「どのレベルのリスクまでは許容できるか（受容可能リスクレベル）」という基準を組織として定めておくことが極めて重要です。この基準を超えるリスクは、すべて何らかの対策が必要となります。

	影響度：小	影響度：中	影響度：大	影響度：甚大
発生可能性：高	中	高	高	極高
発生可能性：中	低	中	高	高
発生可能性：低	低	低	中	中

④ セキュリティ対策を検討・決定する

リスク評価によって、優先的に対応すべきリスクが特定できたら、いよいよ最終ステップです。これらのリスクを、設定した「受容可能リスクレベル」以下に抑えるための具体的な対策を検討し、これを「セキュリティ要件」として決定・文書化します。

リスクへの対応方針には、大きく分けて4つの選択肢があります。

リスク低減： 最も一般的な対応策。セキュリティ対策を実施して、リスクの発生可能性や影響度を下げるアプローチです。例えば、ファイアウォールを導入して不正アクセスを防ぐ、データを暗号化して漏洩時の影響を小さくするなどです。
リスク保有（受容）： リスクが受容可能リスクレベル以下である場合や、対策にかかるコストが想定される損害額を大幅に上回る場合に、リスクを認識した上で受け入れるアプローチです。
リスク回避： リスクの原因となる活動そのものを中止するアプローチです。例えば、特定のサービスのセキュリティリスクが非常に高いと判断した場合、そのサービスの提供を停止するなどです。
リスク移転： サイバー保険に加入するなどして、リスク発生時の金銭的損害を第三者（保険会社など）に転嫁するアプローチです。ただし、リスクそのものがなくなるわけではない点に注意が必要です。

優先度の高いリスクに対して、主に「リスク低減」の観点から、「誰が」「いつまでに」「何を」「どのように」実施するのかを具体的に定義します。例えば、「ランサムウェア感染」という高リスクに対して、以下のような対策（要件）が考えられます。

技術的要件： 全てのPCにEDR（Endpoint Detection and Response）製品を導入し、不審な挙動を検知・ブロックする。
組織的要件： 重要なデータは、ネットワークから隔離されたオフライン環境に毎日バックアップを取得し、3ヶ月間保管する。
人的要件： 全従業員を対象に、標的型攻撃メール訓練を年2回実施する。

このようにして決定された対策のリストが、最終的な「セキュリティ要件定義書」となります。この文書は、具体的で、測定可能で、達成可能で、関連性があり、期限が明確である（SMART）ことを意識して記述することが望ましいです。

セキュリティ要件で定義すべき項目一覧

セキュリティ要件をゼロから考えるのは大変な作業です。幸いなことに、情報セキュリティの分野には、長年の知見が蓄積されたフレームワークや国際規格が存在します。これらを参考にすることで、網羅的かつ体系的に要件を検討できます。ここでは、まずセキュリティの基本となる概念を理解した上で、具体的な要件項目を多角的な視点から解説します。

まずはセキュリティの基本7要素を理解する

セキュリティ要件を検討する際の土台となるのが、情報が持つべき性質を定義した7つの要素です。特に最初の3つは「CIA」と呼ばれ、情報セキュリティの根幹をなす最も重要な概念です。

CIA（機密性・完全性・可用性）

機密性 (Confidentiality): 許可された者だけが情報にアクセスできる状態を保証すること。情報漏洩対策の根幹です。
- 要件例：
  - ファイルやデータベースへのアクセス権を、役職や職務に応じて必要最小限に設定する（アクセス制御）。
  - 顧客データや財務データなどの重要情報は、保管時および通信時に暗号化する。
  - 個人所有のデバイスから社内ネットワークへの接続を原則禁止する。
完全性 (Integrity): 情報が破壊、改ざん、消去されていない、正確かつ完全な状態を保証すること。データの信頼性を担保します。
- 要件例：
  - ファイルが改ざんされていないことを確認するために、ハッシュ値やデジタル署名を利用する。
  - データベースへの変更履歴（誰が、いつ、何を更新したか）をすべて記録する。
  - 入力データの妥当性チェック（バリデーション）を行い、不正なデータが登録されるのを防ぐ。
可用性 (Availability): 許可された者が、必要な時にいつでも情報やシステムを利用できる状態を保証すること。事業継続性の観点から重要です。
- 要件例：
  - サーバーやネットワーク機器を冗長化（二重化）し、一部が故障してもサービスが停止しないようにする。
  - 定期的にデータのバックアップを取得し、災害やシステム障害からの迅速な復旧手順を確立する。
  - DoS攻撃など、サービスの提供を妨害する攻撃を検知し、防御する仕組みを導入する。

その他の4要素（真正性・責任追跡性・信頼性・否認防止）

CIAに加えて、以下の4つの要素を考慮することで、より堅牢なセキュリティ体制を構築できます。

真正性 (Authenticity): 情報の利用者や発信者が、主張通りの本人であることを確実に検証できること。なりすましを防ぎます。
- 要件例： ID・パスワードに加えて、SMS認証や生体認証などを組み合わせた多要素認証（MFA）を導入する。
責任追跡性 (Accountability): ある操作が「いつ、誰によって」行われたのかを後から追跡・証明できること。インシデント発生時の原因究明に不可欠です。
- 要件例： システムの操作ログや認証ログを収集・保管し、定期的に監査する。
信頼性 (Reliability): システムが意図した通りに、一貫して正しく動作すること。システムのバグや予期せぬ挙動によるセキュリティホールを防ぎます。
- 要件例： システム開発時に十分なテストを実施し、セキュリティ上の欠陥がないことを確認する。
否認防止 (Non-repudiation): ある操作を行った本人が、後になってその事実を否定できないようにすること。電子商取引などで重要になります。
- 要件例： 電子契約において、信頼できる第三者機関が発行したデジタル署名とタイムスタンプを利用する。

4つの観点から考えるセキュリティ要件

7つの基本要素を念頭に置きつつ、対策を具体化する際には、以下の4つの観点から要件を分類すると考えやすくなります。これらは互いに独立しているのではなく、連携して多層的な防御を形成します。

観点	概要	具体的な要件項目の例
技術的セキュリティ要件	ITシステムやツール、技術を用いて実現する対策。サイバー攻撃に対する直接的な防御策が多い。	・ネットワークセキュリティ（ファイアウォール, IDS/IPS, WAF）・エンドポイントセキュリティ（アンチウイルス, EDR）・データセキュリティ（暗号化, データマスキング）・アクセス制御（ID管理, 認証強化, 権限管理）・ログ管理と監視・脆弱性管理（パッチ適用, 脆弱性診断）
物理的セキュリティ要件	サーバーやネットワーク機器などの物理的なIT資産や、オフィス、データセンターなどを保護する対策。	・入退室管理（ICカード, 生体認証）・監視システム（防犯カメラ）・施錠管理（サーバルーム, キャビネット）・機器の盗難防止策（ワイヤーロック）・環境対策（防災設備, 電源設備）
人的セキュリティ要件	従業員や関係者など、「人」に起因するリスクを低減するための対策。セキュリティ意識の向上が目的。	・情報セキュリティ教育・訓練（e-ラーニング, 標的型攻撃メール訓練）・ポリシーと規程の整備・周知（情報取扱規程, パスワードポリシー）・クリアデスク・クリアスクリーン・内部不正対策（監視, 権限分離）・入社・退職時の手続き
組織的セキュリティ要件	組織としての体制、ルール、プロセスを整備する対策。セキュリティガバナンスの確立が目的。	・情報セキュリティポリシーの策定と見直し・推進体制の構築（CISO, CSIRTの設置）・役割と責任の明確化・インシデント対応計画の策定と訓練・委託先管理と契約・定期的な内部監査・外部監査

ISO27001を参考にした14の管理策

より網羅的で国際標準に準拠した要件を検討したい場合、情報セキュリティマネジメントシステム（ISMS）の国際規格である「ISO/IEC 27001」の附属書Aが非常に参考になります。附属書Aでは、組織が実施すべき管理策が14のカテゴリに分類されています。これらは、自社のセキュリティ要件に漏れがないかを確認するためのチェックリストとして活用できます。

以下に、その14の管理策の概要を示します。

① 情報セキュリティのための方針群

組織の情報セキュリティに関する最上位の方針（基本方針）を文書化し、経営層が承認し、全従業員に周知することを求める項目です。

② 情報セキュリティのための組織

情報セキュリティを推進するための体制（責任者の任命、役割分担など）を定めることや、モバイル機器の利用やテレワークに関する方針を定めることを求める項目です。

③ 人的資源のセキュリティ

従業員の雇用前から退職後に至るまで、人に関するセキュリティを確保するための項目です。採用時の背景調査、在職中の教育、退職時のアクセス権削除などが含まれます。

④ 資産の管理

組織の情報資産を洗い出し、分類し、誰が責任を持つのかを明確にすることを求める項目です。情報の取り扱いルール（ラベリング、媒体の管理など）もここで定めます。

⑤ アクセス管理

情報資産へのアクセスを、業務上必要な担当者のみに制限するための項目です。利用者登録、権限管理、パスワード管理などの要件が含まれます。

⑥ 暗号

データの機密性、完全性などを保護するために、暗号技術を適切に利用するための方針とルールを定める項目です。

⑦ 物理的および環境的セキュリティ

オフィスやデータセンターなどを物理的な脅威（不正侵入、災害など）から保護するための項目です。入退室管理、施錠、防災設備などが該当します。

⑧ 運用のセキュリティ

システムの運用におけるセキュリティを確保するための項目です。操作手順の文書化、変更管理、マルウェア対策、バックアップ、ログ管理などが含まれます。

⑨ 通信のセキュリティ

ネットワーク通信における情報を保護するための項目です。ネットワークの分離、安全な通信プロトコルの利用（暗号化）などが該当します。

⑩ システムの取得、開発および保守

新しいシステムを導入したり、自社で開発したりする際のセキュリティを確保するための項目です。開発段階からセキュリティを考慮すること（セキュアコーディング）や、テストデータの保護などが含まれます。

⑪ 供給者関係

業務委託先やクラウドサービス提供者など、外部の供給者との関係におけるセキュリティを確保するための項目です。契約時にセキュリティ要求事項を盛り込むことや、定期的な監査などが該当します。

⑫ 情報セキュリティインシデント管理

インシデントが発生した際に、迅速かつ効果的に対応するための体制と手順を定める項目です。報告体制、対応手順、証拠保全、原因分析、再発防止策の策定などが含まれます。

⑬ 事業継続マネジメントにおける情報セキュリティの側面

災害や大規模なシステム障害が発生した場合でも、情報システムの可用性を維持し、事業を継続できるようにするための計画を立てる項目です。

⑭ 順守

法律、規制、契約上の要求事項を遵守していることを確認するための項目です。個人情報保護法などの法令遵守、知的財産権の保護、定期的な監査などが含まれます。

これらの管理策をすべて実施する必要はありません。自社のリスク評価の結果に基づき、必要な項目を選択し、自社の状況に合わせて具体化していくことが、効果的なセキュリティ要件定義の鍵となります。

セキュリティ要件定義を成功させるためのポイント

セキュリティ要件を文書として定義するだけでは、組織のセキュリティレベルは向上しません。その要件が形骸化せず、実効性のあるものとして組織に根付くためには、いくつかの重要なポイントがあります。ここでは、要件定義を成功に導くための5つのポイントを解説します。

経営層を巻き込み全社で取り組む

セキュリティ対策は、もはや情報システム部門だけの課題ではありません。事業継続に直結する重要な経営課題です。要件定義を成功させるためには、まず経営層の深い理解と強力なコミットメントが不可欠です。

なぜ経営層の関与が必要か？
- 予算の確保： 効果的なセキュリティ対策には、ツールの導入や人材育成など、相応のコストがかかります。経営層がその必要性を理解していなければ、十分な予算を確保することは困難です。
- 全社的な協力体制の構築： セキュリティ要件の多くは、特定の部署だけでなく、全従業員の協力がなければ遵守できません。例えば、パスワードポリシーの徹底や情報取り扱いルールの遵守などは、経営トップからの明確なメッセージがあってこそ、全社に浸透します。
- 最終的な意思決定： どのレベルのリスクまでを許容するか、どの対策に優先的に投資するかといった最終的な判断は、ビジネス全体への影響を考慮できる経営層が行うべきです。

経営層を巻き込むためには、セキュリティリスクを専門用語で説明するのではなく、「このリスクを放置すると、事業に〇〇円の損害が出る可能性があります」「この対策に投資することで、当社の社会的信頼性が向上し、〇〇のビジネスチャンスに繋がります」といった、ビジネスの言葉で説明することが重要です。

自社に合ったセキュリティレベルを見極める

セキュリティは、高ければ高いほど良いというものではありません。過剰な対策は、従業員の業務効率を著しく低下させたり、不必要なコストを発生させたりする可能性があります。一方で、対策が不十分であれば、重大なインシデントを招きかねません。重要なのは、自社の事業内容、取り扱う情報の価値、企業文化などを考慮し、リスクとコスト、利便性のバランスが取れた適切なセキュリティレベルを見極めることです。

この「適切なレベル」を見極めるための羅針盤となるのが、前述の「リスクアセスメント」です。

リスクベースのアプローチを徹底する： 「他社が導入しているから」という理由だけで高価なセキュリティツールを導入するのではなく、自社のリスク評価の結果に基づいて、「どのリスクを低減するために、この対策が必要なのか」を常に意識することが重要です。
ビジネスへの影響を考慮する： 例えば、非常に厳しいパスワードポリシーを導入した結果、パスワードを覚えきれない従業員がメモに書いてPCに貼り付けるようになれば、かえってリスクは高まります。セキュリティ要件を検討する際には、それが現場の業務にどのような影響を与えるかをヒアリングし、現実的に運用可能なルールを策定する必要があります。

完璧なセキュリティを目指すのではなく、自社にとって許容できないリスクを確実に管理できるレベルを目指すことが、持続可能なセキュリティ体制を築く鍵となります。

定義した要件をテストで検証する

セキュリティ要件を文書化しただけでは、「机上の空論」で終わってしまう可能性があります。定義した要件が、実際にシステムに正しく実装され、組織の中で意図した通りに機能しているかを確認するためには、定期的なテストによる検証が不可欠です。

技術的要件のテスト：
- 脆弱性診断： 専用のツールや専門家の手によって、サーバーやネットワーク、Webアプリケーションに既知の脆弱性がないかをスキャン・診断します。
- ペネトレーションテスト（侵入テスト）： 攻撃者の視点に立って、実際にシステムへの侵入を試みるテストです。要件に基づいて構築した防御壁が、実際の攻撃に耐えられるかを実践的に検証できます。
人的・組織的要件のテスト：
- 標的型攻撃メール訓練： 従業員に疑似的な攻撃メールを送り、開封率やURLのクリック率などを測定します。セキュリティ教育の効果測定や、従業員の意識向上に繋がります。
- インシデント対応訓練： 「ランサムウェアに感染した」「サーバーがダウンした」といったシナリオを想定し、報告、原因調査、復旧、関係者への連絡といった一連の対応プロセスが、事前に定めた手順通りに機能するかをシミュレーションします。

これらのテスト結果から得られた課題や改善点を、セキュリティ要件や運用ルールにフィードバックしていくことで、PDCAサイクルを回し、セキュリティレベルを継続的に向上させていくことができます。

専門家や外部サービスの活用も検討する

セキュリティは非常に専門性の高い分野であり、すべての対策を自社のリソースだけで完結させるのは困難な場合があります。特に、専門知識を持つ人材が不足している場合や、24時間365日の監視体制を構築するのが難しい場合には、外部の専門家や専門サービスの力を借りることも有効な選択肢です。

セキュリティコンサルティング： リスクアセスメントの実施や、セキュリティ要件定義のプロセス全体を、専門コンサルタントに支援してもらうサービスです。客観的な視点から、自社に最適なセキュリティ体制の構築をサポートしてくれます。
脆弱性診断・ペネトレーションテストサービス： 自社では発見が難しい脆弱性を、専門家の高度な技術力で洗い出してもらえます。
マネージドセキュリティサービス（MSS）： ファイアウォールやIDS/IPSなどのセキュリティ機器の監視・運用を、専門のベンダーにアウトソースするサービスです。SOC（セキュリティオペレーションセンター）による24時間体制の監視により、インシデントの早期発見と迅速な初動対応が可能になります。

自社の強みと弱みを正確に把握し、コア業務に集中するためにも、どこまでを自社で行い、どこからを外部に委託するのかを戦略的に判断することが重要です。

まとめ

本記事では、セキュリティ要件の基本から、その重要性、具体的な決め方のステップ、定義すべき項目、そして成功のためのポイントまでを包括的に解説しました。

セキュリティ要件定義は、単に技術的なルールを決める作業ではありません。それは、自社の大切な情報資産を特定し、それを取り巻く脅威を分析し、ビジネスへの影響を評価した上で、事業を継続するための戦略的な防御策を策定する、極めて重要な経営活動です。

明確なセキュリティ要件がなければ、セキュリティ対策は場当たり的で一貫性のないものとなり、コストをかけても十分な効果は得られません。逆に、自社の実情に合った実効性のある要件を定義し、それを組織全体で遵守することで、以下のような多くのメリットが生まれます。

サイバー攻撃による被害を未然に防ぎ、インシデント発生時の損害を最小限に抑える。
顧客や取引先からの信頼を獲得し、ビジネスチャンスを拡大する。
リスクに基づいた適切な投資判断により、コストを最適化する。

最後に、最も重要なことは、セキュリティ要件定義は一度行ったら終わりではない、ということです。ビジネス環境、ITシステム、そして脅威は絶えず変化し続けます。その変化に対応し、常に自社を最適な状態で保護し続けるためには、定期的に要件を見直し、改善していく継続的なプロセス（PDCAサイクル）が不可欠です。

この記事が、皆さんの組織におけるセキュリティ対策の第一歩を踏み出す一助となれば幸いです。まずは、自社が本当に「守るべきもの」は何か、その洗い出しから始めてみてはいかがでしょうか。