Comments 20
Очень крутая фича. Интересно, как быстро перекочует в прочие популярные базы.
Пока не совсем ясно, как защищаться от перебора через Select.
Выбрали нужную запись с условием where Phone like '8%', потом подобрали like '89%' и т.д.
Есть ли какие-то действенные варианты защиты?
Выбрали нужную запись с условием where Phone like '8%', потом подобрали like '89%' и т.д.
Есть ли какие-то действенные варианты защиты?
Про методы защиты. Это не 100% защита, а способ затруднить доступ. Одно дело сделать select * и унести распечатку, и совсем другое сидеть и угадывать. При этом угадывать можно только на той же базе, нельзя унести замаскированное и на другой системе пытаться восстановить информацию.
Аудит, мониторинг, тут другого варианта вообще трудно придумать.
Можно конечно хранимок понаделать, но так да, элегантней
Допустим у нас есть хранимка скомпиленная из под r_vip, которая делает селект из этой таблицы. Если эту хранимку вызовет другой (не r_vip) он увидит полные данные?
Полные данные может увидеть только та сессия у которoй активна роль R_VIP. Даже владелец, без роли, полных данных не увидит.
А если например у нас хранимая процедура, где необходимо сделать например такой селект, но роли R_VIP у нас нет:
select phone, ccard into v_phone, v_card from test.client_info where ccard = get_card_from_somewhere;
Как такое реализовать?
То есть вопрос, если у нас нет роли R_VIP то получается что и процедуры не видят полных данных?
А если процедуры созданы под пользователем у которого есть роль R_VIP это нам тоже не поможет?
select phone, ccard into v_phone, v_card from test.client_info where ccard = get_card_from_somewhere;
Как такое реализовать?
То есть вопрос, если у нас нет роли R_VIP то получается что и процедуры не видят полных данных?
А если процедуры созданы под пользователем у которого есть роль R_VIP это нам тоже не поможет?
можно ли производить какие-то операции над закрытыми данными: джоин, груп, конкат?
они будут участвовать во всех операциях как закрытые или открытые в зависимости от наличия роли. Но это никак не влияет на колонки не упомянутые в policy.
мне любопытно в какой момент происходит redaction
пусть у меня нет этой роли, что будет если я скажу
… group by email… — и в базе есть ivan@dom2.ru и ivan@dom3.ru, который после redact неотличимы — получу я 2 строки или 1?
А если я использую wm_concat? В общем функция очевидно непростая, поэтмоу мне и интересно, какие у нее есть ограничения
пусть у меня нет этой роли, что будет если я скажу
… group by email… — и в базе есть ivan@dom2.ru и ivan@dom3.ru, который после redact неотличимы — получу я 2 строки или 1?
А если я использую wm_concat? В общем функция очевидно непростая, поэтмоу мне и интересно, какие у нее есть ограничения
Скорее всего данные маскируются при выборке результата из курсора, врядли oracle решился сломать внутренние механизмы. Это скорее для клонок не участвующих в групповых операциях.
SQL> select count(*), email from test.client_info group by email;
COUNT(*) EMAIL
---------- ---------------
1 ivan@xxxxx.com
1 ivan@xxxxx.com
А это все дело на план будет влиять? Могут поехать все планы?
Т.е. таки можно узнать любые отредактированные данные, хотя бы дихотомией — дело лишь в том, что их нельзя получить быстро, так?
Да, пытаться угадать — можно. И можно даже установить, правильно ли угадал:
Но это затруднительно, и для пресечения таких попыток можно использовать аудит.
SQL> select name, email from client_info c where email = 'ivan@dom2.ru';
NAME EMAIL
---------- ---------------
Иван ivan@xxxxx.com
Но это затруднительно, и для пресечения таких попыток можно использовать аудит.
Не сильно затруднительно. Можно угадывать «по букве». На каждую следующую цифру в телефоне в среднем 5 попыток.
И на что аудит? На Select?
А нет ли фичи, сделать так, чтобы запросы, в которых фигурируют УСЛОВИЯ на защищаемые колонки — не выполнялись?
И на что аудит? На Select?
А нет ли фичи, сделать так, чтобы запросы, в которых фигурируют УСЛОВИЯ на защищаемые колонки — не выполнялись?
FGA (fine grained audit) позволяет отслеживать select'ы по колонке, да еще и с анализом условий запроса. Не в этом дело. Обеспечение безопасности — это многоступенчатый процесс. Эта фича рассматривается как «дешевый» (в смысле ресурсов) вариант. Для усиленной защиты существует Transparent data encryption, когда данные хранятся в зашифрованном виде. Но естественно и ресурсов на encrypt/decrypt уходит существенно больше.
Sign up to leave a comment.
Oracle 12c Data Redaction. Сокрытие информации от непривилегированных пользователей