Разграничение полномочий пользователя

Разграничение полномочий пользователей;

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

Каждый элемент Аijв матрице установления полномочий определяет права доступа i-го пользователя к j-му элементу данных. Типичный пример такой матрицы табл. 1, где определенным терминалам пользователей разрешается доступ к определенным элементам данных. Здесь «01» означает право ЧИТАТЬ и «10» — право ЗАПИСАТЬ; «00» в i-й строке и j-м столбце означает, что терминалу из i-й строки запрещены все виды доступа к элементу данных, описанному в j-м столбце, и «11» означает, что с терминала можно как читать, так и записывать элемент данных.

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

Дополнительно к правам ЧТЕНИЕ и ЗАПИСЬ существуют и другие общие типы прав:

 ИСПОЛНЕНИЕ (исполнить процедуру, когда элементом информации является процедура);

 УДАЛЕНИЕ (удалить элемент информации из информационной базы или данных);

 ПРИСОЕДИНЕНИЕ (добавить что-либо к концу элемента информации без изменения его первоначального содержания).

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

Приведём несколько примеров:

1) решение о доступе зависит от предыстории. Пользователь Аможет записывать данные в файл F только в том случае, если он не читал файл G;

2) решение о доступе основывается на динамическом состоянии системы. Пользователь Вможет открыть файл H только в то время, когда информационная база или данных, в которой размещен файл, находится в открытом состоянии;

3) решение о доступе основывается на текущем содержании информации. Данному пользователю может быть не разрешено читать поле зарплаты, величина которой превышает 20 000 долларов;

Таблица 1. Матрица установления полномочий

4) решение о доступе основывается на значении определенных внутрисистемных переменных. Доступ может быть осуществлен пользователями данной группы только в определенное время с 7 до 19 ч, исключая работу со специального терминала.

При необходимости эти процедуры можно сделать взаимодействующими.

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

Таблица 2. Таблица кодов паролей

Предложенные формы таблиц могут быть усовершенствованы или изменены в конкретной информационной системе.

В реальных ситуациях обработки данных число строк матрицы полномочий может быть весьма значительным, а число элементов данных чрезвычайно большим. Матрица установления полномочий обычно может быть сжата до приемлемых размеров путем использования некоторых или всех следующих методов:

Рис. 1. Алгоритм контроля и управления разграничением доступа

к информации: УНДЛ — условный номер должностного лица; КП — ключ-пароль; ТКП — таблица КП; АРМ СБ — АРМ службы безопасности

1) установление групп «виртуальных» пользователей, каждая из которых представляет собой группу пользователей («клик») с идентичными полномочиями с точки зрения безопасности;

2) установление, групп «виртуальных» терминалов — в действительности распределение терминалов по классам;

3) группировка элементов данных в некоторое число категорий с точки зрения безопасности данных.

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

Рис. 2. Автоматическая модификация запроса

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

Спецификации безопасности S(R), связанные с запросом R, вводятся в запрос в форме нового запроса N= R ^ S(R).Запрос Nявляется тем запросом, с которым работает информационная система или база данных.

В качестве примера допустим, что сотрудник бухгалтерии С1 имеет право на доступ к данным о заработной плате всех служащих, кроме сотрудников бухгалтерии. Если он представит запрос: НАЙТИ ПОЛЕ ЗАРПЛАТА ДЛЯ ВСЕХ ЗАПИСЕЙ С (ИМЯ = АНДРЕЙ), то запрос будет автоматически изменен на: НАЙТИ ПОЛЕ ЗАРПЛАТА ДЛЯ ВСЕХ ЗАПИСЕЙ С (ИМЯ = АНДРЕЙ) И (ПОДРАЗДЕЛЕНИЕ ≠БУХГАЛТЕРИЯ). В результате будут найдены только заработные платы Андреев, работающих во всех подразделениях, кроме бухгалтерии.

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

 деление информации в соответствии с требованиями по разграничению доступа;

 размещение элементов информации в разделенных областях оперативной и долговременной памяти в соответствии с заданным разграничением доступа;

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

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

Кроме перечисленных, в компьютер добавляются аппаратные и программные средства изоляции пользователей друг от друга и от операционной системы. Эти средства осуществляют эффективный контроль каждой выборки или посылки на хранение, которые пытается сделать компьютер. Для этой цели на аппаратном уровне используются специальные регистры границ памяти, замки памяти и ключи, сегментация, дескрипторы, «кольца» изоляции и другие методы. На программном уровне используются создание мониторов виртуальной машины, мандатные системы, системы со списками допуска к информации и т. п. методы.

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

