セキュリティ対策の検討方法 – セキュリティ方針と設計ポイント

はじめに

日常の中では意識する機会は少ないですが、セキュリティ事故が発生すると事業継続にダメージを与える事態になる可能性もあるのでセキュリティ対策は非常に重要です。

しかし、世の中に完璧なセキュリティ対策というものはありません。
どこまで費用をかけて完璧に近づけるのか、システムのセキュリティ要件を見極めながら対策することになります。
セキュリティの脆弱性を残してはいけませんが、コストバランスを考えながら対策を取捨選択していきます。
そのためにはセキュリティに対して、ある程度の知識が求められます。

しかしセキュリティの世界は広く、そして深いです。
その中から最適な対策を選択するには、システム要件定義や設計で要点を抑えておくことで、検討のしやすさが変わります。
ここでは、これからシステム構築を始めるにあたり考慮すべきセキュリティ対策の進め方について解説します。

セキュリティを含めた非機能要件については、別記事「非機能要件を進める４つのステップと検討ポイント」を参考にしてください。

セキュリティの方針検討

まず、セキュリティに対する全体の方針を検討します。
そこでのポイントは大きく3つあります。
これらはシステム企画段階や要件定義といった上流工程で方針を決めます。

セキュリティ要件

システム要件定義にて、セキュリティ要件を検討します。
これにより、システムで考慮すべき対策の方針を決めていきます。
具体的な検討事項については、IPAの非機能要件グレードの大項目「セキュリティ」を参考にするとよいでしょう。

セキュリティ設計で注意すべきはシステム全体で俯瞰しながら検討することです。
「ウィルス対策ソフトを入れる」「アカウント管理する」など、思いつく項目を羅列するだけでは抜け漏れが発生します。
システムの目的や環境、構成図や運用など全体を俯瞰しながら検討します。

システムの観点から見る場合、次のレイヤを意識して検討することも大切です。

アプリケーション
製品やスクラッチで作成するアプリケーションに関するセキュリティ全般

ミドルウェア
DBを含む、ミドルウェアに格納されている情報を保護する

OS
アカウント管理、セキュリティ防御するための要塞化、マルウェア対策など

ネットワーク
不正アクセスの検知や防御など

脆弱性検証

構築したシステムにセキュリティホールがないかセキュリティ診断をします。
このセキュリティ診断は外部の専門家などに依頼するのが一般的です。
特殊なスキルが必要であることに加え、第三者機関がチェックすることで診断結果に信ぴょう性が出てきます。
開発したシステム会社が診断すると、診断が甘くなっているのではないか、という疑念を持たれることがあるためです。

このセキュリティ診断の実施例です。

• 専門家による設計書チェック、担当者への問診を行う
• ツール実行によるWeb・アプリケーション診断
• ペネトレーションテスト

ペネトレーションテストは、ホワイトハッカーが実際に本番環境に侵入できるか検証します。
セキュリティレベルの高い重要施設やシステムで用いられます。

システム運用

セキュリティ対策は仕組みを導入するだけでなく、守り続けるための運用も検討します。
例えばOSやミドルウェアの脆弱性対策パッチの定期更新や、セキュリティインシデントの発生状況を監視する体制などです。

セキュリティインシデントが発生した場合の運用ルールも整備します。
問題発生時のエスカレーションルールや、LANケーブルを抜くなどの対策です。
またセキュリティ事故対応を想定して、社内にCSIRTを組織したり、社外のCSIRTと連携することも検討します。
CSIRT（シーサート）とは「Computer Security Incident Response Team」の略でセキュリティ対応チームのことです。

セキュリティガイドライン

セキュリティ対策を検討するとき、最初にガイドラインの有無を確認します。
それでは、どのようなガイドラインがあるか見ていきましょう。

企業管理のガイドライン

自社、また受注開発であれば客先にセキュリティガイドラインが整備されていることがあります。
存在するのであれば、基本的にガイドラインに準拠する必要があります。
このガイドラインが適用できないのであれば、要件とのFit&Gapを行い、適用できない理由を明確にして承認を得ます。

