Transcript 第 6 回 NT-Committee2 北海道勉強会(Tech-Ezo Round 16)

第 6 回 NT-Committee2
北海道勉強会
NT-Committee2 & Tech-Ezo Joint
Meeting
(Tech-Ezo Round 16)
アジェンダ
• データベースシステム
•
のセキュリティ
SQL Server のパフォー
マンスを味わう
データベースシステム
セキュリティ
セキュリティの現状
• Internet Explorer, Outlook, IIS の脆弱性は
頻繁に報告されている。
• しかし
• データベース関連の脆弱性はほとんど騒が
れていない
• しかし
• 重要
マイクロソフトのセキュリティ
• 昨年末に STPP を発表
• ストラテジック・テクノロジ・プロテクション・プロ
グラム
• Security Summit 2001
http://www.microsoft.com/japan/technet/t
cevents/olseminars/sec2001/
ただしく理解していく
• 「わたしは、Outlook じゃないから大丈夫」
– でも、パスワードつけていませんね。
– パスワードは暗号化されずにネットワークに流し
ていますね。
– 無線LANの暗号キーも設定されていませんね。
– サーバーには誰でも触れますね
– では。。。
ソフトウェアの適材適所
• 「うちの部のサーバは、Windows 2000で」
• 「この部署はApache/Linux/Perl でいいね」
– でも、運用担当者はひとりですね
– 開発者は数人で、ASP、CGI のセキュリティ両方
勉強しつづけるだけの体力はなさそう。
– どちらかがクラックされたら、代替サーバ、代替運
用できるの ?
どうすれば
• 適切なコストの範囲内で、正しい理解と情報
収集を続ける
• 重大な問題発生は、ウィルスやワームだけで
はない。
• 組織に重大な打撃を与えるのは、内部犯
さらに
• 定期的に監査
– システムの設定、パッチが適切であるか確認
• 定期的にペネトレーションテスト
– パスワードアタックや疑似攻撃
– システムに脆弱性がないか確認
• システムの変更、更新を監視
• 体制、行動の明文化
SQL Serverのセキュリティ
• PASSJ セキュリティ分科会
• Professional Association for SQL Server
Japan
• セキュリティ分科会を設置
• 主にメーリングリストを中心
• メーリングリスト参加者 約1,800• http://www.sqlpassj.org/security/
SQL Server のセキュリティ ?
• SQL Serverのセキュリティ情報って、マイクロ
ソフトの書籍やサイトにいろいろ情報があって
十分 ?
• アクセス権の設定の仕方や、アカウントの管
理方法のこと ?
SQL Server の脆弱性 ?
• SQL Server の脆弱性って、別にたいした数
はないように思うんですが !?
• 基本的にアカウント管理をしっかりして、パス
ワードをつけていたら、だいじょうぶじゃない ?
• ファイアウォール設置しているから.
• それほど重要なデータを置いていないから.
わたしも..
• わたしも分科会をはじめたときは。
• SQL Server のハッキング、クラッキング情
報って、どこに。。。
• しかし、
• 調べ始めると。。。
PASSJ セキュリティ分科会
• 発言数 266 (2002/3/7 現在)
• 脆弱性報告
• 危険な設定
• 監査ツール
• ペネトレーションツール
• 管理ツール
• イベント、サイト情報
管理: HFNetChk
• マイクロソフト HFNetChk
– パッチ適応状況を確認するツール
– 適応されていないパッチの一覧を表示
– サブネットを一気に調べることもできる
– パッチ情報は、コマンド実行時に自動的にダウン
ロード
– お勧め
毎日すべてコンピュータに自動
管理:Tripwire
• トリップワイヤ Tripwire
• ファイル、レジストリなどの変更を定期的にテ
スト
• 改ざん、トロイの木馬、バックドアの設置を早
期に検知
• どのように守っていても、侵入を検知できなけ
れば意味がない。
管理: InstallWatch,InstallRite
• 本来はインストーラ作成ツール
• Tripwire の代わりにつかえそう
• A poor-man Tripwire-like system on
Windows 9x/NT by Floydian
http://www.geocities.com/floydian_99/poo
rmantripwire.html
管理: Snort
• 侵入検知ツール
• ネットワーク上に流れるパケットから、不正な情報を
•
検出する
SQL7-libs.rules : SQL Server 用ルール
– 例:
セッションが sa ログインに失敗したときのエラーメッセー
ジを検出する
alert tcp $HOME_NET 139 -> any any (msg: "MS-SQL
sa logon failed"; content:
"|e630fc30b630fc302000270073006100270020006f30
ed30b030a430f33067304d307e305b
309330673057305f300230|"; flags: AP; offset:83;)
管理: Active Registory Monitor
• レジストリの記録、変化を見るツール
• ある時点のレジストリを記録しておける
• 任意の時点と比較することができる
• レジストリの変化を調べるのに便利
管理: Active Port
• TCP/UDPポートの状況を確認するツール
• ポートを使用するプログラムを確認できる
• 意図しないプログラムがポートをオープンして
いないか、確認する。
• バックドアプログラムの状況も確認
管理: ネットワークキャプチャ
• ネットワーク上を流れるパケットを見る
• セキュリティ対策の基本
• お勧め
– Vigil (SapporoWorks) シェアウェア: \1,000– HTTP,SMTP などアプリケーションレイヤのデコー
ドをサポート
– 単機能で見やすい
– ※Snort と同時に起動すると不安定
管理: ネットワークキャプチャ
• ネットワークモニタ
•
•
•
•
•
•
•
– Windows NT/2000 に標準
添付
FreePeek
PacMon
Vigil
Etherreal
CommView
WinDump
NATAS
•
•
•
•
NGSSniff
eEye Iris
Observer
Analyzer
– WinPcap の開発元が提
供
• Ethereal
監査: AppDetective for SQL
Server
• 監査とペネトレーションテスト
• サービス不能攻撃 (DoS)、ブルートフォース
攻撃(パスワード攻撃) など、30種類以上
• 現在、ベータ版
• Oracle, Sybase, Lotus Notesテストもできる
• Exhcnage Server, MySQL, DB2 なども予定
• 定期的にサーバーの状態を監視するのにお
勧め
危険: xp_cmdshell
• SQL Server に標準で提供されている
• xp_cmdshell
• 任意のコマンドをクエリーから実行できる
• アドホッククエリーに脆弱性があるとサーバー
を自由にされてしまう。
• 対策: xp_cmdshell を無効にするか、ダミー
にする
危険: レジストリを操作できる
• 任意のレジストリを操作する拡張ストアードプ
ロシジャ
• xp_regread, xp_regwrite など
• 初期設定では、sa など管理者のみ書き換え
操作を許可。そのほかは、読み込み操作の
み許可
• しかし、読み込みもできれば許可しない
危険: SQL Server の実行権限
• SQL Server サービスを実行する権限を制限
すべき
• 権限が強いと、SQL Server に侵入された場
合、クエリー経由で任意の操作ができる
• 専用アカウントをつくり、必要最小限の権利を
与える
• しかし、必要最小限とは ?
危険: ストアドプロシジャの暗号化
• SQL Server はストアドプロシジャなどを暗号
化できる
• しかし
• 解読ツールが提供されている
• dSQLSRVD (フリーウェア)
危険: 個人情報、パスワード
• 個人情報、認証用パスワードをレコードのそ
のまま保存している ?
• パスワードを全部持っていかれる可能性があ
る
• パスワードはハッシュのみ保存する
• 個人情報は個別に暗号化
• ツール: xp_crypt
危険: SQLServer 認証
• 方式: Windows 認証, SQL Server認証
• SQL Server 認証方式を利用している人が多
い
• しかし、ブルートフォースアタックには。。
• アタックを検知して、ロックアウトする仕組み
がない
• できれば、Windows 認証をお勧め
• 少なくとも、ASPにパスワードを直接書かない
危険: アドホッククエリー
• 実行時にクエリーを組み立てる方法
• s = “select * from U where n=‘” + n + “’”
• n にもし ‘ が入っていたら。
• うまくすると、別のクエリーを混ぜてしまえる
• n : x’ update U set n = ‘-’ –
• 推薦: 特定のストアドプロシジャのみ許可
監査: パスワードがないユーザ
• select
name , password
from
syslogins
where
password is null
and isntuser = 0
and isntgroup =0
セキュリティまとめ
• 詳細は、PASSJ セキュリティ分科会
• データベース設計者・開発者は、エンドユー
ザのニーズを聞くだけではダメ
• エンドユーザ・発注者は、マスコミのうわべの
セキュリティに惑わされがち
• IIS, IEの脆弱性や、ウィルスは氷山の一角
• 早期に設計者・開発者にもセキュリティ教育
をほどこす体制をつくるべき
SQL Server のパフォーマンスを
味わう
SQL Server のパフォーマンス
• PASSJ システム構築分科会を中心に。
• Web テクノロジ分科会にても取り上げる
• 推薦本
– アーキテクチャ徹底解説 (日経BP)
– SQL Server Magazine
– ともにカレン・デラニーさん
チューニング
• システム設計、デザインにも大きく関係
• SQL Server 2000 の仕組みを理解する
• 大きなパフォーマンスアップ、より安価なサー
バーでの運用も望める
スケールアップ、スケールアウト
• スケールアップ
– 4CPU-32CPU, メモリ 4GB – 64GB
– 単体マシンの性能アップ
• スケールアウト
– 複数CPUで分散処理
アップか、アウトか
• システムに求められる
•
アベイラビリティ、セ
キュリティと、かけられ
るコストは !?
32CPU/メモリ32GB の
サーバーのアベイラビ
リティが 90% で言い場
合は少ない
アップとアウトとコスト
• セキュリティパッチ適応、修正といったシステ
ムの計画停止を考えると、すくなくとも、2台の
SQL Server が必要。
• IIS, Active Directoryは、それぞれ二重化し
て、ネットワークも二重化
• インターネットの接続だけでなく、SQL Server
の前にも Firewall (もちろん二重化)
9.11 以後
• 遠隔地へのディザスタリカバリ体制
• どんな災害時にも1時間以上前のトランザク
ションを消さない体制
• クラックによる改ざんへの対応
限られたコストの中で
• 限られたコストの中で、SQL Server をより効
率的に使いきれる技術が必要
• 2CPU 必要な処理を 1CPUで十分になれば、
システムの二重化にコストを回せる。
SQL Server チューニングポイント
• クエリプロセッサを理解する
• 「アーキテクチャ徹底解説」
• Microsoft SQL Server 2000
• 第15章クエリプロセッサ
http://www.microsoft.com/japan/technet/
prodtechnol/sql/books/insidesql/
クエリーチューニング
• クエリーアナライザを活用
• プランの表示
• スキャン回数表示
– set statistics io on
• CPU時間 表示
– set statistics time on
• プロファイル表示
– set statistics profile on
• プラン表示
– set showplan_text on
– set showplan_all on
• メーリングリスト投稿のときに是非
select * は使わない
• select * from table
• すべてカラムを取ってきてしまう
• 不要なカラムへのアクセスは、チューニングを
阻害する
• 必要なカラムのみ、取得するように。
カバリングインデックス
• select [名前], [性別] from persons
where [年齢] = 30
• インデックスを[年齢] でとっていると
名前、性別のカラムを下のテーブルにもアク
セスが必要
• [年齢][名前][性別] でインデックスをとってい
ると、インデックスのみのアクセスで終了
インデックスの種類
• SQL Server のインデックスはB-Treeが基本
• クラスタ化インデックス
– ディスク上には、インデックス順に並び替えられて
いる。
• 非クラスタ化インデックス
– インデックス対照のカラムに並び替えられている。
– 元テーブルへの参照は、クラスタ化インデックス
のカラムを利用
インデックスが使われない
• せっかく設定したインデックスが、クエリープ
ロセッサに利用されていない場合がある
• しかし、よくページアクセス参照回数を見よう
• かならずしも、インデックスをつかったから早
いわけではない
• 特に、非クラスタ化インデックス
ヒット件数が多いと
• 条件に一致する件数が多いと非クラスタ化イ
ンデックスが使われないケース
• 境界となる件数はテーブルによって異なる。
• 理由:
– インデックスに含まれないカラムは、元のテーブ
ルにアクセスして取得する必要がある。
– 論理読み取り回数を確認する
検索引数 SARG
• Where で指定する条件には、クエリーオプ
ティマイザが使うものと使わないものがある。
• SARG : Search Argument
– Where [年齢] = 30
• 使われない例
– Where [住所] Like ‘%県’
• インデックスがあっても、SEEKではなく、
SCAN になる。
SARG になるように書き換え
• Where Substring([名前],1,1) = ‘c’
• これは SARG にならない
• インデックスのB-Treeをたどって検索できるわ
けではない。
• 書き換え
• Where
[名前] >= ‘c’ and [名前] < ‘d’
さらに、書き換え
• Where ABS(x) < 10
• これを書き換える
• Where x > -10 and x < 10
• わずかな修正で大きなパフォーマンスの差に
なる。
実数は SARG にならない
• 地図情報、座標などで実数
• where px < 0.05
• インデックス用に整数にしたカラムを作るのも
方法
• メーリングリストにて、ある座標にもっとも近い
レコードを調べるというスレッドを提供。
負荷テスト
• チューニングは、トータル性能で行う。
• 部分的なチューニングは、実環境でマイナス
に働くことがある。
– 例: クエリー処理は短時間で終わるようになった。
– しかし、メモリを大量に消費する
– あるいは、同時実行性能が犠牲に。
• ベンチマークテストツールの活用
– WAS (Web Application Stress Tool) など
チューニングまとめ
• チューニングに常に正解といわれるものは少
ない。
• テストを繰り返して、ネックとなっている部分、
クエリープランの動作を絞り込んでいく。
• メーリングリストでは、できるかぎりモデルを
作って対応
• 投稿する場合は、できるだけ実際に近い形で
質問する。