セキュリティ事故が発生すると、事業継続が困難になるほど社会的信用が失墜してしまう恐れが高まっています。企業にとって、今まで以上にセキュリティ対策が重要になってきました。

セキュリティ事故を発生させないためには、セキュリティ要件を見極めながら、コストパフォーマンスも念頭に置いた対策が不可欠です。

ですが、いざ自社に必要なセキュリティ要件を定義しようと思っても、何をどのように定義するべきかわからない方も多いのではないでしょうか。

そこで今回は、セキュリティ要件定義の書き方に着目し、記載すべき項目やサンプルとして活用すべき資料などを解説していきます。

セキュリティ要件とは？

セキュリティ要件とは、システム開発の初期段階に設定するセキュリティ目標のことを指します。

初期段階に設定する理由は、適切なセキュリティ要件を前もって定義しておかなければ、開発したシステムにセキュリティ上の欠陥が発生し、情報漏えいや改ざんなどのリスクが含まれたシステムになる恐れがあるからです。

しかし、現実はどのプロジェクトも初期段階からセキュリティ要件をしっかり定義しているとは限らず、稼働直前になってようやく本格的に検討しはじめるプロジェクトもあります。

小規模システムなら良いかもしれませんが、大規模システムではシステム開発の初期段階からセキュリティ要件をきちんと定義しておきたいところです。後で修正が発生した場合の工数を減らすことが期待できますし、同時にコスト削減や保守性の向上にもつながってきます。

セキュリティリスクを考慮せず本番稼働させることは論外ですが、セキュリティに関する要件は後回しにせず、システム設計や企画の段階から本格的に定義することが重要です。

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

セキュリティ対策を講じるうえで重要な役割を果たすのが、セキュリティの「要件定義」です。適切な要件定義を行い、それに沿ったカタチでシステムを開発することで、ある程度の発生しうるリスクを未然に防止できます。

セキュリティ要件定義を行うためには、まずはセキュリティ要件の種類について理解を深めておくべきです。そこで、ここからはセキュリティ要件の種類について解説を進めます。

この参考資料として、総務省が2015年に作成した「セキュリティ要件ガイドブック」が存在します。こちらは学習・教育クラウドに特化したセキュリティ要件について記載されたものですが、一般的なセキュリティ要件に関しても当てはまることが多いので、こちらを参照して主要なセキュリティ要件の種類をいくつか解説します。

要件1. 内部組織

1つ目の要件は、プラットフォームの安全性を守る「内部組織」の構成、および運用に関するものです。内部組織とは、プラットフォームのセキュリティに関する役割と責任を担い、適切なセキュリティ対策を実施する主体となるもの（担当部署、チームなど）を指します。

本番稼働がスタートすれば、内部組織を中心とした誰がセキュリティ運用を担うのか、運用担当者だけでなく運用責任者も決め、責任の所在を明確にしなければなりません。責任者を決めることは、セキュリティ対策の実施を確実に進めていくために必要なことです。

要件2. 人的資源

2つ目の要件は、プラットフォームを保守・運用する従業員や契約相手など、組織の「人的資源」に関するものです。

従業員に対しては、守秘義務などのセキュリティに関する要項を雇用契約書などに記載することが求められます。また、雇用期間中にはセキュリティ教育を実施し、コンプライアンス意識の徹底や、そのための手順・スキルなどを教えます。

それでも従業員が内部不正などに手を染めてしまった場合には、懲戒手続きなどを行う必要があります。また、雇用契約終了後でも機密事項は口外しないよう取り決めを交わすなど、契約終了後の遵守事項も設定しましょう。

組織の人的資源に対するセキュリティ対策は、雇用前から雇用後までを念頭に置いた施策であることが求められます。

要件3. 資産に対する責任

3つ目の要件は、組織の資産に対する責任などを明確にし、セキュリティ対策を実施するものです。

まずはユーザーの個人情報など、組織として必ず守らなければならない資産を特定するところからスタートです。すべての特定が終われば、漏えいや改ざんがされないように適切に運用管理を行い、情報資産を利用するための規則を明文化しておくことが求められます。

また、自社の社員だけでなく派遣社員や委託先社員などに対しても、契約終了にともない、物理資産・情報資産の速やかな返却を求めましょう。

