デスクトップアプリケーションの経験はあまりありませんが、クライアントサーバーデスクトップアプリケーションを作成する必要がある場合、データアクセスはWebサービスを通じて行われます。 Webサービスを介したデータアクセスはセキュリティを提供すると思います。dbサーバーのユーザー名やパスワードなどを渡す必要はありません。
Webサービスの前は、データベースアプリケーションはどのようにこれを行っていましたか?すべての重要なdb情報がデスクトップアプリのインストールに渡されましたか?もしそうなら、プログラマはどのようにセキュリティ面を管理しましたか?または、プログラマーはWebサービスに似たものを使用しましたか?
何をWebサービスと呼ぶかによって異なります。
WSDLとRESTの前は、まだHTTPがあったため、基本的に、今できることはすべて以前にも行うことができました。
統一性に欠けていました(そのため、WSDLとRESTが最初に作成されたのはそのためです)が、これにより、あなたが話しているのと同じレベルのデータ機密性とセキュリティが提供されました。
実際にHTTPの使用を回避することもできます。独自のプロトコルを作成し、このサーバーへのソケットを開いて必要なデータを取得する(またはデータをポストする)カスタムサーバーとカスタムクライアントを使用できます。ここでは、HTTPの標準化のメリットはすべて失われますが、データベースへのアクセスをクライアントに与えることはできません。
ああ、棒と石があったとき。
インターネットの前は、「クライアント/サーバー」アーキテクチャとローカルエリアネットワークと呼ばれるものがありました。数マイル離れたサーバーとの接続を確立しようとしていなかった場合、これらのネットワークは完全に問題なく機能し、ほとんどすべてのことを実行できました。必要に応じて、ドライブ文字を確立し、リモートハードドライブのようなファイルサーバーへの接続を使用することもできます。 あった数マイル離れた場所にいる場合は、広域ネットワークを使用して、速度は遅くても費用はかかりますが、基本的に同じことを行うことができます。
リモートで話すための安価な方法は、モデムと呼ばれるデバイスを使用して電話回線を介して情報を渡すことでした。2台のコンピューターがコンピューターアプリケーションを介して互いにやり取りするようなものを作りたい場合は、今日と同じ方法でやりました。 通信プロトコルを確立します。それについて魔法のようなことは何もありません。両方の側は、すべてのバイトの意味について合意する必要があります。
インターネットのごく初期の段階から、マシンがインターネットを介して通信する方法がありました。 Webサービスは今週の最新のフレーバーです。
最初にいくつかの概念を明確にするために...
Webサービスを介したデータアクセスはセキュリティを提供すると思います。dbサーバーのユーザー名やパスワードなどを渡す必要はありません。
上記のステートメントの(1) トランスポート層セキュリティ(TLS) および(2) アクセス制御 の概念を融合していると思います...ユーザー名とパスワードのどちらを使用するか提供する必要があるかどうかは、Webサービスが(1)暗号化されたチャネルと(2)認証(APIキーなど)を介して提供されるかどうかには関係ありません。
非常に不十分に記述されたWebサービスでも、HTTP経由でパスワードをプレーンテキストで送信する必要がある場合があります。よく書かれていない人は、HTTPSでそれを行う可能性があります(安全ですが、たとえば man-in-the-middle 攻撃によって破壊されると、悪用されます)。より優れたWebサービスは、他の入力に基づいて内部的にデータベース接続を処理する必要があります。認証および資格コントロールが検証された後のセッションID。
要点に戻ると、質問に対する@marcusのコメントは本質的にそれです。セキュリティの側面は、「最新の」テクノロジーと同じように扱われ、次のような実装に関する質問を扱います。
X.X.X.X
でデータベースにユーザー名とパスワードを使用して接続するように通知し、次に クエリを実行するINSERT INTO user_address ...
=?詳細については: