認証モードの選択
セットアップ中に、データベース エンジンの認証モードを選択する必要があります。 Windows 認証モードと混在モードという 2 つのモードを使用できます。 Windows 認証モードを選択すると、Windows 認証が有効になり、SQL Server 認証が無効になります。 混合モードを選択すると、Windows 認証と SQL Server 認証の両方が有効になります。 Windows 認証は常に使用可能であり、無効にすることはできません。
認証モードの構成
セットアップ中に混合モード認証を選択した場合は、sa という組み込みの SQL Server システム管理者アカウントの強力なパスワードを入力して確認する必要があります。 sa アカウントは、SQL Server 認証を使用して接続します。
セットアップ中に Windows 認証を選択した場合は、SQL Server 認証用に sa アカウントが作成されますが、無効になっています。 後で混合モード認証に変更し、sa アカウントを使用する場合に、アカウントを有効にする必要があります。 任意の Windows アカウントまたは SQL Server アカウントは、システム管理者として構成できます。 sa アカウントはよく知られているため、悪意のあるユーザーの攻撃対象となることが少なくありません。そのため、アプリケーションで必要とならない限り、sa アカウントを有効にしないでください。 sa アカウントでは、パスワードを空白のままにしたり、推測しやすいパスワードを設定しないでください。Windows 認証モードから混合モード認証に変更して、SQL Server 認証を使用するには、「サーバーの認証モードの変更」を参照してください。
Windows 認証を使用した接続
Windows ユーザー アカウントでユーザーが接続すると、SQL Server はオペレーティング システムの Windows プリンシパル トークンを使用してアカウント名とパスワードを検証します。 つまり、ユーザーの ID は Windows によって確認されます。 SQL Server では、パスワードが要求されず、ID の検証も行われません。 Windows 認証は、既定の認証モードであり、SQL Server 認証よりもはるかに安全性に優れています。 Windows 認証では、Kerberos セキュリティ プロトコルを利用し、強力なパスワードに対して複雑な検証を行うという点に関して、パスワード ポリシーが強化されています。また、アカウント ロックアウトの機能を提供し、パスワード有効期限にも対応しています。 Windows 認証を使用して行われた接続は、信頼関係接続と呼ばれることがあります。これは、SQL Server では Windows が提供する資格情報を信頼しているためです。
Windows 認証を使用することにより、Windows グループをドメイン レベルで作成できます。また、グループ全体に対して SQL Server のログインを作成できます。 ドメイン レベルでアクセスを管理すると、アカウント管理を簡素化できます。
セキュリティに関する注意 |
---|
可能な場合は、Windows 認証を使用します。 |
SQL Server 認証を使用した接続
SQL Server 認証を使用すると、Windows ユーザー アカウントに基づかないログインが SQL Server に作成されます。 ユーザー名とパスワードの両方が SQL Server を使用して作成され、SQL Server に格納されます。 SQL Server 認証を使用して接続するユーザーは、接続するたびに資格情報 (ログインとパスワード) を入力する必要があります。 SQL Server 認証を使用する場合は、すべての SQL Server アカウントに強力なパスワードを設定する必要があります。強力なパスワードのガイドラインについては、「強力なパスワード」を参照してください。
SQL Server ログインでは、省略可能な 3 つのパスワード ポリシーを使用できます。
[ユーザーは次回ログイン時にパスワードを変更する]
ユーザーは、次回接続するときにパスワードを変更する必要があります。 パスワードを変更する機能は、SQL Server Management Studio に用意されています。 このオプションが使用されている場合、サード パーティのソフトウェア開発者はこの機能を提供する必要があります。
[パスワードの期限を適用する]
コンピューターのパスワードの有効期限ポリシーが SQL Server ログインに適用されます。
[パスワード ポリシーを適用する]
コンピューターの Windows のパスワード ポリシーが SQL Server ログインに適用されます。 これには、パスワードの長さおよび複雑さが含まれます。 この機能は、Windows Server 2003 以降のバージョンのみで使用できる NetValidatePasswordPolicy API に依存します。
ローカル コンピューターのパスワード ポリシーを確認するには
[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。
[ファイル名を指定して実行] ダイアログ ボックスで、「secpol.msc」と入力し、[OK] をクリックします。
[ローカル セキュリティ設定] アプリケーションで、[セキュリティの設定]、[アカウント ポリシー] の順に展開して、[パスワードのポリシー] をクリックします。
結果ペインに、パスワードのポリシーが表示されます。
SQL Server 認証の欠点
Windows のログインとパスワードを持っている Windows ドメイン ユーザーの場合、接続するために別の (SQL Server) ログインとパスワードを入力する必要があります。 多くのユーザーにとって、複数の名前とパスワードを把握しておくことは困難です。 データベースに接続するたびに SQL Server の資格情報を入力する必要があるのは面倒な場合があります。
SQL Server 認証では、Kerberos セキュリティ プロトコルを使用できません。
Windows には、SQL Server ログインで使用できない、追加のパスワード ポリシーが用意されています。
接続時に、SQL Server 認証ログインの暗号化されたパスワードをネットワーク上で渡す必要があります。 自動的に接続する一部のアプリケーションでは、クライアントでパスワードが保存されます。 これらは追加の攻撃ポイントとなります。
SQL Server 認証の利点
SQL Server では、古いアプリケーションや、SQL Server 認証を必要とする、サード パーティが提供するアプリケーションをサポートできます。
SQL Server では、すべてのユーザーが Windows ドメインで認証されていない、オペレーティング システムが混在する環境をサポートできます。
ユーザーが、不明なドメインや信頼されていないドメインから接続できます。 たとえば、既存の顧客が、割り当てられた SQL Server ログインを使用して接続し、発注状況を確認するアプリケーションの場合です。
SQL Server では、ユーザーが独自の ID を作成する Web ベースのアプリケーションをサポートできます。
ソフトウェア開発者は、事前に設定された既知の SQL Server ログインに基づいた、複雑な権限の階層を使用してアプリケーションを配布できます。
注 SQL Server 認証を使用した場合、SQL Server がインストールされているコンピューターのローカル管理者の権限は制限されません。