lex.justice.mdlex.justice.md/userfiles/file/2015/mo 258-261 ru/raport... · web viewВ...

Утвержден

Постановлением Счетной палаты

№28 от 17 июля 2015 года

ОТЧЕТ

АУДИТА С ЭЛЕМЕНТАМИ ЭФФЕКТИВНОСТИ

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

достижение предложенной цели?”

Список аббревиатурПО Публичный органВБ Всемирный банкЦЭУ Центр электронного управления Э-управление Электронное управление IaaS Инфраструктура в качестве услуги

ЦСТ Государственное предприятие ,,Центр специальных

телекоммуникаций”

MCloud Общая информационная инфраструктура Правительства

Республики Молдова, функционирующая на основе технологии «cloud computing»

MPass Правительственная электронная услуга по аутентификации и

контролю доступа (MPass)Mpay Правительственная услуга электронных платежей

MSign Правительственная электронная услуга, интегрированная

цифровой подписью (MSign)МИТС Министерство информационных технологий и связи PaaS Платформа в качестве услуги

PAD Документ по утверждению/оценке Проекта (Project Appraisal

Document от 07.05.2011)

ППРРД Правительственная платформа регистров и разрешительных документов (eng. ECMP – Enterprise Content Management Platform)

SaaS Программное обеспечение в качестве услуги ИС Информационная система ИТ Информационные технологии ИТК Информационные технологии и коммуникации

Страница 1 из 56

Терминология

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

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

Соглашение об уровне услуг (SLA) (ITILv3): соглашение между поставщиком ИТ- услуг и клиентом. SLA описывает ИТ-услугу, документирует целевые показатели уровня услуги и определяет ответственность поставщика ИТ-услуг и клиента. Одно SLA может распространяться на множество ИТ-услуг или множество клиентов.

Приложения ППРРД (ПП №717/29.08.2014) – информатическая система, разработанная на основе ППРРД в рамках одной пользовательской среды.

Back-up/резервное копирование (ITILv3): копирование данных для защиты от потери или уничтожения целостности или доступности оригинала.

Бенефициары приложений ППРРД (ПП №717/29.08.2014) – физические лица, юридические лица и государственные служащие;

Бенефициары ППРРД (в дальнейшем – бенефициары) (ПП №717/29.08.2014) – министерства, другие подведомственные Правительству центральные административные органы и организационные структуры, находящиеся в сфере их компетенции (подведомственные административные органы, публичные учреждения и государственные предприятия, в которых министерство или другой центральный административный орган выступает в качестве учредителя), а также автономные публичные учреждения, юридические лица частного права, которые используют ППРРД для развития информационных систем;

Бенефициары платформы MCloud (в дальнейшем – бенефициары) (ПП №128/20.02.2014) – министерства, другие центральные административные органы, подведомственные Правительству, и организационные структуры, входящие в сферу их компетенции, иные публичные органы, а также государственные предприятия, другие юридические лица частного права, использующие платформу MCloud для поставки услуг конечным пользователям (физическим или юридическим лицам);

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

