Введение
Работа конференции проходила в пять потоков: построение информационной инфраструктуры; системы повышения производительности бизнеса; интеграция корпоративных приложений; технологии информационной безопасности; управление информационными ресурсами предприятия.
Тематика докладов, по сравнению с прошлым годом, была не столь насыщена. Большинство докладов было посвящено новым технологиям, информация о которых опубликована на сайте компании Microsoft.
Дэвид Лебланк: разработка защищённых приложений
Почему мне надо волноваться о безопасности приложения? — с этого вопроса начался доклад Дэвида Лебланка.
Корпоративное приложение имеет прямое отношение к безопасности сети, более 50% проблем безопасности уходит к разработчикам.
Защищённость — это вещь, которую надо принимать во внимание с самого начала разработки приложения. Для повышения безопасности необходимо придерживаться комплексного подхода при разработке приложения.
Во-первых, это обучение людей. Образование имеет здесь очень важное значение. В университетах учат создавать эффективные программы, но созданию безопасных программ уделяется очень мало внимания.
Второе — этап проектирования.
Термин «глубинная защита» предполагает массу уровней обороны. При обороне замка — это и стены, и ров, и какие-то другие препятствия, которые должны приостановить врага. Также и при проектировании приложения необходимо заложить несколько уровней защиты.
Принцип SD3, который включает три правила: безопасность согласно проекту, безопасность по умолчанию и безопасность при развёртывании. Не стоит надеяться, что пользователи начнут освоение программного продукта с изучения справочной системы. При конфигурации системы необходимо назначить безопасные параметры по умолчанию. При разработке приложения воспользуйтесь следующими рекомендациями: не стройте систему защиты на ограничении информации о системе, разделяйте код и данные, защищайте все уровни, используйте наименьшие привилегии, принимайте как аксиому, что внешние системы не защищены по определению.
Третий этап — разработка. Здесь основное правило — учитесь на ошибках прошлого. Microsoft составила документацию своих ошибок, изучите и не повторяйте их.
Кроме того, стоит очень внимательно предоставлять права на внесение исправлений и обязательно контролировать внесенные изменения.
И, наконец, тестирование. Цель тестирования защиты — убедиться, что приложение действительно противостоит атакам. В безопасном продукте не должно быть никаких «дополнительных» функций, которые могли бы сделать продукт уязвимым. Хороший тестировщик защиты должен искать такие функции и, обнаружив их, пытаться найти в них слабые места.
Один из принципов, которым вы должны руководствоваться на всём протяжении разработки приложения, — это моделирование угроз.
Главная причина, вынуждающая заниматься моделированием опасностей, в том, что невозможно создать по-настоящему защищённое приложение, не выяснив, что именно ему грозит, и не сделав всё для снижения общей уязвимости.
Процесс моделирования опасностей начинается с создания группы моделирования опасностей и разложения системы на составляющие. Следующий вопрос — это определение опасностей, грозящих системе, и упорядочение опасностей в порядке убывания степени их серьезности. После этого надо определить методы реагирования на опасности, выбрать методы борьбы с опасностями.
Далее кратко были рассмотрены методы безопасного кодирования.
Переполнение буфера является одной из самых серьёзных угроз. Основная причина переполнения буфера — плохой стиль программирования, отсутствие защищённых и простых в использовании строковых функций и непонимание последствий тех или иных ошибок. К ошибкам такого типа относятся и целочисленное переполнение, и переполнение стека, и ошибки индексации массива.
Как предотвратить переполнение буфера? Во-первых, это надежный код! Во-вторых, всегда проверяйте входные данные — всё, что находится вне вашей функции, следует рассматривать как небезопасное.
Еще один вид угроз — это атаки типа «отказ в обслуживании». И здесь крах системы связан с качеством программного обеспечения. В этом случае можно выделить атаки, вызывающие крах приложения, перегрузку процессора, нехватку памяти, нехватку ресурсов.
Пример: сервер слушает порт. Злоумышленник постоянно подключается, в результате чего сервер падает.
Как смягчить такую угрозу? Можно использовать перенаправление, но об этом надо заботиться с этапа разработки приложения.
Следующая «беда» — это плохое шифрование. Не нужно хранить секреты в коде или файлах конфигурации. При определении прав доступа следует отталкиваться от модели выбранных ролей и конфиденциальности информации.
К примерам незащищённого кода следует отнести встраивание пароля в код приложения, или использование имени переменной password для хранения пароля. Использование запросов, связанных с данными, которые определяет пользователь, также могут привести к взлому системы. Кроме этого, не стоит включать в окно сообщения об ошибке информацию о произошедшем исключении.
Таким образом, для написания безопасных приложений необходимо исправлять все ошибки.
Алексей Федоров: стратегия развития средств разработки: первое представление Longhorn
Компания Microsoft планирует к концу 2004 года выпустить новую версию Visual Studio, известную пока под именем Whidbey.
Новый продукт должен удовлетворять следующим требованиям: обеспечить повышение производительности и поддержку будущих технологий, а также упрощение развертывания и управления. Введены новые возможности для разработчиков, обеспечивающие одинаковую сложность для разработки различных типов приложений, как для Windows, так и для Web, Office и мобильных устройств.
Каким образом это обеспечивается?
Введена новая функциональность в IDE, заключающаяся в возможности настраивать внешний вид, используемый для программирования язык. Справочная система может быть отфильтрована по языку, а также по типу создаваемого приложения. Встроены форматы кода, обеспечивающие снижение ручного кода на 50%.
Коллекция ошибок позволяет автоматизировать процесс исправления ошибок. При опечатке появляется всплывающее меню, предлагающее выбрать наиболее подходящее ключевое слово.
При возникновении исключительной ситуации появляется окно с подробной информацией об ошибке и ссылкой на соответствующий раздел справочной системы.
Пространство имён My обеспечивает доступ к часто используемым функционалам: Application, User, Computer, Forms, Resource и др., что приводит к сокращению числа строк. Так, примитивы вывода на принтер занимают всего 3 строки кода.
Новые возможности языка.
Расширение языков увеличит производительность, по приблизительным оценкам, на 30%. Встроенные средства рефакторинга (преобразование плохо написанного кода в хорошо написанный) позволяют преобразовывать любой выделенный фрагмент в процедуру или функцию. Кроме того, средства рефакторинга обеспечивают автоматическое преобразование кода по всей программе при изменении порядка параметров процедуры.
Обобщения — расширения языка, которые позволяют не указывать тип до времени компиляции.
Расширение .NET Framework включает поддержку 64-битной архитектуры, улучшенную адаптацию в ASP.NET, а также средства безопасности.
Поддержка MS Office System.
Для поддержки разработки клиентских приложений упор был сделан на простоту создания и развёртывания, а также на поддержку стилей XP.
Для Microsoft Office будет обеспечена поддержка написания кода на VB, C# для Word, Excel, PowerPoint.
Интеграция с SQL Server Windbey.
Будущий продукт обеспечит управляемый код для функций, триггеров, хранимых процедур; сосуществование кода на TSQL и управляемого кода.
Расширения для корпоративных приложений связаны с созданием средств анализа и дизайна, кроме того, обеспечивается возможность управления конфигурацией (мониторинг, среда открыта, что позволяет интегрировать свои решения). Ядро сборки приложения MS Build основано на XML.
Таким образом, Visual Studio — это первый шаг на пути к OC Longhorn. Visual Studio будет работать и на новой платформе Win FX.
История развития платформ от компании Microsoft началась с MS Dos, далее появилась Win16, затем Win32, сейчас все усилия компании направлены на разработку Win FX.
В основе новой платформы в качестве структурной программной среды будет использоваться .NET Framework.
Платформа включает несколько частей.
Первая часть Avalon — для разработки пользовательского интерфейса. При создании приложения будет возможность выбрать тип — тонкий, толстый или какой-то другой клиент. Каждый тип предполагает специфический способ написания приложения. Однако любой тип клиентского приложения будет описываться на XML, а дальше, в зависимости от контекста, преобразовываться в управляемый код. Код приложения отделён от представления.
Вторая часть WinFS — для управления информацией. Каждое приложение хранит данные в своём формате. Отсюда возникают искусственные границы между данными. Для решения проблем интеграции между приложениями WinFS создаёт ассоциации между различными форматами (для этого имеется набор схем для представления информации).
Третья часть Indigo — для поддержки коммуникаций (транзакции, очередь сообщений, инфраструктура). Компонент Indigo появится на рынке в следующем году.
Итак, всё направлено на разработку новой платформы, новых средств, обеспечивающих большую производительность, большую безопасность и простоту разработки.
Алексей Соболев: антивирусная защита информационной системы
Скорость распространения вирусов в настоящее время уменьшилась до 24 часов, вирус SQL Slammer достиг 90% потенциальных жертв за первые 10 минут жизни, тело этого вируса удваивалось каждые 8,5 секунд.
Как защититься от попадания вируса? Раньше этот вопрос решался установкой антивирусных программ. Недавно вопрос выбора антивирусной программы сводился к вопросу «кто чаще обновляет базы?». В настоящее время для борьбы с вирусами существует Computer Antivirus Research Organization, в рамках которой обмен телом вируса происходит в течение 1 часа.
Характер вирусной угрозы изменился: вирусы внедряют себя в HTML файлы, в Еmail, используют множество точек атаки, вносят изменения в реестр, распространяют конфиденциальную информацию — без участия пользователя удалённо запускают себя, не имея файловой структуры. На фоне этого для борьбы с вирусами необходима комплексность.
Комплексная защита предусматривает защиту на трёх уровнях — рабочих станциях, серверах, шлюзах, а также централизованное управление.
Пример: несмотря на то, что 96% предприятий используют антивирусную защиту, 43% страдает от вирусных атак.
В чём проблема? Может в плохих антивирусных продуктах? Нет.
Рассмотрим ещё один простейший пример. Построен дом из качественных материалов, но постоянно течёт крыша, ветер «ходит». В чём проблема? В используемых технологиях. Так и при антивирусной защите — необходима технология.
Какие существуют проблемы? В результате естественного роста предприятия происходила поэтапная закупка программного обеспечения (ПО), что порождает разнородность программ, операционных систем и антивирусных средств, а также отсутствие централизованного управления и сложность обновления.
Для решения этой проблемы необходимы знания и опыт в области комплексной антивирусной защиты. Для создания комплексной антивирусной защиты существуют 2 стратегии: одновендовая (на всех трёх уровнях использует ПО одного разработчика) и разновендовая (ПО одного разработчика на одном уровне, другого разработчика на другом и третьего — на третьем).
Первая стратегия обеспечивает низкую стоимость владения, упрощение администрирования (единая консоль, интерфейс, единая база сигнатур, единое наименование), единую политику предотвращения атак и приводит к высокой эффективности антивирусной защиты.
С другой стороны, разновендовая стратегия обеспечивает двойную проверку, даёт возможность установить антивирусное ПО на всё «железо» (не всегда один поставщик закрывает все платформы), уменьшает зависимость от успешности и рыночной политики одного поставщика.
Таким образом, одновендовая стратегия даёт максимальную экономическую эффективность за меньшую стоимость, а при выборе разновендовой стратегии решающим фактором становится надёжность (не цена), когда базовый поставщик (вендор) не обеспечивает полного покрытия.
Перечислим современные требования, предъявляемые к защите. Во-первых, это 100% обнаружение вирусов, полнота покрытия и интеграция продуктов. Очень важный фактор — это управляемость (нет централизованного управления — нет защиты), и, соответственно, автоматическое распространение и обновление антивирусного ПО. Возможность работы с мобильными пользователями. Очень важную роль играют централизованные отчёты (необходимы для обоснования того, на что потрачены деньги). Антивирусное ПО должно быть производительным, не мешать работе пользователей, и обладать возможностью обнаружения прочих вредоносных кодов (ActiveX, Java). Не менее важная характеристика — реакция поставщика на новые угрозы (быстрое обновление, предлагаемые технические средства защиты) и предоставляемые поставщиком сервис и поддержка. Это касается оповещения и его качества (каждый день появляется не менее 50 вирусов, извещение о каждом из них не есть качественное извещение, необходимы те извещения, на которые необходимо немедленно отреагировать).
А теперь рассмотрим методологию построения антивирусной защиты. Рассмотрим два варианта решения — индивидуальное и типовое.
Итак, индивидуальное решение. Его цель — построить максимально эффективную систему при заданном ограничении бюджетных средств.
Для построения этого решения необходимо пройти три этапа: аудит, решение задачи управления рисками и составление спецификаций.
Аудит. Необходимо проанализировать организационную структуру компании — базы данных, файловые структуры, доступ к Интернету, проанализировать эти ресурсы в соответствии с привязкой к подразделениям и логической организации сети. Провести инвентаризацию всех рабочих станций (ОС, ПО, аппаратное обеспечение, типизация), серверов (ОС, сервисы, ресурсы, каналы, чем защищены), ИТ-службы (есть ли администратор безопасности, все кто влияет на безопасность).
Управление рисками. Риск будем вычислять по формуле: ценность ресурса * вероятность угрозы * уязвимость.
Определять будем не абсолютными величинами, а относительными, например баллами. Первый множитель должен определить менеджер компании, второй и третий множители — ИТ-менеджер.
Составление спецификаций заключается в определении приемлемого результата риска, составлении спецификаций, сравнении с бюджетом.
На основании составленных спецификаций составляется план поэтапных инвестиций и спецификации системы защиты ИС.
Данное решение позволяет получить оптимальное решение для данной компании, однако требует больших затрат по времени и ресурсам.
Типовое решение начинается с описания модели предприятия, после чего создаётся индивидуальное решение для построенной модели.
Чтобы применить типовое решение для предприятия, необходимо оценить количественное (не качественное!) отклонение и использовать дифференцированный подход к его изменению.
Итак, для построения централизованной системы защиты необходимо построить общее древо управления, обеспечить централизованное управление и сбор статистики.
Алексей Прохоров: интеграция Java/J2EE c .NET Framework
Перед разработчиком стоит следующая задача: необходимо разработать приложение для корпоративной сети на платформе MS .NET, которая должна использовать существующее приложение Identity Manager, созданное на платформе J2EE.
Условия: Identity Manager должен быть не только сервисом, авторизующим пользователей, но и должен уметь создавать иерархию ролей и прав внутри бизнес-системы.
Однако задача интеграции платформ .NET и J2EE порождает ряд проблем. Это и отсутствие встроенных решений в Java и .NET, направленных на интеграцию, а не на замену, и различие в архитектуре систем, языках программирования и базовых библиотеках классов. Сложность развёртывания систем, их сопровождение и поддержка, а также отсутствие встроенной поддержки на уровне средств разработки.
Решение этих проблем даёт дополнительные возможности масштабирования для решений на платформе Microsoft, возможность использования преимуществ .NET для приложений Java. Кроме этого, появляется возможность выбирать и использовать оптимальные технические решения бизнес-задач, а также возможность повторного кода.
Остановимся на трёх основных методах интеграции платформ .NET и J2EE.
Низкоуровневая интеграция.
Связь с Java осуществляется через Java Native Interface. Это решение подходит для маленьких приложений или утилит. Это решение не требует лицензирования, и характеризуется относительно простым способом развертывания. Однако следует отметить высокую сложность реализации при существующих ограничениях области применения (можно интегрировать только локальные приложения).
Цепочка Java — COM — .NET также позволяет интегрировать как локальные, так и распределённые приложения, а также даёт возможность использовать готовые решения. Но и здесь существуют проблемы. Выделим некоторые из них: COM — это морально устаревшая технология; стоимость данного решения будет увеличена за счёт лицензирования технологий. Кроме того, для этого решения характерна сложность развёртывания.
Распределённые системы
Использование CORBA. Область использования — высокомасштабируемые распределённые системы; дополнение существующих J2EE удобным интерфейсом на платформе Windows; доступ к Windows-сервисам из приложений J2EE. Это решение отличает существование промышленного стандарта взаимодействия в гетерогенных системах — CORBA, что, впрочем, ведёт к ряду проблем. Во-первых, это выбор ORB-поставщика, зависимость от ORB-поставщика обусловливает сложность развёртывания систем. Кроме этого, следует указать на существование разных спецификаций CORBA и на отсутствие поддержки этого стандарта Microsoft.
Абстрагирование от конкретного уровня протокола предоставляет использование .NET Remoting. В этом случае взаимодействие строится на основе HTTP и позволяет поставить чёткое соответствие между типами данных интегрируемых платформ. Однако здесь есть свои недостатки: .NET Remoting не стандартизирован, а также существует ограниченный набор решений на .NET Remoting.
Гетерогенные бизнес-системы
Первое решение — web-сервисы. Выделим положительные черты их использования: существующие промышленные стандарты; поддержка технологии со стороны Microsoft; а также развитые средства разработки. Недостатки этого решения основаны на использовании объектов Stateless, которые не дают уверенности в корректной работе, предоставляют плоский, а не объёмный интерфейс. В дополнение к этому существуют проблемы совместимости по причине несоблюдения или расширения базового стандарта.
Второе решение — Messaging Services. Это решение построено на очередях сообщений, обеспечивает Offline-подход, Messaging Services гарантирует доставку сообщений, приоритизацию сообщений и поддержку транзакций, возможно использование туннелирования. Преимущества этого решения заключаются в интеграции на уровне бизнеса, а не на уровне интерфейса; асинхронное взаимодействие упрощает схему обработки сообщений.
Третье решение — J# (следует отметить, что J# предполагает не интеграцию, а переход на платформу Microsoft). В J# встроена Sun SDK 1.4, она поддерживает все механизмы, в том числе серилизацию. Возможность использования любого протокола.
Далее, докладчик детально описал решение, предлагаемое их компанией для решения задачи, поставленной в начале доклада.
Алексей Шуленин: перспективы развития технологий Microsoft в области систем управления данными и бизнес-анализа
Этот доклад был посвящен новому программному продукту Microsoft — MS SQL Server Yukon. Были продемонстрированы новые возможности, информация о которых представлена на сайте Microsoft.
Перечислим некоторые возможности, о которых шла речь в докладе.
- Интеграция с CLR (из поля базы данных можно скачать картинку).
- Поддержка .NET. Возможность использования языков VB.Net, C#, J#, очень тесное взаимодействие с Whidbey (например, можно использовать CLR-триггер, чтобы зашифровать номер кредитной карточки с помощью встроенного в библиотеку алгоритма).
- Использование двух моделей безопасности: установка прав на вызов внутри и CLR-безопасность.
Таким образом, CLR обеспечивает вычислительные операции, операции доступа к файлам, шифрование.
В TransactSQL также появились новые функции, которые были продемонстрированы на конкретных примерах.
Однако, что конкретно будет представлено в MS Server Yukon, пока сказать трудно.
Этот доклад был насыщен примерами, которые демонстрируют всю мощь создаваемого продукта.
Заключение
Доклады конференции представили новые технологии компании Microsoft, идеи партнёров компании. Каждый смог услышать что-то новое, ещё неизвестное. В целом «Платформа 2004» явилась определяющим мероприятием в плане выбора технологий, выбора программного обеспечения. Но все жё надеемся, что следующая «Платформа», будет более насыщенной и интересной.
