А вот как сделано: регистрируешься на каком-нибудь сайте,

← →
Рамиль © (2008-04-02 12:49) [40]

> Также думают все правительственные структуры и корпорации
> :(

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

← →
Оригинал (2008-04-02 13:06) [41]

Обычно регламентирующие документы устанавливают, что администратор БД отличается от администратор АРМ, разработчик не имеет доступа к реальным данным. Следовательно, администратор БД не знает алгоритма перемешивания и не может получить список прав.
Это, усложняет ХП, конечно, потому что в этом случае еще и список групп должен быть закрыт от админа БД.

← →
Рамиль © (2008-04-02 13:11) [42]

Знают, не знают роли не играет. А вдруг узнает, алогоритм переделывать? Тем более при физическом доступе можно дизассемблировать. А шифрование нормальным алгоритмом пока вскрывается только полным перебором или с помощью паяльника.

← →
Оригинал (2008-04-02 13:56) [43]

> Рамиль © (02.04.08 13:11) [42]
> Знают, не знают роли не играет. А вдруг узнает, алогоритм
> переделывать? Тем более при физическом доступе можно дизассемблировать.
> А шифрование нормальным алгоритмом пока вскрывается только
> полным перебором или с помощью паяльника.

Ну и узнает? Переделать алгоритм. Да. Не вижу проблем.

Сильное шифрование непринципиальной информации - паранойя.
Не думаю, что кто-то будет заниматься взломом ХП. Кстати, как ты это себе представляешь, даже имея физический доступ к базе? Как раз ХП-то зашифрована средствами ОС.

← →
Рамиль © (2008-04-02 14:09) [44]

Может для Олега она принципиальная, мы ж не знаем.
Насчет шифрования ХП ничего не знаю и комментировать не могу.

Если ХП действительно хорошо шифруется, то лучше зашить в нее секретный ключ в месте с хорошим известным алгоритмом, а не самопальный.

← →
Оригинал (2008-04-02 14:21) [45]

> Рамиль © (02.04.08 14:09) [44]
> Может для Олега она принципиальная, мы ж не знаем.
> Насчет шифрования ХП ничего не знаю и комментировать не
> могу.
>
> Если ХП действительно хорошо шифруется, то лучше зашить
> в нее секретный ключ в месте с хорошим известным алгоритмом,
> а не самопальный.

Тоже вариант. Можно даже список прав прямо в процедуре хранить-)

← →
Ega23 © (2008-04-02 14:32) [46]

> Если ХП действительно хорошо шифруется, то лучше зашить
> в нее секретный ключ в месте с хорошим известным алгоритмом,
> а не самопальный.
>

Это хороший вариант. Но что-то я не вижу в Postgres стандартных опций шифрования ХП и триггера.

← →
Оригинал (2008-04-02 14:38) [47]

> Ega23 © (02.04.08 14:32) [46]
>
> > Если ХП действительно хорошо шифруется, то лучше зашить
>
> > в нее секретный ключ в месте с хорошим известным алгоритмом,
>
> > а не самопальный.
> >
>
>
> Это хороший вариант. Но что-то я не вижу в Postgres стандартных
> опций шифрования ХП и триггера.

Тогда этот вариант не подойдёт...
Внешние библиотеки нет возможности подключать?

← →
Ega23 © (2008-04-02 15:04) [48]

> Внешние библиотеки нет возможности подключать?

Пока ещё не знаю. Но направление понял, буду думать.

← →
Eraser © (2008-04-02 15:05) [49]

мух от котлет надо отделить, imho. пароль пользователя это одно, его хранить не надо, нужно хранить хэш, т.о. даже админ не сможет посмотреть пароль, а в каком виде этот хэш, права или еще что будет храниться в базе это другое.
т.е. можно вообще все данные в БД заносить в уже зашифрованном виде, при этом шифрованием/дешифрованием будет заниматься скрипт. а где хранить ключи или пароли это уже дело админов/разработчиков.

← →
Ega23 © (2008-04-02 15:24) [50]

> Eraser © (02.04.08 15:05) [49]