Сloud computing («информационное облако») (ПП №128/20.02.2014) – модель поставки ИТ-услуг, которая позволяет осуществлять сетевой доступ по запросу к конфигурируемой совокупности вычислительных ресурсов, подлежащих виртуализации (к примеру сети, серверы, оборудование для хранения, приложения и


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

Клиент (ITILv3): лицо, которое покупает товары или услуги. Клиентом или поставщиком ИТ-услуг является лицо или группа лиц, которые определяют и договариваются о целях уровня услуги.

Договор (ITILv3): обязательное правовое соглашение между двумя и более сторонами.

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

Поставщик услуг ППРРД (в дальнейшем – поставщик) (ПП №717/29.08.2014) – Центр электронного управления (E-Government), владелец ППРРД, ответственный за продвижение, сохранение, функционирование и непрерывное развитие ППРРД;

Поставщик правительственной платформы регистров и разрешительных документов, в том числе 4 приложений (далее - поставщик платформы) – выигравшая Компания в результате международных торгов (договор №14/ICB/2.2 от 07.05.2013) .

Поставщик услуг платформы MCloud (в дальнейшем – поставщик) (ПП №128/20.02.2014)– Центр электронного управления (E-Government), уполномоченный поставлять электронные услуги платформы MCloud;

Служба поддержки пользователей (Help Desk/Service Desk) (ITILv3): единая точка контакта между поставщиком услуг и пользователями. Типичная служба поддержки пользователей управляет инцидентами и требованиями к услугам, а также осуществляет связь с пользователями.

Инфраструктура в качестве услуги (в дальнейшем – IaaS) (ПП №128/20.02.2014) – модель поставки ИТ-услуг и ИТ-ресурсов, при которой поставщик обеспечивает только наличие ИТ-ресурсов, запрошенных бенефициаром, а остальные работы, сопутствующие действию и администрированию информационных систем, возлагаются на бенефициара.

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

Управление непрерывностью бизнеса (BCM) (ITILv3): бизнес - процесс, ответственный за управление рисками, которые могут отрицательно и существенно повлиять на бизнес.

Управление ИТ-услугами (ITSM) (ITILv3): внедрение и управление качественными ИТ-услугами, которые соответствуют потребностям бизнеса. Управление ИТ-услугами


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

Технико-технологический оператор платформы MCloud (в дальнейшем – оператор) (ПП №128/20.02.2014) – Государственное предприятие «Центр специальных телекоммуникаций», которое функционирует в соответствии с законодательством Республики Молдова и осуществляет размещение и администрирование платформы MCloud согласно настоящему Положению и договору, подписанному с поставщиком.

Участник ППРРД (ПП №717/29.08.2014) – поставщик услуг ППРРД, технико-технологический оператор, бенефициар ППРРД, бенефициар приложений ППРРД или другой участник оперирования и использования ППРРД;

Участники платформы MCloud (ПП №128/20.02.2014) – поставщик услуг платформы MCloud, технико-технологический оператор платформы MCloud, бенефициары платформы MCloud, другие участники администрирования платформы MCloud;

Правительственная платформа регистров и разрешительных документов (ППРРД) (ПП №717/29.08.2014) – технологическая платформа, являющаяся частью платформы MCloud, предназначенная для развития информационных систем ведения электронных регистров и/или выдачи разрешительных документов, в частности разрешений.

Платформа MCloud (ПП №128/20.02.2014) – общая правительственная информационная инфраструктура, функционирующая на основе технологии «cloud computing»;

План (ITILv3): подробный проект, описывающий необходимую деятельность и ресурсы для достижения цели. Например, план, который внедряет новую ИТ-услугу или процесс. ISO/IEC 20000 требует наличия плана управления для каждого процесса и управления ИТ-услугами.

Поставщик ИТ-услуг (ITILv3): поставщик услуг, который предоставляет ИТ-услуги внутренним или внешним клиентам.

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

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

ИТ-услуга (ITILv3): услуга, предоставляемая одному и более клиентам поставщиком ИТ-услуг. ИТ-услуга базируется на использовании информационной технологии и


поддерживает процессы бизнеса клиента. ИТ-услуга состоит из комбинации лиц, процессов и технологий и должна быть определена в соглашении об уровне услуг/SLA.

Программное обеспечение (software) в качестве услуги (в дальнейшем – SaaS) (ПП №128/20.02.2014) – модель поставки ИТ-услуг и ИТ-ресурсов, при которой бенефициару предоставляются решения ИТ в полном объеме. При такой модели поставщик обеспечивает компоненты, необходимые для функционирования и администрирования решения ИТ, в том числе данных, а часть обязанностей по администрированию услуги возлагается на бенефициара.

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

Пользовательская среда (ПП №717/29.08.2014): – рабочее пространство, предоставленное одному бенефициару в целях развития одного или нескольких приложений ППРРД. Информатические системы одной пользовательской среды будут использовать общие ресурсы (лицензии, номенклатурные листы, пользователи и пр.);

Платформа в качестве услуги (в дальнейшем – PaaS) (ПП №128/20.02.2014) – модель поставки ИТ-услуг и ИТ-ресурсов, при которой бенефициару предоставляются компоненты программного обеспечения (software), которые он может использовать для внедрения собственных ИТ-услуг. При такой модели поставщик обеспечивает компоненты, необходимые для функционирования и администрирования решений ИТ, используемых бенефициаром, а ответственность за администрирование услуги возлагается на бенефициара;

Резюме

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

ППРРД находится в процессе внедрения, владельцем ее является Центр электронного управления, который обеспечивает администрирование и ее развитие согласно полномочиям, делегированным Правительством и Государственной канцелярией1. После некоторых первоначальных анализов отмечается факт, что 1 Постановление Правительства №717 от 29.08.2014 „О правительственной платформе регистров и разрешительных документов (ППРРД)” (далее - ПП №717 от 29.08.2014).


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

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

Полученная ППРРД представляет собой систему программного обеспечения, которая использует услуги устройств хранения данных (hardware), возможности подключения и поддержку общей правительственной информационной платформы (MCloud). Первоначальная стоимость разработки ППРРД вместе с четырьмя полностью функциональными информационными системами, генерируемыми ППРРД, знакомыми под названием ,,Приложения", составляет 650,0 тыс. долларов США, которая на момент проведения аудита в результате внесенных поправок составила 684,7 тыс. долларов США. Проект находится на этапе развития, основные элементы новой системы программного обеспечения существуют, являются оперативными и были уже признаны адекватными. Из 4 приложений, которые должны быть разработаны в рамках проекта ППРРД, два являются операционными и признаны соответствующими, в то время как два других находятся в процессе разработки и запланированы для последующего запуска.

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

Посредством этого аудита Счетная палата попыталась дать ответ на вопрос, если „Правительственная платформа регистров и разрешительных документов (ППРРД) обеспечивает достижение предложенной цели?, представляя собой успешное решение в области развития ИТ, в том числе в будущем. Для ответа на этот вопрос Счетная палата попыталась установить, если деятельность, процессы и контроли, осуществляемые ЦЭУ в стремлении успешно реализовать в целом проект развития ППРРД, предоставляя в то же время ИТ-услуги тем правительственным учреждениям, которые уже обладают функциональными приложениями, базирующимися на ППРРД, были начаты и управлялись до мая 2015 года надлежащим образом, а также в какой мере внесенные изменения и другие релевантные факторы, которые вмешались в ходе выполнения, были в состоянии иметь существенное влияние на основные выявленные недостатки.


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

Общий вывод Счетной палаты заключается в том, что в целом с некоторыми резервами по улучшению ППРРД, которая находится на этапе внедрения/разработки, является перспективным потенциалом для получения желаемого воздействия, представляя собой существенный вызов для оцифровки публичных услуг в Республике Молдова. Вместе с тем, аудитом установлены некоторые проблемы, условия, а также другие факторы, которые могут отрицательно повлиять на успех проекта ППРРД и, соответственно, на бенефициаров услуг платформы. Идентификация рисков для успешного развития проекта видится как серьезная ответственность, а адекватное управление этими рисками ответственными сторонами считается важным и имеет максимальное значение. Если ЦЭУ учтет указания аудита, изложенные в настоящем Отчете, и примет конкретные меры по внедрению внесенных рекомендаций, а также проанализирует и устранит неисправности системы, выявленные частными специализированными компаниями в аудите информационной безопасности, тогда цели, предложенные как для ППРРД, так и для MCloud в общем, могут быть достигнуты. Одновременно отмечаем, что для реализации широкого спектра деятельности, предусмотренного в Стратегической программе реформирования управления (е-преобразование), ЦЭУ нуждается как в политической поддержке, так и в поддержке со стороны партнеров/бенефициаров/учредителя и др. Без поддержки и конструктивного сотрудничества между сторонами будет тяжело достичь основных задач, предусмотренных в документах утвержденных политик.

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

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

1 вопрос аудита.

Как контролировал ЦЭУ разработку платформы и ее приложений?

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


деятельности постоянно переоценивались и контролировались.


Как содействовал ЦЭУ использованию регистров с технической точки зрения?

Обучение пользователей ППРРД и документация системы, предоставленные поставщиком услуг аутсорсинга в соответствии с первоначальным договором, оказались сами по себе недостаточными для поддержки развития платформы и ее приложений. В результате было закуплено дополнительное обучение для Domain Experts, увеличив стоимость договора в условиях, которых можно было избежать путем применения ЦЭУ наиболее передовых практик управления проектом и рисками.


Как определены требования эффективно сти и качества ППРРД (как составляющей части платформы MCloud)?

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


Каким способом ЦЭУ осуществляет мониторин г соглашений с поставщиками услуг?

Несмотря на то, что приложены совместные усилия ЦЭУ и ЦСТ для осуществления мониторинга эффективности платформы MCloud (ППРРД является составной частью MCloud) в соответствии с установленными/взятыми критериями, аудит отмечает, что такой мониторинг еще не является систематическим. Определение и утверждение базы, охватывающей управление эффективностью, которая в настоящее время находится на этапе тестирования и внедрения, является необходимым условием для осуществления эффективного мониторинга, а также для принятия прозрачного и своевременного режима отчетности.


ЦЭУ внедрял SLA согласно требованиям бенефициар ов?


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


Как управляется безопасность системы приложений, базирующихся на ППРРД (как части платформы MCloud)?

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


Как управляются механизмы back-up данных и восстановления после катастроф для ППРРД и приложений, базирующихся на ППРРД (как части платформы MCloud)?

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

Рекомендации аудита

Центру электронного управления совместно с ЦСТ:1. обеспечить укрепление и совершенствование базы управления ИТ-услугами

путем установления показателей эффективности и качества в положениях


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

2. завершить и утвердить в установленном порядке „Операционную модель общей правительственной технологической платформы (MCloud) и поставляемых из соответствующей платформы услуг”. Центру электронного управления:

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

4. установить эффективный механизм отбора потенциальных курсантов с целью обеспечения устойчивости проектов в области ИТ;

5. завершить и внести в установленном порядке проект типового соглашения по оказанию услуг от ППРРД, обеспечивая, чтобы конечная версия была способна отвечать требованиям деятельности и законодательства бенефициаров (что касается наличности ИТ, гибкости услуг, качества услуг, способности роста, уровня поддержки, планирования непрерывности, безопасности и ограничения заявления);

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

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

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

ЦЭУ и Министерству окружающей среды:

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

Введение

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


эффективное и более ответственное управление благодаря интеллигентным инвестициям в ИТ и их массовому использованию в государственном секторе2.

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

ППРРД сама является системой программного обеспечения. Она не охватывает устройства хранения данных (hardware) в традиционном смысле, но использует устройства хранения данных (hardware) и подключение к общей правительственной технологической платформе (MCloud), платформе Cloud Computing, которая была развита (1 фаза) и находится во владении ЦЭУ, обеспечивая администрирование и функциональность согласно мандату, предоставленному Правительству и Государственной канцелярии. Получая услуги MCloud, ППРРД имеет в распоряжении преимущества, которые предоставляет Cloud Computing дополнительно к традиционным способам поставки ИТ-услуг, которые состоят в рентабельном использовании ресурсов, в том числе путем использования существующих устройств хранения данных, расходов по администрированию и управлению, затрат на обслуживание и безопасность, все разделенные с другими платформами и системами, базирующимися на MCloud.

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

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

Потенциал ППРРД значительно способствовать реализации Стратегической программы технологической модернизации управления трудно недооценить. Если 2 Постановление Правительства №710 от 20.09.2011 „Об утверждении Стратегической программы технологической модернизации управления (е-Преобразование)” //Официальный монитор №156-159/780, 23.09.2011 (далее - Постановление Правительства №710 от 20.09.2011).


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

Адекватные условия для максимизации выгод могут включать:

1. В основном, адекватный характер ППРРД, чтобы служить в качестве виртуальной мастерской, где могут относительно легко, быстро и эффективно развиваться жизнеспособные приложения, базирующиеся на ППРРД. 2. Наличие технических компетенций и менеджмента, необходимых для оперирования и администрирования ППРРД.3. Внедрение устойчивых техник менеджмента рисков и проектов по управлению развития аутсорсинга ППРРД и первоначальных приложений.4. Поддержку в дальнейшем со стороны граждан и Правительства Республики Молдова, а также международных агентов по развитию и других лиц, вовлеченных в проект развития ППРРД, в том числе поставщика платформы.5. Владельцев и потенциальных владельцев приложений, базирующихся на ППРРД, доверяющих способности ППРРД быть единственным местом для осуществления электронной деятельности. 6. Владельцев и потенциальных владельцев приложений, базирующихся на ППРРД, уверенных, что развитые и размещенные в ППРРД приложения могут и будут выполнять их потребности в деятельности и уставные обязательства.7. Адекватную правовую базу.

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

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

3 Согласно техническим требованиям ППРРД, составной части Договора №14/ICB/2.2. от 07.05.2013 между ЦЭУ и Поставщиком платформы.


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

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

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

В конечном счете, необходимо отметить, что аудит системы ППРРД не был без проблем и трудностей, которые включают:

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

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


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

Сфера и подход к аудиту

Счетная палата, в качестве Высшего органа аудита, реализующего внешний публичный аудит, будучи мотивированной повышенным интересом со стороны общества, международных организаций и зарубежных доноров по реформированию управления путем внедрения и эффективного использования ИТ, инициировала и провела аудит информационных технологий с элементами эффективности на тему: „Правительственная платформа регистров и разрешительных документов (ППРРД) обеспечивает достижение предложенной цели?”. Аудиторская миссия была запланирована и реализована на основании Программы аудиторской деятельности на 2015 год5 и в соответствии с положениями Международных стандартов аудита, применяемых Счетной палатой6, соответствующих пособий аудита7 и передовыми практиками в области аудита ИТ

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

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

В этом контексте аудит имел в качестве цели предоставить ответы на следующие вопросы:

1. Как контролировал ЦЭУ разработку платформы и ее приложений?2. Как содействовал ЦЭУ использованию регистров с технической точки зрения?3. Как определены требования к эффективности и качеству ППРРД?4. Каким способом ЦЭУ осуществляет мониторинг соглашений с поставщиками услуг? 5. ЦЭУ внедрял SLA согласно требованиям бенефициаров?

5 Программа аудиторской деятельности на 2015 год, утвержденная Постановлением Счетной палаты №57 от 08.12.2014 (с последующими изменениями).6 ISSAI 100 „Основополагающие принципы аудита публичного сектора”, ISSAI 300 „Основополагающие принципы аудита эффективности”.7 Пособие по аудиту эффективности Счетной палаты, утвержденное Постановлением Счетной палаты №37 от 17.06.2010; Пособие по аудиту информационных технологий, утвержденное Постановлением Счетной палаты №69 от 30.12.2010.


6. Как управляется безопасность системы приложений, базирующихся на ППРРД?7. Как управляются механизмы back-up данных и восстановления после катастроф для ППРРД и приложений, базирующихся на ППРРД?

Критерии аудита и его источники

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

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

- соответствующая нормативно-законодательная база в данной области;- внутренняя нормативная база ЦЭУ, в том числе планы тестирования, план управления проектом, отчеты о прогрессе, договора об оказании услуг, протоколы и др.; - передовые международные практики в области ИТ, соответствующие международные стандарты и др.;

Критерии аудита, идентифицированные из указанных источников с целью анализа эффективности реализуемого ЦЭУ проекта, являются:

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

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


критериев аудита и проанализировала международную соответствующую специализированную литературу.

Сфера аудита охватила реализацию соответствующих мероприятий за период 2013 г. – май 2015 года посредством ЦЭУ, ЦСТ, Государственной канцелярии, других органов, непосредственно вовлеченных в разработку приложений на основе ППРРД.

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

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

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

Констатации аудита

1. Как контролировал ЦЭУ разработку платформы и ее приложений?

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

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

Пересмотром соответствующих правительственных постановлений8 установлено, что ЦЭУ, будучи ответственным за функционирование и непрерывное развитие ППРРД, которая в настоящий момент находится в процессе осуществления, выступает в качестве владельца и поставщика услуг ППРРД для обеспечения выполнения задач в своей деятельности.8 Постановление Правительства №717 от 29.08.2014 „О правительственной платформе регистров и разрешительных документов (ППРРД)” (далее - ПП №717 от 29.08.2014).


Согласно передовым международным практикам, для осуществления контроля развития платформ ИТ и, в основном, некоторых проектов этого же типа и охвата, должны существовать требования к обязательной системе управления проектами. Как правило, цикл развития может быть разложен по фазам или отдельным этапам, каждый с различными требованиями контроля со стороны руководства, для которых были развиты часто используемые инструменты, процессы и техники менеджмента. В этом отношении аудитор руководствовался и использовал в качестве критерия технического регламента „Процессы жизненного цикла программного обеспечения" RT 38370656 - 002:2006, утвержденного МИТС.9

В начальной стадии развития ППРРД анализ ситуации показал, что:

„Правительство имеет три основные категории приложений, развитие которых может стать эффективным путем внедрения общей технологической платформы: Системы управления регистрами, Системы е-программирования и Системы е-автоматизации. Общая технологическая платформа обоснована вследствие высокого уровня сходства между информационными задачами, мета-структуры и потоками деятельности, а также общими функциональными и нефункциональными требованиями, действующими для большинства этих систем. Ответом на эту ситуацию будет то, что мы называем правительственной платформой регистров и разрешительных документов (ППРРД) (Enterprise Content Management Platform (ECMP)). Создание такой платформы значительно повысит эффективность развития информационных систем (что касается бюджета и времени развития), их содержания и качество данных. Это также облегчит обмен данными между государственными информационными системами и будет способствовать интегрированию правительственных ресурсов на семантическом, организационном и техническом уровнях".10

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

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

Закупка услуг аутсорсинга была произведена с использованием процедур конкурентоспособных международных торгов (ICB), указанных в Пособии Всемирного банка: Закупки товаров, работ и неконсультационных услуг в рамках кредитов МБРР и кредитов и грантов МАР со стороны кредиторов Всемирного банка, издание января 2011 г., которое отражает роль Всемирного банка как значимого источника финансирования. Не сообщается об опасениях относительно

9 Приказ МИТС №78 от 01.06.2006.10 Документы тендера - Раздел VI. (Bidding Documents - Section VI). Технические требования (в том числе график внедрения) (Technical Requirements (Including Implementation Schedule) - 0.2. Задачи бизнеса покупателя (Business Objectives of the Purchaser).


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

ЦЭУ предоставил аудитору документ по планированию управления проектом - „План проекта и методологии, используемые при внедрении проекта ППРРД, в том числе 4 информационных систем” (далее – План проекта), так, как были разработаны поставщиком платформы, который в основном выполняет договорные требования. Этот документ планирования был подвергнут минимум 2 пересмотрам, оба в январе 2015 года, для внесения поправок в договор, появившихся в ходе выполнения. Оригинальная версия разработанного Плана проекта была согласована обеими сторонами в июне 2013 года.

График внедрения, предусмотренный в документах планирования, показывает, что сроки проекта запаздывают на 13 месяцев до августа 2015 года. Согласно первоначальному графику внедрения, предусматривалось завершить проект до июля 2014 года. На рисунке №1 можно заметить факт превышения срока внедрения приложения №3 на 194 дня, а также увеличения срока разработки приложения №4 (замененного) от 120 до 195 дней.

Рисунок №1

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

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


Данные из рисунка №2 выявляют реальные затраты, связанные с разработкой ППРРД и 4 приложений, которые превысили на 34,7 тыс. долларов США первоначальную сумму договора в размере 650,0 тыс. долларов США. Эта ситуация обусловлена, в первую очередь, поправками, связанными с отказом от одного приложения в пользу другого, более сложными, а также необходимостью выделения средств для дополнительного обучения.

Рисунок №2

0200000400000600000800000

650000 16250073125 73125 73125

73125

34695

108119

Cost PGRAP și 4 aplicații

Cost inițial Cost suplimentar

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

В этом отношении аудит отмечает, что до мая 2015 года в первоначальный договор было внесено 5 поправок (смотреть приложение №2), имея в основе, по необходимости, 6 заявлений по внесению изменений, согласованных сторонами, из которых 3 поправки привели к увеличению размера/стоимости договора. Аудит признает, что изменения были произведены в соответствии со стандартной документацией, согласованной ВБ. Все-таки отмечается, что как согласованные заявления по внесению изменений, так и поправки к договору не отражают влияние изменений на период гарантии системы, а также не все изменения, включенные в поправки, аргументированы заявлениями по внесению изменений. Можно привести пример поправки №4 от 27.11.2014, согласно которой в результате изменений условия 12.1. Договора, по компоненту обучения стоимость была снижена с 13,0 тыс. долларов США до 9,1 тыс. долларов США, а также снижения, увеличения других затрат. Также отмечается согласованное заявление об изменении под №003 от 04.11.2014 об исключении определенных компонентов (услуги Help Desk с обучением по ее использованию и определенной лицензии), которое приведет к снижению стоимости/размера договора на сумму 19,946 тыс. долларов США. Согласно изменениям, ресурсы, в которых нет больше потребности (на общую сумму 19,946 тыс. долларов США), должны быть перераспределены для реализации заявления по изменению касательно дополнительного обучения для бенефициаров/пользователей приложения Государственного регистра контролей (размером 9,1 тыс. долларов США), для оставшейся суммы не было указано назначение. Так, отмечается, что для аудитора


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

Аудит отмечает, что основные задачи деятельности ППРРД, отраженные в ПП №717 от 29.09.2015, являются адекватными и в основном соответствуют констатациям анализа первоначальной ситуации. Они являются следующими:

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

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

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

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

Кроме того, специфическими задачами деятельности Государственной канцелярии и ЦЭУ, как детально указано в документах по торгам, являются следующие:

1. предоставить Правительству РМ гибкий и эффективный инструмент, который позволит быстро внедрить новые государственные информационные системы с небольшим развитием или вообще без него со стороны клиента;2. интегрировать ППРРД в MCloud, включая свои услуги на уровне

платформы: подлинность и контроль доступа, уведомление, электронные платежи, ведение журналов, цифровая подпись.

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

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

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


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

- затраты для добавления функциональности MPay, вместе с другими изменениями по повторному моделированию и конфигурации, были оценены поставщиком платформы в сумме 16,851 тыс. долларов США (в конце аудиторской миссии этот аспект остался на уровне запроса/оценки без принятия решения по согласованию соответствующих изменений).- Договорная стоимость для разработки новой информационной системы для Министерства транспорта и дорожной инфраструктуры, запоздалое дополнение к проекту, которое в первую очередь добавило функциональность MPay, достигла примерно 108,1 тыс. долларов США, с ростом на 48% к стоимости разработки оригинальных информационных систем №1, №2, №3 и №4.

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

2. Не было разработано и положение о фактическом/в реальном мире тестировании адекватного характера системы для использования Domain Experts как легко используемого и быстрого инструмента развития информационных систем э-управления. Наоборот, стоимость повторного моделирования рабочих потоков и изменения конфигураций системы, в том числе для дополнения эффективной функциональности приложения №1 путем включения MPay, было оценено поставщиком платформы в сумме 16,851 тыс. долларов США или с ростом на 23% против первоначально предложенной стоимости развития регистра.

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

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


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

2. Как содействовал ЦЭУ использованию регистров с технической точки зрения?

Обучение пользователей ППРРД и документация системы, предоставленные поставщиком услуг аутсорсинга в соответствии с первоначальным договором, оказались сами по себе недостаточными для поддержки развития платформы и ее приложений. В результате было закуплено дополнительное обучение для Domain Experts, увеличив стоимость договора в условиях, которых можно было избежать путем применения ЦЭУ наиболее передовых практик управления проектом и рисками.

Согласно Договору №14/ICB/2.2 от 7 мая 2013 года между ЦЭУ и поставщиком платформы, последний оказывает услуги по обучению ППРРД и 4 приложений. Проведенные обучения были следующих видов:

Изучение платформы: использование платформы (5 дней * 8 ч.) для 11 курсантов = 6 Domain Experts (от ЦПО, бенефициаров 4 приложений), 3 координаторов (которые впоследствии будут обучать экспертов Domain experts) + 2 представителя ЦЭУ;

Администрирование платформы: (3 дня * 8 ч.) для 5 курсантов = 4 управляющих (+1 со стороны ЦЭУ).

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

Изучение решения: использование решения (5 дней * 8 ч.) для 12 курсантов, которые представляют 12 координаторов из 4 министерств; Администрирование решения: (3 дня * 8 ч.) для 8 курсантов, которые представляют 4 управляющих и 4 координаторов.

Из соответствующих условий договора с поставщиком платформы очевидно, что обучение по использованию и администрированию приложений покрывается обучением, предоставленным в целом для 12 координаторов, в среднем по три лица из каждого ЦПО бенефициара. Было предложено, что после участия на курсах, предоставленных поставщиком платформы, эти координаторы могут передать свои знания о приложениях любому из своих коллег, которые нуждаются в этих знаниях. Аналогично, план из договора предусматривал, что пользователи Domain Expert ППРРД сначала сами будут обучаться, а затем получат дополнительную подготовку от координаторов.

Договор с поставщиком платформы (39.1.3.) предусматривает, что: „Нет необходимости в изменении по причине любого недостатка поставщика при осуществлении своих операций согласно договору, который не считается изменением, такое изменение не приводит к корректировке цены договора..." Этот пункт подтверждается R6.4.3. технических требований (составной части договора), который предусматривает, что в период гарантии поставщика оказывается техническая


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

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

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

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

ЦЭУ запросил предоставление дополнительного обучения путем Запроса об изменении №007 от 16.01.2015 (Договор №14/ ICB / 2.2 от 7 мая 2013 года) для Domain Experts, который работает на ППРРД, в размере 11,343 тыс. долларов США.

Если вследствие обучения, предусмотренного в договоре, будет получен ожидаемый результат (а именно, если предварительно обученные координаторы будут способны предоставить дополнительное обучение для Domain Experts в соответствии с требованиями (согласно техническому условию R6.2.4)), или если поставщик платформы был бы обязан путем договора актуализировать обучение для Domain Experts в соответствии с условием 39.1.3. и техническим требованием R6.4.3., не было бы необходимости нести эти дополнительные расходы.

В любом случае, в январе 2015 года было заказано дополнительное обучение для 15 лиц Domain Experts по дополнительной стоимости 11,343 тыс. долларов США. Новое обучение было обосновано отдельно ,,сложностью платформы ПРРД" и попыткой повысить уровень передачи знаний участникам на основании накопленного опыта в предыдущем аналогичном обучении. Оно включало предложение от поставщика платформы ограничить обучение только для тех лиц, которые соответствуют определенным техническим предпосылкам, с перспективы развития знаний.

Так, может быть отрицательным факт, что материализовался сообщенный риск поставщиком платформы и ЦЭУ (что обучение для Domain Experts на начальной стадии обучения может не достичь цели), а стоимость принятия однажды


материализованного этого риска была полностью понесена ЦЭУ вопреки договорным условиям.

В соответствии с этим же договором между ЦЭУ и поставщиком платформы, последний должен предоставить документы, а именно: Пособие ППРРД, Пособие Domain Experts для конфигурации ППРРД, материалы по обучению, методологии по созданию приложений, базирующихся на ППРРД, и пособия по использованию и администрированию для каждого приложения. В соответствии с документом под заглавием „План проекта и методологии, используемые при внедрении проекта ППРРД, в том числе 4 информационных систем”, эти пособия должны быть актуализированы в зависимости от потребностей для отражения изменений, вносимых в приложения, после того, как были сданы в производство.

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

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

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

Experts по сравнению с техническими полномочиями, необходимыми для разработки приложений ППРРД;

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

ЦПО не были в полной мере заинтересованы о назначении соответствующих лиц для обучения в качестве координаторов и Domain Experts как для платформы, так и для решений, которые они должны администрировать и ежедневно использовать в своей деятельности;

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

недостаточное обучение по использованию ППРРД по сравнению с реальными потребностями;

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

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

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


эффективностью поставщика, а ЦЭУ не оптимизировал контроль над экономией услуги аутсорсинга.

3. Как определены требования эффективности и качества ППРРД (как составляющей части платформы MCloud)?

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

Учитывая тот факт, что ЦЭУ, в качестве владельца и поставщика услуг ППРРД, в целях осуществления полномочий, которыми был наделен согласно соответствующей нормативной базе13, поставляет аутсорсинговые услуги, аудит оценил соглашения/договора, заключенные ЦЭУ на поставку качественных ИТ-услуг не только для размещения самой ППРРД, но также для передачи в пользование бенефициарам, которые базируются на приложениях из ППРРД для удовлетворения потребностей деятельности и уставных обязательств. Качественные ИТ-услуги могут быть определены как ИТ-услуги или ИТ-процессы, которые способны предоставлять предусмотренные ценности. Могут применяться и другие определения, но в области управления ИТ они будут иметь такое же значение.

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

В качестве назначенного поставщика обеих платформ - MCloud и ППРРД, ЦЭУ несет ответственность за14:

11 Операционная модель Общей правительственной технологической платформы (Mcloud) и услуг, поставляемых из соответствующей платформы (далее – Операционная модель). 12 Документы по управлению проектом в отношениях с разработчиком ППРРД и ее приложений.13 Согласно Постановлению Правительства №717 от 29.08.2014, ЦЭУ имеет (среди других) следующие обязанности:

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

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


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

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

Перечисленные обязанности требуют, чтобы ЦЭУ участвовал в проектировании и управлении ИТ-услугами, как в качестве бенефициара ИТ-услуг с MCloud, размещенной и администрируемой ЦСТ, так и как поставщик ИТ-услуг платформы (для бенефициаров ППРРД).

В соответствии с Постановлением Правительства №128 от 20.02.2014, ЦЭУ, в качестве поставщика услуг с платформы MCloud, должен заключать с Государственным предприятием „Центр специальных телекоммуникаций” (назначенным в качестве технико-технологического оператора платформы MCloud) договор о размещении и администрировании общей правительственной технологической платформы (MCloud).15 Аудит рассмотрел указанный договор, исходя из того, что:

1. сама ППРРД размещена на платформе MCloud;2. приложения, разработанные на основе ППРРД, размещены на MCloud;3. функциональность ППРРД зависит от способности использовать и

взаимодействовать с другими услугами, размещенными на MCloud, такими, как MPay и MPass;

4. понятие „технико-технологического оператора ППРРД”, согласно ПП №717 от 29.08.2014, по смыслу соответствует понятию, определенному в ПП №128 от 20.02.2014, следовательно, технико-технологическим оператором ППРРД является также ЦСТ.

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

Стандарты контроля процесса COBIT (4.1.) требуют четкого определения характеристик услуг и требований деятельности/ мероприятий в рамках соглашения или договора относительно уровня услуг между поставщиком ИТ-услуг и бенефициаром. Они должны иметь обязательный и исполнительный характер, установленный в соответствии с договором. Процессы управления на уровне услуг между бенефициаром и поставщиком услуг должны поддерживать постоянное 14 Постановление Правительства №128 от 20.02.2014 (общие полномочия участников платформы MCloud).15 ПП №128 от 20.02.2014 (п.8.4.).


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

Договор об оказании услуг17, который считается соответствующим для ППРРД, фактически подписан между ЦЭУ (в качестве бенефициара услуг) и ЦСТ (в качестве поставщика услуг) и вступил в силу в январе 2015 года. Данный договор распространяется на предоставление услуг по администрированию общей правительственной технологической платформы (MCloud) на период 2015 года.

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

В договоре рекомендовано, чтобы при оказании услуги поставщик руководствовался набором передовых практик в области ИТ - Infrastructure Library (ITIL) 3 уровня зрелости, признанным на международном уровне как источник для руководства и надлежащей практики, а также Архитектурой безопасности общей правительственной технологической платформы MCloud18.

ITIL 3 Уровня зрелости представляет собой совокупность передового опыта, применяемого для оказания ИТ-услуг в сложных операционных средах, таких ситуаций, в которых ответственность за аспекты, связанные с предоставлением услуг, разделяется между многими партнерами. Аудитор не провел официальную оценку соответствия ЦСТ практикам ITIL 3 уровня зрелости, и не видит никакой пользы от этого на данный момент, но отмечает тот факт, что большие различия между операционной передовой практикой в области управления ИТ-услугами, находящимися на 2 уровне и теми, которые находятся на 3 уровне, могут стать очевидными путем анализа записей. В самых простых терминах, это происходит потому, что ITIL 3 уровня зрелости вводит и описывает формализованные партнерства, гарантируемый уровень ИТ-услуг и зависимость от проверяемых и документированных процессов для непрерывного улучшения услуги и достижения связанных с ними целей, в то время как согласно 2 уровню, управление ИТ-услугами может в дальнейшем достичь своих целей контролируемым способом, но делает это без того, чтобы полагаться на эти легко проверяемые практики.

16 Приказ Министерства информационных технологий и связи №94 от 17.09.2009 „Об утверждении некоторых технических регламентов”.17 Договор №3001-02 от 19 января 201 года „Об оказании услуг по администрированию общей правительственной технологической платформы (MCloud)”.18 Архитектура безопасности общей правительственной технологической платформы (MCloud), утвержденная Приказом Государственной канцелярии №380 от 03.11.2014.


Договор также определяет права, ответственности и обязательства ЦЭУ и ЦСТ по поставке услуг по администрированию MCloud, на которой размещены ППРРД и приложения, базирующиеся на ППРРД, в аспекте услуг IaaS (инфраструктура). Для нынешних и потенциальных бенефициаров услуг ППРРД являются важными положения, касающиеся администрирования тех качеств ИТ-услуг, которые необходимы для обеспечения бенефициару возможности осуществлять свои уставные функции и потребности деятельности в использовании ППРРД. ЦЭУ не имеет договора с ЦСТ относительно платформы ППРРД, учитывая, что она в настоящее время находится на стадии внедрения/разработки, под управлением поставщика платформы. В связи с этим, ЦЭУ заключил договор с поставщиком платформы19.

План управления качеством и методология, утвержденная ЦЭУ для использования поставщиком платформы в развитии ППРРД и первых 4 приложений, содержит показатели качества, которые должны быть выполнены:

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

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

Вышеуказанный договор между ЦЭУ и ЦСТ четко определяет лишь одну характеристику услуги, а именно – доступность, однако без конкретного установления ее минимального уровня. В то время, как Архитектура безопасности определяет минимальный уровень доступности услуги 97,5%, договором допускается интервал, за который могут применяться финансовые санкции в случае недоступности услуги от 99,97% до 72,99%. Согласно договору, эффективность доступности на минимальном уровне, установленном в Архитектуре безопасности, может обусловить применение финансовых санкций ЦСТ в размере 5% от общей месячной стоимости услуг, в то время как доступность на нижнем уровне диапазона, предусмотренного в договоре, может привести к наложению штрафа в размере до 10%.

19 Договор №14/ICB/2.2. от 07.05.2013 между ЦЭУ и поставщиком платформы.Страница 28 из 56

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

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

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

Аудит отмечает, что в соответствии с действующим договором и для руководства и присоединения к передовым практикам ITIL, в рамках взаимоотношений по администрированию эффективности платформы MCloud, ЦСТ и ЦЭУ разработали и используют/внедряют „Операционную модель общей правительственной технологической платформы (MCloud) и услуг, предоставленных из соответствующей платформы” – документ, находящийся на стадии проекта и тестирования и который должен быть скорректирован и утвержден, содержащий некоторые критерии эффективности, процедуры их управления и мониторинга, а также методы отчетности. Документ описывает операционную модель, реализованную совместно ЦЭУ и ЦСТ с целью обеспечения функционирования и развития платформы MCloud и связанных с ней услуг, и применяется для платформы MCloud и предоставляемых из нее услуг, из области ответственности ЦЭУ в рамках осуществления программы е-Преобразования управления.

Вместе с тем, приложение 2 этой модели предусматривает ежемесячную гарантированную доступность платформы 99,97%. Операционная модель также показывает, что услуга типа IaaS (инфраструктура) доступна 7 дней в неделю, с непрерывным графиком. Гарантируемый период согласованного уровня доступности услуг - между 8 и 20 часами в рабочие дни. Вне гарантированного периода доступность услуг будет обеспечиваться по принципу „наилучшие усилия”, которая также определяет стандарты согласования уровня услуг для проведения работ по обслуживанию, а также время реагирования и разрешения, для решения инцидентов, которые затрагивают платформу MCloud и ее услуги. Помимо этого, содержание логов инцидентов и отчетов об измерении эффективности предусмотрены в приложении к

20 Приказ Министерства информационных технологий и связи №94 от 17.09.2009 „Об утверждении некоторых технических регламентов”.


Модели. Однако, этот документ находится еще в стадии разработки/завершения и еще не имеет юридической силы, не являясь составной частью договора между ЦЭУ и ЦСТ.

В отдельном приложении к указанному договору перечислены и услуги по типу деятельности, которые должны быть поставлены как часть управления инфраструктурой MCloud. Эти услуги включают: обслуживание серверов; обслуживание емкости запоминающего устройства; управление инфраструктурой хранения; управление сетью, виртуализацию, инфраструктуру для автоматизации и самообслуживания; управление безопасностью MCloud и управление Virtual Desktop Infrastructure (VDI). Вместе с тем, аудит отмечает, что не указаны цели, определенные для этих элементов эффективности системы в самом договоре или его приложениях.

Пока еще не были определены целевые меры, специфичные для MCloud, касающиеся непрерывности услуги, надежности, способности восстановления, ремонтопригодности и устойчивости ни для одной услуги инфраструктуры (где применимо). Например, в то время как поставщик услуг обязан по договору "принять все необходимые меры для предотвращения и оперативного устранения неисправностей, возникших в инфраструктуре, связанной с предоставлением услуг, а также для ликвидации последствий и понесенного ущерба", в договоре или любом отдельном действующем SLA между ЦСТ и ЦЭУ не указано максимальное время остановки (время, необходимое для восстановления компонента обратно в рабочее состояние после сбоя).

Помимо технических соображений договора определены следующие условия:• Договор предоставляет поставщику время до 24 часов для того, чтобы

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

• Поставщик должен зарегистрировать и разрешать, в пределах своей компетенции, все жалобы и уведомления, полученные от бенефициара, но не установлены предельные сроки для их решения в договоре или любом отдельном действующем SLA между ЦСТ и ЦЭУ по использованию MCloud для размещения ППРРД;

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

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


арбитражный процесс не предусмотрен в договоре или любом отдельном действующем SLA между ЦСТ и ЦЭУ по использованию MCloud для размещения ППРРД.

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

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

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

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


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

Аналогично, отсутствие четких договорных условий, касающихся возможности судебного урегулирования вопросов в случае серьезного спора между ЦЭУ и ЦСТ, обусловит риск потери услуги в течение длительного времени, пока эти споры будут разрешены. В худшем случае, если эффективный механизм независимого арбитража не может урегулировать разногласия между сторонами, существует риск досрочного расторжения договора, что приведет к полной остановке MCloud и ее услуг, в том числе ППРРД.

4. Каким способом ЦЭУ осуществляет мониторинг соглашений с поставщиками услуг?

Несмотря на то, что приложены совместные усилия ЦЭУ и ЦСТ для осуществления мониторинга эффективности платформы MCloud (ППРРД является составной частью MCloud) в соответствии с установленными/взятыми критериями, аудит отмечает, что такой мониторинг еще не является систематическим. Определение и утверждение базы, охватывающей управление эффективностью, которая в настоящее время находится на этапе тестирования и внедрения, является необходимым условием для эффективного мониторинга, а также для принятия прозрачного и своевременного режима отчетности.

Национальные21 и международные регламентирования, признанные и применяемые в Республике Молдова22, четко предусматривают требование о наличии договора/соглашения между поставщиком и заказчиком об уровне и качестве услуг, чтобы обеспечить постоянный контроль над эффективностью услуги. Вместе с тем, соответствующая нормативная база ясно указывает на необходимость мониторинга использования ресурсов из платформы MCloud, оценивая потребности в ресурсах для эффективного функционирования платформы MCloud, а также для мониторинга соблюдения показателей эффективности услуг платформы MCloud и принятия всех мер по их улучшению, как со стороны поставщика (ЦЭУ), так и со стороны оператора (ЦСТ). В этом же контексте, Технические регламенты23 указывают, что „Процесс мониторинга должен осуществлять постоянное слежение за показателями эффективности предоставления публичных услуг”.

Рассмотрение положений Договора между ЦЭУ и ЦСТ показывает, что он включает в себя упомянутые ранее положения. Вместе с тем, Договор предусматривает, что ЦЭУ должен "запрашивать у Поставщика информацию об услугах, оказываемых MCloud, показателях использования платформы MCloud в контексте предоставления услуг".

21 Приказ МИТС №94 от 17.09.2009. Постановления Правительства №717 от 29.08.2014 и №128 от 22.02.2014.22 Международные стандарты (ISO / IEC 20000, ITIL, ISO 27001).23 Раздел 7 „Мониторинг процесса предоставления публичных услуг” из приложения №2 к Приказу МИТС №94 от 17.09.2009.


Положения договора содержат только один показатель эффективности (доступность). Приложение №1 к Договору содержит перечень услуг аутсорсинга по ЦЭУ, которые необходимо мониторизировать, но без указания показателей эффективности и порядка их расчета. В противном случае, приложение №1 также предусматривает требование, чтобы сообщить о реальной эффективности для каждой из услуг, предоставляемых ЦСТ, где отмечается, что ЦСТ предоставит "периодические отчеты (ежедневно/еженедельно/ежемесячно) о стадии осуществляемой деятельности, в том числе об инцидентах, заявках и установленных показателей эффективности".

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

Для руководства и присоединения с передовым практикам ITIL, ЦСТ администрирует и осуществляет мониторинг показателей эффективности платформы MCloud в соответствии с „Операционной моделью” – документом, находящимся в стадии проекта, который должен быть скорректирован и утвержден. Он описывает операционную модель, реализованную совместно ЦЭУ и ЦСТ, в целях обеспечения функционирования и развития платформы MCloud и связанных с ней услуг (приложение №1 к Договору) и распространяется на общую правительственную платформу MCloud и услуги, поставленные в рамках соответствующей платформы, из зоны ответственности ЦЭУ, как части реализации программы е-Преобразования управления, в том числе на услуги ППРРД.

Для обеспечения мониторинга и контроля работы ППРРД, ЦСТ обеспечивает функциональность модуля автоматической периодической отчетности, который обновляет показатели технической эффективности в ходе внедрения ППРРД. Что касается мониторинга ППРРД, ЦСТ регулярно измеряет некоторые аспекты технической эффективности системы и реализует рекомендации ЦЭУ. Мониторинг услуг, ресурсов MCloud на уровне платформы осуществляется согласно процедурам, установленным в упомянутой „Операционной модели”, посредством:

1. системы Help Desk - единой точки контакта и технической поддержки, предоставленной ЦСТ для ЦЭУ;

2. автоматизированного мониторинга на уровне платформы показателей эффективности с помощью специальных инструментов на уровне платформы MCloud со стороны ЦЭУ;

3. проведения периодических оперативных заседаний (каждый месяц с интервалом в 2 недели), в рамках которых анализируется состояние ресурсов MCloud, текущие констатации, статус талонов, открытых в Help Desk.


Имеющиеся доказательства и прямые наблюдения аудитора подтверждают частое проведение заседаний, в ходе которых обсуждаются вопросы операционной деятельности (в общем/целом режиме). Однако, аудитор не отметил случаи, в которых была бы обсуждена ситуация относительно качества и эффективности всех услуг, указанных в приложении №1 к Договору №3001-02 от 19 января 2015 года, заключенному между ЦЭУ и ЦСТ.

Аудитор отмечает, что ЦЭУ и ЦСТ проводят периодические общие оперативные встречи, каждые две недели, для анализа состояния ресурсов MCloud, обсуждения текущих проблем и пересмотр статуса талонов, открытых на платформе поддержки Help Desk. Документирование результатов заседаний осуществляется в соответствии с формой отчетности „Шаблон Отчета по мониторингу платформы MCloud”, предусмотренной в приложении №3 к „Операционной модели”. Рассмотрение аудитом отчетности по мониторингу показывает, что эти периодические оперативные встречи между ЦСТ и ЦЭУ не предоставляют:

1. подробный анализ всех услуг по администрирования платформы MCloud, оказываемых ЦСТ;

2. периодические отчеты измерений от ЦСТ, подтверждая, что она соответствует согласованным требованиям для доступности системы;

3. назначение конкретных лиц, ответственных за решение новых проблем, которые возникают;

4. указаний по предельным срокам для разрешения инцидентов (как указано в приложении №2 к проекту „Операционной модели”); или

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

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

Тот факт, что ЦСТ не предоставляет регулярные отчеты по мониторингу качества всех услуг, указанных в приложении №1 к Договору №3001-02 от 19 января 2015 года, снижает эффективность контроля ЦЭУ за оказанием контрактованных услуг MCloud относительно сроков, сферы применения и качества. В этом контексте, гарантируя, что MCloud выполняет необходимый минимальный стандарт эффективности, ЦЭУ берет на себя в одностороннем порядке большую ответственность, без обеспечения формального покрытия и документированных доказательств.

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


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

5. ЦЭУ внедрял SLA согласно требованиям бенефициаров?

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

Технические регламенты24 устанавливают необходимость, цель, процессы и требования документированных соглашений об уровне обслуживания, применяемые к оказанию электронных услуг в публичном секторе Республики Молдова. Вместе с тем, они определяют основные требования к организации процесса предоставления публичных услуг, связанные с безопасностью и качеством, условиями их реализации и применения, а также критерии правильной организации и эффективной оценки соответствия оказываемых услуг, которые являются сопоставимыми с основными определениями и практиками контроля, находящимися в признанных на международном уровне рамках, таких, как COBIT 4.1. Как и в рамках COBIT, Технические регламенты описывают меры, необходимые для поддержания соответствия требований деятельности пользователей с оказанием ИТ-услуг. Так, в процессе предоставления публичных услуг необходимо выполнить следующие процессы:

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

Также, Постановление Правительства №128 от 20.02.2014 предусматривает, что ЦЭУ определяет параметры и показатели эффективности для услуг платформы MCloud (Раздел 1, п.4.10)). Кроме того, Постановление Правительства №717 от 29.08.2014 ссылается на требование для уровней услуг, которые должны быть согласованы как обязательное условие для доступа к ППРРД, что подтверждает, что пользователи интернета в Республике Молдова ожидают "публичных онлайн услуг, доступных через интернет или мобильный телефон 24 часа в сутки, 7 дней в неделю”.

24 Приказ Министерства информационных технологий и связи №94 от 17.09.2009 „Об утверждении некоторых технических регламентов”.


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

На момент проведения аудита считались действующими 2 из 4 приложений, разработанных поставщиком платформы на ППРРД: "Государственный регистр контролей" и "Регистр природоохранных разрешений на специальное водопользование”. В каждом конкретном случае приложения были внедрены без подписания каких-либо соглашений/договоров, которые должны обеспечить защиту для эффективности и качества услуг.

Хотя, согласно Постановлению Правительства №717 от 29.08.2014 бенефициары ППРРД должны заключать соглашения с ЦЭУ по использованию ППРРД, на основании образца, утвержденного Государственной канцелярией, аудит отмечает, что такое соглашение не было заключено с бенефициарами всех 4 приложений, так как модель Типового соглашения, будучи разработанной, все еще находится в стадии проекта и согласования. Вместе с тем, установлена формализация отношений между ЦЭУ и 3 из 4 бенефициаров ППРРД, владельцев разработанных приложений, в виде соглашений о сотрудничестве, как показано в таблице №1.

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

№ п/п

Название/ орган бенефициар Дата и срок действия

1. Соглашение о сотрудничестве между Министерством окружающей среды Республики Молдова, Фондом Вызовы Тысячелетия Молдовы и Центром электронного управления Молдовы

22.10.2012 Срок действия: 34 месяца

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

29.05.2012 Срок действия: 3 года

3. 3.1. Соглашение о сотрудничестве между Центром электронного управления и Национальным агентством автомобильного транспорта 3.2. Дополнительное соглашение между Центром электронного управления и Национальным агентством автомобильного транспорта №1 от 12/12/2013 к Соглашению о сотрудничестве по внедрению Информационной системы “е-разрешение на транспорте”

12.12.2013Срок действия: 3 года с автоматическим продлением на последующие периоды 03.04.2014 Срок действия: 2 года с автоматическим продлением на последующие периоды

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

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


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

За исключением неопределенных обязательств касательно доступности, не были указаны конкретно уровни эффективности услуги, доступной для держателей приложений ППРРД, ни в договоре между ЦЭУ и ЦСТ (см. вопрос №4 настоящего Отчета аудита), который регламентирует использование услуг с платформы MCloud (применимо и для инфраструктуры ИТ, обслуживающей ППРРД и приложения, базирующиеся на ППРРД). Одновременно аудит отмечает, что проект „Операционной модели” внедряется совместно ЦЭУ и ЦСТ для обеспечения функционирования и развития MCloud, однако, не будучи составной частью договора, соответственно, не имеет юридической силы. Эта Модель описывает роли, стандарты и лучшие практики, ответственность и другие обязательства эффективности услуги и имеет отношение к ППРРД в той мере, в которой она располагается на MCloud. По утверждениям ЦЭУ, „Операционная модель” будет формализована в ближайшем будущем.

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

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

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

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


установленным ЦЭУ25 относительно времени реагирования приложений на ППРРД, оно не должно превышать 5 секунд, часто были зарегистрированы серьезные проблемы, связанные с эффективностью системы. Все операции обрабатываются с опозданием (в некоторых случаях требовалось ~10 минут26 для получения доступа к системе www.rsc.gov.md). К тому же, хотя, согласно договорным положениям, критические проблемы27 поставщик платформы обязан устранить в течение 4 часов, аудитом установлены случаи несоблюдения этого срока. Например, письмом №28-01/107 от 06.04.2015 Главная государственная инспекция по техническому надзору за опасными производственными объектами сообщала о серьезной проблеме, которая возникла 30 марта 2015 года и решение которой длилось до 8 апреля 2015 года.

В контексте, когда согласно соответствующей нормативной базе28 приложения, разработанные на основе ППРРД, будут размещены на платформе MCloud, должны быть заключены соглашения или договоры, по случаю, с ЦЭУ об оказании услуг платформы MCloud, на основе моделей, утвержденных Государственной канцелярией, аудит отмечает, что положения Типового соглашения об оказании услуг с платформы MCloud29 соответствуют обычным требованиям SLA для услуг инфраструктуры (типа IaaS), но не для услуг типа PaaS. Аудитором установлено наличие минимум одного детального соглашения, заключенного между ЦЭУ и бенефициаром (например, Министерство юстиции – Соглашение №MCloud/001/14 от 03.11.2014). Путем внедрения и поддержания такого рода соглашений, договорные условия которых предусматривают непрерывную адаптацию требований деятельности к доступности ИТ-ресурсов, владельцы приложений ППРРД могут чувствовать себя уверенными в том, что они могут выполнять в условиях безопасности свои уставные обязанности, которые требуют использования ППРРД.

Следует отметить и тот факт, что положения соглашений о сотрудничестве, заключенных между ЦЭУ и держателями 3 из 4 приложений, предусматривают условие о передаче информационной системы держателю в администрирование, на основании акта приема-передачи, а впоследствии (по истечении гарантийного срока, установленным договором, заключенным с экономическим оператором, ответственным за разработку приложения) - в управление. Таким образом, хотя на момент аудита функционировали 2 из 4 приложений, 20 марта 2015 года был подписан акт приема-передачи в пользование Информационной системы “Природоохранное разрешение на специальное водопользование”, без заключения соглашения, в котором были бы определены конкретные целевые меры относительно доступности, непрерывности, надежности и возможности восстановления услуги в определенные сроки, согласованные между обеими сторонами (ЦЭУ и бенефициар ППРРД/ Министерство окружающей среды). Вместе с тем аудит отмечает, что хотя положения договора устанавливают гарантийный срок 36 месяцев, который для данного Регистра 25 Технические требования, раздел VI, часть договора с поставщиком платформы (Technical Requirements ICB 5_BDs_ECMP_SectionVI_final, pag. 24, p. R1.31).26 Согласно протоколу Государственной канцелярии от 09.02.2015.27 Договор №14/ICB/2.2.28 Постановление Правительства №717 от 29.08.2014.29 Приказ Государственной канцелярии №305 от 09.09.2014 „Об утверждении Типового соглашения и Типового договора об оказании услуг общей правительственной технологической платформы (MCloud)”.


http://www.rsc.gov.md/

начался 01.01.2015, вышеуказанный акт приема-передачи предусматривает период лишь 24 месяцев.

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

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

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

Как уже упоминалось ранее, ЦЭУ разработал проект Типового соглашения по использованию ППРРД, который на момент проведения аудита находился на этапе согласования/консультирования с компетентными органами в установленном порядке, впоследствии должен быть представлен на утверждение Государственной канцелярией. Аудитор не проверил в деталях проект соглашения/SLA, и не рассмотрел процесс консультации с компетентными органами, ясно то, что стандартизированные официальные соглашения должны содержать меры эффективности оказываемой услуги, с подробным описанием прав и ответственности сторон, которые по своей природе могут быть аналогичными тем, что содержатся в Соглашении о предоставлении услуг с платформы MCloud/ 001/14, отмеченному выше.

6. Как управляется безопасность системы приложений, базирующихся на ППРРД (части платформы MCloud)?

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


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

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

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

1. ISO/IEC 27001:2013

"Информационные технологии - Методы обеспечения безопасности - Системы менеджмента информационной безопасности - Требования "

2. ISO/IEC 27002:2013

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

3. COBIT

Нормативная база по управлению процессами COBIT предусматривает меры для обеспечения безопасности системы и данных в любое время (см. DS5 - Обеспечение безопасности систем). Целью базы передовых практик COBIT является разработка, внедрение, тестирование и мониторинг генерального плана безопасности ИТ, совместимого с ресурсами и культурой безопасности организации.

Архитектуры безопасности, утвержденная Государственной канцелярией31, требует определения уровней безопасности системы и минимальных требований безопасности, которые должны быть внедрены и поддерживаться в процессе эксплуатации платформы MCloud, а также четко устанавливает роли и ответственности, связанные с обеспечением безопасности ИТ, факт, который должен быть оценен как очень полезный документ.

Кроме того, ЦЭУ ("поставщик"), ЦСТ ("оператор") и бенефициары в случае контролей доступа конечных пользователей, все они обязаны взаимодействовать для

30 Постановление Правительства №710 от 20.09.2011 „Об утверждении Стратегической программы технологической модернизации управления (е-Преобразование)”. ОМ №156-159/780 от 23.09.2011.31Приказ Государственной канцелярии №380 от 03.11.2014 „Об утверждении Архитектуры безопасности общей правительственной технологической платформы (MCloud). ОМ №358-363 от 04.12.2014.


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

физическая безопасность центров данных и оборудования для обработки информации (PS 1-8); безопасность сетевой инфраструктуры (NS 1-8); безопасность виртуальной инфраструктуры (VS 1 – 16); контроль доступа и безопасность данных (ADS 1 - 15); мониторинг и тестирование безопасности (SMT 1 -11).

В целом, Архитектура безопасности предусматривает 59 отдельных требований по безопасности системы, связанной с платформой и данными, которые охватывают вышеуказанные области ИТ-инфраструктуры, для которых ЦЭУ и ЦСТ либо несут ответственность, либо являются ответственными. Другие области, в том числе контроль безопасности за разработкой программного обеспечения (software) и практическая реализация контролей также являются частью Архитектуры безопасности.

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

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

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

ADS1 - объем и срок хранения данных должны соответствовать требованиям законодательства, регулирования и деятельности.

В качестве поставщика ППРРД, в ответственность ЦЭУ устанавливаются следующие требования безопасности:

1. ВСЕ требования по физической безопасности центров данных и оборудования для обработки информации (PS 1-8);

2. ВСЕ требования по безопасности сетевой инфраструктуры (NS 1-8);

3. ВСЕ требования по безопасности виртуальной инфраструктуры (VS 1 – 16);

4. НЕКОТОРЫЕ требования в отношении контроля доступа и безопасности данных (ADS 2- 9, ADS11, ADS13, ADS15);

5. ВСЕ требования, касающиеся мониторинга и тестирования безопасности (SMT 1 -11).


В силу своего договора о предоставлении услуг по администрированию общей правительственной технологической платформы (MCloud), ЦЭУ обеспечил ответственность ЦСТ в реализации большинства из вышеуказанных требований безопасности, но из-за ограничений в характере своего договора ЦЭУ остается ответственным за следующие требования:

ADS3 - данные из производственной среды не должны быть воспроизведены или использованы в непроизводственных средах. ADS4 – необходимо внедрить механизмы безопасности для предотвращения утечки данных. ADS5 - необходимо внедрить безопасные механизмы (например, криптографические механизмы) для защиты хранимых данных от несанкционированного доступа и использования, утраты и подделки. ADS6 - необходимо внедрить механизмы резервного копирования (back-up) и дублирования данных для обеспечения соблюдения требований нормативных актов, договоров или деятельности. Тестирование резервных копий должно выполняться в запланированные интервалы. ADS7 - необходимо внедрить механизмы безопасности для защиты резервных копий от несанкционированного доступа и использования, утраты и подделки. SMT4 - записи аудита на уровне виртуальных машин, приложений, баз данных и виртуальных сетей в рамках виртуальной организации, которая фиксирует деятельность пользователей, системных администраторов и операторов системы, но и исключения, ошибки, события безопасности, должны быть получены и храниться в соответствии с:

o требованиями безопасности;

o законодательными, нормативными и договорными требованиями.

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

Аудит отмечает, что нормативная база по регламентированию требований безопасности для услуг типа PaaS, а также ППРРД, обеспечивает минимальные требования безопасности (в соответствии с положениями национальной нормативной базы32, а также передовыми международными практиками в этой области) и описывает (в 15 разделе Архитектуры) большинство областей с потенциальными рисками для безопасности. Таким образом, аудит отмечает, что учитываются, касательно аутсорсинга услуг с платформы MCloud, самые передовые практики в области информационной безопасности (ISO / IEC 27001 и 27002).

32 Приказ МИТС №94 от 2009.Страница 42 из 56

В то же время, Архитектура безопасности устанавливает, что ЦЭУ является единственным ответственным за выполнение обременительных и технических требований безопасности от имени бенефициаров, использующих услуги ППРРД, но только выполнение определенных требований безопасности в настоящее время не отражается в обязательных соглашениях с бенефициарами и может привести к тому, что бенефициары не будут в состоянии доказать, что были реализованы соответствующие меры безопасности в соответствии с ПП №710 от 20.09.2011.

В контексте, в котором ЦЭУ выбрал услуги аутсорсинга, оказываемые как часть инфраструктуры MCloud, необходимо обеспечить направление ЦСТ к тому, что касается функций критических ИТ. ЦЭУ должен также определить четкую процедуру для мониторинга соответствия согласованным требованиям безопасности системы. Этот аспект предусмотрен Постановлением Правительства №717 от 29.08.2014, согласно которому ЦЭУ должен осуществлять постоянный мониторинг выполнения обязанностей оператором ППРРД, соответственно, ЦСТ. Мониторинг и контроль должны проводиться на основе периодической, своевременной отчетности по соответствующей информации в установленном порядке.

Договор между ЦЭУ и ЦСТ, действующий на данный момент33, уточняет, что ЦЭУ должен требовать от ЦСТ обеспечения внедрения им передового опыта и национальных и международных стандартов в целях эффективного администрирования и обеспечения безопасности платформы MCloud. В этом контексте аудит отмечает, что, с целью мониторинга функционирования платформы MCloud, в том числе ППРРД, ЦЭУ организует еженедельные совместные заседания с ЦСТ, на которых обсуждаются неисправности системы, сообщенные Help Desk, статус попыток вторжения и инциденты безопасности на платформе M-Cloud.

Кроме того, в то время как органы, ответственные за контроль и техническое администрирование приложений, разработанных на основе ППРРД, располагают адекватными инструментами для того, чтобы сообщать об инцидентах безопасности (Help Desk, e-mail и по телефону), ЦЭУ не требует от бенефициаров предоставлять информацию о контролях доступа к системе, за которые они несут ответственность в соответствии с требованиями Архитектуры безопасности (ADS 10, 12 и 14), и, следовательно, безопасность на уровне конечного пользователя также не управляется систематически.

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

33 Договор №3001-02 от 19.01.2015.Страница 43 из 56

7. Как управляются механизмы back-up данных и восстановления после катастроф для ППРРД и приложений, базирующихся на ППРРД (части платформы MCloud)?

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

Аудитор стремился установить наличие оперативных планов резервного копирования (back-up) данных и восстановления в случае катастрофы для защиты ППРРД и приложений, базирующихся на ППРРД, которые обслуживаются на MCloud.

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

Требования, установленные в отношении управления непрерывностью, должны включать в себя:

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

2. использование адекватных систем резервирования и восстановления; 3. требования к планам обеспечения непрерывности и восстановления

деятельности.

Одновременно, необходимо выделить требования в отношении резервных мест для обработки информации, в том числе:

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

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

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

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

34 Приказ МИТС №94/2009, Приложение №3, п. 5.10. „Управление непрерывностью деятельности”.Страница 44 из 56

Государственная канцелярия утвердила Архитектуру безопасности для MCloud35 (ИТ-инфраструктуру, обслуживающую ППРРД и базирующихся на ней приложений), которая требует разработки планов непрерывности деятельности, планов восстановления и процедур экстренной помощи в случае бедствий. Документ конкретно предусматривает применение процедур, направленных на обеспечение бесперебойного функционирования платформы MCloud и сопутствующих услуг в случае наступления масштабного инцидента. В частности, в соответствии с той же политикой, ЦЭУ ("поставщик" MCloud, ППРРД и приложений, базирующихся на ППРРД, согласно приказу) и ЦСТ ("оператор" MCloud) обязаны взаимодействовать для того, чтобы обеспечить следующие результаты:

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

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

3. должны быть определены и поддерживаться планы непрерывности деятельности и процедуры восстановления после инцидентов/катастроф для обеспечения непрерывности функционирования платформы и услуг MCloud (PRB7);

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

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

Постановлением Правительства №128 от 20.02.2014 предусмотрено, что участники платформа MCloud должны обеспечить непрерывность каждого вида услуг (IaaS, PaaS и SaaS). В соответствии с этим постановлением ЦЭУ (в качестве поставщика) несет ответственность за разработку, утверждение и пересмотр процедур по обеспечению безопасности платформы MCloud36.

На основании утвержденной Архитектуры безопасности, в качестве поставщика ППРРД Платформа как услуга, ЦЭУ является ответственным за внедрение пакета требований безопасности для платформы, многие из которых переданы ЦСТ в аутсорсинг и описаны в Договоре о MCloud Инфраструктура как услуга. Некоторые требования безопасности, за которые ЦЭУ несет ответственность, но которые не включены в договор об оказании услуг, включают:

35 Регламентировано Приказом Государственной канцелярии №380 от 03.11.2014.36 Постановление Правительства №128 от 20.02.2014„ Общие полномочия участников платформы Mcloud”.


1. ADS6 - должны быть реализованы механизмы резервного копирования (back-up) данных и их дублирование для обеспечения соблюдения нормативных, договорных требований или деятельности. Тестирование резервных копий должно выполняться через запланированные интервалы.

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

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

Хотя проводятся периодические оперативные встречи между ЦЭУ и ЦСТ для обсуждения операционных вопросов и эффективности, связанных с MCloud (ИТ-инфраструктура, обслуживающая ППРРД и, следовательно, приложений, основанных на ППРРД), протоколы этих встреч не показывают, что непрерывность системы обсуждалась в качестве пункта обычной повестки дня. Если мониторинг или управление планами непрерывности услуги обсуждаются менее формально, например, во время телефонных конференций между представителями ЦЭУ и ЦСТ, тогда аудитор не может определить, если эти дискуссии оказали какое-либо влияние, положительное или отрицательное, относительно планирования и управления непрерывностью услуги, поскольку содержание этих переговоров не может быть независимо проверено.

На момент проведения аудита ЦСТ не создает копии платформы MCloud в целом. Кроме того, внедрение фазы MCloud 2, которая находится в процессе реализации, предусматривает обеспечение избыточности платформы MCloud.

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

Что касается ППРРД, на данный момент процедуры резервного копирования выполняются поставщиком платформы на основании договорных положений и в соответствии с процедурами реализации резервных копий для ее компонентов, предусмотренными в „Пособии по установке компонентов в производственной среде ECMP”, 5 версия, разработанной им для ЦЭУ в рамках проекта.

Аудитор также проанализировал констатации в рамках проекта отчета о тестировании безопасности продукта ППРРД в 2015 году, заказанного частной компанией ЦЭУ. Было установлено, что Техническое задание для этой оценки ограничивает область применения аудита безопасности программного обеспечения приложения. Риски, связанные с оборудованием (hardware) и деятельностью человека,


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

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

Бенефициары, которые используют ППРРД Платформа как услуга от ЦЭУ, нуждаются в услуге back-up данных для соблюдения требований Приказа №94, и должны иметь возможность полагаться на соглашения, обязательные для исполнения, имеющие юридическую силу, которые устанавливают ответственность вовлеченных сторон за эти требования безопасности. В настоящее время не существует таких соглашений по защите в действие. В настоящее время проект SLA, который находится в стадии рассмотрения и согласования, может наделить ЦСТ, в качестве поставщика, обязанностью выполнять определенные функции, связанные с непрерывностью услуги и восстановлением данных. В то же время, эти услуги не включены в договор, существующий между ЦЭУ и ЦСТ.

Системы резервного копирования данных (back-up) и восстановления в случае бедствий представляют собой обязательные контроли, призванные уменьшить риск постоянной потери и в значительных объемах существенных публичных данных, или отсутствие таковых, а также непоследовательное формальное управление наряду с отсутствием возможности мониторинга со стороны органа, делегированного осуществлять надзор за надлежащим внедрением проекта, четко указывает на то, что этот риск не контролируется. В частности, существуют резервы относительно предоставления ЦЭУ гарантий бенефициарам приложений в части того, что системы резервного копирования (back-up) и восстановления в случае катастроф являются устойчивыми, надежными и безопасными. Подобная ситуация требует пересмотра и консолидации систем резервного копирования данных и восстановления данных в случае катастрофы, соответствующих для использования ППРРД бенефициарами, которые должны включать, как минимум, оценку услуг по обеспечению непрерывности деятельности, по восстановлению данных в случае бедствий и резервному копированию, доступных ЦЭУ, для того чтобы помочь защитить ППРРД, и бенефициарам, чтобы помочь защитить приложения, основанные на ППРРД.

Общие выводы аудита

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


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

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

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

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

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

4. недостаточное участие ЦПО в процессах по развитию, обучению и администрированию приложений;

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

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

Аудиторская группа Счетной палаты:

Руководитель аудиторской группы,старший государственный контролер

Петру Донцу

Главный государственный контролер Наталья Балабан-Унку

Государственный контролер Владимир Казимир


из 56

Приложение №1

Список источников критериев аудита

I. Законодательно-нормативная база:1. Закон №173 от 28.07.2011 „О ратификации Финансового соглашения между

Республикой Молдова и Международной ассоциацией развития для реализации Проекта "е-Преобразование управления";

2. Закон №235-XVI от 20.07.2006 „Об основных принципах регулирования предпринимательской деятельности”;

3. Закон №229 от 23.09.2010 ,,О государственном внутреннем финансовом контроле”;

4. Постановление Правительства №733 от 28.06.2006 „О концепции электронного правления”;

5. Постановление Правительства №760 от 18.08.2010 „О публичном учреждении "Центр электронного управления" (Е-Government)”;

6. Постановление Правительства №710 от 20.09.2011 „Об утверждении Стратегической программы технологической модернизации управления (е-Преобразование)”;

7. Постановление Правительства №222 от 01.04.2011 „О создании Совета координаторов по электронному преобразованию”;

8. Постановление Правительства №44 от 26.01.2012 „Об утверждении Плана действий на 2012 год по внедрению Стратегической программы технологической модернизации управления (е-Преобразование)”;

9. Постановление Правительства №972 от 21.12.2012 „ Об утверждении Плана действий на 2013 год по внедрению Стратегической программы технологической модернизации управления (е-Преобразование)”;

10. Постановление Правительства №797 от 26.10.2012 „Об утверждении Программы реформирования публичных услуг на 2012-2015 годы”;

11. Постановление Правительства №1096 от 31.12.2013 „Об утверждении Плана действий на 2014 год по внедрению Стратегической программы технологической модернизации управления (е-Преобразование)”, с последующими изменениями и дополнениями;

12. Постановление Правительства №147 от 25.02.2013 „О введении в действие положений Закона №131 от 8 июня 2012 года о государственном контроле предпринимательской деятельности”;

13. Постановление Правительства № 894 от 12.11.2013 „Об организации и функционировании единого окна в области природоохранного разрешения на специальное водопользование”;

14. Постановление Правительства №694 от 05.09.2013 „Об утверждении Общей методологии планирования государственного контроля предпринимательской деятельности на основе анализа критериев риска”;

15. Постановление Правительства №128 от 20.02.2014 „Об общей правительственной технологической платформе (MCloud);

16. Постановление Правительства №717 от 29.08.2014 „О правительственной платформе регистров и разрешительных документов (ППРРД)”;


17. Постановление Правительства №122 от 18.02.2014 „О Программе реформирования публичных услуг на 2014-2016 годы”;

18. Приказ Министерства информационных технологий и связи №78 от 01.06.2006 „Об утверждении технического регламента ,,Процессы жизненного цикла программного обеспечения" RT 38370656 - 002:2006”;

19. Приказ Министерства информационных технологий и связи №94 от 17.09.2009 „Об утверждении некоторых технических регламентов”;

20. Приказ Государственной канцелярии №380 от 03.11.2014 „Об утверждении Архитектуры безопасности общей правительственной технологической платформы (MCloud);

21. Приказ Государственной канцелярии №305 от 09.09.2014 „Об утверждении Типового соглашения и Типового договора об оказании услуг общей правительственной технологической платформы (MCloud)”.

II. Релевантные документы менеджмента проекта:1. Документ по оценке проекта (англ. PAD) Е-Преобразование управления от

07.05.2011;2. Договор №14/ICB/2.2. от 07.05.2013 между ЦЭУ и поставщиком платформы,

включая поправки;3. Договор №3001-02 от 19 января 2015 года об оказании услуг по

администрированию общей правительственной технологической платформы (MCloud);

4. Договор №3001-10 от 11 ноября 2014 года об оказании услуг, связанных с „услугами по размещению оборудования” (предоставление физического пространства и технических средств, необходимых для хранения и подключения соответствующего оборудования);

5. Договор №TS/67-14(3001-03) от 27 мая 2014 об оказании услуг по администрированию общей правительственной технологической платформы (MCloud);

6. Договор №TS/36-14 от 2 января 2014 года об оказании услуг;7. Соглашение о сотрудничестве между Министерством окружающей среды

Республики Молдова с Фондом Вызовы тысячелетия Молдова и Центром электронного управления Молдовы от 22.10.2012;

8. Соглашение о сотрудничестве между Центром электронного управления и Национальным агентством автомобильного транспорта от 12.12.2013;

9. Дополнительное соглашение между Центром электронного управления и Национальным агентством автомобильного транспорта №1 от 12.12.2013 к Соглашению о сотрудничестве по внедрению Информационной системы “е-Разрешение транспорта” от 03.04.2014.

Кроме того, были рассмотрены и проанализированы: 1. документация по торгам;2. внесенные оферты для участия в торгах;3. Проект „Операционной модели общей правительственной технологической

платформы (MCloud) и услуг, поставляемых из соответствующей платформы”;Страница 51 из 56

4. проект „Типового соглашения об оказании услуг с ППРРД”;5. отчеты о состоянии проекта;6. план тестирования;7. результаты тестирования;8. критерии согласования/отказа.

III. Релевантные международные стандарты/практики:1. ISO/IEC 27001:2013 "Информационная технология – Методы обеспечения

безопасности - Системы менеджемента информационной безопасности - Требования";

2. ISO/IEC 27002:2013 "Информационные технологии - Методы обеспечения безопасности - Свод правил по управлению защитой информации";

3. COBIT 4.1. „Техническое задание. Цели контроля. Руководства для управления. Модели зрелости”;

4. ITILv3 „Библиотека инфраструктур информационных технологий”.


Приложение №2

Изменения, внесенные в Договор, заключенный между ЦЭУ и поставщиком платформы

По состоянию на май 2015 года было 5 поправок (дополнительных соглашений) к Договору между ЦЭУ и поставщиком платформы, а именно:

№ п/п

Поправки/ №/число

Что изменено Стоимость договора(доллары США)

1. Поправка №1 от 10.07.2013

Замена менеджера проекта со стороны поставщика платформы. -

2. Поправка №2 от 24.03.2014

Изменение правовой формы поставщика платформы из ООО в АО. -

3. Поправка №3 от 25.07.2014,

1. Была изменена статья 2 Договора: стоимость договора становится 659,1 тыс. долларов США; 2. Изменения в пункте 12.1. путем пополнения на 9,1 тыс. долларов США - дополнительное обучение для бенефициаров (пользователей) Государственного регистра контролей.

659,1 тыс.

4. Поправка №4 от 27.11.2014

1. Статья 2 Договора (стоимость/цена договора) - 672,098 тыс. (73,125 тыс. долларов США исходное значение Приложения 4, приложение 4 обучение – 3,9 тыс. долларов США (гарантия на приложение 4 – 9,75 тыс. долларов США не принимается в расчет); CR 001, 003, 005);2. Замена менеджера проекта со стороны поставщика платформы;3. Изменен пункт 12.1.:

- на b) Оплата за прием в эксплуатацию Приложения 4 заменена – 86,495 тыс. долларов США (первоначально – 68,25 тыс. долларов США), на 18,245 тыс. долларов США больше, чем первоначально;- на c) Услуги, помимо обучения, от стоимости 52,0 тыс. долларов США для операционного приема - разграничение операционного приема для Государственного регистра контроля – 21,45 тыс. долларов США, и транспортного разрешения – 14,3 тыс. долларов США, таким образом, снижение на 16,25 тыс. долларов США по сравнению с первоначальной;- на d) Обучение: снижение стоимости обучения с 13,0 тыс. долларов США до 9,1 тыс. долларов США;- на f) Полная интеграция системы - увеличение суммы для операционного приема полностью интегрированной системы на 14,903 тыс. долларов США, с 65,0 тыс. долларов США до 79,903 тыс. долларов США. Кроме того, оплата за гарантийный период в сумме 52,0 тыс. долларов США делится на: 31,2 тыс.

