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

← →
Ega23 © (2008-04-02 10:54) [0]

вводишь пароль и ответ на контрольный вопрос. Если забыл пароль - присылают вопрос, ответил - высылают пароль.
Собственно, вопрос: а как тогда этот пароль хранят? Не в открытом же виде...

← →
Kolan © (2008-04-02 10:55) [1]

> а как тогда этот пароль хранят? Не в открытом же виде&#133

В зашифрованом.

← →
Рамиль © (2008-04-02 10:58) [2]

В большинстве случаев высалают новый пароль. А старый это от лукавого.

← →
Ega23 © (2008-04-02 11:02) [3]

> В зашифрованом.
>

интересует алгоритм, который в обе стороны действует.

← →
Kolan © (2008-04-02 11:03) [4]

> интересует алгоритм, который в обе стороны действует.

xor :)

← →
Eraser © (2008-04-02 11:08) [5]

> Ega23 © (02.04.08 11:02) [3]

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

← →
Kolan © (2008-04-02 11:09) [6]

> лучше действительно не хранить пароль ни в каком виде

Это, а как тогда при входе проверять пароль?

← →
Eraser © (2008-04-02 11:09) [7]

> Kolan © (02.04.08 11:09) [6]

по хэшу

← →
tesseract © (2008-04-02 11:22) [8]

> Это, а как тогда при входе проверять пароль?

В *nix и windows тоже пароли не храняться. Везде хэши.

← →
Kolan © (2008-04-02 11:23) [9]

> по хэшу

Согласен, неподумал.

← →
Ega23 © (2008-04-02 11:31) [10]

> лучше действительно не хранить пароль ни в каком виде, а
> по запросу на восстановление - высылать на почту ссылку,
> при переходе на которую сбрасывается текущий пароль и осуществляется
> переход на страницу для установки нового.

Мне права пользователей на определённые действия каким-то макаром шифровать надо. Вот сижу, мучуюсь...

← →
Kolan © (2008-04-02 11:34) [11]

> Вот сижу, мучуюсь&#133

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

← →
Оригинал (2008-04-02 11:34) [12]

> Мне права пользователей на определённые действия каким-то
> макаром шифровать надо.

Права пользователей на какие действия и в какой системе?

← →
DVM © (2008-04-02 11:35) [13]

> Если забыл пароль - присылают вопрос, ответил - высылают
> пароль.
> Собственно, вопрос: а как тогда этот пароль хранят? Не в
> открытом же виде...

Чаще всего высылают новый пароль сгенерированный.
А старый могут хранить и незашифрованном виде ибо один фиг если он обратно может быть расшифрован как хранить.

← →
Ega23 © (2008-04-02 11:40) [14]

> Права пользователей на какие действия и в какой системе?

Ну, условно говоря, так:
есть таблица неких бизнес-действий (Просмотр такого-то отчета, модификация таких-то данных и т.п.). Есть аккаунты пользователей. Вот надо связать аккаунт с бизнес-действиями. При этом разрешено действие, или нет - должно хранится в зашифрованном виде.
Казалось бы самое очевидное - md5(пароль + код действия + true (или false)).
всё прохавается на ура. Только вот администратор тогда права пользователя никак увидеть не сможет... :)

← →
Kolan © (2008-04-02 11:44) [15]

> Только вот администратор тогда права пользователя никак
> увидеть не сможет&#133 :)

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

← →
Ega23 © (2008-04-02 11:49) [16]

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

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

← →
tesseract © (2008-04-02 11:53) [17]

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

Ну так шифруй. RC4 например - достаточно шустрый алгоритм.

← →
Kolan © (2008-04-02 11:54) [18]

> сторонний человек
>md5(пароль + код действия + true (или false)).

А, тут скобочки на все.

← →
Alien1769 © (2008-04-02 11:55) [19]

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

Так шифруй информацию пользователей по главному паролю создателя базы и все !

← →
Дмитрий С (2008-04-02 11:57) [20]

> Только вот администратор тогда права пользователя никак
> увидеть не сможет... :)

Администратор отснифить пароль может. А если еще ЭТО написано на PHP, то и изменить код кое где =)

А так ведь ты же придумал, в чем проблема то???

Кстати а как в твоем случае наградить пользователя правами не зная его пароля??

← →
Ega23 © (2008-04-02 12:00) [21]

> Кстати а как в твоем случае наградить пользователя правами
> не зная его пароля??

Дык в этом-то и проблема... :)

← →
Ega23 © (2008-04-02 12:01) [22]

Кстати, дело даже хуже. Практически любой пользователь должен иметь возможность посмотреть свои текущие права. Изменить - нет, а вот просмотр - пожалуйста.

← →
Оригинал (2008-04-02 12:02) [23]

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

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав). Права на расшифровку-прямое выполнение ХП должен иметь только администратор, выполнение ХП разрешено только из прикладного ПО.

← →
Kolan © (2008-04-02 12:02) [24]

> Кстати, дело даже хуже.

По сути это одно и тоже. Используя хеш ты не можешь восстановить назад все. А [17] неподходит?

← →
Оригинал (2008-04-02 12:04) [25]

Непонятно только, чего тут в трепе ветка делает-)

← →
Оригинал (2008-04-02 12:11) [26]

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

← →
Kolan © (2008-04-02 12:13) [27]

> Наверное даже проще можно сделать.

Так а как это спасет от прямого доступа к БД, когда я могу наплевать на ХП. Взять и поспотреть что там в таблице UserRight лежит?

← →
Ega23 © (2008-04-02 12:14) [28]

> Наверное даже проще можно сделать.
> Зашифрованная средствами БД ХП должна выдавать список прав
> только админу. Зарегистрированным пользователям - только
> список их прав.
> Тех, кто не зарегистрирован в БД для использования конкретных
> бизнес-процессов, вообще не получают информации.

Она тупо не спасёт от прямого селекта из таблицы прав.

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

> Kolan © (02.04.08 12:13) [27]
> > Наверное даже проще можно сделать.
>
> Так а как это спасет от прямого доступа к БД, когда я могу
> наплевать на ХП. Взять и поспотреть что там в таблице UserRight
> лежит?

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав).

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

> Ega23 © (02.04.08 12:14) [28]
>
> > Наверное даже проще можно сделать.
> > Зашифрованная средствами БД ХП должна выдавать список
> прав
> > только админу. Зарегистрированным пользователям - только
>
> > список их прав.
> > Тех, кто не зарегистрирован в БД для использования конкретных
>
> > бизнес-процессов, вообще не получают информации.
>
>
> Она тупо не спасёт от прямого селекта из таблицы прав.

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав).

← →
Оригинал (2008-04-02 12:15) [31]

Реальный список прав можно получить только через ХП.

← →
Kolan © (2008-04-02 12:16) [32]

> Перемешать по некоторому алгоритму строку с правами (например
> битовую маску прав).

Кстати да. Тогда создасться впечатление, что с правами ничего не делали, но все будет неправильно.

А функцию перемешивания я бы на клиенте сделал.

← →
Оригинал (2008-04-02 12:17) [33]

> А функцию перемешивания я бы на клиенте сделал.

Тогда алгоритм можно определить.

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

> Перемешать по некоторому алгоритму строку с правами (например
> битовую маску прав).

Шифрование через неясность порочно по своей сути.

Может сделать так:

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

Правда тут есть несколько тонких моментов, надо над ними подумать.

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

> Рамиль © (02.04.08 12:36) [34]
>
> > Перемешать по некоторому алгоритму строку с правами (например
>
> > битовую маску прав).
>
> Шифрование через неясность порочно по своей сути.

Вряд ли. Алгоритм перемешивания достаточно хранить в секрете и всё.
Не нужно усложнять жизнь. Лучше минимальная достаточность.

← →
Ega23 © (2008-04-02 12:42) [36]

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

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

