Стеснение vbulletin. Отключение списка пользователей

03.03.2020

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

Чего потребитель ждет от компьютера? Того же самого, что и от телевизора. Вы его покупаете, подключаете, и он прекрасно работает следующие десять лет. ИТ-специалистам следует принять во внимание эти ожидания и сделать компьютеры такими же надежными и защищенными, как телевизоры.

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

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

Почему системы ненадежны?

Современные операционные системы имеют две особенности, из-за которых они теряют как в надежности, так и в защищенности. Во-первых, эти ОС огромны по размеру, а, во-вторых, в них очень плохо обеспечена изоляция ошибок. Ядро Linux имеет свыше 2,5 млн. строк кода, а ядро Windows XP как минимум в два раза больше.

Одно из исследований, посвященных изучению надежности программного обеспечения, показало, что программы содержат от 6 до 16 ошибок на каждые 1000 строк исполняемого кода. Согласно результатам другого исследования, частота ошибок в программах находится в пределах от 2 до 75 на каждые 1000 строк исполняемого кода , в зависимости от размера модуля. Даже если исходить из самой скромной оценки (6 ошибок на 1000 строк кода), ядро Linux, по всей видимости, содержит примерно 15 тыс. ошибок; Windows XP - как минимум в два раза больше.

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

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

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

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

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

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

Укрепленные операционные системы

Самый консервативный подход, Nooks , был разработан для того, чтобы увеличить надежность существующих операционных систем, таких как Windows и Linux. Технология Nooks поддерживает монолитную структуру ядра, в которой сотни или тысячи процедур связаны вместе в одном адресном пространстве и работают в режиме ядра. Этот подход сосредоточен на том, чтобы сделать драйверы устройств (основная причина всех проблем) менее опасными.

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

Цели проекта Nooks заключаются в следующем:

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

Защита ядра от некорректных драйверов - не главная цель. Впервые технология Nooks была реализована на Linux, но эти идеи в равной степени применимы к другим унаследованным ядрам.

Изоляция

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

Посредничество

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

Nooks предоставляет оболочки как для экспортируемых, так и для импортируемых функций. Теперь, когда ядро вызывает функцию драйвера или драйвер вызывает функцию ядра, вызов на самом деле направляется оболочке, которая проверяет корректность параметров и управляет вызовом. Несмотря на то, что суррогаты (stubs) оболочки (на рис. 1 они изображаются как линии, указывающие как внутрь, так и наружу драйвера) генерируются автоматически на основе прототипов функций, тело оболочки разработчикам приходится писать вручную. В целом группа Nooks написала 455 оболочек: 329 для функций, которые ядро экспортирует, и 126 - для функций, которые экспортируют драйверы устройств.

Когда драйвер пытается модифицировать объект ядра, его оболочка копирует объект в домен защиты драйвера, то есть в его частные страницы, открытые для чтения и записи. Затем драйвер меняет копию. Если запрос был выполнен успешно, менеджер изоляции копирует модифицированные объекты обратно в ядро. Таким образом, сбой в работе драйвера или ошибка во время вызова всегда оставляют объекты ядра в корректном состоянии. Операции контроля за импортируемыми объектами специфические для каждого объекта, в силу чего группе Nooks пришлось вручную писать код для контроля 43 классов объектов, которые используют драйверы Linux.

Восстановление

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

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

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

Ограничения

Несмотря на то, что, согласно экспериментам, Nooks может обнаруживать 99% фатальных ошибок драйвера и 55% не фатальных, он далеко не совершенен. Например, драйверы могут выполнять привилегированные команды, которые они выполнять не должны; они могут записывать данные в некорректные порты ввода/вывода и выполнять бесконечные циклы. Более того, группе Nooks большое количество оболочек пришлось написать вручную, и эти оболочки могут содержать ошибки. Наконец, при данном подходе невозможно запретить драйверам записывать данные в любое место памяти. Тем не менее это потенциально весьма полезный шаг к повышению надежности унаследованных ядер.

Паравиртуальные машины

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

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

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

В частности, в 90-х годах группа разработчиков из университета Карлсруэ создала микроядро L4 . Они смогли запустить слегка модифицированную версию Linux (L4Linux) на L4 в режиме, который можно называть видом виртуальной машины . Позже разработчики выяснили, что вместо того чтобы запускать только одну копию Linux на L4, они могут запускать несколько копий. Как показано на рис. 2 , эта мысль привела к идее использования одной из виртуальных машин Linux для работы прикладных программ, а другой или нескольких - для работы драйверов устройств.

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

