Чем асимметричные алгоритмы шифрования отличаются от симметричных. Как устроено шифрование в интернете (алгоритм Диффи-Хеллмана, RSA, сертификаты, цифровая подпись, хеширование, Tor, i2p). Шифрование на эллиптических кривых

07.09.2009 Валерий Коржов

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

Новые законы оказывают определенное влияние как на рынок средств ИТ, так и на предлагаемые на нем технологические решения. Например, одним из наиболее влиятельных документов в области информационной безопасности до недавнего времени был закон «Об ЭЦП», настолько жестко регламентировавший использование технологии цифровой подписи, что многим клиентам приходилось сознательно выходить из-под его действия, чтобы использовать средства защиты, принятые во всем цивилизованном мире. Проанализируем, каким образом необходимость соответствия федеральному закону «О персональных данных», вступающему в силу 1 января 2010 года, повлияет на рынок информационной безопасности и что ИТ-компании будут вынуждены сделать, чтобы ему соответствовать.

Архитектура

В любой информационной системе современной компании всегда присутствуют персональные данные: телефонные книги, ведомости бухгалтерской отчетности, списки сотрудников и т.п.
В соответствии с законом все эти данные должны быть теперь защищены, однако для этого можно использовать разные уровни защиты. Подзаконные акты Федеральной службы по техническому и экспортному контролю РФ и ФСБ выделяют четыре категории персональных данных (К4-К1) – от обезличенных до наиболее ценных для индивида (сведения о здоровье, религиозных взглядах или особенностях личной жизни). Данные самой высокой категории, предоставляемые в Пенсионный фонд, имеются в любой компании (ведомости о зарплате с указанием ФИО, сведения о социальном положении сотрудника, наличие инвалидности, семейное положение, количество детей и др.).

Чем выше категория персональных данных, тем более сложные механизмы требуются для их защиты. Для самой низкой категории – К4 – достаточно обеспечить только целостность данных, причем подбор технологических решений остается на совести компании. Данные категории К1 необходимо в том числе, защитить от утечек по визуальным и звуковым каналам, а также по побочному электромагнитному излучению, что организовать довольно сложно, поскольку потребуется специальное помещение и компьютерное оборудование, а используемые для защиты решения должны иметь соответствующие сертификаты ФСТЭК и ФСБ. Последнее ведомство контролирует использование криптографии, однако без шифрования в системе такого уровня вряд ли удастся обойтись. К тому же при использовании сертифицированных ФСБ криптобиблиотек нужно еще иметь заключение на корректность их встраивания в продукт.

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

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

Впрочем, сейчас появляются отечественные продукты, не требующие изменения приложений, например решение eToken SafeData компании Aladdin, которое осуществляет защиту СУБД путем выборочного шифрования строк и столбцов в таблицах. Однако необходимые механизмы криптозащиты таблиц и отдельных полей могут быть предусмотрены и в штатных СУБД – их только нужно правильно настроить.

Защита

Компании, собирающие персональные данные, обязаны защищать собранные сведения от модификации и разглашения. За соблюдением нормативных требований следит «Роскомнадзор» – Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций, ведущая реестр операторов персональных данных (pd.rsoc.ru). Сотрудники этого ведомства могут проверить любую компанию на соблюдение требований по защите персональных данных – регулярными проверками они будут заниматься после 1 января 2010 года, а пока реагируют на жалобы граждан. Если окажется, что в компании недостаточно заботятся о защите персональных данных, то ведомство вправе потребовать от оператора в трехдневный срок исправить все недочеты или уничтожить персональные данные. Чтобы этого избежать, лучше заранее позаботиться о классификации персональных данных и обеспечении их защиты в соответствии с требованиями подзаконных актов.

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

Базовые инструменты

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

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

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

В некоторых антивирусных решениях класса Internet Security (например, «Лаборатории Касперского», Symantec, Eset, McAfee и Trend Micro) уже встроены персональные межсетевые экраны, фиксирующие атаки по сетевым протоколам и попытки сетевых червей проникнуть на защищаемую машину. Кроме того, межсетевые экраны должны быть активированы на шлюзовом маршрутизаторе (такой функционал, как правило, имеется в сетевых устройствах), что позволит создать так называемую демилитаризованную зону (DMZ) для внешних Web-приложений и систем электронной почты. Собственно, в DMZ, для доступа к которой в межсетевом экране используются более жесткие правила, размещаются сетевые ресурсы, доступные извне, и защитные механизмы для них.

Системы предотвращения вторжений. Системы предотвращения вторжений (Intrusion Prevention System, IPS) устанавливаются в разрыв сети и служат для выявления в проходящем трафике признаков нападения и для блокировки обнаруженной наиболее популярной атаки. В отличие от шлюзовых антивирусов, IPS анализируют не только содержимое IP-пакетов, но и используемые протоколы и корректность их использования. Спектр атак, от которых могут защитить системы предотвращения вторжений, несколько шире, чем у шлюзовых антивирусов. Системы IPS производят как компании, специализирующиеся на сетевой защите, такие как Check Point и McAfee (продукт Network Security Platform), так и производители сетевого оборудова-ния – Juniper и Cisco.

Сканеры уязвимостей. К общим средствам защиты относятся также сканеры уязвимостей, которые проверяют информационную систему на наличие различных «брешей» в операционных системах и программном обеспечении. Как правило, это отдельные программы или устройства, тестирующие систему путем посылки специальных запросов, имитирующих атаку на протокол или приложение. Наиболее популярными продуктами этого класса являются MaxPatrol, семейство продуктов IBM ISS, Symantec и McAfee (Vulnerability Manager). Впрочем, сейчас появляются пассивные сканеры, которые просто контролируют сетевой трафик и выявляют в нем наличие тех или иных признаков уязвимости. Такие сканеры только появились и еще не завоевали достаточно большой доли рынка. Сканеры уязвимостей можно использовать для проведения внутреннего аудита защиты, который предусмотрен в требованиях ФСТЭК.

Упомянутые средства защиты являются общими для всей сети и не связаны непосредственно с защитой собственно персональных данных, однако в требованиях ФСТЭК их наличие специально оговаривается, поэтому эти базовые средства должны быть у каждого оператора персональных данных, причем даже для минимального уровня К4, где выбор средств защиты предоставляется самому оператору.

Защита от утечек

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

Контроль над устройствами. Нередко утечка данных происходит через съемные носители информации и несанкционированные каналы связи: флэш-память, USB-диски, Bluetooth или Wi-Fi, поэтому контроль за использованием USB-портов и другого периферийного оборудования также является одним из способов контроля утечек. На рынке имеется несколько решений этого класса, например от компаний SmartLine и SecureIT.

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

Шифрование. Защита данных от утечек так или иначе использует механизмы шифрования, а эта отрасль всегда контролировалась ФСБ, и все требования по сертификации систем шифрования публикуются и проверяются этим ведомством. Следует отметить, что шифровать нужно не только сами базы персональных данных, но и их передачу по сети, а также резервные копии баз данных. Можно использовать механизмы шифрования, встроенные в базы данных, однако для их законного применения требуется интегрировать в них российские алгоритмы шифрования, что не всегда возможно, поэтому некоторые российские компании разрабатывают собственные продукты, в частности уже упоминавшийся продукт Aladdin eToken SafeData. Впрочем, для защиты персональных данных можно шифровать целые разделы файловой системы, которые используются для хранения данных, такие решения предлагаются в России несколькими компаниями. Наиболее активны в этой сфере Aladdin, SecureIT, InfoWatch и «Физтех-Софт», однако на больших базах данных продукты этих компаний могут сильно замедлять производительность, поэтому для них можно либо использовать специализированные продукты, либо выделять их в отдельные базы, которые шифруются отдельно.

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

RMS (Right Managemеnt System). Системы данного класса базируются на алгоритмах шифрования, однако управляют не процессом шифрования документов, а ключами дешифрации. Эти ключи хранятся на центральном сервере системы, и доступ к ним разрешается после прохождения процедуры строгой аутентификации пользователя, что означает – расшифровать документ может только тот пользователь, у которого есть на это права. Решения класса RMS предлагают пока в основном зарубежные компании – Microsoft (Microsoft RMS), Oracle (Oracle IRM) и ряд других, поэтому при использовании в российских условиях этих продуктов могут возникнуть проблемы с сертификацией в ФСБ. Кроме того, в существующих продуктах права доступа к ключам определяют авторы документов, что не позволяет защититься от внутренних угроз, как это делается в DLP-системах. Поэтому пока системы RMS не получили должного распространения в качестве средств защиты от утечек информации.

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

Защита по-большому

Следует отметить, что в подзаконных актах ФСТЭК имеется разделение на небольшие, средние и распределенные базы данных, требования к защите которых сильно различаются. Так, для защиты распределенных баз, как правило, нужны дополнительные инструменты защиты, что и понятно – распределенная база должна иметь каналы связи между своими частями, которые также необходимо защищать. Вообще, для защиты больших информационных систем есть несколько продуктов, позволяющих централизованно контролировать крупные установки защитных продуктов.

Управление правами доступа. В большой информационной системе главной проблемой для администратора является правильная организация доступа сотрудников к различным ресурсам – от корректной настройки прав доступа часто зависит сохранность конфиденциальных данных, поэтому система управления правами доступа должна быть включена в систему защиты крупной информационной системы. Такая система обычно позволяет ввести ролевое управление правами доступа и контролирует соблюдение этих прав. Система также блокирует попытки изменить права доступа без разрешения администратора безопасности, что обеспечивает защиту от локальных администраторов. Типичными представителями этого семейства продуктов являются Oracle IAM и IBM Tivoli Access Manager, но можно назвать также и McAfee Unified Secure Access Solution. Следует отметить, что методика защиты персональных данных предполагает управление правами доступа в системах любых размеров, обрабатывающих такую информацию, однако в небольших базах данных достаточно ручного управления правами доступа.

Корреляция событий. Крупная система защиты может генерировать множество сообщений о потенциальных нападениях, которые лишь потенциально способны привести к реализации той или иной угрозы. Часто такие сообщения являются лишь предупреждениями, однако у администраторов безопасности большой системы должен быть инструмент, который позволил бы им разобраться в сущности происходящего. Таким инструментом анализа может стать система корреляции событий, позволяющая связать несколько сообщений от устройств защиты в единую цепь событий и комплексно оценить опасность всей цепочки. Это позволяет привлечь внимание администраторов безопасности к наиболее опасным событиям. Примерами подобных систем являются Cisco MARS или netForensics, однако аналогичные модули есть и в Tivoli Security Operations Manager (TSOM).

Управление безопасностью. Системы централизованного управления защитными механизмами позволяют полностью контролировать все события, связанные с безопасностью информационной системы. Продукты этого уровня могут обнаруживать защитные механизмы, установленные на предприятии, управлять ими и получать от них отчеты о происходящих событиях. Эти же продукты могут автоматизировать решение наиболее простых проблем или помогать администраторам быстро разобраться в сложных атаках. Это, например, уже названный IBM TSOM, LANDesk Security Suite или McAfee Network Security Manager.

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

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

Однако соблюдение всех требований закона, а точнее подзаконных актов чиновников из ФСТЭК и ФСБ, может оказаться делом довольно сложным, справиться с которым компании до 1 января 2010 года, похоже, не сумеют. На этой почве открывается большое поле деятельности для предприятий, способных оперативно построить корпоративную систему защиты информации и подготовить необходимый пакет документов для проверяющих органов. Другим вариантом решения проблемы соответствия закону «О персональных данных» является передача функции защиты персональных данных сторонним организациям, и такие компании-аутсорсеры уже начинают появляться в России. Тем не менее этот вариант может быть связан с изменением ИТ-архитектуры и потребует времени
и дополнительных расходов.

