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

Порядок предъявления подсистем АС СОТОВЫЙ, их испытаний и окончательной приемки определен в Частных Технических Заданиях на разработку соответствующих подсистем АС ГЗ.

НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ

Назначение системы

АС СОТОВЫЙ состоит из ПК, периферийных устройств, линий связи, персонала и информации.

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

Также система предназначена для:

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

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

Цели создания системы

Целью создания АС СОТОВЫЙ является:

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

– выполнение требований нормативных правовых актов Российской Федерации, руководящих документов ФСТЭК России, ФСБ России, регламентирующих вопросы обработки хранения конфиденциальных данных;

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

– обеспечение доступности информационных ресурсов санкционированным пользователям АС СОТОВЫЙ;

– выполнение всех требований, предъявляемых законодательством к АСЗИ.

ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ

Объектом автоматизации АС СОТОВЫЙ является подразделение ЗАО «МТС», осуществляющее сбор, накопление, обработку, анализ конфиденциальной информации, относящейся непосредственно к сфере деятельности предприятия.

Состав общесистемного программного обеспечения

Состав используемого общесистемного программного обеспечения приведен в таблице ниже (таблица 1).

Таблица 1. Состав общесистемного программного обеспечения

Основные роли пользователей

В системах АС СОТОВЫЙ должны быть предусмотрены следующие роли пользователей:

– Администратор – представитель технического персонала, обеспечивающего работоспособность и безопасность системы;

– Администратор безопасности – представитель технического персонала, ответственный за обеспечение информационной безопасности;

– Пользователь – лицо, непосредственно участвующее в работе АС.

Роли могут подвергаться декомпозиции на этапе технического проектирования систем АС СОТОВЫЙ.

ТРЕБОВАНИЯ К СИСТЕМЕ

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

Разработка АС СОТОВЫЙ должна вестись с учётом следующих требований:

– АС СОТОВЫЙ должна быть выполнена на базе ЭВМ стандартной конфигурации в составе одного АРМ: 2048 Мб ОЗУ, накопитель на жестком диске емкостью 200 Гб, цветной Ж/К монитор (диагональ 15.6»), клавиатура, манипулятор типа «мышь»;

– В АС предусмотрено одно устройство печати;

– АС СОТОВЫЙ должна быть подключена к гарантированной системе электропитания с использованием агрегатов бесперебойного питания;

– АС СОТОВЫЙ должна обеспечить надежное хранение данных и бесперебойную работу СВТ, входящих в состав АС;

– В АС СОТОВЫЙ должна быть реализована оптимальная организация данных с точки зрения скорости выполнения операций загрузки информации и запросов пользователей;

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

– АС СОТОВЫЙ должна быть отделена от ЛВС предприятия;

– В состав АС должно входить только лицензионное ПО;

– АС должна соответствовать требованиям, предъявляемым к АСЗИ;

– разработка АС СОТОВЫЙ должна максимально сократить дублирование функционала существующих и создаваемых информационных систем, участвующих в обеспечении процессов ЗАО «МТС»;

– АС СОТОВЫЙ должна максимально упростить работу пользователей и снизить эксплуатационные затраты за счёт автоматизации процессов;

– системный подход к разработке АС СОТОВЫЙ должен опираться на новейшие направления развития информационно-коммуникационных технологий;

4.1.1 Требования к структуре и функционированию системы

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

4.1.2 Требования к численности и квалификации персонала

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

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

4.1.3 Требования к показателям назначения

АС СОТОВЫЙ должна позволять производить корректировку алгоритмов управления в случае изменения технологического процесса объекта. Для этого: использовать программные методы централизованного контроля и управления; предусмотреть запас по объёму памяти ОЗУ на уровне – не менее 15%; предусмотреть свободные места для расширения системы – не менее 10%.

4.1.4 Требования к надежности

АС СОТОВЫЙ должна быть многоканальной, многофункциональной системой длительного пользования и являться ремонтопригодным объектом с периодическим техническим обслуживанием. Требования к показателям надёжности системы устанавливаются в соответствии с ГОСТ 24.701—84.

Требования к безотказности АС СОТОВЫЙ устанавливаются для отдельных функций.

Средняя наработка АС СОТОВЫЙ на отказ типа «Пропуск аварии» при работе в нормальных условиях без учёта первичных преобразователей и исполнительных механизмов должна быть не менее 100000 часов.

Критерием отказа типа «Пропуск аварии» является событие, заключающееся в отсутствии команды управления аварийным остановом ТКА на выходе АСУ ТП КЦ при наличии любого из аварийных сигналов на её входах.