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

2. Нормативно-правовая база

    Настоящий регламент разработан на основе следующих законодательных актов Республики Молдова:
    - Закон Республики Молдова «Об авторском праве и смежных правах» № 293-XIII от 23.11.1994;
    - Закон Республики Молдова «О доступе к информации» № 982-XIV от 11.05.2000;
    - Закон Республики Молдова «Об информатизации и государственных информационных ресурсах» № 467-XV от 21.11.2003;
    - Закон Республики Молдова «Об электронном документе и цифровой подписи» № 264-XV от 15.07.2004;
    - Закон Республики Молдова «Об электронной торговле» № 284-XV от 22.07.2004;
    - Закон Республики Молдова «О техническом регулировании» № 420–XVI от 22.12.2006;
    - Закон Республики Молдова «О защите персональных данных» № 17-XVI от 15.02.2007;
    - Закон Республики Молдова «О регистрах» № 71-XVI от 22.03.2007;
    - Закон Республики Молдова «О государственной тайне» № 245 от 27.11.2008.

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

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

4. Цели и задачи

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

5. Предоставление публичных услуг

    5.1. Классификация публичных услуг
    Признаками публичных услуг являются:
    - предоставление услуг в области общезначимой направленности;
    - наличие неограниченного круга субъектов, пользующихся упомянутыми услугами;
    - осуществление деятельности по предоставлению публичных услуг непосредственно органам публичной власти или косвенно другим субъектам (на основе формализованного соглашения по привлечению сторонней организации к определенному перечню действий по предоставлению публичных услуг электронными средствами);
    - юридическую основу предоставления услуг электронными средствами может составлять как публичная, так и частная собственность.
    Предоставление электронных публичных услуг осуществляется посредством взаимодействия трех основных категорий участников:
    - «Правительство – гражданин» - предоставление электронных публичных услуг основано на взаимодействии гражданина и Правительства, большая часть которого осуществляется в режиме он-лайн. Основными электронными публичными услугами, оказываемыми гражданам, являются:
    1) оплата налогов;
    2) услуги по поиску места работы посредством бюро по трудоустройству;
    3) получение социальной помощи;
    4) оформление личных документов;
    5) регистрация транспорта;
    6) регистрация недвижимости;
    7) подача заявлений и получение разрешений на строительство;
    8) подача заявлений в полицию;
    9) услуги публичных библиотек;
    10) регистрация актов записи гражданского состояния (свидетельство о рождении, о браке, подача заявлений о смене места жительства и т. д.);
    11) поступление в высшие учебные заведения;
    12) содействие общественной безопасности;
    13) услуги здравоохранения;
    - «Правительство – бизнес» – предоставление электронных публичных услуг основано на взаимодействии публичной администрации и делового сообщества. Основными публичными услугами данной категории являются:
    1) социальные и пенсионные отчисления работников и работодателей;
    2) оплата налогов организациями;
    3) регистрация новых компаний;
    4) передача данных статистическим органам;
    5) заполнение и подача таможенных деклараций;
    6) получение разрешений, связанных с охраной окружающей среды;
    7) подача заявлений и получение разрешений на строительство;
    8) осуществление государственных закупок.
    - «Правительство – Правительство» - предоставление электронных публичных услуг основано на взаимодействии органов публичной власти и государственных учреждений через электронные средства связи.
    С функциональной точки зрения, публичные услуги подразделяются на следующие классы услуг:
    - предоставление общезначимых публичных услуг;
    - предоставление услуг в области деловой и коммерческой информации;
    - предоставление услуг в области регистрации земельных и кадастровых взаимоотношений;
    - предоставление услуг в области финансовой и банковской системы;
    - предоставление информационных услуг в просвещении - внедрение и использование новых информационно-коммуникационных технологий в образовательном процессе;
    - предоставление информационных услуг в области науки;
    - предоставление информационных услуг в области здравоохранения;
    - предоставление информационных услуг в области правовой информации;
    - предоставление информационных услуг в сфере социального обеспечения;
    - предоставление информационных услуг по вопросам безопасности;
    - предоставление информационных услуг в области культурного наследия;
    - предоставление информационных услуг в области прав человека;
    - предоставление информационных услуг в области туризма.
    Публичные услуги по признаку целевой направленности делятся на следующие категории:
    - внешние публичные услуги:
    1) социально-экономическое развитие;
    2) наука и знания;
    3) защита окружающей среды;
    4) здравоохранение;
    5) правоохрана, демократические права и права человека;
    6) социальная политика;
    7) культура;
    8) образование;
    9) общественная безопасность;
    10) судебная система;
    11) национальная безопасность и оборона;
    12) природные ресурсы;
    - внутренние публичные услуги:
    1) общественное регулирование, планирование и управление услугами;
    2) управление человеческими ресурсами;
    3) управление финансами;
    4) управление информацией и технологиями;
    5) управление фондами, ресурсами;
    6) управление коммуникациями;
    7) управление поставками;
    8) администрирование;
    9) профессиональные услуги.
    Публичные услуги по способу доступа подразделяются на:
    - открытую, общедоступную информацию;
    - информацию ограниченного доступа: государственная тайна, коммерческая тайна, персональные данные.
    Публичные услуги классифицируются по признаку платности на:
    - платные публичные услуги;
    - бесплатные публичные услуги.
    Публичные услуги по степени персонификации подразделяются на:
    - индивидуальные;
    - коллективные.
    Предоставление публичных услуг возможно по различным уровням сложности:
    Уровень 1 – Информирование.
    Данный уровень включает предоставление информации о следующем:
    - публичные услуги;
    - деятельность органов публичной власти;
    - услуги по информационному обслуживанию;
    - поиск информации;
    - обработка информации;
    - выдача данных (документов);
    - хранение информации.
    Уровень 2 – Взаимодействие.
    Данный уровень позволяет предоставление следующих услуг:
    - копирование формуляров из сети Интернет;
    - обработка формуляров, в том числе их аутентификация;
    - внедрение системы электронного документооборота;
    - услуги по пользованию Интернетом, информационными системами, базами данных, сетями;
    - консультационные услуги;
    - услуги по передаче информации;
    - услуги по доступу к сети Интернет;
    - услуги по пользованию электронной почтой и формированию сайтов.
    Уровень 3 – Транзакции.
    Данный уровень позволяет предоставление следующих услуг:
    - передача информации;
    - принятие решений и предоставление товаров и/или услуг (в том числе осуществление платежей с использованием электронных средств).
    Уровень 4 – Трансформация.
    Данный уровень позволяет переопределить акт управления.
    5.2. Процесс предоставления публичных услуг
    Процесс предоставления публичных услуг осуществляется электронными средствами при помощи единой точки доступа - Правительственного портала.
    Предоставление публичных услуг осуществляется на основе существующих или создающихся информационных ресурсов и систем (ИС) и, таким образом, должно охватывать следующие процессы жизненного цикла ИС, функционирующие в рамках управления информационными системами и технологиями:
    1) планирование - предпроектные работы – требуется разработка концепции системы и бизнес-предложения по предоставлению публичных услуг;
    2) разработка - разработка информационной системы предоставления публичных услуг – требуется определить, проанализировать, разработать, создать, протестировать и, при необходимости, оценить механизмы взаимодействия программных элементов и организационных структур, а также определить требования к аппаратным средствам, инфраструктуре пользователя, обучению и сопровождению. Необходимо разработать техническое задание, технический проект, версию программной системы, техническую документацию, протокол квалифицированного тестирования, акт передачи в опытную эксплуатацию;
    3) внедрение - внедрение информационной системы предоставления публичных услуг – необходимо осуществлять подготовку инфраструктуры пользователя и оборудования помещений, в которых будет осуществляться функционирование программного продукта, проверку работоспособности программного продукта в реальных условиях эксплуатации, а также организовывать обучение персонала работе с программным продуктом или его компонентами;
    4) эксплуатация - эксплуатация информационной системы предоставления публичных услуг – должна включать процессы, которые связаны с использованием программных продуктов для предоставления услуг, а также контроль функционирования, выявления и документирования возникающих проблем;
    5) поддержка и сопровождение - сопровождение информационной системы предоставления публичных услуг – необходимо осуществлять контроль работы программного продукта, регистрацию проблем для анализа, принятие предупреждающих и корректирующих действий, а также действий по адаптации и усовершенствованию программного продукта;
    6) мониторинг и решения по модернизации информационных систем - утилизация информационной системы предоставления публичных услуг – должно предусматриваться изъятие из эксплуатации программного продукта и связанных с ним программных подсистем и вспомогательных программных процессов.
    В рамках процессов управления информационными технологиями создаются информационные системы и ресурсы предоставления публичных услуг, призванные поддержать эффективное функционирование органов публичной власти и обеспечить достижение ими стратегических и тактических задач.
    Система предоставления публичных услуг должна включать следующие виды информационных ресурсов:
    - государственные информационные ресурсы - информационные ресурсы, право собственности на которые принадлежит государству и которые подразделяются на территориальные, ведомственные и базовые информационные ресурсы;
    - информационные системы, являющиеся подсистемами электронного правления;
    - веб-сайты и домены органов публичной власти;
    - классификаторы, информационные объекты и информационные услуги;
    - техническая документация, свидетельства о регистрации доменов и сертификации информационных систем.
    Эти информационные системы и ресурсы должны быть отнесены к конкретному классу и категории публичных услуг.

6. Учет публичных услуг

    Учет публичных услуг представляет собой учет компонентов информационных ресурсов, где должны раскрываться функции и принципы учета, формирование публичных услуг, а также их правовой режим.
    Учет предоставления публичных услуг должен охватывать следующие этапы жизненного цикла публичных услуг:
    - первоначальная постановка публичной услуги на учет предполагает ее регистрацию в регистре;
    - актуализация сведений о публичной услуге должна выполняться в регистре посредством изменения регистрационной записи в случае, если:
    1) меняется организация, оказывающая услуги;
    2) меняется сама услуга;
    3) меняются условия предоставления услуги;
    4) меняется документация, выдаваемая при оказании услуг;
    5) меняется ИС, являющаяся базовой для осуществления услуги.
    При прекращении процесса предоставления публичной услуги все сведения о данной услуге должны быть аннулированы.
    Система ведения учета публичных услуг охватывает:
    - нормативно-правовую базу;
    - документы всех уровней, регламентирующие учет;
    - организации, осуществляющие учет;
    - бумажные и электронные носители и информационные системы, использующиеся при ведении учета публичных услуг.
    6.1. Функции системы учета публичных услуг
    Система учета публичных услуг должна выполнять следующие функции:
    - сбор, накопление, обработка, хранение и актуализация данных публичных услуг;
    - обеспечение на государственном уровне единого учета публичных услуг;
    - обеспечение оперативной и статистической информацией органов публичной власти;
    - обеспечение обмена информацией между органами публичной власти, а также с аналогичными органами других стран;
    - контроль над соблюдением порядка учета публичных услуг, разработка и реализация мер своевременного реагирования на негативные тенденции и проявления;
    - организационное, нормативное и методическое обеспечение деятельности органов публичной власти, непосредственно выполняющих функции учета публичных услуг;
    - обеспечение функционирования авторизированных программно-технического комплекса и информационных сетей, используемых в рамках системы учета публичных услуг.
    При развитии публичных услуг необходимо применять следующие методы реализации функций учета:
    - совершенствование нормативно-правового и методического обеспечения управления публичными услугами;
    - совершенствование организационных структур, связанных с формированием и использованием публичных услуг;
    - организация учета публичных услуг и разработка критериев и методик оценки их стоимости;
    - разработка принципов и создание системы финансово-экономического обеспечения деятельности по формированию и использованию публичных услуг;
    - разработка и внедрение унифицированных технологий использования телекоммуникационных сетей для координации управления публичными услугами;
    - организация и осуществление государственного контроля функционирования публичных услуг.
    6.2. Основные принципы учета публичных услуг
    Учет публичных услуг должен проводиться в соответствии с основными принципами:
    - законность – предусматривает при создании, приобретении, использовании и распоряжении публичными услугами соответствие их действующему национальному законодательству;
    - сочетание гласности и конфиденциальности – предусматривает опубликование общедоступной информации, за исключением информации, признанной конфиденциальной, в порядке, установленном действующим национальным законодательством;
    - эффективность и экономность – означает, что приобретение информационных ресурсов, используемых для обеспечения непрерывности процесса предоставления публичных услуг, осуществляется исходя из необходимости удовлетворения информационных потребностей и сокращения бюджетных расходов;
    - сочетание платности и бесплатности предоставления информации – означает, что информация, приобретенная за счет средств государственного бюджета, предоставляется органам публичной власти на безвозмездной основе. Передача указанной выше информации иным пользователям происходит за определенную плату, если иное не установлено законодательством;
    - последовательность – предусматривает, что создание, приобретение, использование и распоряжение публичными услугами проводится поэтапно;
    - целостность – означает, что система предоставления публичных услуг должна являться одной из основных подсистем интегрированной государственной информационной системы;
    - обоснованность – предусматривает использование документированной информации в системе предоставления публичных услуг;
    - масштабируемость – предусматривает возможность расширения и наращивания компонентов системы учета публичных услуг;
    - единство информационного пространства – предусматривает использование единой системы взаимосвязанных классификаторов, форматов данных, протоколов информационного взаимодействия, стандартов, нормативных и методических документов, что является необходимым условием для формирования единого информационного пространства системы предоставления публичных услуг;
    - защита персональных данных – предусматривает создание и эксплуатацию системы учета публичных услуг в соответствии с международными договорами и соглашениями, а также действующим национальным законодательством в области защиты прав человека;
    - единая идентификация – предусматривает, что все информационные объекты учета должны иметь уникальный идентификационный номер;
    - контроль – предусматривает контроль мер, обеспечивающих качество, надежность информационных ресурсов и систем, а также их хранение и рациональное использование;
    - безопасность – предусматривает обеспечение защищенности системы предоставления публичных услуг от различного рода воздействий, нарушающих непрерывность процесса предоставления услуг.
    6.3. Организация учета публичных услуг
    Предоставляемые публичные услуги подлежат обязательному учету.
    Учет публичных услуг осуществляются в целях:
    - информационного обеспечения органов публичной власти;
    - информирования граждан и организаций о публичных услугах, а также о порядке доступа к ним.
    Формирование данных по учету публичных услуг должно производиться органом публичной власти в регистре, который должен включать информацию о публичных услугах, а также соответствующие государственные информационные системы и ресурсы, являющиеся основой для предоставления публичной услуги, в соответствии с действующим национальным законодательством.
    К формам ведения учета публичных услуг относятся регистры, журналы, дела, карточки, книги, счета учета, записи, а при использовании информационных технологий к формам ведения учета относятся также и файлы электронных таблиц, базы данных, системы текстовых файлов и иные средства организации цифровых данных.
    Формы предоставления учетных данных должны определяться следующими факторами:
    - форма ведения учета;
    - технические средства, обеспечивающие ведение учета;
    - организация учетных данных;
    - способы доведения учетных данных до заинтересованных лиц.
    К формам предоставления учетных данных относятся:
    - выдача удостоверений, отчетов, выписок, справок, свидетельств;
    - голосовое уведомление;
    - публикации в средствах массовой информации;
    - раскрытие через компьютерные сети общего пользования.
    6.4. Правовой режим публичных услуг
    Правовой режим публичных услуг должен включать:
    - порядок и источники формирования публичных услуг;
    - порядок документирования информации;
    - право собственности на отдельные документы и отдельные массивы документов;
    - порядок правовой защиты и использования публичных услуг;
    - порядок регистрации и включения публичных услуг в хозяйственный оборот;
    - иные элементы правового режима публичных услуг, включая определение категории доступа к публичным услугам.
    6.4.1.Порядок и источники формирования публичных услуг
    Публичные услуги должны формироваться соответствующими органами публичной власти, ответственными за формирование публичных услуг в соответствии с предоставленными им полномочиями.
    Формирование публичных услуг должно производиться в регистре, включая перечень сведений об публичных услугах, системах, а также о веб-сайтах и доменах органов публичной власти, в соответствии с действующим национальным законодательством.
    Публичные услуги должны включать в себя информацию, представляемую органами публичной власти, гражданами, организациями и общественными объединениями, осуществляющими свою деятельность на территории Республики Молдова в порядке, установленном действующим законодательством.
    Ответственность за достоверность сведений об публичных услугах несут владельцы публичных услуг.
    Порядок, условия представления и содержание документированной информации для формирования публичных услуг устанавливаются в соответствии с законами Республики Молдова «О регистрах» № 71-XVI от 22.03.2007 и «О доступе к информации» № 982-XIV 11.05.2000.
    В результате формирования публичных услуг должна быть определена следующая информация:
    - подробное описание публичных услуг и необходимых компонентов;
    - методы внедрения и предоставления публичных услуг;
    - процедуры контроля требуемого уровня качества публичных услуг.
    6.4.2. Порядок документирования информации
    Публичные услуги должны формироваться на основании документированной информации. Документированная информация является объектом права собственности и выступает в форме отдельного документа или совокупности документов, зафиксированных на носителе информации с соответствующими реквизитами, в том числе в виде электронного документа.
    В независимости от категории публичных услуг состав информации, предоставляемой потенциальным пользователям публичных услуг, включает:
    - сведения о перечне публичных услуг;
    - общие сведения о поставщике, уполномоченном предоставлять определенный вид публичных услуг;
    - сведения о должностных лицах, непосредственно предоставляющих публичные услуги пользователям;
    - описание предоставляемых публичных услуг в соответствии с перечнем публичных услуг.
    Описание предоставляемых публичных услуг представляет собой документ, предназначенный для пользователей публичных услуг, разъясняющий порядок получения той или иной публичной услуги.
    Описание предоставляемой публичной услуги включает следующую информацию:
    - назначение публичной услуги;
    - сроки получения услуги;
    - документы, необходимые для получения услуги;
    - контактные данные работников органов публичного управления, к которым можно обратиться за получением данной услуги;
    - сведения об условиях и требованиях, предъявляемых к пользователям услуг;
    - порядок получения услуги в электронном виде;
    - информация об оплате услуги, если предусмотрена оплата услуги;
    - дополнительные услуги, сопутствующие получению услуги;
    - ключевые показатели качества услуг: своевременность, доступность, непрерывность и процесс обжалования.
    В отношении отдельных видов публичных услуг могут быть установлены особенности их правового режима, в частности вытекающие из функционального назначения таких публичных услуг либо вследствие отнесения публичных услуг к определенной категории доступа к ним.
    Документирование информации является обязательным условием включения информации в публичные услуги. Документированная информация в публичных услугах должна быть систематизирована, классифицирована и обеспечена соответствующими реквизитами.
    Основными реквизитами документированной информации являются:
    - наименование документа;
    - владелец информации;
    - источник информации;
    - дата и время появления и документирования;
    - порядок использования;
    - другие реквизиты, необходимые для систематизации и классификации.
    При включении информации в состав публичных услуг должна быть обеспечена возможность ее поиска с учетом классификации и по установленным реквизитам. Данные, содержащиеся в центральном банке регистра, включают реквизиты и информацию в соответствии с действующим законодательством.
    Информация о публичных услугах может быть представлена в текстовой, графической, звуковой, видео- и мультимедийной (комбинация текстовых, графических, звуковых и видеоформатов) формах.
    Документ, полученный из информационной системы, а также хранимый, обрабатываемый и передаваемый с помощью информационных и телекоммуникационных систем, приобретает юридическую силу в порядке, установленном действующим законодательством.
    6.4.3. Право собственности на отдельные документы и отдельные массивы документов
    Право собственности на отдельные документы и отдельные массивы документов определяется Законом Республики Молдова «Об авторском праве и смежных правах» № 293-XIII от 23.11.1994. В соответствии с положениями данного нормативного акта право собственности на государственные информационные ресурсы принадлежит государству.
    Ответственность за нарушение прав собственности регламентируется указанным законом и другими действующими нормативными актами.
    6.4.4. Порядок правовой защиты и использования публичных услуг
    Публичные услуги предоставляются пользователям в соответствии с:
    - законодательством Республики Молдова;
    - Соглашением об уровне услуг;
    - на основе запроса;
    - по другим основаниям.
    Правовые отношения, связанные с оказанием публичных услуг, регулируются действующим национальным законодательством и соглашениями, заключенными с пользователями публичных услуг. В случае нарушения договоренностей с какой-либо стороны нарушающая сторона несет ответственность в соответствии с положениями Соглашения об уровне услуг, а также в соответствии с действующим законодательством.
    Соглашение об уровне услуг представляет собой соглашение между поставщиком и пользователем публичных услуг, в котором подробно описаны предоставляемые услуги на понятном для пользователя языке, права и обязанности обеих сторон по предоставлению публичных услуг, а также ответственность сторон в случае невыполнения своих обязательств.
    Лица, виновные в разглашении, изменении или уничтожении информации о публичных услугах несут дисциплинарную, гражданско-правовую, административную или уголовную ответственность в соответствии с действующим законодательством.
    6.4.5. Порядок регистрации и включения публичных услуг в хозяйственный оборот
    Статус публичных услуг считается готовым для их регистрации только после ввода системы в эксплуатацию и после проведения постимплементационного независимого аудита в рамках внутренних требований и положений законодательства.
    Владелец информации должен подготовить всю необходимую документацию в соответствии с порядком документирования, после чего в регистр заносятся необходимые данные.
    Для регистрации публичной услуги в регистр необходимо внести следующую информацию:
    - код публичной услуги;
    - вид публичной услуги;
    - функциональность публичной услуги;
    - целевая направленность;
    - дата начала и срок оказания услуги;
    - количество объектов информационных ресурсов, включенных в услугу;
    - перечень информационных ресурсов, включенных в услугу;
    - тип конфиденциальности информационных ресурсов, включенных в услугу;
    - версии программного обеспечения, используемого при предоставлении услуг;
    - орган публичного управления, ответственный за предоставление услуги;
    - владелец услуги;
    - организация, осуществляющая контроль над предоставлением услуги;
    - организация, осуществляющая обеспечение безопасности услуги и информационных ресурсов, включенных в услугу;
    - организация, осуществляющая концепцию «трех А» (аутентификация, авторизация, администрирование);
    - статус услуги (в соответствии с жизненным циклом);
    - средства оказания услуги;
    - категория типа субъектов;
    - категория пользователя;
    - категория платности;
    - должностные лица, предоставляющие услугу.
    Вся информация, хранящаяся в регистре, должна позволять получать последние версии документации о предоставленной публичной услуге. Данные, содержащиеся в регистре, должны периодически пересматриваться не менее одного раза в три года или в следующих случаях:
    - изменения порядка предоставления публичных услуг;
    - изменения имеющихся данных при условии документального подтверждения достоверности данных собственником;
    - изменения положений действующего законодательства, связанных с предоставлением публичных услуг.
    Лица, ответственные за внесение данных в регистр, обязаны принять на себя обязательство по неразглашению данной информации. Обязательство по неразглашению информации остается в силе и после прекращения деятельности по предоставлению публичных услуг в соответствии с законом.
    После регистрации публичной услуги формально определяется дата запуска процесса предоставления данной услуги, в результате чего публичная услуга считается включенной в хозяйственный оборот.
    6.4.6. Определение категории доступа к публичным услугам
    Порядок доступа к публичным услугам определяется в зависимости от степени секретности размещаемой в ней информации и от ее назначения.
    Публичные услуги являются открытыми и общедоступными. Исключение составляет документированная информация, отнесенная в соответствии с действующим законодательством к категории ограниченного доступа.
    Доступ к общедоступным публичным услугам должен осуществляться без аутентификации и учета пользователя. Учет действий, идентификация и аутентификация пользователя являются обязательными при доступе к публичным услугам ограниченного доступа.
    Публичные услуги ограниченного доступа по условиям их правового режима подразделяются на публичные услуги, содержащие информацию, отнесенную к государственной тайне, и публичные услуги, содержащие конфиденциальную информацию. Отнесение информации к государственной тайне осуществляется в соответствии с Законом Республики Молдова «О государственной тайне» № 245 от 27.11.2008.
    Процесс предоставления публичных услуг ограниченного доступа подлежит защите. Для обеспечения доступа к публичным услугам ограниченного доступа используются механизмы цифровой подписи и специализированная информационная система. Порядок применения механизмов цифровой подписи определяется положениями действующего национального законодательства.
    К работам по обеспечению защиты процесса предоставления публичных услуг ограниченного доступа привлекаются организации, имеющие лицензии на право проведения работ в сфере криптографической или технической защиты информации, а также сертификат безопасности в соответствии с действующим законодательством. Для обработки информации ограниченного доступа и ее защиты должны использоваться сертифицированные в установленном порядке технические средства.
    Режим использования информации, отнесенной к категории ограниченного доступа, не относящейся к государственной тайне, определяется Законом Республики Молдова «О доступе к информации» № 982-XIV от 11.05.2000.
    Органы публичной власти должны обеспечивать равноправный доступ всех заинтересованных субъектов (граждане, организации, органы публичной власти) к общедоступным публичным услугам и официальной информации по вопросам деятельности органов публичной власти.
    Право на пользование публичными услугами ограниченного доступа имеют только органы публичной власти в соответствии со степенью секретности сведений.
    Для защиты от злонамеренного или неумышленного искажения информации при предоставлении публичных услуг необходимо выполнять следующие требования:
    - ведение перечня пользователей, работающих с системой, и учетных сведений о них;
    - обеспечение надежной защиты учетных сведений о пользователях от несанкционированного доступа;
    - ведение журнала учета (аудита) доступа пользователей к информационным ресурсам.
    6.5. Электронный учет публичных услуг
    Электронный учет публичных услуг представляет собой такой учет, в котором хотя бы часть учетных данных используется и предоставляется пользователям исключительно в электронной форме. Система электронного учета публичных услуг предназначена для:
    - подтверждения проведения должных учетных процедур уполномоченными на это участниками административных процессов;
    - обеспечения юридической значимости электронных учетных данных.
    Система электронного учета публичных услуг должна включать следующие подсистемы:
    - обеспечения доверия для цифровых подписей (подтверждение идентичности уполномоченных лиц);
    - электронного подтверждения (подтверждение времени совершения учетных записей);
    - внешнего архивирования (обеспечение сохранения учетных данных);
    - раскрытия информации (обеспечение открытого доступа к учетным данным);
    - регистрации систем электронного государственного учета.
    Для систем государственного учета публичных услуг должна поддерживаться постоянная готовность к переходу во внештатный режим функционирования без использования электронных технологий, для чего бумажный учет должен дублировать электронный учет в режиме реального времени (без ущерба для юридической значимости электронного учета).
    К числу важнейших систем государственного учета публичных услуг относятся:
    - «Государственный регистр населения»;
    - «Государственный регистр правовых единиц»;
    - «Национальная географическая информационная система»;
    - «Информационные ресурсы органов публичной власти»;
    - «Информационные ресурсы социальной сферы»;
    - «Информационные ресурсы финансово-экономической сферы»;
    - «Кадастры природных ресурсов и техногенного потенциала».
    Системы электронного государственного учета должны обеспечивать возможность осуществления различных видов контроля их использования, включая осуществление внутреннего контроля, внешнего контроля и проведения информационного аудита на соответствие требованиям, предъявляемым к этим системам.
    Объектами контроля и аудита являются программно-аппаратные комплексы, обеспечивающие ведение электронного учета публичных услуг:
- вычислительное и телекоммуникационное оборудование;
- каналы связи;
- инженерно-техническое оборудование, обеспечивающее работу вычислительных и телекоммуникационных средств;
- прикладное и системное программное обеспечение.

7. Обеспечение информационной безопасности

    Порядок накопления, обработки, использования информации, отнесенной к категории конфиденциальной, правила ее защиты и порядок доступа к ней регламентируются в соответствии с действующим национальным законодательством.
    Порядок накопления, обработки, использования информации, отнесенной к категории персональных данных, определяется в соответствии с Законом «О защите персональных данных» № 17-XVI от 15.02.2007.
    Для обеспечения информационной безопасности системы учета публичных услуг необходимо выполнение следующих требований:
    - правовое, организационное и техническое обеспечение безопасности публичных услуг, информационных систем, средств связи и информационных сетей;
    - разграничение объемов и содержания информации, которая может быть доступна различным категориям пользователей;
    - выявление угроз информационной безопасности в процессе выбора и приобретения аппаратных и программных средств, создания и эксплуатации информационных систем, их профилактики и предупреждения, а также ликвидации неблагоприятных последствий в случае их наступления, включая возмещение материального ущерба;
    - соблюдение условий хранения и защиты электронных и иных документов, обеспечивающих сохранение идентифицирующих их атрибутов;
    - соблюдение установленных правил использования средств криптографической защиты.
    Программно-аппаратные средства защиты системы учета публичных услуг должны обеспечивать:
    - выявление и предотвращение угроз информационной безопасности;
    - целостность данных при формировании, использовании, обработке, предоставлении публичных услуг;
    - защиту от несанкционированного доступа, внесения дополнений и изменений в публичные услуги;
    - систему резервирования и восстановления данных;
    - контроль целостности и работоспособности системы обеспечения информационной безопасности;
    - идентификацию защищаемых публичных услуг;
    - аутентификацию защищаемых публичных услуг и пользователей;
    - аутентифицированный обмен данными;
    - разграничение доступа пользователей к данным;
    - регистрацию действий по входу пользователей в систему и выходу из системы и нарушений прав доступа к защищаемым публичным услугам.

Приложение № 2
к Приказу № 94
от 17.09.2009 г.

Технический регламент
Предоставление электронных публичных услуг.
Технические требования
1. Область применения

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

2. Нормативно-правовая база

    Настоящий регламент разработан на основе следующих законодательных актов Республики Молдова:
    - Закон Республики Молдова «О доступе к информации» № 982-XIV от 11.05.2000;
    - Закон Республики Молдова «Об информатизации и государственных информационных ресурсах» № 467–XV от 21.11.2003;
    - Закон Республики Молдова «Об электронном документе и цифровой подписи» № 264-XV от 15.07.2004;
    - Закон Республики Молдова «Об электронной торговле» № 284-XV от 22.07.2004;
    - Закон Республики Молдова «О техническом регулировании» № 420-XVI от 22.12.2006;
    - Закон Республики Молдова «О защите персональных данных» № 17-XVI от 15.02.2007;
    - Закон Республики Молдова «О регистрах» № 71-XVI от 22.03.2007.

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

    В настоящем регламенте применяются следующие термины:
    Соглашение об уровне услуг – письменное соглашение между поставщиком услуг и заказчиком (заказчиками), которое описывает согласованные уровни обслуживания по какой-либо услуге.
    Сборка – последний этап создания готовой к использованию конфигурации.
    Конфигурационная база данных учетных элементов – база данных, которая содержит все необходимые сведения по каждому учетному элементу и сведения о важных связях между ними.
    Библиотека программного обеспечения – контролируемая совокупность учетных элементов конфигурации типа программного обеспечения, предназначенная для поддержки сохранности их общего статуса и типа и вместе с тем хранящая элементы по отдельности, для содействия в разработке, эксплуатации и сопровождении.
    Библиотека эталонного программного обеспечения – библиотека, в которой под защитой хранятся эталонные версии всех учетных элементов конфигурации типа программного обеспечения.
    Каталог услуг – короткий, не более семи страниц, документ, в котором сформулированы все услуги, предоставляемые заказчику, при необходимости указываются цена услуги, общий порядок обращения за услугой.
    Категория - классификация группы учетных элементов, документов об изменении или проблемах.
    Жизненный цикл – последовательность процессов, действий и задач, вовлеченных в разработку, эксплуатацию и сопровождение системы и охватывающих всю продолжительность жизни системы.
    Контроль конфигураций – действия, которые входят в контроль изменений в учетных элементах после формального составления их конфигурационной документации.
    Контроль процесса – процесс планирования и регулирования, целью которого является эффективное и рациональное выполнение процесса.
    Внешний контур электронного правления - включает публичную инфраструктуру, обеспечивающую взаимодействие граждан и организаций с органами публичного управления. Его составляют информационные системы, которые обслуживают процессы взаимодействия населения и организаций с органами публичного управления посредством правительственного портала.
    Внутренний контур электронного правления - включает информационные системы, обслуживающие процессы внутри системы публичной администрации (G2G), в том числе предоставление внутренних услуг (G2E) структурам и работникам управления, как на центральном, так и на местном уровнях.
    Дельта-релиз – частичный релиз, включающий только те учетные элементы в рамках единицы релиза, которые были изменены, или новые учетные элементы с момента последнего полного или дельта-релиза.
    Конфигурационная документация – документация, которая определяет требования к учетному элементу, проектирование системы, сборку, производство и проверку учетного элемента.
    Учетный элемент – компонент инфраструктуры, который находится под контролем управления конфигурациями (включая аппаратное и программное обеспечение и документацию).
    Известная ошибка – инцидент или проблема, для которых известна корневая причина и найдено альтернативное решение.
    Управление конфигурациями – процесс идентификации и определения учетных элементов в системе, записей и отчетов по статусу учетных элементов и запросов на изменение, а также проверки полноты и правильности учетных элементов.
    Управление изменениями – процесс контроля изменений в инфраструктуре или в любой составляющей предоставляемых услуг, который приводит в действие утвержденные изменения с минимальными простоями.
    Согласованный график изменений – график, который содержит сведения обо всех изменениях, утвержденных для внедрения, и предлагаемые даты их внедрения.
    ПРИМЕЧАНИЕ. Согласовывается с заказчиком, управлением уровнем обслуживания, Информационно-справочным центром предоставления услуг и управлением доступностью.
    Идентификация конфигурации – деятельность, которая определяет структуру продукта, набор учетных элементов и документацию физических и функциональных характеристик учетного элемента.
    Идентификатор версии – номер версии; дата версии или дата версии и временная метка.
    ИТ-инфраструктура - система организационных структур и технических средств, обеспечивающих функционирование и развитие информационной системы и средств информационного взаимодействия.
    ПРИМЕЧАНИЕ. ИТ-инфраструктура включает совокупность аппаратных средств, операционных систем, телекоммуникационной сети и системы связи, баз данных, средств поддержки, мультимедийных средств, обеспечивающих систему формирования, распространения и использования информационно-коммуникационных технологий, обеспечивающих взаимодействие органов публичного управления, обеспечивая доступ к информационным ресурсам.
    Запись об изменении – учетная запись, содержащая сведения о том, на какие учетные элементы и каким образом оказывает воздействие утвержденное изменение.
    Среда – совокупность аппаратного и программного обеспечения, сетевых коммуникаций и процедур, которые совместно работают для предоставления публичной услуги.
    Программная среда – программное обеспечение, используемое для поддержки приложения, такое как операционная система, система управления базой данных, средства разработки, компиляторы и прикладное программное обеспечение.
    Средства автоматизированной разработки систем – программное средство для разработчиков программного обеспечения, представляющее помощь в планировании, анализе, проектировании, документировании программного обеспечения.
    Средство управления конфигурациями – программный продукт, обеспечивающий автоматизацию поддержки изменений, конфигураций и контроля версий.
    Политика управления доступом - правила предоставления доступа к компьютерным системам и сети отдельным пользователям.
    Предоставление публичных услуг – набор взаимосвязанных процессов, направленных на достижение целей – взаимодействие между субъектами электронного правления, осуществляющегося по двум четким контурам - внутреннему и внешнему, сообщающимся между собой через правительственный портал.
    Проблема – неизвестная исходная причина одного и более инцидентов.
    Информационный продукт – документированная информация, оформленная в соответствии с потребностями пользователей и представленная в виде продукта.
    ПРИМЕЧАНИЕ. Информационными продуктами являются: программное обеспечение, базы и банки данных и другая информация.
    Журнал изменений – журнал запросов на изменения, которые были оформлены во время проекта, показывающий информацию о каждом изменении, его оценке, принятых решениях.
    Релиз – совокупность новых и/или измененных учетных элементов, которые вместе проходят тестирование и вместе вводятся в эксплуатацию.
    Комплексный релиз – все компоненты единицы релиза, которые собираются, тестируются, распространяются и внедряются вместе.
    Информационные услуги - услуги, ориентированные на удовлетворение информационных потребностей пользователей путем предоставления информационных продуктов.
    Публичная услуга – услуга, которая обуславливает три типа взаимодействия составляющих электронного правления: взаимодействие “Правительство - гражданин” (G2C); взаимодействие “Правительство - бизнес” (G2B); взаимодействие “Правительство - Правительство” (G2G) с подкатегорией “Взаимодействие Правительства и его сотрудников” (G2E).
    Запрос на обслуживание – любой инцидент, который не является сбоем в работе инфраструктуры.
    Запрос на изменение – форма, используемая для записи сведений о запросе на изменение любого учетного элемента инфраструктуры или в процедурах и элементах, связанных с данной инфраструктурой.
    Обходное решение – метод, позволяющий устранить инциденты или проблемы с помощью временного решения или способа, благодаря которому заказчик перестает зависеть от какого-либо аспекта услуги, связанного с проблемой.
    Постоянное решение - решение, применение которого устраняет корневую причину возникновения проблемы.
    Разрешение проблемы – процесс устранения проблемы путем разработки и применения постоянного решения.

4. Требования к организации процесса
предоставления публичных услуг

    Суть деятельности организации, оказывающей публичные услуги, состоит в управлении предоставлением публичных услуг. Результатами данной деятельности являются обоснованные по стоимости, надежные, согласованные между собой и имеющие надлежащее качество публичные услуги.
    Система предоставления публичных услуг предназначена для решения следующего комплекса задач:
    - повышение надежности функционирования ИС;
    - сокращение времени выявления и устранения сбоев при предоставлении публичных услуг;
    - регламентация деятельности подразделений и повышение управляемости служб, ответственных за эксплуатацию ИС;
    - создание механизмов оценки вклада информационных технологий (ИТ) в производственные результаты и механизмов обоснования инвестиций в ИТ-инфраструктуру;
    - внедрение средств для планирования и оценки потребностей ИТ-инфраструктуры;
    - оптимизация затрат на эксплуатацию ИС;
    - сокращение сроков внедрения новых проектов по предоставлению публичных услуг;
    - обеспечение накопления и использования знаний и опыта эксплуатации ИТ-инфраструктуры.
    Данный раздел устанавливает основные требования к организации процесса предоставления публичных услуг, связанные с безопасностью и качеством, условиями их реализации и использования, а также критерии правильной организации и эффективной оценки соответствия оказания услуг.
    В рамках предоставления публичных услуг необходимо реализовать следующие процессы:
    - управление мощностями;
    - управление финансами для предоставления публичных услуг;
    - управление доступностью;
    - управление уровнем обслуживания;
    - управление непрерывностью предоставления публичных услуг;
    - управление информационной безопасностью;
    - управление качеством публичных услуг;
    - управление сетевыми сервисами.
    4.1. Процесс управления мощностями
    4.1.1. Цели процесса управления мощностями
    Цель процесса управления мощностями заключается в обеспечении предоставления необходимого уровня услуг, соответствующих требованиям, с минимальными затратами.
    Процесс управления мощностями аппаратных и телекоммуникационных средств должен быть направлен на:
    - постоянное предоставление необходимых информационных ресурсов, в соответствии с параметрами потребностей, времени и цены;
    - предотвращение необоснованных инвестиций в ИС и технологии путем лучшего использования имеющихся ресурсов;
    - своевременное наращивание мощности;
    - управление использованием текущих мощностей ИТ и ИС.
    Оптимально функционирующий процесс управления мощностями должен обеспечивать выполнение следующих задач:
    - снижение рисков, связанных с существующими услугами, посредством осуществления эффективного управления ресурсами и постоянного мониторинга производительности оборудования;
    - снижение угрозы срыва работы процессов предоставления публичных услуг за счет тесного взаимодействия с процессом управления изменениями при определении воздействия изменений на мощности ИТ и телекоммуникационных средств и предотвращении экстренных изменений из-за неправильного расчета мощностей средств;
    - составление более точных прогнозов и быстрое реагирование на запросы заказчика или пользователей;
    - обеспечение рациональности работы за счет заблаговременного достижения баланса спроса и предложения, связанного с новыми и модифицированными услугами;
    - управление затратами (снижение затрат), связанных с мощностью средств, по причине их более рационального использования.
    4.1.2. Основные требования, предъявляемые к процессу управления мощностями
    К процессу управления мощностями предъявляются три категории требований:
    - управление мощностями организации – данные требования необходимо выполнять для понимания будущих потребностей пользователей, определения тенденций, прогноза, моделирования, создания прототипа, определения объема и документирования будущих требований организации;
    - управление мощностями обслуживания – выполнение данных требований способствует определению и пониманию уровня использования публичных услуг пользователями, способствует осуществлению мониторинга, анализа, настройки и созданию отчетов о производительности услуг, определению базисных конфигураций и профилей использования услуг, управлению спросом на услуги;
    - управление мощностями ресурсов – данные требования предназначены для определения и понимания использования ИТ-инфраструктуры, мониторинга, анализа и создания отчетов об использовании учетных элементов, определения базисных конфигураций и профилей использования учетных элементов. В рамках выполнения данной категории требований важным видом деятельности является активный мониторинг тенденций развития.
    Таблица 1. Требования, предъявляемые к процессу управления мощностями

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

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

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

    Управленческие отчеты, предоставляемые процессом управления мощностями, должны содержать информацию по расхождениям между фактическим и плановым использованием мощностей, о тенденциях в расхождениях, о воздействии на уровни услуг, ожидаемое увеличение/уменьшение использования мощностей в краткосрочной и долгосрочной перспективе и данные о пороговых значениях, при достижении которых потребуется приобретение дополнительных мощностей.
    4.2. Процесс управления финансами для предоставления публичных услуг
    4.2.1. Цели процесса управления финансами для предоставления публичных услуг
    Целью процесса управления финансами является содействие организации в эффективном управлении информационными ресурсами и системами, необходимыми для предоставления публичных услуг.
    При оплате счета за предоставление публичных услуг важным моментом для заказчиков является определение того, насколько окупаются затраты полученными преимуществами для организации.
    Оптимально функционирующий процесс управления финансами для предоставления публичных услуг должен обеспечивать решение следующих задач:
    - разработка бюджета - планирование деятельности организации и ее контроль;
    - бухгалтерский учет - определение элементов затрат и способов их структурирования;
    - выставление счетов - анализ возможных вариантов выставления счетов и определение тарифов на услуги.
    4.2.2. Основные требования, предъявляемые к процессу управления финансами для предоставления публичных услуг
    Предоставление большей информации для обоснования расходов, анализ публичных услуг, возмещение затрат на публичные услуги, разработка бюджетов и планов должны выполняться с учетом следующих факторов:
    - качество – в плане операционной деятельности: мощность (пропускная способность); доступность; производительность; восстановление после чрезвычайных обстоятельств; поддержка;
    - стоимость – в плане расходов и инвестиций;
    - требования заказчика – стоимость и качество должны соответствовать потребностям заказчика.
    К процессу управления финансами для предоставления публичных услуг предъявляются следующие требования:
    - определение затрат на публичные услуги;
    - определение и классификация структуры затрат;
    - правильное распределение затрат по публичным услугам, предоставляемым заказчикам;
    - использование различных методов выставления счетов за пользование публичными услугами;
    - возмещение всех расходов, включая капитальные затраты, за счет заказчика;
    - регулярная проверка счета на оплату публичных услуг на предмет корректности и соответствия требованиям заказчика;
    - включение в отчетность, предоставляемую заказчикам, расшифровки информации о затратах.
    Для обеспечения рентабельности процесса предоставления публичных услуг необходимо внедрение эффективной системы контроля затрат, которая должна отвечать следующим требованиям:
    - поддержка разработки инвестиционной стратегии, способствующей гибкости организации за счет использования современных технологических средств;
    - помощь в определении приоритетов в использовании информационных ресурсов;
    - обеспечение покрытия затрат на все используемые организацией информационные ресурсы;
    - помощь руководству в принятии ежедневных оперативных решений для уменьшения финансового риска при принятии долгосрочных решений;
    - обеспечение гибкости и способности быстро реагировать на изменения в процессах предоставления публичных услуг.
    4.2.3. Классификация затрат, связанных с процессом предоставления публичных услуг
    Информация о затратах на предоставление публичных услуг позволяет сбалансировать затраты и качество и обеспечить заказчикам финансово-обоснованный процесс оказания услуг.
    Для каждой услуги требуется определять затраты, прямо или косвенно связанные с ней:
    - прямые затраты – затраты, связанные конкретно и исключительно с какой–либо публичной услугой (например, аренда телефонной линии для доступа к сети Интернет);
    - косвенные затраты – затраты, не связанные прямо и однозначно с какой–либо публичной услугой (например, затраты на помещения, услуги по поддержке и административные расходы).
    Затраты по предоставлению услуг разделяются на постоянные и переменные:
    - постоянные затраты не зависят от объема предоставляемых услуг (инвестиции в аппаратное обеспечение, программное обеспечение и строительство и т.д.);
    - переменные затраты – затраты, уровень которых меняется с изменением объема предоставления услуг (затраты на привлекаемый со стороны персонал, картриджи для принтеров, бумагу, отопление и электричество и т.д.).
    В процессе предоставления публичных услуг формируются следующие виды затрат:
    - затраты на оборудование – все затраты на аппаратное обеспечение (серверы, устройства хранения информации, связь и сети, принтеры и т.д.);
    - затраты на ПО – прямые и косвенные затраты на поддержку функционирования системы (системное ПО, транзакционная система, система управления базами данных, система разработки приложений, программные приложения и т.д.);
    - организационные затраты – прямые и косвенные затраты на персонал, которые могут быть постоянными или переменными (заработная плата, расходы на обучение, командировочные расходы и т.д.);
    - затраты на размещение – все прямые и косвенные затраты, связанные с размещением (серверные комнаты, офисы, другие помещения и оборудование);
    - трансфертные затраты – затраты, связанные с внутренними расчетами между подразделениями организации;
    - учет затрат – затраты, связанные с процессом управления финансами.
     4.2.4. Управление эффективностью процесса управления финансами
    Показатели эффективности процесса управления финансами предоставления услуг дают оценку соответствия данного процесса требованиям, которые обеспечивают корректную организацию функционирования процесса. Основными показателями эффективности процесса управления финансами предоставления публичных услуг являются:
    - точный стоимостной анализ по предоставляемым услугам;
    - удовлетворенность заказчиков;
    - достижение организацией ее финансовых целей;
    - изменение потребления услуг заказчиками;
    - своевременность предоставления отчетов для процесса управления уровнем сервиса.
    4.3. Процесс управления доступностью
    4.3.1. Цели процесса управления доступностью
    Целью процесса управления доступностью является обеспечение рентабельного и согласованного уровня доступности предоставления услуг. Процесс управления доступностью должен быть непрерывным и должен заканчиваться при прекращении предоставления обслуживания.
    Процесс управления доступностью должен охватывать:
    - новые и уже существующие услуги;
    - отношения с внешними и внутренними поставщиками;
    - компоненты инфраструктуры и влияющие на доступность организационные аспекты, такие как уровень знаний персонала, управленческие процессы, процедуры и инструментальные средства.
    Процесс управления доступностью должен выполняться, учитывая следующие факторы:
    - критерии разработки информационной архитектуры для обеспечения доступности и восстановления новых и улучшаемых публичных услуг;
    - технологии, обеспечивающие устойчивость ИТ-инфраструктуры;
    - гарантии доступности, надежности и обслуживания компонентов инфраструктуры;
    - сложность ИТ-инфраструктуры;
    - надежность компонентов - доступность сервиса в течение согласованного периода времени без каких-либо сбоев;
    - способность быстро и эффективно реагировать на сбои;
    - качество обслуживания и качество работы поддерживающих организаций и поставщиков;
    - качество и границы компетенции процессов операционного управления.
    4.3.2. Основные требования, предъявляемые к процессу управления доступностью
    В рамках процесса управления доступностью должны выполняться следующие действия:
    - планирование - определение требований к доступности услуг, проектирование систем для достижения требуемого уровня доступности и требуемой способности восстановления;
    - мониторинг - проведение измерений и составление отчетов.
    Оптимально функционирующий процесс управления доступностью должен обеспечивать выполнение следующих требований:
    - создание единой точки контактов по вопросам доступности публичных услуг;
    - соответствие оказываемых услуг требованиям, предъявляемым к доступности обслуживания в соответствии с действующим национальным законодательством;
    - гарантия соответствия новых услуг предъявляемым к ним требованиям и согласованному с заказчиком стандарту доступности;
    - поддержание уровня затрат на приемлемом уровне;
    - осуществление постоянного мониторинга стандартов доступности и их совершенствование по мере необходимости;
    - выполнение восстановительных мероприятий в случае недоступности обслуживания;
    - уменьшение количества отказов в доступе к системам и сокращение периода недоступности обслуживания;
    - смещение акцентов с исправления дефектов на улучшение обслуживания.
    При прерывании процесса предоставления публичных услуг необходимо быстро и правильно устранить сбой и достигнуть согласованных стандартов доступности. Процедуры восстановления включают в себя такие аспекты, как использование эффективного процесса управления инцидентами (см. 5.1) и соответствующие процедуры эскалации, оповещения, резервного копирования и восстановления.
    4.3.3. Управление эффективностью процесса управления доступностью
    Требуется осуществлять мониторинг и оценку соответствия данного процесса вышеуказанным требованиям. Ключевые показатели эффективности работы процесса управления доступностью:
    - продолжительность простоев;
    - частота возникновения простоев;
    - среднее время ремонта - среднее время между возникновением сбоя и восстановлением обслуживания;
    - среднее время между сбоями - среднее время между восстановлением после одного сбоя и возникновением другого;
    - среднее время между системными инцидентами - среднее время между двумя последовательными инцидентами;
    - коэффициент доступности (или недоступности) обслуживания;
    - общее время работоспособного состояния и время простоя;
    - количество сбоев;
    - информация о сбоях;
    - время обнаружения, реагирования, восстановления и ремонта сбоя, инцидента или проблемы.
    Уровень доступности должен обеспечивать постоянный доступ к публичным услугам путем сокращения времени простоя и путем быстрого восстановления предоставления услуг.
    4.4. Процесс управления уровнем обслуживания
    4.4.1. Цели процесса управления уровнем обслуживания
    Управление уровнем обслуживания (сервиса) - это процесс, в рамках которого происходят переговоры по вопросам предоставления услуг, производятся определение, оценка, управление и улучшение качества публичных услуг при соблюдении приемлемого уровня затрат. Управление уровнем обслуживания требует эффективного и продуктивного сотрудничества с заказчиком, так как уровни запрашиваемых услуг должны определяться при его участии.
    Процесс управления уровнем обслуживания должен находить нужный баланс между предложением и спросом на услуги требуемого уровня качества, их легкостью в использовании и стоимостью. Данный процесс реализует разработку, согласование и выполнение соглашений об уровне услуг, операционных соглашений об уровне услуг, внешних договоров и плана обеспечения качества услуг.
    В рамках процесса управления уровнем обслуживания должны выполняться следующие задачи:
    - интеграция элементов, необходимых для предоставления публичных услуг;
    - документирование и описание предоставляемых услуг;
    - согласование ИТ-стратегии с потребностями организации;
    - контроль улучшения предоставления публичных услуг.
    Уровень обслуживания должен регулярно анализироваться, при этом наибольшее внимание следует уделять следующим аспектам:
    - соглашению об уровне услуг с момента последнего анализа;
    - проблемам, возникшим с услугами;
    - выявлению тенденций работы услуг;
    - изменению услуг в пределах согласованных уровней обслуживания;
    - изменению процедур и расчетов стоимости дополнительных ресурсов;
    - анализу последствий сбоев при предоставлении согласованных уровней услуг.
    Надежность обслуживания должна включать в себя сочетание следующих характеристик:
    - надежность компонентов, используемых для предоставления услуг;
    - устойчивость - способность обслуживания или его компонентов эффективно функционировать, несмотря на сбой одной или нескольких подсистем;
    - профилактическое обслуживание для предотвращения простоев в функционировании.
    Обслуживание должно выполнять следующие виды работ по обеспечению функционирования процесса оказания услуг и его восстановления после сбоев, а также по проведению профилактического обслуживания и регламентных проверок:
    - принятие мер по предотвращению сбоев;
    - своевременное обнаружение сбоев;
    - проведение диагностики, включая автоматическую самодиагностику компонентов;
    - ликвидация сбоев;
    - восстановление функционирования после сбоя;
    - восстановление обслуживания.
    4.4.2. Основные требования, предъявляемые к процессу управления уровнем обслуживания
    Требования к уровню предоставления услуг - детальное описание потребностей заказчика, используемых при разработке, модификации и инициировании услуг. В перечень требований должны быть включены:
    - идентификация потребностей заказчика;
    - определение требуемых услуг в соответствии с потребностями и запросами заказчика, создание плана обеспечения качества услуг;
    - окончательное оформление соглашения - обсуждение с заказчиком требуемого уровня обслуживания и связанных с этим затрат, закрепление достигнутых договоренностей в Соглашении об уровне услуг, операционном соглашении об уровне услуг, внешних договорах и составление или обновление каталога услуг;
    - мониторинг уровней сервисов;
    - отчетность об уровне сервисов;
    - анализ сервисов с целью определения направлений его улучшения;
    - описание функций, которые должен предоставить запрашиваемый уровень обслуживания, с точки зрения заказчика;
    - время и дни, в которые оказываемые услуги должны быть доступны;
    - требования непрерывности процесса обслуживания;
    - определение информационных функций, необходимых для предоставления услуг;
    - наличие ссылок на текущие операционные методы и стандарты качества, которые должны учитываться при определении уровня обслуживания;
    - сопоставление уровня качества услуг с предъявленной в счете стоимостью;
    - определение обязанностей заказчика и организации, предоставляющей публичные услуги;
    - наличие ссылки на Соглашение об уровне услуг.
    Процесс управления уровнем обслуживания должен гарантировать постоянную поддержку и совершенствование требуемых заказчиком публичных услуг путем согласования уровня качества услуг организации, их мониторинга и предоставления отчетов.
    4.4.3. Управление эффективностью процесса управления уровнем обслуживания
    Показатели эффективности и результативности процесса управления уровнем обслуживания:
    - параметры обслуживания, включенные в Соглашение об уровне услуг;
    - параметры, за которыми ведется мониторинг и о недостатках которых составляются отчеты;
    - параметры Соглашения об уровне услуг, которые регулярно анализируются;
    - параметры Соглашения об уровне услуг, для которых удалось достичь согласованных уровней оказания услуг;
    - выявленные недостатки, включенные в план улучшений;
    - выявленные тенденции с учетом реального уровня обслуживания.
    Данные показатели являются инструментами для определения соответствия данного процесса предъявляемым к нему требованиям.
    4.5. Процесс управления непрерывностью предоставления публичных услуг
    4.5.1. Цели процесса управления непрерывностью предоставления публичных услуг
    Целью процесса управления непрерывностью предоставления публичных услуг является поддержка процесса управления непрерывностью деятельности организации. Поддержка состоит в том, что необходимая ИТ-инфраструктура и публичные услуги, включая службу поддержки и все институциональные единицы, обеспечивающие предоставление услуг, должны быть восстановлены в заданный период времени после возникновения чрезвычайной ситуации.
    Доступность публичных услуг должна включать сочетание мер по уменьшению степени риска и способов восстановления.
    В процессе управления непрерывностью публичных услуг должны выполняться следующие задачи:
    - оценка воздействия нарушений в работе публичных услуг после возникновения чрезвычайной ситуации;
    - определение наиболее критичных для организации публичных услуг, которые требуют дополнительных мер;
    - определение периода времени, в течение которого услуга должна быть восстановлена;
    - принятие мер по предотвращению, обнаружению, подготовке к чрезвычайным ситуациям или по уменьшению степени их воздействия;
    - определение общего подхода к восстановлению услуг;
    - разработка, тестирование и поддержка плана восстановления с достаточным уровнем детализации, который помогает пережить чрезвычайную ситуацию и восстановить нормальную работу за заданный период времени.
    4.5.2. Основные требования, предъявляемые к процессу управления непрерывностью предоставления публичных услуг
    В ходе процесса управления непрерывностью предоставления публичных услуг должны выполняться следующие требования:
    - наличие эффективного процесса управления конфигурациями;
    - поддержка процесса управления непрерывностью персоналом организации;
    - наличие современных эффективных инструментальных средств;
    - проведение специального обучения для всех участников данного процесса;
    - регулярное тестирование плана восстановления без предварительного уведомления.
    Для выполнения данных требований необходимо осуществлять следующие деятельности:
    - инициализация;
    - требования и стратегия;
    - внедрение;
    - операционное управление.
    Инициализация – включает работы по определению области действия процесса управления непрерывностью публичных услуг. В ходе инициализации должна быть определена политика организации в отношении управления непрерывностью публичных услуг; должен осуществляться выбор подхода к оценке риска; должны выделяться ресурсы для развертывания информационной среды на случай возникновения чрезвычайных ситуаций.
    Требования и стратегия – включают виды действий, указанные в таблице 3.
    Таблица 3. Виды действий по деятельности «Требования и стратегия»

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

Внедрение – включает виды действий, указанные в таблице 4.
Таблица 4. Виды действий по деятельности «Внедрение»

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

Операционное управление – включает виды действий, указанные в таблице 5.
Таблица 5. Виды действий по деятельности «Операционное управление»

Виды действий	Работы
Обучение и осведомление	Обучение персонала вопросам информационных технологий для оказания персоналом необходимой поддержки при проведении восстановительных работ
Анализ и аудит	Аудит и проверка актуальности всех планов по всем аспектам процесса управления непрерывностью публичных услуг при каждом значительном изменении ИТ-инфраструктуры
Тестирование	Регулярное тестирование планов восстановления публичных услуг
Управление изменениями	Проведение анализа воздействия любого изменения на планы восстановления публичных услуг
Обеспечение гарантий	Проверка соответствия качества процесса (процедур и документации) потребностям

    4.5.3. Управление эффективностью процесса управления непрерывностью предоставления публичных услуг
    Для управления восстановлением ИС, уменьшения простоев в работе предоставления публичных услуг необходимо соблюдение требований, предъявляемых к процессу управления непрерывностью предоставления публичных услуг, соответствие которым отражается в показателях:
    - количество выявленных ошибок в планах восстановления;
    - потери доходов организации в результате чрезвычайной ситуации;
    - стоимость процесса.
    4.6. Процесс управления информационной безопасностью
    4.6.1. Цели, задачи и принципы процесса управления информационной безопасностью
    Целью процесса управления информационной безопасностью является контроль процессов обеспечения информацией и предотвращение разглашения, утраты, утечки, искажения и уничтожения информации, нарушения работы процесса предоставления публичных услуг.
    Процесс управления информационной безопасностью должен выполняться для поддержки непрерывного функционирования организации. Задачей процесса является постоянное обеспечение безопасности услуг на согласованном с заказчиком уровне.
    Процесс управления информационной безопасностью должен осуществляться на основе следующих принципов:
    - принцип равномощности системы защиты - обес-печение защиты аппаратного и программного обеспечения, коммуникационной системы и системы управления от всех видов угроз;
    - принцип непрерывности защиты – в процессе предоставления услуг должна обеспечиваться непрерывная защита информации;
    - принцип разумной достаточности - применение мер и средств защиты, которые являются разумными, рациональными и затраты на которые не должны превышать стоимости нарушения информационной безопасности;
    - принцип комплексности - применение всех видов и форм защиты в полном объеме;
    - принцип надежности - методы, средства и формы защиты должны надежно перекрывать все пути проникновения и возможные каналы утечки информации;
    - принцип универсальности - меры безопасности должны перекрывать пути угроз независимо от места их возможного воздействия;
    - принцип планирования - разработка детальных планов действий по обеспечению информационной безопасности всех компонентов системы предоставления публичных услуг;
    - принцип централизованности - обеспечение организованно-функциональной самостоятельности процесса обеспечения безопасности предоставления публичных услуг;
    - принцип квалификации обслуживающего персонала – оказание услуг и обслуживание оборудования должно осуществляться сотрудниками, подготовленными в вопросах эксплуатации техники и технических вопросах обеспечения безопасности информации;
    - принцип разделения полномочий - ответственность за систему защиты должна разделяться между сотрудниками различного уровня и по различным направлениям работы по защите.
    4.6.2. Основные требования, предъявляемые к процессу управления информационной безопасностью
    Процесс управления информационной безопасностью, исходя из аспектов доступности, целостности и конфиденциальности информации, должен удовлетворять следующим требованиям:
    - обеспечение конфиденциальности важной информации;
    - обеспечение целостности информации и связанных с нею процессов (создание, ввод, вывод, хранение, передача и т.д.);
    - обеспечение своевременной доступности информации;
    - обеспечение неотказуемости при выполнении определенных операций;
    - обеспечение наблюдаемости для обеспечения возможности ИТ-процессам фиксировать любую деятельность пользователей и процессов;
    - учет всех процессов и событий, связанных с информацией.
    Для выполнения требований, предъявляемых к процессу управления информационной безопасности, необходимо следовать следующим условиям:
    - создание структурной схемы управления;
    - создание организационной структуры управления;
    - детальное распределение ответственностей;
    - координация информационной безопасности;
    - согласование инструментальных средств;
    - описание процесса авторизации средств ИТ;
    - предоставление консультаций специалистами;
    - сотрудничество между организациями, внутреннее и внешнее взаимодействие;
    - проведение независимого аудита информационных систем;
    - соблюдение принципов безопасности при доступе к информации третьих сторон.
    В рамках процесса управления информационной безопасностью или в других процессах, находящихся под контролем управления информационной безопасности, должны выполняться следующие виды действий:
    - контроль - политика и организация информационной безопасности, формулирование планов по безопасности, их реализация, оценка реализации и включение оценки в годовые планы по безопасности. Этот вид деятельности должен определять подпроцессы, функции безопасности, роли и ответственности, описывать организационную структуру, систему отчетности и потоки управления;
    - планирование – должно быть определено содержание раздела Соглашения об уровне услуг по вопросам безопасности при участии процесса управления уровнем обслуживания и должны быть описаны действия, связанные с вопросами безопасности, проводимые в рамках внешних договоров;
    - реализация;
    - оценка реализации запланированных мероприятий – необходимо использовать следующие виды оценки: самостоятельная оценка, внутренний аудит, внешний аудит;
    - поддержка соответствующих разделов по безопасности соглашений об уровне услуг и планов по безопасности;
    - составление отчетов – должна предоставляться информация из других процессов о достигнутых характеристиках безопасности и проблемах безопасности.
    Реализация процесса управления информационной безопасностью поддерживается выполнением задач, представленных в таблице 6.
    Таблица 6. Задачи, выполняемые при реализации процесса управления информационной безопасностью

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

    Процесс управления информационной безопасностью обеспечивает инструкциями о структуре деятельности, связанной с безопасностью, другие процессы, такие как:
    - процесс управления инцидентами, который является важным процессом, информирующим о наличии инцидентов, связанных с безопасностью. Любой инцидент, который может помешать выполнению требований безопасности, указанных в Соглашении об уровне услуг, и препятствующий достижению базового внутреннего уровня безопасности, классифицируется как инцидент по безопасности;
    - процесс управления проблемами, который отвечает за идентификацию и устранение структурных сбоев по безопасности, которые могут привести к возникновению риска для системы безопасности. Любые меры безопасности, связанные с внесением изменений, должны реализовываться одновременно с проведением самих изменений, и они должны тестироваться совместно. При тестировании безопасности должны проверяться не только доступность функций безопасности, но также отсутствие других, нежелательных функций, которые могут снизить безопасность системы.
    4.6.3. Управление эффективностью процесса управления информационной безопасностью
    Показателями, дающими оценку работе процесса обеспечения информационной безопасности на соответствие требованиям и условиям, являются:
    - параметры предоставляемых услуг, включенные в Соглашение об уровне услуг;
    - выявленные недостатки, включенные в план улучшений;
    - количество своевременно исправленных недостатков, выявленных в результате аудита и анализа;
    - количество идентифицированных угроз безопасности;
    - количество обнаружений и ликвидаций вторжений;
    - вероятность реализации угроз, инцидентов, проблем;
    - показатели оценки риска;
    - параметры реагирования на инциденты нарушения безопасности;
    - результаты мониторинга информационной безопасности;
    - данные текущего контроля состояния безопасности ИТ.
    4.7. Процесс управления качеством публичных услуг
    4.7.1. Цели процесса управления качеством публичных услуг
    Основной целью процесса управления качеством услуг являются формирование и поддержание в актуальном состоянии каталога услуг, Соглашения об уровне услуг, а также внутренних операционных соглашений, определяющих требования к персоналу и предоставляемым услугам.
    В Соглашении об уровне услуг должны быть перечислены все параметры предоставляемых услуг, которые являются частью договора, заключаемого с организацией, предоставляющей публичные услуги.
    Результатом процесса управления качеством услуг должна быть значимая и своевременная информация о предоставлении услуг, полученная посредством эффективного специализированного мониторинга:
    - отчеты о несоответствии выполнения услуги;
    - сообщения о проблемах, приобретающих хронический характер;
    - сообщения о способах пользования услугой;
    - обзоры отзывов об услугах.
    Процесс управления качеством услуг осуществляется в соответствии со следующими принципами:
    - использование процессного подхода к организации предоставления услуг;
    - измерение показателей качества процессов;
    - контроль процессов в соответствии с определенными критериями и постоянное их усовершенствование.
    4.7.2. Основные требования, предъявляемые к процессу управления качеством услуг
    В процессе управления качеством услуг должны соблюдаться следующие требования:
    - получение информации от процессов управления сетью, процессов формирования и предоставления услуг и процессов обслуживания заказчиков;
    - разработка и принятие исчерпывающего перечня предоставляемых услуг;
    - планирование повышения качества услуг, формируя программу развития качества;
    - принятие необходимых мер для сохранения уровня услуг в согласованных пределах для каждого из классов услуг и для удовлетворения потребностей заказчиков.
    В процессе управления качеством услуг предъявляются следующие требования к персоналу, предоставляющему публичные услуги:
    - персонал должен иметь четкое представление о требованиях заказчика;
    - персонал должен уметь описывать услуги в терминах, понятных заказчику;
    - персонал должен четко описывать требования к предоставлению услуг для исполнителей.
    4.7.3. Управление эффективностью процесса управления качеством услуг
    К ключевым показателям эффективности процесса управления качеством услуг, характеризующим соответствие предоставляемых услуг требованиям качества, указанным в Соглашении об уровне услуг, относятся:
    - количество заказанных услуг;
    - количество поступивших запросов на обслуживание;
    - время, затраченное на оказание услуг;
    - количество просроченных запросов на обслуживание;
    - количество возникших инцидентов;
    - время простоя оборудования;
    - время недоступности услуги;
    - срок замены вышедшего из строя элемента ИТ-инфраструктуры и условия его подмены временным оборудованием.
    4.8. Процесс управления сетевыми сервисами
    4.8.1. Цели процесса управления сетевыми сервисами
    Цель управления сетевыми сервисами заключается в обеспечении защиты систем, объединенных в сеть, и контроле подключений к системам, объединенным в сеть.
    Управление сетевыми сервисами должно обеспечивать перемещение данных из одной системы в другую. Эта группа сервисов должна включать в себя семантику общей среды передачи данных, физическую сеть, охватывающую локальные и глобальные сети, каналы и протоколы передачи данных.
    Прямой доступ к функциям сетевых сервисов требуется для компьютерной телефонии, обмена видеоинформацией, конференц-связи. Задачей управления сетевыми сервисами является определение набора процедур, используемых для динамической установки, поддержки и разрыва соединений, которые требуются для обмена данными между пользователями сети и узлами коммутации.
    4.8.2. Функции и контроль процесса управления сетевыми сервисами
    Функции управления сетевыми сервисами определяют необходимые последовательности и форматы сообщений, обмен которыми осуществляется через сетевой интерфейс.
    При управлении сетевыми сервисами необходимо осуществлять контроль подключений к системам, объединенным сетью. Контроль ограничения возможности сетевых подключений осуществляется в соответствии с требованиями политики управления доступом.
    Контроль обеспечивается посредством:
    - межсетевых шлюзов, которые фильтруют данные, передаваемые по сети, с помощью предопределенных таблиц и правил;
    - персональных пользовательских брандмауэров, фильтрующих трафик защищаемого компьютера;
    - межсетевых сервисных интерфейсов;
    - алгоритмов аутентификации удаленных пользователей, компьютерных систем и оборудования;
    - полного контроля доступа к ИС;
    - системных сервисов и прикладных программ, следящих за содержимым веб- и почтового трафика, поступающим на компьютер.
    4.8.3. Основные требования, предъявляемые к процессу управления сетевыми сервисами
    К процессу управления сетевыми сервисами предъявляются следующие требования, которые характеризуют оценку соответствия требованиям данного процесса:
    - осуществление мониторинга состояния активного сетевого оборудования;
    - осуществление обработки критических событий, происходящих в сети;
    - проведение оповещения технического персонала о критических событиях в сети;
    - накопление статистической информации о функционировании, производительности, загруженности критических элементов сетевой инфраструктуры;
    - обеспечение контроля работоспособности, доступности, производительности серверного оборудования и приложений.

5. Управление процессом предоставления публичных услуг

    В данном разделе рассмотрены интегрированные процессы управления инцидентами, управления проблемами, управления конфигурациями, управления изменениями и управления релизами.
    5.1. Процесс управления инцидентами
    Цель процесса управления инцидентами – быстрое восстановление предоставления публичных услуг и минимизация отрицательного влияния инцидентов, обеспечивая поддержку наилучших уровней качества обслуживания и доступности.
    Инциденты, возникшие в результате отказов или ошибок в ИТ-инфраструктуре, приводят к реальным или потенциальным отклонениям от запланированной работы публичных услуг. При выявлении причины инцидента следует оформить запись о проблеме, с помощью которой идентифицируется корневая ошибка. Это логическая цепочка от первоначального уведомления до разрешения исходной проблемы.
    5.1.1. Основные требования, предъявляемые к процессу управления инцидентами
    К процессу управления инцидентами предъявляются следующие требования:
    - автоматическая регистрация инцидентов и предупреждение в случае обнаружения неисправности в майнфреймах, сетях, серверах;
    - возможность автоматической эскалации для обеспечения своевременной обработки инцидентов и запросов на обслуживание;
    - высокая гибкость и маршрутизация инцидентов;
    - автоматическая выборка данных из Конфигурационной базы данных учетных элементов о неработающих и затронутых инцидентом учетных элементах;
    - специализированное ПО;
    - наличие средств и модулей диагностики.
    Ответственность за мониторинг процесса разрешения всех зарегистрированных инцидентов несет Центр электронного правления (ЦЭП). Инциденты, которые ЦЭП сразу не может разрешить, должны быть переданы для обработки специализированным группам, обладающим более специализированными навыками, дополнительным временем и другими ресурсами для разрешения инцидентов. Разрешение или обходное решение должно быть представлено в максимально короткие сроки для восстановления обслуживания пользователей с минимальным влиянием на их работу. После устранения причины инцидента и восстановления согласованной услуги инцидент должен быть закрыт и должна быть составлена соответствующая документация.
    Статус инцидента должен отражать его текущее положение в жизненном цикле. В течение жизненного цикла инцидента необходимо, чтобы запись о нем поддерживалась в актуальном состоянии, что позволяет получать свежие данные о ходе обработки запроса.
    Следует регистрировать следующие обновления записи об инциденте:
    - сотрудник, сделавший изменение в записи;
    - детальное описание изменения;
    - дата и время изменения;
    - причина внесения изменений;
    - затраченное время.
    Приоритет инцидента должен определяться его влиянием на процессы в организации и срочностью, с которой необходимо обеспечить разрешение или обходное решение. Целевые показатели для разрешения инцидентов или обработки запросов должны быть включены в Соглашение об уровне услуг.
    Все инциденты должны регистрироваться в ЦЭП автоматически либо сотрудниками.
    После получения уведомления об инциденте ЦЭП должен записывать основные сведения, включая время и полученные подробности о симптомах, затем при наличии запроса на обслуживание заявка обрабатывается. Для дополнительной записи об инциденте на основе Конфигурационной базы данных учетных элементов происходит выбор учетных элементов, являющихся причиной инцидента. Следующими действиями, выполняемыми ЦЭП, являются установка соответствующего приоритета, оценка инцидента, предоставление рекомендаций по его разрешению. После успешного разрешения инцидента необходимы закрытие записи о нем, регистрация действий, связанных с его разрешением. После неудачной попытки разрешения инцидента или при выяснении, что необходим более высокий уровень поддержки, происходит передача инцидента специализированной группе.
    Во время процесса разрешения инцидент должен проверяться на наличие связей в базе данных проблем, известных ошибок и инцидентов. При наличии обходного решения или разрешения инцидент должен быть сразу же разрешен, в противном случае процесс управления инцидентами несет ответственность за разрешение или поиск обходного решения с минимальным прерыванием процессов предоставления публичных услуг. Обходное решение должно анализироваться командой управления проблемами, которая обновляет соответствующую запись о проблеме.
    5.1.2. Действия, осуществляемые в процессе управления инцидентами
    Для продуктивной работы процесса управления инцидентами необходимы:
    - своевременно обновляемая Конфигурационная база данных учетных элементов;
    - разработка своевременно обновляемой базы данных проблем и ошибок для хранения существующих разрешений и обходных решений;
    - обеспечение тесной связи с процессом управления уровнями обслуживания для определения требуемых показателей по времени реакции на инцидент.
    Процесс управления инцидентами получает необходимую для обработки информацию из следующих источников:
    - сведения об инциденте, представленные ЦЭП, подразделением обслуживания сетей или эксплуатационной службой;
    - сведения о конфигурации из Конфигурационной базы данных учетных элементов;
    - результаты привязки инцидента к проблемам и известным ошибкам; сведения о разрешении;
    - ответ на запрос на изменение, приводящий к разрешению инцидентов.
    В ходе выполнения действий и требований процесса управления инцидентами должна быть получена следующая информация:
    - запрос на изменение для разрешения инцидента;
    - обновленная запись об инциденте;
    - разрешенные и закрытые инциденты;
    - коммуникации с заказчиками;
    - управленческая информация, отчетность.
    Процесс управления инцидентами должен состоять из следующих действий:
    - обнаружение и регистрация инцидента;
    - классификация и первичная поддержка;
    - расследование и диагностика;
    - разрешение и восстановление;
    - закрытие инцидента;
    - контроль, мониторинг, отслеживание и коммуникации.
    Для поддержки контроля над полным жизненным циклом инцидента для каждого действия следует регистрировать: имя/идентификатор группы специалистов, которые записывают действия, тип действия (маршрутизация, диагностика, восстановление, разрешение, закрытие и т.д.), дата/время действия, описание и результат действия.
    5.1.2.1. Обнаружение и регистрация инцидентов
    В процессе обнаружения и регистрации инцидента должны поступать сведения об инциденте, на основании которых происходит запись основных сведений о нем, затем идет сигнал специализированной группе поддержки при необходимости и начало процедур обработки запроса на обслуживание. Все инциденты следует регистрировать, чтобы они попали в базу данных управления инцидентами. Симптомы, основные данные для диагностики и информация об учетных элементах, связанных с инцидентом, должны быть включены в записи об инциденте во время его обнаружения и записи.
    В записях об инциденте должны регистрироваться следующие данные:
    - уникальный регистрационный номер;
    - класс инцидента;
    - дата/время создания или изменения записи;
    - имя/ идентификатор специалиста или группы специалистов, которые создают или изменяют учетную запись;
    - имя/подразделение/телефонный номер/местоположение обращающегося пользователя;
    - способ обратной связи;
    - описание симптомов;
    - категория или подкатегория;
    - влияние/срочность/приоритет;
    - статус инцидента (активный, ожидание, закрыт, разрешен, в работе, новый, передан специалисту);
    - учетные элементы, задействованные в инциденте;
    - группа поддержки/специалист, которому передан инцидент;
    - проблема/известная ошибка, связанная с инцидентом;
    - дата и время разрешения;
    - категория закрытия;
    - дата и время закрытия.
    Эти данные необходимы для разрешения инцидента, последующего восстановления и для управленческой информации по типам инцидентов и статистике их возникновения. Инцидент должен обрабатываться в соответствии со стандартными процедурами управления уровнем обслуживания.
    5.1.2.2. Классификация и первичная поддержка инцидентов
    В процессе классификации и первичной поддержки инцидентов должны поступать сведения о конфигурации из Конфигурационной базы данных учетных элементов, а также результат привязки инцидента к проблемам и известным ошибкам.
    Для идентификации причины инцидента необходимо проанализировать записи базы данных управления инцидентами и выполнить следующие действия:
    - классификация инцидентов (см. 5.1.3);
    - привязка к проблемам и известным ошибкам;
    - информирование процесса управления проблемами об обнаружении новых проблем, об инцидентах, для которых не было найдено аналогов;
    - присвоение степени влияния и срочности;
    - определение приоритета;
    - оценка сведений о связанных конфигурациях;
    - предоставление первичной поддержки;
    - закрытие инцидента или его маршрутизация на специализированную группу поддержки, информирование пользователя.
    Инцидент должен быть классифицирован. В процессе классификации должны быть определены причины инцидента и соответствующие действия по его разрешению. Классификация используется для определения оказываемой услуги, с которой связан инцидент, связи ее с Соглашением об уровне услуг, выбора специалистов для обработки инцидента, определения приоритета и влияния инцидента на процессы организации, определения наличия связей с известными ошибками и решениями. При классификации инцидентов необходимо предоставление максимального количества информации.
    Важный аспект управления инцидентом – определение его приоритета. Ответственность за определение приоритета лежит на процессе управления уровнем обслуживания. Приоритет инцидента зависит от следующих факторов: влияние на процессы предоставления публичных услуг, срочность, размеры, границы, сложность, доступность ресурсов, необходимых для устранения неисправности.
    При определении степени влияния необходим доступ к Конфигурационной базе данных учетных элементов для установления количества пользователей, которых затрагивает инцидент.
    Срочность инцидента – скорость, с которой его необходимо разрешить.
    5.1.2.3. Расследование и диагностика инцидентов
    В процессе расследования и диагностики инцидента должны поступать обновленные сведения об инциденте, конфигурации из Конфигурационной базы данных учетных элементов, а также выполняться действия по анализу и сбору сведений об инциденте, поиску обходного решения или передачи инцидента группе поддержки.
    После передачи инцидента группе поддержки она должна:
    - обработать инцидент;
    - указать дату и время для регулярного обновления статуса инцидента;
    - предоставить рекомендации ЦЭП по найденным обходным решениям;
    - сопоставить инцидент с известными ошибками, проблемами, решениями;
    - определить решение инцидента, обновить необходимые данные;
    - передать инцидент ЦЭП для его закрытия.
    Процесс расследования и диагностики может повторяться циклически, по мере устранения причин возникновения инцидента.
    5.1.2.4. Разрешение инцидента и восстановление услуги
    Результатом процесса разрешения инцидента и восстановления услуги должны быть обновленные сведения об инциденте, ответы на запрос на изменение, приводящие к разрешению инцидентов, обходные решения и способы разрешения инцидента.
    В процессе разрешения и восстановления необходимо выполнять действия по разрешению инцидента, используя способ разрешения, обходное решение или запрос на изменение, а также действия по восстановлению. После успешного разрешения инцидента требуется начинать действия по восстановлению услуги, которые выполняются специализированным персоналом.
    5.1.2.5. Закрытие инцидента
    Результатом процесса закрытия инцидента должны быть обновленные сведения об инциденте и разрешенный инцидент.
    В процессе закрытия инцидента необходимо осуществлять подтверждение разрешения инцидента его заявителем. После закрытия инцидента ЦЭП должен удостовериться, что:
    - сведения о действиях по разрешению инцидента лаконичны и понятны;
    - существует четкая классификация исходной причины инцидента;
    - действия по разрешению инцидента согласованы с заказчиком.
    5.1.2.6. Контроль, мониторинг, отслеживание и коммуникации
    Контроль, мониторинг, отслеживание и коммуникации должны включать записи об инцидентах. В процессе контроля, мониторинга, отслеживания и коммуникации должны осуществляться мониторинг эскалации инцидентов, информирование пользователей.
    ЦЭП несет ответственность за контроль и наблюдение за разрешением всех открытых инцидентов. Для этого необходимо регулярно выполнять следующие действия:
    - отслеживать статус и ход разрешения всех открытых инцидентов;
    - проверять соответствие уровням обслуживания;
    - отмечать инциденты, передаваемые между специализированными группами;
    - отдавать приоритет мониторингу инцидентов с высокой степенью влияния;
    - информировать пользователей, затронутых инцидентом.
    Результатом выполнения этих действий являются управленческие отчеты о ходе разрешения инцидента, отчеты и коммуникации с заказчиком.
    5.1.3. Классификация инцидентов
    Классификация инцидентов должна быть корректно проведена для достижения следующих целей:
    - определения услуги или оборудования, с которыми связан инцидент;
    - выбора тех специалистов, которые наилучшим образом справятся с устранением инцидента;
    - определения приоритета и влияния на функционирование процессов предоставления публичных услуг;
    - определения критериев привязки при выборе того или иного решения;
    - определения матрицы отчетности для управленческой информации.
    Уровни классификации зависят от требуемого уровня детализации. Детальная классификация обеспечивает более эффективное использование управленческой информации, которая периодически должна анализироваться с целью использования только новейших данных.
    5.1.4. Показатели эффективности процесса управления инцидентами
    Для улучшенного мониторинга и управленческой информации по качеству услуг, обеспечения снижения влияния на процессы предоставления публичных услуг, лучшего использования персонала, исключения потерянных и неправильно введенных инцидентов и запросов на обслуживание необходимо измерять такие показатели, как:
    - общее количество инцидентов;
    - среднее фактическое время, затраченное на разрешение инцидента или поиск обходного решения;
    - процент инцидентов, обработанных в рамках согласованного времени реакции;
    - средние затраты на инцидент;
    - процент инцидентов, закрытых ЦЭП, без обращения к специализированным группам;
    - обработанные инциденты по каждой рабочей станции ЦЭП;
    - количество и процент инцидентов, разрешенных удаленно.
    5.2. Процесс управления проблемами
    Цель процесса управления проблемами – минимизировать количество и отрицательное влияние инцидентов и проблем, вызванноe ошибками в ИТ-инфраструктуре, на процессы предоставления публичных услуг. Для достижения данной цели необходимо осуществлять поиск причин инцидентов и действия по улучшению или исправлению ситуации.
    В процесс управления проблемами должны входить действия, связанные с реагированием на инциденты, и упреждающие действия. Действия управления проблемами должны включать обновление рекомендованных обходных решений и записи о проблеме для поддержки контроля инцидентов.
    Результатом процесса управления проблемами должно быть представление информации об обнаруженных проблемах, известных ошибках и оформленных запросах на изменение.
    5.2.1. Основные требования, предъявляемые к процессу управления проблемами
    К процессу управления проблемами предъявляются следующие требования:
    - хранящаяся информация должна быть организована и легкодоступна;
    - обновление документации (технологии, доступные внешние решения, практический опыт, частота и влияние повторяющихся инцидентов) должно происходить регулярно;
    - проведение детального анализа процесса управления проблемами и составление соответствующей документации;
    - наличие квалифицированного персонала;
    - наличие хранилища информации, основанного на интегрированных средствах управления услугами;
    - использование экспертных систем.
    Проблемы и известные ошибки должны выявляться при помощи анализа инцидентов по мере их возникновения и в различные промежутки времени, анализа ИТ-инфраструктуры, подготовки базы знаний, деятельности разработчиков и поставщиков при вводе в эксплуатацию новых продуктов.
    5.2.2. Действия процесса управления проблемами
    В рамках процесса управления проблемами необходимо осуществлять контроль проблем и ошибок, упреждающее управление проблемами. Все проблемы должны быть известны и зарегистрированы в рамках процесса управления проблемами.
    Для осуществления процесса управления проблемами требуются сведения об инцидентах, сведения о конфигурации из Конфигурационной базы данных учетных элементов, обходные решения.
    При реализации процесса управления проблемами должна быть получена и документирована следующая информация: известные ошибки, запросы на изменение, обновленные записи о проблемах, разрешенные проблемы, закрытые записи о проблемах, управленческая информация.
    Процесс управления проблемами состоит из следующих действий:
    - контроль проблем;
    - контроль ошибок;
    - упреждающее предотвращение проблем;
    - определение тенденций;
    - получение управленческой информации;
    - анализ крупных проблем (осуществляется после разрешения каждой крупной проблемы).
    5.2.2.1. Контроль проблем
    Контроль проблем состоит в эффективной и результативной обработке проблем. Основной целью является определение корневой причины, вызвавшей неисправность и обеспечение ЦЭП информацией и рекомендациями об обходных решениях. Контроль проблем зависит от качества контроля инцидентов и предоставляет рекомендации о лучших обходных решениях.
    В ходе контроля проблем необходимо выполнять следующие действия:
    - идентификация и запись проблемы;
    - классификация проблемы;
    - анализ и диагностика проблемы;
    - запрос на изменение;
    - разрешение и закрытие проблемы.
    5.2.2.1.1. Идентификация и запись проблемы
    Идентификация проблемы должна осуществляться в случае, когда выполняется одно или несколько условий, перечисленных ниже:
    - при первичной поддержке и классификации инцидента не удалось привязать его к существующим проблемам и известным ошибкам;
    - инцидент является повторяющимся;
    - инцидент не связан с существующими проблемами и известными ошибками;
    - анализ ИТ-инфраструктуры указывает на проблему, которая потенциально может привести к инцидентам;
    - возникает крупный, значительный инцидент, для которого необходимо найти структурное решение.
    Записи о проблемах должны содержаться в Конфигурационной базе данных учетных элементов. Записи о проблемах соединены со всеми сопутствующими им записями об инцидентах.
    5.2.2.1.2. Классификация проблем
    В процессе классификации требуется определять объем усилий, требуемых для нахождения и восстановления вышедших из строя учетных элементов, категорию, влияние, срочность и приоритет проблемы. Категории проблем распределены по связанным группам или областям знаний (аппаратное обеспечение, ПО, коммуникационное обеспечение, ПО поддержки и т.д.).     Влияние проблемы определяет распределение усилий по поддержке публичных услуг. При определении приоритета проблемы необходимо принимать во внимание срочность, влияние, риски и доступность ресурсов.
    Срочность в свою очередь должна определять степень задержки, которую можно допустить при разрешении проблемы или ошибки. На срочность проблемы влияют следующие аспекты:
    - доступность временного устранения ошибки;
    - существование обходного решения;
    - возможность планируемой задержки разрешения проблемы;
    - влияние проблемы, которое указывает степень уязвимости процессов, связанных с предоставлением публичных услуг.
    5.2.2.1.3. Анализ и диагностика проблем
    Анализ и диагностика проблемы должны определять причину неисправности в зарегистрированном учетном элементе, после чего необходимо начинать работу системы контроля ошибок.
    Для диагностики проблем необходимо обеспечить эффективные процедуры по сбору аналитических данных, связанных с разрешением проблем, также требуются точные учетные данные о последних изменениях, поскольку они могут указывать на причины проблем.
    При структурном анализе и диагностике проблем должны применяться следующие методы:
- Кепнер и Трего – согласно методу анализ проблем должен быть систематическим процессом, направленным на их решение. Метод выделяет фазы анализа проблем:
    1) -определение проблемы;
    2) -описание проблемы, включая сущность, особенности, местоположение, время и размеры;
    3) -определение возможных причин;
    4) -тестирование наиболее вероятной причины;
    5) -проверка настоящей причины;
    - диаграммы Ишикавы – причинно-следственные диаграммы, показывающие факторы, влияющие на проблему;
    - метод “мозгового штурма”;
    - методы блок-схем.
    В ходе процесса анализа и диагностики проблем необходим доступ к документации на все продукты в ИТ-инфраструктуре в качестве справочной информации, как для процесса, так и для персонала службы поддержки. Эта информация должна включать документацию по прикладным системам, системному ПО, внутренним сервисным программам, сетевому аппаратному обеспечению и ПО, общим диаграммам конфигураций сетей.
    5.2.2.2. Контроль ошибок
    Контроль ошибок должен охватывать процессы, вовлеченные в ход работ, связанных с известными ошибками, до тех пор, пока они не устранены. Основной целью данного процесса является уведомление об ошибках, их мониторинг и устранение.
    Контроль ошибок должен объединять среду разработки и среду эксплуатации. Ошибки в программном обеспечении на этапе разработки могут влиять на работу в среде эксплуатации. Информация об известных ошибках, найденных в среде разработки или среде сопровождения, должна быть передана в среду эксплуатации.
    В ходе контроля ошибок необходимо выполнение следующих действий:
    - идентификация и запись ошибок;
    - оценка ошибок;
    - запись о ходе разрешения ошибок;
    - закрытие ошибок;
    - мониторинг проблем и прогресса разрешения ошибок.
    Контроль ошибок напрямую связан и действует совместно с процессами управления изменениями. Процесс контроля ошибок должен состоять из этапов обнаружения и записи ошибки, оценки ошибки, записи решения по ошибке, закрытия ошибки и сопутствующей проблемы.
    Ошибка должна быть определена тогда, когда найден учетный элемент, установлена корневая причина проблемы и найдено обходное решение. Источниками данных об известных ошибках должны выступать подсистемы контроля проблем в среде разработки и среде эксплуатации. Запись об известной ошибке должна содержать идентификатор запроса на изменение.
    Ошибки должны определяться и записываться в порядке расследования и диагностики – действий по контролю проблем.
    Процедура разрешения каждой известной ошибки должна записываться в системе управления проблемами. Необходимо, чтобы все данные об учетных элементах, симптомах, действиях по разрешению или обходному решению, связанные со всеми известными ошибками, находились в базе данных известных ошибок. Эти данные должны быть доступны для привязки инцидентов, нахождения обходных решений и предоставления управленческой информации.
    После внедрения изменений по устранению ошибки соответствующие записи об известной ошибке должны закрываться вместе со всеми связанными записями об инцидентах и проблемах. Контроль ошибок несет ответственность за мониторинг хода работ, связанных с разрешением известных ошибок.
    Подготовка запроса на изменение входит в обязанности процесса контроля ошибок.
    5.2.2.3. Упреждающее предотвращение проблем
    Упреждающее предотвращение проблем должно охватывать действия, нацеленные на нахождение и разрешение проблем до их возникновения, сводя к минимуму отрицательное воздействие на оказание публичных услуг.
    При этом необходимо выполнять следующие действия:
    - анализ тенденций;
    - действия по поддержке;
    - обеспечение организации информацией.
    Упреждающее предотвращение проблем должно обеспечивать улучшение качества предоставления публичных услуг и более эффективное использование доступных информационных ресурсов.
    Задача упреждающего управления проблемами заключается в эффективном направлении ограниченных ресурсов по поддержке услуг, определению проблемных мест, оказывающих наибольшее негативное влияние на процесс предоставления публичных услуг.
    Основная упреждающая деятельность процесса управления проблемами - это анализ тенденций и направлений действий по предотвращению возникновения проблем. Отчеты по анализу инцидентов и проблем должны предоставлять информацию об упреждающих мерах, которые могут улучшить качество предоставляемых публичных услуг. Анализ инцидентов и проблем должен определять тенденции, неисправности определенного типа, находящиеся в их начальных стадиях, повторяющиеся инциденты и связанные с их возникновением проблемы.
    5.2.2.4. Определение тенденций
    Определение тенденций приводит к определению потенциальных проблемных мест, которые нуждаются в расследовании. Определение и анализ тенденций должны приводить к идентификации неисправностей в ИТ-инфраструктуре, определению общих проблемных мест, нуждающихся в большем внимании со стороны службы поддержки.
    5.2.2.5. Получение управленческой информации
    Получение управленческой информации должно обеспечивать понимание того, какие усилия и ресурсы потрачены организацией на расследование, диагностику и разрешение проблем и известных ошибок.
    В состав управленческой информации должны быть включены:
    - количество оформленных запросов на изменение;
    - влияние запросов на изменение на доступность и надежность предоставляемых публичных услуг;
    - объем времени, потраченного на расследование и диагностику проблемы по каждой организационной единице;
    - количество и влияние инцидентов, возникающих до закрытия корневой проблемы;
    - пропорция усилий, потраченных на реагирование по поддержке, по отношению к запланированным усилиям в процессе управления проблемами;
    - планы по разрешению открытых проблем по отношению к ресурсам и бюджету;
    - описание предпринимаемых действий.
    5.2.2.6. Анализ крупных проблем
    При разрешении каждой крупной проблемы должен выполняться ее анализ. Анализ необходим для определения верных и неверных действий по устранению проблемы, мер по предотвращению повторного появления данной проблемы.
    Процесс управления проблемами должен осуществлять мониторинг долгосрочного влияния проблем и известных ошибок на оказываемые публичные услуги.
    5.2.3. Показатели эффективности процесса управления проблемами
    Историческая информация о контроле инцидентов и проблем дает возможность получить метрики, показывающие качество обслуживания и производительность процесса оказания публичных услуг. Метрикой эффективности по отношению к согласованным уровням обслуживания являются частота и длительность проблем.
    Для улучшения качества предоставляемых публичных услуг, уменьшения количества инцидентов, улучшения процесса обучения персонала, повышения процента запросов, разрешенных во время первого обращения, ЦЭП должен рассчитывать следующие показатели:
    - общее количество проблем;
    - общее количество ошибок;
    - среднее фактическое время, затраченное на разрешение проблем или поиск обходного решения;
    - средние затраты на разрешение проблемы или ошибки;
    - количество и процент проблем, разрешенных удаленно;
    - количество предупрежденных проблем ИТ-инфраструктуры, в том числе и процессом управления доступностью.
    Взаимодействие между процессом управления проблемами и процессом управления доступностью приводит к улучшению качества обслуживания.
    Процесс управления проблемами должен регулярно анализировать полученные достижения по всем целевым показателям.
    5.3. Процесс управления изменениями
    Цель процесса управления изменениями заключается в обеспечении использования стандартных методов и процедур для продуктивной и своевременной обработки изменений, для минимизации влияния инцидентов, связанных с изменениями, на качество предоставляемых публичных услуг.
    Информация о процессах управления изменениями должна быть открытой для перехода к новому состоянию при проведении изменений.
    Для выполнения данного процесса необходимо наличие запросов на изменение, Конфигурационной базы данных учетных элементов, согласованного графика изменений.
    В процессе управления изменениями должны составляться согласованный график изменений, запросы на изменение, отчеты управления изменениями.
    5.3.1. Основные требования, предъявляемые к процессу управления изменениями
    Процесс управления изменениями должен ежедневно управлять происходящими изменениями.
    К процессу управления изменениями предъявляются следующие требования:
    - проведение фильтрации изменений;
    - составление плана изменений;
    - проведение анализа и закрытия запросов на изменение;
    - составление управленческой отчетности.
    5.3.1.1. Фильтрация изменений
    Фильтрация изменений должна осуществляться по отношению к следующим информационным объектам:
    - аппаратному обеспечению;
    - коммуникационному оборудованию и ПО;
    - системному ПО;
    - прикладному ПО, находящемуся в эксплуатации;
    - документации и процедурам сопровождения и поддержки систем, находящихся в эксплуатации.
    В рамках процесса управления изменениями должно предоставляться подтверждение любого предложенного изменения. Управление изменениями не отвечает за идентификацию компонентов, затронутых изменением, обновление записей об изменениях, релизы новых или измененных компонентов. Все действия в процессе изменения должны записываться, по мере их проведения, в журнал управления изменениями.
    По мере регистрации изменений в рамках процесса управления изменениями необходимо проводить краткое рассмотрение каждого запроса, при этом непрактичные запросы отфильтровываются.
    До утверждения каждого изменения необходимо рассмотрение рисков для процессов предоставления публичных услуг, а также рассмотрение оценки влияния и ресурсов. Утверждение изменения должно включать финансовое, техническое и организационное утверждение. Финансовое утверждение определяет рамки бюджета изменения. Техническое утверждение определяет осуществимость, рациональность и выполнимость изменения без ущерба для процесса предоставления услуг. Организационное утверждение определяет требования, обусловленные предоставлением публичных услуг, и ожидания участников взаимодействия и пользователей публичных услуг.
    5.3.1.2. Составление плана изменений
    Для улучшения процесса управления изменениями необходимо координировать разработку и распространение согласованных плана и графика изменений, а также ожидаемой доступности услуг. Эта документация должна быть общедоступна.
    Согласованные план и график изменений должны содержать сведения обо всех изменениях, утвержденных к внедрению, и предполагаемые даты их внедрения. Ожидаемая доступность услуги должна содержать сведения об изменениях в Соглашении об уровне услуг и о доступности услуг при планируемых изменениях.
    5.3.1.3. Анализ запросов на изменение
    В процессе управления изменениями должен проводиться анализ всех внедренных изменений. Целью анализа является установить, что:
    - изменение привело к ожидаемому эффекту и достигло поставленных целей;
    - пользователи удовлетворены результатами;
    - выявлены все недочеты;
    - не возникло побочных эффектов в функциональности, доступности, производительности, безопасности, возможности обслуживания;
    - объем ресурсов, использованных для внедрения изменения, соответствует запланированному объему;
    - изменение было внедрено своевременно;
    - план отката функционировал верно.
    В случае, если изменение не достигло поставленных целей, необходимо принятие решения о последующих действиях. Процесс управления изменениями должен инициировать последующие действия для устранения всех проблем или недостатков, которые возникли в самой системе управления изменениями в результате неэффективных изменений.
    5.3.1.4. Составление управленческой отчетности
    При формировании управленческих отчетов необходимо рассмотрение следующей информации и статистики:
    - количество изменений, внедренных за период времени;
    - распределение изменений в соответствии с причинами их проведения;
    - количество успешно проведенных изменений;
    - количество возвратов в предыдущее состояние при проведении изменений;
    - количество и причины инцидентов, которые привели к изменениям;
    - количество запросов на изменение;
    - количество проанализированных внедренных изменений и количество изменений, ожидающих анализа;
    - количество отклоненных запросов на изменение;
    - изменения, ожидающие внедрения.
    Эта информация используется как основа для оценки продуктивности и эффективности процесса управления изменениями.
    Аудит процесса управления изменениями должен проводиться минимум раз в год.
    Аудит должен включать проверку следующих элементов:
    - случайно выбранных запросов на изменение;
    - записей об изменениях;
    - анализа запросов на изменение.
    5.3.2. Действия процесса управления изменениями
    Процесс управления изменениями играет наблюдательную роль в тестировании всех изменений.
    Запросы на изменение могут быть связаны с любой частью ИТ-инфраструктуры, любой услугой, деятельностью. Необходимо установление процедур документирования запросов на изменение.
    Все принятые запросы на изменение должны регистрироваться и получать идентификационный номер.
    В процессе реализации управления изменениями должны выполняться следующие действия:
    - определение причин запросов на изменение;
    - определение формы запроса на изменение;
    - определение приоритетов запросов на изменение;
    - разработка, тестирование и внедрение изменений;
    - использование программных средств управления изменениями.
    5.3.2.1. Определение причин запросов на изменение
    Для составления запросов на изменение должны быть определены следующие причины:
    - решение, указанное в отчете об инциденте или проблеме;
    - неудовлетворенность пользователя уровнем услуг;
    - предложение о введении или удалении учетного элемента;
    - предложение по модернизации компонентов ИТ-инфраструктуры;
    - изменение требований или содержания процессов, обеспечивающих предоставление публичных услуг;
    - нововведения или изменения в законодательстве;
    - изменение местоположения;
    - изменения в предоставляемых услугах.
    5.3.2.2. Определение формы запроса на изменение
    В форму запроса на изменение должны быть включены следующие элементы:
    - порядковый номер запроса на изменение с перекрестной ссылкой на номер отчета о проблеме;
    - описание и идентификация элемента, который необходимо изменить;
    - причина внесения изменения;
    - последствия в случае невнедрения изменения;
    - версия изменяемого элемента;
    - реквизиты лица, предлагающего изменение;
    - дата предложения изменения;
    - приоритет изменения;
    - оценка влияния и ресурсы;
    - рекомендации консультативного комитета по изменениям;
    - планируемое внедрение;
    - сведения о группе разработчиков изменения;
    - оценка и управление рисками;
    - статус запроса на изменение.
    Отчет о результатах завершения изменения должен быть направлен лицам, ответственным за управление изменениями, затем изменение утверждается. По мере продвижения изменения по жизненному циклу запрос на изменение и Конфигурационная база данных учетных элементов должны обновляться.
    5.3.2.3. Определение приоритетов запросов на изменение
    Каждому запросу на изменение должен быть присвоен приоритет, исходя из влияния проблемы и срочности, с которой требуется восстановление. При присвоении приоритета особую важность имеет оценка риска внедрения или отклонения от изменения. Для каждого приоритета должны быть определены временные рамки. Приоритеты подразделяются на:
    - срочный – кратковременная задержка рассмотрения изменения приводит к прекращению предоставления услуг или серьезным проблемам;
    - высокий – изменение оказывает серьезное влияние на работу нескольких пользователей;
    - средний – влияние изменения незначительно, но меры по устранению не могут откладываться до следующего по графику релиза;
- низкий – изменение оправданно и необходимо, но может подождать до следующего по графику релиза.
    Приоритет должен показывать порядок, в котором следует устранять проблемы.
    5.3.2.4. Разработка, тестирование и внедрение изменений
    Утвержденные запросы на изменение должны передаваться соответствующим техническим группам для разработки и подготовки к внедрению изменения. Подготовка к внедрению изменения должна включать:
    - сборку нового модуля;
    - создание новой версии одного или более программных модулей;
    - внешнюю закупку или получение оборудования;
    - подготовку модификации аппаратного обеспечения;
    - подготовку новой или обновленной документации;
    - подготовку пользователей.
    Для каждого авторизированного изменения необходимы подготовка и документирование процедур отката, для их активизации в случае возникновения ошибок с минимальным воздействием на качество предоставляемых услуг.
    Для предотвращения отрицательного воздействия изменений на качество оказываемых публичных услуг необходимо заранее протестировать изменение.
    Тестирование изменения должно учитывать следующие аспекты:
    - производительность;
    - безопасность;
    - возможность обслуживания;
    - поддерживаемость;
    - надежность и доступность;
    - функциональность.
    Управление изменениями должно оценивать риски для процессов предоставления публичных услуг по каждому изменению, которое внедряется без полного тестирования. Тестирование должно включать достаточный уровень регрессионного тестирования для достаточности доказательств отсутствия отрицательного воздействия изменения на другие компоненты инфраструктуры.
    График внедрения изменений должен быть составлен таким образом, чтобы оказывать минимальное воздействие на услуги, находящиеся в эксплуатации.
    Все изменения должны быть ожидаемыми и спланированными, при этом необходимо учитывать доступность ресурсов для разработки и тестирования этих изменений.
    Для срочных изменений необходима разработка процедур для их быстрой обработки без потери нормального уровня управленческого контроля.
    5.3.2.5. Использование программных средств управления изменениями
    Программные средства процесса управления изменениями должны обладать следующими характеристиками:
    - запросы на изменение и записи о проблемах должны храниться в одной базе данных в легкодоступном формате;
    - наличие возможности находить связи между запросами на изменение, записями о проблемах и учетными элементами;
    - наличие возможности связывать запросы на изменение с проектами;
    - автоматическое создание запросов на оценку воздействия вовлеченных учетных элементов;
    - поддержка записи действий по этапам авторизации и внедрения запросов;
    - регистрация информации о разработке и тестировании изменений;
    - определение процедур отката при неудачных изменениях;
    - автоматическое напоминание о проведении анализа внедренных изменений;
    - автоматическая подготовка управленческой информации, связанной с изменениями;
    - способность сборки изменений;
    - автоматическое создание запросов на изменение;
    - отслеживание процесса управления изменениями и последовательности выполняемых действий.
    Программные средства должны обладать возможностью удаленного обновления централизованных баз данных.
    5.3.3. Показатели эффективности процесса управления изменениями
    Для улучшения согласованности публичных услуг, предоставления большей информации об изменениях, улучшения оценки рисков, уменьшения отрицательного влияния изменений на качество услуг, уменьшения количества изменений, улучшения управления проблемами и доступностью, повышения продуктивности работы пользователей и обработки больших объемов изменений необходимо использование следующих показателей:
    - количество отрицательных воздействий на качество услуг;
    - количество инцидентов, возникших в результате внедрения изменений;
    - количество откатов изменений;
    - количество срочных изменений;
    - соответствие между согласованным графиком изменений и реальным внедрением изменений;
    - отсутствие запросов на изменение с высоким приоритетом в списке ожидания;
    - регулярный анализ запросов на изменение и внедренных изменений;
    - коэффициент успешности внедрения изменений;
    - процент необоснованно отклоненных запросов на изменение.
    Для эффективного управления процессом предоставления услуг необходимо организованное проведение изменений без ошибок и неверных решений. Для удовлетворительного предоставления услуг необходимо рациональное управление изменениями.
    5.4. Процесс управления конфигурациями
    Цель процесса управления конфигурациями - учет всех информационных активов и конфигураций в рамках организации и ее услуг, предоставление документации для поддержки процессов управления услугами, предоставление и проверка информации о конфигурации, а также обеспечение основы для процессов управления инцидентами, проблемами, изменениями, релизами.
    Управление конфигурациями должно охватывать идентификацию, учет и отчеты об информационных компонентах ИТ-инфраструктуры. Элементы, которые должны контролироваться процессом управления конфигурациями, включают все компоненты ИТ-инфраструктуры и ПО.
    Управление конфигурациями должно быть связано с системной разработкой, тестированием, управлением изменениями и управлением релизами, а также должно сохранять и обеспечивать безопасность конфигурационного базиса, его содержимого, документации и отчетов.
    Система управления конфигурациями должна обеспечивать:
    - контроль безопасности;
    - поддержку учетных элементов различной сложности;
    - легкое добавление новых учетных элементов и удаление старых;
    - автоматическую проверку вводимых данных;
    - автоматическую установку всех связей нового учетного элемента в момент его добавления;
    - поддержку учетных элементов с различными кодами моделей, номерами версий и копий;
    - ведение исторических записей обо всех учетных элементах;
    - гибкие средства отчетности.
    5.4.1. Основные требования, предъявляемые к процессу управления конфигурациями
    В процессе управления конфигурациями необходимо осуществить следующие деятельности:
    - планирование – определение назначения, масштаба, политики, целей, процедур для управления конфигурациями;
    - идентификация конфигураций – выбор структуры конфигурации всех учетных элементов, принадлежащих инфраструктуре, их взаимосвязи и конфигурационной документации. Идентификация должна включать распределение идентификаторов, номеров версий учетных элементов, нанесение маркировки на каждый учетный элемент и запись сведений о них в Конфигурационную базу элементов;
    - контроль конфигураций – обеспечение приема и регистрации авторизированных и идентифицируемых учетных элементов на протяжении всего их жизненного цикла. Контроль должен обеспечивать наличие соответствующей контролирующей документации на добавление, модификацию, замену или удаление каждого учетного элемента;
    - учет статусов конфигураций предусматривает отчетность по всем текущим и историческим данным по каждому учетному элементу в течение его жизненного цикла. Учет статусов должен отслеживать изменения в учетных элементах и их учетных записях;
    - проведение проверок и аудита конфигураций – последовательность обзоров и аудитов, проверяющих физическое существование учетных элементов и правильность их регистрации в системе управления конфигурациями.
    5.4.1.1. Планирование управления конфигурациями
    Планирование управления конфигурациями должно определять:
    - стратегию, политику, рамки и цели управления конфигурациями;
    - сопутствующие политики, стандарты и процессы процесса управления услугами;
    - роли и обязанности управления конфигурациями;
    - анализ текущего состояния активов и конфигураций;
    - технические и управленческие действия процесса управления конфигурациями;
    - политику процессов управления изменениями и управления релизами;
    - взаимодействие между проектами, поставщиками, приложениями и группами поддержки;
    - местоположение хранилищ и библиотек для хранения аппаратного обеспечения, ПО и документации.
    Управление конфигурациями должно включать тщательное планирование контроля над ИТ-инфраструктурой и услугами по всем распределенным системам. Средства систем управления конфигурациями проектов, находящихся в разработке, должны работать интегрировано.
    Основными действиями процесса управления конфигурациями по планированию являются:
    - подробный анализ взаимодействия процесса управления конфигурациями с другими процессами управления оказанием услуг;
    - анализ возможностей процесса управления конфигурациями;
    - обзор конфигурационных данных;
    - сбор и пересмотр данных по требованиям и функциональным спецификациям;
    - выбор средств автоматизации Конфигурационной базы данных учетных элементов;
    - определение типов учетных элементов, их атрибутов, типов взаимосвязей;
    - разработка процессов и процедур управления конфигурациями;
    - планирование и обеспечение безопасных хранилищ учетных элементов совместно с процессом управления релизами.
    5.4.1.2. Идентификация конфигураций
    Идентификация конфигураций должна определять выбор, идентификацию и маркировку конфигурационных структур и учетных элементов. Идентификация конфигурации должна включать присвоение идентификаторов учетным элементам и их конфигурационную документацию, а также определять, на каком уровне должен осуществляться контроль и уровень разбивки обобщенных учетных элементов на компоненты.
    5.4.1.2.1. Конфигурационная база данных учетных элементов
    Идентификация и документация конфигурации должна увеличивать эффективность управления изменениями. Процесс управления конфигурациями требует использования средств поддержки для хранения эталонных копий ПО и документации, в том числе Конфигурационной базы данных учетных элементов.
    Конфигурационная база данных учетных элементов должна содержать связи между всеми компонентами системы, включая инциденты, проблемы, известные ошибки, изменения и релизы. Конфигурационная база данных учетных элементов должна включать информацию об инцидентах, известных ошибках и проблемах, в том числе данные о сотрудниках, поставщиках, пользователях, организационных подразделениях по каждому учетному элементу. Она должна обновляться автоматически, когда изменяется статус учетных элементов и релизов.
    Конфигурация ИТ-инфраструктуры должна быть разбита на части, которым присваиваются уникальные идентификаторы, что позволяет эффективно контролировать и регистрировать учетные элементы, формировать детализированные отчеты.
    5.4.1.2.2. Компоненты идентификации конфигурации
    В рамки идентификации конфигурации должны входить используемое аппаратное обеспечение и ПО для сборки, релизов, верификации, инсталляции, распространения, поддержки, восстановления и списания учетных элементов. Обязательными компонентами, для которых необходимо проводить идентификацию конфигураций, являются:
    - аппаратное обеспечение, включая компоненты сети;
    - системное ПО;
    - системы и приложения организации, разработанные по заказу;
    - готовые программные пакеты, стандартные продукты и продукты работы с базами данных;
    - конфигурационные базисы;
    - релизы ПО;
    - конфигурационная документация, лицензии, соглашения о сопровождении, соглашения об уровне услуг.
    Компоненты должны классифицироваться по типам учетных элементов (например, программные продукты, системное ПО, аппаратное обеспечение), что позволяет определять и документировать используемые элементы, их статус и местоположение.
    5.4.1.2.3. Атрибуты учетных элементов
    При управлении конфигурациями требуется планировать, какие атрибуты должны быть зарегистрированы. Для разных типов учетных элементов атрибуты различаются.
    Для регистрации учетных элементов должен использоваться следующий список атрибутов:
    - название учетного элемента;
    - номер копии, серийный номер (уникальный идентификатор учетного элемента);
    - категория учетного элемента;
    - тип учетного элемента;
    - номер модели для аппаратного обеспечения;
    - дата истечения гарантийного обслуживания;
    - номер версии учетного элемента;
    - местоположение учетного элемента;
    - ответственный владелец;
    - источник, поставщик учетного элемента;
    - лицензия;
    - даты поставки и приемки;
    - статус учетного элемента;
    - связи учетного элемента со всеми другими учетными элементами;
    - номера запросов на изменения, номера изменений, проблем, инцидентов.
    Конфигурационный базис должен определяться для конкретной цели, входящая в него информация и учетные элементы должны контролироваться.
    Необходимо определение системы управления информацией для идентификации учетных элементов, конфигурационной документации, изменений, конфигурационных базисов, релизов и сборок. Система управления информацией должна быть уникальна и принимать во внимание корпоративную структуру организации. Она должна разрешать управление иерархическими взаимосвязями между учетными элементами, изменениями и инцидентами.
    Все учетные элементы должны быть маркированы идентификатором конфигурации. Всем учетным средствам аппаратного обеспечения необходима физическая, несъемная маркировка, которую нельзя удалить. Все кабели и линии связи должны быть четко маркированы на каждом конце и во всех местах проверки.
    Эталонные копии ПО в библиотеке эталонного ПО должны иметь маркировку ПО, содержащую наименование учетного элемента и номер версии. Все носители, содержащие ПО, должны быть четко маркированы названием учетного элемента, номером копии и номером версии каждого элемента ПО, содержащегося на носителе.
    5.4.1.3. Контроль конфигураций
    Цель контроля конфигураций заключается в обеспечении записи в Конфигурационную базу данных только авторизированных и распознаваемых учетных элементов. Процедуры контроля конфигураций должны обеспечивать целостность данных организации, систем и процессов.
    Процесс контроля конфигураций должен обеспечивать допуск только авторизированного и лицензированного ПО в библиотеку эталонного ПО, а также их защиту. Доступ к библиотеке эталонного ПО должен быть только у авторизированного персонала. Существующие элементы, находящиеся под контролем управления конфигурациями, не должны изменяться без авторизации. Все неавторизированные версии учетных элементов и сами учетные элементы должны быть ликвидированы или переведены под контроль управления конфигурациями.
    Постоянные процедуры контроля конфигураций должны включать:
    - регистрацию всех новых учетных элементов и их версий;
    - обновление записей об учетных элементах (изменение статуса, обновление атрибутов, изменения во владении или ролях, новые версии документации, контроль лицензий);
    - обновление запросов на изменения;
    - защиту целостности конфигураций;
    - обновление Конфигурационной базы данных учетных элементов.
    После осуществления контроля качества ПО становится авторизированным для приемки и копирования в библиотеку эталонного ПО. ПО не должно быть испорчено или изменено во время процессов копирования и распространения. Соответствующая документация, сертификаты о тестировании и лицензии должны быть помещены в контролируемую библиотеку документов.
    Изменения в атрибутах учетных элементов в Конфигурационной базе данных учетных элементов должны обновляться вместе с соответствующими запросами на изменения.
    Необходимо проводить контроль удаления и устранения учетных элементов по финансовым причинам и для обеспечения безопасности. Необходимо наличие процедур для списания оборудования или ПО для обеспечения обновления соответствующих учетных записей. Процессы закупок, хранения, отправки, получения, выдачи товаров должны обеспечивать сохранность оборудования, ПО и документации.
    Управление конфигурациями должно обеспечивать целостность сохраненных учетных элементов типа ПО при помощи:
    - выбора носителя для хранения, для минимизации ошибок, связанных с восстановлением и возможным повреждением данных;
    - осуществления проверок и обновлений архивных учетных элементов;
    - сохранения дубликатов в контролируемых местах.
    Постоянное дублирование учетных элементов важно для обеспечения отсутствия посторонних элементов.
    5.4.1.4. Учет статусов конфигураций
    Отчеты по учету статуса состояния учетных элементов должен включать уникальные идентификаторы компонентов учетных элементов, текущий статус, конфигурационные базисы, релизы, версии ПО, ответственное лицо за изменение статуса, историю изменений, открытые проблемы.
    До перехода в среду эксплуатации новые релизы, сборки, оборудование и стандарты должны проходить верификацию по отношению к предъявленным требованиям. Для подтверждения верификации необходимо наличие сертификата о тестировании.
    5.4.1.5. Проведение проверок и аудита конфигураций
    Для проверки Конфигурационной базы данных учетных элементов на соответствие физическому состоянию всех учетных элементов необходимо наличие планов регулярных аудитов конфигураций. Аудиты должны подтверждать существование правильных и авторизированных версий учетных элементов. При выполнении аудитов конфигураций необходимо осуществление проверки того, что записи об изменениях и релизах авторизированны управлением изменениями.
    Аудит конфигураций должен осуществляться вследствие:
    - внедрения новой системы управления конфигурациями;
    - крупных изменений в ИТ-инфраструктуре;
    - релиза ПО;
    - восстановления, последовавшего за крупной аварией;
    - обнаружения неавторизированных учетных элементов.
    Средства автоматического аудита должны проводить регулярные проверки с определенным временным интервалом. Постоянно проводимый аудит конфигураций помогает в более эффективном использовании ресурсов.
    5.4.1.6. Составление управленческих отчетов
    Управленческие отчеты процесса управления конфигурациями должны включать:
    - результаты аудита конфигураций;
    - информацию об обнаруженных незарегистрированных или неверно зарегистрированных учетных элементах;
    - информацию о количестве зарегистрированных учетных элементов и их версий с разбивкой по категориям, типу и статусу;
    - информацию о скорости внесения изменений в Конфигурационную базу данных учетных элементов;
    - сведения обо всех задержках и причинах в работе процесса управления конфигурациями;
    - анализ эффективности, роста и аудита управления конфигурациями;
    - ценность и местоположение учетных элементов.
    На основе управленческих отчетов должно определяться будущее направление для развития управления конфигурациями, учитывая планируемую загрузку процесса управления конфигурациями и ожидаемый рост.
    5.4.2. Действия процесса управления конфигурациями
    В процессе управления конфигурациями должны выполняться следующие действия:
    1) предоставление персоналу процесса управления и поддержки публичных услуг правильной и точной информации о конфигурациях и их физических и функциональных спецификациях;
    2) определение и документирование процедур процесса управления конфигурациями;
    3) идентификация, маркировка, запись наименований и версий учетных элементов;
    4) контроль и хранение эталонных, авторизированных и проверенных копий спецификаций, документации и ПО;
    5) отслеживание и регистрация данных о конфигурациях в соответствии с действительным состоянием информационной инфраструктуры;
    6) отчетность по метрикам учетных элементов;
    7) аудит и отчетность о нарушениях стандартов инфраструктуры и процедур управления конфигурациями.
    При реализации действий процесса управления конфигурациями должны применяться физические и электронные библиотеки ПО, которые должны быть идентифицированы с помощью информации:
    - содержание, местоположение и носитель для каждой библиотеки;
    - условия поставки элемента на хранение;
    - меры по защите библиотеки и процедуры восстановления;
    - условия и контроль доступа для групп пользователей для регистрации, чтения, обновления, копирования, переноса или удаления учетных элементов.
    Средства поддержки позволяют осуществлять контроль прикладного ПО от начального системного анализа и проектирования до эксплуатации. Средства управления конфигурациями ИТ-инфраструктуры должны передавать информацию процесса управления конфигурациями из системы управления конфигурациями по разработке ПО в Конфигурационную базу данных учетных элементов без повторного ввода.
    Средства управления конфигурациями должны выполнять автоматическую поддержку следующих действий:
    - идентификации связанных учетных элементов;
    - внедрения изменений;
    - регистрации изменений статусов учетных элементов при внедрении авторизированных изменений и релизов;
    - записи конфигурационных базисов учетных элементов и пакетов учетных элементов.
    В процессе управления конфигурациями должны использоваться Интернет-технологии и различные
программные средства поддержки, такие как:
    - системы управления документооборотом;
    - средства построения архитектуры систем;
    - средства автоматической разработки систем;
    - средства управления аудитом баз данных;
    - средства распространения и инсталляции;
    - средства сравнения, внедрения релизов и сборки;
    - средства сжатия, управления списками и конфигурационными базисами;
    - средства обнаружения и восстановления.
    5.4.3. Показатели эффективности процесса управления конфигурациями
    Для предоставления точной информации об учетных элементах, контроля ценных учетных элементов, доступности информации о произведенных изменениях в ПО, участия в планировании действий при чрезвычайных ситуациях, улучшения безопасности посредством контроля за используемыми версиями учетных элементов, а также для предоставления возможности уменьшения использования несанкционированного ПО, следует использовать целевые показатели:
    - количество неавторизированных учетных элементов конфигурации;
    - инциденты и проблемы, как последствие неправильно сделанных изменений;
    - изменения среднего времени и затрат на диагностику и разрешение обращений в ЦЭП;
    - изменения количества и серьезности ситуаций нарушения Соглашения об уровне услуг;
    - не разрешенные успешно запросы на изменения;
    - время цикла между утверждением и внедрением изменений;
    - количество потерянных и неиспользованных лицензий ПО;
    - данные, полученные в результате проведения аудита конфигураций;
    - изменения количества и значимости инцидентов и проблем;
    - количество месячных изменений в Конфигурационной базе данных учетных элементов по причине обнаруженных ошибок.
    5.5. Процесс управления релизами
    Цели процесса управления релизами:
    - планирование и надзор за успешным развертыванием ПО и связанного с ним аппаратного обеспечения;
    - проектирование и внедрение процедур для распространения и инсталляции изменений;
    - обеспечение инсталляции только правильных, авторизованных и протестированных версий;
    - взаимосвязи с заказчиками и контроль ожиданий заказчика во время планирования и развертывания новых релизов;
    - согласование точного содержимого релиза и его плана развертывания;
    - внедрение новых релизов программного и аппаратного обеспечения в эксплуатационную среду с использованием процессов управления конфигурациями (см. 5.4) и управления изменениями (см. 5.3);
    - обеспечение безопасного хранения копий всего ПО;
    - обеспечение безопасности и отслеживаемости при развертывании или изменении аппаратного обеспечения.
    В процессе управления релизами необходимо концентрировать внимание на защите среды эксплуатации и ее услуг посредством процедур и проверок.
    Управление релизами должно финансироваться за счет бюджета и не включаться в затраты на предоставление услуг заказчикам.
    5.5.1. Основные требования, предъявляемые к процессу управления релизами
    В процессе управления релизами необходимо соблюдать требования по планированию, проектированию, сборке, конфигурированию и тестированию аппаратного и программного обеспечения.
    Основными требованиями, соблюдаемыми в процессе управления релизами, являются:
    - разработка политики и планирование релизов;
    - проектирование, сборка и конфигурирование релизов;
    - приемка релизов;
    - планирование развертывания релизов;
    - всестороннее тестирование релизов по установленным критериям приемки;
    - подтверждение завершения релиза для последующего внедрения;
    - оповещение, подготовка и обучение персонала;
    - проведение аудита аппаратного и программного обеспечения до и после внедрения изменений;
    - инсталляция нового и модернизированного аппаратного обеспечения;
    - хранение контролируемого ПО в централизованных и распределенных системах;
    - релиз, распространение и инсталляция ПО.
    5.5.1.1. Разработка политики и планирование релизов
    5.5.1.1.1. Составление политики релизов
    Политика релизов должна включать в себя правила нумерации релизов, их частоту и уровни в инфраструктуре, которые будут контролироваться этими релизами. Требуемое количество и частота релизов должны определяться в зависимости от размеров и типа систем. Каждый релиз должен иметь уникальный идентификатор, который будет использоваться в процессе управления конфигурациями, в соответствии со схемой, определенной в политике релизов. Идентификация релизов должна включать ссылку на компонент инфраструктуры (учетный элемент), который этот релиз представляет, и номер версии. При изменении инфраструктуры политика релизов должна пересматриваться и расширяться.
    Политика релизов должна четко объяснять роли и обязанности в процессе управления релизами.
    Политика релизов должна включать следующую информацию:
    - уровень контроля инфраструктуры для каждого определенного типа релиза;
    - правила именования и нумерации релизов;
    - определение комплексных и частичных релизов;
    - указания по частоте проведения комплексных и частичных релизов;
    - ожидаемые результаты для каждого типа релиза;
    - указания, как и где должны документироваться релизы;
    - создание и тестирование планов отката;
    - описание процесса контроля управления релизами;
    - документирование конфигурации библиотеки эталонного ПО и определение критериев приемки для добавления нового ПО.
    5.5.1.1.2. Планирование релизов
    Планирование релизов должно включать:
    - формирование общего согласия о содержании релиза;
    - согласование этапов по времени;
    - составление обобщенного графика релизов;
    - проведение опросов для оценки используемого программного и аппаратного обеспечения;
    - планирование уровней загрузки персонала;
    - согласование ролей и обязанностей;
    - предложения по закупке нового программного и аппаратного обеспечения;
    - составление планов отката;
    - разработка плана обеспечения качества релиза;
    - планирование приемки группами поддержки и заказчиком.
    5.5.1.2. Проектирование, сборка и конфигури-рование релизов
    Необходимо планировать и документировать процедуры для сборки релизов ПО. Инструкции по сборке релиза являются частью определения релиза.
    Действия по сборке должны включать компиляцию и связку модулей приложений, разработанных самостоятельно, и всего купленного ПО. Сборка должна содержать действия по созданию баз данных и наполнению их тестовыми данными или статистическими данными справочников.
    Все ПО, параметры, тестовые данные, ПО поддержки реализации программ, которое требуется для релиза, должны находиться под контролем управления конфигурациями. Полная запись о результатах сборки должна регистрироваться в Конфигурационной базе данных учетных элементов.
    Контроль сборки и релиза должен обеспечивать правильную сборку и распространение обновленных версий программного и аппаратного обеспечения.
    Процедуры сборки и автоматизация должны контролироваться как отдельные учетные элементы. Процедуры управления сборкой и распространения ПО должны быть протестированы до начала их использования. На первом этапе эксплуатации необходимо выделить время на разрешение проблем, связанных с введением новшеств.
    Процедуры, шаблоны, рекомендации должны быть спланированными для эффективного осуществления релизов программного и аппаратного обеспечения.
    5.5.1.3. Приемка релизов
    Тестирование должно включать процедуры инсталляции и функциональную целостность готовой системы. Необходимо проводить подтверждение завершения каждого этапа тестирования.
    Приемка релиза должна выполняться в контролируемой тестовой среде, которая может быть восстановлена по известной конфигурации программного и аппаратного обеспечения. Эти конфигурации должны описываться в определении релиза и храниться в Конфигурационной базе данных учетных элементов вместе со всеми другими учетными элементами.
    Если релиз отклонен, то он должен быть перепланирован на другое время управления изменениями, и должен отслеживаться в отчетах управления изменениями как неудачные изменения.
    Конечным результатом действий по проверке должно быть подтверждение полного и точного завершения всего релиза.
    5.5.1.4. Планирование развертывания релизов
    Планирование развертывания релизов должно расширить план релиза и включать следующую информацию:
    - подготовку точного и подробного расписания событий вместе с информацией, кто и какие задачи выполняет;
    - списки учетных элементов для инсталляции и списания;
    - формирование описания релиза и коммуникаций;
    - планирование коммуникаций с конечным пользователем;
    - разработку плана закупок;
    - приобретение программного и аппаратного обеспечения.
    В случае частичной или полной неудачи при развертывании релиза должен составляться план отката для документирования действий по восстановлению услуги. Возможны два подхода:
    - неудачное развертывание полностью возвращается в исходное состояние до полного восстановления услуг к их предыдущему известному состоянию;
    - принятие мер по более полному восстановлению предоставления услуг, если их нельзя восстановить полностью (возможен вариант дельта-релиза).
    План отката должен быть проверен в ходе оценки рисков в общем плане развертывания и признан достаточным заказчиком.
    5.5.1.5. Приемочное тестирование и подтверждение завершения релиза
    Перед развертыванием релиза в среду эксплуатации он должен пройти обязательное тестирование и приемку пользователем, которое делится на:
    - функциональное тестирование;
    - операционное тестирование;
    - эксплуатационное тестирование;
    - интеграционное тестирование.
    Перед развертыванием релиза пользователь должен подтвердить завершение релиза. Наиболее часто встречаемая причина неудачных изменений и релизов – недостаточное тестирование.
    5.5.1.6. Оповещение, подготовка и обучение персонала
    Персонал управления релизами должен пройти обучение по теории и практике управления изменениями и управления конфигурациями, по разработке и сопровождению ПО, по использованию средств поддержки и вспомогательных программ.
    Персонал, взаимодействующий с заказчиком, персонал заказчика и персонал ЦЭП должны знать о том, какие действия планируются и как эти действия могут повлиять на предоставление услуг. О возникших проблемах и изменениях необходимо сообщать всем заинтересованным сторонам, чтобы информировать их о происходящем и формировать их ожидания.
    5.5.1.7. Релиз, распространение и инсталляция ПО
    Распространение релизов ПО из среды сборки в среду эксплуатации должно проходить одновременно со всеми изменениями в аппаратном обеспечении. Распространение ПО должно быть спроектировано таким образом, чтобы поддерживалась целостность ПО во время обработки, упаковки и доставки. После распространения ПО и достижения релизом своего места назначения необходимо проверить полноту этого релиза.
    Конфигурационная база данных учетных элементов должна обновляться после инсталляции или устранения программного или аппаратного обеспечения, что обеспечит наличие в Конфигурационной базе данных учетных элементов обновленных данных.
    В процессе управления релизами должен осуществляться контроль следующих компонент:
    - программных приложений собственной разработки;
    - заказного ПО;
    - вспомогательного ПО;
    - системного ПО;
    - аппаратного обеспечения и его спецификаций;
    - инструкций по сборке и документации.
    Все вышеперечисленные компоненты должны эффективно управляться, начиная с их разработки или закупки и до настройки и конфигурирования, от тестирования и внедрения до работы в среде эксплуатации.
    5.5.2. Типы и классификация релизов
    5.5.2.1. Типы релизов
    Единица релиза описывает часть инфраструктуры ПО. Единица релиза зависит от типа или элемента программного и аппаратного обеспечения.
    Выбор уровня единицы релиза должен учитывать следующие факторы:
    - объем необходимых изменений;
    - объем ресурсов и время, требуемое на сборку, тестирование, распространение и внедрение релизов на каждом уровне;
    - простота внедрения;
    - сложность интерфейсов между предлагаемой единицей и остальной инфраструктурой;
    - доступное дисковое пространство в среде сборки, в тестовой среде, в среде распространения и в среде эксплуатации.
    Различают следующие типы релизов:
    - комплексный релиз – все компоненты единицы релиза собираются, тестируются, распространяются и внедряются вместе. В этом релизе исключается опасность использования устаревших версий учетных элементов. Недостатком такого подхода является увеличение объема, усилий и компьютерных ресурсов, которые задействованы при сборке, тестировании, распространении и внедрении релизов. Необходимо провести регрессионное тестирование для исключения ухудшения системных функций или поведения системы;
    - дельта-релиз (частичный) – включает только те учетные элементы в рамках единицы релиза, которые были изменены, или новые учетные элементы;
    - пакетный релиз – группировка отдельных релизов, уменьшающая вероятность использования старого или несовместимого ПО, что способствует полному тестированию совместной работы групп программ и систем.
    5.5.2.2. Классификация релизов
    Релиз должен использоваться для описания группы изменений в услуге. Релиз состоит из решений по устранению проблем и улучшений предоставляемых услуг. Релиз должен состоять из требуемого нового или измененного ПО и из нового или измененного аппаратного обеспечения, необходимых для внедрения утвержденных изменений.
    Релизы классифицируются следующим образом:
    - крупные релизы ПО и модернизация аппаратного обеспечения – большие объемы новых функций, которые приводят к замене ненужных действий по исправлению некоторых проблем;
    - небольшие релизы ПО и модернизация аппаратного обеспечения – небольшие улучшения и исправления;
    - срочные исправления программного и аппаратного обеспечения – исправления небольшого числа известных проблем.
    Зависимость между особой версией ПО и аппаратным обеспечением, необходимым для ее работы, приводит к объединению программного и аппаратного обеспечения в одном релизе с другими функциональными требованиями.
    По мере роста эффективности управления релизами увеличивается и эффективность работы персонала, занятого в предоставлении услуг.
    5.5.3. Специализированные средства системы управления релизами
    Управление релизами должно использовать:
    - средства управления изменениями – для записи информации о планируемых изменениях, для хранения информации о релизах и ссылках на изменения;
    - средства управления конфигурациями – для записи учетных элементов программного и аппаратного обеспечения в Конфигурационную базу данных учетных элементов;
    - средства управления конфигурациями ПО – для управления версиями программного кода во время разработки, которые могут обрабатывать пакеты изменений, для интеграции с информацией о проблеме и запросами на изменение;
    - средства процесса управления сборкой – для автоматической сборки новых релизов программных приложений, для генерации и запуска исполняемых версий файлов;
    - средства эталонного распространения ПО – для гарантированной доставки программных файлов, для оптимизации пропускной способности сети, для хранения новых версий приложений в состоянии ожидания;
    - средства проведения аудита программного и аппаратного обеспечения – для определения, какое ПО инсталлировано и для выявления наиболее критичных моментов в конфигурации аппаратного обеспечения;
    - средства управления рабочими станциями – для правильного конфигурирования параметров операционной системы и их контроля, для хранения всех инсталляционных файлов на сервере и обновления этих файлов по мере добавления в библиотеку эталонного ПО новых релизов;
    - средства управления серверами – для удаленного контроля операций на сервере, для удаленного мониторинга журнала регистрации событий, для мониторинга использования ресурсов процессора, памяти и дискового пространства.
    5.5.3.1. Конфигурационная база данных учетных элементов
    Конфигурационная база данных учетных элементов должна содержать следующую информацию для поддержки процесса управления релизами:
    - описание планируемых релизов, включая составляющие их учетные элементы аппаратного и программного обеспечения, вместе с ссылками на исходные запросы на изменение;
    - записи об учетных элементах, на которые воздействуют планируемые и прошлые релизы;
    - информацию и место целевого назначения компонентов релиза.
    5.5.3.2. Библиотека эталонного ПО
    Библиотека эталонного ПО – безопасное хранилище, в котором безопасно хранятся эталонные версии всех учетных элементов типа ПО, как ПО, разработанное в организации, так и закупленное. Это хранилище должно состоять из одной или нескольких библиотек ПО или хранилищ файлов, которые отделены от хранилищ файлов для разработки, тестирования или эксплуатации.
    Библиотека эталонного ПО является частью политики релизов и должна включать:
    - тип носителя, физическое местоположение, предполагаемое аппаратное и программное обеспечение;
    - договоренности по присвоению имен для файловых хранилищ и физических носителей;
    - поддерживаемые среды;
    - меры безопасности для оформления изменений и выпуска ПО;
    - период хранения старых релизов ПО;
    - план развития мощностей для библиотеки;
    - процедуры проведения аудита;
    - процедуры обеспечения защиты библиотеки от ошибочных изменений.
    Склад эталонного аппаратного обеспечения – место для безопасного хранения запасного эталонного аппаратного обеспечения (запасные компоненты и собранные модули).
    5.5.4. Показатели эффективности процесса управления релизами
    Для гарантии качества программного и аппаратного обеспечения, улучшения использования ресурсов, поддержки полных записей изменений в среде эксплуатации, контроля и защиты аппаратных и программных активов, проведения большого количества изменений в системах необходимо проанализировать следующие показатели:
    - соответствие сборки и внедрения релиза графику и рамкам бюджета;
    - процент отказов при сборке;
    - безопасность и четкое управление библиотеки эталонного ПО;
    - отсутствие в библиотеке эталонного ПО учетных элементов, не прошедших проверку качества;
    - соответствие дискового пространства потребностям библиотеки эталонного ПО;
    - соблюдение всех законодательных ограничений, связанных с купленным ПО;
    - точное распространение релизов;
    - своевременное внедрение релизов;
    - отсутствие фактов использования неавторизованных ПО;
    - точная и своевременная запись в Конфигурационную базу данных учетных элементов всех действий по сборке, распространению и внедрению;
    - соответствие планируемого состава релиза с действительным;
    - доля успешных релизов;
    - согласованность процессов, связанных с релизами аппаратных платформ или программных сред;
    - минимальное количество прерываний в предоставлении услуг;
    - стабильность тестовой среды и среды эксплуатации;
    - количество ошибок, попадающих в среду эксплуатации;
    - вероятности появления и использования нелегальных копий ПО;
    - использование ИТ и человеческих ресурсов;
    - количество релизов, развертываемых для заказчиков;
    - время обнаружения неверных версий и копий ПО;
    - период выпуска релизов;
    - период сборки и контроля ПО.

6. ИТ-инфраструктура предоставления публичных услуг

    ИТ-инфраструктура предоставления публичных услуг представляет собой систему организационных структур и технических средств, обеспечивающих формирование, распространение и использование информационно-коммуникационных технологий, позволяющих обеспечить взаимодействие органов публичного управления, предоставляя доступ к информационным ресурсам.
    Основными составляющими компонентами ИТ-инфраструктуры являются:
    - аппаратные средства - представляют собой комплекс электронных, электрических и механических устройств, входящих в состав информационных систем и сетей органов публичного управления;
    - операционные системы - обеспечивают выполнение программ и приложений, распределение ресурсов, планирование, ввод-вывод и управление данными, а также определяют взаимосвязанную группу протоколов верхних уровней для выполнения основных функций сети;
    - базы данных - представляют собой совокупность связанных данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и обработки данных;
    - телекоммуникационная сеть - представляет собой совокупность базовых компонентов обработки информации и телекоммуникаций, обеспечивающих обмен данными на основе комплекса взаимосвязанных программно-технических средств;
    - средства поддержки - обеспечивают поддержку функционирования всех информационных систем и сетей (например, средства управления производительностью серверов, средства управления хранением данных);
    - мультимедийные средства - обеспечивают вызов телевизионного сигнала на монитор, композитный видеовыход, развертку живого видео на мониторе, цифровую фильтрацию и масштабирование видео, аппаратно-цифровую компрессию и декомпрессию видео, а также ускорение графических операций, связанных с трехмерной графикой.
    Каждая компонента ИТ-инфраструктуры должна использоваться для автоматизации управления выполняемых действий, связанных с каждой задачей в жизненном цикле публичных услуг – от планирования новой услуги до ее изъятия из использования.
    Сложность компонентов ИТ-инфраструктуры должна зависеть от номенклатуры предоставляемых публичных услуг, а также от уровня взаимодействия органов публичного управления и от выполняемых ими функций.
    6.1. Требования к компонентам ИТ-инфраструктуры
    Для достижения высокого качества предоставляемых публичных услуг необходимо обеспечить надлежащее функционирование, оптимизацию, использование и безопасность всех компонент ИТ-инфраструктуры, посредством выполнения всех процессов управления предоставлением публичных услуг.
    Требования к компонентам ИТ-инфраструктуры на этапах жизненного цикла должны включать следующее:
- планирование и разработка новой компоненты:
    1) необходимо проверить совместимость и возможность интеграции новой компоненты с существующими компонентами инфраструктуры, рассматривая процессы управления и архитектуру каждой компоненты;
    2) необходимо оценить выгоды от внедрения, требования и потребности новой компоненты, стабильность функционирования новой компоненты и ожидаемую продолжительность ее жизненного цикла, а также анализ и управление рисками, связанными с внедрением новой компоненты;
    3) необходимо определить вид разработки новой компоненты: функциональная разработка (формирование набора функциональных спецификаций требований и критериев к компоненте) или техническая разработка (определение технических параметров новой компоненты в текущей инфраструктуре);
- внедрение компонент:
    1) необходимо создать, поддерживать и управлять планом развертывания компонент, содержащим период времени и требуемые ресурсы для внедрения каждой компоненты инфраструктуры;
    2) требуется выбрать команду специалистов, обладающих необходимой квалификацией и навыками для выполнения внедрения;
    3) необходимо оценить риски, которые могут возникнуть при внедрении компонент, уровень соответствия функциональных и технических характеристик компоненты поставленным требованиям, стабильность и адекватность всей ИТ-инфраструктуры с новой компонентой;
    4) необходимо применять различные уровни интеграции: интеграция событий (способность обмениваться информацией между компонентами), интеграция данных (способность распространять общий набор данных разным компонентам) и функциональная интеграция (способность компонент взаимодействовать и согласовывать их функциональное поведение друг с другом);
    5) требуется обеспечить наличие и доступность документации по внедрению для последующей поддержки и технического обслуживания компонент инфраструктуры;
- обслуживание компонент:
    1) обслуживание должно быть непрерывным процессом;
    2) все задачи по обслуживанию должны быть согласованы и подтверждены ответственными лицами организации;
    3) обслуживание должно включать мониторинг и контроль событий, связанных со всеми компонентами ИТ-инфраструктуры;
    4) результаты обслуживания компонент должны включать стабильность и надежность компонент, документацию, содержащую данные по обслуживанию компонент, а также регистр или базу данных всех событий обслуживания, тревог и сигналов.
    На всех этапах жизненного цикла компонент ИТ-инфраструктуры необходимо выполнять требования безопасности к компонентам инфраструктуры и к средствам обеспечения безопасности.
    6.2. Критерии выбора компонент ИТ-инфраструктуры
    При выборе компонент ИТ-инфраструктуры для предоставления публичных услуг необходимо учитывать следующие факторы:
    - усложняющиеся требования пользователей;
    - нехватка навыков по вопросам ИТ;
    - ограничения бюджета;
    - зависимость организации от качественных публичных услуг;
    - увеличивающаяся сложность инфраструктуры;
    - появление изменений в международных стандартах, законодательстве;
    - увеличивающийся масштаб и частота изменений в предоставлении публичных услуг.
    При планировании закупок компонент ИТ-инфраструктуры необходимо использовать следующие критерии их оценки:
    - 80-процентное совпадение с эксплуатационными требованиями;
    - соответствие всем обязательным требованиям;
    - незначительная необходимость или отсутствие необходимости доработок;
    - продуманная структура данных и их обработки;
    - ориентированность на конкретные требования предоставления публичных услуг, а не на технологии;
    - гибкость при внедрении, использовании;
    - удобство в использовании, общая легкость в использовании, предоставляемая пользовательским интерфейсом;
    - интеграция и противоречивость с текущими компонентами инфраструктуры различных поставщиков;
    - обеспечение непрерывности, резервирования, контроля и безопасности;
    - зависимость от поставщиков, партнеров;
    - соотношение цены и качества компонентов;
    - затраты на администрирование и поддержку находятся в рамках бюджета.
    При выборе компонент ИТ-инфраструктуры для системы предоставления публичных услуг необходимо принять решение, использовать ли современные уже внедренные компоненты либо разрабатывать новые с нуля. В случае принятия решения о разработке новой компоненты, следует определить, будет ли разработка вестись собственным персоналом или аутсорсерами.
    При принятии решения об использовании аутсорсинга при разработке компонент ИТ-инфраструктуры необходимо учесть следующие факторы:
    - стоимость собственных разработок в соотношении со стоимостью услуг аутсорсинга;
    - риски нарушения режима информационной безопасности;
    - риски разрыва отношений с аутсорсинговой организацией и дальнейшее развитие созданного приложения.

7. Мониторинг процесса
предоставления публичных услуг

    7.1. Мониторинг и оценка процесса предоставления публичных услуг
    Организация, предоставляющая публичные услуги, должна осуществлять последовательный мониторинг производительности для оценки результатов и производительности процессов оказания услуг.
    Мониторинг и оценка услуг – процесс получения персоналом актуальных сведений о состоянии предоставляемых услуг: состояние процессов, загрузка серверов, время отклика приложений.
    Различают следующие виды мониторинга и оценки предоставления услуг:
    - внутренний мониторинг и внутренняя оценка - планируются и реализуются силами организации, оказывающей публичные услуги;
    - внешний мониторинг и внешняя оценка - осуществляются независимой структурой, которая специально приглашается для их проведения.
    Мониторинг должен включать комплекс динамических наблюдений, аналитической оценки и прогноза состояния целостности информационной системы предоставления услуг.
    7.1.1. Цели и задачи мониторинга и оценки предоставления публичных услуг
    Целями и задачами процесса мониторинга и оценки предоставления услуг являются:
    - проведение мониторинга процессов предоставления услуг;
    - процесс отслеживания и оценки производительности предоставления услуг - должен отражаться в журналах, контрольных записях и отчетах;
    - оценка адекватности внутреннего контроля;
    - автоматизация непрерывной оценки эффективности внутреннего контроля;
    - получение независимых гарантий качества оказанных услуг;
    - обеспечение соответствия нормативным документам;
    - актуализация Конфигурационной базы данных учетных элементов в процессе автоматического сканирования элементов инфраструктуры, позволяющая проведение непрерывной оценки рисков и их ослабление;
    - обеспечение независимого аудита.
    Основные функции системы мониторинга и оценки:
    - информационная – предоставление сведений о ходе процесса предоставления услуг;
    - аналитическая – анализ процесса предоставления услуг для предоставления управленческой информации и принятия решений;
    - прогностическая – определение тенденций и прогнозов для планирования процесса управления уровнем услуг;
    - диагностическая - определение факторов, обеспечивающих стабильность и надежность предоставления услуг;
    - ориентирующая - установление сильных и слабых сторон процесса предоставления услуг;
    - профилактическая – проведение аудита с целью минимизации отрицательного воздействия на предоставление услуг.
    7.1.2. Компоненты процесса мониторинга
    Процесс мониторинга должен включать индикаторы работы, систематическую и своевременную отчетность, включающую параметры эффективности предоставления услуг, и незамедлительные действия по реагированию на запросы.
    Процесс мониторинга должен включать следующие компоненты:
    - подход к мониторингу - устанавливает общую структуру и подход к мониторингу, определяющий возможности, методологию и процесс, который сопровождается оценкой процесса предоставления услуг;
    - определение и сбор контрольных данных - определение набора целей, их сравнение, идентификация доступных данных для измерения цели;
    - определение метода мониторинга – используются различные контролирующие методы, которые учитывают цели и масштабы охвата процесса предоставления услуг;
    - оценка работ, выполненных в процессе оказания услуг - периодический пересмотр выполняемых работ, анализ причин отклонений от поставленных целей, корректирующие действия по устранению основных причин, а также выполнение перекрестного анализа первопричин отклонений;
    - управление ресурсами – контроль использования и распределения ресурсов в процессе оказания услуг, посредством регулярной оценки операций, осуществляющих распределение ресурсов, и выравнивание текущих и будущих стратегических целей;
    - управления рисками - регулярная оценка рисков и связанных с ними воздействий;
    - управленческая отчетность - указывается степень достижения запланированных целей, планируемые и используемые ресурсы, набор встречных целей и определение работ по минимизации рисков;
    - корректирующие действия - выполнение корректирующих действий, основанных на контроле и оценке процесса предоставления услуг. Контроль осуществляется посредством прослеживания результатов переданных действий, обзоров данного процесса, назначение ответственных за исправление;
    - проведение внутреннего или внешнего аудита для определения соответствия уровня оказываемых услуг стандартам и процедурам, общепринятым методам, законодательству.
    Процесс мониторинга должен осуществлять постоянное слежение за показателями эффективности предоставления услуг.
    7.2. Процессы управления и аудита предоставления публичных услуг
    Процессы управления и аудита предоставления услуг предназначены для контроля над процессами оказания услуг в организации. Целью данных процессов является создание эффективного инструмента для классификации и оценки проектов, связанных с оказанием услуг, и гарантированного соблюдения качества при выполнении заказов по предоставлению услуг.
    7.2.1. Анализ модели зрелости процессов управления ИТ
    Анализ модели зрелости процессов управления ИТ предназначен для определения статуса и состояния процесса управления ИТ, а также для организации эффективного управления ИТ и ИС. Уровень модели зрелости процессов управления ИТ определяет способы контроля над правильностью выполнения ключевых процессов и методы их корректировки.
    В зависимости от уровня развития и зрелости процессов управления ИТ должна быть определена стратегия и тактика операционного развития функций и компонентов ИТ-инфраструктуры.
    Шкала моделей зрелости должна включать следующие уровни:
    - нулевой – «Не существует» - отсутствие каких-либо процессов управления в предоставлении публичных услуг, а также отсутствие сведений о проблемах;
    - первый – «Базовый» - не существует четкой схемы и порядка осуществления процессов управления ИТ, существование проблем в управлении предоставлением публичных услуг и осознана необходимость их решения;
    - второй – «Повторяющийся» - процессы управления ИТ осуществляются в определенной зависимости и последовательности; существующие проблемы в управлении предоставлением публичных услуг рассматриваются с целью их минимизации;
    - третий – «Формализованный» - Порядок осуществления процессов управления ИТ задокументирован и доведен до сведения; существует четко отслеживаемая связь между результатом и показателями производительности процессов оказания публичных услуг; внедрены процессы планирования и мониторинга. Показатели производительности фиксируются и отслеживаются для повышения эффективности работы всей организации;
    - четвертый – «Управляемый» - все процессы управления ИТ подвержены мониторингу; отклонения отслеживаются и исправляются; существует полное понимание проблем управления в оказании публичных услуг на всех уровнях организации; происходит постоянное обучение персонала. Определение и поддержание в актуальном состоянии Соглашения об уровне услуг, распределение ответственности, установление уровня владения процессами являются общепринятыми практиками;
    - пятый – «Оптимизирующий процессы управления ИТ» - лучшие практики управления ИТ осуществляются в соответствии со стандартами и на основе современных ИТ; существует углубленное понимание управления в оказании публичных услуг на всех уровнях организации. Обучение и коммуникация поддерживаются самыми современными информационно- коммуникационными средствами.
    В управлении предоставлением услуг должны использоваться следующие концепции:
    - критические факторы успеха;
    - ключевые индикаторы цели;
    - ключевые индикаторы результата.
    7.2.2. Критические факторы успеха
    Критические факторы успеха определяют наиболее важные условия, ресурсы и действия, которые необходимы для достижения целей и задач ИТ-процессов. Данные факторы должны быть управляемыми, ориентированными на успех и описывать выполнение необходимых стратегических, технических, организационных или процедурных действий.
    Критическими факторами успеха являются:
    - управление процессом предоставления услуг способствует достижению целей организации: стратегических, тактических, использование технологий для развития процессов предоставления услуг, достаточность ресурсов и удовлетворение требований;
    - определение, формализация и осуществление действий по управлению процессом предоставления услуг на основе требований организации заказчика;
    - разработка методов управления для увеличения продуктивности, оптимального использования ресурсов и увеличения эффективности процессов;
    - управление рисками и изучение их недостатков;
    - определение степени соответствия установленным стандартам и действующему законодательству;
    - проведение аудита во избежание сбоев и ошибок в системе внутреннего контроля;
    - стандартизация ИТ-процессов и их нацеленность на достижение требований процессов предоставления публичных услуг;
    - определение групп пользователей ИТ-процессов и их требований;
    - обеспечение масштабируемости ИТ-процессов и оптимального управления ресурсами в рамках этих процессов;
    - наличие процедур контроля и повышение качества ИТ-процессов.
7.2.3. Ключевые индикаторы цели
    Ключевые индикаторы цели описывают комплекс измерений, сообщающих руководству о достижении предъявляемых требований.
    Для ключевых индикаторов цели должны выделяться следующие информационные критерии:
    - пригодность информации, необходимой для поддержки процесса предоставления услуг;
    - риски отсутствия целостности и конфиденциальности;
    - рентабельность процессов и операций;
    - подтверждение надежности, эффективности и согласованности процесса предоставления услуг.
    Должны выделяться основные индикаторы цели:
    - улучшение управления производительностью и стоимостью предоставления услуг;
    - сокращение времени запуска в продажу новой услуги;
    - улучшение управления качеством услуг;
    - улучшение управления новшествами и рисками;
    - интеграция и стандартизация процессов предоставления публичных услуг;
    - выполнение требований и ожиданий заказчика согласно Соглашению об уровне услуг;
    - соответствие уровня предоставляемых услуг действующему законодательству, инструкциям, стандартам и договорным обязательствам.
    7.2.4. Ключевые индикаторы эффективности предоставления публичных услуг
    Ключевые индикаторы эффективности предоставления публичных услуг описывают комплекс действий, необходимых для определения степени достижения поставленных целей, отражения адекватности способов, методов и навыков, используемых при предоставлении публичных услуг.
    Ключевыми индикаторами эффективности являются:
    - увеличение рентабельности ИТ-процессов;
    - улучшение работы и планирования действий по совершенствованию процессов предоставления услуг;
    - увеличение нагрузки на ИТ-инфраструктуру;
    - повышение степени удовлетворения пользователей;
    - повышение производительности сотрудников.
    Оптимально функционирующий процесс управления и аудита предоставления услуг должен обеспечивать и создавать следующие преимущества:
    - повышение уровней управления и безопасности процесса предоставления услуг;
    - контроль процессов предоставления услуг;
    - контроль достижения целей по обеспечению качества предоставляемых услуг;
    - контроль результатов каждого ИТ-процесса;
    - отслеживание и совершенствование процесса предоставления услуг;
    - оптимальное использование ресурсов.
    7.2.5. Проведение пост-имплементационного аудита
    Проведение пост-имплементационного аудита системы предоставления публичных услуг необходимо для оперативного получения систематизированной и достоверной информации для оценки качества, возможностей предоставляемых публичных услуг и их соответствия требованиям, представленным в разделах 4 и 5.
    Проведение пост-имплементационного аудита системы предоставления публичных услуг должно осуществляться внешними аудиторами, посредством следующих видов аудита:
    - обследование системы - сбор информации для ее использования в проведении последующих работ;
    - экспертная оценка системы - оценка адекватности финансирования проектных решений и/или инвестиций в систему предоставления публичных услуг, оценка эксплуатации системы и подготовки пользователей, оценка возможности перепрофилирования ИТ-инфраструктуры;
    - операционный ИТ аудит системы - сбор, анализ информации и выдача рекомендаций по улучшению работы как отдельных учетных элементов, так и всей ИТ-инфраструктуры;
    - аудит процессов - аудит ИТ и ИС, критичных для процесса предоставления публичных услуг с заданными критериями качества и эффективности;
    - аудит критерия процесса предоставления услуг - сбор, анализ информации и выдача рекомендаций по выбранному критерию процесса оказания услуг, например, безопасности, производительности, надежности, доступности. При проведении аудита по определенному критерию оценки исследуется не только отдельный элемент ИТ-инфраструктуры, но и вся совокупность программных, аппаратных средств, процессов их сопровождения и обслуживания;
    - комплексный аудит системы - осуществляется определение и анализ взаимосвязей процессов предоставления публичных услуг, их требований, информационных и смежных технологий, совокупности программно-аппаратных средств.
    Результатами проведения пост-имплементационного аудита системы предоставления публичных услуг являются:
    - определение соответствия функциональных возможностей системы предоставления услуг потребностям участников взаимодействия по каждой конкретной публичной услуге;
    - подтверждение адекватной формализации правил и требований по организации взаимодействия участников по каждой публичной услуге, описание основных процессов предоставления услуг и построение карты информационных потоков;
    - подтверждение наличия соответствующей технической документации, описывающей технические характеристики, ИТ-инфраструктуру и архитектурные особенности построения ИС предоставления публичных услуг;
    - определение целесообразности дальнейшего использования, развития или замены ИС предоставления публичных услуг;
    - идентификация списка выявленных рисков, связанных с использованием системы предоставления публичных услуг;
    - разработка конкретных рекомендаций, направленных на повышение качества предоставления услуг и оптимизацию процесса предоставления услуг;
    - предложение направлений снижения затрат на поддержку и развитие системы предоставления публичных услуг;
    - предложение направлений снижения рисков от возникновения внештатных ситуаций при оказании услуг;
    - выявление недостатков и упущений в системе предоставления услуг;
    - разработка предложений по повышению квалификации сотрудников, участвующих в предоставлении услуг, приобретению или модернизации программно-аппаратных средств;
    - получение рекомендаций по обеспечению бесперебойности функционирования ИС предоставления публичных услуг.
    7.3. Управление эффективностью предоставления публичных услуг
    Оптимальное управление процессом предоставления публичных услуг способствует максимально эффективному использованию информации.
    Процесс предоставления услуг должен соответствовать организационным требованиям в разрезе конфиденциальности, целостности, доступности, эффективности, экономичности и надежности.
    7.3.1. Ресурсы процесса предоставления публичных услуг
    Для обеспечения надежного и эффективного функционирования системы предоставления публичных услуг необходимо использовать следующие ресурсы:
    - человеческие ресурсы - сотрудники с навыками и опытом, необходимыми для планирования, организации, комплектования, сопровождения, поддержки и мониторинга системы оказания публичных услуг;
    - приложения – все прикладное ПО, используемое при работе с системой предоставления публичных услуг;
    - технологии – операционные системы, базы данных, системы управления и т.д., позволяющие выполнять процесс предоставления публичных услуг;
    - оборудование – все аппаратные средства ИС с учетом их обслуживания;
    - данные – внешние и внутренние, структурированные и неструктурированные, графические, звуковые и мультимедиа данные.
    7.3.2. Требования, предъявляемые при предоставлении публичных услуг
    В процессе предоставления публичных услуг должны соблюдаться следующие требования:
    - требования к качеству и надежности обслуживания;
    - бесперебойность предоставления услуг - подготовка и планирование способов устранения чрезвычайных ситуаций;
    - требования доверия - эффективность и производительность операций; надежность информации; соответствие нормативным документам;
    - требования безопасности - конфиденциальность; целостность; доступность, неотказуемость;
    - информирование о процессе предоставления услуг, предоставление соответствующей документации;
    - продуктивность процесса предоставления услуг - предоставление информации путем оптимального использования ресурсов;
    - конфиденциальность - защищенность информации от несанкционированного раскрытия;
    - доступность - возможность получения необходимой информации в течение определенного времени, защита информации и ее носителей от похищения или уничтожения;
    - требования к основным эксплуатационным ресурсам;
    - эксплуатационно-технические требования к рабочим местам;
    - эксплуатационно-технические требования для организации информационно-справочных и сервисных служб;
    - требования к техническому обслуживанию;
    - требования к информации - достоверность, полнота, наглядность, оперативность предоставляемой информации, а также удобство и доступность ее получения.
    7.3.3. Критерии эффективности процесса предо-ставления публичных услуг
    Критерии эффективности процесса предоставления публичных услуг основываются на оценке информационных ресурсов и всех компонентов ИТ-инфраструктуры.
    В ходе предоставления публичных услуг должны быть оценены показатели, способствующие реализации управляемого и измеряемого процесса предоставления публичных услуг, и описывающие следующее:
    - соответствие процесса предоставления публичных услуг принятым стандартам и требованиям;
    - достоверность обрабатываемой информации и ее действенность;
    - информационная безопасность - конфиденциальность, целостность, доступность, неотказуемость;
    - качество и стоимость обработки информации, а также характеристики ее доставки получателю.
    Критериями эффективности процесса предоставления публичных услуг, основанными на оценке применяемых ресурсов и компонентов ИТ-инфраструктуры, должны быть:
    - эффективность - актуальность, уместность и соответствие информации задачам организации, а также своевременность ее предоставления, корректность, непротиворечивость и практичность;
    - соответствие - соответствие положениям законов, стандартов, инструкций, распоряжений и соглашений, регулирующих организацию процесса предоставления публичных услуг;
    - конфиденциальность - защищенность информации от несанкционированного раскрытия;
    - целостность - точность, законченность и полнота информации, а также ее обоснованность с точки зрения ценностей и ожиданий организации;
    - доступность – текущий и будущий требуемый уровень доступности информации для выполнения процессов в организации, возможность получения необходимой информации в течение времени, определяемого требованиями внутренних процессов в организации;
    - производительность - предоставление информации путем наиболее оптимального (продуктивного и экономичного) использования ресурсов и компонентов ИТ-инфраструктуры, исполнения требований законов, инструкций и договоренностей, влияющих на осуществление процессов в организации.

Приложение № 3
к Приказу № 94
от 17.09.2009 г.

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

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

2. Нормативно-правовая база

    Настоящий документ разработан на основе следующих законодательных актов Республики Молдова:
    - Закон Республики Молдова «О доступе к информации» № 982-XIV от 11.05.2000;
    - Закон Республики Молдова «Об оценке соответствия продукции» № 186-XV от 24.04.2003;
    - Закон Республики Молдова «Об информатизации и государственных информационных ресурсах» № 467-XV от 21.11.2003;
    - Закон Республики Молдова «Об электронном документе и цифровой подписи» № 264-XV от 15.07.2004;
    - Закон Республики Молдова «Об электронной торговле» № 284-XV от 22.07.2004;
    - Закон Республики Молдова «О техническом регулировании» № 420–XVI от 22.12.2006;
    - Закон Республики Молдова «О защите персональных данных» № 17-XVI от 15.02.2007;
    - Закон Республики Молдова «О государственной тайне» № 245-XVI от 27.11.2008;
    - Закон Республики Молдова «О регистрах» № 71-XVI от 22.03.2007.

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

    В настоящем регламенте применяются следующие термины:
    Санкционированный доступ к информации – доступ к информации, не нарушающий правила разграничения доступа.
    Несанкционированный доступ – получение защищаемой информации заинтересованным субъектом с нарушением установленных правовыми документами или владельцем информации прав или правил доступа к защищаемой информации.
    Соглашение об уровне услуг – письменное соглашение между поставщиком услуг и заказчиком (заказчиками), которое описывает согласованные уровни обслуживания по какой-либо услуге.
    Алгоритм – точное предписание совершения определенной последовательности действий для достижения поставленной цели за конечное число шагов.
    Алгоритмы асимметричного шифрования – алгоритмы шифрования, в которых для шифрования и дешифрования используются два разных ключа, называемые открытым и закрытым ключами, причем, зная один из ключей, вычислить другой невозможно.
    Алгоритмы симметричного шифрования – алгоритмы шифрования, в которых для шифрования и дешифрования используется один и тот же ключ или ключ дешифрования легко может быть получен из ключа шифрования.
    Криптографический алгоритм – алгоритм преобразования данных, являющийся полностью или частично секретным и использующий при работе набор секретных параметров.
    Архитектура информационной системы — это набор ключевых решений по организации информационной системы, а также набор структурных элементов и интерфейсов, из которых она состоит, вместе с поведением, описываемым в терминах коопераций этих элементов.
    Аттестация – форма оценки соответствия процесса эксплуатации информационной системы требованиям безопасности.
    Аутентичность - свойство данных быть подлинными, что означает, что данные были созданы законными участниками информационного процесса, и данные не подвергались случайным или преднамеренным искажениям.
    Требования безопасности – требования, предъявляемые к информационным технологиям, реализация которых обеспечивает конфиденциальность, целостность и доступность информации.
    Криптографический ключ – параметр, используемый криптографическим алгоритмом.
    Шифрование – процесс преобразования открытых данных в зашифрованные данные при помощи шифра.
    Конфиденциальность – обеспечение доступа к информации только авторизованным пользователям.
    Конфигурация – совокупность объектов информационной системы.
    Дешифрование – процесс преобразования зашифрованных данных в открытые данные при помощи шифра.
    Доступность – обеспечение доступа к информации и связанным с ней активам авторизованных пользователей по мере необходимости.
    Экранирование – средство разграничения доступа клиентов из одного множества к серверам из другого множества для контроля информационных потоков.
    Оценка рисков – оценка угроз, их последствий, уязвимости информации и средств ее обработки, а также вероятности их возникновения.
    Дискретное (избирательное) управление доступом - разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.
    Аппаратное обеспечение - оборудование, используемое для ввода, обработки и вывода данных в информационных системах.
    Инцидент – одно или серия нежелательных или неожиданных событий в системе защиты информации, которые имеют большой шанс скомпрометировать стандартные операции и поставить под угрозу защиту информации.
    Инфраструктура, основанная на открытых ключах – совокупность программно-аппаратных средств, политик, процедур и законных обязательств, которые обеспечивают внедрение и функционирование криптографических систем открытых ключей, основанных на сертификатах для обеспечения безопасности сообщений (конфиденциальность, целостность, аутентичность, неотказуемость) с обеих сторон.
    ИТ инфраструктура - совокупность информационно-вычислительных центров, банков данных и знаний интегрированной автоматизированной системы связи и организации, которая обеспечивает пользователям общие условия доступа к хранящейся информации.
    Целостность – обеспечение достоверности и полноты информации и методов ее обработки.
    Мандатное управление доступом основано на сопоставлении меток конфиденциальности информации, содержащейся в объектах (файлы, папки, рисунки) и официального разрешения (допуска) субъекта к информации соответствующего уровня конфиденциальности.
    Среда функционирования - среда, в которой функционирует информационная система.
    Метка чувствительности - определенные маркировки информационных ресурсов и систем, например, степень секретности, категории.
    Средства обеспечения безопасности - аппаратные, программно-аппаратные и программные средства, реализующие совокупность функций, обеспечивающих выполнение требований по защите информации и по контролю эффективности защиты информации.
    Средство управления конфигурациями – программный продукт, обеспечивающий автоматизацию поддержки изменений, конфигураций и контроля версий.
    Средство криптографической защиты информации – аппаратные, программные и аппаратно-программные средства, системы и комплексы, реализующие алгоритмы криптографического преобразования информации, используемые для защиты целостности и конфиденциальности информации.
    Криптографический модуль – совокупность аппаратного, программного обеспечения или некоторая их комбинация, которая реализует криптографическую логику или процессы защиты, включая криптографические алгоритмы или генерацию ключей, и содержится внутри некоторого физического объема.
    Мониторинг – процесс сбора, анализа данных, представления отчетов по выполнению работ.
    Неотказуемость - невозможность отказаться от совершенных действий.
    Аутентификационный пакет - механизм подтверждения подлинности заявляемого идентификатора пользователя.
    Гриф секретности – отметка, проставляемая на материальном носителе сведений, отнесенных к государственной тайне, и/или указанная в сопроводительной документации к ним, подтверждающая степень секретности сведений, содержащихся в их носителе.
    Угроза – совокупность потенциально возможных событий и действий, реализация которых приносит ущерб информационным ресурсам или информационной инфраструктуре.
    Предоставление публичных услуг – набор взаимосвязанных процессов, направленных на достижение целей – взаимодействие между субъектами электронного правления, осуществляющегося по двум четким контурам - внутреннему и внешнему, сообщающимся между собой через правительственный портал.
    Политика управления доступом - правила предоставления доступа к компьютерным системам и сети отдельным пользователям.
    Политика информационной безопасности – набор правил или процедур, предписанных организацией для защиты чувствительных данных.
    Профиль защиты - жестко структурированный документ, содержащий требования безопасности для определенного класса программно-технических средств.
    Владелец информационных ресурсов, информационных систем, технологий и средств их обеспечения - субъект, осуществляющий владение и пользование указанными объектами и реализующий полномочия распоряжения в пределах, установленных действующим законодательством.
    Защита информации - совокупность организационно-технических мероприятий, программно-аппаратных средств и нормативных актов, используемых для сохранения конфиденциальности, целостности и доступности информации, а также для обеспечения неотказуемости.
    Криптографическая защита – защита информационных процессов от целенаправленных попыток отклонить их от нормальных условий протекания.
    Риск – внутреннее или внешнее воздействие на систему, которое может неблагоприятно повлиять на область проекта или привести к его провалу.
    Актив – совокупность материальных благ, принадлежащих одному предприятию или организации (информационные, технические, программные и другие ресурсы, входящие в состав информационных систем).
    Безопасность информационных систем – состояние информационных систем, обеспечивающее их применение на объектах эксплуатации, при котором отсутствует недопустимый риск, связанный с причинением ущерба личности, обществу и государству.
    Публичная услуга – услуга, которая обуславливает три типа взаимодействия составляющих электронного правления: взаимодействие “Правительство - Гражданин” (G2C); взаимодействие “Правительство - Бизнес” (G2B); взаимодействие “Правительство - Правительство” (G2G) с подкатегорией “Взаимодействие Правительства и его сотрудников” (G2E).
    Информационная система - совокупность программных и аппаратных средств, предназначенных для сбора, обработки, хранения и распространения информации, информационных ресурсов с целью поддержки принятия решений, управления, анализа и увеличения наглядности в организации.
    Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
    Туннеллирование – применение специального протокола, с помощью которого два удаленных офиса организовывают между собой безопасный туннель (сеанс связи), в результате чего данные передаются между сетями.
    Уязвимость – слабое место в системе, используя которое, возможно вызвать ее неправильную работу.

4. Цели, задачи и принципы управления безопасностью
при предоставлении публичных услуг

    Обеспечение информационной безопасности - это непрерывный процесс, заключающийся в обосновании и реализации наиболее рациональных форм, методов, способов и путей создания, совершенствования и развития системы безопасности, непрерывном управлении, контроле, выявлении узких и слабых мест и потенциально возможных угроз.
    Информационная безопасность представляет собой состояние защищенности информации и поддерживающей инфраструктуры на всех этапах процессов создания, обработки, передачи и хранения от случайных или преднамеренных воздействий естественного или искусственного характера, чреватых нанесением ущерба процессу предоставления публичных услуг.
    Информационная безопасность должна быть обеспечена посредством комплексного использования всех средств защиты во всех структурных элементах системы и компонентах ИТ-инфраструктуры и на всех этапах технологического цикла ее деятельности. Для достижения наибольшего уровня эффективности управления информационной безопасностью необходимо использовать все средства, методы и мероприятия как единый целостный механизм.
    Система информационной безопасности представляет собой организованную совокупность законодательных, организационных и экономических мер, средств, методов и мероприятий, обеспечивающих информационную безопасность.
    Целью системы информационной безопасности при предоставлении публичных услуг является предотвращение разглашения, утраты, утечки, искажения и уничтожения информации, нарушения работы системы предоставления публичных услуг.
    Предметом защиты при предоставлении публичных услуг являются информационные ресурсы и ИС, в том числе и с ограниченным доступом, составляющие служебную и государственную тайну на магнитной и/или оптической основе, информационные массивы и базы данных, программное обеспечение, информативные физические поля различного характера.
    Объектом защиты предоставления публичных услуг являются средства и системы информатизации (автоматизированные системы и вычислительные сети различного уровня и назначения, телекоммуникационные линии связи, технические средства передачи информации, средства размножения и отображения информации, вспомогательные технические средства и системы), технические средства и системы охраны и защиты информационных ресурсов и систем.
    Безопасность информационных ресурсов и ИС характеризует такое состояние информационных ресурсов и ИС и поддерживающей их инфраструктуры, при которой с требуемой вероятностью должна обеспечиваться защита информации в ходе предоставления услуг от утечки, несанкционированных и непреднамеренных воздействий.
    Обеспечение информационной безопасности представляет собой многоуровневый подход для организации, предоставляющей публичные услуги. Обеспечение информационной безопасности должно осуществляться на четырех уровнях:
    - законодательный уровень (законы, нормативные акты, стандарты);
    - административный уровень (действия общего характера, предпринимаемые руководством);
    - процедурный уровень (конкретные меры безопасности, имеющие дело с людьми);
    - технический уровень (конкретные технические меры).
    В процессе предоставления публичных услуг для обеспечения безопасности информационных ресурсов должны быть обеспечены как минимум три аспекта безопасности:
    - конфиденциальность – обеспечение доступа к информации только авторизованным пользователям;
    - целостность – обеспечение достоверности и полноты информации и методов ее обработки;
    - доступность – обеспечение доступа к информации и связанным с ней активам авторизованных пользователей по мере необходимости.
    4.1. Цели обеспечения информационной безопасности
    Целями обеспечения информационной безопасности в процессе предоставления услуг являются обеспечение сохранности и конфиденциальности информации, защита и гарантия доступности, достоверности и целостности информации, избежание утечки информации, минимизация ущерба от событий, несущих угрозу информационной безопасности.
    Для обеспечения информационной безопасности при предоставлении публичных услуг должны быть достигнуты следующие цели:
    - обеспечение конфиденциальности информации в соответствии с проведенной классификацией;
    - обеспечение целостности информации на всех этапах, связанных с нею процессов (создание, обработка, хранение, передача и уничтожение) при предоставлении публичных услуг;
    - обеспечение своевременной доступности информации при предоставлении публичных услуг;
    - обеспечение наблюдаемости, направленной на фиксирование любой деятельности пользователей и процессов;
    - обеспечение аутентичности и неотказуемости от транзакций и действий, производимых участниками предоставления публичных услуг;
    - учет всех процессов и событий, связанных с вводом, обработкой, хранением, предоставлением и уничтожением данных.
    4.2. Задачи системы информационной безопасности
    Для достижения целей обеспечения безопасности при предоставлении публичных услуг необходимо выполнение следующих задач:
    - идентификация информационных ресурсов и систем и их классификация в зависимости от их ценности и важности в процессе предоставления публичных услуг (компоненты анализа должны включать данные, приложения, технологии, телекоммуникационные и аппаратные средства, помещения, человеческие ресурсы и т.д.);
    - идентификация угроз информационной безопасности и определение возможных источников угрозы по каждому информационному ресурсу и системе;
    - идентификация уязвимых мест по каждой иденти-фицированной угрозе;
    - оценка рисков по идентифицированным информа-ционным ресурсам и системам;
    - выбор мероприятий по управлению информационной безопасностью на основе анализа соотношения стоимости их реализации к эффекту от снижения рисков и возможным убыткам в случае нарушения безопасности;
    - разработка и внедрение механизма и мер оперативного реагирования на угрозы информационной безопасности и проявления негативных тенденций в функционировании информационных ресурсов и систем предоставления публичных услуг;
    - разработка и внедрение системы контролей, позволяющих обеспечивать эффективное функционирование механизма и мер обеспечения безопасности;
    - организация процесса эффективного пресечения посягательств на информационные ресурсы и системы;
- организация процесса обеспечения непрерывности предоставления услуг и создание условий для максимально возможного возмещения и локализации наносимого ущерба неправомерными действиями физических и юридических лиц, ослабление негативного влияния последствий нарушения информационной безопасности;
    - организация процесса обеспечения безопасности при наличии поставщиков услуг, имеющих доступ к информационным ресурсам или системам при предоставлении публичных услуг.
        4.3. Принципы обеспечения информационной безопасности
    Система обеспечения информационной безопасности в ходе предоставления публичных услуг должна создаваться на следующих принципах:
    - принцип равнопрочности - означает обеспечение защиты оборудования, программного обеспечения и системы управления от всех видов угроз;
    - принцип непрерывности - предусматривает непре-рывное обеспечение безопасности информационных ресурсов, ИС для непрерывного предоставления публичных услуг;
    - принцип разумной достаточности - означает применение таких мер и средств защиты, которые являются разумными, рациональными и затраты на которые, не превышают стоимости нарушения информационной безопасности;
    - принцип комплексности – для обеспечения безопасности во всем многообразии структурных элементов, угроз и каналов несанкционированного доступа должны применяться все виды и формы защиты в полном объеме. Недопустимо применять отдельные формы или технические средства;
    - принцип комплексной проверки - заключается в проведении специальных исследований и проверок, специального инженерного анализа оборудования, верификационных исследований программных средств. Должен осуществляться непрерывный мониторинг аварийных сообщений и параметров ошибок, постоянно должно выполняться тестирование аппаратного и программного оборудования, а также контроль целостности программных средств, как при загрузке программных средств, так и в процессе функционирования;
    - принцип надежности – методы, средства и формы защиты должны надежно перекрывать все пути проникновения и возможные каналы утечки информации, для этого допускается дублирование средств и мер безопасности;
    - принцип универсальности - меры безопасности должны перекрывать пути угроз независимо от места их возможного воздействия;
- принцип плановости – планирование должно осуществляться путем разработки детальных планов действий по обеспечению информационной защищенности всех компонент системы предоставления публичных услуг;
    - принцип централизованного управления – в рамках определенной структуры должна обеспечиваться организованно-функциональная самостоятельность процесса обеспечения безопасности при предоставлении публичных услуг;
    - принцип целенаправленности – необходимо защищать то, что должно защищаться в интересах конкретной цели;
    - принцип активности – защитные меры обеспечения безопасности в работе процесса предоставления услуг должны претворяться в жизнь с достаточной степенью настойчивости;
    - принцип квалификации обслуживающего персонала – обслуживание оборудования должно осуществляться сотрудниками, подготовленными не только в вопросах эксплуатации техники, но и в технических вопросах обеспечения безопасности информации;
    - принцип ответственности - ответственность за обеспечение информационной безопасности должна быть ясно установлена, передана соответствующему персоналу и утверждена всеми участниками в рамках процесса обеспечения информационной безопасности.

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

    Методология управления информационной безопасностью при предоставлении публичных услуг охватывает следующие этапы:
    - разработка и поддержка политики информационной безопасности;
    - управление рисками;
    - организационная безопасность;
    - классификация активов и организация контрольной среды;
    - безопасность персонала;
    - физическая безопасность;
    - управление коммуникациями и операционной деятельностью информационных технологий (ИТ);
    - контроль доступа;
    - разработка и обслуживание ИС;
    - управление непрерывностью деятельности;
    - соответствие требованиям;
    - управление информационной безопасностью при привлечении сторонних организаций.
    5.1. Разработка и поддержка политики информационной безопасности
    Цель политики информационной безопасности заключается в обеспечении решения вопросов информационной безопасности и вовлечение высшего руководства организации в данный процесс.
    Политика информационной безопасности представляет собой самый важный документ в системе управления безопасностью организации и один из ключевых механизмов безопасности, на основе которого должна строиться вся система мер и средств обеспечения безопасности при предоставлении публичных услуг.
    В процессе разработки и поддержки политики информационной безопасности должны соблюдаться следующие требования:
    - разработка и реализация политики информационной безопасности организации должна осуществляться высшим руководством путем выработки четкой позиции в решении вопросов безопасности;
    - политика информационной безопасности должна устанавливать ответственность руководства, а также излагать подход организации к управлению безопасностью;
    - политика информационной безопасности в обязательном порядке должна включать следующее:
    1) определение безопасности, ее общих целей и сферы действия, а также раскрытие значимости безопасности как инструмента, обеспечивающего возможность совместного использования информации;
    2) изложение целей и принципов безопасности, сформулированных руководством;
    3) краткое изложение наиболее существенных для организации политик информационной безопасности, принципов, правил и требований;
    4) определение общих и конкретных обязанностей сотрудников в рамках управления безопасностью, включая информирование об инцидентах нарушения безопасности;
    5) ссылки на документы, дополняющие политику информационной безопасности, например, более детальные политики и процедуры безопасности для конкретных ИС, а также правила безопасности, которым должны следовать пользователи;
    - политика информационной безопасности должна быть утверждена, издана и надлежащим образом доведена до сведения всех сотрудников организации в доступной и понятной форме;
    - должно быть назначено ответственное лицо за политику информационной безопасности, которое отвечало бы за ее реализацию и пересмотр, как минимум раз в год;
    - периодические пересмотры должны включать:
    1) проверку эффективности политики, исходя из характера, числа и последствий зарегистрированных инцидентов нарушения безопасности;
    2) определение стоимости мероприятий по управлению безопасностью и их влияние на эффективность выполнения процессов;
    3) оценку влияния изменений в ИТ.
    Эффективная политика информационной безопасности должна определять необходимый и достаточный набор требований безопасности, позволяющих уменьшить риски безопасности до приемлемой величины. Данные требования должны учитывать особенности процессов организации, предоставляющей публичные услуги, должны поддерживаться руководством, позитивно восприниматься и исполняться сотрудниками организации.
    План обеспечения безопасности определяет все действия по достижению целей обеспечения безопасности, по внедрению аппаратно-программного комплекса, и устанавливает процедуры улучшения процесса обеспечения безопасности, проведения тренингов и семинаров по обучению и повышению осведомленности персонала.
    Требования к плану обеспечения безопасности при предоставлении публичных услуг должны включать:
- требования к плану обеспечения безопасности:
    1) должен разрабатываться и реализовываться план обеспечения безопасности при предоставлении услуг;
    2) план обеспечения безопасности должен содержать краткий обзор требований безопасности предоставления услуг и описание мер и средств обеспечения безопасности, применяемых или планируемых к внедрению для удовлетворения этих требований;
    3) план обеспечения безопасности должен быть рассмотрен и утвержден соответствующими должностными лицами;
    4) план обеспечения безопасности должен периодически пересматриваться и корректироваться с учетом изменений в системе предоставления публичных услуг или проблем, возникших в процессе ее реализации, и оценки эффективности мер и средств обеспечения безопасности;
    - требования, связанные с правилами поведения персонала, участвующего в процессе предоставления публичных услуг:
    1) должны быть установлены правила поведения персонала в отношении обеспечения безопасности;
    2) правила поведения должны описывать обязанности персонала и ожидаемые от них действия по обеспечению безопасности;
    3) от каждого специалиста должно быть получено письменное подтверждение, что он ознакомлен и соглашается соблюдать установленные правила поведения.
    5.2. Управление рисками
    Управление рисками представляет собой процесс выявления, контроля и минимизации или устранения рисков безопасности, оказывающих влияние на информационные ресурсы и системы, участвующие в процессе предоставления публичных услуг, в рамках допустимых затрат.
    Управление рисками должно включать следующие этапы:
    - определение области и границ процесса управления рисками;
    - анализ и оценка рисков;
    - выбор и внедрение мер и средств по минимизации рисков;
    - мониторинг процесса управления рисками и эффективности выбранных мероприятий по снижению риска.
    Требования к управлению рисками должны включать:
    - должны разрабатываться, документироваться и периодически обновляться политика управления рисками, а также процедуры и меры, связанные с реализацией этой политики;
    - должна осуществляться оценка рисков и потенциального ущерба, который может быть нанесен вследствие несанкционированного доступа, использования, раскрытия, модификации или уничтожения информационных ресурсов и систем;
    - должна осуществляться переоценка рисков с установленной периодичностью или после внесения существенных изменений в ИС предоставления публичных услуг;
    - требования к исследованию угроз и уязвимостей:
    1) с установленной периодичностью должна проводиться идентификация новых угроз и уязвимостей;
    2) исследование угроз и уязвимостей должно проводиться с использованием специальных методик и инструментальных средств;
    3) инструментальные средства, предназначенные для исследования угроз и уязвимостей, должны предоставлять возможность обновления их списков;
    4) обновление списков угроз и уязвимостей должно осуществляться с установленной периодичностью.
    5.2.1 Определение области и границ процесса управления рисками
    На данном этапе необходимо определить области применения управления рисками, то есть выявить категории активов и внутренних процессов в организации, которые будут рассматриваться в ходе данного процесса, а также определить уровень детализации в определении рисков.
    5.2.2 Анализ и оценка рисков
    Использование системы предоставления услуг связано с определенной совокупностью рисков.
    Анализ рисков представляет собой процесс выявления факторов, способных негативно влиять на процесс предоставления публичных услуг. Целью данного процесса является определение уязвимостей, связанных с активами в системе предоставления услуг, использование которых может привести к нарушению безопасности оказания публичных услуг.
    Оценка рисков представляет собой систематический анализ:
    - вероятного ущерба, который может быть нанесен в результате сбоя в защите, принимая во внимание возможные последствия утраты конфиденциальности, целостности или доступности информации и иных активов;
    - вероятности наступления такого нарушения с учетом существующих угроз и уязвимостей, а также внедренных мер и средств по обеспечению безопасности.
    Для контроля эффективности процесса предоставления публичных услуг, процесс анализа и оценки рисков должен проводиться периодически, как минимум один раз в год, используя систематический подход оценки величины рисков.
    Для определения состава угроз и уязвимостей должны использоваться следующие источники:
    - результаты анализа соответствия используемых мер и средств обеспечения безопасности установленным требованиям безопасности;
    - печатные и электронные источники, содержащие известные угрозы и уязвимости средств обеспечения безопасности;
    - результаты работы автоматизированных средств выявления угроз и уязвимостей;
    - результаты тестирования средств обеспечения безопасности.
    Требуется осуществлять периодический анализ и оценку рисков безопасности и реализуемых средств контроля для обеспечения:
        - учета изменений в требованиях и приоритетах организации;
    - принятия во внимание появление новых угроз и уязвимых мест;
    - гарантии, что средства обеспечения безопасности и контроля функционируют эффективно.
    Анализ рисков должен выполняться на различных уровнях в глубину, в зависимости от результатов предыдущих оценок и меняющихся уровней рисков, уровень которых является приемлемым для руководства.
    Оценки рисков должны проводиться сначала на высоком уровне как средства определения приоритетности ресурсов в областях повышенного риска, а затем на более детальном уровне для рассмотрения более специфичных рисков.
    Значение риска от реализации угрозы должно определяться как функция вероятности возникновения ущерба физическим или юридическим лицам, государственному имуществу, который может быть нанесен в результате невыполнения функций, возлагаемых на системы предоставления услуг и нарушения условий ее эксплуатации.
    Значение риска нарушения безопасности для каждого конкретного актива должно определяться как максимальное значение риска для всех рассмотренных угроз безопасности, относящихся к этому конкретному информационному активу.
    При проведении анализа рисков необходимо выполнить комплекс следующих действий:
    - идентификация и оценка активов (аппаратное и программное обеспечение, телекоммуникационные средства, информационные ресурсы и системы, средства обеспечения безопасности);
    - идентификация и описание угроз, уязвимостей и средств обеспечения безопасности и контроля. При идентификации угроз безопасности должны быть выявлены все имеющиеся и потенциально возможные угрозы безопасности следующих категорий:
    1) объективные и субъективные;
    2) внутренние и внешние;
    3) случайные и преднамеренные.
    Описание угрозы безопасности должно содержать:
    1) источник угрозы;
    2) способ (метод) реализации угрозы;
    3) используемая уязвимость;
    4) вид защищаемых активов, на которые воздействует угроза;
    5) вид воздействия на активы.
    6) нарушаемое свойство безопасности активов;
    - определение вероятности угрозы и воздействия на конфиденциальность, целостность, доступность и достоверность. При определении вероятности реализации угрозы должны быть учтены:
        1) мотивация, компетентность источника угрозы и используемые им ресурсы;
    2) существующие уязвимости;
    3) наличие и эффективность мер и средств обеспечения безопасности;
    - оценка рисков, подготовка рекомендаций по противодействию. Уровень ущерба от реализации угрозы должен определяется как максимальный уровень ущерба для нарушаемых в результате реализации угрозы характеристик безопасности информации, обрабатываемой в системе предоставления услуг;
    - разработка соответствующей политики и документации по анализу, оценке и управлению рисками.
    Требования к защите должны идентифицироваться путем методической оценки рисков для безопасности. Методы оценки рисков могут применяться к организации в целом или только к ее частям, а также к отдельным ИС, специфическим системным компонентам или услугам, когда это практически осуществимо и необходимо.
    Результаты этой оценки должны использоваться в определении и выборе направления соответствующего управленческого действия по обеспечению безопасности, в определении приоритетов защиты информации и в реализации средств обеспечения безопасности и контроля.
    5.2.3. Выбор и внедрение мер и средств по мини-мизации рисков
    5.2.3.1. Выбор мер и средств по минимизации рисков
    После проведения анализа и оценки рисков необходимо принять решение по выбору мер и средств по минимизации рисков до приемлемого уровня, подтвержденного руководством.
    При принятии решения по выбору мер и средств обеспечения безопасности и контроля необходимо учесть следующие факторы:
    - затраты на внедрение и сопровождение мер и средств обеспечения безопасности;
    - политика руководства организации;
    - простота реализации выбранных решений.
    С учетом того, что безопасность при предоставлении услуг может обеспечиваться различными комбинациями организационных и технических мер и средств, выбор конкретной совокупности мер и средств обеспечения безопасности должен осуществляться, исходя из минимизации организационных, технических и финансовых затрат на реализацию ИС предоставления публичных услуг.
    Меры по минимизации рисков должны включать:
    - уменьшение риска - риск считается неприемлемым. Для его уменьшения должны быть выбраны и реализованы соответствующие меры и средства обеспечения безопасности и контроля;
    - передача риска - риск считается неприемлемым и на определенных условиях должен передаваться сторонней организации (например, в рамках страхования или аутсорсинга);
    - принятие риска - риск в конкретном случае считается осознанно допустимым. Организация осознает и принимает возможные последствия, так как стоимость контрмер значительно превосходит финансовые потери в случае реализации угрозы либо невозможно найти подходящие меры и средства обеспечения безопасности и контроля;
    - отказ от риска - отказ от процессов в организации, являющихся причиной риска или от услуг третьих сторон в случае, когда последние неспособны обеспечить приемлемый уровень риска cвязанный с их услугами.
    Выбор мер и средств обеспечения безопасности при предоставлении публичных услуг должен осуществляться в следующей последовательности:
    - анализ применяемых мер и средств обеспечения безопасности;
    - дополнение применяемых мер и средств обеспечения безопасности мерами и средствами, необходимыми для выполнения требований, определенных в результате оценки рисков нарушения безопасности;
    - оценка риска нарушения безопасности для выбранного набора мер и средств обеспечения безопасности;
    - уточнение выбранного набора мер и средств обеспечения безопасности, а также, при необходимости, требований безопасности, если определенный уровень риска не соответствует установленному допустимому уровню риска нарушения безопасности.
    После определения необходимых мер и средств по минимизации рисков необходимо выполнить комплекс следующих действий:
    - определить условия и методы функционирования средств обеспечения безопасности и контроля а также аппаратно-программного комплекса;
    - установить настройки средств обеспечения безопасности и контроля, а также аппаратно-программного комплекса на автоматическую работу или на отслеживание персоналом;
    - распределить ответственность за проведение контрольных проверок функционирования средств обеспечения безопасности и контроля и аппаратно-программного комплекса.
    Меры и средства по минимизации рисков должны периодически пересматриваться, не менее одного раза в год.
    5.2.3.2. Внедрение мер и средств по минимизации рисков
    Внедрение мер и средств по минимизации рисков должно осуществляться в строгом соответствии с политикой информационной безопасности.
    Для внедрения мер и средств по минимизации рисков должна быть:
    - определена персональная ответственность за применение мер и средств обеспечения безопасности при эксплуатации системы предоставления публичных услуг;
    - разработана организационно-распорядительная документация по внедрению мер и средств обеспечения безопасности, определяющая:
    1) задачи персонала и пользователей по применению мер и средств обеспечения безопасности;
    2) порядок действий при возникновении инцидентов нарушения безопасности в ходе процесса предоставления услуг;
    3) процедуры контроля над применением мер и средств обеспечения безопасности.
    Настройка средств обеспечения безопасности должна осуществляться на полностью развернутой и готовой к эксплуатации ИС предоставления публичных услуг.
    После внедрения мер и средств обеспечения безопасности должны быть проведены контрольные проверки и испытания для того, чтобы установить правильность их реализации и эффективность в противодействии угрозам безопасности.
    Все решения по выбору и внедрению мер и средств относительно управления рисками должны быть зарегистрированы и документированы, а также должны гарантировать, что риски уменьшены до приемлемого уровня.
    5.2.4. Мониторинг процесса управления рисками и эффективности выбранных мероприятий по минимизации рисков
    Мониторинг управления рисками предполагает анализ результатов мероприятий по снижению степени выявленных рисков. На данном этапе должны быть определены механизмы оценки и контроля эффективности управления программным обеспечением (ПО), проектами и ресурсами в рамках решений, принятых относительно рисков.
    В ходе проведения мониторинга процесса управления рисками и эффективности мер по минимизации рисков необходимо выполнить комплекс следующих действий:
    - создать систему мониторинга выявленных рисков и мероприятий по их снижению;
    - проверить эффективность мероприятий и работ по минимизации рисков;
    - идентифицировать изменения рисков для организации при внесении изменений в национальном законодательстве, появлении новых технологий предоставления услуг, изменении организационной структуры и полномочий организации, применении новых ИС и ИТ;
    - построить единую систему информирования об изменениях с адекватным процессом управления изменениями;
    - определить адекватности текущего процесса управления рисками к существующим изменениям;
    - определить механизм сохранения рабочей информации, рассматриваемой в процессе управления рисками.
    В качестве способов мониторинга процесса управления рисками необходимо:
    - применять технические меры - мониторинг, анализ системных журналов и выполнения проверок с целью подготовки отчетности для предоставления руководству;
    - проводить анализ со стороны руководства;
    - проводить независимые внутренние аудиты информационной безопасности.
    Аудит системы управления рисками является необходимым этапом мониторинга рисков, в ходе которого должны быть рассмотрены:
    - эффективность телекоммуникационных средств внутри и извне организации;
    - эффективность расходования средств на мероприятия, связанные с управлением рисками;
    - эффективность работы внешних консультантов и третьих сторон, выполняющих аутсорсинг;
    - наличие механизмов реагирования на кризисную ситуацию и эффективность плана обеспечения непрерывной деятельности;
    - процедуры работы с ключевыми рисками, наличие внутренних планов проверок, разработанных для идентификации новых рисков и угроз.
    5.3. Организационная безопасность
    Создание и внедрение системы обеспечения безопасности при предоставлении публичных услуг возможны только при четком определении ответственности и полномочий, связанных с реализацией процессов управления и обеспечения безопасности.
    Реализация подразделениями и отдельными сотрудниками организации обязанностей по обеспечению безопасности должна осуществляться в соответствии с разработанными и утвержденными руководством организационно-распорядительными документами (положениями, инструкциями, обязанностями, перечнями, формулярами).
    При определении ответственности и полномочий, связанных с обеспечением безопасности процесса предоставления публичных услуг, обязательным является выполнение следующих требований:
    - должны быть определены специфические роли и обязанности по осуществлению и поддержанию соответствующих мер и средств по защите активов организации;
    - руководство должно предоставлять подтверждение своих обязательств по созданию, внедрению, эксплуатации, постоянному контролю, анализу, поддержанию в рабочем состоянии и улучшению системы обеспечения безопасности путем комплекса следующих действий:
    1) создание политики безопасности, а также планов обеспечения безопасности;
    2) довести до сведения персонала, участвующего в процессе оказания публичных услуг, о важности выполнения целей обеспечения безопасности при предоставлении публичных услуг;
    3) обеспечение достаточного количества ресурсов для создания, внедрения, эксплуатации, постоянного контроля, анализа, поддержания в рабочем состоянии и улучшения системы обеспечения безопасности;
    4) принятие решения о критериях принятия риска и приемлемых уровнях риска;
    - уровни ответственности и полномочий должны быть ясно определены и документированы;
    - должно быть назначено ответственное лицо по управлению безопасности, а также по внедрению мер и средств обеспечения безопасности;
    - деятельность по защите информации должна быть скоординирована представителями различных структурных единиц организации с соответствующими ролями и рабочими функциями;
    - руководство должно требовать от сотрудников и третьих сторон обеспечивать безопасность процесса предоставления публичных услуг в соответствии с установленными требованиями безопасности;
    - детали назначенной ответственности должны быть документированы в организационно-распорядительных документах;
    - необходимо определить обязанности по защите отдельных активов, и по выполнению определенных процессов и процедур, связанных с безопасностью процесса предоставления услуг;
    - ответственное лицо по защите определенного актива может передавать свои полномочия по обеспечению безопасности либо сотруднику организации, либо третьей стороне, при условии, что переданные полномочия реализуются должным образом.
    5.4. Классификация активов и организация контрольной среды
    Классификация активов, подлежащих защите, является необходимым элементом организации работ по обеспечению информационной безопасности системы предоставления публичных услуг.
    Целями проведения классификации активов являются:
    - определение и поддержка в рабочем состоянии адекватной и эффективной системы защиты активов при предоставлении публичных услуг;
    - обеспечение соответствующего уровня защиты информационных ресурсов и систем, участвующих в процессе оказания публичных услуг.
    При проведении классификации активов должны выполняться следующие требования:
    - все активы должны быть учтены и закреплены за ответственными владельцами;
    - необходимо определить ответственность владельцев активов за поддержание соответствующих мер по обеспечению информационной безопасности;
    - каждый актив должен быть четко идентифицирован и классифицирован в зависимости от критериев безопасности;
    - владельцы активов должны быть авторизованы, а данные о них документированы.
    Необходимо осуществлять классификацию защищаемых активов, с целью правильного выбора мер и средств обеспечения их безопасности, путем выполнения следующих действий:
    - установление градаций важности обеспечения защиты активов;
    - отнесение конкретных активов к соответствующим категориям.
    В качестве активов могут выступать и публичные услуги, предоставляемые через Правительственный портал.
    Для системы предоставления публичных услуг должны применяться степени секретности и категории целостности защищаемых активов, а также степени доступности услуг.
    Категории защиты для активов, таких как средства обработки информации, должны устанавливаться в зависимости от категорий секретности и целостности хранимой или обрабатываемой информации. Для данных активов должны быть определены конкретные требования по применению соответствующих вариантов обязательных мер и настроек средств защиты информации.
    Все результаты классификации должны быть рассмотрены и утверждены соответствующими должностными лицами и должны быть документированы в плане обеспечения безопасности ИС предоставления публичных услуг.
    На основе классификации активов должна быть организована контрольная среда со следующими элементами:
    - основные принципы управления организацией;
    - организационная структура;
    - разделение ответственности и полномочий;
    - кадровая политика.
    По каждому элементу необходимо проводить контрольные процедуры, необходимые для достижения целей соответствия внутренним требованиям организации и обеспечения безопасности.
    5.4.1. Степени секретности защищаемых активов
    Степени секретности защищаемых активов регламентированы Законом Республики Молдова «О государственной тайне» № 245 от 27.11.2008 г.
    5.4.2. Категории целостности защищаемых активов
    Категории целостности защищаемых активов являются:
    - «Высокие» - данная категория включает активы, несанкционированная модификация или фальсификация которых может привести к нанесению значительного прямого ущерба организации, целостность и аутентичность которых должны обеспечиваться гарантированными методами (цифровая подпись) в соответствии с обязательными требованиями действующего законодательства;
    - «Низкие» - данная категория включает активы, несанкционированная модификация, подмена или удаление которых может привести к нанесению незначительного косвенного ущерба организации, ее пользователям или сотрудникам;
    - «Нет требований» - данная категория включает активы, к обеспечению целостности которых требований не предъявляется.
    5.4.3. Степени доступности услуг
    Для системы предоставления публичных услуг должны применяться следующие степени доступности услуг в зависимости от категории пользователей:
    - «Беспрепятственная доступность» - доступ к услуге должен обеспечиваться в любое время, услуга должна предоставляться постоянно, задержка получения результата не должна превышать нескольких секунд или минут;
    - «Высокая доступность» - доступ к услуге должен осуществляться без существенных временных задержек;
    - «Средняя доступность» - доступ к услуге может обеспечиваться с существенными временными задержками, задержка получения результата не должна превышать 3 дней;
    - «Низкая доступность» - временные задержки при доступе к услуге практически не лимитированы, допустимая задержка получения результата - 7 дней.
    5.5. Безопасность персонала
    5.5.1. Основные требования к безопасности персонала
    Обеспечение требуемого уровня безопасности предоставления публичных услуг, достигается надлежащей подготовкой специалистов и пользователей, участвующих в процессе предоставления публичных услуг, и соблюдением ими всех установленных правил, направленных на обеспечение безопасности.
    Основные требования к безопасности персонала, участвующего в процессе предоставления публичных услуг, должны включать:
    - разработку, документирование и периодическое обновление политики обеспечения безопасности персонала, а также процедуры и меры, связанные с реализацией этой политики;
    - требования к классификации персонала:
    1) должны быть назначены категории персонала и определены соответствующие критерии отбора персонала каждой категории;
    2) категории персонала и критерии отбора должны периодически анализироваться и при необходимости корректироваться;
- требования безопасности при найме персонала:
    1) необходимо проводить соответствующую проверку кандидатов на работу, особенно это должно касаться должностей, предполагающих доступ к критичным активам (наличие положительных рекомендаций, проверка резюме претендента, подтверждение заявляемого образования и профессиональных квалификаций, независимая проверка подлинности документов, удостоверяющих личность);
    2) все сотрудники и представители сторонних организаций, использующие средства обработки информации, должны подписывать соглашение о конфиденциальности;
    - требования безопасности при увольнении персонала:
    1) при увольнении специалиста должен быть прекращен его доступ к активам;
    2) с увольняемым специалистом должна быть проведена заключительная беседа;
    3) должен быть обеспечен возврат всех атрибутов, (ключей, идентификационных карточек и т.п.), имевшихся у увольняемого специалиста;
    4) должна быть обеспечена возможность доступа к информации, созданной увольняемым специалистом, со стороны уполномоченных специалистов организации;
    - при перемещении специалиста на другую должность должны быть пересмотрены его атрибуты и средства, на основе которых он получает доступ (например, перегенерация ключей, идентификационные карты, удаление старой учетной записи и создание новой учетной записи);
    - определение и применение санкций различного характера к специалистам, не выполняющим требования соответствующих политик и процедур обеспечения безопасности.
    5.5.2. Требования к информированию и обучению вопросам обеспечения безопасности
    Для обеспечения уверенности в осведомленности пользователей об угрозах и проблемах, связанных с безопасностью, и их оснащенности всем необходимым для соблюдения требований политики безопасности, при выполнении служебных обязанностей, необходимо:
    - разрабатывать, документировать и периодически обновлять политику обучения (тренинга) безопасности, а также процедуры и меры, связанные с реализацией политики обучения безопасности;
    - соблюдать требования к информированию по вопросам безопасности:
    1) в должностных инструкциях должны быть включены общие обязанности по внедрению и соблюдению политики безопасности и специфические особенности по защите определенных активов или действий, касающихся безопасности;
    2) пользователей необходимо обучать процедурам безопасности и правильному использованию средств обработки информации для минимизации возможных рисков безопасности;
    - соблюдать требования к обучению вопросам безопасности:
    1) должны быть идентифицированы лица из числа персонала, выполняющие роли и имеющие обязанности, существенные с точки зрения влияния на безопасность;
    2) должны быть сформированы группы обучения, в зависимости от выполняемых функций и обязанностей;
    3) для каждой группы должны быть разработаны учебные материалы;
    4) обучение сотрудников должно обеспечить знание ими требований безопасности, ответственности в соответствии с действующим законодательством, мер и средств обеспечения безопасностью, а также знание правильного использования средств обработки информации;
    5) идентифицированные лица должны пройти обучение вопросам безопасности;
    - персонал, участвующий в процессе предоставления публичных услуг, должен пройти обучение следующим вопросам:
    1) система защиты процесса предоставления публичных услуг и порядок работы с ней;
    2) основные принципы построения и особенности современных средств защиты информации;
    3) методы защиты информации.
    5.5.3. Требования к реагированию на инциденты нарушения безопасности
    Для минимизации ущерба от инцидентов нарушения безопасности и сбоев функционирования комплекса программно-аппаратных средств, а также для осуществления мониторинга и реагирования по случаям инцидентов необходимо:
    - разрабатывать, документировать и периодически обновлять политику реагирования на инциденты нарушения безопасности, а также процедуры и меры, связанные с реализацией политики реагирования на инциденты нарушения безопасности;
    - соблюдать требования к информированию об инцидентах нарушения безопасности:
    1) об инцидентах нарушения безопасности необходимо информировать руководство в соответствии с установленным порядком, по возможности, незамедлительно;
    2) все сотрудники и сторонние организации должны быть осведомлены о процедурах информирования о различных типах инцидентов, таких как нарушение безопасности, наличие потенциальной угрозы и уязвимости, возникшие сбои программно-аппаратных средств, которые могут оказать негативное влияние на безопасность активов организации;
    3) должны быть установлены меры дисциплинарной ответственности сотрудников, нарушающих требования безопасности;
    - соблюдать требования к обучению действиям по реагированию на инциденты нарушения безопасности:
    1) персонал должен проходить периодичную подготовку по вопросам ответственности и обязанностей при осуществлении действий по управлению реагированием на инциденты нарушения безопасности;
    2) в процессе подготовки персонала должны моделироваться соответствующие события, что поможет в будущем персоналу эффективно выполнить требуемые от него действия при возникновении кризисных ситуаций;
        3) должны использоваться автоматизированные средства для того, чтобы обеспечить более полную и реалистичную среду обучения;
    - соблюдать требования к обработке инцидентов:
    1) возможности по обработке инцидентов должны включать: обнаружение, анализ, предотвращение развития, устранение инцидентов нарушения безопасности и восстановление безопасности после инцидентов;
    2) должны использоваться автоматизированные средства для поддержки процесса обработки инцидентов;
    - соблюдать требования по проверке эффективности действий по реагированию на инциденты нарушения безопасности:
    1) должна осуществляться периодическая проверка эффективности действий по реагированию на инциденты нарушения безопасности с использованием соответствующих тестов (проверочных последовательностей действий);
    2) должны использоваться автоматизированные средства для более тщательной проверки эффективности действий по реагированию на инциденты нарушения безопасности;
    - соблюдать требования по мониторингу инцидентов:
    1) необходимо установить порядок мониторинга и регистрации инцидентов и сбоев в отношении их числа, типов, параметров;
    2) инциденты нарушения безопасности должны отслеживаться и документироваться на постоянной основе;
    3) должны использоваться автоматизированные средства при отслеживании инцидентов нарушения безопасности, сборе и анализе информации об инцидентах;
    - соблюдать требования по предоставлению отчетов об инцидентах:
    1) необходимо представлять отчеты об инцидентах установленным органам в соответствии с установленной формой и периодичностью;
    2) должны использоваться автоматизированные средства поддержки разработки и предоставления отчетов об инцидентах нарушения безопасности.
    5.6. Физическая безопасность
    Для предотвращения неавторизованного доступа, повреждения и воздействия в отношении помещений и информации организации необходимо обеспечивать физическую безопасность средств обработки критичной служебной информации, посредством использования различных защитных барьеров и средств контроля проникновения.
    Требования к физической защите должны включать:
    - разработку, документирование и периодическое обновление политики физической защиты и защиты среды ИС, а также процедуры и меры, связанные с реализацией этой политики;
    - требования к санкционированию физического доступа:
    1) должны быть разработаны списки персонала, которому будет разрешен доступ к активам и выпущены соответствующие мандаты (значки, идентификационные карты, интеллектуальные карты);
    2) соответствующие должностные лица должны рассматривать и утверждать списки и мандаты, разрешающие доступ;
    3) списки доступа должны пересматриваться в соответствии с установленной периодичностью;
- требования к управлению физическим доступом:
    1) уровень защищенности должен быть соразмерен с идентифицированными рисками;
    2) должно осуществляться управление физическим доступом во всех точках доступа к активам;
    3) необходимо использовать четко определенные периметры безопасности для защиты помещений и зон расположения средств обработки информации;
    4) доступ в помещения и здания должен быть предоставлен только авторизованному персоналу;
    3) контроль физического доступа к помещениям должен обеспечиваться использованием самых жестких методов идентификации/аутентификации;
    - требования к контролю посетителей:
    1) должна быть выделена зона регистрации посетителей или должны существовать другие мероприятия по управлению физическим доступом в помещения или здания;
    2) должно осуществляться управление физическим доступом посетителей на объекты;
    3) должно осуществляться сопровождение посетителей на объектах и контроль их действий;
    - требования по ведению журналов учета доступа посетителей:
    1) посетители зон безопасности должны сопровождаться или обладать соответствующим допуском;
    2) должны вестись журналы учета доступа посетителей, где необходимо регистрировать дату и время входа и выхода;
    3) журналы учета доступа посетителей должны периодически анализироваться соответствующими должностными лицами;
    4) должны использоваться автоматизированные средства ведения журналов учета доступа посетителей;
    - требования к защите оборудования:
    1) оборудование должно быть расположено и защищено так, чтобы уменьшить риски от воздействий окружающей среды и возможности неавторизованного доступа;
    2) оборудование необходимо защищать от перебоев в подаче электроэнергии и других сбоев, связанных с электричеством, например, наличие резервных источников питания;
    3) оборудование необходимо защищать от пожаров и других чрезвычайных ситуаций;
    4) необходимо защищать телекоммуникационные кабельные сети от перехвата информации или повреждения;
    5) необходимо проводить надлежащее техническое обслуживание оборудования для обеспечения его непрерывной работоспособности и целостности.
    5.7. Управление коммуникациями и операционной деятельностью информационных технологий
    Для обеспечения уверенности в надлежащем и безопасном функционировании средств обработки информации необходимо установить обязанности и процедуры по управлению и функционированию всех средств обработки информации.
    К управлению коммуникациями и операционной деятельностью функционирования ИТ и средств обработки информации предъявляются следующие требования:
    - требования к операционным процедурам:
    1) операционные процедуры должны рассматриваться как официальные документы, документироваться и строго соблюдаться, а изменения к ним должны утверждаться руководством;
    2) процедуры должны содержать детальную инструкцию выполнения конкретного задания и включать:
    a) обработку и управление информацией;
    b) определение требований в отношении графика выполнения заданий, включающих взаимосвязи между системами;
    c) время начала выполнения самого раннего задания и время завершения самого последнего задания;
    d) обработку ошибок или других исключительных ситуаций, которые могут возникнуть в течение выполнения заданий;
    e) перезапуск системы и процедуры восстановления в случае системных сбоев;
    3) необходимо обеспечить синхронизацию системных часов для правильного выполнения операций в сети;
    4) необходимо постоянно контролировать изменения конфигурации в средствах и системах обработки информации;
    5) должны быть определены и внедрены роли, ответственности и процедуры обеспечения контроля всех изменений в оборудовании, ПО или процедурах;
    6) должны быть определены обязанности и процедуры по управлению инцидентами для обеспечения быстрой, эффективной и организованной реакции на нарушения безопасности;
    7) необходимо наличие журнала регистрации ошибок, появившихся в результате сбоев и несоответствий в процессе работы системы;
    - требования к защите от вредоносного ПО:
    1) пользователи должны быть осведомлены об опасности использования неавторизованного или вредоносного ПО;
    2) необходимо внедрять специальные средства контроля для обнаружения и/или предотвращения проникновения подобных программ;
    3) необходимо устанавливать и регулярно обновлять антивирусное ПО для обнаружения и сканирования компьютеров и носителей информации;
    4) необходимо регулярно проводить инвентаризацию ПО и данных в системах, поддерживающих критические процессы в организации;
    5) должны обеспечиваться обнаружение попыток и защита от несанкционированного изменения ПО и информации;
    - требования к резервированию и сохранению информации:
    1) необходимо регулярно выполнять резервное копирование важной служебной информации и ПО;
    2) необходимо обеспечить гарантированный уровень физической защиты и защиты от воздействий окружающей среды для резервных копий;
    3) необходимо регулярно проводить тестирование резервного оборудования;
    4) необходимо регулярно актуализировать и тестировать процедуры восстановления для обеспечения эффективности их выполнения;
    5) необходимо осуществлять физический контроль и безопасное хранение носителей информации (в бумажном или цифровом виде) с учетом максимальной категории безопасности информации, записанной на носителе;
    6) при сохранении информации должны выбираться такие методы ее архивирования, которые позволили бы ее восстановить в случае необходимости, с учетом изменения применяемых программно-аппаратных средств;
    7) при сохранении информации должны быть учтены все юридические аспекты, связанные с правами собственника информации, использовавшейся в ИС;
    8) должны быть идентифицированы места резервного хранения информации и решены административные вопросы хранения резервных копий информации;
    9) места резервного хранения информации должны быть пространственно (географически) отделены от основных мест хранения информации, чтобы не подвергаться тем же самым опасностям;
    10) место резервного хранения информации должно быть сконфигурировано таким образом, чтобы обеспечить своевременное и эффективное выполнение операций восстановления;
    11) должны быть определены потенциальные проблемы доступности мест резервного хранения информации, в случае сбоя или аварии и определены конкретные действия по восстановлению доступности;
    - требования к безопасности носителей информации:
    1) необходимо наличие процедур по использованию сменных носителей информации (лент, дисков, кассет, а также печатных отчетов);
    2) все носители информации должны храниться в надежном, безопасном месте;
    3) действия по удалению информации с носителей информации должны контролироваться, документироваться и проверяться;
    4) необходимо физически разрушать или перезаписывать безопасным образом носители данных, содержащие важную информацию, а не использовать стандартные функции удаления;
    5) необходимо проверять на предмет удаления всех важных данных и лицензионного ПО все компоненты оборудования, содержащего носители данных (например, встроенные жесткие диски);
    6) процедуры удаления информации с носителей информации должны периодически анализироваться на предмет их корректности и эффективности;
    7) необходимо осуществлять маркирование всех носителей информации, и ограничивать доступ с целью идентификации неавторизованного персонала;
    8) к съемным носителям информации должны быть прикреплены внешние метки, содержащие информацию установленного состава;
    9) должен быть составлен список носителей информации, к которым были прикреплены внешние метки;
    10) необходимо обеспечить формализованную регистрацию авторизованных получателей данных;
    11) при передаче цифрового носителя информации для повторного использования должна быть осуществлена процедура его очистки, чтобы исключить возможность несанкционированного получения доступа к хранимой (хранившейся) на носителе информации и ее использования неуполномоченными на это лицами;
    12) следует осуществлять контроль транспортировки носителя информации, чтобы его могло получить только уполномоченное на это лицо;
    - требования по доступу к носителям секретной информации – доступ к носителям секретной информации должен предоставляться только уполномоченным на это лицам в соответствии с грифами секретности, согласно Закону Республики Молдова «О государственной тайне» № 245 от 27.11.2008 г.;
    - требования к управлению сетевыми службами:
    1) необходимо распределять ответственность и устанавливать процедуры и обязанности за поддержание сетевых ресурсов и компьютерных операций;
    2) необходимо внедрять специальные средства контроля для обеспечения конфиденциальности и целостности данных, проходящих по общедоступным сетям, а также для защиты подключенных систем;
    - требования к обмену данными:
    1) должны быть определены процедуры и мероприятия по защите информации и носителей при их передаче;
    2) при определении требований безопасности должна учитываться степень важности информации, являющейся предметом обмена;
    3) необходимо обеспечить защиту обмена данными через электронную почту и транзакции в режиме он-лайн посредством общедоступных сетей, в частности, Интернет;
    4) ПО, данные и другую информацию, требующую высокого уровня целостности, доступ к которой осуществляется через системы публичного доступа, необходимо защищать средствами криптографической защиты информации, например, посредством цифровой подписи;
    5) требуется обеспечить защиту процесса обмена информацией посредством речевых, факсимильных и видео средств коммуникаций.
    5.8. Контроль доступа
    Для обеспечения санкционированного доступа к активам и процессам организации необходимо осуществлять контроль доступа с учетом внутренних требований организации и требований безопасности.
    Все требования к контролю доступа должны быть отражены в политиках в отношении распространения и авторизации информации.
    5.8.1. Требования к логическому доступу
    Для обеспечения доступа к информации лишь авторизованным пользователям необходимо осуществлять контроль логического доступа.
    К контролю логического доступа должны предъявляться следующие требования:
    - правила контроля доступа и права каждого пользователя или группы пользователей должны однозначно определяться политикой безопасности;
    - классификация информации применительно к различным системам и сетям должна быть согласована с политикой по контролю доступа;
    - должны быть определены стандартные профили доступа пользователей для типовых обязанностей и функций;
    - установление правил должно основываться на предпосылке «все должно быть в общем случае запрещено, пока явно не разрешено».
    5.8.2. Требования к контролю доступа пользователей
    Для предотвращения неавторизованного доступа к активам необходимо осуществлять контроль над предоставлением прав доступа к активам организации.
    Тщательный подход к предоставлению доступа пользователям к активам организации должен позволить получить жесткий контроль доступа и определить все возможные нарушения безопасности.
    Контроль доступа пользователей должен включать:
    - требования по управлению учетными записями:
    1) должно осуществляться управление учетными записями, включая создание, активацию, модификацию, пересмотр с установленной периодичностью, отключение и удаление учетных записей;
    2) должны использоваться автоматизированные средства поддержки управления учетными записями;
    3) действие временных учетных записей должно автоматически прекращаться по окончании установленного периода времени (для каждого типа учетной записи);
    4) должно осуществляться автоматическое отключение неактивных учетных записей после установленного периода времени;
    5) должны использоваться автоматизированные средства регистрации (аудита) и оповещения о создании, модификации, отключении, прекращении действия учетной записи;
    - требования к управлению привилегиями:
    1) предоставление привилегий должно контролироваться посредством процесса авторизации;
    2) доступ к функциям безопасности, реализованным в программном, аппаратном и программно-аппаратном обеспечении, и их данным должен предоставляться только уполномоченным на это лицам, например, администраторам безопасности;
    3) привилегии должны предоставляться только тем сотрудникам, которым это необходимо для работы и только на время ее выполнения;
    4) необходимо обеспечивать процесс авторизации и регистрации всех предоставленных привилегий;
    5) привилегии не должны предоставляться до завершения процесса авторизации;
    6) периодически должно осуществлять формализованный процесс пересмотра прав доступа пользователей (рекомендуется один раз в 6 месяцев или после любых изменений);
    - требования к контролю паролей:
    1) все пользователи должны подписать документ о необходимости соблюдения полной конфиденциальности личных паролей;
    2) пароли никогда не должны храниться в незащищенной форме.
    5.8.3. Требования к обязанностям пользователей
    Для предотвращения неавторизованного доступа пользователей к информации необходимо, чтобы пользователи были осведомлены о своих обязанностях по использованию эффективных мероприятий по управлению доступом.
    Обязанностями пользователей в отношении контроля доступа являются:
    - пользователи должны соблюдать определенные правила обеспечения безопасности при выборе и использовании паролей;
    - все пользователи должны быть осведомлены о необходимости:
    1) сохранения конфиденциальности паролей;
    2) запрещения записи паролей на бумаге, если только не обеспечено безопасное их хранение;
    3) изменения паролей всякий раз, при наличии любого признака возможной компрометации системы или пароля;
    4) выбора качественных паролей с минимальной длиной в шесть знаков;
    5) изменения паролей через определенные интервалы времени или после определенного числа доступов и исключения повторного или цикличного использования старых паролей;
    6) пароли для привилегированных учетных записей должны менять чаще, чем обычные пароли;
    - пользователи должны обеспечивать соответствующую защиту оборудования, оставленного без присмотра, выполняя следующие требования:
    1) активные сеансы по окончании работы должны быть завершены, если отсутствует механизм блокировки сеанса;
    2) должно быть ограничено число параллельных сеансов для каждого пользователя;
    3) должно осуществляться автоматическое завершение сеанса после установленного периода неактивности.
    5.8.4. Требования к контролю сетевого доступа
    Для защиты сетевых сервисов необходимо осуществлять контроль доступа, как к внутренним, так и к внешним сетевым сервисам.
    Требования к контролю сетевого доступа должны включать:
    - пользователям необходимо обеспечивать доступ только к тем сервисам, в которых они нуждаются для выполнения своих обязанностей и в которых они авторизованы;
    - должны быть определены:
    1) сети и сетевые услуги, к которым разрешен доступ;
    2) процедуры авторизации для определения кому, к каким сетям и сетевым сервисам разрешен доступ;
    3) мероприятия и процедуры по защите от несанкционированного подключения к сетевым сервисам;
    - необходимо ограничивать варианты маршрутизации в каждой точке сети;
    - требования к удаленному доступу:
    1) все способы удаленного доступа к активам (такие как, модемная связь, Интернет) должны документироваться, подвергаться мониторингу и контролю;
    2) каждый используемый способ удаленного доступа должен быть санкционирован соответствующими должностными лицами и разрешен только тем пользователям, которым он необходим для выполнения установленных задач;
    3) для облегчения мониторинга и контроля удаленного доступа должны использоваться соответствующие автоматизированные средства;
    4) должно быть реализовано централизованное управление удаленным доступом к ИС;
    - требования по управлению доступом для портативных и мобильных устройств:
    1) должны быть установлены ограничения и разработаны руководства по использованию портативных и мобильных устройств;
    2) доступ к ИС с использованием портативных и мобильных устройств должен документироваться, подвергаться мониторингу и контролю;
    3) использование портативных и мобильных устройств должно быть санкционировано соответствующими должностными лицами;
    4) должны использоваться сменные жесткие диски или другие способы и средства защиты информации, находящейся в портативных и мобильных устройствах;
    - требования по ограничению беспроводных подключений:
    1) должны быть установлены ограничения и разработаны руководства по использованию беспроводных технологий;
    2) беспроводный доступ к ИС должен документироваться, подвергаться мониторингу и контролю;
    3) беспроводный доступ к ИС должен быть разрешен только при применении средств криптографической защиты информации;
    4) использование беспроводных технологий должно быть санкционировано соответствующими должностными лицами.
    5.8.5. Требования доступа к операционным системам
    Для предотвращения неавторизованного доступа к компьютерам на уровне операционной системы необходимо использовать средства обеспечения безопасности, которые должны обеспечивать:
    - идентификацию и верификацию компьютера пользователя, терминала и местоположения каждого авторизованного пользователя;
    - регистрацию успешных и неудавшихся доступов к системе;
    - аутентификацию соответствующего уровня.
    Требования доступа к операционным системам должны включать:
    - возможность использования автоматической идентификации терминала;
    - доступ к информационным сервисам должен быть обеспечен путем использования безопасной процедуры входа в систему;
    - доступ к командам операционной системы должен быть запрещен пользователям, не имеющим прав системного администрирования;
    - должно ограничиваться число разрешенных неудачных попыток доступа (рекомендуется три попытки);
    - при превышении допустимого числа неудачных попыток доступа должно осуществляться блокирование терминала и/или учетной записи на определенный период времени или выполняться другие действия, препятствующие или существенно затрудняющие доступ со стороны потенциальных нарушителей;
    - должно быть подтверждение информации о регистрации только по завершении ввода всех входных данных;
    - необходимо ограничивать максимальное и минимальное время, разрешенное для процедуры входа в систему;
    - информация в отношении успешно завершенной регистрации должна постоянно фиксироваться;
    - использование системных утилит должно быть ограничено и постоянно контролироваться.
    5.8.6. Требования контроля доступа к приложениям
    Для предотвращения неавторизованного доступа к данным ИС необходимо применять меры обеспечения безопасности для ограничения доступа к прикладным системам.
    Требования контроля доступа к приложениям должны включать:
    - обеспечение доступа пользователям приложений к информации и функциям этих приложений в соответствии с политикой контроля доступа, основанной на требованиях к отдельным приложениям;
    - ограничение предоставления пользователям информации о данных и функциях приложений, к которым они не авторизованы на доступ;
    - системы, обрабатывающие важную информацию, должны быть обеспечены выделенной вычислительной средой со специальными условиями эксплуатации.
    5.8.7. Требования к мониторингу доступа
    Для обнаружения неавторизованных действий или отклонений от требований политики контроля доступа необходимо проводить мониторинг системы.
    Требованиями к мониторингу доступа являются:
    - создание журналов аудита и их хранение в течение согласованного периода времени, в которых должны вестись записи инцидентов нарушения безопасности и другие связанные с безопасностью события;
    - записи аудита должны включать:
    1) идентификатор пользователей;
    2) даты и время входа и выхода;
    3) идентификатор терминала или его местоположение;
    4) записи успешных и отклоненных попыток доступа к системе;
    5) записи успешных и отклоненных попыток доступа к данным и другим активам;
    - определение процедуры мониторинга использования средств обработки информации, и анализа их результатов;
    - уровень мониторинга конкретных средств обработки информации должен определяться на основе оценки рисков.
    5.9. Разработка и обслуживание информационных систем
    При разработке и обслуживанию ИС требуется использовать специальные методы, учитывающие критерии степени защиты, гибкости и стоимости, и обеспечивающие следующее:
    - проверка подлинности – использование методов строгой проверки, политик паролей, политик блокировки учетных записей и шифрования;
    - единая система авторизации – должна основываться на модели разрешений и обеспечивать высокую степень детализации контроля доступа;
    - разграничение прав доступа – политика, позволяющая управлять доступом к защищенным информационным ресурсам, системам и операциям;
    - предотвращение чтения сообщений посторонними лицами;
    - защита трафика данных от его анализа посторонними;
    - обнаружение изменений потоков сообщений;
    - определение искажений данных.
    Требования к разработке и обслуживанию ИС включают:
    - требования к архитектуре безопасности:
    1) должны быть определены средства безопасности, посредством которых будет обеспечиваться безопасность предоставляемых публичных услуг;
    2) необходимо применять протоколы обеспечения аутентичности и конфиденциальности в двух режимах: транспортном (защита только содержимого пакетов и некоторых полей заголовков) и туннельном (защита всего пакета);
    3) необходимо использовать механизмы управления средствами криптографической защиты информации (алгоритмы шифрования, контроля целостности и аутентичности);
    - требования безопасности в прикладных системах:
    1) должны осуществляться контроль и учет установки и удаления программных, аппаратных и программно-аппаратных средств систем;
    2) необходимо проводить проверку корректности ввода данных для обеспечения уверенности в их соответствии исходным данным;
    3) необходимо проводить контроль обработки данных в системах;
    4) для приложений, где должна быть обеспечена защита целостности содержания сообщений, необходимо использовать аутентификацию сообщений;
    5) следует проводить тестирование по безопасности всех используемых систем;
    6) должна быть также проведена независимая проверка функционирования систем;
    - требования к контролю изменений:
    1) следует строго контролировать внедрение изменений;
    2) программистам, отвечающим за поддержку, требуется предоставлять доступ только к тем частям системы, которые необходимы для их работы;
    3) следует обеспечить протоколирование согласованных уровней авторизации;
    4) необходимо проводить контроль версий для всех обновлений ПО;
    5) в журналах аудита должны регистрироваться все запросы на изменение;
    6) следует проводить анализ средств контроля приложений и процедур целостности для гарантии, что они не были скомпрометированы изменениями в операционной системе;
    7) необходимо обеспечить своевременное поступление уведомлений об изменениях в операционной системе;
    8) требуется избегать модификаций пакетов программ;
    - требования по применению средств криптографической защиты информации:
    1) необходимо определить методику использования криптографических средств в организации, включая общие принципы и методы восстановления зашифрованной информации в случае потери, компрометации или повреждения ключей;
    2) должны быть определены соответствующие уровни криптографической защиты для различных данных;
    3) для обеспечения защиты конфиденциальной или критичной информации необходимо применять криптографический метод шифрования, принимая во внимание тип и качество используемого алгоритма шифрования, а также длину криптографических ключей;
    4) для обеспечения защиты аутентификации и целостности электронных документов необходимо применять цифровые подписи;
    5) при использовании цифровых подписей необходимо учитывать требования действующего законодательства, определяющие условия, при которых цифровая подпись имеет юридическую силу;
    6) необходимо защищать криптографические ключи от изменения и разрушения, а секретные и личные ключи - от неавторизованного раскрытия.
    5.10. Управление непрерывностью деятельности
    Непрерывность деятельности организации необходимо обеспечивать с целью минимизации отрицательных последствий, вызванных бедствиями и нарушениями безопасности, до приемлемого уровня с помощью комбинирования профилактических и восстановительных мероприятий по управлению безопасностью.
    Требования к управлению непрерывности должны включать:
    - формирование и документирование стратегии обеспечения непрерывности, а также планов обеспечения непрерывности и восстановления деятельности;
    - использование адекватных систем резервирования и восстановления;
    - требования к планам непрерывности и восстановления деятельности:
    1) планы должны включать определение ответственных лиц и выполняемые ими действия при восстановлении ИС предоставления публичных услуг после сбоя или отказа;
    2) планы должны быть рассмотрены соответствующими должностными лицами, утверждены, размножены в необходимом количестве и направлены лицам, ответственным за действия в непредвиденных ситуациях;
    3) планы должны периодически пересматриваться и обновляться с учетом изменений или проблем, возникших в результате проверки или реализации плана;
    4) персонал должен пройти подготовку (с установленной периодичностью – переподготовку) по вопросам его роли, ответственности и обязанностей при осуществлении действий в непредвиденных ситуациях;
    5) в процессе подготовки персонала должны моделироваться соответствующие события, что поможет в будущем персоналу эффективно выполнить требуемые от него действия при возникновении кризисных ситуаций;
6) должны использоваться автоматизированные средства для того, чтобы обеспечить более полную и реалистичную среду обучения;
    - требования к проверке планов непрерывности и восстановления деятельности:
    1) должно осуществляться периодическое тестирование планов с целью оценки их эффективности и готовности персонала к выполнению действий, предписанных планом;
    2) соответствующие должностные лица должны изучить результаты тестирования планов и при необходимости инициировать их корректировку;
    3) должны использоваться автоматизированные средства для более тщательного и эффективного тестирования действий по обеспечению непрерывности и восстановлению деятельности;
    - требования к резервным местам обработки информации:
    1) должны быть определены резервные места обработки информации и решены административные вопросы обработки информации для критически важных задач до восстановления возможностей по обработке информации;
    2) резервные места обработки информации должны быть пространственно (географически) отделены от основных мест обработки информации, чтобы не подвергаться тем же самым опасностям;
    3) должны быть определены потенциальные проблемы доступности резервных мест обработки информации в случае сбоя или аварии и выделены конкретные действия по восстановлению доступности;
    4) при использовании резервных мест обработки информации должны учитываться установленные приоритеты обслуживания;
    5) резервное место обработки информации должно быть сконфигурировано таким образом, чтобы обеспечить минимально требуемые эксплуатационные возможности;
    - требования к резервированию телекоммуникационных сервисов:
    1) должны быть идентифицированы основные и резервные телекоммуникационные сервисы и решены административные вопросы использования резервных телекоммуникационных сервисов для критически важных задач до восстановления доступности основных;
    2) при использовании основных и резервных телекоммуникационных сервисов должны учитываться установленные приоритеты обслуживания;
    3) поставщики основных и резервных телекоммуникационных сервисов должны быть соответствующим образом отделены друг от друга, чтобы не подвергаться одним и тем же самым опасностям;
    4) поставщики основных и резервных телекоммуникационных сервисов должны иметь соответствующие планы действий в непредвиденных ситуациях;
    - требования к восстановлению системы:
    1) должны использоваться механизмы и поддерживающие их процедуры, необходимые для восстановления системы после сбоя или отказа;
    2) восстановление системы после сбоя или отказа должно использоваться как часть проверки плана действий в непредвиденных ситуациях.
    5.11. Соответствие требованиям
    Для предотвращения любых нарушений норм действующего законодательства, обязательных предписаний и регулирующих требований или договорных обязательств, а также требований безопасности необходимо проводить контроль соответствия, в качестве мониторинга и аудита безопасности.
    5.11.1 Требования к мониторингу безопасности
    Мониторинг безопасности должен обеспечивать постоянный контроль над поддержанием требуемого уровня безопасности при предоставлении публичных услуг.
    Мониторинг безопасности должен позволять выявлять изменения:
    - функций, реализуемых в ходе процесса предоставления услуг - мониторинг функций должен быть направлен на выявление необходимости изменения категории активов в связи с изменением возможного ущерба от нарушения безопасности;
    - активов - мониторинг активов должен быть направлен на выявление изменений в информации, аппаратном и программном обеспечении, которые могут явиться причиной изменения состава уязвимостей и угроз нарушения безопасности;
    - угроз и уязвимостей - мониторинг уязвимостей и угроз безопасности должен быть направлен на своевременное выявление новых уязвимостей и угроз, которые могут увеличить риск нарушения безопасности при предоставлении услуг;
    - мер и средств обеспечения безопасности - мониторинг мер и средств обеспечения безопасности должен быть направлен на контроль поддержания их эффективности в противодействии установленным и выявляемым уязвимостям и угрозам.
    Мониторинг безопасности в работе предоставления услуг должен включать:
    - текущий контроль состояния безопасности - должен обеспечивать уверенность, что меры и средства обеспечения безопасности действуют, не скомпрометированы и безопасность системы предоставления публичных услуг не нарушена. С этой целью должны осуществляться следующие действия:
    1) контроль реализации постоянно действующих мер обеспечения безопасности;
    2) контроль работоспособности средств обеспечения безопасности;
    3) контроль целостности информационных ресурсов и систем;
    4) обнаружение и ликвидация вторжений (нарушений прав доступа, вирусных атак, спама), при этом все обнаруженные нарушения безопасности в ходе предоставления публичных услуг должны фиксироваться, расследоваться и незамедлительно ликвидироваться посредством различных мер и средств защиты информации;
    - оценка безопасности - должна обеспечивать уверенность в соответствии системы предоставления услуг установленным требованиям безопасности и политике безопасности. Оценка безопасности должна проводиться периодически, в соответствии со сроками, установленными в политике безопасности, но не реже чем один раз в год, а также при существенных изменениях в активах, угрозах безопасности и политике безопасности. При оценке безопасности процесса предоставления публичных услуг должны оцениваться:
    1) соответствие мер и средств обеспечения безопасности требованиям, определенным в политике безопасности;
    2) правильность применения мер и средств обеспечения безопасности в соответствии с политикой безопасности;
    3) правильность действий по устранению последствий инцидентов нарушения безопасности и нейтрализации уязвимостей.
    Для получения данных о состоянии безопасности системы предоставления услуг должны использоваться:
    - анализ документов по учету применения мер и средств обеспечения безопасности;
    - опросы персонала, участвующих в процессе предоставлении публичных услуг;
    - анализ эффективности мер и средств обеспечения безопасности в противодействии имевшим место инцидентам нарушения безопасности;
    - проверки и испытания мер и средств обеспечения безопасности на соответствие требованиям безопасности;
    - испытания на проникновение для оценки возможности использования уязвимостей для нарушения безопасности;
    - специализированные аппаратные и программные средства для контроля состояния средств обеспечения безопасности и выявления уязвимостей;
    - данные предыдущих оценок безопасности.
    По результатам проведения оценки, в случае выявления недостатков в обеспечении безопасности системы предоставления услуг должны осуществляться, в зависимости от значимости недостатков, следующие действия:
    - уточнение мер и средств обеспечения безопасности;
    - корректировка политики безопасности;
    - оценка риска и корректировка требований безопасности при оказании услуг.
    5.11.2. Требования к аудиту безопасности
    Аудит безопасности представляет собой системный процесс получения и оценки объективных данных о текущем состоянии ИС с точки зрения безопасности, действиях и событиях, происходящих в ней, устанавливающий степень их соответствия определенному уровню безопасности.
    Цель аудита безопасности для организации, предоставляющей публичные услуги:
    - получение наиболее полной и объективной оценки защищенности;
    - локализация имеющихся проблем и разработка эффективной системы обеспечения безопасности организации.
    При проведении аудита безопасности в организации, предоставляющей публичные услуги, могут быть использованы различные виды аудита в области безопасности информации, которые отличаются только по цели, а методика их проведения идентична:
    - первоначальное обследование (первичный аудит) – результатом должна быть концепция безопасности организации, которая позволит ей выстроить грамотную защиту информации;
    - предпроектное обследование (технический аудит) – результатом должен быть набор требований к системе обеспечения безопасности;
    - аттестация объекта – результатом должен быть документ, аттестат соответствия, удостоверяющий, что объект соответствует стандарту и действующему национальному законодательству, или заключение эксперта;
    - контрольное обследование – плановое контрольное обследование с целью проверки соблюдения правил по обеспечению безопасности.
    Процесс проведения аудита безопасности в организации должен включать следующие этапы:
    - постановка задачи и уточнение границ работ – должен быть проведен предварительный анализ и организационные мероприятия по подготовке проведения аудита безопасности;
    - сбор и анализ информации – должна собираться информация и даваться оценка следующих мер и средств: организационных мер в области безопасности, программно-технических средств защиты информации, обеспечения физической безопасности;
    - проведение анализа рисков и оценки соответствия системы предъявляемым требованиям и стандартам – должны быть проведены классификация активов, анализ уязвимостей, составление модели потенциального злоумышленника, оценка рисков нарушения безопасности;
    - разработка рекомендаций и предложений по поводу мер по повышению безопасности:
    1) рекомендации по совершенствованию системы защиты информации, применение которых позволит минимизировать риски;
    2) приложения со списком конкретных уязвимостей;
    3) итоговый отчет, содержащий оценку текущего уровня безопасности;
    4) информация об обнаруженных ошибках;
    5) анализ соответствующих рисков и рекомендации по их устранению.
    Аудит безопасности в организации позволяет получить объективную и независимую оценку текущего состояния защищенности активов, рассчитать риски, учитывающие вероятность реализации угроз, а также их возможный ущерб для ИС.
    Требования к аудиту безопасности при предоставлении публичных услуг должны включать:
    - разработку, документирование и периодическое обновление политики аудита и обеспечения подотчетности (политика регистрации и учета), а также процедуры и меры, связанные с реализацией политики аудита и обеспечения подотчетности;
    - должна осуществляться генерация записей аудита для событий, определенных в перечне событий, подвергаемых аудиту;
    - должны быть предоставлены метки времени для использования при генерации записей аудита;
    - в каждой записи аудита должна регистрироваться следующая информация: дата и время события, тип события, идентификатор субъекта и результат события (успешный или неуспешный), а также дополнительная информация;
    - каждое событие, потенциально подвергаемое аудиту, должно быть ассоциировано с идентификатором пользователя, который был инициатором данного события;
    - у авторизированного администратора должна быть возможность читать всю информацию аудита из записей аудита, то есть должен быть доступ к журналу аудита;
    - у пользователей доступ к чтению записей аудита должен быть запрещен, за исключением пользователей, которым явно предоставлен доступ для чтения;
    - должна быть предоставлена возможность выполнить поиск, сортировку и упорядочение данных аудита, основанных на идентификаторе пользователя и назначении;
    - должна быть возможность включения событий, потенциально подвергаемых аудиту, в совокупность событий, подвергающихся аудиту, или к их исключению из этой совокупности по идентификатору пользователя или назначению;
    - хранимые записи аудита должны быть защищены от несанкционированного удаления, должны быть способны предотвращать модификации записей аудита;
    - должен быть установлен период времени, в течение которого данные аудита должны храниться для обеспечения расследований инцидентов безопасности, а также выполнения нормативных требований по хранению данных аудита;
    - предупреждения об опасности должны генерироваться авторизированному администратору, если журнал аудита превышает принятые ограничения;
    - должна быть возможность предотвращать потерю подвергающихся аудиту событий при переполнении журнала аудита;
    - требования к объему памяти, выделяемому для хранения данных аудита:
    1) должен быть выделен объем памяти, достаточный для хранения данных аудита;
    2) должны быть сделаны необходимые настройки для того, чтобы объем данных аудита не превысил выделенного объема памяти;
    - требования к обработке данных аудита:
    1) при сбоях аудита или заполнении всего объема памяти, выделенного для хранения данных аудита, должно выдаваться уведомление соответствующим должностным лицам и предприниматься установленные действия, такие как завершение работы системы, игнорирование событий, подвергающихся аудиту, запись поверх самых старых хранимых записей аудита;     2) при заполнении установленного процента или количества объема памяти, выделенного для хранения данных аудита, должно выдаваться соответствующее предупреждение;
    - требования к мониторингу, анализу и генерации отчетов о результатах аудита:
    1) должны осуществляться регулярный просмотр и анализ записей аудита с целью обнаружения необычной или подозрительной активности, составление соответствующих отчетов для должностных лиц и предприниматься установленные для этих случаев действия;
    2) должны использоваться автоматизированные средства, позволяющие объединить мониторинг, анализ и генерацию отчетов о результатах аудита в единый процесс анализа подозрительной активности и реагирования на потенциальные нарушения;
    - требования к сокращению объема данных аудита:
    1) должны быть реализованы возможности по сокращению объема данных аудита и генерации соответствующих отчетов;
    2) должна быть реализована возможность автоматической обработки записей аудита для определенных типов событий;
    - должна быть обеспечена защита данных аудита и средств ведения аудита от несанкционированного доступа;
    - должна быть реализована возможность обеспечения неотказуемости (определить, выполнял ли конкретный пользователь данное действие).
    5.11.3. Требования к государственному контролю
    Кроме аудита безопасности должен осуществляться государственный контроль соблюдения требований безопасности ИТ в организации, осуществляющей процесс предоставления публичных услуг, который должен осуществляться уполномоченными органами в целях предупреждения или выявления нарушений требований по безопасности. Органы, уполномоченные провести государственный контроль, вправе:
    - требовать от организации, осуществляющей предоставление публичных услуг, документы, удостоверяющие соответствие процесса эксплуатации ИС требованиям безопасности;
    - выдавать предписания об устранении нарушений обязательных требований по безопасности в срок, установленный с учетом характера нарушения;
    - по решению суда принимать мотивированные решения о полном или частичном приостановлении процесса эксплуатации ИС предоставления услуг, если иными мерами невозможно устранить нарушение требований безопасности;
    - приостанавливать или прекращать действие сертификата соответствия;
    - принимать иные предусмотренные законодательством меры в целях недопущения нарушения требований безопасности.
    Органы, уполномоченные провести государственный контроль, обязаны:
    - проводить в ходе мероприятий по государственному контролю разъяснительную работу по применению требований законодательства в области безопасности ИТ;
    - соблюдать установленный порядок защиты информации в зависимости от степени ее критичности и важности;
    - соблюдать установленный порядок осуществления мероприятий по государственному контролю и оформления результатов таких мероприятий;
    - принимать на основании результатов мероприятий по государственному контролю меры по устранению последствий нарушений требований по безопасности и правил оценки соответствия.
    5.12. Управление информационной безопасностью при привлечении сторонних организаций
    В процесс предоставления публичных услуг могут быть вовлечены:
    - сотрудники сторонних организаций, осуществляющих обслуживание программно-аппаратного комплекса;
    - партнеры, которым может потребоваться обмен информацией или доступ к активам организации.
    При привлечении третьих сторон должны соблюдаться следующие требования:
    - необходимо выявить риски, связанные с активами и процессами, вовлекающими внешние стороны;
    - перед предоставлением доступа сотрудникам сторонних организаций к активам и процессам должны быть реализованы надлежащие меры и средства обеспечения безопасности;
    - доступ третьих сторон к средствам обработки информации организации должен контролироваться;
    - контракты, разрешающие доступ сторонним организациям, должны включать процедуру определения прав и условий доступа других участников;
    - представители сторонних организаций должны подписывать соглашение о соблюдении конфиденциальности до того, как им будет предоставлен доступ к активам или средствам обработки информации;
    - в соглашениях о конфиденциальности должна быть определена ответственность сторон, в соответствии с требованиями безопасности и действующего законодательства;
    - в контракте с третьей стороной особое внимание необходимо уделить следующим вопросам:
    1) уровень предоставляемых услуг;
    2) юридические аспекты, соответствие законодательным требованиям, например, обеспечение сохранности персональных данных;
    3) распределение ответственности, включая ответственность субподрядчиков третьей стороны;
    4) обеспечение конфиденциальности, целостности и доступности обрабатываемой, хранимой и передаваемой информации;
    5) все требования безопасности, связанные с доступом третьей стороны, включая меры и средства по обеспечению безопасности и контроля;
    6) сервисы и мероприятия, которые будут поддерживаться в случае возникновения чрезвычайных ситуаций;
    - необходимо гарантировать, что средства обеспечения безопасности, включенные в соглашение о предоставлении услуг сторонней организации, реализуются, эксплуатируются и поддерживаются сторонней организацией надлежащим образом;
    - услуги, отчеты и записи, предоставляемые сторонней организацией, должны постоянно контролироваться и анализироваться;
    - при разработке ПО с привлечением сторонних организаций необходимо применять следующие меры контроля:
    1) контроль наличия лицензионных соглашений и определенности в вопросах собственности на ПО и соблюдения прав интеллектуальной собственности;
    2) проверка действительности сертификации качества и правильности выполненных работ;
    3) контроль обеспечения прав доступа для аудита с целью проверки качества и точности выполненной работы;
    4) контроль над документированием требований к качеству программ в договорной форме;
    5) проверка процесса тестирования перед установкой ПО.

6. Системы обеспечения безопасности

    Обеспечение безопасности активов организации при предоставлении публичных услуг возлагается на системы обеспечения безопасности. Для достижения целей и решения задач обеспечения безопасности в ходе процесса предоставления публичных услуг как минимум должны применяться следующие три класса систем обеспечения безопасности:
    - опорные системы безопасности – системы, которые являются общими и лежат в основе реализации большинства остальных систем безопасности;
    - системы предотвращения нарушений безопасности – системы безопасности, ориентированные на предотвращение различного рода нарушений безопасности в ходе процесса предоставления услуг;
    - системы обнаружения нарушений и восстановления безопасности – данные системы безопасности должны быть направлены на решение задач выявления нарушений безопасности при предоставлении публичных услуг (до или после их осуществления) и восстановления системы предоставления услуг в безопасное состояние.
    6.1. Опорные системы безопасности
    Опорные системы безопасности должны выступать в роли основы, связующей среды для построения всех остальных систем безопасности. К данному классу относятся следующие системы безопасности:
    - система идентификации – для реализации большинства систем безопасности требуется однократная идентификация объектов и субъектов при предоставлении публичных услуг. Система идентификации должна обеспечивать возможность присвоения уникального идентификатора пользователям, процессам, ИС, информационным и иным ресурсам в ИС;
    - система криптографической защиты – данная система является обязательной для обеспечения безопасности процесса предоставления публичных услуг. Система криптографической защиты должна использовать специальные методы и средства (аппаратные, программные и аппаратно-программные средства) преобразования информации, используемые для защиты целостности и конфиденциальности информации и данных;
    - система управления безопасностью и администрирования. Система управления безопасностью представляет собой распространение и управление информацией, необходимой для работы систем и механизмов безопасности для обеспечения безопасности при предоставлении услуг. Система администрирования представляет собой процессы настройки параметров инсталляции и эксплуатации программного и аппаратного обеспечения систем безопасности при оказании услуг, а также учет вносимых изменений в эксплуатируемое оборудование.
    Должны быть определены обязанности по управлению оборудованием обработки информации и по работе с ним.
    Все опорные системы безопасности обеспечивают защищенность системы, которая представляет собой совокупность свойств системы, позволяющая доверять технической реализации системы для обеспечения безопасности. Примерами мер и средств защищенности системы являются:
    - защита информации от повторного использования;
    - минимизация прав доступа;
    - разделение процессов;
    - разделение ответственности;
    - модульность и этапы разработки;
    - минимизация круга осведомленных лиц.
    Требуется рассматривать не только качество реализованных средств защиты системы предоставления услуг, но и процедуры их разработки, способы достижения и решения технических задач.
    6.2. Системы предотвращения нарушений безопасности
    Системы предотвращения нарушений безопасности должны обеспечивать безопасность защищаемых объектов от воздействия, которое признано вторжением или нарушением безопасности.
    К данному классу должны быть отнесены следующие системы:
    - система защищенных телекоммуникаций (каналов связи). В системе предоставления публичных услуг обеспечение надежной защиты в большой степени зависит от защищенности каналов связи. Система защиты каналов связи должна обеспечивать целостность, конфиденциальность и доступность информации при ее передаче по каналам связи. Меры и средства обеспечения безопасности должны обеспечивать защиту от уничтожения, подстановки, модификации и повторной передачи данных и других видов злоумышленных действий;
    - система аутентификации является наиболее важной системой безопасности, особенно в системе предоставления публичных услуг. Система аутентификации представляет собой систему, выполняющую процедуру проверки подлинности субъекта, позволяющую достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом деле является именно тем субъектом, идентификатор которого он использует. Методы аутентификации должны применяться для пользователей всех категорий, в том числе к персоналу технической поддержки, операторам, администраторам сети, системным программистам, администраторам баз данных;
    - система авторизации представляет собой систему, направленную на предоставление (наделение) субъектам определенных полномочий относительно выполнения ими действий в ИС предоставления публичных услуг;
    - система управления доступом – система, определенная как «предотвращение неавторизованного использования активов, включая предотвращение использования активов недопустимым способом». Система должна быть применима к различным типам доступа к информационным ресурсам и системам, например, использование коммуникационных ресурсов, чтение, запись или удаление информационных ресурсов, использование ресурсов информационных систем по обработке данных. Политика управления доступом должна быть основой политики безопасности ИТ, в которой должны быть охвачены все стадии доступа пользователей: от начальной регистрации новых пользователей до заключительного лишения регистрации тех пользователей, которым больше не требуется доступ к ИС и услугам.
    Системы предотвращения нарушений безопасности при предоставлении публичных услуг должны обеспечивать конфиденциальность, целостность и доступность информации, а также неотказуемость и секретность транзакций.
    Неотказуемость (доказательство принадлежности) определяется как «предотвращение возможности отказа одним из реальных участников коммуникаций от факта его полного или частичного участия в передаче данных». Должны использоваться две формы неотказуемости: невозможность отказа от посылки сообщения (доказательство источника) и подтверждение (доказательство) получения сообщений. Неотказуемость необходима для предотвращения и обнаружения нарушений безопасности в ИС предоставления услуг. Меры и средства обеспечения неотказуемости должны предотвращать возможность отказа от выполненных действий.
    Секретность транзакций в ИС предоставления публичных услуг означает соблюдение требований по обеспечению секретности личности, использующей услуги и информационные ресурсы. Секретность представляет собой защиту от разглашения информации (данных) о личности пользователя, использующего информационные ресурсы и системы. Секретность транзакций должна обеспечивать защиту от потери неотказуемости путем анализа действий, операций, выполняемых пользователями в системе предоставления публичных услуг.
    6.3. Системы обнаружения нарушений и восстановления безопасности
    Системы обнаружения нарушений и восстановления безопасности должны включать услуги обнаружения нарушений безопасности, направленные на усиление услуг предотвращения, а также регулярное создание и тестирование резервных копий данных и ПО.
    Для обнаружения нарушений безопасности ИС предоставления публичных услуг должны использоваться следующие системы:
    - система аудита безопасности, направленная на обнаружение событий, оказывающих влияние на безопасность ИС, на обеспечение реагирования системы на выявленные вторжения, а также на обеспечение формирования необходимых данных для последующего восстановления ИС в безопасное состояние. В ходе аудита безопасности должны рассматриваться различные системы и механизмы безопасности, обеспечивающие защиту информации при предоставлении публичных услуг.
    Механизмы аудита должны решать следующие задачи:
    1) обеспечение подотчетности пользователей и администраторов, что является средством сдерживания попыток нарушения информационной безопасности. Одним из важных механизмов безопасности для обеспечения подотчетности являются механизмы идентификации и аутентификации, а также механизмы управления доступом для обеспечения конфиденциальности и целостности подотчетной информации;
    2) обеспечение возможности восстановления последовательности событий, что позволяет обнаружить слабости в защите информации, выявить виновника вторжения, оценить масштабы причиненного ущерба и вернуться к нормальной работе;
    3) предоставление информации для выявления и анализа проблем, через подготовку соответствующих отчетов;
    - система обнаружения происшествий и политика сдерживания. Система обнаружения происшествий должна быть направлена на обнаружение, как попыток нарушений безопасности, так и на регистрацию легитимной активности пользователей. Обнаружение должно быть локальным и/или дистанционным, и должно реализоваться через тревожную сигнализацию о происшествиях, регистрацию событий и восстановительные действия. Для сокращения действительных и потенциальных следствий инцидентов политика сдерживания потенциальных инцидентов должна включать сообщение об инциденте, ответные действия по минимизации рисков и их приоритеты;
    - система контроля целостности программных, аппаратных и информационных компонент ИС должна быть направлена на своевременное обнаружение нарушений целостности;
    - система восстановления безопасности должно выполнять функцию реакции ИС на нарушение безопасности. Система восстановления безопасности должна реализовываться через выполнение таких действий, как немедленное разъединение или прекращение работы, отказ субъекту в доступе, временное лишение субъекта прав, занесение субъекта в «черный список».

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

    При создании системы обеспечения безопасности необходимо как минимум основываться на профилях защиты, что позволит обеспечить надежную защиту всех активов и процессов организации.
    Профили защиты должны характеризовать отдельные меры и средства обеспечения безопасности, комбинации подобных мероприятий. В профилях защиты должны быть выделены следующие базовые меры и средства обеспечения безопасности:
    - идентификация и аутентификация;
    - управление доступом;
    - протоколирование и аудит;
    - шифрование;
    - контроль целостности;
    - экранирование;
    - анализ защищенности;
    - обеспечение неотказуемости;
    - обеспечение безопасного восстановления;
    - туннелирование.
    При создании комплексной системы информационной безопасности в ходе предоставления публичных услуг должны использоваться следующие профили защиты:
    - контролируемый доступ;
    - меточная защита;
    - операционные системы;
    - одноуровневые операционные системы;
    - многоуровневые операционные системы;
    - системы управления базами данных.
    Все требования профилей защиты должны подразделяться на следующие:
    - функциональные требования, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности системы предоставления публичных услуг и реализующим их механизмам;
    - требования доверия, которые соответствуют пассивному аспекту, предъявляются к технологии и процессу разработки и эксплуатации системы предоставления публичных услуг.
    Требования доверия безопасности должны охватывать весь жизненный цикл предоставления публичных услуг. Требования доверия предполагают выполнение следующих действий:
    - оценка заданий по безопасности и профилей защиты, ставшие источниками требований безопасности;
    - проверка процессов и процедур безопасности, их применение;
    - анализ документации;
    - верификация представленных доказательств;
    - анализ тестов и их результатов;
    - анализ уязвимостей;
    - проведение независимого тестирования.
    7.1. Профиль защиты «Контролируемый доступ»
    Профиль защиты «Контролируемый доступ» предназначен для формулирования требований к механизмам защиты, реализующим, в частности, дискреционный (избирательный) принцип контроля доступа. Профиль защиты с контролируемым доступом определяет набор функциональных требований и требований доверия для ИС предоставления публичных услуг. Контролируемый доступ поддерживает такое управление доступом, которое позволяет ограничивать действия отдельных пользователей и доступ к информационным ресурсам и системам.
    Целями безопасности профиля защиты «Контролируемый доступ» являются:
    - обеспечение доступа к информационным ресурсам и системам только авторизированным пользователям;
    - управление доступом к ресурсам для определения, какие ресурсы могут быть доступны пользователям;
    - протоколирование действий пользователей в ИС в ходе предоставления публичных услуг;
    - обеспечение не раскрытия любой информации, содержащейся в защищаемом ресурсе, при его перераспределении.
    Требования безопасности при предоставлении услуг профиля защиты «Контролируемый доступ» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности.
    7.1.1. Функциональные требования для профиля защиты «Контролируемый доступ»
    7.1.1.1. Требования к защите данных пользователя при предоставлении публичных услуг
    Требования к защите данных пользователя при предоставлении публичных услуг являются:
    - должна осуществляться политика дискреционного (избирательного) управления доступом для пользователей и всех операций между субъектами и объектами (определение границ управления);
    - требования к управлению доступом, основанным на атрибутах безопасности:
    1) должна быть возможность сопоставления разрешенных и запрещенных операций с идентификаторами одного или более пользователей;
    2) должна быть возможность использования разрешенных или запрещенных операций по умолчанию;
    3) для каждой операции должны быть заданы правила использования по умолчанию разрешающих атрибутов, определенных в атрибутах управления доступом объекта;
    4) должны явно разрешать или отказывать в доступе субъектов к объектам, основываясь на правилах;
    - должен выполняться пакет тестовых программ при первоначальном запуске, периодически во время нормального функционирования или по запросу авторизированного администратора для демонстрации правильности выполнения требований безопасности;
    - должен поддерживаться домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения неавторизированными субъектами;
    - должны предоставляться надежные метки времени для собственного использования, так как генерация записей аудита зависит от корректности внутреннего представления даты и времени;
    - должна быть обеспечена недоступность любого предыдущего информационного содержания ресурсов при распределении ресурса для всех объектов.
    7.1.1.2. Требования к управлению безопасностью при предоставлении публичных услуг
    Требования к управлению безопасностью при предоставлении публичных услуг являются:
    - возможность изменять права доступа должна быть ограничена так, чтобы пользователь, имеющий права доступа к информационному объекту, не имел возможность изменять эти права, пока не получит на это разрешение;
    - требования к управлению данными:
    1) должна существовать возможность создания, уничтожения и очистки журнала аудита только авторизированным администраторам;
    2) должна существовать возможность изменения или просмотра множества подвергающихся аудиту событий только авторизированным администраторам;
    3) должна существовать возможность инициализации и модификации атрибутов безопасности пользователя, кроме данных аутентификации, только авторизированным администраторам;
    4) должна существовать возможность инициализации и модификации данных аутентификации только авторизированным администраторам;
    - требования к ролям безопасности:
    1) должны поддерживаться следующие роли: авторизированный администратор; пользователи, уполномоченные политикой дискреционного управления доступом изменять атрибуты безопасности информационного объекта; пользователи, уполномоченные изменять собственные данные аутентификации;
    2) должна существовать возможность ассоциировать пользователей с ролями.
    7.1.2. Требования доверия безопасности для профиля защиты «Контролируемый доступ»
    7.1.2.1. Требования к документации и программному обеспечению
    Требования к документации и ПО, которые обеспечивают предоставление публичных услуг, должны включать:
    - требования к документации системы предоставления публичных услуг, которая должна:
    1) быть актуальна, соответствующим образом защищена и доступна для установленных категорий персонала;
    2) включать документацию, описывающую меры и средства обеспечения безопасности при оказании публичных услуг с подробностью, необходимой для их анализа и проверки;
    - требования к руководству администратора, которое должно содержать:
    1) описание функций администрирования и интерфейсов, доступных администратору;
    2) описание того, как управлять системой предоставления публичных услуг безопасным способом;
    3) предупреждения относительно функций и привилегий, которые следует контролировать в безопасной среде обработки информации;
    4) описание всех параметров безопасности, контролируемых администратором, указывая, при необходимости, безопасные значения параметров;
    5) описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией системы предоставления публичных услуг;
    6) описание возможных событий, относящихся к безопасности и связанных с выполнением обязательных функций администрирования;
    - требования к руководству пользователя, которое должно:
    1) содержать описание функций и интерфейсов, доступных пользователям;
    2) содержать описание применяемых и применения доступных пользователям средств обеспечения безопасности и контроля;
    3) предупреждения относительно доступных для пользователей функций и привилегий;
    4) четко представить все обязанности пользователя, необходимые для безопасной эксплуатации системы предоставления публичных услуг;
    - требования к установке ПО:
    1) эксплуатирующей организацией должны быть установлены и реализовываться четкие правила установки ПО пользователями;
    2) должны быть идентифицированы типы ПО, разрешенные и запрещенные для установки пользователями;
    - требования к использованию ПО:
    1) при использовании ПО и документации на него должны выполняться соглашения с производителем и требования действующего национального законодательства об авторском праве;
    2) эксплуатирующая организация должна иметь систему контроля копирования и распределения ПО и документации на него в соответствии с полученными лицензиями.
    7.2 Профиль защиты «Меточная защита»
    Профиль защиты «Меточная защита» предназначен для управления доступом, который позволяет ограничивать действия отдельных пользователей и доступом к информационным ресурсам и системам, и определяет набор функциональных требований и требований доверия для ИС предоставления публичных услуг.
    При «Меточной защите» должны применяться два класса механизмов управления доступом, которые позволяют индивидуальным пользователям определять, как информационные ресурсы и системы (например, файлы, каталоги) совместно используются под их управлением, и которые накладывают ограничения на совместное использование ресурсов и систем среди пользователей.
    Цели безопасности профиля защиты «Меточная защита» включает все цели профиля защиты «Контролируемый доступ», а также следующие цели:
    - предоставление всех необходимых функций и возможностей для поддержки авторизированных администраторов, которые являются ответственными за управление безопасностью при предоставлении публичных услуг;
    - проектирование и реализация таким образом, чтобы обеспечивалось осуществление политики безопасности организации в предопределенной среде с учетом требований к физической безопасности и требований к персоналу.
    Требования безопасности предоставления публичных услуг профиля защиты «Меточная защита» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности. Функциональные требования профиля защиты «Меточная защита» частично совпадают с требования профиля защиты «Контролируемый доступ», а требования доверия совпадают с профилем защиты «Контролируемый доступ».
    7.2.1. Функциональные требования для профиля защиты «Меточная защита»
    Функциональные требования профиля защиты «Меточная защита» совпадают с требования профиля защиты «Контролируемый доступ», которые должны быть дополнены:
    - требования к экспорту данных пользователя без атрибутов безопасности:
    1) должна осуществляться политика мандатного управления доступом при экспорте «непомеченных» данных пользователя;
    2) устройства, используемые для экспорта данных без атрибутов безопасности не должны использоваться для того, чтобы экспортировать данные с атрибутами безопасности;
    - требования к экспорту данных пользователя с атрибутами безопасности:
    1) при экспорте данных пользователя за пределы атрибуты безопасности должны однозначно ассоци-ироваться с экспортируемыми «помеченными» данными пользователя;
    2) устройства, используемые для экспорта данных с атрибутами безопасности, не могут использоваться для экспорта данных без атрибутов безопасности;
    - должна осуществляться политика мандатного управления доступом для субъектов и объектов, и всех операций среди субъектов и объектов;
    - требования к иерархическим атрибутам безопасности:
    1) должна осуществляться политика мандатного управления доступом, основанная на следующих типах атрибутов безопасности субъектов и информации: метка чувствительности субъекта и метка чувствительности объекта, содержащего информацию;
    2) информационный поток между управляемым субъектом и информацией должен быть разрешен: если метка чувствительности субъекта больше чем или равна метке чувствительности объекта, то поток информации от объекта к субъекту разрешается (операция чтения); если метка чувствительности объекта больше чем или равна метке чувствительности субъекта, то поток информации от субъекта к объекту разрешается (операция записи); если метка чувствительности субъекта A больше чем или равна метке чувствительности субъекта B, то поток информации от субъекта B к субъекту A разрешается;
    - требования к отмене прав доступа:
    1) должна существовать возможность немедленной отмены важных для безопасности полномочий;
    2) права доступа, ассоциированные с объектом, должны быть приведены в действие после того, как проверка доступа произведена;
    - кроме выше указанных ролей должны поддерживаться пользователи, уполномоченные политикой мандатного управления доступом изменять атрибуты безопасности информационного объекта.
    7.3. Профиль защиты «Операционные системы»
    Профиль защиты «Операционные системы» определяет требования безопасности для операционных систем общего назначения при предоставлении публичных услуг, обычно содержащих файловые системы, сервисы печати, сетевые сервисы, сервисы архивации данных и другие приложения, обеспечиваемые хостом (например, электронная почта, базы данных).     Операционные системы, отвечающие требованиям данного профиля, поддерживают среды, где может обрабатываться конфиденциальная информация. Профиль защиты «Операционные системы» обеспечивает дискреционное управление доступом, которое означает, что у субъекта с некоторым разрешением доступа есть возможность передать это разрешение любому другому субъекту.
    Управление доступом ко всем защищаемым данным и информационным ресурсам должен осуществляться на основе идентификатора. Для всех пользователей должны быть назначены уникальные идентификаторы. Этот идентификатор должен обеспечивать ответственность пользователя. Должна быть подтверждена подлинность заявленного идентификатора пользователя перед тем, как пользователю будет разрешено выполнять любые действия.
    Специфические особенности безопасности, требуемые для таких систем, должны включать:
    - идентификацию и аутентификацию: авторизированные пользователи должны быть идентифицированы и аутентифицированы перед доступом к информации, хранящейся в системе предоставления публичных услуг;
    - дискреционное управление доступом предоставляет возможность авторизированным пользователям определить защиту для файлов данных, которые они создают;
    - сервисы аудита, предоставляющие возможность уполномоченным администраторам, должны обнаруживать и анализировать потенциальные нарушения безопасности.
    Целями безопасности профиля защиты «Операционные системы» являются:
    - операционная система должна обеспечивать, чтобы только авторизированные пользователи получали доступ к ней и к информационным ресурсам, которыми она управляет;
    - система должна отображать информацию, связанную с предыдущими попытками установить сеанс;
    - операционная система должна предоставлять возможность обнаруживать и регистрировать значимые для безопасности события при предоставлении публичных услуг, ассоциированные с индивидуальными пользователями, должна предоставлять возможность защитить и выборочно просматривать информацию аудита, ассоциированную с индивидуальными пользователями;
    - операционная система должна управлять доступом к ресурсам, основанным на идентификаторах пользователей или групп пользователей;
    - операционная система должна предоставлять уполномоченным пользователям возможность определять, к каким информационным ресурсам какие пользователи или группы пользователей могут получить доступ;
    - операционная система должна быть поставлена и инсталлирована способом, который поддерживает безопасность системы предоставления публичных услуг;
    - операционная система должна предоставлять средства для защиты данных пользователя и ресурсов;
    - никакой пользователь не должен блокировать других пользователей при обращении их к информационным ресурсам;
    - операционная система должна подвергаться независимому тестированию, включающему сценарии тестирования и результаты;
    - операционная система должна верифицировать заявленный идентификатор пользователя;
    - в операционной системе пользователи должны идентифицироваться однократно.
    Требования безопасности при предоставлении публичных услуг профиля защиты «Операционные системы» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности.
    7.3.1. Функциональные требования для профиля защиты «Операционные системы»
    Функциональные требования профиля защиты «Операционные системы» совпадают с определенными требованиями профиля защиты «Меточная защита», которые должны быть дополнены:
    - должна существовать возможность определения режима выполнения, отключения, подключения, модификации режима выполнения функций, относящихся к выбору событий, подвергаемых аудиту;
    - должна существовать возможность защиты данных от раскрытия и модификации при их передаче между разделенными частями ИС;
    - должна обеспечиваться согласованность данных при дублировании их в различных частях ИС предоставления публичных услуг;
    - требования к самотестированию:
    1) должен выполняться пакет программ самотестирования при запуске или по запросу авторизированного администратора для демонстрации правильного выполнения;
    2) должна существовать возможность у авторизированных администраторов верифицировать целостность данных и хранимого выполняемого кода;
    - должны реализовать максимальные квоты следующих ресурсов: процент памяти дискового пространства и процент системной памяти, которые индивидуальные пользователи могут использовать в любое заданное время;
    - должен предоставляться маршрут связи между собой и локальными пользователями, который логически отличим от других маршрутов связи, и обеспечивает уверенную идентификацию его конечных сторон, а также защиту передаваемых данных от модификации или раскрытия.
    7.3.2. Требования доверия безопасности для профиля защиты «Операционные системы»
    Требования доверия безопасности профиля защиты «Операционные системы» совпадают с требованиями такого рода профиля защиты «Меточная защита», которые должны быть дополнены следующими:
    - требования к тестированию:
    1) разработчик должен протестировать функции ИС предоставления публичных услуг и документировать результаты;
    2) тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования;
    3) планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования;
    4) результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности была выполнена успешно;
    - должны быть идентифицированы все возможные режимы эксплуатации системы предоставления публичных услуг, включая действия после сбоя или ошибки в работе, их последствия и значение для обеспечения безопасной эксплуатации; документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в системе предоставления услуг.
    Примеры угроз для профиля защиты «Операционные системы» представлены в приложении 1.
    7.4. Профиль защиты «Одноуровневые операционные системы»
    Операционные системы, отвечающие требованиям данного профиля, поддерживают среды, где могут обрабатываться одноуровневые данные при предоставлении публичных услуг. Данный профиль должен обеспечивать дискреционное управление доступом и предоставлять криптографические сервисы. Для создания системы предоставления публичных услуг для данного профиля защиты должны использоваться аппаратное и программное обеспечение или их комбинацию для того, чтобы реализовать криптографические сервисы. Криптографические сервисы должны обеспечивать соответствующий уровень функциональных возможностей и уверенность в достижении целей обеспечения информационной безопасности. Должны использоваться сертифицированные средства криптографической защиты. Профиль защиты «Одноуровневые операционные системы» применяется для многопользовательских систем общего назначения, что подходит для системы оказания публичных услуг.
    Цели профиля защиты «Одноуровневые операционные системы» включают те же цели, что и профиль защиты «Операционные системы», а также следующие цели:
    - операционная система должна функционировать, поддерживая безопасность ИС предоставления публичных услуг;
    - операционная система должна предоставлять криптографические механизмы обеспечения целостности данных при их передаче к удаленным частям ИС.
    Требования безопасности при предоставлении услуг профиля защиты «Одноуровневые операционные системы» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности.
    7.4.1 Функциональные требования для профиля защиты «Одноуровневые операционные системы»
    Функциональные требования для профиля защиты «Одноуровневые операционные системы» совпадают с определенными требованиями профиля защиты «Операционная система», которые должны быть дополнены следующими:
    - требования к управлению средствами криптографической защиты информации:
    1) должны быть сгенерированы симметричные и ассиметричные криптографические ключи в соответствии с согласованным алгоритмом генерации криптографических ключей;
    2) должны быть добавлены к каждому сгенерированному симметричному ключу контрольная сумма другого аттестованного алгоритма;
    3) любые сгенерированные сертификаты открытых ключей должны соответствовать требованиям действующего национального законодательства;
    4) криптографические ключи должны распределяться в соответствии с определенным методом распределения: ручной (физический) метод, автоматический (электронный);
    5) должно обеспечиваться хранение ключей только в зашифрованном виде в соответствии с требованиями действующего национального законодательства;
    6) криптографические ключи должны уничтожаться в соответствии с методом уничтожения криптографических ключей, который отвечает требованиям действующего национального законодательства, а стирание всего открытого текста криптографических ключей и всех других критичных параметров безопасности в пределах устройства должно быть немедленным и полным;
    - должны выполняться операции шифрования/дешифрования данных, вычисления криптографической цифровой подписи, операции хеширования, операции обмена криптографическими ключами в соответствии с действующим законодательством;
    - должна быть добавлена роль администратора средств криптографической защиты информации;
    - должен поддерживаться криптографический домен, отделенный от остальной части, защищенный от вмешательства и искажения неавторизированными субъектами.
    7.4.2. Требования доверия безопасности для профиля защиты «Одноуровневые операционные системы»
    Требования доверия безопасности для профиля защиты «Одноуровневые операционные системы», применяемых в процессе предоставления публичных услуг, должны включать в себя анализ уязвимостей/тестирование проникновения, требования к разработке и анализ скрытых каналов для криптографии.
    Требования доверия безопасности для профиля защиты «Одноуровневые операционные системы» совпадают с требованиями такого рода профиля защиты «Операционные системы», которые должны быть дополнены следующими:
    - криптографический модуль должен быть спроектирован и структурирован так, чтобы отделить его от других процессов;
    - должны быть определены физические/логические порты криптографического модуля;
    - требования к устранению недостатков:
        1) должна быть установлена процедура приема и обработки сообщений пользователей о недостатках безопасности и запросов на их исправление;
    2) процедуры устранения недостатков должны содержать описание процедур для отслеживания всех ставших известными недостатков безопасности при предоставлении публичных услуг;
    3) процедуры устранения недостатков должны содержать требование представления описания природы и проявлений каждого недостатка безопасности, а также статуса завершения исправления этого недостатка;
    - требования к анализу скрытых каналов криптографического модуля:
    1) для криптографического модуля должен быть проведен поиск скрытых каналов утечки критичных параметров безопасности;
    2) документация анализа должна идентифицировать скрытые каналы в криптографическом модуле и содержать оценку их пропускной способности;
    3) документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала;
    4) должно быть подтверждение, что результаты анализа скрытых каналов показывают, что криптографический модуль удовлетворяет функциональным требованиям.
    Примеры угроз для профиля защиты «Одноуровневые операционные системы» представлены в приложении 2.
    7.5. Профиль защиты «Многоуровневые операционные системы»
    Операционные системы, отвечающие требованиям данного профиля, поддерживают среды, где могут обрабатываться многоуровневые данные при предоставлении публичных услуг. Системы данного профиля защиты должны обеспечивать дискреционное управление доступом, мандатное управление доступом, мандатное управление целостностью и предоставлять криптографические сервисы. Все пользователи должны иметь ассоциированный уровень допуска, определяющий максимальный уровень чувствительности информационных ресурсов и систем, к которым они могут обращаться.
    Цели операционной системы профиля защиты «Многоуровневые операционные системы» включают те же цели, что и профиль защиты «Одноуровневые операционные системы» и дополнительно цель: – операционная система должна управлять доступом к ресурсам, который основан на уровне допуска пользователей и ресурсов, а также на уровне целостности ресурсов и уровне прав пользователя на модификацию данных.
    Требования безопасности при предоставлении публичных услуг профиля защиты «Многоуровневые операционные системы» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности. Требования доверия безопасности данного профиля совпадают с требованиями доверия безопасности профиля «Одноуровневые операционные системы».
    7.5.1. Функциональные требования для профиля защиты «Многоуровневые операционные системы»
    Функциональные требования для профиля защиты «Многоуровневые операционные системы» совпадают с функциональными требованиями для профиля защиты «Одноуровневая операционная система», которые должны быть дополнены требованиями к полному управлению информационными потоками:
    - для всех операций перемещения управляемой информации к управляемым субъектам должна осуществляться политика мандатного управления доступом;
    - если метка чувствительности субъекта больше чем или равна метке чувствительности объекта, то поток информации от объекта к субъекту разрешен (операция чтения);
    - если метка чувствительности объекта больше чем или равна метке чувствительности субъекта, то поток информации от субъекта к объекту разрешен (операция записи).
    Примеры угроз для профиля защиты «Многоуровневые операционные системы» представлены в приложении 3.
    7.6. Профиль защиты «Системы управления базами данных»
    Профиль защиты «Системы управления базами данных» определяет требования безопасности для систем управления базами данных в организациях, предоставляющих публичные услуги, где имеются требования для защиты конфиденциальности, целостности и доступности информации, хранимой в базе данных. Несанкционированное раскрытие, модификация или отказ в обслуживании такой информации может оказать неблагоприятное воздействие на процесс предоставления публичных услуг и на само функционирование организации.
    Данный профиль защиты должен определять:
    - совокупность основных требований, которым должны удовлетворять все базы данных;
    - совокупность пакетов с данными аутентификации, предоставляющими собой средства для подтверждения подлинности пользователя.
    Цели профиля защиты «Системы управления базами данных» включают:
    - предотвращение несанкционированного или непредусмотренного раскрытия, ввода, модификации или уничтожения данных и объектов базы данных (файлы и каталоги, включая программы, библиотеки рабочих программ, файлы базы данных, экспортируемые файлы, файлы повторной регистрации, управляемые файлы, файлы с трассировкой и файлы с дампом), а также просмотра базы данных, управления данными и аудита данных базы данных;
    - предоставление средств управления использованием информационных ресурсов базы данных авторизированными пользователями;
    - предоставление средств идентификации/аутентификации пользователей для надежного подтверждения подлинности пользователей;
    - предоставление средств подробной регистрации значимых для безопасности событий.
    Требования безопасности при предоставлении публичных услуг профиля защиты «Системы управления базами данных» должны быть разделены на функциональные требования и требования доверий, которые способствуют достижению целей данного профиля безопасности.
    7.6.1. Функциональные требования для профиля защиты «Системы управления базами данных»
    Функциональные требования для профиля защиты «Системы управления базами данных» при предоставлении публичных услуг, должны включать:
    - каждое событие, потенциально подвергаемое аудиту базы данных должно ассоциироваться с идентификатором пользователя базы данных, который был инициатором этого события;
    - управление доступом должно осуществляться для субъектов, объектов и операций базы данных;
    - для каждого пользователя базы данных должен поддерживаться следующий список атрибутов безопасности: идентификатор пользователя базы данных и привилегии доступа к объекту базы данных;
    - каждый пользователь базы данных должен быть успешно идентифицирован до разрешения любого другого действия от имени этого пользователя;
    - должно существовать ограничение возможностей выполнения операций с данными авторизованными пользователями базы данных;
    - должны поддерживаться следующие роли: административный пользователь базы данных и пользователь базы данных;
    - должен поддерживаться домен безопасности для собственного выполнения, защищающий данные от вмешательства и искажения неавторизированными субъектами базы данных;
    - максимальное число параллельных сеансов с базой данных, предоставляемых одному и тому же пользователю базы данных, должно быть ограничено и заранее задано;
    - должна существовать возможность отказа пользователю в открытии сеанса с базой данных, основываясь на его правах;
    - требования к аутентификации средствами базы данных:
    1) должны обнаруживаться неуспешные попытки аутентификации средствами базы данных;
    2) пароли базы данных должны отвечать требованиям действующего законодательства.
    7.6.2. Требования доверия безопасности для профиля защиты «Системы управления базами данных»
    Требования доверия безопасности для профиля защиты «Системы управления базами данных», должны включать основные требования:
    - система должна идентифицировать и аутентифицировать пользователей до предоставления доступа к любым информационным ресурсам, системам и средствам;
    - система должна предоставлять механизмы управления доступом для достижения поставленных целей;
    - система должна предоставлять механизм аудита и инструментальные средства управления аудитом для поддержки ИС предоставления услуг;
    - система должна предоставлять резервную копию, возможность возвратиться к работоспособному состоянию и другие безопасные механизмы восстановления.
    Примеры угроз для профиля защиты «Системы управления базами данных» представлены в приложении 4.

Приложение 1

Угрозы безопасности профиля защиты
«Операционные системы»

Угрозы безопасности

1. Ошибки в проекте операционных систем

2. Ошибки в реализации операционных систем

3. Ошибки документирования

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

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

6. Сбой (отказ) операционных систем

Приложение 2

Угрозы безопасности профиля защиты
«Одноуровневые операционные системы»

Угрозы безопасности

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

2. Порча или потеря данных аудита

3. Порча или потеря данных конфигурации или других доверенных данных

4. Атаки, приводящие к отказу в обслуживании

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

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

7. Перезагрузка может привести к опасному состоянию операционной системы

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

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

10. Случайные или преднамеренные ошибки в реализации проекта операционной системы

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

12. Нарушитель может получать доступ, повторяя информацию аутентификации

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

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

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

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

17. Несанкционированное изменение или использование атрибутов операционной системы и ресурсов

18. Сбой операционной системы при обнаружении и регистрации несанкционированных действий

19. Отказ системы при попытках администратора идентифицировать несанкционированные действия и повлиять на них

20. После сбоя операционной системы состояние безопасности операционной системы может быть неизвестно

21. Потеря или порча данных пользователя другими пользователями

Приложение 3

Угрозы безопасности профиля защиты
«Многоуровневые операционные системы»

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

Угрозы безопасности

1. Сущность, оперирующая на одной машине в сети, может подменить свое представление в этой сети сущностью, оперирующей на другой машине

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

Приложение 4

Угрозы безопасности профиля защиты
«Системы управления базами данных»

Угрозы безопасности

1. Несанкционированный доступ к базе данных

2. Несанкционированный доступ к информации базы данных

3. Чрезмерное использование ресурсов базы данных

4. Неправильное использование привилегий пользователей базы данных

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

Приложение № 4
к Приказу № 94
от 17.09.2009 г.

Технический Регламент
Определение стоимости разработки и внедрения автоматизированных
информационных систем. Нормативы и оценкa трудовых затрат
1. Область применения

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

2. Нормативно-правовая база

    Настоящий регламент разработан на основе следующих законодательных актов Республики Молдова:
    1) Закон Республики Молдова «О доступе к информации» № 982-XIV от 11.05.2000;
    2) Закон Республики Молдова «Об информатизации и государственных информационных ресурсах» № 467–XV от 21.11.2003;
    3) Закон Республики Молдова «Об электронном документе и цифровой подписи» № 264-XV от 15.07.2004;
    4) Закон Республики Молдова «Об электронной торговле» № 284-XV от 22.07.2004;
    5) Закон Республики Молдова «О техническом регулировании» № 420-XVI от 22.12.2006;
    6) Закон Республики Молдова «О защите персональных данных» № 17-XVI от 15.02.2007;
    7) Закон Республики Молдова «О регистрах» № 71-XVI от 22.03.2007;
    8) Закон Республики Молдова «О государственных закупках» № 96 от 13.04.2007.

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

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

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

    ИС является организационно–упорядоченная совокупность информационных ресурсов, информационных технологий, аппаратных и коммуникационных средств, позволяющая осуществлять сбор, хранение, поиск, обработку и пользование информацией.
    ИС состоит из следующих основных компонентов:
    1) программное обеспечение (ПО) – совокупность всей информации, данных и программ, которые обрабатываются компьютерными системами;
    2) информационное обеспечение – обеспечение фактическими данными управленческих структур, использование информационных данных для автоматизированных систем управления, использование информации для обеспечения деятельности различных потребителей;
    3) технические средства – комплекс электронных, электрических и механических устройств, входящих в состав системы или сети;
    4) обслуживающий персонал.
    4.1. Программное обеспечение
    ПО представляет собой совокупность программ систем обработки информации и программных документов, необходимых для эксплуатации этих программ, и подразделяется на:
    1) системное ПО – набор программ, которые управляют компонентами ИС, такими как процессор, коммуникационные и периферийные устройства, а также программы, предназначенные для обеспечения функционирования и работоспособности всей системы:
    - операционные системы общего назначения, реального времени, сетевые, встраиваемые;
    - загрузчик операционной системы;
    - драйверы устройств;
    - программы, способные выполнять преобразование потока данных или сигнала;
    - утилиты;
    2) программные средства защиты - программы для идентификации пользователей, контроля доступа, шифрования информации, удаления остаточной (рабочей) информации типа временных файлов, тестового контроля системы защиты. К программным средствам защиты относятся:
    - криптошлюзы;
    - средства аутентификации;
    - средства мониторинга и аудита;
    - сканеры защищенности;
    - средства разграничения доступа;
    - системы криптографической защиты, шифрования и электронно–цифровой подписи;
    - антивирусные и антиспамовые программы;
    - межсетевые экраны;
    3) инструментальное ПО – программы, предназначенные для использования в ходе проектирования, разработки и сопровождения ИС. Включает в себя средства разработки ПО, системы управления базами данных, компиляторы, трансляторы, генераторы;
    4) Прикладное ПО включает:
    - офисные приложения: текстовые редакторы, текстовые процессоры, табличные процессоры, редакторы презентаций;
    - корпоративные ИС: бухгалтерские программы, системы MRP (Material Requirement Planning), системы MRP II, системы ERP (Enterprise Resource Planning System), системы CRM (Customer relationship management), системы SCM (Supply Chain Management), системы управления проектами, системы автоматизации документооборота, системы управления архивами документов, корпоративный портал;
    - системы проектирования и производства: системы автоматизированного проектирования (CAD–системы Computer-Aided Design), CAE–системы (Computer-aided engineering), CAM–системы (Computer-aided manufacturing), PDM–системы (Product Data Management), PLM–системы (Product Lifecycle Management), автоматизированные системы управления технологическим процессом;
    - системы логистической поддержки изделий: системы анализа логистической поддержки и организационно–технические системы;
    - системы обработки и хранения медицинской информации;
    - научное ПО;
    - геоинформационные системы;
    - системы поддержки принятия решений;
    - клиенты для доступа к интернет–сервисам: электронная почта, веб–ресурсы, мгновенная передача сообщений, чат–каналы, IP–телефония, P2P обмен файлами, потоковое вещание, клиент–банк;
    - мультимедиа.
    4.2. Информационное обеспечение
    Инфраструктура ИС включает в себя организационные и технологические подсистемы, а также комплекс обеспечивающих ресурсов, с помощью которых решаются как внутренние, так и внешние управленческие и организационные задачи, в соответствии с функциями, определенными законодательством.
    ИС обеспечивает связность подсистем в рамках единой логики, стандартов, «интерфейсов» и совместного использования информационных ресурсов.
    К информационным ресурсам относятся:
    1) базы данных и банк данных;
    2) системная документация;
    3) руководства пользователя;
    4) учебные материалы;
    5) операционные процедуры и процедуры поддержки;
    6) планы обеспечения бесперебойной работы организации;
    7) процедуры перехода на аварийный режим.
    Государственные информационные ресурсы в зависимости от использования подразделяются на:
    1) базовые государственные информационные ресурсы;
    2) ведомственные государственные информационные ресурсы;
    3) территориальные государственные информационные ресурсы.
    Базовыми государственными информационными ресурсами являются информационные ресурсы, предназначенные для общего использования всеми органами публичной власти, юридическими и физическими лицами в пределах предоставленных им полномочий.
    Ведомственные информационные ресурсы формируются и используются отраслевыми органами публичного управления, являющимися владельцами этих ресурсов. Ведомственные информационные ресурсы содержат информацию, необходимую для выполнения указанными органами своих функций, за исключением данных, предназначенных для включения в базовые информационные ресурсы.
    Территориальные информационные ресурсы формируются и используются органами местного публичного управления, являющимися владельцами этих ресурсов. Территориальные информационные ресурсы содержат данные обо всех видах природных и искусственных географических объектов, включая ресурсный потенциал на управляемых территориях.
    4.3. Технические средства
    Технические средства используются для установки, поддержки и разъединения связи, а также для обеспечения преобразования сигналов между oконечным оборудованием данных и каналом общего пользования, и включают:
    1) компьютеры и логические устройства;
    2) внешние устройства и диагностическую аппаратуру;
    3) коммуникационное обеспечение;
    4) энергетическое оборудование;
    5) батареи;
    6) аккумуляторы.
    Коммуникационное обеспечение предназначено для управления процессами передачи информации между другими системами и включает в себя:
    1) коммутаторы;
    2) концентраторы;
    3) маршрутизаторы;
    4) межсетевые экраны;
    5) адаптеры;
    6) кабельные системы;
    7) повторители, мосты.
    Коммуникационное оборудование представляет собой сложный специализированный мультипроцессор, который нужно конфигурировать, оптимизировать и администрировать.

5. Методика определения
стоимости информационных систем

    В основу методики определения стоимости ИС легла конструктивная модель стоимости (Constructive Cost Model - COCOMO), которая разработана Барри Боэмом (Barry Boehm) и применяется для определения стоимости коммерческих и государственных ИС. COCOMO II адаптирована к современным методологиям разработки ПО и пригодна для всех моделей жизненного цикла ПО.
    Представленная модель является одной из самых популярных, открытых и хорошо документированных математических моделей оценки стоимости и трудоемкости разработки ПО. Для обработки статистических данных используется Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью.
    Байесовский анализ – подход, который учитывает распределение вероятностей, основанное либо на субъективном мнении, либо на таких объективных данных, как результаты предыдущего исследования; может использоваться для единичных исследований и для мета–анализа. Байесовский анализ использует теорему Байеса и позволяет провести переоценку распределения с учетом результатов исследования, давая представленное распределение, на котором основаны статистические выводы (точечные оценки, доверительные интервалы).
    Модель базируется на реально измеряемых показателях. Для оценки трудоемкости и стоимости проекта эти исходные данные должны быть детализированы. При расчете показателей модель учитывает уровень зрелости процесса разработки.
    В настоящем документе представлен подход к формированию стоимости ИС на каждом этапе жизненного цикла. Подход представлен в виде поэтапного выполнения работ и соблюдения перечня требований, представленных далее.

6. Этапы определения
стоимости информационных систем

    Перед началом этапов определения стоимости разработки и внедрения ИС осуществляется этап предпроектных работ. Этап предпроектных работ начинается с первоначального осознания потребности создания новой или модификации существующей ИС.
    Данный этап является периодом начального изучения, сбора фактов и анализа, изучения действующего законодательства и существующей организационной структуры, обзора аналогичных существующих ИС. Выходными элементами этапа предпроектных работ являются концепция системы и бизнес-предложение, которые позволяют принять решение - продолжать или прекратить реализацию ИС.
    При необходимости внесения дополнительных задач, необходимо оценить целесообразность их выполнения.
    Для определения стоимости разработки и внедрения ИС необходимо последовательно выполнять этапы:
    1) анализ и спецификации требований к ИС - анализ функциональных и нефункциональных требований, требований к внешним интерфейсам ИС, к аппаратному обеспечению, по обеспечению информационной безопасности, определение архитектуры аппаратного обеспечения, проектирование ПО, идентификация объектов и их иерархия;
    2) определение структурных единиц и стоимости поставок программного и аппаратного обеспечения - определение поставок и аренды аппаратного и программного обеспечения;
    3) оценка размера программной части ИС - определение размера программной части ИС и составление документации по оценке размера программной части;
    4) оценка объема работ - идентификация рисков, структурного разбиения работ, расчет и корректировка объема работ и трудозатрат по разработке ПО;
    5) трудозатраты на кодирование и тестирование - расчет объема работ и трудозатрат на кодирование и тестирование, расчет длительности кодирования и тестирования, составление плана работ по разработке ИС и сценариев тестирования;
    6) определение характеристик качества ИС - определение количественных, качественных, внутренних и внешних характеристик качества и оценка качества ИС;
    7) вычисление стоимости ИС - оценка общей стоимости проекта;
    8) определение влияния рисков - оценка влияния рисков, ее регулирование, а также регулирование затрат, основанных на оценке рисков;
    9) подтверждение и корректировка оценки стоимости рисков - оценка рисков независимой экспертной группой, анализ статистических данных, сравнение оценок рисков и их корректировка;
    10) внедрение ИС - разработка плана и задач внедрения, реализация полномасштабного внедрения ИС.
    6.1. Анализ и спецификации требований к информационной системе
    Цель анализа требований к ИС заключается в разработке и подтверждении функциональных, нефункциональных требований, требований к внешним интерфейсам и безопасности системы, идентификации технических и программных ограничений, которые позволят наиболее точно произвести оценку стоимости ИС.
    Процесс сбора и анализа требований состоит из:
    1) анализа и детального моделирования программных требований;
    2) определения архитектуры ИС;
        3) определения ограничений реализации ИС;
4) анализа архитектуры аппаратного обеспечения, коммуникаций.
    6.1.1. Анализ и детальное моделирование программных требований
    6.1.1.1. Функциональные требования
    Функциональные требования описывают действия, для выполнения которых приложение предназначено, и могут выражаться в виде услуг, заданий или функций, которые надлежит выполнять приложению.
    Модель требований определяет целенаправленный комплекс взаимодействий между внешними участниками и рассматриваемой системой. Внешние участники - это стороны вне системы, которые взаимодействуют с системой. Внешним участником может быть класс пользователей, роли, исполняемые пользователями или другие системы.
    Главной целью моделирования функциональных требований является установка границ работы приложения и полного комплекса функциональных возможностей, предоставляемых конечному пользователю.
    Функциональные требования, как минимум, должны включать:
    1) требования, согласованные всеми заинтересованными представителями бизнес-подразделений:
    - характеристику ИС;
    - основные цели создания и назначение;
    - планируемое развитие;
    - требования к ИС в целом;
    - требования к структуре данных ИС;
    - требования к функциональности ИС;
    - требования к интерфейсу пользователя и отчетам;
    - требования к средствам администрирования;
    - требования к средствам разработки;
    - требования к взаимодействию с другими программными продуктами;
    - требования к документированию;
    - требования к программному и аппаратному обеспечению.
    - описание спецификации ИС, в которых применяется данное приложение;
    - документирование форматов входных и выходных данных;
    - методы реализации контролей подготовки, ввода данных и обработки ошибок ввода данных, позволяющих реализовать обнаружение, индикацию и корректировку ошибок;
    - методы реализации контролей проверки данных транзакций, введенных для обработки (вручную или системой) на точность, полноту и достоверность;
    - методы обнаружения и исключения ошибочных транзакций по ходу их обработки;
    - средства, поддерживающие неотказуемость транзакций;
    2) формализованные требования, согласованные всеми заинтересованными представителями бизнес-подразделений :
    - описание детальных спецификаций ПО в части функциональности системы;
    - требования к разработке и документированию интерфейсов с внутренними системами;
    - требования к разработке и документированию алгоритмов обработки данных;
    - требования обеспечения безопасности, целостности и доступности (в том числе при чрезвычайных ситуациях).
    6.1.1.2. Требования к внешним интерфейсам
    Требования к внешним интерфейсам ИС, в зависимости от необходимости, должны включать:
    1) приоритет, который ИС должна присвоить интерфейсу;
    2) требования к типу интерфейса (функционирование в режиме реального времени, передача данных, хранение и извлечение данных), которые необходимо обеспечить;
    3) требуемые характеристики индивидуальных элементов данных, которые должна предоставлять ИС для обеспечения хранения, передачи, доступа, приема данных:
    - имя/идентификаторы;
    - тип данных (цифробуквенный, целый);
    - размер и формат (длина и пунктуация ряда символов);
    - единицы измерения (объема, стоимости, времени);
    - интервал или перечисление возможных значений (например, 0–99);
    - аккуратность (насколько верно) и точность (число значащих разрядов);
    - приоритет, хронометраж, частота, объем, порядок и другие ограничения для актуализации элемента данных и применяемые правила бизнеса;
    - ограничения по безопасности;
    - источники (объекты, которые создают/посылают данные) и получатели (объекты, которые используют/принимают данные);
    4) требуемые характеристики совокупностей элементов данных (записи, сообщения, файлы, матрицы, отчеты), которые ИС должна предоставлять, хранить, передавать, принимать и обеспечивать к ним доступ:
    - имя/идентификаторы;
    - элементы данных, которые входят в их структуру (номер, порядок, группировка);
    - среды (например, диски) и структуры данных/элементов в среде;
    - аудиовизуальные характеристики сообщений и других выходов;
    - отношения между группами, характеристики сортировки/доступа;
    - приоритет, хронометраж, частота, объем, порядок и другие ограничения;
    - время реагирования на запрос;
    - ограничения безопасности;
    - источники и получатели;
    5) требуемые характеристики для методов коммуникаций, которые ИС должна использовать для интерфейса:
    - уникальные проектные идентификаторы;
    - коммуникации, связи/полосы пропускания/частоты/среды и их характеристики;
    - формат сообщений;
    - контроль потоков;
    - скорости передачи, периодичность, интервал между передачами;
    - маршрутизация, адресация и пространства имен;
    - услуги передачи, включая приоритеты и оценки;
    - соображения безопасности/конфиденциальности, такие как шифрование, аутентификация пользователей, проведение аудита;
    6) требования к характеристикам, которыми должны обладать протоколы ИС для взаимодействия:
    - уникальный идентификатор проекта;
    - приоритет/уровень протокола;
    - разбиение на пакеты, включая фрагментацию, повторную сборку, маршрутизацию и адресацию;
    - проверки легальности, контроль над ошибками и процедуры восстановления;
    - синхронизация, включая установку соединения, поддержание, прекращение;
    - состояние, идентификация и любые возможности отчетов;
    7) другие требуемые характеристики, физическая совместимость взаимодействующих объектов информационных ресурсов (размеры, интервалы, загрузки).
    5.1.1.3. Нефункциональные требования
    Нефункциональные требования должны быть использованы для определения требований и ограничений ИС. Требования должны быть использованы в качестве основы для ранней системы измерения и оценки жизнеспособности разрабатываемой ИС.
    Нефункциональные требования включают:
    1) ограничения среды и реализации;
    2) производительность (скорость, пропускная способность, время отклика, используемая память);
    3) зависимость от платформы;
    4) расширяемость;
    5) надежность (пригодность, точность, средняя наработка на отказ, число ошибок на тысячу строк программы, число ошибок на класс).
    При определении нефункциональных требований должны применяться следующие категории атрибутов качества:
    1) управляемость;
    2) рентабельность;
    3) эффективность;
    4) возможность взаимодействия с другими приложениями и службами;
    5) доступность и надежность;
    6) мощность и производительность;
    7) возможность внесения исправлений;
    8) возможность инсталлирования;
    9) контролируемость;
    10) поддерживаемость;
    11) удобство использования;
    12) безопасность.
    Нефункциональные требования должны использоваться для предписания качественных атрибутов разрабатываемого приложения. Данные качественные атрибуты должны применяться для составления планов тестирования приложений в соответствии с нефункциональными требованиями (см. 6.5).
    6.1.1.4. Основные требования к информационным системам органов публичной власти
    ИС органов публичной власти должны обеспечивать:
    1) гарантированный и безопасный доступ к общедоступным государственным информационным ресурсам;
    2) возможность поиска, сбора, обработки и хранения государственных информационных ресурсов;
    3) возможность предоставления органам публичной власти доступа к локальным и глобальным информационным ресурсам;
    4) надежность функционирования и устойчивость к программно–аппаратным сбоям, включая случаи некорректной работы пользователей;
    5) оперативный и безопасный обмен данными между пользователями;
    6) возможность дальнейшего расширения путем модернизации аппаратных и программных средств, наращивания системы новыми компонентами;
    7) другие функции, связанные с основным направлением деятельности органов публичной власти.
    Требования к ИС органов публичной власти должны быть документированы и необходимо проверять соответствие работ по следующим категориям систем:
    1) транзакционные и учетные системы, обеспечивающие поддержку выполнения органами публичной власти своих основных задач и функций;
    2) системы межведомственного информационного взаимодействия между ИС органов публичной власти;
    3) системы управления ресурсами, обеспечивающими поддержку деловых процессов и административных регламентов в деятельности органов публичной власти;
    4) информационно–аналитические системы, обеспечивающие сбор, обработку, хранение и анализ данных о результатах выполнения органами публичной власти своих основных задач и функций;
    5) системы электронного документооборота;
    6) системы управления электронными архивами документов;
    7) системы управления эксплуатацией (включая системы управления инфраструктурными компонентами);
    8) системы взаимодействия с физическими и юридическими лицами, обеспечивающими предоставление органами публичной власти через Интернет или другие каналы связи справочной информации и услуг, включая порталы и центры телефонного обслуживания;
    9) системы обеспечения информационной безопасности;
    10) офисные системы, используемые сотрудниками государственных органов в своей повседневной деятельности для подготовки документов и обмена информацией.
    ИС органов публичной власти должны создаваться на основании следующих принципов:
    1) доступность, достоверность, полнота и своевременность предоставления информации;
    2) конфиденциальность - обеспечение разграничения доступа к информационным ресурсам ИС в пределах предоставленных пользователям полномочий;
    3) открытость - возможность интегрирования с другими ИС и национальной ИС;
    4) масштабируемость - возможность дальнейшего расширения функциональных возможностей ИС путем добавления в их состав программно–аппаратных средств, модернизации;
    5) защищенность - обеспечение сохранности и целостности информационных ресурсов, входящих в состав ИС;
    6) надежность функционирования и устойчивость ИС.
    6.1.1.5. Требования по обеспечению информационной безопасности информационных систем органов публичной власти
    Информационная безопасность в ИС органов публичной власти должна обеспечиваться системой, включающей в себя комплекс организационно–технических мер и программно–аппаратных средств защиты информации.
    Программно–аппаратные средства защиты информации, применяемые в ИС органов публичной власти, должны быть лицензионными, сертифицированными и обеспечивать:
    1) идентификацию защищаемых информационных ресурсов;
    2) аутентификацию пользователей ИС;
    3) конфиденциальность информации, циркулирующей в системе;
    4) аутентифицированный обмен данными;
    5) целостность данных при формировании, передаче, использовании, обработке и хранении информации;
    6) авторизированную доступность всех ресурсов системы в условиях нормальной эксплуатации;
    7) разграничение доступа пользователей к ресурсам ИС;
    8) администрирование (обозначение прав доступа к ресурсам ИС, обработка информации из регистрационных журналов, установка и снятие системы защиты);
    9) регистрацию действий по входу и выходу пользователей, а также нарушений прав доступа к ресурсам ИС;
    10) контроль целостности и работоспособности системы обеспечения информационной безопасности;
    11) безопасность и бесперебойное функционирование системы в чрезвычайных ситуациях.
    6.1.2. Определение архитектуры информационной системы
    На данном этапе необходимо провести анализ и уточнение результирующей иерархии физической архитектуры ИС, программных сегментов и реализации построения сегментов. Исходными данными для этого этапа служит пакет бизнес-требований, включающий функциональные, нефункциональные и требования по обеспечению безопасности ИС.
    На этапе определения архитектуры ИС должны быть разработаны детализированные модели того, что было подготовлено на этапе разработки бизнес-требований. Разрабатываемые модели включают архитектурные модели, в которых необходимо определить способ преобразования различных функциональных компонентов в физические компоненты (т.е. рабочий стол, сервер, база данных, сеть).
    На данном этапе должны быть разработаны планы тестирования для различных уровней тестирования (смотри раздел 6.5):
    1) тестирование блочное;
    2) тестирование модуля;
    3) тестирование системы (возможности интегрирования систем);
    4) тестирование интерфейсов между системами;
    5) тестирование файлов загрузки;
    6) нагрузочное тестирование;
    7) тестирование безопасности;
    8) тестирование резервного копирования.
    6.1.3. Определение ограничений реализации ИС
    На данном этапе необходимо провести анализ проекта и плана разработки ИС. Идентифицировать программные ограничения и требования, включая вспомогательные ресурсы, спецификации, определение решений о покупке или внутренней разработке требуемых компонент приложения.
    Определяется полный набор технически и коммерчески жизнеспособных системных элементов, из которых конфигурируется ИС.
    Необходимо рассмотреть архитектуру ИС и ее структурную схему с ассоциациями между элементами, определить внешние интерфейсы по отношению к системе и между компонентами самой системы.
Описывается программное окружение разрабатываемой ИС. Если разрабатываемая ИС является расширением уже существующей, то описываются главным образом ее дополнительные характеристики. Приводится перечень аппаратного и программного обеспечения, необходимого для работы ИС.
    Необходимо рассматривать несколько аспектов совместимости: неоднородность программной среды, языки программирования, форматы данных и сообщений, форматы отчетов, форматы листингов. Специально должна оговариваться совместимость с различным ПО.
    6.1.4. Анализ архитектуры аппаратного обеспе-чения, коммуникаций
    На данном этапе необходимо проверить и удостовериться в способности аппаратного обеспечения ИС отвечать новым и меняющимся требованиям ведения бизнеса со стороны таких компонентов инфраструктуры как сети, телекоммуникации и другие программные приложения.
    На этапе проектирования определяются как архитектура аппаратного обеспечения, так и требования низкого уровня. Разработка архитектуры заключается в принятии ряда последовательных и взаимосвязанных решений о структуре аппаратного обеспечения ИС. Разработка требований низкого уровня к ИС – формирование требований к отдельным программным модулям.
    Архитектура ИС включает описание:
    1) физических сущностей, из которых состоит система (узлов сети, сетей);
    2) информационных потоков между физическими сущностями в системе;
    3) спецификаций каналов передачи информации в системе;
    4) выбора платформы (платформ) и операционной системы (операционных систем);
    5) выбора архитектуры «файл–сервер» или «клиент–сервер»;
    6) выбора 3–уровневой архитектуры со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
    7) выборa базы данных централизованной или распределенной.
    Подтверждение требований по мощности, производительности и доступности ИС относятся к основным действиям, производимым на данном этапе.
    Результаты этапа включают:
    1) определение аппаратных и программных требований и ограничений;
    2) определение функциональных, нефункциональных и требований по безопасности ИС;
    3) создание программной архитектурной иерархии сегментов и связанных функций;
    4) создание аппаратной архитектуры.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 1.
    Таблица 1. Стоимость информационной системы на этапе «Сбор и анализ требований к информационной системе»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Разработка документации по функциональным требованиям
2	Разработка документации по требованиям к внешним интерфейсам
3	Разработка документации по нефункциональным требованиям
4	Разработка спецификации требований к ИС
5	Разработка документации по требованиям к ПО
6	Проверка и валидация, определение ограничений к ИС
7	Определение архитектуры ИС
8	Разработка ограничений реализации ИС
9	Планирование управления конфигурацией ПО
10	Контроль конфигурации
11	Составление отчетности по конфигурации
12	Определение архитектуры аппаратного обеспечения
13	Определение требований к аппаратному обеспечению
14	Разработка критической модели ИС
15	Определение требований по обеспечению информационной безопасности
16	Проектирование ПО
17	Административные расходы, связанные со сбором и анализом требований к ИС
Итого:
Итого по этапу:

    6.2. Определение структурных единиц и стоимости поставок программного и аппаратного обеспечения
    Цель данного этапа заключается в определении структурных единиц и стоимости поставок программного и аппаратного обеспечения, которые будут включены в стоимость ИС.
    При планировании структурных единиц проекта, для которого требуется оценка стоимости, необходимо применять принцип структурного разбиения работ.
    Структурные единицы и поставки программного и аппаратного обеспечения, которые необходимо проанализировать на данном этапе включают:
    1) управление ПО – предполагает решение широкого спектра задач:
    - отслеживание сбоев в управляемых компьютерах, автоматическое устранение их причин, исправление их последствий и действия по их предотвращению;
    - управление производительностью компьютеров и приложений;
    - автоматическое конфигурирование компьютеров и сетевых устройств;
    - конфигурирование и обновление ПО.
    2) проектирование ИС – определяется как итерационный процесс получения логической модели ИС вместе со строго сформулированными целями, поставленными перед ней, а также написания спецификаций физической системы, удовлетворяющей этим требованиям;
    3) разработка ПО – достаточно подробное уточнение требований заказчика и проектного решения и преобразование их в один или несколько жизнеспособных ПО;
    4) тестирование ПО – один из важнейших этапов проверки качества разработанного ПО;
    5) среда разработки ПО – система программных средств, используемая программистами для разработки ПО. Среда разработки включает:
    - текстовый редактор;
    - компилятор и/или интерпретатор;
    - средства автоматизации сборки и отладчик;
    - систему управления версиями;
    - инструменты для упрощения конструирования графического интерфейса пользователя;
    - браузер классов, инспектор объектов и диаграмму иерархии классов;
    6) системный уровень поддержки тестирования включает испытание разрабатываемого ПО, испытание системного уровня ПО, поддержку сборки, тестирования и процедуры сдачи ПО в эксплуатацию;
    7) сборка, тестирование и процедура сдачи ПО в эксплуатацию – готовое ПО передается заказчику, производятся приемо–сдаточные испытания, осуществляется обучение пользователей и опытная эксплуатация, после чего ПО ставится на сопровождение и начинается производственная эксплуатация ПО;
    8) система обеспечения качества направлена на обеспечение необходимого уровня объективности и достоверности результатов разработки и внедрения ПО, а также на обеспечение надлежащего качества производимой продукции и/или предоставляемых услуг;
    9) независимая проверка и подтверждение адекватности ИС.
    Эти категории структурного разбиения работ включают в себя процессы жизненного цикла разработки ИС.
    Результаты этапа включают:
    1) определение поставок программного и аппаратного обеспечения;
    2) определение структурных единиц ИС.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 2.
    Таблица 2. Стоимость информационной системы на этапе «Определение структурных единиц и стоимости поставок программного и аппаратного обеспечения»

№ п\п	Компоненты затрат	Стоимость приобрете-ния	Стоимость организа-ции тендеров	Стоимость дополнительных работ для введения в эксплуатацию
1	Определение компонентов программного и аппаратного обеспечения
2	Среда разработки ПО
3	Инструменты управления БД
4	Инструменты системного мониторинга
5	Инструменты системной отчетности
6	Инструменты генерирования отчетов
7	Затраты на системный мониторинг
8	Инструменты диагностики аппаратного и программного обеспечения
9	Инструменты анализа и проектирования
10	Инструменты тестирования
11	Рабочие станции и комплектующие
12	Принтеры, сканеры, ксероксы
13	Устройства хранения данных
14	Сервера
15	Оборудование для серверного помещения
16	Инструменты обеспечения информационной безопасности
17	Стоимость аренды аппаратного и программного обеспечения
18	Сетевое оборудование
19	Поддержка сопровождения
20	Операционные системы
21	Обновление ПО
22	Лицензии
23	Коммуникационные услуги
24	Программы для коммуникаций
25	Обучение, переподготовка, инструктаж персонала
26	Административные расходы, связанные с определением структурных единиц и поставками программного и аппаратного обеспечения
Итого:
Итого по этапу:

    6.3. Оценка размера программной части информационной системы
    Целью данного этапа является определение размера программной части ИС.
    Промышленной мерой оценки размера ПО является количество исходных строк кода - Source Lines of Code (SLOC). Под строками кода SLOC понимаются логические строки кода, а именно строки в понимании используемого языка программирования, без учета комментариев.
    Оценка размера ПО происходит следующим образом:
    1) разделение и группировка программных функциональных требований и требований к ИС органов публичной власти в категории программного наследования.
    Категории программного наследования включают:
    - новый проект и новый код;
    - аналогичный проект и новый код;
    - аналогичный проект и многократно используемый код;
    - аналогичный проект и расширенный код, используемый многократно.
    Нефункциональные требования и требования к интерфейсам используются для составления планов тестирования ПО и приложений.
    Впоследствии категории программного наследования будут использованы в качестве множителей для корректировки объема работ для программного наследования (смотри пункт 6.4.2.2, формула (3), таблица 6);
    2) оценка размера каждой программной функции - в соответствии с коэффициентами, приведенными в таблице 3.
    Таблица 3. Оценка KSLOC базовых размеров ПО для модели COCOMO II

Размер ИС	KSLOC	Ед. измерения
Маленькая	2	тыс. строк кода
Небольшая	8	тыс. строк кода
Средняя	32	тыс. строк кода
Большая	128	тыс. строк кода
Очень большая	512	тыс. строк кода

Количество тысяч строк кода (KSLOC) рассчитывается по формуле:

, (1)
    где:
    - KSLOC - количество тысяч строк кода;
    - SLOCP - код, обеспечивающий определенную логику работы системы. Обычно это классы, описывающие свойства объектов системы, взаимосвязь между бизнес–функциями;
    - SLOCI - код, обрабатывающий элементы интерфейса и связывающий его с другими частями системы. Обычно это классы обработки ошибок ввода данных, записи данных в базу данных и т.п.;
    - SLOCR - код, описывающий интерфейс системы. Обычно это код, описывающий сам интерфейс. Для компонент, работающих в среде Интернет - это HTML код;
    - Kp - фактор изменения логики работы системы;
    - Ki - фактор изменения обработки интерфейсных элементов системы;
    - Kr - фактор изменения интерфейса системы.
    Факторы K подбираются опытным путем и измеряются от 0,01 - 0,6 и свыше 0,6 при создании новой системы. Для определения факторов K используется статистический подход, помогающий изменять априорные оценки с учетом данных новых исследований;
    3) расчет общего размера программной части ИС в KSLOC, просуммировав данные, полученные в пункте 2 по каждой программной функции.
    Альтернативные методы оценки программной части ИС представлены в приложении 1.
    Результаты этапа включают:
    1) размер ПО, оцененный для каждой функциональной категории наследования KSLOC;
    2) общая программная оценка размера KSLOC.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 4.
    Таблица 4. Стоимость информационной системы на этапе «Оценка размера программной части информационной системы»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Составление документации по оценке размера программной части ИС
2	Определение размера программной части ИС
3	Анализ статистических данных в данной области
4	Административные расходы, связанные с оценкой размера программной части ИС
Итого:
Итого по этапу:

    6.4. Оценка объема работ
    Для оценки людских ресурсов (человек – в месяц), продолжительности (в календарных днях) и стоимости (в денежных единицах) необходимо основываться на статистике из прошлого опыта. В случае отсутствия исторических данных или если ведется работа над новым проектом необходимо применение специальных методик, позволяющих предварительно оценить затраты на планируемый проект.
    6.4.1. Идентификация категорий структурного разбиения работ, атрибуты которых будут влиять на размер и объем работ
    Необходимо идентифицировать категории структурного разбиения работ, атрибуты которых будут влиять на размер и объем работ согласно смете проекта, с точки зрения наследования и риска. Основными категориями рисков могут быть следующие:
    1) новые технологии: код, язык программирования или метод проектирования. Выбор языка программирования также может оказать существенное влияние на безопасность ИС. Лучшими языками программирования являются те, в которых все действия определены и обоснованы, поддерживаются функции, уменьшающие число ошибок, осуществляется контроль над распределением памяти и использованием указателей. Эта группа рисков объединяет риски, связанные с используемыми технологиями, несовместимостью языков программирования, несоответствием методов проектирования;
    2) низкий уровень готовности технологий – истечение срока действия лицензий, моральное устаревание технологий, появление принципиально новых технологий, которые сразу делают определенные продукты и услуги неактуальными;
    3) оптимистические предположения, связанные с наследованием элементов ИС;
    4) возможность многократного использования кода - увеличение количества ошибок в связи с неправильно составленным многократно использующимся программным кодом;
    5) риск, связанный с поставщиками программного и аппаратного обеспечения - необходимо создание формальных процедур по управлению рисками, связанными с поставщиками. К этой категории рисков также относятся риски ценообразования, связанные с неопределенностью экономических показателей проектов, и валютные риски;
    6) риск недостаточной защиты интеллектуальной собственности: возможность нарушения патентов и хищения интеллектуальной собственности на развивающихся рынках;
    7) риски, связанные с сервисным и техническим обслуживанием: отсутствие специализированных инженерных служб, квалифицированной рабочей силы и подменного оборудования;
    8) параллельная разработка аппаратных средств;
    9) количество интерфейсов между многочисленными подразделениями разработчиков;
    10) инфраструктурные риски – проблемы подключения к сети и отсутствие доступа к передающим и распределительным системам;
    11) географическое распределение многочисленных подразделений разработчиков;
    12) высокая сложность элементов ИС;
    13) профессиональные навыки и опыт персонала – данной категории рисков необходимо уделить особое внимание. Руководитель проекта должен оценить риски и организовать обучение еще до начала проекта, чтобы не терять время на ошибки в будущем;
    14) неопределенные или неполные требования – процесс разработки ИС начинается с определения требований и вариантов использования системы. Основная проблема заключается в том, что некоторые ключевые требования могут быть пропущены, другие требования не так понятны разработчиками. Еще одна категория рисков, связанная с требованиями, – это реализация второстепенных требований и откладывание основных требований;
    15) риски, связанные с аутсорсингом;
    16) политические риски - связаны с корпоративной политикой взаимодействующих сторон, а также особенностями организаций и деятельностью составляющих подразделений.
    Для каждой категории рисков средневзвешенный коэффициент влияния на размер и объем работ определяется согласно статистическому подходу, помогающему изменять априорные оценки с учетом данных новых исследований.
    6.4.2. Преобразование размера программного обеспечения в объем работ
    Целью является преобразование размера ПО, полученного в соответствии с подразделом 6.3 (формула (1), в объем работ. Разработка ПО охватывает программных инженеров, системотехников, тестировщиков, программистов, а также включает в себя: разработку и анализ требований по интегрированию и тестированию ПО. Вычисление объема работ и стоимости других категорий структурного разбиения работ приведено ниже, с использованием других методов.
    Вычисление объема работ производится в рабочих месяцах (РМ) для следующих категорий структурного разбиения работ: «Проектирование ИС», «Разработка ПО» и «Тестирование ПО».
    6.4.2.1. Оценка трудозатрат и объема работ по проектированию информационной системы
    Анализ и проектирование ИС являются определяющими при построении ИС. Выделяют три фазы анализа и проектирования ИС:
    1) обследование и системный анализ существующей ИС и выявление ее недостатков;
    2) обобщение результатов системного анализа и создание предварительной концепции новой или модернизированной ИС;
    3) разработка системного проекта комплекса программ и баз данных, определяющих методы и средства дальнейшего детального проектирования и всего жизненного цикла ИС и базы данных.
    Системный анализ является важным для успешного проектирования ИС, поэтому может рассматриваться как один из факторов риска. Для выполнения работ по проектированию ИС могут привлекаться специализированные организации, имеющие опыт подобного проектирования, либо собственные аналитические структуры, знающие бизнес–процессы организации. Работы по проектированию ИС выполняются наиболее эффективно комбинированной проектной группой.
    При реализации системного анализа достигаются следующие результаты:
    1) описание бизнес и информационных процессов, сложившихся в организации;
    2) узкие места в бизнес–процессах и пути их ликвидации;
    3) информационная и функциональная модель ИС;
    4) список требований к новой или модернизированной ИС;
    5) методы и средства проектирования и реализации ИС;
    6) предварительный укрупненный план проектирования ИС;
    7) технико–экономическое обоснование.
    Трудозатраты по проектированию ИС включают оплату работ специалистов сторонних организаций в соответствии с условиями заключенного контракта, а также оплату работ собственных аналитических структур.
    Объем работ по проектированию ИС определяется согласно контракту, заключенному со специалистами сторонних организаций, в котором указывается объем выполняемых работ и сроки их выполнения, а также согласно должностным инструкциям собственного персонала.
    Объем работ по проектированию ИС в разрезе декомпозиции основных категорий структурного разбиения работ в процентном соотношении определяется согласно методике и статистическому анализу SEER–SEM (смотри пункт 6.4.3(2), таблица 11) или согласно статистическому методу (приложение 1).
    Проектирование ИС охватывает три основные области:
    1) проектирование объектов данных, которые будут реализованы в базе данных;
    2) проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
    3) учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, параллельной обработки, распределенной обработки данных.
    6.4.2.2. Преобразование размера каждой про-граммной функции в объем работ по разработке программного обеспечения
    Преобразование размера каждой программной функции в объем работ по разработке ПО вычисляется следующим образом:
    1) расчет объема работ по разработке выполняется по формуле (2).

(2),
    где
        - Объем работ по разработке ПО - определяется в рабочих месяцах (РМ);
    - Программная производительность - определяется в SLOC/РМ;
    - Полученный размер - определяется в SLOC.
    Для определения программной производительности, используются данные из аналогичного программного проекта. Если данные аналогичного проекта недоступны, можно использовать таблицу 5. Показатели производительности, представленные в таблице 5, отражают процесс разработки ПО.
    Таблица 5. Производительность программной разработки для средних промышленных проектов

Характеристика	Производительность программной разработки (SLOC/РМ)
Классические показатели	130–195
Развивающиеся методы	244–325
Новое встроенное ПО	17–105

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

(3),
    где
    - Скорректированный_Объем_работ - определяется в рабочих месяцах (РМ);
    - Объем_работ - определяется в рабочих месяцах (РМ);
    - Множитель_объема_работ – определяется по данным таблицы 6.
    Таблица 6. Множители объема работ для программного наследования

Категория программного наследования	Множитель объема работ
Новый проект и новый код	1,2
Аналогичный проект и новый код	1,0
Аналогичный проект и код, используемый многократно	0,8
Аналогичный проект и расширенный код, используемый многократно	0,6

    3) скорректированный объем работ каждой функциональной и программной категории наследования суммируется, чтобы определить общий объем работ.
    6.4.2.3. Оценка трудозатрат на разработку программного обеспечения
    Трудозатраты на разработку ПО могут включать оплату работ специалистов сторонних организаций в соответствии с условиями заключенного контракта, а также оплату работ собственного персонала.
    6.4.2.3.1. Трудозатраты на аутсорсинг по разработке программного обеспечения
    Аутсорсинг определяется как отказ от разработки ПО собственным персоналом и приобретение услуг по разработке ПО у сторонних организаций.
    Аутсорсинг по разработке ПО может включать следующие виды услуг:
    1) разработка ПО;
    2) поддержка ПО;
    3) рефакторинг и реинжиниринг приложений;
    4) внедрение разрабатываемого ПО;
    5) документирование ПО;
    6) обучение персонала заказчика;
    7) консалтинг в области ИТ.
    При принятии решения об использовании аутсорсинга по разработке ПО необходимо учитывать следующие факторы:
    1) стоимость собственных разработок в соотношении со стоимостью услуг аутсорсинга;
    2) риски нарушения режима информационной безопасности;
    3) риски разрыва отношений с аутсорсинговой компанией и дальнейшее развитие созданного приложения;
    4) особенности организации и управления процессами разработки внутри компании;
    5) степень доверия сторонней организации определенной доли своих секретов.
    Аутсорсинг позволяет использовать опыт профессионалов, сократить риски и снизить затраты, увеличивая отдачу вложенных средств.
    К трудозатратам на разработку ПО специалистами сторонних организаций относится оплата работ по оказанию услуг по разработке ПО в соответствии с условиями заключенного контракта.
    6.4.2.3.2 Трудозатраты на разработку программного обеспечения собственным персоналом
    Оценка трудозатрат на разработку ПО определяется по количеству строк кода. Базовая формула оценки трудозатрат с использованием модели COCOMO II:

, (4)
    где
    - E - трудозатраты, выраженные в рабочих месяцах;
    - a, b - коэффициенты, которые зависят от режима использования модели (смотри таблицы 6, 7);
    - KSLOC - количество тысяч строк кода;
    - EAF - фактор корректировки трудозатрат.
    Режимы использования модели COCOMO II в зависимости от размеров численности команды и размера проекта приведены в таблице 7.
    Таблица 7. Режимы использования модели COCOMO II

Название режима	Размер проекта	Описание
Органичный	До 50 KSLOC	Некрупный проект разрабатывается небольшой командой, для которой не характерны нововведения и среда остается стабильной
Сблокированный	50–300 KSLOC	Относительно небольшая команда занимается проектом среднего размера, в процессе разработки необходимы определенные инновации, среда характеризуется незначительной нестабильностью
Внедренный	Более 300 KSLOC	Большая команда разработчиков трудится над крупным проектом, необходим значительный объем инноваций, среда состоит из множества элементов, которые не характеризуются стабильностью

Базовые значения коэффициентов модели СОСОМО II в зависимости от режима представлены в таблице 8.
Таблица 8. Базовые значения коэффициентов модели COCOMO II в зависимости от режима

Название режима	Значение коэффициента a	Значение коэффициента b
Органичный	2,4	1,05
Сблокированный	3,0	1,12
Внедренный	3,6	1,20

Фактор корректировки трудозатрат EAF увеличивает или уменьшает трудозатраты в зависимости от факторов среды разработки. Расчет фактора корректировки трудозатрат выполняется по формуле (5):

, (5)
    где
    - Ci – один из факторов среды разработки.
    Определение факторов корректировки трудозатрат EAF:
    1) фактор учета технологии разработки (ФУТР). Под этим фактором учитывается увеличение количества трудозатрат в результате вовлечения разного количества сотрудников.
    В этом процессе задействованы следующие категории сотрудников:
    - категория «А»: менеджер проекта; менеджер разрботки программной системы; менеджер внедрения ПО; менеджер эксплуатации; менеджер сопровождения ПО; аналитик бизнес-процессов; бизнес-проектировщик; системный аналитик; технолог бизнес–процессов;
    - категория «В»: программист; проектировщик программной системы; проектировщик пользовательского интерфейса; интегратор; технический писатель; системный администратор; администратор баз данных; специалист управления конфигурацией;
    - категория «С»: тестировщик; тестировщик службы сопровождения; разработчик тестов; аналитик службы сопровождения.
    Время тестирования является величиной зависимой от времени кодирования и определяется коэффициентом Ktest, который рассчитывается по формуле (6):

, (6)
    где
    - l - продолжительность процесса кодирования, выраженная в рабочих месяцах.
    - ltest - продолжительность процесса тестирования, выраженная в рабочих месяцах.
    Расчет фактора учета технологии разработки выполняется по формуле (7), выражается в рабочих месяцах:

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

, (8)
2) Фактор учета сложности и опыта разработки (ФУСОР) определяется эмпирически и состоит из значений, приведенных в таблице 9.
Таблица 9. Базовые значения коэффициентов фактора учета сложности и опыта разработки

Фактор учета сложности и опыта разработки	Значение
Надо поправить то, что есть	1,00
Уже делали раньше, есть опыт	1,10
Есть опыт и не видно трудностей	1,30
Опыта нет, но есть помощь	2,00
Нет ни опыта, ни помощи	4,00

    Этот способ оценки используется на начальной стадии проекта для оценки всего проекта в целом. Для небольших проектов и небольших по объему работ его использование затруднительно.
    6.4.3. Завершение оценки объема работ
    Цель данного шага состоит в расширении оценки для охвата всех категорий структурного разбиения работ. До этого шага, оценивались следующие категории структурного разбиения работ: «Проектирование ИС», «Разработка ПО» и «Тестирование ПО». Объем работ, например, таких как, «Управление программным объемом работ» и «Система обеспечения качества» является дополнительным по отношению к объему работ по разработке ПО.
    1) Для получения стоимостной оценки работ по всем перечисленным категориям необходимо к рассчитанному ранее объему работ прибавить дополнительный объем работ по разработке ПО. Дополнительный объем работ по разработке ПО – это отношение объема работ по разработке ПО для дополнительной деятельности к общему объему работ для всех рабочих элементов структурного разбиения работ, выраженное в процентах. Дополнительный объем работ по разработке ПО приведен в таблице 10.
    Таблица 10. Дополнительный объем работ по разработке ПО

Категория Структурного разбиения работ	Дополнительный объем работ по разработке ПО, %
Управление ПО	Прибавить 6–27%
Системный уровень поддержки тестирования	Прибавить 34–112%
Система обеспечения качества	Прибавить 6–11%
Независимая проверка	Прибавить 9–45%
Дополнительная деятельность:
управление конфигурацией проектов	Прибавить 3–6%
управление проектами	Прибавить 8–11%
управление поставками программного и аппаратного обеспечения	Прибавить 11–22%
доработка	Прибавить 17–22%
Эксплуатация, первые пять лет	Прибавить 22% объёма работ по разработке ПО за год эксплуатации

2) Суммируйте объем работ для каждой категории структурного разбиения работ, не относящейся к разработке ПО, чтобы получить общий объем работ. Декомпозиция объема работ основных категорий структурного разбиения работ согласно методике и статистическому анализу SEER–SEM представлена в таблице 11.
Таблица 11. Декомпозиция разработки ПО

Категория Структурного разбиения работ	% от объёма работ по разработке ПО
Разработка ПО:	100%
Анализ требований ПО	12%
Разработка ПО	55%
Внедрение ПО	13%
Программное интегрирование и тестирование ПО	20%

    SEER–SEM является широко используемой системой определения и оценки ресурсов ПО, созданной на основе комбинирования математики и статистики.
    Декомпозиция объема работ может проводиться согласно статистическому методу (приложение 1).
    Результаты этапа включают:
    1) объем работ по разработке ПО для всех категорий структурного разбиения работ (в рабочих месяцах);
    2) общий объем работ по разработке ПО.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 12.
    Таблица 12. Стоимость информационной системы на этапе «Оценка объема работ»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Идентификация Структурного разбиения работ
2	Идентификация рисков
3	Расчет объема работ по разработке ПО
4	Корректировка объема работ по разработке ПО
5	Оценка трудозатрат на разработку ПО
6	Расчет фактора корректировки трудозатрат
7	Определение дополнительных работ по разработке ПО
8	Определение объема дополнительных работ по разработке ПО
9	Декомпозиция разработки ПО
10	Административные расходы, связанные с оценкой объема работ
Итого:
Итого по этапу:

    6.5. Трудозатраты на кодирование и тестирование
    Целью данного этапа является определение периода времени и расчет трудозатрат на кодирование и тестирование, которые необходимы для завершения программного проекта, и сроков выполнения рабочих элементов структурного разбиения работ.
    6.5.1. Объем работ по кодированию и тестированию
    За основу оценки трудозатрат по разработке программной компоненты берется оценка трудозатрат по количеству строчек кода по формулам (4) и (5). Оценка каждого функционального требования выполняется отдельно, при этом значение константы b принимается равной 1, так как функциональное требование является составной частью проекта. Объем работ зависит от вида работы, а время его выполнения зависит от программной производительности. Программная производительность это величина, равная отношению объема проделанной работы ко времени, за которое она была совершена. Формула (4) преобразуется к виду, указанному в формуле (9):

, (9)
    где
    - Wj - программная производительность, необходимая для выполнения j–ого вида работы;
    - KSLOC(_i,j) - количество тысяч строк кода j–го вида работ для реализации i–го требования.
    Производительность W определяется опытным путем, исходя из опыта работы над предыдущими компонентами.
    6.5.2. Определение длительности кодирования и тестирования
    Кодирование – написание уже спроектированной программы на некотором формальном языке программирования. В процессе кодирования проверяются отдельные требования к ИС. Затем начинается интегральное тестирование системы как единого целого, которое начинается еще в процессе кодирования. Тестирование сопровождается проверкой исходного кода, поиском ошибок по их проявлениям в процессе выполнения программы.
    Длительность кодирования и тестирования, выраженная в рабочих месяцах, вычисляется по формуле (10):

, (10)
Распределить время для каждой категории структурного разбиения работ и определить допустимую рабочую нагрузку. После составления плана работ проверить распределение работ в соответствии с аналогичным опытом, используя таблицу 13 и таблицу 14. Числа в таблице 13 и таблице 14 представляют среднее, базовое расписание. Значимые отклонения от этих данных приведут к увеличению риска и повышению стоимости.
Таблица 13. Распределение времени по фазам разработки ПО, основанное на промышленных данных

Фаза	Промышленные данные (средства)
Анализ требований	18%
Разработка ПО	22%
Внедрение	36%
Программное интегрирование и тестирование	24%

Таблица 14. Распределение объема работ для нового, модифицированного или преобразованного ПО, основанного на промышленных данных

Фаза	Новое ПО	Существующее модифицированное ПО	Преобразованное ПО
Анализ требований проекта	20%	15%	5%
Рабочий проект, код и тест	57%	10%	5%
Интеграция и тестирование ПО	23%	40%	30%
Относительный объём работ	100%	65%	40%

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

, (11)
    При определении трудозатрат на тестирование важно учитывать трудозатраты персонала категории «С» (см. пункт 6.4.2.3) на составление планов тестирования (см. пункт 6.1.2).
    Один из ключевых элементов обеспечения качества - это тестирование. Процесс тестирования осуществляется в несколько этапов, которые отличаются видами выполняемых работ и привлекаемыми ресурсами.
    Первым этапом тестирования является внутреннее тестирование, на котором выполняется проверка функциональной полноты ИС, соответствие проектной документации, корректность проектных решений, а также контролируется соответствие законодательству.
    Следующим этапом является внешнее тестирование, на котором происходит концентрация усилий опытных экспертов, использующих различную методологию и разнообразные подходы к работе с ИС.
    Как на внутреннем, так и на внешнем тестировании постоянно проводится статистический анализ количества обнаруженных и исправленных ошибок, на основе результатов которого принимается решение о переходе к следующему этапу.
    На заключительном тестировании проводится проверка реализации максимального количества бизнес–процессов и исправление ошибок на предшествующих этапах.
    Для этого этапа тестирования необходимо выделить больше времени и трудовых ресурсов, чтобы гарантировать высокую надежность ИС. Высокий уровень методического, технического, организационного обеспечения тестирования на всех этапах предопределяет высокое качество ИС. Далее осуществляется опытная эксплуатация, которая позволяет выявить все нюансы, которые не были обнаружены на предыдущих этапах тестирования.
    Тестирование довольно высокотехнологичный и трудозатратный процесс, требующий у организации наличия в своем распоряжении широкого разнообразия аппаратных, программных и людских ресурсов. В некоторых случаях целесообразно использование аутсорсинга по тестированию.
    Аутсорсинг по тестированию - передача функций оценки качества ИС третьей стороне, профессионально занимающейся тестированием. Для обеспечения должного уровня проводимого тестирования необходимо обеспечить достаточную квалификацию тестировщиков, современные инструменты автоматизации тестирования, наличие оборудования, позволяющего имитировать ситуации реальной эксплуатации ИС.
    Доверяя тестирование ИС третьей стороне, необходимо обеспечить гарантию проверки и оценки именно тех аспектов, которые в этом нуждаются. Для этого разрабатываются план и сценарии тестирования, подробно описывающие, что, в какой последовательности, с какими приоритетами, с какой тщательностью, каким образом, с помощью каких инструментов и в какой среде будет тестироваться.
    Процесс тестирования в обязательном порядке должен быть документирован, а именно должны быть оформлены отчеты и протоколы тестирования, наглядно показывающие результаты и динамику проводимой оценки.
    Результаты этапа включают:
    1) определение трудозатрат на кодирование и тестирование;
    2) распределение сроков выполнения работ категорий структурного разбиения работ.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 15.
    Таблица 15.Стоимость информационной системы на этапе «Трудозатраты на кодирование и тестирование»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Определение объема работ по кодированию
2	Определение объема работ по тестированию
3	Определение фактора среды EAF
4	Расчет Фактора Учета Технологии Разработки
5	Расчет Фактора Учета Сложности и Опыта Разработки
6	Расчет длительности кодирования и тестирования
7	Расчет трудозатрат на кодирование и тестирование
8	Распределение времени по фазам разработки ПО
9	Составление плана работ по разработке ИС
10	Составление планов и сценариев тестирования
11	Административные расходы, связанные с оценкой трудозатрат на кодирование и тестирование
Итого:
Итого по этапу:

    6.6. Определение характеристик качества информационной системы
    Целью данного этапа является определение внутренних и внешних характеристик качества, методологии анализа качества, показателей качества, а также определение и оценка необходимых работ по улучшению качества ИС, которые требуют организационного, технического и методологического обеспечения.
    Для описания характеристик качества ИС выделяют следующие процессы:
    1) выбор и обоснование набора исходных данных, отражающих общие особенности и этапы жизненного цикла ИС, которые влияют на определенные характеристики качества ИС;
    2) выбор, установление и утверждение конкретных метрик и шкал измерения характеристик и атрибутов качества ИС для их последующей оценки и сопоставления с требованиями спецификаций в процессе квалификационных испытаний или сертификации на определенных этапах жизненного цикла ИС.
    6.6.1. Параметры качества
    На начальных этапах жизненного цикла детально определяются требования к ИС (см. пункт 6.1.1). Детализированные требования, необходимые для работы ИС, определяются характеристиками качества, которые уточняют и конкретизируют данные требования к их содержанию и реализации.
    При выборе параметров качества главными показателями являются: их адекватность целям качества, прозрачность и четкость интерпретации и экономическая эффективность получения результата.
    Параметрами качества являются:
    1) адаптируемость - мера гибкости системы, оценивает способность ИС адаптироваться к изменениям требований либо перепроектированием ИС, либо интеграцией приложений;
    2) сложность интерфейсов и интеграции - параметр, измеряющий степень сложности интерфейса или дополнительного объема работ по программированию, требуемого для интеграции компонент в ИС, которые требуются для тестирования, отладки и сопровождения;
    3) тестовое покрытие указывает степень полноты различных типов тестирования;
    4) надежность - параметр, оценивающий вероятность работы ИС без отказов;
    5) профили ошибок - параметр, измеряющаий кумулятивное число обнаруженных ошибок.
    Характеристики, субхарактеристики и атрибуты качества ИС с позиции возможности и точности их измерения разделяются на типы:
    1) категорийный – описательный, отражающий набор свойств и общие характеристики объекта. К данному типу относятся свойства ПО и наборов данных, которые охватывают назначения и функции ИС. Функциональная пригодность является самой важной и доминирующей характеристикой ИС;
    2) количественный - представляемый множеством упорядоченных, числовых точек, которые можно объективно измерить и численно сопоставить с требованиями. Значения таких характеристик влияют на функциональные возможности ИС. Такими характеристиками являются надежность и эффективность ПО. Надежность характеризуется временем наработки на отказ, средним временем восстановления, а также коэффициентом готовности. Количественные характеристики качества ИС приведены в таблице 16;
    Таблица 16. Количественные характеристики качества ИС

Характеристики качества	Единица измерения	Интервал значений
Надежность
Завершенность:
наработка на отказ при отсутствии рестарта	час	10–1000
Устойчивость:
наработка на отказ при наличии автоматического рестарта	час	10–1000
относительные ресурсы на обеспечение надежности и рестарта	%	10–90
Восстанавливаемость:
длительность восстановления	минута	10–2 – 10
Доступность–готовность:
относительное время работоспособного функционирования ИС	вероятность	0,7–0,99
Эффективность
Временная эффективность:
время отклика — получения результатов на типовое задание	секунда	1–1000
пропускная способность — количество типовых заданий, исполняемых в единицу времени	количество в минуту	1–1000
Используемость ресурсов:
относительная величина использования ресурсов при нормальном функционировании ПО	вероятность	0,7–0,99

3) качественный - содержащий несколько упорядоченных или отдельных значений, которые характеризуются порядковой или точечной шкалой, устанавливаются, выбираются и оцениваются субъективно и экспертно. Качественные характеристики ИС приведены в таблице 17.
Таблица 17. Качественные характеристики качества ИС

Характеристики качества	Единица измерения	Интервал значений
Практичность
Понятность:
четкость концепции ИС	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
демонстрационные возможности
наглядность и полнота документации
Простота использования:
простота управления функциями	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
комфортность эксплуатации	-
среднее время ввода заданий	секунда	1 – 1000
среднее время отклика на задание	секунда	1 – 1000
Изучаемость
трудоемкость изучения применения ИС	человеко–час	1 – 1000
продолжительность изучения	час	1 – 1000
объем эксплуатационной документации	страница	1 – 1000
объем электронных учебников	килобайт	1 – 1000
Привлекательность:
субъективные или экспертные оценки	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
Сопровождаемость	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
Анализируемость:
стройность архитектуры программ	человеко–час	1–1000
унифицированность интерфейсов	час	1–1000
полнота и корректность документации	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
Изменяемость:
трудоемкость подготовки изменений	человеко–час	1–1000
длительность подготовки изменений	час	1–1000
Стабильность:
устойчивость к негативным проявлениям при изменениях	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
Тестируемость:
трудоемкость тестирования изменений	человеко–час	1–1000
длительность тестирования изменений	час	1–1000
Мобильность
Адаптируемость:
трудоемкость адаптации	человеко–час	1–100
длительность адаптации	час	1–100
Простота установки:
трудоемкость инсталляции	человеко–час	1–100
длительность инсталляции	час	1–100
Сосуществование – соответствие:
стандартизация интерфейсов с аппаратной и операционной средой	-	Отличная; хорошая; удовлетворительная; неудовлетворительная
Замещаемость:
трудоемкость замены компонентов	человеко–час	1–100
длительность замены компонентов	час	1–100

    6.6.2. Внутренние и внешние характеристики качества информационной системы
    Качество ИС должны соответствовать внутренним и внешним характеристикам, состоящим из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:
    1) функциональная пригодность ИС:
    - пригодность для применения;
    - корректность (правильность, точность);
    - способность к взаимодействию;
    - защищенность;
    2) надежность ИС:
    - уровень завершенности (отсутствие ошибок);
    - устойчивость к дефектам;
    - восстанавливаемость;
    - доступность — готовность;
    3) эффективность ИС:
    - временная эффективность;
    - используемость ресурсов;
    4) применимость (практичность) ИС:
    - понятность;
    - простота использования;
    - изучаемость;
    - привлекательность;
    5) сопровождаемость ИС:
    - удобство для анализа;
    - изменяемость;
    - стабильность;
    - тестируемость;
    6) переносимость (мобильность) ИС:
    - адаптируемость;
    - простота установки — инсталляции;
    - сосуществование — соответствие;
    - замещаемость.
    Дополнительно каждая характеристика должна сопро-вождаться субхарактеристикой «согласованность», которая отражает отсутствие противоречий с нормативными документами.
    6.6.3. Характеристики качества программного обеспечения в использовании
    Внутренние и внешние характеристики качества относятся непосредственно к самой ИС, а характеристики качества в использовании проявляются в эффекте от ее применения и зависят от внешней среды. Между характеристиками качества существует взаимовлияние сверху вниз и зависимость снизу вверх, то есть повышение одной характеристики может привести к снижению другой, и наоборот.
    Основными характеристиками качества ПО в использовании должны являться:
    1) системная эффективность применения ПО по назначению;
    2) продуктивность - производительность при решении основных задач ИС, достигаемая при ограниченных ресурсах в конкретной внешней среде применения;
    3) безопасность - надежность функционирования комплекса ПО и возможный риск от его применения для людей, бизнеса и внешней среды;
    4) удовлетворение требований и затрат пользователей в соответствии с целями применения ИС.
    6.6.4. Методология оценки качества информа-ционной системы
    Для обеспечения полноты измерения качества ИС на ранних стадиях жизненного цикла ИС требуется разработать структурные параметры качества.
    Измерение качества ИС состоит в вычислении отклонения фактических характеристик ИС от нормативов.
    Методология создания параметров качества ИС состоит из следующих шагов:
    1) определение нетехнического уровня, предназначенного для менеджеров, пользователей, заказчика:
    - формирование требований качества;
    - выбор свойств качества, установка приоритетов и связи с требованиями;
    - определение допустимых коридоров для величин качества;
    2) определение технического уровня, предназначенного для аналитиков, конструкторов, разработчиков:
    - осуществление декомпозиции факторов качества в измеряемые характеристики ПО;
    3) определение нижнего уровня иерархии – уровень разработанных правил и норм, которым должна удовлетворять ИС для того, чтобы выполнялись факторы качества.
    Тщательно проведенная методологическая оценка качества ИС в соответствии с целями разработки ИС создает основу для корректного планирования и контроля затрат на качество для достижения требуемых показателей и эффективности работы ИС. Затраты на оценку качества ИС включают оплату труда специалистов собственной организации.
    Результаты этапа включают:
    1) определение характеристик качества;
    2) стоимость затрат на оценку качества ИС.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 18.
    Таблица 18. Стоимость информационной системы на этапе «Определение характеристик качества информационной системы»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Определение количественных характеристик качества ИС
2	Определение качественных характеристик качества ИС
3	Определение внутренних и внешних характеристик качества ИС
4	Оценка качества ИС
Итого:
Итого по этапу:

    6.7. Вычисление стоимости информационной системы
    Цель - оценка общей стоимости проекта по разработке ИС, охват поставок программного и аппаратного обеспечения и структурного разбиения работ.
    В общую стоимость ИС входят:
    1) капитальные затраты;
    2) операционные расходы.
    6.7.1. Капитальные затраты
    Капитальные затраты - расходы на приобретение новых и замещение старых долгосрочных материальных и нематериальных активов, используемых в процессе создания ИС.
    К капитальным затратам относится стоимость поставок:
    1) аппаратного обеспечения:
    - стоимость оборудования (полная стоимость оборудования без учета амортизации);
    - амортизационные расходы (амортизационный срок берется в зависимости от типа техники);
    - апгрейд (включает все обновления и изменения в аппаратной конфигурации, такие как: замена жестких дисков, установка дополнительных устройств. В отдельную подкатегорию сведены процессорные апгрейды);
    - память (расходы на увеличение объема памяти как клиентских мест, так и остальных устройств, содержащих модули памяти);
    - устройства хранения информации (дисководы, жесткие диски, карты памяти, носители, оптические приводы, системы хранения, стримеры, устройства хранения данных, флеш–накопители);
    - периферия (принтеры, сканеры, плоттеры и т. д.);
    - сетевое оборудование (концентраторы, коммутаторы, сетевые карты (кроме встроенных в клиентские компьютеры), маршрутизаторы, мосты и т. д.);
    2) ПО:
    - операционные системы;
    - стоимость лицензий;
    - приложения (включает в себя кроме стандартных офисных приложений еще и специализированное ПО, как разработанное самой компанией, так и произведенное третьими организациями);
    - обслуживающие программы (диагностические, отладочные, программы–дефрагментаторы, криптографические, антивирусные и прочие);
    - программы для коммуникаций: различные браузеры, протоколы передачи файлов FTP, почтовые программы, средства удаленного доступа и пр.
    - определение стоимости транспортных расходов, имеющих отношение к ИС.
    6.7.2. Операционные расходы
    Операционные расходы - затраты и платежи, связанные с проведением за определенный период времени финансовых, производственных, хозяйственных операций, связанных с процессом поддержки ИС. Операционные расходы включают затраты на производство и реализацию продукции и/или предоставление услуг, административные и финансовые расходы.
    К операционным расходам относятся:
    1) платежи - оплата арендованного аппаратного и программного обеспечения и прочие расходы на компьютерное оборудование, не подпадающие ни под одну из перечисленных категорий;
    2) управление:
    - управление сетью;
    - диагностирование и ремонт;
    - управление и планирование трафика;
    - оптимизация производительности (выполняется системным администратором и включает в себя выявление узких мест в сети и принятие соответствующих мер);
    - администрирование пользователей (добавление, удаление, изменение прав);
    - поддержка операционных систем;
    - текущие регламентные работы (профилактика);
    - прочие работы по управлению сетью;
    3) управление системой:
    - изучение и планирование развития системы;
    - определение стоимости и закупка оборудования;
    - лицензирование и дистрибуция программного обеспечения;
    - управление имуществом (оборудованием);
    - управление приложениями;
    - контроль за секретностью и защита от вирусов;
    - конфигурирование и перенастройка оборудования;
    - установка оборудования;
    - прочие вопросы управления системой;
    - управление устройствами хранения данных;
    - управление дисками и файлами;
    - планирование емкости устройств хранения данных;
    - управление доступом к данным;
    - архивирование и резервное копирование;
    - прогнозирование неисправностей и восстановление;
    - управление репозиторием;
    - остальные виды управления;
    4) поддержка:
    - оперативная работа;
    - помощь административного персонала;
    - нерегулярное обучение (административный состав);
    - поддержка производителя;
    - поддержка, осуществляемая сторонними организациями (аутсорсинг);
    - обучение административного персонала;
    - обучение конечного пользователя;
    - затраты на передвижения;
    - закупки;
    - прочие расходы на оперативную работу;
    - контракты на поставку;
    - контракты на поддержку;
    - учебные курсы и сертификация;
    5) определение профессионального уровня и заработной платы персонала.
    Результаты этапа включают:
    1) стоимость поставок программного и аппаратного обеспечения;
    2) определение стоимости категорий структурного разбиения работ;
    3) общая оценочная стоимость ИС.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 19.
    Таблица 19. Стоимость информационной системы на этапе «Вычисление стоимости информационной системы»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Оценка общей стоимости проекта по разработке ИС
2	Выполнение текущих регламентных работ
3	Изучение и планирование развития ИС
4	Административные расходы, связанные с вычислением стоимости ИС
Итого:
Итого по этапу:

    6.8. Определение влияния рисков
    Целью данного этапа является определение рисков проекта для оценки их влияния на стоимость разработки.
    6.8.1. Оценка влияния рисков на стоимость информационной системы
    Риски оцениваются следующим образом:
    1) основываясь на начальном списке рисков (см. пункт 6.4.1) идентифицировать основной риск, который оказывает наибольшее влияние на оценку ИС;
    2) оценить общее влияние рисков (см. таблицы 20 и 21). Общее влияние рисков получается путем умножения величин оценки влияния рисков на стоимость всех причин риска. Оценка влияния рисков на стоимость приведена в таблице 21;
    Таблица 20. Оценка причин рисков

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

Таблица 21. Оценка влияния рисков на стоимость

Причины риска	Оценка влияния на стоимость
Причины риска	Высокое	Очень высокое	Наивысшее
Опыт и навыки работы в команде	1,02	1.05	1.08
Планирование	1,10	1,17	1,25
Проектирование	1,05	1,13	1,2
Кадровое обеспечение	1,02	1,05	1,13
Тестирование	1,05	1,08	1,15
Инструментальные средства	1,02	1,03	1,1
Максимум ожидаемое влияние	1,3	1,6	2,32

3) определить влияние рисков на стоимость ИС по формуле (12):

(12)
    Вычисление стоимости ИС приведено в подразделе 6.7;
    4) регулировать оценку риска путем добавления общего фактора риска к стоимости по формуле (13):

(13),
    где
    - Влияние – влияние рисков на стоимость ИС.
    - Вероятность случая определяется опытным путем, для этого используется статистический подход, помогающий изменять априорные оценки с учетом данных новых исследований.
    6.8.2. Влияние информационной безопасности на функционирование информационной системы
    Для минимизации влияния рисков функционирования ИС необходимо соблюдение и контроль требований по обеспечению информационной безопасности ИС.
    К требованиям по обеспечению информационной безопасности ИС относятся:
    1) планирование обеспечения информационной безопасности - план обеспечения безопасности и правила поведения сотрудников;
    2) реагирование на инциденты нарушения информационной безопасности;
    3) действия по обеспечению информационной безопасности в непредвиденных ситуациях – план действий в непредвиденных ситуациях, резервирование телекоммуникационных сервисов, резервное копирование и хранение информации, восстановление данных;
    4) требования к оцениванию рисков и уязвимостей;
    5) требования к защите носителей информации - маркировка, хранение, транспортировка, очистка, передача и уничтожение носителей информации;
    6) требования к обеспечению целостности информации;
    7) требования к физической защите ИС;
    8) требования к безопасности эксплуатирующего персонала, а также к его информированию и обучению вопросам безопасности;
    9) требования идентификации и аутентификации;
    10) требования к управлению доступом.
    Обеспечение информационной безопасности включает затраты на аппаратные и программные средства защиты, затраты на оплату труда специалистов информационной безопасности как сторонних организаций, так и собственного персонала.
    Результаты этапа включают:
    1) подробный список рисков ИС;
    2) определение требований по обеспечению информационной безопасности;
    3) переоцененные характеристики: размер, объем, план работ, проектная стоимость с учетом рисков.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 22.
    Таблица 22. Стоимость информационной системы на этапе «Определение влияния рисков»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Оценка влияния рисков на стоимость
2	Регулирование оценки риска
3	Регулирование затрат, основанных на оценке риска
4	Административные расходы, связанные с определением влияния риска на стоимость
5	Обеспечение информационной безопасности
Итого:
Итого по этапу:

    6.9. Подтверждение и корректировка оценки стоимости рисков
    Целью этапа является подтверждение и корректировка оценки стоимости рисков.
    Первоначальный список рисков (см. пункт 6.4.1) дополняется списком рисков, используя:
    1) альтернативную оценку: привлечение человека или группы с соответствующим опытом для независимой экспертной оценки;
    2) исторические аналогии: используя предыдущий опыт, следует сравнить оценку по следующим параметрам:
    - размер, объем работ и стоимость аналогичного ПО;
    - отношение размера к назначению ПО;
    - отношение размера к объему работ и стоимости (продуктивность разработки);
    - отношения технологии, примененной при разработке к объему работ и цене.
    Для выполнения данной задачи необходимо сравнить первоначальный список рисков (см. пункт 6.4.1) с дополнительными рисками, полученными в предыдущем пункте, определить разницу и составить новый список рисков для получения более точных показателей.
    В дальнейшем необходимы управление и корректировка полученного списка рисков.
    Реализация процесса управления рисками включает:
    1) оценку рисков в течение всего жизненного цикла ИС;
    2) определение и классификацию рисков;
    3) количественное определение неблагоприятных воздействий рисков;
    4) определение мер по предотвращению рисков;
    5) определение стратегии управления каждым выявленным риском;
    6) составление отчетности о рисках и их состоянии.
    Результаты этапа:
    1) подтверждение правильности оценки;
    2) подтвержденные и скорректированные: объем работ, сроки выполнения, сметные затраты, полученные с повышенной точностью.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 23.
    Таблица 23. Стоимость информационной системы на этапе «Подтверждение и корректировка оценки стоимости рисков»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала	Стоимость учебных курсов и сертификации
1	Оценка рисков независимой экспертной группой
2	Анализ статистических данных в данной области
3	Сравнение оценок рисков
4	Регулирование оценки рисков
5	Административные расходы, связанные с подтверждением и корректировкой оценки стоимости рисков
Итого:
Итого по этапу:

    6.10. Внедрение информационной системы
    Цель этапа состоит в:
    1) повышении производительности труда персонала;
    2) снижении трудоемкости конкретных процессов за счет единого информационного пространства;
    3) уменьшении ошибок за счет расширения возможностей анализа и проверок информации в ИС.
    Этап внедрения начинается со следующего:
    1) получение разрешения на установку ИС в местах ее функционирования;
    2) подготовка инфраструктуры пользователя и оборудования помещений, в которых будет осуществляться функционирование ИС;
    3) проверка работоспособности ИС в реальных условиях эксплуатации;
    4) организация обучения персонала работе с ИС или ее компонентами.
    Задачи внедрения ИС являются комплексными, так как их решение предполагает проведение целого ряда мероприятий, к числу которых относятся следующие:
    1) концентрация людских и финансовых ресурсов для решения задачи внедрения ИС;
    2) разработка концепции создания единой ИС;
    3) обучение пользователей;
    4) обучение администраторов и узконаправленных специалистов;
    5) адаптация ИС к специфике процессов в организации;
    6) реализация пилотного проекта ИС;
    7) разработка нормативной базы для работы в новых технологиях;
    8) полномасштабное внедрение ИС в практику работы организации.
    Для выполнения задач внедрения ИС необходимо составление плана внедрения ИС.
    Стандартный план внедрения ИС включает в себя следующие этапы:
    1) планирование внедрения – назначение менеджера проекта, обеспечение информированности сотрудников, подбор сотрудников в группу внедрения ИС;
    2) установка системы - установка, тестирование и проверка корректности настройки ИС;
    3) запуск пилотного проекта – обучение пользователей, перевод пользователей на новую ИС, сбор отзывов пользователей и доработка ИС в случае необходимости, назначение группы лиц, ответственных за сопровождение ИС (менеджер процесса внедрения);
    4) полномасштабное внедрение ИС в работу организации.
    Результаты этапа включают:
    1) обучение пользователей;
    2) разработка документации по внедрению;
    3) реализация пилотного проекта ИС, а затем полномасштабное внедрение ИС.
    На данном этапе в стоимость ИС будут включены компоненты затрат, указанные в таблице 24.
    Таблица 24. Стоимость информационной системы на этапе «Внедрения информационной системы»

№ п\п	Компоненты затрат	Стоимость работ сторонних организаций	Стоимость работ собственного персонала
1	Разработка плана внедрения
2	Обучение пользователей
3	Установка ИС
4	Адаптация ИС к специфике процессов организации
5	Реализация пилотного проекта ИС
6	Реализация полномасштабного внедрения ИС
Итого:
Итого по этапу:

Общая стоимость информационной системы на всех этапах представлена в таблице 25.
Таблица 25. Общая стоимость информационной системы

№ этапа	Название этапа	Стоимость
1	Сбор и анализ требований к ИС
2	Определение структурных единиц и стоимости поставок программного и аппаратного обеспечения
3	Оценка размера программной части ИС
4	Оценка объема работ
5	Трудозатраты на кодирование и тестирование
6	Определение характеристик качества ИС
7	Вычисление стоимости ИС
8	Определение влияния рисков
9	Подтверждение и корректировка оценки стоимости рисков
10	Внедрение ИС
Итоговая стоимость ИС:

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

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

(14)
    Аналогично рассчитываются границы сроков выполнения работ;
    2) сравниваются проектная стоимость, сроки выполнения работ и границы бюджета проекта для определения их согласованности;
    3) если оценка существенно превышает запланированные величины, то следует определить и устранить различия. Для этого следует:
    - максимально детализировать требуемые границы и функциональность, анализируя и определяя приоритеты функций, для того, чтобы идентифицировать функции, которые могут быть устранены. Следует принимать во внимание зависимость между функциями;
    - прекратить поставки, в которых нет необходимости;
    - проверить сроки выполнения работ, сметную стоимость и риски, влияющие на базовую стоимость. Уменьшить риск и издержки за счет уменьшения функциональности или объема поставок;
    - повторить данный процесс, пока функциональность и поставки не войдут в допустимые пределы, по отношению к бюджету и срокам выполнения работ;
    - согласовать уменьшение функциональности, снижение объема поставок и соответственно пересмотренные затраты для достижения соглашения. Скорректировать структурное разбиение работ согласно пересмотренной функциональности.
    7.2. Документация и отчетность произведенной оценки стоимости информационной системы
    Цель - проверить точность оценки стоимости ИС и обеспечить аналогичное оценивание для будущих программных проектов.
    В процессе жизненного цикла ИС с каждым бизнес–процессом связана документация, которая либо подается на вход, либо получается на выходе данного процесса.
    Следует проанализировать оценку для определения сроков и причин, по которым проект может выйти за границы запланированных затрат, вследствие чего необходимо:
    1) изменить документацию в процессе определения стоимости ИС. Документация - это результат записи информации, полученной в ходе действий или процессов жизненного цикла программной системы;
    2) для улучшения показателей оценки и планирования скорректировать оценку на каждом этапе.
    Необходимо задокументировать следующую информацию:
    1) опорную информацию о проекте:
    - название проекта;
    - организация-разработчик;
    - платформа;
    - язык программирования;
    - метод оценок;
    - дата утверждения стоимости проекта;
    2) оцененный и фактический размер, объем работ, стоимость аппаратного и программного обеспечения;
    3) запланированные и фактические даты основных этапов;
    4) идентифицировать риски и их предполагаемое и фактическое влияние.
    В процессе проектирования разработки и внедрения ИС составляется следующая документация в соответствии с RT 38370656-002:2006:
    1) план руководства проектом;
    2) календарный план реализации проекта;
    3) концепция ИС;
    4) бизнес-предложение;
    5) техническое задание;
    6) технический проект;
    7) инструкция по эксплуатации ИС;
    8) руководство администратора;
    9) план тестирования;
    10) протокол тестирования;
    11) акт передачи в опытную эксплуатацию;
    12) акт о завершении разработки;
    13) календарный план процесса перехода;
    14) акт передачи в эксплуатацию;
    15) акт ввода в эксплуатацию;
    16) предложение о модификации;
    17) сообщение о проблеме;
    18) журнал регистрации обращений.
    Документация содержит справочные сведения о проекте ИС и контрактов, заключенных в процессе проектирования, разработки и внедрения.

Приложение 1

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

    В качестве методов оценки программной части ИС можно применять:
    Метод аналогии - применяется при многократном использовании или для модифицируемых функций. Метод аналогии широко используется как модель – аналог объекта, изучаемого посредством моделирования. Применяется аналогия экспертного решения или аналогия исторических данных. Экспертное решение основано на опыте с аналогичной функцией, тогда как аналогия исторических данных на прошлых проектах, сходстве и различиях в функциональных требованиях.
    Статистический метод (PERT). Применяется для аналогичных или новых функций, где опыт и исторические данные ограничены, или для проектов с неопределенными или неполными требованиями. Оценка программной части ИС происходит следующим образом:
    1) первый независимый эксперт определяет минимально возможный размер программной части ИС (Least);
    2) второй независимый эксперт определяет максимальный возможный размер программной части ИС (Most);
    3) третий независимый эксперт, используя в том числе и исторические данные, определяет наиболее вероятный размер программной части ИС (Likely);
    4) вычисляется размер программной части ИС (Mean):
    Mean = (Least + 4*Likely + Most)/6.
    Этот метод компенсируется тем, что оценивание устремляется к более низкому пределу, чем к верхнему пределу.
    Если размер оценивания основан на исторических базах данных, использовавших физические строки кода или аналогии в проектах, следует преобразовать физические строки кодовой оценки размера в логические строки, используя таблицу 1.1.
    Таблица 1.1. Преобразование размера оценивания

Язык программирования	Логические SLOC
Assembler и Fortran	Физические SLOC = Логические SLOC
Языки программирования третьего поколения (C, Cobol, Pascal, Ada 83)	Уменьшение физических SLOC на 25%
Языки программирования четвертого поколения (SQL, Perl, Oracle)	Уменьшение физических SLOC на 40%
Объектно–ориентированные языки программирования (Ada 95, C++, Java, Python)	Уменьшение физических SLOC на 30%

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

Язык программирования	Преобразование автогенерированного кода в логические SLOC по:
Язык программирования	Least	Likely	Most
Второго поколения	-	1	-
Третьего поколения	0,22	0,25	0,4
Четвертого поколения	0,04	0,06	0,13
Объектно–ориентированные	-	0,09	0,17