Защита данных в Lotus

[Kizarek86]

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

Галочка в правах доступа "Ре5пликация или копирование документа" - это запрет на копирование и базы и документа? т.е. при опущеной галке пользователь не сможет создать локальную копию?

 

[Constantin A Chervonenko]

В Домине очень грамотная защита. Доступиться удаленно к док-там, защищенным полями READERS/AUTHORS невозможно. Однако они бесполезны при наличии физического доступа к носителю (локально - всё открывается), а с 6-ки - и удаленному FullAccess-админу.
Действительно прочной защитой остаются подпись и шифрование - опять-же при условии физической защиты ключей.

PS: защита от копирования - вообще чистА интерфейсная (т.е. легко обходится)

 

[Kizarek86]

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

 

[Omh]

Через Lotus юзер не откопирует себе на локал документы, которые не может видеть по причине использования READER/AUTHOR полей.
Т.е. если используются READER/AUTHOR и юзер в них не перечислен, то для юзера этих документов, считай, не существует.
Но если юзер физически скопирует базу с сервака (на уровне файловой системы) и потом откроет локально, то увидит всё.
Кажись так...

 

[Kizarek86]

ет понятно, но пользователь видит документ, он в документе не должен видеть некоторые данные.т.е. скопировать он эти документы сможет.
Возможно ли запретить локальное копирование всем кроме определенных пользователей?

 

[Omh]

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

 

[Constantin A Chervonenko]

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

Не любой (т.е. не "чайник"), но - может. Скопировать. И лично потр*цензура*ть. Обратно на сервер уже не всунет

 

[alb]

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

это так один извариантов для твоего случая, думаю их много.

 

[Kizarek86]

Базу копировать можно запретить?

 

[SkinGreek]

Не любой (т.е. не "чайник"), но - может. Скопировать. И лично потр*цензура*ть. Обратно на сервер уже не всунет

То есть другими словами, система не може защитить себя хотябы на 80% от несанкционированного прочтения конфиденциальной инфы???
Мне просто интересно, сам я в общем то начинающий чайник, но получается что если даже сделать как предложил alb , то "не чайник" может скопировать локально БД, поставить там fulladmin и ресетнуть все поля ридеров?

 

[morpheus]

Базу копировать можно запретить?

да, галочка репликате в АЦЛ для персон

, то "не чайник" может скопировать локально БД,

может скопировать БД, но доки на основе полей ридерс в єту БД не перенесуться

 

[Kizarek86]

Morpheus
Гут, я просто сомневался))) Спасибо.

 

[Medevic]

Мне просто интересно, сам я в общем то начинающий чайник, но получается что если даже сделать как предложил alb , то "не чайник" может скопировать локально БД, поставить там fulladmin и ресетнуть все поля ридеров?

Да, но скопируются только доступные ему документы.

 

[SkinGreek]

но всеже я считаю что зря нет настройки (не применять fulladmin) на случай несанкционированного доступа к файловой системе. Это конечно риск получить потерянную БД в случае потери пароля(так же как и при зашифорованной БД), но это лучше чем зависеть от безопасности окружения.

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

 

[Constantin A Chervonenko]

То есть другими словами, система не може защитить себя хотябы на 80% от несанкционированного прочтения конфиденциальной инфы???
Мне просто интересно, сам я в общем то начинающий чайник, но получается что если даже сделать как предложил alb , то "не чайник" может скопировать локально БД, поставить там fulladmin и ресетнуть все поля ридеров?

1.Никакая система не может себя защитить, если её физически выключат, изымут винчестер и т.д..
2."Честный" хакер (через сеть, удаленно) поля READERS не обойдет
3.Зашифрованные поля - зашифрованы RC2 128-битным ключом. Читайте..

 

[Akupaka]

но всеже я считаю что зря нет настройки (не применять fulladmin) на случай несанкционированного доступа к файловой системе

Full Admin доступен только на сервере, только через Domino Administrator, только тем людям, которые перечислены в спец. поле серверного документа (это, если по правильному)

Если пользователь сможет получить базу в виде файла, то он без проблем сможет ее открыть и менять те данные, которые он видит, т.е. authors/readers-поля действуют на локале, но, если пользователь знает, кто там прописан, и знает как создать id-файл с нужным именем, то тут уже он сможет получить доступ.

Полезна галочка Enforce consistent ACL across all replicas, тогда пользователь не сможет (стандартными средствами) расширить свои полномочия в конкрентной локальной реплике, но от подделанной id'шки это не спасет...

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

но даже шифрование имеет свое ограничение, т.е. надо подбирать способ шифрования из расчета актуальности данных на определенный период времени, который может потребоваться на расшифровку. т.о. если мы зашифровали данные таким методом, что на их расшифровку потребуется год, а данные актуальны лишь пол года, то такая защита будет вполне подходящей...
но можем ли мы быть уверены в этом на 100%?

 

[Constantin A Chervonenko]

Full Admin доступен только на сервере, только через Domino Administrator, только тем людям, которые перечислены в спец. поле серверного документа (это, если по правильному)

IMHO: Full Admin - зло, т.к. понижает доверие к READERS/AUTHORS как средствам защиты. Без Full Admin НИКТО, никакой админ не мог в-тихомолку, бесконтрольно доступиться к конф.данным (иначе как взломав замок в серверную)

Если пользователь сможет получить базу в виде файла, то он без проблем сможет ее открыть и менять те данные, которые он видит, т.е. authors/readers-поля действуют на локале, но, если пользователь знает, кто там прописан, и знает как создать id-файл с нужным именем..

Даже это не требуется. READERS, роли и т.п. на локале просто не действуют

Полезна галочка Enforce consistent ACL across all replicas,

Да. При этой галке ридерс/роли/etc начинают действовать на локале. Но эта галка - один байт в локальном файле .nsf - легко счищается. Осн.ценность Enforce consistent ACL на WPS - отладка, имитация действий сервера

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

Да.
Вот только с шифрованием на уровне файловой системы не согласен. Дело в том, что у автопилотного сервере ключи от баз будут лежать на этом-же сервере, и "в случае обхождения физ защиты" будут украдены вместе с базами.
Шифрование "работает", когда ключи хранятся отдельно от данных: id - у клиента, а док-т - на сервере; или док-т на клиентском ПК, а id - на флэшке в кармане юзера (не на диске этого ПК!)

В общем, справедлива аксиома: никакие программные средства не могут повысить безопасность сверх того, что обеспечено организационными методами (1-й отдел! Ауу!!)

 

[Akupaka]

Даже это не требуется. READERS, роли и т.п. на локале просто не действуют

ну, работают при установленной Enforce consistent ACL across all replicas (это чтобы внести ясность)
со снятой не работают...

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

В общем, справедлива аксиома: никакие программные средства не могут повысить безопасность сверх того, что обеспечено организационными методами

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

 

[abbatik]

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


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

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

А галочка Full Access оказывается иногда крайне удобной и полезной.

 

[Constantin A Chervonenko]

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

.. для того, что-б получить доступ к настройкам и док-там, не имея доступа физического. Unix-way