詳しい方のために、パスワードを Windows Azure 構成ファイル (RoleManager 経由でアクセス) に保存するための推奨事項を教えてください。次のことが重要です。
1) 開発者は、自分のローカル ボックスでテストしながら、すべての実稼働データベースに接続できる必要があります。これは、同じ構成ファイルを使用することを意味します。
2) 開発者は、デプロイされているものと同じ (または非常に類似した) 構成ファイルを必要とします。パスワードは判読可能であってはなりません。
構成内のパスワードが判読できない場合でも、開発者は接続文字列を取得するためにデバッグ/監視できることを理解しています。これは望ましくありませんが、少なくとも許容されます。受け入れられないのは、人々がこれらのファイルを読み取って接続文字列 (またはパスワードを必要とする他の場所) を取得できることです。
一番のおすすめは?
ありがとう、
アーロン
ええと、開発者はそもそも本番データベースにアクセスすることは想定されていません。これは、Azureにあるか他の場所にあるかに関係なく、本質的に安全ではありません。本番データベースに対してライブデバッグを実行することはリスクの高いビジネスです。単純なミスが本番全体を台無しにする可能性があるためです。代わりに、本番データを複製して（最終的には一晩のプロセスとして）、開発者が非本番コピーに対して機能するようにすることをお勧めします。
ある種の資格情報ストレージ サービスによって部分的に解決される可能性があると思います。パスワードを必要としないが、マシンとホワイトリストに登録されている SSPI 認証済みユーザーのみにアクセスを許可する一種のサービスを意味します。このサービスは、次のような単純な原則を使用して、SSL サーバーでホストされる単純な WebAPI にすることができます。1) 保存されたデータへのすべての変更は、サービスをホストするサーバーへの RDP アクセスまたは SSH 経由でのみ行われます。2) 保護された情報は SSL 経由でのみアクセスされ、この API は読み取り専用です。3) クライアントは、自身の権限を事前に確認し、 https: //s.product.com/ のような API を呼び出して一時トークンを取得する必要があります。 3) クライアントは証明書を提供する必要があり、マシン ID は各呼び出しでリソースの論理ホワイトリスト データと一致する必要があります。4) データのリクエストは次のようになります。 Url: https://s.product.com/resource-name ヘッダー: X-Ticket: 手順 3 で取得した値 (有効期限が切れるまで)、証明書: 手順 3 で使用したものと同じ証明書.
そのため、ユーザー名とパスワードの代わりに、そのような保護されたリソースのエイリアスを接続文字列に格納することができます。コードでは、このエイリアスは、Sql 接続ファクトリで手順 4 から取得した実際のユーザー名とパスワードに置き換えられます。エイリアスは、obscured@s.product.com/product1/dev/resource-name のような特別な形式でユーザー名として指定できます
Dev インスタンスと prod インスタンスは、product1.dev/resource1 と product1/staging/resource1 などのように、異なる認証情報エイリアスを持つことができます。
そのため、prod サーバーをデバッグするか、そのトラフィックをスニッフィングするか、ログを埋め込む (コンパイル時にコードを電子メールで送信する) ことによってのみ、実際に保護されたリソースの運用資格情報を知ることができます。