もしガイドラインに準拠していない環境でセキュリティインシデントが発生した場合、構築側の責任とされる可能性があります。
そのような事態を回避するためにも、必ずガイドラインを確認する必要があります。

業種固有のガイドライン

業種によっては、対策必須とされるガイドラインがあります。
例えば金融機関であればFICS、クレジットカードならPCD DSSがあげられます。

システムによっては、これらの対策必須とされるガイドラインが存在する場合があります。
そのガイドラインを守っていない場合、罰則やペナルティをうける場合もあります。

未経験の業種を担当することになった場合、そのようなガイドラインが存在するのか調べておくと良いでしょう。

組織体系ガイドライン

情報セキュリティマネジメントシステム（ISMS）の国際規格である「ISO/IEC 27001」や「ISO/IEC27002」を活用する方法もあります。
これは組織が保護すべき情報資産を洗い出し、セキュリティを維持、改善するための組織を体系化したものです。
セキュリティ技術うんぬんではありませんが、セキュリティを構築・運用するための規格であるため、セキュリティ運用を検討するときに使用できます。
クライアントのセキュリティ体制について見直し、提案することができればベストです。

設計ポイント

ここではセキュリティ設計で盛り込むべき基本項目を説明します。
システム特性により対応不要の項目もありますが、なぜ不要なのか理由を明確にする必要はあります。

アカウント管理

システム利用者、OSやミドルウェアなどのソフトウェアのアカウントを検討します。
不正アクセスを防ぐためにはアカウント乗っ取りを避けたり、ユーザに権限以上の操作を許さないことが重要です。
検討内容について説明します。

特権アカウントの管理

システム管理者など、特別に権限の強いアカウントを管理します。
どのユーザを誰が使用するのか、パスワードの更新頻度など、特権アカウントについて整理します。
初期設定されているAdministratorなどは不用意に残さないように注意してください。

ユーザアカウントの管理

一般ユーザのアカウントについても管理する必要があります。
アカウントを記録、棚卸するだけでなく、アカウントを追加・変更・削除するときの承認方法についてもルール化します。
また使わなくなったアカウントを削除や無効化することも大切です。

ユーザ数が少なければ台帳管理することもできますが、数が膨大になると人手では難しくなる場合があるので、その時はツール活用を検討します。

権限設定は最小にする

アカウントに権限設定する場合、必要最小限にとどめます。
例えば何でもできる権限を全ユーザに設定すると、不正操作や誤操作でトラブルになることもあります。

しかし権限を細かく設定しすぎると管理が煩雑になる場合もあります。
運用できる範囲を確認しながら検討を進めます。

パスワードポリシー

アカウントごとに設定するパスワードについてルール設定します。
例えば、次の内容についてルールを定義します。

• パスワードの長さ
• パスワードの複雑さ
• パスワード更新頻度
• 有効期限

パスワードポリシーを厳しくすれば、それだけセキュリティ向上します。
ただ厳しすぎるとユーザのパスワード管理が難しくなり運用に支障が出る可能性があります。
こちらも運用できる範囲を確認しながら検討を進めます。

共用アカウントの有無

例えば部門やチームごとに１つの共用アカウントを作る場合があります。
当然、アカウントを共用するということはIDとパスワードを共有するため、情報が第三者に流出する可能性が高くなります。

また、同じIDを使いまわすので、誰が操作したのかログから判断できません。
それでも共有アカウントを作成するのであれば、そのデメリットを運用でカバーするなど対策を検討します。

アクセス制御

コンピュータやネットワークにアクセスできるユーザを制限することでセキュリティを担保します。
アクセス制御は「認証」「認可」「監査」の３つに分けられます。

認証

許可されたユーザだけがシステムを利用できるように認証方法を取り決めます。
認証方法はID／パスワードだけでなく、生体認証やツールを使った認証などあります。
よりセキュリティを高めるために、認証方法を多重化させて多段階認証する場合もあります。
サーバや端末の認証だけでなく、サーバルームへの入室方法やラックの施錠といった物理的な認証も検討することがあります。

認可

アクセス制御リスト（ACL）をもとに、ユーザがアクセスできる範囲を制限します。
アクセス制御リストとはネットワーク通過の許可設定であり、該当しないユーザはネットワークにアクセスできません。

監査

外部からのアクセス履歴を記録するためにアクセスログを出力します。
このログを検証することで、アクセス制御の方法を改善することができます。
またセキュリティインシデントが発生したときの調査で利用します。

データ保護

ファイルや通信を暗号化することで、ファイルが外部に流れたりネットワークを盗聴されても情報を保護します。
またネットワークに侵入されたとしてもファイルが暗号化されていればファイルやデータの改ざんが難しくなります。

不正アクセス監視

ネットワークやサーバへの不正アクセスを検知、防御します。
不正アクセスを監視するサービスと、ファイアウォール、WAF、IDSやIPSなどのツールを使用して環境構築する方法があります。
ここでは環境構築する場合のツールについて説明します。

ファイアウォール

通信の送信元、送信先を監視し、許可された通信だけ通すための仕組みです。
通信の中身までは確認しません。

WAF（Web Application Firewall）

Webアプリケーションを防御するための仕組みです。
通信の中身を精査し、SQLインジェクションやクロスサイトスクリプティングなどWebアプリケーションを攻撃する目的でないかチェックします。
これはWebアプリケーションのシステムに対しての監視となるため、OSやミドルウェアへの攻撃は防御できません。

IDS（不正侵入検知）

ネットワーク上の通信パケットを監視したり、サーバの受信データやログをチェックします。
何かしらの不正侵入の兆候があった場合、システム管理者に警告メールを発報します。

IPS（不正侵入防御）

ネットワークやシステムを通過するトラフィックを監視し、パケット内容を確認します。
そこで不正通知と判断したらアクセスを遮断するなどの処置をとります。

IDSと似ていますが、不正検知した後の動作が異なります。
IDSは管理者にアラート通知するのに対して、IPSは防止、遮断などの対応を行います。

マルウェア対策

マルウェア対策は、どのようなシステムでも必ず対策する必要があります。
外部とネットワークが隔離されている環境でも、USBなどで持ち込まれたファイルから感染することも考えられます。

基本的にはマルウェア対策ソフトの導入が挙げられますが、ユーザの運用検討も含まれます。
例えば「USBを使用しない」「不要なアプリは入れない」などルールを決めたり、セキュリティ教育を行うこともマルウェア対策です。

セキュアコーディング規約

プログラム作成する場合、セキュアコーディング規約を定めます。
コーディング規約は、一般的にコーディング作法を全体統一させるために用いられますが、コードの書き方によってセキュリティ脆弱性につながる場合もあります。
極端な例ですが、IPアドレスがハードコーディングされるような問題プログラムをなくすためにはルールが必要です。
当たり前と思われることでも、人によっては考えが違う場合もあるので、ルール化する必要があります。

バックアップ

セキュリティインシデントが発生しないための対策を講じるのが基本ですが、それでも問題が発生した場合の対策は必要です。
ウィルスに感染したシステムは、どこに不正プログラムが潜在しているかわかりません。
ましてランサムウェアのように暗号化されてシステムが利用できなくなることも考えられます。
そのような事態になっても事業継続できるようにシステムのバックアップを取ることは大切です。

システム全体をリストアできる準備を心がけましょう。

構成管理

システムで稼働するプログラムの構成管理だけでなく、使用しているミドルウェアやフレームワークなどのバージョンを管理して把握する必要があります。
もし脆弱性が発見されたとき、担当しているシステムにも影響するのか確認できるようにするためです。
セキュリティ関連は対策に時間がかかるほど脅威にさらされる可能性が高まります。
それらの情報がすぐに把握できるよう準備しておくことが大切です。