Управление правами доступа в корпоративных web-системах

Информационная инфраструктура многих крупных организаций — это нередко набор слабо связанных между собой островков информационных систем (ИС), созданных в разных подразделениях и филиалах и реализованных на разных платформах. Например, в головном офисе компании функционирует интранет-система, построенная на WebSphere Application Server, в отделе поддержки установлена система управления услугами HP ServiceDesk, система заказов работает на основе php-скриптов и базы данных mySQL, а в филиалах есть свои web-системы на основе Apache, IIS. Знакомая картина, не правда ли? При этом у каждого такого островка свой круг пользователей и собственный набор правил доступа к ресурсам. Разумеется, организации, чтобы обеспечить возможность эффективной работы своих сотрудников с частями общей ИС, размещенными в разных департаментах, необходимо устранить электронные границы между ними.

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

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

В простых случаях, когда набор приложений невелик, задача централизованного управления может решаться при помощи собственных разработок или встроенных в web-серверы либо серверы приложений механизмов. К примеру, хранилища информации о пользователях можно объединить, используя ПО метакаталогов или собственные приложения, в одном центральном мастер-каталоге, после чего web-серверы и серверы приложений (с помощью дополнительных средств) смогут разместить информацию об управлении доступом в том же каталоге. Однако, когда количество приложений увеличивается, а система усложняется, цена реализации такого решения может сравняться со стоимостью переноса систем на новую, унифицированную платформу.

Как это делается

Для решения задач разграничения доступа к различным ИС создан целый класс продуктов — системы управления доступом (Access Management Systems, AMS). Оговоримся сразу, что сфера их применения выходит за рамки web-систем, однако в данной статье мы хотели бы остановиться на возможностях AMS для web-приложений.

Системы управления доступом «абстрагируют» уровень разграничения полномочий пользователей от конкретных систем, позволяя решать поставленные задачи более гибко, четко и просто. Чтобы разобраться, как действуют AMS, рассмотрим архитектуру систем управления доступом (рис. 1).

Информационные базы
Данные о пользователях размещены в хранилище User Store, информация о правах доступа — в Policy Store. Эти хранилища могут быть реализованы в виде каталога LDAP (например, Sun Java Systems Directory Server, IBM Directory Server, Windows Active Directory или Novell eDirectory) либо реляционной базы данных (Oracle, MS SQL). Основной компонент системы управления учетными записями — сервер авторизации Policy Server. Он производит аутентификацию пользователей на основе данных из User Store и авторизацию на основе Policy Store. Модули Policy Server написаны практически для всех платформ: Windows, Linux, Solaris, AIX, HP-UX. Наиболее широко применяются серверы авторизации, построенные на базе продуктов IBM Tivoli Access Manager, Netegrity Siteminder, HP OpenView Select Access, RSA ClearTrust. Рассмотрим механизм их работы на примере Netegrity Siteminder и Tivoli Access Manager, архитектуры которых во многом схожи.

Агенты
Запросы к web-серверу или серверу приложений перехватываются специальной программой-агентом, которая, обращаясь к Policy Server, проверяет, аутентифицирован ли пользователь и имеет ли он право на доступ к данному ресурсу. Если все условия выполнены, агент транслирует запрос на родительский web-сервер или сервер приложений. Такие агенты разработаны для web-серверов Microsoft IIS, Apache, IBM HTTP, iPlanet и серверов приложений IBM WebSphere, BEA WebLogic и Jboss. Если же используется web-сервер, для которого нет WebAgent, запросы перехватываются реверсивным прокси-сервером, разрешения проверяются сервером авторизации и при наличии у пользователя соответствующих прав транслируются на web-сервер.

Механизм поддержки сессий
При первом обращении к ресурсам, защищаемым AMS, происходит аутентификация пользователя. Если она прошла успешно, в память браузера или на диск клиентской станции записывается фрагмент данных с информацией о пользовательской сессии (cookie), после чего cookie предоставляется агентам системы для подтверждения аутентификации пользователя. Разумеется, набор cookie хранится в зашифрованном виде, а ключи шифрования, которые использует Policy Server, помещаются в централизованное хранилище Key Store, также представляющее собой каталог LDAP или базу данных SQL.

