Моделирование системы защиты конфиденциальной информации в медицинском учреждении

- Приказ о назначении ответственного за обработку персональных данных;

- Инструкция ответственному за анализ персональных данных;

- Акт обследования информационной системы персональных данных;

- Описание процессов обработки персональных данных (схемы обработки персональных данных);

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

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

В состав Политики в отношении персональных данных должны входить следующие разделы:

- Общие положения;

- Цели сбора персональных данных пациентов;

- Правовые основания обработки персональных данных;

- Объем и категории обрабатываемых персональных данных, категории субъектов персональных данных;

- Порядок и условия обработки персональных данных пациентов;

- Порядок актуализации, исправления, удаления и уничтожения персональных данных, ответы на запросы субъектов на доступ к персональным данным;

- Перечень мест хранения бумажных персональных данных (под каждую категорию);

- Положение об уничтожении персональных данных на материальных носителях;

- Акт классификации информационной системы персональных данных;

- Положение об обеспечении безопасности персональных данных и подписи соответствующих сотрудников под ним;

- Акт о вводе в действие информационной системы персональных данных;

- Акт о проведении обучения медицинского персонала.

Каждое медицинское учреждение должны опубликовать Политику конфиденциальности на своём личном сайте.

3. Программно - техническая модель средств защиты информации

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

Требования к программно-техническим средствам защиты информации сформулированы в руководящих документах ФСТЭК России от 18 февраля 2013 г. №21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». В данном руководящем документе прописано условия защиты от неправомерного или случайного доступа к конфиденциальным данным пациентов, уничтожение, копирование, распространение, также от иных неправомерных действий в отношении персональных данных.

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

· идентификация и аутентификация субъектов и объектов доступа;

· управление доступом субъектов к объектам доступа;

· ограничение программной среды;

· защита машинных носителей информации, на которых хранятся и обрабатываются персональные данные;

· регистрация событий безопасности;

· антивирусная защита;

· обнаружение (предотвращение) вторжений;

· контроль защищенности персональных данных;

· обеспечение целостности информационной системы и персональных данных;

· обеспечение доступности персональных данных;

· защита среды виртуализации;

· защита технических средств;

· защита информационной системы, ее средств, систем связи и передачи данных;

· выявление инцидентов (одного события или группы событий), которые могут привести к сбоям или нарушению функционирования информационной системы и к возникновению угроз безопасности персональных данных (далее - инциденты), и реагирование на них;

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

Руководствуясь требованиями приказа ФСТЭК России от 18 февраля 2013 г. №21 статья 12 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» технические меры защиты персональных данных реализуются посредством применения средств защиты информации, в том числе программных средств, в которых они реализованы, имеющих необходимые функции безопасности.

При использовании в информационных системах, сертифицированных по требованиям безопасности информации средств защиты информации:

· в информационных системах 1 уровня защищенности персональных данных применяются средства защиты информации не ниже 4 класса, а также средства вычислительной техники не ниже 5 класса;

· в информационных системах 2 уровня защищенности персональных данных применяются средства защиты информации не ниже 5 класса, а также средства вычислительной техники не ниже 5 класса;

· в информационных системах 3 уровня защищенности персональных данных применяются средства защиты информации не ниже 6 класса, а также средства вычислительной техники не ниже 5 класса;

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

Классы защиты определяются в соответствии с нормативными правовыми актами, изданными в соответствии с подпунктом 13.1 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16 августа 2004 г. № 1085.

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

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

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

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

1. Сертифицированная операционная система;

2. Система управления базами данных;

3. Сертифицированное программное обеспечение;

4. Сертифицированный межсетевой экран;

5. Средства антивирусной защиты;

6. Средства обнаружения вторжений;

7. Модуль доверенной загрузки.

Далее рассмотрим сертифицированные средства защиты информации.

В качестве операционной системы можно использовать «Astra Linux Special Edition». Операционная система специального назначения «Astra Linux Special Edition» предназначена для создания на ее основе автоматизированных систем в защищенном исполнении, обрабатывающих информацию до степени секретности «совершенно секретно» включительно. Имеет сертификат ФСТЭК от 27.01.2012 г. № 2557.

Система управления базами данных «Postgres Pro» сертифицирована ФСТЭК России. Сертификат подтверждает, что СУБД «Postgres Pro» может применяться для защиты информации в медицинских информационных системах и автоматизированных системах управления до 1 класса защищенности, а также обеспечения до 1 уровня защищенности персональных данных в информационных системах. Сертификат ФСТЭК России №3637 выдан 05.10.2016 года.

