2012-05-04 6 views
3

Я новичок в администрировании и пытаюсь улучшить безопасность нашей базы данных Oracle.Oracle: Ограничение просмотра «Другие пользователи»

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

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

Спасибо.

ответ

3

Возможно, вы не можете (по крайней мере, не разумно). Такие инструменты, как SQL Developer, собираются запросить ALL_USERS, чтобы получить список пользователей, и это покажет всем пользователям в базе данных любому пользователю, имеющему возможность входа в систему. Действительно ли это представляет угрозу безопасности для A, чтобы знать, что пользователь B существует, если A не может ничего увидеть о B?

Хотя я бы настоятельно советовал ему, вы можете решить эту проблему, создав в схеме непривилегированного пользователя (или создав частный синоним представления в другой схеме) вид ALL_USERS, который имеет одинаковую структуру как ALL_USERS, но имеет меньше данных. Поскольку большинство инструментов не квалифицируют имена таблиц словаря данных SYS.ALL_USERS, а не только ALL_USERS, этот трюк обычно работает. Однако существуют значительные риски. Неизбежно, есть неожиданные недостатки, когда какой-то скрипт установки ожидает, что словарь данных «нормальный», в конечном итоге кто-то будет использовать инструмент, который полностью квалифицирует имя таблицы словаря данных и т. Д.

+0

Спасибо, Джастин. Наша цель заключалась в том, что «если один пользователь взломан, по крайней мере, он не выдаст имена пользователей всех остальных, что может позволить кому-то попробовать и проложить свой путь вперед». – learningOracle

+1

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

1

Возможно, SQL Developer запросит таблицу (или я не помню) all_users. Так что вам нужно будет отменить этот грант (как SYSDBA):

revoke select on ALL_USERS from PUBLIC; 

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

EDIT:

Я согласен с ответом @Justin Пещеры. Это есть риски, а также, что он приносит хороший вопрос:

Является ли это действительно угроза безопасности для А, чтобы знать, что пользователь B существует, если А не может увидеть что-нибудь еще о B?

+0

Спасибо Серхио – learningOracle

0

По вашему вопросу: Действительно ли риск безопасности для А, чтобы знать, что пользователь B существует, если А не может увидеть что-нибудь еще о B?

Я думает, да, если пользователь A (непривилегированных) знает о имеющейся B, он может попытаться подключиться (перебор), а также: вариант а: преуспевает, и B является привилегированным пользователем вариант B: не удается потому что у B есть сильный пароль, и у пользователя B есть некоторые профилирующие прерывания, которые после нескольких намерений от A, чтобы подключиться как B, пользователь B блокируется, и это может быть проблемой отказа в обслуживании.

Смежные вопросы