Поскольку драйверы устройств работают на аппаратном обеспечении в режиме пользователя, основной вопрос заключается в том, как они будут выполнять ввод/вывод и обрабатывать прерывания. Физический ввод/вывод поддерживается за счет добавления примерно 3 тыс. строк кода к ядру Linux, на котором работают драйверы, благодаря чему драйверы могли использовать сервисы L4 для ввода/вывода вместо того, чтобы делать это самостоятельно. Дополнительные 5 тыс. строк кода поддерживают взаимодействия между тремя изолированными драйверами (диска, сети и шины PCI) и виртуальной машиной, в которой выполняются прикладные программы.

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

Параметры производительности показывают, что накладные расходы при использовании паравиртуализованных машин составляют около 3-8%.

Мультисерверные операционные системы

Первые два подхода предусматривают модификацию унаследованных систем. Следующие два посвящены будущим системам.

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

Мультисерверная архитектура

Для того чтобы лучше понять, в чем состоит идея мультисерверной операционной системы, обратимся к современному примеру. Как показано на рис. 3 , в Minix 3, микроядро обрабатывает прерывания, предоставляет базовые механизмы для управления процессами, реализует взаимодействия между процессами и выполняет планирование процессов. Оно также предоставляет небольшой набор вызовов ядра для авторизованных драйверов и серверов, такие как чтение избранной части адресного пространства конкретного пользователя или запись в авторизованные порты ввода/вывода. Драйвер часов использует то же адресное пространство, что и микроядро, но он планируется как отдельный процесс. Ни один другой драйвер в режиме ядра не работает.

Над микроядром находится уровень драйверов устройств . Каждое устройство ввода/вывода имеет свой собственный драйвер, который функционирует как отдельный процесс в своем собственном частном адресном пространстве, защищенном с помощью аппаратного модуля управления памятью (MMU). Этот уровень включает в себя процессы драйверов для диска, терминала (клавиатуры и дисплея), Ethernet, принтера, аудио и так далее. Эти драйверы работают в режиме пользователя и не могут выполнять привилегированные команды или операции чтения и записи на портах ввода/вывода компьютера. Для того чтобы получить эти сервисы, драйверы должны обратиться к ядру. Хотя такая архитектура увеличивает накладные расходы, она значительно повышает надежность.

Над уровнем драйверов устройств находится уровень сервера. Сервер файлов представляет собой программу (4,5 тыс. строк исполняемого кода), которая принимает запросы от пользовательских процессов на системные вызовы Posix, касающиеся файлов, таких как, read, write, lseek и stat, и выполняет их. Кроме того, на этом уровне расположен менеджер процессов, который управляет процессами и памятью и выполняет вызовы Posix и другие системные вызовы, такие как fork, exec и brk.

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

К числу других серверов относятся сетевой сервер, который содержит: полный стек TCP/IP; хранилище данных, простой сервер имен, который используют другие серверы; информационный сервер, который используется при отладке. Наконец, над серверным уровнем расположены пользовательские процессы. Единственное отличие между этой и другими системами Unix заключается в том, что библиотечные процедуры для чтения, записи и других системных вызовов выполняется посредством посылки сообщений серверам. За исключением данного отличия (скрытого в системных библиотеках) это обычные пользовательские процессы, которые могут использовать POSIX API.

Взаимодействия между процессами

Поскольку именно механизм взаимодействия между процессами (Interprocess Communication, IPC) позволяет всем процессам работать вместе, он критически важен в мультисерверной операционной системе. Однако так как все серверы и драйверы в Minix 3 выполняются как физически изолированные процессы, они не могут напрямую вызывать функции друг друга или совместно использовать структуры данных. Вместо этого Minix 3 поддерживает IPC за счет передачи сообщений фиксированной длины на так называемом принципе рандеву (когда и отправитель, и получатель готовы к обмену, система копирует сообщение непосредственно от отправителя к получателю). Кроме того, имеется механизм асинхронных уведомлений о событиях. События, которые не могут быть реализованы, в таблице процессов помечаются как отложенные.

Minix 3 элегантно объединяет прерывания с системой передачи сообщений. Обработчики прерываний используют механизм уведомлений для сигнализации о завершении ввода/вывода. Этот механизм позволяет обработчику устанавливать бит в битовой карте «отложенных прерываний», а затем продолжать работу без блокировки. Когда драйвер готов к получению прерывания, ядро преобразует его в обычное сообщение.

Характеристики надежности

Причин высокой надежности Minix 3 несколько. Во-первых, в ядре выполняется код размером не более 4 тыс. строк, поэтому, исходя из скромной оценки 6 ошибок на 1000 строк, общее число ошибок в ядре, скорее всего, около 24. Сравните это число с 15 тыс. ошибок в Linux и намного большим их количеством в Windows. Поскольку все драйверы устройств, за исключением часов, - это пользовательские процессы, никакой посторонний код никогда не будет работать в режиме ядра. Кроме того, небольшой размер ядра позволяет более эффективно проверить его корректность либо вручную, либо с помощью формальных методов.

