Вайнштейн Ю.В., Демин С.Л., Кирко И.Н. и др. Основы информационной безопасности

Подождите немного. Документ загружается.

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

ГЛАВА 4. МЕХАНИЗМЫ РЕАЛИЗАЦИИ БЕЗОПАСНОСТИ

4.1. Источники угроз информационной безопасности

Конечно, политика, разработанная одним человеком, служит в качестве

механизма для другого человека. Неформальная политика доступа из

предыдущей главы должна быть значительно переработана прежде, чем она

может быть предписана компьютерной системе. Должны быть точно описаны

как массив конфиденциальной информации, так и множество должным

образом авторизованных сотрудников. Можно рассмотреть такие описания

как более детальную политику, или как реализацию неформальной политики.

Фактически, реализация защиты имеет две части: код и настройку

(setup). Код – это программы в доверенной вычислительной базе (в комплексе

средств защиты). Настройка – это все данные, которые управляют

операциями этих программ: списки контроля доступа, членства группы,

пользовательские пароли, ключи шифрования, и т.д.

Задача реализации защиты должна защитить против уязвимостей. Они

встречаются в трех основных формах:

1. Плохие (ошибочные или враждебные) программы.

2. Плохие (небрежные или враждебные) агенты – программы или

пользователи, которые дают плохие команды хорошим, но легковерным

программам.

3. Плохие агенты, подключающиеся к коммуникациям, или заполняющие их

своими сообщениями.

Случай (2) может каскадироваться, давая несколько уровней

легковерных агентов. Ясно, что агенты, которые могли бы получить команды

от плохих агентов, должны быть благоразумными, или даже придирчивыми,

но не легковерными.

В общем случае имеются четыре стратегии защиты:

1. Никого не впускать. Это – полная изоляция. Она обеспечивает лучшую

защиту, но препятствует использованию информации или услуг от других, и

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

очень малого числа приложений.

2. Не впускать нарушителей. Программам внутри этой защиты можно

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

цифровые подписи программ и межсетевые экраны (МЭ).

3. Впустить нарушителей, но воспрепятствовать им в причинении вреда.

Традиционным способом служит динамическое ПО типа sandboxing на

основе процессов операционной системы, или в современном виде, в

виртуальной машине Java. Динамическое ПО типа sandboxing создает в

компьютере защищенное пространство (sandbox), в котором может

выполняться подозрительный код, и в типичном случае использует контроль

доступа к ресурсам, чтобы определить нарушения. Программы, доступные из

указанного защищенного пространства, должны иметь повышенную

стойкость; трудно написать их правильно.

4. Захватить нарушителей и преследовать их. Это делают аудит и силовые

структуры.

Дискреционная модель управления доступом обеспечивает структуру для

этих стратегий. В этой модели диспетчер доступа управляет доступом

запросов на обслуживание к ресурсам, которые обычно инкапсулированы в

объектах, по следующей схеме: принципал (источник запроса) →

запрашиваемая операция → диспетчер доступа (сторож) → объект (ресурс).

Работа диспетчера доступа заключается в том, чтобы решить: может ли

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

Чтобы решить это, используют два вида информации: аутентификационная

информация, которая идентифицирует принципала, сделавшего запрос, и

авторизационная информация, которая говорит, кому разрешено сделать что-

то на объекте.

Причина для того, чтобы отделить диспетчера доступа от объекта –

сделать его простым. Если защита смешана с остальной частью реализации

объекта, намного тяжелее быть уверенным в том, что она является

корректной. Цена, заплаченная за это, состоит в том, что решения должны

основываться только на принципале, методе объекта и, возможно,

параметрах. Например, если необходимо, чтобы файловая система

предписывала квоты (ограничения) по дисковой памяти только для новых

пользователей, есть два способа сделать это в пределах этой модели:

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

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

2. Иметь отдельный объект «квота», который файловая система вызывает по

запросу пользователя.

