システム開発におけるセキュリティ要件の決め方具体例を通して解説
現代のシステム開発において、セキュリティは欠かせない要素となっています。サイバー攻撃の脅威が日々増大する中、システムの安全性を確保することは非常に重要です。セキュリティを考慮した設計は、システムの堅ろう性を高め、安定的にシステムを利用できる状態とするための鍵となります。
本記事では、具体的な事例を交えながら、セキュリティ要件の決定方法について詳しく解説します。
セキュリティ要件とは
システムを開発する際には、一般的に要件定義書として開発したいシステムの内容を取りまとめます。この要件定義書における一つの要素となるのがセキュリティ要件です。セキュリティ要件では、開発するシステムに求めるセキュリティについて、網羅的に記載し、開発者へ伝えます。
セキュリティ要件の重要性
なぜセキュリティ要件を取りまとめ、要件定義書に記載する必要があるのでしょうか。その最も大きな理由は「セキュリティ対策はシステム開発中からリリース後まで継続して実施し続けなければならないため」です。システムのライフサイクル全体を通して、どのようなセキュリティ対策を行うかを明確にすることで、継続した対応をとれるようにします。セキュリティ要件は、開発プロセスの初期段階である要件定義段階で決定すべきであり、システムの設計や実装、テスト、運用に至るまでの全てのフェーズで考慮される必要があります。
また、要件定義段階でセキュリティ対策方法を定義することで、セキュリティ対策の一貫性を保つという点も重要です。特に複数のチームや部門が関与する大規模プロジェクトにおいては、どの水準でセキュリティ対策を行うかを明確にする必要があります。
注目される「セキュリティ・バイ・デザイン」とは
近年では、セキュリティ・バイ・デザインというキーワードが注目されるようになりました。デジタル庁ではセキュリティ・バイ・デザインに関するガイドブックを公開するなど、セキュリティ・バイ・デザインの浸透が進んでいます。セキュリティ・バイ・デザインとはどのような概念なのでしょうか。
セキュリティ・バイ・デザインを端的に言えば、システムやサービスの開発初期段階からセキュリティ対策を組み込むアプローチのことです。セキュリティ・バイ・デザインは、セキュリティ対策を後付けするのではなく、設計段階からセキュリティを考慮することで、全体的なシステムの安全性を高めることを目的としています。具体的には、開発プロセスの初期段階でセキュリティ要件を定義し、設計、実装、テスト、運用の各フェーズでこれらの要件を遵守することが求められます。
セキュリティ・バイ・デザインのアプローチを採用することにより、予期せぬセキュリティホールが発見されるリスクを低減し、システムの堅ろう性を向上させることができます。また、セキュリティ対策を最初から組み込むことで、後から対策を講じるよりもコスト効率が良くなり、システム全体の整合性も保たれます。
※参考：デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」
代表的なセキュリティ要件と記載例
具体的に、要件定義書にはどのようなセキュリティ要件を記載するべきなのでしょうか。以下では、項目ごとにセキュリティ要件の記載例を紹介します。
前提条件
順守すべき情報セキュリティに関する組織規程やルール、法令、ガイドライン等が存在するかどうかについて記載する項目です。開発者に対して順守すべき規程、法令、ガイドラインを示しつつ、これらと矛盾のないようにセキュリティに関する非機能要求項目のレベルを決定していきます。
記載例：
本開発にあたっては、以下の法令・規程・ガイドラインの内容を順守するものとする。
- 不正アクセス禁止法・不正競争防止法・プロバイダ責任法・改正個人情報保護法・SOX法
- EU一般データ保護規則(GDPR)
- 当社セキュリティ基本方針、セキュリティ管理規程
認証機能
システムの利用は一般的に認証により制限するものです。本項目では、システムの利用者を識別するために、どのような認証をどの程度実施するのかを示します。
ID・パスワードのみならず、複数回の認証を実施することにより万が一攻撃者がID・パスワード等を盗んだ場合でも権限の乱用を防止することができます。
記載例：
システムの利用にあたっては、以下の認証を行うものとする
- ID/パスワードによる認証とスマートフォンの所有を用いた多要素認証
利用制限
システムの利用者が、権限に応じてどこまでシステムを利用できるようにするかについて定める項目です。全ての利用者にあらゆる権限を与えるのは危険です。不正なソフトウェアがインストールされてしまったり、不要なアクセス経路から情報漏えいが行われてしまったりというリスクがあるため、不要なアクセスは制限し、業務上必要な範囲での権限付与にとどめましょう。
また、居室への入退室の制限など、物理的な制限についても併せて検討します。
記載例：
権限は以下の2種類設定できるようにする
- スーパーユーザー：あらゆる機能を利用できる
- 利用者：スーパーユーザーが個別に利用できる機能を設定できる
システムの開発、運用を行う居室においては、ICカードを用いた入退館管理を行う
ID管理方法
従業員の異動や退職により、利用者に付与すべき権限は変わっていきます。ユーザーIDは継続的に管理し、棚卸を行っていく必要があります。これらの作業をどのように行うか定義する項目です。
記載例：
- ユーザーIDを一覧化し、Excel等でダウンロードできる機能を用意する
- ユーザーIDは年に一度棚卸を行い、常に最新の状態とする
データ暗号化
機密性のあるデータについては、データの転送時やデータベース上での保管時に暗号化を行うべきです。暗号化により、万が一悪意のある攻撃者にデータを盗まれたとしても、その被害を最小化できます。ここでは、どのように暗号化を行うかについて定めます。
記載例：
- ネットワークを経由して送信するパスワード等については第三者に漏えいしないよう暗号化を実施する
不正監視
悪意のある攻撃者や内部による不正行為を検知するために、システム監視を行います。ここでは、監視する範囲や、監視の記録を保存する量や期間を定義します。
具体的には、不正なアクセスが発生した際に、「いつ」「誰が」「どこから」「何を実行し」「その結果、どのようになったか」を確認し、その後の対策を迅速に実施するために、ログを取得します。また、取得したログのうちどの範囲を継続的に確認していくかを定める必要もあります。
記載例：
- 不正行為を確認する、また、正しく処理された証跡を保持するために、3年分のアクセスログを保持する
- ログ管理システムを導入し、継続的にログを確認できるようにする
- 不正の兆候が見られる場合、迅速に報告を行う
ネットワーク
不正な通信を遮断するための制御を実施するための項目です。ファイアウォールやIPS/IDS、UTMなどの機器を導入し、悪意のある攻撃者の侵入からシステムを守ります。
また、DoS/DDoS攻撃といったネットワークへの攻撃についての対策を実施するかについても併せて定義します。
記載例：
- 踏み台攻撃等の脅威や、情報の持ち出しを抑止するために、不正な通信の遮断等をネットワーク制御にて行う
- DoS/DDoS攻撃の対策を行うための機器を導入する
マルウェア対策
ウィルス、ワーム、ボットなどのマルウェアの感染を防止するための項目です。マルウェア対策の実施範囲やチェック方法について定義します。対策を実施する場合には、ウィルス定義ファイルの更新方法やタイミングについても検討し、常に最新の状態となるようにします。
記載例：
- マルウェアの感染を防ぐため、セキュリティソフトウェアを導入する
- セキュリティソフトウェアは定期的な更新を行い、常に最新の状態を維持できるようにする
セキュリティ診断
悪意のある攻撃者からの攻撃を防ぐために、セキュリティ診断を行いシステムの堅牢性を評価してもらいます。セキュリティ診断では、設計書や環境定義書、ソースコードなどに対して、第三者によるセキュリティに特化した各種試験や検査の実施を行います。ここでは、セキュリティ診断の必要性について定義します。
記載例：
システムのリリース時、およびリリース後年に1度、セキュリティ診断を行う
セキュリティ診断は以下の項目を含んだ形で行う
- ネットワーク診断：目視による設定の確認や、疑似攻撃を実施することにより脆弱性を発見するペネトレーションテスト、およびネットワーク上のサーバや通信機能をもつソフトウェアなどに対する脆弱性調査を行う
- Web診断： WebサーバやWebアプリケーションに対するセキュリティ診断を行う
- DB診断：データベースシステムに対してセキュリティ診断を行う
インシデント対応
万が一セキュリティインシデントが発生したときに、早期に発見し被害を最小化しつつ、復旧をすすめるための項目です。どのような体制を整備し、どのようにインシデントに対応するかについて定義します。
記載例：
- セキュリティインシデント発生時には、当社のCSIRTと連携して対応を行う
- 継続的に、インシデント対応マニュアルの整備や、システムの関係者に対するセキュリティ教育を実施する
主なセキュリティ要件ガイドライン
セキュリティ対策をどの水準で実施するかは非常に難しい問題です。セキュリティはいくらでも強度を高めることができる一方で、対策をしすぎると多額のコストがかかります。
そこで参考にしたいのが、官公庁などが提供しているセキュリティ要件に関するガイドラインです。以下では、セキュリティ要件を定める際に参考になる各種ガイドラインをご紹介します。
総務省「セキュリティ要件ガイドブック」
総務省の「セキュリティ要件ガイドブック」は、教育機関向けシステムに関するセキュリティ要件の定め方に関するガイドブックです。しかしながら、その内容は教育機関向けだけでなくあらゆるシステムに共通するものです。業界問わず利用できるガイドブックであり、具体的なセキュリティ要件を定める際に参考になる情報といえるでしょう。
本ガイドラインでは、以下のような内容が紹介されています。
- 内部組織: セキュリティ管理組織の役割を明確にし、誰が責任を負うかを定義する。
- 人的資源: 従業員や契約先に対し、セキュリティに関する研修を実施する。
- 資産の管理: 情報資産の分類と管理、そして契約終了時の資産返却を求める規則を定める。
- アクセス制御: 情報の可用性を考慮し、必要な情報にのみアクセスできるようにする。
- 物理的および環境的セキュリティ: 災害、停電、盗難などからシステムを保護し、入退出管理によって物理的なセキュリティを高める。
情報処理推進機構「IT製品の調達におけるセキュリティ要件リスト」
情報処理推進機構（IPA）が提供する「IT製品の調達におけるセキュリティ要件リスト」は、IT製品を調達する際に考慮すべきセキュリティ要件を網羅的にまとめたガイドラインです。このリストは、IT製品の選定や導入において、セキュリティリスクを低減するための基準を提供しています。
具体的には、以下のような内容を提供するものです
- セキュリティ機能の確認: 各製品が備えるべき基本的なセキュリティ機能の一覧。
- 脆弱性管理: 製品内の脆弱性をどのように管理し、対処するかについての指針。
- セキュリティ評価: 製品のセキュリティ性能を評価するための基準と手法。
- 運用管理: 製品の導入後のセキュリティ管理についての注意点。
- 法令遵守: 関連法規や規制に従うための要件。
※参考：情報処理推進機構「IT製品の調達におけるセキュリティ要件リスト」
情報処理推進機構「ユーザのための要件定義ガイド」
同じく情報処理推進機構（IPA）が提供する「ユーザのための要件定義ガイド」は、要件定義全般の進め方に関する情報が提供されているものです。本ガイドラインの中にはセキュリティ要件に関する定め方についても示されています。
本ガイドラインを参考にすることで、セキュリティ要件だけでなく要件定義全般の進め方を理解することができます。
セキュリティ要件定義のポイント
最後に、セキュリティ要件作成におけるポイントについて簡単にご紹介します。
社内標準の参照
社内の規程やガイドラインがある場合、それらを順守する形でセキュリティ要件を定めると効率的です。改めてセキュリティ要件を一から定めるのではなく、既存の規程にシステムの独自要素を追加する形でセキュリティ要件を設定します。
もし社内に規程やガイドラインが無い場合には、各システムでのセキュリティレベルのずれをなくすためにも、新たに作成しておくことをおすすめします。
チェックリストによる順守確認
セキュリティ要件を定めたものの、開発者が十分に理解できていなかったという事態はよくあるものです。これを防ぐために、チェックリストを用意し、開発者側にチェックしてもらうことで、順守を徹底するようにすることをおすすめします。
あとで「知らなかった」となることを防ぐために、チェックリストの活用が有効です。
継続的な見直し
システムはリリース後も継続的にセキュリティ対策を行っていく必要があるものです。システムに求めるセキュリティ水準は継続的に見直しを行っていくことをおすすめします。
近年ではランサムウェアの被害が多発していますが、このようにセキュリティに関する脅威は年々進化していくものですので、システム側でもそれに追随して対応を行っていく必要があります。
まとめ
この記事では、セキュリティ要件の決定方法について詳しくご紹介しました。システム開発を行う際に、セキュリティに関する要件は必ず定めるべきものです。一方で、過剰にセキュリティ要件を設定してしまうと、費用対効果の悪いシステムができあがってしまいます。各種ガイドラインも参考にしながら、必要十分なセキュリティ要件を定めることがポイントとなります。
この記事をシェア
