Ролевое управление СЭДО

Видео:Практика работы с СЭДО в 1С: ЭЛН, сообщения, запросы, пособия.Скачать

Управление доступом на основе ролей: преимущества, практика, особенности

Здравствуйте, уважаемые посетители портала! Меня зовут Александр Омельченко, я – новый сотрудник компании Cleverics. Буду заниматься проектами по внедрению решений IDM и управлению доступом.

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

Сегодня поговорим о наиболее популярной на сегодняшний день модели предоставления доступа – управление доступом на основе ролей, известной как RBAC (Role Based Access Control).

Управление доступом на основе ролей

Ключевой особенностью ролевой модели является то, что весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль – это набор прав доступа. Пользователи получают доступ только через присвоенные им роли.

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

Универсальную модель ролевого управления доступом впервые предложили Дэвид Феррайоло и Ричард Кун из Национального Института Стандартов и Технологий США (NIST) в 1992 году.

Документ давал определения основным понятиям, их отношениям и зависимостям, и представлял ролевое управление доступом (RBAC – Role Based Access Control) как альтернативу мандатному управлению (MAC – Mandatory Access Control) и избирательному управлению (DAC – Discretionary Access Control) доступом.

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

Преимущества ролевого управления доступом

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

• Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.  
• Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
• При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
• Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.

Особенности

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

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

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

Это может стать серьезной проблемой для системы управления доступом:

• В таком случае трудно определить «разумно малый» набор ролей, которые отвечают за права доступа основной массы пользователей.
• Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.

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

В-третьих, «изменение обязанностей пользователейи реорганизация бизнеса»: даже если ролевая модель отражает текущую ситуацию в организации, ее необходимо поддерживать в актуальном состоянии, отслеживать изменения обязанностей пользователей и оперативно вносить изменения в ролевую модель.

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

Практика применения

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

https://www.youtube.com/watch?v=14s3q2A60mk

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

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

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

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

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

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

Резюмируя, можно сказать следующее — RBAC является полезным решением для некоторых конкретных проблем: управление пользователями в одном каталоге или управление большими группами пользователей с одинаковыми правами.

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

Видео:Управление документами в СЭД «ДЕЛО»Скачать

Обзор систем электронного документооборота

Уважаемые читатели! В связи с тем, что при сборе материала для настоящего исследования была некорректно оценена функциональность представленной в обзоре системы МОТИВ, редакцией по своему усмотрению была произведена корректировка диаграмм для более точного отражения функциональности указанного продукта. В исправленных диаграммах указана функциональность системы МОТИВ версии 1.1, существовавшей на момент отбора участников тестирования (март 2010 года). Возможно, что некоторые параметры других систем также оценены некорректно.

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

В современной организации системы электронного документооборота (СЭД) становятся обязательным элементом ИТ-инфраструктуры.

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

Общепринятой аббревиатурой является СЭД, хотя наравне с ней также используются САД (система автоматизации делопроизводства), СЭДО (система электронного документооборота) и САДО (система автоматизации документооборота).

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

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

Сегодня разработчики СЭД ориентируют свои продукты на работу не только с корреспонденцией и ОРД (организационно-распорядительными документами), но и с различными внутренними документами (договорами, нормативной, справочной и проектной документацией, документами по кадровой деятельности и др.).

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

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

https://www.youtube.com/watch?v=pZraN6Fedvc

Рынок СЭД в последние годы является одним из самых динамично развивающихся сегментов отечественной ИТ-индустрии.

В 2009 году, по данным IDC, на фоне практически 50-процентного сокращения объемов общего рынка программного обеспечения в России, данный сегмент показал высокую устойчивость. Его спад по данным за 2009 год составил не более 20—25%.

В численном выражении объем рынка СЭД на сегодня, по данным CNews Analytics, составляет около 220—250 млн. долл.

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

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

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

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

О разработчиках сэд

Выбирая решения класса СЭД, заказчик рассматривает различные варианты: коробочное решение, решение на базе платформы или заказная разработка.

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

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

