|
|
  |
Главная страница / Архитектура отрасли ПЛАТФОРМА БЕЗ «ДЫР»?C каждым годом Microsoft «сдает» позиции самой уязвимой операционной системы, что не может не радовать. Логично предположить, что в текущем году число уязвимостей будет еще меньше: механизмы защиты в платформе .NET реализованы на более качественном уровне. Рассмотрим их более пристально. Для начала уточним задачи, для решения которых разрабатывалась данная концепция. • Создание новых операционных систем, предназначенных для различных устройств (не только компьютеров) и позволяющих пользователям работать с распределенными данными независимо от их расположения. • Создание надежных серверов, обеспечивающих поддержку критичных для компании приложений, в первую очередь предназначенных для работы в Internet. Основные компоненты Можно выделить несколько основных компонентов .NET Framework, участвующих во всех механизмах обеспечения безопасности новой серверной платформы, призванной составить конкуренцию Java 2 Platform компании Sun. Common Language Runtime (CLR) – инструмент, позволяющий выполнять модули не на «родном» (для данной архитектуры компьютера) языке, а на промежуточном байт-коде, так называемом Microsoft Intermediate Language (MSIL). Знатоки Java смогут провести аналогию с байт-кодом Java, который должен выполняться на любом Java-совместимом компьютере. Иными словами, программы, написанные на любом языке высокого уровня, например C, Pascal и т. д., транслируются в MSIL, который и выполняется в среде CLR. В свою очередь механизм Common Language Runtime компилирует MSIL в машинный код на лету (Just-In-Time) либо с помощью CLR Native Image Generator. Однако при компиляции в машинный код учитываются некоторые внешние факторы, в том числе и условия безопасности. Один из MSIL-модулей может ограничить перечень разрешенных действий в вызываемом им подчиненном MSIL-модуле. Например, .NET-программа может разрешить внешним приложениям только чтение локальных файлов, в то время как локальным приложениям предоставить полный доступ. Как видим, данная схема очень напоминает браузеры — промежуточное звено, выполняющее апплеты и иной мобильный код (ActiveX и т. д.) с учетом определенных прав доступа. Такой контроль всех действий MSIL-модулей получил название «управляемого кода» (managed code). Тем самым Microsoft обещает как можно быстрее избавиться от неуправляемого кода (в обход CLR), по вине которого и наносится основной ущерб информационным ресурсам (троянцы, вирусы, черви и т. д.). С точки зрения безопасности CLR напоминает «песочницу» (sandbox) Java, контролирующую исполнение кода и не позволяющую ему выполнить неожиданные или враждебные действия. Второй основной компонент – библиотеки классов, которые разработчики могут многократно использовать в своих программах, не изобретая велосипед. С помощью таких классов реализованы различные защитные функции, включая разграничение полномочий, аутентификацию, криптографическую защиту и т. д. Система безопасности .NET состоит из ряда элементов, рассмотрим нене показаний (evidence-based security). • Безопасность на уровне кода (access code security). • Процесс верификации (verification process). • Безопасность на уровне ролей (role-based security). • Криптография. • Безопасность на уровне приложений (applications domain). Политика безопасности К основным элементам данного механизма можно отнести: политику безопасности (policy), полномочия (permissions) и показания (evidence). Политика безопасности уже давно известна всем пользователям не только ОС семейства Windows. Она определяет, какие субъекты (пользователи, программы и т. д.) могут получить доступ к защищаемым ресурсам, исключая попытки нарушения их целостности, доступности или конфиденциальности. Описываемая на XML политика безопасности применяется не только к каждому пользователю, но и к каждому компьютеру корпоративной сети. Полномочия описывают защищаемые ресурсы и связанные с ними права доступа. .NET Framework определяет большое число защищаемых ресурсов, включая системный реестр, файлы, журналы регистрации, DNS, Web-ресурсы, принтер и т. д. С помощью показаний устанавливается, откуда получен тот или иной код и сопутствующие параметры, например: • автор кода (технология Authenticode), • источник кода (конкретный адрес URL, зона безопасности /Internet, локальная сеть и т. д.). В целом такой подход повышает защищенность системы, так как помимо настроек, создаваемых администратором, в ней по умолчанию реализованы некоторые механизмы, не допускающие тех или иных несанкционированных действий. .NET становится еще ближе рядовому пользователю, не имеющему глубоких познаний в области обеспечения информационной безопасности. Безопасность кода Разработчик самостоятельно определяет привилегии, необходимые исполняемому коду для нормальной работы. Если одной программе нужен только доступ к чтению, второй – к модификации, то третьей – полный доступ и т. д. Такие полномочия задаются в самом коде и всегда «следуют» за ним, что позволяет создавать действительно мобильные и переносимые приложения. В процессе своего выполнения код не только может «запросить» права на доступ к какому-либо объекту (например, файлу), но и потребовать от вызывающей стороны (пользователя или другой программы) соответствующих полномочий на обращение к себе. Такой механизм позволяет создавать программы, которые могут выполняться только администратором безопасности и никем иным, а также код, который не сможет получить доступ к локальным файлам, даже если администратор разрешил такое действие («разработчик превыше всего»). Проверив код, система безопасности .NET формирует для него набор привилегий, с учетом которых код и выполняется в системе. Процесс верификации Технология CLR позволяет существенно ограничить возможности несанкционированных действий со стороны враждебного кода, в том числе не разрешает создавать указатели на произвольный адрес в памяти. Тем самым она защищает приложения от роцессе исполнения MSIL-модулей посредством верификации. Однако существует потенциальная возможность обойти названный защитный механизм, для чего можно использовать неуправляемый код, который напрямую обращается к ресурсам компьютера в обход CLR. Ролевая безопасность и криптография Данные механизмы известны уже давно, отметим лишь, что в .NET предусмотрены так называемые провайдеры аутентификации, которые удостоверяют, что субъект, пытающийся получить доступ к защищаемому ресурсу, именно тот, за кого себя выдает. В настоящее время .NET Framework поддерживает аутентификацию с помощью cookies, Passport (собственная технология Microsoft), Kerberos, X.509, NTLM, криптографическую аутентификацию и т. д. Библиотеки классов .NET Framework реализуют большое число криптографических примитивов, которые используются как встроенными приложениями, так и приложениями, разработанными внешними разработчиками. Эти примитивы применяют давно известные алгоритмы: • RSA, DSA – шифрование и ЭЦП с открытыми ключами; • DES, TripleDES, RC2 – симметричное шифрование; • MD5 и SHA1 – функция хэширования. С помощью спецификации CryptoAPI могут быть подключены и другие алгоритмы, в том числе российские ГОСТ 28147-89, ГОСТ Р 34.10-01, ГОСТ Р 34.11-94. Защита приложений Последний из рассматриваемых механизмов – защита приложений. Обычно каждому приложению выделяется своя, изолированная от других приложений область (отдельный процесс), в рамках которой и выполняется приложение. Таким образом предотвращается непосредственное вмешательство одного приложения в работу другого. Однако на очень загруженных серверах такой подход является неоправданным и зачастую нереализуемым. Возможность контроля управляемого кода в рамках CLR и процесс верификации позволяют реализовать при исполнении одного процесса несколько изолированных приложений, каждое из которых обладает собственными полномочиями. Уязвимости Идеи, заложенные в .NET Framework, очевидны и не являются уникальными – унификация набора базовых функций (библиотеки классов), улучшение управляемости приложений, в том числе и с точки зрения безопасности (CLR). Концепция .NET вобрала в себя все известные технологии, используемые в предыдущих версиях решений Microsoft и в программных продуктах других компаний. Однако, как уже бывало не раз, провозгласив прекрасную идею, Microsoft пошла своим путем. Как говорится, «хотелось как лучше, а получилось как всегда». Любая, даже самая замечательная идея может быть дискредитирована неудачной ее реализацией, а Microsoft славится этим. Большим скандалом ознаменовался в Сан-Франциско день 13 февраля 2002 года, когда на конференции VSLive были представлены .NET Framework и Visual Studio.NET. Однако уже назавтра компания Cigital, которая занимается разработкой программных средств в области управления информационными рисками, выпустила пресс-релиз (http://www.cigital.com/news/mscompiler.html) с сообщением об уязвимости средств ра Уязвимость присуща одному из компонентов данных программных средств, ответственному за контроль переполнения буфера. Примечательно, что и обнаруженная уязвимость относилась к данному классу. Иными словами, компонент Visual C++.NET оказался уязвим по отношению к проблеме, от которой должен был защищать. Самое опасное, что эта уязвимость автоматически переносится во все приложения, написанные с помощью Visual C++.NET. Даже если программист и не допустит такой оплошности, за него «постарается» Microsoft, внеся в созданную программу фрагмент, который могут использовать злоумышленники. «Вместо того чтобы защищать, он (уязвимый компонент – А.Л.) вообще ничего не делает», – говорится в пресс-релизе Cigital. Данной информацией можно было бы и ограничиться, если бы не сообщения о первом вирусе, который специально разработан для платформы .NET. В середине января текущего года обнаружен вирус W32/Donut, который, по мнению специалистов, был специально выпущен на волю, чтобы продемонстрировать уязвимость .NET. *** В заключение стоит напомнить, что «благими намерениями выстлана дорога в ад». Предложив действительно интересную и эффективную концепцию системы защиты своей новой архитектуры .NET, Microsoft не уделила достаточно внимания ее реализации. Однако упущение Microsoft – это своего рода шанс многим небольшим (по сравнению с Microsoft) компаниям, которые «живут за счет» производства различных средств обеспечения информационной безопасности для операционных систем Microsoft. Главная страница / Архитектура отрасли |