Вот ты сейчас вообще ничего нового не сказал. :)

← →
tesseract © (2008-04-02 15:52) [51]

> Но что-то я не вижу в Postgres стандартных опций шифрования

А зачем тебе стандартные ?

Извращённый вариант - накатать отельный сервис, к нему цепануть функцию запроса прав и через него запрашивать права, а у юзеров права на просмотр таблицы прав отобрать :-).

← →
Ega23 © (2008-04-02 15:56) [52]

> Извращённый вариант - накатать отельный сервис, к нему цепануть
> функцию запроса прав и через него запрашивать права, а у
> юзеров права на просмотр таблицы прав отобрать :-).
>

И снимаю я бэкап базы, и поднимаю на другом сервере, где имею уровень доступа superuser. И все GRANT-ы летят пописать в Африку (кстати, касается всех субд)

← →
Дмитрий С (2008-04-02 15:59) [53]

> Ega23 ©

чем тебе мой вариант не нравится? необсуждаемый?

← →
tesseract © (2008-04-02 16:07) [54]

> (кстати, касается всех субд)

Скорее всех кривых бэкапщиков.

← →
Ega23 © (2008-04-02 16:51) [55]

> чем тебе мой вариант не нравится? необсуждаемый?

Я администратор. Я не должен знать пароль пользователя (он может вообще его менять каждый день). Но я должен знать его права. И уметь их изменить.
Я в твоём варианте не вижу этой возможности.

← →
Дмитрий С (2008-04-02 16:53) [56]

Опиши полностью кто чего должен мочь?

← →
Ega23 © (2008-04-02 16:56) [57]

> Скорее всех кривых бэкапщиков.

Ну почему? Администратор БД может не являться администратором, гм.. "комплекса". А администратор "комплекса" может не являться администратором БД. Да, на свою базу имеется роль доступа с полными правами. Но на остальные - нет.
А вот если я администратор БД, но не имею доступа к комплексу, то я в любой момент могу посмотреть, что у меня в БД творится.
Так вот, задача - максимально скрыть приватную информацию от вот таких вот ушлых администраторов.

← →
Дмитрий С (2008-04-02 17:05) [58]

А если шифровать все строки в базе. Админ будет видеть связи, но не поймет что к чему.

← →
Ega23 © (2008-04-02 17:07) [59]

> А если шифровать все строки в базе. Админ будет видеть связи,
> но не поймет что к чему.

Нет, это не то, сам понимаешь...

← →
Дмитрий С (2008-04-02 17:14) [60]

ну или как вариант - не хранить связи в базе...

← →
Ega23 © (2008-04-02 17:17) [61]

> ну или как вариант - не хранить связи в базе...

да-да, а ещё все таблицы именовать Table1, Table2, ..., TableN.
И столбцы в каждой - Column1, Column2, ..., ColumnN.... :)

← →
Дмитрий С (2008-04-02 17:23) [62]

А что... написать небольшой модуль, который будет в каждом запросе искать название таблиц и.... ну ты понял =)

← →
Anatoly Podgoretsky © (2008-04-02 17:28) [63]

> Ega23 (02.04.2008 10:54:00) [0]

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

← →
VirEx © (2008-04-02 17:28) [64]

Почему-бы хэш пароля не комбинировать с хешем прав?

← →
Anatoly Podgoretsky © (2008-04-02 17:30) [65]

> Ega23 (02.04.2008 11:31:10) [10]

А зачем их позволять читать?
Ты борешься с последствиями, а не с причиной.

← →
tesseract © (2008-04-02 17:32) [66]

> Так вот, задача - максимально скрыть приватную информацию
> от вот таких вот ушлых администраторов.

гм. Храни отдельно для админов и юзеров. Либо добавляй "мусор" в запись, дабы никто не понял порядок назначения этой ерунды :-)

← →
tesseract © (2008-04-02 17:33) [67]

> Почему-бы хэш пароля не комбинировать с хешем прав?

Читай выше, админ как просмотрит и/или изменит?

← →
Anatoly Podgoretsky © (2008-04-02 17:33) [68]

> Ega23 (02.04.2008 11:49:16) [16]

Это почему сторонний человек имеет прямой доступ до БД?

> Т.е. сторонний человек, имея прямой доступ к БД, не должен
> узнать, разрешено ли юзеру с ID=18 бизнес-действие с кодом
> 55.

а если так
UserRights
User_ID (int) | Rigths (varbinary или image или что там в постгресе) - зашифровано, некая структура или их массив
Смотреть только через специальную смотрелку, которая расшифровывает
Шифровать каким-нить RCA

> Ega23 (02.04.2008 12:42:36) [36]

Ну есть у них прво и что, зачем тогда давал?

> Eraser (02.04.2008 15:05:49) [49]

> пароль пользователя это одно, его хранить не надо, нужно хранить хэш

Это тоже не надо, это задача системы, а не программиста, если не доверяем системы, то ничему доверять нельзя.

> Ega23 (02.04.2008 15:56:52) [52]

> И снимаю я бэкап базы, и поднимаю на другом сервере, где имею уровень доступа superuser.

Тебя надо уволить с волчьим билетом.

> Это почему сторонний человек имеет прямой доступ до БД?
>

Ну простая ситуация: заказчику ставится некий программно-аппаратный комплекс.
Идеальная ситуация - комплекс работает в своей локальной сети, полностью закрытой от локальной сети организации. В таком случае всё ок - имеем свой собственный сервер БД, администратором которого выступает администратор комплекса.
Фиговая ситуация: комплекс функционирует в рамках локальной сети организации. Организация обладает своим сервером БД (MSSQL, например), в рамках которого под данный комплекс администратором БД выделяется БД + учетная запись dbo. Таким образом, администратор БД имеет полный доступ к базе (у него sa-пароль есть), но сам комплекс не имеет доступа к, например, master.

Второй вариант гораздо более вероятен, т.к. дешевле (не надо покупать дополнительное железо и лицензии на ОС для комплекса - отсюда уменьшении стоимости комплекса).

> Ega23 (02.04.2008 16:56:57) [57]

> максимально скрыть приватную информацию от вот таких вот ушлых администраторов.

Опять же уволить.

> Тебя надо уволить с волчьим билетом.

Безусловно. И это задача службы безопасности, чтобы админы не могли бэкап утащить.
Но задачи по максимальному скрытию приватных данных это не отменяет.

Я понимаю, что нет ничего супер-надёжного, можно только максимально постараться затруднить взлом.

> Ega23 (02.04.2008 17:42:14) [74]

Ты во первых путаешь сервер с базой, пароль SA это пароль на сервер.
Второе ты смотришь на это с дилетатнской точки зрения, не являясь специалистом по безопасности, а безопасность это комплекс мер.
И администратор фирмы подчинет не тебе, а как раз наоборот, это их собственность. Кроме того это уже не программно-аппаратный комплекс, что бы он таким стал ты должен поставить как программную сторону, так и аппаратную, опечатанаю, оговоренную договором, что владелец системы не имеет на нее никаких прав, тут ты еще вступишь и в противоречич со многими статьями разных законов, единственный выход это не продавать программно-аппаратный комплекс, а предоставлять услугу по пользованию, это даже не аренда. Ну а в этом случае какая проблема, когда ящик является твоей собственностью и ты не сдаешь его в аренду и никаких проблем ни с администрирование, ни с обнаружением взлома или попыток. Если же владелец не ты, то у тебя нет абсолютно никаких прав указывать владельцу, как ему поступать с его собственностью, всю ответственность перекладываешь на него, и каждый твой чих он будет оплачивать по таксе. Главно правильно составить договор об обслуживании, сколько тебе должны платить за каждый витамин.

> Ega23 (02.04.2008 17:45:16) [76]

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

> Ты во первых путаешь сервер с базой, пароль SA это пароль на сервер.

Ничего я не путаю. Или ты хочешь сказать, что обладая sa я не могу какую-то базу просмотреть?

А вот как сделано: регистрируешься на каком-нибудь сайте, Найти похожие ветки