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

[ivas]

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

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

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

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

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

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

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

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

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

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

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

[glibs]

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

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

[twilight]

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

[ivas]

Quote:

Originally Posted by glibs

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

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

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

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

[ivas]

Quote:

Originally Posted by twilight

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

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

[twilight]

Quote:

Originally Posted by ivas

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

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

[kashperuk]

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

Quote:

Originally Posted by ivas

aLL woRk aNd nO JoY MAKes jAck a dULL Boy

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

[ivas]

Quote:

Originally Posted by twilight

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

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

[ivas]

Quote:

Originally Posted by kashperuk

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

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

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

[glibs]

Quote:

Originally Posted by twilight

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quote:

Originally Posted by twilight

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

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

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

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

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

[ivas]

решили поступить так:
клиент будет "думать" что работает с БД, а AOS с файлами и передавать их в бинарном виде на клиента

[twilight]

Quote:

Originally Posted by glibs

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

С другой стороны, не нужно заниматься отдельно вопросом резервного копирования документов, они будут бэкапиться вместе со всей базой

Quote:

Originally Posted by glibs

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

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

Quote:

Originally Posted by glibs

- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Да, с совместным доступом тяжело. С другой стороны, он не так уж часто требуется.

Quote:

Originally Posted by glibs

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

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

Под сервером я подразумевал физический сервер. А хранение организовывать средствами СУБД, как вы и описали в своем сообщении.

А насчет производительности - пока не попробуешь, не узнаешь.

[glibs]

2 ivas

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

[glibs]

Quote:

Originally Posted by twilight

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

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

[aidsua]

Quote:

Originally Posted by glibs

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

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

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

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

[KiselevSA]

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

[ivas]

Quote:

Originally Posted by 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]

Quote:

Originally Posted by 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]

Quote:

Originally Posted by twilight

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

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

[KiselevSA]

Quote:

Originally Posted by ivas

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

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