セキュリティについて知ろう
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/bft_infra_main_8.jpg?itok=llUKF7Ln)
はじめに
みなさん、こんにちは。今回は「セキュリティ」をテーマに解説します。弊社は今でこそSIを軸に商売を行っていますが、2002年の創業当時はセキュリティサービスを主軸にしており、「Nessus」というセキュリティスキャンソフトを日本語化するというマニアックなこともやっていました。当時はまだ情報システムのセキュリティに関する意識は低く、積極的にお金をかけているお客様も少なかったと思います。
時が流れて、今や情報システムは私たちの生活と密接につながり、攻撃者にとって格好の標的となりました。情報セキュリティ関連のニュースがメディアを賑わせることも多くなり、情報セキュリティ人材も圧倒的に不足しています。
システム全体まで広げると多くのセキュリティリスクや対策が考えられますが、今回はインフラに限定して解説します。
セキュリティとは
1. セキュリティの定義
「セキュリティ」と言われて、皆さんはどのようなことを思い浮かべるでしょうか。「ハッカー」「サイバーテロ」「Windowsアップデート」、「ファイアウォール」や「Struts2の脆弱性」なんて考えた方は随分勉強されている方かもしれません。ただ、捉えどころがないというのが正直なところだと思います。
こんな時には要素を分解してみると良いのですが、今回は要求定義で使用されるフレームワーク「非機能要求グレード」を利用して分解してみたいと思います。
- 非機能要求グレード
情報システムには「業務の機能に関する要求」と「業務機能以外の非機能に関する要求」が存在する。非機能要求グレードはシステム発注側と受注側での認識齟齬を防ぐ目的で、非機能要求としてまとめるべき項目を体系的に整理したツール群のこと
2. 非機能要求グレードにおけるセキュリティ
非機能要求グレードにおいて、セキュリティは図1のように分解されています。
ここからは、図1の赤枠で囲った部分の各項目に対してインフラとしてどのように対応しているのか、またどのような対応が考えられるのかを紹介していきます。イメージしやすい具体的な対応内容をもとに、頭の中を整理していただければ幸いです。
セキュリティ要求に対するインフラの対応
1. アクセス・利用制限
アクセス・利用制限は「認証機能」「利用制限」「管理方法」から構成されています。管理方法はルールの策定などになるため、ここでは認証機能と利用制限について解説します。
1.1. 認証機能
現在のシステムにおいてはIDとパスワードを使用したユーザ認証が主流ですが(図2)、マイナンバーのようにICカードを使用した認証を行っているシステムもあります。また、最近では技術の発展とともに生体認証や顔認証といった選択肢も採られるようになってきました。
認証を行う場合にはシステムインフラとして認証基盤が必要となりますが、その選択肢はOS標準の認証機能、認証ミドルウェア(RADIUS製品、LDAP製品やActiveDirectoryなど)、アプリケーションによる作りこみなど複数存在します。どれを選択するかはそれぞれの特徴を把握したうえでシステムごとに決めていきますが、アプリケーションとも密接に関係してくるため、インフラ担当とアプリケーション担当が協力して設計していくことが多くなります。
1.2. 利用制限
認証されたユーザごとに使用できるリソースを制限することです。Windowsではユーザごとに読み取りや変更といったアクセス許可を制御できますが(図3)、UNIXやLinuxでも同様に制限できます。
ミドルウェアも制限をかけることができますが、例えばDBサーバミドルウェアであればデータベースに接続する権限やデータベースユーザを作成する権限などがあります。
このような利用制限を設計するのもインフラエンジニアの仕事ですが、アプリケーションの実装とも関係してくるため業務用のユーザ権限に関してはヒアリングを行い設計していきます。
2. データの秘匿
システムが扱うデータには、大きく分けて「ネットワーク上を流れるデータ」と「各サーバや機器に蓄積されるデータ」があります。データを秘匿するには暗号化する方法がありますが、暗号化をしておけば万が一データを盗まれても中を見ることができません。図4はCiscoのスイッチにログインする際の通信データをパケットキャプチャソフトで傍受したものです。ログインプロンプトの[ Password: ]という文字列が表示されているのが確認できると思いますが、この後の通信をさらに傍受していくとパスワードを盗むことも可能です。
暗号化をする際には元のデータを「暗号化アルゴリズム(DES、AESといったものがある)」に従って暗号化します。ただし、暗号化アルゴリズムは誰でも入手できるものなので、そのままでは簡単に復号化されてしまいます。そこで利用者ごとに暗号化内容を変化させる「何か」が必要となるのですが、それが「暗号鍵」です。
この手の話題になると必ず出てくる例がシーザー暗号ですが、これは「アルファベットの文字をずらす」という暗号化アルゴリズムによって暗号化します。例えばBFTというデータを暗号化する際に1文字ずらすとCGUとなりますが、ずらす数が3文字や5文字と選択肢があることで復号化が難しくなります。この3文字や5文字が暗号鍵に該当します。
インフラエンジニアとしては、暗号化する対象や暗号化アルゴリズム・プロトコル、暗号鍵の複雑さなどを決めていく必要がありますが、性能とのトレードオフといった側面もあるため注意が必要です。
現在のシステムでよく目にする暗号化は、以下のようなものです。
- インターネットからロードバランサ・Webサーバ間の通信データをSSL/TLSにより暗号化
- DBサーバの重要な一部のデータを暗号化
すべてを暗号化してしまうと性能面で劣化が発生するため、注意する必要があります。
3. 不正追跡・監視
不正追跡・監視は「不正監視」と「データ検証」から構成されています。ここでは、システムを監視して不正を検知することが目的となります。
3.1. 不正監視
アナログな方法ですが、不正監視にはログの確認が有効です。ログにも「OSログ」「ミドルウェアログ」「アプリケーションログ」、そして「ネットワーク機器のログ」などがあります。エンタープライズシステムでは各機器にログインしてログを確認するといった運用は現実的ではないため、運用ミドルウェアを導入して一元管理することになりますが、大量のログとなるため通常は事前に設定したフィルタ(WARNING、ERROR、CRITICALなど)に引っかかったログのみが表示されるようにしています。
なお、事前にフィルタ設定したもの以外でも有事のログ解析時に必要となるログもあるため、通常は管理サーバで定期的にログを収集して保存しています。
3.2. データ検証
データの改ざん検知に関する項目ですが、こちらも「2.データの秘匿」で解説した通り、ネットワーク上を流れるデータと各サーバや機器に蓄積されるデータについて考える必要があります。
通信データに関しては「デジタル署名」を使用するケースが多いですが、簡単に説明すると送信側と受信側でデータのハッシュ値(短い文字列、同じデータからは必ず同じハッシュ値が得られる)を取得して比較することでデータが改ざんされていないことを確認します(図5)。
蓄積されているデータに関しては、改ざん検知ソフトウェアを導入することになります。監視対象機器に導入してデータの改ざんを検知する方法や、監視サーバなどに導入してユーザと同じ方法でアクセスし、その結果から改ざんを検知する方法などがあります。
4. ネットワーク対策
ネットワーク対策は「ネットワーク制御」「不正検知」「サービス停止攻撃の回避」から構成されますが、ネットワーク越しに利用するWebシステムでは、特にこのネットワーク対策がセキュリティを下支えする存在です。
4.1. ネットワーク制御
いわゆる通信制御ですが、選択肢としてTCP/IPにおける各層での制御があります。ネットワークインターフェース層ではMACアドレスによる制御、インターネット層ではIPアドレスによる制御、トランスポート層ではポート番号による制御、アプリケーション層ではアプリケーションデータの内容による制御が可能となります。
よく利用されているのは「L3スイッチ」や「ルータ」、「ファイアウォール」といったネットワーク機器に実装されているアクセス制御を利用したものです。また、サーバサイドでもOSに実装されているファイアウォール(WindowsファイアウォールやLinuxファイアウォール「iptables」など)を利用してアクセス制御しているシステムもありますが、運用が大変になるためメインはネットワーク機器としているシステムが多いのではないでしょうか。
4.2. 不正検知
アクセス制御だけでは正常な通信を装った通信を防ぐことはできません。例えば、同一のIPアドレスから複数のユーザIDでログインしていたりなど、通常の利用ではありえない通信に関しては不正を検知するための対策が必要となります。
その対策として使用されているのが「IDS」や「IPS」といった製品です。ネットワークやサーバに製品を導入することで、やり取りするパケットの内容を監視してくれます。IDSは警告を表示してくれますが、IPSはさらに一歩進んで不正と認定したアクセスを遮断してくれます。
最近ではファイアウォールにIDS/IPS機能を追加した「UTM」と呼ばれる製品も出てきており、以前よりは気軽に利用できるようになってきています。ただし、「何を不正とするか」といったチューニングが必要となってくるため、少し敷居が高い存在かもしれません。
4.3. サービス停止攻撃の回避
DoS攻撃やDDoS攻撃といったネットワークを輻輳させる攻撃に対する対策です。通常DoS攻撃は単一の送信元からアクセスされるため、該当アドレスをネットワーク制御するといった対策が可能です。DDoS攻撃では対象が複数となり、また変化するため、選択肢としてはDDoS攻撃に対応したファイウォールや外部サービスを利用するといった対策があります。
5. マルウェア対策
マルウェアは対象機器に害を与えるように悪意をもって作成されたソフトウェアなどの総称です。その種類にはトロイの木馬やウィルス、ワームなど様々ありますが、一般的には対策ソフトウェアを導入することで対策します。一昔前まではWindowsのサーバが対策ソフトウェア導入の対象でしたが、最近ではUNIXやLinuxのサーバでも対策ソフトウェア導入するケースが多くなってきています。
対策ソフトウェアはサーバをスキャンしてマルウェアを検知します。サーバで使用する際の注意点としては、DBサーバ上の大きなファイルやダンプファイルなどをスキャン対象から除外する設定をしておかないと、スキャンプロセスがCPUを使い切ってしまう(負荷が高い)ことがあるという点です。
6. Web対策
昨今のWebシステムに特化したものとして、Web実装への対策が行われるようになってきています。これまではApacheなどWebサーバミドルウェアの設定をチューニングすることでセキュリティ対策をしていましたが、最近ではWebサーバの前段に「WAF(Web Application Firewall)」と呼ばれるWebアクセスに特化したファイアウォールを配置してパケットを制御する構成を採るシステムが多くなってきています。
通常、ファイアウォールではアプリケーションデータの中身までは確認しないのですが、WAFではその中身まで確認して不正なアクセスの場合は遮断します。ただし、導入するためにはシステムに合わせて設定をチューニングする必要があり、実際には本番のアクセスデータがないと設定が完了しないため、導入には少し時間やコストが必要なところが注意点です。
連載を通して、インフラエンジニアが関わる「システム運用」に注目し、さまざまな側面から解説していく本コラム。今回は「システム寿命」について考えていきたいと思います。
第1回で、「情報システムはハードウェアとソフトウェアから成り立っている」と解説しましたが、ハードウェアやソフトウェアにも寿命があります。例えばIAサーバだと5年ぐらい、OSだと5~10年ぐらいがEOSL(End of Service Life)といってサポートが終了する期限になります。
ハードウェアが故障した時には交換や修理をお願いする必要がありますが、交換・修理するためのパーツが必要となります。メーカ側としてはいつまでもパーツを保管しておくわけにもいきませんし、交換対応するCEさんも古い機器だと技術的に対応が難しくなってきます。
ソフトウェアであれば不具合の修正やセキュリティパッチを適用していく必要がありますが、メーカ側としてはいつまでも開発を続けるわけにもいきません。
企業の基幹システムは平均で14年近く使用しているという数字も出ていますが、通常のシステムでは上記の寿命に合わせてシステム更改を行っていくことになります。ただ、中には間に合わずに裏ルートから個別に延長保証をお願いしているケースもあります。
(第11回へ続く)
おわりに
今回はセキュリティをテーマに解説しました。セキュリティ対策はやろうと思えばいくらでも実施できる領域です。コストとの相談も必要ですが、日進月歩で新たな攻撃手法が開発される現状では、「いかに早く検知して改善するか」といった観点で準備しておく必要があります。
さて、いよいよ本連載も次回で(本当に)最終回です。次回は「プログラミング」をテーマに解説します。バッチプログラムやシェルスクリプトをはじめインフラエンジニアでもプログラミングをする機会はありますが、最近ではAIとともにPythonの存在感も増してきています。次回も楽しみにしていてください!