Конечно, защита все же зависит от объекта, который должен корректно

осуществлять свои методы. Например, если файловый метод чтения read

изменяет данные или метод записи write ошибается в выделении квоты, или

любой из них касается данных в других файлах, то система не защищена,

несмотря на сторожа.

Другая модель используется, когда конфиденциальность должна

противостоять атакам со стороны плохих программ: модель управления

информационными потоками. Эта модель мандатного доступа организована

по следующей схеме: информация (источник) → диспетчер доступа (сторож)

→ принципал (сток). Она, грубо говоря, является противоположной

дискреционной модели управления доступом; в ней сторож решает, может ли

информация течь к аутентифицированному принципалу.

В каждой модели, существуют три основных механизма для

осуществления защиты. Вместе, они формируют «золотой» стандарт:

- Аутентификация принципалов, отвечает на вопрос: «Кто это сказал?» или

«Кто получает данную информацию?». Обычно принципалы – это

пользователи, но могут также быть группы, машины или программы.

- Авторизация доступа, отвечает на вопрос, «Кому разрешено делать такие

операции на этом объекте?»

- Аудит решений диспетчера доступа, для того, чтобы позже можно было

выяснить, что случилось и почему.

4.2. Сертификация: создание защищенной работы

Что означает сделать работу защищенной? Ответ основан на понятии

комплекса средств защиты (КСЗ), набора аппаратных средств, программного

обеспечения, и информации по настройке (setup), от которой зависит защита

системы [4, с.33; 5, с.7]. Вот некоторые примеры для понимания этой мысли:

– если политика безопасности для машин в сети такая, что они могут читать

только веб-страницы, и не могут обращаться ни к какому другому сервису

сети «Интернет», и внутренний доступ для внешних программ запрещен,

тогда КСЗ представляет собой только межсетевой экран (аппаратные

средства, программное обеспечение и настройка), который разрешает

внешние подключения по протоколу TCP к порту 80, и не разрешает никакой

другой трафик

; если политика также говорит, что не должно выполняться

программное обеспечение, загруженное из сети «Интернет», тогда

добавляется дополнительно программа браузера и его настройка, которая

должна отключить Java и другие загрузчики программного обеспечения

;

– если политика безопасности для системы Unix состоит в том, что

пользователи могут читать системные каталоги, и читать и записывать свои

домашние каталоги, тогда КСЗ, в первом приближении, включает аппаратные

средства, ядро Unix, а также все программы, которые имеют разрешение на

запись в системный каталог (включая те, которые выполняются с правами

суперпользователя); это – довольно большой объем программного

обеспечения, который также включает /etc/passwd и разрешения на

системные и домашние каталоги.

Вообще говоря, не просто выяснить, что находится в КСЗ для данной

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

как показывают приведенные примеры.

Чтобы защита работала совершенным образом, спецификации для всех

компонент КСЗ должны быть достаточно серьезными, чтобы выполнять

предписания политики, и каждый компонент должен удовлетворять своей

спецификации. Этот уровень сертификации редко достигается. По существу,

часто соглашаются на что-то намного более слабое, и соглашаются с тем, что

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

должно быть ясно, что чем меньше размер КСЗ – тем лучше.

Хороший способ предотвращения вреда, который могут причинить

дефекты в КСЗ – использовать защиту в глубину (эшелонированную

оборону), т.е. избыточные механизмы защиты. Например, система могла бы

включать:

- сетевой уровень безопасности, используя МЭ;

- уровень безопасности ОС, используя sandboxing, чтобы изолировать

программы; это может быть сделано базовой ОС, такой как Windows XP или

Unix, или высокоуровневой ОС, такой как виртуальная машина Java;

- уровень безопасности приложения, который дополнительно проверяет

авторизацию.

Это предполагает, что нет других соединений с Интернет за исключением межсетевого экрана.

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

Невыполнение этого требования может значительно расширить КСЗ в любой операционной системе.

Идея заключается в том, что нарушителю будет сложно одновременно