Кэширующие модули
При большом объеме запросов на аутентификацию к web-агенту возрастает нагрузка на канал между агентом и Policy Server и на сам сервер авторизации. Поэтому агент может снабжаться кэширующим модулем, в котором содержится информация об установленных сессиях либо части соответствующих хранилищ.

Интеграция хранилищ пользователей
Policy Server может подключаться к любым хранилищам данных о пользователях, поэтому поддерживает аутентификацию в гетерогенной среде с несколькими приложениями, каждое из которых имеет свое хранилище данных о пользователях. Причем каждое приложение сможет «увидеть» пользователей других приложений, т.е. поиск пользователей будет производиться последовательно по всем подключенным хранилищам, что в некоторых случаях позволяет обойтись без ПО метакаталогов.

Усиленная аутентификация
Помимо базовой аутентификации (имя пользователя и пароль) могут применяться HTML-формы, где, кроме имени и пароля, запрашиваются дополнительные атрибуты пользователей, например идентификационный номер сотрудника. Для усиления защиты используются также сертификаты Х.509, токены SecurlD, протоколы шифрования SSL/TLS и устройства, совместимые с PKCS #7. При аутентификации можно присваивать пользователю уровень доступа, точнее, вес схемы аутентификации. Тогда повторная аутентификация потребуется только при обращении к ресурсам с более высоким весом схемы.

Персона и доступ

Существует несколько способов управления доступом пользователей. Самый простой, используемый в большинстве ОС и web-серверов, — это списки доступа. Однако такой способ авторизации не всегда удовлетворяет бизнес-требованиям, поскольку схема «кому и что» не всегда применима. Часто возникает вопрос: кому, когда, откуда и на каких условиях нужно предоставить доступ. В таких случаях в AMS используется ролевой механизм контроля доступа Role Based Access Control List. В нем определяются такие параметры сеанса пользователя, как время доступа, откуда может осуществляться доступ, а также более сложные правила бизнес-логики, реализуемые в прикладных модулях.

Сервисы саморегистрации
Согласно статистике западных аналитических компаний, до 80% запросов в Help Desk поступает от сотрудников, которые не могут войти в систему или хотят сменить пароль. В системы управления доступом могут быть встроены сервисы саморегистрации и смены пароля (хотя обычно эти функции относятся к системам управления учетными записями).

Имперсонификация пользователя
Суть этой важной функции систем управления доступом в том, что администратор или другой привилегированный пользователь может зайти в систему от имени другого пользователя и проверить, есть ли у того доступ к тем или иным приложениям. При этом администратор не должен знать пароль пользователя, от имени которого он входит в систему.

Индивидуальная настройка среды
Особо стоит отметить, что при аутентификации web-сервер или приложение получает довольно много информации о пользователе из записи о нем в LDAP-каталоге или другом хранилище. Данная информация передается агентом серверу приложений для персонализации среды пользователя. Кроме того, в журналах посещений записывается дополнительная информация о пользователях, в том числе о тех, кто не прошел аутентификацию, поскольку в браузер таких пользователей передается cookie с уникальным номером. Впоследствии эти данные используются для анализа работы сервера Business Intelligence.

Самое изящное решение проблемы управления пользователями в гетерогенной среде — то, которое реализовано по схеме однократной регистрации (Single Sign-On, SSO). Множество реализаций SSO можно подразделить на два типа: для сеансов web-приложений (WebSSO), где пользователь вводит пароль при первом обращении к web-приложению, и Desktop SSO, когда пользователь вводит свои данные только при входе в настольную операционную систему.

Однодоменная модель WebSSO
Поскольку для передачи информации об аутентификации при схеме WebSSO (рис. 2) используется механизм cookie, то проблем с аутентификацией внутри одного домена второго уровня (company.com) не возникает.

Для каждого запроса внутри домена выдается cookie с информацией о пользовательской сессии. Однако данный механизм не работает, если AMS обслуживает несколько пространств доменных имен, например companyl.com и company2.com. Механизм cookie в целях безопасности передает ответы агентам внутри доменов второго уровня и выше (рис. 3).

Многодоменная модель WebSSO
Для однократной регистрации между двумя доменами второго уровня применяются механизмы междоменной аутентификации (Cross Domain SSO, CDSSO), которые могут быть реализованы в двух моделях: Push и Pull.

