Является SQL Server / интегрированной защитой Windows, хорошей для чего-нибудь?

Итак, после долгих проб и ошибок я нашел решение, которое работает. (Вероятно, это не самый чистый / рекомендуемый подход)

Шаг 1) Добавьте каждую ось джойстика (все 28) для каждого контроллера (все 8) в вашем диспетчере ввода. (Сценарий может сделать это очень просто / намного меньше времени)

Шаг 2) Создайте свой собственный Input Mapper. (Определите «вверх» и «влево» каждого контроллера.)

Шаг 3) Сохраните эти результаты в файле «PlayerPrefs».

Шаг 4) Создайте свой собственный сценарий обнаружения ввода. (Единственное, что необходимо для доступа к диспетчеру ввода Unity - это ось джойстика.) Другие кнопки можно выполнить вручную из (строк), загруженных из файла PlayerPrefs.

Плюсы этого подхода:

  • Работает как ловить всех. (Для любого контроллера, устройства, компьютера и т. Д.)
  • Очень стабильно!
  • Позволяет максимально контролировать все входы и то, что они делают.

Минусы:

  • Кажется немного смешным делать все это.
  • Достаточно много времени. (Но может легко использоваться снова в будущих проектах)
  • Кажется небрежным, но прекрасно работает.
6
задан Stefan Steiger 17 April 2015 в 10:41
поделиться

13 ответов

Многие из них были сказаны или подобны предыдущим ответам... С AD интеграцией:

a) Я не должен волноваться о пользователях, у которых есть доступ к любому данному приложению, я могу выдать это парням безопасности.

b) Я могу ограничить доступ за таблицей уровнем таблицы на основе групп, который уже существует, а также то, чтобы вынуждать типичных пользователей только иметь способность назвать сохраненный proc's.

c) Когда разработчик оставляет мою группу, мы не должны изменять все пароли DB (т.е. если Вы заботитесь о безопасности данных...),

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

e) Интегрируется с аутентификацией IIS. Если Вы уже используете IE & IIS для своей интранет, это просто делает жизнь намного легче.

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

9
ответ дан 8 December 2019 в 02:35
поделиться

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

0
ответ дан 8 December 2019 в 02:35
поделиться

Я думаю, что интегрированная защита хороша, если она используется правильно. По некоторым причинам я не могу понять, много компаний, в которых я работал, не использует AD, полномочия SQL и модель обеспечения безопасности IIS очень.

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

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

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

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

1
ответ дан 8 December 2019 в 02:35
поделиться

Как насчет того, что при использовании аутентификации SQL Server информация о пароле отправляется через сеть как открытый текст. Интегрированная защита не имеет той проблемы.

1
ответ дан 8 December 2019 в 02:35
поделиться

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

Но это не правильно для всего.

[РЕДАКТИРОВАНИЕ] Также это является большим для входа доступа. Если бы я должен был создать вход в систему SQL для каждого нового разработчика в крупной организации, то... это, вероятно, прекратило бы происходить, и логины совместно использовать, то я никогда не буду уверен в способности показать пальцем на knucklehead, кто отбросил таблицу.

1
ответ дан 8 December 2019 в 02:35
поделиться

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

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

1
ответ дан 8 December 2019 в 02:35
поделиться

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

Вы не должны помещать свое имя пользователя базы данных и пароль в файле в Вашем приложении где-нибудь

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

1
ответ дан 8 December 2019 в 02:35
поделиться

да, конечно, Если у Вас есть свой уровень доступа к данным прикладного уровня, работающий как услуга, можно использовать интегрированную защиту, чтобы говорить с databasem использование Приложения "Сервисная учетная запись" для входа сервера... Затем Вы надеваете; t должны сохранить пароли пользователя в файле конфигурации приложений, и Вы не передаете пароли по сетевой ели каждая новая связь, установленная с базой данных

2
ответ дан 8 December 2019 в 02:35
поделиться

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

