guest_20040621> не добавить ли управление по уровням секретности данных

Данные шифруются? Есть ограничение доступа на уровне СУБД?Первое - нет; принципиально против второго. Но если действительно копать в эту сторону, то вопрос для меня видится совершенно не проработанным, и даже намеков на хорошие решения я не видел. Ведь тут и от админов закрывать надо. И так далее.

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

guest_20040621> зачем это нужно

Классная штука, кстати. Модель ограничения доступа TE (Type-Enforcement). Все довольно просто: домены -> типы > политики доступа. Попробуйте в permissive mode - реально работать не будет, но на лог интересно посмотреть. Можно SEEdit использовать - у него свои политики, но более прозрачное управление.На досуге посмотрю. В практике использовал только AD, т.е. из противоположного лагеря, но до чего же недоделанная вещь.

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

Конечно, под конкретную организацию можно это видоизменить, но пока таких запросов не поступило. Наш клиент - СМБ - не особо взыкателен в данном вопросе, опыта не имеет.

guest_20040621Тогда в чем смысл управления уровнями секретности? - dba все видит.Проблема всевидящего ДБА - это одна проблема, а проблема назначения информации некоего уровня секретности - другая. На практике я их делю и пока первую не пытаюсь решить. Я все говорил применительно к правам доступа пользователей - например, документ имеет гриф ДСП и к нему нет доступа у юзера Гест, пофиг что это документ относится, например, к ОбластиОбщихЗнаний и у Геста есть доступ к этому типу документов.

guest_20040621Почему принципиально против ограничений на уровне пользователей БД?Просто потому что предпочитаю аутентификацию средствами разрабатываемой системы, а не средствами ОС. Надежнее? Кто его знает. Мне так удобнее по жизни.

> Ведь тут и от админов закрывать надо. И так далее.

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

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

guest_20040621> На досуге посмотрю.

Я плохо рассказал; нужно было сразу уточнить. Домены в SELinux - это не обычные домены, это такая абстракция контекста для процессов. ;) Ну, вот так неудачно назвали. ;)Ну я и не думал что это домены AD.

guest_20040621> проблема назначения информации некоего уровня секретности - другая

Imho это две части одной и той же проблемы. ;) Об этом мы тоже никому не расскажем. Это как эзотеричность знаний о конструкции замков ;)

guest_20040621Практически все руководства по ограничению доступа начинаются с простейшего примера, связанного с ограничениями на уровне объектов бд. ;)Ай, эти простейшие примеры... Ну зачем зависеть от ДБА. Другое дело, что если оправдано усилить систему защиты от НСД (понижая вероятность успешного осуществления попыток оного), то это надо сделать.

guest_20040621> Как реализовать - без понятия.Ну в общем-то мало-мало подумавши вариант не один появляется, да.

guest_20040621> В итоге систему довольно сложно спроектировать без дыр.

Да нет, абсолютно реально. Только ресурсов она будет есть... как хороший, большой паровоз. ;)) Впрочем, сервера дешевеют на глазах. ;)В частном случае тонкого клиента можно шифрование выполнять на нем (и доступа ДБА к администрированию рабочих станций не давать :).

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

guest_20040621
Похоже, и эта тема себя исчерпала. :(Дааа, темы кончились.

Пытался шо-нибудь вспомнить - нету. Спроектировали уже всё. Блин.

По обоим примерам у меня сразу перед глазами встает старая добрая Украина.

guest_20040621
Буквально сегодня в "Коммерсанте" два интересных материала: о ЕГАИС (отдали ФНС и похоже будут переписывать) На Украине в 1990-х работала гос.система межбансковких расчетов. Не знаю как сейчас, а тогда платежи можно было отправить и получить в течение полутора часов, без российских извращений с "рейсами" и т.п. Тупая, надежная, грамотно сделанная система. Кроме этой системы, работали частные сети межбанковских расчетов, не мешавшие, а дополнявшие ее. Было несколько вариантов использования СКЗИ. Все очень дубово, ни разу не слышал о сбоях системы, работал сам в ней несколько лет. Сделано было в эпоху управления Нацбанком... правильно, Ю.

Здесь так отчего-то не умеют.

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

Это было никому не надо. Задинамили и сдохло.

ЕГАИС никому не надо (имеются в виду участники системы, не берем в расчет инициаторов и т.п.).

От того, что я слышу и читаю про ЕГАИС, меня трясет. Этих, гм, разработчиков надо было отправлять сидеть на точках в тайге. И не пущать к проектированию таких систем. Ну я уже высказывался в топике про ЕГАИС.

guest_20040621и о системе персонального учета населения МЭРТ (идентификаторов не будет; будет "стандарт процедуры отождествления данных").Та же Украина хотела иметь БД о всех операциях физлиц. Это хотел не банк, а ГНИ. Примитивная прикидка объема БД сразу давала вывод - ГНИ не потянет. Денег не хватит.

По-моему, тоже сдохло.

А реестр физлиц-плательщиков налогов делали так: организации, гед это надо делать, печатают на бумаге, а некоторые даже покупают программы для ввода данных и печати форм (я даже такое сделал однажды), печатают и несут в ГНИ. Там сидит девочка и перебивает.

Предложили принести файл - хоть бумагу сэкономили бы всем! - сказали, что нет, сказали делать как делаем.

В России дури может и хватит профинансировать бюждет такой системы, но ума не хватит реализовать.

guest_20040621

Если Вы внимательно посмотрите на задачу, то формулироваться она будет примерно так: есть некий набор обособленных информационных систем, причем, данные этих систем могут пересекаться. Вопрос: как максимально достоверно сопоставить данные всех информационных систем. Вы полагаете, решение очевидно? Было бы интересно послушать, каким Вы его видите.

Hint 1: количество информационных систем не определено.
Hint 2: требования к структуре и способу хранения данных информационных систем не определены.

Главное, чтобы нам (налогоплательщикам) не продали для этого BizTalk. Боже, если ты есть, сделай так, чтобы нам (налогоплательщикам) не продали для этого BizTalk.