использовать слабости разных систем на всех уровнях. Эшелонированная

оборона не дает строгих гарантий, но, в действительности, практически

помогает.

Большинство обсуждений безопасности было сосредоточено на

программном обеспечении (и иногда, на аппаратных средствах). Но другой

важный компонент КСЗ – вся настройка или информация о конфигурации,

кнопки и выключатели, которые говорят программному обеспечению, что

сделать (setup). В большинстве систем, поставляемых сегодня, имеется много

такой информации, как известно всем, кто выполнял настройку. Она

включает:

– информацию о том, какое ПО установлено с системными привилегиями, а

также какое ПО установлено с привилегиями пользователя; ПО включает не

только наборы исполняемых файлов, но и все, что исполняется, например,

сценарии оболочек (shell scripts) или макросы;

– базу данных пользователей, пароли (или другие идентификационные

данные), привилегии, и членства группы; часто сервисы, подобные серверам

SQL, имеют собственные пользовательские базы данных;

– сетевую информацию, такую как перечни доверенных машин;

– управление доступом на всех системных ресурсах: файлах, сервисах

(особенно тех, которые отвечают на сетевые запросы), устройствах и т.д.

Хотя настройка намного более проста чем программа, она все еще

является достаточно сложной, обычно делается менее квалифицированными

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

однократно, настройка различна для каждой инсталляции. Поэтому следует

ожидать, что она обычно неправильна, и много исследований подтверждают

это ожидание. Проблема ухудшается тем, что настройка должна быть

основана на документации для программного обеспечения, которая является

обычно большой по объему, неясной и неполной, в лучшем случае

Единственное решение этой проблемы состоит в том, чтобы сделать

часть настройки, отвечающую за безопасность, более простой как для

администраторов, так и для пользователей. Не следует делать это, изменяя

базовую ОС, по причинам того, что изменения там трудно выполнимы, и

Конечно, и код программы также зависит от документации по программному языку и вызываемым

библиотекам, но там качество документации обычно значительно лучше.

потому что некоторые пользователи будут настаивать на детальном

управлении, которое обеспечивает настройка. Вместо этого, можно

использовать в своих интересах это детализированное управление, используя

его как «машинный язык». Необходимо задать модель безопасности с

небольшим числом параметров настройки, и затем компилировать эти

параметры в многочисленные кнопки и выключатели базовой системы.

Какую форму должна принять эта модель?

Пользователи нуждаются в очень простой модели, приблизительно с

тремя уровнями защиты: я, моя группа или предприятие, и остальные, с

прогрессивно убывающими полномочиями. Сегодня браузеры

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

конфиденциальные и открытые сведения должны быть в трех частях

файловой системы: мои документы, документы моей группы и общие

документы. Это комбинирует защиту данных с той частью файловой

системы, где они хранятся; так же, как в реальном мире это сделано,

например, с досками объявлений, папками, замкнутыми в столах и сейфами.

Это знакомо, требует меньшей работы, при этом сразу очевидно, какова

защита каждого элемента данных.

Все остальное должно быть обработано политиками безопасности (ПБ),

которую должны предоставить поставщики или администраторы. В

частности, ПБ должны классифицировать любые программы как доверенные

или недоверенные, на базе того, каким образом они подписаны, если

пользователь сознательно не отменит эти предписания явным образом.

Недоверенные программы могут быть отклонены или ограничены

(sandboxing); если они – ограничены, то должны работать в полностью

изолированном пространстве состояний, с отдельным глобальным

состоянием, таким как пользовательские и временные папки, журналы, веб-

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

кроме того случая, когда пользователь явно копирует что-то вручную. Это не

удобно для пользователя, но все другое связано с опасностью.

Администраторы также нуждаются в довольно простой модели, но они

нуждаются даже еще больше в возможности обработать много пользователей

и систем однородным способом, так как они не могут эффективно иметь дело