Архитектура IPC в Minix 3 не требует поддержки очередей или буферизации сообщений, что избавляет от необходимости управления буфером в ядре. Более того, поскольку IPC - это мощная конструкция, IPC-возможности каждого сервера и драйвера строго ограничены. Для каждого процесса строго определены используемые примитивы IPC, доступные адресаты и уведомления о пользовательских событиях. Пользовательские процессы, например, могут взаимодействовать только по принципу рандеву или посылать сообщения только серверам Posix.

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

Драйверы и серверы в режиме пользователя не могут работать с привилегиями суперпользователя. Они не могут получать доступ к областям памяти, находящимся за пределами их собственных адресных пространств, за исключением вызовов ядра (проверку корректности которых выполняет ядро). Более того, битовые карты и диапазоны внутри таблицы процессов ядра управляют набором допустимых вызовов ядра, возможностей IPC и допустимых портов ввода/вывода для каждого процесса в отдельности. Например, ядро может не допустить, чтобы драйвер принтера записывал информацию в пользовательские адресные пространства, обращался к портам ввода/вывода диска или посылал сообщения аудиодрайверу. В традиционных монолитных системах любой драйвер может делать что угодно.

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

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

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

Параметры производительности

В течение десятилетий разработчики критиковали мультисерверные архитектуры, базирующиеся на принципе микроядер, за их более низкую по сравнению с монолитными архитектурами производительность. Однако различные проекты подтверждают, что модульная архитектура на самом деле может обеспечивать сравнимую производительность. Несмотря на тот факт, что Minix 3 не была оптимизирована по производительности, система работает достаточно быстро. Потери производительности, которые возникают из-за того, что драйверы работают в режиме пользователя, по сравнению с драйверами в режиме ядра составляют менее 10%, и система может создаваться, в том числе ядро, общие драйверы и все серверы (112 компиляций и 11 ссылок), менее чем за 6 с на машине с процессором Athlon/2,2 ГГц.

Тот факт, что мультисерверные архитектуры позволяют поддерживать достаточно надежную Unix-подобную среду при весьма небольших потерях производительности, делает такой подход практически приемлемым. Minix 3 для Pentium можно загрузить бесплатно на условиях лицензии Berkeley с сайта www.minix3.org . Сейчас разрабатываются версии для других архитектур и встроенных систем.

Защита на базе языка

Самый радикальный подход, что весьма неожиданно, предложили в Microsoft Research, отказавшись от операционной системы как единой программы, выполняющейся в режиме ядра, и некоторого набора пользовательских процессов, функционирующих в режиме пользователя. Вместо этого предлагается система, написанная на совершенно новых, обеспечивающих безопасность типов языках, которые избавлены от всех проблем с указателями и других ошибок, связанных с Си и C++. Как и предыдущие два подхода, этот подход был предложен несколько десятилетий назад и был реализован в компьютере Burroughs B5000. Тогда существовал только язык Алгол, и защита поддерживалась не с помощью MMU (которого вообще не было в машине), а благодаря тому, что компилятор Алгол просто не генерировал «опасный» код. Подход, предложенный Microsoft Research, адаптирует эту идею к условиям XXI века.

Общее описание

Эта система, получившая название Singularity, практически полностью написана на Sing#, новом языке, гарантирующим безопасность типов. Этот язык основан на C#, но дополнен примитивами передачи сообщений, семантика которых определяется формальными, описанными средствами языка контрактами. Поскольку язык жестко ограничивает системные и пользовательские процессы, все процессы могут работать вместе в едином виртуальном адресном пространстве. Это увеличивает как безопасность (поскольку компилятор не позволит одному процессу менять данные другого процесса), так и эффективность (поскольку это избавляет от перехватов вызовов ядра (kernel trap) и переключений контекста.

Более того, архитектура Singularity является гибкой, поскольку каждый процесс - это замкнутая сущность и поэтому она может иметь свой собственный код, структуры данных, структуру памяти, систему времени исполнения, библиотеки и сборщик мусора. MMU поддерживается, но он только распределяет страницы, а не устанавливает отдельный защищенный домен для каждого процесса.

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

Микроядро

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

Хотя большая часть микроядра написана на Sing#, отдельные компоненты созданы на C#, C++ или assembler и должны быть надежными, поскольку проверить их корректность невозможно. К надежному коду относятся уровень аппаратной абстракции и сборщик мусора. Уровень аппаратной абстракции скрывает низкоуровневое аппаратное обеспечение от системы, инкапсулируя такие концепции, как порты ввода/вывода, линии запросов на прерывания, каналы прямого доступа к памяти и таймеры для того, чтобы предоставить остальной части операционной системы интероперабельные абстракции.

