当社は、多数のクライアントとそのワークステーションのそれぞれにリッチ クライアント アプリケーションとしてロードされる、当社が販売する製品にデータベース サービスを提供する SQL Server 2000 環境を備えたデータ センターです。
現在、アプリケーションはクライアント サイトからデータセンターへの直接 ODBC 接続を使用しています。
現在はすべてがクリアテキストであり、認証は弱い暗号化であるため、資格情報の暗号化を開始する必要があります。また、クライアントへの影響を最小限に抑えながらサーバー上で SSL を実装する最善の方法を決定しようとしています。
ただし、いくつか注意点があります。
1) 当社には独自の Windows ドメインがあり、すべてのサーバーは当社のプライベート ドメインに参加しています。当社のクライアントは当社のドメインに一切アクセスしません。
2) 通常、クライアントは次のいずれかの方法でデータセンター サーバーに接続します。a) TCP/IP アドレスを使用する、b) 当社がインターネット経由で公開する DNS 名を使用する、当社の DNS サーバーから顧客へのゾーン転送を使用する、またはクライアントが静的 HOSTS エントリを追加する。
3) 暗号化を有効にすると、ネットワーク ユーティリティに移動して、暗号化するプロトコルの「暗号化」オプションを選択できると理解しています。たとえば、TCP/IP などです。
4) 暗号化オプションを選択すると、サードパーティの証明書または自己署名証明書をインストールする選択肢があります。自己署名証明書をテストしましたが、潜在的な問題があります。後で説明します。Verisign や Network solutions などのサードパーティ証明書を使用する場合、どのような証明書を要求すればよいですか? これらは IIS 証明書ではありませんか? Microsoft の証明書サーバー経由で自己署名証明書を作成する場合、「認証証明書」を選択する必要があります。これはサードパーティの世界では何を意味するのでしょうか?
5) 自己署名証明書を作成する場合、「発行先」の名前は、SQL を実行しているサーバーの FQDN と一致する必要があることは理解しています。私の場合は、プライベート ドメイン名を使用する必要があります。これを使用すると、クライアントが SQL Server に接続しようとすると、どのような影響がありますか? クライアントは、ネットワーク上で私のプライベート DNS 名を解決できないのは確かです...
また、自己署名証明書がインストールされている場合、SQL Server を実行しているユーザー アカウントのローカル個人ストアに証明書が保存されている必要があることも確認しました。SQL Server は、FQDN が証明書の「発行先」と一致し、証明書がインストールされているアカウントで SQL が実行されている場合にのみ起動します。
自己署名証明書を使用する場合、検証のためにすべてのクライアントに証明書をインストールしてもらう必要があるということですか?
6) サードパーティの証明書を使用した場合 (これが最善の選択肢と思われます)、証明書の検証に使用するプライベート WAN 接続のプライベート サーバーにアクセスするときに、すべてのクライアントがインターネットにアクセスできる必要がありますか?
FQDN についてはどうすればいいですか? 公開されていない私のプライベート ドメイン名を使用する必要があり、私が設定したドメイン名は使用できなくなっているようです。
7) 近々 SQL 2000 にアップグレードする予定です。SQL 2005 では、SSL のセットアップは SQL 2000 より簡単/優れていますか?
ご協力やご指導をいただければ幸いです
答え1
正直に言うと、データベース サーバーに直接アクセスするのをやめるのが最善策です。これは本質的に弱いソリューションです (セキュリティの観点から)。誰でも sa アカウントを使用して SQL Server にログインできるからです。
より良い解決策としては、Web サーバー上に Web サービスを設定し、アプリケーションからこの Web サービスに HTTPS 経由でリクエストを送信し、Web サービスからリクエストをデータベースに転送し、データベースをパブリック インターネットから切断 (またはファイアウォールで保護) する方法があります。
また、Web サーバーはデータベースと通信するだけなので、問題なくデータベースを切り替えることができるという利点もあります。また、Web 層の負荷を分散できるため、規模が拡大しても接続負荷を Web サーバー全体に分散できます。