2

内部セキュリティにより、開発者が本番データベースのユーザー名とパスワードを知らないことが必要な状況があります。

web.config 変換を使用して、web.config ファイルを手動で編集することによって展開中に発生する人為的なエラーの数を削減しようとしています。理想的には、web.config を完全に自動化し、人間の介入を必要としないようにしたいと考えています。

これには、開発者 (私たちの組織で web.config 変換を作成および変更する方法を知っている唯一の開発者) が、運用環境の接続文字列情報を知る必要があることを理解しています。

本番環境の接続文字列を開発者に知らせずに、web.config 変換の維持を開発者だけに任せる方法はありますか?

4

5 に答える 5

3

これが私が思いついた解決策であり、チームに提案しています。

問題: 環境間の展開中に発生する人為的な構成エラーを排除するために、web.config 変換の使用を必要とする新しい標準を実装したいと考えています。これには、web.config 変換ファイルの作成を担当する担当者が、他の環境への接続文字列のユーザー名とパスワードを含む、各環境のすべての構成値を知っている必要があります。インフラストラクチャ チームには、書き込みアクセス権を持つデータベース ユーザーのユーザー名とパスワードを彼ら以外は知ることができないというポリシーがあります。したがって、私たちは対立しています。

提案された解決策: web.config 内の任意の構成セクションは、web.config ファイル自体で明示的に定義する代わりに、そのセクションの構成を含む外部ファイルを指すことができます。
たとえば、接続文字列セクションを次のように定義する代わりに、

<connectionStrings>
    <add name="conn_ExceptionManagement" connectionString="Data source=mydb;database=App_Error_Logging;uid=user;pwd=password" providerName="System.Data.SqlClient" />
  </connectionStrings>

次のように定義できます。

<connectionStrings configSource="myApp.ConnectionStrings.config"/>

次に、「myApp.ConnectionStrings.config」というファイルを次の内容で作成します。

<?xml version="1.0"?>
<connectionStrings>
    <add name="conn_ExceptionManagement" connectionString="Data source=mydb;database=App_Error_Logging;uid=user;pwd=password" providerName="System.Data.SqlClient" />
  </connectionStrings>

そのため、Web サーバーのルートに「CONFIG」というフォルダーを作成し、その中に各アプリケーションのファイルを「myAppName.ConnectionStrings.config」のような名前で配置できます。そのファイルには、その環境でアプリケーションに使用するすべての接続文字列を入れます。次に、web.config 変換で、接続文字列を明示的に更新する代わりに、接続文字列構成セクションを変更して、Web サーバー上のそのファイルを指すようにします。このように、インフラストラクチャ チームは、これらの環境の接続文字列を実際に確認できる唯一の人物であり、展開中に web.config 内の接続文字列を変更する必要がなくなります。加えて、

于 2012-10-05T13:46:49.617 に答える
2

このことを考慮：

  • 暗号化されたパスワード (たとえば SHA-2 を使用) を含むデータベースで、" salt " が含まれています。パスワードは平文の「鍵」によって識別されます。

  • 特定のキーの暗号化されたパスワードを返す Web サービス。

  • (salt を指定して) パスワードを復号化し、平文のパスワードを返す標準ライブラリ。

Web アプリケーションは接続文字列全体を保存できますが、パスワードにはプレースホルダーを使用できます。接続の準備が整うと、アプリケーションは Web サービスを呼び出し、暗号化されたパスワードを取得し、パスワードを復号化します (編集: パスワードを復号化するには、Web アプリケーションに保存されているソルトを使用する必要があります)、接続を修正します。文字列、接続を確立し、パスワードを忘れます。

完璧な解決策ではありませんが (IT 担当者を信頼できないのに、なぜあなたのために働いているのでしょうか?)、プログラマーがパスワードを知ることはできません。追加の利点として、Web 構成で接続文字列を更新する必要なく、パスワードを個別に管理できます (たとえば、パスワードを期限切れにする)。

本当に「全力」を出したい場合は、 SecureStringにも興味があるかもしれません。(接続文字列を構築するためにSecureString
をプレーンテキストに変換する必要があることを考えると、SecureStrings の使用について説明している良い記事があります。archive/2009/06/12/how-to-properly-convert-securestring-to-string.aspx )

編集
最終的に、最も安全なオプションは、データベース接続を Web サービスにラップし、独自のカスタム認証システム (または Active Directory など) を使用して Web サービスにアクセスすることです。Web サービスは、データベースへのクエリを単独で担当し、集中管理することができます。それを使用する Web サイト (およびそれらの Web サイトのプログラマー) は、データベースの詳細を知りません。

このアプローチには、データベースを完全に再構築する機能 (テーブル/ストアド プロシージャの変更は Web サービスにのみ関係する)、サーバー間の切り替え (問題なく SQL Server から MySQL に移行する) など、非常に多くの利点があります。 Web サイトを消費する)、負荷分散、追加のセキュリティ層など。

于 2012-10-04T20:32:24.027 に答える
0

webconfig 接続文字列を暗号化および復号化するクラスを使用します。復号化して使用する接続文字列に対して取得が実行されるたびに...暗号化は、接続文字列を最初に暗号化してweb.configファイルに入れるために使用するツールメソッドにすぎません

これを行うために使用できる双方向の暗号化プロバイダーが多数あります。

于 2012-10-04T20:32:00.097 に答える
0

はい、接続文字列の暗号化をご覧ください: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.100).aspx

于 2012-10-04T20:27:38.860 に答える
0

web.config の更新を自動化することは間違いなく良い方法ですが、この目的で web.config 変換を使用する価値はあまりありません。スクリプト言語 (VBScript、PowerShell など) から呼び出し可能な XML API があり、これは同様に簡単で柔軟性があります。

web.config でデータベース資格情報を使用している場合は、次の一部またはすべてを検討します。

  • データベースが Windows 認証をサポートしている場合 (SQL Server など)、データベースへの接続に Windows 認証を使用するのが理想的です。これにより、データベースの資格情報を管理するタスクから解放されます。

  • web.config の接続文字列でパスワードを更新できる小さなユーティリティを記述します。これは、標準の XML API を使用して簡単に実行できます。管理者はこれを使用して、運用サーバーにデプロイするときにパスワードを更新できます。

  • Protected Configurationを使用して運用サーバー上の web.config を暗号化します。サーバー上で直接暗号化を行うことで、暗号化キーを別の場所にコピーする必要がなくなります。たとえば、単一サーバーの場合は DPAPI を使用します。または、web.config を複数のサーバー (Web ファームなど) で使用する必要がある場合は RSA。

    パスワード更新ユーティリティは、これを自動的に行うことができます。

于 2012-10-04T20:59:35.363 に答える