Взаимодействие между процессами

Пользовательские процессы получают системные сервисы, посылая строго типизированные сообщения микроядру по двунаправленным каналам точка-точка. Фактически эти каналы используются для всех взаимодействий между процессами. В отличие от других систем передачи сообщений, имеющих библиотеку с функциями send и receive, Sing# полностью поддерживает каналы на уровне языка, в том числе формальные спецификации типизации и протоколов. Для того чтобы прояснить это, рассмотрим спецификацию канала.

contract C1 {

In message Request(int x) requires x > 0;

Out message Reply(int y);

Out message Error();

Request? -> Pending;

State Pending: one {

Reply! -> Start;

Error! -> Stopped;

State Stopped: ;

Этот контракт утверждает, что канал принимает три сообщения: Request, Reply и Error. Первый имеет в качестве параметра положительное целое, второй - целое, а третий параметров не имеет. Когда для доступа к серверу используется канал, сообщения Request передаются от клиента к серверу, а другие два сообщения пересылаются иным путем. Машина состояний описывает протокол для канала.

В состоянии Start клиент посылает сообщение Request, переводя канал в состояние Pending. Сервер может в ответ послать либо сообщение Reply, либо сообщение Error. Сообщение Reply переводит канал обратно в состояние Start, в котором взаимодействие может продолжаться. Сообщение Error переводит канал в состояние Stopped, завершая взаимодействие по каналу.

Куча

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

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

Файловая система

Singularity поддерживает единое иерархическое пространство имен для всех сервисов. Корневой сервер имен использует вершину дерева, но другие серверы имен могут монтироваться на своих собственных узлах. В частности, файловая система, которая представляет собой всего лишь процесс, монтируется на /fs, поэтому, например, имя /fs/users/linda/foo может быть файлом пользователя. Файлы реализуются как B-деревья, в которых номера блоков служат ключами. Когда пользовательский процесс запрашивает файл, файловая система отдает драйверу диска команду поместить запрашиваемые блоки в кучу. Владение затем передается так, как описано выше.

Проверка

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

компилятор проверяет безопасность типов, владение объектами, протоколы каналов и так далее;
компилятор генерирует Microsoft Intermediate Language, переносимый JVM-подобный байт-код, который может проверять верификатор;
MSIL компилируется в код x86 для базового компьютера, который может добавлять в код проверки времени исполнения (однако существующий компилятор этого не делает).

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

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

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

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

Три из четырех исследовательских проектов - паравиртуализация на базе L4, Minix 3 и Singularity - используют микроядра. Пока не известно, какой из этих подходов в перспективе получит широкое распространение (если это не будет какое-то иное решение). Тем не менее интересно отметить, что микроядра, долгое время считавшиеся неприемлемыми из-за их более низкой производительности по сравнению с монолитными ядрами, могут снова вернуться в операционные системы из-за их потенциально более высокой надежности, что многие считают важнее производительности. Колесо истории повернулось.

Эндрю Таненбаум ([email protected]) - профессор информатики Vrije Universiteit (Амстердам, Голландия). Джоррит Хердер ([email protected]) - аспирант отделения компьютерных систем факультета информатики Vrije Universiteit. Хербер Бос ([email protected])- доцент отделения компьютерных систем факультета информатики Vrije Universiteit.

Литература

V. Basili, B. Perricone, Software Errors and Complexity: An Empirical Investigation, Comm. ACM, Jan. 1984.
T. Ostrand, E. Weyuker, The Distribution of Faults in a Large Industrial Software System, Proc. Int?l Symp. Software Testing and Analysis, ACM Press, 2002.
A. Chou et al., An Empirical Study of Operating System Errors, Proc. 18th ACM Symp. Operating System Principles, ACM Press, 2001.
M. Swift, B. Bershad, H. Levy, Improving the Reliability of Commodity Operating Systems, ACM Trans. Computer Systems, vol. 23, 2005.
M. Swift et al., Recovering Device Drivers, Proc. 6th Symp. Operating System Design and Implementation, ACM Press, 2003.
R. Goldberg, Architecture of Virtual Machines, Proc. Workshop Virtual Computer Systems, ACM Press, 1973.
J. LeVasseur et al., Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines, Proc. 6th Symp. Operating System Design and Implementation, 2004.
J. Liedtke, On Microkernel Construction, Proc. 15th ACM Symp. Operating System Principles, ACM Press, 1995.
H. Hartig et al., The Performance of Microkernel-Based Systems, Proc. 16th ACM Symp. Operating System Principles, ACM Press, 1997.
J.N. Herder et al., Modular System Programming in MINIX 3, Usenix; www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf .

Исследование на тему: какая ОС безопаснее?

Alexander Antipov

А.Ю.Щеглов, д.т.н, проф.

ЗАО «НПП «Информационные технологии в бизнесе»

www . npp - itb . spb . ru

В последнее время все чаще появляются публикации на тему, какая из современных ОС безопаснее. Это связано с тем, что безопасность сегодня становится важнейшим потребительским свойством, как системных средств, так и приложений. Разработчики системных средств вынуждены уделять вопросам безопасности все больше внимания, дабы повысить конкурентную способность своего продукта. Но вот что у них при этом получается? Что на самом деле «скрывается» за хвалебными декларациями производителей? Имеет ли в принципе смысл сравнивать сегодня между собою безопасность современных универсальных ОС различных производителей, а если сравнивать, то как? Может ли в принципе быть создана безопасная универсальная ОС?

Из чего складывается безопасность системного средства.

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

В данной работе мы акцентируем свое внимание на вопросах оценки эксплуатационной безопасности современных универсальных ОС.

Подход к оценке эксплуатационной безопасности системного средства.

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

Под «отказом защиты» будем понимать обнаружение уязвимости системного средства. Наличие уязвимости делает данное средство незащищенным до момента устранения ее производителем системного средства.

Под «восстановлением защиты» будем понимать устранение производителем обнаруженной уязвимости системного средства. устранение обнаруженной уязвимости восстанавливает безопасность системного средства (в предположении, что данная уязвимость одна).

Под «интенсивностью отказов защиты» будем понимать интенсивность обнаружения в системном средстве уязвимостей в единицу времени.

Под «интенсивностью восстановления защиты» после отказа будем понимать интенсивность устранения в системном средстве уязвимостей в единицу времени (величина, обратная времени устранения уязвимостей).

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

Построим модель для количественной оценки эксплуатационной безопасности системного средства.

Допустим, что обнаружение уязвимостей - отказов защиты, описывается пуассоновским входящим потоком (описывает наиболее случайные события, что и имеет место на практике), суммарную интенсивность которого обозначим, через:

Примем также, что время устранения уязвимости - восстановление защиты, имеет экспоненциальное распределение с интенсивностью:

Теперь собственно о модели (СМО). Будем рассматривать следующую гипотетическую ситуацию - любая обнаруженная уязвимость сразу же направляется на обслуживание (устранение). Никакой очереди неустраненных уязвимостей не образуется, т.е. будем рассматривать систему (СМО) с бесконечным числом обслуживающих приборов.

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

В данных предположениях, расчетная формула вероятности того, что в системе находится ровно n требований (или присутствует n неустраненных уязвимостей) выглядит следующим образом (см. стр.159 в кн. Т.Саати. Элементы теории массового обслуживания и ее приложения. - М.: Изд. «СОВЕТСКОЕ РАДИО», 1965. - 511 с.) :

С учетом же то, что:

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

Итак, модель мы построили, теперь с ее помощи проведем исследование.

Оценка уровня эксплуатационной безопасности современных универсальных ОС.

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

Первое исследование, которое мы здесь приведем: «"Критические дни": Linux, Mac OS X, Solaris and Windows» опубликовано на сайте 19 июня 2007 года.

Джефф Джонс провел очередное исследование на тему того, как долго компании закрывают найденные дыры в своем ПО. Рассматривались следующие коммерческие операционные системы:

Apple: Mac OS X, все версии, исправленные в 2006 году.
· Microsoft: Windows 2000 (Professional и Server), Windows XP, Windows Server 2003.
Red Hat: Red Hat Enterprise Linux 2.1, Red Hat Enterprise Linux 3, and Red Hat Enterprise Linux 4.
Novell: SUSE Linux Enterprise Server 8, SUSE Linux Enterprise Server 9, SUSE Linux Enterprise Server 10, Novell Linux Desktop 9, и SUSE Linux Enterprise Desktop 10.
Sun: Все версии Solaris, исправленные в 2006.

В случае, если одна уязвимость устранялась для разных версий ОС в разное время, то за время устранения считалось как среднее значение двух дат.

Если одна уязвимость устранялась в нескольких компонентах одного продукта в разное время, то уязвимость считалась устраненной, когда было выпущено последнее исправления. Например, если 1 января появилась уязвимость в Firefox и Thunderbird в RHEL3, а патч для Firefox был выпушен 10 января, а для Thunderbird 15 января, то считалась устраненной, когда было выпущено последнее исправления. Например, если 1 января появилась уязвимость в Firefox и Thunderbird в RHEL3, а патч для Firefox был выпушен 10 января, а для Thunderbird 15 января, то считалась устранненной 15 января.

В результате были получены следующие значения среднего времени устранения уязвимостей в различных операционных системах (см. рис.1).

Рис.1

Как видно из графика, быстрее всех исправление выпускала компания Microsoft, которой требовалось в среднем 29 дней для закрытия уязвимости, а хуже всех компания Sun, которая устраняла уязвимости в среднем за 167 дней.

На следующем графике (см. рис.2) представлена скорость устранения критических уязвимостей в различных операционных системах.

Рис.2

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

Рис.3

Заметим, что данные, полученные Джефом, несколько расходятся с исследованием компании Symantec , в котором утверждалось что Microsoft устраняет уязвимости в среднем за 21 день, Red Hat за 58, Appple Maс OS за 66, а Solaris за 122 дня. Однако сравнение Symantec затрагивает меньший период времени - только вторую половину 2006 года. А в нашем исследовании, куда важнее собственно порядок цифр.

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

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

Рис.4

А теперь оценим, как влияет на эксплуатационную (реальную) безопасность современных ОС интенсивность обнаружения уязвимостей. Для этого обратимся к другому исследованию под громким названием « Symantec: Windows - самая надежная система», также опубликованному на сайте , но 27 марта 2007 года.

В данном исследовании утверждается следующее.

Microsoft Windows, несмотря на все проблемы с безопасностью, является самой надёжной операционной системой из всех существующих, утверждает Symantec.

Во втором полугодии 2006 г. в системах Windows было найдено и устранено наименьшее число уязвимостей; компания в среднем быстрее всех выпускает обновления безопасности, — говорится в последнем «Докладе об угрозах безопасности интернета», выходящем дважды в год.

Утверждение подтверждается сравнительными показателями среди пяти операционных систем: Windows, Mac OS X, HP-UX, Sun Solaris и Red Hat Linux.

За полгода Microsoft выпустила обновления более чем к 39 уязвимостям; каждая дыра существовала в открытом состоянии в среднем 21 день. На втором месте — Red Hat Linux: 208 уязвимостей и средний срок устранения 58 дней. Несмотря на большее количество, эти уязвимости были в среднем менее опасны, отмечает Symantec. Mac OS X отметилась 43 уязвимостями и средним временем устранения в 66 дней. На уязвимости высокой степени опасности у компании уходило в среднем 37 дней.

Замыкают пятёрку HP-UX и Solaris: 98 дыр и 101 день, и 63 дыры и 122 дня соответственно.

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

Рис.5

Рассмотрим внимательно данные результаты, при этом будем помнить, что мы говорим о гипотетически идеальных характеристиках - это верхняя теоретическая граница, реальное положение дел куда хуже. Прежде всего, обратимся к красной пунктирной линии на рис.5. Этой линией характеризуется следующий случай - вероятность того, что в любой момент времени система находится в безопасном состоянии составляет 0,5, т.е. либо защищена, либо нет. А ведь такова эксплуатационная безопасность ОС достигается (см. рис.5) при обнаружении лишь 8 уязвимостей в год, при средней продолжительности их устранения в пределах месяца. Если же за год в среднем обнаруживается 20 уязвимостей, то вероятность того, что система находится в безопасном состоянии, составляет уже около 0,2. Другими словами, в этом случае можно говорить об отсутствии какой-либо безопасности подобной системы. Однако напомним о следующем (см. выше) «…За полгода Microsoft выпустила обновления более чем к 39 уязвимостям…» и речь идет о том, что « Windows - самая надежная система». Замечательно !

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

И в заключение еще немного «свежей» статистики с сайта , от 08 октября 2007 года. «Корпорация в текущем месяце планирует опубликовать семь бюллетеней безопасности с описанием новых дыр в операционных системах Windows, офисных приложениях и браузере

Как сообщается в предварительном уведомлении, четыре из октябрьских бюллетеней будут содержать сведения о критически опасных уязвимостях, позволяющих выполнить произвольный вредоносный код на удаленном компьютере. Дыры, получившие максимальный рейтинг опасности по классификации Microsoft, выявлены в новой операционной системе а также Windows 2000/ХР и Кроме того, Microsoft намерена выпустить патчи для критических уязвимостей в офисных приложениях, браузере Internet Explorer, программе Outlook Express и почтовом клиенте Windows Mail.

Еще две дыры в программных платформах Windows получили статус важных. Одна из них теоретически может использоваться злоумышленниками с целью организации DoS-атак, а другая - для имитации соединений. Кроме того, еще одна уязвимость, охарактеризованная важной, может использоваться с целью повышения привилегий в Windows и Office».

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

В наш век BYOD, когда почти половина организаций сообщают об утечке данных и взломе мобильных устройств, а 64% и вовсе не имеют политик BYOD (по данным фирмы Veracode), тема мобильной безопасности становится всё более актуальной для поставщиков решений, стремящихся защитить сети заказчиков.

Это возлагает бремя BYOD на ИТ-подразделения и VAR`ов, которые должны внедрить лучшие методы защиты на всём многообразии устройств.

Существуют, конечно, десятки разных моделей смартфонов и планшетов, но, по большому счету, дело сводится к четырем главным платформам мобильных ОС: iOS Apple, Android Google, BlackBerry и Windows Phone Microsoft.

IPhone и iPad получили широкое распространение в корпоративной среде, согласно опросу вендоров администрирования мобильных устройств (MDM), проведенному CRN при подготовке этой статьи. Теодора Тайтонис, вице-президент по мобильным технологиям в Veracode, считает, что успех Apple выстроен на ее жестком контроле над аппаратной платформой, ПО и экосистемой приложений наряду с продуманными дополнениями, такими как новые API управления контентом и приложениями в iOS 7.

Android, самая популярная мобильная ОС на планете, значительно продвинулась в корпоративном сегменте, хотя вендоры антивирусов приводят длинный перечень вредоносного ПО, перед которым Android-устройства порой пасуют. Samsung - главный вендор в сегменте Android - всячески подчеркивает свои расширения SAFE (Samsung Approved For Enterprise) и фирменную технологию защиты Knox, встроенную в некоторые модели, стремясь повысить привлекательность этой ОС для организаций.

Microsoft в своей Windows Phone 8 предлагает уникальные возможности, прежде всего интеграцию с Active Directory, позволяя вендорам MDM улучшить администрирование и назначать политики для групп пользователей. Есть еще, конечно, встроенная поддержка Active Sync. И эксперты по безопасности говорят, что Windows Phone 8 несравненно продвинулась в более надежной изоляции приложений (sandboxing).

Есть, наконец, BlackBerry, снискавшая (и всё еще сохраняющая) огромное уважение среди поставщиков решений за множество своих функций безопасности, таких как служба BBM и функции защиты в ее переоснащенном сервере администрирования BES 10. Теперь в этой ОС есть поддержка Exchange Active Sync и новая технология Balance, позволяющая организациям создать раздел в устройстве с BlackBerry 10, чтобы держать персональные и корпоративные данные и приложения отдельно.

«Потребители обычно тяготеют к более яркому на рынке мобильных устройств», - говорит Тайтонис из Veracode. Но это не всегда оказывается надежно защищенным. «Бремя BYOD лежит на конечном пользователе, который должен сделать правильный выбор смартфона или планшета и использовать их, соблюдая безопасность», - добавила она.

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

С этим согласен и Джерри Зигмонт, владелец реселлерской компании MacWorks, сотрудничающей с Apple. «Я не думаю, что есть какой-то один телефон, более защищенный, чем все другие», - сказал он. Тем не менее, он считает, что Apple и iOS 7 имеют некоторое преимущество перед Android, Windows Phone 8 и BlackBerry.

IOS: самая защищенная

Так считают эксперты мобильной безопасности и поставщики решений. У Apple преимущество, говорят они, потому что она держит в своих руках значительную часть всех составляющих - прикладной уровень (App Store), операционную систему (iOS) и сами устройства (iPhone/iPad), но не инфраструктуру (ее предоставляют операторы связи).

«iOS наиболее защищена, поскольку внимание к безопасности на уровне приложений ничуть не меньше, чем на уровне операционной системы», - говорит Айра Гроссман, директор по технологии клиентских устройств компании MCPc, крупного поставщика решений в США с собственной платформой Anyplace Workspace.

«Если приложения не защищены, то не имеет значения, насколько защищена операционная система, - говорит Гроссман. - Apple Store дает уровень безопасности, которого мы не имеем сегодня в стандартной витрине Android-приложений».

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

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

«Apple продвинулась дальше всех в деле безопасности. Каждое приложение запускается отдельно (sandboxed), то есть хранение данных и память изолируются. И у нее больше всего контроля над установкой патчей», - сказал один эксперт по безопасности из MDM-фирмы, попросивший об анонимности.

Управление уровнем заплат и контроль за установкой обновлений - важное преимущество Apple перед Android, говорят многие вендоры MDM. Apple посылает свои собственные «заплаты» напрямую пользователям, и это означает, что найденные уязвимости устраняются в течение 24 часов. Это дает Apple преимущество, говорят они, так как Android полагается на операторов беспроводной связи, которые рассылают свои заплаты и обновления ОС для устранения «дыр» в безопасности. Что еще хуже, сегмент Android фрагментирован: разные аппаратные платформы и номера версий ОС могут порой требовать отдельной заплаты для каждой версии.

В отличие от Apple, Android-устройства используют мешанину разных вариантов этой ОС. К сожалению, операторы не спешат с рассылкой заплат на устройства. Даже вендоры MDM признаются, что с трудом охватывают все версии.

Android: прочное второе место

Но это не значит, что Android OS не защищена. Она имеет множество встроенных функций безопасности. Кроме того, производители Android-устройств, прежде всего Samsung, улучшили версии этой ОС дополнив их расширенными средствами защиты, такими как технология Knox (Samsung).

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

С учетом этого, Ожас Реже (Ojas Rege), вице-президент по стратегии компании MobileIron, вендора MDM, утверждает, что безопасность и возможности администрирования в Android почти равны таковым у Apple. «Ключ к безопасности - это архитектура с изоляцией приложений, где данные в корпоративном приложении не могут быть доступны для другого приложения. iOS обеспечивает наиболее строгую изоляцию. Но более защищенные версии Android, например, с технологией Knox Samsung, также не хуже».

BlackBerry: возможно ли второе рождение?

Популярной в определенных кругах остается также BlackBerry OS. Со своим BlackBerry Enterprise Server (BES) она включает сотни функций защиты для организаций.

«BlackBerry - самая защищенная. В этом единственная причина, почему она еще жива, - говорит Стивен Канторович, президент VAR-компании CelPro Associates. - Именно поэтому ее используют госорганы и даже президент Обама».

Если бы ностальгия и заслуженное уважение могли увеличивать долю рынка, то BlackBerry обошла бы Apple уже завтра, но увы! - многие в отрасли считают, что она неуклонно угасает. Как результат, наблюдается исход разработчиков, да и вендоры MDM тоже переключаются на другие платформы. Если судить по цифрам, то будущее BlackBerry выглядит блёклым. Реже из MobileIron говорит, что доля BlackBerry среди организаций, с которыми он работает, быстро падает.

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

Впрочем, главный управляющий BlackBerry Джон Чэнь (John Chen) позволил себе не согласиться с ниспровергателями. На Всемирном конгрессе мобильной связи в феврале он заявил собравшимся, что компания намерена вновь громко заявить о себе на рынке смартфонов с новой high-end моделью с QWERTY-клавиатурой под названием BlackBerry Classic, намеченной к выпуску в этом году.

В интервью журналу USA Today Чэнь так охарактеризовал эту модель: «Это усовершенствованная и расширенная версия одного из наших самых популярных и успешных продуктов, который назывался Bold. Она будет иметь клавиатуру и хороший сенсорный экран, очень быстрый Интернет, веб-браузер и средства мультимедиа. А кроме того, будет очень защищенной».

Чэнь не раз заявлял, что BlackBerry - самая защищенная платформа в том, что касается самого устройства и пересылки сообщений (как электронной почты, так и BBM), и безопасность - главное в планах разработки компании.

Windows Phone 8: сила, с которой нужно считаться

Исследование фирмы ComScore показывает, что Android и Apple вместе удерживают сегодня более 93% рынка (доля Android составляет 52%, у Apple 41%), а Windows Phone 8 и BlackBerry состязаются за очень отдаленное третье место, имея 3,4% и 2,9% соответственно.

Хотя доля рынка Microsoft составляет единицы процентов, ее преимуществом перед BlackBerry является тесная интеграция с корпоративной средой. «Windows Phone - центральная часть нашего предложения, поскольку мы думаем, что она имеет большой потенциал в корпоративном сегменте», - говорит Реже из MobileIron.

Эксперты в безопасности говорят, что в Windows Phone 8 значительно улучшена изоляция приложений. Но эта ОС поддерживает меньше политик MDM по сравнению с iOS, а это означает, что вендоры, такие как MobileIron, не могут предоставить такой же уровень контроля для этой ОС, говорит Реже.

«Windows Phone 8 вполне способна удовлетворить специалистов по работе с информацией, но не тех, кто должен соответствовать высокому уровню регулятивных требований и защищенности», - говорит Райан Смит, ведущий инженер по безопасности компании-стартапа Mojave Networks.

По этим причинам (и вследствие невысокого спроса) Windows Phone 8 стоит в конце списка у многих экспертов в безопасности. Но это не значит, что вендоры MDM не обеспечивают ее поддержку - у большинства она есть.

Если BlackBerry явно не хватает жизненной силы, то перед Windows Phone 8 раскрыт горизонт возможностей. Защищенность мобильных устройств - это ускользающая цель, говорит Смит. Опираясь на прочное присутствие в корпоративном сегменте и купленный бизнес смартфонов Nokia, Microsoft может изменить расклад сил в безопасности с новым выпуском своей мобильной ОС, сказал он.