В качестве технологической платформы программного обеспечения будет реализована средствами 1С: Предприятие 8 технологическая платформа 1С: Предприятие, версия 8.3z. комплекта 1С: Медицина. Сертификат ФСТЭК России №3442 выдан 02.09.2015 года. Защищенный программный комплекс "1С: Предприятие, версия 8.3z" может применяться для обеспечения безопасности персональных данных в соответствии составом и содержанием организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных.

Межсетевой экран - это комплекс аппаратных и программных мер, осуществляющих фильтрацию проходящих через него сетевых пакетов. Задачей межсетевого экрана заключается в защите компьютерных сетей от несанкционированного доступа. Например, межсетевой экран Cisco ASA 5585 S40 K8. Имеет сертификат ФСТЭК от 28.09.2012 г. № 2724.

Одним из сертифицированным средством антивирусной защиты, которое можно использовать в медицинских учреждениях, является «Dr. Web Enterprise Security Suite». Сертификат ФСТЭК от 27.01.2016 г. № 3509. Dr.Web полностью соответствует требованиям закона «О персональных данных», предъявляемым к антивирусным продуктам в части централизованной защиты рабочих станций от вредоносных программ, так и от несанкционированного доступа, и может применяться в сетях, соответствующих максимально возможному уровню защищенности, включая сети 1-го уровня защищенности персональных данных.

Средства обнаружения вторжений программный комплекс обнаружения вторжения «Ребус-СОВ». Сертификат ФСТЭК от 28.12.2017 г. № 3856.

Модуль доверенной загрузки, аппаратно-программный модуль доверенной загрузки «Максим - М1». Сертификат ФСТЭК от 12.04.2017 г. № 3732.

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

Контролируемые меры по обеспечению безопасности.

Для рассмотрения и анализа мер по обеспечению защиты персональных данных в медицинских учреждениях была взята система программ 1С: Предприятие 8 технологическая платформа 1С: Предприятие, версия 8.3z. комплекта 1С: Медицина». Гибкость платформы позволяет применять «1С: Предприятие 8» в самых разнообразных областях.

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

«1С: Предприятие 8» контролирует следующие функции:

· Дискреционное разграничение доступа;

· Идентификация и аутентификация;

· Очистка внешней памяти;

· Регистрация;

· Надежное восстановление;

· Периодический контроль за целостностью.

Меры обеспечения информационной безопасности, предусмотренные Приказам ФСТЭК России от 2013 года №21 «Обеспечение безопасности персональных данных».

Диспетчер доступа «1С: Предприятие 8» представляет собой совокупность функций проверки прав пользователей на выполнение тех или иных действий.

Диспетчер доступа реализован в виде нескольких взаимосвязанных программных фрагментов, каждый из которых контролирует свою область действий технологической платформы «1С: Предприятие 8».

Первая часть обслуживает подсистему идентификации и аутентификации. Она получает управление в момент открытия логической связи c информационной базой «1С: Предприятие 8» при изменении прав пользователей. Данный фрагмент обеспечивает идентификацию, аутентификацию, проверку категорий доступа.

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

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

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

Право доступа - это разрешение на выполнение определённого действия над объектом конфигурации.

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

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

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

1) Имеет ли пользовать право на построение такого запроса;

2) Если право есть, то разрешено ли пользователю возвращать информацию по запросу;

3) Если право есть, то разрешено ли пользователю вносить изменения на основании полученного запроса;

4) Если право есть, то разрешено ли пользователю сохранять полученные значения в информационной базе.



Рисунок 3.1. Блок-схема алгоритма работы диспетчера доступа

аутентификация межсетевой программный

Общие правила настроек функций обеспечения безопасности информации.

Функциональность дискреционного и мандатного разграничение доступа реализуется в прикладных решениях, разработанных на основе «1С: Предприятие 8» посредством применения различных настроек.

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

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

- Файл-серверный режим;

- Клиент-серверный (при использовании СУБД Microsoft SQL Server 2008, редакция 64-бит SP3; Microsoft SQL Server 2012, редакция 64-бит SP3; Microsoft SQL Server 2014);

- Клиент-серверный (при использовании СУБД PostgreSQL из состава Astra Linux Special Edition 1.5).

События безопасности регистрируются в журнале регистрации. Правила идентификации и аутентификации задаются администратором. Контроль целостности выполняется посредством применения утилиты ci.

Виды аутентификации.