Стоит отметить, что ряд поставщиков начали предоставлять СЭД заказчикам в режиме SaaS (Software as a Service), но пока данный подход в силу целого ряда причин (доверие к провайдеру, качество и надежность каналов связи) скорее рассматривается как форма знакомства с возможностями системы, а не как реальный подход к автоматизации документооборота.

Одним из формирующихся трендов является использование для работы с документами систем класса ECM (Enterprise content management). По материалам свободной энциклопедии (Википедии):
Enterprise content management (ECM) — управление информационными ресурсами предприятия или управление корпоративной информацией.

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

И хотя в России спрос на подобные технологии еще находится в стадии формирования, во многих отечественных СЭД уже реализованы различные компоненты ECM: управление документами, управление образами документов, долговременное хранение документов, управление потоками работ (Workflow), коллективная работа с документами.

Принципиально технологии ECM отличаются от СЭД более глубокой проработанностью вопросов управления веб-контентом и мультимедиа-контентом.

Государственные инициативы вокруг «Электронного документа»

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

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

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

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

Стандарты в области СЭД

Сегодня деятельность разработчиков СЭД практически не регулируется.

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

• ГОСТ Р 51141-98. Делопроизводство и архивное дело. Термины и определения (утв. постановлением Госстандарта РФ от 27 февраля 1998 г. № 28);
• Федеральный закон от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи» (в ред. от 08.11.2007);

Видео:Обучение СЭДОСкачать

Система электронного документооборота (СЭД ): что такое, особенности и рекомендации

Еще несколько лет назад о системах электронного документооборота говорили как о светлом будущем. Сегодня они уже активно используются на частных и государственных предприятиях. Но самое главное, что спрос постоянно растет на СЭД. Что такое система электронного документооборота и как она действует, рассмотрим на примере действующих в РФ систем.

Предпосылки

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

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

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

https://www.youtube.com/watch?v=-HNhxuhczec

Возникает дилемма: использовать ли для хранения информации старые бумажные носители или СЭД. Что такое важное можно получить благодаря электронной системе? Повысить эффективность деятельности организации.

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

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

Чтобы оценить эффективность, которую предоставляет программа СЭД, нужно просчитать затраты рабочего времени на оформление бумажной документации. По оценкам консалтинговых компаний, такие операции занимают 20 % рабочего времени. В системе российской бюрократии на это уходит и того больше — 60 % времени. Внедрение СЭД позволит снизить эти затраты минимум в 10 раз.

Делопроизводство и документооборот

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

Документ является единицей хранения информации в СЭД.

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

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

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

Программа документооборота предназначена для решения таких задач:

• систематизации работы с документами.
• созданию документов по шаблонам, их регистрации хранение;
• автоматизации учёта;
• классификации документов.

Рассмотрим детальнее функции СЭД. Программа документооборота используется для:

• создания карточек.
• формирования текста документа;
• сохранения данных в формате pdf или ms word;
• управления правами доступа пользователей;
• создание маршрутов;
• управления движением документов;
• рассылки уведомлений, напоминаний;
• ведения журналов, справочников, классификаторов;
• формирования поручений;
• поиска и подписание документов;
• формирования отчётов.

К общесистемным функциям можно отнести:

• удалённую работу с документами;
• использование СУБД для хранения данных;
• одновременную работу с СЭД;
• обеспечение безопасности через сертификаты, штрих-коды и персонализацию.

Преимущества и недостатки

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

• централизованное структурированное хранение информации;
• одинаковый подход к формированию и обработке документов;
• использование шаблонов;
• поиск;
• аудит доступа.

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

Процессы обработки документов

В СЭД электронный документооборот проходит через ряд этапов, в процессе которых документу присваиваются определенные свойства. Обработка осуществляется как вручную, так и автоматически. Во втором случае задаются:

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

Виды обработок:

• Создание документа.
• Редактирование.
• Переименование.
• Перемещение.
• Сохранение.
• Индексирование.
• Удаление.

Расходы на СЭД

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

Внедрение СЭД

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

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

Ошибки внедрения

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

За выполнение двойной работы никто не доплачивает. Нужно выстроить процессы автоматизации без дублирования. Вторая ошибка — неподготовленность кадров. Чаще всего новые процессы воспринимаются в штыки.

Поэтому нужно объяснить сотрудникам, зачем вообще внедряется СЭД, чтобы они осознанно подошли к процессу обучения.

Технологии хранения документов

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

Иногда документ создается по шаблону, иногда – путем перенесения данных из базы. Атрибуты хранятся в таблицах. Сам файл помещается в папку хранилища, информация из него — в каталог СУБД.

Доступ к данным получают только пользователи системы СЭД.

Что такое поточное сканирование?

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

Оптическое распознавание текстов

Эта система электронного документооборота СЭД преобразует электронный образ документа в формате фотографии или jpeg в текстовый формат.

При этом используется специальное ПО в виде самостоятельного приложения или интегрированной ESCOM.BPM в СЭД. Что такое ESCOM.BPM? Это программа по распознаванию документов, набранных разными шрифтами.

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

Штрих-кодирование

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

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

Он клеится на бумажный вариант документа.

ЭЦП

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

Последний представляет собой файл в специальном формате, который регенерируется в центре выдачи лицензии. Для обеспечения сохранности информации следует хранить сертификат на смарт-карте или ключах I-Token. Они защищены PIN-кодом.

Если PIN несколько раз будет введён неправильно, то сертификат автоматически заблокируется.

Полнотекстовой и атрибутный поиск

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

При этом система сравнивает введенные критерии с данными в карточках и заносит в результат те карточки, по которым прошли совпадения. Поиск осуществляется с учётом точного или частичного совпадения.

Полнотекстовый поиск осуществляется по данным в самом документе, в том числе по словоформам через встроенные средства СУБД, такие как MS SQL SERVER, ORACLE. Для полноценного поиска файлы должны быть занесены в базу в формате документа (doc), таблицы (xls), презентаций, сообщения.

Видео:СЭДО с ФСС. Использование в программе 1С:ЗУПСкачать

Приложения в СЭД. Часть 3: Контекстно-ролевая модель документа, права и оптимальный интерфейс для работы с документами

Важное отличие приложений СЭД от других привычных пользователю приложений (например, ERP-систем) в том, что документ СЭД – это объект с очень сложным и длительным жизненным циклом.

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

Естественно, логика его обработки и права доступа к данным документа зависят от этапа его обработки. Но это еще не самое сложное.

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

Вот пример такого сложного правила, определяющего право вносить изменение в содержимое договора:

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

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

Нужно сказать, что традиционное понятие «роли» — например, роль в операционной системе и роль в контекстно-ролевой модели — отличается.

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

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

Настройка ролевой модели включает в себя три шага:

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

(О конструкторе карточек и состояний Docsvision смотри тут habrahabr.ru/company/docsvision/blog/263263).

Настройка ролей для вида документа производится в интерфейсе «конструктора ролей» Рисунок 1. Конструктор ролей позволяет параметрически описывать контексты использования тех или иных объектов приложения на базе платформы Docsvision.

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

Конструктор ролей позволяет описать множество ролей (контекстов использования) для того или иного вида документа. Каждая роль – это набор условий, объединённых в комбинации по и/или. Каждое условие — это логическое выражение (параметр–операция–значение), которое проверяется на истинность, при обращении к конкретному экземпляру документа.

Производится проверка актуальности всех ролей для текущего контекста (пользователь — экземпляр документа), настроенного для данного вида документа. В случае если все (И) или одно (ИЛИ) выражение истинно, данная роль актуализируется в текущем контексте.

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

По сути дела, сегодня в системе существуют 3 типа параметров: • Параметры, которые определяют контекст текущего пользователя. Самый простой пример – я = значение поля документа, текущий пользователь указан в каком-то поле документа. Существуют и более сложные условия, например, текущий пользователь – временный заместитель пользователя, указанного в поле карточки. Можно также в качестве значения выбирать не поле текущего документа, а поле документа (или другого объекта), связанного с текущим. Например, можно проверить условие: я являюсь временным заместителем пользователя, указанного в поле исполнитель задания, назначенного на данный документ. • Параметры, связанные со временем. Условия можно связывать с текущей датой и с текущим временем, например, проверить, рабочее ли сейчас время, и запретить доступ к документу вне рабочего времени, или ограничить доступность документа календарным годом. • Параметры, связанные с данными текущего документа. При открытии документа можно проверить, соответствует ли значение поля документа или связанного с ним объекта определенным условиям. Например, в зависимости от суммы договора можно дать права на его редактирование только пользователям определенной группы. Как и при создании любого визуального конструктора, мы столкнулись с тем, что всех ситуаций из реальной жизни предусмотреть не получается. Поэтому дали возможность создать произвольное условие, подключив в качестве условия низкоуровневый код. Использовать этот механизм мы рекомендуем только опытным разработчикам, так как выполнение операций расчета ролевой модели может очень существенно повлиять на скорость работы решения. Особенно это касается расчета прав доступа к документам при выводе табличных представлений с большим количеством документов, например, журнала входящих документов за текущий год.

Определение операций обработки документа и данных, доступных для данной роли

Второй этап настройки контекстно-ролевой модели заключается в определении доступности тех или иных данных или операций для настроенных ролей. Рисунок 2. Конструктор ролей позволяет предоставить права выполнения тех или иных операций и редактирования данных для различных ролей.

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

операция «Вернуть на подготовку» для входящего документа доступна регистратору в состоянии «Зарегистрирован» и недоступна в состоянии «Подготовка» и «В архиве». Настройки безопасности ролевой модели работают на базе сервера приложений Docsvision.

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

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

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

Конструктор карточек позволяет связать тот или иной интерфейс документа с состоянием и ролью с помощью «дерева дизайнов».

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

https://www.youtube.com/watch?v=6azZqy-_7nQ

В следующем эпизоде этой серии статей я напишу о разработке справочников в СЭД, а затем о разработке бизнес-процессов, подсистеме навигации и поиска, подсистеме представлений и отчётов.

Видео:Обучение по работе с СЭД DirectumСкачать

Ролевая модель доступа. Инвентаризация прав доступа

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

Любые избыточные права доступа сотрудников ведут к увеличению риска утечки информации.

В статье рассказывается о ролевой модели прав доступа, процессе инвентаризации выданных прав доступа и выявлении несоответствий на примере системы управления и контроля доступа «КУБ».

1. Введение

2. Инвентаризация прав доступа

3. Типовой доступ

4. Ролевая модель

5. Индивидуальный доступ

6. Сертификация доступа

7. Работа с несоответствиями

8. Заключение

Введение

Рост компании = ужесточение контроля

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

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

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

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

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

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

Происходит ужесточение политики ИБ, так как увеличиваются риски утечки информации.

Одним из первых этапов по упорядочиванию процесса выдачи прав к информационным системам – ввод системы согласования заявок.

Рисунок 1. Ввод системы согласования заявок

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

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

Инвентаризация прав доступа

Давайте остановимся подробнее на последних операциях.

Представьте, что нужно узнать, к каким ресурсам имеет доступ сотрудник, работающий в организации пять лет. Сколько это займет времени? 15-20 минут? А если необходимо провести проверку 50 сотрудников?

Информационные системы:

• Active Directory
• Файловые ресурсы
• ERP-системы (1С, SAP, IBM, Microsoft)
• CRM (Microsoft, IBM, amoCRM, SugarCRM)
• СЭД (БОСС-референт, IBM lotus, Directum)

Рисунок 2. Типовой доступ сотрудника к информационным системам предприятия

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

https://www.youtube.com/watch?v=WXT7rX-rao4

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

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

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

В таких ситуациях единственная возможность выявить текущие права доступа сотрудников – проведение оперативной или плановой инвентаризации.

Рисунок 3. Пример отчета «Инвентаризация прав доступа», предоставляемый системой управления и контроля доступа «КУБ»

Наиболее оптимальным решением проблемы инвентаризации существующих прав доступа – использование ролевой модели и типового доступа. Давайте рассмотрим подробнее эти понятия.

Типовой доступ

Типовой доступ – это использование шаблонных групп, профилей, ролей в информационных системах для предоставления доступа. Например, в 1С 8.2 – использование профиля «Менеджер», который включает в себя определенный набор элементарных ролей и прав доступа к таблицам.