Валерий Коржов () – обозреватель Computerworld Россия (Москва).

Как защититься от утечек

В приведены методы защиты конфиденциальной информации, из которых первые пять обеспечивают единичные сценарии защиты конфиденциальных данных от утечки, а подход 6 позволяет получать финансово значимый результат уже в первые недели после внедрения системы. Подход 7 требует кропотливого внедрения и отладки (от одного до трех лет). Подходы 8-10 дополняют DLP-системы за счет снижения рисков утечки в результате кражи/потери ноутбуков или дисков. Подходы 11-12 в той или иной степени используются во всех компаниях и могут косвенно повлиять на снижение рисков утечки информации.

Терминальные решения

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

Одним из возможных вариантов построения подобной системы является решение, разработанное совместно компаниями Sun Microsystems и «Свемел», состоящее из защищенного сервера с операционной системой «Циркон-10», сервера терминального доступа «Циркон-Т», а также набора терминалов Sun Ray 2, Sun Ray 2FS или Sun Ray 270, производимых компанией Sun по техническим требованиям «Свемел». Операционная система «Циркон-10» представляет собой специализированную версию ОС Solaris 10 со встроенной системой защиты Trusted Extension, исходные коды которой сертифицированы ФСТЭК на отсутствие программных закладок и надежность контроля доступа. Система может работать как на платформе SPARC, так и на серверах x86, позволяя запускать весь набор приложений для Solaris 10.

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

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

Примеры применения системного подхода к решению типичных проблем компаний

Ситуация 1

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

В процессе диагностики было выявлено следующее:

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

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

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

4. Между отделами продаж и закупок по некоторым вопросам не установлены четкие процедуры взаимодействия, что часто приводит к срывам заключения сделок с клиентами.

5. Отдел логистики практически не понимает, что важнее — минимизировать логистические затраты или доставить в срок заказ клиента.

Для решения данных проблем:

1. Была разработана гибкая ценовая политика. Отдел продаж получил полномочия самостоятельно устанавливать цену.

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

3. Были разработаны приоритеты в работе с определенными товарными марками.

4. Премирование сотрудников стало осуществляться из фондов премирования, созданных для каждого отдела.

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

Ситуация 2

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

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

Ситуация 3

Владелец торговой компании обратился к экспертам по системному подходу к управлению бизнесом за консультацией с вопросом: как добиться оптимальной траты финансовых средств и материальных ресурсов в фирме и как, не затрачивая дополнительных средств (при прочих равных условиях), значительно увеличить эффективность деятельности фирмы?

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

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

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

Андрей Наумов, Валерий Симонян

Мнение эксперта:

Власова Н. М., научный консультант центра «Харизма»:

— Самой яркой и частой, по сути — фундаментальной, не только ошибкой, но и слабостью топ-менеджеров всей страны является именно их стиль управления — так называемый командирский. Он основан на механистической парадигме устройства организации, где люди как бы часть этого механизма и являются исполнителями. Его главное отличие — использование внешних рычагов управления, а именно управления финансовыми рычагами, оптимизацией деятельности через изменения структуры, бизнес-процессами, репрессивной (в основном) системой контроля и т. п. Этот стиль подобен тюрьме, в которой заперт человеческий потенциал. В итоге работники используют 20-30% своего потенциала, а подавляющее большинство и того меньше. Производительность труда — в 5-80 раз меньше, чем в передовых странах. Чтобы это изменить, нужен фундаментальный сдвиг в мозгах всех управленцев. Ведь организация не машина — она живой организм.

Необходима смена парадигмы командирского стиля на лидерский. Лидер воспринимает людей не как исполнителей и объекты, а как субъектов и инвесторов своего таланта и интеллекта, т. е. своего потенциала. Лидерский стиль управления использует принципиально другие инструменты и методы воздействия. Это не внешняя мотивация и стимулирование труда, а включение внутренней мотивации и самодисциплины. Лидер ориентируется на глубинные законы человеческого поведения и создает условия, в которых эти законы начинают самопроизвольно работать. Лидер отличается от менеджера (по сути —командира) только одним, но очень важным признаком: за ним идут, и идут добровольно.

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

Елена Лисицина, директор Института качества «Люди Дела»:

Стратегия — это совокупная работа команды, которая обеспечивает сбалансированный вектор развития компании. Руководитель может и не знать особенности и детали, которые для линейного руководителя лежат на поверхности. Для того чтобы разработать комплексную стратегию развития, на мой взгляд, нужно привлекать к разработке стратегии команду специалистов и максимально использовать их знания для составления общей картины развития. Инициировать разработку стратегии, направлять членов команды и принимать решения должен, безусловно, руководитель компании. Недаром «стратегия» в переводе с греческого (strategos) означает «искусство генерала»! Системный подход — один из принципов управления, заложенных в международных стандартах ISО, которые как раз унифицированы для любого бизнеса. Взять хотя бы простой цикл Деминга: PDCA — Планируй — Делай — Контролируй — Действуй (Улучшай). А вот с применением его на практике нередко возникают сложности, ведь системный подход требует постоянства и рутинной повторяемости установленных в определенном порядке действий. Важно соблюдать этот порядок и не нарушать его — в первую очередь самому руководителю. В последнее время в организациях можно встретить большое количество различных проектов по улучшению деятельности. Причем реализуются они одновременно, к реализации привлекается один и тот же персонал (как в пословице — «Кто везет, на том и едут»). Зачастую реализация этих проектов не скоординирована по этапам, работам, срокам, а руководители соперничают друг с другом в масштабности изменений, перетягивая одеяло в сторону своего проекта. Но в большинстве случаев такие кардинальные изменения организации не под силу: ведь надо еще и деньги умудриться заработать, не погрязнув в бесконечном потоке новаторства. Что в результате? Огромный интерес со стороны руководства в начале проекта и сведение на нет всех усилий команды в середине, когда мероприятия уже разработаны и дело за их внедрением. А руководитель в это время активно внедряет новый проект, и так до бесконечности... Я хочу дополнить слова экс-президента компаний «Форд» и «Крайслер» Ли Якокка: «Управление представляет собой не что иное, как настраивание других людей на труд». А любой труд эффективнее, когда исполнитель видит результат.

В статье рассматриваются типичные проблемы, связанные с целостностью данных, и показывается, какие средства дает Analysis Services 2005 для решения этих проблем.

Проблемы, связанные с целостностью данных, типичны для реляционных баз данных, особенно для оперативных (OLTP) систем. Эти проблемы обычно исправляются с помощью job"ов ETL (Extraction, Transformation и Load - извлечение, трансформация и загрузка), которые загружают данные в хранилище данных. Однако даже в хранилище данных проблемы с целостностью данных - не редкость.

SQL Server 2005 Analysis Services поддерживает кубы, построенные напрямую из оперативных хранилищ данных, и предлагает сложные элементы управления для обеспечения управления проблемами целостности данных, присущими таким системам. Администраторы баз данных могут сильно упростить свои задачи по управлению кубами, используя эти элементы.

Типы проблем, связанных с целостностью данных

В этой главе мы определим основные проблемы целостности данных. Для рассмотрения этих проблем мы будем использовать следующую реляционную модель:

Таблица фактов sales имеет внешний ключ product_id, который указывает на первичный ключ product_id в таблице измерений product.

Таблица измерений product имеет внешний ключ product_class_id, который указывает на первичный ключ product_class_id в таблице измерений product_class.

Рис.1. Реляционная модель

Ссылочная целостность

Проблемы ссылочной целостности (Referential integrity, RI) являются наиболее типичными проблемами целостности данных в реляционных базах данных. Ошибка RI - это по существу нарушение ограничения первичный ключ-внешний ключ. Например:

Таблица фактов sales имеет запись с таким значением product_id, которое не существует в таблице измерений product.

Таблица измерений product имеет такое значение product_class_id, которое не существует в таблице измерений product_class.

Значения NULL

Хотя значения NULL обычны и даже приветствуются в реляционных базах данных, они требуют особой обработки в Analysis Services. Например:

Таблица фактов sales имеет запись со значением NULL в столбцах store_sales, store_cost и unit_sales. Это может быть интерпретировано или как транзакция с нулевыми продажами, или как несуществующая транзакция. Результаты запроса MDX (NON EMPTY) будут различаться в зависимости от интерпретации.

Таблица фактов sales имеет запись со значением NULL в столбце product_id. Хотя это и не является ошибкой ссылочной целостности в реляционной базе данных, эту проблему целостности данных Analysis Services должен обрабатывать.

Таблица product имеет запись со значением NULL в столбце product_name. Так как этот столбец передает ключи и имена товаров в Analysis Services, то значение NULL может быть оставлено как есть, сконвертировано в пустую строку, и т.д.

Ошибки в связях

Analysis Services позволяет определять связи между атрибутами измерений. Например, измерение Product может иметь отношение "многие-к-одному" между столбцами brand_name и product_class_id. Рассмотрим две записи в таблице product со следующими значениями столбцов:

Это нарушение связи "многие-к-одному", так как значение столбца brand_name "Best Choice" имеет два связанных с ним значения столбца product_class_id.

Элементы управления целостностью данных

В этой главе мы рассмотрим различные элементы управления, которые предлагает Analysis Services администраторам баз данных для решения проблемам целостности данных. Заметьте, что эти элементы не являются полностью независимыми. Например, Null Processing (обработка Null) зависит от Unknown Member (неизвестный элемент), а Error Configuration (обработка ошибок) зависит от Null Processing и Unknown Member.

Unknown Member (неизвестный элемент)

Объект Dimension имеет свойство UnknownMember, которое принимает три возможных значения - None, Hidden и Visible. Когда UnknownMember=Hidden/Visible, Analysis Server автоматически создает специальный элемент, называемый Unknown Member (неизвестный элемент) в каждом атрибуте измерения. UnknownMember=Hidden показывает, что неизвестный элемент будет скрыт для результатов запроса и наборов строк схемы. Значение по умолчанию для свойства UnknownMember - None.

Свойство UnknownMemberName может использоваться для определения имени неизвестного элемента. Свойство UnknownMemberTranslations может быть использовано для определения локализованных заголовков неизвестного элемента.

На рис.2 показано измерение Product с UnknownMember=Visible и UnknownMemberName="Invalid Product".

Рис.2. Измерение Product

Null Processing (обработка Null)

Объект DataItem используется в Analysis Services DDL для определения метаданных о любом скалярном элементе данных. Он включает:

Ключевой столбец (столбцы) атрибута

Имя столбца атрибута

Столбец-источник атрибута

Объект DataItem содержит много свойств, включая следующие:

Свойство NullProcessing определяет, какое действие должен предпринять сервер, когда он обнаруживает значение NULL. Это свойство может принимать пять возможных значений:

ZeroOrBlank - сообщает серверу, чтобы он сконвертировал значение NULL в нулевое значение (для числовых элементов данных) или в пустую строку (для строковых элементов данных). Так обрабатывает значения NULL Analysis Services 2000.

Preserve - сообщает серверу, чтобы он оставил значения NULL. Сервер может хранить NULL, как любое другое значение.

Error - сообщает серверу, что значение NULL запрещено в этом элементе данных. Сервер сгенерирует ошибку целостности данных и проигнорирует эту запись.

UnknownMember - сообщает серверу обработать значение NULL как неизвестный элемент. Сервер так же сгенерирует ошибку целостности данных. Эта опция применима только для ключевых столбцов атрибутов.

