データベースと、ローカル ネットワーク内の複数のマシンにインストールされるクライアント アプリケーションがあり、それらは DB にアクセスできる必要があります。
それらの一部は、DB を編集および変更できる必要があり、一部は単に読み取るだけです。これら 2 つのグループはそれぞれ、誰がどのテーブル/フィールドにアクセスできる必要があるかに基づいて、複数のグループに分けられます。
このアプリケーションを作成するために、DB を保護するために、クライアントと DB の間のプロキシとしての役割を果たす Web サービスをデプロイするようにアドバイスを受けました。
ただし、機密データ (クレジット カード番号など) を転送することはありません。権限のない人が DB を変更できないことを恐れているだけです。
integrated securityapp.config のオプションを使用するだけで十分ではありませんか?
接続文字列を非表示にして保護する必要は本当にあるのでしょうか?
私には船外に聞こえます。アプリケーションが内部でのみ使用され、Windows 認証がオプションである場合は、必ずそれを使用してください。Web サービスの構築は、開発を遅らせ、不要な複雑さの層を追加するだけです。読み取り/書き込みユーザーは、データベースへの読み取り/書き込みアクセスを持つ Windows グループのメンバーである可能性があり、読み取り専用ユーザーは、データベースへの読み取りアクセスのみを持つ Windows グループのメンバーである可能性があります。次に、ユーザーが (フロントエンドを使用せずに) データベースに直接アクセスできる場合、ユーザーは Windows 権限に基づいて読み取りまたは読み取り/書き込みのみを行うことができます。
やり過ぎかもしれませんが、そうではないかもしれません。サービス指向アーキテクチャへの移行は、次のようないくつかの要因に基づいて決定される可能性があります。
要するに、中間層またはデータベースで変更できるようにしたいが、その際にすべてのクライアントをアップグレードする必要がないようにする場合は、サービス層を追加することが方法かもしれません。行く。また、ビジネス ルールとセキュリティを一元化された場所で制御しながら、他のクライアント開発者 (内部または外部) に豊富な API を提供できるという利点もあります。
SOA は間違いなくプロジェクトの複雑さを増しますが、多くの場合、将来の多くの頭痛の種から解放されます。
詳細については、 http ://en.wikipedia.org/wiki/Service-directional_architecture、http: //www.soapatterns.org/、または Google を参照してください。