> Ega23 © (02.04.08 12:42) [36]
> Интересно. Но есть проблема: под "администратором" я называю
> того пользователя (или группу пользователей), которым доступно
> бизнес-действие "изменение прав пользователей"

Ну так если администраторы доолжны иметь доступ, надо им дать соответствующие права, включив в отдельную группу.

← →
Дмитрий С (2008-04-02 12:45) [38]

А если сделать так:

В таблицу аккаунтов добавляется еще два поля:
login_count - увеличивается при каждом входе пользователя
login_count_cs - вычисляется при каждом входе на основе пароля и поля login_count.

Таблица прав пользователей организована как ты сказал:
md5(account_id + right_id + password)

При добавлении какого либо права пользователю в таблицу прав добавляется запись:
md5(account_id + right_id + login_count_cs)

А при каждом входе клиентская часть ищет (перебором видимо придеться, надеюсь прав не так много=) ) все строки, которые соответствуют
md5(account_id + right_id + login_count_cs)
и переделывает их в формат
md5(account_id + right_id + password), зная, конечно пароль (А пароль пользователь только что ввел, для того чтобы войти).

Тем самым у администратора будет очень мало шансов, что либо узнать =)

Можно упростить схему...
Добавлять в таблицу записи вида
md5(account_id + right_id)
и также, при входе пользователя, конвертировать их.

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

> Ega23 © (02.04.08 12:42) [36]

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

> Вряд ли. Алгоритм перемешивания достаточно хранить в секрете
> и всё.
> Не нужно усложнять жизнь. Лучше минимальная достаточность.
>

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

← →
Рамиль © (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]

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

← →
clickmaker © (2008-04-02 17:36) [69]

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

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

← →
VirEx © (2008-04-02 17:36) [70]

> [67] tesseract © (02.04.08 17:33)

комбинировать можно по разному

← →
Anatoly Podgoretsky © (2008-04-02 17:37) [71]

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

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

← →
Anatoly Podgoretsky © (2008-04-02 17:40) [72]

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

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

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

← →
Anatoly Podgoretsky © (2008-04-02 17:41) [73]

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

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

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

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

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

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

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

← →
Anatoly Podgoretsky © (2008-04-02 17:43) [75]

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

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

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

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

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

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

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

← →
Anatoly Podgoretsky © (2008-04-02 17:55) [77]

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

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

← →
Anatoly Podgoretsky © (2008-04-02 17:57) [78]

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

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

← →
Ega23 © (2008-04-02 18:00) [79]

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

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

← →
Ega23 © (2008-04-02 18:00) [80]

> Anatoly Podgoretsky © (02.04.08 17:55) [77]

А это - крайне интересно, спасибо, не знал. :)

← →
Anatoly Podgoretsky © (2008-04-02 18:05) [81]

> Ega23 (02.04.2008 18:00:19) [79]

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

← →
Ega23 © (2008-04-02 18:06) [82]

> а если себе не доверяешь?

убить себя апстену? (других вариантов чё-та не вижу...) :)

← →
Anatoly Podgoretsky © (2008-04-02 18:10) [83]

> Ega23 (02.04.2008 18:00:20) [80]

Юриспруденция крайне сложная вещь, тут нельзя опираться на свои предположения, юристы должны серьезно поработать, особенно в твоем случае, иначе можно нарвать на серьезные неприятности.
Это кстати из той же оперы, когда программу привязывают к железу, одного привязывальщика мы серьезно наказали в начале 90 годов, за его счет обновили свой компьютерный парк и купили программу у его конкурента, он не учел класс наших юристов, а они мирового класса. Ему еще очень не повезло, что он уехал куда то далеко на отпуск, за счет этого сумма убытков взлетела до астрономических величин, с тех пор мы его больше не видели на рынке.

← →
Дмитрий С (2008-04-02 18:11) [84]

> с тех пор мы его больше не видели на рынке.

Он теперь на рынке... в самом прямом смысле этого слова =)

← →
Kolan © (2008-04-02 18:17) [85]

> а они мирового класса

Мирового класса по Российскому законодательству? :)

← →
b z (2008-04-02 19:11) [86]

> Ega23 ©

Вы так долго изобретали UID, почему бы его не использовать в данном случае, т.е. "мусорить" (или еще как) права юзера с его-же UID-ом ... (как предложение)

← →
Anatoly Podgoretsky © (2008-04-02 19:44) [87]

> Ega23 (02.04.2008 18:06:22) [82]

Не, ну я серьезно.

← →
Anatoly Podgoretsky © (2008-04-02 19:49) [88]

> Kolan (02.04.2008 18:17:25) [85]

С Российским законодательством почти не приходится иметь дело, зона интересов, весь наш рынок это Евросоюз, обе америки и Серверная Африка, без хороших юристов легко остаться без штанов, но мы и сами можем других оставить без этого, только дай повод.

← →
tesseract © (2008-04-02 20:45) [89]

> Вы так долго изобретали UID, почему бы его не использовать
> в данном случае, т.е. "мусорить" (или еще как) права юзера
> с его-же UID-ом ... (как предложение)

Предложение надо осмыслить, Ваше уровня "Я студент, я крут, я кучу книжек перечитал".
Я видел много систем, объяснить зачем Олегу это понадобилось, кроме как ИБД всяких доморощенных security я не могу.

← →
KlGuy (2008-04-02 20:53) [90]

А в чем проблема?
Очень сложно ограничить разрешить доступ к таблице только определенным процедурам, доступ к процедурам разрешить только админу и клиентскому ПО, ну а в самих процедурах уже права конкретного пользователя проверять.

← →
tesseract © (2008-04-02 20:55) [91]

> доступ к процедурам разрешить только админу и клиентскому
> ПО, ну а в самих процедурах уже права конкретного пользователя
> проверять.

Код запроса в студию.

← →
KlGuy (2008-04-02 20:59) [92]

> tesseract © (02.04.08 20:55) [91]

"Хватит умничать, давай код" ?

Если тут с серьезными СУБД никто не работал толком, я как-то не виноват. RTFM.

← →
tesseract © (2008-04-02 21:02) [93]

> Если тут с серьезными СУБД никто не работал толком, я как-
> то не виноват. RTFM.

Тут все работаю с серьёзными СУБД. Читай ветку с начала.

← →
KlGuy (2008-04-02 21:05) [94]

> tesseract © (02.04.08 21:02) [93]

Да читал я ветку. Правильное решение еще в [26] написано. К этому только добавить настройку прав доступа к самой таблице и все. А от админа ничего не спасет, с этим в детский сад.

← →
Ega23 © (2008-04-02 21:10) [95]

> Да читал я ветку. Правильное решение еще в [26] написано.

Видать хреново читал.

← →
tesseract © (2008-04-02 21:21) [96]

> Да читал я ветку. Правильное решение еще в [26] написано.

оу из да мэн!!! МегаФранч. Твое любое решение при условии доступа к файлам я хакну за вечер. Ну не считай всяких хитростей вроде шифровке самих файлов - потребуеться расшифровать. Если бы в [26] присутсвовало правильное решение ветка бы замолчала. Ega23 много лет проработал в системах безопастности и именно с "крутыми" БД. Так что, он зря не спрашивает.

← →
Ega23 © (2008-04-02 21:32) [97]

> Ega23 много лет проработал в системах безопастности и именно
> с "крутыми" БД.

Я всё-таки немного в другой "безопасности", я скорее по сигнализациям всяким и управлению доступом.

← →
KlGuy (2008-04-02 21:39) [98]

> tesseract © (02.04.08 21:21) [96]
> оу из да мэн!!! МегаФранч. Твое любое решение при условии
> доступа к файлам я хакну за вечер. Ну не считай всяких хитростей
> вроде шифровке самих файлов - потребуеться расшифровать.

Странно, что ты еще не миллионер. Напиши в суппорт Оракла и Мелкософт, как хакнуть базу не зная админского пароля, но имея доступ к файлам, они заплатят, уверен :)

Детский сад.

← →
Ega23 © (2008-04-02 21:42) [99]

> Напиши в суппорт Оракла и Мелкософт, как хакнуть базу не
> зная админского пароля, но имея доступ к файлам, они заплатят,
> уверен :)

Еще раз: возьми бэкап базы и восстанови его дома на локальном сервере.

← →
KlGuy (2008-04-02 21:47) [100]

> Ega23 © (02.04.08 21:42) [99]

Где я его полный возьму, если я не админ?
А как безопасно хранить админские дампы - другой вопрос. Сама база данных его не обязана решать.

← →
tesseract © (2008-04-02 22:00) [101]

> Напиши в суппорт Оракла и Мелкософт, как хакнуть базу не
> зная админского пароля, но имея доступ к файлам, они заплатят,
> уверен :)

Задача стоит защить базу от тех кто ЗНАЕТ админский пароль.

← →
tesseract © (2008-04-02 22:02) [102]

> Где я его полный возьму, если я не админ?

Ты задачи больше 1 миллиона рублей ЯВНО не решал. Так что брось понты кидать. Получить админские права - около 10-20 тысяч долларов + 4-5 недель. В базе средней конторы.

← →
KlGuy (2008-04-02 22:02) [103]

> tesseract © (02.04.08 22:00) [101]
> Задача стоит защить базу от тех кто ЗНАЕТ админский пароль.

Эта задача нерешаема в принципе. Если подумаешь, поймешь почему.
Тут либо делать "админа" с кастрированными правами доступа взамен настоящего, либо не болтать ерундой.

> Эта задача нерешаема в принципе.

Хакни novel + eDrirectory - там такое возможно.

> Задача стоит защить базу от тех кто ЗНАЕТ админский пароль.

Не знаю, как в MSSQL, но во многих базах эта задача решается только поддержкой шифрования данных.

> Эта задача нерешаема в принципе.

Решаема в принципе. Вон, Линукс вообще опенсорсный. При входе - только логин и пассворд. Однако как-то определяет, какие тебе права положены.

Ega23 © (02.04.08 22:12) [106]

> Вон, Линукс вообще опенсорсный. При входе - только логин
> и пассворд. Однако как-то определяет, какие тебе права положены.
>

И от root-а защищена ?

Задача стоит не защитить базу, а недопустить сговора пользователя с человеком, имеющим прямой доступ к данным, с целью "поднятия" прав доступа пользователя.

> И от root-а защищена ?

дык а как она узнаёт, что ты - root? Как-то ведь узнаёт. И даёт полный доступ ко всему.

> Однако как-то определяет, какие тебе права положены.

Права на файлы - не больше. Каждому файлу определены только то что текущий пользователь может с ним делать, всё в ФС. Можно в приципе, он очень много кода и триггеров потребуеться.

> дык а как она узнаёт, что ты - root? Как-то ведь узнаёт.

userid = 0 ;-)

> userid = 0 ;-)

ну хорошо, одного мы так исключим... :)))

> ну хорошо, одного мы так исключим... :)))

В тяпницу расскажу как там что. На пальцах лучше получаеться. Но база "вширь" у тебя сильно пойдёт. И против "рестора" из бэкапа не попрёшь.

> Задача стоит не защитить базу, а недопустить сговора пользователя
> с человеком, имеющим прямой доступ к данным, с целью "поднятия"
> прав доступа пользователя.

С этого места подробнее или ссылку на пост с подробным описанием

> С этого места подробнее или ссылку на пост с подробным описанием

[0] и чуть ниже. Или смотреть учебные материалы по netware / eDirectory. Наверно поэтому и въехал что именно нужно - на курсах очень подробно объясняли как это в eDirectory делаеться. На пальцах - нужен chroot.

> [0]

и [108] как-то слабо связаны между собой. Админ чего имеется в виду - базы данных или локальной сети ?

> Админ чего имеется в виду - базы данных или локальной сети
> ?

