特集 Windowsセキュリティセミナー・レポート Windows環境におけるセキュリティ強化のポイント（後編） 4．SQL Server 2000のセキュリティ・ポイント デジタルアドバンテージ 2003/02/28

---

SQL Server 2000：4つのセキュリティ・ポイント

　SQL Server 2000（およびMSDE）のセキュリティ・ポイントとしては、次の4つが挙げられる。

ポイント	内容
saパスワード	SQL Serverの管理者権限である「sa」に対しては必ずパスワードを設定する。できればWindows統合認証モードを使用し、saを使わないようにする
システムSPの制限	SQL Serverを管理するためのストアード・プロシージャであるシステムSPへのアクセスを正しく管理する
サービス実行アカウント	Local System、Administratorなどの強力なアカウントは使用しない。専用のアカウントを作成し、このアカウントに対して必要最小限の権限を割り当てて使用する
SQLインジェクション	SQLインジェクションは、クロスサイト・スクリプティングと同様にして、実行時に別のクエリーを混入させるハッキング技術。文字のエスケープや禁止文字の検出を行い、ハッキングを防止する

SQL Server 2000のセキュリティ・ポイント（1）：saアカウントのパスワード

　「sa」とは、SQL Serverを「混合モード」を選択してインストールすると作成されるSQL Server用の管理アカウントである。「Windows統合認証モード」でインストールした場合には作成されない。Windows統合認証モードでは、OS（Windows）の機能を使って認証処理を行う。これに対し混合モードでは、SQL Server自身が認証機能を持ち、これを使ってユーザー認証を行う。これは、Windows以外の環境（UNIX環境など）からもデータベースに接続できるようにするためのモードである。

　saは管理者権限のアカウントであり、SQL Serverに対して完全な権限を持つSYSADMINというロール（役割。Windowsのユーザー・グループに相当するもの）が割り当てられている。従ってsaに対するアクセス権制限が突破されると、データベースの削除やデータ改ざんまで、何でも可能になってしまう。

　混合モードでSQL Serverをインストールした場合には、OSの管理者アカウントと同様にして、saアカウントを管理しなければならない。まず、パスワードをきちんと設定することだ。OSへの攻撃には危機感を持っていても、SQL Serverへの攻撃となると、むとんちゃくになる管理者がいる。実際、saをパスワードなしの状態で運用しているケースも少なくないようだ（SQLのインストール時に何も設定をしないと、このようになってしまう）。過去には、こうしたパスワードの設定されていないSQL Serverを狙うワーム（SQLSPIDAやCBLAD）が発生したことがある。そして可能であれば、混合モードではなく、Windows統合認証モードを使うことが推奨される。前出のSQLSPIDAは、自身を繁殖させるだけの愉快犯的なワームだったが、その気になればデータベースを消去することも可能だった。

SQL Server 2000のセキュリティ・ポイント（2）：システムSPの制限

　システムSPは、SQL Server自身を管理するためにデフォルトで提供されるストアード・プロシージャである。機能的には非常に強力で、これを利用すればSQL Serverの管理は容易になるが、機能な強力なだけに、突破されると被害は甚大になる危険がある。

　システムSPを実行するにはsysadminロール（管理者権限）が必要なので、通常は実行できない。ただし一部のシステムSPは、publicロール（すべてのデータベース・ユーザーが属している特別なロール）だけで利用もできるものがある。システムSPのデフォルト設定は次のようになっている。

機能	SP	sysadmin	public	guest
コマンド・シェル	xp_cmdshell	○
アカウントの操作	sp_addlogin	○	○
	sp_adduser	○	○
	sp_addrolemember	○	○
	sp_addsrvrolemember	○	○
権限の許可	sp_grantlogin	○	○
	sp_grantdbaccess	○	○
SQL ServerのシステムSP（ストアード・プロシージャ）とロール

　コマンド・シェルはsysadminロールのみ実行可能だが、これを突破されるとハードディスクのフォーマットすら可能になる。特に注意が必要である。

　表から分かるとおり、デフォルトでは、アカウント操作や権限の許可などもpublicロール（WindowsでいうEveryoneに相当）で実行可能である。具体的な対応としては、sysadmin以外のロールではこれらのシステムSPを実行できないように、明示的にpublic（WindowsでいうEveryone）やguest（ゲスト・アカウント）でのアクセスを拒否する。拒否は許可よりも優先するので、万一間違って不必要なロールに許可の権限を与えてしまった場合でも、明示的に拒否が設定されていれば、実行できないからだ。

SQL Server 2000のセキュリティ・ポイント（3）：サービス実行アカウント

　通常、SQL Serverをインストールしたデフォルトの状態では、SQL Serverの処理がOSレベルのドメイン管理者権限やローカル管理者権限（LocalSystem）で実行されるようになっている。しかし外部に公開されるWebサーバでは、このデフォルトの状態のまま使うのではなく、最小限の権限で実行されるようにする必要がある。

　具体的には、「SQLAdmin」などといった独自のユーザーを作成して、これに必要最低限のアクセス権を与え、このユーザー権限でSQL Serverの処理を実行するように設定する。またこのユーザーについては、必要となるリソース以外のアクセスを明示的に拒否する。こうしておけば、万一SQL Serverがハッキングを受けて突破された場合でも、OSレベルで処理がブロックされるようになる。

　SQL ServerとWindowsサービス実行アカウントに必要なアクセス権の関係については、SQL Server 2000のBooks Online（SQLのヘルプ・ファイル）にある、「Windows サービス アカウントの設定」のページを参照されたい。

「Windows サービス アカウントの設定」

SQL Serverのアクセス権を設定する場合は、SQLサービス用の独自アカウントを割り当て、必要最小限の権限だけを持たせるようにする。具体的なアクセス権についてはSQL Server 2000付属のBooks Onlineヘルプの「Windows サービス アカウントの設定」を参照のこと。

SQL Server 2000のセキュリティ・ポイント（4）：SQLインジェクション

　「SQLインジェクション」とは、IIS 5.0の項で述べたクロスサイト・スクリプティングと同じような攻撃手法の1つである。外部からの入力データを正しく検査せずに、そのままSQLのクエリーに流し込む構成になっていると、想定外の処理を行うクエリー文字列が送られて、データが盗み出されたり、消去されたりする危険がある。例えば簡単な例を見てみよう。

SQLインジェクションの例

“user”と“password”というフィールドからなるテーブルtableから、特定ユーザーのパスワード情報を取り出すクエリーの例。ユーザーが入力する部分は、青い背景の部分だけであり、その前後は固定的なクエリー文字列になっている。通常は上のようにユーザー名が入力されることを想定しているが、ここに別のSQLクエリーを流し込まれると、予想外の処理が実行されてしまうことになる。

　仮にいま、“user”と“password”というフィールドからなるテーブルがあったとしよう。そしてWebページでユーザー名を入力させ、このテーブルから対応するパスワード文字列を取り出して処理を行うものと仮定する。図の上側は、入力された“taro”というユーザー名を指定して、対応するパスワードを取り出すSQLクエリーである。青い背景の部分がユーザーが入力した文字列であり（この場合は「taro」と入力している）、そのほかの部分は固定的なクエリー文字列となっている。一方、“taro”の代わりに、SQLクエリー文字列が指定され、それをそのままクエリーに組み込んだものが下側である（ユーザーの入力は「' or user is not NULL or user='」。最初と最後に、文字列を囲むためのシングルクォート記号が置かれていることに注意）。ご覧のとおり、これは「userがNULL（＝何もない）か、またはNULLでないか（つまり何らかの文字が格納されているか）、またはNULLか」というクエリーになる。これを実行すると、ユーザー名がNULLでないレコード、つまりテーブルのすべてのレコードが処理対象となってしまう。クエリーの結果をユーザーに表示していたとすると、全ユーザーの情報が表示されてしまうことになる。

　クロスサイト・スクリプティングと同様、SQLインジェクションを防止するには、外部から入力されたデータをそのままクエリーに挿入せず、文字のエスケープや禁止文字を検出することだ。またアプリケーションから、アドホックに（場当たり的に）クエリーを実行するのではなく（このようなクエリーは「アドホック・クエリー」と呼ばれる）、できるだけストアード・プロシージャを利用するようにする。そしてSQL Serverのロールに対して、そのストアード・プロシージャの実行だけを許可すると有効である。

現場の担当者だけでなく、経営者やマネージャもセキュリティへの理解を深める必要がある

　以上、インターネット向けのサービスを提供するWebサイトを想定した、セキュリティのチェック・ポイントについてまとめた。いまに始まったことではなく、安全なシステムを構築し、運用するためには、システムに精通した管理者が初期設定をきちんと行い、またその後の運用に携わるべきだ。しかし.NETによるアプリケーション連携など、今後も情報システムは機能性の向上に伴って複雑化を増すだろう。もはやボランタリー・ベースで少数の管理者が努力するというレベルではない。情報システムを安全に運用するには、予算決定権を持つ経営層も含めて、情報セキュリティに対する認識を新たにする必要がある。システムの安全性をどれだけ高めても、それを運用する人間側がきちんとしなければ何の意味もない。

　最後に小野寺氏は、「運用が最後の要。どんなセキュリティ設定を行っても、運用が適切でなければシステムは脆弱になってしまう。人間こそが一番の脆弱性であり脅威だ」と締めくくった。

INDEX
	[特集]　Windowsセキュリティセミナー・レポート
	Windows環境におけるセキュリティ強化のポイント
	1．Windows 2000 Serverのセキュリティポイント（1）
	2．Windows 2000 Serverのセキュリティポイント（2）
	3．IISのセキュリティ・ポイント
	4．SQL Server 2000のセキュリティ・ポイント

　

特集

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）