データベースに直接接続するクライアントサーバーアプリケーションは良い考えですか？
データベースに直接接続する複数のクライアント（1〜5）を備えた、安全なマルチユーザーのクライアントサーバーアプリケーションを作成できますか？または、カスタムサーバーアプリケーションを作成し、WCFまたは類似のものを介して接続する必要がありますか？
現在、DBに直接接続していますが、まだ認証を実装していません。 SQL Server認証認証の使用は良い考えですか？
問題は、アプリケーションにユーザー管理を実装する必要があり、すべてのユーザーアクション（レコードの追加/レコードの変更）をdbに記録する必要があることです。私がsqlユーザーを使用している場合、ユーザーは資格情報を使用してデータベースに直接接続することで、アプリケーションのログ記録メカニズムをバイパスできます。
WCFは適切なソリューションのように見えますが、アプリケーションアーキテクチャの開発と変更にはより多くの時間が必要です（アプリケーションの開発時にそれを考慮に入れましたが、まだ多くの変更が必要です）。また、WCFについてはあまり知りません。
これは内部（インターネットに接続されていない）アプリケーションですが、機密データが含まれます。
編集：ユーザーは信頼されていません。
それはすべて、システムの要件に依存します。内部でのみアプリケーションを使用する1〜5人のユーザーがいて、Windowsドメインがある場合、はい、物理的に2層のアプリケーションはすばらしい設計です。ただし、論理的にはn層をコーディングする必要があるため、これらの要件が変更された場合に、物理層をより簡単に分離できます。 ADグループメンバーシップを使用し、統合セキュリティを使用してデータベースに接続できます。 ADグループをDBユーザーにマップし、その役割/グループに基づいてDBで権限を付与します。
私はそのようなシステムを構築し、それはうまくいきました。ユーザーの半分がオフィスを別の町の場所に移動するまで。それらは論理的にはDBと同じネットワークの一部でしたが、VPNトンネルは非常に遅いT1回線上にありました。アプリは新しい場所から使用できませんでした。幸い、Csla.Netフレームワークを使用してn層アプリケーションを設計し、構成ファイルの変更、アプリサーバー（IISサーバー）のセットアップを行うことができ、問題は解決されました。ビジネスオブジェクトがアプリサーバーにシリアル化され、おしゃべりdbが機能したため、クライアントアプリケーション間のネットワークの雑談が少なくなりました（また、DBとIISサーバーは同じネットワークスイッチ上にありました） 、次にシリアル化されます。
もちろん、WCFでも同じことができます。今構築するだけで心配する必要はありませんが、WCFサービスを構築するための先行費用がかかります。ただし、要件が変更され、DBコードの雑談が問題になる場合は、準備ができています。必要に応じて、ビューやその他のDBオブジェクトを使用してセキュリティを強化することもできますが、挿入/更新/削除ステートメントの薄いラッパーであるSPは、必要以上のメンテナンスであることがわかりました。
アプリケーションの詳細を知らない限り、この質問に対する明確な答えはありません。
ユーザー管理に関してはほとんど違いはありません。
さらに重要な点は、次のとおりです。長期取引が必要ですか？
もしそうなら2層アーキテクチャの方が簡単に構築できます。それ以外の場合、そこにあるほとんどのフレームワークは、ビジネスロジックをデータベースの外側の中央で許可する層アーキテクチャをサポートしています。
「ロギング要件、DBに直接接続している悪意のあるアクターを停止し、他のユーザーとしてレコードを追加する方法（他のIDを挿入）について懸念があります。」
これに対する解決策は、優れたデータベース設計にあります。ユーザーがデータベース内のテーブルに直接アクセスできないようにしてください。
viewsを介してアクセスを提供します。ユーザーがそれらに対してDMLを実行すると、セキュリティモデルで必要なフィールドを変更、追加、または削除できます。例えば。ユーザーがDMLで渡した「ユーザーID」を実際のデータベースセッションから取得したUserIdに置き換えることができます。