Построение консолидированных информационных хранилищ масштаба предприятия
|
1) В чем состоят типовые подходы к интеграции информационных потоков предприятия, их достоинства и недостатки? 2) Каковы принципы защиты консолидированных информационных хранилищ от внешних и внутренних угроз? |
| Максим Ковалев, начальник отдела вычислительных систем, Inline Technologies (http://www.in-line.ru) |
1) Опыт показывает, что сегодня у крупных и средних предприятий есть устойчивый интерес к проектам интеграции информационных потоков. Роль ИТ в поддержке бизнеса постоянно возрастает. Если в начале 90-х годов прошлого века внедрение ИТ в значительной мере определялось модой, то сейчас их развитие на предприятиях диктуется финансовой выгодой. Помимо явных преимуществ, таких, как сокращение затрат на содержание офиса при обслуживании заказчиков через Интернет, некоторые достоинства ИТ сложно оценить, хотя их значение для бизнеса гораздо больше. Например, эффект от внедрения системы, позволяющей принимать оперативные решения для управления бизнесом, сложно определить в конкретный момент времени. Его нужно оценивать за длительный период (например, финансовый год) через рост доходов, увеличение темпов роста и другие показатели деятельности предприятия.
Интеграция информационных потоков предприятия — это многогранный процесс, затрагивающий практически все информационные системы и всех сотрудников. Максимальный эффект от интеграции достигается, если вся информация будет доступна для анализа. По статистике, до 60% важных корпоративных данных хранится на персональных компьютерах сотрудников. Маловероятно, что управленческое решение, принятое на основе 40% корпоративной информации, будет адекватным. Поэтому при построении консолидированных хранилищ необходимо не только выделить место для хранения всей корпоративной информации, но и соответствующим образом перестроить информационные потоки, чтобы информация в хранилище была полной и актуальной.
Исходя из опыта реализации проектов компании Inline Technologies, можно выделить две основные тенденции в построении информационных систем, интегрирующих информационные потоки предприятия:
- построение единой информационной системы модульной архитектуры и интеграция с ней тех информационных систем, функциональность которых не может обеспечить единая система;
- создание согласующей надстройки над существующими информационными системами.
Каждая тенденция имеет свои достоинства и недостатки.
К построению единой информационной системы тяготеют крупные предприятия, у которых, с одной стороны, накопилось множество различных информационных систем, трудно соединяемых друг с другом, а с другой — имеются достаточные финансовые средства для ведения дорогостоящего проекта и выстроена жесткая вертикаль управления, обеспечивающая выполнение решений по внедрению новой системы. Одно из основных достоинств построения единой информационной системы — использование стандартных, хорошо зарекомендовавших себя программных продуктов. Другое несомненное преимущество — возможность поручить разработку и внедрение системы высококвалифицированным специалистам компании — системного интегратора, которых было бы невозможно привлечь на проекте с маленьким бюджетом. Из достоинств построения единой информационной системы стоит еще назвать возможность выбора масштабируемой и отказоустойчивой аппаратной платформы: большие потоки данных в единой системе обуславливают выбор оборудования класса Enterprise или даже Datacenter. В этих классах возможности масштабирования и повышенная отказоустойчивость заложены конструктивно. Среди недостатков такого решения следует отметить, во-первых, значительную даже для крупного предприятия стоимость разработки, внедрения и сопровождения такой системы, во-вторых, необходимость изменения бизнес-процессов, приведение их в соответствие с возможностями единой информационной системы.
Концепции создания согласующей надстройки следуют средние предприятия. Основные достоинства такого подхода — невысокая (по сравнению с единой информационной системой) цена решения и отсутствие необходимости значительных изменений в структуре и бизнес-процессах предприятия. В качестве достоинства можно также отметить гибкость такой согласующей надстройки, возможность подключения к ней новых информационных систем по мере необходимости. Главный недостаток этого решения — сложность реализации эффективных механизмов одновременного анализа данных нескольких информационных систем.
2) Высокая ценность информации, хранящейся в центре обработки консолидированных данных, требует соответствующих мер защиты. Потеря доступности и целостности консолидированных данных может привести к ущербу из-за того, что будет невозможно вовремя использовать эти данные, а также создаст накладные расходы на их восстановление. В то же время потеря конфиденциальности может вызвать санкции со стороны как партнеров (коммерческая тайна), так и государства, особенно если среди консолидированных данных были персональные данные граждан. Полноценные меры защиты консолидированных информационных хранилищ должны обеспечивать выполнение требований информационной безопасности на различных уровнях: сетевом, уровне серверов, систем хранения данных, приложений, а также на организационном уровне, — что включает в себя различные инструкции и предписания для пользователей и обслуживающего персонала хранилища. После идентификации всех составляющих на каждом обеспечивающем уровне необходимо идентифицировать корпоративные бизнес-системы, которые используют консолидированную информацию, ранжировать эти системы по важности для бизнеса предприятия и определить для них допустимое время простоя. При формулировании требований к конфиденциальности необходимо установить, к каким классам относится та или иная составляющая консолидированной информации. В результате этой работы станет ясно, есть ли применимые нормативные акты и законы, предъявляющие специфические требования к защите данных типов информации. В завершение будут сформулированы требования к целостности, доступности и конфиденциальности в рамках системы информационной безопасности консолидированного информационного хранилища.
Следующий шаг — анализ рисков, связанных с каждым из обеспечивающих работоспособность хранилища элементов, а затем — их ранжирование по суммарной величине связанных рисков. При этом очень важно понять природу источника угроз — они могут быть как внешними, так и внутренними, могут носить, например, природный (случайный либо сезонный) или техногенный характер. Наконец, они могут быть связаны с человеческим фактором. Количество и разнообразие таких источников угроз может быть велико. Обычно при выполнении таких работ компания Inline Technologies пользуется специальными каталогами, содержащими источники и связанные с ними угрозы. Нужно отметить, что в данной модели обслуживающий персонал может выступать и как источник угроз, и как объект, подвергаемый угрозам. Многие также не учитывают физическое окружение — здание и помещение, в котором располагается обеспечивающая инфраструктура, могущие стать объектом угроз.
После идентификации рисков и формирования требований выбираются адекватные меры защиты для каждого уровня. В число таких мер могут входить как оперативный мониторинг и журналирование, повышение надежности и катастрофоустойчивости, так и защита от утечки конфиденциальной информации, что включает задание прав доступа пользователей через роли к конкретным объектам файловой системы, базам данных, таблицам БД и полям в этих таблицах, а также к конкретным внешним устройствам.
Ни одна система не способна обеспечивать гарантированную защиту постоянно — появляются новые угрозы и уязвимости, вносятся изменения в конфигурацию и т. п. Поэтому систему защиты нужно периодически проверять и улучшать, что предполагает такие работы, как сканирование уязвимостей, периодическое испытание возможности восстановления данных с резервных копий, испытание плана действия в чрезвычайных ситуациях и т. п. Обычно данные работы проводятся в рамках комплекса мер, называемого СУИБ (система управления информационной безопасностью), согласно положениям международного стандарта ISO/IEC 17799.
Последний элемент в системе защиты консолидированных информационных хранилищ — это проверка специализированной организацией и выдача подтверждения (аттестата) правильности формулирования требований к защите и адекватности внедренных мер. В зависимости от типа обрабатываемой информации такой организацией может быть или ФСТЭК России, в рамках которой проводятся работы по аттестации систем, обрабатывающих конфиденциальную информацию, или независимый международный орган по сертификации систем в соответствии со стандартом ISO/IEC 27001.
| Андрей Гребенюк, ведущий специалист департамента программной интеграции, “Ай-Теко” (http://www.iteco.ru) |
1) Современные предприятия представляют собой сложные комплексы разнородных систем — ERP, CRM, SCM, HRM и т. д. В лучшем случае такой комплекс — это модульная система от одного производителя; тогда в нее уже заложены механизмы обмена информацией и данными между модулями. Однако на практике модульные системы встречаются крайне редко. Причины этого различны: кому-то не понравился функционал и он выбрал решение от независимого поставщика, у кого-то проблемы с финансированием и т. д.
Как правило, каждая из систем комплекса имеет свою базу данных, не связанную с другими системами. В этом случае возникает ряд проблем, связанных с управлением информацией в масштабах всего предприятия. Основные проблемы можно разделить на две группы. В первую входят проблемы, связанные с обработкой информации системами, а именно:
- необходимость разработки специальных шлюзов в системах для обмена информацией, сложность синхронизации;
- различные форматы данных;
- проблемы целостности и качества данных, дублирование и т. д.
Вторая группа — это проблемы, связанные с представлением информации пользователям:
- большие затраты времени на поиск нужной информации;
- затрудненный доступ к данным для пользователей;
- сложность всеобъемлющего анализа информации и т. д.
Соответственно и решать данные проблемы можно на двух уровнях — на уровне сервисов и бизнес-логики и на уровне представления информации.
Для интеграции данных на уровне сервисов и бизнес-логики традиционно используются два подхода — консолидация информации и федеральный доступ к ней. Эти подходы применяются как для данных (структурированная информация — таблицы, формы и т. д.), так и для контента (неструктурированная информация — электронные документы, изображения). Классический пример консолидации — хранилище данных, т. е. специализированная система, включающая базу данных и ряд сервисов для загрузки и выгрузки данных, их преобразования и т. п. Как правило, хранилище данных служит фундаментом для построения аналитической системы. Иногда в качестве узла консолидации (корпоративного хранилища) может выступать основная производственная система, иногда — отдельная независимая база данных.
Процедуры доступа к источникам данных, преобразования и выгрузки в целевое хранилище достаточно ресурсоемки, поэтому процесс обновления данных дискретен: он выполняется, как правило, по расписанию, обычно во время наименьшей загруженности систем-источников. Отсюда и минусы такого подхода — существует «время задержки» до обновления, данные не всегда актуальны. Поскольку данные перед помещением в хранилище трансформируются, не всегда есть возможность получить исходные данные (впрочем, это зависит от структуры хранилища). Жесткая структура — еще один минус такого подхода; при подключении новых источников данных может потребоваться существенная реорганизация системы. Плюсы же этого подхода — разгружаются основные транзакционные системы, проводится централизация данных, проще организовать защиту и резервное копирование критически важной информации. Кроме того, поскольку данные существуют уже в «подготовленном виде», сокращается время выполнения запросов пользователей.
Другой подход, федеральный доступ, получил распространение в последнее время, когда существенно возросли вычислительные мощности, стал возможен быстрый доступ к данным и преобразование «на лету». При таком подходе данные в исходном виде находятся в источниках, а специальные сервисы, отвечающие за доступ к данным и их преобразование, работают по запросу и связывают системы по требованию. Современные средства гарантированной доставки и обмена сообщениями также способствуют популярности такого подхода.
Минусы данного подхода — требуются большие вычислительные мощности для приемлемого времени ответа (реакции системы), дорогостоящая транспортная среда, не исключены проблемы с качеством данных, затруднен контроль и резервное копирование информации. Основные плюсы — гибкость, возможность получения первичных данных. Этот подход может применяться как на уровне сервисов, так и на уровне представления данных.
Современный вариант, лишенный недостатков хранилищ данных, — системы класса MDM (Master Data Management). Для данных одной предметной области (например, информация о клиентах и поставщиках, о продуктах, финансовая информация) создается специальное хранилище — Data Hub, структура которого наиболее полно отражает информацию об объектах данного типа. Данные из различных источников (систем), подключенных к системе MDM, собираются в хранилище, где очищаются, дополняются и приводятся к стандартному виду. После этого очищенная информация через сервисы синхронизации возвращается в источники. При возникновении нового объекта в одном из источников, включенных в систему MDM, информация в режиме онлайн поступает в Data Hub и через него транслируется в другие системы. Такой подход позволяет системам обмениваться качественной информацией через центральную систему (Hub), в то же время обеспечивая актуальность информации. Данный подход представляется наиболее перспективным.
Для интеграции информации на уровне представления используются аналитические, поисковые системы, информационные порталы. В основе таких систем лежит все тот же принцип федерального доступа. Как правило, большинство современных информационных систем предоставляет пользователям (системам) открытый Web-интерфейс или API, позволяющий получать из них информацию.
К аналитическим системам обычно относят системы регламентированной отчетности, системы произвольных запросов и OLAP-анализа, системы поиска закономерностей и прогнозирования (Data Mining), а также панели управления (Dashboards). Все они могут собирать информацию из различных источников, консолидировать (преобразовывать) по определенным правилам и представлять пользователю. Потребность в аналитических системах возрастает с увеличением на предприятии числа различных информационных систем и уровня автоматизации бизнес-процессов.
Поисковые системы используются в основном для полнотекстового поиска неструктурированной информации и существенно повышают производительность персонала за счет сокращения времени поиска нужных документов.
Основное назначение порталов — объединить информацию из различных систем для представления пользователю в удобном виде. Порталы условно делят на два вида: информационные и интеграционные.
Информационные порталы позволяют работать с системами, предоставляющими Web-интерфейс, и служат только для объединения информации. Их функционал ограничен функционалом Web-интерфейса, предоставляемого приложениями. Такие порталы просты в настройке и поддержке, а также имеют более низкую стоимость, чем интеграционные порталы.
Интеграционные порталы обладают более богатым функционалом и работают с системами на более низком уровне — на уровне API или даже прямого доступа к данным. Такие порталы могут взаимодействовать со связанными системами, а также служить «мостиком» для взаимодействия систем между собой через портал посредством обмена данными.
В любом случае не стоит забывать о том, что порталы — это только надстройка, хотя и очень полезная, и они всего лишь представляют информацию из других систем предприятия, например, из аналитической (отчеты, панель управления) или поисковой системы.
2) Основной принцип защиты — стоимость системы безопасности не должна превышать стоимости защищаемой информации. При реализации системы защиты информационных хранилищ применяются все те же хорошо известные принципы, что и для других информационных систем. Однако есть ряд особенностей, характерных для хранилищ информации, на которые следует обратить внимание:
- необходимость резервного копирования и архивирования информации хранилища для минимизации потерь в случае нарушения защиты (разработка регламентов, организационные меры, создание резервного хранилища, специальных серверных комнат, аппаратная (программная) кластеризация);
- защита данных в форс-мажорных обстоятельствах (необходимо предусмотреть комплекс мероприятий и технологии быстрого переноса критических данных на другую площадку в случае стихийных бедствий, захвата зданий и т. д.);
- необходимость защиты каналов связи, по которым передается информация, например, с помощью программных и/или аппаратных средств криптозащиты;
- необходимость защиты от несанкционированного доступа и использования информации на всех этапах ее жизненного цикла. Ценность информации может меняться со временем, поэтому контроль доступа необходим как для «рабочей», так и для архивной информации. Централизация информации и каталогов пользователей существенно облегчает контроль доступа к информации и процедуры обеспечения надежности хранения.
| Юрий Марьинский, руководитель проектов по внедрению аналитических систем, “Микротест” (http://www.microtest.ru) |
1) В настоящее время в большинстве компаний, руководство которых приняло решение создавать корпоративную информационно-аналитическую систему, имеются несколько источников данных, на основе которых будут строиться аналитические модели и корпоративная отчетность. Это связано с тем, что лучшие на рынке решения класса ERP, CRM, системы бюджетирования, электронного документооборота и т. д. создаются разными производителями и хранят свои данные в разном формате. Кроме того, в большинстве компаний значительная часть корпоративных данных хранится в формате Excel.
Чтобы руководство компании могло получать полную, оперативную и достоверную информацию из аналитической системы, необходимо, чтобы в ней присутствовали данные из всех имеющихся учетных систем. Наиболее популярный подход к решению задачи объединения разрозненных данных — создание хранилища данных (data warehouse).
Хранилище данных представляет собой единую базу данных, имеющую упрощенную структуру по сравнению со структурой баз данных учетных транзакционных систем. Неотъемлемую часть хранилища данных также составляют процедуры извлечения, преобразования и загрузки данных из разнородных источников в единую базу данных, которые либо реализуются промышленными средствами класса ETL, либо создаются путем программирования.
Существуют два основных подхода к реализации хранилища данных. Первый, традиционный подход, до недавнего времени считавшийся единственно правильным, предусматривает создание хранилища данных на основе реляционной СУБД. Этот подход наиболее универсален и надежен, многократно проверен на практике. Реляционные СУБД позволяют хранить практически неограниченные объемы данных, поддерживают всевозможные типы данных. Современные версии промышленных реляционных СУБД имеют множество встроенных средств для оптимизации производительности, что актуально для получения аналитических отчетов на основе больших объемов данных.
Однако, наряду с достоинствами, у этого подхода есть и некоторые недостатки. Очень часто подобные проекты требуют программирования на языке SQL, трудоемки, продолжаются месяцами (а иногда — и годами), наряду с затратами времени требуют значительных финансовых вложений. Независимо от того, разрабатывается ли хранилище данных силами внешних консультантов или собственных специалистов компании, возникают риски, связанные с тем, что создается уникальное решение, поддержкой и развитием которого в состоянии заниматься только его разработчики. На практике нередки также случаи, когда размер созданного хранилища данных многократно превышает совокупный размер исходных источников данных, и время получения отчетов измеряется не секундами, а минутами или десятками минут. В результате приходится постоянно дорабатывать хранилище данных, создавая новые таблицы с заранее просчитанными агрегированными значениями для каждого нового аналитического отчета.
Альтернативный подход к созданию хранилища данных, который в последние годы, параллельно с развитием программных средств класса Business Intelligence, становится все более популярным, заключается в использовании многомерных баз данных — OLAP-кубов вместо реляционных СУБД. Этот подход многократно, на один-два порядка, упрощает процесс разработки хранилища данных, поскольку разработчикам не требуются языки программирования для извлечения, трансформации и загрузки данных. Проектирование структуры хранилища данных также проводится визуальными средствами.
Важное преимущество этого подхода — быстрое получение результатов. Как только данные из разных источников загрузились в OLAP-куб, руководители, менеджеры, аналитики и массовые пользователи автоматически получают доступ к аналитической информации, необходимой для принятия управленческих решений. Стоит также отметить, что использование хранилища данных на основе OLAP-кубов гарантирует высокую производительность при обработке аналитических запросов и генерации отчетов. В среднем любой аналитический запрос пользователя обрабатывается OLAP-системой за время в пределах 5 с, практически независимо от объема исходных данных и количества одновременно работающих пользователей.
Наряду с преимуществами использования OLAP-кубов в качестве платформы для создания хранилища данных, у этого подхода имеется ряд недостатков и ограничений. Например, в OLAP-кубах, в отличие от реляционных СУБД, нельзя хранить некоторые типы данных, например, графические изображения. Стоит также отметить, что в один OLAP-куб не рекомендуется загружать более миллиарда реляционных записей.
Практика показывает, что использовать реляционную СУБД для создания хранилищ данных целесообразно в тех случаях, когда объем исходных данных в учетных системах относительно велик, превышает десятки или сотни миллионов записей. Этот подход также полезен при наличии нескольких учетных систем, не имеющих единых справочников. В этом случае нужно разрабатывать подсистему ведения НСИ, и без программирования не обойтись. В других ситуациях, когда объемы данных не так велики или когда они велики, но данные отличаются высоким качеством, уместно использовать многомерное хранилище данных на основе OLAP-кубов.
2) Чтобы минимизировать риски несанкционированного доступа к конфиденциальной информации, содержащейся в хранилище данных, необходимо следовать нескольким важным правилам. Во-первых, в качестве платформы для хранилища данных рекомендуется использовать промышленную реляционную или многомерную СУБД от всемирно известного разработчика, содержащую средства разграничения прав доступа, надежность которых проверена временем. Во-вторых, целесообразно предоставлять пользователям доступ к аналитической информации только через интерфейс аналитической системы, а не путем написания собственных отчетов и выгрузки данных из хранилища в локальные файлы Excel, которые имеют слабый уровень защиты.
| Виталий Соловьев, начальник отдела общесистемных технологий, «ТехноСерв А/С» (http://www.technoserv.ru) |
1) Объемы информации крупнейших российских предприятий и организаций всегда были большими. С развитием бизнеса предприятия увеличивается и количество данных, обрабатываемых корпоративными информационными системами. По оценкам ведущих мировых аналитических агентств, объем информации, обрабатываемой и хранимой западными корпорациями, с каждым годом увеличивается в два раза. Россия не осталась в стороне от этой тенденции: по нашим оценкам, объем данных крупнейших российских предприятий также ежегодно удваивается.
Крупным предприятиям с разрозненной ИТ-инфраструктурой становится все сложнее эффективно управлять постоянно увеличивающимися потоками данных. Например, с одной стороны, информация зачастую дублируется, а с другой — увеличивается время на поиск и обработку необходимых данных. Снижается производительность корпоративной информационной системы, увеличивается совокупная стоимость владения ИТ-ресурсами.
Основной подход к управлению информационными потоками складывается из консолидации данных и организации их централизованного хранения. На первом этапе строится система для хранения оперативных данных (OLTP), на основе которой на втором этапе развертывается долгосрочное хранилище данных (data warehouse). Такое решение обеспечивает как оперативный доступ к наиболее актуальной в конкретный момент информации, так и долгосрочное хранение данных в архиве. Этот подход радикально снижает затраты времени на обработку информации и обеспечивает надежное многолетнее хранение всех данных, накопленных за время существования предприятия.
Это, можно сказать, «классика жанра», путь, который выбирает подавляющее большинство крупных российских предприятий. При этом в части оборудования речь здесь идет о решениях класса hi-end или midrange. Конечно, выбор платформы хранения данных будет зависеть от требований как к техническим параметрам, так и к стоимости, но экономить за счет использования небольших локальных систем крупному предприятию не имеет смысла. Исходя из опыта сотрудничества «ТехноСерв А/С» с российскими организациями, относимыми к крупнейшим, можно отметить тот факт, что они все чаще делают выбор в пользу по-настоящему больших современных устройств, таких, как EMC Symmetrix DMX 2000 и 3000, StorageTek SL8500, HDS TagmaStore, IBM DS8300 и т. д.
2) Два главных принципа, обеспечивающих сохранность данных, — это резервирование в системах хранения и организация резервного копирования и восстановления. Для этого могут применяться самые разнообразные средства, выбор которых зависит от требований к производительности системы и ее стоимости: резервирование аппаратных узлов, использование RAID разных уровней, создание как локальных, так и удаленных резервных хранилищ, обеспечивающих отказо- и катастрофоустойчивость корпоративной ИТ-системы, и т. д.
Для защиты от логических ошибок применяется технология создания локальных логических (snapshots) и физических (BCV) копий.
Важную роль в защите данных играет разграничение доступа к информации как на уровне приложений, так и на уровне доступа пользователей. Кроме того, организуется ограниченный и контролируемый доступ в серверные помещения.
Нужно понимать, что корпоративная система хранения данных крупного предприятия — это сложный и комплексный механизм, требующий постоянного внимания. Поэтому целесообразно создать в рамках внутренней ИТ-службы предприятия группу storage-администраторов, каждый из которых возьмет на себя определенный круг обязанностей по поддержанию работоспособности системы хранения.
Для обеспечения информационной безопасности консолидированных хранилищ от внешних угроз, как правило, применяется метод защиты периметра. Это продиктовано необходимостью гарантировать доступность хранимых данных, а также обеспечить контроль за входящими информационными потоками. Для решения описанной задачи рекомендуются системы межсетевого экранирования уровня предприятия: StoneGate Firewall, Cisco PIX, Juniper NetScreen и т. д. Как показывает практика, использование комбинированных систем межсетевого экранирования и систем обнаружения и предотвращения вторжений позволяет эффективно перекрыть основные критичные угрозы и уязвимости защищаемых данных.
Таким образом, для построения надежной и современной системы защиты информационного хранилища необходимо применять процессный подход: использовать эшелонированный принцип защиты, включающий защиту внутреннего и внешнего периметра системы хранения.