Что сделать чтобы пользователь не подвесил бд
Перейти к содержимому

Что сделать чтобы пользователь не подвесил бд

  • автор:

Рекомендации по защите автономных баз данных

Содержащиеся базы данных имеют некоторые уникальные угрозы, которые следует понимать и устранять администраторами ядра СУБД SQL Server. Большинство угроз связаны с процессом проверки подлинности USER WITH PASSWORD , который перемещает границу проверки подлинности с уровня ядра СУБД на уровень базы данных.

Угрозы, связанные с пользователями

Пользователи в автономной базе данных, имеющие разрешение ALTER ANY USER , такие как члены db_owner и db_accessadmin фиксированных ролей базы данных, могут предоставлять доступ к базе данных без знаний или разрешений или администратора SQL Server. Предоставление пользователям доступа к автономной базе данных увеличивает потенциальную область атаки для всего экземпляра SQL Server. Администраторы должны понимать это делегирования контроля доступа и должны быть очень осторожными при предоставлении пользователям в автономной базе данных разрешения ALTER ANY USER . Все владельцы базы данных обладают разрешением ALTER ANY USER . Администраторы SQL Server должны периодически проверять пользователей в автономной базе данных.

Доступ к другим базам данных с использованием гостевой учетной записи

Владельцы и пользователи базы данных, имеющие разрешение ALTER ANY USER , могут создавать пользователей автономной базы данных. После подключения к автономной базе данных в экземпляре SQL Server пользователь автономной базы данных может получить доступ к другим базам данных в ядре СУБД, если другие базы данных включили гостевую учетную запись.

Создание повторяющегося пользователя в другой базе данных

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

USE DB1; GO CREATE USER Carlo WITH PASSWORD = ''; -- Return the SID of the user SELECT SID FROM sys.database_principals WHERE name = 'Carlo'; -- Change to the second database USE DB2; GO CREATE USER Carlo WITH PASSWORD = '', SID = ; GO 

Для выполнения межбазового запроса необходимо установить параметр TRUSTWORTHY в вызывающей базе данных. Например, если определенный выше пользователь (Carlo) находится в базе данных DB1 для выполнения запроса SELECT * FROM db2.dbo.Table1; , то параметр TRUSTWORTHY должен быть включен для базы данных DB1. Чтобы включить параметр TRUSTWORTHY , выполните следующий код:

ALTER DATABASE DB1 SET TRUSTWORTHY ON; 

Создание пользователя с повторяющимся именем входа

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

  • Согласно рекомендациям, члены предопределенной роли сервера sysadmin должны всегда рассматривать соединение без использования параметра исходного каталога. Это вызывает подключение имени входа к базе данных master и предотвращает попытки владельца базы данных неправильно использовать попытку входа. Затем администратор может измениться на содержащуюся базу данных с помощью инструкции USEdatabase.> Можно также установить в качестве базы данных по умолчанию автономную базу данных, которая выполняет вход в базу данных master, а затем переносит вход на автономную базу данных.
  • Рекомендуется не создавать пользователей автономной базы данных с паролями, которые имеют то же имя, что и для входа SQL Server.
  • Если существует дублированное имя входа, выполните подключение к базе данных master без указания исходного каталога, а затем выполните команду USE , чтобы переключиться в автономную базу данных.
  • При наличии автономных баз данных пользователи баз данных, которые не содержатся, должны подключаться к ядру СУБД без использования первоначального каталога или указания имени базы данных, не содержащейся в качестве исходного каталога. Это позволяет избежать подключения к автономной базе данных, которая находится под менее прямым контролем администраторами ядра СУБД.

Увеличение доступа путем изменения состояния включения базы данных

Имена входа, которые имеют разрешение ALTER ANY DATABASE , такие как члены предопределенной роли сервера dbcreator и пользователи неавтономной базы данных, с разрешением CONTROL DATABASE , такие как члены предопределенной роли базы данных db_owner , могут изменять параметр включения базы данных. При изменении параметра включения базы данных с NONE на PARTIAL или FULLпользователю может быть предоставлен доступ путем создания пользователей автономной базы данных с паролями. Это может предоставить доступ без знаний или согласия администраторов SQL Server. Чтобы запретить содержать базы данных, задайте для ядраСУБД параметр проверки подлинности базы данных равным 0. Для предотвращения подключения пользователей автономной базы данных с паролями к выбранным автономным базам данных, используйте триггеры входа для отмены попыток входа пользователей автономной базы данных с паролями.

Присоединение автономной базы данных

При присоединении автономной базы данных администратор может предоставить нежелательным пользователям доступ к экземпляру ядра СУБД. Для предотвращения такого риска администратор может перевести базу данных в состояние «в сети» в режиме RESTRICTED USER , в результате чего пользователи автономной базы данных с паролями не смогут пройти проверку подлинности. Доступ к ядру СУБД сможет получить только субъекты, авторизованные через имена входа.

Пользователи создаются с учетом требований к паролю, действительных в момент их создания, и при присоединении базы данных повторная проверка паролей не производится. Подключив содержащуюся базу данных, которая позволила слабым паролям в систему с более строгой политикой паролей, администратор мог разрешить пароли, которые не соответствуют текущей политике паролей в присоединении ядра СУБД. Администраторы могут запретить сохранение простых паролей с помощью требования переустановки всех паролей в присоединенной базе данных.

Политики паролей

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

Проверка подлинности Kerberos

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

Атака вне сети перебором по словарю

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

Экранирование автономной базы данных

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

Отказ в обслуживании через параметр AUTO_CLOSE

Не настраивайте автономную базу данных на автоматическое закрытие. Если закрыть базу данных, ее открытие для проверки подлинности пользователя будет связано с потреблением дополнительных ресурсов, что может стать объектом атаки типа «отказ в обслуживании».

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

Здравия! Не могу разобраться. Делаю бота-анкету с telebot, он должен при /start добавлять айди телеги юзера в базу данных. Если ещё раз написать /start и если юзер уже есть в базе, то вывести сообщение «Вы вернулись!», если юзера нет в базе данных, то написать «Вас нет в базе :(» Пытался сделать так, но он всё равно не хочет работать так, как надо.

def firstSeen(get_id): conn = sqlite3.connect("users.db") db_worker = conn.cursor() db_worker.execute("SELECT id FROM users WHERE (get_id,)) rez = db_worker.fetchall() if not rez: print('Добавил в базу') return addUser(get_id) else: print('Уже в базе') def addUser(message): conn = sqlite3.connect("users.db") db_worker = conn.cursor() db_worker.execute("INSERT INTO users VALUES (<>,'<>')".format(message, "true")) conn.commit() conn.close() @bot.message_handler(commands=['start']) def on_start(message): if firstSeen(message.chat.id) == message.chat.id: print('--- Вы вернулись!') else: print('=== Вас нет в базе') 

С кодом выше он выводит вот что: Уже в базе === Вас нет в базе

Отслеживать

149k 12 12 золотых знаков 59 59 серебряных знаков 132 132 бронзовых знака

задан 23 ноя 2020 в 21:26

Vova Kazanovsky Vova Kazanovsky

Как ограничить доступ к базам данных?

На впс настроил хостинг сайтов (php+apach+mysql). Мне нужно дать доступ к хостингу для двух моих друзей, проблема в базах данных, не знаю как сделать так, чтоб каждый юзер имел доступ только к своим базам и не видел базы другого юзера. Где это настраивается? в пхп му админе или в другом месте?

2 Ответ от Hanut 2010-07-05 11:00:37

Re: Как ограничить доступ к базам данных?

MoT9I
Это настраивается в phpMyAdmin на странице привилегий. Создайте базы данных, затем добавьте на странице привилегий пользователей и установите им доступ к необходимым базам данных, выберите права, которые должны быть делегированы пользователям на эти БД. Не выставляйте глобальные права, а только права уровня выбранной базы данных.

В некоторых случаях может быть удобно устанавливать права на базы данных по префиксу, в этом случае выбрав например префикс [mono]user_[/mono] можно установить необходимые права на уже существующие базы данных с префиксом [mono]user_[/mono] и те, которые будут с ним созданы.

3 Ответ от viktor6 2010-07-05 16:13:17

Re: Как ограничить доступ к базам данных?

А у меня другой вопрос
У меня на компе есть веб сайты а также игровые сервера которые используют mysql и вот какой вопрос:
Хочу создать одного пользователя в Бд чтобы он имел доступ ко всем базам но с ограничеными возможностями тобиш чтобы если ктото узнает пароль и логин то не мог через phpMyAdmin и другим способом навредить базам данных?
как это все реализовать?

4 Ответ от Hanut 2010-07-05 16:37:48

Re: Как ограничить доступ к базам данных?

viktor6
Создайте отдельного пользователя и наделите его только необходимыми привилегиями. Для простейших случае достаточно отметить SELECT, UPDATE, INSERT и DELETE (конкретные привилегии зависят от прав необходимых для выполнения скрипта). Можно ограничить доступ к критически важным данным определенных таблиц, то есть выставить особые права уровня таблицы, что тоже возможно.

5 Ответ от viktor6 2010-07-05 17:39:52

Re: Как ограничить доступ к базам данных?

Hanut сказал:

viktor6
Создайте отдельного пользователя и наделите его только необходимыми привилегиями. Для простейших случае достаточно отметить SELECT, UPDATE, INSERT и DELETE (конкретные привилегии зависят от прав необходимых для выполнения скрипта). Можно ограничить доступ к критически важным данным определенных таблиц, то есть выставить особые права уровня таблицы, что тоже возможно.

А можно както этому пользователю запретить в phpMyAdmin что либо делать?

6 Ответ от Hanut 2010-07-05 23:45:58

Re: Как ограничить доступ к базам данных?

viktor6
phpMyAdmin можно установить и на свой сайт, поэтому ограничить надо не доступ к phpMyAdmin, а именно уровень прав пользователя MySQL. Можно создать разные группы пользователей, которые устанавливать в зависимости от необходимости. Привилегии в MySQL настраиваются достаточно широко по своим возможностям.

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

7 Ответ от viktor6 2010-07-05 23:58:58

Re: Как ограничить доступ к базам данных?

Hanut сказал:

viktor6
phpMyAdmin можно установить и на свой сайт, поэтому ограничить надо не доступ к phpMyAdmin, а именно уровень прав пользователя MySQL. Можно создать разные группы пользователей, которые устанавливать в зависимости от необходимости. Привилегии в MySQL настраиваются достаточно широко по своим возможностям.

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

Думал есть другое решения кроме .htaccess

8 Ответ от Hanut 2010-07-06 11:42:32

Re: Как ограничить доступ к базам данных?

Если ограничить права пользователя MySQL нельзя, то можно только закрыть доступ к phpMyAdmin. Не знаю что еще можно придумать и зачем.

9 Ответ от viktor6 2010-07-06 11:57:54

Re: Как ограничить доступ к базам данных?

Hanut
Хорошо как тогда закрыть доступ к phpMyAdmin ? файлом .htaccess или другим способом ?
если .htaccess из таким содержанием

order allow deny deny from all allow from 192.126.12.199

а если ап динамика? вот и незнаю как ето все реализовать
просто думал в phpMyAdmin есть настройки которые при авторизации пользователя ему все было ограничено в использовании phpMyAdmin

10 Ответ от Hanut 2010-07-06 13:18:51

Re: Как ограничить доступ к базам данных?

viktor6
Я имел в виду закрыть доступ вообще, с помощью .htpasswd и .htaccess. Это в том случае, если пользователю не нужен доступ к phpMyAdmin. Доступ к MySQL это никак не ограничит.

.htaccess будет примерно таким:

AuthType Basic AuthName "Private Zone" AuthUserFile /var/www/.htpasswd require valid-user

И файл .htpasswd содержащий хеш пароля. Создается хеш пароля либо из командной строки, либо при наличии панели управления сайтом, через нее.

Сообщения 10

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

Форум работает на PunBB , при поддержке Informer Technologies, Inc

Currently installed 7 official extensions . Copyright © 2003–2009 PunBB.

Перенос базы данных с помощью автономных баз данных

Используйте пользователей автономной базы данных для проверки подлинности SQL Server и База данных SQL Azure подключений на уровне базы данных. Содержащаяся база данных — это база данных, изолированная от других баз данных и от экземпляра SQL Server или База данных SQL (и master базы данных), в которую размещается база данных.

SQL Server поддерживает использование пользователей автономной базы данных для проверки подлинности Windows и SQL Server. При использовании База данных SQL объедините пользователей автономной базы данных с правилами брандмауэра уровня базы данных.

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

Традиционная модель входа и пользователя

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

ядро СУБД После подтверждения проверка подлинности Windows учетных данных или проверки подлинности учетных данных проверки подлинности SQL Server подключение обычно пытается подключиться к пользовательской базе данных. Чтобы подключиться к пользовательской базе данных, имя входа должно быть сопоставлено (т. е. связанному с) пользователем базы данных в пользовательской базе данных. Строка подключения также может указывать подключение к определенной базе данных, которая является необязательной в SQL Server, но требуется в База данных SQL.

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

Если подключение к master базе данных недоступно (например, отработка отказа выполняется), общее время подключения увеличится или подключение может истекать. Недоступное подключение может снизить масштабируемость подключения.

Модель пользователя автономной базы данных

В модели пользователя автономной базы данных имя входа в master базу данных отсутствует. Вместо этого процесс проверки подлинности выполняется в пользовательской базе данных. Пользователь базы данных в пользовательской базе данных не имеет связанного имени входа в master базу данных.

Модель пользователя автономной базы данных поддерживает как проверка подлинности Windows, так и проверку подлинности SQL Server. Его можно использовать как в SQL Server, так и в База данных SQL.

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

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

В Azure База данных SQL и Azure Synapse Analytics поддерживают удостоверения из идентификатора Microsoft Entra (ранее Azure Active Directory) как пользователей автономной базы данных. База данных SQL поддерживает пользователей автономной базы данных, использующих проверку подлинности SQL Server, но Azure Synapse Analytics не поддерживает. Дополнительные сведения см. в Подключение База данных SQL с помощью проверки подлинности Microsoft Entra.

При использовании проверки подлинности Microsoft Entra пользователи могут подключаться из SQL Server Management Studio с помощью универсальной проверки подлинности Microsoft Entra. Администратор istrator может настроить универсальную проверку подлинности для многофакторной проверки подлинности, которая проверяет удостоверение с помощью телефонного звонка, текстового сообщения, смарт-карта с помощью ПИН-кода или уведомления мобильного приложения. Дополнительные сведения см. в разделе «Использование многофакторной проверки подлинности Microsoft Entra».

Для База данных SQL и Azure Synapse Analytics имя базы данных всегда требуется в строка подключения. Поэтому вам не нужно изменять строка подключения при переключении с традиционной модели на пользовательскую модель автономной базы данных. Для подключений SQL Server имя базы данных необходимо добавить в строка подключения, если она еще не присутствует.

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

Брандмауэры

SQL Server

Для SQL Server правила брандмауэра Windows применяются ко всем подключениям и имеют одинаковые последствия для входа (традиционные подключения модели) и пользователей автономной базы данных. Дополнительные сведения о брандмауэре Windows см. в разделе «Настройка брандмауэра Windows для ядро СУБД доступа».

брандмауэры База данных SQL

База данных SQL разрешает отдельные правила брандмауэра для подключений на уровне сервера (имена входа) и для подключений на уровне базы данных (пользователей автономной базы данных). При подключении База данных SQL к пользовательской базе данных сначала проверка правила брандмауэра базы данных. Если нет правила, разрешающего доступ к базе данных, База данных SQL проверка правила брандмауэра на уровне сервера. Проверка правил брандмауэра на уровне сервера требует доступа к базе данных сервера master База данных SQL.

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

Дополнительные сведения о правилах брандмауэра База данных SQL см. в следующих разделах:

  • Брандмауэр Базы данных SQL Azure
  • Настройка параметров брандмауэра (База данных SQL Azure)
  • sp_set_firewall_rule (база данных SQL Azure)
  • sp_set_database_firewall_rule (база данных SQL Azure)

Различия синтаксиса

CREATE LOGIN login_name WITH PASSWORD = ‘strong_password’;

Затем при подключении к пользовательской базе данных:

Управляемый экземпляр SQL

Управляемый экземпляр SQL Azure ведет себя как локальный сервер SQL Server в контексте автономных баз данных. Обязательно измените контекст базы данных из базы данных master на пользовательскую базу данных при создании автономного пользователя. Кроме того, при настройке параметра хранения не должно быть активных подключений к пользовательской базе данных. Используйте следующий код в качестве руководства.

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

USE master; SELECT * FROM sys.dm_exec_sessions WHERE database_id = db_id('Test') DECLARE @kill_string varchar(8000) = ''; SELECT @kill_string = @kill_string + 'KILL ' + str(session_id) + '; ' FROM sys.dm_exec_sessions WHERE database_id = db_id('Test') and is_user_process = 1; EXEC(@kill_string); GO sp_configure 'contained database authentication', 1; GO RECONFIGURE; GO SELECT * FROM sys.dm_exec_sessions WHERE database_id = db_id('Test') ALTER DATABASE Test SET containment=partial USE Test; GO CREATE USER Carlo WITH PASSWORD='Enterpwdhere*' SELECT containment_desc FROM sys.databases WHERE name='Test' 

Замечания

  • Пользователи автономной базы данных должны быть включены для каждого экземпляра SQL Server. Дополнительные сведения см. в разделе «Проверка подлинности автономной базы данных» (параметр конфигурации сервера).
  • Пользователи и имена входа автономной базы данных с не перекрывающимися именами могут сосуществовать в приложениях.
  • Предположим, что имя входа в master базе данных имеет имя 1. При создании пользователя автономной базы данных с именем 1 при указании имени базы данных в строка подключения контекст пользователя базы данных будет выбран контекст входа для подключения к базе данных. То есть пользователь автономной базы данных имеет приоритет над именами входа с одинаковым именем.
  • В База данных SQL имя пользователя автономной базы данных не может совпадать с именем учетной записи администратора сервера.
  • Учетная запись администратора сервера База данных SQL никогда не может быть пользователем автономной базы данных. Администратор сервера имеет достаточные разрешения для создания пользователей автономной базы данных и управления ими. Администратор сервера может предоставлять разрешения пользователям автономной базы данных для пользовательских баз данных.
  • Так как пользователи автономной базы данных являются субъектами уровня базы данных, необходимо создать пользователей автономной базы данных в каждой базе данных, где они будут использоваться. Удостоверение ограничено базой данных. Удостоверение является независимым (во всех аспектах) от пользователя, имеющего то же имя и тот же пароль в другой базе данных на том же сервере.
  • Используйте ту же силу паролей, которые обычно используются для входа.

Связанный контент

  • Автономные базы данных
  • Рекомендации по обеспечению безопасности с содержащимися базами данных
  • СОЗДАНИЕ ПОЛЬЗОВАТЕЛЯ (Transact-SQL)
  • Подключение для База данных SQL Azure с помощью проверки подлинности Microsoft Entra

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *