0

非常に基本的な質問があり、他の専門家がこれをどのように行うかを知りたい
のですが、数百人のユーザーがいるアプリケーションがあります。私はこれらのユーザーを認証するためにSQLログインを使用しています。これらのユーザーには、パスワードポリシーが適用されています。また、ユーザーのパスワードの有効期限が切れると、問題が発生します。つまり、SSMSから自分でパスワードをリセットする必要があります。それは私がする他の仕事と一緒に時々難しい仕事になります。

一部の専門家から、独自のユーザーテーブルを作成し、そのテーブルにすべてのユーザーの詳細を含めることをお勧めします。次の列を持つユーザーテーブルを作成しました。

  • ユーザーID
  • ユーザー名
  • パスワード
  • PasswordCreationDate
  • PasswordExpiryDate
  • PasswordActive

1つの簡単な質問。ユーザーはどのようにデータベースに接続しますか。オフコース私はアプリケーションからの接続文字列が必要になります。その接続文字列にはユーザー名とパスワードが必要ですよね？データベースに接続するまで、ユーザーテーブルから情報を取得できません。

もう1つの問題は、最後の5つのパスワードを追跡するにはどうすればよいですか。ポリシーによると、ユーザーは、すでに使用されている最後の5つのパスワードを使用できません。

パスワードの有効期限が「n」日であり、有効期限が切れる前にパスワードを変更する必要があることをユーザーに通知するソリューションを入手できれば、これをすべて回避できます。

他の開発者は、ユーザーを認証するときに何をしますか。案内してください

4

3 に答える 3

1

ユーザーのログイン資格情報をデータベースに保持している場合、SQLサーバー自体にアクセスするには、アプリ全体で1回のログインのみが必要になる場合があります。アクセス権を強制するのはアプリケーション次第であるため、このログインはデータベースへのフルアクセスを持ちます。

このルートを使用する場合は、次の2つの点に注意する必要があります。

  1. Reporting Services、Crystal Reports、Infomakerなどのツールを介してユーザーにアドホックレポート機能を提供する必要がある大規模なアプリケーションには、セキュリティ上の懸念があります。この場合、ユーザーはこれらのレポートツールを使用して、彼らが見ることができないはずのデータベース。
  2. ユーザーの独自の資格情報を保存する場合は、それが適切に行われていることを確認する必要があります。つまり、プレーンテキストのパスワードはありません。暗号的に安全なパスワードハッシュ（md5ではありません！）とユーザーごとのソルトが必要です。それがあなたにとってギリシャ語であるならば、これを放っておくのが最善です。

利用できるもう1つのオプションは、データベースにActive Directory/Windows認証を使用することです。ここでの秘訣は、すべてのユーザーのアクセス権を設定する必要があるということです。ただし、これにActive Directoryグループを使用して、作成する必要のあるログインの数を減らすことができます。ユーザーはActive Directoryアカウントでログインするため、少なくともSQLServerのログインを手動でリセットする必要はありません。

于 2012-12-24T07:11:58.913 に答える
1

Webアプリケーション間で非常に一般的なシナリオは、1つのユーザー名/パスワードを使用することです（したがって、1つのSQLログインのみ、通常はアプリケーションに対する最小限の権限を持つある種の専用ログイン）。このようにして、接続プールを使用できます。これはもちろんバックエンドアカウントであり、web.configで構成され、エンドユーザーには表示されません。

ユーザーは、アプリケーション内のデータの一種として維持されます。Asp.netには、メンバーシップと呼ばれるソリューションが付属しています。ユーザー認証はメンバーシッププロバイダーに対して行われ、いくつかのクラスにより、認証や役割などのプログラムによるサポートが提供されます。たとえば、ADをプロバイダーとして使用したり、認証を形成したりできます。または、独自に作成することもできます。

現在、ユーザーごとに専用のSQLログインを使用しているため、このアプローチによりデータアクセスのセキュリティがアプリケーションレベルに移行することに注意する必要があります。したがって、これは必ずしもあなたのニーズに合うとは限りません。

于 2012-12-24T07:05:20.810 に答える
0

理想的には、既存のActive Directoryインフラストラクチャを使用して個々のユーザーの認証/承認を処理し、エンドユーザーの資格情報をWebサーバー経由でSQLサーバーに渡すことができます（おそらくKerberosの処理を検討する必要があります）これを実行するための「ダブルホップの問題」）。

しかし、これに失敗すると、ユーザーレベルの認証情報を取得するために、アプリケーション自体がデータベースにアクセスするためのSQLログインを持つように設定するのは簡単です。ユーザーパスワードの一方向ハッシュは、アプリのパスワードが接続文字列から読み取られた場合でも、ユーザーパスワードを取得できないようにします。

または、これら2つのソリューションの中間で、DB内からユーザーアカウント情報を取得するために、アプリケーションがAD内にサービスアカウントを持ち、SQLデータベースにアクセスできます。

いずれにせよ、ADが利用可能な場合は、Kerberosサービスポイント名を使用してさらに保護し、予想されるエンドポイント（つまり、ASP.NETサーバー）からのみデータベースにアクセスできるようにすることができます。

于 2012-12-24T07:01:07.357 に答える