MySQL SecureString как строка подключения

Question

У меня есть общий вопрос о SecureString как строка подключения для MySql-Connector. Если я правильно понял, SecureStrings - это «безопасный» способ хранения строк в моей программе. Теперь я имею две проблемы с этим:

1. Я читать в пароле при установке (TextBox который string и поэтому небезопасно)
2. Я построить строку подключения для MySQL-разъем который string (небезопасно снова)

пример:

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-Con nector API является «небезопасным», поскольку все значения хранятся в виде открытого текста string.

Заключительный вопрос: Есть ли смысл использовать SecureString?

По-моему, я мог бы использовать string всюду в своей программе. Если дело доходит до MySQL, все виды шифрования (в моей программе) будут бесполезны.

Справился ли я с этим мнением? Есть ли другие способы?

наилучшими пожеланиями Алекс

Answer 1

Есть и другие способы сделать это. Это зависит от того, кто, по вашему мнению, отправляется после вашей строки подключения и какого типа доступа и уровней навыков они будут иметь. Строка подключения находится где-то, независимо от того, как вы пытаетесь ее скрыть.

Зная, что строка соединения может быть взломана, я всегда предполагаю, что она будет взломана и примет меры предосторожности на другом конце.

Мы делаем несколько вещей на конце сервера БД, чтобы убедиться, что даже если строка соединения сведена, данные по-прежнему защищены.

• Пользователь, который связан со строкой подключения, имеет практически нулевые разрешения на сервере. Единственные разрешения, которые у них есть, - EXECUTE и CONTROL на SCHEMA, которые содержат хранимые процедуры.
• Единственный доступ, который имеет передняя часть, - это хранимые процедуры. Мы никогда не разрешаем внешнему концу отправлять строки SQL.
• Данные хранятся в отдельной схеме, чем в исполняемых файлах, в схеме DATA пользователь, связанный со строкой подключения, имеет разрешения ZERO, они не могут смотреть на него, обонять или прикоснуться к нему.
• Хранимые процедуры делегируют полномочия пользователю без входа, который имеет достаточные разрешения для выполнения proc. (WITH EXECUTE AS 'no-login User')

Это все, что мы можем сделать. Мы не нашли способ помешать какой-либо передаче какой-либо строки подключения.

В ответ на вопрос, который Алекс спросил ниже. (слишком длинный для комментариев)

Примечание. Ниже приведен пример MS SQL Server, он может применяться к другим системам СУБД, но я не могу поручиться за другие.

База данных содержит схему, схема содержит объекты базы данных, такие как таблицы, представления, хранимые процедуры. Шема позволяет вам отбросить объекты базы данных, например, если у вас есть группа таблиц, которые кому-либо разрешат видеть, тогда они могут перейти в схему COMMON, если у вас есть информация о платежной ведомости, которую вы должны были защитить, вы могли бы поставить это в схему PAYROLL. Затем вы можете поместить различные меры безопасности в SCHEMA на основе типа объектов, которые внутри них. Графически они выглядят как папки на жестком диске, а под ними все объекты базы данных, которые они содержат. Когда вы запускаете свой сервер, существует несколько схем, которые автоматически создаются. Тот, с которым вы больше всего знакомы, будет DBO schmea. Возможно, вы не знаете об этом, если ваш администратор настроил это как схему по умолчанию.

Мы делаем это, чтобы поместить все данные в DATA schmea, это означает, что разрешены только таблицы. Поэтому, если бы у нас была база данных платежной ведомости, тогда таблицы данных перешли бы в схему, называемую dataPayroll.

Сохраненная процедура представляет собой блок или блоки кода SQL, которые сервер базы данных может выполнять при вызове. Он может возвращать таблицу данных или одно значение. Подумайте об этом как о методе на C#.

Сохраненные процедуры имеют параметры ввода и возврата, которые используются в коде SQL. Параматизированные хранимые процедуры - это сильная защита от атак SQL Injection.

Наш протокал говорит, что хранимые процедуры и представления хранятся в схеме, которой предшествует «прог». Таким образом, в случае базы данных платежной ведомости все объекты, не являющиеся данными, находятся внутри схемы progPayroll.

Пользователь, который определен строкой Connection, имеет только права на управление и выполнение на схеме «prog». Это позволяет им вызвать хранимую процедуру. Пользователь, который определяется строкой Connection, лишен всех других разрешений. Этот пользователь также не разрешает ВСЕ разрешения везде. В хранимой процедуре разрешение на доступ к данным делегируется пользователю NO LOGIN, которому разрешено извлекать данные из схемы данных, используя команду EXECUTE AS.

В передней части нет номера. Все программисты на передней панели знают, что такое имя хранимых процедур, параметры и типы и значения возврата.

Таким образом, даже если злоумышленнику удается вычеркнуть строку подключения из вашей программы, у них все еще есть много работы, чтобы сделать что-либо в вашей базе данных, поскольку пользователь, который у них есть, может выполнять только Хранимая процедура.

Если вы не знаете, что из этого происходит, вам действительно нужно, чтобы программист БД установил вашу систему для вас.