|
|
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
Добрый день коллеги! Вопрос для секьюрити маньяков ) На данный момент строится решения на базе SQL Server 2012, и клиентом поднимаются два вопроса: - Как разделить клиентов использующих БД для соблюдения бедопасности и сохранности данных? - Как обезопасить данные таким образом, чтобы они были видны только целевым пользователям системы? Первый вопрос решается довольно "просто", т.е. мы можем разделить клиентские данные втупую, т.е. 1 клиент - 1 база... а можем позаимствовать решение у SharePoint т.е. multitenancy, где все клиенты буду пользоваться одной базой но разделены при этом т.н. партициями. Второй вопрос - безопасность самих данных. Понятно что к БД имеет доступ ИТ персонал и вопрос здесь состоит... (как-бы по-точнее сформулировать )))... как обезопасить данные от самих себя )) Тут я перегибаю конечно, но речь идет о шифровании данных. Т.е. задвиг такой - админ обслуживающий дата-центр данные не увидит, т.к. они зашифрованы, клиенты (которые и так будут разделены по п.1) тоже нифига не увидят чужие данные... а увидеть их должны только целевые пользователи у кот. есть воотв. доступ и которые с этими данными работают. По сему - шифрование самой БД (средствами сиквела) отпадает... от админа этим данные не скроешь. Применение других методов шифрования выглядит достаточно страшно, чтобы даже начинать строить что-то подобное. Может кто-то сталкивался с такой проблемой - подскажите как решить (избавится от клиента не предлагать :)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 18:43 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
Allaire Как разделить клиентов использующих БД для соблюдения бедопасности и сохранности данных?Сколько у вас клиентов? Allaire 1 клиент - 1 базаУ такого подхода есть свои достоинства и недостатки. Здесь нет однозначного ответа. Allaire т.н. партициямиСкорее ищите по слову row level security. Allaire как обезопасить данные от самих себяОт админа ничего не скроешь. p.s. Не маньяк ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 19:48 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
SERG1257От админа ничего не скроешь. Не совсем так. Ничего не скроешь от "всех админов разом, действующих в команде". Но разделяя права и полномочия между админами, вполне можно скрыть информацию от конкретных админов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 19:51 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
SERG1257Сколько у вас клиентов? Будет порядка полутора тысяч... SERG1257У такого подхода есть свои достоинства и недостатки. Здесь нет однозначного ответа. Стандартное ограничение сиквела 32 тысячи БД на одну инстанцию, хотя в жизни не видел больше 300. Но недостаток не только в этом я так понимаю )) Не дай бог если в финале эти данные из такого дикого кол-ва баз кому-то захочется комбинировать... SERG1257От админа ничего не скроешь. Это не совсем то что я хотел услышать... Шифровать базу целиком смысла нет, тем более админу по боку. Если применить шифрование клиентских данных открытым ключем (pgp к примеру) и уже складывать в БД шифрованные данные - звучит не очень няшно, да и кто ключи-то выдавать будет )) В общем это большой костыль но не решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 20:59 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
softwarerНе совсем так. Ничего не скроешь от "всех админов разом, действующих в команде". Но разделяя права и полномочия между админами, вполне можно скрыть информацию от конкретных админов. Базу админит все-равно какой-то конкретный человек, даже в облаке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 21:03 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
Allaire Но недостаток не только в этом я так понимаюПравильно понимаете Allaire Шифровать базу целиком смысла нетВы имеете ввиду Transparent Data Encryption? Почему нет? Allaire звучит не очень няшноГлавная беда, что такие данные недоступны не только ДБА, но и СУБД - ни отфильтровать, ни отсортировать. Allaire да и кто ключи-то выдавать будетТаки да, то что нагрузка снимается с СУБД не значит, что она исчезает совсем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 21:44 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
AllaireДобрый день коллеги! ... Может кто-то сталкивался с такой проблемой - подскажите как решить (избавится от клиента не предлагать :)). А что по этому поводу говорит сама MS?! На сколько я помню, можно много из вышесказанного решить правильной настройкой ролей. IMHO в начале нужно ознакомиться с рекомендациями MS. Благо в MSDN статей по этому поводу есть не мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 06:28 |
|
||
|
Варианты безопасности в SQL Server (2012)
|
|||
|---|---|---|---|
|
#18+
AllaireКак разделить клиентов использующих БД для соблюдения бедопасности и сохранности данных? Клиент - это что за сущность, в данном случае?AllaireКак обезопасить данные таким образом, чтобы они были видны только целевым пользователям системы? Это называется "разделение доступа к данным". Для промышленных СУБД, достаточно тривиальная вещь. Вы распишите по пунктам, что мыслится под безопасностью. Сохранность - это ведь тоже компонента безопасности... Allaire1 клиент - 1 база... Недавно обсуждалось . Allaireвсе клиенты буду пользоваться одной базой но разделены при этом т.н. партициями. Начиная с MS SQL Server 2005, можно использовать схемы. Allaireкак обезопасить данные от самих себя <...> По сему - шифрование самой БД (средствами сиквела) отпадает... от админа этим данные не скроешь. Применение других методов шифрования выглядит достаточно страшно, чтобы даже начинать строить что-то подобное. А вы как думали? Шифроваться от DBA - дорогое удовольствие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 12:17 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38826041&tid=1540719]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 275ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...