Для передачи аутентификационных данных из одного домена в другой Push использует скрипты, исполняемые агентами и браузером. На HTML-странице программируется специального вида ссылка с параметрами для скриптов перехода. При переходе на данную ссылку в браузере выполняется скрипт, перенаправляющий его на другого агента (одновременно информация об аутентификации между агентами передается через URL специального вида, который пересылается агенту другого домена). Метод прост в реализации, но обладает одним существенным недостатком: для того чтобы «правильно» (без дополнительной аутентификации) попасть в другой домен, пользователь должен «кликать» по ссылке.

В модели Pull один из доменов выделен в сети для аутентификации — он называется Cookie Provider, а набор доменов, защищаемых AMS, носит название e-Community, при этом один или несколько серверов домена Cookie Provider назначаются исполнителями запросов аутентификации из всех остальных доменов. Такой(ие) сервер(ы), естественно, именуется (именуются) главным(и) сервером(ами) аутентификации — Master Authentication Server (MAS), и все запросы на данную процедуру из e-Community будут перенаправляться на MAS (рис. 4). В такой Pull-реализации CDSSO, если агент не получает cookie от браузера, при обращении пользователя к ресурсам для его аутентификации инициируется запрос к MAS. Если в MAS cookie тоже не предоставляется (т.е. пользователь еще не аутентифицирован), то происходит аутентификация пользователя методом аутентификации MAS. После этого в браузер пользователя помещаются cookie от MAS, затем пользователь специальной командой перенаправляется в начальный домен, где ему по представленным параметрам также создается cookie. Все дальнейшие запросы к ресурсам данного домена осуществляются на базе cookie этого домена. Если пользователю нужны ресурсы другого домена, агент целевого домена инициирует переход на MAS, где уже есть cookie, и cookie пользователя создается из целевого домена без повторной аутентификации.

Данный способ заметно сложнее первого в реализации, зато избавляет от «навязанных» переходов. При этом у каждого домена могут быть свои Policy Server и User Store. Между хранилищами пользователей выполняется отображение (mapping) с использованием схем «один к одному», «один ко многим», «многие к одному», «многие ко многим».

В качестве примера реализации Desktop SSO может быть рассмотрена схема, где MAS реализован на агенте для Internet Information Server, а клиенты пользуются браузером Internet Explorer. Тогда при обращении к ресурсам запросы на аутентификацию будут переданы серверу MASTIS, который произведет аутентификацию на основании учетной записи Windows, при помощи механизма SPNEGO, по протоколу Kerberos или NTLM — в зависимости от версии клиентской ОС. Заметим, что существует и схема расширенной регистрации SSO, которой могут пользоваться партнеры и клиенты компании. Здесь применяются федеративные сервисы на базе SAML (Security Assertion Markup Language) — основанного на XML стандарта безопасности (иногда эту схему называют федеративной SSO). SAML дает возможность партнерам обмениваться информацией об аутентификации пользователей по каналам HTTP SSL. Особенность данной реализации в том, что у бизнес-партнера или клиента может отсутствовать система управления доступом. В этом случае необходимо лишь установить SAML-агента, причем необязательно от того же производителя, что и основная AMS. После аутентификации на сайте (SAML-producer) пользователь получает с этого сайта SAML Artifact для доступа к другим сайтам партнеров (SAML-consumer). Механизм федеративной SSO поддерживается Tivoli Access Manager, Netegrity Siteminder и HP OpenView Select Access.

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

Предыдущая новость:
Системы хранения данных десять лет спустя Следующая новость:
Открытые регионы

Принципы защиты информации и разграничение полномочий пользователей

Реализованные в системе LanDocs механизмы защиты информации и разграничения полномочий пользователей позволяют:

· Защитить систему от несанкционированного входа паролем.

· Определить права доступа пользователей к документам различного уровня конфиденциальности.

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

· Персонифицировать право доступа к документу, определив список лиц, имеющих право работы с документом.

· Шифровать (кодировать) конфиденциальные документы (при использовании подсистемы LanDocs: ПОДСИСТЕМА БЕЗОПАСНОСТИ).

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

Дополнительное разграничение полномочий пользователей по доступу к документам реализуется на основании механизма уровней конфиденциальности.

Система обеспечивает Права на файл – список операций с файлами документов, которые регламентированы для каждого файла. На уровне документа задается право – создать файл, т.е. ввести файл в документ. Для файла, уже введенного в документ, могут быть назначены следующие права:

· изменение имени файла;

· изменение статуса файла;

· назначение права на файл;

При использовании подсистемы LanDocs: ПОДСИСТЕМА БЕЗОПАСНОСТИ дополнительно обеспечивается защита целостности документов СЭД РСХН (ревизионная безопасность на программном уровне).

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

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

Дата добавления: 2015-09-07 ; просмотров: 155 . Нарушение авторских прав

Разграничение полномочий пользователей в 1С на уровне записей

В типовых конфигурациях 1С, таких как «1С:Управление торговлей 8», «1С:Комплексная автоматизация 8», «1С:Управление производственным предприятием» реализован механизм позволяющий разграничить права доступа пользователей к справочникам и документам на уровне следующих записей:

  • Организация;
  • Контрагенты;
  • Физические лица;
  • Проекты;
  • Склады;
  • И т.д.

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

В рамках этой статьи мы рассмотрим пример настройки разграничения полномочий к справочнику Контрагенты в конфигурации «1С:Управление торговлей 8.Редакция 11.0».

Кратко опишем ситуацию, в соответствии с которой необходимо выполнить настройку программы: менеджеру по закупкам (стажеру) — Петрову Станиславу Игоревичу необходимо ограничить доступ для работы только с одним поставщиком – ЗАО «Кактус».

Итак, по пунктам:…

1. Первое что необходимо сделать, это разрешить в программе вести учет полномочий на уровне записей: Администрирование -> Настройки пользователей и прав: установить признак «Ограничивать доступ на уровне записей».

2. Далее необходимо включить в программе возможность доступа ко всем функциям:

В окне «Параметры», необходимо поставить флажок «Отображать команду «Все функции»:

3. Далее создаем новую группу доступа «Для стажера» к справочнику «Партнеры». Через пункт меню «Все функции» открываем справочник «Группы доступа партнеров» и добавляем новую группу.

4. Создаем новый элемент в справочнике «Профиль групп доступа» путем копирования уже существующего «Менеджер по закупкам» и корректируем во вновь созданном профиле ограничения по группам партнеров:

5. Создаем новую группу доступа (элемент справочника Группы доступа) и включаем во вновь созданную группу пользователя – стажера.

6. Осталось создать новую группу пользователей «Стажеры» и внести в нее нужного пользователя.

7. Для тестирования правильности выполненных настроек, внесем изменения в группу партнера для ЗАО «Кактус» и проверим доступность справочника «Партнеры» под пользователем из группы Стажер.

Так выглядит справочник «Партнеры», для пользователя из группы «Стажеры».

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

Всем привет!
Создаю базу данных, столкнулся со следующей проблемой:
Как разграничить полномочия пользователей на просмотр информации?

Исходные условия примерно следующие: Имеется 4 БЕ(бизнес единицы), соответственно, с каждой из них будут работать определённые пользователи. Необходимо, чтобы пользователи, которые, например, находятся в первой БЕ видели и могли вводить информацию только по первой БЕ. Так же необходимо, чтобы ряд пользователей мог видеть и изменять информацию по всем БЕ. Какими инструментами Access этого добиться
Система: MS Access 2010

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь.

Разграничение полномочий пользователей на доступ к информации БД
сделал всё как тут описано. но не знаю: как именно ограничить доступ к своим.

Авторизация в приложении и разграничение ролей пользователей
У меня такой задача. Как сделать так чтобы когда ты открываешь от имени Админа.

Разграниченный доступ пользователей
Доброго време суток,Только учусь, строго не судите. делаю раграничение.

Авторизация пользователей раздельный доступ
Дорогие форумчане помогите сделать Авторизацию в БД я сделала кое что, всё.

Доступ нескольких пользователей к Access по сети
Здравствуйте! Нужно написать программу-тестирование студентов. Каким способом.

A97, 2002, 2003, 2007:
сервис -> защита -> мастер

в 2010 не работал, думаю различия не принципиальные)

Необходимо сделать ряд процедур:
1) Создать группы (Admins & Users);
2) Создать пользователей;
3) Изменить собственника проекта;
4) Установить права доступа к объектам;

После создания группы в нее можно добовлять пользователей. Для этого используется метод Add коллекции Users группы. Добовляемые пользователи уже должны существовать в коллекции Users каталога