Так или иначе Это больше, чем просто не хранит пароль в Вашем приложении, так как, надо надеяться, Вы посолили бы и хешировали бы свой пароль так или иначе. Существует также:

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

  2. Управление пользователями свободно, так как администратор IT только должен отредактировать пользователя в Active Directory.

  3. Имена пользователей и Ролевые имена последовательны всюду по организации.

  4. Пользовательское олицетворение является более безопасным методом при доступе к внутреннему веб-сервису. (например; интернет-веб-сайт получает доступ к веб-сервису интранет),

  5. Веб-приложение ничего не должно делать авторизация дополнительного пользователя на базе данных, так как это все обрабатывается беспрепятственно.

  6. [РЕДАКТИРОВАНИЕ] Вы также знаете пользователя в своих объектах базы данных. Таким образом, у Вас может быть представление, только возвращают строки, связанные с ними. (если Вы не создаете нового пользователя SQLServer для каждого пользователя приложения, это было бы невозможно, и создание нового пользователя SQLServer для каждого пользователя приложения также неблагоразумно),

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

2
ответ дан 8 December 2019 в 02:35
поделиться

Так как все остальные обсудили преимущества аутентификации Windows, я предполагаю, что буду играть Адвоката Дьявола...

Позволяя учетной записи 'Пользователь Joe' иметь доступ к серверу подразумевает, что не только может быть подключение с Вашим приложением, но и он может также соединиться через любые другие средства (Инструменты SQL, Excel, вредоносное программное обеспечение, и т.д.).

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

3
ответ дан 8 December 2019 в 02:35
поделиться

Я предполагаю это в основном вниз к "не изобретению велосипед" и использованию в своих интересах "многих глаз" эффект.

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

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

В моей текущей работе у нас есть AD группы, поскольку SQL входит в систему, таким образом, мы присваиваем полномочия SQL на основе членства в AD группах. Таким образом, у всех членов sys технической группы есть некоторые полномочия, DBAs имеют другой, других обычных пользователей, других супервизоров, и т.д. Добавление новых пользователей или изменение их полномочий являются простой вещью сделать, только сделанный однажды в AD, и они сразу получают полномочия, они должны достигнуть базу данных.

Постредактирование:

Расширение немного на "изобретении велосипед": В AD учетную запись я могу отклонить право войти в определенную машину - или заблокировать его из everymachine, сохраняют один или два. Я могу мешать им войти в систему больше чем на 2 рабочих станциях одновременно. Я могу вынудить их изменить пароли через какое-то время плюс осуществление некоторой минимальной силы в них. И некоторые другие приемы, все из которых улучшают безопасность в моей системе.

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

И затем Вы не можете остановить пользователя SA (или привилегированный пользователь) входящий в систему ни от какой машины. Мне сказали однажды умного способа остановить атаку перебором по S. SQL, который имел его порт для удаленного входа в систему, открытого по Интернету - администраторы сайта реализовали задание, которое изменяло пароль SA каждое полчаса. Если бы это был SQL + Windows, то они, возможно, просто сказали, что хотели, чтобы администратор вошел в систему только от определенного boxen или прямого использования только аутентификация Windows, таким образом, вынудив любого пройти VPN сначала.

4
ответ дан 8 December 2019 в 02:35
поделиться

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

Самое большое преимущество должно использовать AD группу в качестве входа в систему в SQL Server. Таким образом, можно предоставить доступ ко всем в групповом доступе "Учетных записей" к ряду sprocs, таблицы и т.д. и все в доступе групп "менеджеров" к различному набору, всем с AD. Ваши системные администраторы не должны вскакивать в Studio управления для предоставления пользовательских прав доступа приложению.

6
ответ дан 8 December 2019 в 02:35
поделиться

Логины SQL: Запутываемые пароли в виде открытого текста по проводу

Windows Integrated Login с NTLM: Хеши передаются по проводу

Windows Integrated Login с Kerberos: Надлежащая безопасная аутентификация.

Существует только один выбор, если Вы заботитесь о безопасности.

2
ответ дан 8 December 2019 в 02:35
поделиться
Другие вопросы по тегам:

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