SQL Server認証のADユーザーとSQLユーザー

Question

私の会社には、顧客サイトに展開する複数のWebアプリケーションがあります。多くの場合、顧客は展開オプションで最終的な発言権を持っています。

これらの顧客の多くは、サーバー管理者と同じActive Directory資格情報を使用して、配備されたデータベースを指すようにWebアプリケーションを配備しています。何らかの理由でアプリケーションが侵害された場合、攻撃者はサーバーおよびネットワークへのアクセス権も取得します。

SQL ServerにActive Directoryを使用する正しい目的は何ですか。私がそれを使用すると考えられる唯一の健全な理由は、複数のSQL Serverを備えたWebファームで、適切なアクセス許可でこれらのサーバーすべてにアクセスするための分離されたアカウント/グループがあり、それでも特定の環境で懸念がある場合です。これらのユーザーとグループは、マシン/サーバーの管理者アカウント（アカウントはサーバーにログインしたりデータベースにログインしたりすることはできません）などの他の権限から隔離されたままである必要があるという私の想定は正しいですか？

それとも、SQLサーバーにADを使用してはならない単なる遅延セキュリティですか？

おかげで、

Xander · Accepted Answer

理想的には、SQL Serverにアクセスするユーザーまたはアプリケーションは、それらを正しく識別し、必要に応じてSQL Serverやデータベースへの適切なレベルのアクセス権が割り当てられている資格情報のセットを使用する必要があります。実行する。

SQL認証はレガシー認証メカニズムであり、適切に構成された環境ではまったく有効にすべきではありません。 Microsoftはお勧めしませんそして、セキュリティの観点から、ユーザーまたはアプリケーションのIDと認証コンテキストとの関連付けを解除することは悪いことです。

これで解決しました、あなたは確かにアプリケーションがサーバーまたはドメイン管理者アカウントのコンテキストでデータベースにアクセスしてはならないことは正しいです。 Webアプリケーションは、Webアプリケーションの機能（機能するために必要なデータベースへの適切なアクセスを含む）を実行するために必要な権限を持つアカウントで実行する必要があります。

結局のところ、これはAD認証とSQL認証の問題ではなく、使用制限付きアカウントの使用（またはその欠如）、または最小特権の原則の違反に関する問題です。彼らがSQL認証を使用していないという事実は問題ではなく、実際には正しい設計です。一方、ADアカウントに過剰な権限があるという事実は、お気づきのとおり、深刻な問題であり、対処する必要があります。

Sven Vermeulen · Answer

SQL ServerにActive Directoryを使用することには多くの利点があり、推奨されるアプローチになります。 SQL DBAは、多くの場合、データベースをWindows統合認証（WIA）モードのみ（SQL認証もサポートする「混合モード」ではなく）にすることを望んでいます。

ADを使用する場合、アカウント認証は一元化されます。環境内に存在するすべてのアカウントの概要が1つあります。アカウントが侵害された場合は、ADで1回だけ取り消す必要があります。 SQL認証では、すべてのSQL Serverにログインして削除する必要があります。
ADを使用する場合、パスワードのローテーション（必要な場合）は一元化されます。 SQL認証では、すべてのターゲットでログオンしてパスワードを変更する必要があります（多くの場合、パスワードを変更する必要はありません）。
ADを使用する場合、パスワードは単一の中央リポジトリに保存されます。 SQL認証では、SQLデータベース自体に格納されます。 SQLサーバーへの攻撃ベクトルが一般に大きいため、ADの強化はSQLサーバーの強化よりもはるかに単純です（そうです、これはケース固有です）。
ADを使用すると、認証はより安全に行われます（Kerberosを使用）。これにより、攻撃者がパスワードを取得して取得することが困難になり、中間者攻撃（MITM）の攻撃を受けにくくなります。また、パスワードとは異なり、Kerberosチケットは他のサービスに対して再利用できません。各チケットはサービスに固有です（この場合、単一のSQL Serverサービスの場合）。別のサービスに対して認証するには、新しいチケットを取得する必要があります。
WIAを使用する場合、SQL Serverにアクセスするアカウントを管理するには、通常、ランタイム（サービス）アカウント（アプリケーションサーバーが実行されているアカウント）に権限を付与するだけで済みます。 SQL認証の場合のように追加のアカウントを作成する必要はありません。これにより、影響分析も一元化されます。IISサーバーが危険にさらされた場合、リスクを軽減するためにIISサービスアカウントのみを取り消す必要があります。SQL認証を使用する場合、設定でSQL認証アカウントが使用されているかを調べる必要がありますIISサーバー。
WIAを使用する場合、アプリケーションサーバーは接続用のユーザーIDとパスワードを保存する必要はありません。これも、侵害されたシステムの影響を軽減します。
WIAを使用する場合、リモートログインを無効にすることができます。これは、SQL Authenticatedアカウントでは不可能です。

shalomew · Answer

ユーザーにデータベースへのアクセスを許可する場合、ユーザビリティとセキュリティの点で、長所と短所に関していくつかの考慮事項があります。ここでは、認証とユーザーへのアクセス許可を付与するための2つのオプションがあります。 1つは、すべてのユーザーにsa（システム管理者）アカウントへのアクセスを許可し、必要に応じてアクセス許可を付与または拒否できるユーザーのリストを保持して、アクセス許可を手動で制限することです。これは、SQL認証方式とも呼ばれます。以下に示すように、この方法には重大なセキュリティ上の欠陥があります。 2番目の優れたオプションは、Active Directory（AD）に必要なすべての認証と承認（Windows認証とも呼ばれる）を処理させることです。ユーザーが自分のコンピューターにログインすると、アプリケーションはオペレーティングシステムのWindowsログイン資格情報を使用してデータベースに接続します。

SQLオプションを使用した場合の主要なセキュリティ問題は、最小特権（POLP）の原則に違反することです。POLPは、ユーザーに絶対に必要なアクセス許可のみを与え、それ以上は許可しないことです。 saアカウントを使用すると、深刻なセキュリティ上の欠陥が生じます。アプリケーションがsaアカウントを使用すると、データベースサーバー全体にアクセスできるため、POLPに違反します。一方、Windows認証は、サーバー上の1つのデータベースへのアクセスのみを許可することにより、POLPに従います。

2番目の問題は、アプリケーションのすべてのインスタンスが管理者パスワードを持つ必要がないことです。これは、すべてのアプリケーションがサーバー全体の潜在的な攻撃ポイントであることを意味します。 Windowsは、SQL ServerへのログインにWindows資格情報のみを使用します。 WindowsパスワードはSQLデータベースインスタンス自体とは対照的にリポジトリに保存され、認証はアプリケーションにsaパスワードを保存する必要なしにWindows内で内部的に行われます。

3番目のセキュリティ問題は、SQLメソッドを使用することによって発生し、パスワードが含まれます。 MicrosoftのWebサイトやさまざまなセキュリティフォーラムで紹介されているように、SQL方式ではパスワードの変更や暗号化は強制されず、ネットワーク経由でクリアテキストとして送信されます。また、SQLメソッドは失敗した試行の後でロックアウトしないため、侵入の試みが長時間続く可能性があります。ただし、Active Directoryは、Kerberosプロトコルを使用してパスワードを暗号化し、パスワード変更システムと試行の失敗後のロックアウトも使用します。

効率の面でも不利です。ユーザーがデータベースにアクセスするたびに資格情報を入力する必要があるため、ユーザーは資格情報を忘れる可能性があります。

ユーザーが削除される場合は、アプリケーションのすべてのインスタンスから資格情報を削除する必要があります。 sa adminパスワードを更新する必要がある場合は、SQLサーバーのすべてのインスタンスを更新する必要があります。これは時間がかかり安全ではないため、却下されたユーザーがSQL Serverへのアクセスを保持する可能性があります。 Windowsの方法では、これらの問題は発生しません。すべてが一元化され、ADによって処理されます。

SQLメソッドを使用する唯一の利点は、その柔軟性にあります。リモートからでも、どのオペレーティングシステムやネットワークからでもアクセスできます。一部の古いレガシーシステムと一部のWebベースのアプリケーションは、saアクセスのみをサポートする場合があります。

ADメソッドは、グループなどの時間節約ツールを提供して、ユーザーの追加と削除を容易にし、ユーザー追跡機能も提供します。

SQLメソッドのこれらのセキュリティ欠陥をなんとか修正したとしても、車輪を再発明することになります。パスワードポリシーを含み、POLPに従うなど、Windows認証によって提供されるセキュリティ上の利点を検討する場合、SQL認証よりもはるかに優れた選択肢です。したがって、Windows認証オプションを使用することを強くお勧めします。