Безопасность в ОС

       

Формулировка задачи


Формулировка задачи


Формулировка задачи

  А мальчик-юзер пошел пить пиво со злыми интернетчиками, а те ему и говорят: "Да какой-ты крутой хаксор. Почту ты сломал, факт. А вот этот сервак попробуй сломать". И в окно показывают. А напротив пивняка стоит здание, с надписью "Почта". И мальчик-юзер пошел почту ломать. А па почте, видать, сниффер стоял, так что через пять минут менты-модераторы приехали и так отмодерили мальчика-юзера, что с тех пор о нем ничего неизвестно.

Vitar Velazquez



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Содержание раздела