EXECUTE AS USER или EXECUTE AS LOGIN
Пересказ статьи Kenneth Fisher. EXECUTE AS USER vs EXECUTE AS LOGIN
Я часто использую имперсонализацию. Это действительно простой способ проверки, имеет ли кто-то разрешения, которые у него должны быть. Итак, коллега недавно задал интересный вопрос. Они тестировали разрешения на синоним.
EXECUTE AS User='Domain/NetworkName';
SELECT Col1, Col2 FROM SynonymName;
-- SynonymName == OtherDB.dbo.TableName
Msg 916, Level 14, State 1, Line 3
The server principal “Domain/NetworkName” is not able to access the database “OtherDB” under the current security context.
(Учетная запись сервера «Domain/NetworkName» не может получить доступ к базе данных «OtherDB» в текущем контексте безопасности.)
Domain/NetworkName имеет доступ к SynonymName, доступ к OtherDB и доступ к TableName. Так почему мы получаем ошибку? И это не совсем то, что вы ожидаете от ошибки отказа в доступе.
Проблема состоит в том, что они выполняли имперсонализацию на уровне учетной записи базы данных (пользователь). Это означает, что вы имеете доступ к их разрешениям в пределах этой базы.
Заметьте, что вы можете перейти от LoginA либо к DB1, либо к DB2, но не напрямую от DB1 к DB2 или наоборот. При имперсонализации UserA вы можете иметь доступ только к DB1. То же самое относительно UserB и DB2. Однако при имперсонализации LoginA вы можете получить доступ и к DB1, и к DB2, поскольку LoginA отображается на обоих пользователей UserA и UserB. Поэтому, если по какой-то причине вам необходим доступ к нескольким базам данных при имперсонализации разных id, убедитесь, что вы используете EXECUTE LOGIN. Если доступ требуется только к одной базе данных, то вы можете использовать любой из вариантов. Если, конечно, вы не хотите, чтобы он потерпел неудачу, когда неожиданно попытаетесь получить доступ к другой базе данных. И да, раньше я использовал EXECUTE USER именно по этой причине.
The server principal “Domain/NetworkName” is not able to access the database “OtherDB” under the current security context.
(Учетная запись сервера «Domain/NetworkName» не может получить доступ к базе данных «OtherDB» в текущем контексте безопасности.)
Domain/NetworkName имеет доступ к SynonymName, доступ к OtherDB и доступ к TableName. Так почему мы получаем ошибку? И это не совсем то, что вы ожидаете от ошибки отказа в доступе.
Проблема состоит в том, что они выполняли имперсонализацию на уровне учетной записи базы данных (пользователь). Это означает, что вы имеете доступ к их разрешениям в пределах этой базы.
Заметьте, что вы можете перейти от LoginA либо к DB1, либо к DB2, но не напрямую от DB1 к DB2 или наоборот. При имперсонализации UserA вы можете иметь доступ только к DB1. То же самое относительно UserB и DB2. Однако при имперсонализации LoginA вы можете получить доступ и к DB1, и к DB2, поскольку LoginA отображается на обоих пользователей UserA и UserB. Поэтому, если по какой-то причине вам необходим доступ к нескольким базам данных при имперсонализации разных id, убедитесь, что вы используете EXECUTE LOGIN. Если доступ требуется только к одной базе данных, то вы можете использовать любой из вариантов. Если, конечно, вы не хотите, чтобы он потерпел неудачу, когда неожиданно попытаетесь получить доступ к другой базе данных. И да, раньше я использовал EXECUTE USER именно по этой причине.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой