|
|
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
1. В одной таблице информацию с разным уровнем секретности я бы не держал. Это если грубо. 2. Не переусложняйте, ибо все пароли легко доступны при использовании нагревательных приборов, будь то батарея центрального отопления либо же утюг. 3. Ключи пользователям не передаются, потому что это их сразу компрометирует. Они должны генерить ключи сами, это азбука. Вдумываться лень, т.к. ТЗ кажется писанным далекими от разработки ИС людьми. Впрочем, это все имхо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2006, 22:18 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Imho логично выделить три подзадачи: 1. метаописание структуры данных, 2. политика ограничение доступа, 3. защита данных (шифрование). Метаописание: получение сведений о статусе атрибутов, определение политики доступа. Модель ограничения доступа будет чуть шире традиционной. За основу я бы выбрал комбинацию RBAC и свободного доступа. Шифрование атрибутов здесь обсуждалось. Приватные ключи можно хранить на дополнительно защищенном девайсе (например, шифрованном разделе или удаленном хосте). Imho постановка задачи сыровата. Основная проблема - невнятная логическая модель (абсолютно непонятно, почему возможно существование нескольких политик?). P.S. Если это open source проект - с удовольствием расскажу подробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 11:22 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Как-то не верится что "Бизнес Сущности" будут только храниться в таблицах. "Бизнес Логика" подразумевается?.. Доступ процедур к "Бизнес Сущностям"?.. Как с конкретной постановкой задачи вяжется то, что сводные данные могут на практике иметь более другой уровень секретности, чем данные, использованные для построения отчета?.. =============================================================================== Отвечать без смысла на это письмо. Сообщение направлено вам роботом доски объявлений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 11:41 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
@Dogen: Я согласен, что ключ пользователя-владельца генерится им самим, как быть с теми, кому он дал права на чтение шифрованных полей? Им же их как-то расшифровать надобно... @guest_20040621 огромное спасибо за RBAC - буду изучать документ Открою чуть подробнее и на более абстрактном уровне чего надо: Планируется открытие электронной информационной биржи (Хранилища Информации - ХИ). Товар биржи - информация - ее продают, покупают. ХИ находится на стороне компании-владельца проекта). Каждый клиент биржи должен обладать следующими возможностями: 1. Заносить свою информацию, при этом он должен быть гарантированно защищен от того, что в случае физического доступа к ХИ злоумышленники получат болт. Предполагаемое решение: 1.1. внедрить на стороне ХИ шифрование данных - либо на уровне файловой системы, либо на уровне сервера, либо на уровне таблиц 1.2. данные клиента шифруются своим собственным ключем - на случай, если под утюгом сотрудник компании-владельца проекта расколится на предмет ключа шифрования ХИ, тогда пускай едут к клиенту - другим утюгом работать (уже его проблемы) 2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК имеет доступ к информации клиента. При этом клиент должен иметь также возможность для того, чтобы заинтересовать других клиентов, открыть общедоступную часть публикации для просмотра. При этом система должна автоматически: 2.1. определять, что условия наступили 2.2. определять кому предоставить доступ в связи с 2.1 2.3. наконец этот доступ предоставить 2.4. при наступлении момента окончания подписки - в доступе отказать 3. Подписываться на публикации, созданные другими клиентами. При этом система переводит с баланса клиента-подписчика на баланс клиента-публикатора соответствующуюю цифру (если публикация платная - могут быть и бесплатные)и дает доступ P.S. не стоит ли открыть другой топик для продолжения темы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 13:54 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan@Dogen: Я согласен, что ключ пользователя-владельца генерится им самим, как быть с теми, кому он дал права на чтение шифрованных полей? Им же их как-то расшифровать надобно...Ключ для расшифровки конкретных данных может быть предоставлен пользователям, будучи зашифрованным их открытым ключом. Это должен явно делать тот, кто выдает доступ к этим данным. Например. Можно, наверное, по-разному тут подойти. Общий подход, вероятно, осветит quest_... Stas Tristanспасибо за RBAC"тут я вдруг узнал что всю жизнь говорю прозой" Stas Tristan1. Заносить свою информацию, при этом он должен быть гарантированно защищен от того, что в случае физического доступа к ХИ злоумышленники получат болт. Гарантированная защита информации достигается путем ограничения физического доступа. Есть физический доступ к носителям или каналам передачи данных - считайте защиту скомпрометированной. Если говорить о том, что надо еще время на взлом и т.д. и т.п. - это уже даже не вопросы оперативно-розыскной деятельности, а вопросы построения полукриминальной стратегии работы Вашей гипотетической компании. Вы какую-то башню из слоновой кости строите, и сами в такой же сидите. Как этот проект будет в наших реалиях существовать?.. И что там продавать?.. Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОКПроблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:24 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК Проблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. Подписался, например, на месяц - значит ровно месяц имеешь доступ к информации и к ее обновлениям, закончился месяц - доступ имеешь только к той информации, что вышла в пределах этого месяца, к обновлениям доступ закрыт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:37 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan Stas Tristan2. Создавать публикации своей информации - КТО, на КАКИХ УСЛОВИЯХ и НА КАКОЙ СРОК Проблемы с логикой - что значит срок?? Однажды открыл - считай, навсегда доступно. Подписался, например, на месяц - значит ровно месяц имеешь доступ к информации и к ее обновлениям, закончился месяц - доступ имеешь только к той информации, что вышла в пределах этого месяца, к обновлениям доступ закрытЭто другое дело. Но к отдельным порциям - обновлениям - применимо то, что я сказал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 14:38 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> Это должен явно делать тот, кто выдает доступ к этим данным. Я бы тоже так сделал. Причем, ничто не мешает генерировать ключ с ограниченным временем действия. > физический доступ к носителям Можно тоже шифровать. Ценой потери ~5 - 20 процентов производительности. > каналам передачи данных Как вариант - vpn. Только вот вопрос: что таким образом защищается? Есть смысл городить огород? > Как этот проект будет в наших реалиях существовать? Мне тоже не слишком понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:07 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Господа, если можно в моем посте выше, где я абстрактно описал основные положения необходимой защиты, отметить пункты, за реализацию которых вы бы даже не взялись, в идеале - с обоснованием. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:22 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Ничего сверхсложного в описанном нет. Но за проект я бы не взялся: Вы жестко определили imho далеко не очевидные допущения: все поставщики данных готовы их разместить на Вашем сервере строго определенным Вами образом; для любого поставщика данных приемлем предложенный Вами способ доступа, предложенная Вами тарификация и предложенная Вами защита. Полагаю, это слишком оптимистичный подход. Кстати, наиболее потенциально интересную часть описанного проекта - агрегирование данных нескольких источников - Вы даже не упомянули. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 15:58 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
guest_20040621 все поставщики данных готовы их разместить на Вашем сервере строго определенным Вами образом; для любого поставщика данных приемлем предложенный Вами способ доступа Это гарантируется guest_20040621 для любого поставщика данных приемлема предложенная Вами тарификация и предложенная Вами защита. С тарификацией проблем тоже не будет, защита будет приемлема в том случае, если будут выполняться требования описанные выше, а именно гарантия неприкосновенности данных клиентов даже владельцами проекта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 16:14 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
Stas Tristan С тарификацией проблем тоже не будет, защита будет приемлема в том случае, если будут выполняться требования описанные выше, а именно гарантия неприкосновенности данных клиентов даже владельцами проекта На фига козе баян? Сделайте аукцион информационных лотов, ведь все равно информацию будут покупать, а кто покупает кота в мешке? - хоть название и аннотация блока неких закрытых данных должны иметься в открытом виде. Ну так и не храните данные у себя! Просто выступите посредником. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 16:54 |
|
||
|
Физики и юрики
|
|||
|---|---|---|---|
|
#18+
> С тарификацией проблем тоже не будет Кто-то захочет продавать по-килобайтно, кто-то по-документно, кто-то по времени доступа. У каждого владельца данных есть свои бизнес-процессы. Вряд ли он их будет менять при никем не гарантированном результате. Впрочем, если Вы в этом уверены, - никаких проблем. Просто считаю нужным обратить на это внимание. И еще: г-н Dogen правильно пишет: "Ну так и не храните данные у себя! Просто выступите посредником." Для части данных это imho наиболее логичное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2006, 19:44 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33929050&tid=1545088]: |
0ms |
get settings: |
11ms |
get forum list: |
21ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
182ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 548ms |

| 0 / 0 |