Елена,
Дело в том, что формы одинаковые, под эти формы созданы таблицы(Вернее наоборот ), а для каждой БЕ создавать свои таблицы и формы это как то неправильно мне кажется

Что касается программирования в ВБ, то скажу честно, я не умею программировать) Нашёл в интернете, что можно через SQL Server разграничить полномочия, но пока не разобрался, как то информации мало по этому поводу, если не разбирусь, то придётся учиться программировать)

могу поделиться примером, нарыл в инете.

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

1. Заходим под паролем разработчика. (Пароль — Developer (при любом логине)).
2. Через менюшку Developer — Изменить доступ к объектам — вводим пароль разработчика.
База закрывается. При новом открытии она открывается с новыми параметрами «Параметры запуска», то есть в «открытом» состоянии.
3. Либо создаем нужные объекты нового приложения, либо импортируем из другой базы.
4. Добавляем(изменяем) в менюшку кнопки, которые нужны в новом приложении. (Открыть форму, отчет, вызвать функцию и т.д. (Пример вызова форм/отчетов можно посмотреть в кнопках менюшки администратора.
5. В запросах — источниках данных форм/отчетов можем использовать функции модуля modCurrentUser для ограничения выборки данных:
funCurrentUserID — возвращает ID текущего пользователя
funCurrentUserAdm — возвращает признак прав администратора текущего пользователя.
Например Администратор видит все записи, пользователь только свои.
6. В модулях форм так-же можно использовать эти функции для отображения/скрытия некоторых элементов управления.
7. По окончании разработки опять «Закрываем файл» паролем разработчика.

Три формы (Авторизация, список пользователей и данные пользователя) я условно «спрятал» префиксом Usys в названии. Чтобы они не мешались при разработке.
Увидеть их можно установив : Меню «Сервис»-«Параметры»-вкладка «Вид» — группа «Отображать» флажок -«Системные объекты» в True.

Смотрите еще:

  • Как получить ходатайство Как написать ходатайство для получения квоты на РВП? Необходимо написать ходатайство от главы факультета в УФМС с целью выделения квоты на РВП иностранной студентке. Как оформить и есть ли шаблон для данного вида ходатайства? 18 […]
  • Заявление от анны седых Обращения граждан Вы имеете право обратиться в судебный участок с запросом (предложение, заявление, жалоба), который будет зарегистрирован и рассмотрен в соответствии с порядком, установленным законодательством Российской […]
  • Расчет пенсии в мо рф Калькулятор военной пенсии с 1 января 2018 года по новой выслуге лет Расчет пенсии военнослужащих отличается от расчета пенсии обычных работников. Но благодаря калькулятору, приведенному ниже, вы сможете без проблем рассчитать свои […]
  • Куда подавать за клевету Как подать в суд за клевету и взыскать моральный ущерб? Добрый день! Меня оклеветали! После увольнения,по собственному желанию,одна сотрудница пустила слухи,якобы я воровала деньги из кассы! Причем, доказательств нет, хотя над кассой […]
  • Фамилии после заключения брака Какие документы и в какой срок необходимо менять после смены фамилии в связи с вступлением в брак? При заключении брака супруги по своему желанию выбирают фамилию одного из них в качестве общей фамилии, либо каждый из супругов […]
  • Авито работа подать заявление АРМАВИРСКАЯ ДОСКА ОБЪЯВЛЕНИЙ Армавирская Доска Объявлений Официальный партнёр Яндекс. Такси. Работа для водителей с автомобилями. Заказы поступают непрерывно. Следующий заказ рядом. Выплаты сразу. Подключение БЕСПЛАТНО, […]
  • Пенсия в крыму в 2014 году ЧТО ВАЖНО ЗНАТЬ О НОВОМ ЗАКОНОПРОЕКТЕ О ПЕНСИЯХ Подписка на новости Письмо для подтверждения подписки отправлено на указанный вами e-mail. 24 мая 2016 В связи с обращениями граждан по поводу получения пенсии в прежнем размере […]
  • Программа преемственность пособия Методические рекомендации к программе "Преемственность". Пособие для педагогов. Федосова Н.А., Белова Т.В. и др. 2-е изд., перераб. - М.: 20 1 5 - 156с. Методические рекомендации к программе «Преемственность» позволяют […]