退職後でも利用できるユーザーIDやパスワードが残っていたり、退職者の端末に機密データが残っていたりするのはとても危険な状態です。必ず対策を講じるようにしましょう。

要件4. 情報分類

4つ目の要件は、組織の資産をセキュリティ上の重要性に応じて分類するものです。

たとえば、「機密レベルの高いフォルダには、役職者などしかアクセスできないようにする」などが、分類手法として考えられます。

また、ユーザーの個人情報については、個人情報保護法に定められた法的対応が必要となります。当然、法的要求に基づく管理体制を敷きましょう。

情報資産の管理責任者を決め、資産の分類結果を従業員に周知し、その取り扱いなどについて注意喚起をすることも必要でしょう。

要件5. アクセス制御

5つ目の要件は、プラットフォームに対するアクセス制御に関するものです。

アクセス制御に関しては、「必要な時に、必要な人に、必要な情報にだけアクセスできる」という状況が、アクセス制御に求められる基本的な要件です。

以下に挙げられるものが、代表的なアクセス制御の要件となるはずです。

・個人情報保護法などに定められたアクセス制御
・システム運用者、ユーザーに対するアクセス権の適切な割り当てと削除
・システム運用者に対する特権的アクセス権限の割り当て
・セキュアなログオン手順の確立
・機密文書が保管されているフォルダへのアクセス制限

要件6. 物理的セキュリティ

6つ目の要件は、物理的および環境的セキュリティに関するものです。

災害・停電・盗難・破壊などからシステムを保護して、環境的セキュリティを高めるための要件です。また、セキュリティレベルを一定以上保つべきオフィスや施設などには、入退出管理により制御を行うなどして、物理的にもセキュリティレベルを高めなければなりません。

要件7. 運用のセキュリティ

7つ目の要件は、運用のセキュリティに関するものです。運用上の使いやすさなども、セキュリティを高めるためには重要な要素です。

たとえば、「オペレーションミスなどによりデータの紛失が起こらないように、オペレーションのマニュアル化などの対策を行う」「システムの性能不足でサービスが停止しないよう、必要なスペックを余裕を持って搭載しておく」といった対応が必要です。

セキュリティ要件定義書の書き方・記載すべき項目

上記の要件をまとめた「要件定義書」を作成するにあたっては、まずユーザー認証やアクセス制御など、セキュリティ対策を講じるべきポイントを決めていきます。そして業界水準や特有の環境なども考慮して、具体的に何を実施すべきかを明記していきます。

その際、Webセキュリティの情報共有と普及を目的とするNPO団体「OWASP Japan」が公開している「Webシステム／Webアプリケーションセキュリティ要件書」を参考にして、要件定義書を作成するのも良いかもしれません。

ここからはそちらの資料の一部を抜粋して解説を進めます。詳細を知りたい方はオリジナル資料を確認ください。

項目1. 認証

特定のユーザーにのみアクセスを許可したいケースでは、まずは「認証」を行う必要があります。認証が成功した後は、アクセス権限の確認が必要です。そのため、認証済みユーザーだけがアクセスできる箇所などはあらかじめ明文化しておくことが求められます。

認証は最初のアクセスだけの実施で終わるのではなく、特に重要な情報や機能へのアクセスが必要なケースでは、再認証を行う必要があります。

認証を行う際には、一般的に「パスワード」が本人確認の手段として利用されます。そのため、パスワードの盗聴や漏えいは防がなければなりません。

パスワードに対する総当たり攻撃などから守るためには、試行速度を遅らせるアカウントロック機能などの実装が不可欠です。

項目2. 認可（アクセス制御）

認証により何らかの制限を行いたい場合、情報や機能へのアクセス（読み込み・書き込み・実行など）権限を確認することで、もう一段階のアクセス制御ができます。

Webページや機能、データ、ファイルなどにアクセスする際には、認証情報を元にして権限があるかどうかの判定を行います。

項目3. セッション管理

セッションとは、ユーザーがWebサイトにアクセスしてから離脱するまでの一連の流れのことを指します。ユーザーがWebサイトに1回アクセスすることを「1セッション」と呼び、このセッション数は、アクセス解析でも最も基本的な単位にもなります。

