特集
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によるアプリケーション連携など、今後も情報システムは機能性の向上に伴って複雑化を増すだろう。もはやボランタリー・ベースで少数の管理者が努力するというレベルではない。情報システムを安全に運用するには、予算決定権を持つ経営層も含めて、情報セキュリティに対する認識を新たにする必要がある。システムの安全性をどれだけ高めても、それを運用する人間側がきちんとしなければ何の意味もない。

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

 

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

@IT Special

- PR -

TechTargetジャパン

Windows Server Insider フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間
ソリューションFLASH