windows環境のC#ローカルアプリケーション（パッケージ配布型）をクラウド上のDB/WEBサービスとセキュアに接続する

Question

windows環境のC#ローカルアプリケーション（パッケージ配布型）を
クラウド上のDB/WEBサービスとセキュアに接続するシステム設計について
みなさまのお知恵を拝借させてください。
当方、WEBアプリの開発経験しかなく、ローカルアプリケーション（パッケージ配布型）
と接続するようなシステムの設計・構築経験が全くございません。

●今回構築したいシステム
・クライアントシステム＝windows環境のローカルアプリケーション（パッケージ配布型）
環境：windows、開発言語はC#を予定
・クライアントシステムの使用にはユーザー認証機能が必要（ログインしないと使用できないアプリ）
・ユーザー情報などが格納されているDBはクラウド上に存在
・アプリケーションの一部の機能では、特定のWEBサービスをAPI経由で呼び出す必要がある。
※このWEBサービスもユーザー認証機能が（ユーザーが特定できる）必要である
※WEBサービスAPIは、SSL通信で呼び出す想定

上記を踏まえた上で、どういったシステム設計が妥当と考えられますか？
※一番の疑問・懸念点は、"ローカル"でセキュアに重要なシステム情報を保持できるのか？
保持しても良いものなのか？どこまで保持するべきか？どういった方法で安全に保持できるのか？
あるいは、保持する必要などなく全く別の考え方が必要になってくるのか？
（セキュアなシステム設計のお作法的な意味で、こういった場合の正攻法がわかりません）

私が今考えているのは

1. ローカルアプリケーション自体にDB接続情報とWEBサービス接続情報を？セキュアに？持たせる。

＋
ユーザー認証に使用されるユーザーによる入力値のID/パスワードをクライアントシステム/WEBサービスAPI
の認証に使用する（クライアントシステム/WEBサービスAPIサーバー側それぞれで、DBのユーザー情報を
問い合わせ認証する）。

1. ローカルアプリケーション自体にDB接続情報のみ？セキュアに？持たせる。

＋
ユーザー認証に使用されるユーザーによる入力値のID/パスワードをクライアントシステム/WEBサービスAPI
の認証に使用する（クライアントシステム/WEBサービスAPIサーバー側それぞれで、DBのユーザー情報を
問い合わせ認証する）。
※1との違いは、WEBサービス接続情報（URLやHTTPメソッドの種類）をDBから問い合わせるようにする点。
ローカルではWEBサービス接続情報は保持しないようにする。

1. ローカルアプリケーション自体にWEBサービス接続情報のみ？セキュアに？持たせる。

＋
ユーザー認証に使用されるユーザーによる入力値のID/パスワードをWEBサービスAPI/クライアントシステム
の認証に使用する（WEBサービスAPIサーバー/クライアントシステム側それぞれで、DBのユーザー情報を
問い合わせ認証する）。
※1,2との違いは、DB接続情報をWEBサービスから問い合わせるようにする点。
ローカルではDB接続情報は保持しないようにする。

1. ローカルアプリケーション自体にWEBサービス接続情報のみ？セキュアに？持たせる。

＋
ユーザー認証に使用されるユーザーによる入力値のID/パスワードをWEBサービスAPI
の認証に使用する（WEBサービスAPIサーバー側で、DBのユーザー情報を問い合わせ認証する）。
※1,2,3との違いは、DB接続情報の保持、問い合わせもしない → クライアントシステムから直にDB接続は行わない
全ての機能（DBデータのCRUDに絡む処理）をWEBサービスAPI化し、クライアントシステムはそのAPIを
呼び出すようにする点。

現時点では、DBの接続情報が決して露見することない4が一番安全なような気がしていますが。
いろいろ調べてみてはいるんですが確証が持てずにおります。

どうかお助けいただけると幸いです。

+追記

・toBなシステムになります。
・クライアントパッケージの配布数は500程度で、ユーザー数も同数程度
・サーバーサイドのインフラ構成は自由に決められますが、クライアントパッケージの導入マシーンは、"ざっくり"アプリが動く最低要件のみ提示可能というイメージです。

Comments

[Tak1wa]

おそらく色々なパターンがあると思いますが、エンタープライズ向けなのかコンシューマ向けなのか（不特定多数のユーザが使用する？）・インフラ構成を決めれるのかどうか、も重要な要素のような気がします。

[terasakiyoshio2]

以下の内容を、追記させていただきました。

・toBなシステムになります。
・クライアントパッケージの配布数は500程度で、ユーザー数も同数程度
・サーバーサイドのインフラ構成は自由に決められますが、クライアントパッケージの導入マシーンは、"ざっくり"アプリが動く最低要件のみ提示可能というイメージです。

Answer 1

私も４をお勧めします。
.NETアプリは逆アセンブル(人によっては逆コンパイルとかデコンパイルと言いますが)が簡単にできてしまうので、可読性は落ちるものの、実行ファイルをソースファイルに戻して動きを追うようなことをされないとも限りません。

生のIDやパスワードを保持するようなことはないと思いますが、ログイン処理を行う箇所が見えてしまうので、セキュリティの面からもそういったものをできるだけ持たせない作りにしておく方が安全だと思います。

Answer 2

まずクラウド上のDBを外から生で触れるようにするのはありえないような気が..
もちろんデータセンターとVPN接続とか考えられているのなら話は別ですがたぶん違いますよね
ということで私は4ですね

あと.NET Frameworkを採用するならWCFを使わないと楽ができない気がしますけど、なせかWCFは流行りじゃないんですよね
ここんとこなんでもJSON JSONですよね
別にいいんですが、日付型とかbyte[]型とかガッカリな点も多いです