Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 icon

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14





НазваниеЗадачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14
страница10/16
Дата21.02.2013
Размер2.99 Mb.
ТипРеферат
1   ...   6   7   8   9   10   11   12   13   ...   16
^

5.2Требования к элементам технологического сегмента

5.2.1Комплексная система защиты персональных данных (СЗПДн)


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

Система защиты персональных данных должна включать следующие подсистемы:

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

  • Подсистему регистрации и учета;

  • Подсистему аутентификации и идентификации;

  • Подсистему криптографической защиты информации;

  • Подсистему обеспечения целостности информации;

  • Подсистему антивирусной защиты;

  • Подсистему защиты от компьютерных атак;

  • Подсистему инженерно-технической защиты объектов.

Подсистема управления доступом предназначена для предоставления доступа пользователям и программным компонентам к информационным ресурсам РИАМС.

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

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

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

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

^ Подсистема антивирусной защиты предназначена для организации защиты программного обеспечения РИАМС от вредоносных программ.

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

Подсистема инженерно-технической защиты объектов предназначена для физической защиты объектов РИАМС.
^

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


Подсистема управления доступом должна обеспечивать:

  • создание замкнутой программной среды, в которой пользователь может только получать и обрабатывать разрешенные данные;

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

  • задание правил доступа на основе групповых характеристик пользователей;

  • реализацию механизма сигнализации попыток НСД к информации;

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

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

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

  • регистрацию в РИАМС новых пользователей и удаление пользователей, срок полномочий которых истек;

  • инициализацию личных идентификаторов пользователей, которые необходимы им для работы в РИАМС;

  • анализ протокола действий пользователей;

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

  • предоставление пользователям права на доступ к информационным ресурсам.

Подсистема управления доступом должна функционировать на основе общесистемного сервиса единой службы каталогов (п. 5.2.6.1).
^

5.2.1.2Подсистема регистрации и учета


Подсистема регистрации и учета должна обеспечивать:

  • регистрацию и учет подключения (отключения) пользователей к ресурсам информационной системы;

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

  • регистрацию и учет доступа к контролируемым объектам доступа в центре обработки данных и серверных помещениях медицинских учреждений;

  • регистрацию и учет получения бумажных копий с защищаемой информации;

  • регистрацию и учет событий, квалифицируемых как попытка НСД;

  • регистрацию и учет изменения полномочий субъектов доступа;

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

  • регистрация проведенных криптографических операций.

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

Подсистема регистрации и учета должна быть интегрирована с общесистемным сервисом единой службы каталога (см. п. 5.2.6.1).
^

5.2.1.3Подсистема аутентификации и идентификации


Подсистема идентификации и аутентификации должна обеспечивать:

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

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

  • идентификацию программ, томов, каталогов, файлов, записей, полей записей по именам;

  • контроль доступа пользователей к защищаемым ресурсам в соответствии с матрицей доступа;

  • возможность применения механизмов дискреционного принципа доступа;

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

  • блокирование доступа к СВТ при превышении установленного интервала времени неактивности данного СВТ.

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

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

  • должен осуществляется контроль доступа пользователей к периферийным устройствам;

  • должна осуществляться динамическая и статическая блокировка доступа к внешним устройствам.

Подсистема аутентификации и идентификации должна функционировать на основе общесистемного сервиса единой службы каталогов (п. 5.2.6.1).
^

5.2.1.4Подсистема криптографической защиты информации


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

  • шифрование защищаемой информации при ее передаче по открытым каналам связи вне границы контролируемой зоны, не защищенным от НСД к информации организационно-техническими мерами;

  • шифрование команд управления при их передаче по каналам связи, не защищенным от НСД к информации организационно-техническими мерами;

  • имитозащиту защищаемой информации при ее передаче по каналам связи, не защищенным от НСД к информации организационно-техническими мерами;

  • имитозащиту команд управления при их передаче по каналам связи, не защищенным от НСД к информации организационно-техническими мерами;

  • управление криптографическими ключами.

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

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

5.2.1.5Подсистема обеспечения целостности информации


Подсистема обеспечения целостности информации должна обеспечивать:

  • контроль неизменности объектов контроля;

  • контроль неизменности конфигурации ПТС объектов информатизации;

  • проверку целостности подлежащих проверке файлов операционной системы до ее загрузки;

  • автоматическую проверку целостности определенных администратором исполняемых модулей и файлов данных;

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

  • блокирование работы системы обеспечения информационной безопасности в случае отрицательного результата проверки с отражением соответствующей информации в регистрационном журнале;

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

  • обеспечение возможности надежного восстановления системы обеспечения информационной безопасности.

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

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

5.2.1.6Подсистема антивирусной защиты


Подсистема антивирусной защиты должна строиться на комплексном использовании сертифицированных в системе сертификации ФСБ России и ФСТЭК России антивирусных средствах. Программное обеспечение подсистемы антивирусной защиты должно быть сертифицировано на соответствие требованиям руководящего документа «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» Гостехкомиссии России (1999 г.).

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

  • антивирусные средства должны применяться для антивирусной защиты программного обеспечения, установленного на серверах и на АРМ пользователей РИАМС;

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

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

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

Средства антивирусной защиты должны обеспечивать:

  • возможность выявления вирусной активности в режиме реального времени;

  • возможность обнаружения вирусов при принудительной проверке АРМ;

  • централизованное управление сканированием, удаление вирусов и протоколирование вирусной активности;

  • централизованное обновление вирусных баз на всех объектах РИАМС;

  • формировать отчеты по результатам своей работы.
^