Default - условное значение по умолчанию. Оно подразумевает использование ZeroOrBlank для измерений и кубов, и UnknownMember для структур добычи данных (mining structures) и моделей.

Заметьте, что опции NullProcessing - Error и UnknownMember, генерируют ошибки целостности данных, а другие опции - нет.

На следующем рисунке показан редактор DataItem для ключевых столбцов атрибута измерения.

Рис.3. Редактор DataItem Collection.

Список ошибок

Перед рассмотрением элемента управления обработки ошибок Error Configuration нам нужно четко определить различные типы ошибок целостности данных, с которыми может встретиться сервер. Мы уже узнали о двух из них в предыдущей главе об обработке Null. Ниже приведен полный список:

NullKeyNotAllowed - эта ошибка генерируется, когда встречается запрещенное значение NULL и запись игнорируется (когда NullProcessing = Error).

NullKeyConvertedToUnknown - эта ошибка генерируется, когда ключевое значение NULL обрабатывается как неизвестный элемент (когда NullProcessing = UnknownMember).

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

KeyNotFound - это классическая ошибка ссылочной целостности в реляционных базах данных. Она может встретиться как при обработке партиций, так и при обработке измерений.

Error Configuration (обработка ошибок)

Объект ErrorConfiguration является центральным в управлении ошибками целостности данных. Сервер имеет конфигурацию ошибок по умолчанию (в конфигурационном файле msmdsrv.ini). Конфигурация ошибок также может быть определена в базе данных, измерении, кубе, группе измерений и партиции. Кроме того, конфигурирование ошибок также может быть задействовано для команд Batch и Process.

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

KeyErrorLogFile - это файл, в который сервер логирует ошибки целостности данных.

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

KeyErrorLimitAction (по умолчанию = StopProcessing) - это действие, которое предпримет сервер, когда будет достигнут предел количества ошибок. Это свойство имеет две опции:

• StopProcessing - сообщает серверу, чтобы он прервал обработку.

  StopLogging - сообщает серверу, чтобы он продолжил обработку, но остановил логирование дальнейших ошибок.

KeyErrorAction (по умолчанию = ConvertToUnknown) - это действие, которое должен выполнить сервер, когда возникает ошибка KeyNotFound. Свойство имеет две опции:

• ConvertToUnknown - сообщает серверу, чтобы он обработал неправильное значение ключа как неизвестный элемент.

  DiscardRecord - сообщает серверу, чтобы он проигнорировал эту запись. Так Analysis Services 2000 обрабатывает ошибки KeyNotFound.

NullKeyNotAllowed (по умолчанию = ReportAndContinue)

NullKeyConvertedToUnknown (по умолчанию = IgnoreError)

KeyDuplicate (по умолчанию = IgnoreError)

KeyNotFound (по умолчанию = ReportAndContinue) - действие, которое должен выполнить сервер, когда возникает ошибка целостности данных этого типа. Свойство имеет три опции:

• IgnoreError - сообщает серверу, чтобы он продолжал обработку до достижения предела количества ошибок без логирования ошибок.

  ReportAndContinue - сообщает серверу, чтобы он продолжал обработку до достижения предела количества ошибок с логированием ошибок.

  ReportAndStop - сообащает серверу, чтобы он логировал ошибку и прервал обработку немедленно (вне зависимости от предела количества ошибок).

Заметьте, что сервер всегда выполняет правила NullProcessing перед правилами ErrorConfiguration для каждой записи. Это важно, так как обработка NULL может приводить к ошибкам целостности данных, которые потом должны обработать правила ErrorConfiguration.

На следующем рисунке показаны свойства ErrorConfiguration для куба в панели свойств.

Рис.4. Панель свойств

Сценарии

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

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