с большим количеством индивидуальных случаев. Одним из способов

является определение, так называемых, низкоуровневых политик

безопасности

(НПБ), правил настройки безопасности, которые

автоматически применяются к группам машин. Они включают следующее:

- Каждый пользователь имеет право на чтение/запись в своей домашней

папке на сервере, и никто более не имеет этот доступ.

- Пользователь – обычно член одной из рабочих групп, который имеет

доступ к групповым домашним папкам на всех машинах членов группы и на

сервере.

- Системные папки должны содержать наборы файлов, которые формируют

версию ПО (релиз), одобренную поставщиком.

- Все выполняемые программы должны быть подписаны полномочными

сторонами.

Эти НПБ должны быть обычно небольшими изменениями шаблонов,

которые обеспечили и проверили поставщики, так как для большинства

администраторов трудно изобрести их на пустом месте. Должно быть

простым отключение обратной совместимости со старыми приложениями и

сетевыми узлами, т.к. они вызывают проблемы безопасности.

Некоторые пользователи будут настаивать на особых случаях. Это

означает, что необходима информация о полезных особых случаях. Должно

быть легким докладывать все отклонения от стандартной практики в системе,

особенно изменения в программном обеспечении машины, и все изменения

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

т.к. длинные сообщения, возможно, будут игнорироваться.

Чтобы делать НПБ управляемыми, администраторам надо определять

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

которые они претендуют, и затем кратко формулировать НПБ в терминах

этих групп. В идеале, группы ресурсов отражены в структуре файловой

системы, но должны быть и другие пути к их определению, чтобы принять во

внимание причудливые соглашения по существующим сетям, ОС и

приложениям.

Реализация НПБ обычно заключается в компиляции в существующие

параметры настройки защиты. Это означает, что не нужно изменять

существующие администраторы ресурсов, и позволяет реализовать мощные

политики безопасности высокого уровня и эффективный контроль, так как

Это – низкоуровневый пример спецификаций безопасности, такой, который может понять машина, в контрасте с

тем высокоуровневым примером, который приводился в предыдущей главе.

компиляторы позволяют использовать мощные языки программирования и

эффективную реализацию.

Разработчики нуждаются в безопасном типизированном языке,

подобном языку Java; это устранит множество дефектов программ. К

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

в системном программном обеспечении, которое, например, обеспечивает

коммуникации с сетями, и нужно стремиться к тому, чтобы системные

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

Разработчики должны серьезно рассматривать вопросы защиты,

оценивая дизайны, которые делают более простой сертификацию и дают

возможность рассмотрения их программ профессионалами в области

безопасности, которые должны препятствовать поставке ПО с серьезными

недостатками защиты.

Контрольные вопросы

1. В каких случаях процесс в системе является субъектом, а в каких –

объектом?

2. Чем обусловлен переход от концепции диспетчера доступа к концепции

комплекса средств защиты (КСЗ)?

3. Шифрование с секретным ключом более эффективно, чем шифрование с

открытым ключом, но оно требует, чтобы отправитель и получатель заранее

договорились об используемом ключе. Предположим, что отправитель и

получатель никогда не встречались, но существует доверенная третья

сторона, у которой есть общий секретный ключ с отправителем и другой

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

отправитель и получатель могут установить новый общий секретный ключ?

4. Что собой представляют аутентификация, авторизация и аудит?

5. Какой из целей политики безопасности соответствует аутентификация?

6. Назовите три характеристики, которые должен иметь хороший

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

аутентификации при входе в систему.

7. Дайте определение комплекса средств защиты (КСЗ).

8. Покажите на примере преимущества защиты в глубину или

эшелонированной обороны.

9. Почему не следует упрощать часть настройки (setup), отвечающую за

безопасность, с помощью изменения базовой операционной системы?

10. Что предлагает модель безопасности с небольшим числом параметров

настройки в отношении пользователей?

11. Что предлагает вышеуказанная модель в отношении администраторов?

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

систем?