Защита вашего уровня данных в приложении С#

Ответ 1

В вашем случае есть две основные возможности атаки:

• Украдите строку подключения, а затем напрямую войдите в базу данных
• Вызов методов в коде С# напрямую без использования пользовательского интерфейса

Для строки подключения вам необходимо сохранить ее в зашифрованном виде в файле конфигурации. Проблема в том, что в приложении winforms должно быть достаточно информации, чтобы он мог расшифровать и использовать его.

Для прямого доступа к коду вы можете использовать защиту доступа к коду и обфускацию.

В вашем случае я бы не дал прямому доступу Windows к базе данных. Пусть приложение Windows вызовет службу WCF, служба WCF получит доступ к базе данных.

Учетная запись пользователя пользователя может вызывать службу WCF, служба WCF запускается под учетной записью, которая разрешена для доступа к базе данных, учетная запись пользователя пользователя не имеет прав на базу данных.

Приложение Windows с 3 слоями:

• Пользовательский интерфейс
• Бизнес (проверка безопасности, какой пользовательский интерфейс должен показывать пользователю)
• Proxy

Служба WCF с 2 слоями:

• Фасад/бизнес-уровень (для проверки безопасности пользователю разрешен этот метод с этими данными).
• Entity Framework datamodel

Общая dll для обоих слоев

• Контракты/Интерфейсы WCF
• Объекты передачи данных

Информацию о прокси, контрактах и ​​DTO см. в этом видео:

http://www.dnrtv.com/default.aspx?showNum=103

Ответ 2

Шираз Бхайдз подошел близко, но я думаю, что они пропустили ключевой шаг.

Да, вы хотите получить доступ к базе данных, которая будет опосредована средним уровнем, отображаемым через WCF, который накладывает любую требуемую бизнес-логику, включая полный контроль доступа. У этой службы есть строка соединения, которую вы хотите хранить в секрете, но она не доступна для клиентов WinForm.

Ключевым моментом является то, что клиент использует аутентификацию пользователя для получения соответствующих уровней доступа и никогда не имеет возможности связаться с базой данных или даже получить полный контроль над средним уровнем. Средний уровень предоставляет доступ к методам, основанным на группах, членом которых является пользователь клиента. Это означает, что пользователь с низкой степенью защиты может вызывать любой метод, который им нравится, но они получат доступ к запрещенным исключениям или фильтрацию данных или любой другой режим отказа. Учетная запись пользователя сама по себе не имеет доступа к базе данных, поэтому средний уровень может делать все, что ему нравится.

Очевидным способом обойти это было бы для клиента использовать учетную запись кого-то с полным доступом. Конечно, если бы они могли это сделать, у них уже было то, что они хотели.

Надеюсь, этот подход был бы полезен при решении вашей проблемы.

изменить

Это решение не позволяет LINQ-to-SQL в клиенте, только средний уровень. Если это разбойник, то это не для вас. Опять же, в тот момент, когда клиент может напрямую обращаться к базе данных, открывается гигантская дверь безопасности, и ее трудно закрыть. Там огромное количество дополнительной работы, связанной с обеспечением безопасности самой базы данных, так что она обеспечивает определенную безопасность на уровне пользователей на уровне пользователей, которая возникает, естественно, из трехуровневого решения. Я бы вообще рекомендовал против этого, хотя я действительно признаю, что бывают времена, когда это вполне уместно.

Ответ 3

Один из способов - использовать Trusted Connection to SQL Server, таким образом вы не сохраните имя пользователя и пароль в коде.

Ответ 4

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

Насколько я знаю, нет известных способов безопасного хранения информации о подключении на стороне клиента, так как ваш клиент является "доверенной" частью связи с сервером. Независимо от того, как вы храните информацию, клиент должен иметь возможность отменить ее или отправить ее непосредственно на сервер, что также означает, что потенциальный злоумышленник может повторить этот процесс. Также любая внешняя связь непосредственно с вашей базой данных может быть перехвачена/взломана.

Лучший способ защитить ваши данные - иметь веб-сервис (через безопасное соединение) в качестве промежуточного программного обеспечения, контролирующего связь с вашей базой данных (который вам необходимо защитить) и добавить логику для обеспечения любого уровня безопасности, который вы хотите достичь. Вы можете сделать эту учетную запись для предоставления различных уровней доступа, если это необходимо. Но главное, что он позволяет только безопасные/изолированные операции.

Для защиты веб-сервиса (промежуточного программного обеспечения) существуют две проблемы: аутентификация и изоляция.