Все уровни. + Должен быть выделен админ кнкретного отдела, novel с этим вопросом 30 лет билась. Но решение нашла, но не через SQL.

← →
KlGuy (2008-04-02 22:47) [119]

Бедлам какой-то. Спецъйалисты :). Куда мне там...

> Причем тут novell ?

Там есть решение нужное олегу :-). Каждая ветка может быть изолирована по уровню доступа, даже от самого верховного Админа.

Короче, смысл такой:
Есть пользователи, есть "бизнес-действия". На каждое бизнес-действие пользователю либо дано разрешение, либо нет. Раздача таких прав - одно из бизнес-действий. Таким правом могут обладать несколько пользователей.
Задача: исключить возможность разоешения какого-либо бизнес-действия любому пользователю, работая с БД напрямую.
Т.е. я, как разработчик, пририехав на "объект" и подсоединившись к базе напрямую, не мог бы разрешить какому-либо пользователю право на бизнес-действие.

Как-то так.

> KlGuy (02.04.08 22:47) [119]
>
> Бедлам какой-то. Спецъйалисты :). Куда мне там...

Вы бы зарегистрировались сперва...

> Ega23 © (02.04.08 23:00) [121]
> Короче, смысл такой:
> Есть пользователи, есть "бизнес-действия". На каждое бизнес-
> действие пользователю либо дано разрешение, либо нет. Раздача
> таких прав - одно из бизнес-действий. Таким правом могут
> обладать несколько пользователей.
> Задача: исключить возможность разоешения какого-либо бизнес-
> действия любому пользователю, работая с БД напрямую.
> Т.е. я, как разработчик, пририехав на "объект" и подсоединившись
> к базе напрямую, не мог бы разрешить какому-либо пользователю
> право на бизнес-действие.
>
> Как-то так.

Надо делать так: суп отдельно - мухи отдельно.
Если программа основана на сереверных вебскриптах (php,asp,...), то проще всего защититься от пользователя создав эккаунт для вебсайта.

1. Защищаем БД от юзеров:
Значит, ренгистрируешь webapp под iis. Создаешь app pool для этого webapp. Даешь этому app pool некий windows (или какая там система) системный эккаунт. Пускаешь этот app pool под этим экаунтом. Регистрируешь этот эккаунт на БД как некого юзера (или trusted или с паролем). Создаешь в БД database role. Включаешь в эту database role эккаунт своего app pool, и указываешь "размеры" допуска этой database role к БД объектам.

2. Строим юзеров:
Создаем таблицу в БД (с отдельным доступом)/xml файл/просто файл/еще что-то где храним уровни доступа/пароли/логины/адреса/явки к ресурсам/страницам/функциям вебсайта. Можно даже использовать Active Directory User Groups (даже предпочтительнее, если вебсайт на локалке).
После того как юзер идентифицирован и впущен, определяем его уровень доступа и храним его в переменной session и используем для определения доступности ресурсов на текущей странице...

Ega23 © (02.04.08 23:00) [121]

> Короче, смысл такой:
> Есть пользователи, есть "бизнес-действия". На каждое бизнес-
> действие пользователю либо дано разрешение, либо нет. Раздача
> таких прав - одно из бизнес-действий. Таким правом могут
> обладать несколько пользователей.
> Задача: исключить возможность разоешения какого-либо бизнес-
> действия любому пользователю, работая с БД напрямую.
> Т.е. я, как разработчик, пририехав на "объект" и подсоединившись
> к базе напрямую, не мог бы разрешить какому-либо пользователю
> право на бизнес-действие.
>
> Как-то так.

Ясно. На Oracle бы подумал, про MSSQL не знаю ничего.

> Ясно. На Oracle бы подумал, про MSSQL не знаю ничего.

Должно быть некое общее решение, "СУБД-независимое"
В принципе, есть некоторые идеи, но они ещё, как бы это сказать, в виде "образов" в башке витают. Как оформятся - отпишу.

> Мазут Береговой © (02.04.08 23:38) [123]

За идею спасибо, но архитектура системы будет несколько сложнее.

Использование Active Directory Groups.
Если локалка правильно организована, то каждый работник, должен иметь эккаунт для попадания в компутер. Так же юзеры должен быть разделены на группы, которые должны определять уровни доступа к сетевым ресурсам компании. Можно использовать эти же группы, или создать новые исключительно для сайта...

Всегда пожалуйста.. :-)

Ega23 © (02.04.08 23:48) [125]

> Должно быть некое общее решение, "СУБД-независимое"

В Оракле это можно реализовать ролями. Как это делается в MSSQL я не знаю. Независимое от СУБД решение основано на GRANT и REVOKE :)

> В Оракле это можно реализовать ролями. Как это делается
> в MSSQL я не знаю. Независимое от СУБД решение основано
> на GRANT и REVOKE :)

да вот как раз это дело в бошке и вертится. только ещё не оформилось окончательно... :)

От разработчика ты можешь обезопаситься, а от администратора базы данных - нет.

> Игорь Шевченко © (03.04.08 00:16) [128]
> Ega23 © (02.04.08 23:48) [125]
>
>
> > Должно быть некое общее решение, "СУБД-независимое"
>
>
> В Оракле это можно реализовать ролями. Как это делается
> в MSSQL я не знаю. Независимое от СУБД решение основано
> на GRANT и REVOKE :)

Это то, о чем я писал в пункте 1;
В MSSQL есть GRANT (неуверен насчет revoke);
Хотя, может это разные вещи в Oracle & MSSQL;

есть там и grant и revoke

недочитал, ибо вариант
хранить права отдельно шифруя мд5(юзер.право)
по одному праву на запись
обратно - перебором.

> хранить права отдельно шифруя мд5(юзер.право)

А Админу как ?

просмотр прав пользователей - поиск перебором
добавление права - внесение сгенерированой записи
удаление права - поиск сгенерированой записи и удаление оной

> просмотр прав пользователей - поиск перебором

Это в смысле брурфорсом? :)

← →
Дмитрий С (2008-04-03 11:31) [137]

> Это в смысле брурфорсом?

А что, долго чтоли?

Кстати, всетаки левый администратор должен не иметь прав только изменять данные, или же изменять и видеть??

Ну видеть-то он их по-любому сможет.
Нет, только изменять.

Точнее, изменить-то он тоже может. Только вот "повысить" права доступа не сможет.

← →
KlGuy (2008-04-03 16:07) [140]

Сколько еще человек должны повторить эту простую мысль:

> Игорь Шевченко © (03.04.08 00:31) [130]
> От разработчика ты можешь обезопаситься, а от администратора
> базы данных - нет.

?

← →
Дмитрий С (2008-04-03 16:11) [141]

Ну так это ж можно сделать дополнительным полем (контрольный хеш на основе данных о записи и некому секретному ключу, который храниться у программы в другом месте и для каждого клиента уникален и известен только ему).

> и для каждого клиента уникален и известен только ему

Так как редактировать права пользователя, если эта штука известна только ему? :)

На самом деле решение, вроде как найдено. Комбинированный способ через GRAND на 2 разные роли + шифрование по алгоритму.

Сдается мне, что шифрование здесь - это хороший способ выстрелить себе в ногу

> Сдается мне, что шифрование здесь - это хороший способ выстрелить
> себе в ногу

Тут фишка такая, что я, имея прямой доступ к базе, не мог сказать: "вот этому товарищу разрешено это, это и ещё вот это, а другому - только то".
С учётом того, что обращений будет совсем не много - сойдёт.

Ega23 © (03.04.08 16:58) [144]

Так может быть прямой доступ к базе тебе не надо иметь ? А нужный доступ иметь только тем, кому это по должности положено ?

> А нужный доступ иметь только тем, кому это по должности
> положено ?

Вот им и нефиг смотреть.
Игорь, так долго объяснять, я лучше в пятницу расскажу.

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