アクセス解析の際にも大いに役立つセッションですが、セッションがいつまでも残った状態になることはおすすめできません。理由はセッションをのっとる行為（セッション・ハイジャック）が発生し、攻撃対象となるリスクが高まるからです。

一定時間以上Webサイトがアイドル（待機）状態になる場合、サーバー側でセッションをタイムアウトととし、破棄する仕様にする必要があります。また、ログイン画面があるWebサイトでは必ずログアウト機能も設け、ユーザーがログアウトすると同時に、セッションをサーバー側で破棄することが求められます。

【補足：セッションID】

セッションはセッションIDで管理するのが基本ですが、セッションIDはランダムでないと推測が可能になります。セッション・ハイジャックを防ぐためには、推測や漏えい、盗聴などができない工夫が必要です。

セッションIDは基本的にはユーザーがログインに成功した場合に割り当てる、もしくは割り当て直す必要があります。また、原則としてセッションIDはCookieにのみ格納すべきもので、かつCookieにもSecure属性をつけておくのがおすすめです。

ログイン後に使えるセッションIDが平文（暗号化されていない文面）になるタイミングが発生し、漏えいリスクがあるからです。

・Cookie：ユーザーが見るWebサイトからユーザーのスマホやPC内のブラウザに保存される情報のこと。サイトを訪れた日時や訪問回数など、さまざまな内容が記録され、利便性向上やアクセス解析に使われる

項目4. パラメータ

URLに付け加えることができる「name=value（登録やお問い合わせ用のフォームなどで主に活用される、入力した情報をが含まれるパラメータ）」は、Referrer情報などにより外部に漏えいする可能性が高いため、秘匿にすべき情報（ユーザーIDやパスワード）はURLパラメータでやり取りしてはいけません。またパラメータには、参照すべきファイルパスを含めるのもNGです。

・Referrer情報：ブラウザがWebサーバーに送信する情報で、ユーザーが直前にアクセスしたWebページのURLを指す。ユーザーがどこから来たのかがわかる参照元のこと

また、アプリケーションの要件に基づき、フォームへ入力できる文字の種類や文字列の長さの検証も行う必要があります。サーバーの脆弱性を突く攻撃として、非常に長い文字列や特殊な文字列をわざと送る攻撃パターンが存在するからです。

事前に文字列のチェックは必ず行ったうえ、パラメータをそのままプログラム内部で使用しないなどの対策が必要となります。

項目5. 文字列処理

外部からの特殊文字（htmlタグとして認識される文字）の入力により、不正なhtmlタグが実行されてしまう可能性があります。

そのため、特殊文字は以下のようなエスケープ文字（特殊文字を無効化できる文字のこと）に置き換えられるようにしましょう。

・「<」→「&lt;」
・「&」→「&amp;」
・「"」→「&quot;」

実際のコーディング時には、これらを自動的にエスケープするフレームワークやライブラリを使用するべきです。

また、SQLコマンドをコーディングする際には、プレースホルダを使用する必要があります。これはSQLインジェクションを防ぐための標準的対策となります。

・プレースホルダ：入力欄に入力例などのテキストを薄いグレーで表示し、入力方法をユーザーに提示することができる機能のこと。ユーザーが入力を始めると、入力の妨げにならないよう表示は消える

・SQLインジェクション：アプリケーションの脆弱性により本来の意図ではない不当な「SQL文（データベースを制御するための命令文）」が作成されてしまい、データベースのデータを不正に操作される攻撃のこと

項目6. https

httpsとは、「Hypertext Transfer Protocol Secure」の略称で、SSL（暗号化通信）によってセキュリティレベルを高めたhttpのことを指します。httpsを利用することで、平文での通信ではなく暗号化された通信が可能となり、悪意ある第三者による情報の盗聴や改ざんなどを防止するのに役立ちます。

しかしhttpsで提供されているにもかかわらず、Webサイトにアクセスした場合にブラウザから警告メッセージ等が発せられるケースがあります。そのような場合、正常なhttpsでの運用がなされておらず、盗聴や漏えい、改ざんのリスクがあることを意味するため、適切なサーバー証明書（SSL認証）を取得する必要があります。

また、オリジナルの資料では、「SSL2.0を無効にすること」と記載されていますが、POODLE脆弱性の問題が発覚している以上、「SSL3.0」の使用も禁止するべきだといえます。

・POODLE脆弱性：暗号化された通信から、その脆弱性を突いて認証情報やクッキー情報を盗み出す攻撃のこと。SSL3.0の無効化で対策できる

項目7. Cookie

先ほども触れた通り、Cookieとはユーザーが一度訪問したWebサイトに再訪する際、IDやパスワードの情報を再入力せずログインできる仕組みのことを指します。

Cookieには「name=value」として任意の値を格納することができますが、Cookieの値は盗聴されるリスクが常につきまといます。ですので、それらの値はセッションIDなどの情報に紐づけた代替情報を格納して管理することが必要です。また、セッションIDを格納する場合には、極力Secure属性を付けるようにしましょう。

項目8. その他

その他にもいくつか必要な対策があるため、いくつかご紹介します。

【エラーメッセージでユーザーIDやメールアドレスなどの存在証明をしない】

認証失敗時に「パスワードが間違えています」というエラーメッセージを表示したら、逆説的に「ユーザーIDは合っている」ことを意味してしまいます。

攻撃者はこれを利用して、ユーザーIDを探ることができます。エラーメッセージでユーザーIDやメールアドレスなどの存在がわかるようなメッセージは出力してはいけません。

「ユーザーIDもしくはパスワードが間違っています」というエラーメッセージにしましょう。

【メール送信処理には専用のライブラリを使用する】

メール送信処理時にユーザーが指定した値を挿入できるケースでは、不正なコマンドなどが挿入されてしまう恐れがあります。そのため、メール送信専用のライブラリなどを使うことも検討しましょう。

ただし、ライブラリなら絶対大丈夫という訳ではありません。実績があるライブラリであっても、脆弱性が後から発見されるのはよくあること。セキュリティ情報に関する最新の動向をチェックする癖はつけておきましょう。

項目9. 提出物

オリジナルの資料では、提出物として「サイトマップ」「画面遷移図」「ディレクトリツリー」が挙げられています。

認証やアクセス制御が必要な項目や、httpsによる保護が必要な画面などは明確にする必要があり、かつWebサイト全体の構成もきちんと把握することが求められます。上記の資料は最低限用意する必要はあるでしょう。

セキュリティ要件定義書のサンプル

セキュリティ要件定義も突き詰めれば奥が深い分野ですが、まずはここまで解説してきた通りの基本的なセキュリティ要件を盛り込むことからスタートしてみてください。

その際に活用できるのが、今まで解説してきたOWASP Japanの「Webシステム／Webアプリケーションセキュリティ要件書」です。

基本的に下記の点さえ守れば、自由に利用することが可能です。

・表示：あなたは原著作者のクレジットを表示しなければなりません
・継承：もしあなたがこの作品を改変、変形または加工した場合、あなたはその結果生じた作品をこの作品と同一の許諾条件の下でのみ頒布することができます

この要件書をベースにして、案件ごとに合わせたカタチでセキュリティ要件を取り決めることが、効率的かつ要件漏れを防げるやり方のひとつです。セキュリティ要件定義書を作成する際には活用してみましょう。

セキュリティの要件定義はGIGにお任せください

適切なセキュリティ要件定義を作成し、それに沿ったカタチでシステム開発を行っても、セキュリティに関するリスクがゼロになることはありません。

既知の攻撃パターンでも、今までと違うカタチで脆弱性を突いて攻撃してくることも多分にあります。ですが、情報漏えいやウイルス感染などは絶対に起こしてはいけません。起こさないためにもセキュリティ要件はきちんと定義し、できる対策はまんべんなく実施する必要があります。

とは言っても「どのようなセキュリティ対策が自社にとっての最適解なのか」の判断は正直難しい部分でもあります。セキュリティ要件定義についてご支援が必要な場合は、ぜひGIGにお問い合わせください。

■Webサイト制作事例
Chatwork - サービスサイト制作 / マーケティング支援
ミクシィ - コーポレートサイト制作 / デザイン・保守運用
SmartNews - サービスサイト制作 / マーケティング支援

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。