Проблемы с безопасностью, позволяющие анонимным пользователям создавать учетные записи и учетные записи SQL Server?

Question

У меня есть богатая клиентская программа, установленная на ПК пользователей, где я хочу начать хранить некоторые пользовательские данные на SQL Azure/SQL Server. Потенциальные пользователи анонимного пользователя будут использовать свое имя, учетную запись электронной почты и пароль, который будет храниться на SQL Azure/SQL Server. Затем они начнут генерировать свои собственные данные. Я ожидаю объемы, возможно, 1000 пользователей.

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

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

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

Пользователи могут вставить только записи с помощью хранимых процедур, которые используют следующие:

SELECT @uName=SYSTEM_USER 

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

Все мнения будут иметь встроенные с ними ИНЕКЕ, такие как

WHERE tbLoginName = SYSTEM_USER. 

Я новичок в SQL Server, так что я может отсутствовать некоторые основные понятия, так что я бы признателен за любые и все комментарии.

Answer 1

Этот вопрос, как указано на http://msdn.microsoft.com/en-us/library/ms189751.aspx:

В SQL Azure, только главный Войти на уровне сервера (созданные в процессе инициализации) или члены роли базы данных loginmanager в основной базе данных может создать новый логины.

Эти учетные записи также могут изменять и удалять логины. Поэтому, если вы вставляете эти учетные записи в клиентское приложение, вы по существу предоставляете каждому пользователю право изменять/удалять учетные записи других пользователей. Хотя средний пользователь этого не сделает, хакер будет. Таким образом, вы не можете позволить клиентскому приложению управлять входами SQL Azure, если только доверенным пользователям (таким как ваш ИТ-администратор) не разрешено использовать это приложение.

С наилучшими пожеланиями,

Ming Xu.

Answer 2

Я хотел бы указать на потенциальную проблему в упомянутом вами подходе: ваша главная учетная запись SQL Azure должна иметь право создавать новые учетные записи и предоставлять им доступ к определенным таблицам. Это означает, что ваша главная учетная запись также должна иметь доступ ко всем этим таблицам. Если вы храните главную учетную запись на стороне клиента, умный пользователь получит доступ ко всем данным пользователей.

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

С наилучшими пожеланиями,

Ming Xu.

Answer 3

Вы по существу создаете физическое двухуровневое соединение с базой данных, позволяющее клиентскому приложению напрямую подключаться к базе данных. Это проблема во многих отношениях, включая безопасность и производительность. С точки зрения безопасности, не контролируя, откуда будут подключаться ваши клиенты, вам нужно будет поддерживать правило брандмауэра для всех в мире, чтобы попытаться взломать каждый клиент uid/pwd. И вместо того, чтобы иметь только 1 идентификатор пользователя, хакеры будут иметь до 1000 ...

Вторая проблема - производительность. Приложениям не удастся использовать пул соединений, создавая чрезмерный стресс на сервере базы данных и, возможно, в какой-то момент могут столкнуться с проблемами дросселирования. Использование веб-службы с членством ASP.NET для управления входами и использование учетной записи службы (то есть того же uid/pwd) для получения данных гарантирует, что вы будете эффективно использовать пул соединений, если вы сохраните строку соединения одинаково для всех ваших запросов ,

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

В облаке вам намного лучше использовать веб-службы.

Мои 2 цента.