Таблица фактов sales имеет записи с product_id, которые не существуют в таблице измерений product. Сервер выдаст ошибку KeyNotFound во время обработки. По умолчанию ошибки KeyNotFound логирутся и ведется их подсчет до предела количества ошибок, который по умолчанию равен нулю. Поэтому обработка прервется на первой же ошибке.

Решением является изменение ErrorConfiguration для группы измерений. Ниже показаны две альтернативы:

Установить KeyNotFound = IgnoreError.

Установить KeyErrorLimit равным достаточно большому числу.

По умолчанию обработка ошибок KeyNotFound заключается в постановке записи из таблицы фактов в соответствие неизвестному элементу. Другой альтернативой является установка KeyErrorAction равным DiscardRecord, чтобы проигнорировать эту запись из таблицы фактов.

Проблемы целостности данных в таблице измерений SnowFlaked

Таблица измерений product имеет записи с product_class_id, которых не существует в таблице измерений product_class. Эта проблема обрабатывается таким же образом, как и в предыдущей главе, кроме необходимости модификации ErrorConfiguration для измерения.

Внешние ключи со значением NULL в таблице фактов

Таблица фактов sales имеет записи, в которых product_id равен NULL. По умолчанию все значения NULL конвертируются в ноль, и уже нулевое значение ищется в таблице product. Если существует product_id, равный нулю, то соответствующие данные таблицы фактов соотносятся с этим значением product (возможно, это не то, что Вы хотели). В противном случае выдается ошибка KeyNotFound. По умолчанию ошибки KeyNotFound логируются и производится подсчет количества таких ошибок до предела количества ошибок, который по умолчанию равен нулю. Поэтому обработка прервется после первой же ошибки.

Решением является изменение NullProcessing в свойстве группы измерений. Ниже показаны две альтернативы:

Установить NullProcessing = ConvertToUnknown. Эта установка сообщает серверу, чтобы он поставил записи со значениями NULL в соответствие неизвестному элементу "Invalid Product". При этом также генерируются ошибки NullKeyConvertedToUnknown, которые по умолчанию игнорируются.

Установить NullProcessing = Error. Эта установка сообщает серверу, чтобы он игнорировал записи со значением NULL. При этом также генерируются ошибки NullKeyNotAllowed, которые по умолчанию логируются и их количество подсчитывается до достижения предела количества ошибок. Это можно регулировать с помощью изменения ErrorConfiguration в группе измерений.

Рис.5. Диалоговое окно Edit Bindings

Заметьте, что свойство NullProcessing должно быть установлено у KeyColumn свойства группы измерений. Во вкладке Dimension Usage дизайнера кубов отредактируйте отношение между измерением и группой измерений. Нажмите кнопку Advanced, выберите свойство масштабируемости и установите NullProcessing.

NULL в таблице измерений Snowflaked

Таблица измерений product имеет записи, в которых product_class_id имеет значение NULL. Эта проблема обрабатывается таким же образом, как и в предыдущей главе, кроме необходимости установки NullProcessing у KeyColumn в DimensionAttribute (в панели Properties дизайнера измерений).

Несогласованные отношения в таблице измерений

Как было описано ранее, несогласованные отношения в таблице измерений приводят к задвоению ключей. В примере, описанном ранее, brand_name со значением "Best Choice" появляется дважды с разными значениями product_class_id. Это приводит к ошибке KeyDuplicate, которая по умолчанию игнорируется, а сервер игнорирует задвоенную запись.

В качестве альтернативы можно установить KeyDuplicate = ReportAndContinue/ReportAndStop, что приведет к логированию ошибок. Этот лог можно будет потом исследовать для определения потенциальных недостатков в дизайне измерений.

Заключение

Решение проблем целостности данных может оказаться нелегкой задачей для администраторов баз данных. SQL Server 2005 Analysis Services предоставляет сложные элементы управления, такие, как Unknown Member (неизвестный элемент), Null Processing (обработка Null) и Error Configuration (конфигурирование ошибок), которые сильно упрощают задачи управления кубами.