Common SQL Server Security Issues and Solutions

[アーティクル]
10/26/2016

セキュリティ

SQL Server でよく発生するセキュリティ上の問題とその解決方法

Paul S. Randal

概要:

物理的なセキュリティとネットワークセキュリティ
攻撃対象領域、サービスアカウント、および最小特権
認証、承認、および SQL インジェクション
障害回復と監査

IT 業界に携わっていればどなたでもご存じだと思いますが、今セキュリティが注目を集めています。企業のデータは、その企業が保有する最も大事な資産の 1 つで、そのデータを保護することは非常に重要です。私は、セキュリティに関する今回の記事のテーマを考えるときに、それについて書けば 1 つの記事になるようなセキュリティ機能を探そうとしました。ですが、その後私は、現在急増している "不本意な DBA" (思いがけず SQL Server インスタンスの管理を担当することになった IT プロフェッショナル) と、2008 年 8 月号の記事「効果的なデータベースメンテナンスのヒント」に対していただいた大きな反響について考えました。そして、SQL Server でよく発生するセキュリティ上の問題を紹介する記事、言い換えれば SQL Server インスタンスのセキュリティ強化に関する入門書のような記事を書くことにしました。

考慮する必要のあるセキュリティ上の問題をすべて紹介する記事を書こうとすると、それだけで 1 冊の雑誌ができあがるほどのボリュームになってしまうので、私は SQL Server MVP の仲間 (および私の妻) に、どのトピックを今回の記事に含めたらよいかを聞いて回りました。その結果、セキュリティに精通していない DBA が、思いがけず SQL Server インスタンスとその関連アプリケーションを管理することになった場合に考慮する必要のあるセキュリティ領域のトップ 10 を紹介することにしました (ただし、この記事さえ読めば万全というわけではないので注意してください)。領域ごとに、問題の簡単な説明、問題を緩和する方法に関するアドバイス、および詳細情報へのリンクを提供します。

オンラインブックへのリンクは、すべて SQL Server 2008 向けのページですが、各 Web ページから SQL Server 2005 向けのページも表示できます。また、記事のまとめ部分では、SQL Server 2005 と SQL Server 2008 のセキュリティに関する主要なホワイトペーパーと、オンラインブックのセクションへのリンクを提供します。

物理的なセキュリティ

最初に頭に入れておく必要があるのは、SQL Server のセキュリティだけでなく、SQL Server に到達するまでに通過するすべての層について考慮しなければならないことです。この多層化されたセキュリティ (多くの場合、"多層防御" と呼ばれます) の概念では、1 つの層だけをセキュリティで保護するのではなく、システム全体について考慮します。

最初の考慮事項として最も明らかなのは、SQL Server を実行するコンピュータの物理的なセキュリティです。ただしこの層は、見過ごされることが多く、無頓着になってしまう層です。物理的なセキュリティには、コンピュータが盗まれる可能性があるかどうかだけでなく、データベースファイルをホストするストレージシステム、バックアップテープ、データベースの冗長なコピーをホストするサーバーなどのリソースに物理的にアクセスできるかどうかも含まれます。このようなリソースには、実際に物理的に触れる必要のあるユーザーのみがアクセスできるようにします。一時的にアクセスする必要のあるユーザーの場合は、必ず同行して監視するようにします。

あまり知られていない考慮事項は、高い特権を使用して SQL Server にアクセスできるユーザーが使用するデスクトップのセキュリティです。sysadmin 権限で SQL Server にアクセスできるユーザーが、Windows デスクトップをロックせずにそこから離れた場合、世界中のどのようなセキュリティも、その置き去りにされたシステムの横を通ったユーザーによる機密データへのアクセスを防いではくれません。よりたちの悪い問題は、そのデスクトップの横を通ったユーザーがなんらかのデータを変更してしまうことです。たとえば、人事データベースのスキーマを理解している従業員が不正を企み、気付かれないように給与を変更しようとする場合が考えられます。

TechNet では、「マイクロソフトにおける物理的なセキュリティ」という非常に興味深いホワイトペーパー (スライドデッキと Web キャストを含む) が公開されています。このホワイトペーパーでは、マイクロソフトが自社で所有する多くのサーバーの物理的なセキュリティをどのように管理しているかが説明されています。

ネットワークセキュリティ

サーバーに物理的にアクセスできない場合でも、それらのサーバーはおそらくなんらかのネットワークに接続されています。これは、外部に接続されない独立した企業内 LAN の場合もあれば、直接インターネットに接続されている場合もあります。どのような場合でも、次のことについて考慮する必要があります。

Windows サーバーのネットワークセキュリティが適切に構成されていることを確認します。
許可するネットワークプロトコルを決定し、不要なプロトコルを無効にします。
ファイアウォール (Windows ファイアウォールなど) を有効にし、SQL Server へのアクセスを許可するように構成します (図 1 参照)。
SQL Server への接続を暗号化するかどうかを決定し、適切に構成します。
Kerberos を使用する場合は、サーバープリンシパル名を登録します。Kerberos は Windows 認証を補強する認証メカニズムですが (これについては後ほど説明します)、あまりよく理解されていません。サポートエスカレーションエンジニアである Rob Greene のブログ記事「Kerberos for the Busy Admin」(忙しい管理者のための Kerberos 講座) では、Kerberos に関するわかりやすく簡潔な説明が提供されています。一度目を通してみてください。
SQL Server Browser サービスを使用して、インストール済みの SQL Server インスタンスをクライアントが確認できるようにするかどうか、およびいくつかのインスタンスを非表示にするかどうかを決定します。インスタンスを非表示にすると、クライアントアプリケーションとユーザーは、その SQL Server インスタンスの接続情報を知らなければ接続できなくなりますが、ユーザーがネットワーク上の SQL Server インスタンスを探し回ることもなくなります。

図 1 SQL Server への TCP アクセスを許可するように Windows ファイアウォールを構成する

これらの作業 (およびその他の作業) については、SQL Server 2008 オンラインブックで説明されています。まず「サーバーネットワークの構成」を参照してください。また、「クライアントネットワーク構成」も参照することをお勧めします。

攻撃対象領域を最小化する

有効にするサービスと機能の数が多くなるほど、悪意のあるユーザーの攻撃を受ける確率が高くなります。SQL Server 2005 では、"既定で無効にする" 戦略がとられ、セキュリティに密接に関わる機能が既定で無効になっていて、必要な機能だけを DBA が有効にできます (通常、サービスを有効または無効にするこのプロセスは、"セキュリティ構成" と呼ばれます)。

無効にした方がよい機能の典型的な例は、ホスト Windows システム上で SQL Server インスタンスのコンテキスト内からコマンドを実行できる、xp_cmdshell です。侵入者が SQL Server インスタンスを侵害し、SQL Server サービスアカウントを使用して Windows 特権を昇格させた場合、その侵入者は xp_cmdshell を使用して、Windows システムにもアクセスできます。

セキュリティ構成には、さまざまな方法があります。SQL Server 2005 と SQL Server 2008 のどちらでも、SQL Server 構成マネージャを使用して、サービスとネットワークプロトコルを構成できます。また、どちらのバージョンでも、sp_configure ストアドプロシージャを使用して、データベースエンジンの機能とオプションを構成できます。たとえば、次のコードを使用すると、xp_cmdshell 機能を無効にできます。

-- To allow advanced options to be changed EXEC sp_configure 'show advanced options', 1; GO -- To update the currently configured value for -- advanced options RECONFIGURE; GO -- To disable xp_cmdshell EXEC sp_configure 'xp_cmdshell', 0; GO -- To update the currently configured value for this -- feature RECONFIGURE; GO

データベースエンジンのオプションと機能をグラフィカルに構成する方法は、2 つのバージョン間で大きく異なります。SQL Server 2005 では、SQL Server セキュリティ構成 (SAC) ツールが導入されたことによって、簡単に変更を行うことができます。たとえば、SAC を使用すると、図 2 のように、xp_cmdshell を無効にできます。

図 2 SQL Server 2005 で SAC を使用して xp_cmdshell を無効にする

SQL Server 2008 では、SAC が完全に削除され、その機能がポリシーベースの管理機能に組み込まれました。この機能の詳細については、SQL Server 2008 オンラインブックの「ポリシーベースの管理を使用したサーバーの管理」を参照してください。図 3 は、条件を作成して、xp_cmdshell が無効になっているかどうかを確認する方法を示しています。構成したポリシーは、SQL Server 2005 インスタンスと SQL Server 2008 インスタンスの両方に適用できるので、いったんポリシーを構成すれば、実質的にはクリック 1 つで設定を変更できます。

図 3 SQL Server 2008 でポリシーベースの管理に使用する条件を作成する

サービスアカウント

SQL Server は、Windows 上で 1 つ以上のサービスとして実行されます。各サービスには、そのサービスを実行するための Windows アカウントが必要です。このアカウントは、Windows システム上のさまざまなリソース (ネットワークやファイルシステムディレクトリなど) にアクセスできる必要があります。ベストプラクティスは、SQL Server が正しく動作するために必要な最小限の特権をこのアカウントに与えることです。この概念は、ユーザーやプロセスに必要最小限の特権のみを与えることによってシステムのセキュリティを強化できると考える、"最小特権の原則" の一部です。

したがって、高い特権を持つアカウント (ローカルシステムアカウントやローカル管理者アカウントなど) を SQL Server サービスアカウントとして使用しないようにします。これは、SQL Server が侵害された場合、Windows システムも侵害される可能性があるからです。通常、SQL Server サービスは Network Service という組み込みのアカウントで実行されますが、SQL Server が他のドメインリソースへのアクセスを必要とする場合は、新しいドメインユーザーアカウントを作成し、必要最小限の特権と該当リソースへのアクセス権を与えるようにします。SQL Server 2008 オンラインブックの「Windows サービスアカウントの設定」では、サービスアカウント、必要な特権、およびリソースが記載された包括的な一覧を参照できます。サービスアカウント (またはそれに関連する要素) を変更する必要がある場合は、必ず SQL Server 構成マネージャを使用して、必要なすべての構成変更を適切に実装するようにします。

管理者特権の使用を制限する

SA ログインや sysadmin 固定サーバーロールの公開範囲が広くなるほど、セキュリティ侵害、つまり事故の発生率が高くなります。いくつかのベストプラクティスを次に示します。

SA アカウントにアクセスできるユーザーの数を最小限に抑えると共に、sysadmin ロール (およびその他の特権ロール) のメンバシップを制限し、どうしても必要なユーザーにのみ、sysadmin 特権を与えるようにします。また、SQL Server への一時的なアクセスを必要とするユーザーや、簡単なタスクを実行する SQL ユーザーには、SA のパスワードを公開しないようにします。このような場合は、新しい SQL ログインを作成し、必要な特権を与えます。

SA アカウントを使用するよりも、ユーザーを sysadmin ロールのメンバにすることをお勧めします。この方法を使用すれば、ユーザーのログインを削除するときに、SA アカウントのパスワードを変更する必要がなくなります。古いサーバーの管理を引き継ぎ、どのユーザーがサーバーにアクセスできるかがわからない場合は、新たにその情報を管理するために、SA のパスワードを変更します。

Windows の BUILTIN/Administrators グループを sysadmin ロールから削除するかどうか (このグループは既定で追加されます) は、議論を呼ぶ問題の 1 つです。Windows の管理者が、人事データベースを照会できる必要はあるでしょうか。また、企業は管理者であれば、だれでも疑いなく誠実な人間として信頼してよいのでしょうか。BUILTIN/Administrators グループを sysadmin ロールから削除する場合は、注意して作業を行う必要があります。特に、クラスタ化された環境では、正しい手順を踏まなかった場合、SQL Server が起動しなくなる可能性があるので、注意が必要です。この問題と、クラスタに関するその他の問題については、サポート技術情報の記事「クラスタ化された SQL Server に関する推奨事項と注意事項および基本的な警告」を参照してください。

sysadmin 特権を使用してアクセスできるユーザーには、どうしても必要な場合のみ高い特権を使用してログインするよう呼びかけます。また、ユーザーごとに、特権付きのアカウントとそうでないアカウントの 2 つを提供します。特権付きでないアカウントを既定で使用することによって、犠牲の大きい失敗を犯す可能性が最小限に抑えられるだけでなく、ロックされていない Windows 端末上で、sysadmin 特権を使用してウィンドウが開かれる可能性を低下させることもできます。大事なのは多層防御です。

ここでの最後のアドバイスは、sysadmin 特権を必要とするアプリケーションを使用しないようにすることです。残念ながら、一部のアプリケーションでは、やむを得ないこととして、この適切でない手法がよく使用されていますが、独自に作成するアプリケーションではこの手法を使用するべきではないので、sysadmin 特権を必要とするアプリケーションの開発者に、そのことを訴える必要があります。

認証

使用できる認証モードは 2 つあります。これらは、Windows 認証と混合モード (Windows 認証を SQL Server 認証と組み合わせた認証方法) です。

Windows 認証は、ネットワークアカウントまたはドメインアカウントを使用して、SQL Server への接続に使用する Windows アカウントを検証します。セットアップ中にこの認証方法を選択した場合、SA アカウントは、無作為に生成された、実質的には無効なパスワードと共に作成されます。SA のパスワードは、インストール直後に強力で安全なパスワードに変更する必要がありますが、SA アカウント自体は、どうしても必要にならない限り使用しないようにしてください。

SQL Server 認証を使用するには、各ユーザーが定義済みの SQL Server アカウントを持っていて、そのパスワードが SQL Server に格納されている必要があります。また、言うまでもありませんが、SA アカウントも有効にして、そのパスワードを定義する必要があります。SQL Server 認証では、ユーザーが 2 つのユーザー名とパスワード (ネットワーク用と SQL Server 用) を使用します。一般的に、より安全な方法として推奨されているのは、可能な限り Windows 認証のみを使用することです。これに関する詳しい説明と、認証モードの変更方法については、オンラインブックの「認証モードの選択」を参照してください。

SQL 認証を使用する場合、すべてのユーザーに強力なパスワードを割り当てる必要があります。強力なパスワードとは、パスワード解読プログラムによって推測されにくい複雑なパスワードのことです。これは、SA や sysadmin ロールのメンバなど、高い特権を持つアカウントで特に重要な意味を持ちます (これまで最も一般的に使用されていた、最も望ましくない手法の 1 つは、SA のパスワードを空にすることです。さいわい、SQL Server 2000 SP3 以降、そのような設定は不可能になりました)。

また、パスワードを定期的に変更し、企業のポリシーを社内に公開して、従業員が安全で強力なパスワードに関するベストプラクティスを使用できるようにします。強力なパスワードの作成と保護に関するベストプラクティスの概要については、「強力なパスワード: 作成方法と使用方法」を参照してください。このページで紹介されるポリシーを、企業のポリシーに取り入れることができます。

SQL Server 2005 または SQL Server 2008 を Windows Server 2003 以降のオペレーティングシステム上で実行する場合、SQL Server は、Windows のパスワードポリシーメカニズムを使用して、複雑さと有効期限に関するポリシーを適用します。SQL Server 2008 オンラインブックの「パスワードポリシー」では、SQL Server で提供される、強力なパスワードのサポートとさまざまなパスワードポリシーに関する説明が記載されています。

承認

既に説明したとおり、システムをセキュリティで保護するための方針の 1 つは、最小特権の原則を使用することです。この原則は、管理者レベルの特権には直接適用されますが、通常のデータベースユーザーの権限にも適用されます。あるデータベースのユーザーは、(おそらく) 別のデータベース内のデータにアクセスできないようにした方がよいでしょう。また、あるテーブルセットの所有者が、別のユーザーのテーブルを操作できないようにしたり、ユーザーが、必要なデータにのみアクセスし、必要な操作のみをそのデータに対して実行できる (たとえば、SELECT は実行できても UPDATE や DELETE は実行できない) ようにすることをお勧めします。

このようなセキュリティはすべて、SQL Server 内の包括的で階層的な権限システムによって実現されます。このシステムでは、ユーザーやロール (プリンシパルと呼ばれます) に、オブジェクト、スキーマ、データベースなどの特定のリソース (セキュリティで保護可能なリソースと呼ばれます) に対する特定の権限が与えられるか、拒否されます。図 4 は、SQL Server で使用される権限の階層を大まかに示しています。この図は、管理者が最小特権の原則に従う必要があることを暗黙的に示しています。たとえば、すべてのデータベース開発者を db_owner ロールのメンバにしないようにします。また、権限を public ロールに制限し、最も低いレベル (ユーザーやロール) にのみ権限を与えて、直接的なアクセスを最小限に抑えるようにします。権限のベストプラクティスについては、この記事では詳しく説明しませんが、SQL Server 2008 オンラインブックの「ID およびアクセス制御 (データベースエンジン)」に、すべての概念に関する詳しい説明が記載されています。

図 4 SQL Server で使用される権限の階層

SQL Server 2005 では、権限をよりきめ細かく制御し、データベース内の各ロールをより適切に分離できるように、ユーザーとスキーマが分離されています。スキーマはデータベースユーザーから独立し、単なるオブジェクトのコンテナとして機能します。これにより、さらにきめ細かく権限を管理できるようになるなど、多くの動作変更が実現されました (SQL Server 2005 と SQL Server 2008 では、server.database.schema.object という形式に従って、4 つの部分から名前が構成されます。以前は、server.database.owner.object という形式が使用されていました)。

たとえば、CONTROL 権限を与えられたデータベース開発者は、スキーマを作成できます。これらの開発者は、制御下にあるスキーマ内の任意のオブジェクトに対して、CREATE、ALTER、および DROP 操作を実行できますが、データベース内の他のスキーマに対する暗黙的な権限は与えられません。このため、データベース開発を行う目的で db_owner 権限を使用する必要はなくなります。さらに、ユーザーとスキーマが分離されることによって、データベースユーザーを削除するときに、新しいユーザー名を使用して、関連するすべてのオブジェクトやアプリケーションのコードを変更する必要がなくなります。オブジェクトはスキーマのメンバなので、オブジェクトの作成者とは関連付けられません。

このような理由から、スキーマを使用してオブジェクトの所有権を定義することをお勧めします。詳細については、SQL Server 2008 オンラインブックの「ユーザーとスキーマの分離」を参照してください。

禁止された操作をユーザーが行わないようにするもう 1 つの方法は、ベーステーブルへの直接的なアクセスを許可しないことです。これを行うには、更新や削除などの操作をカプセル化、制御、および分離するためのストアドプロシージャと関数、および制限を適用したうえで最適な選択を可能にするビューを提供します。

SQL インジェクション

不正なデータアクセスの最も一般的な方法の 1 つは、SQL インジェクション攻撃を使用することです。SQL インジェクションにはさまざまな形式がありますが、基本的には、動的に構築された文字列を使用するコードを巧みに利用して、予期しないコードを構文内に "挿入" します。たとえば、次のインジェクション攻撃のコードは、不完全なユーザー入力検証ロジックを利用して、入力文字列にエスケープ文字を含め、SQL Server にその文字列を許可させます。あまり自然な例ではありませんが、コード内で、十分に検証されない入力文字列を使用して動的に文字列を構築するときの動作がよくわかります。

DECLARE @password VARCHAR (20); DECLARE @input VARCHAR (20); DECLARE @ExecStr VARCHAR (1000); SELECT @password = 'SecretSecret'; -- assume application gets input 'OR''=' SELECT @input = '''OR''''='''; SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted'''; EXEC (@ExecStr); GO

このコードを実行すると、ユーザーによって入力された文字列がパスワード文字列と正確に一致しない場合でも、"Password Accepted" (正しいパスワードが入力されました) という語句が出力されます。ユーザーによって入力された文字列が正しく解析および確認されないので、その文字列に挿入されたエスケープシーケンスによって、Transact-SQL ロジックが変更されます。

SQL インジェクションは、アプリケーションのコードを適切に記述すれば問題にはならず、そのための手法もいくつかあります (たとえば、区切られた識別子に QUOTENAME を使用します)。ただし、古いアプリケーション (社内アプリケーションになった自社のプロジェクトなど) を引き継ぐ場合は、SQL インジェクション攻撃を受けやすいかどうかを別途テストする必要があります。SQL インジェクション攻撃は、さまざまな手法を使用して緩和できます。SQL Server 2008 オンラインブックでは、この攻撃に関する包括的なセクションが提供されています。まずは、そのとおりの名前が付いた「SQL インジェクション」を参照してください。

障害回復

障害回復の重要度は、環境のダウンタイムとデータ損失に関する要件によって異なります (これらの要件をまだ定義していない場合は、定義してください)。セキュリティ上の問題は、さまざまなレベルで発生する可能性があります。障害回復手段として、別の SQL Server にフェールオーバーしたり、暗号化されたデータが格納されたデータベースを復元する場合、いくつかのことを考慮する必要があります。

1 つ目は、ログ配布やデータベースミラーリングを使用する場合など、データベースへのアクセスに必要なログインがフェールオーバーサーバーに複製されなかったときに問題が発生することです。データベースがミラーインスタンスにフェールオーバーした後、アプリケーションがミラーサーバー上に存在しない特定のログインを使用してそのデータベースに接続しようとした場合、アプリケーションは "ログインできませんでした" という 18456 エラーを受け取ります。このログインはアプリケーションエコシステムの一部なので、データベースをホストするインスタンス上で定義する必要があります。この方法は、サポート技術情報の記事 918992「SQL Server 2005 のインスタンス間でログインおよびパスワードを転送する方法」で説明されています。エラー 18456 のトラブルシューティング方法については、この後すぐに説明します。

2 つ目は、データベースバックアップに含まれるデータの暗号化に使用した暗号化キーがバックアップされなかったことによって、データベースの復元先である SQL Server インスタンス内でその暗号化キーを使用できず、問題が発生することです。最善のシナリオは、データベースの一部のみが暗号化されていて、その部分のデータにのみアクセスできない場合です。一方、最悪のシナリオは、SQL Server 2008 で透過的なデータ暗号化 (TDE) を使用してデータベース全体を暗号化した場合です。このシナリオでは、データベースの暗号化キーを保護するために使用したサーバー証明書が、バックアップされていないか使用できない場合、データベース全体を復元できず、次のエラーが返されます。

Msg 33111, Level 16, State 3, Line 1 Cannot find server certificate with thumbprint '0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'. Msg 3013, Level 16, State 1, Line 1 RESTORE DATABASE is terminating abnormally.

もちろん、これが TDE の狙いです。つまり、暗号化されたデータベースのバックアップの一部を偶然見つけても、それを復元して機密データにアクセスすることはできません。データの所有者で、そのデータにアクセスする必要がある場合でも、サーバー証明書がなければデータは失われます。

暗号化はそれ自体が大きなトピックで、SQL Server 2008 オンラインブックでも広範囲にわたる説明が提供されています。まずは「SQL Server の暗号化」を参照してください。また、.com/tips で入手できる付属のビデオスクリーンキャストでは、私が TDE のデモを行ったり、2 番目のインスタンスに正しく復元する方法を紹介します。

監査

システムのセキュリティを強化するための最も重要な対策は、監査機能を実装することです。これにより、どのユーザーが何をしているかがわかります。ビジネスの性質によっては、必ずこの機能を実装する必要があります。

最低でも、失敗したログインと成功したログインの両方を監査して、たとえばログインが 5 回失敗した後に成功した場合、そのことがわかるようにしておいた方がよいでしょう。そうすれば、あるユーザーが SQL Server インスタンスに侵入しようとしたときに、それに気付くことができ、使用されたログインも特定できます。図 5 では、SQL Server 2005 Management Studio の [サーバーのプロパティ] ダイアログボックスを使用して、ログインの監査を構成しています。失敗したログインは、エラーログ内のメッセージ 18456 として監査され、そのエラー状態から失敗の原因がわかります。Il-Sung Lee の SQL プロトコルに関するブログ記事「Understanding 'Login Failed' (Error 18456) Error Messages in SQL Server 2005」(SQL Server 2005 の "ログインできませんでした" (エラー 18456) エラーメッセージについて) には、さまざまな状態に関する非常にわかりやすい説明と、それらのトラブルシューティング方法が記載されています。

図 5 SQL Server 2005 Management Studio でログインの監査を構成する

SQL Server 2005 では、すべてのアクションを包括的に監査することは困難です (これについては、この記事では詳しく説明しません)。このような監査を実現するには、さまざまなトリガと SQL トレースが必要です。SQL Server 2008 では、新機能の導入によって、監査が大幅に単純化されました。その新機能とは、SQL Server Audit です。この機能に関する説明は、最近公開された非常に詳しいホワイトペーパー「SQL Server 2008 における監査」で提供されています。また、私も付属のビデオスクリーンキャストで、SQL Server Audit のデモを行っています。その他の監査ツールについては、SQL Server 2008 オンラインブックの「監査 (データベースエンジン)」を参照してください。

まとめ

実に多くのトピックを取り上げ、多くのリンクを紹介しましたが、それがこの記事の核心です。なぜなら、この記事の目的は、セキュリティの扱いに慣れていない DBA が考慮する必要のある、重要なセキュリティトピックについて概説することだからです。

一般的なセキュリティ上の脆弱性がシステム内に存在するかどうかを確認するには、いくつかのツールを使用できます。1 つ目は、Windows、ネットワーク、ファイルシステムの確認を実行できるだけでなく、SQL Server 2000 と SQL Server 2005 のセキュリティ上の問題も一部検出できる Microsoft Baseline Security Analyzer (MBSA) ユーティリティです。最新バージョンは、Microsoft Baseline Security Analyzer 2.1 です。また、SQL Server 2000 と SQL Server 2005 のみを対象とした、SQL Server 専用ツールのベストプラクティスアナライザ (BPA) が提供されています。このツールは、一連の定義済みルールを使用して SQL Server の構成を確認し、問題を検出した場合 (SA のパスワードが空の場合など) は警告を表示します。

上記のツールは、どれも SQL Server 2008 上では動作しません。実は、SQL Server 2008 用の BPA はリリースされず、短命に終わった SQL Server 2005 セキュリティ構成ツールと共に、先ほど説明した新しいポリシーベースの管理機能に置き換わりました。この理由の 1 つは、BPA と SAC が読み取り専用のツールで、問題を検出できても解決できないからです。ポリシーベースの管理機能は、問題のさまざまな解決方法を提供し、SQL Server 2000 サーバーと SQL Server 2005 サーバー上でも動作します。

もちろん、常に Windows Update を使用して、適切なタイミングで新しいセキュリティ更新プログラムとサービスパックをダウンロードしてインストールする必要があります。これが、最新の更新プログラムが適用された状態を維持するための最も良い方法です。ダウンタイムを発生させずにこれらのプログラムをインストールする方法については、この記事では詳しく説明しませんが、2006 年 12 月号の SQL Q&A コラムでいくつかのヒントが提供されています。

よく使用する検索エンジンで、セキュリティに関するマイクロソフトの一般的なリソースを検索すると、さまざまなリンクが表示されると思います。これらを端からクリックして参照する手間を省くために、目を通しておいた方がよい重要な 2 つのホワイトペーパーを次に示します。

「SQL Server 2005 のセキュリティに関するベストプラクティス - 運用作業と管理作業」および「SQL Server 2008: データベース管理者向けのセキュリティの概要」

Books Online で、SQL Server 2005 のセキュリティについて調べる場合は、まず「データベースおよびデータベースアプリケーションのセキュリティに関する注意点」を参照してください。また、オンラインブックで、SQL Server 2008 のセキュリティについて調べる場合は、まず「セキュリティと保護 (データベースエンジン)」を参照してください。

私がこの記事で皆さんに伝えたかったのは、SQL Server に格納するデータを要件に合わせてセキュリティで保護するには、いくつかの手順を踏む必要があることです。これは、別の従業員が管理していた SQL Server インスタンスを引き継ぐ場合、特に重要です。たとえば、ある人から家を買うとしたら、警報機が作動するか、庭が柵で囲まれているか、だれが鍵の複製を持っているかなど、さまざまなことをその人に尋ねると思います。まずはこの記事で紹介した考慮事項をひととおり確認することをお勧めしますが、管理している環境に関係のある部分については、より詳しく学習する必要があります。いつものように、ご意見やご質問は Paul@SQLskills.com (英語のみ) までお寄せください。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージエンジンチームに所属していました。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコアストレージエンジンを担当していました。Paul は障害回復、高可用性、およびデータベースメンテナンスの専門家であり、世界中のカンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul で公開されています。

目次

その他のリソース