какие ас должны быть отображены на карте приложений блока

Автоматизированные системы Сбербанка

Содержание

Сбербанк

На июнь 2015 года «Сбербанк» делит свои автоматизированные системы по 11 основным направлениям:

Core banking

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

Системы FrontEnd

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

Также к FrontEnd системам относятся:

Процессинговые системы

Фабрика данных

BI-системы

В «Сбербанке» существует Центр компетенции развития BI. По данным одного из выпусков корпоративной газеты для сотрудников «Сбербанк Технологии», в ведении центра находятся: программно-аппаратный комплекс Teradata, включающий аналитическое хранилище данных, оперативное хранилище данных Oracle Exadata и еще одна система – витрины MIS.

Управление метаданными

Основной целью создания единой базы метаданных является автоматизация и повышение качества бизнес-процессов [2] :

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

Кредитные АС

АС по управлению рисками

АС по управлению инвестициями

АС по управлению внутрихозяйственной деятельностью и персоналом

АС платформы BPM

Создание BPM-системы полного цикла в сбербанке

Единая модель процесса

Система связанных процессов

E2E-процессы вместо Продуктовых процессов Разделение процессов на 2 уровня:

Концентрация на E2E-процессах для повышения ценности для клиентов:

Непрерывное совершенствование & трансформация процесса

Интеграция с корпоративной архитектурой (КА)

Из презентации Бутыркин Вячеслав Алексеевич, 15.02.2018 на конференции CNews BPM-системы

Источник

Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка

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

Disclaimer
Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.

Глава 1. Общее описание ИТ-инфраструктуры

Основные термины

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

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

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

Справедливость подобного подхода можно доказать тем, что в Приказе ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» для защиты информационных систем госрегулятор предписывает руководствоваться ГОСТами по автоматизированным системам.

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

Дать определение понятию информационный сервис довольно сложно, поэтому просто перечислим его основные отличия от информационной системы:

Автоматизированная банковская система

Ядром информационной инфраструктуры любого банка является автоматизированная банковская система или сокращенно АБС.

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

Данное определение позволяет подвести под него практически любую IT-систему в банке. В то же время обычные банковские служащие называют АБС ту систему, которая занимается учетом банковских счетов, проводок между ними (движением денежных средств) и остатков. Второе определение не противоречит первому и более четко его детализирует, им и будем пользоваться дальше.

В современных Российских банках наиболее распространенными являются следующие АБС :

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

Прикладные информационные системы

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

Примерами прикладных информационных систем могут быть:

Инфраструктурные информационные системы

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

Информационные сервисы

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

Клиентские части сторонних информационных систем

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

Типовые способы интеграции информационных систем

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

Модули интеграции

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

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

Пример ИТ-инфраструктуры банка

На Рис.1 можно увидеть фрагмент типовой информационной инфраструктуры банка, содержащий рассмотренные выше типы элементов.

Глава 2. Инфраструктура безналичных расчетов

Если посмотреть на эту схему (Рис.1) с точки зрения осуществления безналичных расчетов, то можно увидеть, что банк реализует их при помощи:

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

Инфраструктура обеспечения платежного взаимодействия с Банком России

Рис. 2.
IT-инфраструктуру платежного взаимодействия банка с Банком России будем рассматривать на примере исполнения платежа, отправляемого в адрес клиента другого банка.

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

Если клиент передал платежное поручение на бумажном носителе, то работник банка на его основании делает электронное платежное поручение в АБС. Если распоряжение было подано через ДБО ИКБ, то через модуль интеграции оно попадает в АБС автоматически.

Доказательством того, что именно клиент сделал распоряжение о переводе денежных средств, в первом случае является лично подписанный им бумажный документ, а во втором, электронный документ в ДБО ИКБ, заверенный в соответствии с договором.

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

Попав в АБС, платежное поручение в соответствии с внутренними регламентами банка проходит контроль и передается для исполнения в платежную систему Банка России.

Технические средства взаимодействия с платежной системой Банка России

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

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

АРМ КБР

АРМ КБР – это ПО, с помощью которого уполномоченные работники банка осуществляют шифрование и электронную подпись исходящих платежных документов, а также расшифровку и проверку электронной подписи платежных документов, поступающих из Банка России. Но, если быть более точным, то АРМ КБР в своей работе оперирует не платежными документами, а электронными сообщениями (ЭС), которые бывают двух типов:

Для того чтобы АРМ КБР мог обработать платеж, он должен быть преобразован в файл, содержащий электронное платежное сообщение формата УФЭБС. За подобное преобразование отвечает модуль интеграции АБС с платежной системой Банка России. С технической точки зрения подобные преобразования довольно просты, поскольку формат УФЭБС основан на XML.

Файлы электронных сообщений покидают модуль интеграции АБС в открытом виде и помещаются в специальную папку файловой системы (обычно это сетевая папка), которая настроена в АРМ КБР для электронных сообщений, имеющих статус «Введенные». На ранее представленной схеме (Рис. 2.) эта папка обозначена как «Папка 1».

Затем в процессе обработки электронные сообщения меняют свои статусы на «Контролируемые», «Отправленные» и т. д., что технически реализуется путем перемещения файла с электронным сообщением в соответствующие папки, которые настроены в АРМ КБР. На схеме (Рис. 2.) эти папки обозначены как «Папка 2».

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

СКАД Сигнатура

СКАД Сигнатура, это СКЗИ, разработанное компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ нет в открытом доступе (кроме документации, размещенной на сайте ЦБ РФ), и оно распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:

Зашифрованные и подписанные электронные сообщения помещаются в специальную папку, на схеме (Рис. 2.) это «Папка 3». УТА непрерывно мониторит эту папку и, если он видит там новые файлы, передает их в ЦБ РФ одним из следующих способов:

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

Получив зашифрованное электронное сообщение, УТА перекладывает его в папку с входящими зашифрованными сообщениями. Уполномоченный работник с помощью своих криптоключей и АРМ КБР проверяет электронную подпись и расшифровывает сообщение.

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

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

Альтернативные схемы обработки

Мы рассмотрели «классическую» схему работы системы. В реальности существует множество ее разновидностей. Рассмотрим некоторые из них.

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

Разновидность 2. Полный автомат
АРМ КБР настраивается на работу полностью в автоматическом режиме без участия человека

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

Перенос электронной подписи из АРМ КБР в АБС

Банк России планирует перейти на новую технологическую схему обработки платежей, при которой электронные сообщения будут подписываться не в АРМ КБР, как было ранее, а в АБС (точнее в модуле интеграции АБС — АРМ КБР).

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

Рассмотрим схему информационных потоков в классическом АРМ КБР. Источник схемы – официальная документация на АРМ КБР «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ. Руководство программиста. ЦБРФ.61209-04 33 01».

Рис. 3.
Примечания.

Рис. 4.

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

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

Помимо файлового интерфейса взаимодействия между АБС, АРМ КБР-Н и УТА добавлен интерфейс IBM WebSphere MQ, что позволяет строить сервис-ориентированную ИТ-инфраструктуру банка и решить проблему старой схемы с организацией одновременной работы нескольких операторов, ответственных за отправку платежей.

Источник

Архитектура АС

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

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

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

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

-оперативное корректирующее управление запасами и
производственными ресурсами;

— мониторинг и управление качеством производства;

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

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

— автоматизированное накопление и хранение производственного опыта в

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

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

Стандарт ISO 15704 определяет архитектуру отдельной информационной системы как «описание (модель) основного взаиморасположения и взаимосвязей частей системы (будь то физический или концептуальный объект/ сущность) «.

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

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

профиль прикладного программного обеспечения;

профиль защиты информации в АС;

профиль инструментальных средств, встроенных в АС. Основными целями применения профилей при создании и применении АС являются:

•снижение трудоемкости, длительности, стоимости и улучшение других технико-экономических показателей проектов АС;

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

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

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

• обеспечение переносимости прикладного программного обеспечения между разными аппаратно-программными платформами.

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

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

Концептуальная модель архитектуры OSE/RM предусматривает
разбиение ПО АС на приложения (прикладные программные комплексы),
реализующие заданные функции АС, и среду взаимодействия,

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

программирования (API) (рис.1).

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

приложений промышленной автоматизации. Их применение при проектировании архитектуры АС решает вопросы обмена данными с

Рис. 1 Концептуальная OSE/RM модель ПО АС

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

• OPC DA (Data Access) описывает набор функций обмена данными в реальном времени с ПЛК и другими устройствами;

• OPC HDA (Historical Data Access) предоставляет доступ к уже сохраненным данным;

• OPC Security определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер;

• OPC XML-DA (XML-Data Access) предоставляет гибкий, управляемый правилами формат обмена данными через интранет среду.

Рис.2 Структура ОРС взаимодействий

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

На данный момент используется OPC версии 3.0, однако более распространенной версией пока является 2.1. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.

На рис.2 показана структура ОРС взаимодействий SCADA автоматизированной газораспределительной станции (АГРС), реализуемая опциональными программными компонентами ф. Rockwell Automation.

На рисунке показаны:

ИБП- источник бесперебойного питания, который посредством SNMP связан со SCADA приложениями.

SNMP (англ. Simple Network Management Protocol — простой протокол управления сетью) — это протокол управления сетями связи на основе архитектуры TCP/IP. Этот менеджер предназначен для мониторинга состояния сети АС и управления сетевыми устройствами, в частности, в случае несанкционированного выключения энергии. Используя решения на базе SNMPc, удается контролировать всю сетевую инфраструктуру, управляя сетевым оборудованием различных типов, наблюдать за работой служб OSE/RM и анализировать отчеты по их работе за заданный период.

Информационный обмен данными в АС строится с использованием стандарта ODBC (Open DataBase Connectivity).

В соответствии с проектным решением, представленном на этом рисунке, управление технологическим процессом на АГРС со стороны диспетчеров происходит с использованием ключевых команд и только от одного диспетчера одновременно. Работу с тремя автоматизированными системами осуществляет ОРС-сервер. С ним же работают клиенты: ОРС-клиент SCADA-системы ClearSCADA, ОРС-клиент SCADA-системы PSI (программы для мгновенного обмена сообщениями посредством сети Интернет). В реализованной Системе ОРС-клиент ClearSCADA установлен на одной машине с ОРС-сервером, а ОРС-клиент PSI установлен за несколько сотен километров от них. Интранет клиенты SCADA-сервера ViewX и WebX используются диспетчерами на самой АГРС и удалённо по защищённому Internet (протокол https).

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

Анализ проектных решений комплексной автоматизации показывает, что предприятия тратят около 35–40 % своего бюджета, отводимого на поддержку информационных технологий, на работы по организации обмена данными между приложениями и СУБД. Столь высокий процент затрат объясняется несовместимостью форматов данных между унаследованными приложениями и стандартами применяемых СУБД «островной автоматизации». Вот почему необходимо использовать единый стандарт управления базами данных. В начале 1990 г. существовало несколько поставщиков баз данных, каждый из которых имел собственный интерфейс. Если приложению было необходимо общаться с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать свой код. Для решения возникшей проблемы Microsoft и ряд других компаний создали стандартный интерфейс для получения и отправки данных источникам данных различных типов. C помощью ODBC прикладные программисты могут разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками.

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

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

Профиль среды распределенной АС должен включать стандарты протоколов транспортного уровня (по ISO OSI или стандарту де-факто протокола TCP/IP), стандарты локальных сетей (например стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u ), а также стандарты средств сопряжения проектируемой АС с сетями передачи данных общего назначения (в частности, RS-485, сети CAN, ProfiBus и др.).

Стандарт PROFINET (IEC 61158) предназначен для коммуникационной части систем промышленной автоматизации. Он обеспечивает доступ к устройствам полевого уровня (датчикам, машинным контроллерам, исполнительным устройствам) со всех уровней управления предприятием. Стандарт позволяет выполнять широкий обмен данными, поддерживает проектирование ИКСУ в масштабах предприятия и использует IT стандарты вплоть до полевого уровня. Он поддерживает практически все существующие сети полевого уровня (PROFIBUS, Ethernet, AS-I, CAN, LonWorks и др.). Все они могут быть интегрированы в PROFINET без модификации установленной аппаратуры.

PROFINET базируется на стандарте Industrial Ethernet и использует стандарт TCP/IP (транспортный протокол/ Internet протокол) для выполнения операций настройки параметров, конфигурирования и диагностики. Обмен данными в реальном масштабе времени выполняется через стандартные каналы связи Ethernet параллельно со стандартными вариантами обмена данными в сети Ethernet.

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

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

Функциональная область защиты информации включает в себя функции защиты, реализуемые разными компонентами АС:

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

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

• функции управления данными, реализуемые СУБД;

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

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

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

распределенных системах являются рекомендации X.800, принятые МККТТ в 1991 г. (сейчас ITU-T). Подмножество указанных рекомендаций и составляет профиль защиты информации в АС с учетом распределения функций защиты информации по уровням концептуальной модели АС и взаимосвязи функций и применяемых механизмов защиты информации.

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

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

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

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

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

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

• ведением баз данных системы;

• восстановлением работоспособности системы после сбоев и аварий.

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

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

К основным задачам, решаемым инструментальными средствами, является разработка, отладка и исполнение программ контроллерами, которая осуществляется с помощью специализированного программного обеспечения. Это, прежде всего, многочисленные пакеты программ для программирования контроллеров, предлагаемые производителями аппаратных средств. К этому же классу инструментального ПО относятся и пакеты ISaGRAF (CJ International France), InConrol (Wonderware, USA), Paradym 31 (Intellution, USA), имеющие открытую архитектуру и широко распространенные на рынке..

Определившись с набором стандартов, которым должна удовлетворять АС, можно приступать к проектированию ее отдельных компонентов.

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник