2

SecureStringMySql-Connector の接続文字列としての一般的な質問があります。私がそれを正しく理解していればSecureStrings、プログラム内に文字列を保存する「安全な」方法です。今、私はそれに2つの問題があります:

  1. インストール時にパスワードを読み込む必要があります（TextBoxこれはstring安全ではありません）
  2. string(再び安全ではない) MySQL-Connector の接続文字列を作成する必要があります。

例：

MySqlConnection con = new MySqlConnection();
MySqlConnectionStringBuilder builder = new MySqlConnectionStringBuilder();
builder.Add("SERVER", "loaclhost");
builder.Add("PORT", "3306");
builder.Add("DATABASE", "test_db");
builder.Add("UID", "root");
builder.Add("PASSWORD", "11235813"); //not the real password ;)
con.ConnectionString = builder.ConnectionString;
con.Open();

これにより、次の問題が発生します。すべての値がプレーンテキストとして保存されるため、MySQL-Connector API は「安全ではありません」string。

最後の質問: を使用する意味はありますSecureStringか?

私の意見stringでは、プログラムのどこでも使用できます。MySQL に関して言えば、(私のプログラム内の) あらゆる種類の暗号化は役に立たないでしょう。

私はその意見で正しいですか？他の方法はありますか？

よろしくアレックス

4

1 に答える 1

1

それを行う他の方法があります。それは、接続文字列の後に誰が来ると思うか、および彼らが持つアクセスの種類とスキル レベルによって異なります。接続文字列は、どのように隠そうとしても、どこかにあります。

接続文字列がハッキングされる可能性があることを知っているので、私は常にハッキングされると想定し、反対側で予防策を講じています。

接続文字列が侵害された場合でもデータが安全であることを確認するために、DB サーバー側でいくつかのことを行います。

  • 接続文字列に関連付けられているユーザーには、サーバーに対するアクセス許可が事実上ありません。彼らが持っている権限は、ストアド プロシージャを含む SCHEMA に対する EXECUTE と CONTROL だけです。
  • フロント エンドが持つ唯一のアクセスは、ストアド プロシージャを介したものです。フロントエンドが SQL 文字列を送信することを決して許可しません。
  • データは、実行可能ファイルとは別のスキーマに保持されます。DATA スキーマでは、接続文字列に関連付けられているユーザーにはゼロのアクセス許可があり、データを見たり、匂いを嗅いだり、触ったりすることはできません。
  • ストアド プロシージャは、プロシージャを実行するのに十分な権限を持つログインしていないユーザーに権限を委任します。(WITH EXECUTE AS 'no-login User')

これが私たちにできるすべてです。接続文字列がどこかで何らかの方法で公開されるのを防ぐ方法は見つかりませんでした。

アレックスが以下に尋ねた質問に答えて。（コメントするには長すぎます）

ノート。以下は MS SQL Server の場合です。他の DBMS システムにも適用される可能性がありますが、他のシステムについては保証できません。

データベースにはスキーマが含まれ、スキーマにはテーブル、ビュー、ストアド プロシージャなどのデータベース オブジェクトが含まれます。schmea を使用すると、データベース オブジェクトを隔離することができます。たとえば、誰でも見ることができるテーブルのグループがある場合、それらを COMMON スキーマに入れることができます。それを PAYROLL スキーマに変換します。その後、SCHEMA 内にあるオブジェクトのタイプに基づいて、SCHEMA にさまざまなセキュリティ対策を講じることができます。これらはグラフィカルにハード ドライブ上のフォルダのように見え、その下にすべてのデータベース オブジェクトが含まれています。サーバーを起動すると、いくつかのスキーマが自動的に作成されます。あなたが最もよく知っているのは、DBO schmea でしょう。管理者がそれをデフォルト スキーマとして設定している場合は、気付かないかもしれません。

私たちがしていることは、すべてのデータを DATA schmea に配置することです。これは、テーブルのみが許可されることを意味します。したがって、給与データベースがある場合、データ テーブルは dataPayroll というスキーマに入ります。

ストアド プロシージャは、呼び出されたときにデータベース サーバーが実行できる 1 つまたは複数の SQL コードのブロックです。データのテーブル、または単一の値を返すことができます。C# のメソッドと考えてください。

ストアド プロシージャには、SQL コードで使用される入力パラメーターと戻りパラメーターがあります。パラメーター化されたストアド プロシージャは、SQL インジェクション攻撃に対する強力な防御手段です。

私たちのプロトカルは、ストアド プロシージャとビューがすべて「prog」で始まるスキーマに格納されていると述べています。そのため、給与データベースの場合、データではないオブジェクトはすべて progPayroll スキーマ内にあります。

接続文字列によって定義されたユーザーは、「prog」スキーマに対する制御権限と実行権限のみを持ちます。これにより、ストアド プロシージャを呼び出すことができます。接続文字列によって定義されたユーザーは、他のすべてのアクセス許可を拒否されます。このユーザーは、他の場所でもすべての権限を拒否されます。ストアド プロシージャでは、データにアクセスする権限は、EXECUTE AS コマンドを使用して「データ」スキーマからデータを取得する権限を持つ NO LOGIN ユーザーに委任されます。

フロントエンドにはSQLはありません。フロントエンド プログラマーが知っているのは、ストアド プロシージャの名前、パラメーター、戻り値の型と値だけです。

このように、攻撃者がプログラムから接続文字列を引き出すことに成功したとしても、攻撃者が所有するユーザーはストアド プロシージャしか実行できないため、データベースに対して何かを実行できるようにするためには、まだ多くの作業を行う必要があります。

このようなものが何であるかわからない場合は、DB プログラマーにシステムをセットアップしてもらう必要があります。

于 2013-08-09T15:51:41.780 に答える