【はじめに】
SQL Server には、Windows認証と、SQL Server認証という2つの認証方式が用意されています。どちらの認証方法を利用するかは、SQL
Serverを含むシステム全体の要件にあわせる必要があります。それぞれの認証方式には、歴史的な背景や特性、利用上の注意があります。この連載では特にシステムのセキュリティを確保するためのプログラミング方法、設定方法、運用方法を確認していていきます。
【Windows認証が基本】
Windows認証は、Windows に登録しているユーザーやグループをSQL Serverの認証に利用できるようにします。コンピュータに登録したユーザーだけでなく、ドメイン・Active
Directory のユーザーやグループを指定することができます。
SQL Server認証は、SQL Serverに作成したユーザー名やパスワードを利用してSQL Serverの利用を認証します。
ここで、ポイントです。
「Windows 認証が基本」
マイクロソフト社は、Windows認証をできるかぎり利用することを推奨しています。SQL Server 2000の初期設定では、Windows認証のみ有効になっています。SQL
Server認証は別途有効にしなければ利用できません。逆にSQL Server認証は、古いバージョンのSQL Serverとの互換性のために残しているとなっています。
世の中のセキュリティ事情はどんどん変化しています。悪意をもった人達のシステムに対する攻撃手法は、年々進化しています。最新の攻撃手法やウィルス、ワームは、インターネットを利用して一日とたたず世界中に広がります。Slammer
ワームは、数時間のうちに世界中に被害を与えました。攻撃手法を詳細に解説したサイトや、実際に攻撃をするツールを提供するサイトも氾濫しています。
このため、セキュリティ機能の重要な要素である認証技術にも日々改良と対策が求められています。SQL Serverを提供するマイクロソフト社は、この改良と対策について、Windows認証により充実した機能と対策を行っています。一方、SQL
Server認証は、基本的な機能と深刻な問題への対策のみを行っています。
したがって、できるかぎりWindows認証を利用することを推奨します。
では、SQL Server の認証方式は、何のためにあるのでしょうか。
・ SQL Server の利用を許可/拒否する
・ SQL Server のオブジェクトの利用を許可/拒否する
まず、SQL Server に接続するときのユーザーを認証します。A さんはSQL Serverを利用してもいいが、Bさんはダメということができます。
もうひとつは、SQL Server 内のオブジェクトの利用を許可します。データベース、テーブル、ストアドプロシージャなどを利用できるか、編集できるか、削除できるかということを制御します。A
さんは、pubs データベースのauthors テーブルに対して select/insert/update/delete
をしてもいいが、B さんは、select だけしかダメということができます。
この利用を許可/拒否するユーザーやグループとして、Windows で利用しているユーザーやグループをそのまま利用できるのが、Windows認証になります。Windows
のユーザーとは関係なく、SQL Serverの中に独自につくれるのが、SQL Server認証となります。
SQL Server は、どちらの認証方式を利用できるかを設定することができます。SQL Server Enterprise
Manager からサーバーを選択し、[プロパティ]を表示し、[セキュリティ]を選択すると図のように設定を変更することができます。
・混合モード (Windows認証とSQL Server認証)
・Windows認証
なお、SQL Server認証だけを許可し、Windows認証を無効にすることはできません。
MSDEを利用しているなど、Enterprise Managerをもっていない場合、次のスクリプトをつかって、混合モードに変更することができます。
スクリプト
SqlToMix.wsf
【SQL Server認証の問題】
実際のところ、SQL Server認証を利用しているサンプルプログラムやシステムは多くあります。主な理由としては、Windowsと関係なくユーザーが管理できるため、システムを導入しやすいという面があり、解説も行いやすいからです。また、Windows
98、ME にSQL Serverをインストールしている場合は、Windows認証が設定できません。
Windows認証と比較して、SQL Server認証には次のような問題があります。
＜SQL Server認証の問題点＞
| パスワードアタック対策 |
パスワードを順番にためしていく攻撃を検出し、一時的にアカウントを無効・ロックアウトすることができない。 |
| パスワードの複雑さの指定 |
簡単なパスワードを許可してしまう。 |
| パスワードの期限設定 |
パスワードを一定期間ごとに強制的に変更させることができない。 |
|
パスワードアタックというのは、特定のユーザについて、パスワードをひたすら試す攻撃のことです。銀行のATMでしたら、3回失敗するとカードが利用できなくなりますが、SQL
Server認証には、同様の機能はありません。Windows認証の場合は、Windowsのパスワード管理機能を使ってセキュリティポリシィとして設定することができます。
コンピュータやネットワークが高速化しているため、この攻撃はますます深刻になっています。実際に、この攻撃をSQL Serverに対して行うツールやワームが公開されています。
逆に、セキュリティが必要なシステムで、この攻撃に対処していないものは、「脆弱」と判断されても仕方ない状況にあります。
同様にパスワードの複雑さやパスワード期限の設定機能も重要なセキュリティ対策ですが、やはりSQL Server認証には提供されていません。ユーザーのパスワードが、「password」といった単純で漏洩しやすいものになっている可能性があります。
SQL Server認証を利用する場合は、問題点をシステム全体や他のセキュリティツールにて対応する必要があります。たとえば、パスワードアタックは、イベントログやネットワークパケットを監視することで対応することができます。
【システムとしての認証】
ここまでは、SQL Serverの認証方式をみてきました。ここからは、SQL Serverを含むシステム全体としての認証をとりあげます。
ポイントは、次の2点です。
1. ユーザー管理は、自分でも実装できる
2. コネクションプールは、ユーザーが違うと再利用されない
SQL Serverを利用するシステムにあわせて認証を実装する必要があります。実装形態には次のようなものがあります。
* C/S : VB や.NET Windows Form を利用したクライアントとサーバ方式
* Web : IIS/SQL Server とブラウザによるシステム
* XML Web Service : クライアントと、XML Web Service によるシステム
C/S システムでは、クライアントはSQL Serverに直接接続します。すでにActive Directoryやドメインを構築している組織であれば、SQL
ServerをWindows認証に設定することになります。ドメインでユーザー管理を構築できていない場合、Unix,
MacなどWindows認証の使えないクライアントがある場合は、SQL Server認証を検討する必要があります。
Web、XML Web Serivce の場合、イントラネットで、ドメインが構築できている場合は、やはりWindows認証にします。ここでポイントは、ショッピングサイト、グループウェアサイトの場合です。この場合、一般にユーザー管理はシステムとして作り込むことになります。参加者をすべてドメインに登録したり、SQL
Server認証に登録するという事例はあまり見かけません。より柔軟なシステムが求められることが多いため、システム独自に作り込むことになります。
また、独自に作り込む別の理由として、コネクションプールとの関係があります。コネクションプールとは、SQL Serverとクライアントの間の接続時間を短縮するためのしくみです。クライアントアプリケーションがコネクションをCloseしたときに、実際にはコネクションを切断せず、次回
Open のときに、コネクションをそのまま再利用します。
Web システムでは、IISが動作するサーバー上でSQL Serverに対してコネクションプールが動作し、SQL
Serverへの接続時間を短縮します。
ただし、ここで制限があります。ユーザーに応じてWindows認証/SQL Server認証のアカウントを変更するように設定していると、コネクションプールはコネクションを再利用しません。あるユーザが利用していたコネクションを、別のユーザーが再利用することはセキュリティに問題があるためです。これは、パフォーマンスが悪くなります。
したがって、一般に Webシステムでは、IIS (ASP/ASP.NET)からSQL Server への接続は、ひとつ、または少数のユーザーしか使いません。
たとえば、Windows認証を利用する場合、次のように設定します。
Windows OS 上に、次のユーザ「WebUser」「WebAdmin」を登録
↓
SQL Serverには、Windows認証を設定し、「WebUser」「WebAdmin」を登録
↓
SQL Server上のデータベースのオブジェクトに対する権限を「WebUser」は最小限の権限、特定のストアドプロシージャのみ実行できるように設定
↓
「WebAdmin」には、管理に必要な権限、管理用のストアドプロージャを実行できるように設定
↓
IIS 上では、一般ユーザー用のページの実行アカウントには、WebUserを指定
↓
管理用ページの実行アカウントには、WebAdminを指定
|
|
このようにすると、コネクションプールがうまく再利用されます。
コネクションプールの利用状況は、SQL Serverのプロファイラをつかうと確認することができます。 【おわりに】
認証システムに必要な機能の点から、SQL ServerではWindows認証を推奨しています。ただ、Web や
XML Web Service を利用するシステムでは、独自の認証機能を実装することが多くなりますので、SQL
Serverの認証や権限の設定とどのように使い分けるのか、充分に検討する必要があります。特に、Web システムの脆弱性のために、SQL
Server上のデータベースが改ざん、漏洩することがないようにしておきましょう。
次回は、SQL Serverユーザーのアカウントの作成方法を解説していきます。
|
