Доброго времени суток. Хочу задать вопрос о защите файлов ert от открытия или изменения. 

Для нормальной работы компании требуется чтобы пользователи (продавцы) не могли запустить часть обработок. Конечно, есть возможность запоролить обработку в конфигруаторе, но есть проги которые этот пароль снимают, а можно и вообще вручную через HEX редактор. Также можно использовать всякие проверки пороля в самом коде, но это также легко обойти если у юзверя дома установлена 1С и он может на время унести туда обработку. Доступ же к этим обработкам открывает большие возможности для правки базы и соответственно у продавцов мало-мальски шарящих в программировании появляется возможность быть нечестными, чем предположительно они  и пользуются. 

Право на открытие только общих внешних отчетов не помогает, поскольку можно записывать в каталог общих отчетов любые другие. Закрывыть доступ на запись в эту папку пользователю нельзя, поскольку отчеты, находящиеся в ней автоматически обновляются на новые версии при каждом запуске 1С и естественно происходит это когда пользователь заходит в компьютер под собой.

Да, еще, объясню зачем скрывать код уже существующих обработок, если можно написать обработку меняющую документы или цены самостоятельно. Конфигурация хитрая и напичкана разными проверками, поэтому не увидев прежде кода, который изменяет документы, пользователь даже обладая навыками программирования в 1С наврядли сможет написать такую обработку. Поэтому очень важно спрятать код в именно существующих файлах *.ert.

Хотел узнать находил ли кто-нибудь эффективный способ защиты обработок для 1С 7.7 от в описанных выше условиях. Буду рад любому совету.

Я тоже пробовал заниматься защитой, но это малоэффективно.

Жаль. Потому что очень нужно. Гении из 1С не увидели такой очевидной необходимости! Или может быть они думали, что в качестве пользователей в конфигурациях предназначеных для ведения торговли будут работать только кристально честные продавцы?   Думаю, нельзя ли использовать что-то вроде запароленного самораспаковывающегося архива, который после распаковки запускал бы эти обработки (они в случае запущеной 1С-ки тогда открываются в ней) и тут же удалял загруженый в 1С файл ert.  Это был бы идеальный вариант, но пока не знаю как это реализовать. Разве что написать прогу которая бы это делала, но думаю ни мое начальство ни другие сотрудники не одобрили бы такое осложнение  работы со служебными обработками.

Ну вот ребята которые продвигают проект 2С, вроде тоже не видят необходимости в защите модулей.   
Да в общем то действительно специалистов использующих 2С наверное не много, хотя проект интересный, и с 1С он совместим.
А с дугой стороны если подумать то человек знающий 1С не будет заказывать написание обработок, а человек не знающий 1С и не догадается как вскрывать, да даже если и вскроет, то проблематично доработать код модуля....
  Хотя все спорно!

Добавлено через 7 минут и 44 секунды
Хотя вот по этому адресу (http://infostart.ru/edu) ребята предлагают защиту, не знаю правда на скольно эффективную. Если есть желение то можешь проверить.

Ну, если продаавцы умеют работать с hex-редактором, то возникает вопрос - почему они продавцы, а не ... скажем программеры.
полагаю, что автор вопроса либо лукавит (что скорее всего), либо акцент нужно ставить не на защиту ert-файлов , а на отслеживание действий ваших продавцов на ваших компах.

larabelle 


 

Дело в том, что написание обработок никто не заказывает. Они уже есть. Вопрос в том как защититься от использования обработок другими людьми. Если в конфигурации есть запрет на ручной неконтролируемый ввод документов, а в служебной обработке этот запрет снимается, то от чего следует защищаться сразу становится ясно. Разбираться в MD-шнике это все же одно, а найти в инете веселую ломалку паролей на обработки и нахимичить - это просто. Преценденты были.


Для восьмой версии. Кстати, на этом сайте есть еще разработка Golden Key  http://infostart.ru/projects/1337/?cp=all   Но для обработок я ее проверял - не запускаются они потом, потому что в переделанном коде потом синтаксические ошибки, да и загрузка внешней компоненты требуется, что не очень удобно.


Про редактор к слову, можно было не придираться   


Поставить перед каждым монитором камеру не получится. Закрыть доступ к файлам тоже, во-первых потому что они обновляются при загрузке 1С продавцом, во вторых потому, что компы эти обслуживаются удаленно и нам с этими файлами приходится работать в сеансе пользователя + доступа только на чтение не достаточно для нормальной работы. По моему вопрос защиты базы 1С и обработок все же стоит достаточно остро, чтобы от него отмахиваться.

а чего тут придираться - если вы - удаленный/неудаленный (неважно) не имеете контроля над машинами в вашей сети (или не в сети)
- я понять этого не могу -
админ (или как он у вас называется) - есть -или нету - понять не могу - почему у вас продавцы  с компами и прогами могут делать все
 - кто - что захочет - 
и даже !!! ert- файлы - используемые компанией - втюхивать свои -

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


камеру ставить не нужно - в смысле не обязательно - нужно профессионально обрабатывать ситуацию -
или не лукавить в вопросе
larabelle

Это сообщение отредактировал(а) larabelle - 22.11.2007, 14:13

larabelle

Ептыть! Вопрос: "Как защитить внешние отчеты от взлома паролей"?
Ответ: "Не лукавь. Вообще забудь про пароли на обработки. Лучше иди поадминь правильно    ". 

  

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

WaldemarL, нету способа защитить вненшние обработки от взлома.
Но есть решение проблемы. Нужно закрыть доступ на использование внешних обработок и встроить всех их в конфу. При этом установить продовцам минимальные права. И 1с запускать на клиентском компе в режиме терминала. Тогда не один продавец не нае**т.

To WaldemarL : Собсно именно эти шаги и означают грамотное администрирование. 

To Zero - по поводу терминалки у меня вопрос. Автор говорил, что право на запись в каталог общих отчетов пользователю (т.е.продавцу) закрывать нельзя.
Мне кажется, что это может послужить лазейкой.

А кто говорил что нужно пользователю что-то закывать в файловой системе? Всё что нужно закрыть, это доступ к ипользованию диспетчера задач и всё. А дальше при входе под определённым пользователем, должна сразу запускаться 1с-ка, при выходе из 1с должен завершаться работа в ОС в терминальном режиме юзера. В данном случае пользователь даже не будет знать, что в 1с-ке существуют такие режимы как "конфигуратор" монитор и т.п. разве что только догадываться.  

Я поставил защиту, путем прописания в глобальном модуле некоторых процедур, т.е. пользователи могут запускать ert из одного места, пример (Если Путь<>КаталогИБ()+"ExtForms\" Тогда 
Конт.Форма.Закрыть(); ) у пользователей права стоят на чтения данной папки, т.е. у них нет возможности (вставлять,удалять). Все подробно написано тут   http://infostart.ru/forum/read.php?25,14858,ref=547   . Да и хотело бы от вас узнать какие есть возможности взлома в данном случаи?

Это сообщение отредактировал(а) zork_zotrum - 10.2.2008, 14:13

Приветствую ВСЕХ!!!

Да темка прикольная.

Меня заинтересовала, так как иногда защита нужна.

А вот вопрос такой, если попробовать сделать защиту внешней форме путем прописания в самом модуле, как это сделали "На смену периода проводки документов", там тупо заблокирован период пока не введёшь пароль. 

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

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

Желаю удачи, главное подана идея   

Это сообщение отредактировал(а) Angel_X - 18.2.2008, 17:10

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