5.2.1.7Подсистема защиты от компьютерных атак


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

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

  • контроль процесса функционирования сенсоров системы обнаружения атак;

  • сбор информации от сенсоров системы обнаружения атак и ее анализ на предмет выявления атаки;

  • сканирование хостов контролируемого сегмента IP-сети;

  • управление и настройка системы обнаружения атак в целом;

  • уведомление администратора сети о наступлении заданного множества событий, определяемых шаблонами;

  • фиксирование процесса и результатов функционирования системы обнаружения атак;

  • контроль функционирования сетевого сенсора и узловых сенсоров.

Средства мониторинга сетевых атак должны обеспечивать перехват сетевого трафика контролируемого сегмента IP-сети (задается администратором) и выявление:

  • появления несанкционированных хостов или шлюзов в другие компоненты РИАМС;

  • использования несанкционированных протоколов взаимодействия и/или портов;

  • отклонений от штатных режимов работы пользователей (клиентов);

  • проведения компьютерных атак на объекты контролируемой сети.

Автоматическая регистрация и хранение информации об атаках и функционировании сети включает:

  • информацию о выявленных компьютерных атаках:

  • протокол, используемый для проведения атаки;

  • идентификатор субъекта атаки (если его можно определить на основе анализа трафика);

  • идентификатор объекта атаки;

  • код регистрируемого события;

  • результат попытки осуществления регистрируемого события;

  • факты входа/выхода администратора для управления с указанием идентификатора режима управления (удаленное или локальное), идентификатор указанного администратора,

  • моменты запуска/перезагрузки;

  • результаты проверки целостности программной части и настроек.
^

5.2.1.8Подсистема инженерно-технической защиты объектов


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

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

  • разграничение доступа сотрудников на объекты (в здания, помещения и т.п.) в соответствии с назначенными полномочиями;

  • организацию системы охранно-пропускного режима и системы контроля доступа на объекты;

  • предотвращение несанкционированного проникновения на защищаемые объекты злоумышленников и нарушителей (затруднение проникновения, сигнализация о попытках проникновения и прорывах рубежа охраны с локализацией места и времени нарушения);

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

  • визуальный и технический контроль контролируемой зоны объекта.

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

В рамках данной подсистемы в серверных помещениях РЦОД РИАМС, а также в серверных помещениях МЦОД должны быть развернуты:

  • Система охранно-тревожной сигнализации;

  • Система контроля и управления доступом;

  • Система видеонаблюдения.
^

5.2.1.9Система охранно-тревожной сигнализации


Система охранно-тревожной сигнализации ЦОД должна соответствовать требованиям ГОСТ 26342-84. Охранная сигнализация серверного помещения РЦОД должна быть выполнена отдельно от систем безопасности здания. Сигналы оповещения должны быть выведены в помещение круглосуточной охраны в виде отдельного пульта. Дополнительно, сигналы оповещения могут доставляться средствами связи: телефон, СМС, пейджер.

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

5.2.1.10Система контроля и управления доступом


Система контроля и управления доступом ЦОД должна полностью соответствовать требованиям ГОСТ Р 51241-2008 (Средства и системы контроля и управления доступом). Система контроля и управления доступом ЦОД должна исключить попадание в серверное помещение лиц, в чьи обязанности не входит монтаж, эксплуатация и техническое обслуживание оборудования, размещенного в серверном помещении.

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

  • Ключи от механических замков;

  • Кодонаборные панели;

  • Карты и метки электронной идентификации;

  • Биометрическая идентификация;

  • Комбинация вышеперечисленных методов.

Биометрические считыватели, при их применении в системе, должны соответствовать требованиям ГОСТ Р ИСО/МЭК 19794-2, ГОСТ Р ИСО/МЭК 19794-4, ГОСТ Р ИСО/МЭК 19794-5, ГОСТ Р ИСО/МЭК 19794-6.

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

  • Механические замки;

  • Электромеханические замки;

  • Электромагнитные замки;

  • Комбинация вышеперечисленных средств.
^

5.2.1.11Система видеонаблюдения ЦОД


Система охранного видеонаблюдения должна быть спроектирована в соответствии с ГОСТ Р 51241-2008. Система охранного видеонаблюдения предназначена для визуального наблюдения и фиксации текущей обстановки в серверных помещениях ЦОД. Камеры необходимо разместить таким образом, чтобы контролировать входы и выходы в помещение, пространство возле технологического оборудования (ИБП, кондиционеры, серверные шкафы и телекоммуникационные стойки). Разрешения видеокамер должно быть достаточным, чтобы уверенно различать лица сотрудников, обслуживающих технологическое оборудование. Все данные видеокамер, датчиков движения должны сохраняться на выделенном сервере подсистемы инженерно-технической защиты ЦОД. Данные системы видеонаблюдения должны подвергаться процедуре сохранения для долговременного хранения.

Оборудование системы видеонаблюдения должно обладать следующими техническими характеристиками:

  • количество видеовходов: 4…32;

  • количество аудиовходов: 2…32;

  • разрешение/скорость записи: 704x576 /25 fps;

  • минимальный размер кадра: 5 Кб;

  • наличие портов PCI 2.2 или PCIe x1 (DV-S8 PCI Express);

  • технология компрессии аудиопотока : Ogg Vorbis;

  • частота дискретизации: 16 кГц;

  • аудиопоток на выходе: 16 кбит/c;

  • обеспечение возможности получения несжатого видео до 704х576;

  • тип компрессии H.264.

Оконечное оборудование системы видеонаблюдения должно:

  • обладать разрешением не менее 540 ТВЛ;

  • обладать чувствительностью при работе стандартной функции «день/ночь»: 0.6 лк в цветном режиме/0.05 лк в черно-белом режиме;

  • обеспечивать компенсацию задней засветки;

  • обеспечивать автоматический контроль баланса белого;

  • обеспечивать автоматический контроль освещенности;

  • иметь видеообъектив (не хуже): вариобъектив 2.8 ~ 10 мм 3.6x с ирисовой диафрагмой;

  • обеспечивать возможность вывода изображения на монитор;

  • обеспечивать внутреннюю/мультиплексную синхронизацию по вертикальному импульсу;

  • поворот петель: горизонталь/вертикаль/наклон.
^

5.2.2Система информационного взаимодействия


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

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



Рис. 6. Система информационного взаимодействия

Компонент, функционирующий на региональном уровне РИАМС, должен обеспечивать следующие виды взаимодействия:

  • обмен данными между прикладными системами РИАМС регионального уровня (горизонтальное межсистемное взаимодействие);

  • обмен данными с компонентами СИВ медицинских учреждений (вертикальное внутрисистемное взаимодействие);

  • обмен данными с внешними системами регионального уровня, включая системы «электронного правительства» Республики Коми;

  • обмен данными с информационными системами федерального уровня, входящими в состав ЕИС в сфере здравоохранения.

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

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

  • модель «точка-точка» (point-to-point);

  • модель «публикация-подписка» (publish-subscribe).

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

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

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

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

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

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

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

  • иметь графический редактор процессов;

  • предоставлять возможность моделирования процессов в соответствии со стандартом BPEL4WS;

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

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

5.2.3Система ведения нормативно-справочной информации


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

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

Общими принципами формирования нормативно-справочной информации РИАМС должны являться:

  • открытость и доступность для всех пользователей и информационных систем, входящих в РИАМС;

  • обеспечение методического и организационного единства;

  • комплексность, предусматривающая наиболее полный охват информации, хранимой в РИАМС и используемой при информационном обмене;

  • регулярная актуализация;

  • обязательность применения при формировании информационных ресурсов, включаемых в РИАМС.

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

  • организацию (учреждение), ответственную за разработку и ведение классификатора (справочника);

  • порядок внесения изменений в классификатор (справочник);

  • сроки обновления и введение в действие новых версий классификатора (справочника);

  • порядок передачи изменений от организации, ответственной за ведение классификатора (справочника) Оператору РИАМС;

  • порядок внесения изменений Оператором РИАМС в электронную версию классификатора (справочника);

  • порядок публикации Оператором РИАМС электронной версии классификатора (справочника) для дальнейшего использования этой версии в РИАМС.

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

  • создание и модификацию структуры классификатора (справочника) с помощью метаданных;

  • автоматизированное получение и загрузку классификаторов (справочников), ведущихся федеральными ведомствами;

  • автоматизированную загрузку электронных версий классификаторов (справочников), а также внесение изменений в электронные версии классификаторов (справочников) в соответствии с положениями регламентирующих документов;

  • автоматизированную публикацию новых версий классификаторов (справочников), включая актуализацию НСИ на объектах РИАМС;

  • •поддержание историчности данных в общесистемных классификаторах и справочниках с использованием дат начала и окончания действия;

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

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


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

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

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

Основными функциями электронного документооборота являются:

  • Однократная регистрация и идентификация документа;

  • Хранение документов в виде прикрепленных файлов, включая графические форматы;

  • Поддержка создания шаблонов документов;

  • Возможность настройки и оптимизации процессов обработки документов определенного типа (жизненного цикла документа);

  • Возможность параллельной работы с документом с отслеживанием авторов исправлений и версий документов;

  • Разделение прав доступа к документам;

  • Назначение ответственных за исполнение документа в целом или его положений;

  • Контроль исполнения документов;

  • Поддержка возможности электронно-цифровой подписи документов;

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

  • Контроль движения документов и анализ процессов их обработки;

  • Оповещение сотрудников о необходимости обработки документов в соответствии с преднастроенными процессами;

  • Мониторинг загруженности сотрудников и перераспределение нагрузки между сотрудниками с одинаковыми ролевыми функциями;

  • Гибкая система отчетности, позволяющая настраивать необходимые формы;

  • Возможность экспорта и печати документов.
^

5.2.5Система управления эксплуатацией


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

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

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

  • Подсистему управления инцидентами;

  • Подсистему управления проблемами;

  • Подсистему управления конфигурациями;

  • Подсистему управления производительностью;

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

  • Подсистему мониторинга функционирования РИАМС и ее компонентов.

Подсистема управления инцидентами предназначена для регистрации и учета инцидентов в работе компонентов РИАМС, данных об устранении произошедших инцидентов, эскалации инцидентов в подсистему управления проблемами.

^ Подсистема управления проблемами должна производить анализ инцидентов, возникающих в РИАМС, с целью выявления и устранения исходных причин их вызывающих. Исходными данными для подсистемы управления проблемами должны являться:

  • информация об инцидентах, передаваемая из подсистемы управления инцидентами;

  • конфигурационные данные элементов информационной инфраструктуры из подсистемы управления конфигурацией;

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

^ Подсистема управления конфигурациями предназначена для учета и хранения конфигураций компонентов РИАМС, внесения изменений в конфигурацию компонентов РИАМС, учет последствий внесенных изменений.

^ Подсистема управления производительностью предназначена для осуществления контроля производительности отдельных компонентов РИАМС и обеспечения подготовки обоснованных решений по оптимизации использования ресурсов РИАМС.

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

^ Подсистема мониторинга функционирования Системы и ее компонентов предназначена для сбора первичной информации о состоянии компонентов РИАМС с целью своевременного выявления отклонений в их функционировании и предупреждения сбоев в работе компонентов РИАМС.

В настоящее время в государственном автономном учреждении Республики Коми «Центр информационных технологий» в рамках работ по проекту «Электронное правительство» внедрена система управления эксплуатацией на базе промышленного решения Manage Engine Service Desk plus версии 8.0.0. Данная система включает в себя следующие подсистемы:

  • Подсистему управления инцидентами;

  • Подсистему управления проблемами;

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

Целесообразно максимально использовать функциональность внедренной системы управления эксплуатацией в интересах РИАМС, для чего необходимо расширить состав ее компонентов.
^

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


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

  • регистрацию и автоматизированную обработку запросов на устранение инцидентов или внесение изменений в инфраструктуру РИАМС;

  • присвоение инцидентам категорий в соответствии с предметной областью (системные ресурсы, приложения, сетевое или телекоммуникационное оборудование и пр.);

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

  • предварительная оценка и присвоение инцидентам степени критичности относительно их воздействия на компоненты РИАМС;

  • учет проводимых работ по технической эксплуатации и поддержке оборудования;

  • контроль «жизненных циклов» инцидентов от момента поступления запросов на устранение до их устранения и «закрытия запросов»;

  • информирование пользователей РИАМС о статусе работ по устранению инцидентов;

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

  • передачу информации об инцидентах в подсистему управления проблемами;

  • передачу информации о запросах на изменения конфигураций компонентов РИАМС в подсистему управления конфигурациями.
^

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


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

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

  • статистический анализ инцидентов по частоте их возникновения, категориям, степени критичности и др.;

  • прием информации о конфигурациях и производительности компонентов РИАМС из подсистем управления конфигурациями и производительностью;

  • корреляционную обработку инцидентов по времени их возникновения с данными о конфигурации и производительности компонентов РИАМС для выявления исходных причин проблемы и принятия решения;

  • передачу заявок на изменение (реконфигурацию, модернизацию) компонентов РИАМС в подсистему управления конфигурациями с целью устранения проблем;

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

  • ведение базы данных типовых известных проблем и связанных с ними инцидентов.
^

5.2.5.3Подсистема управления конфигурациями


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

  • прием и регистрацию заявок на изменение конфигурации компонентов РИАМС из подсистем управления инцидентами и проблемами, включая классификацию заявок по категориям и установление им приоритетов;

  • принятие решений по утверждению или отклонению заявок на изменения конфигураций;

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

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

  • ведение базы данных конфигураций и хронологии изменений конфигураций.
^

5.2.5.4Подсистема управления производительностью


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

  • мониторинг использования приложениями системных и сетевых ресурсов;

  • сбор информации о снижении производительности компонентов РИАМС с последующей передачей данных в подсистему управления проблемами для анализа и выработки корректирующего решения;

  • анализ изменения производительности компонентов РИАМС во времени;

  • передачу информации о производительности компонентов РИАМС в подсистему управления конфигурациями и контроль корректности внесенных изменений.
^

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


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

  • проверка соответствия времени устранения инцидентов соглашениям об уровне услуг на основании данных из подсистемы управления инцидентами;

  • оценка качества информационных услуг на основании данных о производительности компонентов РИАМС, получаемых из подсистемы управления производительностью, на соответствие установленным соглашениям об уровне услуг.
^

5.2.5.6Подсистема мониторинга функционирования РИАМС и ее компонентов


Подсистема мониторинга функционирования РИАМС и ее компонентов должна обеспечивать реализацию следующего набора функций:

  • прием SNMP-сообщений от компонентов РИАМС и автоматическая регистрация текущего состояния компонента РИАМС в специализированной базе данных;

  • интерпретация и визуализация данных из базы данных на мониторах обслуживающего персонала в режиме «on-line»;

  • уведомление персонала о превышении пороговых значений в работе оборудования;

  • хранение в БД данных о состояниях компонентов РИАМС;

  • формирование отчетности;

  • передача данных о состояниях компонентов РИАМС в подсистемы управления инцидентами, управления проблемами и управления производительностью.

Дополнительно подсистема мониторинга функционирования РИАМС и ее компонентов в части контроля и мониторинга активного сетевого оборудования должна обеспечивать:

  • автоматический поиск устройств;

  • определение топологии сети;

  • определение физического соединения;

  • определение топологии по VLAN;

  • мониторинг состояния STP;

  • возможность построения топологии относительно заданного устройства;

  • поиск точки подключения пользователя;

  • проверку доступности и измерение показателей работы TCP, UDP, HTTP, ICMP.

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

Детальные требования к подсистеме мониторинга функционирования РИАМС и ее компонентов должны быть разработаны на стадии технического проектирования.
^

5.2.6Общесистемные сервисы


В состав общесистемных сервисов РИАМС должны быть включены следующие службы:

  • Единая служба каталога;

  • Служба электронной почты;

  • Служба предоставления доступа к сети Интернет;

  • Базовые сетевые службы (DNS, DHCP, WINS);

  • Файловая служба;

  • Единая служба времени;

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

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

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

^ Служба предоставления доступа к сети Интернет предназначена для организации единой точки доступа в Интернет в рамках РИАМС для всех медицинских учреждений и органов управления здравоохранением.

^ Базовые сетевые службы (DNS, DHCP, WINS) предназначены для организации в рамках РИАМС единого сетевого адресного пространства, выдачи постоянных и временных IP-адресов, разрешения доменных имен в IP-адреса и обратно, а также для поддержки NetBIOS-адресации в рамках РИАМС.

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

^ Единая служба времени предназначена для обеспечения корректной работы единой службы каталога и организации единого временного пространства в рамках РИАМС.

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

5.2.6.1Единая служба каталога


Единая служба каталога (ЕСК) должна обеспечивать:

  • Централизованное хранение и централизованное управление такими объектами, как учетные записи пользователей, компьютеров и групп, общие папки и принтеры, почтовые системы;

  • Возможность децентрализованного (делегированного) управления объектами, размещенными в таких контейнерах, как домены или организационные подразделения (ОП);

  • Быстрый поиск информации о любом объекте сети при помощи запросов к контроллерам домена или серверам глобального каталога;

  • Проверку подлинности участников безопасности при входе в единую вычислительную сеть РИАМС;

  • Авторизацию при доступе к информационным ресурсам РИАМС;

  • Технологию единого входа (Single Sign On) при доступе к любым информационным ресурсам РИАМС;

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

  • Возможность интеграции с системой проверки подлинности на основе электронных сертификатов;

  • Возможности расширения каталога и интеграции с другими каталогами.

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

Единую службу каталога РИАМС целесообразно развернуть на базе продукта Microsoft Active Directory 2008. При проектировании ЕСК необходимо рассмотреть следующие основные вопросы:

  • Модель леса Active Directory;

  • Структура доменов Active Directory;

  • Административная модель управления;

  • Структура организационных подразделений;

  • Структура сайтов и размещение контроллеров домена.

Ниже представлены основные рекомендации по развертыванию Единой службы каталога. Более детально решения по развертыванию Единой службы каталога должны быть проработаны на стадии технического проектирования.
^
5.2.6.1.1Модель леса AD

В настоящий момент в аппарате Правительства Республики Коми спроектирована и внедрена Единая Служба Каталога, состоящая из леса rkomi.local двух доменов: основного домена rkomi.local и ресурсного rk.local.

В качестве модели леса единой службы каталога РИАМС целесообразно рассмотреть модель с единым лесом. Такая модель характеризуется, прежде всего, простотой и эффективностью формирования и отслеживания политик безопасности. В рамках единой политики безопасности легко реализуется делегирование полномочий на службу каталога и на управление РИАМС в целом. Делегирование полномочий позволит сократить число сотрудников, обладающих административными полномочиями, и централизовано контролировать зону ответственности каждого из администраторов. Кроме того, при внедрении службы электронной почты на основе модели единого леса ЕСК, будет возможным создание единой глобальной адресной книги, содержащей всех пользователей РИАМС.

С целью обеспечения возможности использования аппаратных и программных средств, развернутых в рамках ЕСК Аппарата Правительства Республики Коми, а также с целью обеспечения взаимодействия между ЕСК Аппарата Правительства Республики Коми и проектируемым ЕСК РИАМС целесообразно установить двухсторонние транзитивные доверительные отношения между лесами rkomi.local и лесом РИАМС (riams.local).
^
5.2.6.1.2Структура доменов AD

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



^ Рис. 7. Доменная структура ЕСК

При такой структуре одно дерево содержит корневой домен riams.local и дочерний домен test.local, второе дерево содержит рабочий домен riams.rkomi.ru. Сокращенные доверительные отношения между тестовым и рабочим доменами упрощают процедуры проверки подлинности.

Корневой домен леса riams.local является хранителем следующих мастеров операций: Мастера схемы и Мастера именования доменов. Администраторы корневого домена riams.local имеют административные права на уровне всего леса и могут производить такие операции, как модификация схемы AD и создание новых доменов.

Тестовый домен test.local используется для тестирования новых продуктов перед внедрением их в рабочий домен.

В рабочем домене riams.rkomi.ru располагаются все основные информационные ресурсы РИАМС – учетные записи пользователей всех объектов РИАМС, учетные записи всех компьютеров и серверов, опубликованные принтеры, общие папки и т.д.

Стратегическое управление всеми ресурсами ЕСК осуществляется администраторами Оператора РИАМС. Для выполнения некритичных для безопасности ЕСК операций техническим специалистам, находящимся непосредственно на объектах информатизации, назначаются минимально необходимые для осуществления этих операций полномочия.

Приведенная структура доменов обеспечивает:

  • Контроль членства в группах Enterprise Admins и Schema Admins (расположенных в корневом домене леса), имеющих административные права во всех доменах ЕСК;

  • Унификацию процессов администрирования службы каталога;

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

В соответствии с основными положениями организации эксплуатации РИАМС, представленными в настоящем документе (раздел 6), административная модель управления ЕСК должна строиться на принципах централизованного управления с делегированием разрешений на отдельные операции группам локальных администраторов. Управление объектами службы каталога должно выполняться на следующих уровнях:

  • Уровень леса;

  • Уровень домена;

  • Уровень организационных подразделений.

Предоставление полномочий на управление объектами ЕСК на уровне леса и доменов осуществляется с помощью стандартных групп безопасности – Enterprise Admins и Domain Admins. Предоставление локальным администраторам полномочий на управление организационными подразделениями на своем объекте информатизации происходит с помощью механизма делегирования. Для этого в рабочем домене для каждого объекта информатизации создаются организационные подразделения, куда помещаются все ресурсы соответствующих объектов. Для каждого такого организационного подразделения создаются группы безопасности. Этим группам безопасности делегируются полномочия на осуществление конкретных операций. Локальные администраторы получают полномочия на проведение операций с объектами в организационных подразделениях своих объектов за счет членства в соответствующих группах безопасности.
^
5.2.6.1.4Структура организационных подразделений

