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

(0) упс - В общем я забацал *

(0) Ну, если есть физический доступ к файлу базы, то ее можно взломать.
Вполне естественно.
По-моему, и SQL-ную можно, только сложнее.

(2) ну в скульной нужно права доступа к склуь серверу еще получить, а в файловой без физического доступа никак.

абидно - включал изменение в базе для того что бы роли добавить свои, а оказывается толку с этого ноль((((

если заморочиться то можно сделать следующее.
Решаем что мы прячем, конфу или данные?
1. Если конфу - то решается поставкой и/или КЗК (не в курсе как там для восьмерки допилили или нет.
Конечно и это расковыривается, но не так просто.
2. Если данные, то можно хранить данные в базе в зашифрованном виде, и расшифровывать их или обрабатывать в закрытом модуле, который можно спрятать в поставку, ну и привязаться к какому-либо параметру в ПК. (а лучше нескольким, номер проца, видюхи, ЖД и т.д.)

По интрнету ходили обработки которые могли удалять пользователя из базы

(5) поставка же не убирает тексты, максимум где можно спрятать это dll

и к тому же клиентские модули не могут быть без поставки (программа не даст)

(5) в данных вопрос , конфу прятать мне не надо - с типовыми работаю, а вот данные - за которые переживает каждый ларечник будто там все секреты мира - это пичалька

http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=611345

(9) тока вчера старым семерошным клиентам рассказывал что в7ке нет никакой защиты, а вот 8ка Вещь(((((

(10) все модули, которые исполняются на тонком клиенте не могут поставляться без исходников
то что выполняется на обычном клиенте/сервере отлично прячется в поставку.

(9) А что с данными. распечатала, сфотографировал, отправил по почте (благо в типовых уже есть встроенный почтовый клиент, и у админов обычно разрешен с сервера ходить 1С в инет)

если речь идет о свистнуть базу, тоже практически всё готово в типовых. Теже обработки типа универсальный обмен в формате xml

вообщем 1С постаралась по максимум облегчить утечку информации

(14) ну тут больше уже проблема одминов а не 1С.

(13) ну с данными тут больше интересует не их "утечка" а их неизменность. дабы гарантировать что пользователь не сможет влезть под полными правами в какой нибудь док и откорректировать нужные ему данные

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

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


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


плюс вон в БП еще не смотрел, заполняем книгу покупок под пользователем с правами главбуха, в результате

{ОбщийМодуль.УчетНДС.Модуль(3243)}: Ошибка при вызове метода контекста (Выполнить)
    ТаблицаДокументов = Запрос.Выполнить().Выгрузить();
по причине:
Ошибка выполнения запроса
по причине:
У пользователя недостаточно прав на исполнение операции над базой данных.