Вопрос.. как ограничить доступ пользователя к файловой базе 1С 7.. ??? Какие есть механизмы? Ведь для нормальной работы программы у пользователя есть доступ к каталогу ИБ 1С на чтение и запись??
|
Вопрос.. как ограничить доступ пользователя к файловой базе 1С 7.. ??? Какие есть механизмы? Ведь для нормальной работы программы у пользователя есть доступ к каталогу ИБ 1С на чтение и запись??
отчасти может помочь терминальный доступ ... но (по опыту) если у какого то пользователя есть стойкое желание навредить - его мало что остановит ...
Кратк. - сестр. тал. !
Для начала объясните, от чего именно вы хотите защититься.
от возможного вредительства пользователя(ей)... либо от случайных необдуманных действий (вроде удаления файла, переноса каталога...)
А подробней можно? Как при терминальном доступе не дать права пользователю на чтение и запись в каталог с ИБ?? и при этом чтобы программа в среде этого пользователя запускалась и работала...
В терминальном такое не возможно, но возможно, если базу разместить на самба сервере (Linux) и настроить невидимость файлов в каталоге базы.
Тогда их 1с будет видеть, а пользователи нет
А вообще лучше ставьте SQL
Hoc est vivere bis,vita posse priore frui!
Нет, в файловом варианте ничего не поможет. Конечно, абсолютно согласен с Mulder_1, что терминальный доступ много лучше, чем работа с БД по сети, но это до поры. Есть админы, которые для обычных пользователей ( а в этом смысле себя считаю обычным) могут создать определенные трудности. Они как то убирают пользователю рабочий стол и как-то особенно настраивают доступы. Но вот я не мог особо никуда добраться, а пришел молодой парень и буквально через 20 минут уже слил БД себе на локальный комп. И готов был показать, как он может переименовать папку userdef Вот так... Чтоб не могли навредить - надо SQL
no comments...
В 7.7 защита символическая
SQL также не спасет т.к. пароль к SQL базе вскрывается ну очень просто.
Переходите на новую версию 1С.
Это не панацея, но безопасность все-таки лучше.
Последний раз редактировалось nvk; 24.01.2011 в 21:10.
Да, и любая программа которая просматривает шары в сети думаю не сможет не заметиь комп с самбой на борту... либо просто при открытии 1С посмотреть путь к базе данных и попробовать проследовать по этому пути... думаю это не вариант защиты... может есть еще какие мысли???
не совсем, вы плохо знаете самбу. Сетевой поиск, просмотр сетевого каталога в этом варианте не доступен. Маленькое отличие самбовского протокола от windows
Пользователь заходит и видит пустой каталог, а 1С, при указании полного пути и имени файла его получает. Но, если у вас сейчас по сети плохо работает 1с, то самба для вас явно не панацея, сначала наладьте работу 1С.К тому же, как уже было сказано выше, такой вариант требует определенных знаний от админа, обслуживающего сервер. Однако, как показывает практика, линукс при правильной настройке в поддержке нуждается меньше, чем windows
Вообще можете почитать тут что это такое и с чем едять http://www.samba.org/samba/docs/using_samba/ch08.html
опция "dont descend"
Hoc est vivere bis,vita posse priore frui!
Самый простой вариант: перенести 1с на терминал и ежедневный дамп базы на скрытый винт, с сохранением истории дампа ну хотя бы за месяц.
На клиент службы терминалов жестко задается программа для запуска на сервере (в данном случае 1C). А в 1С Файл-открыть... и получаем доступ к файлам и дискам сервера. Учитывая, что имеем сетевой вход через службу терминалов, значит и сервер по сети доступен, слить файлы с сервера уже не проблема. Хотя есть конечно гуру админства....
Вариантов слить базу даже без доступа к дискам масса - к примеру через почтовый клиент, встроенный в платформу - указать во вложении путь к файлу CD текущей базы 1С при работе не блокирует его ни на запись, ни на чтение
Или открыть конфигуратор(его можно открыть к примеру вызвав ошибку в конфигурации) и написать простенький клиент ftp клиент и спокойно слить базу.
Безопасность 1С баз в файловом режиме никогда не была на высоте, правда они и для этого и не планировались
Hoc est vivere bis,vita posse priore frui!
На практике были такие глюки, что пользователь некорректно завершил терминальную сессию и на следующий день при запуске терминала он спокойно попадает на рабочий стол сервера. До конца эту историю так и не отследил. Есть еще компонента которая умеет блокировать пункты меню типа "Открыть ,сохранить,печать". Но все варианты предугадать невозможно. Ты же калькулятор не закроешь, а в нем есть дыра. Советую закрыть основные дыры и отключить паранойю. Если б я был конкурентом то подкупал бы программиста , а не каких-то второстепенных сотрудников.
В 2008 сервере, есть такая приблуда (что то там).rdp - удаленный вызов приложения, с помощью этой приблуды даже удаленный раб. стол не вызывается, но доступ к локальным дискам сервера естественно есть.
Что-то мы совсем отклонились от темы, насколько я понял, основная задача все-таки не дать убить базу, а не запрет на копирование базы. Мое вмнение, бэкап базы наимение трудоемкий процесс.
топик-стартер пишет: "от возможного вредительства пользователя(ей)... либо от случайных необдуманных действий (вроде удаления файла, переноса каталога...)" . Т.е, я так понимаю, он хочет защититься не только от разгильдяя, но от негодяя. Если так - то и бэкап ничего не сможет исправить в нашем случае. То, что получить доступ к файлам он сможет - уже обсудили. Мы делаем частый бэкап? Ок. Но он, получив доступ к файлам не станет убивать файл 1cv77.md. Это сразу остановит работу и эффекта он не получит. Он удалит или, еще сильнее, - переименует индексный файл cmd . И какое-то время мы будем "делать кашу" . А бэкап ее будет архивировать... По-моему вопрос раскрыт до конца - никак защитить файловый вариaнт 1С нельзя. IMHO
no comments...
Бэкап делается не в один и тот же файл, а с сохранением истории, хотя бы за месяц, т.е. ежедневно делается архив но с новым именем файла. В результате всегда можем откатить до работоспособного состояния.
А с cmd еще надо попасть на тот файл, который в данный момент не используется. При открытой таблице удалить/переименовать cmd не получиться.
Социальные закладки