Обеспечение Слоя Данных в Приложении C#

Если нет планы относительно нового VM некоторого вида (и я не услышал ни о каких подобных планах), существует вся причина полагать, что в конечном счете производительность Py3K будет, по крайней мере, асимптотически, равняться производительности 2,5

, Это может занять несколько месяцев, но в конечном счете произойдет, поскольку ничто в новых возможностях Py3k не по сути менее производительно.

В заключение, я не думаю, что существует место для волнения об этом. Ни один для надежды на основное улучшение некоторого вида.

12
задан Filip Ekberg 1 August 2009 в 09:07
поделиться

12 ответов

In your case there are two main attack possibilities:

  • Steal the connection string and then access the database directly
  • Call methods in your C# code directly without using the UI

For the connection string you need to store it in an encrypted form in a config file. Problem is that there need to be enough information in the winforms app so that it can decrypt and use it.

For accessing the code directly you can use code access security and obfuscation.

In your case I would not give the windows app direct access to the database. Let the windows app call a WCF service, the the WCF service would access the database.

The user's user account is allowed to call the WCF service, the WCF service is running under an account that is allowed to access the database, the user's user account has no rights to the database.

Windows App with 3 Layers:

  • UI
  • Business (Security check what UI should be shown to the user)
  • Proxy

WCF Service with 2 Layers:

  • Facade / Business Layer (Security check is user allowed to call this method with this data)
  • Entity Framework datamodel

Common dll's to both Layers

  • Contracts / WCF Interfaces
  • Data Transfer Objects

For info on proxy, contracts and DTO's see this video:

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

14
ответ дан 2 December 2019 в 06:45
поделиться

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

3
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

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

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

редактировать

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

4
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

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

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

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

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

Также вот несколько тем SO о авторизации WCF, которые могут быть интересными: Вы можете избежать аутентификации на основе сеанса , а также можете использовать запрос-ответ , например, запрос с меткой времени и ожидать хэш метки времени + пароль (который пользователь должен ввести в application start) или какую-либо другую творческую комбинацию в качестве ответа, я уверен, что есть лучшие хеш-комбинации для ответа. Это также должно быть сделано в двустороннем порядке, чтобы убедиться, что клиент проверяет все, что он получает от сервера.

Также вот несколько тем SO о авторизации WCF, которые могут быть интересными: Вы можете избежать аутентификации на основе сеанса , а также можете использовать запрос-ответ , например, запрос с меткой времени и ожидать хэш метки времени + пароль (который пользователь должен ввести в application start) или какую-либо другую творческую комбинацию в качестве ответа, я уверен, что есть лучшие хеш-комбинации для ответа. Это также должно быть сделано в двустороннем порядке, чтобы убедиться, что клиент проверяет все, что он получает от сервера.

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

Изоляция

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

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

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

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

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


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

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

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

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

2
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

Также, когда кто-то написал, ваш веб-сервис будет открыт для прямого доступа.

0
ответ дан 2 December 2019 в 06:45
поделиться

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться

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

HTH

0
ответ дан 2 December 2019 в 06:45
поделиться

Ответ прост: защитить строки sql просто. НИКОГДА не устанавливайте прямое соединение с SQL на стороне клиента.

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться

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

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

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

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

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

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

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

0
ответ дан 2 December 2019 в 06:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: