Web-design, Multimedia, Network, Security, Virtualization

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

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

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

Очевидно, что на определение новой технологии в значительной степени влияет выбор прикладных систем, которые запланированы для внедрения. Задача разработки прикладных систем - часто один из первых задач, которые приходится решать многим банкам. Большинство систем была разработана 5-10 лет назад, они используют устаревшую технологию, которая является как ценной, с точки зрения затрат на поддержку, так и проблематичной с точки зрения возможности совершенствовать ее в соответствии с требованиями времени. Этот фактор не позволяет ИТ отвечать потребностям сегодняшнего дня. К тому же такие прикладные системы были разработаны для поддержки конкретных банковских продуктов в то время, и сегодня они препятствуют полноценному обслуживанию клиентов.

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

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

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

- Приобрести отечественную систему;

- Приобрести импортную систему;

- Разработать систему с нуля;

- Воспользоваться существующей.

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

Приобретение зарубежной системы имеет ряд недостатков:

- Высокая стоимость;

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

- Дорогие услуги по сопровождению;

- Необходимо более дорогостоящее компьютерное оборудование.

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

Таким образом банка имеет смысл создавать собственную систему в случае, если:

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

2) будущая система перспективна с точки зрения банковских технологий;

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

Чем является большинство систем сегодня?

Основой системы является набор модулей формата ЕХЕ (Executable - выполняемый), которые ориентированы на решение четко определенных задач контроля параметров, количества денег и справочной информации. Дополнительные режимы работы (дополнительные возможности) могут быть внесены двумя путями. Первый путь заключается в написании дополнительных модулей подобных формата DLL (Dynamic Link Library - динамически подсоединяемых библиотека), которые подсоединяются к существующих модулей EXE по определенным правилам. Этот путь позволяет добавить отчеты или некоторые расчетные блоки, но не в состоянии изменить принцип работы самого модуля EXE. Путь второй - изменение конкретного модуля EXE. Этот путь позволяет изменить принцип работы программы, но требует вмешательства разработчика и затрудняет получение пользователями обновлений. Ни первый, ни второй путь не решает тех ситуаций, когда каждый конкретный пользователь желает что либо изменить в системе, т.е. приспособить ее для той схемы работы, которая принята в его банке. Более того, сама система очень "болезненно" реагирует на ошибку в расчетных частях (получение отчетов или расчет основных цифр), а также на попытки изменить ее для внесения даже малых изменений. Также подобные изменения, как правило, разработчик системы обуславливает особо и дальше отказывается от любого сопровождения своей разработки.

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

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

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

В тоже время хотелось бы акцентировать внимание на примере достижения компромисса между закупкой новой системы и ее сопровождением собственными специалистами банка [2]. Иными словами, Предлагаемая концепция создания и совершенствования прикладных систем банковского производства основана на обьектно-ориентированном подходе с использованием широко распространенных инструментов быстрой разработки систем. В качестве инструмента предложенная Delphi фирмы Inprise. Почему? Delphi достаточно открыт средой и позволяет не только создавать об `некоторые проекты из библиотеки визуальных компонентов в своем приложении, но и создавать или модифицировать другие об` некоторые проекты и компоненты. Причем, ничего другого, кроме самой Delphi, для этого не требуется. Каждый из об `ектив имеет свои свойства, каждый из объектов определенным образом может реагировать на только ему присущие события, и на каждый объект определенным образом оказывает влияние реализация тех или иных методов.

Единицей измерения информации в системе предусматривается одна запись типа "понятия" [3]. Понятие - объект, описываемый набором основных и дополнительных свойств. Совокупность данных, описываемых понятием, хранится в одной физической таблицы на носителе информации или в нескольких таблицах имеют отношения типа "один к одному" или "один к многих". Сущность каждого понятие имеет два уровня. Уровень первый - логический уровень. Это уровень его восприятия разработчиком конфигурации, пользователем и уровень, на котором с ним оперирует язык программирования. Уровень второй - физический уровень. Это уровень физического расположения данных, описываемых понятием. Введение двухуровневой архитектуры позволяет располагать в одной физической таблицы несколько логических понятий и достичь при этом более компактного физического хранения данных. Контроль за физическим объединением понятий берет на себя система. Разработчику достаточно оперировать верхним логическим уровнем.

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

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

Таким образом, предполагается, что фирма-разработчик предоставляет банку в одном пакете саму систему и библиотеку компонентов или документированный API (Application Program Interface) к ней.

Преимущества такого подхода в следующем:

1) сама Delphi, как инструмент, достаточно документирована, поэтому никто из сопровождающих не останется без помощи;

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

3) выполняется определенная стандартизация инструментов создания локального программного обеспечения в банке;

4) в системе можно легко использовать библиотеки компонентов от третьих фирм, которые могут решать задачу коммуникации, работы в локальных и глобальных сетях, защиты информации, создание модулей мониторинга данных OLAP (OnLine Analytical Processing) и DSS (Decision Support System) и т.д.;

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

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

В соответствии с международным стандартом ISO 17799 [5], при создании эффективной системы безопасности особое внимание следует предоставить комплексному подходу в управлении информационной безопасностью. В качестве элементов управления рассматриваются как технические, так и организационно-административные меры, направленные на обеспечение следующих требований к информации: конфиденциальность, целостность, достоверность, доступность.

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

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

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

В нашем подходе такое согласие будет получено заранее и, что главное, оно будет официальное задокументировано!

- Скрытые каналы и троянский код:

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

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

Наш подход в этом случае:

- Во-первых, уменьшает риск получения такого ПО, поскольку в принципе часть задач реализуется уже внутри компании, а не поставщиком системы, пусть даже проверенным,

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



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

Авторами была предложена концепция объектно-ориентированного подхода для расширения прикладных банковских систем с учетом требований международного стандарта по безопасности процессов разработки и поддержки таких систем.

Источники:

1. Банковское дело: стратегическое руководство. - М.: Издательство АО "Консалтбанкир", 1998 .- 432 с.

2. Е.А. Завальнюк, Г.П. Завальнюк, Обьектно-ориентированный подход в прикладных финансовых системах / / "Наука и предпринимательство", сборник трудов международного симпозиума, Винница-Дрогобыч, 2000, - С.201-205.

3. Учетная система "Офис 2000". [http://www.ab-system.com]

4. В.А. Цихоцкий, Е. А. Завальнюк, А.Н. Мироненко, Технология построения полнофункциональных банковских систем / / "Наука и предпринимательство", материалы международного симпозиума, Винница-Львов, 1996,-с.47.

5. Стандарт построения эффективно системы безопасности ISO 17799 [http://www.iso-17799.com]