...

インターネットサーバーの安全性向上策に関する 調査報告書

by user

on
Category: Documents
6

views

Report

Comments

Transcript

インターネットサーバーの安全性向上策に関する 調査報告書
セキュリティ対策研究開発等事業
インターネットサーバーの安全性向上策に関する
調査報告書
平成15年 3 月
情報処理振興事業協会
セキュリティセンター
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
目次
はじめに ............................................................................................................................................ vi
背景 ................................................................................................................................................ vi
調査の観点 .................................................................................................................................... vi
対象とする読者層 ....................................................................................................................... vii
本調査報告書の構成.................................................................................................................... vii
1
サーバーのハイアベイラビリティ技術............................................................................... 1-1
1.1
サーバーのハイアベイラビリティ技術....................................................................... 1-1
1.2
クラスタリング............................................................................................................... 1-1
1.2.1
クラスタリングの形態........................................................................................... 1-1
1.2.2
データの保存方式................................................................................................... 1-2
1.2.3
NIC の冗長化(チーミング)............................................................................... 1-3
1.2.4
フォールト・トレラント・サーバー................................................................... 1-4
1.2.5
クラスタ型とフォールト・トレラント型の違い............................................... 1-5
1.3
1.3.1
ロードバランサー................................................................................................... 1-6
1.3.2
ネットワークアドレス変換(NAT:Network Address Translation) ................ 1-7
1.3.3
障害監視(サーバーのヘルスチェック機能)................................................... 1-8
1.3.4
負荷分散方式........................................................................................................... 1-9
1.3.5
パーシステンス、スティッキー(セッション維持) ..................................... 1-10
1.3.6
ロードバランサーの接続形態............................................................................. 1-12
1.3.7
ロードバランサー自身のセキュリティ対策..................................................... 1-16
1.3.8
Quality of Service(QoS) .................................................................................... 1-20
1.4
ロードバランサーの対象............................................................................................. 1-21
1.4.1
Web サーバー ........................................................................................................ 1-21
1.4.2
DNS サーバー........................................................................................................ 1-23
1.4.3
キャッシュサーバー............................................................................................. 1-23
1.4.4
ファイアウォール................................................................................................. 1-23
1.4.5
ISP(マルチホーミング)................................................................................... 1-25
1.5
CDN と広域ロードバランス ....................................................................................... 1-25
1.5.1
広域ロードバランスの必要性............................................................................. 1-25
1.5.2
広域ロードバランスの方式................................................................................. 1-26
1.5.3
広域用ロードバランサーの機能......................................................................... 1-28
1.5.4
その他の留意点(DNS キャッシュ)................................................................ 1-29
1.6
2
ロードバランサーによるハイアベイラビリティ実現技術 ....................................... 1-5
参考資料 ........................................................................................................................ 1-30
ネットワークのハイアベイラビリティ技術....................................................................... 2-1
2.1
ネットワークのハイアベイラビリティの必要性....................................................... 2-1
Copyright © 2003 IPA, All Rights Reserved.
i
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
目次
レイヤ1 .......................................................................................................................... 2-2
2.2
2.2.1
ネットワーク機器の電源....................................................................................... 2-2
2.2.2
ネットワーク機器のシャーシ............................................................................... 2-3
2.2.3
ネットワーク機器の配置....................................................................................... 2-4
レイヤ2 .......................................................................................................................... 2-4
2.3
2.3.1
STP(スパニングツリー・プロトコル) ............................................................ 2-4
2.3.2
リンクアグリゲーション....................................................................................... 2-6
レイヤ3 .......................................................................................................................... 2-6
2.4
3
2.4.1
VRRP(Virtual Router Redundant Protocol)......................................................... 2-7
2.4.2
ダイナミックルーティングプロトコル............................................................... 2-7
2.4.3
マルチホーミング................................................................................................. 2-10
2.5
レイヤ4∼7................................................................................................................. 2-11
2.6
参考資料 ........................................................................................................................ 2-12
ストレージのハイアベイラビリティ技術........................................................................... 3-1
3.1
RAID................................................................................................................................. 3-1
3.1.1
ディスクアレイ....................................................................................................... 3-1
3.1.2
RAID......................................................................................................................... 3-2
3.1.3
RAID 0...................................................................................................................... 3-2
3.1.4
RAID 1...................................................................................................................... 3-2
3.1.5
RAID 0+1................................................................................................................ 3-2
3.1.6
RAID 5...................................................................................................................... 3-3
3.1.7
各種 RAID 技術....................................................................................................... 3-3
NAS と SAN .................................................................................................................... 3-4
3.2
3.2.1
NAS(Network Attached Storage) ........................................................................ 3-5
3.2.2
SAN(Storage Area Network) ............................................................................... 3-6
3.2.3
仮想ストレージ....................................................................................................... 3-8
3.2.4
FCIP と iSCSI......................................................................................................... 3-10
3.2.5
NAS と SAN のまとめ.......................................................................................... 3-11
3.3
データ管理技術............................................................................................................. 3-15
3.3.1
ジャーナリングファイルシステム..................................................................... 3-15
3.3.2
リモート監視......................................................................................................... 3-15
3.4
基本的なバックアップ技術......................................................................................... 3-16
3.4.1
データのバックアップ・リカバリのポイント................................................. 3-17
3.4.2
バックアップ媒体................................................................................................. 3-17
3.4.3
バックアップ媒体の選択..................................................................................... 3-19
3.4.4
テープ RAID.......................................................................................................... 3-20
Copyright © 2003 IPA, All Rights Reserved.
ii
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
目次
3.4.5
テープライブラリ................................................................................................. 3-20
3.4.6
ディザスタリカバリ............................................................................................. 3-21
3.4.7
オフサイトバックアップ..................................................................................... 3-22
3.5
3.5.1
スナップショット................................................................................................. 3-23
3.5.2
オンラインバックアップ..................................................................................... 3-24
3.5.3
オンライン・アーカイブ..................................................................................... 3-24
3.5.4
階層型ストレージ管理(HSM:Hierarchical Storage Management).............. 3-24
3.5.5
ネットワークバックアップ................................................................................. 3-25
3.5.6
サーバーレスバックアップとリストア............................................................. 3-26
3.5.7
同期リモートコピー............................................................................................. 3-27
3.5.8
レプリケーション................................................................................................. 3-28
3.6
4
参考資料 ........................................................................................................................ 3-29
サービス妨害攻撃................................................................................................................... 4-1
4.1
サービス妨害攻撃の分類............................................................................................... 4-1
4.1.1
包括的 DoS 攻撃 ..................................................................................................... 4-2
4.1.2
システム欠陥利用型 DoS 攻撃.............................................................................. 4-4
4.2
対策 .................................................................................................................................. 4-7
4.2.1
リソース枯渇型 DoS 攻撃の対策.......................................................................... 4-8
4.2.2
システムの欠陥を狙った攻撃に関する対策..................................................... 4-10
4.2.3
攻撃への IDS による対応 .................................................................................... 4-11
4.3
攻撃の詳細 .................................................................................................................... 4-13
4.3.1
リソース枯渇型攻撃の詳細................................................................................. 4-13
4.3.2
システムの欠陥利用型攻撃の詳細..................................................................... 4-17
4.4
5
高度なバックアップ技術............................................................................................. 3-22
参考資料 ........................................................................................................................ 4-21
サービス妨害攻撃に関する対策とその強度、脆弱性....................................................... 5-1
5.1
概要 .................................................................................................................................. 5-1
5.2
対策 1:クラスタリング................................................................................................ 5-4
5.3
対策 2:サービス毎のサーバーの分離........................................................................ 5-4
5.4
対策 3:インターネットサーバーの脆弱性対策........................................................ 5-5
5.5
対策 4:キャッシュサーバーの利用............................................................................ 5-8
5.6
対策 5:複数サーバーへの処理の分散........................................................................ 5-8
5.7
対策 6:サーバーへのヘルスチェック........................................................................ 5-9
5.8
対策 7:DNS の冗長化................................................................................................. 5-10
5.9
対策 8:通信機器自身に関するセキュリティ対策.................................................. 5-11
5.10
対策 9:複数 ISP(プロバイダ)の利用 ............................................................... 5-12
Copyright © 2003 IPA, All Rights Reserved.
iii
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
目次
6
5.11
対策 10:外部委託の評価........................................................................................ 5-12
5.12
対策 11:ファイアウォールの導入........................................................................ 5-13
5.13
対策 12:QoS 制御 ................................................................................................... 5-14
5.14
対策 13:十分な通信帯域の確保............................................................................ 5-14
5.15
対策 14:ネットワーク(回線)の分離................................................................ 5-15
5.16
対策 15:NIC の冗長化............................................................................................ 5-15
5.17
対策 16:回線の多重化............................................................................................ 5-16
5.18
対策 17:ストレージの信頼性確保........................................................................ 5-16
5.19
対策 18:バックアップ............................................................................................ 5-17
5.20
対策 19:ログ用ストレージ容量確保.................................................................... 5-18
5.21
対策 20:インターネットサーバーの広域分散.................................................... 5-19
5.22
対策 21:バックアップサイトによるサイトの分散............................................ 5-20
5.23
対策 22:攻撃の検知とインシデントレスポンス................................................ 5-20
5.24
サーバー構築でのハイアベイラビリティ技術選択の観点のまとめ ................. 5-22
5.25
参考資料 .................................................................................................................... 5-23
サイトモデルから考えた対策............................................................................................... 6-1
6.1
サイトモデル................................................................................................................... 6-1
6.1.1
サイトモデルの考え方........................................................................................... 6-1
6.1.2
サイトモデルと対策レベルの考え方................................................................... 6-3
6.1.3
分類のまとめ........................................................................................................... 6-4
6.2
分類別対策 ...................................................................................................................... 6-5
6.2.1
タイプ 1:大規模ミッションクリティカルサイト(高負荷)設計 ................ 6-5
6.2.2
タイプ 2:大規模ミッションクリティカルサイト(低負荷)設計 ................ 6-8
6.2.3
タイプ 3:ミッションクリティカル EC サイト(高負荷)設計 ................... 6-10
6.2.4
タイプ 4:小規模 EC サイト(低負荷)設計................................................... 6-12
6.2.5
タイプ 5:高負荷ポータルサイト案 A 設計 ..................................................... 6-14
6.2.6
タイプ 6:低負荷ポータルサイト設計.............................................................. 6-16
6.2.7
タイプ 7:高負荷ポータルサイト案 B 設計 ..................................................... 6-18
6.2.8
タイプ 8:企業のポータルサイト(コスト重視)案 A 設計 ......................... 6-20
6.2.9
タイプ 9:広域ミッションクリティカルコンテンツ配信サイト(高負荷)設計
6-22
6.2.10
タイプ 10:コンテンツ配信サイト(低負荷)設計 .................................... 6-24
6.2.11
タイプ 11:ミッションクリティカルコンテンツ配信(高負荷)サイト設計
6-26
6.2.12
タイプ 12:無停止が望まれるサイト案 A 設計 ........................................... 6-28
6.2.13
タイプ 13:コンテンツ配信サイト(コスト重視)設計 ............................ 6-30
Copyright © 2003 IPA, All Rights Reserved.
iv
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
目次
6.2.14
タイプ 14:無停止が望まれるサイト案 B 設計 ........................................... 6-32
6.2.15
タイプ 15:企業のポータルサイト(コスト重視)案 B 設計 ................... 6-34
6.2.16
タイプ 16:小規模企業のポータルサイト設計............................................ 6-36
7
まとめ ...................................................................................................................................... 7-1
8
索引 .......................................................................................................................................... 8-1
商標
Microsoft、Windows は、米国 Microsoft Corporation の米国およびその他の国における登録商標である。
UNIX は、米国 X/Open Co., Ltd. が独占的にライセンスをする米国および他の国における登録商標である。
その他、アプリケーション名、製品名、会社名は各社の商標または登録商標である。
本調査報告書では、TM、©、®などの記号は省略している。
Copyright © 2003 IPA, All Rights Reserved.
v
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
はじめに
はじめに
背景
インターネットを利用した情報提供、商取引の重要性は年々高まっており、今日、
多くの企業、組織で業務を遂行する上でなくてはならないインフラになっている。一
方、DoS攻撃1、DDoS攻撃2による被害は年々増加の一途をたどっており、2002年10月に
も全世界のインターネットの基幹システムをなす13台のドメインネームサービス
(DNS)ルートサーバーに対するDDoS攻撃が発生している。また、2003年1月下旬に
はワームに起因した世界的規模でのインターネット障害の発生が確認されている。こ
のような状況の中で、DoS攻撃、DDoS攻撃からインターネットサーバーを守り、その
ハイアベイラビリティ3(High Availability:高可用性)を確保するのが急務になってい
る。
インターネットサーバーの安全性向上策のうち不正アクセスに関する対策はこれま
でも議論され、比較的多くの資料が入手可能になっている。その反面、DoS攻撃、DDoS
攻撃に関する対策はまとまった資料が不足していた。サーバー製品、ネットワーク製
品、ストレージ4製品に関する資料では、アベイラビリティ向上に関しては機能とその
効果を説明していたが、製品がDoS攻撃、DDoS攻撃に対して、それがどのような効果
があるのかは十分には説明していない。つまり、インターネットサーバー管理者がDoS
攻撃、DDoS攻撃に対して対策を立案するための資料が根本的に不足していた。そこで、
サービス妨害攻撃対策を含むインターネットサーバーに関するハイアベイラビリティ
技術の現状と技術開発動向について調査を行い、各サイトの規模に応じた対策の構築
モデルを含む啓発資料を作成した。
調査の観点
1
Denial of Service attack:サービス妨害攻撃。コンピュータ資源やネットワーク資源を利用で
きない状態に陥れる攻撃である。
2
Distributed Denial of Service attack:分散型サービス妨害攻撃。DoS 攻撃の攻撃元が複数で、
標的とされるコンピュータに大きい負荷を与える攻撃である。
3
可用性が高いこと。システムが利用不能となることが少ないこと。正規利用可能性を確保
する技術。
4
記憶装置。コンピュータ内でデータやプログラムを記憶する装置。
Copyright © 2003 IPA, All Rights Reserved.
vi
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
はじめに
従来からのインターネットサーバーシステムの構築では、サイトの要件・規模に対
して最適か否かを考えながら製品、技術を選択していた。本調査報告書では、そのよ
うな従来の観点に加え、各製品・技術がサービス妨害攻撃に対して有効なのか、それ
とも脆弱性を持つのかをも含め説明した。サービス妨害攻撃も考慮した上でのハイア
ベイラビリティなインターネットサーバー構築での技術選択に利用可能な調査報告書
を目指した。
対象とする読者層
(1)
システム管理者
システム導入の際の技術・構成検討の選択のために利用することを目的とする。ま
た、現システムにおけるセキュリティの十分性の評価と対策拡充に利用することを目
的とする。
(2)
システムの企画・提案・導入の検討を行う担当者
システム導入の際の技術・構成検討の選択のために利用することを目的とする。
(3)
システムの提案・設計・構築を行うコンサルタントおよびシステムインテグレ
ータ
システム提案での技術・構成の選択、システム構築でのレビューのための参考資料
として利用することを目的とする。
本調査報告書の構成
本調査報告書では、ハイアベイラビリティ技術、攻撃、そして対策という順で説明
していく。各章の内容は以下のとおりである。
1章から3章:ハイアベイラビリティ技術の現状と動向をサーバーに関するもの、ネ
ットワークに関するもの、ストレージに関するものの3分野に分けて説明する。
4章:サービス妨害攻撃、すなわちDoS攻撃、DDoS攻撃などの手法を説明する。
5章:サービス妨害攻撃に関する対策とその強度、脆弱性を説明する。
6章:サイトモデルから考えた対策という形でまとめる。
7章:調査報告書全体をしめくくる。
Copyright © 2003 IPA, All Rights Reserved.
vii
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
1 サーバーのハイアベイラビリティ技術
1.1 サーバーのハイアベイラビリティ技術
インターネットサーバーのハイアベイラビリティを実現するアプローチには、大き
く分けて次の2つが考えられる。
サーバーでクラスタを構成する。
ロードバランサーを導入する。
ここでは、これらのサーバーのハイアベイラビリティを実現する技術について解説
する。
1.2 クラスタリング
サーバーのクラスタとは、複数の独立したサーバーを組み合わせ、単一のサーバー
として利用することである。クライアントからは、クラスタ全体で単一のサーバーと
して認識され、クラスタ内の一つのサーバーに障害が発生しても、自動的に他のサー
バーに処理が引き継がれ、クライアントはそのまま処理を続行することができる。
クラスタリングの対象となるサーバーには、主に次の2つがある。
アプリケーションサーバー
データベースサーバー
本項では、クラスタリングの形態、データの保存方式、ネットワークへの接続(NIC)
の冗長化(チーミング)について説明する。
1.2.1
クラスタリングの形態
クラスタリングの形態には次の3種類がある。
密結合:1台の稼働系の中に複数のCPUがあり、メモリなどを共有する形態
疎結合:複数の稼働系があり、それらが互いに動作を確認しあいながら動作す
る形態
アクティブ/スタンバイ:2台のサーバーで、1台を稼働系、もう1台を待機系とし
て利用する形態
Copyright © 2003 IPA, All Rights Reserved.
1-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
RDBMS5では複数CPU用のクラスタリング機能が装備されているものがある。複数の
データベースプロセスを実行し、アプリケーションサーバーからの処理要求を並列に
処理する。この機能を使えば、データベースを扱うアプリケーションでは、データベ
ース処理を並列化でき、特にデータの件数が多い場合にパフォーマンスの向上が期待
できる。アプリケーションの特徴を考え、この並列化の程度をチューニングすること
が必要である。
1.2.2
データの保存方式
クラスタリングにおけるデータの保存方式には次の2種類がある。
共有ディスクタイプ
データミラータイプ
共有ディスクタイプ(図 1-1)では、クラスタ構成されたサーバーの共有ボリューム
としてディスクアレイ装置が用いられる。サーバーからディスクアレイ装置へはSCSI
やファイバーチャネル(Fiber Channel)で接続する。もちろん、ネットワーク型ストレ
ージ(SAN:Storage Area Network)なども利用できる。ネットワーク型ストレージは3
章で説明する。
通常時は稼働系サーバーからデータをディスクアレイ装置に書き込む。障害が発生
した場合は他のサーバープロセスまたは、待機系サーバーから処理を引き継ぐ。この
時の処理の引継ぎをフェイルオーバーと呼ぶ。
通常時
障害時
業務
業務
フェイルオーバー
図 1-1 共有ディスクタイプ
この方式は大量のデータを扱うシステムに適している。ただし、共有ボリュームの
冗長化を考慮しないと、共有ボリュームの障害時にシステムが停止してしまう。
一方、データミラータイプ(図 1-2)は、各サーバーでディスクを有し、そのディス
クをサーバー間でミラーリングする方式である。
5
Relational Database Management System(関係データベース管理システム)
Copyright © 2003 IPA, All Rights Reserved.
1-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
障害時
通常時
ミラーリング
業務
業務
図 1-2 データミラータイプ
この方式は、共有ボリュームが不要なため、ハードウェアのコストを低くすること
ができるが、サーバー間でデータをミラーリングするため、大量のデータを扱うシス
テムには向いていない。
1.2.3
NICの冗長化(チーミング)
インターネットサーバーでは、ネットワークとの接続のフォールト・トレランス性
(耐故障性)を確保することも重要である。その方法としてNIC(Network Interface Card)
を冗長化する技術がある。これはNICのチーミングと呼ばれる。LANケーブルの断線や
NIC故障時にも待機用NICに処理を自動的に切り替えてノンストップ通信を実現するも
のである。NICの冗長化にもアクティブ/スタンバイ型とアクティブ/アクティブ型があ
り、アクティブ/スタンバイ型がネットワーク・フォールト・トレランスだけを実現す
るのに対して、アクティブ/アクティブ型は接続するLANスイッチの機能と併用するこ
とで伝送の負荷分散を実現しスループットの向上も実現する。NICの冗長化には、レイ
ヤ2、レイヤ3でのアドレス・アグリゲーション方式がある。ハイアベイラビリティに
関する機能には下記がある。
フォールト・トレランス(Fault Tolerance)
リンクアグリゲーション(Link Aggregation)
ロードバランシング(Load Balancing)
また、速度の異なるNICを混在させることもできる。
NICのチーミングモードは複数あり、モードによって、どの機能に対応しているかが
異なるので注意が必要である。
①フォールト・トレランス
NICでセカンダリのアダプタを用いることによって、プライマリ・アダプタのケー
ブルや、接続先ポートが故障した際に機能を引き継ぐことができる。
②リンクアグリゲーション
Copyright © 2003 IPA, All Rights Reserved.
1-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
リンクアグリゲーションとは同じチャネルに対して複数のアダプタを束ねること
により、複数の送信先に対する帯域幅を倍増するものである。
③ロードバランシング
送信の負荷をアグリゲートされたアダプタ群で分散する。ANS(Advanced
Networking Services)ドライバに組み込まれた調整エージェントによって、サーバ
ーからのトラフィックを分析し、宛先アドレスにより振り分ける。
1.2.4
フォールト・トレラント・サーバー
クラスタと同様に利用される用語にフォールト・トレラントがある。フォールト・
トレラント・サーバーとは、システムの一部に故障が発生しても所定の処理を継続で
きる能力(フォールト・トレランス)を備えたサーバーである。フォールト・トレラ
ント・サーバーは、個々のコンポーネント単位でハードウェアを冗長化することで、単
点障害(SPOF:Single Point of Failure)による影響を排除し、無停止で長時間動作する
ことが可能である。
フォールト・トレラント・サーバーのハードウェア構成例を表 1-1に示す。
表 1-1 フォールト・トレラント・サーバーのハードウェア構成例
コンポーネント
プロセッサ
構成
完全二重化
構成内容
自己診断機能を持つCPUボード2枚1組が論理的に1つの
プロセッサとして同時に同一の処理を実行する。
メモリ
完全二重化
パリティ・チェック(1ビット修正、2ビット検出)機能
を持つメモリ・ボード2枚1組が論理的に1つのメモリと
して機能する。
I/Oプロセッサ・
完全二重化
通信I/Oプロセッサ
ディスク
自己診断機能を持つI/Oプロセッサ・ボード2枚1組が論
理的に1つのI/Oプロセッサとして 同時に同一の処理を
実行する。
完全二重化
二重化されたディスクドライブとI/Oプロセッサに対
し、OSがwriteは両方のドライブに、readは早くアクセス
できる方のドライブから行う。
システム・バス
完全二重化
パリティ・チェック機能を持つシステム・バスを二重化
している。
通信アダプタ・カー
必要に応じた二重化
ド
電源
故障時の影響は通常1∼2回線であるが、重要度の高い回
線は二重化または予備を装備し切り替えを可能とする。
完全二重化
二重化された各々のコンポーネントに対して、二重化さ
れた別々の電源が電力を供給する。
Copyright © 2003 IPA, All Rights Reserved.
1-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
1.2.5
クラスタ型とフォールト・トレラント型の違い
フォールト・トレラント型は純粋に1つのサーバー上での耐障害性を追求したもので
あり、言い換えれば処理能力よりも1台のサーバーのSPOFを極力少なくして、ハイアベ
イラビリティを目指している。これに対し、クラスタ型は既存のシステムからの拡張
性を重視し、さらに処理能力の向上も実現する方法である。
クラスタ型とフォールト・トレラント型の相違点を表 1-2にまとめる。
表 1-2 クラスタ型とフォールト・トレラント型の相違点
相違点
クラスタ型
フォールト・トレラント型
フェイルオーバー
時間
待機サーバーのアプリケーショ
ンの起動時間、ディスクマウント
の時間、ファイルの整合性をチェ
ックする時間などが含まれるた
め、フェイルオーバーに数分を要
する場合もある。
停止時間なし。
フェイルオーバー
後の保守
フェイルオーバーにより切り離
されたサーバーを停止し、故障箇
所を自分で特定する。または予備
のサーバーを利用する。
故障したモジュールをベンダに
連絡し新しいものと交換する。
交換後は再起動して通常状態に
復帰させる。
メリット
デメリット
電源などが入った状態での交換
作業(ホットスワップ)が採用さ
れているため、サーバーを停止す
ることなく稼働したまま実施可
能。
製品価格帯、性能レンジなどの選
択肢が豊富。
開発・運用が容易。
インターコネクト自体に障害が
発生すると、互いに相手サーバー
の障害を検出しフェイルオーバ
ーが開始されてしまう。
製品機種の選択肢が狭い。
クラスタ型より安価。
開発・設定が複雑。
運用・保守が煩雑。
1.3 ロードバランサーによるハイアベイラビリティ
実現技術
Copyright © 2003 IPA, All Rights Reserved.
1-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
1.3.1
ロードバランサー
サーバーのハイアベイラビリティを実現するもう一つの方法は、ロードバランサー
を使用する方法である。ロードバランサーは、負荷分散装置またはレイヤ4(レイヤ7)
スイッチとも呼ばれ、アドレス変換技術やヘルスチェック機能などにより、複数サー
バーへのシームレスなアクセス環境およびハイアベイラビリティを提供するネットワ
ーク機器である。クラスタでは共有ボリューム制御の難しさから、登録できるサーバ
ー数を増やすとコストがかかる。ロードバランサーで管理されるサーバーは各々が独
立した記憶領域を持ち単独で動作するため、現実的には登録できるサーバーの台数に
は制限がなく、増設のコストも少なくてすむ。また、この性質から個々のサーバーの
パフォーマンスが低くても、多数のサーバーにて並列処理を行うことができるため、
パフォーマンスの高いシステムの構築が容易に実現できる(図 1-3)。
一方、サーバー間におけるデータ整合性の問題から、更新系のサーバーへ適用する
場合は別途強力なレプリケーション6の仕組みが必要となる。
インターネット
ロードバランサー
インターネットサーバー
図 1-3 ロードバランサー
以下にロードバランサーで必要不可欠な機能・特徴を挙げる。
ネットワークアドレス変換機能(NAT)
障害監視(サーバーのヘルスチェック機能)
負荷分散方式
パーシステンス、スティッキー(セッション維持)
6
(Replication)データベースの複製。詳細は 3 章を参照のこと。
Copyright © 2003 IPA, All Rights Reserved.
1-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
ロードバランサーの接続形態
ロードバランサー自身のセキュリティ対策
Quality of Service(QoS)
以下では、これら機能・特徴の詳細について解説する。
1.3.2 ネットワークアドレス変換(NAT:Network Address
Translation)
ロードバランサーの多くは、アドレス変換の技術を用いてクライアントへのシーム
レスなアクセス環境を提供する。具体的には、複数のサーバーで構成されるサーバー
ファームを1つの仮想IPアドレスで公開し、クライアントはこの仮想アドレスにアクセ
スする。ロードバランサーは仮想アドレスへのアクセスを最適なサーバーへ割り当て
る。
ロードバランサーにおけるアドレス変換の原理を表 1-3、図 1-4に示す。
表 1-3 アドレス変換の原理
手順
IP アドレス
アドレス変換原理
発信元
①
クライアントがロードバランサーの仮想 IP アドレス宛て クライアントの IP 仮想 IP アドレス
にアクセスする。
②
宛先
アドレス
ロードバランサーは仮想 IP アドレス宛てのパケットを受 クライアントの IP サーバーの IP アド
信すると、仮想アドレスに関連付けられたサーバーファー アドレス
レス
ムの中から最適なサーバーを選択し、パケットの宛先をそ
のサーバーに書き換えてパケットを送信する。
③
サーバーからの応答パケットがロードバランサーに到達 サーバーの IP アド クライアントの IP
する。
④
レス
アドレス
ロードバランサーが応答パケットを受信すると、送信元ア 仮想 IP アドレス
クライアントの IP
ドレスを仮想 IP アドレスに書き換えてパケットをクライ
アドレス
アントに転送する。
Copyright © 2003 IPA, All Rights Reserved.
1-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
① 宛先:仮想 IP アドレス
② 宛先:サーバーIP アドレス
発信元:クライアント IP アドレス
発信元:クライアント IP アドレス
サーバー
ロードバランサー
クライアント
④ 宛先:クライアント IP アドレス
発信元:仮想 IP アドレス
③ 宛先:クライアント IP アドレス
発信元:サーバーIP アドレス
図 1-4 アドレス変換の原理
1.3.3
障害監視(サーバーのヘルスチェック機能)
ロードバランサーは定期的にサーバーの状態を監視している。これは一般的にヘル
スチェック機能と呼ばれる機能であり、ロードバランサーの基本的な機能の一つであ
る。ロードバランサーはサーバーの障害を検知すると、障害の発生したサーバーをグ
ループから瞬時に切り離し、その他の正常なサーバーを使ってサービスを継続的に提
供することで、ハイアベイラビリティを実現している。サーバーの障害監視方法は、
検知できる障害のレベルで大きく以下の3つに分けられる。また、製品によっては、こ
れらの手法を複数組み合わせることで、より正確にサーバーの状態を監視するものも
ある。
(1)
レイヤ 3 レベルのヘルスチェック
IPレベルでサーバーの障害をチェックする。チェックにはICMP7(Internet Control
Message Protocol)やARP8(Address Resolution Protocol)が使用され、各サーバーに宛て
てICMPエコー要求(ping)またはARP要求を発行し、サーバーからのICMPエコー応答
またはARP応答が検出できれば、そのサーバーをサービス提供状態にあると判断する。
ヘルスチェック方法としては最も基本的で、すべてのロードバランサーが備える機能
である。サーバーだけでなくルータなどのすべてのIPホストに適用可能である。
(2)
レイヤ 4 レベルのヘルスチェック
TCPレベルでサーバーの障害をチェックする。チェックにはサーバーのサービス提供
ポートに対するTCPセッションの確立手順(3ウェイハンドシェーク)が使用される。
ロードバランサーはサーバーの対象TCPポートに対しTCP SYNを送信し、サーバーから
7
TCP/IP プロトコルにおいて、その機能を補助するために用意された制御用プロトコル。
RFC792 で定義されている。TCP/IP パケットの転送中において発生した各種エラーの通知や、
動作の確認などを行うために利用される。
8
IP アドレスから MAC アドレスを知るためのプロトコル。
Copyright © 2003 IPA, All Rights Reserved.
1-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
のTCP SYN/ACK9(Acknowledgment)が検出できれば、そのサーバーをサービス提供可
能状態にあると判断する。この方法はすべてのTCPアプリケーションに適用可能であ
る。
(3)
アプリケーションレイヤレベルのヘルスチェック
アプリケーションレベルでサーバーの障害をチェックする。チェック方法はアプリ
ケーションによりさまざまだが、実際のログイン手順を行って判断するものやテスト
コンテンツを取得できるかどうかで判断するものなどがある。一般的にアプリケーシ
ョンレイヤのヘルスチェックでは、サーバーへのリクエスト内容および期待する応答
内容をそれぞれカスタマイズ可能である。Webサーバーの例を考えると、アプリケーシ
ョンサーバーやデータベースサーバーとの連動を行うテスト用のWebコンテンツをサ
ーバー上に用意することで、これらの連動性までチェックすることができる。また、
認証が必要なWebサイトではログインを行い、実際にコンテンツが取得可能かどうかを
チェックする。サービス提供可能かどうかの判断には、HTTPステータスコードや応答
文字列パターンのマッチングを取る方法が一般的である。
チェック可能なアプリケーションには、HTTP、DNS、SMTP、POP3、LDAP、NNTP、
IMAP4、FTP、Telnet、RADIUSなどがあるが、ロードバランサーによっては対応して
いないアプリケーションもあるので注意が必要である。
1.3.4
負荷分散方式
ロードバランサーがサーバーにリクエストを割り振るためのアルゴリズムには、静
的なものと動的なものがある。静的な方法には、登録順にリクエストを割り当てるも
のやソースIPアドレスにハッシュ関数を適用するものなどがある。動的な方法には、最
小コネクション方式、最小トラフィック量方式、応答時間方式、サーバーエージェン
ト方式などがある。また、製品によってはこれらの方式を複数組み合わせることで、
より精度の高い負荷分散を行えるものもある。
以下では各負荷分散方式の詳細について解説する。
(1)
ラウンドロビン
ラウンドロビンによる負荷分散方法では、ユーザからの接続を、グループ内のサー
バーに順番に割り当てる。通常は全サーバーを接続数や応答時間に関係なく平等に扱
うが、製品によってはサーバーの処理性能に応じて静的に重み付けを設定し、確実に
多くの接続を割り当てることができるものもある。
9
データを正常に受信したことの通知など、受信側のネットワークデバイスから送信側のネ
ットワークデバイスへ送られる確認応答。
Copyright © 2003 IPA, All Rights Reserved.
1-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
(2)
ハッシュ関数
ハッシュ関数による負荷分散方法では、クライアントのIPアドレスにハッシュ関数を
適用し、その結果からサーバーを割り当てる。同じソースIPアドレスからの接続は必ず
同じサーバーに割り当てられるため、パーシステンス(セッション維持)機能も兼ね
る。
(3)
最小コネクション
最小コネクションによる負荷分散方法は、ロードバランサーを経由して確立された
TCPセッションの数が最も少ないサーバーに接続を割り当てる方式である。
(4)
トラフィック量
トラフィック量による負荷分散方法は、一定時間に転送されたデータ量が最も少な
いサーバーに接続を割り当てる方式である。FTPサーバーなどバースト的なデータの転
送を行うサーバーの負荷分散に適した方法である。
(5)
応答時間
応答時間による負荷分散方法は、応答時間が最も短いサーバーに接続を割り当てる
方式である。応答時間の測定には、アプリケーションレベルのヘルスチェックの応答
時間なども使用される。
(6)
サーバーエージェント
サーバーエージェントによる負荷分散方法は、エージェントと呼ばれるサーバーの
状態をロードバランサーに伝えるためのソフトウェアをサーバーにインストールし、
エージェントから送られる情報を元に負荷の低いサーバーへ要求を送る方式である。
サーバーの状態を考慮するため負荷分散の高い効果が期待できるが、OSに対応したエ
ージェントソフトを用意しなければならない、エージェントを動作させるためにサー
バーのリソースを消費してしまう、などの問題もある。
1.3.5
パーシステンス、スティッキー(セッション維持)
ロードバランス対象となるアプリケーションの特性によっては、作業が行われてい
る間は負荷分散されることなく特定のサーバーに接続させたい場合がある。例えばシ
ョッピングサイトでは、ユーザが品物を選んでいるときに接続されたサーバーと支払
い時のサーバーが別々になってしまった場合、支払いサーバーはユーザが選択した品
物の情報を保持していないので購入物の整合性がとれなくなってしまう。これを回避
するために、ユーザと選択した品物の対応状況を都度バックエンドのデータベースサ
ーバーに記録する方法もあるが、アクセス集中によりデータベース自体がボトルネッ
クとなる可能性が高く、また開発コストも高くなってしまう。
Copyright © 2003 IPA, All Rights Reserved.
1-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
このため、ロードバランサーにはある条件に基づいて同一サーバーへの接続を保証
する機能が必要になる。これは一般にパーシステンス機能やスティッキー機能と呼ば
れている。
なお、ユーザからの最初の接続については、負荷分散アルゴリズムに基づいて接続
先サーバーが選択されるが、その後の通信については、パーシステンス機能を使って
同一サーバーへの接続を保証する。
以下では、各種パーシステンスの詳細について解説する。
(1)
ソース IP アドレス
仮想IPアドレスに接続してきたクライアントのソースIPアドレスをロードバランサ
ーの内部データベースに一定時間保持しておき、このデータベース内に情報が残って
いるうちは、同じサーバーに接続させる方法である。また、ソースIPアドレスにハッシ
ュ関数を適用することでパーシステンスを実現しているロードバランサーもある。
ソースIPアドレスによるパーシステンス機能は最も基本的な方法であり、さまざまな
アプリケーションに対応できるのが特徴である。ただし、多数のクライアントがプロ
キシサーバー経由でアクセスしてくる場合などにおいては、トラフィックの偏りが発
生し有効な負荷分散にならない可能性がある。また、ダイヤルアップ環境や携帯電話
端末など、IPアドレスが一定ではないユーザからのアクセスがある場合には利用できな
い方法である。
(2)
SSL(Secure Sockets Layer)セッション ID
10
SSL セッション確立時にユニークに決められるSSLセッションIDと、接続させたサ
ーバーをロードバランサーの内部データベースに一定時間保持しておき、このデータ
ベース内に情報が残っているうちは、同じサーバーに接続させる方法である。この方
法はセキュアなWebサイトなどでの利用が想定されている。多くのロードバランサーが
この機能をサポートしているが、主要なWebブラウザがセキュリティ対策のため数分間
隔でSSLセッションIDを取得し直すようになったため、この方法は現在ほとんど利用さ
れていない。
(3)
クッキー11(Cookie)を使用する方法
ロードバランス対象サービスがWebサービスの場合は、クライアントのWebブラウザ
に保存されるクッキー情報を使用して、サーバーへのパーシステンスを実現する方法
が利用できる。ユーザがそのサイトにアクセスしている間は、クッキー情報を付与し
10
Web ブラウザと Web サーバー間で安全な通信を行うために Netscape Communications が開
発したセキュリティ機能。TLS(Transport Layer Security)として RFC2246 で標準化されている。
11
ユーザ情報やアクセス履歴などの情報を Web ブラウザと Web サーバーでやり取りするた
めの仕組み。
Copyright © 2003 IPA, All Rights Reserved.
1-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
たアクセスが保証される。クッキーを使用する方法は、クッキーの配布方法により表
1-4に示す3種類に分けられる。
表 1-4 クッキーの配布方法
方式
パッシブ
説明
パーシステンスが必要なページで、Web サーバーがセッショ
ン ID を含むクッキーを送出する。この方法では、各 Web サー
バー上でセッション ID を管理する必要がある。
インサート
ロードバランサーで自動的にクッキーを挿入する。サーバーで
クッキーを管理する必要はないが、Web サーバー上のすべて
のページでパーシステンスが有効になってしまう。
リライト
サーバーが特定の文字列を含むクッキーを送出し、ロードバラ
ンサーがそれにセッション ID を付与する。(書き換える)
クッキーを利用したパーシステンスは、多くのWebサイトで利用されている。ただし、
携帯電話端末やセキュリティの理由からクッキーの使用を制限しているユーザからの
アクセスが予想されるサイトについては、この方法は利用できない。
(4)
URL への埋め込み
携帯電話端末はクッキーに対応しておらず、またサーバーに伝わるIPアドレスもアク
セス毎に変わる可能性がある。そのため、これまで述べてきた3つのパーシステンス手
法が利用できない。そこで、携帯端末でのパーシステンスが必要な場合は、
サーバー側でURLの中にセッションIDを埋め込む。
次のリクエストに付加されたセッションIDをロードバランサーがルールと照ら
し合わせて割り振る。
といった方法が使用されている。
1.3.6
ロードバランサーの接続形態
ロードバランサーを導入する際のネットワークの接続形態は、大きく以下の3種類に
分けられる。
①
ルータ構成
②
ブリッジ構成
③
DSR(Direct Server Response)構成
Copyright © 2003 IPA, All Rights Reserved.
1-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
①はロードバランサーがルータの役割を務める。②はロードバランサーがブリッジ
の役割を務める。③は①、②と異なり、サーバーからロードバランサーを経由せず直
接応答パケットが送信される。ロードバランサーは一般的にNATの技術を使って負荷
分散を実現しているため、①、②のようにクライアントとサーバーの間にロードバラ
ンサーを設置するのが基本的な構成である。ただし、サーバー側で特別な設定を行う
ことで③の様な構成も可能である。
以降ではロードバランサーが接続するセグメントを次のように定義している。
パブリックセグメント:ユーザがアクセスする、インターネットアクセスルー
タなどが接続されるセグメント
サーバーセグメント:負荷分散対象となるサーバーが接続されるセグメント
Copyright © 2003 IPA, All Rights Reserved.
1-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
(1)
ルータ構成
ロードバランサーが備える2つのインタフェースを使って、パブリックセグメントと
サーバーセグメントにそれぞれ物理的に接続し、さらに両方のセグメントに別々のIP
ネットワークが割り当てられる構成である(図 1-5参照)。パブリックセグメントとサ
ーバーセグメントが異なるIPネットワークであることから、ロードバランサーをサーバ
ーのデフォルトゲートウェイとして設定することで、ユーザとサーバーの間の通信は
必ずロードバランサーによってルーティングされることになる。ロードバランサーは
ルーティング処理の際に仮想アドレスとサーバーの実アドレスの変換などロードバラ
ンスに必要な処理を確実に行うことができる。この構成はロードバランサーの最も基
本的な構成と言える。
インターネット
ISP
ルータ
172.16.1.20
パブリックセグメント
172.16.1.10
ポート 1
仮想アドレス
172.16.1.100
ロードバランサー
10.1.1.10
ポート 2
サーバーセグメント
サーバー
10.1.1.2
10.1.1.1
サーバーファーム
図 1-5 ルータ構成
Copyright © 2003 IPA, All Rights Reserved.
1-14
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
(2)
ブリッジ構成
ロードバランサーが備える2つのインタフェースを使って、パブリックセグメントと
サーバーセグメントにそれぞれ物理的に接続し、両方のセグメントに単一のIPネットワ
ークを割り当てる構成である(図 1-6参照)。この構成により、ユーザとサーバーの間
の通信はロードバランサーにより必ずブリッジングされるが、ブリッジングの際に仮
想アドレスと実アドレスのアドレス変換などロードバランスに必要な処理が行われ
る。ただし、ロードバランスに必要な処理をレイヤ3レベルで行う製品では、代理ARP
機能を使ってこの構成をサポートしているものもある。この構成は、既存ネットワー
クに変更を加えることなくロードバランサーを導入できるというメリットがある。な
お、ロードバランサーを2台使った冗長構成の場合、製品によってはブリッジングルー
プを回避できないものもあり、注意が必要である。
インターネット
ISP
ルータ
172.16.1.20
パブリックセグメント
IP VLAN
インタフェース
172.16.1.10
ポート 1
ロードバランサー
仮想アドレス
172.16.1.100
ポート 2
サーバーセグメント
サーバー
172.16.1.1
172.16.1.2
サーバーファーム
図 1-6 ブリッジ構成
(3)
DSR(Direct Server Response)構成
ロードバランサーのインタフェースを1つだけを使って、パブリックセグメントおよ
びサーバーセグメントの共存するセグメントに物理的に接続し、単一のIPネットワーク
を割り当てる構成である(図 1-7参照)。この構成は、ユーザからの仮想アドレス宛て
のパケットはロードバランサーで処理が行われサーバーに転送されるが、サーバーか
らユーザ宛てのパケットはロードバランサーで中継されずに直接ユーザに転送され
Copyright © 2003 IPA, All Rights Reserved.
1-15
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
る。ロードバランサーの負担が小さくなるため、ストリームデータ配信サイトのよう
にサーバーからのトラフィックの多いシステムに適している。
ただし、応答パケットがロードバランサーで処理されないことから、サーバーにて
ソースアドレスを仮想アドレスに変換するための特殊な設定が必要であり、アプリケ
ーションによってはこの設定をサポートしていない場合もあるため注意が必要であ
る。
インターネット
ISP
ルータ
172.16.1.20
仮想アドレス
172.16.1.100
デフォルトルータ
172.16.1.10
ロードバランサー
ループバック
172.16.1.100
デフォルトルータ
172.16.1.20
172.16.1.1
ループバック
172.16.1.100
デフォルトルータ
172.16.1.20
172.16.1.2
ループバック
172.16.1.100
デフォルトルータ
172.16.1.20
172.16.1.3
サーバーファーム
図 1-7 DSR 構成
1.3.7
ロードバランサー自身のセキュリティ対策
アプライアンス型12のロードバランサー製品は、汎用OSをカスタマイズしたもの、ま
たは独自OSであるものが多く、不必要なサービスを自動起動しないなど、OSレベルで
セキュリティを高めているものが多い。また、製品によっては、簡易的なファイアウ
ォール機能やパケットフィルタ機能を備えているものや、ロードバランサーに対する
アクセスロギング機能を持つものもある。以下のような機能を持つ製品もある。
(1)
リモート管理機能でのユーザ認証
ロードバランサーのリモート管理機能では、SSH(Secure Shell)を利用した安全な
UNIXシェル、またはSSLを利用した安全な通信を使用している。これにより、管理者
12
(Appliance)特定用途向けの専用装置。
Copyright © 2003 IPA, All Rights Reserved.
1-16
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
のなりすましや、パスワードや通信データの傍受といった不正アクセスに関する対策
を行っている。
(2)
RADIUS および LDAP 認証サービスのサポート
上記リモート管理機能でのユーザ認証を補完するために、既に運用されている
RADIUS13(Remote Authentication Dial In User Service)やLDAP14(Lightweight Directory
Access Protocol)といったユーザ認証やアカウント管理の仕組みを利用することが可能
な製品もある。
RADIUSとLDAPはカスタマイズ可能なユーザ認証とアカウント管理の仕組みであ
り、どちらもプロトコルが標準化されている。そのうち、RADIUSはリモートアクセス
でのユーザ認証によく利用されている。一方、LDAPは、イントラネットなどのアカウ
ント管理とユーザ認証に利用されている。ロードバランサーによっては、SSHやSSLを
用いて管理者がロードバランサーにアクセスする際のユーザ認証に既存のRADIUSや
LDAPを用いることができる。既にRADIUSやLDAPを導入済みのネットワークでは、新
たなアカウント管理システムを導入することなく、ロードバランサーでの管理者に対
するユーザ認証機能が実現でき、アカウント管理の運用負担を軽減することができる
(図 1-8)。
RADIUS/LDAP
ロードバランサー
管理者
管理のためのログイン
(SSH/ブラウザ)
ユーザ認証
アカウント情報
図 1-8 RADIUS/LDAP のサポート
(3)
監視機能
監視機能では、不正アクセス試行を受けた場合、そのサービスとポートを識別する。
例えば、下記を識別する機能を有する。
不正アクセス試行回数
攻撃を受けたポート
攻撃者のソースIPアドレス
13
ダイヤルアップ接続で多く利用されているユーザ認証方式。RFC2865 で標準化されている。
X.500 ベースのディレクトリサービスをインターネット向けに軽量化したプロトコル。
RFC2222、2251∼2256 で標準化されている。
14
Copyright © 2003 IPA, All Rights Reserved.
1-17
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
SSL アクセラレータ
(4)
ロードバランサーにSSLアクセラレータカードを追加することで、ロードバランサー
上でSSLの復号化を行うことができる製品もある。SSLアクセラレータ利用の利点は3
点ある。
①
SSLアクセラレータカードと呼ばれる専用ハードウェアをロードバランサーに
搭載することにより、SSL処理可能数は1秒間に数百程度以上まで向上する。そ
れにより、サーバーのSSL処理の負荷を肩代わりすることができる。
②
証明書のインストールや管理がロードバランサーだけですむ。
③
ロードバランサー上で、HTTPの解析ができるため、クッキーやURL情報などに
よりリクエストをサーバーに振り分けることができる。
FIPS 140-115レベル3 認定SSLアクセラレータカードに対応しているロードバランサ
ー製品もある。SSLアクセラレータカードは、安全な鍵管理機能と専用のトランザクシ
ョンアクセラレーションを持っている。
特定のアプリケーションへアクセスできるユーザを限定するようなWebサービスに
対して、SSLクライアント認証をコントロールできる製品もある。
(5)
サービス妨害(DoS)攻撃に対する防御(アクセス制御)
ACL(Access Control List:アクセス制御リスト)を使用することで、サブネット上の
特定アドレスから特定アプリケーションへのアクセスを制限することができる。パケ
ットフィルタリングを使用して、トラフィックの送信元、宛先、またはポートを監視
し、インターネットサイトに出入りするアクセスの制限を行う。サーバーの特定ポー
トまたはVIP(Virtual Internet Protocol)アドレスへのアクセスを拒否するように、フィ
ルタを設定することができる。逆に、ユーザまたはサブネットからのアクセスを許可
するようにすることもできる。
(6)
DoS 攻撃に対する防御(セッション・フローを監視)
ロードバランサーでは、セッション・フローを監視および追跡することで、TCP SYN
攻撃などのさまざまな形式のDoS攻撃からサーバーファームを保護する。この機能を大
量同時接続管理機能と組み合わせることで、ハッカーによるWebサーバー資源の占領を
防ぐことができる。
DoS攻撃の詳細は「4章 サービス妨害攻撃」にて説明する。
15
コンピュータや音声を含む通信システムにおける機密扱いではない情報の保護を目的と
し、暗号モジュールが満たすべきセキュリティ要件 11 項目を規定し、各セキュリティ要件
に対して 4 段階のセキュリティレベルを定めている。
Copyright © 2003 IPA, All Rights Reserved.
1-18
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
ロードバランサーによっては、不正なフレームを廃棄することができるものもある。
次の条件に合致した場合にフレームを廃棄する。
長さが短すぎる。
フレームがフラグメント化されている。
発信元IPアドレスが送信先IPアドレスである。(LAND攻撃)
発信元がサブネット・ブロードキャストである。
発信元アドレスがユニキャスト・アドレスではない。
発信元IPアドレスがループバック・アドレスである。
送信先IPアドレスがループバック・アドレスである。
送信先アドレスが有効なユニキャスト・アドレスまたはマルチキャスト・アド
レスではない。
ロードバランサー製品によっては、フローの初期セットアップ時にすべてのセッシ
ョン・フローを検証し、すべての接続ベースのDoS攻撃や、他の不審な接続または異常
な接続の試行を排除する機能もある。
ロードバランサーでは、HTTPフローの開始から一定時間以内に有効なコンテンツ・
フレームを受信しないとフレームは廃棄し、フローを切断させることもできる。有効
なコンテンツ・フレームが受信されるまではサーバーへは伝達されない。したがって、
サーバー上へ攻撃が達する恐れはない。
また、ロードバランサーでは、一定時間以内にTCPスリーウェイ・ハンドシェイク用
の応答ACK を受信しないと、そのTCPフローを切断することもできる。これにより、
プロセステーブルに対する、サーバーへのオープン要求接続を繰り返し試行するDoS
攻撃は防止できる。
さらに、初期SYN(ACKバッファ無しの不当なSYN)の数がしきい値を超えた場合、
そのフローを切断することができる。同一初期シーケンス番号、送信元および送信先
アドレス、ポートのペアを持つ送信元からのSYN処理(新しいセッションのバインド)
を停止する。これで、SYNフラッド攻撃を防止できる。アイドル接続を排除すること
もできる。これは、サービス妨害攻撃に対する防御である。
(7)
NAT(ネットワークアドレス変換)による IP アドレス隠蔽
ロードバランサーでは、NATを使用して下記の項目を実現することができる。
サーバーのアドレス隠蔽
ウェルノウン(Well Known)ポートのマップ
Copyright © 2003 IPA, All Rights Reserved.
1-19
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
NAT機能により、サーバーには非公開アドレスを使用することができる。Webサーバ
ーおよびキャッシュなどのWebスイッチの背後にあるすべてのデバイスのIPアドレス
が隠される。このため、ハッカーによる明示的なIPアドレスを使用したサーバーへの直
接攻撃を排除できる。
よく使用される80、443、23、21などのポート(ウェルノウンポート)をサーバー上
の任意のポートにマップできる。ハッカーは、どのポートで何のサービスが実行され
ているかが識別困難になるため、セキュリティが大幅に向上する。
1.3.8
Quality of Service(QoS)
ロードバランスにおけるQoS制御とは、クライアントからサーバーへの要求に対する
処理速度の品質を一定に保つ機能である。QoSを実現するには、特定のサーバーへの過
負荷を防ぐ、クライアントに最適なサーバーを選択するというのが基本的な方式であ
る。表 1-5のように何種類かの方法がある。
表 1-5 QoS 制御方式
説明
QoS制御方式
ホップ数
要求をクライアントとサイト間のホップ数が最も少ないサイトへ
割り当て、迅速なアクセスを保証する。(広域対応ロードバランサ
ー)
スレッシュホールド
(しきい値)
要求をサイトのスレッシュホールドに基づいて分配する。サイトが
処理容量を越えると、それを検知し、障害が発生する前にトラフィ
ックを他のサイトに転送する。(広域対応ロードバランサー)
サーバー能力予測
サーバーからの情報に基づいて、サーバーの能力を予測し、サーバ
ーファームを選択する。
スロースタート
起動直後で処理能力が低いサーバーに対する割り当ては徐々に増
やしていく。これによりサーバーの安定性確保を図る。
最大コネクション数
接続
特定のサーバーが並行して処理できる接続の数を制限し、トラフィ
ック量がそのサーバーの許容量を超過しないようにする。
属性によるQoS
サービス・ポートやアプリケーション・タイプに従って優先順位を
付ける。例えば、FTPトラフィックよりもHTTPトラフィックを優
先することができる。
クライアント指定の
ロードバランシング
発信元IPアドレスに基づいて、トラフィックをサーバーに割り当て
る。発信元IPアドレスがあらかじめ決まっている場合に有効であ
る。
QoS制御では、アクセス数が設定した値を超えると、本来のサーバー群へはリクエス
トを送らず、お詫びのページを表示させるようなサーバー(Sorryサーバー)へリクエ
ストをリダイレクトする機能もある(図 1-9)。
Copyright © 2003 IPA, All Rights Reserved.
1-20
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
Webサーバーなど負荷分散されるサーバーの性能が同一でない場合に、クライアント
からの要求を均等に分散するようにロードバランサーを設定すると、性能の低いサー
バーに負荷が偏るため、サーバーの性能も考慮したロードバランスの設定が必要であ
る。
クライアント
クライアントからの
要求
サイト
ロードバランサーで
の QoS 制御
インターネット
振り分け
サイト
サーバーファーム
ただ今混み合
っております
サーバーファーム
サーバーファーム
Sorry サーバー
・
・
・
図 1-9 ロードバランサーでの QoS 制御
1.4 ロードバランサーの対象
ロードバランサーを使用することによりインターネットサーバーのハイアベイラビ
リティが確保できることについて述べてきたが、ロードバランサーがハイアベイラビ
リティを提供するものは、この他にも数多く存在する。以下では、ロードバランサー
でハイアベイラビリティ構成が可能となる対象とその際のネットワーク構成について
紹介する。
1.4.1
Webサーバー
現在、ロードバランサーが適用される対象として最も多いのがWebサーバーである。
ロードバランサーの多くはWebサーバーをメインターゲットとしており、Webサーバー
用の機能を充実させているものが殆どである。
Copyright © 2003 IPA, All Rights Reserved.
1-21
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
Webサーバーのロードバランスに関した機能には下記のようなものがある。
(1)
ロードバランスアルゴリズム
Webサーバーに特化したロードバランスアルゴリズムとしては、下記のようなものが
サポートされている。
URLスイッチ
URLヘッダーのハッシュ値
URLスイッチングでは、HTTP要求を、URL文字列ストリングのテキスト内に組み込
まれている情報に従って、サーバー群に送る。Webコンテンツをサーバーに分割して配
置できるという利点がある。URLハッシュでは、HTTP要求内の情報(クッキーヘッダ
ーとURLストリングのいずれか)を検査し、サーバー群を選択する。同じ情報を持つ
以降のHTTP要求は、同じWebサーバーに送られる。
(2)
ヘルスチェック
Webサーバーのヘルスチェックでは、実際にコンテンツにアクセスし、その機能の稼
働状態をチェックするなどアプリケーションレベルでの機能がある。コンテンツチェ
ックとも呼ぶ。
(3)
パーシステンス
Webサーバーへのアクセスでのパーシステンスに関しては、下記のような方式をサポ
ートしている。
クッキー
HTTPヘッダー
URLに含まれる文字列
(4)
Sorry サーバー
サーバーに接続させるセッション数がしきい値に達する、またはサーバー障害の多
発により、サーバーファームにてサービスが提供不可能な状態になった場合、仮想ア
ドレスへの通信をSorryサーバーへと転送する機能を持つロードバランサー製品もあ
る。
Sorryサーバーとは、「ただ今混み合っています。しばらくお待ちになってからアク
セスしてください。」というページだけがあるサーバーである。これにより、既に開
始されているユーザのトランザクションを中断せずにすむ。
Copyright © 2003 IPA, All Rights Reserved.
1-22
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
1.4.2
DNSサーバー
ロードバランサーはDNS16サーバーのハイアベイラビリティを実現するためにも利
用されている。DNS自体にも、セカンダリサーバーを設置することで可用性を高める
機能を備えているが、ロードバランサーを利用した方がダウンタイムを小さくするこ
とができる。
1.4.3
キャッシュサーバー
キャッシュサーバーは、インターネットサーバーのコンテンツのコピーを保持し、
応答時間を短縮するために利用されるサーバーである。
キャッシュサーバーに対してもロードバランサーを適用することができ、製品によ
っては、リクエストされたURLの情報を元にキャッシュするサーバーを特定すること
で、キャッシュ領域を有効に活用する機能を備えたものもある。また、ユーザからの
透過的なHTTPリクエストを自動的にキャッシュグループへリダイレクトする機能を
持つ製品もある。これにより、ブラウザのプロキシ設定が不要となるため管理コスト
が軽減できる、ユーザが確実にキャッシュサーバーを利用することが保証される、な
どの効果も期待できる。ただし、透過的なキャッシュシステムは、ネットワーク設計
方法により、パフォーマンスボトルネックとなりやすく、障害を生む原因となる点を
注意する必要がある。
リバースキャッシュサーバーは、クライアント側のキャッシュと同じで、静的コン
テンツへのアクセスをインターネットサーバーの代理で処理する。インターネットサ
ーバーの手前に設置し、インターネットサーバーには動的コンテンツを中心に処理さ
せることで、静的コンテンツ配信の高速化や負荷の軽減を実現する。また、ロードバ
ランサー自体にリバースキャッシュ機能を持つ製品もある。
1.4.4
ファイアウォール
インターネットを利用したシステムでは、ファイアウォールがボトルネックとなり
やすい。また、ファイアウォールがダウンしてしまうと、サイト全体のサービスが停
止してしまう。このような観点から、大規模サイトではロードバランサーを使ってフ
ァイアウォールを複数設置し、パフォーマンスの向上と冗長性を確保する必要がある。
16
Domain Name System:TCP/IP ネットワーク環境において、ホスト名から対応する IP アド
レスを取得できるようにするサービスを提供するシステム。
Copyright © 2003 IPA, All Rights Reserved.
1-23
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
ファイアウォールに障害が発生した場合は、正常に作動しているファイアウォール
にトラフィックをリダイレクトする。図 1-10は、ファイアウォールサンドイッチと呼
ばれるファイアウォールのロードバランスの構成図である。
インターネット
ISP1
ISP2
ISP
ルータ
スイッチ
ロードバランサー
スイッチ
監視端末
ファイアウォール
スイッチ
ロードバランサー
スイッチ
インターネットサーバー
図 1-10
ファイアウォールのロードバランス構成図
ファイアウォールのインターネット側に設置されるロードバランサーは、サイトに
送られるパケットをそれぞれのファイアウォールに振り分ける。また、ファイアウォ
ールの内部ネットワーク側に設置されるロードバランサーは、通過してきたファイア
ウォールへ応答パケットが戻るように制御を行う。これは、インターネットからの接
続要求に対し、サーバーからの応答パケットが接続要求を処理したファイアウォール
を通して転送される必要があるというファイアウォールの性質上の理由からである。
また、インターネットへ向かうトラフィックについてもロードバランサーで上記同様
の処理が行われる。
各々のロードバランサーでは、単にファイアウォールのヘルスチェックだけでなく、
ファイアウォールの先につながるパスまでをチェック対象とする。ファイアウォール
Copyright © 2003 IPA, All Rights Reserved.
1-24
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
またはパスに障害が発生した場合は、他の正常なファイアウォールおよびパスを利用
することで、ユーザに対し継続的にアクセスパスを提供することができる。また、負
荷分散グループに含まれるすべてのファイアウォールがセッション状態の情報を共有
している場合、ファイアウォールに障害が発生してもユーザセッションは中断されな
い。
1.4.5
ISP(マルチホーミング)
エンタープライズ・ネットワーク環境では、インターネットへの接続性に冗長性を
持たせるために、複数のインターネットアクセス回線を持つ必要がある。ISPの障害に
も対応するためには、さらに複数のISPを利用する必要がある。この構成はマルチホー
ミングと呼ばれる。これまでマルチホーミング環境の実現にはBGP-417(Border Gateway
Protocol Version 4)というルーティングプロトコルが利用されてきた。(BGPについて
は2章を参照)しかし、BGP-4には設定、管理、運用に専門の技術が必要であることや
BGP利用のためにJPNIC(日本ネットワークインフォメーションセンター)などに申請
が必要であることなどの理由から、比較的小規模のネットワークセグメントでのBGP
による接続は事実上困難であり、簡単に利用できるものではなかった。
昨今、ファイアウォールロードバランスの技術とDNSを使った広域ロードバランス
の技術を併用することでマルチホーミング環境を構築できる、マルチホーミング専用
のロードバランサーが販売されるようになってきた。これにより、従来のBGPによる方
法よりも比較的容易にマルチホーミング環境が構築できるようになった。
1.5 CDNと広域ロードバランス
1.5.1
広域ロードバランスの必要性
大規模な停電や災害などにより、サイト全体がサービス提供不可能に陥る可能性も
ある。この場合はサービスを地理的に離れた場所に分けて設置するのが効果的である。
CDN(Contents Distribution Network、またはContents Delivery Network)を利用する方法
もある。CDNとは、ファイルサイズの大きいデジタルコンテンツをネットワーク経由
で配信するために最適化されたネットワークである(図 1-11)。CDNを構築・運用し、
17
インターネットで主として利用されているドメイン間ルーティングプロトコルのバージ
ョン 4。CIDR(Classless Interdomain Routing)をサポートするほか、ルーティング テーブル
のサイズを抑えるための集約機能を持つ。
Copyright © 2003 IPA, All Rights Reserved.
1-25
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
企業などに有料で利用させるサービスをコンテンツデリバリサービス(CDS)という。
複数のサイトへのサーバーの分散配置では、下記のような利点がある。
サイトの電力障害・災害などの対策
iDC18やプロバイダのバックボーン限界時の対策
ユーザの近くへのサーバーの設置
複数のサイトへサーバーを分散配置した場合、ユーザからのリクエストを適切に振
り分ける仕組みが必要になるが、現在では広域ロードバランサーと呼ばれる製品を導
入し、ユーザを最適なサーバーに導く方法が一般的になってきている。広域ロードバ
ランサーは、ヘルスチェックにより各サイトのサービス提供可能状況を定期的に確認
し、ユーザを最適なサイトへの接続を提供する。
静的コンテンツがメインのサイトでは、キャッシュサーバーを分散させる。ただし、
可用性を高めるためにはオリジナルのサーバーも分散させることも必要である。
東京サイト
大阪サイト
広域
ロードバランサー
インターネット
ニューヨークサイト
図 1-11 CDN と広域ロードバランス
1.5.2
広域ロードバランスの方式
負荷分散を検討する単位は以下の2つの場合がある。
18
Internet Data Center:E コマースや ASP 事業を行うためサーバーのホスティング拠点。
Copyright © 2003 IPA, All Rights Reserved.
1-26
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
各サイト内に設置された単一のサーバー
ロードバランサーが形成する仮想サーバー
一方、ロードバランスの方式には
DNS
HTTPリダイレクト
による2つの方式がある。
(1)
DNS 方式
DNSによる方式は、DNSキャッシュの脆弱性(4章)があるが、あらゆるアプリケー
ションに対応できる。DNS方式の処理の流れは次のようになる(図 1-12)。
① クライアントは対象サイトにアクセスするため、ローカルの DNS にホスト名を問
い合わせる。
② ローカル DNS サーバーは広域ロードバランサーにホスト名を問い合わせる。
③ 広域ロードバランサーは、収集しておいた各サイトの負荷情報や状態の情報を元
に、クライアントにとって最適なサイトのアドレスをローカル DNS に転送する。
④ ローカル DNS は広域ロードバランサーから受け取った IP アドレスをクライアント
に転送する。
⑤ クライアントは応答されたアドレス情報を元に、最適なサイトにアクセスする。
クライアント
東京サイト
⑤
①
③
④
インターネット
サーバー
②
広域
ロードバランサー
ローカル
DNS
インターネット
大阪サイト
ニューヨークサイト
図 1-12
DNS 方式
Copyright © 2003 IPA, All Rights Reserved.
1-27
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
(2)
HTTP リダイレクト方式
HTTPリダイレクトによる方式は、適用サービスがHTTPのみに限定される。しかし、
DNSキャッシュの問題を回避できる、DNSの仕組みに依存しない(広域ロードバラン
サーだけで制御ができる)、サイトの障害に瞬時に対応できる、などのメリットがあ
る。HTTPリダイレクト方式の処理の流れは次のようになる(図 1-13)。
① ユーザが広域ロードバランサーの仮想 IP アドレスにアクセスする。
② 広域ロードバランサーは、収集しておいた各サイトの負荷情報や状態の情報を元
に、ユーザにとって最適なサイトを決定し、サイトのアドレスが変更された旨の
HTTP 応答をユーザに対して返答する。
③ ユーザは広域ロードバランサーから知らされたアドレス情報を元に、最適なサイト
へアクセスする。
クライアント
東京サイト
①
③
②
広域
ロードバランサー
インターネット
サーバー
ローカル
DNS
インターネット
大阪サイト
ニューヨークサイト
図 1-13
1.5.3
HTTP リダイレクト方式
広域用ロードバランサーの機能
広域用ロードバランサーの機能としては、冗長構成、ヘルスチェックおよび負荷分
散アルゴリズムがあり、以下に説明する。
まず、広域ロードバランサー自体も冗長構成を取ることができる。
Copyright © 2003 IPA, All Rights Reserved.
1-28
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
ヘルスチェック機能では、ローカルロードバランサーとほぼ同等の機能を備える。
製品によっては、各社のローカルロードバランサーと連携することで、サイトの負荷
を考慮できるものもある。
負荷分散アルゴリズムも基本的にはローカルロードバランサーと同じ方法が利用可
能である。広域ロードバランサー製品によっては以下に示す近接性の情報やサイトの
情報を利用し負荷分散できるものもある(表 1-6)。
表 1-6
広域ロードバランサー製品での負荷分散アルゴリズム
考慮点
近接性
アルゴリズム
ホップ数(対象サイトまでの中継ルータ数)
BGP のメトリック情報
サイトまでの経路の品質
サイトの負荷や状態
サイト負荷の状態
サイトのキャパシティ
サイトに設置された(ローカル)ロードバランサーと情報をやり取りして、各サイ
トの負荷情報を収集し、負荷分散に役立てることができる製品もある。このやり取り
には各ベンダの独自プロトコルが使われるのが一般的であるため、システム内のすべ
てのロードバランサーが同一ベンダの製品で統一されている必要がある。
1.5.4
その他の留意点(DNSキャッシュ)
DNSサーバーは一度解決したホスト名を一定時間(長いものは1日など)キャッシュ
領域に保存しておき、再度同じホスト名解決要求が届いた場合にキャッシュから応答
する。これにより、レスポンスの改善やDNSトラフィックを削減できるなどのメリッ
トがある。広域ロードバランサーがサイト障害を検出し、そのサイトへのトラフィッ
ク転送を停止していたとしても、ユーザはローカルDNSのキャッシュから応答される
(障害)サイトに接続してしまうため、この結果がユーザに反映されない、という問
題がある。このような状況を防ぐため、広域ロードバランサーはホスト名解決に応答
する際に、その情報の有効期限をユーザ側で指定できるようになっている。広域ロー
ドバランサーの効果を高めるためには、有効期限を短く設定すべきである。しかし、
短く設定しすぎるとDNSトラフィックの急増を招く恐れがあるため、設定値は数十秒
程度にとどめるべきである。
Copyright © 2003 IPA, All Rights Reserved.
1-29
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
1 サーバーのハイアベイラビリティ技術
1.6 参考資料
本章での参考資料は以下である。
日経 Windows プロ,2001.12 月号
F5 Networks Japan,http://www.f5networks.co.jp/
ArrayNetworks Inc.,http://www.arraynetworks.net/
日本ラドウェア株式会社,http://www.radware.co.jp/
Nortel Networks Japan,http://www.alteon.co.jp/
Cisco Systems K.K.,http://www.cisco.com/japanese/
エクストリームネットワークス K.K.,http://www.extremenetworks.co.jp/
物産ネットワークス株式会社,http://www.foundry.ne.jp/
ソフトバンク・テクノロジー株式会社,http://www.ni.tech.softbank.co.jp/
株式会社ソリトンシステム,http://www.soliton.co.jp/index_1.html
日本ストラタステクノロジー株式会社,http://www.stratus.co.jp/
RFC 2865,2000.6
日経インターネットテクノロジー,2002.6 月号,新時代を迎える企業インターネット接続
日経インターネットテクノロジー,2002.7 月号,ベスト・エフォートからの脱却
日経インターネットテクノロジー,2002.8 月号,エッジ・コンピューティング(CDN)
日経インターネットソリューションズ,2002.10 月号,特集 ファイアウォールの 7 つの疑問
日経オープンシステムズ,2001.10 月号,特集 Part2 24 時間,365 日稼働を実現する
日経オープンシステムズ,2001.6 月号,活用&選択 負荷分散装置
日経オープンシステムズ,2000.4 月号,特集 WWW システムはなぜ遅いのか?
日経コミュニケーションズ,2002.9.16 号,ここが知りたい “お手軽”マルチホーミングの効き目
日経コミュニケーションズ,2001.11.19 号,多様化進むサーバー負荷分散装置
日経コミュニケーションズ,2001.9.17 号,第 2 特集 テクノロジスコープ サーバー負荷分散技術
日経コミュニケーションズ,2000.10.2 号,立ち上がるかコンテンツ配信サービス
日経コミュニケーションズ,2000.3.20 号,サーベイ&チョイス サーバー負荷分散装置
日経コミュニケーションズ,2000.1.17 号,立ち上がるロードバランサー市場
INTEROP MAGAZINE,2001.2 月号,サーバー負荷分散装置の運用
INTEROP MAGAZINE,2000.9 月号,企業セキュリティ運用ガイド第 5 回 ファイアウォールの冗長構成と信頼性向上
INTEROP MAGAZINE,2000.12 月号,特集「止まらないサービス」実現のためのヒント サーバロードバランサ編
Copyright © 2003 IPA, All Rights Reserved.
1-30
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
2 ネットワークのハイアベイラビリティ
技術
2.1 ネットワークのハイアベイラビリティの必要性
企業ネットワークを構築・運用・管理しているIT部門のタスクは、ネットワークのダ
ウンタイムを限りなくゼロに近づけることである。一方、ネットワーク・インフラは、
障害の兆候を発することなく障害を起こす場合が多い。そのため、IT部門が直面する最
重要課題は、電源、デバイス、ユーザ・グループ、リモートアクセスなどの重要なネ
ットワーク要素の異常を瞬時に感知すると共に、その危険性に対処することである。
ハイアベイラビリティなネットワークを構築するためには、IT部門におけるネットワー
ク管理者は7層からなるOSI参照モデルにおけるあらゆる層の技術を駆使する必要があ
る。表 2-1に、ルータ・スイッチ・リピータハブと、OSI参照モデルとの関係を示す。
表 2-1 ルータ・スイッチ・リピータハブと、OSI 参照モデルとの関係
レイヤ 7
アプリケーション層
レイヤ 6
プレゼンテーション層
レイヤ 5
セッション層
レイヤ 4
トランスポート層
レイヤ 3
ネットワーク層
ルータ
レイヤ 2
データリンク層
スイッチ
レイヤ 1
物理層
リピータハブ
「リピータハブ」は物理層(レイヤ1)で動作し、これを使うことでイーサネットの
ケーブル長の制限を越えてネットワークを構築することができる。リピータハブの場
合、カスケード接続できる段数には制限がある。10BASE-Tなら4段まで、100BASE-TX
なら2段までである。これに対し「スイッチ」はデータリンク層(レイヤ2)で動作し、
リピータハブのような段数制限はない。これは、スイッチではMACアドレスを使って
データの送り先ポートを識別し、それ以外のポートにはデータを送信しない仕組みに
なっていて、コリジョン19を低く抑えることができるからである。一方、「ルータ」は
19
(collision)ネットワークにおいて複数のノードから同時にパケットを送信しようとして
パケットが伝送媒体上で衝突し、正しく送信できない状態のこと。
Copyright © 2003 IPA, All Rights Reserved.
2-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
ネットワーク層(レイヤ3)で動作し、IPアドレスを使ってパケットを転送する。つま
りスイッチ間(LANセグメント間)でデータを移動させる。
ハイアベイラビリティ・ネットワーク構築の目的は、企業におけるエンドユーザが
業務に必要なあらゆるサービスに対して、何の障害もなくアクセスできることである。
しかし、ネットワーク・インフラはデバイスとアプリケーションを組み合わせて構成
されており、何らかの理由により突然のネットワーク障害を起こすことは必然的であ
る。
そのため、障害が起こることを前提として、ハイアベイラビリティ・ネットワーク
を設計し構築するべきである。こうした前提に立つと、重要なのは個々のデバイスの
平均故障間隔(MTBF)ではなく、ネットワークのダウンタイムを限りなくゼロに近づ
けることである。このような考え方によりハイアベイラビリティ・ネットワークの課
題に取り組むことは、ビジネスやエンドユーザの観点から見ても適切である。
以下、OSI参照モデルの階層別に、ハイアベイラビリティ・ネットワーク構築の技術
を説明する。
2.2 レイヤ1
企業ネットワークにおけるハイアベイラビリティ・ネットワーク構築の基本的な構
成要素は、レイヤ1、つまりインフラである。信頼性の高いインフラの設計は、ネッ
トワークの可用性を高めるための基礎工事のようなものである。高い信頼性のインフ
ラを準備できてこそ、システムのアップタイムを構成する他のすべての層を実用的な
観点から検討することが可能となる。
2.2.1
ネットワーク機器の電源
レイヤ1(物理層)における最大の課題の一つは、ネットワークを構成する物理デ
バイスに一定の電力を供給し続けることである。そのためにはネットワークを構成す
るデバイスが、ロードシェアリング型の二重化電源を備えていることが望ましい。二
重化電源により、1つの電源が故障しても、別の電源がサービスを中断することなくシ
ャーシ(本体)に電力を供給し続けることが可能となる。
Copyright © 2003 IPA, All Rights Reserved.
2-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
さらに、二重化電源を使っても、デバイスへの電力供給を保証するためには、同じ
供給源から電力を取ることを避けるべきである。例えば、同一のブレーカ上の回路に
両方の電源を接続することは賢明な選択とは言えない。
電力システムの障害による電圧の低下や落雷による瞬断などの影響を受けず、安定
した電力をデバイスに供給するためにはUPS(無停電電源装置:Uninterruptible Power
System)の導入が最適である。UPSはCVCF(Constant Voltage Constant Frequency)とも
呼ばれる。現在は、スタンドアロン型からラック型などネットワーク規模に応じたUPS
を選択することが可能である。
2.2.2
(1)
ネットワーク機器のシャーシ
モジュールの独立
シャーシとモジュールで構成されるネットワークデバイスにおいては、ある機能を
果たすモジュールなどのコンポーネントは、同一シャーシ内の他のコンポーネントと
は独立している必要がある。つまり、分散インテリジェンスと分散処理、という設計
をされているのが一般的である。このように設計されたデバイスにおいては1つ以上の
要素のアベイラビリティが低下しても、同一シャーシ内にある他の要素に影響を及ぼ
すことはない。
具体的に言うと、ネットワークデバイスを構成するバックプレーン、パケット転送、
ルーティング、物理インタフェースなどのそれぞれのデバイス機能は完全に分離・分
散しているのである。したがって、あるモジュールが故障による保守作業などの理由
により使用できなくなっても、シャーシ内の他のモジュールはその影響を受けること
なく動作し続けることが可能となり、モジュール交換も電力を落とすことなく、シス
テム稼働状態にて行うことも可能となる。
(2)
モジュールの二重化
さらに、シャーシ内に搭載するモジュールを二重化することで、モジュール障害に
よる機能の停止を防ぐことが可能となる。
(3)
モジュールの例
レイヤ3スイッチを例に挙げると、シャーシを構成するモジュールは以下のようなも
のがある。
バックプレーンとなるスイッチファブリック
パケット転送とルーティングを行うコントロールモジュール
Copyright © 2003 IPA, All Rights Reserved.
2-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
物理インタフェースを提供するインタフェースモジュール(1000Base-SXや
ATM20:Asynchronous Transfer Modeなど)
2.2.3
ネットワーク機器の配置
今日の企業ネットワークはネットワークデバイスとクライアント、サーバー類がUTP
ケーブル(Unshielded Twisted Pair Cable)や光ケーブルなどを使用したスター型トポロ
ジにて接続されるのが一般的である。さらに、ネットワーク規模にもよるがコア、デ
ィストリビュート、アクセスといった階層的に設計されるのが標準的であり、これら
を総称して階層化スター型トポロジとも呼ばれている。しかし、階層化スター型トポ
ロジと言えども、単純なものはデバイス障害などどこか1箇所のトラブルがネットワー
クシステム全体に影響を及ぼす、単点障害(SPOF)が存在する。
この単点障害をなくすために、先に述べたデバイスに組み込んだ各種冗長性に加え、
ネットワークデバイス自体の冗長化によるネットワーク経路の冗長化などの方法によ
ってネットワークシステムを補強する必要がある。
しかし、すべてのネットワーク経路を冗長化することは現実的ではない。というの
も、ネットワークにおいてクライアントに代表されるエンドステーションが備える物
理的なインタフェースは1つしかないのが普通であるためである。また、二重化の場合
には単純に計算してもコストが2倍になってしまうのである。そのため、ネットワーク
デバイスの冗長化、つまりネットワーク経路の二重化はコストと障害時に受ける影響
度(リスク)を考慮して設計を行う必要がある。
2.3 レイヤ2
「ブリッジされたネットワークセグメント」とも呼ばれるレイヤ2ドメインでは、イ
ンフラの特長を生かしつつ、ブロードキャスト・トラフィックを制御し、システム全
体のアベイラビリティを向上させることがポイントとなる。
2.3.1
(1)
STP(スパニングツリー・プロトコル)
STP の標準化
レイヤ2ドメイン内部では、ブロードキャストが通過する経路を1つにすることが重
要である。それを実現するために、一般的なネットワークデバイスが実装しているプ
ロトコルがSTP(スパニングツリー・プロトコル)である。
20
セルと呼ばれる固定長のフレームを転送する通信方式。非同期転送モード。
Copyright © 2003 IPA, All Rights Reserved.
2-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
STPは旧DEC21とIEEE802.1d22にてそれぞれ標準化された。レイヤ2におけるネットワ
ーク・ループを回避するためのプロトコルである。具体的にはブリッジ間にてBPDU23
(Bridge Protocol Data Unit)と呼ばれる制御パケットを送受信することで情報を受け渡
し、ループが発生しないように一部の経路を論理的に遮断(ブロッキング)する。こ
のように、STPは実際の「ループのある」冗長な経路を「論理的にループのない」トポ
ロジを作成することにより、物理的なループをレイヤ2ドメインに存在させている。
ネットワークデバイスによってはDEC方式とIEEE802.1dの方式の両方をサポートし
ているものとIEEE802.1dしかサポートしていないものがある。この2つの間には、相互
互換性はないためSTPを使用しているネットワークにおいて、ネットワークデバイスを
追加する場合にはサポートしているSTPの仕様を考慮する必要がある。
(2)
スパニングツリー再構築時間
ハイアベイラビリティが求められるネットワークにSTPを導入する際には、障害時、
復旧時におけるスパニングツリー再構築に要する時間を考慮する必要がある。という
のも、スパニングツリーの再構築中はネットワークがダウンしている状態であり、そ
れに要する時間は約45秒かかるのが一般的である。さらに、ネットワーク規模によっ
てはそれ以上の時間を要することも考えられる。なお、ネットワークデバイスに対す
るSTPのタイマー値を調整することでスパニングツリー再構築によるネットワークダ
ウン時間を短縮することは可能だが、それでも10秒以上かかってしまう。
近年、スパニングツリー再構築時間、つまりレイヤ2収束時間を短縮するために、
UplinkFastなどSTPを拡張したベンダ独自の機能を持たせたネットワークデバイスもあ
る。さらに、RSTP(Rapid STP)と呼ばれるスパニングツリー再構築を高速に行う技術
がIEEE802.1wにて標準化が完了しており、今後はIEEE802.1wを搭載したネットワーク
デバイスが増えると考えられる。なお、この技術によりレイヤ2収束時間は1秒以内と
も言われている。
(3)
多重スパニングツリー(MSTP)
また、Per Vlan Spanning TreeやSpanning Forestなどネットワークデバイスベンダが独
自に搭載しているVLAN毎にSTPを設定できる技術は、IEEE802.1sでは多重スパニング
ツリー(MSTP:Multiple STP)として標準化が進められている。この技術により、い
21
旧 Digital Equipment 社独自のスパニングツリー・プロトコル
CSMA/CD 方式(EEE802.3)、トークンパッシングバス方式(IEEE802.4)
、トークンパッシ
ングリングアクセス方式(IEEE802.5)のネットワークに使用するためのブリッジのアクセ
ス制御についての規格。
23
スパニングツリー・プロトコルの hello パケット。ネットワーク内のブリッジ間で情報を
交換するために、設定可能な一定の間隔で送出される。
22
Copyright © 2003 IPA, All Rights Reserved.
2-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
くつかの小規模なスパニングツリーを作成することが可能となり、STPが動作している
ネットワークデバイスの障害による影響範囲を小さくすることができる。
2.3.2
リンクアグリゲーション
リンクアグリゲーションは、複数の物理インタフェースを1つの論理インタフェース
として束ねる技術であり、これを使用してネットワークデバイス間を接続することで、
接続の信頼性を高めるだけでなくネットワークデバイス間の通信帯域幅を増大するこ
とが可能である。
例えば、4つのFastEthernetの物理インタフェースをリンクアグリゲーションにより束
ねた場合、通信帯域幅は200Mbps(全二重)×4=800Mbpsになると同時に、物理インタ
フェースやケーブル切断などの障害があった場合でも、1秒未満で障害を検知しネット
ワークトポロジに影響を与えることなく該当するリンクを避けるようにデバイス間の
トラフィックを他のリンクに振り分けてくれる(図 2-1)。
従来はEtherChannel、SmartTRUNKなどネットワークデバイスベンダ独自の技術によ
りリンクアグリゲーションを実現していたが、互換性がないためリンクアグリゲーシ
ョンを使用して接続するのは同一ベンダのデバイスに限定されていた。しかし、
IEEE802.3adによりリンクアグリゲーション機能が標準化され、IEEE802.3adをサポート
していれば、ベンダが異なってもデバイス間の接続にリンクアグリゲーションを使用
することが可能となった。
FastEthernet 200Mbps × 4 = 800Mbps
図 2-1
リンクアグリゲーション
2.4 レイヤ3
今日の企業ネットワークにて広く使用されているIPプロトコルはネットワーク層、つ
まりOSI参照モデルのレイヤ3に該当する。IPプロトコルはIPアドレスを元に、ルーティ
ング機能によりパケットが転送される。
ここではレイヤ3のルーティング機能を使用してハイアベイラビリティ・ネットワー
クを構築するための技術を説明する。
Copyright © 2003 IPA, All Rights Reserved.
2-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
VRRP(Virtual Router Redundant Protocol)
ダイナミックルーティングプロトコル
マルチホーミング
2.4.1
(1)
VRRP(Virtual Router Redundant Protocol)
デフォルトゲートウェイの二重化
VRRPはRFC2338にて標準化されているプロトコルであり、デフォルトゲートウェイ
を二重化することを目的としている。経路の冗長化を実現するダイナミックルーティ
ングプロトコルとは別ものであり、デバイスに対してVRRPとダイナミックルーティン
グプロトコルを別々に設定することはもちろん、併用することも可能である。
VRRPでは複数のレイヤ3対応デバイスをグループ化し「仮想ルータ」を設定する。
デフォルトゲートウェイを1つしか設定できないエンドステーション(クライアント)
に対して、その仮想的なルータをデフォルトゲートウェイに設定することにより、レ
イヤ3対応デバイスが障害などによりダウンした場合でも、残りのデバイスがエンドス
テーション間のコネクティビティ(接続性)を提供する。なお、1台のレイヤ3対応デ
バイスを複数のグループに所属させ、複数の仮想ルータを設定することで、エンドス
テーションに設定するデフォルトゲートウェイを振り分けることにより高信頼性と負
荷分散を実現することも可能である。
(2)
ベンダ独自の VRRP
VRRPと同じ機能を持ちながら、ネットワークデバイスベンダ独自のプロトコルも存
在する。代表的なものとして、HSRP(Hot Standby Router Protocol)やESRP(Extreme
Standby Router Protocol)、FSRP(Foundry Standby Router Protocol)などがあるが、相互
の互換性はない。
例えば、ESRPはスイッチとルータを兼ねる装置に特有の拡張がいくつか施されてい
る。VRRPでは、フェイルオーバーの際にはフォワーディングデータベースのエントリ
ーが消えるまで待たなければならない。一方、ESRPをサポートしたスイッチに接続さ
れている場合は、フェイルオーバー、フェイルバックともに一定時間内に行われる。
また、ESRPはIPXルーティングの冗長化にも使用可能、といった相違点がある。
2.4.2
ダイナミックルーティングプロトコル
ルータやL3スイッチなどのネットワークデバイスはレイヤ3、つまりIPアドレスを元
にルーティング機能によりパケットの転送を行う。ルーティングによるパケット転送
を行うためには、ルーティングテーブルが必要である。ルーティングテーブルは人が
静的に作成するものと、ネットワークデバイスが自動的に作成する2つがある。後者の
Copyright © 2003 IPA, All Rights Reserved.
2-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
ようにネットワークデバイスが自動的にルーティングテーブルを作成するためには、
ネットワークデバイス上にてダイナミックルーティングプロトコルを動作させる必要
がある。現在広く使用されているダイナミックルーティングプロトコルにはディスタ
ンスベクター(Distance Vector)およびリンクステート(Link State)と呼ばれる2つの
種類が存在する。
2.4.2.1 RIP(Routing Information Protocol)
DVA(Distance Vector Algorithm)というアルゴリズムを採用するディスタンスベク
ター・ルーティングプロトコルでは、各デバイスがホップ数と呼ばれるパケットが宛
先に届くまでに経由するデバイスの数を元に、最小のホップ数にて到達できる経路が
決定され、ルーティングテーブルが作成される。ディスタンスベクタ・ルーティング
プロトコルで最も一般的なのがRIP(Routing Information Protocol)である。RIPは実装
が容易なため、高価なネットワークデバイスだけでなくSOHO向けルータなどもサポー
トしており、導入しやすいといえる。しかし、ディスタンスベクター・ルーティング
プロトコルにはハイアベイラビリティ・ネットワークを構築する上での致命的な欠陥
がある。それは、ネットワーク上のディスタンスベクタ・プロトコルが動作するデバ
イスの台数が増えるほど、それらのデバイスがネットワークトポロジを認識するのに
要する時間が長くなってしまう点である。したがって、レイヤ3収束時間(経路情報の
収束時間)も長くなり、デバイスが障害を起こしたり、動作が不安定な状態に陥ると
ネットワークがまったく使用できなくなったりする可能性が高くなる。
また、ディスタンスベクタ・ルーティングプロトコルで使用されるホップ数に制限
がある点は、大規模なネットワークには適さないと共にネットワークのスケーラビリ
ティを阻害する要因となる。例えば、RIPにおける最大ホップ数は16であり、それを超
える数のデバイスを経由した通信が不可能であることを示す。
なお、RIPにはバージョン1とバージョン2があり、RIPバージョン2はRIPバージョン1
の機能に加え、ネットワークにサブネットを指定することが可能なため、サブネット
化されたネットワーク環境への導入も可能である。
2.4.2.2 OSPF(Open Shortest Path First)
LSA(Link State Advertisement)アルゴリズムを採用するリンクステート・ルーティ
ングプロトコルは、隣接するデバイス間の距離に依存するディスタンスベクター・ル
ーティングプロトコルとは異なり、隣接するデバイスへ通じるリンクの状態に依存す
る。
Copyright © 2003 IPA, All Rights Reserved.
2-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
リンクステート・ルーティングプロトコルが動作するデバイスにはIDが割り当てら
れている。各デバイスは隣接するデバイスの識別属性を確認し、LSAに基づく情報パケ
ットを使用して他のデバイスに情報を通知する。LSAは隣接するデバイスの名前だけで
なく、隣接するデバイスに到達するのに要するコストを保持している。以下にLSAの動
きの概要を説明する。
①
LSA はネットワーク上に存在するデバイス(リンクステート・ルーティングプロト
コルが動作している)に転送される。
②
次に、各デバイスは隣接するデバイスから受信した最新の LSA を収納し、各宛先ネ
ットワークまでの最短経路を計算する。
③
受信したすべての LSA に集められた情報に基づいて、各デバイスは認識できる他の
ネットワークへの最短経路をすべて計算する。
④
この情報は、リンクステートデータベース(LSDB:Link State DataBase)に格納され
る。
上記のようにリンクステート・ルーティングプロトコルは動作が複雑であり、動作
するためにはある程度のスペックが求められる。このため、比較的高価なデバイスに
搭載される傾向がある。しかし、リンクステート・ルーティングプロトコルの最大の
長所はスケーラビリティとレイヤ3収束時間が短い点である。リンクステート・ルーテ
ィングプロトコルが動作するデバイスは宛先ネットワークへ通じる独自の経路を計算
しており、さらに、各デバイスはそのLSDBに収納された情報に基づいてネットワーク
に関する独自の全体像を作成し、ネットワークを横断する最速の方法を発見する。最
短経路優先(SPF:Shortest Path First)アルゴリズムを使用することにより、各デバイ
スはネットワークトポロジがいつ変化しても、宛先ネットワークへ通じる新しい経路
を直ちに計算することが可能なのである。
現在、IPネットワークにおいて最も一般的に使用されるリンクステート・ルーティン
グプロトコルはOSPF(Open Shortest Path First)である。OSPFはRIPが抱えるさまざま
な制約を解消するため、IETF24のRFC2176にて定義された大規模ネットワーク向けのル
ーティングプロトコルである。
OSPFでは、ネットワークをそれぞれエリアと位置づけた上で、エリア内でのルーテ
ィングを行う「エリアルータ」とエリア間を接続する「エリアボーダルータ」の2つの
階層構造でテーブルを構成する。各ルータは必要最低限のルーティング情報を持てば
よいので、テーブルサイズが肥大化しないというメリットがある。OSPFでは、ホップ
数ではなく、ネットワークの回線幅を元にした「コスト」という値を元に計算を行い、
24
Internet Engineering Task Force:Internet 上で開発されるさまざまな新しい技術の標準化を促
進するために設立されたコンソシアム。IETF が発行するドキュメントは RFC(Requests For
Comment)として知られる。
Copyright © 2003 IPA, All Rights Reserved.
2-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
最小のコストで到達できる経路を選択する。また、更新は変更が生じた際に随時行わ
れる。
そのほか、拡張性に関しても考慮されており、トラフィックや回線速度、遅延など
を経路選択の条件にしたり、RIPやBGP-4(Boarder Gateway Protocol Version 4)といっ
た異なるルーティング環境との相互接続が行えたりするようになっている。現在では
OSPFはレイヤ3スイッチなど各種デバイスにも実装されており、大規模ネットワークで
はOSPFが一般的に使用されているが、IS-IS25(Intermediate System to Intermediate
System)、EIGRP26(Enhanced Interior Gateway Routing Protocol)(ベンダ独自技術)も
使用されている。
2.4.3
マルチホーミング
マルチホーミングとはサイトを複数のISPと接続し、特定ISPでのネットワーク障害な
どのリスクを回避する技術である。本節では、マルチホーミングについて、2つの方式
を説明する。
BGP(Border Gateway Protocol)によるマルチホーミング
ロードバランサーによるマルチホーミング
2.4.3.1 BGP(Border Gateway Protocol)によるマルチホーミング
マルチホーミングの考え方は従来からある。ダイナミックルーティングプロトコル
の1つであるBGPを使って実現しているユーザも存在していた。しかし、BGPは主に、
ISP間での通信に使用されているルーティングプロトコルであり、BGPをサポートする
ネットワークデバイスも限られる。企業ネットワークで使用されるケースはあまりな
いため、BGPの導入は一般的な企業ユーザにとって高いハードルといえる。現在でも、
ISP接続のマルチホーミングを実現するためにBGPを使用しているユーザはまれであ
る。
しかし、BGPではなく、IPネットワークで広く使用されているDNSの仕組みを応用し
て、マルチホーミングを実現するロードバランサーが登場し、導入するユーザが増え
ている。
25
26
中・大規模ネットワークで使用可能なリンクステート型ルーティングプロトコル
Cisco が開発した拡張ディスタンスベクター ルーティングプロトコル
Copyright © 2003 IPA, All Rights Reserved.
2-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
2.4.3.2 ロードバランサーによるマルチホーミング
マルチホーミング機能を持つロードバランサーはリンク・ロードバランサーとも呼
ばれる。
リンク・ロードバランサーは、DNSの技術を応用し、接続タイプやプロバイダを問
わず複数リンクでのサイトの双方向トラフィックを管理するネットワークデバイスで
ある。ISPとのリンク状態に対してヘルスチェックを行い、トラフィックを最適な接続
回線に送信する。さらに、インバウンド・アウトバウンド双方のトラフィックのダイ
ナミックな負荷分散も行う。
他のネットワークデバイスと同様、リンク・ロードバランサーもデータセンタなど
の大規模サイト向けから中小規模サイトまで、それぞれのトラフィックレベルに合っ
た機種が製品化されており、ハイアベイラビリティとコストのバランスを考慮して導
入することができる。
2.5 レイヤ4∼7
先に述べた技術によりネットワークシステムにおけるレイヤ1∼3の階層を安定した
状態で運用することは可能である。しかし、それだけでは企業組織における日常の業
務要件を満たし十分効果的に機能しているとは言えない。ネットワークにおける待ち
時間は、アプリケーションのデータに悪影響を及ぼす恐れがある。そこで、ミッショ
ンクリティカルな情報伝達の遅れが、業務ニーズを満たすことができないという問題
が発生してしまう。
このような問題は、ネットワークシステムが最低でもレイヤ7、つまりアプリケーシ
ョン層での認識・管理機能を備えるような設計が施されなければ、長期にわたって発
見または改善されないまま放置されてしまう恐れがある。
(1)
レイヤ 7 スイッチ
レイヤ7スイッチは、OSI参照モデルのアプリケーション層(第7層)のデータを元に
ルーティング処理を行うことが可能な機器であり、アプリケーションスイッチとも呼
ばれる。
多くの場合、ルーティング処理はデータリンク層(第2層)のMACアドレスや、ネッ
トワーク層(第3層)のIPアドレスを用いて行われるが、レイヤ7スイッチではHTTPや
FTPなどのアプリケーション層レベルのプロトコルを認識し、パケットの具体的な通信
内容を元に行き先を制御することができる。
Copyright © 2003 IPA, All Rights Reserved.
2-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
負荷分散と帯域制御を合わせた機能を持つ製品、ファイアウォールやIDS(Intrusion
Detection System:侵入検知システム)のロードバランシングや冗長化、コンテンツ課
金のためのデータの記録を行う製品などが登場している。また、攻撃を受けたサーバ
ーの「おとり」として犯行の記録を取る「デコイサーバー」としての機能を持った製
品もある。
(2)
アプリケーション層での認識・管理機能
IT部門などのネットワーク管理者がアプリケーションの性能と動作を理解すること
により、システムとしてのアベイラビリティを定義し、改善することができるのであ
る。つまり、アプリケーション情報を理解するようになると、ネットワーク管理者は
アプリケーションの性能をビジネスと結びつけることにより、ビジネスの要求をネッ
トワーク運用に移し変えることができるようになる。ネットワークに対してアップタ
イムからハイアベイラビリティへ視点が変わることがハイアベイラビリティ・ネット
ワークを成立させる核心であり、企業組織がビジネス指向のハイアベイラビリティ・
ソリューションを本格的に展開する際に生じる重大な思考の転換を意味する。
今後は、アプリケーション層の観点で、より高度なハイアベイラビリティ確保技術
が生まれてくると考える。
2.6 参考資料
本章での参考資料は以下である。
シスコシステムズ株式会社,http://www.cisco.com/japanese/
ノーテルネットワークス株式会社,http://www.nortelnetworks.com/corporate/global/asia/japan/
エンテラシス・ネットワークス株式会社,http://www.enterasys.co.jp/products/vh/
日立電線株式会社,http://www.hitachi-cable.co.jp/
株式会社ネットワールド,http://www.networld.co.jp/amplify/
F5 ネットワークス,http://www.f5networks.jp/
丸紅ソリューションズ,http://www.msol.co.jp/it/radware/
日本ラドウェア株式会社,http://www.radware.co.jp/index.html
日本 AT&T 株式会社,http://www.attgns.co.jp/
ヤマハ RT シリーズルータ,http://www.rtpro.yamaha.co.jp/
スリーコム ジャパン株式会社,http://www.3com.co.jp/
株式会社ネットマークス,http://www.netmarks.co.jp/index.html
物産ネットワークス株式会社,http://www.foundry.ne.jp/
エクストリーム ネットワークス株式会社,http://www.extremenetworks.co.jp/
アライドテレシス株式会社,http://www.allied-telesis.co.jp/
東京エレクトロン株式会社,http://www.tel.co.jp/
株式会社マクニカ,http://www.macnica.co.jp/
Copyright © 2003 IPA, All Rights Reserved.
2-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
2 ネットワークのハイアベイラビリティ技術
ソフトバンク・テクノロジー株式会社,http://www.tech.softbank.co.jp/
トップレイヤーネットワークスジャパン株式会社,http://www.toplayer.co.jp/
ascii24 スリーコム、企業の LAN コア構築向け技術“XRN”と新製品を発表 2002 年 5 月 22 日,
http://ascii24.com/news/i/net/article/2002/05/22/print/635924.html
キーマンズネット スイッチ-基礎講座 Page. 1,http://www.keyman.or.jp/search/30000011_1.html
キーマンズネット スイッチ-基礎講座 Page. 2,http://www.keyman.or.jp/search/30000011_2.html
@IT 標準化の完了した最新イーサネット規格 特集:10 ギガビット・イーサネット大解剖,
http://www.atmarkit.co.jp/fnetwork/tokusyuu/1310gbe/10gbe03.html
アスキーデジタル用語辞典,http://yougo.ascii24.com/
e-Word 情報・通信事典,http://e-words.jp/
日経ネットワーク,2002.5 月号,特集 2 ネットワーク機器カタログの見方
日経ネットワーク,2001.12 月号,LAN 編 レイヤ 3 スイッチ
日経コミュニケーションズ,2002.2.4 号,サーベイ&チョイス 部門向けギガビット対応 LAN スイッチ
日経コミュニケーションズ,2002.2.4 号,早わかり講座 EC サイトの基盤要素 コンテンツ配信を支援する CDN
日経コミュニケーションズ,2002.9.16 号,ネットワーキングの現場ノウハウ トラブルを最小限に抑える監視テクニッ
ク
日経インターネットテクノロジー,2002.8 月号,リンク・ロードバランサー
日経インターネットテクノロジー,2002.3 月号,充実するマルチホーミング専用ロードバランサー
Copyright © 2003 IPA, All Rights Reserved.
2-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3 ストレージのハイアベイラビリティ技
術
サーバーのハイアベイラビリティ技術と連動したストレージのハイアベイラビリテ
ィ技術としては以下の5点がある。本調査報告書では、これらの技術について現状と技
術開発動向を説明する。また、各方式のサイト規模との関連、サービス妨害攻撃に対
しての強度・脆弱性を説明する。それを踏まえた上でのサーバー構築でのストレージ
のハイアベイラビリティ技術選択の観点を述べる。
①
RAID(Redundant Array of Inexpensive Disks)
②
SAN(Storage Area Network)
③
NAS(Network Attached Storage)
④
その他のストレージ技術
⑤
バックアップ
3.1 RAID
RAIDでの考慮点は大きく分けると、下記の2点である。この2点について、攻撃に関
する対策も含めハイアベイラビリティとの関連を説明する。
①
RAID の方式
②
RAID の管理のしやすさ
3.1.1
ディスクアレイ
ディスクアレイとは、複数のディスクを並列に並べて、1つのファイルを複数のディ
スクに並列処理で同時に読み書きすることによって、高速化を実現する技術である。
ディスクアレイには
①
外付けディスクアレイ
②
サーバー内蔵ディスクアレイ
がある。
外付けディスクアレイは、サーバー内蔵ディスクアレイに比べると障害発生時の障
害部位の切り分けが容易で、ハイアベイラビリティシステムの外付けディスクとして
も使用でき、特に信頼性の面でも優位である。
Copyright © 2003 IPA, All Rights Reserved.
3-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
各ベンダで大規模向け、中小規模向けのディスクアレイ製品のラインナップがある。
大規模向けでは以下のような機能をサポートしている。
完全二重化・冗長化のハード構造
遠隔リモートコピー
異種プラットフォーム間での高速データ交換
3.1.2
RAID
RAIDとは、ディスクアレイ技術にさらに冗長性を持たせ、可用性に優れた技術であ
る。また、RAIDは0から5までのレベルがある。ここでは、RAIDのレベルのうち、以下
を説明する。
①
RAID 0
②
RAID 1
③
RAID 0+1
④
RAID 5
3.1.3
RAID 0
RAID 0は「ストライピング」とも呼ばれ、2台以上のハードディスクに対してデータ
を分割して同時に読み書きすることにより、データ転送の高速化を実現する技術であ
る。
3.1.4
RAID 1
RAID 1は「ミラーリング」とも呼ばれ、2台以上のハードディスクに対しまったく同
じデータを書き込むことで、信頼性を向上させる技術である。
3.1.5
RAID 0+1
RAID 0+1とは、RAID 0とRAID 1を組み合わせた技術である。これは、最低4台のハ
ードディスクで構築し、RAID 0を構築したセットをRAID 1により複数構築するという
ものである。RAID 0でデータ転送の高速化を実現し、また複数のハードディスクを単
一ドライブとして活用できる上、RAID 1により冗長性も確保できる。ただ、ハードデ
ィスクの利用効率は半分以下に下がる。
Copyright © 2003 IPA, All Rights Reserved.
3-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.1.6
RAID 5
RAID5は、ハードディスクの故障時に記録データを修復するための「パリティ」と呼
ばれる冗長コードを、全ハードディスクに分散して保存する技術である。RAID 5では、
データをハードディスクに記録する際、RAID 0と同様に複数のハードディスクにデー
タを分散して書き込む。その際、パリティも計算し、書き込む。パリティは、全ハー
ドディスクに分散して書き込まれる。このため、パリティの書き込みで単一の(また
は固定の)ハードディスクのみに負荷(アクセス)が集中し、性能が低下するという
ことはない。また、ハードディスクが1台故障しても、それ以外のハードディスクのデ
ータとパリティから、元の完全なデータを修復できる。ただし、データ修復可能なの
はハードディスク1台の故障までで、同時に2台以上が故障するとデータが修復できな
い。
パリティの保存に必要なのは、ハードディスク台数に関係なくハードディスク1台分
の容量である。したがってハードディスク台数が多いほど容量の利用効率が向上する
ことになる。RAID 0+1と比較した場合、この利用効率の高さがRAID 5のメリットであ
る。性能については、読み出し時に複数のハードディスクから同時並行読み出しが可
能なので読み出し性能は高い。一方、パリティを生成するオーバーヘッドから、書き
込み性能は高くはない。
3.1.7
各種RAID技術
各種RAID技術として下記を説明していく。
①
ソフトウェア RAID
②
ハードウェア RAID
③
アダプティブ RAID
④
バーチャルアレイ
⑤
オンラインアップグレード
ソフトウェアRAIDは、サーバーに搭載したソフトウェアによって、複数のディスク
ドライブを1つのディスクアレイとして取扱う。一方、ハードウェアRAIDは、サーバー
のCPUとは独立したアレイコントローラ、インタフェースを持っている。
一般にハードウェアRAIDは、ソフトウェアRAIDに比べるとやや高価である。一方、
サーバーのCPUとは独立してディスクの処理を行うため、サーバーのパフォーマンスに
影響を与えない。信頼性の面でもソフトウェアRAIDに比べて障害発生時における障害
部位の切り分けが容易であり、サーバーに障害が発生した場合にもディスクのデータ
を利用できる。
Copyright © 2003 IPA, All Rights Reserved.
3-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
RAID間のインタフェースにも種類がある。例えば、IDE RAIDではSCSIでなくIDEイ
ンタフェースでディスクのRAIDを組む。
サーバー、ストレージが増えれば増えるほど管理のしやすさや作業の自動化なども
大きな課題となってくる。例えば、ベンダ独自RAID技術により、RAIDレベルの自己管
理機能を提供する製品もある。これをアダプティブRAIDという。この機能は、ランダ
ムアクセスとシーケンシャルアクセスの異なる要求に対して、自動的にRAIDレベルを
選び、データをディスクドライブへ格納する機能である。またアクセス頻度の高いデ
ータはパフォーマンスの高いRAID0+1へ、アクセス頻度が低いデータは、ディスク効
率の高いRAID5へ自動で移行しディスクの使用効率を高めることができる。
バーチャルアレイとは、複数のハードディスクドライブを一つの仮想的なストレー
ジプールとして扱うことで、ディスクアレイの管理を簡素化し、パフォーマンスを最
適化する技術である。バーチャルアレイでは、物理データを複数のハードディスク上
に分散して記録し、論理データと物理データをつなぐマップをコントローラのキャッ
シュ上に生成する。コントローラ内に作られたバーチャル・ディスク(LU:論理ユニ
ット)は、物理ディスクに関係なく作られるので、高速かつ、柔軟な論理ユニット管
理が可能である。これによりオンラインアップグレード、アダプティブRAIDなどの優
れた機能を提供することができる。
容量の増加に対応するため、オンラインでのハードディスク増設は重要な機能であ
る。さまざまな容量のドライブが混在する構成でも、オンラインでのハードディスク
の追加が可能なディスクアレイ製品も発売されている。
3.2 NASとSAN
ストレージは、従来はDAS(Direct Attached Storage:サーバー直結型ストレージ)が
採用されていた。しかし下記の点が問題となっていた。
①
ストレージ増設がサーバーに依存するためにサーバー増設が必要である。
②
データ一元化が難しく管理コストが大きい。
③
SCSI(SCSI/IDE も同様)制約でシステム性能が低い。
これらの問題を解決するため、現在ではインターネットサーバーシステムなどのス
トレージは、NAS(Network Attached Storage:ネットワーク直結型ストレージ)やSAN
(Storage Area Network:ストレージエリアネットワーク)といったものに変遷してい
る。
本節では上記技術であるNASとSANを説明する。
Copyright © 2003 IPA, All Rights Reserved.
3-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.2.1
NAS(Network Attached Storage)
NASとは、ネットワーク直結型のファイルサーバーシステムである。サーバーにフ
ァイルサービスに特化した専用OSとFS(ファイルシステム)を搭載している。アプリ
ケーションサーバーやクライアントは、従来のNFS(Network File System)やCIFS27
(Common Internet File System)と同じようにNAS上のファイルにアクセスすることが
できる。また、AppleShareに対応したNASも既に開発されている。
NASには専用OSによるNASと、WindowsベースのNASがある。WindowsベースのNAS
はWindows 2000のファイルサーバーがNFSをサポートしているものであり、性能的にも
さほど違いはない。
NASではすぐに利用できる手軽さが特徴である。長所として以下の5点が挙げられ
る。
①
簡易型ファイルサーバーとして手軽に利用できる。
②
異種サーバー間でファイル共用が可能である。
③
既存のネットワーク・インフラ(LAN)を利用可能である。
④
NFSやWindowsファイルシステムなどをサポートしており、さまざまなクライア
ントからのアクセスにも対応できる。
⑤
汎用サーバーを使用したファイルシステムに比べ高速アクセス可能である。
短所として以下の2点がある。
①
SANに比べデータ転送が低速である。(ギガビット・イーサネットを利用して
も転送速度は30MB/s程度)
②
ネットワーク(LAN)の帯域幅、負荷状態により性能が低下する。
ストレージ拡張が容易なNAS製品も販売されている。ストレージ環境を変更するた
めに新しいハードウェアを導入する必要はない。ボードの入れ替えとソフトウェアの
インストールだけでよい。このような製品を導入すれば小規模な構成からスタートし、
必要に応じてドライブとコントローラを徐々に追加していくことができる。
27
Windows のファイル共有サービスで利用されているプロトコルの「SMB」を拡張し、
Windows 以外の OS やアプリケーションソフトでも利用できるよう仕様を公開したもの。
Copyright © 2003 IPA, All Rights Reserved.
3-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
NASでは、高速にしかも簡単にデータのポイントインタイム・スナップショット28を
作成することができ、高速の無停止オンラインバックアップと簡単なリストアが可能
なツールも発表されている。
3.2.2
SAN(Storage Area Network)
SANとは、サーバーとストレージ間をファイバーチャネル29(Fiber Channel)などの
伝送方式を用いてネットワーク化し、仮想ストレージを実現したものである。ストレ
ージへのアクセスの高速化、一元管理、データ共用・データコピー・バックアップな
どの性能・拡張性・耐障害性を高めている。SANはパフォーマンス、スケーラビリテ
ィともにNASを上回る。
SANの長所として以下の10点が挙げられる。
①
ファイバーチャネル化:ストレージ入出力性能を大幅に向上させる。(ファイ
バーチャネル利用の場合の転送速度は100MB/s程度)
②
サーバー・ストレージ間の距離制限を100Kmに緩和している。
③
LAN負荷低減化:データコピー/バックアップ等のデータがLANを経由しない。
④
データ共用化:複数サーバー(異機種含む)間でのデータ共有が可能である。
⑤
ストレージ一元管理化:複数のストレージデータを一元管理できる。
⑥
ストレージ独立化:サーバー環境と独立し、柔軟にストレージ環境の設定・拡
張が可能である。
⑦
デバイスの共有:大容量テープライブラリ、MOライブラリ、ディスクアレイを
複数のサーバーで共有可能である。
⑧
バックアップ時間短縮:高速データ転送によりバックアップ時間などが短縮で
きる。
⑨
拡張性向上:デバイスやサーバーの増加に対応できる。
⑩
可用性向上:特定のサーバーで問題が起きても、ストレージへのアクセスに悪
影響を与えることなく修正できる。
28
オンライン・ビジネス・プロセスを中断せずに、オンラインデータの瞬間的なスナップ
ショットを作成する技術。
29
12.5Mbytes/sec から数百 Mbytes/sec といったデータ転送を可能とするシリアルインタフェ
イスの規格。メディアは、ファイバーケーブルや同軸ケーブル、ヨリ対線など複数が規格
により利用可能となっている。
Copyright © 2003 IPA, All Rights Reserved.
3-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
SAN環境において、ストレージは複数のホストに共有される。SANではディスクア
レイのLU(Logical Unit)を柔軟にサーバーに割り当て可能である反面、LUを使用しな
いサーバーからもアクセス可能であるため、不正なホストからのアクセスを防止する
必要がある。SANのセキュリティ機能では、各LUに対してアクセスを許可するサーバ
ーを制限できる。これにより、SAN環境での不正アクセスによるデータ破壊、性能劣
化や操作ミスによるデータ破壊を防止できる。
また、異機種環境下でストレージを共有している場合には、データ損失の危険性を
避けるために、スイッチ上でサーバーとストレージのグループ化を行う必要がある。
これが「ゾーン」と呼ばれるものであり、ゾーンを作成することをゾーニングという。
異なるゾーンにあるデバイスは認識できないようにスイッチが制御するため、データ
の安全性を確保することができる。
ストレージ共有においてゾーニングは非常に重要な技術であり、多くのSANシステ
ムで利用されている。デバイスのWWN30(World Wide Name)レベルでのゾーニングと
スイッチのポートレベルでのゾーニングがあり、前者はソフト的に区別するので便利
ではあるがセキュリティに弱く、後者はセキュリティに強いと言われている。ポート
レベルでのゾーニングは通常FC-SW31(Fiber Channel-Switched)にて利用される。
SANのストレージコントローラ製品によっては、1台のSANへ各種UNIXやWindows
2000などの複数OSを同時に接続することが可能である。これを複数OS同時接続ポート
シェアリング機能という。この機能により、ストレージの統合が実現可能である。こ
れにより、異なるOSのハイアベイラビリティ構成を1台のSAN製品の筐体内に混在させ
ることも可能である。
クラスタ環境では、WindowsとUNIXは混在できないため、FC-SWのゾーニングによ
りWindowsとUNIXを分けて、ポートシェアリングを使用してHP-UXとSolarisを共有さ
せている。
一方、SANでは、ファイバーチャネル関連機器(ファイバーチャネル・ボードやフ
ァイバーチャネル・スイッチ)の価格が高く、導入における初期費用が高い。
SAN製品には以下のバリエーションがある。
小規模分散システム向け製品
中規模のUNIX/PCシステムのサーバー向け製品
マルチプラットフォーム/オープンモデル向け製品
30
ファイバーチャネル・スイッチや HBA といったハードウェアに固定的に割り当てられた
64bits(8bytes)のアドレス
31
ファイバーチャネルのトポロジ。スイッチを使ってサーバーとストレージを 1678 万ノー
ドまで接続可能。
Copyright © 2003 IPA, All Rights Reserved.
3-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.2.3
仮想ストレージ
仮想ストレージとは、ディスクアレイ、テープドライブなどのストレージシステム
を構成する機器を抽象化し、ストレージ機能をデバイスから独立させるシステムであ
る。機器の構成や所在、それぞれの容量などを把握しておく必要がなく、個々のハー
ドディスクに分散している空き容量を有効活用できるようになる。
仮想ストレージを実現するには、まず、ファイバーチャネルのスイッチやハブのポ
ートゾーニングなどの機能を使って、アプリケーションサーバーから直接ストレージ
にアクセスできないように設定する。次に、アプリケーションサーバーとストレージ
との間に、ストレージを仮想化するための専用サーバーを設置する。この専用サーバ
ーを仮想ストレージサーバーという。この仮想ストレージサーバーがドメイン内の全
物理ストレージを管理して、ストレージプールを生成する。
こうした仮想ストレージでは、ストレージ側の変更が直接アプリケーションサーバ
ーに影響を与えない。同様に、アプリケーションサーバー側の保守もストレージ側に
影響を与えない仕組みになっている(図 3-1)。
ストレージのハードウェアベンダが提供する仮想ストレージでは、特定ベンダのス
トレージ製品だけを対象に一元管理するようになっているケースがある。しかし、ソ
フトウェアベンダが提供する仮想ストレージでは異なるベンダのストレージ製品も一
元管理できるようになっている。また、仮想ストレージサーバーを複数台設置するこ
とで、スループットと可用性の向上を図ることもできる。
サーバーのハードウェアベンダの提供する仮想ストレージでは、ストレージ製品に
ついてはベンダに依存しないが、利用できるサーバーについては単一のベンダに限定
される。
Copyright © 2003 IPA, All Rights Reserved.
3-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
サーバー
ストレージ
サーバー
FC-SW
サーバー
ストレージ
管理用サーバー
管理用サーバーにてマッピングテーブルを管理し、各サーバーからの
アクセス時に使用するパスを決める
図 3-1 仮想ストレージ
分類方法として以下の内容がある。
ホストベース(ソフトウェア仮想化)
・ホスト上のソフトウェアプロダクトによるRAID。
ストレージ・アレイベース
・ストレージ・サブシステムで仮想化を行う。
ネットワークベース
・ストレージ仮想化がネットワーク内の専用プロセッサ上に行われる。
・「In-band」と「Out-of-band」の手法がある。
この仮想ストレージの中心はSANやNASと呼ばれるネットワーク型ストレージであ
る。仮想ストレージの導入目的としては以下が挙げられる。
ストレージ管理の可用性を高める。
アプリケーションサーバーによる物理的なストレージ管理を不要にする。
異なるストレージシステムの管理を統合する。
アプリケーションサーバーに対して透過的かつ動的にストレージプールを拡張
できるようにする。
ストレージプール内で透過的かつ動的にデータを移動できるようにする。
一貫したストレージ・インタフェースと管理モデルを提供する。
Copyright © 2003 IPA, All Rights Reserved.
3-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
バックアップの占有時間を削減し、データ復旧に費やす時間を削減できるよう
にする。
3.2.4
FCIPとiSCSI
大規模インターネットサーバーシステムへSANを導入するための課題は、サーバ
ー・ストレージ間の距離の制限である。ファイバーチャネルの制限で100Kmより長い
距離での接続ができない。この解決策としてIPストレージという技術が考えられる。IP
ストレージとは、IP技術を利用して、サーバー、ストレージ、テープドライブなどの間
で大量のデータ伝送を行う技術である。IPストレージを実現するために、いくつかの技
術が提案されているが、IETFでは以下の2つの方式を検討している。
FCIP(Fiber Channel over IP, FC over IP)
iSCSI(Small Computer Systems Interface protocol over the Internet)
これらはファイバーチャネル・フレームのカプセリング技術である。この2つを説明
する。
FCIPは、独立した複数のファイバーチャネル(FC)のLAN(FC-LAN)を、IPトンネ
ルを使って相互接続し、仮想的に1つの大きなストレージを構成する技術である。IPネ
ットワークとファイバーチャネルは、ギガビット・イーサネットのポートを搭載した
FCスイッチで相互接続する。つまり、遠く離れた場所にあるSAN同士を接続すること
で、LANとSANを1つのIPネットワークにまとめることができる。ファイバーチャネル
通信の途中で、長距離伝達が可能なTCP/IPネットワークを経由することで、伝達距離
の延長が可能になる(図 3-2)。
iSCSI(Internet SCSIまたはSCSI over IP)はIETFで標準化している技術で、これはSCSI
の命令体系をIPに変換したものである。iSCSIはRFC3347で定義されている。伝送媒体
がファイバーチャネルからIPになっても同じSCSI命令体系を使用することができる。
そのため、HBA(ホストバスアダプタ)やNICのデバイスドライバを変更するだけで、
サーバーシステムに従来のSCSIデバイスを認識させることができる。NASもIPを利用
したストレージだが、iSCSIはファイル単位ではなくブロック単位のアクセスなので、
iSCSIの方がNASより高速伝送できる。なお、従来のファイバーチャネルを使ったSAN
をFC-SANと呼び、iSCSIを使ったSANをIP-SANと呼んで区別している(図 3-3)。
SANに対して、iSCSIはまだ2001年に発表されたばかりである。iSCSIは、対応製品は
発表されているが、事例はほとんどない。だが、SANと目指す方向性が同じであるた
め、やがて大きな勢力になることが予想される。
Copyright © 2003 IPA, All Rights Reserved.
3-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
FC-SAN
FC-SAN
IP ネットワーク
図 3-2 FCIP
iSCSI サーバー
ディスク
ディスク
サーバー
LAN
iSCSI
図 3-3 iSCSI
3.2.5
NASとSANのまとめ
NAS、SANの両者ともストレージ装置をサーバーから切り離し、ネットワークに直
接参加させるという特徴がある。NASはLAN環境に直接接続する形式のストレージデ
バイスで、いわゆる専用ファイルサーバーである。SANは、ストレージとサーバーを
ファイバーチャネルなどにより接続したネットワークである。PCやサーバーとストレ
ージを結ぶネットワークで、通常のネットワークとは異なる。各ストレージの主な用
途は下記のとおりである。
Copyright © 2003 IPA, All Rights Reserved.
3-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
① NAS32:一般オフィスでのメール系、DB 系、Web 系システムのファイル共有
② SAN:iDC/企業での基幹系、CRM33系システムのデータ共有
NASとSANの利点をまとめると下記のようになる。
① 複雑なストレージ環境の管理を単純化する。
② サーバー、アプリケーションを変更せずに、ストレージを統合できる。
③ 運用管理の仕組みをネットワーク・インフラと共通化できる。
④ 高速ストレージと低速ストレージの階層管理により有効活用できる。(ストレージマ
イグレーション)
⑤ 遠隔地サイトへのデータコピーにより、災害に対応できる。
⑥ ストレージの仮想化により利用効率、利便性を高める。(バーチャライゼーション)
(SAN の技術)
⑦ ファイバーチャネルにより高速にアクセスできる。(SAN の技術)
⑧ サブシステム内でのストレージプールによりファイルアクセス、共有が容易にでき生
産性が向上する。(SAN の技術)
表 3-1 NAS と SAN の特徴
特徴
メリット
NAS
SAN
① 簡易型ファイルサーバーとして手軽に利
① ファイバーチャネル化によりストレージ
用可能。
入出力性能が向上。(ファイバーチャネ
② 異種サーバー間でファイル共用が可能。
ル利用の場合の転送速度は 100MB/s 程
③ 既存のネットワーク・インフラ(LAN)
度)
を利用可能。
② サーバー・ストレージ間の距離制限を
④ NFS や Windows ファイルシステムなどを
サポートしており、さまざまなクライア
ントからのアクセスにも対応可能。
⑤ 汎用サーバーを使用したファイルシステ
ムに比べ高速アクセス可能。
100Km に緩和。
③ データコピー/バックアップ等のデータが
LAN を経由しないため LAN 負荷を低減。
④ 複数サーバー(異機種含む)間でのデー
タ共有が可能。
⑤ 複数のストレージデータを一元管理可
能。
⑥ サーバー環境と独立し、柔軟なストレー
ジ環境の設定・拡張が可能。
⑦ 大容量テープライブラリ、MO ライブラ
32
NAS 製品とデータベース製品の組み合わせによっては必ずしも相性がよくない場合があ
るので、導入前に確認する必要がある。
33
Customer Relationship Management:情報システムを利用した顧客関係管理。
Copyright © 2003 IPA, All Rights Reserved.
3-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
特徴
NAS
SAN
リ、ディスクアレイなどのデバイスを複
数のサーバーで共有可能。
⑧ 高速データ転送によりバックアップ時間
などが短縮。
⑨ デバイスやサーバーの増加に対応でき拡
張性が向上。
⑩ 特定のサーバーで問題がおきても、スト
レージへのアクセスに悪影響を与えるこ
となく修正できる可用性が向上。
デメリット
① SAN に比べデータ転送が低速。(ギガビ
① ファイバーチャネル利用の場合は、関連
ット・イーサネットを利用しても転送速
機器(ファイバーチャネル・ボードやフ
度は 30MB/s 程度)
ァイバーチャネル・スイッチ)の価格が
② ネットワーク(LAN)の帯域幅、負荷状
高く、導入時の初期費用が高い。
態により性能が低下。
SAN導入への問題は、ファイバーチャネルの価格が高いことである。しかし、全体
の流れとしては、DASからNAS、NASからSANやiSCSIへと進んでいる。特に大企業で
は、日々増え続ける膨大なデータの管理に対処するため、SANの導入に積極的である。
iSCSIはまだ規格の策定中で対応製品も少ないため、今は導入例が少ないが、数年内に
はSANと同様に利用される可能性がある。
NASとSANは当面、以下のように使い分けられるだろう。
全社的なストレージ統合・接続インフラとしてはSANを利用
ファイルの共用が必要なアプリケーションに関してNASを補完的に利用
一方、将来はSANとLAN(NAS)の統合として、以下のように利用されるだろう。
NAS over SANによるSANベースでのNAS利用(図 3-4)
SCSIによるNAS・LAN統合(図 3-5)
Copyright © 2003 IPA, All Rights Reserved.
3-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
サーバー
SAN
サーバー
ディスク
データ
サーバー
ファイル管理情報
NAS
NAS サーバー
図 3-4
NAS over SAN による SAN ベースでの NAS 利用
サーバー
iSCSI
ディスク
サーバー
データ
サーバー
ファイル管理情報
NAS
LAN
NAS サーバー
図 3-5 SCSI による NAS・LAN 統合
Copyright © 2003 IPA, All Rights Reserved.
3-14
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.3 データ管理技術
RAID、SAN、NAS以外にもハイアベイラビリティに有効なデータ管理技術として、
ジャーナリングファイルシステム、リモート監視がある。ジャーナリングファイルシ
ステムとは、トランザクションを記録するシステムである。リモート監視とは、ファ
イルシステムが動いているかどうかを定期的に検査(ヘルスチェックに対してコント
ローラが応答する)機能である。本節では、この2つを説明する。
3.3.1
ジャーナリングファイルシステム
ジャーナリングファイルシステムとは、ディスク障害発生時、すぐ復旧できるよう
に、ファイル更新履歴を記録しておくファイルシステムである。ディスクにデータを
書き込む際に記録を取っておき、システムのクラッシュや異常動作によってファイル
が壊れた際にはその記録を基にファイルを修復する。このためファイルシステムの修
復率が高くなり、また修復にかかる時間も短縮される。
ジャーナリングファイルシステムではファイルを上書き更新の時にはその処理が正
常に終了するまで更新前のファイルを保管する。このため、ファイルの書き込み中に
停電・システムトラブルなどが起こって、その結果ファイルが破壊されても、サーバ
ーを再起動すれば更新前の状態のファイルが復元される。さらに、オンラインバック
アップも可能である。ジャーナリングファイルシステムでは、ファイルチェックの時
間も高速になっている。
ジャーナリングファイルシステムは、商用UNIXなどで利用されており、Linuxでもバ
ージョン2.4からサポートされた。
3.3.2
リモート監視
リモート監視では、SNMP(Simple Network Management Protocol)で情報を送信する
方法が採られている。各社ハードウェア提供ベンダよりストレージの稼働状況、障害
の有無について確認できる管理ソフトが提供されている。ベンダが提供する障害管理
ツールによっては、トラブルが発生すると影響のあるサーバーを分かりやすく表示す
るものもある。さらにサーバーや装置を指定すると、詳細情報を表示し、故障個所や
原因を究明することができるようになっているものもある。また、監視センタに対し
て通知を行うことが可能なものもある。通知先は通常ストレージ製品の保守サービス
提供を担当しているサービス会社の監視センタ向けとなっている。
提供されるストレージのリモート監視のサービス例としては以下のものがある。
Copyright © 2003 IPA, All Rights Reserved.
3-15
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
(1)
リモートトラブル監視
監視用PCに実装されている監視ツールにより、ストレージシステムの稼働状況を監
視する。トラブル予兆(ディスクモジュール・キャッシュメモリ等のソフトウェアの
エラー)やトラブルを検知した場合、リモートセンタが自動的に通知を受け、対処を
行う。
(2)
リモート診断
リモートトラブル監視での解析の結果リモート診断が必要であると判断した場合、
ユーザに連絡を行い、リモートセンタからリモートサービス専用の回線と監視・診断
専用の監視用LANを通じて監視用PCに接続し、トラブル原因の調査および切り分けを
行う。リモート調査によりトラブル原因が特定された場合、原因およびその対策につ
いてユーザに連絡し、故障修復を行う。
(3)
トラブル履歴管理・定期報告
リモートトラブル監視により通知された情報やユーザからの情報に基づく対応、処
理状況などのトラブル対応履歴を管理し、定期的に報告する。
3.4 基本的なバックアップ技術
ストレージ技術は多岐にわたるものだが、バックアップは、特に可用性と信頼性を
保証するためには不可欠である。システムのデータは、運用での誤操作や保守作業の
ミス、外部からの攻撃により破壊される可能性がある。また地震や火事などによって
大きな損害を被った事例も多い。そのような事態は、基本的には避けられない。どれ
だけ早期に原状回復してサービスを再開できるかが、企業競争力の一つの鍵となって
いる。原状回復のためには、常にバックアップによってデータを保護しておかなけれ
ばならない。
バックアップでの基本的な技術、考慮点には下記がある。
① バックアップ媒体
② ネットワークバックアップと HSM(Hierarchical Storage Management)
③ テープ RAID
④ ディザスタリカバリ
本節では、これらのバックアップ技術を説明する。
Copyright © 2003 IPA, All Rights Reserved.
3-16
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.4.1
データのバックアップ・リカバリのポイント
バックアップは重要であるが、サーバーのサービスすべてに対し、まったく同じレ
ベルで重要というわけではない。例えば、24時間365日の稼働が求められるデータベー
スによるシステムと、社員が日中利用するようなイントラネット用のWebサーバー、フ
ァイルサーバーのような用途では可用性に対する要件が異なる。連続稼働が要求され
るサーバーは、当然稼働中にバックアップを取る必要がある。サービスの特性に合わ
せてバックアップ手法を選択する必要がある。
データのバックアップとリカバリで考慮すべき重要な要素は、次の2つである。
データの損失量を減らす。
ダウンタイムを短縮する。(データを素早く回復する)
この2つの要素を考慮してバックアップの手法を考えることになる。
データの損失量を減らすには、バックアップとRAID技法とを組み合わせる。バック
アップでは、オンラインバックアップや差分バックアップを使用する。また、データ
ミラーリングまたはレプリケーションを使用して、データの完全同期コピーを維持す
る。ジャーナリングファイルシステムなども組み合わせる。遠隔バックアップも必要
である。
ダウンタイムを短縮するには、テープ媒体ではなく他のディスクにデータのコピー
を保持する必要がある。これにはディスクミラーリングまたはレプリケーションおよ
びハイアベイラビリティクラスタリングなどのアプリケーションリカバリツールを使
用する。
以下、このような技術を説明していく。
3.4.2
バックアップ媒体
バックアップ用の媒体では、光メディア、テープ媒体などがある。この二種類を説
明する。
光メディアでは、DVD-RAM、DVD-R、CD-R、CD-RW、MOがバックアップ用に使
われている。ライブラリシステムによって企業システムに必要な数TBの容量を利用で
きるようになり、用途によってはテープの代わりとして活用できるようになってきた。
光メディアは、テープ媒体よりもメディアがコンパクトであり、ライブラリ装置も省
スペースにできる。また劣化が少ないため、アーカイブとして長期保存するのに適切
である。一方、光メディアは、リード/ライトに時間がかかる。テープ媒体に比べて容
量あたりの単価が高い。メディア1枚当たりの容量が少ないため、大量データを扱う場
合には管理が課題になる。
Copyright © 2003 IPA, All Rights Reserved.
3-17
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
テープ媒体は、現在、バックアップメディアとして最も普及している。テープ媒体
は他のリムーバブルメディアに比べ、低コストであり、大容量でもある。一方、テー
プ媒体は、テープの性質上、環境によって劣化が起こる可能性があり、また定期的な
クリーニングの必要もある。またライブラリ装置では機械的に駆動する部分が多く、
メンテナンスが欠かせない。テープ媒体では、DDS(Digital Data Storage、DAT:Digital
Audio Tapeとも言う)、DLT(Digital Liner Tape)、AIT(Advanced Intelligent Tape)、
LTO(Linear Tape-Open)、DTF(Digital Tape Format)等が一般的に利用されている。容
量と転送速度を比べると、現時点ではDLT、またはLTOが優れているといえる。ただし、
DLT、またはLTOの価格は高い。DLTの転送速度は数10MB/sになる。テープ仕様は高
速化、大容量化に向かって進化している。100GBから数TB超のテープ規格が出されて
いる。今後はこのような大容量テープ規格を軸に、比較的中小規模のシステムには、
コストパフォーマンスの高い規格が受け入れられていくと思われる。また、CD、DVD、
DLTは耐用年数(20∼30年)があるため、法的長期保存が求められるデータに関しては、
WORM34(Write Once Read Many)の利用などを考慮する必要がある。
表 3-2、表 3-3に主な媒体の記憶容量と転送速度の目安を示す。数値は大体の目安で
あり、インタフェースの種類や装置の性能により若干異なる。テープ媒体では、テー
プの長さにより記憶容量が異なる。また、データを圧縮することにより約倍の記憶容
量が得られる。
表 3-2 ディスク媒体
媒体種類
記憶容量
転送速度
価格
安価
CD-R
650MB/700MB
150KB/s の n 倍
CD-RW
650MB/700MB
150KB/s の n 倍
MO
128MB/230MB/640MB/1.3GB
1.5MB/s∼20MB/s
DVD-RAM
2.6GB(片面)
1.37MB/s の n 倍
5.2GB(両面)
ORB
2.2GB
12.2MB/s
高価
34
一度だけ書き込むことができる光ディスクメディアの総称。CD-R や DVD-R などの追記型
光ディスクがこれに該当する。
Copyright © 2003 IPA, All Rights Reserved.
3-18
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
表 3-3 テープ媒体
媒体種類
記憶容量
転送速度
DAT
2GB(DSS-1)/4GB(DSS-2)
12GB(DSS-3)/24GB(DSS-4)
150KB/s∼500KB/s
8mm
7GB
250KB/s∼500KB/s
DLT
35GB
1.5MB/s∼
AIT
25GB∼100GB
∼12MB/s
LTO
100GB
20MB/s∼
Super DLT
110GB
11MB/s∼
3.4.3
価格
安価
高価
バックアップ媒体の選択
バックアップ媒体の種類は、下記の点を考慮して選択する。
容量
転送速度
世代管理
本数
第一に、対象データ量を見積もることが必要である。媒体容量は、通常、バックア
ップ対象のデータの4倍以上を目安にする。もちろん1本の媒体でまかなえるとは限ら
ないので、ライブラリ製品を使うのが一般的である。
第二に、バックアップに要する時間を見積もる必要がある。通常は夜間にバックア
ップすることになるので、それに見合った転送速度のものを選べばよい。データ量と
見比べて、時間内にバックアップ可能なタイプを選ぶことになる。
第三に、世代管理のローテーションを考慮する必要がある。これまでの資産を有効
に活用できることも重要なポイントである。通常は各規格ともに下位互換性を持って
いるのでほとんどは問題がないものの、場合によってはリードができてもライトがで
きないこともあるので、機器ベンダに確認が必要である。
第四に、テープ媒体の大きさや本数についても計算する必要がある。これは収納ス
ペース、テープコスト、対応ライブラリに関係する。DLTとLTOはほぼ同じだが、AIT
はコンパクトであり、専用のライブラリもコンパクトである。アーカイブとしてテー
プを保管する場合でも省スペース性は有利である。
Copyright © 2003 IPA, All Rights Reserved.
3-19
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.4.4
テープRAID
テープRAIDとは複数のテープ装置を使ってRAID構成を組む技術である。信頼性が高
いためバックアップで用いられているテープドライブだが、テープ自体も破損が起こ
りうる。バックアップデータの消失という事態を避けるため、最近ではテープドライ
ブ同士でRAID構成を行う「テープRAID」と呼ばれる機能が使われ始めた。RAIT
(Redundant Array of Independent Tape drives)と呼ばれることもある。構成はハードデ
ィスクのRAIDとまったく同じで、2台のドライブでデータをミラーリングするRAIDレ
ベル1や、各ドライブにパリティビットを書き込むRAIDレベル5などがある。
3.4.5
テープライブラリ
バックアップ媒体・装置選択の重要なポイントは以下の3点である。
大容量
高速データ転送
高信頼性
媒体が大容量であれば、媒体交換作業や管理から解放される。また、高速データ転
送は、バックアップ時間の短縮化や迅速なデータ復旧に不可欠な要素である。高信頼
であれば、データを安全に保護することができ、管理も容易になる。これらの3要素に
対応できるのがテープライブラリである。テープライブラリとは、テープドライブを
複数台搭載し、数十巻以上のテープメディアを収納できる装置である。
テープライブラリ製品には、異機種ドライブの混在搭載機能、バックアップ稼働中
にもカートリッジの出し入れが可能なノンストップ・メディア交換機能、ロボット・
メカニズムの高速性・信頼性・耐久性、メディア検索能力などがある。複数サーバー
からの同時アクセスやドライブの共有に柔軟に対応できるのもライブラリの最大のメ
リットである。表 3-4にオートローダーとライブラリの比較を示す。
テープライブラリの選択では、2∼3年先の運用形態を視野に入れたパフォーマンス
と容量を考慮することが必要である。つまり将来のビジネスの発展と組織変更に柔軟
に対応できるような機能を備えている機種がよい。
表 3-4
比較項目
運用の容易性
オートローダーとライブラリの比較
オートローダー
ライブラリ
中小規模のシステムで1週間の運用サ
イクルが限界。運用容量を越えた場
合、人手による媒体交換や管理が必
要。
中規模のシステムで最低1ヶ月以上の
運用が可能。媒体のローテーションに
より年単位の世代管理も可能。複雑な
世代管理にも対応。容量に余裕を持た
せれば完全自動運用によるメディア
Copyright © 2003 IPA, All Rights Reserved.
3-20
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
比較項目
オートローダー
ライブラリ
管理が可能。
高速性
ドライブを1台しか搭載していないた
め、ドライブのスピードに依存。
複数ドライブによる並列処理による
スピードアップ可能。
記憶容量
搭載できるカートリッジは5から10巻
程度。
ネットワークの規模や必要に応じて
大容量も可能。
拡張性
人手によるメディア交換・管理、また
はオートローダーの追加が必要。
スロット増設、ドライブ増設による拡
張が可能。
共用利用・運
用管理
サーバー毎に接続。サーバー毎に運用
管理が発生。
SAN接続により、複数サーバーからの
共有可能。バックアップとリストアの
同時実行やバックアップの二重化に
も対応。
リストア性能
メディア内部に記録されたインデッ
クスをサーチするため、メディア認識
に時間が必要。
媒体のバーコード・ラベルでメディア
認識とリストアも可能。
3.4.6
ディザスタリカバリ
ディザスタリカバリは、災害からの復旧でハードディスク等のクラッシュや人的操
作ミスによって稼働しなくなったシステムを元に短時間で復旧することを目的とした
機能である。ディザスタリカバリでは、ハードディスクのブート情報やディスクイメ
ージをブート用のフロッピーディスクとバックアップ媒体に書き込み、クラッシュ時
にはそれらを使いOS、設定、アプリケーション、データまで一気にバックアップ取得
時の状態に復旧する(図 3-6)。最近ではテープドライブを仮想的にCD-ROMドライブ
に見せることで、ボタン1つでOSからデータのリストアまで1本のテープ媒体で行える
便利な機能もある。
ディザスタリカバリを確実に行うため、あらかじめ実験を行うべきである。
復旧ディスク
フルバックアップ
テープ
クラッシュした
サーバー
リモートサーバー
システムの復旧
OS・環境の復旧
テープドライブ
データのリストア
図 3-6 ディザスタリカバリ
Copyright © 2003 IPA, All Rights Reserved.
3-21
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.4.7
オフサイトバックアップ
バックアップ媒体をオフサイト(遠隔地)に保管することをオフサイトバックアッ
プという。オフサイトバックアップを行うには媒体を人手で遠隔地に送ってもよいし、
データを遠隔地まで転送してもよい。オフサイトバックアップは以下の点で重要であ
る。
データ損失の被害を抑えることができ、業務停止から早急な業務再開が可能に
なる。
最新データからの復旧が可能であり、再入力の膨大な時間と人的労力を回避で
きる。
オフサイトバックアップは重要なデータでは必須である。
3.5 高度なバックアップ技術
単にディスクの内容を他に書き出すだけなら、tarコマンドやntbackupコマンドでもよ
い。しかし、多くのサーバーの内容を毎日、人手に頼ってバックアップするのは現実
的でない。複数台のサーバーの内容を、自動的にスケジュールしてバックアップする
仕組みが必要である。システムによりバックアップが必要となるサーバーの数は2∼3
台レベルから数百、数千台までさまざまである。それらのデータをバックアップする
にはオンラインでバックアップを簡単に実行できるバックアップツールが重要であ
る。NASやSANを使って合理的なストレージ管理を行う場合にも、バックアップツー
ルはなくてはならない。
以下、下記のバックアップツールを紹介していく。
スナップショット
オンラインバックアップ
オンライン・アーカイブ
階層型ストレージ管理
ネットワークバックアップ
サーバーレスバックアップとリストア
同期リモートコピー
レプリケーション
Copyright © 2003 IPA, All Rights Reserved.
3-22
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
3.5.1
スナップショット
スナップショットとは、従来のバックアップとは異なり、システムに影響を与える
ことなく、ある状態にあるテーブルおよびそのサブセットのコピーを作成することで
ある。プライマリデータサーバーで生成されるスナップショットをレプリカ側に一定
間隔で送信することでレプリケーションを行う。また、必要な場合にデータをリスト
アする機能を提供する。
スナップショットを利用したバックアップ手順は次のとおりである。
① サーバーにコマンドを送り、バックアップを知らせる。
② サーバーがこの信号を受信すると、アプリケーションが処理を中断する。
③ 未処理のトランザクションがすべて完了するように、ファイルシステムをフラッシ
ュする。(データを書き出す)
④ スナップショットの作成を開始する。
⑤ スナップショットが終了すると、アプリケーションが解放され、通常の処理を再開
する。
⑥ このスナップショットを使用して、データ配置のマップを作成する。
⑦ このマップを利用してデータをディスクまたはテープにバックアップする。
スナップショットには3種類の形式がある。
ハードウェアスナップショット(前述のRAID、ミラーリング)
ソフトウェアスナップショット(後述のオンラインバックアップ)
SANでのスナップショット(後述のサーバーレスバックアップ、サーバーフリ
ーバックアップとも言う)
ハードウェアバックアップやSANでのスナップショットはボリュームレベルのスナ
ップショットである。スナップショット実行中にCPUオーバーヘッドはない。一方、ソ
フトウェアスナップショットは、ファイルレベルでのスナップショットである。サー
バーのCPUを利用するのでサーバーに負荷がかかる。
スナップショットの利点をまとめると以下のようになる。
ゼロ ダウンタイム バックアップ
リストア パフォーマンスの向上
サーバーフリー バックアップ
バックアップを業務中に実行しながら、ホストサーバーへの負荷をゼロにする。こ
れにより、バックアップウィンドウ(バックアップのためにサーバーをダウンさせる
時間)がなくなり、24時間365日のビジネスが可能になる。リストアでは、最新のデー
Copyright © 2003 IPA, All Rights Reserved.
3-23
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
タをリストアでき、遅延もなくなる。アプリケーションサーバーへのCPUやI/Oの負荷
がない。
また、スナップショットの欠点は以下のとおりである。
障害が起きた場合にトランザクションの整合性が保証されない。
プライマリ側の変更が多い場合、ネットワーク負荷が増大し転送のパフォーマ
ンスを劣化させる。
レプリカ側ではそのコピーを読み取り専用でしか使用できない。
3.5.2
オンラインバックアップ
オンラインバックアップ35とはデータベースを止めずにバックアップする機能であ
る。現在ではRDBMSとグループウェアなどにオンラインバックアップの機能がある。
RDBMSやグループウェアのサーバーにバックアップエージェントを導入する。バック
アップサーバーとバックアップエージェントが連携することで、稼働中のサーバーで
もバックアップを取ることができる。一方、オンラインバックアップ中はトランザク
ション処理の性能が落ちる。
3.5.3
オンライン・アーカイブ
データのアーカイブは監査やデータの分析に使用される。特に、インターネット取
引などでは、このデータのアーカイブが重要視されてきている。このアーカイブを自
動化したものがオンライン・アーカイブ機能である。オンライン・アーカイブでは、
面倒な手動によるテープへのアーカイブ処理が不要である。また、アーカイブされた
データへの高速なアクセスも可能である。
オンライン・アーカイブを用いると、電子メールのアーカイブも可能である。電子
メールを、添付ファイルの有無にかかわらず、アーカイブ・ストレージに自動的に移
行できる。自動移行は管理者が定義したポリシーに基づいて管理され、アーカイブさ
れた電子メールはユーザのメールボックスから容易に検索できる。
3.5.4 階層型ストレージ管理(HSM:Hierarchical Storage
Management)
HSMはストレージを階層毎に分けて管理する仕組みである。サーバー上のハードデ
ィスクを一次媒体といい、バックアップメディアを二次媒体という。この一次媒体と
35
オンラインバックアップの意味として、オンライン(インターネット)上のストレージ
にバックアップを行う、という意味に用いられる場合もある。
Copyright © 2003 IPA, All Rights Reserved.
3-24
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
二次媒体との間に仮想ファイルシステムを作ったものがHSMである。これにより、頻
繁にアクセスされるファイルを一次媒体に置いておき、あまりアクセスされないファ
イルを二次媒体に移動させるといった一連の処理が自動化できる。一次媒体からあふ
れたデータを二次媒体に自動的に振り分けることで、限られた一次媒体を有効活用す
ることが可能になる。複数のテープを収容するライブラリなどと併用することでユー
ザからも一次・二次媒体を意識することなく、透過的にファイルを扱うことができる
ようになる。2階層のみならず4階層程度まで扱える製品も多い。
3.5.5
ネットワークバックアップ
複数サーバーのバックアップを考えた場合、サーバー毎にテープドライブを購入す
るのは高価であるし、テープドライブをいちいち付け替えてバックアップするのは非
効率である。そのため複数サーバーでバックアップ装置を共有する必要が出てくる。
この手段としてネットワークバックアップがある。
バックアップすべきデータを保持しているサーバーをバックアップクライアントと
呼ぶ。バックアップクライアント上にエージェントソフトウェアを導入し、バックア
ップサーバー1台で集中してバックアップを行う(図 3-7)。バックアップクライアン
ト毎にバックアップの設定を分ける、アクセス頻度の高いデータを切り分けてバック
アップする、といったことも行うことができる。
バックアップ
サーバー
テープドライブ
LAN
バックアップクライアント
図 3-7 ネットワークバックアップ
一方、ネットワークバックアップでは、バックアップのデータ転送でLANを利用す
るため、ネットワークの負荷は避けられない。大容量のバックアップの場合、100Mbps
でも帯域は足りない。こういう現状から通常バックアップ作業は夜間や休日に作業を
行われている。インターネットからのアクセスのセグメントとバックアップのセグメ
Copyright © 2003 IPA, All Rights Reserved.
3-25
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
ントをスイッチなどで分ける(図 3-8)、または、ネットワーク自体を強化する方法は
あるが、一般的には、SANのようなストレージ専用のネットワークを設ける方が効果
的である。
バックアップ専用
ネットワーク
テープドライブ
バックアップ
サーバー
インターネット接続
図 3-8 バックアップ専用ネットワーク
3.5.6
サーバーレスバックアップとリストア
サーバーレスバックアップでは、ディスク デバイスとバックアップ媒体間にて直接
データを転送する。これにより、迅速なバックアップを実現でき、アプリケーション
サーバーやストレージシステムに、データバックアップ処理の負荷をかけない。これ
は、SAN内であらかじめ、正副のディスクを持ち、正をサーバーからのアクセスに利
用する。このデータは副にミラーしておき、バックアップは副から行うというもので
ある。上位ホスト側から、両ディスクのデータ内容の同期、ペアの解除、再同期など
をコントロールする。実際には、バックアップの採取のタイミングで同期を合わせ、
終わったらペアを解除し、バックアップした側からテープに落とす。ペアを解除する
ことによりサービス側とバックアップ側が切り離されそれぞれの負荷が影響しなくな
ることと、ディスク上のデータが更新されることはないのでゆっくりテープに落とす
ことができる。その間、サービスの停止や、バックアップモードの縮退運転を行わな
くても良いという点が最大の特徴である(図 3-9)。
Copyright © 2003 IPA, All Rights Reserved.
3-26
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
アプリケーション
サーバー
テープドライブ
アクセス
SAN
バックアップ
ディスク
正
副
ミラーリング
図 3-9 サーバーレスバックアップ
3.5.7
同期リモートコピー
SANでは、ファイバーチャネル・インタフェースで接続されたディスクサブシステ
ム中のLU間の同期を取ることができる、同期リモートコピー機能を持つソフトウェア
がある。データベースアクセスに対して2つのディスクサブシステム内に同期データを
持ち、一方のディスクサブシステムの障害時にはもう一方のサイトにあるサーバーや
ディスクサブシステムに切り替えが可能である。図 3-10や図 3-11のような形態で実現
可能である。
このSANの機能は、インターネットサーバーの広域分散にも利用できる。しかし、
地震など災害によっては、被害が数十Km∼数百Kmにも及ぶ場合もある。最近ではフ
ァイバーチャネルとギガビット・イーサネットを利用し、東京−大阪間(ファイバー
全長 約800Km)にて遠隔ストレージ間のデータ伝送の実証実験が行われており、実用
レベルになっているが、コストが課題となっている。
Copyright © 2003 IPA, All Rights Reserved.
3-27
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
リモートサイト
メインサイト
サーバーA
サーバーB
WAN・LAN
SAN
メイン装置
リモート装置
障害発生
正 Vol
切り替え
副 Vol
同期リモートコピー
図 3-10 同期リモートコピー機能(SAN 接続)
リモートサイト
メインサイト
サーバーA
サーバーB
LAN
FC
メイン装置
リモート装置
障害発生
正 Vol
切り替え
副 Vol
同期リモートコピー
図 3-11 同期リモートコピー機能(サーバー直結)
3.5.8
レプリケーション
レプリケーション36とは、各拠点のデータベース間でデータの同期を取る機能である
(図 3-12)。これにより、各サイトからデータベースを利用できるようにする。主要
36
レプリケーションは用語として RDBMS のような特定システムに依存した形以外で述べ
られる場合もある。
Copyright © 2003 IPA, All Rights Reserved.
3-28
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
なRDBMSはレプリケーションの機能を持っている。障害時に自動的に復旧作業を行う
リカバリ機能も持っている。レプリケーションは、以下の点でクラスタリングと異な
っている。
サーバー間の接続が専用回線ではなくWAN回線などの利用を想定している。
本稼働しているサーバー上のデータを同期する。
OSのフェイルオーバーの機能を持たない。
クライアント
レプリケーション
クライアント
図 3-12 レプリケーション
ミラーリングとレプリケーションの違いは、ミラーリングは二重化した正と副のデ
ィスクを同時に更新するのに対し、レプリケーションは二重化した正のディスクのみ
を更新し、ある一定間隔で副のディスクを更新する点である。レプリケーションの構
築運用方法はDBMS(DataBase Management System)製品によって異なる。
3.6 参考資料
本章での参考資料は以下である。
株式会社日立製作所,http://www.str.hitachi.co.jp/index.html
イーエムシー ジャパン株式会社,http://japan.emc.com/index.jsp
日本アイ・ビー・エム株式会社,http://www-6.ibm.com/jp/storage/
日本ヒューレット・パッカード株式会社,http://www.jpn.hp.com/products/storage/index.html
日本ネットワーク・アプライアンス株式会社,http://www-jp.netapp.com/
データコア,http://japan.datacore.com/
株式会社ニューテック,http://www.newtech.co.jp/
株式会社ウィンドウ,http://www.window.co.jp/
ノックス株式会社,http://www.nox.co.jp/
マイクロテクノロジー株式会社,http://www.microtec.co.jp/index.html
Copyright © 2003 IPA, All Rights Reserved.
3-29
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
3 ストレージのハイアベイラビリティ技術
株式会社サイバネテック,http://www.cybernetech.co.jp/
株式会社アイ・エイ・アイ,http://www.iai-usa.co.jp/index.html
株式会社 コムテックス,http://www.comtecs.co.jp/
日本ストレージ・テクノロジー株式会社,http://www.storagetek.co.jp/
デジタルテクノロジー株式会社,http://www.dtc.co.jp/
日商エレクトロニクス,http://www.nissho-ele.co.jp/index1.html
デルコンピュータ株式会社,http://www.dell.com/jp/jp/gen/default.htm
株式会社ビジュアル・プロセッシング・ジャパン,http://www.vpj.co.jp/
ベリタスソフトウェア株式会社,http://www.veritas.com/jp/
Computer Associates International, Inc.,http://www.caj.co.jp/
バックボーン・ソフトウエア株式会社,http://www.bakbone.co.jp/
IBM Tivoli Storage Manager,http://www.tivoli.com/
アルファテック・ソリューションズ株式会社,http://www.alphatec-sol.co.jp/
キーマンズネット ストレージ管理ソフト 基礎講座 Page. 1,
http://www.keyman.or.jp/search/30000023_1.html
キーマンズネット ストレージ管理ソフト 基礎講座 Page.2,
http://www.keyman.or.jp/search/30000023_2.html
キーマンズネット よくわかるバックアップツール,
http://www.keyman.or.jp/search/robo_backup_1.html
@IT 光ディスクとテープ・バックアップ規格が分かるキーワード 2002/09/11,
http://www.atmarkit.co.jp/fsys/keyword/003backup/003backup02.html
BUSINESS CENTER / 特集 2000年1月号,2000年のストレージ技術のすべて,
http://biz.ascii24.com/biz/sp/article/2000/01/11/354752-006.html,
http://biz.ascii24.com/biz/sp/article/2000/01/11/354752-007.html
情報通信事典 e-words,http://e-words.jp/w/RDBMS.html
日経オープンシステムズ,2002.1月号,トラブル110番
日経オープンシステムズ,2002.1月号,データベース・トラブル10選 第5回 バックアップのトラブルを回避する
日経オープンシステムズ,2002.3月号,オープンレポート 解説 SANが抱える4つの弱点と、補完製品の実力
日経オープンシステムズ,2002.11月号,活用&選択 SAN(Storage Area Network)
日経インターネットソリューションズ,2003.2月号,特集 バックアップを見直す
日経インターネットソリューションズ,2002.11月号,ビジネスの継続性とTCOの削除に貢献する 最新ストレー
ジ・ソリューションズ
日経ネットワーク,2003.2月号,ディザスタ・リカバリーセミナー報告
日経ネットワーク,2002.12月号,ストレージ・ネットワーキング
日経ネットワーク,2002.6月号,ネットワーク&サーバー強化作戦
日経コミュニケーションズ,2002.5.6号,活気づく遠隔ストレージ接続
Copyright © 2003 IPA, All Rights Reserved.
3-30
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
4 サービス妨害攻撃
本章では、最初にサービス妨害を分類した後、対策を紹介する。最後に、補足のた
め、サービス妨害攻撃の詳細を説明する。
4.1 サービス妨害攻撃の分類
まず、サービス妨害攻撃の性質を考えるため、分類を考えてみる。サービス妨害攻
撃は
包括的DoS攻撃(帯域幅消費、リソース枯渇化)
システム欠陥利用型DoS攻撃
などに分類できる。
包括的DoS攻撃とは、ネットワークの負荷を増大させ、処理できなくする、または、
CPUやディスクといったリソースを枯渇化させる攻撃である。
一方、システム欠陥利用型DoS攻撃とは、ハードウェア、OSやアプリケーション、
ネットワーク、ストレージの脆弱性を狙い、システムを停止させるような攻撃である。
それぞれの分類での攻撃を説明していく(図 4-1)。
Copyright © 2003 IPA, All Rights Reserved.
4-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
インターネット
ISP1
ISP2
ISP
帯域幅消費型 DoS 攻撃
通信帯域幅
サイト
ルータ
ロードバランサー
ネットワークの脆弱性を
利用した攻撃
ファイアウォール
DNS
リソースの枯渇化型 DoS 攻撃
ロードバランサー
NIC および回線
ストレージ
ハードウェアの脆弱性を
利用した攻撃
インターネットサーバー
OS やアプリケーションの
脆弱性を利用した攻撃
ストレージの脆弱性を
利用した攻撃
ログを利用した DoS 攻撃
図 4-1 サービス妨害攻撃の分類
4.1.1
包括的DoS攻撃
一般に包括的DoS攻撃は、
帯域幅消費型DoS攻撃
リソース枯渇型DoS攻撃
などに分類できる。
包括的DoS攻撃に共通の要素はプロトコルの操作である。ICMPなどのプロトコルを
不当な目的で操作すると、多くのシステムに同時に悪影響を及ぼすことができる。攻
撃者が電子メール爆弾を使用すれば、何千件もの電子メールメッセージを特定の被害
者システムに送信することができ、帯域幅を消費したり、メールサーバーのシステム
Copyright © 2003 IPA, All Rights Reserved.
4-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
リソースを消耗させたりする。Melissaウイルス(ワーム)はDoS攻撃を意図したもので
はなかったが、電子メールメッセージを波のように発生させ、その結果メールサーバ
ーを突然停止させてしまった。このウイルスは大量に複製されたため、リソース不足
によりメールサーバーが簡単に停止してしまった。
では、この帯域幅消費型DoS攻撃とリソース枯渇型DoS攻撃について説明する。
4.1.1.1 帯域幅消費型DoS攻撃
DoS攻撃の中で、最も危険なのが帯域幅消費型の攻撃である。攻撃者は、特定のネッ
トワークで利用できるすべての帯域幅を消費する。リモートから攻撃する形が最も多
い。
攻撃者はサイトへ不正なリクエストを大量に送付する。それに対し、DNSサーバー
やファイアウォールなどが応答を返すのだが、その応答により、通信回線が飽和し、
その他のサービス、例えばWebサーバーへのアクセスが妨害される。
ISP間の回線をまたがったDoS攻撃は比較的検知されやすい。検知されにくいために
問題となるのがISPのネットワーク内でのDoS攻撃である。
DoS攻撃ではネットワークプロトコルの脆弱性やネットワーク機器やOSの脆弱性が
利用される。
ICMP、ブロードキャストを悪用する。
トラフィックの送信元(ソースアドレス)を偽る。(スプーフィング)
受信側OSのIPスタックに関する脆弱性を利用する。
表 4-1
主な帯域幅消費型 DoS 攻撃の概要
攻撃
Smurf 攻撃、Fraggle 攻撃
攻撃のポイント
ICMP、ブロードキャスト、スプーフィングを組み合わせ
た攻撃
TCP SYN フラッド攻撃
受信側 OS の IP スタックに関する脆弱性を利用する
帯域幅消費型DoS攻撃は次の2つに分類できる。
直接のDoS攻撃
DDoS攻撃(踏み台(バウンスサイト)を利用したDoS攻撃)
この2つの攻撃をさらに説明する。
Copyright © 2003 IPA, All Rights Reserved.
4-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
(1)
直接の DoS 攻撃
第一のタイプは、直接のDoS攻撃である。攻撃者の方が利用できる帯域幅が広い場合、
攻撃者は被害者ネットワークの帯域幅を使い切ってしまうことができる。例えば、ネ
ットワーク接続の速度がT1(1.544Mbps)以上の攻撃者であれば、56Kbpsまたは128Kbps
のネットワークを攻撃するシナリオが考えられる。この種の攻撃は低速のネットワー
ク接続に限られているわけではない。利用可能な帯域幅が100Mbpsを超えるネットワー
クが攻撃されたケースも実際にある。
(2)
DDoS 攻撃
第二のタイプは、DDoS攻撃である。DDoS攻撃では、攻撃者が複数のサイトを利用
してDoS攻撃を増幅させることで、被害者ネットワークの帯域幅を使い切ってしまう。
ネットワークリンクが56Kbps程度の攻撃者でも、他のサイトを利用してDoS攻撃を増幅
させ、100Mbpsの帯域幅を作り出し、T3(45Mbps)アクセスが可能なネットワークを
完全に飽和させることができる。
DDoS攻撃が大量に出てきたのは2000年2月である。最初はYahooを対象にして仕掛け
られ、次にE*TRADE、eBay、buy.com、CNN.comなどに移り、その後無数のサイトに
対して行われた。
DDoS攻撃は通常次のステップで行われる。
攻撃者は、できるだけ多くのサーバーを狙って侵入を試みる。
攻撃者はシステムへの侵入が成功すれば、DDoSソフトウェアを仕掛け、このソ
フトウェアを走らせる。
ソフトウェアは攻撃者から命令が来たら一斉に攻撃を始める。
4.1.1.2 リソース枯渇型DoS攻撃
リソース枯渇型DoS攻撃は帯域幅消費型DoS攻撃と異なり、ネットワークリソースで
はなくシステムリソースを消費する。一般に、リソース枯渇型DoS攻撃では、CPUの稼
働率、メモリ、ファイルシステムの割り当て、その他のシステムプロセスといったシ
ステムリソースが消費される。リソース枯渇型DoS攻撃があるとリソースが使用できな
くなる。システムはクラッシュしたり、ファイルシステムが満杯になったり、各プロ
セスがハングアップしたりしてしまう。
4.1.2
システム欠陥利用型DoS攻撃
システムの欠陥を狙った種類のサービス妨害攻撃は、攻撃を受ける部分で、以下の
ように分類できる。
Copyright © 2003 IPA, All Rights Reserved.
4-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
ハードウェア
OS、アプリケーション
ネットワーク
ログ
ストレージ
4.1.2.1 ハードウェアの脆弱性を利用した攻撃
ハードウェアの脆弱性を利用した攻撃は、CPU、ネットワークインタフェースカード
(NIC)などのハードウェアに特有な脆弱性を利用して、OS、アプリケーションをダ
ウンさせたり、ハードウェアを故障させたりするような攻撃である。
DoS攻撃の大半は、特定のベンダのIPスタック実装とプログラミング脆弱性に関連し
ている。攻撃の大半は、特定のパケットまたはパケットシーケンスをターゲットシス
テムに送信することで、特定のプログラミングの欠陥を見つける。ターゲットシステ
ムがこれらのパケットを受信した結果、
パケットを正常に処理できない。
システム全体がクラッシュする。
などが起きる。
特定のハードウェアの不具合や特性を利用した攻撃がある。このような攻撃の手口
は、以下のものがある。
CPUのアーキテクチャ(種類)によりバッファオーバランを起こす命令パターン
をトロイの木馬などに忍び込ませ、バッファオーバーフローを起こさせる。(カ
ーネルパニック攻撃)
特定のビットパターンを送りつけることにより、ネットワークインタフェース
カードを故障させる。
メモリの書き込み回数、バスクロック特性などを利用し、ハードウェアを故障
させる。
この中で、最も一般的なカーネルパニック攻撃を説明する。
CPUアーキテクチャの欠陥利用とは、アプリケーション、OS、埋め込み型ロジック
チップなどが例外状態に対処できないことを悪用した攻撃を言う。OSのカーネルがパ
ニックに陥るので、カーネルパニック攻撃と呼ばれる。
一般に、ターゲットシステムに対して意図しないデータを送信するとこうした例外
状態が発生する。この攻撃には、下記のような種類がある。
不正パケット送信
Copyright © 2003 IPA, All Rights Reserved.
4-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
大量データ送信(バッファオーバーフローを起こさせるため)
特権コマンドの実行
4.1.2.2 OSやアプリケーションの脆弱性を利用した攻撃
UNIXシステムやWindows NTシステムに対して何百ものローカルDoS攻撃の方法が
存在する。4章の後半では、Windows NTとUNIXのそれぞれに対応する代表的なプログ
ラミング欠陥攻撃を取りあげる。
4.1.2.3 ネットワークの脆弱性を利用した攻撃
ネットワークの脆弱性を利用した攻撃には、ネットワーク通信を混乱させるような
攻撃などがある。ネットワークプロトコルの脆弱性やネットワーク機器やOSの脆弱性
が利用される。
受信側OSのIPスタックに関する脆弱性を利用する。
DNS(送信先のIPアドレス)を操作して、通信を妨害する。
ルーティングプロトコルを操作して、通信を妨害する。
ICMPを悪用して、通信を妨害する。
これらを簡単に説明する。
表 4-2
主な DoS 攻撃の概要
攻撃
TCP SYN フラッド攻撃
攻撃のポイント
受信側 OS の IP スタックに関する脆弱性を利用する。
Teardrop 攻撃、Land 攻撃
DNS に対する DoS 攻撃
DNS(送信先の IP アドレス)を操作して、通信を妨害
する。
ルーティングプロトコルを利用 ルーティングプロトコルを操作して、通信を妨害する。
した DoS 攻撃
ICMP リダイレクトを利用した ICMP リダイレクトを利用して、通信を妨害する。
DoS 攻撃
4.1.2.4 ストレージの脆弱性を利用した攻撃
ストレージの脆弱性を利用した攻撃には、以下がある。
① RAID コントローラの特性を利用し、RAID を故障させる。
② 大量のデータを書き込む。(バッファオーバーフロー攻撃)
Copyright © 2003 IPA, All Rights Reserved.
4-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
③ ディスク割当量に関する脆弱性を悪用する。
4.2 対策
本節では、前節で分類したサービス妨害攻撃に関する対策を説明する。図 4-2にサー
ビス妨害攻撃への対策項目と、対策箇所の概要図を示す。
インターネット
ISP1
DDoS 攻撃の予防
ISP2
ISP
通信帯域幅
サイト
ルータ
Smurf 攻撃と Fraggle 攻撃に
関する対策
ロードバランサー
DNS に対する DoS 攻撃に
関する対策
ファイアウォール
DNS
DDoS 攻撃の検出
ロードバランサー
TCP SYN フラッド攻撃の
対策
NIC および回線
ストレージ
インターネットサーバー
カーネルパニック攻撃に
関する対策
ログを利用した DoS 攻撃に
関する対策
ディスク割当量に関する
脆弱性を悪用した攻撃に
関する対策
図 4-2 サービス妨害攻撃の対策
Copyright © 2003 IPA, All Rights Reserved.
4-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
4.2.1
リソース枯渇型DoS攻撃の対策
4.2.1.1 DDoS攻撃の予防
自分のシステムが踏み台として使用されないようにするための最善の防御方法は、
第一に自分のシステムが侵入されないようにすることである。
ICMPでTFN攻撃が発生するので、TFN攻撃に対する予防策には自分のネットワーク
に着信するすべてのICMPトラフィックをユーザが否認するようにするという方法もあ
る。
ユーザはTFN攻撃から自分のシステムを守るため、ISPとのボーダールータで「レー
トフィルタリング」のようなものを使用する。(例えば、ICMP攻撃を制限するICMP
レートフィルタリング)また、TCP SYNフラッド攻撃のリスクを避けるため、スイッ
チなどでアクセス制御を行うこともできる。
4.2.1.2 DDoS攻撃の検出
TFN攻撃他のDDoS攻撃に対しては検出メカニズムが多く存在している。例えば、コ
ネクションの状態やサーバー負荷状態を監視することで検出する。IDSで検出できる攻
撃と検出できない攻撃がある。
WinTrinoo(またはWinTrin00)攻撃では、手動検出の他に、ウイルス防止プログラム
で検出することもできる。ウイルス防止ではこのファイルが実行する前に自動的に隔
離されるようになっている。
4.2.1.3 Smurf攻撃とFraggle攻撃に関する対策
バウンスサイトとして使用されないようにするため、指定ブロードキャストの機能
はユーザのボーダールータで使用不可能にする必要がある。
また、各OSを構成変更すれば、ブロードキャストICMPのECHOパケットを破棄する
こともできる。RFCでは、クライアントは、ブロードキャストICMPのECHOに対して
返答はしなくてよい。
ボーダールータに着信するICMPトラフィックとUDPトラフィックを制限することも
有効な対策である。対象を自分のネットワークで必要なシステムのみと特定の種類の
ICMPのみに限定する。もちろん、こうしてもSmurf攻撃やFraggle攻撃の発生時に自分
の帯域幅を消費することを防ぐことはできない。
さらにISPで攻撃を遮断するような対処ができればよりよい。ボーダールータでICMP
トラフィックを制限する(例えば256Kや512Kに)のも有効である。
Copyright © 2003 IPA, All Rights Reserved.
4-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
万一自分のサイトが攻撃を受けた場合は、まず自分の接続するISPに連絡する。攻撃
者を追跡することは非常に難しいが、それが可能な場合もある。
バウンスサイトから始めて上流に上りながらそれぞれのルータを系統的に調べてい
くと、攻撃を追跡して攻撃側のネットワークを突き止めることが可能である。この場
合、スプーフされたパケットを受信したインタフェースを決定し、さらに上流を追跡
することになる。このプロセスを自動化したスクリプトが開発されている。このスク
リプトにより、ルータにログインし、スプーフされた攻撃を追跡して発生源を突き止
めることもできる。攻撃に関連する全ルータにアクセスできることが前提である。
4.2.1.4 TCP SYNフラッド攻撃の対策
TCP SYNフラッド攻撃には4種類の対策がある。
接続キューのサイズを増やす。
接続確立タイムアウト時間を短縮する。
ベンダのソフトウェアパッチを使ってTCP SYNフラッド攻撃を検出・回避する。
ネットワークのIDSを使用する。
接続キューのサイズを調整することで、TCP SYNフラッド攻撃の影響を緩和させる
ことができる。これは有効な方法ではあるが、最適の解決法とは言えない。システム
リソースを余分に必要とし、性能に影響を及ぼす。
接続確立タイムアウト時間を短縮しても、TCP SYNフラッド攻撃の影響を緩和させ
ることができる。これもやはり最適の解決法とは言えない。
最近のOSの大半はSYNフラッド攻撃の検出・予防機能を既に実装している。
ネット全体でTCP SYNフラッド攻撃が流行して以来、このDoS状態に対処するその他
の解決法も開発されてきた。最近のLinuxカーネル2.0.30以降では、
「SYNクッキー」
(暗
号を使った通信相手認証プロトコル)というオプションを採用している。このオプシ
ョンを使用可能状態にすると、可能性のあるTCP SYNフラッド攻撃をカーネルが検
出・記録するようになっている。たとえ攻撃が発生した場合でも、SYNクッキーを利
用して通信相手を認証し、接続処理を継続することができる。しかし、通信相手もサ
ポートする必要があり、あまり使われていない。
Windows NT(4.0 SP2以降)など、OSによっては対策ができているものもある。
ネットワーク対応のIDS製品には、TCP SYNフラッド攻撃を検出できるものもある。
TCP SYNフラッド攻撃は、SYNパケットのフラッドにより検出可能であり、後続の対
応が不要である。IDSは、最初のSYN要求に対応している攻撃対象システムに対してRST
Copyright © 2003 IPA, All Rights Reserved.
4-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
パケットを送信することができる。この処置により、攻撃対象システムが接続キュー
を緩和させることができることもある。
4.2.2
システムの欠陥を狙った攻撃に関する対策
4.2.2.1 ICMPリダイレクトを悪用した攻撃に関する対策
ICMPリダイレクトを悪用すると、ネットワークに侵入した攻撃者が、存在しないサ
ーバーや機器のアドレスへの転送を指示することができる。そうすると、クライアン
トからのリクエストがサーバーへ到達しなくなってしまう。
この対策として、ICMPリダイレクトを受け付けないようにサーバーや機器を設定す
ることもできる。しかし、そうするとサーバーや機器が故障した場合に、アクセスサ
ーバー経路の変更や他のインターネットサーバーへの転送をネットワーク経由で設定
できなくなってしまう。攻撃を受ける可能性と故障時の対処の容易性を比較して、対
策導入の是非を検討する必要がある。
4.2.2.2 カーネルパニック攻撃に関する対策
通常、カーネルパニック攻撃は新しいディスリビューションで解決される。つまり、
このような攻撃に関する対策としては、脆弱性情報をよくチェックし、必要なパッチ
をあてるなどが必要である。
4.2.2.3 ログを利用したDoS攻撃に関する対策
この攻撃の対策には、下記の対策が必要である。
ストレージがいっぱいになる前に十分なログ用のストレージを確保する。
攻撃を検知できるようにするため、ストレージの残量を監視する。
攻撃に遭う確率を減らすため、ストレージの量を推測されないようにする。
ログがいっぱいにならないように、またログを削除されないようにするため、
ログをログ専用サーバーへ転送する。この時ログを受け取るサーバーにおいて、
特定のサーバーからのログしか受け取らないように設定を施すことが望まし
い。
4.2.2.4 ディスク割当量に関する脆弱性を悪用した攻撃に関する対策
この対策としては、下記を行う。
Copyright © 2003 IPA, All Rights Reserved.
4-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
システムドライブは、ユーザがアクセスできるファイルが保存されているパー
ティションとは別のパーティションにする。
ブート処理をしないパーティションにプロファイルを配置し、必要な場合のみ
このプロファイルを使用する。
4.2.3
攻撃へのIDSによる対応
参考として、JNSA(日本ネットワークセキュリティ協会)では、2000年度にダイナ
ミックディフェンスWGにて、不正アクセスに対する直接的な対応(ダイナミックディ
フェンスと呼ぶ)を行う手段について議論されている。以下は、ダイナミックディフ
ェンスWGで作成された「ダイナミックディフェンスの概要と適用について」(2000年
12月29日)からの引用である。http://www.jnsa.org/active00_8.html
「現状のダイナミックディフェンスの対応についての分類」
現在一般的に利用することができるダイナミックディフェンスの対応部分は、以下のよう
なものがある。
共通
Host Base IDS
Network Base IDS
Store and Forward
***
単独 ・システムのシャットダ ・ログインセッションの ・セッションの強制終了 ・パケットドロップ
ウン
中断
・セッションの中断
・IPホッピング*
・アカウントの削除・停
止
・バナーの送出
・ファイルのライトバッ
ク
・プロセスの強制終了
・デコイ
連動 ・ルーティング情報の変 ・ソースアドレスのブロ ・ソースアドレスのブロ
更**
ック
ック
・ディストネーションア ・ディストネーションア
ドレスのブロック
ドレスのブロック
・ディストネーションポ ・ディストネーションポ
ートのブロック
ートのブロック
*IPホッピング:アタックを受けたIPアドレスの付け替え。
**ルーティング情報のコントロール:ルータ、L3スイッチ、L7スイッチなど。
***Store & Forward:ファイアウォールへのIDSの実装。
ダイナミックディフェンスの対応手法について
上記表に記載されている、ダイナミックディフェンスの対応手法を以下に記載する。
Copyright © 2003 IPA, All Rights Reserved.
4-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
システムのシャットダウン
不正アクセスの検出により、サーバのシャットダウンを行う事や、ファイアウォールや
ルータをシャットダウンすることで、ネットワークセグメント全体をシャットダウンする
手法が用いられることがある。
IPホッピング
ルータ、L3スイッチ、L7スイッチなどにより、ターゲットのIPを付け替えることにより、
不正アクセスに対処する手法。
バナー送出・デコイ
許可されていないポートへの接続に対し、警告文や偽のメッセージを送出する手法。こ
の手法は、アタッカーを混乱させることで、対処のための時間を稼ぐことや、不正アクセ
スの検知を容易にするために利用される。
ハニーポットと呼ばれる手法に近い考え方。
ルーティング情報の変更
RIPなどのルーティングプロトコルを使って、ルーティング情報を変更することで、不正
アクセスに対処する技法。
ログインセッションの中断
ログインの失敗が続いた際に、ログインのセッションを中止する手法。
IDSの機能というよりは、システム自身の機能であることが多い。
アカウントの停止
アカウントを停止することで、該当するアカウントを使ったログインができないように
する手法。
一般的には、上記「ログインセッションの中断」のタイミングで実施されることが多い。
ファイルのライトバック
ファイルの改ざんを検知した場合、バックアップのファイルを使って自動的に復旧を図
る手法。
プロセスの強制終了
不正なプロセスを強制終了させることで、不正アクセスに対処する手法。
この手法は、主にバックドアや、ワームに対する対処として想定されている。
セッションの強制終了
Copyright © 2003 IPA, All Rights Reserved.
4-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
不正アクセスのソースとターゲットに対して、リセットパケットを送出することにより、
TCPセッションの強制終了を行う手法。
ソースアドレスのブロック
ファイアウォールやルータなどの設定を変更して、不正アクセスのソースIPからのアク
セスを一定時間ブロックすることで不正アクセスに対処する手法。
ディストネーションアドレスのブロック
ファイアウォールやルータなどの設定を変更して、不正アクセスのディストネーション
(ターゲット)IPに対するアクセスを一定時間ブロックすることで不正アクセスに対処す
る手法。
ディストネーションポートのブロック
ファイアウォールやルータなどの設定を変更して、不正アクセスのターゲットとなって
いるポートに対するアクセスを一定時間ブロックすることで不正アクセスに対処する手
法。
パケットのドロップ
ファイアウォールやルータ等のStore & Forward型のデバイスにおいて、不正アクセスに
関係するパケットと判断した際に、パケットをForwardしないことで不正アクセスに対処す
る手法。
4.3 攻撃の詳細
4.3.1
リソース枯渇型攻撃の詳細
4.3.1.1 DoS攻撃
(1)
Smurf 攻撃
ICMPはネットワークの診断や管理を行うためのプロトコルである。しかし、ICMP
トラフィックは危険である。ICMPは、診断という重要な目的を果たす一方で、悪用さ
れやすく、帯域幅消費型DoS攻撃に利用されることもしばしばである。また、たいてい
の攻撃者はソースアドレスを勝手に変える(スプーフする)ため、真の攻撃者を突き
止めることが極めて困難である。
「Smurf」および「Fraggle」攻撃には、対象となる被害者の発信元アドレスであるか
のように偽装して、大量のICMP(Internet Control Message Protocol)ECHO(ping)メッ
セージをIPブロードキャストアドレスへ送信する。ネットワーク境界のルータが宛先ネ
Copyright © 2003 IPA, All Rights Reserved.
4-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
ットワークへのブロードキャスト中継(Directed broadcast)を有効にしていると、ルー
タは、宛先ネットワーク上の全ホストにパケットを送信する。その結果、ネットワー
ク・ホストは、ICMP ECHO要求を受け取り、ECHO応答する。応答するホストの数に
応じてこの応答のトラフィックが増える。これにより、ネットワークがトラフィック
で飽和し、通信ができなくなる。ネットワークによっては、何百というマシンが各パ
ケットに応答することも可能である。攻撃者は、増幅比が大きいバウンスネットワー
クを見つけることができれば、被害者のネットワークを飽和させられる。
Smurf攻撃は、その増幅効果が大きく、現存するDoS攻撃の中で最も恐ろしい。
(2)
Fraggle 攻撃
Smurf攻撃の変形に「Fraggle攻撃」がある。Fraggle攻撃は基本的にはSmurf攻撃と同
じであるが、ICMPの代りにUDPを使用する。攻撃者は、バウンスネットワークのブロ
ードキャストアドレスに対して、スプーフされたUDPパケットを送信することができ
る。ECHOを使用可能状態にしたネットワークでは、それぞれのシステムが被害者のホ
ストに応答してくるので、大量のトラフィックが発生する。バウンスネットワークに
常駐するシステムでECHOを使用可能状態にしていない場合は、到達不可能なICMPメ
ッセージを発生させるので、やはり帯域幅が消費される。
(3)
TCP SYN フラッド攻撃
Smurf攻撃が流行する以前は、現存するDoS攻撃の中で「SYNフラッド攻撃」が最大
の脅威であった。
TCP SYNフラッド攻撃は、TCP接続要求が、完了せずに、繰り返し送信される。これ
により、攻撃を受けるシステムでリソースが使い果たされ、サービス不能になる。
TCP SYNフラッド攻撃では、攻撃者はSYNパケットをシステムAからシステムBに送
信する。しかし、攻撃者は、実際に存在しないシステムのソースアドレスをスプーフ
する。このとき、システムBがスプーフされたアドレスに対してSYN/ACKパケットを
送信する。スプーフされたシステムが存在すると、このシステムは接続を起動してい
ないので、システムBに対してRSTパケットで応答するのが普通である。ただし、攻撃
者が選ぶのは到達できないシステムである。したがって、システムBはSYN/ACKパケ
ットを送信するが、システムAからRSTパケットを受け取ることはない。この潜在接続
は現在SYN_RECV状態にあるので、接続キューにつながれる。一般に接続キューは非
常に短いので、攻撃者は10秒毎にSYNパケットを数個分送信するだけで、特定のポー
トを完全に使用不能にすることができる。
ほんの少し帯域幅があれば、SYNフラッド攻撃をうまく起動できる。攻撃者には、
14.4Kbps以下のモデムリンクから極めて強力なサーバーを破壊することが可能である。
Copyright © 2003 IPA, All Rights Reserved.
4-14
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
次に、攻撃者はSYNパケットのソースアドレスはスプーフされているので、攻撃者を
特定することは困難である。
(4)
DNS の脆弱性を利用した DoS 攻撃
DNSは通信をするための基本的な仕組みである。TCP/IPでの通信はDNSに依存して
いる。しかし、このDNSに対する攻撃がある。DNSを攻撃されると最も被害が大きい。
サービス妨害攻撃では、DNSが攻撃の標的になりやすい。
DNSへの攻撃には、DNSに大量にトラフィックを送りつける方法と、偽り情報をDNS
に返答する方法がある。
これまでに発生したDNS対応のDoS攻撃には、長時間にわたり大規模のサイトをアク
セス不能にしたものもある。
DNSには他のDNSからの情報をキャッシュする際に情報の正確性を確認しないとい
う脆弱性がある。
DNSポイズニング(DNSスプーフィング)とは、特定のホストのアドレスと偽って
嘘のIPアドレス情報を渡し、本来の接続先に届くはずのトラフィックを偽のホストに導
くという攻撃である。
DNSサーバーは、DNSの問い合わせに対する応答を受け取る際、この応答の送信元
は検証していない。これらの弱点を利用し、有効な応答の内部に偽のDNS情報を隠し
て返送する。すると、この応答を受け取ったDNSサーバーは、有効な情報とともに、
偽の情報もキャッシュに保存する。
DNSは可用性を確保するため、通常、プライマリとセカンダリという2台のDNSで動
作する。その場合、セカンダリがプライマリから最新情報を得るため、ゾーン転送と
いう機能を利用する。しかし、そのゾーン転送機能が悪用され、偽りのプライマリか
らセカンダリが(偽り)情報を受け取ってしまう脆弱性がある。
BIND37(Berkeley Internet Name Domain)というDNSソフトウェアが最もよく使われ
ている。脆弱性があるBINDで再帰検索機能38を使用可能状態にすると、再帰検索を実
行するDNSが偽りのIPアドレス情報をキャッシュする可能性がある。この処理が、PTR
(Pointer)レコードスプーフィングとかDNSポイズニング、キャッシュポイズニングと
呼ばれている。
37
カリフォルニア大学バークレイ校(UCB)で Kevin Dunlap によって開発・実装されたド
メインネームシステム(DNS)サーバソフトウェア。ソースコードが無償公開されている
オープンソースソフトウェアであり、ほとんどの UNIX および UNIX 系 OS に移植され、標
準的に装備されている。
38
DNS サーバーでの、DNS データに対しての問い合わせを他の DNS サーバーに問い合わ
せる機能。
Copyright © 2003 IPA, All Rights Reserved.
4-15
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
例えば、攻撃者が、www.ipa.go.jpを0.0.0.99(偽りのIPアドレス)に変換するという
情報を脆弱なDNSのキャッシュに保存できたとする。クライアントがwww.ipa.go.jpにア
クセスする場合、このDNSは0.0.0.99をIPアドレスとして返す。そうすると、クライア
ントはwww.ipa.go.jpにアクセスできなくなる。
偽りのIPアドレスの他、偽りサーバーのアドレスが攻撃に使われる場合もある。
クライアントがIPアドレスに注意しない限り、他のサーバーにアクセスしていること
には気がつかないだろう。また、DNSキャッシュに長い有効期限や大きなシリアル番
号を設定されるといつまでも不正情報が残り、書き直されない。管理者がキャッシュ
を明示的に削除するしか対策はない。
4.3.1.2 DDoS攻撃
DDoSツールのコア部分とみなされるものを分類すると、TFN、Trinoo、Stacheldraht、
TFN2K、WinTrinooになる。ShaftやmStreamsなど、これ以外にもDDoSツールが発表さ
れているが、その原理は上記ツールと同じである。TFN、Trinoo、Stacheldraht、TFN2K、
WinTrinooとその対策を説明していく。
(1)
Tribe フラッドネットワーク(TFN)
TFNはMixterというハッカーが書いたもので、UNIX対応の分散型サービス拒否ツー
ル(SolarisコンピュータとRedHatコンピュータの大半に搭載されている)の中で最初に
公表されたものである。TFNでは、攻撃者はリモートシステムにサーバーをインストー
ルする。クライアント上でコマンドを使ってDDoS攻撃を仕掛けることができる。TFN
で利用できる攻撃の種類には、ICMP、Smurf、UDP、とSYNのフラッド攻撃などがある。
TFN他のDDoSに対しては検出メカニズムが多く存在している。Robin Keirの
DDOSPing(http://www.keir.net)、BindviewのRazorチームによるZombie Zapper
(http://razor.bindview.com)、米国インフラストラクチャ予防センター(NIPC)の
find_dDoS(http://www.nipc.gov)などがある。
(2)
Trinoo 攻撃
TFNと同様、Trinooの動作原理は、リモート制御プログラム(クライアント)がマス
タに話しかけるように命令し、マスタはデーモン(サーバー)に攻撃を指示する。ク
ライアントとマスタとの間のやり取りはTCPポートの27665で行い、通常
「betaalmostdone」というパスワードが必要である。マスタとサーバーとの間のやり取
りはUDPポートの27444で行う。サーバーからマスタへの返信は静的なUDPポートの
31335を経由するのが一般的である。
Copyright © 2003 IPA, All Rights Reserved.
4-16
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
TFN攻撃とTrinoo攻撃については、Dave Dittrichの分析結果がある。
http://staff.washington.edu/dittrich/misc/dDoS/
(3)
Stacheldraht 攻撃
Stacheldraht攻撃はTrinooの機能とTFNの機能を組み合わせた機能満載の破壊ツール
である。現在ではスレーブとマスタとの間の暗号化Telnetセッションも使われている。
ネットワーク型IDSにも検知されない。TFNと同様、StacheldrahtはICMP型、UDP型、
SYN型、Smurf型の攻撃で攻撃する。クライアントとサーバーとの間の通信には、TCP
パケットとICMP(ECHO応答)パケットの組み合わせを使用する。
(4)
TFN2K 攻撃
TFN2KはTFN 2000の省略形であり、TFNの後継版である。TFNとは大きな相違があ
り、ポートに対するランダム化通信と暗号化を装備している。ランダム化通信により、
ボーダールータでのポートブロッキングをすり抜けられる。暗号化により、ネットワ
ーク型IDSにも検知されない。TFNと同様、TFN2KはSYN、UDP、ICMP、Smurfの各攻
撃で攻撃することができる。また、各種の攻撃モードをランダムに切り替えることも
できる。しかし、Stacheldrahtの暗号化とは異なり、TFN2Kが使用している方式はBase 64
エンコーディングである。
TFN2Kの詳細な分析結果が
http://packetstorm.security.com/distributed/TFN2k_Analysis-1.3.txt
に出ている。
(5)
WinTrinoo 攻撃
WinTrinooはTrinooのWindows版である。このツールは一種のトロイの木馬であり、
一般にはservice.exeと呼ばれている。名称が変更されている場合もある。
WinTrinooを検出する場合、ユーザのネットワークを探してTCPポートまたはUDPポ
ートの34555がオープンになっているかどうかを調べることができる。あるいは、ユー
ザのシステムで名称がservice.exe(名称が変更されているかもしれない)のファイルを
検索することもできる。ファイルのサイズは23,145バイトである。
4.3.2
システムの欠陥利用型攻撃の詳細
4.3.2.1 ハードウェアアーキテクチャに依存した攻撃
(1)
カーネルパニック攻撃
攻撃者が規格以外の不正なパケットをターゲットシステムに対して送信し、カーネ
ルパニックを発生させようとする場合がある。
Copyright © 2003 IPA, All Rights Reserved.
4-17
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
攻撃者が長さ数千行に及ぶ大量のデータ列を送信する場合もある。例えばプログラ
ムでのバッファが128バイトであれば、バッファオーバーフローが起き、アプリケーシ
ョンはクラッシュする。攻撃者がエラーを起こすコマンドを実行することもある。埋
め込み型ロジックチップでは、プログラミング欠陥があるケースもよくある。Pentium
f00fに対するDoS攻撃の場合、usermodeプロセスにより無効な0xf00fc7c8命令を実行する
ことで、どんなOSでもクラッシュさせることができる。
また、Linuxのカーネル版2.2.0の場合、一部のコアファイルを印刷するために共有ラ
イブラリを使用すると、DoS状態が発生する可能性があった。これは、ファイルまたは
装置をメモリにマッピングするライブラリ関数の不具合である。特定の条件下でこの
関数をコールすると、カーネルメモリの重要エリアが上書きされ、システムでパニッ
クが発生し、システムがリブートされる。
このように、カーネルパニック攻撃では、カーネルで使用されているメモリの重要
エリアが破壊され、カーネルがパニック状態になる。Linuxなどの場合、ソースコード
を調べてセキュリティの脆弱性を見つけることができるので問題である。
4.3.2.2 UNIXとWindows NTのDoS攻撃
多数の種々なUNIXモデルで数百ものDoS攻撃が発見されている。また、Windows NT
OSとその関連アプリケーションに対するDoS攻撃も多数発見されている。
(1)
Teardrop 攻撃(IP フラグメント化の重複)
Teardrop攻撃とこれに関連した攻撃では、特定のIPスタック実装でパックされたアセ
ンブリコードで脆弱性を探している。パケットが種々のネットワークを横断するとき、
ネットワークの最大伝送単位(MTU)に従ってパケットを細分化(フラグメントと呼
ぶ)しなければならないことがある。「Teardrop攻撃」は、以前のLinuxカーネルでは、
フラグメント長が大き過ぎる場合は健全性チェックを実行したが、フラグメント長が
小さ過ぎる場合は検証を実行していなかった。このため、不正パケットを脆弱なLinux
に送信した場合、リブートやシステム停止にする。Windows NTやWindows 95も同様に
影響を受けていた。
(2)
Windows NT のスプールリーク(「RPC 経由のパイプ」)
Windows NTではspoolss.exeにメモリーリークがあるので、認証されていないユーザ
が¥¥server¥PIPE¥SPOOLSSにつながり、ターゲットシステムで利用可能なメモリをすべ
て消費することがある。たとえRestrict Anonymous接続を使用可能状態にしても、ヌル
セッション経由でこの種の攻撃が起動することができる。この攻撃では、ターゲット
Copyright © 2003 IPA, All Rights Reserved.
4-18
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
システムを完全に使用不可能にするには時間が少しかかる。また、検出を避けるため
に、長時間にわたってリソースを徐々に消費する。
(3)
IIS FTP サーバーのバッファオーバーフロー型 DoS 攻撃
バッファオーバーフローはDoS状態を発生させる上でも効果的である。バッファオー
バーフローはsuperuserアクセス(侵入)に使われたり、脆弱なアプリケーションを遠隔
でクラッシュさせたりするために使用される。
listコマンドでは、攻撃者がサーバーを遠隔でクラッシュさせることができるので、
インターネット情報サーバー(IISの3.0と4.0)のFTPサーバーはバッファオーバーフロ
ー状態に脆弱である。listコマンドが利用できるのは、認証を受けたユーザのみである。
しかし、匿名のFTPユーザであれば、listコマンドにアクセスが可能になる。バッファオ
ーバーフロー状態を経由して、ターゲットシステムの任意のコードをユーザが実行す
ることができれば、リスクが大幅に増加することになる。
(4)
ストリーム攻撃とレープ攻撃
2000年の初めに、Stream.c(作者は不明)とraped.c(作者はLiquid Steel)が出現した。
両方ともリソース枯渇型DoS攻撃である。一時に送信されてきた奇形のパケットをす
べて管理する能力がOSにはないという欠陥を活用している。stream攻撃もraped攻撃も
多くのOS(Windows NTなど)のCPU稼働率を高くする。攻撃が沈静化すると、システ
ムは元の状態に戻る。stream.c攻撃は、ランダムなシーケンス番号とランダムなソース
IPアドレスにより、一連のポートにTCP ACKパケットを送信したとき作動する。raped.c
攻撃は、スプーフ化したソースIPアドレスにより、TCP ACKパケットを送信したとき
である。
(5)
ディスク割当量に関する脆弱性を悪用した攻撃
リソース枯渇型DoS攻撃の典型例は、所定の割当量(Quota)を超える量を使用する
ことでディスクの利用可能なスペースを消費する方法である。UNIXではディスク割当
機能がしばらく使用されてきたが、Windows NTでは比較的新しい機能である。例えば、
Windows NTのターミナルサーバー版-SP4の場合、通常のユーザでもWindows NTのディ
スク割当機能を見つけてシステムドライブを一杯にすることができる。この結果、シ
ステムに対するアクセスはすべて拒否される。この場合、本来、ユーザのディスク使
用量が自分の割り当てを超えた場合には、システムからログオフできないようにし、
使用量の超過を解消した時点でログオフできるようにすべきである。
以上の(1)∼(5)の攻撃については、Windows 2000やWindows XPでは対策済みと
なっている。
Copyright © 2003 IPA, All Rights Reserved.
4-19
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
4.3.2.3 ストレージに対するリソースの枯渇化
ストレージに対する攻撃には、ストレージを一杯にして利用できなくするような攻
撃がある。例えば、DoSを繰り返し、ログが一定量を超えるとディスクにログを書き込
めなくなるようにする攻撃(ログを利用したDoS攻撃と呼ぶ)がある。
ログを利用したDoS攻撃では、同じログに大量のデータを書き込むようなDoS攻撃や
DDoS攻撃を繰り返す。この攻撃により、ログのバッファやディスクがいっぱいになる。
そのため、ディスクにログを書き込めなくなる。この攻撃では、攻撃によってログが
取られなくなった隙にパスワードクラッキングなどを行い、サーバーなどに侵入する
のが狙いである。
サーバーによっては、ログのディスクの容量が推測できる。そのため、DDoS攻撃を
すべき時間が推測できる。例えば、アプライアンスのファイアウォールでは、ディス
クの容量が限られている上、容量の種類も少ないため、製品情報から簡単にログの容
量が推測できる。
大量のデータを送りつけられると1時間くらいでディスクが満杯になることも想定
される。このような攻撃は夜間にされることが多い。特に中小規模のサイトでは管理
者がいない場合が多い。朝になって管理者が出社し不正アクセスに気がついたときに
は既に不正アクセスが成功してしまっている。
アプライアンスのメールサーバーでも同様の攻撃が可能である。ディスク容量が決
まっているため、それ以上のデータ量のスパムメールを大量に送信されるとログがあ
ふれる。
4.3.2.4 ネットワークプロトコルの脆弱性を利用したDoS攻撃
(1)
ルーティングプロトコルを利用した DoS 攻撃
DNS攻撃と並び、ルーティング攻撃もインターネットの基礎になっているサービス
に対する脆弱性を狙ったものである。BGPを経由してルーティング情報を操作すること
でインターネット自体にDoS攻撃を仕掛けることもありえる。BGPは大半のインターネ
ットバックボーンISPで使用されている。
「ルーティング対応のDoS攻撃」とは、攻撃者がルーティングテーブルのエントリー
を操作することにより、正当なシステムやネットワークに対するサービスを拒否する
攻撃である。例えばルーティング情報プロトコル(RIP)やBGP-4のように、たいてい
のルーティングプロトコルには権限がついていないか、あっても非常に弱い。攻撃者
は正当なルートを変更するという完全なシナリオになる。自分のソースIPアドレスをス
プーフする。通常のトラフィックが攻撃者のネットワークや「ブラックホール」(現
Copyright © 2003 IPA, All Rights Reserved.
4-20
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
4 サービス妨害攻撃
実には存在しないネットワーク)にルートを変更される。これにより、DoS状態を発生
させる。
BGPは大半のISPで使用されている。このBGPの悪用によりISPにDoS攻撃を仕掛ける
ことが可能である。
ICMPでは、サーバーや機器へICMPリダイレクト指示を送り、受け付けた通信を他の
サーバーや機器に転送するように指示できる。これを悪用して、ネットワークに侵入
した攻撃者が、存在しないサーバーや機器のアドレスへの転送を指示することができ
る。そうすると、クライアントからのリクエストがサーバーへ到達しなくなってしま
う。
4.4 参考資料
本章での参考資料は以下である。
「HACKING EXPOSED Network Security Secrets & Solutions Second Edition」Joel Scambray,Stuart McClure,George
Kurtz,OSBORNE,2001
「Hash-Based IP Traceback」Alex C. Snoeren,Craig Partridge,Luis A. Sanchez,W. Timothy Strayer,Christine E. Jones,
Fabrice Tchakountio,Stephen T.Kent,BBN Technologies,2001.6
「Advanced and Authenticated Marking Schemes for IP Traceback」Dawn Xiaodong Song,Adrian Perrig,Computer Science
Department University of California,Berkeley,2001
「セキュリティ完全対策」足利 俊樹,石塚 聡,伊原 秀明,宇野 俊夫,小宮一朗,渡部 勝弘,日経BP社,2001.11
「セキュリティ技術大系2003」青木 和仁,新井 悠,武岡 徳之,村上 晃 著,三輪 信雄 監修,日経BP社,2002.9
「ダイナミックディフェンスの概要と適用について」JNSA,ダイナミックディフェンス WG,2000.12
http://www.jnsa.org/active/houkoku/dd.doc.pdf
Copyright © 2003 IPA, All Rights Reserved.
4-21
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
5 サービス妨害攻撃に関する対策とその
強度、脆弱性
5.1 概要
以上、1章から3章まででサーバーのハイアベイラビリティ技術を説明してきた。こ
の中から、4章にて説明したサービス妨害攻撃に対して有効な技術をまとめる。
対策のポイントは
単点障害(SPOF)を除去する。
DoS攻撃に対し、十分な処理能力を持つ。
という2点である。
単点障害は、ハードウェアやソフトウェアの故障で起きる場合もあるし、不正アク
セスで起きる場合もある。
単点障害になる可能性がある箇所、処理能力がDoS攻撃によって枯渇してしまう可能
性がある箇所として、下記9箇所が挙げられる(図 5-1参照)。
① インターネットサーバー
②
DNS
③
ロードバランサー、ルータ、スイッチなど通信機器
④
ISP
⑤
ファイアウォール
⑥
通信帯域
⑦
NIC および回線
⑧
ストレージ
⑨
サイト
Copyright © 2003 IPA, All Rights Reserved.
5-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
インターネット
ISP1
ISP2
⑥通信帯域
④ISP
⑨サイト
③ルータ
③ロードバランサー
⑤ファイアウォール
②DNS
③ロードバランサー
⑦NIC および回線
⑧ストレージ
①インターネットサーバー
図 5-1 攻撃の対象となる箇所
各箇所で有効な対策を挙げる。
①インターネットサーバーに関する対策
対策1:クラスタリング
対策2:サービス毎のサーバーの分離
対策3:インターネットサーバーの脆弱性対策
対策4:キャッシュサーバーの利用
対策5:複数サーバーへの処理の分散
対策6:サーバーへのヘルスチェック
②DNSに関する対策
対策7:DNSの冗長化
③ロードバランサー自身に関する対策
Copyright © 2003 IPA, All Rights Reserved.
5-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
対策8:通信機器自身に関するセキュリティ対策
④ISPに関する対策
対策9:複数ISP(プロバイダ)の利用
対策10:外部委託の評価
⑤ファイアウォールに関する対策
対策11:ファイアウォールの導入
⑥通信帯域に関する対策
対策12:QoS制御
対策13:十分な通信帯域の確保
対策14:ネットワーク(回線)の分離
⑦NICおよび回線に関する対策
対策15:NICの冗長化
対策16:回線の多重化
⑧ストレージに関する対策
対策17:ストレージの信頼性確保
対策18:バックアップ
対策19:ログ用ストレージ容量確保
⑨(テロや地震などの大規模災害を想定した)サイト全体の対策
対策20:インターネットサーバーの広域分散
対策21:バックアップサイトによるサイトの分散
対策22:攻撃の検知とインシデントレスポンス
一方、上記の対策は次の観点でも分類できる。
ホストセキュリティ(個別サーバーに対するセキュリティ)
グループセキュリティ(サーバー群に対するセキュリティ)
この観点で対策1から22を分類すると、対策1、対策2、対策16がホストセキュリティ、
他がグループセキュリティということになる。通常の不正アクセス対策ではホストセ
キュリティが重要であるが、ハイアベイラビリティを確保するには、むしろ、グルー
プセキュリティに重点を置いた対策に効果があるということが分かる。
これらの大半は導入時に検討する対策であるが、運用開始後の定期的な見直しに関
する項目としては、対策3、対策10、対策18、対策22がある。
Copyright © 2003 IPA, All Rights Reserved.
5-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
もちろん、対策の実施にあたっては、対策自身の脆弱性、対策のコスト、業務やネ
ットワークの特性なども考慮する必要がある。
以下、各対策の有効性と導入上の注意点を順に述べる。
5.2 対策1:クラスタリング
ECサイトや予約サイトなどの、更新系のインターネットサーバーでは、処理能力と
信頼性の向上のための手段にはサーバーをクラスタリングする、フォールト・トレラ
ントにするくらいしか選択肢がない。大規模サイト、中小規模サイトに関わらず、更
新系で特に高リスク、または高負荷なサイトの場合に採用することを推奨する。CPU
数を増やすほど高価となるため、トラフィック量等を考慮して規模を検討する必要が
ある。
リスク回避からはデータを分散させて同期を取ればいいのだが、
同期を取るのが難しい。
データベースのメンテナンスなど管理の手間がかかる。
運用の要員が必要。
という理由のため、通常、データベースは1箇所で管理している。特にハイアベイラ
ビリティを確保したいようなシステムでは、バックアップサイトを置くということが
行われている。「バックアップサイトによるサイトの分散」の節で説明する。
一方、サービス妨害攻撃に対しては、クラスタが存在しているネットワークが攻撃
に遭った場合、クラスタのOSなどが攻撃に遭った場合など、十分な強度があるとは言
えない。クラスタリングを利用する場合でも、ネットワーク機器などでの対策、回線
の分散など他の対策が必要である。
5.3 対策2:サービス毎のサーバーの分離
サービス毎のサーバーの分離は、下記の2点で有効である。
不正アクセス時の被害の低減。
I/Oボトルネックの排除。
サーバーコストの削減。
Copyright © 2003 IPA, All Rights Reserved.
5-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
不正アクセスされる可能性は、サービスの種類が増えるほど増える。Web、メール、
データベースといったサービスを個別のサーバーから提供することにより、全サーバ
ーが同時に不正アクセスに遭う可能性を減らすことができる。
サイトの規模、更新系、参照系に関わらず、高リスク、または高負荷なサイトの場
合に採用することを推奨する。Webとメールなど大量データを扱うサービスを同一サー
バーに共存させるとディスクI/Oがボトルネックになる可能性が高い。
同様に、高価なサーバー1台より、安価なサーバーで分けた方が性能も安全性も優れ
ている。高価なサーバーだと、それ1台が攻撃されたり、故障したりするとまったくサ
ービスが提供できなくなる。また、一般には、同じコストをかけても、安いサーバー
複数台で同一のサービスを提供した方が、性能も信頼性も挙げることができる。安価
なサーバー複数台で同一のサービスを提供するのがロードバランシングの考え方であ
る。この点でも、サービス毎にサーバーを分離するのは有効である。
インターネットサーバーへウイルスなどが持ち込まれ、それによってサービスが停
止するという可能性もある。ウイルス対策には、下記が有効である。
サーバーではウイルスを持ち込む可能性があるファイルを扱わない。
必要に応じてウイルス対策ソフトを利用することが望ましい。
5.4 対策3:インターネットサーバーの脆弱性対策
DoS攻撃を受けないようにするための第一歩はインターネットサーバーの脆弱性を
減らすことである。インターネットサーバーの脆弱性は、クラスタリングの形態や構
成により変わる。つまり、OS、データベースなど製品固有の脆弱性をよく調査し、分
析して、パッチの適用など、不正アクセス対策を確実に行うことが重要である。
また、クラスタの構成や形態を攻撃者に知られると不正アクセスの標的になる。構
成や形態など攻撃手段の特定に利用されるような情報はすべて秘密にし、文書管理や、
情報管理、サーバーの設定(システムのバージョンを外部に分からないように設定す
る等)などを厳重に行う必要がある。
インターネットサーバーに対する脆弱性には下記のようなものがある。
オペレーティングシステム(OS)の不具合
ドライバソフトウェアの不具合
管理ツールの不具合
アプリケーションの不具合
運用管理者の設定ミス
Copyright © 2003 IPA, All Rights Reserved.
5-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
管理者の不注意(トロイの木馬、ウイルス、パスワード漏洩)
ハードウェア特有の脆弱性
これらの脆弱性には、大規模サイト、中小規模サイトに関わらず、表 5-1の項目を実
施することが解決策となる。
表 5-1 インターネットサーバーの脆弱性対策
項番
脆弱性対策
1
脆弱性に関する最新情報を入手し、パッチなど対策をタイムリーに行う。
2
アプリケーション(特にCGIなど)での脆弱性を排除する。
3
管理者・利用者に対し教育・訓練を行う。
4
定期的な検査ツール実行による設定ミス、脆弱なパスワードを発見し、対処する。
5
特定のベンダやハードウェアアーキテクチャに依存しない構成を採用する。
6
ハードウェア、OSの種類を外部から推測されないようにする。
7
ハードウェア、ソフトウェア、クラスタリング構成に関しわざと攻撃者を混乱させる
ような応答を返信する。
8
システムのデフォルト設定は利用しない。
9
不要なサービスは停止する。
10
不要なプログラムはインストールしない。
11
公開すべきデータと公開してはならないデータを分離する。
アプリケーション、特にCGI(Common Gateway Interface)などを悪用した不正アク
セスを排除するには、脆弱性を持たないようにプログラミングするテクニックを十分
に理解して開発を行うことが必要である。
サーバーや機器のデフォルト設定には脆弱性が多い。OS、ドライバソフトウェア、
管理ツールに関する脆弱性排除の方法を確実に理解して、対策を行うことが必要であ
る。管理ツールは悪用されないように、実行権限を特定のユーザに制限するなどの対
策も必要である。脆弱性情報の提供無料、有料サービスもある。また、定期的に検査
ツールを用いてインターネットサーバーや通信機器に設定ミスや脆弱性がないかを確
認するとより確実である。
Copyright © 2003 IPA, All Rights Reserved.
5-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
ネットワークやサーバーを二重化する場合、通常は同一製品を使いがちである。し
かし、CPUアーキテクチャなどのハードウェアに依存した攻撃に関する対策としては、
特定のベンダやハードウェアアーキテクチャに依存しないネットワークやサーバーで
二重化を行うことが効果的である。
複数のサーバーを利用する場合も、異なるアーキテクチャのサーバーを混ぜて利用
する。同一のOSであっても、CPUのバージョンが異なれば効果がある。ファイアウォ
ール、ルータなどでも同じことが言える。
NICの場合は、NICを2重化する際に、2種類のNICを利用するという対策を採ること
ができる。また、不正アクセスに関するデータベースなどに特定のNICに対する攻撃が
知られていないか確認する。
攻撃者が攻撃を仕掛けるにはまず、ホストスキャン、ポートスキャンなどにより、
サイトの仕組みを分析し、脆弱性を発見するところから始める。例えば、ポートスキ
ャンによりNICのMACアドレスが分かるとNICのベンダや型が推定できる。脆弱性を見
つけるには、ハード、OS、ソフトウェア、クラスタリング技術、構成などについて詳
しい情報が必要である。UNIXサーバーをWindowsサーバーと思って攻撃してもうまく
行かない。つまり、この情報がなければ、または疑っていれば攻撃されないというこ
とである。
OSやWebサーバーのバージョンは攻撃者に調べられてしまう。それを逆に取って、
わざと攻撃されやすいサーバーをダミーで置き、攻撃させる手法もある。これをハニ
ーポットという。このハニーポットサーバーへのアクセスのログからクラッカーの行
動パターンをつかむことが可能である。不正アクセス対策に役立てられる。
インターネットサーバーでは不要なサービスはすべて停止すべきである。SNMP
(Simple Network Management Protocol)はサーバーやクライアント、ルータなどのネッ
トワーク機器を遠隔地から管理サーバーやクライアント、ルータなどのネットワーク
機器を遠隔地から管理するためのプロトコルである。NTP(Network Time Protocol)は、
サーバー間での時刻同期のためのプロトコルである。これまでSNMPやNTPの実装では
脆弱性が発見され、それに対して対策版が出ている。SNMPやNTPを動作させるとネッ
トワーク情報が傍受され、攻撃に利用される可能性もある。安全のため、できればSNMP
とNTPのサービスは停止すべきである。
不要なプログラムはトロイの木馬、ウイルスなどの可能性もあるし、攻撃に悪用さ
れるかもしれない。インターネットサーバー構築時に不要なプログラムは削除すべき
である。もちろん、出所不明なプログラムを持ち込みは禁止する。
Webサーバーでの情報漏洩や不正アクセスは、公開すべきでないデータを外部から参
照可能な領域に誤って置いてしまったというような場合が非常に多い。そのため、ま
Copyright © 2003 IPA, All Rights Reserved.
5-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
ず、ストレージはシステム、公開すべきデータ、公開してはならないデータ、ログと
いうようにパーティションを分け、それぞれについてアクセス可能者(一般ユーザ、
データをメンテナンスする者、管理者)、アクセスに利用できる遠隔端末のIPアドレス、
アクセス権限、CGIの実行許可などの制限を定義・設定する。
運用については、サイト内の全システムについて脆弱性対策を組織的・体系的に行
うことが効果的である。組織的な運用とは、体制を整え、実施する対策のルールを確
立することであり、体系的な運用とは、すべてのシステムに対して定期的に脆弱性対
策を施すことである。さらにハードウェアのメンテナンスも故障の予防には必要であ
る。
5.5 対策4:キャッシュサーバーの利用
参照系、コンテンツ配信のインターネットサーバーでは、キャッシュを利用するこ
とがサービス妨害攻撃に対し、非常に有効である。特に大規模サイトで、高リスクま
たは高負荷なサイトの場合に採用することを推奨する。トラフィック量等を考慮し、
キャッシュサーバーの設置台数を検討する必要がある。
キャッシュの機能には以下がある。
処理能力を向上させる。
処理を多重化させる。
処理や接続を広域に分散させる。
一方、キャッシュサーバーでもサービス妨害攻撃に関する対策、不正アクセスに関
する対策はインターネットサーバー同様必要である。
5.6 対策5:複数サーバーへの処理の分散
複数サーバーによるハイアベイラビリティ技術には次のようなものがある。
DNSによるトラフィックの複数インターネットサーバーへの分散
ロードバランサーによる複数インターネットサーバーへの処理の分散
特定のサーバーがサービス妨害攻撃に遭った場合にDNSによりトラフィックを他の
サイトにリダイレクションする機能も有効であるといえる。
Copyright © 2003 IPA, All Rights Reserved.
5-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
これらの対策は、参照系の大規模サイトで、高リスク、または高負荷のサイトにて
有効となる。ロードバランサーは高価であるため、大規模サイト向けと言える。ロー
ドバランサーによる複数インターネットサーバーへの処理の分散は、処理能力が高け
れば、DoS攻撃に対し、ある程度耐えうる程度の対策であって、根本的な対策とは言え
ない。
つまり、ハイアベイラビリティの要求度に応じて、上記の中から複数の手段を用い
る必要があるということになる。
サーバーの多重化は、インターネットサーバーなどの脆弱性に対するタイムリーな
対策、ハードメンテナンスのためには不可欠である。Webサービスやインターネット取
引の立ち上げを急ぐあまり、Webサーバー1台でサービスを開始してしまう場合が多い。
いったんサービスを開始すると停止できない。停止できないので、パッチがあてられ
ない。そのため、セキュリティホールをたくさん抱え込んだままサービスを継続する
ことになる。これに開発者の知識不足が加わって、結局、脆弱性だらけのインターネ
ットサーバーが運用され続けることになってしまう。これが、インターネットサーバ
ーでの不正アクセスの最大の原因となっている。
5.7 対策6:サーバーへのヘルスチェック
インターネットサーバーのヘルスチェックをするDNSは少ない。しかし、広域ロー
ドバランスを行っている場合、DNSからのヘルスモニタリングを行っていると、ある
サイトがサービス妨害攻撃に遭った場合でも、すぐに他のサイトにアクセスを転送で
きるため、アベイラビリティ向上には有効である。参照系で高リスクまたは高負荷で
ある大規模なサイトにて有効となる。
ロードバランサーからWebサーバーへのヘルスモニタリングは、Webサーバーがサー
ビス妨害攻撃や不正アクセスに遭った場合、クライアントからのリクエストを別のWeb
サーバーにリダイレクトするために有効である。
一方、ヘルスモニタリングに利用する通信プロトコルには脆弱性がある可能性があ
り、サービス妨害攻撃に利用されるかもしれない。特に、ヘルスモニタリングにICMP
を利用している場合はサーバーやネットワーク機器の設定が不正に変更される可能性
もある。この対策として、ヘルスモニタリングに使う通信回線をインターネット接続
回線とは分離するという方法がある。
Copyright © 2003 IPA, All Rights Reserved.
5-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
5.8 対策7:DNSの冗長化
DNSは通信で最も重要な部分であるにもかかわらず、脆弱性が多い。DNSは通信の
一番重要な部分、つまりIPアドレスの検索に関わっている。DNSなしではインターネッ
トでのサービス提供は行えない。つまり、サイトに対する攻撃の中ではDNSへの攻撃
が一番有効である。そのため、サービス妨害攻撃の標的になっている。
DNSの重要性を考慮すると、業務の種類、サイトの規模、リスクの高低、負荷の高
低に関わらずDNSの冗長化を行う必要がある。特にハイアベイラビリティを確保した
いサイト、大規模サイトでは、DNSのハイアベイラビリティ確保には十分な対策を採
るべきである。
DNSは通常プライマリとセカンダリ2台で運用するが、さらにDNSのハイアベイラビ
リティを確保するためには、以下のような対策が有効と言われている。
多重化する。
ロードバランサーを導入する。
各DNSでOSを変える。
DNSに対するサービス妨害攻撃や不正アクセス、DNSの故障を考えたときに、DNS
の多重化は不可欠な対策である。ISPでもDNSを数台設置してトラフィック分散を行っ
ている。多重化には、ロードバランサーを利用した多重化、広域対応ロードバランサ
ーを利用した多重化などの手段がある。また、同じ役割を全DNSに持たせる方法と、
DNS毎に役割を分ける方法もある。
この他に、DNSでの可能な対策は、被害を受ける範囲を限定させることがある。例
えば、インターネットからの問い合わせとイントラネット内で問い合わせを処理する
DNSを分ける。さらにインターネット接続回線毎にDNSを分ける方法もある。これに
より全DNSが一斉に攻撃に遭うことはなくなる。
DNSの多重化では、DNSのOSに違うものを採用すると、DNSに対するサービス妨害
攻撃、不正アクセスに対して有効である。つまり、2台でOSが違うとDNS間でOSなど
での脆弱性が違ってくる。つまり、2台が同時に攻撃される可能性が低くなり、サービ
スが完全に停止するということが減る。
DNSのリモート管理機能を利用する場合は、不正アクセス防止のためのセキュリテ
ィ対策が必須である。DNSは外部からの不正アクセスを防止するため、もちろん、DMZ
に置く。インターネットサーバーを置くDMZと同じDMZにするか別にするかは一概に
は言えない。
Copyright © 2003 IPA, All Rights Reserved.
5-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
他にも、DNSのハイアベイラビリティ確保には、次のような対策がある。
リモート管理機能を利用する場合は、セキュリティ機能を用いる。
物理的に広域に分散させる。
複数のプロバイダとの回線を持つ。
インターネットサーバーへの負荷が高いサービスでは、その性能、冗長構成におけ
るフェイルオーバーの速度も重要な要素である。
DNSのハイアベイラビリティ対策は重要であるが、一方、DNSの広域分散をISPへ依
頼するには月額数十万円程度かかる。広域対応のロードバランサーは比較的高価であ
り、数百万する。
他にも、DNSには多くの脆弱性がある。DoS攻撃に対しても確実な防止対策はない。
DNSへの不正アクセスや攻撃を減らすための対策としては他にもある。
DNSにDNSでないような名称を付け、攻撃の可能性を低くする。
DNSの台数が多いように見せかけ、攻撃を抑止する。
例えば、DNSの名称をdns09として、一見、9台もDNSがあるように見せかける。これ
は、特に費用のかからない対策である。
5.9 対策8:通信機器自身に関するセキュリティ対策
ロードバランサーに対するサービス妨害攻撃はありえる。攻撃の種類によっては、
ロードバランサーの二重化は有効である。参照系のサービスで、特に高リスク・高負
荷である大規模サイトで有効となる。
ISPとの接続毎にVLANを分けると、攻撃に対し、全VLANが一斉に影響を受けると
いう事態は避けられるので、サービス妨害攻撃に対して有効であるといえる。
ロードバランサーも不正アクセスされる可能性はある。不正アクセスに対しては、
アクティブ/アクティブモードでは、2台のロードバランサーとも同時に不正アクセスに
遭う可能性がある。アクティブ/スタンバイモードでは、スタンバイは不正アクセスに
遭わないので、多少、強度は高いといえる。
サービス妨害攻撃に対して、セキュリティ機能は有効であり、必須でもある。さら
に、最新のサービス妨害攻撃の動向を入手し、ベンダからパッチなど対策が出ていれ
ば、それをタイムリーに導入するべきである。
Copyright © 2003 IPA, All Rights Reserved.
5-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
また、リモート管理機能を利用するのであれば、不正アクセスに利用されないよう
に、管理機能にはセキュリティ対策は必須である。
NATはコネクションを確立しないタイプの攻撃(多くのDoS攻撃)には有効であるが、
クライアントがコネクションをサーバーと確立してしまった後の不正アクセス、例え
ばTCPコネクションジャックに対しては有効ではない。つまり、NATだけでは不正アク
セスを防ぐことはできないというNATでの対策の限界をよく理解し、他の不正アクセ
ス対策も組み合わせる必要がある。
アプライアンス製品であるからすぐサービス妨害攻撃に対して脆弱であるとは言え
ない。しかし、サービス妨害攻撃に対して、アプライアンス製品の強度を保つために
は、下記が重要である。
製品名が攻撃者に対し分からないようにする。
サービス妨害攻撃に対し、最新の対策を行う。
バージョンアップの手間、メンテナンス性が悪い場合がある。アプライアンス製品
といっても、ロードバランサーやNASはWindows 2000で動作しているものも多い。そ
のため、Windowsと同様のセキュリティホールがあり、その対策として、「Windows
Update」でバージョンアップする必要がある。これを管理者が認識する必要がある。
5.10 対策9:複数ISP(プロバイダ)の利用
DoS攻撃の多くは、特定ISP内で起こるため、影響はISP内やISPとの接続、特定ISPか
らのアクセスの部分で起きる。そのため、インターネットサーバーのサービスが特定ISP
に完全に依存するのはリスクが高い。
ハイアベイラビリティの基本的な考えは起きた場合のリスクを低減することであ
る。つまり、リスクを分散する、単点障害をなくすことである。高リスクの大規模サ
イトでは、DoS攻撃に対し、インバウンド・アウトバウンドの通信帯域を確保するには、
複数のプロバイダとの回線を持つという対策が有効である。複数のプロバイダとの回
線を持つことにより、特定のプロバイダの回線を通じたDoS攻撃に対しても、攻撃に利
用されていないプロバイダの回線を利用して、アウトバウンドの帯域を確保すること
ができる。一方、複数ISPへの接続を持つと費用はかかる。さらに、場合によってはISP
にDoS攻撃への対応を依頼することも考えられる。
5.11 対策10:外部委託の評価
Copyright © 2003 IPA, All Rights Reserved.
5-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
インターネットサービスでは、ISPの利用、インターネットサーバーの運用の外部委
託、CDN(Contents Delivery Network)の利用、サイトの監視など外部委託に頼る必要
がある業務が多数ある。特に高リスクまたは高負荷のサイトで、小規模あるいは新し
くインターネットビジネスを開始したために運用体制が整っていない企業の場合、外
部委託を利用することは有効である。
インターネットサーバーの運用を外部へ委託する場合、業者やサービスの費用によ
ってサービスレベルや技術力に差があるということをよく理解した上で業者とサービ
スを選択する必要がある。Webサーバーの書き換えの事例を見ると同一エンジニアが導
入し、iDCで運用されていると思われるWebサイトが一気に不正アクセスに遭う例が多
い。
インターネットサービスのセキュリティリスクに関係する項目には以下がある。
不正アクセスされるようなセキュリティホールに対する知識、対策実施の正確
性
不正アクセスされた場合の対処
SLA(サービスレベルアグリーメント)
各業者でのこの3点の十分性を客観的に評価し、業者を選択する必要がある。また、
契約後も、定期的にこの評価結果を見直す必要がある。
5.12 対策11:ファイアウォールの導入
ファイアウォールは社内ネットワークへの不正侵入や破壊行為、Web、DNS、FTPサ
ーバーなど外部公開サーバーの防御などを行うために設置する。一般的には社内ネッ
トワークとWANルータの間に設置する。通過するネットワークトラフィックを監視し
て、ルールに基づいた正当な通信のみを行えるようにする一方、不正な動きを検知す
る。業務の種類、サイト規模に関わらず、高リスクのサイトで導入すると有効である。
また、ファイアウォールを狙ったサービス妨害攻撃や不正アクセスに対し、ファイ
アウォールの多重化、特に、異なるベンダの製品による多重化は有効である。ただし、
デメリットとしてシステムインテグレーションの複雑さを生む可能性もある。
高速なISP接続では、ファイアウォール処理能力を多重化により増強する必要がある。
増強すればDoS攻撃に対しある程度有効である。一般には、ある程度大規模な(数十
Mbps)DoS攻撃に十分帯域を確保するようにすると、ファイアウォールがボトルネッ
クになる可能性が高い。そのため高負荷なサイトで採用する場合は注意が必要である。
Copyright © 2003 IPA, All Rights Reserved.
5-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
ファイアウォールがボトルネックになった場合は、ファイアウォールでの処理を簡素
化する必要がある。
5.13 対策12:QoS制御
サービス妨害攻撃が特定のインターネットサーバーに対し行われた場合を想定する
と、ロードバランサーでインターネットサーバーへの最大コネクション数などQoSによ
る制限を行う対策は有効である。(ロードバランサーのQoS機能の詳細は1章を参照)
高リスク、高負荷の大規模サイトで導入すると有効である。
5.14 対策13:十分な通信帯域の確保
サービス妨害攻撃に対しては、攻撃者を上回る処理能力が要求される。処理能力は
インターネットサーバーで行うアプリケーションなど多種の要因により左右される。
特に、通信帯域が最も影響を受ける部分である。
攻撃者がDNSに不正パケットを送付した場合、DNSへのパケットに比べ、レスポン
スのサイズは約4倍になる。そのため、不正パケットの送付に対し防衛するためには、
攻撃者が不正パケットを送りつけるのに対し、4倍の応答を返すアウトバウンドの通信
帯域が必要になる。DoS攻撃に対処するためには、インバウンドの帯域に比べ、4倍の
アウトバウンドの帯域でプロバイダと契約する必要がある。通常の通信回線の帯域は、
通常1.5Mから10Mbpsである。これと同程度のインバウンドの帯域と、この4倍以上のア
ウトバウンドの帯域を準備すれば、通常の攻撃者からの攻撃には対抗できる。可能な
ら100Mbps確保するのが望ましい。
また一般的に、Webサイトでは、HTTPリクエストに比べ、配信するコンテンツの方
がサイズは大きい。このため、アウトバウンドの帯域の方がより大きくする必要であ
る。大規模であればあるほどこの傾向がある。
このように、通信帯域の確保は、業務の種類、サイトの規模に関わらず、高負荷サ
イトはもちろん、高リスクのサイトでのDoS攻撃に対する有効な対策として重要であ
る。もちろん、ISPとの接続などでは費用もかかる。そこで、インバウンドの帯域とア
ウトバウンドの帯域を分け、個別に契約し、コストパフォーマンスをよくすることも
検討すべきである。
Copyright © 2003 IPA, All Rights Reserved.
5-14
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
5.15 対策14:ネットワーク(回線)の分離
インターネットサーバーシステムで必要となる通信には下記がある。
インターネット(ISP)との接続、つまりクライアントへのサービス提供のため
の回線(サービス回線と呼ぶ)
データのバックアップ、遠隔地のサーバーと同期などのための回線(データ回
線と呼ぶ)
機器・サーバーの管理・監視のための回線(メンテナンス回線と呼ぶ)
通常のDoS攻撃や不正アクセスはインターネット接続から来る。高リスク・高負荷の
大規模サイトの場合、データの同期に用いるデータ回線とインターネットからのサー
ビス回線とは分離し、他方の回線のトラフィック影響を受けないようにする、つまり、
データ回線がサービス回線でのDoS攻撃の影響を受けないようにするのが安全である。
また、インターネットから受け付けるトラフィックはHTTPに限定し、データの更新
やシステムの管理操作は内部ネットワークからしか行えないように設定し、回線も分
離すれば、不正アクセスに遭う可能性を大幅に抑えることができる。通常、サーバー
にNICが2つあるのはこの2本の通信回線を分けるためである。
バックアップなどデータ転送がインターネットからのアクセスのパフォーマンスに
影響を与えないようにする技術も重要である。サーバーレスバックアップやネットワ
ークレスバックアップという技術を用いるとデータバックアップ処理がサーバーや、
ネットワークに負荷をかけずにすむ。また、データの同期にはVPNや専用線を用いる。
データの同期用の回線とサーバー管理用の回線を共有するのは問題がないと思われ
る。VLANを利用することで無駄なブロードキャストを削除できる。これはDoS攻撃に
有効である。
5.16 対策15:NICの冗長化
高リスクまたは高負荷な大規模サイトのような、アベイラビリティが重要なシステ
ムでは、NICの冗長化は必要である。
例えば、インターネットサーバーに3番目のNICを予備として付ける。サービス用か
マネジメント用のどちらかのNICの故障時にはこの3番目のNICを利用する。3番目の
NICは1番目、2番目のうち、処理能力の低い方に合わせると、投資効果がよい。例えば、
Copyright © 2003 IPA, All Rights Reserved.
5-15
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
1番目のNICがGigabit用、2番目のNICが100Mbps用なら、3番目のNICは100Mbps用でよ
い。
NICの多重化には、下記のような技術がある。
NICのチーミング(詳細は1章を参照)によるフォールト・トレランス
リンクアグリゲーション
チーミング技術を用いるとアダプタ、ケーブル、接続先ポートなどが故障した際に
他のアダプタに処理を引き継ぐことができる。また、リンクアグリゲーションを用い
て複数のアダプタを束ねることにより、複数の送信先に対する帯域幅を倍増し、ロー
ドバランスも実現することができる。
さらに、異なるベンダのNICを利用して多重化すると、NICの特性を利用したサービ
ス妨害攻撃に対しても有効である。
5.17 対策16:回線の多重化
業務の種類に関わらず、高リスクまたは高負荷である大規模サイトの場合は通信機
器だけではなく、回線の多重化も重要である。回線のうち、特に、各ISPとの接続回線
を多重化する、代替接続手段を契約しておくことも有効な手段である。
今日、安価な通信手段が各種ある。中小規模サイトでもこのような通信手段を代替
手段として用意しておけば、単点障害を防止できる。
回線の多重化には、リンクアグリゲーションのほか、ロードバランサーを利用した
多重化もある。一方、回線間のロードバランスはアプリケーションの特性などにもよ
る場合があるため、チューニングが必要な場合が多い。
5.18 対策17:ストレージの信頼性確保
RAIDの利用はシステムを故障から守り、ハイアベイラビリティを確保するには不可
欠である。特に、更新系サービスの高リスクなサイトでは、サイト規模に関わらずス
トレージの可用性確保が重要である。一方、特定のRAID製品に対する攻撃がありえる
ので、大規模システムで1種類の製品に依存するのはリスクがある。複数技術に分散可
能なら分散させるのもよい。
Copyright © 2003 IPA, All Rights Reserved.
5-16
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
ストレージやバックアップでは運用管理が課題である。管理を単純化する技術の採
用が望ましい。これは、システムの変更などの管理を単純化すると、管理者がシステ
ムのセキュリティ対策や監視により時間を使うことができるからである。管理の単純
化技術には、アダプティブRAID、HSMによるストレージの階層管理、外付けRAIDが
ある。
内蔵RAIDではデータ移行にかなりの時間と人手を必要とする。それに比べ、外付け
RAIDは、サーバーのリプレース時にケーブルの接続替えのみですむ場合がある。つま
り、信頼性・高速性を重視するシステムや大規模システムで管理体制が充実している
場合は外付けRAIDがよい。
ファイバーチャネルを利用したSANの導入などは、信頼性だけではなく、パフォー
マンスの向上にも役立ち、その点では、データへのアクセスがボトルネックになるよ
うなシステムでは、DoS攻撃に対するシステムのハイアベイラビリティ向上に役立つと
考えられる。
また、今後、FCIPやiSCSIストレージなど、IPネットワークにまとめることができる
技術が広まれば、広域なデータ分散も可能になってくるかもしれない。
5.19 対策18:バックアップ
バックアップは、セキュリティ対策の中でも最も基本的なものである。業務の種類、
サイト規模に関わらず、バックアップを確実に取得する必要がある。一方、各種の対
策の中で一番、運用コスト(人件費、メディア、保管場所など)がかかるものである。
特に中小規模のサイトでは、バックアップの確実な実行は難しい。
データが大きいにもかかわらず十分なバックアップ運用体制が確保できない場合
は、バックアップを自動化するためのテープライブラリ製品の導入や運用の外部委託
を考えるべきである。
自分でバックアップを行う場合は、定期的にリストアの訓練を行う必要がある。ま
た、特にバックアップを自動化していない場合は、確実にバックアップを実行してい
るかについて監査を行うことも重要である。
バックアップとリストアでは重要な観点が3点ある。
運用への影響を減らす。
データの損失を減らす。
データを短時間で回復する。
Copyright © 2003 IPA, All Rights Reserved.
5-17
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
更新系で高負荷なシステムではバックアップによるサービスの停止や、サーバー、
ネットワークへの負荷を最低限に抑える必要がある。スナップショット、サーバーレ
スバックアップ、バックアップ用ネットワークの分離などの対策が必要である。
更新系のシステムで、特にトランザクションが重要なシステムでは、故障時のデー
タ損失を減らす必要がある。オンラインバックアップの他、遠隔へのバックアップ、
データバックアップの間隔の短縮、ジャーナルシステムの利用など高度なバックアッ
プ技術が必要である。
参照系のシステムでも、障害時に短時間で回復できるようにするために、データの
バックアップは重要である。特にシステムが分散している場合、システム毎にデータ
をバックアップしようとすると手間がかかりすぎる。ネットワークを経由したバック
アップ、SANやNASといったストレージの管理を一元化する技術はバックアップを単
純化でき、有効である。リストア時間の短縮にもつながる。
ハイアベイラビリティの要求度が高いシステムでは、故障後、回復(リストア)を
短時間で行う必要がある。リストアの手順を単純化する技術が重要である。ディザス
タリカバリなどサーバーの設定とデータを両方短時間で回復する技術は有効である。
インターネットサーバーで扱うデータは金融取引など重要な記録の場合が多い。そ
のようなデータの事故による削除や不正アクセスによる改ざんを防止するためには、
ログの遠隔バックアップが重要である。オンライン・アーカイブというログ専用のア
ーカイブ技術も利用できる。
5.20 対策19:ログ用ストレージ容量確保
DoS攻撃ではストレージを使い切るような攻撃がある。また、ログのためのストレー
ジがなければ不正アクセスを追跡できない。
一方、ファイアウォール、ロードバランサーなど通信機器のログは大量になる。特
にストレージが限られたアプライアンス製品では注意が必要である。この問題への対
策には、下記がある。
ログに確保できるストレージ容量のなるべく大きい製品を選択する。
ストレージをシステム用、データ用、ログ用のパーティションに分け、1パーテ
ィションの使用量増加が他のパーティションに影響を与えないようにする。
ディスクの残容量を常に監視する。
製品の型やディスク容量を推測されないようにする。
Copyright © 2003 IPA, All Rights Reserved.
5-18
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
特に高リスクの大規模サイトで採用することが有効である。ただし、単に、ディス
ク容量を大きくすればいいというわけでもない。ディスク容量を大きくするとログ管
理が大変になる。このトレードオフを考える必要がある。また、ログを受け取るサー
バーの特定などファイアウォールやフィルタリングでの設定が重要となる。
5.21 対策20:インターネットサーバーの広域分散
参照系サービスで、高リスク、高負荷である大規模サイトの場合、複数ISPへ接続す
る対策の代替策として、キャッシュサーバーを分散設置するという対策がある。キャ
ッシュサーバーをそれぞれ異なるISPに接続すれば、特定ISPがサービス妨害攻撃に遭っ
た場合やオリジナルのWebサーバーがダウンした場合でも、残りのキャッシュサーバー
からコンテンツ配信が継続できる。
通常、複数のプロバイダと回線を結んだり、複数のハウジング先にWebサイトをハウ
ジングさせたりすると費用がかかる。CDNは複数のプロバイダのネットワーク内にキ
ャッシュサーバーをハウジングさせるサービスである。サービスによっては、物理的
にも分散して設置を行ってもらえる。物理的、ネットワーク的に分散設置すると、DoS
攻撃などISPでの問題と、災害などサイトの問題の両方に対し効果がある。
CDNは、製品・サービスの紹介、ソフトウェアやパッチの配信などといったコンテン
ツ配信サービス(参照系)には適している。一方、オンライン予約のような更新系サ
ービスには適さない。
CDNはスポット的(今日だけ、この時間だけなど)に利用するとアベイラビリティ
向上に効果的である。例えば、次のようなイベントでは、短時間にWebサイトに対し大
量のアクセスが発生する。
コンサートの中継
著名ソフトウェアプリンタ・ドライバ・デバイスドライバなどのバージョンア
ップ、パッチの公開
しかし、このようなアクセスのためだけにハードウェア設備を増設するのはコスト
がかかりすぎる。それに対し、CDNでは、Webコンテンツの配信を短期間(数分、数
時間、数日など)で利用できるため、効率がよい。また、このようなイベントは攻撃
の標的になる可能性が高いため、CDNなどによるリスクの分散化は有効である。最近
Copyright © 2003 IPA, All Rights Reserved.
5-19
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
は、リソースオンデマンド39など、iDCなどに特定のサーバーを一時的に借りてサービ
スを行うものがある。
5.22 対策21:バックアップサイトによるサイトの分
散
更新系サービスであり、高リスク、高負荷な大規模サイトのような、ハイアベイラ
ビリティが特に重要視されるシステムでは、バックアップサイトによるサイトの分散
が行われている。つまり、通常時はメインサイトで処理を行い、バックアップサイト
では処理は行わないが、データベースは常にメインサイトと同期を取っておく。メイ
ンサイトが利用できなくなった場合には、そのデータを用いて、バックアップサイト
で処理を継続する。メインサイトからバックアップサイトへのデータの転送には、デ
ータベースのレプリケーション機能、SANなどストレージのリモートコピー機能など
の方法がある。
5.23 対策22:攻撃の検知とインシデントレスポンス
攻撃の検知は、高リスクの大規模サイトで特に重要である。攻撃の検知技術として
は下記がある。
オペレータによるトラフィックと装置の監視
通信機器、サーバーの監査ログのチェック
IDS(Intrusion Detection System:侵入検知システム)によるトラフィックの監視
ストレージの変更検出ツール
トラフィックと装置の監視を行うことは、特に24時間365日運転のシステムでは、攻
撃や故障を迅速に発見し、対処するために重要である。トラフィック量の監視が、DoS
攻撃を検知する基本的な手段である。
ただし、ISP接続でのトラフィックだけを監視していても、特定サーバー、特定セグ
メントへのDoS攻撃は検知できない。例えば、ISP接続が100Mbpsでは、そのトラフィ
ックの変化を見ていても、特定インターネットサーバー向けの1.5MbpsのDoS攻撃は小
39
機器や人的資源などのコンピュータ・リソースを必要な時に必要なだけ提供するサービス。
Copyright © 2003 IPA, All Rights Reserved.
5-20
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
さ過ぎて検知できないからだ。トラフィックを各ルータで監視し、セグメント間のト
ラフィックの異常を確実に検知することが必要である。
BGPなどのルーティングプロトコルには脆弱性がある。複数のISP接続があった場合、
攻撃によって影響を受ける可能性がある。例えば、ルートフラップ攻撃では、2つのISP
接続から異なる2つのルーティング情報が交互に送られて来てルーティング情報が混
乱する。この混乱により、パケットの到着のジッター(ディレイのゆらぎ幅)が大き
くなる。つまり、あるときはパケットがすぐ到着し、あるときには到着が遅れる。到
着のディレイを元にチューニングしているようなアプリケーションでは、パフォーマ
ンスに大きな影響が受ける。このような異常もトラフィックの監視によって発見する
ことができる。発見した際はISPへの連絡と対処の依頼が必要である。
通信機器での監査ログは大量になる。このログをどう監視するかが課題である。ロ
グの監視には下記の手段がある。
ログをフィルタし、重要なイベントのみ、管理者へ送信する。
IDSを用いる。
外部のログ解析サービスを用いる。
初めの2つはリアルタイムな対策として、最後は、不正アクセスのターゲットになっ
ていないかの監視のためである。
DoS攻撃などの検知には、IDSの導入という手段もある。IDSには、下記のような課
題がある。
IDSはまだ発展途上の技術であり、製品毎に検出できる攻撃が異なっている。
異常検出時に取るべき対策がはっきりしない。
つまり、トラフィックに応じた性能のIDSを複数製品導入でき、異常検出時に適切な
対策を採るためのノウハウがあれば、IDSも有効であると言える。
IDSを導入する場合は、誤検知や、検知漏れを防ぐために、定期的にチューニングを
行う必要がある。
不正アクセスの証拠隠滅のために、攻撃者は攻撃の後、証拠(ログ)を削除しよう
とする。貴重な取引データなども含め、ログを削除や改善から保護する対策も重要で
ある。重要なログはリアルタイムで別のサーバーや外部媒体へバックアップすると安
全である。CD-Rのような一度しか書き込めない媒体に出力するとそれ以上書き換えが
できず、より安全である。
不正アクセスを検出するためには、ストレージの変更検出ツールを利用するのが便
利である。フリーのツールや製品が利用可能である。
Copyright © 2003 IPA, All Rights Reserved.
5-21
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
DoS攻撃などのサービス妨害攻撃をインターネットから受けた場合には、ISP側でも
攻撃元を特定し、攻撃元との接続の切断などの対策を、迅速に行ってもらう必要があ
る。そのためにも、ISPとの連絡方法、ISPとの責任分担、取りうる対策などを契約に含
め、協議しておく必要がある。また、サービス妨害攻撃に対するISP側の対応や、技術
レベルについて評価し、ISPを選択することも重要である。もちろん攻撃元の特定は、
今日まだ研究途上の技術であり、必ずしも特定できない場合があることは、理解して
おく必要がある。サイトでこういった手続きをインシデントレスポンスマニュアルと
してまとめることは、どのサイトでも行うべきことである。
監視に関しては、中小規模サイトでは24時間実施するのは困難なため、監視サービ
スなど外部に委託するのが通常である。
最後に、長期休暇の後は特にDoS攻撃が増える傾向がある。これは、攻撃者が長期休
暇の間に、新しい不正アクセスの手口を考案したり、新しいウイルスを作成したりす
るからである。また、インターネット上の大きなイベントを妨害するようなDoS攻撃も
ある。このため、長期休暇の後や大きなインターネットイベント開催時は特に監視を
強化する必要がある。
5.24 サーバー構築でのハイアベイラビリティ技術選
択の観点のまとめ
セキュリティ対策の一般的な考え方を元に、サーバー構築でのハイアベイラビリテ
ィ技術選択で重要な観点をまとめる。セキュリティ対策の考え方は次の点である。
予防と低減
抑止
検知
回復
セキュリティ対策での1番目の考え方は、被害の予防と低減、つまりリスクの分散で
ある。この観点から、ハイアベイラビリティの確保でも、単点障害の除去が有効であ
る。
単点障害を防止するためには、Webサーバー、NIC、ロードバランサー、ファイアウ
ォール、ISPへの接続、サイトなど各種のレベルでの多重化が有効である。その中でも、
今日のDoS攻撃の多くに対しては、複数ISPへの接続が、一番効果があると考えられる。
Copyright © 2003 IPA, All Rights Reserved.
5-22
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
5 サービス妨害攻撃に関する対策とその強度、脆弱性
DoS攻撃の特性を考えると、サイトのリソースを攻撃者が想定しているよりも多く確
保しておくという対策も有効である。十分なリソースがあれば、予防策になる。
2番目は、攻撃の抑止である。そもそもDoS攻撃にあわないこと、攻撃者から狙われ
ないようにすることも有効である。DoS攻撃も含め、不正アクセスすべてに言えること
だが、サイトの脆弱性に関する情報がなければ攻撃者が攻撃を成功させることは難し
い。能ある鷹は爪を隠すという。サイトに関する情報や、サイトが行っているセキュ
リティ対策が外部から分からないようにする対策も重要である。
3番目はDoS攻撃の検知と機器の故障の検知である。DoS攻撃を検知するにはトラフ
ィックを監視し、異常を検出する。また、検知した場合に、ISPへ連絡を取るなどイン
シデントレスポンスでの手続きを確立しておくことも今日、必要になってきている。
機器の故障に対しても、代替機の確保、修理などを行うアクションを取るため、各レ
ベルでの確実な動作の監視が重要である。
4番目は攻撃や故障後のデータの回復である。データを確実に回復するにはデータの
バックアップとリストアに関する対策が欠かせない。バックアップは手間がかかる。
確実なバックアップには自動化が望ましい。リストアは確実に行えるかをあらかじめ
テストしておく必要がある。
5.25 参考資料
本章での参考資料は以下である。
「The Twenty Most Critical Internet Security Vulnerabilities(Updated)The Experts’ Consensus Version 2.504」SANS Institute
Resources,2002.5
「The CERT Guide to System and Network Security Practices」Julia H.Allen,ADDISON WESLEY,2001.12
「アクティブディフェンス システム&ネットワーク完全防衛バイブル」クリス・ブレントン,キャメロン・ハント,
株式会社秀和システム,2002.6
「Web セキュリティ&コマース」Simson Garfinkel,Gene Spafford,O’REILLY,1998.1
Copyright © 2003 IPA, All Rights Reserved.
5-23
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6 サイトモデルから考えた対策
本章はこの調査報告書のまとめとして、これまで考えてきた対策をサイトモデル別
に分類する。まず、サイトモデルの考え方を説明した後、モデル別の対策セットを説
明していく。
6.1 サイトモデル
6.1.1
サイトモデルの考え方
セキュリティ対策を考える要素には次の2点がある。
リスクの度合い
対策の自由度
リスクはサイトの知名度や扱う情報の重要度によって変わる。例えば、停止すると
社会的影響が高いようなサイトや個人情報を扱うサイトは攻撃の対象になり易く、攻
撃にあった場合の被害も大きい。重要なサイトでは確実なセキュリティ対策を行う必
要がある。
対策の自由度としては、ネットワークやサーバー構成の自由度、対策費、とれる運
用体制の大きさといった要素がある。さらに、構成はインターネットサーバーで行う
業務が参照系か更新系か、また、負荷がインターネットサーバー1台で処理できる量か
複数台でしか処理できない量かで変わる。運用体制の人数や24時間365日監視できるか
などは、大規模サイトか小規模サイトかで変わる。
そこで、インターネットサーバーでのハイアベイラビリティ対策は次の4要素で考え
ることになる。
業務の特性(参照系か更新系か)
サイトのリスク
運用体制(大規模サイトか小規模サイトか)
負荷(1台で処理できるか複数台必要か)
(1)
業務の特性
インターネットサーバー(公開Webサーバー)で扱う業務の特性で変わる。インター
ネットサーバーで扱う業務が、参照系(静的コンテンツ配信)なら、分散方法は容易
である。しかし、更新系(予約サイトやショッピングサイト)であればサーバー間で
Copyright © 2003 IPA, All Rights Reserved.
6-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
データベースの共有が必要なため、地理的な分散は難しい。そのため、クラスタの導
入と、バックアップセンターの設置が必要になる。このような条件を考慮して、ハイ
アベイラビリティ対策を考えることが必要である。
(2)
サイトのリスク
リスクは攻撃の可能性、インターネットサーバーで扱う情報やサービスの価値、被
害の大きさで変わる。攻撃を考えると、まず有名サイトと無名サイトでは攻撃の目的
やレベルが異なる。有名サイト向けの攻撃は攻撃者の売名行為によるものが多い。売
名行為を狙う攻撃者は攻撃の技術レベルが高いといえる。攻撃の技術レベルが高いと
いうことは当然、被害もサイト全体に及ぶ可能性が高い。また、多くの攻撃者が有名
サイトを狙うため、攻撃に遭う可能性も高い。レベルが高い攻撃者はISPも狙う。一方、
無名な中小規模サイト向け攻撃は特別の目的があるものである。目的には、個人的な
恨みなどがある。特定の攻撃者が狙うため、中小規模サイトが攻撃に遭う可能性は一
般には低いと思われる。
(3)
運用体制(対策レベルの差)
一般的に、大規模サイトでは通常、十分な技術的対策や運用体制をとることができ
る。一方、中小規模サイトでは十分な技術的対策や運用体制をとることができない場
合が多い。中小規模サイトでは、さらに、回線の帯域幅が小さいため、サービス妨害
攻撃に本質的に弱いし、技術的・予算的な問題で、十分なセキュリティ対策を立てに
くい。このような制限の中で、どの対策を採るかを検討する必要がある。
(4)
負荷
インターネットサーバーのハイアベイラビリティ実現に必要な対策や構成は、イン
ターネットサーバーを1サイトに設置するのか複数サイトに設置するのかで大きく変
わる。システムがどちらの分類なのかを考えてから対策を検討する必要がある。業務
が拡大し、負荷が上がった場合、サーバー1台のまま性能を向上させるという手段と、
サーバー複数台で処理を分散するという手段の2通りがある。1台で処理すると管理が
容易である。複数台で処理すると、コストパフォーマンスが良くなる。管理とコスト
のどちらが重要かで選択肢が決まる。このように対策は、
負荷が低くサーバーが1台で処理ができる場合
負荷が高くサーバーが複数台でなくては処理ができない場合
で大きく異なる。どちらの種類かを考えて、対策を選ぶことが必要である。また、
負荷が低い場合は、通常、ある程度業務の中断は許されるが、高負荷のシステムでは、
通常、業務の中断は許されない。
Copyright © 2003 IPA, All Rights Reserved.
6-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.1.2
サイトモデルと対策レベルの考え方
以上のサイトモデルの考え方をまとめ、対策レベルは下記のように考えた。まず対
策の必要度を検討する際に、重視する項目の順序は以下のとおりとする。
① 更新系でのデータの損失(リスクの度合いを検討)
② サーバー故障への対応(リスクの度合いを検討)
③ パフォーマンスの向上(負荷のピークを検討)
④ 機器故障への対応(リスクの度合いを検討)
⑤ DoS攻撃への対応(リスクの度合いを検討)
この考え方を元に、サイトのリスクの度合い、負荷の度合いを考慮した対策レベル
は、更新系と参照系にてそれぞれ以下の表 6-1、表 6-2のように定義する。
表 6-1 リスク・負荷の度合いを考慮した対策レベル(更新系)
更新系
必要度
高
対策
重視点
①データのバックアップ
データの損失
②サーバーの多重化
サーバー故障
③通信帯域幅の増強
パフォーマンス
④ネットワーク機器の冗長化
機器故障
(DNS、ファイアウォール、ロードバランサー)
⑤回線の冗長化
DoS 攻撃
⑥複数 ISP の利用
低
⑦バックアップサイト
表 6-2 リスク・負荷の度合いを考慮した対策レベル(参照系)
参照系
必要度
高
対策
重視点
①サーバーの多重化
サーバー故障
②通信帯域幅の増強
パフォーマンス
③ネットワーク機器の冗長化
機器故障
(DNS、ファイアウォール、ロードバランサー)
④データのバックアップ
データの損失
⑤回線の冗長化
DoS 攻撃
⑥複数 ISP の利用
低
⑦サイトの分散(CDN)
Copyright © 2003 IPA, All Rights Reserved.
6-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
また、対策に必要な費用や、運用体制を考慮した対策レベルは、以下の表 6-3のよう
に定義する。
表 6-3 費用・運用体制を考慮した対策レベル
費用
安
体制
小規模
①アウトソーシング
高
大規模
②運用の自動化
6.1.3
対策
分類のまとめ
以上のサイトモデルの考え方をまとめると、サイトは表 6-4に示すように、16タイプ
に分類される。
表 6-4 サイトの分類
タイプ
1
更新・参照
更新系
リスク
高リスク
運用体制
負荷
高負荷
大規模
サイトの例
大規模ミッションクリティカルサ
イト(高負荷)
低負荷
2
大規模ミッションクリティカルサ
イト(低負荷)
高負荷
小規模
3
ミッションクリティカル EC サイト
(高負荷)
4
低リスク
5
大規模
6
小規模
7
8
低負荷
小規模 EC サイト(低負荷)
高負荷
高負荷ポータルサイト案 A
低負荷
低負荷ポータルサイト
高負荷
高負荷ポータルサイト案 B
低負荷
企業のポータルサイト(コスト重
視)案 A
9
参照系
高リスク
大規模
高負荷
広域ミッションクリティカルコン
テンツ配信(高負荷)
10
小規模
11
低負荷
コンテンツ配信(低負荷)
高負荷
ミッションクリティカルコンテン
ツ配信(高負荷)
12
13
低リスク
大規模
14
低負荷
無停止が望まれるサイト案 A
高負荷
コンテンツ配信(コスト重視)
低負荷
無停止が望まれるサイト案 B
Copyright © 2003 IPA, All Rights Reserved.
6-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
タイプ
更新・参照
リスク
運用体制
高負荷
小規模
15
負荷
サイトの例
企業のポータルサイト(コスト重
視)案 B
低負荷
16
小規模企業のポータルサイト
6.2 分類別対策
本節では、16タイプのシステムでの対策のポイントを順に説明していく。なお、こ
のタイプ毎の対策は典型的なサイトの例であり、必ずしもすべてのサイト構築に有効
な方法であるとは限らない。
6.2.1
タイプ1:大規模ミッションクリティカルサイト(高負荷)設計
タイプ1は、更新系高リスク大規模高負荷サイトである。例えばこのタイプのシステ
ムは、有名ショッピングサイト、オンライン金融取引システムの中でも負荷が集中す
るもの(オンライントレード)などである。このようなシステムはリスクが高いため
リスクの分散が必要だが、更新系なのでシステムを広域分散するのが難しい。
このサイトの特徴としては、リスクが高いので、災害などに関する対策として、メ
インサイトのほかにバックアップサイトを置く点である。この2つを東日本と西日本に
分けて設置するなど、地震などの広域災害にも備える。メインセンターが利用できな
い場合やメインサイトでシステムの変更が必要な場合は、処理をバックアップサイト
へ移す。データはデータベースのレプリケーション機能を用いてメインサイトからバ
ックアップサイトへコピーしておく。バックアップサイトの処理能力はメインサイト
の50%程度でもよい場合がある。
今後データベースを分散する技術が進歩すれば、バックアップサイトとの分散処理
も考えられる。しかしコストはかかるだろう。
更新系システムなので、ストレージの可用性確保やデータのバックアップの自動化
も重要である。サイトが攻撃に遭う可能性は高いので、ロードバランスも含め、攻撃
に関する対策に重点を置いて行う。また機器の接続回線も二重化する。図 6-1に、大規
模ミッションクリティカルサイト(高負荷)の対策モデルを示す。
Copyright © 2003 IPA, All Rights Reserved.
6-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
インターネット
ISP1
ISP2
大容量
大容量
ルータ
ルータ
ロードバランサー
ロードバランサー
ファイア
ウォール
ファイア
ウォール
DNS
DNS
クラスタ
ストレージ
監視端末
インターネット
サーバー
データ回線
インターネット
サーバー
クラスタ
ストレージ
バックアップ装置
バックアップ装置
監視端末
東日本
西日本
メインサイト
バックアップサイト
図 6-1 大規模ミッションクリティカルサイト(高負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-6
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-5 タイプ 1 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
○
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
○
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
○
5
複数サーバーへの処理の分散
−
16
回線の多重化
○
6
サーバーへのヘルスチェック
○
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
○
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
○
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
○
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
○
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-7
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.2
タイプ2:大規模ミッションクリティカルサイト(低負荷)設計
タイプ2は、更新系高リスク大規模低負荷サイトである。例えばこのタイプは、有名
ショッピングサイト、オンライン金融取引システムなどの中でも負荷が集中しないも
の(オンラインバンキング)である。通常、バックアップサイトの処理能力は限られ
ていてもよいし、業務の中断もある程度許される。バックアップサイトへのデータ転
送もバッチでもよい場合もある。更新系システムなので、ストレージの可用性確保や
データのバックアップの自動化もある程度重要である。サイトが攻撃に遭う可能性は
高いので、攻撃に関する対策に重点を置いて行う。図 6-2に、大規模ミッションクリテ
ィカルサイト(低負荷)の対策モデルを示す。
インターネット
ISP1
ISP2
ルータ
ルータ
ロード
バランサー
ファイア
ウォール
ファイア
ウォール
DNS
DNS
データ回線
インターネット
サーバー
クラスタ
ストレージ
監視端末
インターネット
サーバー
ストレージ
バックアップ装置
バックアップ装置
監視端末
東日本
西日本
メインサイト
バックアップサイト
図 6-2 大規模ミッションクリティカルサイト(低負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-8
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-6 タイプ 2 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
○
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
○
6
サーバーへのヘルスチェック
○
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
○
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
○
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
○
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
○
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-9
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.3
タイプ3:ミッションクリティカルECサイト(高負荷)設計
タイプ3は、更新系高リスク小規模高負荷サイトである。例えばこのタイプは、歴史
が浅い組織でインターネット系ビジネスをスタートさせるような場合である。高リス
クな更新系システムを少ない人数で運用するのは危険である。基本的に運用を外部委
託するのが安全である。
また、データを確実にバックアップするため、バックアップ設備を自社に保有する、
遠隔バックアップを行うなどもビジネスの継続上非常に重要である。図 6-3に、ミッシ
ョンクリティカルECサイト(高負荷)の対策モデルを示す。
インターネット
ISP1
ISP2
大容量
大容量
バックアップ媒体
ルータ
ロードバランサー
遠隔サイト
ファイアウォール
DNS
インター
ネット
クラスタ
インターネットサーバー
自社監視端末
ストレージ
バックアップ装置
データ回線
ストレージ
バックアップ装置
自社
監視端末
iDC
図 6-3 ミッションクリティカル EC サイト(高負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-10
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-7 タイプ 3 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
△
12
QoS 制御
△
2
サービス毎のサーバーの分離
△
13
十分な通信帯域の確保
△
3
インターネットサーバーの脆弱性
△
14
ネットワーク(回線)の分離
△
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
△
5
複数サーバーへの処理の分散
−
16
回線の多重化
△
6
サーバーへのヘルスチェック
△
17
ストレージの信頼性確保
○
7
DNS の冗長化
△
18
バックアップ
○
8
通信機器自身に関するセキュリティ
△
19
ログ用ストレージ容量確保
△
対策
9
複数 ISP(プロバイダ)の利用
△
20
インターネットサーバーの広域分散
−
10
外部委託の評価
○
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
△
22
攻撃の検知と
△
インシデントレスポンス
△:外部委託先にて実施
Copyright © 2003 IPA, All Rights Reserved.
6-11
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.4
タイプ4:小規模ECサイト(低負荷)設計
タイプ4は更新系高リスク小規模低負荷サイトである。例えばこのタイプは、歴史が
浅い組織でインターネット系ビジネスをスタートさせるような場合、公共の入札シス
テムなどである。システムが低負荷であれば、少ない人数である程度運用することも
可能であるかもしれない。しかし、更新系なので、データのバックアップが重要であ
る。また、高リスクなので、回線の二重化や、常時確実な監視を行うことが重要であ
る。回線を二重化する際にVRRP、HSRPを利用する場合には、ISPと協調が必要となる。
少ない人数で運用するため、データのバックアップの自動化、監視の外部委託などが
効率的である。図 6-4に、小規模ECサイト(低負荷)の対策モデルを示す。
インターネット
ISP1
ISP2
ルータ
ロードバランサー
ファイアウォール
DNS
バックアップ ストレージ
装置
クラスタ
インターネットサーバー
監視端末
図 6-4 小規模 EC サイト(低負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-12
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-8 タイプ 4 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
○
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
○
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
○
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
○
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-13
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.5
タイプ5:高負荷ポータルサイト案A設計
タイプ5は更新系低リスク大規模高負荷サイトである。例えばこのタイプのシステム
は人気の高いオンラインゲームサイトなどがある。このタイプはリスクが低いので、
バックアップサイトを置かない。また、高負荷であるが、低リスクなのでファイアウ
ォールは設置しない。その代わりインターネットサーバーの不正アクセス対策を確実
に行う。更新系システムなので、クラスタリングの利用とストレージの可用性確保や
データのバックアップの自動化も重要である。
クラスタリング技術では、密結合の共有ディスクタイプが一般的に利用されている。
クラスタサーバーの規模は、トラフィック量等を考慮して、定常的に安定して処理で
きるようなCPU数を検討する必要がある。
また、セキュリティ確保にはCDNなどに依頼すると安心である。図 6-5に、高負荷ポ
ータルサイト案Aの対策モデルを示す。
インターネット
ISP1
ISP2
大容量
大容量
ルータ
DNS
バックアップ ストレージ
装置
監視端末
クラスタ
インターネットサーバ
図 6-5 高負荷ポータルサイト案 A のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-14
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-9 タイプ 5 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
○
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
○
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
○
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-15
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.6
タイプ6:低負荷ポータルサイト設計
タイプ6は、更新系低リスク大規模低負荷サイトである。このタイプは例えば、オン
ラインゲームサイトなどがある。低負荷なので大規模なクラスタリングは必要ない。
大規模サイトで費用があれば、不正アクセスを排除するためにファイアウォールを導
入することが望まれる。また、更新系システムなので、ストレージの可用性確保やデ
ータのバックアップは重要である。図 6-6に、低負荷ポータルサイトの対策モデルを示
す。
インターネット
ISP
ルータ
ファイアウォール
DNS
バックアップ ストレージ
クラスタ
装置
インターネットサーバ
監視端末
図 6-6 低負荷ポータルサイトのモデル
Copyright © 2003 IPA, All Rights Reserved.
6-16
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-10 タイプ 6 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
○
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-17
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.7
タイプ7:高負荷ポータルサイト案B設計
タイプ7は、更新系低リスク小規模高負荷サイトである。例えばこのタイプのシステ
ムは、有料音楽配信システムなどの、ある程度利用者は限られているが、扱うデータ
が大きなインターネットシステムである。このようなシステムでは、高リスクシステ
ムに比べ、ある程度システムの停止は許容できるため、バックアップセンターの設置
はしない。また、高負荷であるが、低リスクなのでファイアウォールは設置しない。
しかし、更新系システムなので、クラスタリングを利用し、ストレージの可用性確保
やデータのバックアップの自動化も重要である。サイトが攻撃に遭う可能性は高いの
で、攻撃について可能な対策はできるだけ行う。図 6-7に、高負荷ポータルサイト案B
の対策モデルを示す。
インターネット
ISP
大容量
ルータ
DNS
バックアップ ストレージ
装置
監視端末
クラスタ
インターネットサーバー
図 6-7 高負荷ポータルサイト案 B のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-18
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-11 タイプ 7 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
○
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
○
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
−
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-19
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.8
タイプ8:企業のポータルサイト(コスト重視)案A設計
タイプ8は、更新系低リスク小規模低負荷サイトである。例えばこのタイプのシステ
ムは、ある程度利用者が限られた企業のポータルサイトなどがある。このようなシス
テムでは、低負荷システムなので、高負荷システムに比べ、ある程度システムの停止
は許容できる。しかし、更新系システムなので、ストレージの可用性確保やデータの
バックアップの自動化も重要である。図 6-8に、企業のポータルサイト(コスト重視)
の対策モデルを示す。
インターネット
ISP
ルータ
DNS
バックアップ ストレージ
インターネットサーバー
装置
監視端末
図 6-8 企業のポータルサイト(コスト重視)のモデル案 A
Copyright © 2003 IPA, All Rights Reserved.
6-20
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-12 タイプ 8 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
−
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
−
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-21
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.9 タイプ9:広域ミッションクリティカルコンテンツ配信サイト(高
負荷)設計
タイプ9は、参照系高リスク大規模高負荷サイトである。ミッションクリティカルと
は停止が許されないサイトである。サービス毎にシステム停止の許容範囲は異なるが、
ランニングコストや、サイト運営で回収できる費用を考慮して可能な範囲を検討する
必要がある。例えばこのタイプのシステムは、有名ダウンロードサイト、放送局、有
名ニュースサイトなどがある。このようなシステムはリスクが高いためリスクの分散
が有効である。キャッシュサーバーを用いたネットワーク的、地理的な分散が必要で
ある。サイトが攻撃に遭う可能性は高いので、ロードバランスも含め、攻撃に関する
対策に重点を置いて行う。図 6-9に、広域ミッションクリティカルコンテンツ配信サイ
ト(高負荷)の対策モデルを示す。
東京サイト
大阪サイト
広域対応
ロードバランサー
大容量
ISP4
ISP3
大容量
インターネット
ISP2
ISP1
大容量
ニューヨーク
サイト
図 6-9 広域ミッションクリティカルコンテンツ配信サイト(高負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-22
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-13 タイプ 9 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
△
2
サービス毎のサーバーの分離
△
13
十分な通信帯域の確保
△
3
インターネットサーバーの脆弱性
△
14
ネットワーク(回線)の分離
△
対策
4
キャッシュサーバーの利用
△
15
NIC の冗長化
△
5
複数サーバーへの処理の分散
△
16
回線の多重化
△
6
サーバーへのヘルスチェック
△
17
ストレージの信頼性確保
△
7
DNS の冗長化
△
18
バックアップ
△
8
通信機器自身に関するセキュリティ
△
19
ログ用ストレージ容量確保
△
対策
9
複数 ISP(プロバイダ)の利用
△
20
インターネットサーバーの広域分散
△
10
外部委託の評価
○
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
△
22
攻撃の検知と
△
インシデントレスポンス
△:外部委託先にて実施
Copyright © 2003 IPA, All Rights Reserved.
6-23
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.10 タイプ10:コンテンツ配信サイト(低負荷)設計
タイプ10は、参照系高リスク大規模低負荷サイトである。例えばこのタイプは、有
名サイトの一部を受け持つサーバーなどである。このようなシステムは業務的な重要
性は低い場合もある。サイトが攻撃に遭う可能性は高いので、攻撃に関する対策に重
点を置いて行う。セキュリティ対策を確実に行うには、CDNに預けることで、運用コ
ストが抑えられる。CDNを利用しない場合は、専任の担当者をおき、セキュリティポ
リシーの策定や、サーバーのOS・アプリケーション等のパッチの適用、関連するセキ
ュリティ問題の調査などのセキュリティ対策を確実に行うことが必要である。また、
キャッシュサーバーへの負荷分散はDNSのラウンドロビンで実現する。図 6-10に、コ
ンテンツ配信サイト(低負荷)の対策モデルを示す。
インターネット
ISP
ルータ
DNS
キャッシュサーバー
バックアップ装置 ストレージ
監視端末
インターネットサーバー
図 6-10 コンテンツ配信サイト(低負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-24
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-14 タイプ 10 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
○
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
○
16
回線の多重化
−
6
サーバーへのヘルスチェック
○
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
○
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-25
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.11 タイプ11:ミッションクリティカルコンテンツ配信(高負荷)サ
イト設計
タイプ11は、参照系高リスク小規模高負荷サイトである。例えばこのタイプは、試
験の合格発表、宝くじの当選番号発表などの一時的にアクセスが集中するサイトであ
る。このようなシステムはリスクが高いためリスクの分散が有効である。キャッシュ
サーバーを用いたネットワーク的、地理的な分散が必要である。サイトが攻撃に遭う
可能性は高いので、ロードバランスも含め、攻撃に関する対策に重点を置いて行う。
サイトの運用をCDNに委託するのがコスト的に有利である。委託先業者の評価を十分
に行い、安心できる委託先に頼むことが一番である。図 6-9に、ミッションクリティカ
ルコンテンツ配信サイト(高負荷)の対策モデルを示す。
大阪サイト
東京サイト
広域対応
ロードバランサー
ISP2
ISP1
インターネット
図 6-11 ミッションクリティカルコンテンツ配信サイト(高負荷)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-26
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-15 タイプ 11 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
△
2
サービス毎のサーバーの分離
△
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
△
14
ネットワーク(回線)の分離
△
対策
4
キャッシュサーバーの利用
△
15
NIC の冗長化
△
5
複数サーバーへの処理の分散
△
16
回線の多重化
△
6
サーバーへのヘルスチェック
△
17
ストレージの信頼性確保
△
7
DNS の冗長化
△
18
バックアップ
△
8
通信機器自身に関するセキュリティ
△
19
ログ用ストレージ容量確保
△
対策
9
複数 ISP(プロバイダ)の利用
△
20
インターネットサーバーの広域分散
△
10
外部委託の評価
○
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
△
22
攻撃の検知と
△
インシデントレスポンス
△:外部委託先にて実施
Copyright © 2003 IPA, All Rights Reserved.
6-27
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.12 タイプ12:無停止が望まれるサイト案A設計
タイプ12は、参照系高リスク小規模低負荷サイトである。例えばこのタイプには、
アクセスは少ないがサイトが著名な、官公庁などのサイト、情報セキュリティベンダ
などがある。最も基本的な構成といえる。機器の冗長化により、バックアップ機の準
備や監視の充実が効果的である。監視にはアウトソーシングという手段もある。図 6-12
に、無停止が望まれるサイト案Aの対策モデルを示す。
インターネット
ISP
ルータ
ファイアウォール
バックアップ機
DNS
バックアップ装置 ストレージ
インターネットサーバー
監視端末
図 6-12 無停止が望まれるサイト案 A のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-28
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-16 タイプ 12 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
−
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
○
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-29
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.13 タイプ13:コンテンツ配信サイト(コスト重視)設計
タイプ13は、参照系低リスク大規模高負荷サイトである。例えばこのタイプのシス
テムは、ダウン時の影響が少ないダウンロードサイトなどである。キャッシュサーバ
ーを用いた処理の分散などが効果的である。図 6-13に、コンテンツ配信サイト(コス
ト重視)の対策モデルを示す。
インターネット
ISP
大容量
ルータ
DNS
ロードバランサー
キャッシュサーバー
バックアップ ストレージ
装置
インターネットサーバー
監視端末
図 6-13 コンテンツ配信サイト(コスト重視)のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-30
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-17 タイプ 13 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
○
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
○
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
○
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
○
16
回線の多重化
−
6
サーバーへのヘルスチェック
○
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
○
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-31
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.14 タイプ14:無停止が望まれるサイト案B設計
タイプ14は、参照系低リスク大規模低負荷サイトである。例えばこのタイプのシス
テムは、アクセスが少ない大規模な企業のサイトである。大規模サイトで費用があれ
ば、不正アクセスを排除するためにファイアウォール、管理を容易にするために複数
サーバーへの処理の分散や、ロードバランサーを導入することが望まれる。図 6-14に、
無停止が望まれるサイト案Bの対策モデルを示す。
インターネット
ISP
ルータ
DNS
ファイアウォール
ロードバランサー
バックアップ ストレージ
装置
インターネットサーバー
監視端末
図 6-14 無停止が望まれるサイト案 B のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-32
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-18 タイプ 14 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
○
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
○
16
回線の多重化
−
6
サーバーへのヘルスチェック
○
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
○
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-33
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.15 タイプ15:企業のポータルサイト(コスト重視)案B設計
タイプ15は、参照系低リスク小規模高負荷サイトである。例えばこのタイプのシス
テムは、天気予報サイトなどアクセスが多いサイト、最近できてきた監視サイトなど
扱うデータが大きいサイト、小規模な企業のホームページなどで、アクセスが多いも
のである。サイトの運用を外部に委託するのがコスト的に有利である。委託先業者の
評価を十分に行い、安心できる委託先に頼むことが一番である。図 6-15に、企業のポ
ータルサイト(コスト重視)案Bの対策モデルを示す。
インターネット
ISP1
大容量
ISP2
大容量
ルータ
DNS
ロード
バランサー
キャッシュ
サーバー
インター
ネット
自社監視端末
インターネット
サーバー
監視端末
バックアップ
装置
ストレージ
iDC
図 6-15 企業のポータルサイト(コスト重視)案 B のモデル
Copyright © 2003 IPA, All Rights Reserved.
6-34
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-19 タイプ 15 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
△
2
サービス毎のサーバーの分離
△
13
十分な通信帯域の確保
△
3
インターネットサーバーの脆弱性
△
14
ネットワーク(回線)の分離
△
対策
4
キャッシュサーバーの利用
△
15
NIC の冗長化
△
5
複数サーバーへの処理の分散
△
16
回線の多重化
△
6
サーバーへのヘルスチェック
△
17
ストレージの信頼性確保
△
7
DNS の冗長化
△
18
バックアップ
△
8
通信機器自身に関するセキュリティ
△
19
ログ用ストレージ容量確保
△
対策
9
複数 ISP(プロバイダ)の利用
△
20
インターネットサーバーの広域分散
−
10
外部委託の評価
○
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
△:外部委託先にて実施
Copyright © 2003 IPA, All Rights Reserved.
6-35
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
6.2.16 タイプ16:小規模企業のポータルサイト設計
タイプ16は、参照系低リスク小規模低負荷サイトである。例えばこのタイプのシス
テムは、小規模企業のホームページなどで、参照が少ないものである。基本的な管理
策を立てるとよい。運用体制が小規模なら、監視やサイトの運用を外部に委託するの
がコスト的に有利である。委託先業者の評価を十分に行い、安心できる委託先に頼む
ことが一番である。図 6-16に、小規模企業のポータルサイトの対策モデルを示す。
インターネット
ISP
ルータ
バックアップ機
DNS
インターネットサーバー
監視端末
バックアップ ストレージ
装置
図 6-16 小規模企業のポータルサイトのモデル
Copyright © 2003 IPA, All Rights Reserved.
6-36
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
6 サイトモデルから考えた対策
表 6-20 タイプ 16 でのセキュリティ対策の採用例
対策
対策
採否
No.
対策
対策
採否
No.
1
クラスタリング
−
12
QoS 制御
−
2
サービス毎のサーバーの分離
○
13
十分な通信帯域の確保
−
3
インターネットサーバーの脆弱性
○
14
ネットワーク(回線)の分離
−
対策
4
キャッシュサーバーの利用
−
15
NIC の冗長化
−
5
複数サーバーへの処理の分散
−
16
回線の多重化
−
6
サーバーへのヘルスチェック
−
17
ストレージの信頼性確保
○
7
DNS の冗長化
○
18
バックアップ
○
8
通信機器自身に関するセキュリティ
−
19
ログ用ストレージ容量確保
○
対策
9
複数 ISP(プロバイダ)の利用
−
20
インターネットサーバーの広域分散
−
10
外部委託の評価
−
21
バックアップサイトによるサイトの
−
分散
11
ファイアウォールの導入
−
22
攻撃の検知と
−
インシデントレスポンス
Copyright © 2003 IPA, All Rights Reserved.
6-37
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
7 まとめ
7 まとめ
以上、インターネットサーバーでのハイアベイラビリティ技術とその選択の指針を
説明してきた。
1章 サーバーのハイアベイラビリティ技術では、更新系サイトのハイアベイラビリ
ティ技術としてクラスタリング、フォールト・トレラント・サーバーが利用されてい
ること、また、参照系サイトではロードバランサーでの負荷分散が有効であることを
説明した。さらに大規模な参照系サイトの場合に特に効果的な、CDNや広域ロードバ
ランサーの必要性について説明した。
2章 ネットワークのハイアベイラビリティ技術では、OSI参照モデルにおける各レイ
ヤ毎の安全性向上のための技術について説明した。レイヤ1では、信頼性の高いネット
ワーク・インフラの設計、レイヤ2では、ブロードキャスト・トラフィック制御技術と
して、STPやリンクアグリゲーションについて説明した。レイヤ3ではルーティング技
術としてVRRP、ダイナミックルーティングプロトコル、マルチホーミングについて説
明した。今後は、レイヤ4∼7におけるアプリケーション層での認識・管理機能が必要
であり、より高度なハイアベイラビリティ確保技術の開発が期待される。
3章 ストレージのハイアベイラビリティ技術では、RAID、SAN、NASなどのストレ
ージ技術と、主なバックアップ技術を説明した。ストレージはDASからNAS、NASか
らSANやiSCSIへと技術が進んでいる。将来は、iSCSIによるNAS・SANの統合、SANベ
ースでのNASの利用技術が発展すると思われる。特に更新系サイトでは、確実にバッ
クアップを取得することが重要である。用途と予算に合わせて最適な技術を選択する
必要がある。
4章 サービス妨害攻撃では、分類別のDoS攻撃の概要と対策を説明した。また主な
DoS攻撃の手法の詳細を説明した。現在では、少なくても数千種類の攻撃手法が開発さ
れており、今後も増加し続けると思われる。本調査報告書ではその一部を説明したに
過ぎない。
5章ではサービス妨害攻撃に対する対策とその強度、脆弱性として、1章から4章の内
容を踏まえ、単点障害の除去や、DoS攻撃に対し十分に処理能力を確保することを目的
として、サービス妨害攻撃に対しての有効な技術をまとめた。
6章 サイトモデルから考えた対策では、サイトのタイプを業務の種類(更新系・参
照系)、サイトのリスク、運用体制の規模、負荷 の4つの要素にて分類し、5章で述べ
た対策の利用例をまとめた。
Copyright © 2003 IPA, All Rights Reserved.
7-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
7 まとめ
セキュリティ対策に共通に言えることだが、リスクの評価をきちんと行うことがま
ず重要である。リスク評価を行うとは、第一に、インターネットからのDoS攻撃やDDoS
攻撃の脅威やサイト内のサーバーや機器の故障などの脅威を認識し、それに応じて対
策すること、第二に、情報資産の価値に応じてセキュリティ対策を立てることである。
その上で、この調査報告書を参考にし、ビジネスの重要性と投資額、そして、その予
算の中でどの対策を選択するかをよく検討してほしい。
また、DoS攻撃の対策では、サイトの分散や、ISPの協力が欠かせない。ISP内での
DoS攻撃の防止、検知、低減、攻撃の停止や切断などの対策、サイトがDoS攻撃を受け
た場合にISPに対応を依頼できるサービスの充実が今後望まれる。また、技術的には攻
撃の検知や攻撃者の特定に対する技術、更新系サービスでのインターネットサーバー
の分散技術の充実が今後望まれる。
ISPに代表される通信事業者のセキュリティサービス拡充が進められると共に、各サ
イトのセキュリティ対策もバランスよく進められることで、インターネット全体の安
全性強化が図られていくだろう。
攻撃者
攻撃
サイト
ISP
ISP での攻撃防止
サイトの分散
ISP での攻撃検知
サイトでの攻撃検知
対応依頼
ISP での攻撃低減
ISP での攻撃への対策
(攻撃の停止・切断)
図 7-1 サービスの安定性のための対策
Copyright © 2003 IPA, All Rights Reserved.
7-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
8 索引
A
E
ACK .............................................................. 1-9
EIGRP..........................................................2-10
ACL............................................................. 1-18
EtherChannel ................................................ 2-6
ARP ............................................................... 1-8
F
ATM .............................................................. 2-4
FCIP................................................... 3-10, 5-17
B
FC-SW .......................................................... 3-7
BGP ....................................................1-25, 2-10
FIPS 140-1 ...................................................1-18
BGP-4.................................................1-25, 2-10
Fraggle 攻撃 ................................. 4-3, 4-8, 4-14
BIND ........................................................... 4-15
H
BPDU ............................................................ 2-5
HSM................................................... 3-24, 5-17
C
I
CDN ...................................................1-25, 5-19
ICMP............................................................. 1-8
CDS ............................................................. 1-26
ICMP リダイレクトを悪用した攻撃 .......4-10
CIFS .............................................................. 3-5
ICMP リダイレクトを利用した DoS 攻撃4-6
CRM ............................................................ 3-12
ICMP 攻撃.................................................... 4-8
CVCF ............................................................ 2-3
iDC...............................................................1-26
D
IDS...............................................................5-20
DAS............................................................... 3-4
IEEE802.1d................................................... 2-5
DDoS 攻撃........................................vi, 4-4, 4-8
IEEE802.1s ................................................... 2-5
DLT ............................................................. 3-18
IEEE802.1w.................................................. 2-5
DNS......................................................1-23, 5-1
IEEE802.3ad ................................................. 2-6
DNS キャッシュ ........................................ 1-29
IETF.............................................................. 2-9
DNS サーバー ............................................ 1-23
IIS FTP サーバーのバッファオーバーフロー
DNS スプーフィング ................................ 4-15
型 DoS 攻撃 ............................................4-19
DNS に対する DoS 攻撃 ............................. 4-6
In-band.......................................................... 3-9
DNS の冗長化 .....................................5-2, 5-10
IP ストレージ.............................................3-10
DNS の脆弱性を利用した DoS 攻撃 ....... 4-15
iSCSI............................................................3-10
DNS ポイズニング .................................... 4-15
iSCSI ストレージ.......................................5-17
DoS 攻撃......................................................... vi
IS-IS.............................................................2-10
DVA............................................................... 2-8
ISP............................................... 1-25, 5-1, 5-19
Copyright © 2003 IPA, All Rights Reserved.
8-1
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
J
RAID............................................. 3-1, 3-2, 5-16
RAID 0.......................................................... 3-2
JNSA ........................................................... 4-11
RAID 0+1.................................................... 3-2
L
RAID 1.......................................................... 3-2
Land 攻撃...................................................... 4-6
RAID 5.......................................................... 3-3
LDAP .......................................................... 1-17
RAIT ............................................................3-20
LSA ............................................................... 2-8
RDBMS ........................................................ 1-2
LTO ............................................................. 3-18
RFC2176....................................................... 2-9
M
RFC2222......................................................1-17
RFC2246......................................................1-11
MSTP ............................................................ 2-5
RFC2251......................................................1-17
MTBF ............................................................ 2-2
RFC2256......................................................1-17
N
RFC2338....................................................... 2-7
RFC2865......................................................1-17
NAS.............................................. 3-4, 3-5, 3-12
RFC3347......................................................3-10
NAT ............................................................... 1-7
RFC792......................................................... 1-8
NFS ............................................................... 3-5
RIP ....................................................... 2-8, 2-10
NIC.......................................................1-3, 5-16
NIC および回線 ........................................... 5-1
RSTP............................................................. 2-5
NIC の冗長化 ......................................5-3, 5-15
S
O
SAN ...................................3-4, 3-12, 5-17, 5-20
OSI 参照モデル............................................ 2-1
SmartTRUNK ............................................... 2-6
Smurf 攻撃 ................................... 4-3, 4-8, 4-13
OSPF ......................................................2-8, 2-9
Sorry サーバー............................................1-22
OS やアプリケーションの脆弱性を利用した
Spanning Forest ............................................ 2-5
攻撃........................................................... 4-6
SPOF............................................... 1-4, 2-4, 5-1
Out-of-band ................................................... 3-9
SSL ..............................................................1-11
P
SSL アクセラレータ..................................1-18
Per Vlan Spanning Tree................................. 2-5
Stacheldraht 攻撃.........................................4-17
PTR レコードスプーフィング................. 4-15
STP ............................................................... 2-4
Q
T
QoS.............................................................. 1-20
TCP SYN フラッド攻撃 .......4-3, 4-6, 4-8, 4-9,
QoS 制御..............................................5-3, 5-14
4-14
Teardrop 攻撃 ...................................... 4-6, 4-18
R
TFN2K 攻撃 ................................................4-17
RADIUS ...................................................... 1-17
TFN 攻撃...................................................... 4-8
Copyright © 2003 IPA, All Rights Reserved.
8-2
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
オンラインバックアップ..........................3-24
Tribe フラッドネットワーク.................... 4-16
Trinoo 攻撃 ................................................. 4-16
か
U
カーネルパニック攻撃............. 4-5, 4-10, 4-17
UplinkFast ..................................................... 2-5
回線の多重化 ..................................... 5-3, 5-16
UPS ............................................................... 2-3
階層型ストレージ管理..............................3-24
外部委託の評価 ................................. 5-3, 5-12
W
仮想ストレージ .......................................... 3-8
Web サーバー............................................. 1-21
カプセリング .............................................3-10
WinTrinoo ..................................................... 4-8
き
WinTrinoo 攻撃 .......................................... 4-17
WORM ........................................................ 3-18
キャッシュサーバー..................................1-23
WWN ............................................................ 3-7
キャッシュサーバーの利用................ 5-2, 5-8
キャッシュポイズニング..........................4-15
あ
旧 DEC ......................................................... 2-5
アクティブ/アクティブ型 .......................... 1-3
業務の特性 .................................................. 6-1
アクティブ/スタンバイ .............................. 1-1
共有ディスク .............................................. 1-2
アクティブ/スタンバイ型 .......................... 1-3
く
アダプティブ RAID ...........................3-4, 5-17
アドレス・アグリゲーション方式 ........... 1-3
クッキー .....................................................1-11
アプライアンス型 ..................................... 1-16
インサート .............................................1-12
アプリケーション層 ..........................2-1, 2-11
パッシブ .................................................1-12
リライト .................................................1-12
い
クラスタ ............................................... 1-1, 1-5
インターネットサーバー ........................... 5-1
クラスタリング ............................ 1-1, 5-2, 5-4
インターネットサーバーの広域分散 ...... 5-3,
こ
5-19
インターネットサーバーの脆弱性対策 .. 5-2,
広域ロードバランスの方式
DNS 方式 ................................................1-27
5-5
HTTP リダイレクト方式 ......................1-28
う
攻撃の検知とインシデントレスポンス...5-3,
運用体制....................................................... 6-2
5-20
お
コリジョン .................................................. 2-1
オートローダー ......................................... 3-20
さ
オフサイトバックアップ ......................... 3-22
サーバーへのヘルスチェック............ 5-2, 5-9
オンライン・アーカイブ ......................... 3-24
サーバーレスバックアップ......................3-26
オンラインアップグレード ....................... 3-4
サービス毎のサーバーの分離............ 5-2, 5-4
Copyright © 2003 IPA, All Rights Reserved.
8-3
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
す
サービス妨害攻撃 ....................................... 4-1
再帰検索機能............................................. 4-15
スイッチ ............................................... 2-1, 5-1
サイト........................................................... 5-1
スティッキー .............................................1-10
サイトのリスク ........................................... 6-2
ストリーム攻撃 .........................................4-19
サイトモデル
ストレージ .................................................. 5-1
企業のポータルサイト(コスト重視)案 A
ストレージに対するリソースの枯渇化..4-20
.....................................................6-4, 6-20
ストレージの信頼性確保.................. 5-3, 5-16
企業のポータルサイト(コスト重視)案 B
ストレージの脆弱性を利用した攻撃....... 4-6
.....................................................6-5, 6-34
スナップショット......................................3-23
広域ミッションクリティカルコンテンツ
スパニングツリー・プロトコル............... 2-4
配信(高負荷)..........................6-4, 6-22
スプールリーク .........................................4-18
高負荷ポータルサイト案 A ..........6-4, 6-14
せ
高負荷ポータルサイト案 B ..........6-4, 6-18
コンテンツ配信(コスト重視) ..6-4, 6-30
セッション維持 .........................................1-10
コンテンツ配信(低負荷) ..........6-4, 6-24
セッション層 .............................................. 2-1
小規模 EC サイト(低負荷).......6-4, 6-12
そ
小規模企業のポータルサイト ......6-5, 6-36
ゾーニング .................................................. 3-7
大規模ミッションクリティカルサイト
疎結合 .......................................................... 1-1
(高負荷)....................................6-4, 6-5
外付けディスクアレイ............................... 3-1
大規模ミッションクリティカルサイト
外付け RAID...............................................5-17
(低負荷)....................................6-4, 6-8
ソフトウェア RAID.................................... 3-3
低負荷ポータルサイト..................6-4, 6-16
た
ミッションクリティカル EC サイト(高負
荷) .............................................6-4, 6-10
帯域幅消費型 DoS 攻撃 ............................. 4-3
ミッションクリティカルコンテンツ配信
ダイナミックディフェンス WG ..............4-11
(高負荷)..................................6-4, 6-26
ダイナミックルーティングプロトコル... 2-7
無停止が望まれるサイト案 A ......6-4, 6-28
多重スパニングツリー............................... 2-5
無停止が望まれるサイト案 B ......6-4, 6-32
単点障害 ........................................ 1-4, 2-4, 5-1
し
ち
システム欠陥利用型 DoS 攻撃 ...........4-1, 4-4
チーミング ......................................... 1-3, 5-16
システムの欠陥利用型攻撃 ..................... 4-17
直接の DoS 攻撃 ......................................... 4-4
システムの欠陥を狙った攻撃 ................. 4-10
つ
ジャーナリングファイルシステム ......... 3-15
十分な通信帯域の確保 ......................5-3, 5-14
通信機器自身に関するセキュリティ対策5-3,
障害監視....................................................... 1-8
5-11
通信帯域 ...................................................... 5-1
Copyright © 2003 IPA, All Rights Reserved.
8-4
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
て
ソース IP アドレス................................1-11
バーチャルアレイ....................................... 3-4
ディザスタリカバリ ................................. 3-21
ハードウェア RAID.................................... 3-3
ディスクアレイ ........................................... 3-1
ハードウェアアーキテクチャに依存した攻
ディスク割当量に関する脆弱性 ............. 4-10
撃 .............................................................4-17
ディスク割当量に関する脆弱性を悪用した
ハードウェアの脆弱性を利用した攻撃... 4-5
攻撃......................................................... 4-19
ハイアベイラビリティ..................................vi
ディスタンスベクター ............................... 2-8
バウンスサイト .......................................... 4-8
ディスタンスベクター・ルーティングプロ
バスクロック .............................................. 4-5
トコル....................................................... 2-8
バックアップ ...................3-16, 3-17, 5-3, 5-17
データミラータイプ ................................... 1-2
バックアップサイトによるサイトの分散5-3,
データリンク層 ..................................2-1, 2-11
5-20
テープ RAID .............................................. 3-20
バックアップツール..................................3-22
テープ媒体................................................. 3-18
バックアップ媒体......................................3-17
テープライブラリ ..................................... 3-20
デコイサーバー ......................................... 2-12
ひ
と
光メディア .................................................3-17
同期リモートコピー ................................. 3-27
ふ
トランスポート層 ....................................... 2-1
ファイアウォール.............................. 1-23, 5-1
トロイの木馬............................................... 4-5
ファイアウォールサンドイッチ..............1-24
な
ファイアウォールの導入.................. 5-3, 5-13
ファイバーチャネル.......................... 3-6, 5-17
内蔵 RAID .................................................. 5-17
フェイルオーバー....................................... 1-2
ね
フォールト・トレランス.................. 1-3, 5-16
ネットワーク(回線)の分離 ..........5-3, 5-15
フォールト・トレラント........................... 1-5
ネットワークアドレス変換 ....................... 1-7
フォールト・トレラント・サーバー....... 1-4
ネットワーク層 ........................................... 2-1
負荷 .............................................................. 6-2
ネットワークの脆弱性を利用した攻撃 ... 4-6
負荷分散方式 .............................................. 1-9
ネットワークバックアップ ..................... 3-25
応答時間 .................................................1-10
ネットワークプロトコルの脆弱性を利用し
サーバーエージェント .........................1-10
最小コネクション .................................1-10
た DoS 攻撃............................................ 4-20
トラフィック量 .....................................1-10
は
ハッシュ関数 .........................................1-10
パーシステンス ................................1-10, 1-22
ラウンドロビン ...................................... 1-9
SSL セッション ID................................ 1-11
複数 ISP(プロバイダ)の利用....... 5-3, 5-12
クッキー................................................. 1-11
複数サーバーへの処理の分散............ 5-2, 5-8
Copyright © 2003 IPA, All Rights Reserved.
8-5
IPA
ISEC インターネットサーバーの安全性向上策に関する調査
8 索引
物理層....................................................2-1, 2-2
リンクステート .......................................... 2-8
プレゼンテーション層 ............................... 2-1
リンクステート・ルーティングプロトコル
.................................................................. 2-8
へ
る
平均故障間隔............................................... 2-2
ヘルスチェック ..................................1-8, 1-22
ルータ ................................................... 2-1, 5-1
ルーティングプロトコルを利用した DoS 攻
ほ
撃 ..................................................... 4-6, 4-20
ポイントインタイム・スナップショット3-6
れ
包括的 DoS 攻撃...................................4-1, 4-2
ホットスワップ ........................................... 1-5
レイヤ1 ...................................................... 2-2
レープ攻撃 .................................................4-19
ま
レプリケーション..................... 1-6, 3-28, 5-20
マルチホーミング ............................1-25, 2-10
ろ
み
ロードバランサー................1-1, 1-6, 5-1, 5-16
密結合........................................................... 1-1
ロードバランサーの接続形態
り
DSR 構成 ................................................1-15
ブリッジ構成 .........................................1-15
リカバリ..................................................... 3-17
ルータ構成 .............................................1-14
リストア..................................................... 3-26
ロードバランシング............................ 1-3, 1-4
リソース枯渇型 DoS 攻撃 ...................4-4, 4-8
ログ用ストレージ容量確保.............. 5-3, 5-18
リバースキャッシュサーバー ................. 1-23
ログを利用した DoS 攻撃 ........................4-10
リピータハブ............................................... 2-1
リモート監視............................................. 3-15
リンクアグリゲーション .......... 1-3, 2-6, 5-16
Copyright © 2003 IPA, All Rights Reserved.
8-6
Fly UP