документооборот и доступ к файлам

[ivas]

Цитирую задачу (прислано заказчиком):

Описание текущей ситуации
- Сейчас каждый пользователь, имеющий право работать с документооборотом и файлами документооборота должен иметь доступ к файловому хранилищу \\server\doc.

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

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

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

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

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

Конкретного способа решения проблемы пока не придумал.

Есть варианты
- При размещении файл копируется клиентом в некую промежуточную папку, открытую для всех в сети. Далее этот файл "подхватывает" АОС, размещает в своем файловом хранилище стандартной процедурой.

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

Возможны и другие варианты. Может кто то уже решал данную проблему...
(Ax 3.0 sp3)

[glibs]

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

[twilight]

А почему бы просто не хранить документы в базе?

[ivas]

Цитата:

Сообщение от twilight

А почему бы просто не хранить документы в базе?

их достаточно много > 50гб

[twilight]

Цитата:

Сообщение от ivas

их достаточно много > 50гб

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

[ivas]

Цитата:

Сообщение от twilight

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

мысль интересная надо её подумать

[glibs]

Цитата:

Сообщение от twilight

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

Вопрос в количестве документов и количестве обращений к ним. А также в том, читаются они в основном или модифицируются.

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

С т.з. производительности влияет. Это бесспорно. Вопрос только насколько существенно (ощутимо).

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

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

Работа с документами врядли ощутимо нагрузит процессор сервера БД.

Работа с документами при интенсивной работе с большими по размеру файлами достаточно ощутимо загрузит сетевой интерфейс на сервере БД.

Работа с документами при интенсивной работе с большими по размеру файлами отнимет память на сервере БД под выполнение задач ввода-вывода. Затрудняюсь оценить насколько много. Попробую уточнить у специалистов. Или они сами тут напишут. Знаю точно, что в файловых серверах много памяти не бывает. Думаю, это не спроста.

Последнее важно в связи с тем, то сервер БД сложно масштабировать.

Если вы что-то понимаете в задачах и процессах администрирования сервера БД, то... даже при условии хранения файлов на отдельном дисковом массиве БД (как единая сущность) будет пухнуть. А значит будет пухнуть архив БД. А это уже увеличит время на сервисные процедуры с БД (архивирование). Того же стоит ожидать и в случае, если БД будет восстанавливаться из архива при необходимости такого восстановления. А время — деньги, как известно.

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

А если, например, сервер БД сконфигурирован в режиме зеркалирования (горячий stand by), то пошло-поехало.

И наконец, стоит учитывать различия в функциональности документооборота, которые обусловлены тем или иным способом хранения файлов (скорее всего, это не полный список):
- При хранении файлов в БД файлы всегда передаются по сети. Если же файлы хранить на файловом сервере, то на удаленных инсталляциях есть возможность организации локальных файловых хранилищ для определенных видов файлов с доступом в рамках высокоскоростных локальных каналов.
- Мне пока на тестовой базе не удалось воспроизвести стабильную работу в режиме открыл файл, отредактировал, сохранил при работе с сохранением файлов в БД (я продолжу исследование данного вопроса и отпишу через некоторое время). Процесс сохранения измененных файлов при работе с файлами, которые хранятся в БД, не тривиален. В случае же если файлы хранятся на файловом сервере, то таких проблем не возникает. Если же файлы просто класть в БД... ну т.е. поправил — сохранил уже новую версию, то БД будет пухнуть. Хотя вариант имеет некотрые плюсы (версионность изменения файла хранится).
- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Цитата:

Сообщение от twilight

...
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?
...

А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?

Или что вы имеете в виду?

В общем, думайте сами, решайте сами, как говорилось... по-моему, в песне какой-то.

_____________
* Здесь и далее я буду оперировать терминологией и функциональными возможностями MS SQL. Просто я с ним работаю и в определенной степени его знаю. С Oracle я же наоборот практически не знаком. Однако я склонен считать, что все, что я написал, одинаково справедливо и для Oracle. Возможно, эксперты Oracle меня поправят, если это не так.

[ivas]

Цитата:

Сообщение от glibs

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

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

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

[blokva]

Цитата:

Сообщение от ivas

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

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

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

зы: ИМХО glibs именно это и имел ввиду.

[ivas]

Цитата:

Сообщение от blokva

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

зы: ИМХО glibs именно это и имел ввиду.

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

[aidsua]

Цитата:

Сообщение от glibs

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

Любой чайник спокойно видит невидимые каталоги C$, D$, Admin$.. Более продвинутые пользуют для подобных целей Far Manager или что-то подобное..

Оптимальный вариант закрыть доступ на уровне домена к ресурсам.. имхо.

[kashperuk]

Sorry за офф-топик:

Цитата:

Сообщение от ivas

aLL woRk aNd nO JoY MAKes jAck a dULL Boy

Насколько я знаю, должно быть
aLL woRk aNd nO PLAY MAKes jAck a dULL Boy

[ivas]

Цитата:

Сообщение от kashperuk

Sorry за офф-топик:

Насколько я знаю, должно быть
aLL woRk aNd nO PLAY MAKes jAck a dULL Boy

мне первый вариант больше нравиться

[glibs]

2 ivas

И "модифицировал-сохранил-все вернулось в хранилище" тоже будет работать?

[KiselevSA]

На папку устанавливаем права для всех пользователей на Create и Modify (особые права для определенных групп назначаем сразу), для Owner устанавливаем все права. Мне кажется, такая схема должна работать. Только не давайте права на чтение на директорию, иначе все буду видеть список и смогут читать "чужие" файлы.

[ivas]

Цитата:

Сообщение от KiselevSA

На папку устанавливаем права для всех пользователей на Create и Modify (особые права для определенных групп назначаем сразу), для Owner устанавливаем все права. Мне кажется, такая схема должна работать. Только не давайте права на чтение на директорию, иначе все буду видеть список и смогут читать "чужие" файлы.

тоже не вариант пользователь генерит батник вида:
copy \\server\doc\doc00001.doc c:\doc\doc00001.doc
copy \\server\doc\doc00002.doc c:\doc\doc00002.doc
...
copy \\server\doc\doc99999.doc c:\doc\doc99999.doc

и все содержимое у него в кармане

[twilight]

Цитата:

Сообщение от ivas

тоже не вариант пользователь генерит батник вида:
copy \\server\doc\doc00001.doc c:\doc\doc00001.doc
copy \\server\doc\doc00002.doc c:\doc\doc00002.doc
...
copy \\server\doc\doc99999.doc c:\doc\doc99999.doc

и все содержимое у него в кармане

умные у вас пользователи, если они батники умеют писать

[ivas]

Цитата:

Сообщение от twilight

умные у вас пользователи, если они батники умеют писать

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

[KiselevSA]

Цитата:

Сообщение от ivas

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

Админы могут и не иметь права на файлы (только не убейте права у Backup Operators). А вот аудит изменения владельца файла для изменения прав на файл администраторами домена лучше на такую папку включить

[KiselevSA]

Цитата:

Сообщение от ivas

тоже не вариант пользователь генерит батник вида:
copy \\server\doc\doc00001.doc c:\doc\doc00001.doc
copy \\server\doc\doc00002.doc c:\doc\doc00002.doc
...
copy \\server\doc\doc99999.doc c:\doc\doc99999.doc

и все содержимое у него в кармане

А как он сможет скопировать то, на что у него нет прав на чтение?