Архив WinRAR / ЕКАСУФР
.docСИСТЕМНЫЙ ЛАНДШАФТ ПРОЕКТА ЕК АСУФР И ПРИНЦИПЫ ЕГО ФОРМИРОВАНИЯ
В условиях проводимой реформы железнодорожного транспорта на первый план выходят задачи повышения эффективности управления акционерным обществом, создания эффективной финансово-экономической политики компании. Однако достижение данных целей невозможно без построения эффективных автоматизированных систем управления в сфере финансово-хозяйственной деятельности ОАО «Российские железные дороги».
В настоящее время на сети железных дорог активно ведется внедрение проекта Единой автоматизированной системы управления финансами и ресурсами (ЕК АСУФР), первым этапом которой является создание автоматизированной системы управления, охватывающей сферы бухгалтерского, налогового и управленческого учета и отчетности.
Проект ЕК АСУФР строится на основе системы управления предприятием (ERP-системы) компании SAP AG-SAP R/3. Проект включает следующие основные функциональные подпроекты: «Управление финансами» (УФ), «Управление доходами» (УДП), «Типовая дорожная система» (ТДС), «Управление материально-техническим обеспечением» (МТО), «Сводная отчетность» (СВО). Данные подпроекты внедряются как на дорожном, так и на сетевом уровнях.
Одним из обязательных условий для обеспечения внедрения ЕК АСУФР на сети железных дорог является построение системного ландшафта проекта на всех уровнях, обеспечивающего необходимую производительность, с одной стороны, и удовлетворяющего ряду требований, с другой. К наиболее значимым требованиям к системному ландшафту проекта ЕК АСУФР следует отнести следующие:
• системный ландшафт должен соответствовать рекомендациям компании SAP AG;
• построение системного ландшафта должно выполняться с учетом особенностей функциональных задач проекта ЕК АСУФР;
• ландшафт должен удовлетворять требованиям по надежности, доступности и безопасности.
Согласно рекомендациям SAP AG, для разработки и тестирования настроек и расширений системы R/3 необходимо использование так называемого трехсистемного ландшафта, в рамках которого предусматривается создание системы разработки, системы тестирования (системы контроля качества) и продуктивной системы, предназначенной для работы конечного пользователя. Эти системы должны быть отдельными инсталляциями R/3. Также рекомендуется размещение этих систем на отдельных серверах. Соответственно к НТК различных по назначению систем R/3 выдвигаются различные требования. В соответствии с рекомендациями SAP по безопасности систем R/3 на серверах должны быть размещены только данные по проекту ЕК АСУФР, недопустимо размещение данных, не относящихся к проекту. Таким образом, реализация трехсистемного ландшафта позволяет обеспечить независимость продуктивной системы от процессов разработки и тестирования, а также дает возможность реализации различных принципов построения технической инфраструктуры с точки зрения обеспечения ее резервирования и отказоустойчивости.
На сегодняшний день системы R/3 функциональных подпроектов ЕК АСУФР размещаются в ГВЦ ОАО «РЖД» (системы сетевого уровня) и в ИВЦ железных дорог (системы дорожного уровня).
Схема системного ландшафта подпроектов представлена ниже. Одним из основных принципов, лежащих в основе данной схемы является централизация систем разработки. Так, в частности, в Типовой дорожной сис-теме-подпроекте, предусматривающем автоматизацию всех предприятий основной деятельности ОАО и требующем, помимо основных разработок, доработок дорогами для собственных нужд, все разработки ведутся в единой, централизованной системе разработки, установленной в ГВЦ. На дорожном уровне, как видно из рисунка, эксплуатируются продуктивные системы ТДС и УДП.
На сегодняшний день все функциональные подпроекты, за исключением подпроекта «Сводная отчетность ЕК АСУФР», разработаны на версии SAP R/3 4.0. В целях расширения функциональности проекта, обеспечения надежности работы систем, снижения затрат на системное сопровождение, необходим переход на версию SAP 4.7 (SAP Enterprise Business Suite). Кроме того, одним из решающих факторов по переходу на версию 4.7 является окончание «бесплатной» поддержки компанией SAP AG.
Таким образом, системный ландшафт сетевого и дорожного уровней должен формироваться с учетом требований по обеспечению в 2004 г. -первой половине 2005 г. стопроцентного внедрения функциональности ТДС, обеспечению резервирования программно-аппаратного комплекса проекта, обеспечению перехода на версию 4.7. Также существенным является необходимость объединения на дорожном уровне подпроектов УДИ и ТДС, что позволит эксплуатировать на дорожном уровне только одну продуктивную систему. Необходимо также максимально полно использовать имеющиеся вычислительные ресурсы с целью защиты инвестиций в инфраструктуру проекта в 2000-2004 гг.
Исходя из изложенных требований можно рассмотреть следующий вариант построения системного ландшафта на дорожном уровне.
Московская железная дорога
Текущая конфигурация ПТК, состоящая из серверов SUN Enterprise моделей UE5 500, UE3500 и UE10000 не обеспечивает резервирования оборудования, а также, учитывая количество предприятий Московской дороги, не обеспечивает достаточную для стопроцентного внедрения ЕК АСУФР на дороге производительность. Используемый сервер SUN Enterprise UE 10000 позволяет использовать разделение на домены для обеспечения независимости друг от друга инстанций SAP R/3, что целесообразно использовать при дальнейшем развитии ПТК для повышения надежности комплекса в целом и оптимизации конфигурации для различных типов пользовательской нагрузки.
Единая корпоративная автоматизированная система управления финансами и ресурсами (ЕК АСУФР) железных дорог России является многофункциональной системой, которая обеспечивает:
функционирование пользователей в едином информационном пространстве, обладающем свойствами полноты, достоверности, своевременности поступления и согласованности информации, выдаваемой пользователям на всех уровнях системы;
возможность гарантированного и своевременного получения необходимой информации всеми пользователями системы в соответствии с их полномочиями; исключение дублирования и повторного ввода информации в различных подразделениях на всех уровнях управления; системный контроль соблюдения технологии работы. Вся финансовая информация, обрабатывающаяся в ЕК АСУФР, хранится централизованно на серверах баз данных соответствующего уровня (сетевой или дорожный). Операции, выполняемые на сетевом уровне ЕК АСУФР, фактически выполняются в системе развернутой на серверах, расположенных в ГВЦ МПС. Операции, выполняемые на уровне дороги, выполняются в системе развернутой на серверах, расположенных на ИВЦ соответствующих дорог и в ГВЦ МПС. В системе реализована возможность обмена данными между сетевым и дорожным уровнями в режиме реального времени.
Базовой технологией для построения системы ЕК АСУФР является система управления ресурсами предприятия (СУРП) SAP AG R/3, функционирующая на ОС SUN Solaris v. 2.6 (серверное оборудование в ГВЦ - SUN Enterprise 3500 и SUN Enterprise 5500), СУБД Oracle v. 8.0.5.
Клиентские рабочие места ЕК АСУФР работают под управлением ОС MS Windows 9x, Windows NT и Windows 2000. Обращение с клиентских мест к продуктивному серверу SAP осуществляется по протоколу DIAG (используется SAPGui).
Для межуровневого взаимодействия систем (МПС - железная дорога), а также для доступа удаленных терминалов SAP R/3, устанавливаемых для импорта данных и работы пользователей ЕК АСУФР, используется отраслевая СПД.
Подключение пользователей к системе ЕК АСУФР и доступ к информационным ресурсам осуществляется на основании утвержденного в МПС «Порядка подключения пользователей к информационным системам, телекоммуникационной сети и информационным ресурсам отрасли».
В состав системы SAP R/3 может входить шлюз приложений SAPRouter, который позволяет установить контроль над сетевыми соединениями. Логически SAPRouter располагается между клиентом SAPGui (рабочим местом пользователя) и сервером приложений. Клиент устанавливает соединение на порт SAPRouter, который в свою очередь устанавливает соединение от имени клиента с требуемой службой сервера приложений. Клиенты SAP-системы устанавливают соединения только с SAPRouter и не могут устанавливать соединения непосредственно с сервером приложений. SAPRouter разбирает SAP-протоколы, проверяет допустимость соединения по таблице допустимых маршрутов и затем уже устанавливает соединение с требуемой службой сервера приложений.
Использование SAPRouter позволяет сузить диапазон портов, открытых в СПД, к которым подключаются SAPGui - клиенты.
Система SAP R/3 использует следующие штатные методы обеспечения безопасности:
разграничение доступа и контроль данных, обеспечиваемые логикой работы приложений;
аутентификацию и шифрование на прикладном уровне, обеспечиваемые обращением к функциям интерфейса GSS-API (Generic Security Service Application Program Interface).
Пользователи могут интерактивно взаимодействовать с системой через пользовательский интерфейс SAPGui и проходят процедуру аутентификации в начале сеанса работы с SAP R/3 (в частности, вводят идентификатор пользователя и пароль); после положительного результата проверки происходит регистрация пользователя в системе.
При взаимодействии SAPGui и сервера приложений SAP R/3, a также RFC-клиента и сервера, по сети могут передаваться конфиденциальные данные (например, пароль пользователя, передаваемый от SAPGui к серверу приложений). Одним из средств обеспечения безопасности является шифрование передаваемой информации.
В системе SAP R/3 используется технология SNC (Secure Network Connections - безопасные сетевые соединения), предназначенная для защиты сетевых соединений. В SNC предусмотрено три уровня защиты:
аутентификация - производится аутентификация клиента и сервера в сетевом соединении;
проверка целостности - обеспечивается целостность передаваемых по сети данных;
обеспечение конфиденциальности - происходит шифрование передаваемых по сети данных.
Все эти процедуры реализуются внешними средствами через интерфейс GSS-API. Работа через GSS-API подразумевает возможность использования любых внешних продуктов шифрования, реализующих функции GSS-API.
В целях снижения нагрузки на сервер приложений можно перенести функции зашифрования/расшифрования на отдельный сервер, например, SAPRouter. При этом канал связи «сервер шифрования -сервер приложений» не шифруется, а защищается другими средствами. Дополнительное шифрование передаваемых данных может быть реализовано другими средствами, например, для этого может использоваться SSF.
Все данные в системе SAP R/3 хранятся в базе данных (БД), доступ к которой осуществляется с помощью соответствующей СУБД (например, Oracle). Разграничение доступа пользователей к объектам БД реализовано логикой приложений SAP R/3. Все обращения к СУБД осуществляются от имени единственного пользователя СУБД.
Таким образом, на уровне СУБД существует возможность получения доступа к объектам СУБД в обход логики приложений SAP R/3, при этом в хранимых объектах может содержаться конфиденциальная информация. Для защиты этих данных, кроме средств защиты, обеспечиваемых самой СУБД и ОС, необходимо также реализовать шифрование хранимых данных.
Цифровая подпись позволяет обеспечить целостность данных -их защиту от несанкционированного изменения. В SAP R/3 используется технология SSF (Secure Store & Forward), обеспечивающая цифровую подпись (digital signatures) данных и шифрование (digital envelopes) данных, как при хранении, так и при их передаче (обеспечивается продуктами сторонних фирм - производителей). С SAP R/3 поставляется SAP Security Library (SAPSECULIB), которая позволяет ограниченно использовать SSF - в ней реализована только цифровая подпись данных, но не реализовано шифрование. SAP AG официально публикует список продуктов, в том числе и по обеспечению информационной безопасности, которые гарантированно работают с SAP R/3.
Механизм SSF не обеспечивает прозрачного шифрования данных. При необходимости шифрования данных необходима поддержка со стороны приложения, т.е. изначальная разработка приложения с поддержкой шифрования средствами SSF API или переделка существующего приложения для шифрования конфиденциальных данных средствами SSF API. Для использования механизма SSF необходимо наличие ИОК. При этом система SAP R/3 сама не использует сервисы ИОК, ИОК используется внешними продуктами шифрования для обеспечения механизма SSF.
Службы удалённого доступа к ОС SUN Solaris (по умолчанию используются rsh, rlogin, telnet), а также ftp - протокол, используемый для доступа к информационным ресурсам, не обеспечивают шифрования данных, передаваемых по сети (в т.ч. пароли пользователей). Проблемы, связанные с обеспечением конфиденциальности и целостности данных, существуют также при обмене файлами по NFS и работе по прикладным протоколам SAP R/3. Применение механизма ИОК позволяет решить эти проблемы путем использования SSH или IPsec.
В СУБД Oracle8i r3 производителем добавлен ряд новых возможностей и поддержка последних стандартов безопасности. Компонент Oracle Advanced Security (Усиленная безопасность) поддерживает тройное DES-шифрование, а также более длинные ключи шифрования для RC4 (256-битовый). Для приложений с особыми требованиями к защите уязвимых данных от просмотра (даже со стороны администратора базы данных) в Oracle8i r2 был доставлен пакет PL/SQL для шифрования и расшифрования данных, включая строковую и поточную информацию, с использованием стандарта шифрования данных DES, что позволяет шифровать данные прямо на сервере. Это обеспечивает защиту особо уязвимых данных, таких как номера кредитных карточек, пароли пользователей или сессионные жетоны ("cookies"). В Oracle8i гЗ данная возможность расширена поддержкой алгоритма тройного DES-шифрования (Triple-DES). Oracle8i гЗ поддерживает в т.ч. интеграцию с Entrust/PKI, обеспечивая установление подлинности (аутентификацию) и одноразовое предъявление пароля через опцию Oracle Advanced Security. Кроме того, Oracle Internet - каталог работает с Entrust/PKI, выполняя функцию архива для публикации информации, такой как списки сертификатов и отозванных сертификатов. К другим свойствам, гарантирующим надежность системы безопасности в OracleSi гЗ можно отнести поддержку SSL для HTTP-соединений и шифрование для тонких JDBC-соединений.
ИОК используется для управления ключами и электронными сертификатами для установления защищенных сетевых соединений с помощью базовых протоколов SSL/TLS и IPSec.
Автоматизированная система управления грузовыми перевозками в иерархии информационных связей ФЖТ функционирует на сетевом, дорожном и линейном уровнях.
Сервисы линейного уровня АСУ ГП предоставляются пользователям на автоматизированных рабочих местах (АРМ ТВК, АРМ СПВ, АСУ ТехПД), которые функционируют на базе ПЭВМ (аппаратная платформа-Intel). В настоящее время в отрасли осуществляется перевод АРМов на операционные системы Windows 2000 и переход на работу систем в технологии «клиент - сервер».
Дорожный и сетевой уровни АСУ ГП строятся на программно-техническом комплексе ЕК ИОДВ (Единый комплекс интегральной обработки дорожной ведомости), функционирующем на Мэйнфрейме (IBM 96xx) под управлением OS/390, с использованием отправочной модели на серверах приложений и баз данных, работающих под управлением СУБД DB2, Oracle и MS SQL Server.
Доступ к базам данных, в том числе, осуществляется с помощью программных комплексов SAS. Главной целью применения системы SAS является объединение разрозненных данных из различных оперативных баз в Информационное Хранилище, содержащее информацию, необходимую для поддержки принятия оперативных и долгосрочных решений на всех уровнях управления железнодорожной отраслью.
В системе SAS присутствует широкий спектр средств для построения систем оперативной аналитической обработки (OLAP- приложений), источником данных для которых является Информационное хранилище (отдельные разделы). Характерными примерами таких систем в МПС являются - система анализа использования исключительных тарифов, информационно-аналитическая система управления безопасностью движения, системы анализа дислокации и использования выделенных родов подвижного состава.
Применение продукта SAS/INTRNET позволяет осуществлять публикации на Web-сервере готовых отчетов, и создавать динамические OLAP приложения на Web. Web - серверы используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых приложений. Наиболее часто при этом используется протокол SSL.
Программный продукт SAS/SECURE, входящий в состав системы SAS, использует криптосервисы, предоставляемые Bsafe RSA и CryptoAPI Microsoft. Для обеспечения функций шифрования SAS Institute предлагает программный модуль версий SAS/SECURE International или SAS/SECURE for Windows (поддерживается RSA - 1024 ключи в сочетании с алгоритмом DES (56 бит) и RSA - 512 ключи с RC2 и RC4). Сервисы шифрования доступны при доступе к SAS по TCP/IP, DECnet и NetBIOS протоколам.