sql-server - SQL Server/Windows 統合セキュリティは何の役にも立ちますか?

Question

Windows ユーザー権限と SQL Server GRANT のセットの違いは、無関係な概念のように思えます。多くの場合、実際にはデータベースロールの疑似ログインで実装されているようです。しかし、それは Windows のアクセス許可に有効にマップされません。単一ログイン ID 検証を前提として、可能な限り単純なデータベースロールを使用しないのはなぜでしょうか?

編集:
これまでのところ、アプリケーションにパスワードを保存する必要がないという 1 つの利点を取り上げてきました。しかし、それは設計目標というよりも、些細な有益な結果のように思えます。両方の宇宙のセキュリティ装置全体を密接に結合することなく、それを達成するためのより直接的な方法は他にもたくさんあります。

もう一度編集:
単一のログインとSDがグループを維持する機能以外に、提案する利点はありませんか?

グループの問題にはいくつかの欠陥があります。たとえば、AD マネージャーは両方を維持する資格があると想定されています。また、AD の一部ではないネットワーク接続を除外します (そのため、MS テクノロジにロックされます)。

ベストプラクティスの用語で言えば、システムの結合を組み込みましたが、これは一般に悪いことであると認められています。

score 10 · Accepted Answer

これらの多くは言われているか、以前の回答に似ています... AD統合の場合：

a) 特定のアプリケーションにアクセスできるユーザーについて心配する必要はありません。それをセキュリティ担当者に渡すことができます。

b) 既に存在するグループに基づいて、テーブルレベルごとにテーブルでのアクセスを制限したり、標準ユーザーにストアドプロシージャの呼び出しのみを強制したりできます。

c) 開発者が私のグループを離れるとき、すべての DB パスワードを変更する必要はありません (つまり、データのセキュリティが気になる場合...)

d) 変更を行ったユーザーに基づいてカスタムログを作成するのは簡単です。これを行う方法は他にもありますが、私はすべて怠け者です。

e) IIS 認証と統合します。イントラネットに IE と IIS を既に使用している場合は、これで作業がずっと楽になります。

注: 使用しない理由は他にもたくさんありますが、現在のポジションになるまで使用したことはありません。ここでは、AD にすべてが既に揃っています...データベースセキュリティに関して、これまでで最も簡単な時期です。

score 6 · Accepted Answer

統合セキュリティを使用する場合、アプリはセキュリティについて何も認識したり処理したりする必要はありません。また、ユーザーが既にドメインにログインしている場合は、アプリにもログインする必要はありません (なりすましがあると仮定します)。正しく設定してください)。

最大の利点は、AD グループを SQL Server のログインとして使用することです。このようにして、「Accounts」グループの全員に一連の sprocs、テーブルなどへのアクセス権を付与し、「Managers」グループの全員に別のセットへのアクセス権をすべて AD で付与できます。システム管理者は、アプリへのアクセス権をユーザーに付与するために Management Studio にジャンプする必要はありません。

score 4 · Accepted Answer

基本的には、「車輪の再発明をしない」ことと、「多くの目」効果を利用することにあると思います。

Windows 認証を使用すると、必要に応じて独自のものを追加できる上に、Windows 統合セキュリティの力を活用できます。これは、何百万回もテストされた成熟したシステムであり、自分で間違いを犯して後で発見/解決するための労力 (およびクライアントのコスト) を節約します。

そして、多くの人が常に Windows 認証プロセスをスキャンし、脆弱性をチェックし、それを回避する方法を模索しています。脆弱性が公に開示され、それに対する修正プログラムが作成されると、アプリケーションは「無料」のセキュリティ強化を取得したことになります。 .

私の現在の作業では、AD グループを SQL ログインとして使用しているため、メンバーシップに基づいて SQL 権限を AD グループに割り当てています。したがって、sys エンジニアリンググループのすべてのメンバーにはいくつかの権限があり、DBA にはその他の権限があり、通常のユーザーにはその他の権限があり、スーパーバイザーにはその他の権限があります。データベースで取得する必要がある権限。

投稿編集:

「車輪の再発明」を少し拡張します。AD アカウントに対して、特定のマシンにログインする権利を拒否するか、1 つか 2 つを除いてすべてのマシンからロックアウトすることができます。同時に 2 つ以上のワークステーションにログインするのを防ぐことができます。しばらくしてからパスワードを変更するように強制できます。さらに、最小限の強度を強制することもできます。その他のいくつかのトリックは、すべてシステムのセキュリティを向上させます。

SQL S. ユーザーの場合、このようなことはありません。複雑な SQL ジョブや自作のデーモンのようなものを使ってそれらを強化しようとしている人を見てきました。

そして、ユーザー SA (または特権ユーザー) がどのマシンからもログインするのを止めることはできません。インターネット経由でリモートログイン用のポートを開いている SQL S に対するブルートフォース攻撃を阻止する巧妙な方法について聞いたことがあります。SQL + Windows だった場合、管理者に特定のボックスからのみログインさせるか、Windows 認証のみを完全に使用して、最初に VPN を通過させるように強制することができます。

score 3 · Accepted Answer

他の誰もが Windows 認証の利点について話し合っているので、私は悪魔の支持者を演じると思います...

アカウント 'Joe User' にサーバーへのアクセスを許可するということは、アプリに接続できるだけでなく、他の手段 (SQL ツール、Excel、マルウェアなど) を介して接続できることを意味します。

SQL 認証を使用すると、アプリを特定のユーザーとして実行でき、アプリはデータベースアクセスを処理できます。したがって、'Joe User' がアプリを実行すると、アプリは SQL アクセス権を持ちます... しかし、'Joe User' 自身はそうではありません。つまり、前述のアプリはデータベースへの暗黙的なアクセス権を持つことができません。

score 2 · Accepted Answer

統合セキュリティが本当に役立つのは、イントラネットアプリだけです。私が確認した疑似ログインは、ほとんどがインターネット Web アプリケーション用です。

とにかく、アプリにパスワードを保存しないだけではありません。とにかくパスワードをソルトしてハッシュすることを願っています。次のものもあります。

ユーザーがログインする必要はありません。これは、1 日中散発的に Web アプリケーションにアクセスする場合や、複数の内部 Web アプリケーションがある場所で作業している場合に重要です。
IT 管理者は Active Directory でユーザーを編集するだけでよいため、ユーザー管理は無料です。
ユーザー名とロール名は、組織全体で一貫しています。
ユーザー偽装は、内部 Web サービスにアクセスする際のより安全な方法です。(たとえば、インターネット Web サイトがイントラネット Web サービスにアクセスする)
すべてがシームレスに処理されるため、Web アプリケーションはデータベースに対して追加のユーザー認証を行う必要はありません。
[編集] データベースオブジェクトのユーザーも知っています。したがって、ビューに関連付けられた行のみを返すようにすることができます。(アプリユーザーごとに新しい SQLServer ユーザーを作成しない限り、これは不可能であり、アプリユーザーごとに新しい SQLServer ユーザーを作成することも無理があります)

統合セキュリティはすべてに適しているわけではありませんが、企業にとっては多くの付加価値があります。

score 2 · Accepted Answer

SQL 認証を介して接続すると、ほとんどのアプリケーションからデータベースに対して実行されるクエリの応答時間が大幅に短縮されるというのが私の経験です。AD にセキュリティ検証を常に要求することで発生する遅延を取り除きます。

パフォーマンスに関する SQL 認証 >> Windows 統合セキュリティ。

score 2 · Accepted Answer

はい、もちろん、アプリケーションレベルのデータアクセスレイヤーをサービスとして実行している場合は、統合セキュリティを使用して、アプリケーションの「サービスアカウント」を使用してデータベースと通信し、サーバーにログインできます...アプリケーション構成ファイルにユーザーパスワードを保存するため、データベースへの新しい接続ごとにネットワーク経由でパスワードを渡しません

score 2 · Accepted Answer

SQL ログイン: ネットワーク上の難読化されたクリアテキストパスワード

NTLM を使用した Windows 統合ログイン: ネットワーク経由で渡されるハッシュ

Kerberos を使用した Windows 統合ログイン: 適切な安全な認証。

セキュリティを重視するなら、選択肢は 1 つしかありません。

score 1 · Accepted Answer

データベースには、ユーザーごとに異なる多くの設定を使用して、きめ細かいアクセスを設定できます。アプリケーションへのアクセスに 1 人のユーザーがいて、それがすべてのデータセキュリティであるシナリオだけではありません。

チーム開発について話している場合、おそらく、データベースへの開発アクセスを許可されたユーザーグループが存在するでしょう。このグループの各ユーザーは内部ドメインのメンバーになり、データベース管理者が管理するはずのない独自のパスワードを持ち、データベースへのアクセスを許可することさえ知っています.

score 1 · Accepted Answer

grant table/etc 側を無視して、ログイン側は非常に便利です。アプリは Windows 認証を使用して SQL サーバーに接続できるためです。つまり、

データベースのユーザー名とパスワードをアプリケーションのどこかにあるファイルに入れる必要はありません

プレーンテキストファイルにパスワードを入力すると、セキュリティ上のリスクが生じます。それを回避することは素晴らしいことです。

score 1 · Accepted Answer

統合されたセキュリティにより、ユーザーアクセス IMO の柔軟性が向上します。たとえば、組織が開発者グループがサーバーにアクセスできる時間を制限したい場合、統合セキュリティが最善の策です。

しかし、それはすべてに適しているわけではありません。

[編集] アクセスのログ記録にも最適です。大規模な組織で新しい開発者ごとに SQL ログインを作成する必要があるとしたら... おそらくそれは行われなくなり、ログインが共有されるようになるでしょう。テーブル。

score 1 · Accepted Answer

SQL サーバー認証を使用すると、パスワード情報がネットワーク上でクリアテキストとして送信されるという事実はどうでしょうか。統合セキュリティにはその問題はありません。

score 1 · Accepted Answer

統合セキュリティはうまく使えば良いと思います。どういうわけか理解できませんが、私が働いてきた多くの企業では、AD、SQL アクセス許可、および IIS セキュリティモデルをあまり利用していません。

SQL Server のアクセス許可システムを設計する必要があり、それが AD に統合されているという重要な要件がある場合、おそらく非常によく似たものを思いつくでしょう。私見では。

ユーザーを AD グループにグループ化し、SQL Server でさまざまな権限を持つグループログインを作成するのが好きです。データベースに接続するためのツールを持っているからといって、人々がデータへのアクセスを増やすべきではありません。接続方法に関係なく、データに対して同じ権限を持つ必要があります。

ゲストユーザー (匿名の Web ユーザーなど) は、IIS 構成に関する推奨事項に従って、自分自身の AD グループに属している必要があります。このグループに、データベース内でアクセスできる必要があるものへのアクセスのみを許可することで、いつの日かデータを災害から救うことができます。ソースコードを読んでデータが保護されているかどうかを確認するのは難しく、データベースのアクセス許可とセキュリティ構成を調査するのははるかに簡単です。

また、パスワードが常に配布されたり、構成ファイルに入れられたりするため、統合されていないセキュリティは良くありません。

score 0 · Accepted Answer

AD 環境で実行されるエンタープライズアプリケーションの場合、Windows 統合セキュリティを使用することは間違いなく正しいアプローチです。環境で既に認証されているユーザーが、アプリのためだけに別の資格情報セットを管理する必要はありません。認証について話していることに注意してください...承認のために、 SQLサーバーのロールベースのセキュリティを引き続き使用します。

sql-server - SQL Server/Windows 統合セキュリティは何の役にも立ちますか?

14 に答える 14

Related

Reference