Sql sa: Как сбросить пароль SA в Microsoft SQL Server?

sql server — MS SQL 2008 / в названии таблицы

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

import pandas as pd
from sqlalchemy import create_engine, text
# variables
serverName = "DBTEST"
engine = create_engine('mssql+pyodbc://user:[email protected]/TEST?driver=SQL+Server')
conn = engine.connect()
queryDiscr = text(f'SELECT * FROM "{serverName}$Sales/purch" ')
DiscrDF = pd.read_sql_query(queryDiscr, conn)

пробовал экранировать по разному:

    queryDiscr = text(f'SELECT * FROM [{serverName}$Sales/purch] ')
    queryDiscr = text(f'SELECT * FROM {serverName}[$Sales/purch] ')
    queryDiscr = text(f'SELECT * FROM "{serverName}$Sales/purch" ')
    queryDiscr = text(f'SELECT * FROM \"{serverName}$Sales/purch\" ')

одна и та же ошибка Invalid object name 'DBTEST$Sales/purch'
помогите пожалуйста с запросом.

  • sql
  • sql-server
  • pandas






5

Пожалуйста, попробуйте следующее в SSMS.

Это покажет имена таблиц и остальные детали.

USE DBTEST;
GO
SELECT * FROM INFORMATION_SCHEMA.TABLES;

Например, для базы данных AdventureWorks2019:

TABLE_CATALOGTABLE_SCHEMATABLE_NAMETABLE_TYPE
AdventureWorks2019SalesSalesTaxRateBASE TABLE
AdventureWorks2019SalesPersonCreditCardBASE TABLE
AdventureWorks2019dboTBASE TABLE
AdventureWorks2019PersonvAdditionalContactInfoVIEW
AdventureWorks2019PersonPersonPhoneBASE TABLE







Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации



Почта

Необходима, но никому не показывается




By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.


Введение в безопасность SQL Server. Часть 4

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

Серии на данный момент:
  1. Введение в безопасность SQL Server — часть 1
  2. Введение в безопасность SQL Server — часть 2
  3. Введение в безопасность SQL Server — часть 3
  4. Введение в безопасность SQL Server — часть 4
  5. Введение в безопасность SQL Server — часть 5
  6. Введение в безопасность SQL Server — часть 6
  7.  

В предыдущих статьях этой серии я познакомил вас с принципами безопасности SQL Server и той ролью, которую они играют в аутентификации и авторизации. По своей сути принципалы — это объекты сервера и базы данных, которые могут запрашивать доступ к ресурсам SQL Server. Наиболее распространенными субъектами являются имена входа на сервер, роли сервера, пользователи базы данных и роли базы данных.

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

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

Логин sa

Логин sa , сокращение от системного администратора , — один из самых рискованных участников уровня сервера в SQL Server. Он автоматически добавляется в качестве члена фиксированной серверной роли sysadmin и поэтому имеет все разрешения для этого экземпляра и может выполнять любые действия. Если логин был взломан, злоумышленник может нанести неограниченный ущерб.

Вы не можете сбросить логин sa , но можете отключить его. Если вы выбираете проверку подлинности Windows при установке SQL Server, ядро ​​базы данных назначает учетной записи случайный пароль и автоматически отключает его. Если вы затем переключитесь на аутентификацию SQL Server, вход в систему останется отключенным, и вам придется включить его вручную.

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

Вы можете проверить, отключен ли вход sa , запросив системное представление sys.server_principals , используя SELECT оператор, подобный следующему:

мастер ЕГЭ;

GO

ВЫБЕРИТЕ Principal_id, type_desc, is_disabled

FROM sys.server_principals

ГДЕ name = ‘sa’;

Если вход в систему отключен, значение is_disabled будет 1 , как показано на рисунке 1.

Рисунок 1. Имя входа sa в экземпляре SQL Server

Вы не можете удалить логин sa из роли сервера sysadmin , но можете проверить его членство:

1

2

3

4

5

6

7

SELECT member. name

FROM sys.server_role_members rm

JOIN sys.server_principals role  

  ON rm.role_principal_id = role.principal_id  

90 002 ПРИСОЕДИНЯЙТЕСЬ к члену sys.server_principals  

  ON rm.member_principal_id = member.principal_id

ГДЕ role.name = ‘sysadmin’;

Оператор использует системное представление sys.server_role и системное представление sys.server_principals для возврата членов роли sysadmin , как показано на рисунке 2.

9 0002 Рисунок 2. Принципалы, назначенные роль сервера sysadmin

Если вы окажетесь в ситуации, требующей sa , вы должны активировать учетную запись, прежде чем ее можно будет использовать. Для этого запустите оператор ALTER LOGIN , который устанавливает свойство ENABLE , а затем снова запустите оператор, чтобы назначить пароль для входа в систему, как показано в следующем примере:

1

2

3

4

5

6

мастер ЕГЭ;

GO

ALTER LOGIN sa ENABLE;

GO  

ИЗМЕНИТЬ ВХОД sa С ПАРОЛЕМ = ‘tempPW@56789’;

ГО

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

Вы можете проверить вход sa в SQL Server Management Studio (SSMS), запустив новый запрос и изменив соединение. Следующие шаги описывают, как изменить это соединение:

  1. В SSMS запустите новый запрос.
  2. На новой вкладке запроса щелкните правой кнопкой мыши пустую область в редакторе запросов, выберите Connection и щелкните Change Connection .
  3. В диалоговом окне Connect to Database Engine выберите SQL Server Connection из раскрывающегося списка Authentication . Форма будет обновлена ​​и будет содержать текстовые поля для входа и пароля.
  4. Введите sa в качестве логина и пароля, которые вы указали при включении входа, а затем нажмите 9.0035 Подключить .

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

ВЫБЕРИТЕ * ОТ sys. server_principals;

Запрос должен выполняться без проблем, поскольку логину sa разрешено делать что-либо на сервере. В моей тестовой системе оператор SELECT возвращает 32 строки.

После подтверждения входа выполните следующие ALTER LOGIN оператор для его отключения:

ALTER LOGIN sa DISABLE;

ГО

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

Рисунок 3. Ошибка при попытке подключения с отключенным логином sa

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

Логины на основе сертификатов

Изучая SQL Server, вы, вероятно, заметите набор логинов на сервере, имена которых начинаются и заканчиваются двойными решетками, как в ##MS_PolicySigningCertificate## . Логины — это учетные записи с сопоставлением сертификатов, используемые ядром базы данных для внутренних целей. Вы не должны удалять их или связываться с ними каким-либо образом.

Чтобы получить список входов на основе сертификатов, выполните следующий запрос:

SELECT name, type_desc, is_disabled

FROM sys.server_principals

WHERE name LIKE ‘##%’

ORDER BY name;

На рис. 4 показаны результаты, возвращаемые оператором в моей системе.

Рисунок 4. Входы на основе сертификатов в экземпляр SQL Server

Обратите внимание, что два входа помечены как отключенные и их тип указан как SQL_LOGIN , а не CERTIFICATE_MAPPED_LOGIN . Несмотря на эти различия, в документации Microsoft конкретно указано, что эти два входа также считаются входами с сопоставлением сертификатов.

Вы можете просмотреть сертификаты, связанные с включенными входами на основе сертификатов, выполнив следующие SELECT оператор:

SELECT name FROM sys.certificates

WHERE name LIKE ‘##%’

ORDER BY name;

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

Рис. 5. Сертификаты, связанные с входами в систему с сопоставлением сертификатов Возможно, вам придется объяснить властям, почему эти логины отображаются в ваших отчетах.

Общедоступные роли сервера и базы данных

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

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

Чтобы просмотреть разрешения, назначенные роли общедоступного сервера , выполните следующую инструкцию SELECT :

1

2

3

4

5

6

7

8

9

10

11

SELECT pm. state_desc,

  pm.permission_name,

  pm.class_desc,

  pm.major_id,

  ep.name

ОТ sys.server_permissions pm

ПРИСОЕДИНЯЙТЕСЬ к sys.server_principals pr

  ON pm.grantee_principal_id = pr.principal_id

LEFT JOIN sys.endpoints ep

  ON pm.major_id = ep.endpoint_id

ГДЕ pr.name = ‘public’;

Оператор объединяет системные представления sys.server_permissions , sys.server_principals и sys.endpoints для получения соответствующей информации. В моей системе я сохранил разрешения по умолчанию, которые показаны на рисунке 6.

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

1

2

3

4

5

6

7

8

9 9 0003

10

11

USE ImportSales1;

GO

SELECT pm. state_desc,

  pm.permission_name,

  pm.class_desc,

  pm.major_id,

  OBJECT_ ИМЯ(pm.major_id) obj_name

ОТ sys.database_permissions pm

ПРИСОЕДИНЯЙТЕСЬ к sys.database_principals pr

  ON pm.grantee_principal_id = pr.principal_id

ГДЕ pr.name = ‘public’;

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

На рис. 7 показана часть результатов, возвращаемых оператором SELECT в моей системе. Как и в случае с общедоступной серверной ролью , я не вносил изменений в роль общедоступной базы данных . По умолчанию роли предоставлено 176 разрешений, большинство из которых — это разрешение SELECT , предоставленное системным представлениям.

Рисунок 7. Частичное представление разрешений по умолчанию, назначенных роли общедоступной базы данных

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

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

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

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

Пользователь базы данных dbo и схема

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

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

SQL Server автоматически сопоставляет имя пользователя sa , владельца базы данных и членов системного администратора для учетной записи пользователя dbo в каждой базе данных. Чтобы убедиться в этом, подключитесь к экземпляру SQL Server как один из этих пользователей и запросите системную функцию CURRENT_USER , как в следующем примере:

.

ВЫБЕРИТЕ ТЕКУЩЕГО_ПОЛЬЗОВАТЕЛЯ;

Оператор SELECT должен возвращать dbo в качестве текущего пользователя.

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

Чтобы проверить имя пользователя и базу данных по умолчанию, связанные с пользователем dbo , выполните следующий запрос к одной из ваших баз данных:

USE ImportSales1;

GO

ВЫБРАТЬ SUSER_SNAME(sid) login_name, default_schema_name

ОТ sys.database_principals

ГДЕ имя = ‘dbo’;

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

Вы также можете убедиться, что пользователь dbo был добавлен в роль базы данных db_owner :

1

2

3

4

5

6

7

SELECT member.name

FROM sys.database_role_members rm

JOIN sys.database_principals role  

  ON rm.role_principal_id = role.principal_id  

90 002 ПРИСОЕДИНЯЙТЕСЬ к члену sys.database_principals  

  ON rm.member_principal_id = member.principal_id

ГДЕ role.name = ‘db_owner’;

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

Однако посмотрите, что происходит с базой данных WideWorldImporters , которую я прикрепил к своему экземпляру SQL Server из файла резервной копии, загруженного с GitHub:

ИСПОЛЬЗОВАНИЕ WideWorldImporters;

GO

SELECT SUSER_SNAME(sid) login_name, default_schema_name

FROM sys. database_principals

ГДЕ name = ‘dbo’;

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

Рисунок 8. Логин, связанный с пользователем dbo

900 02 Кроме того, когда я получаю членов db_owner роль базы данных, результаты включают как пользователя dbo , так и мою учетную запись:

1

2

3

4

5

6

7

SELECT member.name

FROM sys.database_role_members rm

JOIN sys.database_principals role  

  ON rm.role_principal_id = role.principal_id  

90 002 ПРИСОЕДИНЯЙТЕСЬ к члену sys.database_principals  

  ON rm.member_principal_id = member.principal_id

ГДЕ role.name = ‘db_owner’;

Поскольку пользователь dbo связан с учетной записью sa , мой логин добавляется как отдельный член к роли базы данных db_owner . Таким образом, и мой логин, и логин sa имеют полный контроль над базой данных (при условии, что логин sa включен).

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

В моей системе мой логин считается владельцем базы данных ImportSales1 и WideWorldImporters , хотя мой логин связан только с пользователем dbo в базе данных ImportSales1 . Чтобы подтвердить владельцев базы данных, я выполнил следующий запрос:

ВЫБЕРИТЕ имя, SUSER_SNAME(owner_sid)

FROM sys.databases

ГДЕ name = ‘ImportSales1’

  ИЛИ name = ‘WideWorldImporters’;

Запрос вернул мой логин для обеих баз данных, как показано на рисунке 9.

Рисунок 9. Логин, связанный с базами данных WideWorldImporters и ImportSales1Схема 0025 dbo . Когда вы запрашиваете объект базы данных без указания схемы, механизм запросов сначала ищет вашу схему по умолчанию, если она отличается от dbo . Если объекта там нет, механизм запросов ищет схему dbo . Если объект отсутствует в этой схеме, возвращается ошибка.

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

Кроме того, если указать схему по умолчанию, отличную от dbo , и пользователь является членом роли сервера sysadmin , указанная схема игнорируется и используется схема dbo . Схема по умолчанию для всех членов sysadmin — dbo .

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

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

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

Пользователь guest владеет схемой guest . Как и пользователь, схему нельзя удалить. Однако он не содержит объектов и не имеет разрешений. На самом деле схема guest используется редко, если вообще используется.

Чтобы проверить, включен ли пользователь guest , выполните следующий запрос:

1

2

3

4

5

6

7

USE ImportSales1;

GO

ВЫБЕРИТЕ u. hasdbaccess, p.default_schema_name

ИЗ sys.database_principals p

ПРИСОЕДИНЯЙТЕСЬ к sys.sysusers u

  ON p.principal_id = u.uid

ГДЕ p.name = ‘гость’;

Запрос должен вернуть значение hasdbaccess 0 , указывающее, что учетная запись пользователя отключена, как показано на рис. 10. Запрос также должен вернуть guest в качестве схемы по умолчанию.

Рисунок 10. Статус включения гостевой учетной записи пользователя

Если вопреки всем советам вы решите включить гостевую учетную запись , вы должны предоставить пользователю разрешение CONNECT , как показано в следующем примере:

ПРЕДОСТАВЛЕНИЕ ПОДКЛЮЧЕНИЯ К гостю;

ГО

Предоставление разрешения CONNECT — это все, что нужно для включения гостя пользователь. Если вы повторно запустите предыдущую инструкцию SELECT , значение hasdbaccess теперь должно быть 1 .

В любой момент (чем раньше, тем лучше) вы можете отключить учетную запись гостя, отменив разрешение CONNECT :

ОТМЕНИТЬ ПОДКЛЮЧЕНИЕ ОТ гостя;

ГО

Чтобы проверить, содержит ли схема guest какие-либо объекты, выполните следующий запрос, который обычно возвращает нулевые строки:

ВЫБЕРИТЕ o.name

ИЗ sys.all_objects o

ПРИСОЕДИНЯЙТЕСЬ к sys.schemas s

  ON o.schema_id = s.schema_id

ГДЕ s.name = 'guest ';

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

Пользователь базы данных sys и схема

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

Схема sys — это отдельная история. Ядру базы данных требуется схема для внутреннего использования. Вы не можете изменить или удалить схему. Он содержит ряд важных системных объектов, таких как системные таблицы, представления каталогов, представления динамического управления и встроенные функции. Вы уже видели несколько представлений каталога в действии в предыдущих примерах. 9Схема 0025 sys особенно удобна для доступа к метаданным SQL Server.

Вы можете просмотреть объекты в схеме sys , выполнив следующий запрос:

1

2

3

4

5

6

7

8

USE ImportSales1;

GO

SELECT o. type_desc, o.name

FROM sys.all_objects o

JOIN sys.schemas s

  ON o.schema_id = s.schema_id

ГДЕ s.name = ‘sys’

ORDER BY o.type_desc, o.name;

В этом случае оператор SELECT относится к базе данных ImportSales1 . В моей системе оператор возвращает 2273 строки, разбитые на 12 типов объектов. Чтобы просмотреть список типов объектов, выполните следующий запрос:

1

2

3

4

5

6

ВЫБРАТЬ отдельный o.type_desc

ИЗ sys.all_objects o

ПРИСОЕДИНИТЬСЯ к sys.schemas s

  ON o.schema_id = s.schema_id

ГДЕ s.name = ‘sys’

ЗАКАЗАТЬ ПО o.type_desc

На рис. 11 показаны результаты, полученные при выполнении оператора SELECT .

Рисунок 11. Типы объектов в схеме sys

Вы также можете получить список объектов по типу, как показано в следующем примере:

1

2

3

4

5

6

7

SELECT o. name

FROM sys.all_objects o

JOIN sys.schemas s

  ON o.schema_id = s.schema_id

ГДЕ s.name = ‘sys ‘

  И o.type_desc = ‘ВИД’

ЗАКАЗ o.name;

Оператор возвращает только объекты типа VIEW . На рис. 12 показана часть полученных мною результатов. Всего было 473 ряда.

Рисунок 12. Частичный список представлений в схеме sys

Для получения дополнительной информации о представлениях каталога и представлениях динамического управления см. мою статью Simple Talk «Системные представления SQL Server: основы».

Пользователь базы данных INFORMATION_SCHEMA и схема

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

В отличие от sys схема INFORMATION_SCHEMA содержит лишь небольшое количество представлений и не содержит других типов объектов. Вы можете подтвердить это, выполнив следующую инструкцию SELECT :

1

2

3

4

5

6

SELECT o.name

FROM sys.all_objects o

JOIN sys.schemas s

  ON o.schema_id = s.schema_id

ГДЕ s.name = ‘INFORMATION_SCHEMA’

ЗАКАЗАТЬ o.name;

На рис. 13 показана часть результатов, которые я получил. Всего существует 21 представление INFORMATION_SCHEMA для базы данных ImportSales1 .

Рисунок 13. Частичный список представлений в схеме INFORMATION_SCHEMA

Дополнительные сведения о представлениях INFORMATION_SCHEMA см. в той же статье Simple Talk, SQL Server System Views: The Basics.

Нечетная коллекция предопределенных принципов SQL Server

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

Рекомендации по защите учетной записи SQL Server sa

Автор: K. Brian Kelley   |
Комментарии (3)   | Связанные: > Безопасность

Проблема

Я знаю, что передовой опыт говорит о защите учетной записи SQL Server sa. Однако я не
уверен, что все, что я должен сделать, чтобы защитить свои SQL-серверы. Какие шаги я должен
брать?

Решение

Каждый раз, когда у вас есть известная учетная запись, например администратор в Windows
system или sa для SQL Server, вы должны предпринять определенные шаги для его защиты. Давайте
посмотри конкретно что тебе делать с sa:

  1. Установите трудно угадываемый пароль.
  2. Переименовать sa.
  3. Отключить СА.
  4. Убедитесь, что не существует других учетных записей с именем sa.

Установить сложный пароль

Даже если вы используете только проверку подлинности Windows, обязательно установите
угадать пароль для учетной записи sa. В конце концов, разница между SQL
Сервер, принимающий только логины Windows, принимает как Windows, так и SQL Server
логины — это изменение реестра и перезагрузка.

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

Но что, если вам нужно сохранить его для аварийного восстановления? В этом
случае, следуя стандартным процедурам вашей организации в отношении
защиты таких учетных записей и паролей. Ваши администраторы Windows должны
уже столкнулись с теми же проблемами в отношении сохранения конкретных
пароли для контроллеров домена и отдельных учетных записей и паролей, которые будут
в состоянии администрировать вашу среду Active Directory. Логины sa должны быть
относятся с одинаковой безопасностью.