Аутентификация - проверка принадлежности предъявленного идентификатора конкретному пользователю системы, проверка подлинности. Пользователь может быть аутентифицирован системой «1С: Предприятие» с помощью ввода его имени и пароля (в диалоге аутентификации, в виде параметров командной строки или строки соединения с информационной базой для внешнего соединения или automation-сервера). В этом случае проверка наличия пользователя и корректности ввода его пароля выполняет система «1С: Предприятие».

Пользователь может быть аутентифицирован неявно средствами операционной системы. Для этого пользователю должен быть поставлен в соответствие некоторый пользователь операционной системы. При старте системы, «1С: Предприятие» запрашивает у операционной системы пользователя, который аутентифицирован в системе в данный момент. Затем выполняется проверка, что данному пользователю операционной системы сопоставлен пользователь «1С: Предприятия». Если поиск заканчивается успешно - считается, что пользователь системы «1С: Предприятие» аутентифицирован успешно, и диалог аутентификации не отображается.

OpenID - это протокол, который позволяет пользователю использовать единую учетную запись для аутентификации на множестве не связанных друг с другом ресурсов, систем. Система «1С: Предприятие» использует протокол, созданный на основе протокола OpenID версии 2.0 по модели Direct Identity.

Общая схема работы выглядит следующим образом:

- Пользователь пытается выполнить вход в систему.

- Система определяет, что в информационной базе работает OpenID-аутентификация (по файлу публикации default.vrd).

- Провайдеру OpenID отправляется запрос на выполнение аутентификации.

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

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

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

В качестве OpenID-провайдера выступает информационная база системы «1С: Предприятие». В качестве OpenID-идентификатора используются имена пользователей информационной базы.

Настройка правил разграничения доступа.

Настройка правил разграничения доступа производится посредством инструментов, реализованных в подсистеме «Управление доступом».

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

Для работы подсистема использует возможности подсистемы «Пользователи».

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

Рисунок 3.2. Пользователи (Группа доступа)

Рисунок 3.3. Ограничения доступа

Для установки текстов ограничений прав доступа используется один из четырех стандартных шаблонов:

#ПоЗначениям(…)

#ПоНаборамЗначений(…)

#ПоЗначениямРасширенный(…)

#ПоЗначениямИНаборамРасширенный(…)

Стандартные шаблоны поставляются в роли «ИpмененияУчастниковГруппДоступа». Наличие сразу нескольких шаблонов объясняется необходимостью решать различные задачи. Так, шаблоны «ПоЗначениям» и «ПоНаборамЗначений» позволяют решить большую часть простых задач. Для шаблонов «ПоЗначениямИНаборамРасширенный» (только для вида доступа Объект) и «ПоНаборамЗначений» можно использовать модификатор «Расширенное ИЛИ», который меняет расчет ограничений с несколькими проверками, результаты которых объединяются по «ИЛИ». Например, электронное письмо доступно, если разрешена «Учетная запись» или «Организация». Без модификатора, если ограничение по учетным записям или организациям не используется, все письма будут разрешены. Шаблоны с модификатором «Расширенное ИЛИ» работают медленнее, поэтому нет нужды использовать модификатор там, где нет логики ограничения по «ИЛИ». Если в ограничении используется вид доступа Объект, а типы объектов и их логика ограничения заранее неизвестны, модификатор нужно указать, когда требуется расширенный расчет «ИЛИ». При установке ограничений прав доступа в ролях, следует указывать их для всех полей. В колонке Поля выбирать вариант <Прочие поля> без указания ограничений для конкретных полей. Это обусловлено тем, что для пользователя состав строк в списках и отчетах не должен зависеть от состава колонок, которые он настроил для отображения тем или иным способом. Шаблон «ПоЗначениям» позволяет реализовать проверку разрешения значений доступа в полях таблицы. Нужно указывать виды доступа, чтобы текст ограничения автоматически оптимизировался, когда вид доступа не используется. Например, текст ограничения доступа вида.

#ПоЗначениям("Документ.ОприходованиеИнструментов", "", "",

"Организации", "Организация",

"Склады", "Склад", …).

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

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

Например, если для документа «Оприходование инструментов» в регистре «НаборыЗначенийДоступа» имеются записи вида:

<Документ1>, , "Организации", "Организация1"

<Документ1>, , "Склады", "Склад1";

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

#ПоНаборамЗначений("ЖурналДокументов.СкладскиеДокументы", "", "", "Ссылка"),

где Ссылка - имя стандартного реквизита журнала.

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

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

Для ограничений, предполагающих логику с «ИЛИ», предусмотрены расширенные шаблоны, в частности «ПоЗначениямРасширенный». Например, ограничение для права Чтение выглядит следующим образом:

#ПоЗначениямРасширенный("Документ.ПеремещениеМедикаментов", "", "",

"",

"",

"Организации", "Т.Организация", "И(",

"Склады", "Т.СкладОтправитель", "ИЛИ",

"Склады", "Т.СкладПолучатель", ")", …)

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

"Внутреннее Соединение Документ.ПеремещениеТоваров.Номенклатура

КАК Т2 по Т.Ссылка = Т2.Ссылка",

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

"ГруппыНоменклатуры", "Т2.Номенклатура", ""

В результате получится такое ограничение:

#ПоЗначениямРасширенный("Документ.ПеремещениеТоваров", "", "",

"Внутреннее Соединение Документ.ПеремещениеТоваров.Номенклатура КАК Т2 по Т.Ссылка = Т2.Ссылка",

"",

"Организации", "Т.Организация", "И(",

"Склады", "Т.СкладОтправитель", "ИЛИ",

"Склады", "Т.СкладПолучатель", ")И",

"ГруппыНоменклатуры", "Т2.Номенклатура", "", …)

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

«ПоЗначениямИНаборамРасширенный».

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

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

#ПоЗначениям("Справочник.Файлы", "Чтение", "",

"ПравоЧтение", "Т.ВладелецФайла",

"Организации", "Т.ВладелецФайла.Организация", …).

Когда владельцев много, этот способ не подходит. Для такого случая, подсистема «Управление доступом» предоставляет специальный вид доступа по объекту-владельцу. Для использования этого вида доступа в шаблоне следует указывать в качестве имени вида доступа Объект. Вид доступа Объект предполагает, что в поле находится значение, которое является ссылкой на объект данных. А в регистре «Наборы значений доступа», как и для шаблона «ПоНаборамЗначений», записаны наборы значений для этого объекта, которые следует проверить. Исключение составляют владельцы настроек прав - для них наборы значений доступа записывать не требуется, но процедура заполнения может понадобиться, если они используются для заполнения наборов значений доступа зависимых объектов.

Так, используя шаблон «ПоЗначениямИНаборамРасширенный», можно проверить не одно значение доступа, а набор значений, подготовленный при записи документа, ссылка на который находится в реквизите, например, «Владелец» элемента справочника «Файлы»

#ПоЗначениямИНаборамРасширенный("Справочник.Файлы", "", "",

"",

"",

"Объект", "Т.Владелец" , "", …)

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

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

Права объекта, которые проверяются в ограничении по виду доступа Объект, можно переопределить в процедуре: «ПриЗаполненииЗависимостейПравДоступа» модуля «УправлениеДоступомПереопределяемый».

Структура регистра «Наборы значений доступа» поддерживает логику ИЛИ для значений доступа и различные наборы по правам доступа. Для реализации логики ИЛИ добавлено измерение «Номер» набора типа «Число», а для наборов по правам добавлены два ресурса Чтение, Изменение - типа Булево.

Сложную логику ИЛИ записать в регистр «напрямую» не получится. Номер набора позволяет сделать для одного ссылочного элемента данных (например, документа) несколько наборов значений, по которым проверяется доступность документа. Причем достаточно, чтобы значения хотя бы одного набора значений были доступны одновременно. Точнее, результаты проверки значений доступа по видам доступа в пределах набора с одним номером объединяются по «И», а результаты проверки целых наборов объединяются по «ИЛИ». Например, для документа «Перемещение товаров» регистр «Наборы значений доступа» будет содержать записи для логики права «Чтение»:

<Документ2>, 0, "Организации", "Организация1"

<Документ2>, 0, "Склады", "Склад1";

<Документ2>, 1, "Организации", "Организация1"

<Документ2>, 1, "Склады", "Склад2";

Видно, что, хотя значений доступа три: Организация1, Склад1, Склад2, - записей в регистре четыре. Это связано с раскрытием скобок в логическом выражении О1 и (С1 или С2), что приводит к логическому выражению суммы произведений О1 и С1 или О1 и С2.

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

Записи для логики права «Изменение»:

<Документ2>, 0, "Организации", "Организация1"

<Документ2>, 0, "Склады", "Склад1";

<Документ2>, 0, "Склады", "Склад2";

Шаблон «ПоЗначениямИНаборамРасширенный» отличается от шаблона «ПоЗначениямРасширенный» только поддержкой специального вида доступа Объект.

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

Рисунок 3.4. Алгоритм для быстрого выбора шаблонов

При использовании стандартных шаблонов «ПоНаборамЗначений» или «ПоЗначениямИНаборамЗначений» с видом доступа Объект потребуется записать в регистр Наборы значений доступа сведения, требуемые для их работы.

