Доброго всем времени суток.

У нас на предприятии ведется "собственная" конфигурация, где на данный момент роли находятся в полном беспорядке, хаос и вакханалия.

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

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

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

В чем собственно вопрос? Как правильно проектируются роли в 1С? В гугле и яндексе на запросы по ролям 1С, нашел только сотни запросов "как правильно проставить роли", но мне не это нужно, а именно этап их создания. Т.е. как вы берете их названия, как определяете для какого объекта конфигурации какие объекты?

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

С уважением к вашим знаниям, Дмитрий.

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

(0) Разбить для начала на подсистемы в виде дерева, под них и пилить права

Разделение по ролям это по сути разделение по отделам/управлениям/департаментам.. Зависит от учета который вы в своей базе ведете. Если все из одного отдела то разделение сводится к выдаче суперправ для продвинутых юзеров и простых

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

смотри в стороны типовых УФ.

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

(3) Отделов огромное количество. Большая организация (более 2000 человек), и ладно бы если определенные отделы работали, которым можно просто дать доступ определенный и забыть, но ещё и много "поштучных" людей, которые "захотели" доступ к программе. И которым нужно его предоставить.

Вся проблема ещё и в том, что подсистем 16 штук (это не включая вложенные подсистемы), и делать для каждой подсистемы разделение по ролям - будет практично? Потому что пока что я такой вариант рассматриваю, но думал нормально ли это с "правильной" стороны.

(2) То есть Вы имеете ввиду, что для каждой подсистемы (и её подчиненным) своя роль? И создать какую-то роль, всеоблемлющую (тонкий клиент, только чтение и т.п.), и ими регулировать или только роли для подсистем, жестко настроенные? Я вот тут и начинаю теряться.

(5) Одна роль на один справочник/документ? Ох.... это будет жестко =) там их порядка 200+ получится, и новые объекты добавляются (1 объект раз в неделю-две как минимум), но предложение очень интересное, благодарю. Буду над ним сейчас думать.

Профили пользователей - это справочник, в котором можно проставлять роли, не заходя в конфигуратор, я правильно понял?

(6) если все объекты МД четко разделены по подсистемам, то тут самое правильное - на каждую подстему дать свою роль.
если внутри подсистемы есть однозначное разделение - то и на подподсистемы назначить роли.

кроме того, не забывайте возможности управления видимостью разделов.
Можно 20 аудиторам дать доступ на просмотр всего, но разделы оставить каждому свои.

+ ну и обязательно какая-то внешняя обработка или даже база, в которой вы будете контролировать права доступа пользователей.
Чтобы одним кликом мыши можно было включить новую роль всем 100 пользователям или наоборот, одним кликом отключить пользователя от системы

(6) Если компания большая- то еще большая потребность есть в стандартизации

чота задумался - а почему в 1С нет каких-то групп ролей?

скажем отдел из 10 человек, права у всех одинаковы.
При запуске все выбирают пользователя "Отдел закупок", а в параметрах сеанса идет определение ТекущегоПользователя - по IP, или по имени компьютера или по имени пользователя ОС

Таким образом нет необходимости создавать и сопровождать 100500 пользователей ИБ. Достаточно вести десяток групп ролей

(10) Как это нет, есть - по функциям- профили пользователя
по доступу к данным -группы пользователей

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

(12) Вот если в системе не сидит СБ, то у меня всегда есть вопросы к ее квалификации

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

(14) Тогда не вижу смысла СБ вообще, если за информационную безопасность отвечают Айтишники

(0) Нагрузи созданием проектов ролей службу безопасности.

(12) да ничего плохого. Сейчас система расширяется, все больше и больше пользователей появляется у нас (20-30 в месяц), и какой-то определенной схемы допуска пользователей к нам нет. Есть служебка, но она больше формальная, чем официальная.

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

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

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

(7) То есть, допустим, 40-50 ролей для конфигурации это нормально? Это, так сказать, по фен-шую? =)

(9) Подробнее про стандартизацию, пожалуйста. Регламенты, служебки, вы об этом? Если да, то этот этап отчасти пройден, отчасти сейчас вот его и доделываем. Один из этих этапов - роли и права доступа.

(16) Неплохо бы, но они могут очень сильно как сделать лучше, так и сделать хуже, поэтому лучше пока сами. Своими ручками. =)

-----------------------------------
Вариант 1 (на текущей самописке работает)

"Базовые" - даются все, нужны для входа в 1с без доступа к данным

далее делим по видам учета, например "Торговля, Финансирование, ПЭО, БухУчет", для каждого вида учета делаем 3 обязательных роли (пример для торговли)

"Торговля_Базовые", "Торговля_Администратор", "Торговля_ПросмотрВсе"

далее делим на участки учета
"Торговля_Продажа", "Торговля_Закупки", "Торговля_Склад"...


в результате пользователю даем "Торговля_Продажа" + еще несколько....

-----------------------------------
вариант 2 (я его реализовывал на прошлой работе), реально работает на больших конторах

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

>>>в результате пользователю даем "Торговля_Продажа" + еще несколько....

в результате пользователю даем
"Базовые" +
"Торговля_Базовые" +
"Торговля_Продажа" + еще несколько....

>>То есть, допустим, 40-50 ролей для конфигурации это нормально?

у вас что там,конфигурация для детей?
в зупе 3.0 больше сотни ролей

(20) Ну можно сделать 1 роль с кучей RLS, и уже в регистре индивидуально прописывать куда доступ пользователь имеет.

(0) Самый прозрачный, но не самый простой способ - это использовать СППР или что-то подобное.
С точки зрения СППРа мир устроен как-то так. Конфигурация используется для автоматизации каких-то бизнес процессов. Каждый бизнес процесс состоит из шагов. Шаг процесса с точки зрения ИС - это исполнитель (профиль доступа), выполняющий какую-то функцию ИС. Функция ИС привязаны к подразделениям. Выполнение функции заключается в том, что на вход она получает какие-то объекты данных, что-то с ними делает и на выходе дает другие (или измененные те же самые) объекты данных. Каждый объект данных связан с объектами метаданных. Каждый профиль доступа связан с какими-то ролями в конфигурации.
Соответственно, в итоге всего этого, роли, притороченные к профилю, должны иметь права:
1. на чтение всего, что на входе в функицю, выполняемую профилем
2. на запись всего, что на выходе

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

(17) У тя 2000 челов, а значит что ты не можешь управлять функциями и обязанностями каждого чела в компании- следовательно функции и обязанности должны быть зарегламентированы, аналогично и  с доступом к информации.

Так как сбшники получили сейчас причесать доступ к информации, поэтому они и заинтересовались. Это значит что у вас кто-то думает головой

2000- это что-то типа пенсионного или страхового фонда мне напоминает

В большинстве своем на каждый объект создаем роли на чтение/просмотр, добавление/изменение.
Например, РасходныеНакладныеЧтение,РасходныеНакладныеДобавлениеИзменение.
Почему на каждый объект отдельная роль:
1. Удобно потом собрать это в профиль (набор ролей).
2. RLS на один объект будет отрабатывать не в нескольких ролях, а только в одной, это более оптимально с точки зрения производительности.
3. Это ПРОЗРАЧНО, нежели роль СУПЕРПОЛЬЗОВАТЕЛЬ.

Доступ к отчетам можно объединять, например "Отчеты по товарам на складах", но подчеркну, роль должана давать доступ только к отчету.

(18) это если отдел кадров в курсе, какие у кого обязанности. На больших предприятиях ОК обычно дальше штатки не лезет.

(22) "Функция ИС привязаны к подразделениям" - а если одна и та же функция в разных подразделениях?

(25) странно как-то сообщение добавилось.

система прав доступа в 1С несовершенна.

Если у нас сотня документов, то для полного набора прав доступа надо создать 100(чтение+запись)+100(только чтение)+100(все права) ролей на эти документы.
итого 300 ролей.

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

(26) совершенно не важно кто будет это делать... можно сделать, что ОК выдает права только руководителям, а они внутри своих групп сами рулят кто чего делает...

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

(22) Михалыч, есть ссылки почитать про СППР? Хочу понять "как его готовить" :)

(30) Мертворожденный Айдеф 0, даже не 3-й

хотя.. что-то подумалось.

Если создать РС ПраваПользователей(Пользователь, объект, право доступа)
создать 1 роль на все документы, а в РЛС уже прописывать права доступа к таблице документов на основании регистра и текущегоПользователя

(32) Там придется еще создать и заполнить справочник ТиповыеРоли, где будут шаблоны для заполнения регистра. Иначе взвоешь ;)

+(33) Вообще, 1С группами пользователя пытается с этим бороться.

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

(35) глубоко покласть на грамотность персонала.... не может сам - пусть назначает исполнителя... или читает инструкции...

в конечном случае отсутствие или избыточные права ВНУТРИ ЕГО ОТДЕЛА - это чисто его головная боль...

(36) клевая идея
(35) У меня рядовой персонал себестоимость закрывает в упп без высшего образования,