Аутентификация

Вы можете использовать стандартную проверку подлинности .NET, как предложил Стивен. Обычно я предпочитаю откатывать свое решение, хотя по двум причинам. Во-первых, до сих пор я в основном работал с более сложными пользователями/ролями. Например, используя роли, основанные на разрешении, чтобы вы могли проверять разрешения вместо определенных ролей.

И во-вторых, это дает вам больше контроля. Вы можете избегать аутентификации на основе сеанса, и вы также можете использовать challenge-response, например, вызов с отметкой времени и ожидающий хеш отметки времени + пароль (который пользователь должен ввести при запуске приложения) или какую-либо другую комбинацию объявлений в качестве ответа, я уверен, что есть лучшие комбинации хэшей для ответа, Это также должно выполняться с двух сторон, чтобы убедиться, что клиент проверяет все, что он получает с сервера.

Также есть некоторые SO-темы о разрешении WCF, которые могут быть интересны: шаблоны авторизации службы WCF Авторизация и аутентификация с использованием WCF Авторизация WCF - доступ к операциям с помощью претензий А также книга и документ (не бесплатно )

Выделение

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

Вам нужно будет идентифицировать уровни изоляции, чтобы пользователи не могли влиять друг на друга или на систему в целом, а также на то, как приложение используется. Будут ли клиенты писать данные или читать только? Если они пишут, записываются данные, разделенные каким-либо образом, и каким образом вы можете изолировать/проверить эти данные? Если они читают, является ли конфиденциальная информация для пользователя, конфиденциальной для системы или общего пользователя?

Например, система хранения медицинских журналов или личных списков задач будет иметь очень изолированные данные, и вы можете ограничить доступ только к вашей личной информации (и, возможно, к своему врачу/боссу в зависимости от групп пользователей). В этом случае вы можете изолировать все данные для чтения/записи конкретному пользователю, таким образом, злоумышленник может воздействовать только на свои собственные данные, сохраняя при этом всех остальных.

Если данные распределяются между пользователями, вам потребуется какой-то способ проверки ввода, который предоставляется пользователю. Желательно, чтобы у вас также был какой-то доверительный уровень для пользователя, такой как репутация SO, чтобы предотвратить попытки разобраться с разовыми пользователями. Это действительно слишком специфично, чтобы давать полезные советы.

Вам также необходимо проверить ввод, который вы получаете, чтобы предотвратить взломы, такие как переполнение буфера переходов и SQL-инъекции. Хотя я не знаю, является ли переполнение буфера проблемой .NET, а SQL-инъекции должны быть легко предотвращены с помощью LINQ-to-SQL.

В целом нет гарантированного гарантированного качества ваших данных на 100%, и вы должны сохранять регулярные резервные копии (отдельно от вашей базы данных) ваших данных в случае, если вы получаете компрометацию и, возможно, также журналы транзакций.

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

Также вы можете использовать LINQ с веб-сервисами через LINQ to ADO.NET, хотя у меня нет попробовал это сам.

Эта ссылка может быть более объяснима Как перейти от LINQ to SQL к "LINQ to WCF"?

Ответ 5

Если безопасность важна, например, когда вы храните информацию о кредитной карте, обычно вам нужен репозиторий данных и веб-сервер в отдельных блоках с межсетевым экраном между ними и заблокированными IP Security.

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

Вы также можете рассмотреть SSL-шифрование в веб-службах и выставить только конечные точки HTTPS.

Ответ 6

Я здесь не совсем понятен. Если приложение winforms вызывает webservice, тогда используйте подходящую модель для взаимно доверенной аутентификации. Это может быть основано на сертификатах клиентов и серверов или SSL с сертификатами клиентов или даже Net.Tcp, если вы все .Net. Затем, однако, веб-служба подвергается воздействию только доверенных клиентов. Затем вебсервис может оставаться за DMZ и DB за другой DMZ. Используйте соответствующие правила брандмауэра, а IPSec-соединение между webservice и SQL - это вариант.

Для прямого подключения к SQL-серверу во множество приложений winforms много проблем. Соединение с вашей БД должно быть аутентифицировано и зашифровано. В любом случае ваш SQL-сервер будет открыт, и я бы не рекомендовал такую ​​модель.

Ответ 7

Вы не защищаете его, потому что не можете его защитить. Во-первых, вы не можете правильно скрыть учетные данные, даже если вы выясните, как это сделать, тогда злоумышленник может понюхать (да, даже если он зашифрован, вы можете локально обнюхать) или выполнить SQL Injection прямо на провод.

