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

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

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. Какие ограничения предлагает данная модель относительно разработки

систем?

ГЛАВА 5. ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

ОБЪЕКТОВ ИНФОРМАЦИОННОЙ СФЕРЫ ГОСУДАРСТВА

В УСЛОВИЯХ ИНФОРМАЦИОННОЙ ВОЙНЫ

5.1. Основные направления обеспечения информационной безопасности

Коммуникационные сети, связывающие компьютеры и рабочие стан-

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

в компьютерные ресурсы. Однако сети требуют строгого информационного

контроля и повышенной безопасности. Задача состоит в широком распро-

странении информации между теми, кто нуждается в ней, с гарантией того,

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

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

За последние годы компьютер принес серьезные изменения в техноло-

гию работы с информацией в производственной среде. Большинство органи-

заций имеет несколько больших компьютеров, часто расположенных на вы-

числительных центрах. Эти большие компьютеры, обеспечивающие работу с

базами данных, связаны между собой с помощью одной или нескольких се-

тей, использующих те или другие доступные сетевые технологии. Централь-

ные процессоры могут относиться к разным машинным архитектурам, при-

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

связывающие эту смесь машин, имеющих разные операционные системы,

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

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

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

того, локальные вычислительные сети (ЛВС) объединяют рабочие станции и

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

ных подразделениях.

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

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

ЛВС. Если рассматривать вопросы безопасности, то пользователь, соединив-

шись с такой сетью, фактически становится администратором данных. Мож-

но выделить данные, обработать их при помощи своих не тестированных

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

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

права доступа и преодолеть существующие процедуры локального контроля.

5.2. Отличия сети от вычислительного центра

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

защите информации на сетевых микрокомпьютерах, заметно отличаются от

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

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

динен к центральной машине. Важные отличия с точки зрения безопасности

показаны в табл. 2.

Таблица 2

Отличия сети от вычислительного центра с точки зрения безопасности

Объект Вычислительный центр Распределенная сеть

Среда

В пределах идентифицирован-

ной группы пользователей, ра-

ботающих с приложением

Потенциально открыта через

межсетевые соединения

Информационная

база

Определена и контролируема

Не определена: средства кон-

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

Информационный

поток

Двусторонний Неограниченный

Физический кон-

троль доступа

Зависит от физической

структуры банка данных

Относительно менее важен,

поскольку данные распределе-

ны

Логический кон-

троль доступа

Защищает файлы

Защищает файлы и целостность

сети

В отличие от средств физического и логического контроля, сосредото-

ченных в одном месте, что типично для схемы безопасности вычислительно-

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

– контроль доступа ко всем информационным файлам, доступным по внут-

ренней сети и по внешним сетям;

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

разрешено работать;