ファット クライアントがアクセスする SQL Server データベースを保護する方法はありますか? 意味: アプリケーションは、SQL ステートメント自体を配置するときに、データベースと直接通信します。つまり、接続文字列はクライアントのどこかにある必要があります。この接続文字列 (winauth または sql サーバー認証のいずれか) を使用すると、ユーザーは管理スタジオまたはコマンド ラインを使用してデータベースにアクセスし、GUI が許可するものとは異なるステートメントをデータベースに配置できます。
それについて何をすべきか?このアーキテクチャは修正されているため、クライアントとデータベースの間に別のレイヤーを配置することはできません。
3 に答える
Windows や SQL 認証を含むすべてのセキュリティ モデルで、アクセス権はアプリケーションではなくユーザー(ID) に付与されます。したがって、アプリケーションが必要とするアクセス権は、アプリケーションを実行しているユーザーに付与する必要があります。Windows 認証が使用されている場合、これは、同じユーザーが SSMS クエリから、アプリケーション自体が必要とするすべての特権を利用できることを意味します。これは、管理者が理解しなければならない基本的な規則です。セキュリティの観点から (CC コンプライアンスなどを意味します)、これは事実であり、それを回避しようとする試みは運命づけられています。
しかし、実際的な観点からは、展開できる特定の対策があります。最も一般的に使用されるのは、適切に定義された一連のクライアント ワークステーションと、適切に定義された一連のユーザーからのみ SSMS へのアクセスを検証して許可するログオン トリガーを使用することです。APP_NAME()
CREATE TRIGGER reject_SSMS
ON ALL SERVER WITH EXECUTE AS '...'
FOR LOGON
AS
BEGIN
IF (APP_NAME() = 'Microsoft SQL Server Management Studio'
OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query')
AND (ORIGINAL_LOGIN() NOT IN (...)
OR HOST_NAME() NOT IN (...))
ROLLBACK;
END;
このようなメカニズムは、悪意のあるユーザーによって簡単に回避される可能性があるため、セキュリティ機能ではないことを理解することが重要です。それらはドアロックのようなものです。泥棒を締め出すのではなく、正直なユーザーを正直に保ちます。
これが、SQL Server のアクセス許可の目的です。
基になるテーブルへのアクセス許可をユーザーに付与せずに、ビューまたはストアド プロシージャでユーザーにアクセス許可を付与するなどの操作を実行できます。
あなたはアプリケーションロールを調べたいと思うかもしれません
何よりもまず、SQL インジェクションの脆弱性の要点は、攻撃者がクエリを操作できることです。この意図的なプロトコルは、さらに深刻な脆弱性です。しかし、これはCWE-602: Client-Side Enforcement of Server-Side SecurityおよびCWE-603: Use of Client-Side Authenticationの明らかな違反でもあります。
これを安全にするには、次のことを行う必要があります。
また、各ユーザーはロックダウンされた独自のデータベースを持っている必要があります。同様に、選択/更新/削除/挿入のみがあり、他の権限はありません(特に xp_cmdshell()!!!! はありません)。ユーザーがデータベースを共有できるようにすることはできません。そうしないと、攻撃者が他のユーザーの情報を閲覧できるようになります。攻撃者は、常にSQL サーバーのユーザー名/パスワードを取得し、自分のクライアントに直接接続することができます。この関係が安全であると考えるのは難しいです。ほとんどの場合、これは重大な脆弱性です。
実際には、これは非常に深刻なアーキテクチャ上の欠陥であり、クライアントのクワイアを構築するサーバー側コンポーネントを構築する必要があります。これは通常、SOAP (ms プラットフォームの場合は wcf) で行われます。