672,098 тыс.(стоимость договора

увеличивается на 12,998 тыс. долларов США)


долларов США для ППРРД и Приложений 1 и 2, а 20,8 тыс. долларов США для последних 2 приложений. Изменен Раздел "Технические характеристики Приложения VI, C5 и Раздел VI, Е); Приложения Оn-line программирование на прием у органов ЦПО заменяется Приложением e-Разрешение на транспорте.

5. Поправка №5 от 24.04.2015

1. Ст.2 Договора - Стоимость/цена Договора – 684,695 тыс. долларов США;2. Замена менеджера проекта со стороны поставщика платформы;3. Изменения в условиях оплаты (п. 12.1.: - на b) включение затрат на интеграцию ППРРД с Налоговым регистром – 1,254 тыс. долларов США (CO006);- d) Обучение – пополнение на сумму 11,343 тыс. долларов США за дополнительное обучение для Domain Experts.

684,695 тыс. (стоимость договора

увеличивается на 12,597 тыс. долларов США)

Источник. Поправки к Договору, внесенные до мая месяца 2015 года.

В основу поправок легли следующие запросы о внесении изменений:

Заявка/запрос с предложением о внесении поправки

Запрос/предложение по внесению поправки

Приказ о внесении поправок

Причина поправки Цель поправки Поправки