Запись наборов значений доступа выполняется при записи объектов - например, документов. Перед записью вызывается пользовательская процедура заполнения наборов значений доступа.

Процедура заполнения помещается в модуль объекта, и его тип включается в подписку на события записать наборы значений доступа и в состав типов измерения Объект регистра сведений Наборы значений доступа.Вид доступа (только для специальных видов доступа «ПравоЧтения», «ПравоИзменения»). Специальные имена видов доступа «ПравоЧтения», «ПравоИзменения» требуются, когда нужно разработать ограничение с зависимостью по правам «подчиненного» объекта от «ведущего» объекта. В шаблонах ограничения доступа в проверку по виду доступа Объект встроена логика проверки зависимых прав, как и в этих видах доступа. В связи с этим сочетать данные виды доступа с видом доступа Объект не требуется. Также не требуется использовать эти виды доступа при заполнении зависимых наборов значений доступа. Для этих целей предусмотрен третий параметр в процедуре «ЗаполнитьНаборыЗначенийДоступа», при указании которого соответствующие проверки добавляются автоматически.

Настройка свойств объектов метаданных производится по правилам, указанным в таблице 3

Таблица 3 - Настройка свойств объектов метаданных

Свойство объекта метаданных	Настройка
ОпределяемыйТип.ЗначениеДоступа	? Обязательные типы: ? СправочникСсылка.Пользователи, ? СправочникСсылка.Группы Пользователей ? СправочникСсылка.Внешние Пользователи ? СправочникСсылка.ГруппыВнешних Пользователей. ?Типы значений доступа, например, СправочникСсылка.Организации. ? Типы групп значений доступа, например
ОпределяемыйТип.ВладелецНастроекПрав	? Типы владельцев настроек прав,
ОпределяемыйТип.ВладелецНастроекПравОбъект	? Типы владельцев настроек прав
ОпределяемыйТип.ЗначениеДоступаСГруппами ЗначенийДоступаОбъект	? Типы значений доступа, для которых указан тип групп значений
ОпределяемыйТип.ВладелецНаборовЗначенийДоступаОбъект (совместно с типами, указанными в создаваемых подписках на события ЗаписатьНаборыЗначенийДоступа<Окончание>)	? Типы объектов, для которых записываются наборы значений доступа используемые, как значения в проверках по виду Объект через шаблон #ПоЗначениямИНаборамРасширенный. ? Типы объектов с ограничением, настроенным с помощью шаблона #ПоНаборамЗначений
ОпределяемыйТип.ВладелецВнешнихЗначенийВНаборахЗначенийДоступаОбъект(совместно с типами, указанными в создаваемых подписках на события ЗаписатьЗависимыеНаборыЗначенийДоступа<Окончание>)	Типы объектов, которые используются в процедурах ЗаполнитьНаборыЗначенийДоступа для формирования наборов, но не входят в состав типов владельцев наборов значений доступа, то ест отсутствуют в типе ОпределяемыйТип.ВладелецНаборовЗначенийДоступаОбъект (а также среди типов, указанных в соответствующих создаваемых подписках на события).
ОпределяемыйТип.ВладелецСОграничениемПоНаборамЗначенийДоступаОбъект(совместно с типами, указанными в создаваемых подписках на события ЗаполнитьНаборыЗначенийДоступаТабличныхЧастей<Окончание>)	Используется для тех объектов (кроме документов), которые используют наборы значений доступа в шаблоне #ПоНаборамЗначений для ограничения объекта. Для документов необходимо создавать отдельную подписку
ТабличнаяЧасть.НаборыЗначенийДоступа. (НомерНабора, ЗначениеДоступа, Уточнение, Чтение, Изменение)	Табличная часть создается в объектах метаданных прикладной конфигурации, которые используют наборы значений доступа в шаблоне #ПоНаборамЗначений для ограничения доступа к ним. Состав полей табличной части одинаков для всех таких объектов. Состав типов, как у тех же полей в регистре сведений НаборыЗначенийДоступа

Для использования отчета «Права доступа» требуется задать список видов доступа, используемых в ограничении прав объектов метаданных. Список задается в переопределяемом модуле в виде многострочной строки формата <Полное имя таблиц>. <Право>. <Вид доступа>. Для автоматического формирования кода процедуры следует применить инструменты разработчика. Пример заполнения процедуры:

Процедура ПриЗаполненииВидовОграниченийПравОбъектовМетаданных(Описание) Экспорт

Описание =

"