Структура организационных подразделений (ОП) должна отражать территориально–производственную и организационную модель РИАМС. Основным критерием создания организационных подразделений является необходимость решения задач управления объектами и ресурсами сети, а также задач разграничения доступа.

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

  1. Для административных доменов riams.local и test.local структура организационных подразделений не проектируется.

  2. Для рабочего домена riams.rkomi.ru предлагается набор организационных подразделений в следующем составе:

  • Организационное подразделение Servers, предназначенное для размещения объектов всех основных типов серверов системы. Для каждого типа серверов (серверы почтовой системы, файловые серверы, серверы печати, серверы удаленного доступа, прокси-серверы и т.д.) создаются отдельные вложенные организационные подразделения: Exchange Servers, File Servers, Print Servers, Terminal Servers и т.д., в которых размещаются учетные записи соответствующих серверов.

  • Организационное подразделение Organizations, в котором будут располагаться учетные записи всех пользователей рабочего домена и опубликованные в ЕСК общие папки. Внутри данного подразделения создаются ОП второго уровня с названиями организаций, входящих в РИАМС: Минздрав РК, ТФОМС, МЦОД г. Воркута, МБУ «Воргашорская больница», ГУ РК «Кардиологический диспансер» и т.д. В организационных подразделениях с названиями организаций при необходимости создаются подразделения с названиями объектов информатизации и отдельных площадок (включая ФАПы). Структура подразделений должна соответствовать организационной структуре медицинского учреждения или органа управления здравоохранением и может включать: Департамент, Отдел и т.д., при этом в организационных подразделениях департаментов и отделов располагаются учетные записи пользователей и опубликованные в ЕСК общие папки.

  • Организационное подразделение System Accounts, в котором будут располагаться административные и специализированные учетные записи, группы безопасности и группы распространения (списки рассылки). Внутри данного подразделения создаются ОП второго уровня с названиями содержащихся в них объектов, такие, как, например, «Административные учетные записи», «Группы», «Почтовые ресурсы», «Ресурсы общего доступа» и т.д. В организационных подразделениях второго уровня при необходимости создаются вложенные подразделения – в соответствии с территориально-производственным признаком или по названию ресурса, доступ к которому определяют соответствующие специализированные учетные записи или группы безопасности.

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

Предложенные положения организации структуры ОП ЕСК отвечают следующим основным требованиям:

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

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

Структура сайтов единой службы каталога должна отражать физическую структуру сети РИАМС. При проектировании структуры сайтов и межсайтовых связей единой службы каталога РИАМС должен применяться следующий подход:

  • Каждой территориально обособленной площадке должен соответствовать собственный сайт.

  • В случае, если на площадке не будет развертываться ни одного контроллера домена, и площадка имеет канал связи только с одной другой площадкой, на которой будут развертываться контроллеры домена, допускается объединить данные площадки в один сайт Active Directory.

  • Топология межсайтовых связей должна отражать топологию физических каналов связи.

Размещение контроллеров домена на объектах информатизации РИАМС должно производиться исходя из следующих данных:

  • Количество пользователей на объекте;

  • Наличие программного обеспечения, для которого необходимо наличие локальных контроллеров домена;

  • Количество и качество каналов связи на данном объекте информатизации.

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

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

  • На каждом объекте, где расположены серверы службы электронной почты, должно быть развернуто не менее двух серверов глобального каталога;

  • На объекте с 200 пользователями и более должно быть развернуто не менее двух контроллеров домена, один из которых назначается сервером глобального каталога;

  • При количестве пользователей более 50 развертывается не менее одного контроллера домена;

  • При количестве пользователей менее 50 контроллеры домена развертываются только на тех объектах, на которых размещается программное обеспечение и службы, требующие наличия контроллера домена. В данном случае контроллер домена развертывается в режиме только для чтения (RODC);

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

С целью стандартизации именования объектов проектируемой ЕСК РИАМС, предлагается принять за основу стандарт именований объектов, принятый в ЕСК аппарата Правительства Республики Коми.
^

5.2.6.2Служба электронной почты


Служба электронной почты должна обеспечивать:

  • Обмен почтовыми сообщениями как внутри РИАМС, между организациями и пользователями системы, так и с внешними почтовыми системами;

  • Централизованное управление маршрутами доставки сообщений как внутри РИАМС, так и при взаимодействии с внешними почтовыми системами;

  • Хранение почтовых ящиков и общих папок в базах данных серверов службы электронной почты;

  • Работу с адресными книгами, в том числе с глобальными списками всех получателей РИАМС, а также возможности быстрого поиска получателей;

  • Управление почтовыми ящиками пользователей;

  • Работу с календарями, контактами, задачами, как общими, так и персональными;

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

  • Возможности по делегированию управления функциями службы электронной почты объектам единой службы каталогов;

  • Предоставление доступа к базовым функциям и данным службы с использованием стандартных интерфейсов и протоколов, таких, как HTTP/HTTPS, POP3/SMTP, IMAP4, MAPI/RPC, ActiveSync;

  • Защиту почты от вирусов и нежелательных сообщений (спама).

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

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

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

  • развертывания отказоустойчивого кластера для основных почтовых серверов РИАМС;

  • настройки постоянной резервной репликации для почтовых ящиков пользователей;

  • развертывания кластера балансировки сетевой нагрузки для серверов клиентского доступа.

Количество и размещение серверов службы электронной почты на других объектах РИАМС должно быть определено на стадии технического проектирования общесистемных сервисов РИАМС с учетом данных об объектах РИАМС, количестве пользователей на объектах, а также с учетом требований обеспечения отказоустойчивости и распределения нагрузки.
^

5.2.6.3Служба предоставления доступа к сети Интернет


Централизованная служба доступа к сети Интернет должна обеспечивать:

  • Межсетевое экранирование и фильтрация данных на разных уровнях (пакетном, прикладном);

  • Управление доступом к сети Интернет пользователей РИАМС в соответствии с групповыми политиками, определенными с помощью единой службы каталога, в том числе: разрешение/запрет доступа по категориям сайтов, разрешение/запрет доступа по типам сетевых протоколов и адресу назначения, контроль доступа по времени (напр., в рабочее/нерабочее время), разрешение/запрет доступа по именам файлов или их типам;

  • Управление пропускной способностью канала доступа к Интернет в зависимости от категории пользователя РИАМС;

  • Кэширование прямого и обратного соединения (прокси-сервер);

  • Антивирусную защиту при подключении пользователей РИАМС к Интернет.
^