RC001 от 17.05.2014

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

Замена Приложения Оn-line программирование на прием у органов ЦПО Приложением e-Разрешение на транспорте.

-

RC001/02 от 26.09.2014

PO001/2 от 04.11.2014

CO 001 от 05.11.2014

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

Замена Приложения Оn-line программирование на прием у органов ЦПО Приложением e-Разрешение на транспорте.

сумма – 108,119 тыс. долларов США;необходимое время -6,25 месяцев

RC002 от 22.05.2014

CP002 от 02.07.2014

CO002 от 24.07.2014

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

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

сумма – 9,1 тыс. долларов США;необходимое время - 9 дней


RC003 от 25.07.2014

CP003 от 04.11.2014

CO003 от 04.11.2014

a) Не требуется лицензии для Windows Server 2008, учитывая, что ЦЭУ приобрел необходимые лицензии для MCloud после того, как был подписан отдельный договор закупки с поставщиком платформы;b) Не требуется установка услуги help desk и обучение по ее использованию для ППРРД, учитывая, что ЦЭУ имеет help desk, который может быть расширен и на ППРРД.

Перераспределение ресурсов, которые больше не являются необходимыми, согласно техническим требованиям, от Лицензии Windows Server 2008 (3,696 тыс. долларов США) и установки и обучения Help-desk (16,25 тыс. долларов США), на внедрение CP00265,0 тыс. долларов США+9,1 тыс. долларов США - (16,25+3,696).

- уменьшение стоимости договора на сумму 19,946 тыс. долларов США(стоимость договора-639,154 тыс. долларов США)

RC004/2 от 22.10.2014 CEP 004

- - a) Согласно существующим положениям Государственной экологической инспекции, некоторые разрешения должны утверждаться на уровне центрального аппарата Инспекции. Процесс утверждения должен быть продлен таким образом, чтобы инспекторы на местах могли запросить утверждение со стороны центрального аппарата/ управления;b) в соответствии с существующими нормативными положениями относительно ГЭИ и Национального центра общественного здоровья, некоторые виды деятельности, необходимые для утверждения разрешения, должны быть оплачены бенефициаром. Таким образом, необходима интеграция с MPay.

Расширение процесса утверждения на центральном уровне;Интеграция с MPay Регистра вод.

предложенная сумма – 16,851 тыс. долларов США;срок выполнения - 20 рабочих дней

RC005 от 16.09.2014

CP005 от 19.09.2014

CO005 от 27.10.2014

Регистрационный номер документа является комплексным выражением, как правило, состоит из 2 или 3 блоков, разделенных символами/знаками (-./..).

В регистрационном номере документа из Государственного регистра контроля изменить тип данных из number (для чисел, любой тип чисел, целых или десятичных) в string (используемый для данных,

сумма – 1,850 тыс. долларов США;

необходимое время -5 рабочих дней


которые содержат любой текст или ряд символов)

RC006 от 25.09.2014

- - Изменение требований C3R18.03, C3R18.03, C3R18.04 (для Государственного регистра контроля).

- -

-/RC006/2 CP006/2 от 20.02.2015

CO006/2 от 10.03.2015

„Для доступа к юридическим лицам на других приложениях, разработанных на ППРРД ”...„структура данных об юридических лицах должна быть скорректирована и разработан компонент интеграции других приложений с ППРРД на ГРЮЛ (Государственный регистр юридических лиц).”

Разработка компонента интеграции RSUD-FISC на уровне ППРРД

сумма – 1,254 тыс. долларов США;необходимое время

-15 дней

RC007 от 16.01.2015

CP007 от 28.01.2015

CO 007 от 30.01.2015

Учитывая сложность ППРРД и внесенные изменения согласно Поправке 4, требуется дополнительное обучение для Domain Expert для публичных учреждений (не менее 15 участников), которые будут использовать платформу для разработки своих собственных систем, используя ППРРД.

Дополнительное обучение для Domain Experți (ППРРД)

сумма – 11,343 тыс. долларов США;необходимое время -30 чел./дней

Источник. Запросы о внесении изменений, которые лежат в основе поправок.