|БизнесПроцесс.Задание.Добавление.Пользователи

|БизнесПроцесс.Задание.Изменение.Пользователи

|БизнесПроцесс.Задание.Чтение.Пользователи

|…

|…

|…

|Справочник.ПапкиФайлов.Изменение._ДемоПапкиФайлов

|Справочник.ПапкиФайлов.Чтение._ДемоПапкиФайлов

|Справочник.УчетныеЗаписиЭлектроннойПочты.Чтение.УчетныеЗаписиЭлектроннойПочты

|";

КонецПроцедуры

Если в конфигурации не используется подсистема «Настройки программы», то в командном интерфейсе необходимо разместить:

? Справочник.ГруппыДоступа (кроме случая упрощенного интерфейса):

? Для частой работы администратора по просмотру и редактированию групп доступа;

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

? Справочник.ПрофилиГруппДоступа (кроме случая упрощенного интерфейса) - для редкой работы администратора по просмотру списка и содержания профилей групп доступа.

? ОграничиватьДоступНаУровнеЗаписей - для включения/выключения ограничения доступа на уровне записей (администраторами). Если в ограничениях прав используются наборы значений доступа, то при включении константы необходимо выдавать предупреждение о необходимости заполнения данных для ограничения доступа.

Для настройки прав доступа пользователей к данным подсистемы «Управление доступом» следует использовать следующие роли, указанные в таблице 4.

Таблица 4 - Роли настройки прав доступа пользователей

№	Роли и их назначение
1	БазовыеПрава (из подсистемы «Базовая функциональность») Просмотр списка пользователей. Просмотр списка своих групп доступа в форме Права доступа. Формирование и просмотр отчета о своих правах доступа
2	ИзменениеУчастниковГруппДоступа Изменение состава участников и просмотр тех групп доступа, у которых пользователь установлен как администратор группы доступа
3	ПолныеПрава (из подсистемы «Базовая функциональность») Просмотр и редактирование групп доступа (в том числе назначение администраторов групп доступа). Удаление объектов подсистемы, помеченных на удаление. Ручной запуск регламентного задания Заполнение данных для ограничения доступа. Включение и отключение ограничений прав доступа на уровне записей. Разработка профилей групп доступа

Пример настройки прав доступа пользователей в таблице 5:

Таблица 5 - Пример настройки прав доступа пользователей

Группа пользователей и ее функции	Состав ролей
Ответственный за составы участников групп доступа (дополнительно): Нужен для работы пользователя, которого назначили ответственным за состав участников в группе доступа (например, начальник подразделения, руководитель проектной группы и др.)	? ИзменениеУчастниковГруппДоступа, ? <Подсистема_Адмиристрирование> (просмотр подсистемы Ад администрирование подсистемы «Настройки программы»)

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

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

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

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

Рисунок 3.5. Проверка работы логики ограничений прав

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

1) Возможная ошибка при настройке прав доступа:

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

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

- некорректная настройка ограничений доступа в группе доступа (списков разрешенных значений: организаций, групп партнеров, складов)

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

2) Возможная ошибка при разработке или доработке конфигурации на внедрении:

- некорректная настройка состава ролей в профиле;

- некорректная настройка состава видов доступа в профиле.

3) Ошибки разработчика конфигурации:

- ошибка в параметрах стандартного шаблона;

- ошибка в составе типов подписок на события;

- ошибка в процедуре заполнения наборов значений доступа;

- ошибка в описании видов доступа.

- ошибки разработчика этой подсистемы:

- ошибка в стандартном шаблоне;

- ошибка особенностей работы СУБД;

- ошибка в общих модулях подсистемы.

Для диагностики ошибок доступа к данным можно воспользоваться следующими средствами:

1) Убедиться, что содержимое регистра сведений «Наборы значений доступа» содержит наборы значений доступа, которые записаны таким образом, что наборы с одинаковыми номерами для одного объекта соответствуют логике ограничения доступа по условию «И», а затем наборы с разными номерами «складываются» по условию «ИЛИ»:

- если по интересующему объекту в регистре сведений нет записей, то объект не будет доступен для всех пользователей;

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

2) Если в профиль не добавлена роль для чтения каких-либо данных, но предусмотрены роли для работы с другими связанными объектами, то возможна ситуация, когда в полях этих объектов будут отображаться значения вида «Ссылка не найдена» вместо самих данных.

Заключение

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

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

2. Были сформированы модели угроз и модель нарушителя в соответствии с законодательством РФ и приказом ФСТЭК России. В ходе выпускной квалификационной работы были определены уровни защищенности информационных систем, изучены категории обрабатываемых персональных данных. Также определены типы актуальных угроз и методика определения уровня защиты системы.