5.2.6.4Базовые сетевые службы (DNS, DHCP, WINS)


Базовая сетевая служба DNS должна обеспечивать:

  • создание и поддержание зон различных типов: основных, дополнительных, зон-заглушек;

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

  • поддержку записей, регистрируемых контроллерами доменов и серверами единой службы каталога;

  • делегирование доменов;

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

  • динамическую регистрацию имен и IP-адресов узлов по запросу клиентов или сервера(ов) DHCP, в том числе и защищенную (регистрацию только после проверки подлинности);

  • возможность автоматической очистки зон путем удаления из них устаревших записей;

  • прямое преобразование (разрешение) DNS-имен узлов в IP-адреса, и обратное преобразование IP-адресов в DNS-имена;

  • разрешение имен узлов, как внутренних, так и узлов в Интернете;

  • возможность пересылки неразрешенных запросов к серверам WINS.

Базовая сетевая служба DHCP должна обеспечивать:

  • авторизацию серверов DHCP в единой службе каталога;

  • создание и поддержание областей DHCP с диапазонами IP адресов и другими параметрами;

  • ведение журнала работы службы;

  • периодическое резервное копирование баз данных DHCP;

  • выдача клиентам DHCP параметров для работы в сети TCP/IP (основные параметры: IP-адрес и маска подсети; дополнительные параметры: адрес основного шлюза, сервера(ов) DNS и WINS, имени домена и т.д.);

  • возможность резервирования IP-адресов;

  • возможность создания классов клиентов и выдачи различных дополнительных параметров для клиентов разных классов;

  • возможность регистрации выданных IP-адресов и имен клиентов в прямых и обратных зонах службы DNS.

Базовая сетевая служба WINS должна обеспечивать:

  • репликацию данных WINS между разными серверами;

  • периодическое резервное копирование баз данных WINS;

  • динамическую регистрацию имен NetBIOS и соответствующих им IP-адресов;

  • разрешение имен NetBIOS в IP-адреса и, наоборот, предоставление для IP-адреса списка зарегистрированных имен NetBIOS;

  • поддержку статических записей для компьютеров и устройств, не являющихся клиентами NetBIOS.

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

5.2.6.5Файловая служба


Файловая служба должна обеспечить:

  • надежное хранение пользовательских и других файловых данных на серверах;

  • предоставление файлов в совместный доступ по сети;

  • защиту и аудит доступа;

  • отказоустойчивость и высокую доступность данных;

  • доступ к предыдущим версиям и восстановление удаленных файлов;

  • контроль объемов и типов данных, хранящихся на серверах, с помощью пользовательских квот и шаблонов фильтров.

Файловые серверы должны быть развернуты на вычислительных мощностях Регионального центра обработки данных, а также на объектах РИАМС типов МЦОД-В, МЦОД-УП, МЦОД-И, МЦОД-У, ЛПУ-С (Таблица 2).

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

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

5.2.6.6Единая служба времени


Единая служба времени должна обеспечивать:

  • централизованное управление единым временным пространством леса единой службы каталога;

  • синхронизацию времени между всеми узлами в рамках леса единой службы каталога;

  • механизмы для коррекции и компенсирования хода часов операционных систем серверов и рабочих станций;

  • синхронизацию с внешним источником времени по протоколу NTP.

Служба синхронизации времени должна быть развернута в варианте, обеспечивающем постоянную доступность для всех серверов, компьютеров, служб и приложений РИАМС.
^

5.2.6.7Службы удаленного развертывания, обновления и администрирования программного обеспечения


Службы удаленного развертывания должны позволять:

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

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

  • Автоматически устанавливать обновления системного, базового и прикладного ПО рабочих станций с централизованного сервера обновлений.

При проектировании служб удаленного развертывания целесообразно рассмотреть применение служб WDS (Windows Deployment Services) и WSUS (Windows Server Update Services), входящих в состав серверной операционной системы Windows Server 2008 R2.
^

5.2.7Региональный удостоверяющий центр


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

В качестве удостоверяющего центра РИАМС необходимо использовать Региональный удостоверяющий центр Республики Коми, созданный на основании Постановления Правительства Республики Коми от 31 декабря 2008 г. № 390 «Об удостоверяющем центре органов исполнительной власти Республики Коми, государственных органов Республики Коми, образованных Главой Республики Коми или Правительством Республики Коми, и о мерах по применению средств электронной цифровой подписи». Региональный удостоверяющий центр Республики Коми удовлетворяет всем функциональным требованиям, а также требованиям информационной безопасности.

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

  • Регистрацию и изготовление сертификатов пользователей по заявлениям;

  • Уникальность сертификатов и достоверности указанных сведений;

  • Ведение и хранение реестра сертификатов открытых ключей пользователей в течении установленного срока;

  • Аннулирование, приостановление и возобновление действия сертификатов пользователей;

  • Подтверждение ЭЦП в электронных документах;

  • Выдачу сертификатов открытых ключей пользователям.

При приеме заявлений пользователей о выдаче электронного сертификата, Региональный УЦ должен проводить верификацию заявок пользователей на основании информации об учетной записи пользователя в Единой службе каталога (см. п. 5.2.6.1).

Региональный удостоверяющий центр Республики Коми должен взаимодействовать с Федеральным удостоверяющим центром ЕГИС в сфере здравоохранения, создаваемом в Федеральном уровне Системы в соответствии с Концепцией создания Единой Государственной Информационной Системы в сфере здравоохранения, утвержденной приказом Минздравсоцразвития РФ от 28.04.2011.

В процессе взаимодействия с Федеральным удостоверяющим центром Региональный УЦ должен:

  • отправлять все изменения реестра сертификатов, произведенные в РК, включая информацию о вновь выданных сертификатах, а также об аннулированных, приостановленных и возобновленных сертификатах;

  • принимать изменения реестра сертификатов федерального уровня, производя обновление реестра сертификатов.