(36) ну ну, у него все работники еще глупее чем он (именно поэтому он стал "управляющим персоналом" а не они.

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

Со времен 1с 77 все мечтают чтобы настройка прав доступа перенесли с конфигуратора в предприятие.

У меня даже  реализация этого было в 1с77.

К сожалению в 1с8.х все оставили так же. Хотя очень много удобного внесли.
Проектирование ролей больше задача не кодерская а организаторская. Для начала надо чтоб у руководства была четкая картина.
() Распечатай простыню в виде объекты и права и пользователей и отдай руководсву у них тогда возникнет что и как быть с этим.

(37) повезло значит.

(39) с точностью до наоборот, сначала понять кто и что делает, потом простыню под это делатью

(39) Эта простыня - козырный туз, если не хочешь ролями заниматься :)

(41) А если так, как водится, все пользователи - человеки-оркестры?

(42) ну если затупить вопрос хочешь, то да, согласен )) Но автор,вроде как, не этого хочет.

Если СБ так хочет - то пусть сама раздает права пользователям.
напиши 200страничную инструкцию как добавлять роли и назначать их пользователям

Ну если все пользователи у тебя "человеки-оркестры", то весла надо сушить, а не правами рулить, ибо результат твоей работы НОЛЬ. Это все равно, что оркестр из одних дирижеров))))

к (43)

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

Как только это понимаешь - все становится просто и круто... включая наследование от начальника к подчинённому...

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

(48) Дык я это к чему? Если этого порядку нет организационно - откуда он появится в 1С?

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

ну а права - они даются по первому принципу безопасности "Достаточная необходимость"

Коллеги, благодарю за ответы! Дискуссия получается очень интересной =)

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

Сейчас я размышляю как сделать так, чтобы один раз мне потратить много времени на это (даже завести 300+ ролей если потребуется), но чтобы потом более-менее автоматизированно было.

Как я понял из прочтения ваших комментариев - 1С ещё не придумали нормального способа заполнения и проектирования ролей у пользователей. И поэтому все пытаются сделать что-то с этим, с помощью регистров, справочников, обработок и прочего. Но какой способ самый оптимальный? =)

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

(26) ни чему не противоречит
(30) v8.1c.ru или в комплекте поставки
(31) ни чо он не мертворожденный, просто не надо его воспринимать, как ответ на все вопросы вселенной о жизни и смерти и всем остальном. Это просто инструмент проектирования, заточенный онле под 1С. И с разбегу в нем правильно все не сделать - нужен мозг.

На данный момент в системе 98 справочников и 50 документов.  И это далеко не предел.

(52) >Как я понял из прочтения ваших комментариев - 1С ещё не придумали нормального способа заполнения и проектирования ролей
Ты чем-то не тем читал или понял не внимательно. Способ есть, называется "Система проектирования прикладных решений".

(53)v8.1c.ru там не густо,
а комплект поставки надо посмотреть... В любом случае спасибо.

>>> Отделов огромное количество. Большая организация (более 2000 человек)

>>>  это все на службе поддержки и разработчиках (коими я и являюсь в одном лице)


на 2000 человек один одинескник и на него вешают работу по администрированию пользователей? При этом безопасники "важные"  а кадровики могут турнуть тебя за предложение автоматизировать чисто кадровую работу?

ВАЛИ от туда!!!!

Система сия - есть "трудно осилить"
По факту. Возьми роль полные права, а затем от нее скачи к ограничениям. И никак не иначе (от никто во вселителю).

(57)+ при среднем стаже 5 лет у Вас текучка примерно 1 человек в день.... а когда ты уйдешь в отпуск (заболеешь) кто будет вбивать их вместо тебя?

(57) не не не! 2000 человек не работает в нашей конфе! Это организация свыше 2000 человек, но пользователи заводятся со средней активностью. То есть, как уже написал, 20-30 человек в месяц. Вносить их всех легко, это не проблема.

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

Разработчиков нас двое. На поддержке сижу я, и есть ещё один человек, который может меня подменить.

С оргструктурой огромные проблемы, это что есть то есть, но факт остается фактом, исправить ситуацию в 1Се в моих силах (как я пока что думаю =) )

(55) СППР применяется, как я понимаю, больше для "отслеживания" документооборота компании, для урегулирования действий каждого пользователя. Но как эту систему можно применить для проектирования ролей? Не понимаю, чесслово =) В институте проходили диаграммы IDEF0, но сейчас не могу завязать под это. Возможно ли где-то это об этом подробнее прочитать (понятным языком), кроме как тут http://v8.1c.ru/model/?

(57) на данный момент максимальное пребывание пользователей в 1С ~90 человек разом.