Переименуйте SQL Server sa Login

Если вы откроете SQL Server Management Studio и увидите что-то вроде этого
в папке Безопасность,
вам, вероятно, нужно переименовать sa:

Однако способ проверить, является ли это исходной учетной записью sa, заключается в следующем:
запрос sys.sql_logins так:

 ВЫБЕРИТЕ имя
ИЗ sys.sql_logins
ГДЕ Сид = 0x01;

Sid, или идентификатор безопасности, важен. Учетная запись sa всегда
0x01. Этот запрос определяет, является ли логин с именем sa исходным sa.
аккаунт или новый. Мы доберемся до того, что делать, если это новый в немного. Если
это оригинал, вы должны увидеть результат, как показано ниже:

Так как же нам его переименовать? Ну, мы не можем использовать графический интерфейс, если откроем
характеристики. Обратите внимание, что имя выделено серым цветом:

.

Хитрость заключается в том, чтобы щелкнуть правой кнопкой мыши на sa и выбрать переименование:

Другой вариант — использовать T-SQL:

 ИЗМЕНИТЬ ВХОД [sa]
С ИМЯ = [old_sa];

Затем, если я обновлю папку Logins, я увижу, что учетная запись sa переименована.

Отключить учетную запись SQL Server sa

Вы не должны останавливаться на переименовании учетной записи sa. Вы также должны отключить его.
В то время как кто-то, у кого есть разрешение, чтобы определить, какой логин для sid
0x01 наверное можно переименовать учетную запись, это простая мера и стоит того
секунд, необходимых для выполнения. Это еще один шаг, который должен сделать злоумышленник.
преодолеть, чтобы скомпрометировать логин. Есть два способа отключить учетную запись.
сначала через графический интерфейс:

Вы также можете сделать это через T-SQL (убедитесь, что вы указали правильный логин, поскольку вы уже должны были его переименовать):

 ИЗМЕНИТЬ ВХОД [old_sa]
ЗАПРЕЩАТЬ;

Убедитесь, что другие логины не называются sa

Рекомендация против использования учетной записи sa для приложений значительно превышает
десятилетие. Однако, несмотря на это, сегодня все еще есть приложения, которые все еще хотят
используйте «sa» специально. В результате некоторые будут включать создание учетной записи sa в
их развертывание приложения, даже если приложение способно использовать
другой аккаунт. Поэтому рекомендуется периодически проверять
посмотрите, был ли создан логин с именем sa на каждом из ваших SQL-серверов. Ты можешь
визуально проверьте через графический интерфейс, или вы можете написать простой скрипт, который выполняет
следующий запрос ко всем вашим серверам SQL:

 ВЫБЕРИТЕ сторону, имя
ИЗ sys.sql_logins
ГДЕ имя = 'са';

Очевидно, вы не хотите возвращать никаких результатов:

Но не помешает ли это вам определить, используется ли sa для попытки
и подключить? Нет, не будет. Если вы проводите аудит неудачных входов в систему, вы увидите
следующую запись в журналах SQL Server, если кто-то пытается подключиться. Обратите внимание, что
это указывает на то, что логин не существует.

Как насчет олицетворения, владения базой данных и агента SQL Server?

Переименование и отключение учетной записи sa не остановит внутренние процессы от
возможность использовать учетную запись sa. Поэтому, если у вас есть базы данных, владельцы которых
есть, нет проблем. Это хорошо, потому что некоторые базы данных,
как master и tempdb, требуют учетную запись sa в качестве владельца. Кроме того, наличие SQL
Задания агента сервера, принадлежащие sa, также не будут прерываться. Олицетворение все еще работает.
Следовательно, нет причин НЕ переименовывать и отключать учетную запись sa.

Как насчет пакетов обновлений и накопительных обновлений?

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

Следующие шаги
  • Узнайте, как использовать

    Профилировщик SQL Server, чтобы определить, входит ли кто-то в систему как sa.