Оператором Регионального удостоверяющего центра Республики Коми является Государственное бюджетное учреждение Республики Коми «Центр безопасности информации», который также включается в общую структуру управления РИАМС (раздел 6).
^

5.2.8Единый портал системы здравоохранения Республики Коми


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

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

Единый портал системы здравоохранения Республики Коми должен включать следующие подсистемы:

  • Подсистема «Внешний портал»;

  • Подсистема «Внутренний портал»;

  • Подсистема управления структурой и содержанием портала.

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

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

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

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

  • Редакторы портала – пользователи портала, отвечающие за информационное наполнение портала, оформление разделов и страниц портала, предназначенных как для внешних, так и для внутренних пользователей;

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

5.2.8.1Подсистема «Внешний портал»


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

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

  • Отображение опубликованных материалов;

  • Предоставление информационных сервисов прикладными информационными системами;

  • Предоставление доступа к прикладным информационным системам, интегрированным с порталом – для авторизованных пользователей;

  • Навигацию по разделам портала;

  • Отображение карты портала;

  • Поиск опубликованных на портале материалов.

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

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

5.2.8.2Подсистема «Внутренний портал»


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

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

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

  • Отображение опубликованных на портале материалов – в соответствии с профилем и ролью пользователя, заданными групповыми политиками ЕСК;

  • Доступ к прикладным информационным системам, интегрированным с порталом   в соответствии с профилем и ролью пользователя, заданными групповыми политиками ЕСК;

  • Сохранение истории операций и действий пользователя;

  • Отображение и редактирование профиля пользователя;

  • Навигацию по разделам портала;

  • Отображение карты портала;

  • Поиск опубликованных на портале материалов и сервисов.

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

5.2.8.3Подсистема управления структурой и содержанием портала


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

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

  • Управление структурой портала;

  • Управление информационным наполнением портала.

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

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

  • Раздел;

  • Страница.

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

  • Отображение структуры портала;

  • Добавление структурного элемента в структуру портала;

  • Редактирование свойств структурного элемента;

  • Публикация структурного элемента;

  • Прекращение публикации структурного элемента;

  • Изменение расположения структурного элемента в структуре портала;

  • Удаление структурного элемента из структуры портала.

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

  • Документ;

  • Статья;

  • Изображение;

  • Ссылка;

  • Сервис и т.п.

5.2.9Контакт-центр


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

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

  • Программно-аппаратный комплекс приема, маршрутизации и регистрации телефонных обращений;

  • Базы знаний.

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

  • Модуль определения телефонного номера;

  • Модуль автоматической маршрутизации звонка (IVR);

  • Модуль распределения звонков между сотрудниками контакт-центра;

  • Модуль мониторинга и записи разговоров;

  • Модуль работы с входящей корреспонденцией;

  • Модуль работы с электронной почтой;

  • Модуль регистрации обращений;

  • Модуль сбора статистики;

  • Модуль интеграционного взаимодействия.

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

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

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

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

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

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

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

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

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

Особенностью реализации программно-аппаратного комплекса в рамках РИАМС является многократное использование его функциональности для реализации различных целей:

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

  • Осуществление первого уровня технической поддержки пользователей единого информационного портала регионального уровня;

  • Осуществление первого уровня технической поддержки сотрудников медицинских учреждений по работе с системами РИАМС.

В связи с необходимостью осуществления оперативного взаимодействия с разными категориями обращений необходимо создание и ведение баз знаний, содержащих наиболее часто встречающиеся вопросы и ответы на них в разрезе целей использования контакт-центра. Базы знаний должны содержать механизмы, обеспечивающие ввод, систематизацию, изменение, хранение и удаление информации, быстрый поиск и средства максимально удобной для сотрудников контакт-центра визуализации запрошенных данных.
1   ...   6   7   8   9   10   11   12   13   ...   16

Ваша оценка этого документа будет первой.
Ваша оценка:

Похожие:

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconРеспублики Коми «Республиканский информационный центр оценки качества образования»
Перечень учреждений профессионального образования Республики Коми, 11 осуществляющих набор по медицинским...
Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconМинистерство экономического развития республики коми управление труда охрана и условия труда в республике

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОбщая информация о деятельности муниципального учреждения «Городская Поликлиника №3 п. Водный» мму
Почтовый адрес: 169336, Республика Коми, Ухта г, Водный пгт, Гагарина ул., д. 21
Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconВы чувствуете себя неважно после простуды?
Республика Коми, г. Сыктывкар ул. Гаражная 4/1, 24-92-77 инн 1101041326, лицензия № ло-11-01-000263...
Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОб утверждении территориальной программы государственных гарантий бесплатного оказания гражданам
В соответствии с постановлением Правительства Российской Федерации от 21 октября 2011 г. N 856 "о...
Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОбщий план структурной организации зубов 27 общая характеристика эмали. Принципы сруктурной организации

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconНекоторые аспекты правового регулирования в сфере здравоохранения республики беларусь
Министерство здравоохранения Республики Беларусь Республиканский научно-практический центр медицинских...
Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОб утверждении территориальной программы государственных гарантий бесплатного оказания гражданам

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОб утверждении территориальной программы государственных гарантий бесплатного оказания гражданам

Задачи риамс 12 3 характеристика объекта информатизации 14 1 Общая характеристика региона Республика Коми 14 2 Система здравоохранения Республики Коми 14 iconОб утверждении территориальной программы государственных гарантий бесплатного оказания гражданам

Разместите кнопку на своём сайте:
Медицина


База данных защищена авторским правом ©MedZnate 2000-2019
обратиться к администрации | правообладателям | пользователям
Документы