В среднем сейчас в конфе сидит до 50-60 человек. Поэтому не переживайте, 60 человек я пока ещё могу победить =D

(61) не парься, до 200-300 пользователей "на круг"  и так справишься, настоящие проблемы потом появятся

(0) Конфа на УФ?

(41)(42) (44) Про простыню я предложил потому что у меня была аналогичная ситуация в 2007 году. Правда на 1с 77 было.
Финдир, Начальник ИТ, СБ начали мне компостировать мозг. Типа давай права доступа четко надо сделать бла бла бла.
И что-то требовали от меня то что сами не знали толком. Я то понимал что они хотели. Это четкую структуру ролей и и права доступа  пользователей к объектам.
Сначала дал картенький список по группам ролей типа. Не
понравилось. Потом подробней тоже не довольны были.
Тогда я взял и распечатал простыню. Размер простыни после склейки было 1 на 2 метра.
Когда они разложили это на большом столе у них пришло некое протрезвение. После этого я им выдал компактное по ролям и все успокоились.

+(63)
Но мне пришлось разработать систему настройки прав доступа в 1С прямо в предприятии. Буквально на двух справочниках.

(0) Если это идея подойдет я могу поделится.

Не вру три справочника...

(63) права нужно выдавать в соответствием с ОБЯЗАНОСТЯМИ !!!

на месте автора я-бы просил давать список действий которые человек ОБЯЗАН выполнять, и на основании этих действий давал-бы права...

нельзя выдать просто право "видеть остатки на складе"

а вот если есть ОБЯЗАНОСТЬ "предоставлять клиенту Х наши складские остатки раз в неделю", тогда и выдаем права...

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

Нельзя давать права по письму безопасника, права нужно давать тогда когда в должностной инструкции безопасника будет написано "контролировать полноту заведение контактов менеджера в 1с"...

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

(60) >СППР применяется, как я понимаю, больше для "отслеживания"
не угадал ни разу. СППР применяется для проектирования прикладных решений И (внимание на это сюда!) для проектирования профилей доступа.

Для того, чтобы решить задачу (0), в любом случае нужно:
1. Бизнес процессы, которые дают взаимосвязь и порядок выполнения функций
2. Должностные инструкции, которые задают соответствие функций и исполнителей

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

(69) должностные инструкции есть, но касательно нашей Конфигурации - не существуют. Ты имеешь в виду создать для каждого отдела должностные инструкции по нашей программе? Что делают, какие права нужны и т.п.?

по первому пункту, можно чуть-чуть поподробнее?

(0) На ИТС раздел Методическая поддержка, конфигуриррование, там есть проектирование ролей. Точно не помню, извини.


P.S. 70 ответов, Ctrl+F, " ИТС", ничего не найдено --> Миста деградирует.

(71) Благодарю! сейчас поищу =)

(71) ссылку приведи, где конкретно на итс есть проектирование ролей

Потому что нету там ни чего по сабжу
только http://its.1c.ru/db/v8std#content:2149184317:1:_top - Разработка ролей в библиотеках

но это мимо кассы

(0) в самописке отдельная роль на каждый чих: ПравоЧтениеДокументаТакогоТо, ПравоПроведениеДокументаТакогоТо и т.д...

(76) это один из двух подходов. Второй - по функциям. На практике для сложных систем всегда используется симбиоз, так как:
1. Чисто функциональный подход возможен только в идеальной стране волшебных эльфов и железных роботов
2. Объектный подход идеален для небольших конфигураций, т.к. он плодит роли в количестве 2*количество_объектов, а на больших конфах проще напиться натурально яду, чем это сопровождать

(76) вопрос в том, как это все реализовать в больших конфах, что бы не зашиться при сопровождении. Вопрос больше организационно-методологический, чем технический.

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

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

Мне так показалось, что внятно распределить роли не может никто, даже фирма 1С, по крайней мере, если судить по той хрени, что творится сейчас с правами в типовой УТ, которой уже далеко не первый год, у меня отчетливое ощущение, что управлять правами в фирме 1С не научились :-(

(77) да, речь в (76) вел именно о небольших конфигурациях - количество документов всегда было не больше 15
А для сложных... как это сделано в ЕРП 2.0 видел, но не очень разбирался, и ждаже желания не возникало

(73) На диске путь такой:

Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8
-- Настройка прав доступа к данным
---- Стандартные роли

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

(65) А какие справочники? Н 1-пользователи, 2- права. А 3-й???

(84) Ну красиво сделал, тут тебе и кто что менял из коробки, и периодичность

(84) можно узнать, как именно вы это сделали? Есть какая нибудь статья где? или что то подобное? :)