| Вопрос: Сертификат. Вопрос о доверенных издателях | Добавлено: 14.06.06 23:43 |
Автор вопроса:  Vilor
|
|
Чтобы не появлялись лишние вопросы к пользователя по поводу включения макросов, содержащихся в книге Excel z создал с помощью cert.exe цифровой сертификат. Подписал им код VBA и проверил: при открытии файла есть возможность добавить издателя "VBACode" в список доверенных. На другом компе даная опция неактивна. Проверил - нужно создавать сертификат именно на том компе, на котором будет открываться файл с макросом, чтобы можно было добавить издателя в список доверенных. :-( ...не подходит...
Вопрос: Как не снижая уровня безопасности ("средний") создать и подписать код в книге Excel цифровым сертификатом, чтобы владельца сертификата можно было один раз при запуске книги добавить к группу оверенных издателей и вопросы по поводу отключения макросов, содержащихся в книге перестали доставать пользователей? |
| Ответы | Всего ответов: 9 |
|
Номер ответа: 1 Автор ответа:  Vilor Вопросов: 5 Ответов: 28 |
Профиль | | #1 | Добавлено: 15.06.06 00:59 |
|
Может быть с помощью selfcert.exe, входящего в состав Office2003 нельзя создать сертификат для подписывания кода, который вызвал бы доверие у пользователя и системы на другом компе?
Или никто не знает как стать доверенным издателем ПО в домашних условиях? |
||
|
Номер ответа: 2 Автор ответа: Незнайка Вопросов: 7 Ответов: 188 |
Профиль | | #2 | Добавлено: 15.06.06 09:53 |
|
перестали доставать пользователей?
1. Можно записать все функции либо в personal.xls 2. А лучше сделать надстройку (xla). В обеих случаях вопросы относительно запуска макросов доставать не будут. |
||
|
Номер ответа: 3 Автор ответа: VilorВопросов: 5 Ответов: 28 |
Профиль | | #3 | Добавлено: 15.06.06 20:12 |
| Возможно у меня мало опыта для сосдания надстроек, но мне кажется что распространять и обновлять приложения гораздо легче, не используя xla надстроек. Сделал рассылку по пользователям с информацией о расположении новой версии приложения, либо заменил файл запуска приложения, на который есть ярлыки у конечных пользователей и не надо бенать устанавливать надстройки. А для использования personal надо сначала добраться до его размещения, что требует прав администратора. А если с приложением работают удаленно или на одном компе работают порядка более 5-х пользователей, и у каждого своя книга personal. | ||
|
Номер ответа: 4 Автор ответа:  НезнайкаВопросов: 7 Ответов: 188 |
Профиль | | #4 | Добавлено: 16.06.06 09:32 |
|
Несогласен со всем.
Надстройки самое лучшее - что ты можешь сделать в твоем варианте. 1. Создай в сети папку куда будут иметь доступ "только чтенике" все пользователи которые работают с приложением. 2. Себе к этой папке естественно полный доступ. 3. Положи в эту папку файл надстроек. В нем должны содержаться все функции тобой написанные и процедура создания меню запуска этих функций (можешь написать для каждого пользователя или для групп пользователей свое меню - проверять будешь по сетевому имени пользователя и если захочешь по сетевому имени компьютера). 4. ОДИН раз рассылаешь пользователям файл .xls со следующим кодом: Sub Установка()
5. Потльзователь на своем компьютере запускает этот файл ЕДИНОЖДЫ.
Dim Надстройка As AddIn, НадстройкаНайдена As Boolean For Each Надстройка In AddIns If Надстройка.Name = "ИмяНадстройки.xla" Then НадстройкаНайдена = True If Надстройка.Installed = False Then Надстройка.Installed = True MsgBox "Надстройка активирована." Exit For End If End If Next Надстройка If НадстройкаНайдена = False Then Set Надстройка = AddIns.Add("ПолныйСетевойПуть\ИмяНадстройки.xla", False) Надстройка.Installed = True MsgBox "Надстройка установлена." End If End Sub 6. Всё. После этого ты можешь дописывать в единственный файл надстройки все функции + раздавать права пользователей на те или иные функции. Запрешать им временно пользоваться файлом - разгонять их когда захочешь - и твоя защита на уровне виндоус - доступа к папкам. Впринципе - ты перекладываешь зашиту файла надстройки от изменений на администраторов сети - что не самое плохое. |
||
|
Номер ответа: 5 Автор ответа: VilorВопросов: 5 Ответов: 28 |
Профиль | | #5 | Добавлено: 16.06.06 21:15 |
|
Спасибо, буду пробовать. Если можно одно уточнение: надстройка "ПолныйСетевойПуть\ИмяНадстройки.xla" при AddIns.Add не копируется на машину пользователя, а лишь подключается к Excel?
И вопрос: + раздавать права пользователей на те или иные функции Я так понимаю, что если надстройка установлена, то все функции могут быть доступны. Разве можно разрешать пользователю пользователям одну функцию разрешать использовать, а другую запрещать????
|
||
|
Номер ответа: 6 Автор ответа: НезнайкаВопросов: 7 Ответов: 188 |
Профиль | | #6 | Добавлено: 17.06.06 17:55 |
|
Set Надстройка = AddIns.Add("ПолныйСетевойПуть\ИмяНадстройки.xla", [B]False[/B] Если False, то копироваться на компьютер пользователя не будет.
 2. Просто делаешь: Sub ИмяФункции()
Соответственно создай маленький .ini файл типа:
If ПроверкаРазрешения("ИмяФункции" = False Then Exit Sub
'код функции End Sub Public Function ПроверкаРазрешения(ByVal ИмяФункции As String) As Boolean 'выполняешь проверку End Function [Права] Менеджер= Аналитик= Бухгалтер= ... А проверяй по сетевым именам машин: Public Declare Function GetComputerName Lib "KERNEL32" Alias "GetComputerNameA" _
...или таким же образом для пользователей
 ByVal lpBuffer As String, nSize As Long) As Long |
||
|
Номер ответа: 7 Автор ответа: VilorВопросов: 5 Ответов: 28 |
Профиль | | #7 | Добавлено: 18.06.06 01:42 |
|
еще раз спасибо...
А у тебя есть опыт организации доступа без использования GetComputerName или GetUserName? Дело в том что на одном компе, используя однй учетную запись, работают несколько пользователей, а уровень доступа у них разный. Я использовал *.xls файл но на старых машинах дополнительное открытие, чтение, фильтр данных пользователей занимает столько времени (конечно, возможно и код не оптимизирован как следует), что решил от этого варианта отказаться. Вариант с *.ini файлом мне кажется стоящим рассмотрения. Но ведь в этом случае, как мне кажется тяжело организовать изменение данных пользователя... Подскажи, может есть API функции для работы с ini файлами? Если есть, то какие? Также рассматриваю как альтернативу вариант организации пользовательской базы на InterBase (но недостаток опыта и времени, постоянные "пинки" от руководства не дают возможности заняться вплотную). Посоветуй, пожалуйста, какими инструментами воспользоваться для организации авторизации пользователей и разграничения доступа к функциям VBA Excel. Пользователей не более 100 человек. Пользовательские даные стандарные: ФИО. пароль, адрес, телефоны, e-mail-ы, пароль, даты рождения. таб.номера, и т.п. И, если у тебя ранее стояли подобные задачи и есть какие-то наработки, то я буду простосчастлив, если ты поможешь мне сэкономить время и вышлешь на мой e-mail |
||
|
Номер ответа: 8 Автор ответа: VilorВопросов: 5 Ответов: 28 |
Профиль | | #8 | Добавлено: 18.06.06 03:02 |
|
Нашел-таки я API функции для работы с *.ini файлами:
GetPrivateProfileSection
И все же, еще раз хочу попросить поделиться наработками по разграничению доступа, выслав на мыло хоть какой-то пример практического использования ini файлов... Раньше никогда с ними не работал и буду долго плутать, пока не нащупаю верное решение, а времени в обрез GetPrivateProfileString WritePrivateProfileSection WritePrivateProfileString .
Получиться ли работать таким образом: '- в одной секции перечислю всех user-oв, чтобы по нему формировать Combox на форме авторизации. [UserName] UsersName_001="Иванов И.И" UsersName_002="Петров И.И" '- в другой - пароли [UsersPwd] UsersPwd_001="ПароЛЬиВаноВа" UsersPwd_002="ПароЛЬпЕТровА" или лучше в одной секии в одной строке перечислять все пользовательские данные вот так: [Users] 'первая строка Иванов И.И.; ПароЛЬиВаноВа; Иванов Иван Иванович; начальник; (918)222-2222; ул. Ивановская 'вторая строка Петров И.И; ПароЛЬпЕТровА; и т.д. 'А в другой секции определять уровни оступа для пользователя вот так: [UsersLevel01] "Иванов И.И." = 1 "Петров И.И." = 3 Подсткажи пожалуйста, как будет легче организавать обработку и не нарвусь ли я вов втором случае на возможно присутствующие органичения на длину строки в ini-файле? ведь число полей разделенных ";" вполне может перевалить за 20. |
||
|
Номер ответа: 9 Автор ответа: НезнайкаВопросов: 7 Ответов: 188 |
Профиль | | #9 | Добавлено: 18.06.06 20:10 |
|
пример практического использования ini файлов... Тут достаточно хорошо расписано как с использованием API работать с .ini http://www.vbnet.ru/articles/showarticle.aspx?id=24 На счет того как огранизавать структуру .ini и ваще по теме:
1. Код на VBA - тайна 1 секунды. Существует множество утилит вскрытия защищенного проекта - прменить не составит труда даже самому неопытному пользователю. Соответственно "защищать" код от "подсматривания" в него бессмымсленно. Другое дело защищать код от изменения - чтобы ты был уверен что в твои функции никто невлезет и "случайно" не исправит. Тут как уже говорилось - защита на уровне виндоус - доступ к директориям - это веьма надежно. 2. Соответственно даже если ты делаешь надстройку - ее можно скопировать - "поламать" - открыть модуль - и убить процедуры проверки любых паролей, соответственно нет смысла возлагать надежду на авторизацию доступа (то бишь шифрование, использование прав с помощью ini, и т.д. и т.п.). 3. Если нужна база данных то она не Excel. Лично я большой сторонник 1С. 4. Большинству и не нужно "ломать" твои процедуры - им нужно ими пользоваться, а тут я советую просто создать текстовый файлик (log) в который писать при помощи VBA: время запуска каким пользователем, с какого компьютера, каких процедур - чтобы тебе можно было смотреть динамику кто чем пользуется. 5. Реально даже если много людей работают за одним компьютером - а на Excel возлагаются хоть какие-то надежды по распределению доступа (что есть криво - но имеет право на жизнь - иначе ваще не писал бы это) - то ВАЖНО ЧТОБЫ ОНИ ИМЕЛИ КАЖДЫЙ СВОЙ ЛОГИН - НЕДОПУСТИМО РАБОТАТЬ ПОД ОДНИМ ЛОГИНОМ. 6. Так что даже если ты напишешь: UsersPwd_001="ПароЛЬиВаноВа" И даже зещифруешь не мудря XOR (с красивыми сдвигами) и в .ini у тебя никогда не будет паролей - а только хеши - все равно "ломать" будут VBA - зачем что-то подбирать.
7. Я лично использую .ini для разделения прав доступа, больше для того чтобы не засорять людям ненужными командами их рабочие панели инструментов. Понимая, что это не защита от тех кому "захочется"... И у меня все пользователи имеют свои логины!!!!! 8. Возможно налил воды - просто хотел поделиться некоторыми соображениями...а ваще ЛУЩШАЯ ЗАЩИТА - это постоянное обновление своей надстройки - ведь она у тебя будет живая - - постоянно появляются новые задачи и ты пишешь и снова дописываешь код ... 9. Вот так. INI у меня огранизован как: [Права] ФункцияДелатьЧтоТО=Иванов/Петров ФункцияДелатьТОТО=Сидоров [СпециальныеПрава] РазрешитьВсе=МоеСетевоеИмя ЗапретитьВсе=ЧерныйСписок 10. Вот так... |
||
Страница: 1 |