Или управление членством группы в Active Directory «Доступ к папке «Текущие проекты» чтение» для предоставления прав доступа к разделяемому каталогу. Использование шаблонов позволяет сократить время на аудит прав пользователя и формализует процедуру их предоставления.

Рисунок 4. Использование шаблонных групп, ролей и профилей

Ролевая модель

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

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

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

Рисунок 5. Использование шаблонов должностного доступа

Например: создание учетной записи в AD для входа в домен, создание корпоративного почтового ящика, выделения доступа к корпоративной папке отдела на файлообменнике и регистрация в профильной информационной системе с базовыми правами (ERP, CRM, СЭД).

Бизнес-роль

Бизнес-роли включают в себя типовой доступ, который сотрудник запрашивает (либо ему выдается) для выполнения определенных функций – участия в проекте, выполнения поручений руководства, командировка.

Рисунок 6. Использование шаблонов бизнес-ролей

Индивидуальный доступ

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

При применении ролевой модели доступа, количество индивидуальных прав обычно составляет 5-10% от общего количества привилегий.

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

Рисунок 7. Процесс предоставления индивидуальных прав доступа

Сертификация доступа

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

https://www.youtube.com/watch?v=IGGGhpQp0WE

С помощью IDM-системы, например, «КУБ» эту процедуру можно автоматизировать. Руководитель будет периодически получать уведомления со списком индивидуальных привилегий его подчиненных, которые он может продлить на расчетный период или отобрать.

Есть другой вид переаттестации, когда доступ подтверждается не руководителем, а согласующими лицами, которые утверждали первоначальный доступ.

Рисунок 8. Утверждение индивидуальных прав доступа

Работа с несоответствиями

Как правило, в IDM-решении присутствуют механизмы отслеживания, так называемых, несоответствий. Несоответствие – это изменение прав доступа сотрудников, изменение атрибутов ресурсов и информационных систем в обход процедуры согласования и без уведомления сотрудников службы ИБ.

Рисунок 9. Отслеживание несоответствий в правах доступа

IDM-решения производят мониторинг информационных систем на предмет изменения состояний, после чего соотносят эти изменения с заявками, созданными в IDM.

Рисунок 10. Мониторинг изменений доступа в информационных системах

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

Рисунок 11. Несоответствие прав доступа фиксируются системой

Заключение

По статистике около 70% утечек конфиденциальной информации происходит по вине сотрудников организации. Любые меры по противодействию утечкам информации делятся на два типа: превентивные меры и защитные.

Защитные меры – использование:

Превентивные меры – инвентаризация, ресертификация и мониторинг прав доступа сотрудника. Основная задача — обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это позволяет минимизировать риски по утечке информации.

• Контроль существующих прав доступа
• Построение матрицы доступа
• Мониторинг изменений ИС

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

💥 Видео

Электронный документооборот с ФСС: СЭДО и ЭЛН 2.0Скачать

СЭДО с ФСС - практика взаимодействия, поддержка в 1С.Скачать

Настройка сертификатов для взаимодействия с ФСС (для 4-ФСС, ЭЛН, Прямых выплат, СЭДО) в 1С:ЗУП ред.3Скачать

«Управление совещаниями» СЭД «ДЕЛО»Скачать

Установка сертификатов ФСС для работы с СЭДО и 4-ФСС в 2022 годуСкачать

Программы для документооборота: сравнение СЭД 1C Документооборот, Directum, Elma, Битрикс24Скачать

Как работать с проактивными выплатами ФСС(СЭДО) в AO 4.5Скачать

Видеоролик по работе в СЭДСкачать

СЭД ДЕЛО Регистрация документовСкачать

Новый документ СЭДО в ЗУП 3.1 – Исходящее сообщение о страховом случае ФСС (выпуск 30.08.2022)Скачать

Социальный электронный документооборот (СЭДО) СФР в 1ССкачать

Обработка входящего документа в СЭД ТЕЗИС NEWСкачать

Регистрация, контроль исполнения документов в СЭД «ДЕЛО»Скачать

Настройка прав в 1С - права, роли, группы доступаСкачать

СЭДО ФСС в 1С: Бухгалтерия — как быть, если пособие сотруднику не положеноСкачать