Вам необходимо написать все вызовы webservice безопасным способом, который не требует передачи необработанного SQL-запроса или прямого подключения SQL Server.

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

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

Ответ 8

Безопасный метод:

Поместите слой данных за службу (WCF) на физически отдельный сервер приложений и попросите клиентов WinForms подключиться к службе с использованием их учетных данных Windows. Затем служба проверяет, могут ли пользователи получать доступ к различным методам службы на основе хранилища авторизации (например, Active Directory) и базы данных или их комбинации.

Затем служба данных может использовать единый объединенный идентификатор для подключения к базе данных.

Ответ 9

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

В терминах файла конфигурации можно зашифровать сам файл или использовать встроенную защиту в качестве упомянутого другого плаката.

Ответ 10

Трудно дать точный ответ, потому что я не уверен, какие конкретные проблемы вы пытаетесь решить и который является ключевым драйвером для обеспечения безопасности системы.
Однако в прошлом я использовал безопасную связь WinForms → WebService, используя WSE
Мы использовали сертификаты X509 и WS-Security. Это имеет явное преимущество предоставления End To End Security вместо того, чтобы полагаться на стандартный SSL-транспорт.
Однако это само по себе не решает такие проблемы, как аутентификация пользователя как таковая, в этом случае Mitch Wheat answer кажется хорошим решением.
Тем не менее, ваша модель проверки подлинности пользователя будет зависеть от того, является ли это общедоступным распределенным приложением, зависит ли количество пользователей инструмента от большого или малого и т.д.
Для небольшого числа пользователей или где стоимость не является проблемой, вы можете реализовать аутентификацию RSA SecurID, настроив RADIUS-сервер или тому подобное. Это имеет то преимущество, что каждый ключ RSA уникален и привязан к этому пользователю (хотя вы никогда не можете остановить пользователя, выдающего свои учетные данные и PIN-код).

НТН

Ответ 11

Ответ прост для защиты. Строки sql просты. НИКОГДА не делайте прямого подключения к SQL на стороне клиента.

Принимать только хорошо сформированные, проверенные схемой xml-сериализованные объекты в качестве входа в вашу программу после аутентификации в хэшированной паре открытого частного ключа (http://msdn.microsoft.com/en-us/library/6f05ezxy.aspx), являющийся сертификатом открытого ключа, отправленным в вашу программу, поэтому кто-то подслушивает не обнаружит пароль.

Также обратите внимание на атаки DDOS. Измерить использование каждой веб-службы, открытой для каждого клиента, и, если использование превысит заданный предел, заблокируйте все входящие соединения от пользователя и из IP-адреса пользователя.

Ответ 12

Если я правильно понимаю ОП, непреложными конструктивными характеристиками являются клиент WinForms, который напрямую подключается к общедоступному SQL Server?

Почти каждый, кто ответил, в основном сказал: "Не делай этого, вместо этого используйте веб-сервис". Это хороший совет. Даже если ws взломан, он может делать только то, что он должен был сделать. Таким образом, RPC WS может выполнять только написанные методы, тогда как взломать соединение SQL Server позволит произвольное выполнение SQL. Кроме того, я думаю, вы обнаружите, что хорошо спроектированная веб-служба будет более эффективной.

Однако, если вы собираетесь это сделать, вы должны защитить свое SQL-соединение через SSL (см. technet) в качестве запуска, Как и в случае безопасных веб-сервисов (которые также будут использовать SSL), это скроет содержимое трафика от людей посередине.

Вы не можете полагаться на аутентификацию строки подключения (но с ее помощью добавляется еще один уровень для хакера, чтобы пройти), поэтому у вас должен быть уровень аутентификации уровня приложения, который вы, скорее всего, будете катиться самостоятельно.

Не позволяйте приложению WinForms подключаться к вашей операционной базе данных. Создайте вместо этого другую базу данных и позвольте подключаться к ней на основе строки подключения. Не выполняйте динамический SQL с этим дизайном, вместо этого используйте хранимые процедуры. Создайте хранимые процедуры в своей публичной базе данных, которые будут действовать как ваш "веб-сервис rpc", чтобы скрыть реальный SQL (который будет запрашивать вашу операционную базу данных и возвращать результаты). Это скроет оперативные детали вашей схемы и уменьшит площадь атаки.

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

Не понимая, почему вы должны разрешать прямое соединение sql, я могу только сказать снова, что вы не должны этого делать. То, что вы набираете, делая это в краткосрочной перспективе, зависит от вашей долгосрочной безопасности системы.