|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
本章では、システムの一般的なセキュリティ対策についての指針を記載します。
本章の内容は、日本政府が情報セキュリティ対策のための統一基準を定めた、「政府機関等の情報セキュリティ対策のための統一基準群（平成28年度版）」(http://www.nisc.go.jp/active/general/kijun28.html)の内容に基づいています。
出展：「府省庁対策基準策定のためのガイドライン （平成 28 年度版）」
（https://www.nisc.go.jp/active/general/pdf/guide28.pdf）
「府省庁対策基準策定のためのガイドライン （平成 28 年度版）」
（https://www.nisc.go.jp/active/general/pdf/guide28.pdf） を加工して作成。
主体認証とは、情報資産にアクセスする人や機器が正当であるか否かを検証することをいいます。
ここでは主体認証の例として、記憶による認証、所持による認証、生体情報による認証について説明します。
パスワードなど、正規の利用者のみが記憶しているデータに基づいて利用者本人か否かを認証する方法です。
ICカード又はワンタイムパスワード生成器など、正規の利用者のみが所持している物によって利用者本人か否かを認証する方法です。
指紋や静脈など、正規の利用者の生体に基づくデータによって利用者本人か否かを認証する方法です。
記憶による認証の代表例として、パスワードによる認証が挙げられますが、 システム側で、以下に挙げる対策を行うことによって、セキュリティを強化することができます。
パスワードとして、英字の大文字/小文字、数字を組み合わせた文字列を強制することによって、 攻撃者が容易に推定できないパスワードを設定させることができます。
パスワードとして、ある桁数以上の文字列を強制することによって、攻撃者が容易に推定できないパスワードを設定させることができます。
パスワードに有効期間を設定し、有効期間が過ぎたらパスワードの変更を強制することによって、 攻撃者によりパスワードを解析されるリスクを低減することができ、また、パスワードが解析された場合、 不正利用され続ける時間を短くすることができます。
例えば、連続でのログイン失敗回数に上限値を設け、この上限値を超えた場合は、次回ログイン試行までに一定の期間
ログイン試行を受け付けないようにすることが考えられます。
また、ログイン失敗ログを取得し、その取得内容を継続的に監視することにより、大量のログイン失敗を検知する仕組みを導入することが考えられます。
認証を行う場合、認証情報が第三者に対して明らかにならないよう、適切に管理する必要があります。
正しい主体にのみIDと認証情報を付与し、認証情報を受け取ったら速やかに初期パスワードを変更するよう促します。
一人に複数のIDを付与すること、一つのIDを複数人に付与することを禁止します。
本人の電子メールアドレスに対して主体認証情報を送付します。その場合、必要に応じて暗号化して配布します。あるいは、本人の電子メールアドレスに対して主体認証情報を直接送付するのではなく、主体認証情報を入手するためのウェブサイト情報を送付する方法も有効です。
また、ワンタイムパスワードを利用し、認証情報の漏えい時の影響度を小さくすることも有効です。
ワンタイムパスワード方式とは、認証を行うたびに毎回異なるパスワードを利用する方式です。毎回異なるパスワードを使用するため、ある時点でのパスワードが盗聴されても、不正アクセスを受ける可能性は低くなります。
主体認証情報が第三者によって悪用されることを防ぐため、以下のような主体認証情報の漏えい防止策、主体認証情報漏えい時の不正利用防止策を行う必要があります。
利用者の役割等に応じて、主体認証情報へのアクセスを制限します。
主体認証情報の漏えいを防ぐため、ネットワーク経由のログインを制限します。
過去に漏えいした主体認証情報の不正利用を防止するため、定期的に変更することを促します。
主体認証情報が第三者に漏れたとしても悪用できないように、保存する際、通信する際に暗号化します。
主体認証情報が漏えいしたことが判明した場合、直ちにその利用を停止させる、無効化する等の措置を取ります。
システム内のさまざまなリソースを管理する上で、いつ、誰が、何に対して、どのような権限でアクセスできるかを指定するため、必要に応じて、アクセス制御を導入します。
アクセス制御方法としては、次のようなものがあります。
利用者の役割や、属するグループに応じてアクセス対象を制限します。
メンテナンス時間を考慮する等、時間帯によってアクセスを制限します。
システムリソースの枯渇を防ぐため、同時利用者数を制限します。
課金を行うシステム等、不正利用を防ぐために同一IDでのアクセス数を制限します。
特定のIPアドレスを持つ端末のみの許可や、外部のIPアドレスからの接続を拒否します。
アクセス制御とは、情報資産に対する参照、更新、実行などの正当な権限を持つ者のみに情報資産の利用を許可することです。
不正なアクセスを防ぐため、以下を例とする手段を講じる必要があります。
限られた者のみ読取可能とする属性を付与します。
不適当な者から変更されないよう、書換禁止の属性を付与します。
システムの管理機能として、一般的に管理者権限にはあらゆる操作が許可される特権が付与されています。
この特権が悪意ある第三者に入手された場合、情報等の漏えいや改ざんの恐れがあります。
したがって、限られた主体のみに管理者権限が付与され、不正に利用されないよう、権限管理機能を導入する必要があります。
権限管理機能の例を以下で説明します。
あらかじめ限られた操作が可能な特権を付与することにより、特権を使った不正な操作が発生する機会を減らし、 結果的に安全性を強化する方法が考えられます。例えばUnix系システムにおけるsudoコマンドが挙げられます。
内部からの不正操作を防ぐために、ある処理に対して複数名による認証操作がなければその処理自体を完遂できない 「デュアルロック機能」を導入します。
識別コード、主体認証情報が正しく利用されるよう、認証情報は適切に管理する必要があります。その際の注意点として以下のような点が挙げられます。
第三者が知りえる初期パスワードの利用を防ぐため、速やかな初期パスワードの変更を指示します。
他人のIDを使用した不正アクセスを防止するため、1人につき1つのIDを付与することを前提とし、1人が複数のIDを所持する、または1つのIDを複数人で共有して使用することを禁止します。
主体認証情報など機密事項の漏えいやシステムへの攻撃を防ぐため、業務上必要な場合に限定して管理者権限のIDを付与します。
不要なIDは無効化・または削除します。また、定期的に不要なIDがないか点検し、不正利用を防止します。
システムにおけるログとは、システムの動作履歴、利用者のアクセス履歴、その他必要な情報が記録されたものであり、
悪意ある第三者による不正侵入や不正操作などを検知するための重要な材料となるものです。
また、システムにセキュリティ上の問題が発生した場合には、ログは事後の調査で、問題を解明するための重要な材料となります。
したがって、仕様どおりにログが取得され、また、改ざんや消失等が起こらないよう、ログが適切に保全される必要があります。
以下に、取得すべきログの例を記載します。
ログイン失敗ログを監視することにより、大量のログイン失敗を検知します。これにより第三者による不正ログイン攻撃の有無を検知します。
不正アクセスを検知するために、サーバ装置へのアクセスに関するログのほか、サーバ装置が異常等を検出した際に出力するログ（エラーログ）を確認することも有効です。
なお、ログを取得する場合、システムに含まれる構成要素（サーバ装置・端末等）のうち、時刻設定が可能なものについては、基準となる時刻に同期させ、ログに時刻情報が記録されるよう設定する必要があります。
情報システムにおけるセキュリティの脅威は多様化しており、部外者によるシステム外部からの不正侵入等の意図的な脅威だけでなく、内部のシステム利用者による誤操作等の偶発的な脅威も情報セキュリティインシデントの原因となり得ます。 情報システムのセキュリティ担当者がこうした脅威による情報セキュリティインシデントの発生を検出し、被害範囲の特定や再発防止策を講じることを可能にするためには、システムが出力するログメッセージに次の情報を含めることが有効です。
情報セキュリティインシデントの原因となる操作を「誰が」行ったのか。例えば、IPアドレス、セッションID、DBMSのユーザIDなど。
操作を行ったユーザや機器の識別コードはいつ発行されたのか。例えば、DHCPによるIPアドレスの払い出し記録、ユーザ名の登録履歴など。
ユーザや機器がシステムの「何に」に対して「どのような」操作を行ったのか。例えば、DBのレコード読み取り、ファイルの削除、外部へのメール送信など。
情報セキュリティインシデントの発生原因となった一連の操作が「いつ」行われたのか。
システムごとに必要に応じた追加情報。
情報セキュリティインシデントの原因となる操作が発生した際に、攻撃者が入手した情報とシステムの監視担当者が受け取ったインシデント発生を示す通知の内容。
採取したログからセキュリティインシデントの調査や追跡を十分に実施するためには、ログの保存期間を適切に設定しなければなりません。 標的型攻撃に関して、攻撃の初期段階から経緯を確認する観点から、過去の事例を踏まえると、一般に１年以上ログは保存することが望ましいとされます。実際にはシステムや業務の特性を考慮して、ログファイルごとに保存期間を調整します。
さらに、採取したログ自身も情報システムの資産となるため、適切なアクセス権限を設定して不正な消去、改ざん及びアクセス等の脅威から保護する必要があります。 サーバがファイルに直接出力したログファイル（アクセスログ・シスログなど）だけでなく、ログ収集ソフトウェアで収集した情報やログ可視化ソフトウェアのUI画面なども保護の対象です。
[ ログの管理 ] の通り、セキュリティ対策として情報システムでは様々なログを採取する必要があります。 しかし、システムがログとして取得する項目数、利用者数等が多くなるにつれて、ログの量は膨大になり、 目視でセキュリティインシデントを検出することが困難になります。
従って、システムが出力するログの量に応じて、以下に代表される各種ツールを活用してログの点検・分析・通知の自動実行を検討します。
インターネットからアクセスされるサーバ装置や、そのアクセスに利用される通信回線装置及び通信回線の中から、特に高い可用性が求められるものを優先的に監視する必要があります。不正行為や不正アクセス等を監視するために、以下を例とする対策を行う必要があります。
取得したアクセスログ等を定期的に確認することで、不正侵入や不正操作を検知します。ログの取得については、 [ ログの取得 ] を参照してください。
IDS/IPSは、ネットワークを流れるパケットの監視や、サーバー上の受信データやログを確認することで、不正侵入の検知や防御を行います。
対象サーバに不正プログラムが存在しないかどうか確認します。また、不正プログラムが存在する場合はその駆除を行います。
稼働しているソフトウェアが不正に変更されていないかどうかを検証します。
攻撃を受けることに関する監視として、稼動中か否かの状態の把握、また、CPU使用率、メモリ使用量、プロセス数、ディスクI/O量、 ネットワークトラフィック量などの、システム構成要素に対する負荷の定量的な把握を行います。
サーバ装置、端末、通信回線などを監視している場合、監視対象の状態は一定ではなく変動することが一般的です。 監視対象の状態の変動を把握するという目的に照らして、時間変動、曜日変動、週変動、月変動、季節変動等を考慮したうえで、監視記録の保存期間を定める必要があります。
システムを構築するために使用するソフトウェアには、脆弱性が発見されることがあります。脆弱性を対策せずそのままにしておくと情報漏洩等、
大きな社会問題を引き起こす可能性もあります。そのため、定期的に脆弱性情報を入手し脆弱性に該当するソフトウェアを使用していないか確認
する必要があります。脆弱性情報は以下のようなサイトから入手するとよいでしょう。
脆弱性情報を入手し、その脆弱性がご使用のWebOTXへ該当するか否かはWebOTXのWebページやNECサポートポータルから
確認することが出来ます。脆弱性に該当する場合の対処方法や修正パッチを入手することができますのでご確認ください。
インターネットからアクセスを受ける情報システムに対する脅威としては、第三者から攻撃を受けて利用者がサービスを利用できなくなることが想定されます。このため、攻撃を想定し、システムの可用性を維持するための対策を実施する必要があります。
インターネット業務システムでは、不特定多数からのアクセスを想定する必要があるため、 内部ネットワーク(社内LANなど)と外部ネットワーク(インターネットなど)との間のアクセスを制御し、 外部からの不正な侵入を防ぐ必要があります。 また、WAFを設置することで、ファイアウォールでは防御し切れない攻撃に対応することができ、セキュリティレベルをより強固にすることができます。
Web サーバとアプリケーションサーバの間にも、Web サーバからの特定のサービスのみがアプリケーションサーバにアクセスできるようにファイアウォールを導入することで、アプリケーションサーバが外部から直接アクセスされることを禁止でき、さらに強固なセキュリティレベルを確保することができます。このとき、Web サーバは外部のインターネットからも内部のネットワークからも限定的にアクセスができます。この２つのファイアウォールの間に挟まれたネットワークをDMZ(非武装地帯)と呼び、高い機密性が求められるアプリケーションサーバやデータベースサーバに対する強固なセキュリティを確保するために用いられます。
脆弱な通信プロトコルや不要な通信プロトコルの利用を制限することで、不正行為が行われる可能性を低減することができます。
攻撃への対策を講じたとしても、攻撃を100%防御することは不可能です。したがって以下に挙げるような、攻撃を受けた場合の影響を最小化するための手段も備えておく必要があります。
攻撃を受けた場合に、直ちにシステムを外部ネットワークから遮断するための手段を検討します。
攻撃を受けた場合に備え、サービスを提供するサーバ、通信回線装置、通信回線についての負荷分散、あるいは切り替えなどによって、サービスを継続することができるようにシステムを構築する必要があります。
SSL (Secure Sockets Layer) / TLS (Transport Layer Security) は、通信を暗号化するためのプロトコルです。
クライアントとサーバ間の通信データを暗号化することで、第三者による盗聴や改ざんなどを防ぐことが可能となります。
暗号化のアルゴリズムには様々なものがあり、複数のアルゴリズムから利用するものを選択することが可能です。 暗号技術は、計算機を用いても現実的な費用と時間で解読できないことを前提に、その安全性を保障していますが、計算機の性能向上や暗号解読技術の進歩により、その安全性が低くなることがあります。 例えば、SSL 1.0/2.0/3.0は、脆弱性があるため、推奨されていません。また、256bit以下の鍵は、推奨されていません。 そのため、アルゴリズムの選定にあたっては、CRYPTREC (Cryptography Research and Evaluation Committees) 等の最新の情報を確認して、十分な強度を持つものを選択する必要があります。
また、暗号化をすることで計算量が増え、性能に影響します。暗号化が必要となる経路を見極め、適切に使い分ける必要があります。
SSL (TLS) を利用するには、サーバに電子証明書 (サーバ証明書) の導入が必要です。 サーバ証明書には、身元証明のための情報と、暗号化のための公開鍵等が含まれており、通信の暗号化、および、改ざんの検出を行うことが可能となります。 また、信頼のある第三者機関 (認証局、CA (Certification Authority)) から発行されたサーバ証明書を利用することによって、そのサーバが正当であることの証明となります。
クライアント認証は、そのクライアントが、保護されたリソースへのアクセスを許可されているかを確認することです。 例えば、ユーザIDとパスワードだけによる認証の場合、ユーザIDとパスワードが流出すると、なりすまし等の問題が発生する可能性がありますが、それにかわって (あるいは、それに加えて)、クライアント証明書を利用することによって実現します。
クライアント証明書は、プライベート認証局や、信頼のある第三者機関 (認証局) で発行し、あらかじめクライアント端末にインストールして利用します。 サーバとの通信時にサーバからの要求に応じてクライアント証明書を提示し、それをサーバ側で検証することによって、接続元であるクライアントが正当であるかを確認します。
遠隔地から保守や診断を行う、リモート管理に関するセキュリティ確保のために、以下を例とする対策を行う必要があります。
次章の WebOTXを利用する場合のセキュリティ対策の設定 では、本章で示した一般的なセキュリティ対策を踏まえて、WebOTXを利用したシステム構築に関するセキュリティ対策について説明します。
1. WebOTX にて、WebOTXに関するセキュリティ対策を説明します。
下図の紫色の点線で囲んだ部分の説明となります。
2. Webサーバ にて、WebOTXで利用するWebサーバに関するセキュリティ対策を説明します。
下図の緑色の点線で囲んだ部分の説明となります。
3. アプリケーション にて、WebOTX上で動作するアプリケーションに関するセキュリティ対策を説明します。下図の赤色の点線で囲んだ部分の説明となります。