3. В третьей главе была разработана модель системы защиты информации для медицинских учреждений. Для достижения необходимого уровня безопасности конфиденциальной информации, применили организационные и программно-технические средства защиты информации. На этапе создания нового медицинского учреждения в обязательном порядке нужно провести организационные мероприятия и разработать необходимое количество документации в соответствии с требованиями приказа ФСТЭК России от 18 февраля 2013 г. №21 статья 12 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». На основании выше сказанного руководящего документа ФСТЭК России от 18 февраля 2013 г. №21, были определены программно-технические средства защиты информации. Для автоматизации рабочих мест в медицинском учреждении были взяты сертифицированные средства защиты информации из государственного реестра сертификации защиты информации и реестра отечественного программного обеспечения.

В выпускной квалификационной работе для рассмотрения и анализа мер по обеспечению защиты персональных данных в медицинских учреждениях была взята сертифицированная система программ 1С: Предприятие 8 технологическая платформа 1С: Предприятие, версия 8.3z. комплекта 1С: Медицина». Так как гибкость платформы позволяет применять «1С: Предприятие 8» в самых разнообразных областях и является отечественным программным продуктом которые используют большинство медицинских учреждений. Система программ «1С: Предприятие 8» включает в себя платформу и прикладные решения для медицинских организаций различных организационно-правовых форм, оказывающих медицинскую помощь в амбулаторно-поликлинических условиях.

Литература

1. ГОСТ Р ИСО/ТС 18308-2008 Информатизация здоровья. Требования к архитектуре электронного учета здоровья [электронный ресурс] URL: http://www.gostrf.com/normadata/1/4293832/4293832895.pdf (дата обращения: 18.05.2018)

2. ГОСТ Р 52976-2008 Информатизация здоровья. Состав первичных данных медицинской статистики лечебно-профилактического учреждения для электронного обмена этими данными. Общие требования [электронный ресурс] URL: http://vsegost.com/Catalog/47/47936.shtml (дата обращения: 16.04.2018)

3. ГОСТ Р 52977-2008 Информатизация здоровья. Состав данных о взаиморасчетах за пролеченных пациентов для электронного обмена этими данными. Общие требования [электронный ресурс] URL: http://docs.cntd.ru/document/1200071439 (дата обращения: 25.03.2018)

4. ГОСТ Р 52978-2008 Информатизация здоровья. Состав данных о лечебно-профилактическом учреждении для электронного обмена этими данными. Общие требования [электронный ресурс] URL: http://docs.cntd.ru/document/gost-r-52978-2008 (дата обращения: 10.03.2018)

5. Международный стандарт ISOH/TR 20514:2005 Информационные технологии в медицине Электронная медицинская запись - Определение, назначение, содержание [электронный ресурс] URL: https://allgosts.ru/35/240/gost_r_iso!to_20514-2009 (дата обращения: 16.05.2018)

6. ГОСТ Р ИСО/МЭК 17799-2005 «Информационная технология -Практические правила управления информационной безопасностью» [электронный ресурс] URL: https://fintender.ru/star/gost/r-isomek-27002-2012 (дата обращения: 25.04.2018)

7. Нормативно-методический документ ФСТЭК России «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных» от 15 февраля 2008 года [электронный ресурс] URL:https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye-dokumenty/379-bazovaya-model-ugroz-bezopasnosti-personalnykh-dannykh-pri-ikh-obrabotke-v-informatsionnykh-sistemakh-personalnykh-dannykh-vypiska-fstek-rossii-2008-god (дата обращения: 16.05.2018)

8. Нормативно-методический документ ФСТЭК России «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных» от 14 февраля 2008 года [электронный ресурс] URL: https://fstec.ru/normativnye-i-metodicheskie-dokumenty-tzi/114-deyatelnost/tekushchaya/tekhnicheskaya-zashchita-informatsii/normativnye-i-metodicheskie-dokumenty/spetsialnye-normativnye-dokumenty/380-metodika-opredeleniya-aktualnykh-ugroz-bezopasnosti-personalnykh-dannykh-pri-ikh-obrabotke-v-informatsionnykh-sistemakh-personalnykh-dannykh-fstek-rossii-2008-god (дата обращения: 10.03.2018)

9. Нормативно-методический документ Минздрав социальное развития России «Методические рекомендации для организации защиты информации при обработке персональных данных в учреждениях здравоохранения, социальной сферы, труда и занятости» от 23 декабря 2009 года [электронный ресурс] URL: https://www.rosminzdrav.ru/documents/7570-rekomendatsii-ot-24-dekabrya-2009-g (дата обращения: 19.05.2018)

10. Федеральный закон Российской Федерации от 27 июля 2006 г. № 152-ФЗ «О персональных данных» [электронный ресурс] URL: http://www.consultant.ru/document/cons_doc_LAW_61801/ (дата обращения: 17.05.2018)

11. Постановление Правительства Российской Федерации от 17 ноября 2007 г. № 781 г. Москва «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных» [электронный ресурс] URL: http://www.consultant.ru/document/cons_doc_LAW_72596/ (дата обращения: 10.05.2018)

12. Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» [электронный ресурс] URL: http://www.consultant.ru/document/cons_doc_LAW_137356/ (дата обращения: 10.05.2018)

13. Приказ ФСБ РФ от 14.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» [электронный ресурс] URL: http://www.consultant.ru/document/cons_doc_LAW_146520/ (дата обращения: 14.04.2018)

14. Приказ ФСТЭК РФ № 55, ФСБ РФ № 86, Мин информ связи РФ № 20 от 13.02.2008 «Об утверждении Порядка проведения классификации информационных систем персональных данных» (Зарегистрировано в Минюсте РФ 03.04.2008 № 11462) [электронный ресурс] URL: https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/110-prikazy/815-sovmestnyj-prikaz-fstek-rossii-fsb-rossii-i-minkomsvyazi-rossii-ot-31-dekabrya-2013-g-n-151-786-461 (дата обращения: 18.03.2018)

15. Постановление Правительства Российской Федерации от 15 августа 2006 г. № 504 «О лицензировании деятельности по технической защите информации» [электронный ресурс] URL: https://fstec.ru/litsenzionnaya-deyatelnost/tekhnicheskaya-zashchita-informatsii/75-postanovleniya/225-postanovlenie-pravitelstva-rossijskoj-federatsii-ot-3-fevralya-2012-g-n-79 (дата обращения: 07.04.2018)

16. Административный регламент ФСТЭК России по исполнению государственной функции по лицензированию деятельности по технической защите конфиденциальной информации, утвержденный приказом ФСТЭК России от 28 августа 2007 г. № 181 [электронный ресурс] URL: https://fstec.ru/component/attachments/download/417 (дата обращения: 12.04.2018)

17. Назаренко Г.И., Гулиев Я.И., Ермаков Д.Е. Медицинские информационные системы: теория и практика. Физматлит, 2010. 320 с.

18. Домарев В.В. Защита информации в медицинских информационных системах: врачебная тайна и современные информационные технологии, клиническая информатика и телемедицина. 2012. Т. 1. № 2. С. 147-154.

19. Калачаева А., Морозов А., Абдуманонов А., Хошимов В., Халилов А. Алгоритмы и стандарты компьютерных технологий обеспечения безопасности информации в МИС «ExterNET» // Актуальные проблемы организации экстренной медицинской помощи: тр. VII Республ. науч.-практич. конф. Ташкент, 2007. С. 269-273.

20. Гулиев Я.И., Фохт И.А., Фохт О.А., Белякин А.Ю. Медицинские информационные системы и информационная безопасность. Проблемы и решения // Программные системы: Теория и приложения: тр. Междунар. конф. Переславль-Залесский, 2009. С. 175-206.

21. Левин, В.К. Защита информации в информационно-вычислительных cистемах и сетях // Программирование. N3. 2009. - C. 67.

22. Северин, В.А. Комплексная защита информации на предприятии. Гриф УМО МО РФ. - М.: Городец, 2010. -С. 108.

23. Хофман, Л. Современные методы защиты информации. СПб: Питер, 2009. - С. 45.

24. Романов, Д-Н. Внедрение промышленной медицинской информационной системы с заменой морально устаревших программных решений / Д.Н. Романов, А.А. Борейко // Врач и информационные технологии, 2010. -- № 1. М.: ИД «Менеджер здравоохранения» - С. 30-35.

25. Гулиева, И.Ф. Медицинские информационные системы: затраты и выгоды / И.Ф. Гулиева, Е.В. Рюмина, Я.И. Гулиев // Врач и информационные технологии, 2009. №3. - М.: ИД «Менеджер здравоохранения» - С. 4-16.

26. Мартыненко, В.Ф. Информационные технологии в повышении качества медицинской помощи / В.Ф. Мартыненко // Врач и информационные технологии, 2009. №5. - Ч. 1 - М.: ИД «Менеджер здравоохранения» - С. 4-10.