Структурно любая АС содержит два вида элементов: элементы
программно-аппаратного блока, в котором происходит переработка данных
системы, и элементы среды взаимодействия, посредством которой данные
системы передаются пользователям или другим программно-аппаратным
блокам.
На системном уровне это -- центральный процессор и всевозможные
сопроцессоры, оперативная память, шины и т.п; ядро системы, драйверы
устройств, системные службы и т.д. На прикладном уровне это --
аппаратные кодеки, графические процессоры и т.п.; любые
пользовательские
задачи, преобразователи форматов, внутрисистемные средства связи между
задачами.
На системном уровне это -- несъёмные жёсткие диски, ПЗУ и ППЗУ и
прочие внуренние накопители данных. На прикладном уровне -- файловые
системы, хранилища баз данных и т.п.
В случае, если средство хранения данных может быть без нарушения
политики безопасности системы отторгнуто от конкретного
программно-аппаратного блока и включено в какую-либо другую АС, его
следует считать также и средством передачи данных. Пример такого
устройства -- дискета или магнитная лента. Если есть необходимость
использовать такое устройство только в качестве устройства хранения,
политика безопасности должна запрещать применение этого устройства в
другой АС (например, поскольку после резервного копирования магнитная
лента не должна находиться в одном помещении с носителем данных, её
следует запирать в переносной сейф).
На системном уровне это -- сетевые адаптеры и прочие передающие
учтройства, носители данных (лазерные диски, дискеты и т.п.), среды
передачи данных (разнообразные кабели и радиканалы) и т.д.; сокеты,
каналы и прочие системные абстракции межпроцессного взаимодействия,
связывающие задачи разных программно-аппаратных блоков. На прикладном
уровне -- устройства считывания кодов, сканеры и т.д.; сетевые файловые
системы и прочие приложения передачи пользовательской информации,
перемещаемые архивы или резервные копии и т.д.
На системном уровне это -- устройства текстового, графического или
оного ввода-вывода (терминал, графический дисплей, ручной манипулятор,
микрофон и т.п.). На прикладном уровне -- язык управления системой,
графическое предстваление пользовательских задач (меню, кнопки и т.п.),
возможность голосового управления, аудиосообщения и т.п.
На системном уровне это -- средства аппаратного тестирования,
watchdog-и, температурные, вольт-амперные или иные датчики, средства
аппаратной проверки контрольных сумм и т.п; , средства периодический
проверки состояния системы, анализаторы загруженности системы и сети,
системные журналы и их анализаторы и т.д. На прикладном уровне --
средства тестирования готовой продукции; средства обновления
программного обеспечения, журналы пользовательских приложений и их
анализаторы и т.д.
Для разработчиков в АС могут быть внедрены специальные элементы
программно-аппаратного блока и среды взаимодействия (в частности,
интерфейсы и средства обработки данных), использование которых на этапе
эксплуатации может нарушать политику безопасности АС, описанную для
прикладной модели системы и не включающую в себя модель реализации и её
средства. В общем случае такие средства должны быть изъяты из АС перед
сдачей её в эксплуатацию.
В отдельных случаях (система автоматизации научных исследований, АС
моделирования и стендовой проверки и прочие системы с часто меняющейся
функциональностью) средства разрабоотки и соответствующие им элементы
АС
должны быть сохранены. В таких АС следует разрабатывать политику
безопасности, учитывающую наличие разработчика в функционирующей
системе.
В задачу администратора входит поддержание АС в работоспособном
состоянии: оперативное устранение неисправностей и контроль качества
готовой продукции и функциональностей системы, а также прогнозирование
и
предупреждение ситуаций, приводящих к потере работоспособности АС или
ухудшению качества её работы: анализ ресурсов элементов АС и их
пропускной способности, локализация и замена элементов, понижающих
качество работы АС, отслеживание и предупреждение намеренных и
ненамеренных нарушений политики безопасности АС и т.п.
Для администрирования АС может включать в себя элементы
программно-аппаратного блока и среды взаимодействия, превышающие
полномочия пользователя при работе с данными АС. В этом случае задача
ограмничения и контроля за действиями администратора должна решаться на
стадии разработки АС (такие средства контроля не должны быть доступны
администратору) или определяться внесистемно, чисто административными
мерами (аудит, административно-правовое принуждение и пр.).
К вычислительному аппаратному обеспечению относится всевозможная
схемотехника, обрабатывающая данные (устройства хранения, переработки и
передачи данных и интерфейсные устройства), а также каналы передачи
данных (шины, кабели компьютерных сетей, соединительные кабели
устройств
и т.п.).
Сбой в работе вычислительного аппаратного устройства часто не
приводит к останову системы, однако служит причиной потери и/или порчи
данных. Поэтому для обеспечения защиты данных к такому устройству
следует применять средства повышения надёжности как аппаратного, так и
программного уровня
К вспомогательному аппаратному обеспечению относятся системы
электропитания (блоки питания, аккумуляторы, устройства бесперебойного
электроснабжения, кабели и разъёмы электропитания, сетевые фильтры,
трансформаторы и пр.), системы контроля влажности и температуры
(вентиляторы, криогенные и иные охладители, кондиционеры и т.д.),
системы оповещения и индикации (для взаимодействия с обслуживающим
персоналом) и т.д.
Сбой в работе вспомогательного аппаратного устройства не приводит
непосредственно к потере и/или порче данных АС. Однако сбой
вспомогательного устройства часто провоцирует нештатную ситуацию на
зависящих от него вычислительных устройствах, которая, в свою очередь,
может привести к нештатной ситуации в программном обеспечении. Меры по
защите данных при сбое вспомогательного устройства следует принимать
как
на аппаратном уровне вспомогательного устройства так и на всех уровнях
зависящих от него вычислительных устройств и программных компонентов:
Специализированное ПО подразделяется по степени интерактивности и
объёму решаемых задач. Как следствие этого, классы специализорованного
ПО будут различаться по требованиям к интерфейсу.
Функциональность автоматических подсистем изменяется только
разработчиком.
Следовательно, эти части АС не нуждаются в интерфейсе настройки, а
средства мониторинга необязательны и не влияют на работу этого вида ПО.
Функциональность профилируемой подсистемы изменяется (возможно,
многократно) администратором, то есть субъектом АС, авторизованным на
задание профиля и имеющим знания и навыки профилирования.
Интерфейс профилируеиого программного продукта, таким образом,
организуется вокруг операции профилирования. Такой интерфейс должен
быть
достаточно мощен и гибок, чтобы позволить пользователю описать в
профиле любую задачу (или подмножество) из заявленного класса
пользовательских задач.
Функциональность системы задаётся и изменяется в процессе диалога
самим конечным пользователем. При этом весь процесс работы такого
программного продукта можно рассматривать как последовательность обмена
данными с пользователем и их переработки.
Таким образом, основным требованием к интерфейсу интерактивного ПО
будет приспособленность к непрерывному и информационно насыщенному
взаимодействию с пользователем, включая необходимость языка постановки
пользовательских задач. В зависимости от специфики прикладной области,
в
интерфейсной части интерактивного ПО приходится решать задачи
эргономики, информационной перенасыщенности, наглядности,
быстродействия
и т.д.
Диалог с отложенным взаимодействием применяется в случае
информационной перенасыщенности потока управления, при низких
возможностях аппаратной части интерфейса, при требованиях однозначности
и точности языка постановки задачи, т.е. во всех случаях, когда имеет
смысл разделять во времени процедуру воздействия пользователем на АС и
процедуру выдачи результатов.
Работа с командным интерпретатором, подготовка документации в
системе TeX и DocBook, программирование -- примеры диалога с отложенным
взаимодействием.
Диалог с продолженным взаимодействием применяется в случае
отсутствия жёстких требований к структуре конечного продукта, при
жёстком требовании наглядности или постоянного контроля вносимых
изменений, при необходимости скрывать от пользователя реализацию
(профиль) и т.п., т.е. во всех случаях, когда от программы требуется
немедленная обатная связь.
Пример системы, устроенной по принципу диалога с продолженным
взаимодействием -- любой программный продукт, созданный по технологии
WYSIWYG, экранный текстовый процессор или графический редактор и т.д.
Диалог с предварительным профилированием применяется в ПО
профессионального уровня, в случае требования идентичности "модели"
продукта и самого продукта или когда работа ведётся непосредственно с
самим продуктом (в этом случае необходимо как можно аккуратнее
настроить
средства его отображения и изменения), при возможности повторного
использования частей профиля, т.е. во всех случаях, когда для решения
любой задачи из класса пользовательских задач необходимо, помимо
прочего, воспользоваться решениями нескольких стандартных подзадач, или
когда такое разбиение не обязательно, но возможно и приносит выгоду при
реализации.
Пример диалога с предварительным профилированием -- создание
программных библиотек перед разработкой собственно программного
продукта, создание стилей при разработке документа, настройка цветовых
и
линейных параметров монитора при выполнении профессиональных
графических работ, создание макрокоманд для работы в приложениее
WYSIWYG
и т.п.
Некоторые действия по предотвращению сбоев (например, удаление пыли
из корпусов) необходимо проводить при нерабочем состоянии
соответствующего элемента АС. В этом случае составляется расписание
профилактических работ, во время которых блок АС отключается. Во время
профилактики можно проводить обновление и дополнение элементов АС.
Если возможности профилактического отключения определённого блока АС
нет (напрмер, система работает в режиме 24*7), такой блок должен быть
зеркалирован. На время профилактики работу этого блока выполняет его
зеркало.
Если в результате анализа системных журналоы администратор АС
приходит к выводу, что текущий профиль работы системы неоптимален по
отношению к решаемым пользовательским задачам, также может понадобться
перенастройка.
Следует иметь в виду, что во многих случаях перепрофилирование
системы требует большого срока, в течение котрого качество работы может
понизиться, а вероятность нештатных ситуаций -- повыситься (период
отладки). На период отладки целесообразно предусматривать
зеркалирование
функций отлаживаемого блока и даже всей АС.
Во многих случаях может потребоваться уничтожение конфиденциальной
информации на носительях данных. Следует иметь в виду, что подобная
процедура необходима как в случае продолжения функционирования АС в
ином
качестве (непример, передача другому отделу предприятия), так и в
случае демонтажа, поскольку в обоих случаях данные АС выходят из-под
административного контроля и соблюдение надлежащей политики
безопасности
становится невозможно.
Характеристики элемантов АС используются на всех этапах ЖЦ системы
как исходные данные для планирования, настройки, диагностики АС и т.п.
Об актульности решения проблемы защиты информации уже сказано
достаточно много. Информация, обрабатываемая в автоматизированных
сетях,
особенно уязвима. Существенному повышению возможности
несанкиционированного использования или модификации данных, введению в
оборот ложной информации в настоящее время способствуют:
Настоящий Руководящий документ устанавливает классификацию средств
вычислительной техники по уровню защищенности от несанкционированного
доступа к информации на базе перечня показателей защищенности и
совокупности описывающих их требований.
Под СВТ понимается совокупность программных и технических элементов
систем обработки данных, способных функционировать самостоятельно или в
составе других систем.
Данные показатели содержат требования защищенности СВТ от НСД к
информации.
Показатели защищенности СВТ применяются к общесистемным программным
средствам и операционным системам (с учетом архитектуры ЭВМ).
Требования к показателям реализуются с помощью
программно-технических средств.
Устанавливается семь классов защищенности СВТ от НСД к информации.
Самый низкий класс - седьмой, самый высокий - первый. Классы
подразделяются на четыре группы, отличающиеся качественным уровнем
защиты:
Выбор класса защищенности СВТ для автоматизированных систем,
создаваемых на базе защищенных СВТ, зависит от грифа секретности
обрабатываемой в АС информации, условий эксплуатации и расположения
объектов системы.
Применение в комплекте СВТ средств криптографической защиты
информации по ГОСТ 28147-89 может быть использовано для повышения
гарантий качества защиты.
Требования данного РД охватывают следющий ряд методов обеспечения
безопасности от НСД
Оценка класса защищенности СВТ проводится в соответствии с
Положением о сертификации средств и систем вычислительной техники и
связи по требованиям защиты информации, Временным положением по
организации разработки, изготовления и эксплуатации программных и
технических средств защиты информации от несанкционированного доступа в
автоматизированных системах и средствах вычислительной техники и
другими
документами.
Настоящий руководящий документ устанавливает классификацию
автоматизированных систем, подлежащих защите от несанкционированного
доступа к информации, и требования по защите информации в АС различных
классов.
Руководящий документ разработан в дополнение ГОСТ 34.003-90, ГОСТ
34.601-90, РД 50-680-88, РД 50-34.680-90 и других документов.
Документ может использоваться как нормативно-методический материал
для заказчиков и разработчиков АС при формулировании и реализации
требований по защите.
Классификация распространяется на все действующие и проектируемые АС
учреждений, организаций и предприятий, обрабатывающие конфиденциальную
информацию
Деление АС на соответствующие классы по условиям их функционирования
с точки зрения защиты информации необходимо в целях разработки и
применения обоснованных мер по достижению требуемого уровня защиты
информации
Дифференциация подхода к выбору методов и средств защиты
определяется важностью обрабатываемой информации, различием АС по
своему
составу, структуре, способам обработки информации, количественному и
качественному составу пользователей и обслуживающего персонала
Необходимыми исходными данными для проведения классификации
конкретной АС являются:
Выбор класса АС производится заказчиком и разработчиком с
привлечением специалистов по защите информации
К числу определяющих признаков, по которым производится группировка
АС в различные классы, относятся
Каждый класс характеризуется определенной минимальной совокупностью
требований по защите
Классы подразделяются на три группы, отличающиеся особенностями
обработки информации в АС
В пределах каждой группы соблюдается иерархия требований по защите в
зависимости от ценности (конфиденциальности) информации и,
следовательно, иерархия классов защищенности АС
Третья группа включает АС, в которых работает один пользователь,
допущенный ко всей информации АС, размещенной на носителях одного
уровня
конфиденциальности. Группа содержит два класса - 3Б и 3А
Вторая группа включает АС, в которых пользователи имеют одинаковые
права доступа (полномочия) ко всей информации АС, обрабатываемой и
(или)
хранимой на носителях различного уровня конфиденциальности. Группа
содержит два класса - 2Б и 2А
Первая группа включает многопользовательские АС, в которых
одновременно обрабатывается и (или) хранится информация разных уровней
конфиденциальности. Не все пользователи имеют право доступа ко всей
информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А
Требования предъявляемые данным РД к разрабатываемым АС охватывают
следующий спектр вопросов:
Организационные мероприятия в рамках СЗИ НСД в АС, обрабатывающих
или хранящих информацию, являющуюся собственностью государства и
отнесенную к категории секретной, должны отвечать государственным
требованиям по обеспечению режима секретности проводимых работ
При обработке или хранении в АС информации, не отнесенной к
категории секретной, в рамках СЗИ НСД государственным, коллективным,
частным и совместным предприятиям, а также частным лицам рекомендуются
следующие организационные мероприятия:
При разработке АС, предназначенной для обработки или хранения
информации, являющейся собственностью государства и отнесенной к
категории секретной, необходимо ориентироваться в соответствии с РД
"Средства вычислительной техники. Защита от несанкционированного
доступа
к информации. Показатели защищенности от несанкционированного доступа к
информации" на классы защищенности АС не ниже (по группам) 3А, 2А, 1А,
1Б, 1В и использовать сертифицированные СВТ:
В 1990 году была начата разработка международного стандарта
критериев оценки общего пользования в Международной организации по
стандартизации (ISO). Новые критерии были призваны обеспечить взаимное
признание результатов стандартизированной оценки безопасности на
мировом
рынке ИТ.
Версия 1.0 ОК была завершена CCEB в январе 1996 года и одобрена ISO
в апреле 1996 года для распространения как Проект комитета. Был
проведен
ряд экспериментальных оценок на основе версии 1.0 ОК, а также
организовано широкое обсуждение документа. Затем в рамках Проекта ОК
была предпринята значительная переработка ОК на основе замечаний,
полученных при его экспериментальном использовании, публичном
обсуждении
и взаимодействии с ISO. Переработка документа была выполнена преемником
CCEB, названным Советом по реализации ОК (CCIB).
CCIB завершил
бета-версию 2.0 ОК в октябре 1997 года и представил ее в WG3, которая
одобрила ее как Второй проект комитета. Последующие промежуточные
версии
проекта предоставлялись неофициально экспертам WG3 по мере их
подготовки
в CCIB. CCIB
При разработке стандарта был учтён опыт ряда стран, ликвидированы
недочёт предыдущих стандартов, выявленные к этому времени.
Во-первых больше нет прямолинейной классификации систем, вместо этого
предложена многоуровневая схема определения требований к создаваемому
продукту. Благодаря этому стало возможным определять безопасность самых
различных систем, от обычных приложений, то комплексных решений и
автоматизированных систем. Также в стандарте определён полностью цикл
разработки продукта, благодаря чему более точно определена необходимая
для сертификации документация.
Итак, давайте вкратце пройдёмся по этапам разработки продукта, согласно
требованиям Общих критериев.
Первым делом необходимо составить так называемое Задание Безопасности
(Security Target). ЗБ содержит совокупность требований безопасности.
"Задание Безопасности" содержит общую спецификацию, совместно с
требованиями и целями безопасности и их обоснованием. "Задание
Безопасности" является основой для соглашения между всеми сторонами
(разработчиками, потребителями и экспертами) относительно безопасности
продукта.
Стандарт определяет что и в каком формате должно быть описано в этом
документе. После того как продукт пройдёт сертификацию, его "Задание
Безопасности" помещается в реестр (на данный момент этот реестр
публично
доступен по адресу http://www.commoncriteria.org) вместе с описанием
продукта и доступно для просмотра потенциальными покупателями.
Поскольку
линейной классификации (как это было в "Оранжевой Книге" ) больше нет,
то покупателю придётся внимательно изучить этот документ, прежде чем
понять удовлетворяет ли его этот продукт. Здесь сразу проявляется
преимущество и недостатки Общих Критериев. С одной стороны, больше нет
привязки к конкретному типу систем и можно точно подобрать требования
которые необходимы для того или иного продукта. С другой стороны, надо
подробнее изучать характеристики продуктов, чтобы выбрать наиболее
подходящий.
Требования по безопасности в "Задании Безопасности" могут быть
сформулированны с использованием:
- существующих Профилей Защиты (о них подробнее будет сказано
ниже)
- существующие Профили Защиты могут быть использованы как основа
для создания нового Профиля Защиты.
- cуществующих компонентов функциональных требований или требований
гарантии
- расширенных требований: в Профиле Защиты или Задании
Безопасности
могут быть использованы дополнительные функциональные требования, не
содержащиеся в части 2 стандарта и/или дополнительные требования
гарантии, не содержащиеся в части 3 стандарта.
Таким образом, перед тем как составить Задание Безопасности для
продукта, необходимо посмотреть есть ли в стандарте готовые
предопределённые профили защиты или составить свой профиль.
Профиль защиты - это совокупность требований безопасности, взятых из
Общих Критериев или заданных явным образом. Профиль Защиты позволяет
выразить не связанные с конкретной реализацией требования безопасности
для некоторого семейства продуктов. В стандарте четко перечисленны
требовании к описанию Профиля. Профиль это как бы тот самый класс по
"Оранжевой книге" только более с более сложной структурой и не
находящийся в какой либо иерархии. Профиль отдельно включает в себя
помимо требований и уровень гарантии оценки.
Уровень Гарантии Оценки (Evaluation Assuarance Level) - это
предопределённые пакеты гарантий. Определяют уровень доверия к
проведённой сертификации продукта. Чем выше уровень гарантии, тем выше
доверие пользователя, что продукт действительно представляет из себя то
о чём заявлено в Задании Безопасности.
В общих критериях определены уровни гарантии оценки с 0 по 7. По
уровням 1 - 4 проводится сертификация в ISO, сертификация (и детали
требований)
по остальным уровням оставлено на откуп правительственным учреждениям
стран.
Между делом возник ещё один термин (а их в общих критериев великое
множество) - пакет. Пакет это некая комбинация компонентов.
Пакет
объединяет совокупность функциональных требований или требований
гарантии, которые выполняют установленное подмножество целей
безопасности. Пакет предназначен для многократного использования
и
определяет требования, которые известны как полезные и эффективные для
достижения конкретных целей безопасности. Пакет может быть использован
в
составе больших крупномасштабных пакетов, Профилей Защиты и Заданий
Безопасности.
Вот наконец мы и добрались до основы Общих критериев, большую часть
которых составляют именно различные шаблоны требований (компоненты)
сгруппированных в классы, а классы в свою очередь в семейства.
Эти требования как всякие шаблоны представляют собой полуфабрикаты с
которыми можно проводить определённые (стандартом) операции такие как:
итерация( многократное повторение одного и того же требования в разном
контексте), назначение ( спецификация параметров, устанавливаемых
при использовании компонента ), выбор (из возможных вариантов указанных
в шаблоне) и уточнение (проведение детализации там где это необходимо).
Между требованиями могут быть зависимости. То есть если вы выбрали
некоторое требование, для выполнения которого необходимо выполнение
дополнительных условий, необходимо указать и все требования от которых
это зависит.
В общих критериях определяются следующие классы требований:
- FAU Аудит безопасности
- FCO Связь
- FCS Криптографическая поддержка
- FDP Защита данных пользователя
- FIA Идентификация и аутентификация
- FMT Управление безопасностью
- FPR Приватность
- FPT Защита комплекса средств обеспечения
безопасности.
- FRU Использование ресурсов
- FTA Доступ к Объекту Оценки.
- FTP Доверенный маршрут/канал
Пример семейства требований - FTA_SSL Блокирование сеанса.
Пример компонента - "FTA_SSL.1
Блокирование сеанса, инициированное комплексом средств обеспечения
безопасности".
Сложность Общих критериев (которую вы наверное уже ощутили на себе) с
лихвой компенсируется огромной гибкостью и повторным использованием уже
подготовленных компонент. Например существуют сертифицированные готовые
профили защиты, которые помещены в общий репозитарий и могут
использоваться всеми желающими.
Самые интересные из них это Labeled Security Protection Profile (SLPP)
- замена класса B1, а также Controlled Access Protection Profile
(CAPP) - замена класса C2. Оба профиля разработаны Агенством
Национальной безопасности США и призваны обеспечить переход с
требований
"Оранжевой книги" на новый стандарт.
Немаловажно также что это международный стандарт. В настоящее время
глобальной интеграции экономикии промышленности стран очень кстати
иметь
общие критерии оценки, ведь зачастую заказы, связанные с
инфморационными
технологиями для одного государства выполняются на территории другого.
Что касается Российской Федерации, то нам ещё предстоит проделать
большую работу по разработке собственных профилей на смену требований
Руководящих Документов. На момент написания подобная работа только
начиналась. Возможно правильным являлось бы ,по примеру США,
просертифицировать в последствии эти профили в ISO, так они пройдут
проверку корректность и получат международное признание.
Кроме того новые критерии гораздо сложнее в работе, поэтому предстовит
провести ещё большую работу по обучению сертифицирующих организаций
новой методологии.
3. Информационная безопасность в Автоматизированных Системах
3.1 Угрозы безопасности функционирования Автоматизированных Систем
На текущий момент существует множество вариантов моделей угроз
безопасности АС. Это объясняется стремлением более точно описать
многообразные ситуации воздействия на информацию и определить наиболее
адекватные меры противодействия. В принципе можно восопльзоваться любой
подходящей моделью необходимо только убедиться, что она учитывает
максимальное число факторов, влияющих на безопасность информации.
Угроза безопасности информации -- это возможность осуществления
действия, направленного против объекта защиты, проявляемая в опасности
искажений и потерь информации. В данном случае речь идет не обо всей
информации, а только о той ее части, которая, по мнению ее владельцев
(пользователей), имеет определенную ценность или подлежит защите в силу
закона (конфиденциальная информация).
Необходимо также учитывать, что источники угроз безопасности могут
находиться как внутри фирмы -- внутренние источники, так и вне ее --
внешние источники. Такое деление оправдано потому, что для одной и той
же угрозы (например в случае кражы) методы противодействия для внешних
и
внутренних источников будут разными.
При составлении модели угроз безопасности АС использованы различные
варианты моделей, разработанных специалистами в области защиты
информации государственных и негосударственных научных учереждений.
Исходя из проведенного анализа, все источники угроз безопасности
информации, циркулирующей в корпоративной сети, можно разделить на три
основные группы:
-
угрозы, обусловленные действиями субъекта (антропогенные)
-
угрозы, обусловленные техническими средствами (техногенные)
-
угрозы, обусловленные стихийными источниками.
Первая группа, самая обширная, представляет наибольший интерес с
точки зрения организации противодействия угрозам данного типа, так как
действия субъекта всегда можно оценить, спрогнозировать и принять
адекватные меры. Методы противодействия этим угрозам управляемы и
напрямую зависят от воли организаторов защиты информации.
Субъекты, действия которых могут привести к нарушению безопасности
информации, могут быть как внешние: криминальные структуры;
недобросовествные партнеры; конкуренты; политические противники. Так и
внутренние: персонал учреждения персонал филиалов лица с нарушенной
психикой специально внедренные агенты.
Судя по результатам международного и российского опыта, действия
субъектов могут привест к ряду нежелательных последствий, среди которых
применительно к АС мождно выделить следующий:
-
Кража: технических срудств, носителей информации, информации,
средств доступа
-
Подмена (модификация): операционных систем, систем управления
базами данных, прикладных программ, информации (данных), отрицание
факта
отправки сообщений, паролей и правил доступа
-
Уничтожение (разрушение): технических средств, носителей
информации, программного обеспечения, информации, паролей и ключевой
информации.
-
Нарушение нормальной работы (прерывание): скорости обработки
информации, пропускной способности каналов связи, объемов свободной
оперативной памяти, объемов свободного дискового пространства,
электропитания технических средств
-
Ошибки при инсталяции ПО, ОС, СУБД, при написании прикладного
ПО, при эксплуатации ПО, при эксплуатации технических средств.
-
Перехват информации (несанкционированный): за счет ПЭМИ от
технических средств, за счет наводок по линиям электропитания, за счет
наводок по посторонним проводникам, по акустическому каналу от средств
вывода, по акустическому каналу при обсуждении вопросов, при
подключении
к каналам передачи информации, за счет нарушения установленных правил
доступа (взлом)
Вторая группа содержит угрозы, менее прогнозируемые. напрямую
зависящие от свойств техники и поэтому требующие особого внимания.
Технические средства, содержащие потенцильные угрозы безопасности
информации, также могут быть внутренними:
-
некачественные технические средства обработки информации
-
некачественные программные средства обработки информации
-
вспомогательные средства (охраны, сигнализации, телефонии)
-
другие технические средства, применяемые в учреждении
и внешними:
-
средства связи
-
близко расположенные опасные производства
-
сети инженерных коммуникаций (энерго-, водоснабжения,
канализации)
-
транспорт
Последствиями применения таких технических средств, напрямую
влияющими на безопасность информации, могут быть:
-
Нарушение нормальной работы: нарушение работоспособности систем
обработки информации, нарушение работоспособности связи и
телекоммуникаций, старение носителей информации и средств ее обработки,
нарушение правил доступа, эдектромагнитное воздействие на технические
средства
-
Уничтожение (разрушение): программного обеспечения, ОС, СУБД,
средств обработки информации (броски напряжений, протечки), помещений,
информации (размагничивание, радиация и т.д.), персонала
-
Модификации (изменения): программного обеспечения, ОС, СУБД,
информации при передачи по каналам связи и телекоммуникациям
Третью группу составляют угрозы, которые совершенно не поддаются
прогнозированию, и поэтому меры их парирования должны применяться
всегда. Стихийные источники, составляющие потенциальные угрозы
информационной безопасности, как правило, являются внешними по
отношению
к рассматриваемому объекту, и под ними понимаются, прежде всего,
природные катаклизмы:
Эти природные и необъяснимые явления также влияют на информационную
безопасность, опасны для всех элементов АС и могут привести к
последствиям, перечисленны ниже:
Даже первичный анализ приведенного перечня угроз безопасности
информации показывает, что для обеспечения комплексной безопасности
необходимо принятие как организационных, так и технических решений
противодействия. Такой подход позволяет дифференцированно подойти к
рапределению материальных ресурсов, выделенных на обеспечение
информационной безопасности.
Необходимо отметить, что оценить весовые коэффициенты каждой угрозы
достаточно трудно из-за высокой латентности из проявлений и отсутствия
вразумительной статистики по данному вопросу. Поэтому в современной
литературе приводятся различные шкалы оценок. Вместе с тем на основе
анализа, проводимого различными специалистами в области компьютерных
преступлений можно расставить угрозы безопасности по частоте проявления
следующим образом:
-
кража (копирование) программного обеспечения
-
подмена (несанкионированный ввод) информации
-
уничтожение (разрушение) данных на носителях информации
-
нарушение нормально работы (прерывание) в результате вирусных
атак
-
модификация (изменение) даннх на носителях информации
-
перехват (несанкионированный съем) информации
-
кража (несанкионированное копирование) ресурсов
-
нарушение нормальной работы (перегрузка) каналов связи
-
непредсказуемые потери
Описав состав угроз безопасности информации, необходимо перейти к
вопросам моделирования их воздействия. Все эти угрозы по-разному
проявляются в каждой точке корпоративной сети.
Наложение угроз безопасности информации на модель АС позволяет в
первом приближении оценить их опасность и методом исколючения выделить
наиболее актуальные для конкретного объекта защиты. Кроме того, можно в
первом приближении оценить объемы необходимых работ и выбрать основное
направление по обеспечению защиты информации.
Следствием реализации выявленных угроз безопасностиинформации в
конечном счете может стать ущемление прав собственника (пользователя)
информации или нанесение ему материального ущерба, наступившее в
результате:
-
уничтожение информации из-за нарушения программных, аппаратных
или программно-аппаратных средств ее обработки либо систем защиты, а
также из-за форс-мажорныз обстоятельств, применения специальных
технических (например, размагничивающих генераторов), программных
(например, логических бомб) средств воздействия, осуществляемого
конкурентами, персовалом учреждения или его филиалов, преступными
элементами либо поставщиками средств обработки информации в интересах
третьих лиц,
-
модификация или искажение информации вследствие нарушения
программных, аппаратных иили программно-аппаратных средств ее обработки
либо систем защиты, а также форс-мажорных обстоятельств, применения
специальных программных средств воздействия, осуществляемого
конкурентами, персоналом учреждения, поставщиками средств обработки
информации в интересах третьих лиц
-
хищения информации путем подключения к линиям связи или
техническим средствам, за счет снятия и расшифровки сигналов побочных
электромагниных илучений, фотографирования, кража носителей информации,
подкупа или шатнажа персонала учреждения или его филиала, прослушивание
конфиденциальных переговоров, осуществляемых конкурентами, персоналом
учреждения или преступнымим элементами, несанкионированного копирования
информации, считывания данных других пользователей, мистификации
(маскировки), маскировки под зарегистрированного пользователя,
проводимых обслуживающим персоналом автоматизированной системы, хищение
информации с помощью программных ловушек
-
махинации с информацией (путм применения программных,
программно-аппаратных или аппаратных средств), осуществляемых в
интересах третьих лиц поставщиками средств обработки информации или
проводимых персоналом учреждения
3.2 Внутренние и внешние угрозы
Отдельно рассмотрим угрозы, которые наиболее распространены в последнее
время, благодаря тому что большинство АС распространились за пределы
одного здания, одной организации, одного государства. Если
проанализировать угрозы по местонахождению нарушителя, то возникают
следующие основные классы:
- внешние угрозы
- внутренние угрозы
Внутренние угрозы проистекают со стороны персонала. В основном он
вызваны следующими причинам:
- Сотрудник может находится под шантажом
- Личная выгода
- Банальная месть
Внешние угрозы специфичны для современных автоматизированных систем.
Благодаря большей распределённости современных АС, их каналы связи
зачастую проходят через сети публичного доступа. В связи с этим
возникают новые классы проблем:
- Публичная сеть, и её политика безопасности, не контролируются
какой либо одной организацией. Как следствие фактически нет лиц
ответственных за безопасность информации
- Доступ к отдельным узлам АС (преимущественно шлюзам) получают все
пользователи публичной сети. В случае глобальных сетей, таких как
Internet потенциально доступ к шлюзам АС имеют миллионы людей.
С какой целью может действовать внешний злоумышленник? Да фактически с
любой. В атаках на автоматизированные системы могут проявляться любые
деструктивные особенности характера человека. Характер атак в
основном ориентирован на каналы инфморации:
- Изменение маршрута следования данных
- Прослушивание
- Внедрение в канал ложных данных
- Перекрытие канала (атака типа "Отказ Обслуживания" (DOS))
3.2.1 Наиболее распространённые сетевые атаки
Атаки компьютерных сетей типа "отказ в обслуживании" (DoS, Denial of
Service) являются одними из самых, а быть может, и самыми
распространенными. Частично виной тому простота их реализации и высокая
эффективность. Целью таких атак, как следует из названия, является
приведение сервера-жертвы в состояние, когда он не может отвечать на
запросы клиентов. Побочным эффектом таких атак является большой трафик,
направленный на жертву. Далее мы рассмотрим некоторые, наиболее
распространенные, атаки и методы их сдерживания. Важно понимать, что не
существует методов, которые защитили бы вас от DoS-атак, можно лишь
попытаться минимизировать причиненные убытки и оперативно отреагировать
на атаку.
В классическом понимании успехом атаки "отказ в обслуживании" является
отказ оператора (сервера) в предоставлении сервиса. Но, беря во
внимание
специфику домашней сети и малого провайдера, я считаю, что в крайнем
случае, приемлемо перестать временно (на период атаки) предоставлять
сервис клиенту, чтобы не обанкротиться.
Атаки типа "SYN-flood"
Как известно, TCP использует трехэтапное квитирование для установления
соединения. В основу данного типа атак заложена идея превышения
ограничения на количество соединений, находящихся в состоянии
установки.
Результатом является состояние системы, в котором она не может
устанавливать новые соединения. Кроме того, при такой атаке на каждый
входящий пакет система-жертва высылает ответ, что ещё сильнее
увеличивает злонамеренный трафик.
Возможность данной атаки обусловлена тем, что в сети Internet
(стандарта IPv4) не предусмотрен контроль за IP-адресом отправителя
сообщения, следовательно невозможно отследить истинный маршрут,
пройденный IP-пакетом, и, следовательно, у конечных абонентов сети нет
возможности ограничить число возможных запросов, принимаемых в единицу
времени от одного хоста. Поэтому возможно осуществление данного типа
атаки, которая будет заключаться в передаче на атакуемый хост как можно
большего числа ложных TCP-запросов на создание соединения от имени
любого хоста в сети. При этом атакуемая сетевая ОС в зависимости от
вычислительной мощности компьютера либо - в худшем случае - практически
зависает, либо - в лучшем случае - перестает реагировать на легальные
запросы на подключение (отказ в обслуживании). Это происходит из-за
того, что для всей массы полученных ложных запросов система должна,
во-первых, сохранить в памяти полученную в каждом запросе информацию и,
во-вторых, выработать и отослать ответ на каждый запрос. Таким образом,
все ресурсы системы "съедаются" ложными запросами: переполняется
очередь
запросов и система занимается только их обработкой. Эффективность
данной
удаленной атаки тем выше, чем больше пропускная способность канала
между атакующим и целью атаки, и тем меньше, чем больше вычислительная
мощь такуемого компьютера (число и быстродействие процессоров, объем
ОЗУ и т. д.).
Поскольку такие атаки не предусматривают обратной связи с атакующим,
нет необходимости использовать настоящий адрес источника.
В заключение необходимо отметить, что в существующем стандарте сети
Internet IPv4 нет приемлемых способов надежно обезопасить свои системы
от этой
удаленной атаки.
DoS-атаки основанные на протоколе ICMP.
Большое количество DoS-атак основывается на протоколе ICMP. Его
служебные функции могут использоваться в неблаговидных целях. Сценарий
данного вида атаки таков: посылается эхо-запрос с адресом источника,
подмененным на адрес жертвы. Следовательно, эхо-ответ уже приходит к
компьютеру-жертве. Если, к тому же, эхо-запрос является
широковещательным для сети, на него могут отреагировать все компьютеры
указанной сети и поток, направленный на жертву, уже становится
огромным,
приобретая лавинообразный характер.
DoS-атаки основанные на программных ошибках
Зачастую отказ в обслуживании возникает из-за элементарных ошибок
реализации сетевых сервисов. Ошибка может быть какой угодно, результат
всегда один - сервер больше не может принимать запросов. Например,
из-за
ошибки в реазации обработки запросов сервер может уйти в бесконечный
цикл.
DDoS - атаки
Расширение данного вида атаки может являться распределенная или
DDoS-атака. В предыдушем примере эхо-запросы посылались с одного
компьютера злоумышленника и использовалась лишь одна сеть для
"отражения" и "усиления" потока пакетов. В данном случае атака ведется
с
десятков, сотен или даже тысяч компьютеров и для "отражения"
используется соответствующий порядок сетей. . Проведение таких атак
требует значительных умений, ресурсов и большог желания. Для начала
нужно внедрить большое количество "агентов", которые обычно
распространяются вместе с "троянами". Нужно собрать достаточно
разведывательной информации о жертве и возможных посредниках. Это этапы
достаточно длительные. Лишь после этого можно начинать распределенную
атаку.
Как правило современные операционные системы стараются противостоять
большинству атак основанных на особенностях протоколов Internet.
Программные ошибки реализации сетевых служб остаются на совести
авторов,
Но вот атакам типа "забивание траффика" противостоять практически
невозможно, особенно если они распределённые. В последнем случае одному
серверу противостотит слишком большая вычислительная мошь чтобы он смог
её "переварить".
Перейдём к рассмотрению атак направленных изменение маршрута следования
сетевых пакетов.
ARP-spoofing
Из анализа безопасности протокола ARP становится ясно, что, перехватив
на атакующем хосте внутри данного сегмента сети широковещательный
ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя
искомым хостом (например, маршрутизатором), и в дальнейшем активно
контролировать и воздействовать на сетевой трафик "обманутого" хоста.
Рассмотрим обобщенную функциональную схему ложного ARP-сервера:
- ожидание ARP-запроса
- при получении ARP-запроса передача по сети на запросивший хост
ложного ARP-ответа, в котором указывается адрес сетевого адаптера
атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на
котором будет принимать пакеты ложный ARP-сервер (совершенно
необязательно указывать в ложном ARP-ответе свой настоящий
Ethernet-адрес, так как при работе непосредственно с сетевым адаптером
его можно запрограммировать на прием пакетов на любой Ethernet-адрес)
- прием, анализ, воздействие и передача пакетов обмена между
взаимодействующими хостами
Стоит отметим, что, во-первых, причина успеха данной удаленной атаки
кроется, не столько в Internet, сколько в широковещательной среде
Ethernet и, во-вторых, очевидно, что эта удаленная атака является
внутрисегментной и поэтому представляет для вас угрозу только в случае
нахождения атакующего внутри вашего сегмента сети. Однако, как известно
из статистики нарушений информационной безопасности вычислительных
сетей, большинство состоявшихся взломов сетей производилось изнутри
собственными сотрудникам. Причины этого понятны. Как подчеркивалось
ранее, осуществить внутрисегментную удаленную атаку значительно легче,
чем межсегментную. Кроме того, практически все организации имеют
локальные сети (в том числе и IP-сети), хотя далеко не у всех локальные
сети подключены к глобальной сети Internet. Это объясняется как
соображениями безопасности, так и необходимости такого подключения для
организации. И, наконец, сотрудникам самой организации, знающим
тонкости
своей внутренней вычислительной сети, гораздо легче осуществить взлом,
чем кому бы то ни было. Поэтому администраторам безопасности нельзя
недооценивать данную удаленную атаку, даже если ее источник находится
внутри их локальной IP-сети.
Ложный DNS-сервер в сети Internet
Как известно, для обращения к хостам в сети Internet используются
32-разрядные IP-адреса, уникально идентифицирующие каждый сетевой
компьютер в этой глобальной сети. Однако, для пользователей применение
IP-адресов при обращении к хостам является не слишком удобным и далеко
не самым наглядным.
Для реализации системы DNS был создан специальный сетевой протокол DNS,
для обеспечения эффективной работы которого в сети создаются
специальные
выделенные информационно-поисковые серверы - DNS-серверы. Поясним
основную задачу, решаемую службой DNS. В современной сети Internet хост
при обращении к удаленному серверу обычно имеет информацию только о его
имени и не знает его IP-адреса, который и необходим для
непосредственной
адресации. Следовательно, перед хостом возникает стандартная проблема
удаленного поиска: по имени удаленного хоста найти его IP-адрес.
Решением этой проблемы и занимается служба DNS на базе протокола DNS.
Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети
Internet:
- хост посылает на IP-адрес ближайшего DNS-сервера (он
устанавливается при настройке сетевой ОС) DNS-запрос, в котором
указывает имя сервера, IP-адрес которого необходимо найти
- DNS-сервер, получив запрос, просматривает свою базу имен на
наличие в ней указанного в запросе имени. В случае, если имя найдено,
а,
следовательно, найден и соответствующий ему IP-адрес, то на запросивший
хост DNS-сервер отправляет DNS-ответ, в котором указывает
искомыйIP-адрес. В случае, если указанное в запросе имя DNS-сервер не
обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на
один из корневых DNS-серверов, адреса которых содержатся в файле
настроек DNS-сервера root.cache, и описанная в этом пункте процедура
повторяется, пока имя не будет найдено (или не найдено)
Анализируя с точки зрения безопасности уязвимость этой схемы удаленного
поиска с помощью протокола DNS, можно сделать вывод о возможности
осуществления в сети, использующей протокол DNS, удаленной атаки, а
имеено создание ложного объекта в сети. Практические изыскания и
критический анализ безопасности службы DNS позволяют предложить три
возможных варианта удаленной атаки на эту службу:
- внедрение в сеть Internet ложного DNS-сервера путем перехвата
DNS-запроса
- внедрение в сеть Internet ложного сервера путем создания
направленного "шторма" ложных DNS-ответов на атакуемый хост
- внедрение в сеть Internet ложного сервера путем перехвата
DNS-запроса или создания направленного "шторма" ложных DNS-ответов на
атакуемый DNS-сервер
В первом случае для реализации атаки путем перехвата DNS-запроса
атакующему необходимо перехватить DNS-запрос, извлечь из него номер
UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора
DNS-запроса и искомое имя и затем послать ложный DNS-ответ на
извлеченный из DNS-запроса UDP-порт, в котором указать в качестве
искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит
в дальнейшем полностью перехватить трафик между атакуемым хостом и
сервером.
Необходимым условием осуществления данного варианта атаки является
перехват DNS-запроса. Это возможно только в том случае, если атакующий
находится
либо на пути основного трафика, либо в сегменте настоящего DNS-сервера.
Выполнение одного из этих условий местонахождения атакующего в сети
делает подобную удаленную атаку трудно осуществимой на практике
(попасть
в сегмент DNS-сервера и, тем более, в межсегментный канал связи
атакующему, скорее всего, не удастся). Однако в случае выполнения этих
условий возможно осуществить межсегментную удаленную атаку на сеть
Internet.
Во втором случае осуществления удаленной атаки, направленной на службу
DNS). В этом случае атакующий осуществляет постоянную передачу на
атакуемый хост заранее подготовленного ложного DNS-ответа от имени
настоящего DNS-сервера без приема DNS-запроса! Другими словами,
атакующий создает в сети Internet направленный "шторм" ложных
DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса
используется протокол UDP, в котором отсутствуют средства идентификации
пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к
полученному от DNS-сервера ответу, является, во-первых, совпадение
IP-адреса отправителя ответа с IP-адресом DNS-серве-ра; во-вторых,
чтобы
в DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих,
DNS-ответ должен быть направлен на тот же UDP-порт, с которого был
послан DNS-запрос (в данном случае это первая проблема для атакующего),
и, в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке
DNS
(ID) должно содержать то же значение, что и в переданном DNS-запросе (а
это вторая проблема).
Поэтому для осуществления данной удаленной атаки атакующему необходимо
выбрать интересующий его хост (например, aaa.bbb.com), маршрут к
которому требуется изменить так, чтобы он проходил через ложный сервер
-
хост атакующего. Это достигается постоянной передачей (направленным
"штормом" ) атакующим ложных DNS-ответов на атакуемый хост от имени
настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных
DNS-ответах указывается в качестве IP-адреса хоста aaa.bbb.com IP-адрес
атакующего. Далее атака развивается по следующей схеме. Как только цель
атаки (атакуемый хост) обратится по имени к хосту aaa.bbb.com, то от
данного хоста в сеть будет передан DNS-запрос, который атакующий
никогда
не получит, но этого ему и не требуется, так как на хост сразу же
поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят
ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака
состоялась, и теперь атакуемый хост будет передавать все пакеты,
предназначенные для aaa.bbb.com, на IP-адрес хоста атакующего, который,
в свою очередь, будет переправлять их на aaa.bbb.com
Таким образом, реализация данной удаленной атаки, использующей пробелы
в безопасности службы DNS, позволяет из любой точки сети Internet
нарушить маршрутизацию между двумя заданными объектами (компьютерами)!
Данная удаленная атака осуществляется межсегментно по отношению к цели
атаки и угрожает безопасности любого хоста Internet, использующего
обычную службу DNS.
Третий вид атаки основан на слудующей технологии работы службы DNS. Из
схемы удаленного DNS-поиска следует, что в том случае, если указанное в
запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос
отсылается сервером на один из корневых DNS-серверов, адреса которых
содержатся в файле настроек сервера root.cache.
Итак, в случае, если DNS-сервер не имеет сведений о запрашиваемом
хосте, то он сам, пересылая запрос далее, является инициатором
удаленного DNS-списка. Поэтому ничто не мешает атакующему, действуя
описанными в предыдущих пунктах методами, перенести свой удар
непосредственно на DNS-сервер. В качестве цели атаки теперь будет
выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться
атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер.
При этом важно учитывать следующую особенность работы DNS-сервера. Для
ускорения работы каждый DNS-сервер кэширует в области памяти свою
таблицу соответствия имен и IP-адресов хостов. В том числе в кэш
заносится динамически изменяемая информация об именах и IP-адресах
хостов, найденных в процессе функционирования DNS-сервера, а именно,
если DNS-сервер, получив запрос, не находит у себя в кэш-таблице
соответствующей записи, он пересылает ответ на следующий сервер и,
получив ответ, заносит найденные сведения в кэш-таблицу в память. Таким
образом, при получении следующего запроса DNS-серверу уже не требуется
вести удаленный поиск, так как необходимые сведения уже находятся у
него
в кэш-таблице. Из анализа только что подробно описанной схемы
удаленного
DNS-поиска становится очевидно, что в том случае, если в ответ на
запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае
"шторма" ложных ответов будет вести их постоянную передачу), то в
кэш-таблице сервера появится соответствующая запись с ложными
сведениями и в дальнейшем все хосты, обратившиеся к данному
DNS-серверу,
будут дезинформированы, и при обращении к хосту, маршрут к которому
атакующий решил изменить, связь с ним будет осуществляться через хост
атакующего. И, что хуже всего, с течением времени эта ложная
информация,
попавшая в кэш DNS-сервера, будет распространяться на соседние
DNS-серверы высших уровней, а, следовательно, все больше хостов в
Internet будут дезинформированы и атакованы. Очевидно, что в том
случае, если атакующий не может перехватить DNS-запрос от DNS-сервера,
то для реализации атаки ему необходим "шторм" ложных DNS-ответов,
направленный на DNS-сервер.
При этом возникает следующая проблема, отличная от проблемы подбора
портов в случае атаки, направленной на хост. Как уже отмечалось ранее,
DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот
запрос двухбайтовым значением (ID). Это значение увеличивается на
единицу с каждым передаваемым запросом. Узнать атакующему это текущее
значение идентификатора DNS-запроса не представляется возможным.
Поэтому предложить что-либо, кроме перебора 256 возможных значений ID,
достаточно сложно. Зато исчезает проблема перебора портов, так как все
DNS-запросы передаются DNS-сервером на 53 порт.
Следующая проблема, являющаяся условием осуществления этой удаленной
атаки на DNS-сервер при направленном "шторме" ложных DNS-ответов,
состоит в том, что атака будет иметь успех только в случае, если
DNS-сервер пошлет запрос на поиск имени, которое содержится в ложном
DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный для
атакующего запрос в том и только том случае, когда на него приходит
DNS-запрос от какого-либо хоста на поиск данного имени и этого имени не
оказывается в кэш-таблице DNS-сервера. В принципе, этот запрос может
возникнуть когда угодно, и атакующему придется ждать результатов атаки
неопределенное время. Однако, ничто не мешает атакующему, не дожидаясь
никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и
спровоцировать DNS-сервер на поиск указанного в запросе имени! Тогда
эта
атака с большой вероятностью будет иметь успех практически сразу же
после начала ее осуществления.
3.2.2 Наиболее вероятные угрозы безопасности АС различных типов
В зависимости от принадлежности автоматизированной системы опрделённому
типу разные виды угроз беопасности данных в ней могут быть более или
менее вероятны. Вероятность опрделённого вида угроз зависит от
структуры АС, от сложности реализации принятой в ней политики
безопасности, от наличия в системе неустойчивых к определённого вида
атакэлементов, от полноты реализации политики безопасности в средах
взаимодействия, включённых в состав АС и т.д.
Угрозы безопасности данных в монолитных системах
Согласно классификации, монолитные системы не включают в свой состав
среду взаимодействия, на которой могло бы происходить понижение уровня
безопасности циркулирующих в системе данных. Поэтому реализация угрозы
бесопасности может возникнуть только при явном нарушении политики
безопасности, принятой в этой системе. Иными словами, если все
программные и аппаратные компоненты АС находятся в штатном режиме и
субъекты ас соблюдают административные правила, можно счичаться только
с внешними угрозами, связанными с превосходящими обстоятельствами.
- Внешние угорзы со стихийным источником: природные бедствия,
пожары и т.д. могут привести к потере данных, отвлечению и гибели
персонала и т.п.
- Силовое или иное воздействие на персонал, склоняющее к нарушению
политики безопасности, может привести к несанкционированному
воздействию как на данные, доступные сотруднику как субъекту системы,
так и на аппаратную составляющую АС.
Однако слабости в реализации политики безопасности системы могут
привести к реализации также и угроз, связанных с воздействием на
интерфейсные устройства и/или превышением субъектами АС прав доступа к
данным системы.
- Недостаточная техническая и административная защищённость
интерфейсных устройств может привести к несанкционированному
прослушиванию конфидициальной информации (например, размещение точки
доступа привилегированного субъекта системы в помещении, доступ к
которому имеют лица с иными правами доступа к данным в системе)
- Ошибки в программном обеспечении могут позволить субекту системы
несанкционированно расширить свои права доступа к данным АС (напрмер,
при использовании атаки клсса buffer overrun).
- Недостаточная административная защищённость или неоправданное
понижения уровня секретности архивных носителей может привести к утечке
данных (посредством кражи или несанкционированно копировани носителя)
- Ошибки и недостаточная надёжность программных и аппаратных
элементов системы может привести к потере данных
- Недостаточный контроль за состоянием системы может спровоцировать
недобросовестного субъеска системы на создание нештатного средства
доступа к данным, не зависящего от его текущих прав доступа. Тогда
понижение прав доступа такого субъекта перестаёт быть эффективным.
Типичный пример -- обиженный на начальство бывший администратор
системы.
Угрозы безопасности в одноуровневых системах
Одноуровневые системы включают в себя одну или несколько сред
взаимодействия, находящихся под единым административным контролем
(например, локальную вычислительную сеть). Помимо уже перечисленных, в
силу специфики понятия среды взаимодействия, в одноуровневых АС могут
быть реализованы угрозы, связанные с частичным понижением уровня
безопасности при передаче данных. Здесь могут играть роль уже не явные
нарушения политики безопасности, а некоторые её искажения, не носящие
очевидный харакртер нарушений.
- Неодинаковые права доступа субъектов АС на различных
программно-аппаратных блоках могут привести к несанкционированному
доступу субъекта системы к информации. Типичный пример -- пользователь,
не имеющий привилегий на сервере, но имеющий их на доверенной рабочей
станции, может добиьтся привилегий на сервере.
- Отказ или сбои в работе среды взаимодействия может привести к
отказу работы системы и даже потере данных, если в АС не учтена
реальная надёжность и/организованного с помощью этой среды
взаимодействия канала передачи данных (например, представляет угрозу
хранение ключевой системной информации ф сетевой файловой системе).
Следует также иметь в виду, что надёжность АС в общем случае меньше
надёжности любого её элемента, участвующего в процессе обработки и
передачи данных.
Угрозы безопасности в иерархических системах
Иерархические системы включают в себя несколько сред взаимодействия,
находящихся под различным административным уонтролем (напрмер, узлы АС,
принадлежащие подразделениям или партнёрам). Помимо угроз, возникающих
от наличия среды взаимодействия, дополнительным источником угром может
стать несогласованность политик безопасности АС в различных точках
административной ответственностиАС. Поскольку, как правило, всей
полнотой информации о совокупной политике безопасности не обладает в
иерархической системе никто, процедура определения несогласованностей,
представляющих угрозу, не бывает полной и до конца надёжной.
- Совместное использование одной среды взаимодействия несколькими
АС может открыть доступ субъектам одной АС к потокам данных другой
- Если согласование политик безопасности происходило по пути
сокращения несовпадающих требований (некоторые правила были исключены
или упрощены для того, чтобы упростить взаимодействие), становятся
возможны разнообразные угрозы по утечке информации и
несанкционированному доступу к ней. Напрмер, если поток данных от
субъекта A к субъекту B невозможен, но возможен поток данных от A к C,
а от C к B, нарушение налицо.
- Невозможность оперативного реагирование на изменение политики
безопасности административно отдельной части АС может создавать
временные лакуны, в течение которых субъект АС будет иметь возможность
пользоваться двойным набором прав доступа
- Использование субъектом нескольких АС идентичной учётной
информации в каждой из этих АС может привести к тому, что
санкционированный доступ к этой информации на одной системе сознаст
угрозу несанкционированного доступа на другой АС. Пример --
использование одного и того же паоля в защищенной АС и в АС,
допускающей открытую трансляцию или хранение пароля.
Угрозы безопасности в многосвязных системах
Многосвязные системы включают в себя среду взаимодействия, не
попадающую под административный контроль, например сеть Интернет. При
прогнозировании угроз в таких системах следует предполагать, что в
процессе передачи посредством этой среды с данными может произойти
всё,
что угодно. Поэтому организация многосвязной АС сопряжена со всеми
возможными видами угроз. Отметим только некторые, которые особенно
актуальны для многосвязных АС.
- Любые передаваемые данные могут быть перехвачены, если данные
передаются в незашифрованном виде, возможна фальсификация.
- Если способ шифрования данных недостаточно наждёжен, или
информация, способствующая расшифровке данных, передаётся по тому же
каналу, что и сами данные, угрозы аналогичны таковым при передаче по
незашифрованному каналу. Пример -- атака monkey-in-the-middle при
использования SSL.
- Если время, затрачиваемое на расшифровку "с нуля" передаваемых
данных сопоставимо со временем их предположительной актуальности,
угрозы аналогичны таковым при передаче по незашифрованному каналу.
Иными словами, если вы используете алгоритм шифрования, позволяющий
расшифровать передаваемую информацию за год, то через год её можно
считать известной злоумышленнику.
- Если в многосвязной АС используется недостаточно надёжное ПО,
вероятность успешной атаки возрастает многократно, оттого что
многократно возрастает возможность реализации внешней угрозы. Вы можете
быть уверены, что лояльные сотрудники авшей компании не станут
атаковать вашу заведомо небезопасную систему, но вы не можете быть
уверены во всех абонентах сети Интернет.
3.3 Методы защиты Автоматизированных Систем
Уменьшить отрицательное воздействие угроз безопасности информации
можно различными методами. Среди таких методов выделяются четыре
основные группы:
Организационные методы в
основном ориентированы на работу с персоналом, выбором местоположения и
размещения объектов корпоративной сети, организацию систем физической и
противопожарной защиты, осуществление контроля выполонения принятых
мер,
воложение персональной ответственности за выполнение мер защиты. Эти
методы применяются не только для защиты информации и, как правило, уже
частично реализованы на объектах АС. Однако их применение дает
значительный эффект и сокращает общее число угроз.
Инженерно-технические методы
связаны с построением оптимальных сетей инженерных коммуникаций при
учете требований безопасности информации. Это довольно дорогостоящие
решения, но они, как правило, реализуются еще на этапе строительства
или
реконструкции объекта, способствуют повышению его общеей живучести и
дают высокий эффект при устранении некоторых угроз безопасности
информации. Некоторые источники угроз, например обусловленне стихийными
бедствиями или техногенными факторами, вообщем не устранимы другими
способами.
Технические методы основаны на применении специалных технических
средств защиты информации и контроля обстановки и дают значительный
эффект при устранении угроз безопасности информации, связанных с
действиями криминогенных элементов по добыванию информации незаконными
техническими средствами.
Кроме того, некоторые методы, например резервирование средств и
каналов связи, оказывают эффект при определенных техногенных факторах.
Программно-аппаратные методы главным образом нацелены на устранение
угроз, непосредственно связанных с процессом обработки и передачи
информации. Без этих методов невозможно построение целостной
комплексной
системы информационной безопасности.
Сопоставление представленных выше угроз безопасности информации и
группы методов противодействия позволяет решить, какими способами какие
угрозы наиболее целесообразно парировать, а также определить
рациональное соотношение групп методов при распределении средств,
выделенных на обеспечение безопасности информации.
Анализ результатов моделирования с учетом принятых в модели
ограничений и допущений позволяет считать, что все группы методов
противодействия угрозам безопасности информации имеют примерно равную
долю в организации комплексной защиты информации. Однако необходимо
учесть, что некоторые варианты могут быть использованы только для
решения ограниченного круга задач защиты. Это особенно характерно для
устранения угроз техногенного и стихийного характера.
Наибольший эффект достигается при применении совокупности
организационных и программно-аппаратных методов противодействия. Анализ
программно-аппаратных методов позволяет сделать вывод, что
гипотетическое средств защиты АС, прежде всего, должно обеспечивать
разграничение доступа собъектов к объектам (мандатный и дискреционный
принципы), управлять внешними потоками информации (фильтрации,
ограничение, исключение) и как минимуму обеспечивать управление
внутренними потоками информации с одновременным контролем целостности
программного обеспечения, конфигурации сети и возможности атак
разрушающиъ воздействий.
После анализа угроз и методов противодействия им можно переходить к
построению системы комплексной защиты информации АС. Прежде чем
приступить к рассмотрению данного этапа, следует обратить внимание на
некоторые моменты, без которых построенная система комплексной защиты
будет не просто бесполезна, но даже вредна. Перечислим основные
принципы
построения таких систем.
3.4 Организационные методы обеспечения информационной безопасности
Поскольку без применения мер административного воздействия обойтись
невозможно в любой АС, отдельно расмотрим эти методы. Краткое
перечисление было дано в первом разделе, здесь будет дано более
подробное перечисление.
Уровень информационной безопасности организации существенно зависит
от всех категорий сотрудников и должностных лиц организации.
Обслуживающий персонал и пользователи могут быть как источниками
внйтренних угроз, так и неотъемлемой частью системы защиты АС. Первое
что необходимо сделать после построения общей концепции защиты
предприятия, это жёсткая регламентация действий. Благодаря этому
сокращаются возможности сотрудников по совершению нарушений.
Однако необходимо не забывать что ограничение никак не должно
сказываться на повседневной деятельности сотрудников и влиять на
производительность их труда. Необходима также разработка серии
инструкций для разных категорий сотрудников: от обычных
пользователей АС, до системных администраторов. Инструкции определяют
порядок работ и позволяют контролировать соблюдение регламента.
Появляется официальное обоснование для введения административных
санкций. Определение ответвенности за нарушение режима безопасности
важный этап. Санкции должны напрямую зависеть от должностных
обязанносей сотрудника. B наконец все созданные руководящие документы
организации не должны противоречить существующему законодательству.
Необходимо также выделения в структуре организации отдельного
подразделения ответственного за создание и соблюдение регламента работ.
Данное подразделение должно постоянно проводить анализ текущей ситуации
и при необходимости (например изменение профиля предприятия) вносить
изменения в существующие руководящие документы. Решающая
административная власть остаётся у руководителей предприятия, но они
тоже обязаны соблюдать предписанные им правила безопасности.
Руководитель данного подразделения назначает администратора
информационной безопасности, лучше всего если данная должность не будет
совмещатся обычным администратором системы. Если в организации
используется несколько АС, то полезно назначить администраторов
безопасности по каждой из систем. Также должны быть назначены
отвественные по безопасности в каждом подразделении организации, а
также
лица осуществляющие непосредственно имеющие отношения безопасности
действия, такие как выдача паролей для АС, оборудования и т.д.
Организационные меры могут быть: разовые (например собственно
разработка концепции безопасности предприятия и других руководящих
документов) и регулярные (например распределение паролей, анализ
системных журналов). Должны быть заранее также предусмотрены меры для
особых ситуаций(пожар, стихийное бедствие, авария, выход из строя
технических средств).
При проведении организационных мер ни в коем случае не надо
забывать
об аппаратных средствах. Все используемые аппаратные средства должны
быть зарегистрированны и должны периодически проходить контроль
целостности. Терминалы в идеале не должны иметь возможности
подключения каких-либо внешних периферийных устройств. В случае
каких-либо сбоев в функционировании аппаратных средств должен быть
определён регламент их осмотра и замены иначе возможны ситуации утечек
информации при предаче компьютера с неудалёнными данными в ремонт.
Хороший пример объединения административных и программных мер
защиты
- процедура авторизации сотрудников. Проходя на территорию организации
сотрудник проходит авторизацию у охраны (face-control или с
использованием каких либо специальных средств), далее следует вторичная
авторизация при входе на територрию, где размещаются терминалы АС, и
наконец происходит завершающая авторизация средствами АС. При
поступлении на работу, сотрудник получает все отличительные аттрибуты,
начиная с удостоверения и пропуска, заканчивая выдачей account'а и
пароля. При этом пароль как правило бывает создан автоматически,
предаётся в конверте, так что выдающий не знает какой пароль у данного
пользователя. При выдаче вышеперечисленных аттрибутов заполняются
необходимые формуляры, которые позволят в дальнейшем анлизировать
случаи
нарушения и законно применять административные санкции.
3.5 Принципы построения комплексных систем защиты
Противодействие угрозам безопасности информации носит
недружественный характер по отношению к пользователям и обслуживающему
персоналу АС. Это происходит из-за того, что лююбая система защиты по
определению налагает ограничения на работу организационного и
технического характера.
Поэтому одним из основных принципов создания системы комплескной
защиты информации должен стать прнцип
масимальной дружественности. Иными словами, не надо вводить
запреты там, где без них можно обойтися, если уж и налагать
ограничения,
то предварительно нужно продумать, как это сделать с минимальными
неудобствами для пользователя. Притом следует учесть совместимость
создаваемой системы комплексной защиты с используемой операционной и
программно-аппаратной структурой АС и сложившимися традициями
(нормативными документами) организации или учереждения.
Вплотную к этой проблеме стоит принцип
прозрачности. АС пользуются не только высококлассные
программисты. Кроме того, основное назначение АС состоит в обеспечении
производственных потребностей пользователей, то есть работы с
информацией. Поэтому система защиты информации должна работатьы в
"фоновом" режиме, быть "незаметной" и не мешать пользователям в
основной
работе, но при этом выполнять все возложенные на нее функции.
Принцип превентивности. Надо
всегда помнить, что последствия реализации угроз безопасности
информации
могут потребовать значительно больших финансовых, временных и
материальных затрат по сравнению с затратами на создание комплексной
защиты информации.
Принцип оптимальности.
Оптимальный выбор соотношения различных методов и способов
противодействия угрозам безопасности информации при принятии решения
позволит в значительной степени сократить расходы на создание системы
защиты информации.
Принцип адекватности.
Принимаемые решения должны быть дифференцированны в зависимости от
важности, частоты и вероятности возникновения угро безопасности
информации , степени конфиденциальности самой информации и ее
коммерческой стоимости.
Принцип системного подхода к
построению системы защиты позволяет заложить комплекс мероприятий по
противодействию угрозам безопасности информации уже на стадии
проектирования АС, обеспечив оптимальное сочетание организационных и
инженерно-технических мер защиты информации. Важность реализации этого
принципа основана на том, что оборудование действующей незащищенной АС
средствами защиты информации сложнее и дороже, чем изначальное
проектирование и построение ее в защищенном варианте.
Принцип адаптивности. Система
защиты информации должна строиться с учетом возможного изменения
конфикурации сети,числа пользователей и степени конфиденциальности и
ценности информации. При этом введение каждого нового элемента сети или
изменения действующих условий не должно снижать достигнутого уровня
защищенности корпоративной сети в целом.
Принцип доказательности. При
создании системы защиты информации необходимы соблюдение
организационных
мер внутри АС, включая привязку логического и физического рабочих мест
друг к другу, а также применение специальных аппаратно-программных
средств идентификации, аутентификации и подтверждения подлинности
информации. Реализация данного прнципа позволяет сократить расходы на
усложнение системы, например применять цифровую электронную подпись
только при работе с удаленными и внешними рабочими местами и
терминалами, соединенными с АС по каналам связи.
Эти принципы должны быть положены в основу при выборе направлений
обеспечения безопасности АС, функций и мер защиты информации. При
выборе
средств защиты информации обязательного встает вопрос о необходимости
подтверждения выполнения тех или иных функций конкретным средство
защиты. Это немаловажный процесс, который в определенных случаях
(например, при организации защиты информации, содержащей
государственную
тайну или сведения о личности - персональные данные) строго
регламентирован. Свидетельством того, что те или иные функции защиты
реализованы конкретным средством защиты, является сертификат
соответствия - документ, которым независимые эксперты подтверждают
готовность срдеств выполнить возложенные на него задачи.
При проектировании эффективной подсистемы информационной
безопасности следует также учитывать ряд общих принципов обеспечения
информационной безопасности:
-
экономическая эффективность - стоимость средств защиты должна
быть меньше, чем размеры возможного ущерба
-
минимум привилегий - каждый пользователь должен иметь
минимальный набор привилегий, необходимый для работы
-
открытость проектирования и функционирования механизмов защиты -
специалисты, имеющие отношение к системе защиты, должны полностью
представлять себе принципы ее функционирования и в случае возникновения
затруднительных ситуаций адекватно на них реагировать
-
всеобщий контроль - любые исключения из множества контролируемых
субъектов и объектов защиты снижают защищенность автоматизированного
комплекса обработки информации
-
независимость системы защиты от субъектов защиты - лица,
занимавшиеся разработкой системы защиты, не должны быть в числе тех,
кого эта система будет контролировать
-
отчетность и подконтрольность - система защиты должна
предоставлять доказательства корректности своей работы
-
ответственность - подразумевается личная ответственность лиц,
занимающихся обеспечением безопасности информации
-
изоляция и разделение - объекты защиты целесообразно разделять
на группы таким образом, чтобы нарушение защиты в одной из групп не
влияло на безопаснссть других
-
полнота и согласованность - надежная системы защиты должна быть
полностью специфицирована, протестирована и согласована
-
параметризация - защита становится более эффективной и гибкой,
если она допускает изменение своих параметров со стороны администратора
-
принцип враждебного окружения - система защиты должна
проектироватся в расчете на враждебное окружение. Разработчики должны
исходить из предположения, что пользователи имеют наихудщие намерения,
будут совершать серьезные ошибки и искать пути обхода мезанизмов защиты
-
привлечение человека -- наиболее важные критические решения
должны приниматься человеком
-
отсутствие излишней информации о наличии механизмов защиты -- из
существование следует по возможности скрыть от пользователей, работа
которых должна контролироваться
3.6 Типичные методы защиты АС различного типа от реализации угроз
Методы защиты системы от угроз безопасности данныз напрямую диктуются
списком возможных угроз этим системам. Списки возможных угроз
правильнее всего создавать, взаимодействуя с реальной АС. Однако
некоторые погнозы таких спискв можно дать, исходя из классификации АС,
равно как и рассмотреть типичные для каждого класса методы защиты.
Заметим, что список вероятных угроз расширяетя с увеличением
масштаба и связности системы, поэтому главной стратегией защиты должно
быть приведение АС к типу, допускающему реализацию меньшего количества
утроз безопасности данных.
- Доведение системы до состояния связности.
- Если необходимости использовать административно неподконтрольную
среду взаимодействия нет, или возможно организовать такой среде
административно подконтрольную замену, многосвязную систему можно
преобразовать в односвязную. Тем самым станет возможно избежать угроз,
характерных для многосвязных АС. Напрмер, исключить из состава АС
взаимодействие через сеть Интернет.
- Организация единого администрирования
- Если есть возможность организовать есдиное административное
управление всеми средами взаимодействия, обеспечить единую политику
безопасности и полный доступ администратора к состоянию АС,
иерархическую систему можно преобразховать в одноуровневую.
Более точно, система останется многоуровневой по управлению, но
в силу единого информационногго пространства и единого центра принятия
решений, станет возможным анализ непротиворечивости политики
безопасности и минимизируются угрозы, характерные для иерархической АС.
Примером может служить введение единого администрирования, единой
отчётности и единой системы учетных записей в корпоративонй сети.
- Локализация среды взаимодействия
- Если есть возможность использовать надёжную среду взаимодействия,
которая позволяет не снижать уровень защиты данных при их передаче и
доступ к которой на любом уровне возможен только программно-аппаратным
блокмам АС, одноуровневую систему можно преобразовать в монолитную.
Более точно, система будет состоять из нескольких
программно-аппаратных блоков, ведущих себя аналогично элементам одного
программно-аппаратного блока, при этом модифицированная среда
взаимодействия будет функционировать в качестве шины данных такогй
метасистемы. Очень важен единый центр управления составляющими частями
системы. Всё это позволяет избежать угроз, связанных с наличием в АС
среды взаимодействия. Примером такой АС может служить вычислительный
кластер или мэйнфрейм.
Защита монолитных систем
Как правило, монолитные системы используются для решения задач
максиальной защищённости, поэтому в них принимаются меры по
предотвращению даже довольно маловероятных угроз:
- Защита от физического воздействия: пуленепробиваемый ил
устойчивый к иным воздействиям корпус, двойная фильтрация воздуха,
защита от проникающего излучения и т.д.
- Техническая и административная защита от утечки данных:
блокировка испускаемого излучения, многократный контроль физического
доступа к интерфейсным устройствам, средства нейтрализации и захвата
возможного злоумышленника и т.п.
- Перевод некоторых процедур изменения данных в системе на
админстративны уорвень, например, схемы безопасноси с тсутствием в
схеме прав доступа единого доверенного субъекта
- Многократная стедновая проверка аппаратного обеспечения и
верификация исходных текстов ПО
- Двойное и многократное зеркалирование функций элементов АС
- Анализ системных журналов на предмет возможных попыток нарушения
политики безопасности АС
Защита одноуровневых систем
Предметом дополнительной защиты в одноуровневых системах служит среда
взаимодействия.
- Применение к среде взаимодействия методов защиты монолитных АС.
- Разделение совместно используемой несколькими АС среды
взаимодействия на логическом (организация виртуальных сетей) и
физическом (прокладка выделенных линий) уравнях.
- Предотвращение появления в среде взаимодействия нового или
фальшивого программно-аппаратного блока (возможно в сиду единого
администрирования). Напрмер строгая фиксация точек входа в локальную за
определёнными компьютерами.
- Сосредоточение сервисов одного уровня защиты в одном
программно-аппаратном блоке
Защита иерархических систем
Предметом дополнительной защиты в иерархических системах служит
синзронизация и согласование политик безопасности
- Ведение и согласование отчётностей административно раздельных
областей АС
- Оповещение узловых центров АС об общесистемных событиях, включая
попытки атак
- Избыточное шифрование и дополнительный мониторинг точек изменения
административной ответственности
- Анализ совокупной политики безопасности на предмет
непротиворечивости
Защита многосвязных систем
Прежде всего состоит в крайне осторожном обращении с информацией,
передаваемой при посредстве административно неподконтрольной среды
взаимодействия. Следует, однако, помнить, что защита многосвязных
систем даже теоретически не может быть гарантирована.
- Повсеместное использование передачи данных с надёжным шифрованием
и запрет исаользования других видов передачи данных
- Использование административных каналов для передачи ключевых
данных, напрмер передача сертификатов лично посредством обмена дисками
- Разделение публичной, внутренней и системной зон внутри АС,
например внедрение межсетевого экрана между серверами общего доступа
(WWW) и серверами частного доступа (корпоративной СУБД), а также между
серверами частного доступа и собственно корпоративной сетью (т.н.
"демилитаризованная зона").
4. Программно-аппаратные средства обеспечения безопасности
В данном разделе будут перечислены различные существующие программные
средства обеспечения безопасности, предоставляемые современными
информационными системами. Также будут указаны известные проблемы
существующих средств.
4.1 Регистрация и аудит
Ещё во премена создания первых критериев TCSEC была осознана
необходимость регистрации действий объектов информационной системы.
Идея
, как и многие другие, была привнесена из реальной жизни любого
режимного учереждения. При получении документа, проходе в закрытые
помещения человек обязательно регистрировался в журнале, ставил в нём
свою подпись. В случае возникновения проблем эта журнальная запись
скреплённая подписью ответственного лица могла служить обвинением или
доказательством невиновности.
Точно также в информационных системах происходит регистрация действий
пользователей, критичных для обеспечения безопасности данных. Как
правило регистрируются:
- выход и выход из системы
- доступ к защищаемому ресурсу
- операции над защищаемум ресурсом
При этом перед регистрацией стоят следующие задачи:
- полнота данных. Не должно быть пропущенно не одного мало-мальски
важного события
- достоверность данных. Как и в случае бумажных журналов требуется
иметь доказательную силу зарегистрированных действий
Что касается полноты, то немаловажным является условие постоянной
доступности журнала для новых данных. Место на диске когда-нибудь
закончится. Как должна поступать в этом случае система. Классический
подход в системах, где безопасность превыше всего, считается что в
данном случае вся работа в системе должна быть приостановлена: лучше
пусть остановится работа, чем будет пропущено какое-то важное событие.
Ведь злоумышленник может спровоцировать переполнение журнала пустыми
событиями и потом совершить незарегистрированную нелегальную
операцию (или по крайней мере попытаться сделать её). Ещё раз напомним,
что стоимость информации зачастую превышает стоимость имущества большой
организации. Пусть лучше отключится АС во всём здании, чем
злоумышленник
незаметно (именно назаметно) прочитает файл с описанием какой-нибудь
бомбы.
Вряд ли может существовать какое-то другое решение, разве когда
изменится архитектура современных информационных систем. Но можно
оттянуть момент завершения места на диске проведением регулярных мер по
контролю за дисковым пространством: например, производить регулярную
архивацию данных, вовремя заменять диск, выделенный для журнала, на
новый.
Тут сразу встаёт другая проблема. Если регистрационные данные так
важны, то их тоже надо защищать. То есть журнал является эдаким
"един в двух лицах" . С одной стороны он явдяется частью системы
защиты, с другой - защищаемыми данными. Записать в
журнал все возможные действия с журналом невозможно, необходимо
привлечение администратвных мер.
Ещё для полноты важно чтобы в записи содержались исчерпывающие данные о
произошедшем событии. Например если будет сообщено что открыт файл, но
не будет указано точное (именно точное, например для операционных
систем
типа Unix это номер i-node) местоположеине файла, то информация теряет
свой смысл. Она просто ничего на даст. Также обязательно надо
регистрировать дату и время события.
Вернёмся к рассмотрению задач стоящих перед регистрацией. Достоверность
данных. Внутри системы у пользователей не существует никаких
подписей, все пользователи (и их процессы) различаются исключительно по
уникальным идентификаторам, выдаваемым при входе в систему. Таким
образом ключевую роль в этом вопросе играет подсистема идентификации и
аутентификации. Если мы считаем идентификацию пользовтеля достоверной,
то записи журнала будут также достоверными, если, конечно, авторы
операционной системы докажут, что исключена подделка записи от момента
создания и до момента записи в файл.
Для достоверности также необходимо доказать что системные события
генерируются неподделываемым образом, то есть что невозможно
возникновение ложных событий. Самым правильным является генерация
событий на аксимально возможном низком уровне и ни в коем случае не на
высоком. Например: противопоказано ганерировать события на уровне
текстового редактора, нет никакой гарантии что пользователь будет
работать именно через него.
При простановки даты и времени события необходимо знать достоверное
время. В противном случае события потеряют свою истинную
последовательность и могут быть неверно истолкованы. Время действия
играло решающую роль в бумажных журналах, его роль не
преуменьшилась и в информационную эпоху. Эту последовательнось ни в
коем
случае нельзя пытаться восстановить по порядку записи в регистрационную
базу. Дело в том что многие из них могут возникать одновременно и
одновременно идти в журнал.
Таким образом архитекторы информационной системы обязаны доказать, что
время в системе по крайней мере строго возрастать и с одной скоростью.
Я
не говорю об обязательном соответствии астрономическому времени. Это
конечно тоже должно выполняться, но в отдельных случаях можно обойтись
и
без этого.
В случае проектирования распределённой информационной системы
желательно обеспечить синхронизацию времени по всем узлам, в противном
случае администратору придётся все время держать перед глазами (или в
уме) локальное время каждого узла, что затруднит его работу. Особенно
это касается случая распределённых атак , когда надо восстановить
цепочку событий по всей территории защищаемой АС.
Говоря о регистрации ни в коем случае нельзя забывать об аудите,
анализе журнальных записей.
Как уже было сказано выше чем на более низком уровне генерируются
события тем больше к ним доверия. Оборотная сторона этого состоит в
том,
что записи в журнале сложно поддаются чтению и изучению. Система может
только сообщить
что тогда-то и тогда-то такой-то процесс, выполняющийся от имени
такого-то пользователя пытался получить доступ к такому-то ресурсу. Для
надёжного контроля же необходимо знать больше:
- статистические данные по нарушениям в системе. Статистика может
проводиться как по ресурсам так и по пользователям и обязательно
по времени. Эта инфморация позволяет контролировать активность обмена
данными и отмечать подозрительные её всплески. Например если в какой-то
из дней участились неудачные попытки доступа к некоторому ресурсу в то
время когда его не используют - это повод для беспокойства
- высокоуровневые данные о перемещениии данных между различными
подраздалениями, отделами. Если файл с данными одного отдела вдруг
распечатан на принтере находящемся в другом отделе (пусть даже оба
отдела физически используют один сервер) или была попытка доступа
сотрудника одного отдела к данным другого отдела - это также повод для
беспокойства. Один и тот же человек может иметь несколько
пользовательских записей в системе, а необходимо оценивать всё-таки его
действия в целом.
Для того чтобы было возможно использовать аудит на журнальные записи
накладывается ещё одно довольно жёсткое ограничение: записи должны
иметь
максимально стандартный формат. В противном случае невозможно будет
осуществить автоматический анализ. А ручной анализ при большом потоке
данных вещь нереальная в особенности для огромных информационных
систем,
простирающихся на территории нескольких регионов (или даже
стран).
Это требование также должно быть изначально заложено в архитектуру
системы ибо все без исключения cлужбы АС, как низкоуровневые так
и высокоуровневые должны поддерживать один формат сообщений.
4.2 Разграничение доступа
Самый распространённый приём защиты и в реальной жизни и в
информационных системах - не допускать всех подряд к данным. Даже если
в
данном компоненте информационной системы циркулируют данные одного
уровня конфиденциальности, всё равно есть данные относящиеся к разным
категориям пользователей, ведь финансовый отчёт вряд ли должен быть
доступен администратору системы и его процессам также как и файл с
паролями не надо давать на прочтение финансовому директору.
Выход - данные надо каким либо образом классифицировать, а потом
раграничить доступ в соответствии с выбранной классификации.
Что касается разграничения, То или иное раграничение доступа в системе
сводится к заполнению некоторой матрицы , в строках которой указаны
объекты, в столбцах - субъекты, а на пересечении - права доступа
соответствующего субъект к соответсвующему субъекту.
Подобная схема называется дискреционной или произвольной и упоминается
практически во всех стандартах, посвящённых защите операционных систем
(например в "Оранжевой книге"). Напомним ещё раз, что наиболее часто
она
встречается в современных системах в виде прав доступа (или списков
доступа - ACL) на файлы.
Дискреционная модель является простой, эффективной, но слишком
низкоуровневой. В жизни требуются более хитрые и гибкие подходы, но
почти все из них в конечном итоге сводятся к этой самой матрице доступа
в том или ином виде.
Первый шаг к облегчению пользования материцай доступа - укрупнение,
группировка субъектов и объектов по тому или иному принципу, то есть
классификация. Классификация может быть одноуровневой и многоуровневой,
иерархия может быть линейной и нет.
Под одноуровневой классификацией я понимаю, когда происходит просто
разделение по линии субъектов и объектов на непересекающиеся множества.
И доступ может быть только внутри своей группы. Например пользователь
test1 не имеет доступа к данным пользователя test2.
Многоуровневая классификация - это когда объекты делятся на вложенные
друг в друга множества. И объект имеет доступ к объектам из того
множества в которые он входит. Например пользователь из группы с
допуском "секретно" читает данные из группы "секретно", а также и из
группы "конфиденциально" и "несекретно". Но он же, например, совершенно
не имеет никакого доступа к данным группы "совершенно секретно".
Как правило решения прежде всего ориентированные на раграничение
доступа нежели на использование какой-то классификации требуют
минимальной доработки существующего программного обеспечения, поэтому
сначала проведём краткий обзор именно их:
4.2.1 Изолированные среды исполнения
На самом высоком уровне ограничения находятся изолированные полноценные
среды исполнения. Эти среды могут быть реализованы совершенно разными
средствами, сюда же можно отнести и виртуальные машины. Общая задача
этих сред - максимально сохраняя функциональность уже сущсствующего ПО
отделить потоки данных друг от друга.
Допустим администратор большой информационной системы должен по долгу
службы иметь прямой доступ к большому количеству узлов унутренней сети
директората и одновременно к большому количеству узлов сети партнёров.
С
данными сетями работают свои процессы и не желательно чтобы они хотя бы
гипотетически могли обмениваться информацией (например используя тайные
каналы). Дорогой выход из положения иметь на одном столе два, не
связанных физически, компьютера для управления обоими сетями. А если
придётся поставить десятки компьютеров? Гораздо лучше иметь на одном
компьютере несколько изолированных сред. преимущество изолированных
сред, что не надо переписывать существующее ПО, процессы даже и не
будут
догадываться об их существовании. Ещё одно преимущество, для
большинства
существующих операционных систем не придётся их модифицировать, всё уже
есть готовое.
4.2.2 Минимизация полномочий
Мало раграничить доступ субъектов к объектам, надо ещё убедиться чтобы
субъекты имели в данный момент времени ровно стольно полномочий сколько
им необходимо для выполнении данной задачи. Ведь если менеджеру надо
иметь доступ и к базе данных внутренних распоряжений по предприятию и
базе данных кадров, вовсе не обязательно что ему это требуется
одновременно ибо в случае если кто-то получит доступ к консоли
управления этого менеджера он сможет одновременно повредить обе
базы.Самый простой приём решения этой проблемы - представление
одного человека несколькими пользователями в информационной системе.
Этот каждый пользователь будет соответствовать одной из задач, которые
возложены на данного человека.
Но в системе исполняются процессы не только реальных пользователей.
Если для каждого из них делать отдельную запись с отдельной
расстановкой
аттрибутов раграничения доступа по системе - управление такой махиной
станет очень тяжёлым. Выход из положения расстановка аттрибутов не на
защищаемые объекты, а на процессы. Подобные механизмы существуют в
некоторых операционных системах и желательно иметь их в архитектуре
каждой системы проектируемой с учётом защиты данных.
Подобную схему можно ещё представить как
4.2.3. Блокираторы поведения
Это совсем низкоуровневый и специфичный приём, однако он тем не менее
широко используется, а посему требует упоминания.
Идея заключается в том, что если мы не в состоянии создать хорошее
программное обеспечение, то давайте сделаем хотя бы так, чтобы процессы
не могли изначально делать то что потенциально опасно.
Например, печально знаменитая атака на переполнение буфера, которыми
пестрят большинство отчётов об обнаруженных ошибках. Вероятность
осуществления такой атаки может быть значительно снижена если ядро
операционной системы сделает стек непригодным для запуска с него
исполняемого кода. Ещё один подход к данной проблеме - давайте не будем
переписывать заново программы, а просто сразу соберём их компилятором,
который будет совершать дополнительные проверки во время исполнения.
Данные средства также как и изолированные среды хороши для того случая
когда уже есть масса готового программого обеспечения и надо
наименьшими
средствами повысить его надёжность. Подобные средства также разработаны
для большинства существующих операционных систем и языков
программирования, но наиболее правильным будет как всегда изначально
заложить их в архитектуру проектируемой системы.
Многоуровневая классификация вносит новое измерение и новые
взаимоотношения между субъектами. Самая простейшая иерархия - линейная.
4.2.4 Мандатное раграничение доступа
Этот вид иерархии существовал ещё в докомпьютерные времена и назывался
"грифы секретности". Общая идея такова - есть данные которые можно
читать всем, есть которые можно читать не всем, а есть и такие, которые
можно читать только избранным.
Классической считается модель, предложенная Белл и Ла-Падула. Эта
модель была даже реализована в своё время в операционной системе
MULTICS.
Освовная идея состоит в следующем. Необходимо реализовать систему
обработки грифованной информации. Система должна работать в полностью
автоматическом режиме и не допускать возможности перетекания информации
из ''большего грифа" в "меньший". То есть "совершенно секретная"
информация никогда не должна стать "секретной".
Для строго математического обоснования было формально описано что такое
состояние системы, описаны правила перехода системы из одного состояния
в другое. Далее было определено что такое безопасное состояние и
доказано, что никакими разрешёнными переходами невозможно перевести
систему из безопасного состояния в опасное.
Метка безопасности состоит из двух компонент. Первая компонента -
собственно гриф, он образует линейную иерархию в классификации. Вторая
компонента - категория, абстракция описания множества ведомств к
которым принадлежит данный субъект или объект.
Считается что метка (A,B) доминирует над меткой (C,D) если A>=C и B
надмножество D. Например, если элементы категорий брать из множества
{a,b,c,d}, а гриф - натуральное число, то метка {2,{a,b}} доминирует
над
меткой {1,{a}}. А вот метка {2,{a,b}} не доминирует над {1,{c,d}}.
Таким
образом устанавливается на множестве меток отношение частичного
порядка.
Линейный порядок нас не устраивает поскольку два документа с одним и
тем
же грифом могут относиться к разным ведомствам и человек имеющий доступ
к документом данного уровня в своём ведомстве может вовсе не иметь
доступа к документам другого ведомства. В принципе вторая компонента
метки успешно эмулируется дискреционным доступом (для назначения
множественных групп объекту можно использовать систему вложенных
каталогов принадлежащих соответствующим группам), но поскольку в
оригинальной модели метка была именно двойная - будем придерживаться
той же схемы.
Для каждого объекта и субъекта две метки: максимальный уровень
безопасности и текущий уровень безопасности. Для объектов эти два метки
совпадают, для субъектов могут различаться. Максимальный уровень всегда
доминирует над текущим.
Назначаются следующие правила игры:
- (no read-up). Субъект имеет доступ к объекту, только если текущий
уровень субъекта доминирует над текущим уровнем объекта.
- (no write-down) Второе правило предназначено для предотвращения
ситуации когда субъект открыл один файл с большей меткой для чтения и
меньшей для записи. Если такая ситуация станет возможной, то произойдет
нежелательная утечка информации с понижением грифа. Во избежание таких
проблем записывать разрешается только в объекты с тем же уровнем
безопасности (если объект не существовал до этого, то он автоматически
получает уровень равным текущему уровню субъекта). Добавлять данные
(append) можно только в объекты большего уровня.
- Поскольку предыдущее правило сильно снижает удобство
использования системы, то появляются так называемые "доверенные"
субъекты которы могут игнорировать это правило.
Таким образом права доступа назначают только субъекту при его заведении
в системе, а потом вся регуляция происходит автоматически. Модель
создана так что потоки данных могут идти только наверх или на тот же
уровень но ни в коем случае не в низ. Несмотря на простоту и красоту
первая же реализация показала, что подобная модель плохо уживается в
реальной системе и необходимо делать исключения - "доверенные "
процессы. Так жизнь опять вносит свои коррективы и красивая
математическая модель в жизни покрывается множеством дополнительных
винтиков гаечек и лазеек.
Вот ещё одна проблема связанная с мандатным доступом. Когда речь идёт о
простейшей системе со статическими объектами, всё хорошо, но как только
система приходит в движение...
При "перемещении" данных необходимо перемещать вместе с ними и
привязанные к ним метки. Эта проблема актуальна для всех
автоматизированных систем обработки информации. Там практически никогда
не бывает статических данных, собранных в одном узле, данные как
правило
циркулируют по всей сети. Если данные перемещаются в своём исходном
контейнере (файле), то протокол передачи файлов должен передавать
вместе
с файлом и все его аттрибуты, включая метки. В противном случае после
копирования секретных данных с машины A на машину B они могут перестать
быть секретными. Если данные перемещаются без контейнера, то при
доставке в конечный пункт они должны обрести новый контейнер с той же
меткой. Например при передачи результата запроса из базы данных из поля
категории секретно, в клиентской программе данные тоже должны быть
отмеченны как секретные. При сохранении части данных в буфере обмена
они
должны быть отмечены там как секретные и не могут быть вставлены в
нескретный документ.
Ещё немаловажный момент - преобразование данных. При преобразовании
данных в другой формат может происходить естественная потеря метки
из-за
изменения их представления. Например, человек не может работать с
файлами в их электро-магнитном или ином представлении непосрественно,
для этого данные преобразуются в символьную или иную форму и выводятся
при помощи соответствующего устройства. Надо помнить что в этот момент
данные покинули систему и более не контролируются. Если на экран
монитора выведено содержимое секретного файла, то предотвратить
дальнейшую утечку информации можно только административными мерами. В
конце-концов человек может использовать свою память в качестве буфера
обмена в обход всех красивых мандатных моделей.
Итак, резюмирую. При передаче (преобразовании) грифованных данных,
протоколы передачи должны сохранять (для преобразования по возможности)
метку. Это необходимо помнить и не возлагать особо больших надежд
на программные методы защиты.
4.2.5 Нелинейная иерархия
Следующим этапом идёт усложнение иерархии. Усложнение позволяет
назначать привилегии более точно и соответственно держать пользователей
на более длинном поводке.
4.2.5.1 Domain Type Enforcement
Самая простая из нелинейных иерархий преложнена в модели, называемой
Domain Type Enforcement или сокращённо DTE. Основная идея состоит в
разделении исполняемых процессов на непересекающиеся группы с более
точным (и сложным) определением взаимодействий этих групп. Эта модель
очень действенна например для разделения процессов по задачам, например
на сетевые и локальные.
Type Enforcement - это модель базирующая на таблице. Субъекты
разделяются на домены, объекты на типы. Возможен доступ на чтение,
запись, исполнение и отказ в доступе. Возможные варианты доступа
описываются в таблице (Глобальная таблица определения доменов, Domain
Definition Table (DDT)) где в столбцах перечислены домены, в строках
типы, а на пересечении указаны возможные права доступа.
Взаимодействие между субъектами контролируется дополнительной таблицей
(Domain Interaction Table - DIT). В строках и столбах данной таблицы
перечислены домены, на пересечении возможные права доступа,
например: послать сигнал, создать/уничтожить, и т.д.
В отличие от TE, DTE поддерживает неявное определение аттрибутов.
Например, аттрибуты могут быть заданы на каталог и наследоваться на все
файлы и подкаталоги данного каталога.
Каждый процесс может перейти из одного домена в другой только через
запуск специального процесса, так называемую точку входа. Переход
возможен, только если один домен имеет право запуска для другого
домена.
Право запуска "auto" на некотором домене автоматически выбирает этот
домен, если произошёл вход в одну из его точек входа.
В результате получаем высокоуровневое описание схемы которую уже можно
легко привязать к реальной системе. Сильная сторона этой модели -
максимально возможная точность при определении матрицы доступа. Слабая
сторона следует из сильной, столь подробное описание сложно
поддерживать. Как правило домены определяются один раз и больше не
меняются.
4.2.5.2 Ролевая модель
Ролевая модель (Role Based Access Control - RBAC) определяет субъекты,
роли и транзакции. Транзакция - это процедура изменения состояния,
рассматриваемая вместе с необходимыми для этого правами доступа к
данным. Вся деятельность в системе происходит через определённые
транзакции, за исключением сугубо системных задач, таких как
идентификация и аутентификация.
Три основных правила ролевой модели:
- Назначение ролей: Субъект может запустить транзакцию только если
субъект имеет назначенную или выбранную роль.
- Авторизация роли: Активная роль субъекта должна быть одна из
авторизованных данному субъекту
- Авторизация транзакции: Субъект может запустить транзакцию только
если эта транзакция авторизована для активной роли субъекта.
Дополнительно в описании транзакций возможно указать какая роль какие
права доступа к объектам имеет во премя запуска процедуры трансформации.
Роли могут иметь представительство в другой роли. Дочерняя роль
наследует права всех родительских ролей, включая их авторизации на
запуск транзакций. Для поддержания правила Разделения обязанностей
дополнительно действует правило взаимного исключения. Благодаря этому
пары ролей не могут иметь общей дочерней роли, или иначе говоря не
могут
быть одновременно актифированны для одного и того же субъекта.
Для каждой роли определяется максимально возможное количество дочерних
ролей, а также максимально возможное количество субъектов, которые
могут
иметь её в качестве активной.
Данная модель интересна своей ориентированностью на выполняемые задачи.
Каждая задача получает ровно столько полномочий сколько ей необходимо -
не больше и не меньше. Нет необходимости в отличие от DTE заполнять
права на все файлы. Разрешения возникают только там где это необходимо.
Тем н менее данная модель всё-таки достаточно сложная и требует большой
квалификации обслуживающего персонала. Но это общее правило - тем
длинее
поводок, чем точнее минимизируются полномочия пользователей, тем
сложнее
используемая модель.
4.2.6 Заключение
Как бы не было изощрённо сделано разграничение доступа, как бы
хитро не была создана иерархия немаловажным является следующий факт.
Всегда остаётся тот, кто должен всё это настраивать, управлять. В самой
простой классификации, одноуровневой есть всегда суперпользователь,
который может делать всё или в лучшем случае у каждой группы
пользователей есть свой босс. Прелесть мандатного доступа в том что
администрирования как такого нет - метки назначаются изначально, а
потом
права доступа возникают автоматически (то есть матрица доступа
заполняется по известному алгоритму), здесь в роли суперпользователя
выступает некий автомат, зато файл со случайно "зашкалившей"
секретностью невозможно уже вернуть к нормальной жизни. Поскольку это
может сказатся на работоспособности системы иногда на практике всё-таки
пренебрегают этим (нанося значительный ущерб модели в целом) и
появляется в системе ещё один суперпользователь. Сложные иерархические
модели как правило сочетают автоматику с ручной настройкой, но всё
равно
возникают локальные суперпользователи.
В общем как не крути - хочешь получить управляемую систему, получай и
управляющего.
Есть ещё один немаловажный момент о котором обязательно надо
упомянуть. Эффективность, да и работтоспосоность вообще,
механизма
разграничения доступа существенно зависит от качества расстановки
аттрибутов на субъекты и объекты системы. Необходимо
гарантировать:
- точность определения объектов и субъектов. Субъекты и объекты
должны иметь уникальные идентификаторы(!). В противном случае система
разграничения доступа будет давать сбой: то не даст доступ кому надо, а
то допустит куда не нужно. Особое внимание надо обратить на
идентификаторы пользователей. Пользователи в системе появляются и
уходят
(например при переходе человека на другую работу его пользовательская
запись аннулируется), но вновь добавленные в систему пользователи не
должны получить ни в коем случае идентификатор удалённого ранее
пользователя. В противном случае, новый пользователь может получить
доступ к чужим данным. Например, вновь заведённый программист может
получить доступ к документам бывшего финансового директора.
- надёжность определения субъектов и объектов. Некоторые субъекты и
объекты могут иметь несколько различных представлений в системе, но
зачастую надо считать все эти представления как одно целое. Самый
наглядный пример: В Unix есть специальные файлы устройств, так вот эти
файлы надо различать по общим идентификаторам (major,minor), но ни в
коем случае частным (то есть как файлы, по номеру inode) иначе
злоумышленник может просто заново создать в другом месте специальный
файл с тем же общим идентификатором, но другим частным и получить
доступ, хотя ему он был запрещён.Говоря образно: надо защищать комнату,
а не конкретное окно ведущее в неё.
4.3 Контроль целостности
Пожалуй самый распространённый приём защиты данных - это контроль
целостности. Данная технология применяется в различных контекстах и на
разных этапах жизненного цикла программного обеспечения.
Во-первых, контроль целостности играет доказательную роль в любом
сертификационном процессе. Сертифицированный продукт не может быть
изменён по дороге от сертификационного центра до покупателя. Помимо
чисто административных мер (пломбирование дисков с информацией),
распространённым является сличение контрольных сумм данных на диске с
контрольными суммами указанными на сопроводительных документах.
Второе применение, это подтверждение замкнутости программной среды.
Одним из важных организационных приёмов является неизменность
программной среды узлов автоматизированной системы. Ведь если
пользователи будут ставить на рабочих местах какие угодно программы, то
это равносильно тому что пронести оружие в защищаемое помещение.
Умышленно или случайно таким способов в автоматизированной системе
могут
возникнуть вирусы, "троянские" программы, процессы приводящие к атакам
типа отказ в обслуживании и многое другое. Просто ограничить список
используемого ПО недостаточно, необходимо ещё как-то это
контролировать.
Замкнутая программная среда означает, что все исполняемые файлы не
возможно удалить или перезаписать, а пользователь не может запускать
никаких приложений кроме тех, которые разрешены ему поисполняемым
задачам. Регулярная проверка и совпадение с эталонными
контрольных
сумм файлов исполняемых программ убеждает (до некоторорой степени)
администратора, что в системе исполняются только те программы, которые
были инсталлированы им и нет никаких новых, нелегальных программ. Эту
процедуру можно назвать "статическим протоколированием". Периодически
делается "слепок" системы и сравнение с эталонным состоянием. Данная
процедура весьма полезна для анализа глобальных изменений, просмотр как
бы с высоты птичьего полёта.
Контроль целостности может проводиться в любое время - как до загрузки
операционной системы специальными аппаратными средствами, так и во
время
работы системы или аппаратными или программными средствами. При
использовании и разработке программных средств следует иметь в виду что:
- Программа подсчёта контрольных сумм не должна доверять никому
кроме самой себя. Поэтому, во-первых, она должна хранить данные в
доверенном месте, лучше всего на сменном диске, вставляемом в
систему на время проверки (лучше всего если этот диск будет в
режиме только чтения во время проверки, режим записи следует разрешать
только во время создания новых эталонных сумм). А, во-вторых, програма
должна быть собранна статически и не использовать никаких внешних
системных библиотек (можно подменить библиотеки таким образом, что
программа будет всегда выдавать положительные результаты). Сама
программа в идеале должна размещаться на внешнем носителе, вставляемом
в
систему только на время проверок.
- Если запуск происходит во время работы системы, то необходимо
понимать, что некоторые файлы могут измениться сразу после того как они
пройдут проверку, поэтому в идеале проверку надо проводить когда
система
не занимается никакой обработкой информации.
Для расчёта контрольных сумм как правило используются так называемые
хеш-функции. Их задача "перемолотить" переданные данные до
неузнаваемости и при этом достичь эффекта, когда сложно подобрать две
такие входные комбинации, когда будет одинаковый выход. Наиболее часто
используются такие проверенные временем алгоритмы как:
- MD5 - разработан Роном Ривестом для генерации ключей для
знаменитого алгоритма шифрования RSA.
- SHA1 - алгоритм принятый как стандарт Национальным Институтом
Стандартов и Технологий США (NIST)
- Могут применяться и модификации обычных блочных алгоритмов
шифрования.
Полезно также использовать имитовставки ГОСТ-28147-89, это вносит ещё
один уровень надёжности - невозможно подделать контрольную сумму
не зная секретного ключа.
Работая с контрольными суммами необходимо помнить, что они хоть и дают
вероятность обнаружения изменения файла, но эта вероятность не
стопроцентная. Как правило размер файла во много раз превышает размер
контрольной суммы. Получить стопроцентную гарантию можно только путём
побайтового сравнения с эталоном.
4.4 Анализаторы исходного кода
Данный класс средств предназначен для того чтобы изначально
предотвратить большинство стандартных ошибок в программном обеспечении.
Использование хорошо проверенного программного обеспечения снимает как
минимум половину наиболее распространённых атак на АС.
В настоящий момент используются два класса подобных средств:
- Средства аудита программного обеспечения , которые предотвращают
возникновение уязвимых мест, поскольку позволяют заранее обнаружить их
как с помощью средств автоматического анализа, так и без них.
- Средства предотвращения использования уязвимых мест , которые
представляют собой методы времени компиляции, препятствующие
возникновению ошибок во время исполнения.
При этому средства аудита могут быть:
- Статические. Статические анализаторы проверяют исходные тексты и
сообщают о подозрительных строках кода, которые могут оказаться
уязвимыми. Недостатком подобных анализаторов является большое
количество
ложных срабатываний, а также невозможность обнаружить сложные,
комплексные ошибки. При этом ложных срабатываний избежать невозможно
поскольку подобный анализ тесно связан с с особенностями конкретных
языков программирования.
- Динамические. Поскольку многие важные уязвимые места в защите
невозможно обнаружить с помощью статического анализа, часто весьма
полезным оказывается использование динамической отладки. Программа
проходит через жёсткую проверку граничных условий которые с большой
вероятностью должны привести к обнаружению уязвимостей
Средства предотвращения как правило являются расширениями к стандартным
компиляторам добавляющие дополнительные проверки на соблюдение границ
структур данных во время исполнения программы.
4.5 Сетевые средства
4.5.1. Межсетевые экраны
Интенсивное развитие глобальных комьютерных сетей, появление новых
технологий поиска информации привлекают все больше внимания к сети
Internet со стороны частных лиц и различных организаций. Многие
организации принимают решение об интеграции своих локальны и
корпоративных сетей в глобальную сеть. Использование глобальных сетей в
коммерческих целях, а также при передаче информации, содержащей
сведения
конфиденциального характера, влечет за собой необходимость построения
эффективной системы защиты данных.
Глобальная сеть Internet создавалась как открытая система,
предназначенная для свободного обмена информацией. В силу открытости
своей идеологии Internet предоставляет злоумышленникам значительно
большие возможности по сравнению с традиционными информационными
системами. Через Internet нарушитель может:
- вторгнуться во внутреннюю сеть предприятия и получить
несанкционированный доступ к конфиденциальной информации
- незаконно скопировать важную и ценную информацию
- получить пароли, адреса серверов, их содержимое
- входить в информационную систему АС под именем
зарегистрированного пользователя и т.д.
Ряд задач по отражению наиболее вероятных угроз для внутренних сетей
способны решать межсетевые экраны (МЭ). Межсетевой экран - это система
межсетевой защиты, позволяющая разделить общую сеть на две части или
более и реализовать набор правил, определяющих условия прохождения
пакетов с данными через границу из одной части общей сети в другую. Как
правило, эта граница проводится между АС и глобальной сетью Internet,
хотя ее можно провести и внутри АС. МЭ пропускает через себя весь
трафик, принимая относительно каждого проходящего пакета решение -
пропускать его или отбросить. Для того чтобы МЭ мог осуществить это,
ему
необходимо определить набор правил
фильтрации. Ни один МЭ не может гарантировать полной защиты АС при всех
возможных обстоятельствах. Однако для большинства АС установка МЭ -
необходимое условие обеспечения безопасности внутренней сети. Главный
довод в пользу применения МЭ состоит в том, что без него системы
внутренней сети подвергаются опасности со стороны слабо защищенных
служб
сети Internet, а также зондированию и атакам с каких-либо других
компьютеров как внешей так и внутренней сети. Ряд распространненых
служб
сети Internet, которые могут найти применение внутри АС обладают
"врожденными слабостями" с точки зрения безопасного их
функционирования,
безопасности обрабатываемой информации, безопасности всей АС в целом. К
таким службам относятся:
- программы обработки и пересылки почтовых сообщений
- службы сетевых имен (DNS)
- WEB-сервис, FTP-сервис
- большая часть протоколов семейства TCP/IP
Политика сетевой безопасности в каждой АС должна включать как минимум
две состявляющие:
- политику доступа к сетевым сервисам
- политику реализации межсетевых экранов
Политика доступа к сетевым сервисам должна быть уточнением общей
политики организации в отношении защиты информационных ресурсов в АС.
МЭ
может реализовывать ряд политик доступа к сервисам АС. В простейшем
случае политика доступа к сетевым сервисам может быть основана на одном
из следующих принципов:
- запретить доступ из Internet во внутреннюю сеть АС и разрешить
доступ из внутренней сети в Internet
- разрешить ограниченный доступ во внутренюю сеть из Internet,
обеспечивая работу только отдельных "авторизованных" систем, например
информационных и почтовых сереверов
В соответствии с политикой реализации межсетевых экранов определяются
правила доступа к ресурсам внутренней сети АС. Правила доступа к
внутренним ресурсам должны базироваться на одном из следующих принципов:
- запрещать все, что не разрешено в явной форме (наиболее
безопасный, но может внести определенные неудобства в работу
пользователей АС)
- разрешать все, что не запрешено в явной форме (не
рекомендуемый принцип построения, так как дает больше возможностей
обойти МЭ при несанкционированном доступе к ресурсам АС)
Функциониальные требования к МЭ охватывают слудующие сферы:
- фильтрацию на сетевом уровне
- фильтрацию на прикладном уровне
- настройку правил фильтрации и администрирование
- средства сетевой аутентификации
- внедрение журналов и учет сетевых событий
Основные компоненты межсетевых экранов . Большинство компонентов
межсетевых экранов можно отнести к одной из трех категорий:
- фильтрующие маршрутизаторы
- шлюзы сеансового уровня
- шлюзы уровня приложений
Эти категории можно рассматривать как базовые компоненты реальных
межсетевых экранов. Лишь немногие МЭ включают лишь одну из
перечисленных
категорий. Тем не менее эти компоненты отражают ключевые возможности,
отличающие межсетевые экраны друг от друга.
Фильтрующий маршрутизатор представляет собой маршрутизатор или
работающую на сервере программу, сконфигурированную таким
образом,
чтобы фильтровать входящие и исходящие пакеты. Фильтрация пакетов
осуществляется на основе информации, содержащейся в TCP- и IP-
заголовках пакетов. Фильтрующий маршрутизатор обычно может
фильтровать IP-пакты на основе группы следующих полей заголовка
пакта:
- IP-адрес отправителя
- IP-адрес получателя
- порт отправителя
- порт получателя
МЭ с фильтрацией пакетов, работающий только на сетевом уровне модели
OSI-ISO, обычно проверяет информацию, содержащуюся только в
IP-заголовках пакетов. Следовательно подделав данный заголовок, что
технически сделать достаточно просто, можно создать пакет
удовлетворяющей политики сетевой безопасности настроенной в данном МЭ.
К положительным качествам фильтрующих маршрутизаторов можно отнести:
- сравнительно невысокую стоимость
- гибкость в определении правил фильтрации
- небольшую задержку при прохождении пакетов
Недостатками фильтрующих маршрутизаторов являются:
- внутрення сеть видна (маршрутизируется) из сети Internet
- правила фильтрации пакетов трудны в описании и требуют очень
хороших знаний технологий функционирования семейства протоколов TCP/IP
- при нарушении работоспособности МЭ с фильтрацией пакетов все
компьютеры за ним становятся полностью незащищенными либо недоступными
- аутентификацию с использованием IP-адреса можно обмануть путем
подмены IP-адреса (атакующая система выдает себя за другую, используя
ее
IP-адрес)
- отсутствует аутентификация на пользовательском уровне
Шлюзы сеансового уровня представляет собой транслятор TCP-соединения.
Этот шлюз принимает запрос авторизованного клиента на конкретные услуги
и после проверки допустимости запрошенного сеанса устанавливает
соединение с местом назначения (внешним хостом). После этого шлюз
копирует пакеты в обоих направлениях, не осуществляя из фильтрации. Как
правило, пункт назначения задается заранее, в то время как источников
может быть много. Используя различные порты, можно создавать различные
конфигурации соединений. Данный тип шлюза позволяет создать транслятор
TCP-соединения для любого определенного пользователем сервиса,
базирующегося на TCP, осуществлять контроль доступа к этому сервису и
сбор статистики по его использованию.
Важным фактом работы данного вида МЭ является то, что после
установления связи, дальнейший поток пакетов не контролируются МЭ, то
есть фильтрация проводиться только на сеансовом уровне модели OSI,
содержимое пакетов, передаваемых между внутренней и внешней сетью на
уровне прикладных программ не производится. Для того чтобы фильтровать
пакеты, генерируемые определенными сетевыми службами, в соответствии с
их содержимым необходим шлюз прикладного уровня.
С целью защиты ряда уязвимых мест, присущих фильтрующим
маршрутизаторам, МЭ должны использовать прикладные программы для
фильтрации соединений с определенными службами. Подобное приложение
называется уполномоченным (или proxy-службой), а хост, на котором
работает proxy-служба - шлюзом уровня приложений (прикладным шлюзом).
Шлюз уровня приложений исключает прямое взаимодействие между
авторизованным клиентом и внешним компьютером. Шлюз фильтрует все
входящие и исходящие пакеты на прикладном уровне. Обнаружив сетевой
сеанс, шлюз приложений останавливает его и вызывает уполномоченное
приложение для оказание запрашиваемой услуги. Для достижения более
высокого уровня безопасности и гибкости шлюзы уровня приложений и
фильтрующие маршрутизаторы могут быть объединены в межсетевом экране.
Шлюзы прикладного уровня позволяют обеспечить надежную защиту,
поскольку взаимодействие с внешним миром реализуются через небольшое
число уполномоченных приложений, полностью контролирующих весь входящий
и исходящий трафик. Следует отметить, что шлюзы уровня приложений
требуют отдельного приложения для каждого сетевого сервиса.
Шлюзы прикладного уровня имеют ряд преимуществ по сравнению с
работающими в обычном режиме, при котором прикладной трафик
пропускается
непосредственно к внутренним компьютерам:
- невидимость структуры защищаемой сети из глобальной сети
Internet. Имена внутренних систем можно не сообщать внешним системам
через DSN, поскольку шлюз прикладного уровня может быть единственным
хостом, имя которого должно быть известно внешним системам
- надежная аутентификация и регистрация. Прикладной трафик может
быть аутентифицирован, прежде чем он достигнет внутренних хостов, и
зарегистрирован более эффективно, чем с помощью стандартной регистрации
- приемлимое соотношение цены и эффективности. Дополнительные
программные или аппаратные средства аутентификации или регистрации
нужно
устанавливать только на шлюзе прикладного уровня
- простые правила фильтрации. Правила на фильтрующем маршрутизаторе
оказываются менее сложными, чем на маршрутизаторе, который
самостоятельно фильтровал бы прикладной трафик и отправлял его большому
числу внутренних систем. Маршрутизатор должен пропускать прикладной
трафик, предназначенный только для шлюза прикладного уровня, и
блокировать весь остальной
- возможность организации большого числа проверок. Защита на уровне
приложений позволяет осуществлять большое количество дополнительных
проверок, что снижает вероятность взлома с использованием "дыр" в
программном обеспечении
К недостаткам шлюзов уровня приложений отностятся:
- относительно низкая производительность по сравнению с
фильтрующими маршрутизаторами. В частности, при использованиии
клиент-серверных протоколов, требуется двушаговая процедура для входных
и выходных соединений
- более высокая стоимость по сравнению с фильтрующими
маршрутизаторами
Основные схемы сетевой защиты на базе межсетевых экранов
При подключении АС к глобальным сетям администратор сетевой
безопасности должен решать следующие задачи:
- защита АС от несанкционированного удаленного доступа со стороны
глобальной сети
- cкрытие информации о структуре сети и ее компонентов от
пользователей глобальной сети
- разграничение доступа в защищаемую сеть из глобальной и из
защищаемой в глобальную
Необходимость работы с удаленнми пользователями требует установления
жестких ограничений доступа к инфомационным ресурсам защищаемой сети.
При этом в организации часто возникает потребность иметь в составе АС
несколько сегментов с разными уровнями защищенности:
- свободно доступные сегменты
- сегменты с ограниченным доступом
- закрытые сегменты
Для защиты АС применяются следующие основные схемы организации МЭ:
- МЭ - фильтрующий маршрутизатор
- МЭ на основе двупортового шлюза
- МЭ на основе экранированного шлюза
- МЭ - экранированная подсеть
4.5.2 Виртуальные частные сети
Один из способов защититься от "прослушивания" данных АС, передаваемых
через публичне сети - применение виртуальных частных сетей.
Виртуальные частные сети (Virtual Private Networks - VPN) предназначены
для безопасного обмена данными между удалёнными пользователями и
удалёнными друг от друга ЛВС. Основным компонентом VPN являются
криптографические устройства, располагаемые на шлюзах АС. Возможны
следующие варианты реализации VPN:
- На основе межсетевых экранов. Преимущество данного метода
заключается в том, что для защиты потоков данных всех узлов каждой ЛВС
используется только один программно-аппаратный комплекс.
- На основе специальной службы, встроенной в операционную систему
сетевых узлов. Это самый доступный вариант, однако для защиты самих
узлов всё равно необходим межсетевой экран
- На основе специальных криптографических шлюзов между внутренними
сетями и сетью общего пользования. Системы такого типа отличаются
высокой производительностью, не требуют сложного администрирования, но
в
то же время относительно дороги
Но необходимо помнить, что VPN активно используют в работе такие
приёмы как инкапсуляция защищёного протокола в существующие и
шифрование
данных, поэтому технология VPN не подходит:
- Когда чрезвычайно важна производительность
- Когда задержка во времени не приемлема
- Когда используются нестандартные протоколы, крирпые невозможно
инкапсулировать в собственный протокол Интернета (IP)
- Когда используется изохронный трафик, например телефон.
4.5.3 Сканеры безопасности
Периодически необходимо проводить полный анализ общего состояния
вычислительной сети предприятия. Средства анализа защищённости
(security
scanners) выполняют серию тестов по обнаружению уязвимостей,
аналогичных
тем, которые применяют злоумышленники при подготовке и осущствлении
атак
на корпоративные сети. Поиск уязвимостей как правило основывается на
базе знаний сканнера, которую надо периодически обновлять на предмет
новых атак. Как правило сканирование начинается со сбора информации об
открытых портах и доступных сервисов внутри сети. После этого
начинаются
проверки обнаруженных сервисов на известные атаки.
Финкционировать подобные средства могут как на сетевом
уровне(тестирование сетевых протоколов), на уровне приложений
(тестирование протоколов высокого уровня).
4.5.4 Средства обнаружения атак
Эти средства как правило осуществляют действия обратные действиям
сканеров. Основной их приём работы - выявление подозрительной
активности
на основе статистических данных. Средства обнаружения могут
осуществлять
оперативный (в режиме реального времени) контроль всего сетевого
траффика, проходящего через защищаемый сегмент сети, а также
постоянный анализ системного журнала на предмет частоты появления
новых сообщений. Задача подобных средств дать немедленный сигнал
администратору об опасности и ,возможно, предпринять автоматически
какие-то меры защиты, например полное закрытие всех шлюзов от траффика
приходящего с определённого узла. Недостатком подобных средств как и
всяких средств основанных на статистике - достаточно высокая
вероятность
ложных срабатываний на начальном этапе эксплуатации. Возможны
следующие варианты установки средств обнаружения:
- В демилитаризованной зоне, между шлюзом и внутренней сетью.
Средство будет действовать как дополнительная защита периметра
внутренней сети
- Перед межсетевым экраном, снаружи во внешней сети. При таком
размещении становится возможным контролировать корректность
функционирования межсетевого экрана и гарантировать невозможность
обходных путей во внутреннюю сеть.
- В ключевых сегментах корпоративной сети (внутри). Например на
главной сетевой магистрали для контроля межсегментного траффика или
сразу после модемной стойки для защиты от НСД к сети по коммутируемым
каналам.
4.6 Криптографические средства
Аппаратно-программные средства, обеспечивающие повышенный уровень
защиты информации, можно разделить на следующие группы:
- средства обеспечения конфиденциальности данных
- средства идентификации и аутентификации пользователей
- средства аутентификации электронных данных
- средства управления ключевой информацией
Обеспечение конфиденциальности данных осуществляют путем их шифрования
с использованием симметричных и асимметричных алгоритмов шифрования.
В группу средств, обеспечивающих защиту конфиденциальности данных,
входят системы шифрования дисковых данных и системы шифрования данных,
передаваемых по компьютерным сетям. Основная задача, решаемая такими
системами, состоит в защите от несанкционированного использования
данных.
Обеспечение конфиденциальности данных, располагаемых на дисковых
магнитных носителях, осуществяется путем их шифрования с использованием
симметричных алгоритмов шифрования. Основным классификационным
признаком
для комплексов шифрования служит уровень их встраивания в компьютерную
систему.
Работа прикладных программ с дисковыми накопителями состоит их двух
этапов - "логического" и "физического". Логический этап соответствует
уровню взаимодействия прикладной программы с операционной системой
(например, вызов сервисных функций чтения/записи данных). На этом
уровне
основным объектом является файл. Физический этап соответствует уровню
взаимодействия операционной системы и аппаратуры. В качестве объектов
этого уровня выступают структуры физической организации данных - сектор
диска.
Системы шифрования данных могут осуществлять криптографические
преобразования данных на уровне файлов (защищаются отдельные файлы) и
на
уровне дисков (защищаются диски целиком).
Другим классификационным признаком систем шифрования дисковых даных
является способ из функционирования . По способу функционирования
системы шифрования дисковых данных делят на два типа:
- системы прозрачного шифрования
- системы, специального вызываемые для осуществления шифрования
В системах прозрачного шифрования криптографические преобразования
осуществляются в режиме реального времени, незаметно для пользователя.
Например, пользователь записывает подготовленный в текстовом редакторе
документ на защищаемый диск, а система защиты в процессе записи
выполняет шифрование файла.
Системы второго типа обычно представляют собой утилиты, которые
необходимо специально вызывать для выполнения шифрования. К ним
относятся, например, архиваторы со встроенными средствами парольной
защиты.
Системы шифрования данных, передаваемых по компьютерным сетям,
различаются по реализации и своим характеристикам в зависимости от
используемого рабочего уровня модели взаимодействия открытых систем
(модель OSI). Для передачи защищенных шифрованием данных в принципе
могут быть использованы канальный, сетевой, транспортный, сеансовый,
представительный или прикладной уровени модели OSI.
В случае канального шифрования защищается вся передаваемая по каналу
связи информация, включая служебную. Этот способ шифрования обладает
слудующим достоинством: встраивание процедур шифрования на канальный
уровень позволяет использовать аппаратные средства, что способствует
повышению производительности системы. Однако у данного подхода имеются
существенные недостатки:
- шифрование на канальном уровне всей информации, включая
служебные
данные транспортных протоколов, осложняет механизм маршрутизации
сетевых
пакетов и требует расшифрования данных в устройствах промежуточной
коммутации (шлюзах, ретрансляторах и т.п.)
- шифрование служебной информации может привести к появлениею
статистических закономерностей в шифрованных данных; это влияет на
надежность защиты и накладывает ограничения на использование
криптографических алгоритмов
Шифрование передаваемых данных на сетевом уровне в настоящее время
регламентируется новым протоколом IPSec, предназначенным для
аутентификации, туннелирования и шифрования IP-пакетов.
Стандартизиванный консорциумом Internet Engineering Task Force (IETF)
протокол IPSec вобрал в себя все лучшие решения по шифрованию пакетов и
должен войти в качестве обязательного компонента в протокол IPv6.
Протокол IPSec предусматривает не только стандартные способы
использования шифрования конечными точками виртуального туннеля, но и
стандартные методы идентификации пользователй или компьютеров при
инициации туннеля, а также стандартные методы обмена и управления
ключами шифрования между конечными точками. Шифрование передаваемых
данных на транспортном уровне осуществляется, в сущности, шифраторами,
которые зачастую привязаны к единственному приложению, например
электронной почте. Наиболее известными из таких протоколов являются
SMTP
over Transport Layer Security, Secure Shell и т.д.
Некоторые виртуальные частные сети используют подход под названием
"посредники каналов" (circuit proxy). Этот метод функционирует над
транспорнтым уровнем и ретранслирует трафик из защищенной сети в
общедоступную сеть Internet для каждого сокета в отдельности (сокет IP
идентифицируется комбинацией TCP-соединения и конкретного порта или
заданным портом UDP). Стек TCP/IP не имеет пятого - сеансовго - уровня,
однако ориентированные на сокеты операции часто называют операциями
сеансового уровня. Шифрование информации, передаваемой между
инициатором
и терминатором тунеля, часто осуществляется с помощью защиты
транспортного уровня TLS (Transport Layer Security) ранее протокола
защищенных сокетов SSL. Для стандартизации аутентифицированного прохода
через межсетевые экраны консорциум IETF определил протокол под
названием
SOCKS, и в настоящее время протокол SOCKS v.5 применяется для
стандартизованной реализации посредников каналов.
Оконечное (абонентское) шифрование позволяет обеспечить
конфиденциальность данных, передаваемых между двумя прикладными
объектами (абонентами). Оконечное шифрование реализуется с помощью
протокола прикладного или представительного уровня эталонной модели
OSI.
В этом случае защищенным оказывается только содержание сообщения; вся
служебная информация остается открытой. Данный способ позволяет
избежать
проблем, связанных с шифрованием служебной информации, но при этом
возникают другие проблемы. В частности, злоумышленник, имеющий доступ к
каналам связи компьютерной сети, получает возможность анализировать
информацию о структуре обмена сообщениями, например об отправителе и
получателе, о времени и условиях передачи данных, а также об объеме
передаваемых данных.
Системы идентификации и аутентификации пользователей применяются для
ограничения доступа случайных и незаконных пользователей к ресурсам
комьютерной системы. Общий алгоритм работы этих систем заключается в
том, чтобы получить от пользователя информацию, удостоверяющую его
личность, проверить ее подлинность и затем предоставить (или не
предоставить) этому пользователю возможность работы с системой.
При построении подобных систем возникает проблема выбора информации, на
основе которой осуществляются процедуры идентификации и аутентификации
пользователя. Можно выделить слудующие типы:
- секретная информация, которой обладает пользователь (пароль,
персональный идентификатор, секретный ключ и т.п.). Эту информацию
пользователь должен запомнить, или же могут быть применены специальные
средства ее хранения
- физиологические параметры человека (отпечатки пальцев, рисунок
радужной оболочки глаза и т.п.) или особенности поведения человека
(особенности работы на клавиатуре компьютера и т.п.).
Системы идентификации, основанные на первом типе информации, принято
считать традиционными. Системы идентификции, использующие второй тип
информации, называются биометрическими. Следует отметить наметившуюся
тенденцию опережающего развития биометрических систем идентификации.
При обмене электронными данными по сетям связи возникает проблема
аутентификации автора документа и самого документа, то есть
установление
подлинности автора и проверки отсутствия изменений в полученном
документе.
Для аутентификации электронных данных применяют код аутентификации
сообщения (имитовставку) или электронную цифровую подпись. При
формировании кода аутентификации сообщения и электронной цифровой
подписи используются разные типы систем шифрования.
Код аутентификации сообщения формируют с помощью симметричных систем
шифрования данных. В частности, симметричный алгоритм шифрования данных
DES при работе в режиме сцепления блоков шифра CBC позволяет
сформировать с помощью секретного ключа и начального вектора IV код
аутентификации сообщения MAC (Message Authenication Code). Проверка
целостности принятого сообщения осуществляется путем проверки кода MAC
получателем сообщения.
Аналогичные возможности предоставляет отечественный стандарт
симметричного шифрования данных ГОСТ 28147-89. В этом алгоритме
предусмотрен режим выработки имитовставки, обеспечивающий имитозащиту,
то есть защиту систмы шифрованной связи от навязывания ложных данных.
Имитовставка вырабатывается их открытых данных посредством специального
преобразования шифрования с использованием секретного ключа и
передается
по каналу связи в конце зашифрованных данных. Имитовставка проверяется
получателем сообщения, владеющим секретным ключом, путем повторения
процедуры, выполенной ранее отправителем, над полученными открытами
данными.
Электронная цифровая подпись представляет собой относительно небольшое
количество дополнительнрой аутентифицирующей цифровой информации,
передаваемой вместе с подписываемым текстом.
Для реализации ЭЦП используются принципы асимметричного шифрования.
Система ЭЦП включает процедуру формирования цифровой подписи
отправителем с использованием секретного ключа отправителя и процедуру
проверки подписи получателем с имспользованием открытого ключа
отправителя.
Под ключевой информацией понимается совокупность всех используемых в
компьютерный системе или сети криптографических ключей.
Безопасность любого криптографического алгоритма определяется
используемыми криптографическими ключами. В случае ненадежного
управления ключами злоумышленник может завладеть ключевой информацией и
получить полный доступ ко всей информации в компьютерной системе или
сети.
Основным классификационным признаком средств управления ключевой
информацией является вид функции управления ключами. Различают
следующие
основные виды функций управления ключами: генерация, хранение и
распределение ключей.
Способы генерации ключей различаются для симметричных и асимметричных
криптосистем. Для генерации ключей симметричных криптосистем
используются аппаратные и программные средства генерации случайных
чисел, в частности схемы с применением блочного симметричного алгоритма
шифрования. Генерация ключей для асимметричных криптосистем
представляет
существенно более сложную задачу ввиду необходимости получения ключей с
определенными математическими свойствами.
Функция хранения ключей предполагает организацию безопасного хранения,
учета и удаления ключей. Для обеспечения безопасного хранения и
передачи
ключей применяют их шифрование с помощью других ключей. Такой подход
приводит к концепции иерархии ключей. В иерархию ключей обычно входят
главный ключ (мастер-ключ), ключ шифрования ключей и ключ шифрования
данных. Следует отметить, что генерация и хранение мастер-ключей -
критические вопросы криптографической защиты.
Распределение ключей является самым ответственным процессом в
управлении ключами. Этот процесс должен гарантировать скрытность
распределяемых ключей, а также оперативность и точность их
распределения. Различают два основных способа распределения ключей
между
пользователями компьютерной сети:
- применение одного или нескольких центров распределения ключей
- прямой обмен сеансовыми ключами между пользователями
4.7 Безопасность и производительность системы
Ни в коем случае нельзя забывать что любые средства защиты вносят
дополнительные проверки во время работы системы.Кроме того из-за
перестраховки некоторые действия могут выполняться несколько раз.
Например, при удалении файла он будет перезатёрт и переименован
нескольно раз. Очевидное следствие этого - падение производительности
системы. Избавиться от этого невозможно. Либо вы получаете надёжную
систему, перепроверяющей всё подряд (пересчёт контрольных сумм по всей
системе тоже отнимает часть её ресурсов) или высокопроизводительную, но
не тратящую лишнее время на проверки. Не ждите также комфортной работы
от защищённой системы. Основной принцип любой защиты состоит в
минимизации полномочий. Хорошо защищённая система будет давать отказ по
любым попыткам действий выходящих по её мнению за рамки ваших
должностных обязанностей. Более того будут запротоколированы все ваши
попытки получить доступ (даже случайно) к чужому ресурсу. Все
защищённые
АС узко направлены на выполнение определённых задач. Странно требовать
от кассового аппарата игры в пасьянс.
4.8 Интеграция сервисов безопасности с ПО
Как правило система защиты помещается в ядро операционной системы для
организации надёжного и полного контроля информационных пакетов.
Эта схема имеет тот недостаток, что ядро знает
слишком
мало о контексте выполняемой задачи. Если все происходящие в системе
процессы рассматривать как конечные автоматы, то количество различных
состояний высокоуровненой задачи значительно превышает количество
возможных состояний этой же задачи рассматриваемой как процесс. Из-за
этого может быть не полностью решена задача минимизации полномочий. ОС
не в состоянии распознать в какие моменты времени доступ к каким
объектам требуется задаче. Все тем не менее высокоуровневые задачи
можно разбить на некоторое число атомарных низкоуровневых задач. Если
теперь приложению потребуется переключиться с одной задачи на другую,
то оно просто сообщит об этом подсистеме безопасности, та в свою
очередь переключит её контекст и соответственно изменит права доступа.
Приожение как бы "подсказывает" о своих пожеланиях. Система
безопасности естественно смотрит является ли очередное желание из числа
допустимых.
Всё это хорошо,но подходить к этому надо чрезвычайно осторожно.
Необходимо помнить, что любое приложение это конечный автомат более
высокого уровня чем процесс и соответственно оно "помнит" гораздо
больше
данных. Таким образом возникает канал возможной утечки информации.
Например, текстовый редактор читающий секретные файлы может "запомнить"
что-то внутри себя, переключиться на чтение нескретных файлов и
перебросить туда то, что запомнил. Поэтому технологию самостоятельного
переключения контекста приложения можно делать только после детальной
проверки кода. Даже если с кодом всё в порядке, необходимо проверить
наличие тайных каналов, поскольку сервер одновременно будет работать в
нескольких ролях возможны нежелательные "наводки".
Вот пример где можно сделать переключение (после проверки кода на
наличие тайных и явных каналов). Когда http сервер Apache работает с
разными виртуальными сайтами есть смысл переключать роли, дабы
при
атаке на сервер принципиально не было возможно получить доступ к
контенту других сайтов.
Ещё один аспект демонстрирующий необходимость интегрировать сервисы
безопасности с програмным обеспечением. Как правило, стремятся внедрить
защиту без сильной переработки уже существующего программного
обеспечения. Более серьёзные модели безопасности чаще всего требуют
наличия дополнительных аттрибутов на субъектах и объектах. Старое
приложение может запросто "потерять" расширенные аттрибуты (например
переименовав временный файл в окончательный) изменив непредсказуемым
образом состояние системы. Поэтому при разработке нового защищённого
решения надо критически относится к уже существующим наработкам и
перепроверять всё их взаимодействие с окружающеё системой. Целый ряд
примеров такого рода будет вриведён в следующем разделе.
Ещё один аспект где необходимо слияние с системой безопасности - это
подсистема управления. Подсистема централизованного управления по всей
АС должна знать и учитывать все дополнительные аттрибуты безпасности.
Немаловажно чтобы централизованный пульт управления АС был не только у
администратора системы, но и у администратора безопасности.
5. Проблемы существующих решений
Человеству свойственно стремиться к повторному использованию
накопленного опыта. Вопросу о том можно ли использовать какие
существующие решения в новом контексте посвящён этот раздел. Как
правило
все современные технологии, которые хотелось бы модернизировать,
используют клиент-серверную архитектуру. Однако с точки зрения этой
архитектуры при использовании мандатных меток (мандатный доступ
приводится в качестве примера, любые нелинейные иерархии будут иметь те
же самые проблема) есть следующие проблемы:
- Все существующие протоколы передачи информации не годятся
для достоверной передачи вместе с информацией её метки защиты. Всё
теряется при передаче. Это понятно, на заре становления коммуникаций
пропускная способность каналов оставляла желать лучшего и засорять
канал
какими-либо ненужными большинству пользователей данными смысла не было.
- Сервер одновременно обсуживает множество пользователей,
соответсвенно работает с данными разного уровня секретности, поэтому он
вынужден иметь максимальный доступ к данным и становится слабым
звеном и потенциальным местом утечки информации.
- Недостаточный уровень доверия между клиентом и сервером. По жизни
получается что сервер всегда прав, он может принимать/обрабатывать
запросы с любыми метками безопасности(сервер печати/сервер для отправки
почты). А вот клиенту(особенно удалённому) доверять нельзя, очень
сложно
доказать что он работает с той меткой безопасности какой сообщает(Web
браузер/почтовые клиенты).
5.1 Система печати с поддержкой вывода грифованной информации
Первое на что надо обратить внимание эта система уже не может
рассматриваться как чисто программная, это скорее программно-аппаратное
решение. Аппаратная часть представлена устройством печати. Чрезвычайная
интеллектуальность современных периферийных устройств значительно
усложняют обеспечение безопасности в плане повторного использования
объектов. Действительно, принтер может буферизовать несколько страниц
документа, (а при нынешних объёмах памяти может запросто поместиться и
весь документ целиком) которые останутся в памяти даже после окончания
печати. Нет никакой гарантии, что следующее задание на печать при
помощи некоторой специальной последоаптельности "вытолкнут" их оттуда.
Даже если приставить стража прямо к принтеру он не заметит утечки
информации. В файлах протокола, понятное дело, также не будет отмечено
никакой подозрительной активности. Отсюда первое ограничение: нельзя
использовать один и тот же принтер для вывода данных разной степени
секретности.
Ещё один момент - вывод документа на бумагу, по сути преобразование
информации приводящее к потере грифа. Например его можно отсканировать,
переведя тем самым снова в электронную форму но уже с другой меткой.
Единожды распечатанный документ уже не подлежит строгой защите со
стороны информационной системы. Если файл рассматривать как контейнер
данных, то говоря образно "деньги ещё в сейфе, но его уже открыли и их
пересчитали". Отсюда второе ограничение: гарантировать защиту для
системы электронного грифованного документооборота можно только при
обязательном применении мер административного характера.
Предположим, что все условия, перечисленные выше, выполнены. Какие ещё
остаются проблемы при попытке перевести грифованный документооборот в
электронную форму? Простая попытка переноса мандатных меток файлов на
твёрдую копию бесмыслена.
Документ это объект более высокого уровня нежели файл потому что:
- он может иметь различные метки секретности на разных своих
участках: одна глава может быть секретной, параграф другой
главы совершенно секретным, а введение несекретным.
- он содержит ряд дополнительной информации такой как: история
изменений документа (с датами и данными на исполнителя),
регистрационный номер, категория секретности (при однородности
содержимого по секретности). Причём часть информации может быть
заключена в формат документа (изменения, категория), а часть вынуждена
храниться отдельно (регистрационный номер подразумевает доверенной
системы выдачи этих номеров)
Работа с документами обязательно сопровождается использованием
клиент-серверной архитектуры поскольку принтер чаще всего разделяемый
по
всей АС ресурс. Кроме того нормальным считается выстраивание оступающих
запросов в очередь. Если от второго можно избавиться, то наличия
сервера
печати не избежать. Связанные с этим проблемы подробно объяснены ранее.
Исходя из перечисленного мы вынуждены реализовать как минимум следующие
подсистемы:
- регистрации документов и контроля их изменений
- раздельные системы печати документов разной категории секретности.
- надёжное средство просмотра и редакторования (при чтении
документа происходит преобразование инфморации в символьный вид со
всеми
проблемами связанными с этим)
- надёжное хранилище (которое впрочем может быть и локальным на
машине пользователя)
- база дополнительных должностных сведений о пользователях.
- протоколы надёжной передачи меток между разными системами: от
редактора в систему регистрации, от системы регистрации в систему
печати и т.д.
Отметим, что это минимальный набор без системы совместной работы
над документом.
Всё перечисленное наводит на мысль о том что система защиты ОС вроде
как нигде не участвует. Однако это не так: ОС как доверенная основа
обеспечивает:
- во время работы пользователя над документом защиту от
просмотра документа процессами не имеющими соответствующих
полномочий
- защиту файлов, контейнеров документов от несанкционированного
просмотра во время хранения в случае множественных категорий
внутри документа файл будет иметь максимальную метку. Немаловажным
является защита документов со стороны системы во время хранения в
очереди на печать. Очередь должна иметь такую же метку защиты как и
находящиеся в ней документы. Очередь не может содержать файлы разного
уровня секретности. По какой-нибудь программной ошибке они могут уйти
на
печать как один документ. Хотя принтер работает только с одним уровнем
безопасности к одной машине может быть подключено несколько принтеров и
кроме того всегда есть масса других служебных процессов, которым не
стоит иметь доступ к документам. Пока данные не покинули систему она
должна их защищать.
- доверенное сопоставление пользователя и его метки доступа.
- надёжное удаление документа с магнитного носителя
Итого: требуется обязательная переработка существующих системы печати и
обработки документов; без привлечения административных мер никак
обойтись не получится.
5.2 Электронная почта с поддержкой пересылки грифованной информации
Случай электронной почты несравненно более сложный чем это было со
службой печати. Во-первых, если в системе печати информация идёт в
большинстве случаев по локальной сети, то почта перемещается по
глобальной сети. Кроме того, если в системе печати происходит
одноноправленное преобразование информации в печатную форму, то письмо
изменив свой формат из файла в поток данных некоторого протокола снова
должно быть восстановлено в файл с точно такими же ограничениями
доступа.
Чтобы упростить себе задачу не будем считать письмо документом. Как
было указано в предыдущем разделе грифованный документ это достаточно
сложная структура, которая добавляет ещё целый веер проблем.
Давайте последовательно просмотрим жизненный цикл письма и все
возникающие с этим проблемы. Пусть изначально письмо представляет собой
некоторый файл с некоторой мандатной меткой. Пока он ещё надёжно
защищается локальной службой безопасности системы. Когда пользователь
желает передать файл он сначала выбирает адресата. Вот и первая
проблема
- адресат должен иметь доступ к информации данного грифа. Должна быть
какая-то доверенная общая база, где указано кто какие права доступа
имеет. База должна регулярно проверятся на валидность на предмет
соответствия прав пользователя в системе, где он работает, и запись в
базе. Тут не обойтись без централизованной системы администрирования.
Уже на этом этапе хорошо бы использовать электронную подпись и
шифрование с открытым ключом чтобы с одной стороны письмо дошло до того
кому предназначено и с другой стороны оно пришло от того кого
ожидается.
Доступ к базе также должен осуществлятся по закрытому каналу так как
она
должна быть глобальной.
Итак отправитель получает возможность (например некий одноразовый
ключ(билет) на данную пересылку, всё это также надо поддерживать
криптографичесеи) отправить письмо другому пользователю. Письмо
передаётся smtp серверу и ставится в очередь Случай электронной почты
несравненно более сложный чем это было со службой печати. Во-первых,
если в системе печати информация идёт в большинстве случаев по
локальной
сети, то почта перемещается по глобальной сети. Кроме того, если в
системе печати происходит одноноправленное преобразование информации в
печатную форму, то письмо изменив свой формат из файла в поток данных
некоторого протокола снова должно быть восстановлено в файл с точно
такими же ограничениями доступа.
Чтобы упростить себе задачу не будем считать письмо документом. Как
было указано в предыдущем разделе грифованный документ это достаточно
сложная структура, которая добавляет ещё целый веер проблем.
Давайте последовательно просмотрим жизненный цикл письма и все
возникающие с этим проблемы. Пусть изначально письмо представляет собой
некоторый файл с некоторой мандатной меткой. Пока он ещё надёжно
защищается локальной службой безопасности системы. Когда пользователь
желает передать файл он сначала выбирает адресата. Вот и первая
проблема
- адресат должен иметь доступ к информации данного грифа. Должна быть
какая-то доверенная общая база, где указано кто какие права доступа
имеет. База должна регулярно проверятся на валидность на предмет
соответствия прав пользователя в системе, где он работает, и запись в
базе. Тут не обойтись без централизованной системы администрирования.
Уже на этом этапе хорошо бы использовать электронную подпись и
шифрование с открытым ключом чтобы с одной стороны письмо дошло до того
кому предназначено и с другой стороны оно пришло от того кого
ожидается.
Доступ к базе также должен осуществлятся по закрытому каналу так как
она
должна быть глобальной.
Итак отправитель получает возможность (например некий одноразовый
ключ(билет) на данную пересылку, всё это также надо поддерживать
криптографичесеи) отправить письмо другому пользователю. Письмо
передаётся smtp серверу и ставится в очередь на оправку. Очередь писем
должна быть разделена по меткам безопасности соответствующим письмам и
хранится в системе в соответсвующем виде. Хотя письма и защищены
криптографически не ровён час их расшифруют, поэтому пока письмо не
покинуло систему его метка безопасности должна сохранится.
Когда письмо готово покинуть сервер, последний связывается со службой
DNS на предмет MX, то есть адреса того сервера который обслуживает
почту
данного домена. Либо протокол должен поддерживать метку доступа
(стандартный протокол конечно же этого не делает) либо надо эту метку
инкапсулировать в письмо причём защищённым образом (с применением
шифрования) чтобы не могла произойти подмена метки во время пути.
Маршрут письма совершенно не определён. Всегда надо быть готовым что
письмо канет в небытие. Злоумышленник может подсунуть ложную запись
DNS,
спровоцировать DOS для принимающего сервера, попытаться подсунуть
вместо
данного письма совсем другое.
Предположим, что наконец целевой smtp сервер готов принять письмо.
Необходимо провести ещё раз проверку валидности данной пересылки
(например нет ли попытки воспользоваться устаревшим билетом) далее
необходимо восстановить метку письма (или из метки сохранённой в самом
письме или из протокола). Далее всё повторяется в обратном порядке.
Получатель письма может получить его либо локально на сервере либо
через один из протоколов доступа к почтовому ящику(POP3, IMAP4).Письма
в
почтовом ящике должны быть разложены по нескольким ящикам согласно
меткам безопасности. Протокол POP сразу забирает весь почтовый ящик
целиком, поэтому гарантированно происходит потеря меток. Протокол IMAP
следует расширить чтобы после передачи письма, локальная копия имела бы
правильную метку безопасности. В любом из этих методов возникает
прблема
доверия клиентскому ПО, описанная в начале раздела. Самый лучший
способ - не заниматься более повторными пересылками, а читать
сообщения прямо сразу на сервере.
Интересно, что если получатель пожелает ответить на письмо, ответ
автоматически получит тот же гриф ибо файл почтового ящика
"сообщит" сразу верную метку.
Итого: как и в случае с системой печати требуется переработка всей
существующей инфрастуктуры электронной почты. При этом совершенно
невозможно обойтись без применения самых современных методов шифрования
информации. Шифрование играет в данном случае ключевую роль фактически
инкапсулируя защищённый протокол внутрь стандартного. Немаловажно,
также, что сложно организовать надёжнвый приём почты через протоколы
POP3 и IMAP4. Лучше всего читать почту локально.
5.5 Проблемы обработки грифованного контента в случае использования
Web-технологий.
На текущий момент существует множество технологий организации
документооборота на базе различных Web-технологий. Отчасти это
обусловленно тем, что встроенное программное обеспечение в ряде
операционных систем для просмотра HTTP-файлов достаточно просто в
использовании, получило глобальное распространение, имеет
децентрализованную структуры, а также достаточно просто интегрируется в
различные как наследуемые так и вновь создаваемые программные комплексы
обработки данных. К сожалению при проектировании существующих
Web-технологий проблема безопасности не стояла на первом месте и как
следствие использование данных средств при обработке данных с
различными метками безопасности не может быть обеспечена. Также
существует факт того, что использование одних и тех же средств как в
среде Internet (доступ к публичным, не классифицированным с точки
зрения информации, ресурсам) так и в рамках внутренненого
документооборота в рамках автоматизированных систем не сколько
ослажнено, сколько невозможно. Как следствие необходимо разрабатывать
ряд программных комплексов реализующих все возможности Web-технолгий с
дополнительным учетом всех вопросов безопасности и обработки информации
с разными метками конфиденциальности. Ниже представлен перечень
проблемных областей функционирования Web-технологий с точки зрения
обработки информации содержащих классифицированную по степени
секретности информуцию:
- Web-сервер как достаточно простое с технической точки зрения
программное обеспечение не производит ни какого контроля по линии
информациионой безопасности содержимого файлов которые он передает
пользователю. Максимум, что он может сделать это ограничить доступ к
ресурсам и в случае необходимости обеспечить шифрование (с
использованием внешней крипто-библиотеки). Как видно данного факта
контроля недостаточно для использования в случае если не вся
информация, а ряд ее частей (параграфов, приложений, абзацев, глав)
имеют разные степени конфиденциальности.
- Web-browser (устоявшегося перевода на русский язык нет) -
средство просмотра http-файлов также не прозводит ни какого контроля
над содержимым с точки зрения информационной безопасности файла или его
частей. Web-browser передал запрос на доступ к информации (http-файлу),
Web-сервер выполнил запрос, Web-browser отобразил пользователю. Если
немножко усложнить то в действительности есть механизмы ограничения
доступа на стороне Web-сервер (объясненно в ранее) и ряд механизмов
криптопреобразований (шифрования) передаваемой информации. Это может
закрыть передачу по сети, выполнить ряд мер по журналированию
обращений, заблокировать обращения с ряда компьютеров,в нашем же случае
данных механизмов недостачно.
- Все что выше представлено объясняет только верхушку айсберга
проблем использование данных, наследуемых, Web-технологий без
координальной переделки не только программного обеспечения, но и самого
главного - всей технолгии работы в целом. В качестве примера можно
привести возможность обработки не только статического контента
Web-сервер (статические не изменяемые файлы, хранимые на жестком диске,
передаваемые Web-browser'у на запрос), но и обработки динамического
контента, когда информация передаваемая на запрос зависит не только от
самой информации, но и от информации передаваемой пользователем,
времени обращения, наличием информации в ряде баз данных или передача
изображений с фото-, видео-камер (или иных датчиков)в режиме реального
времени. Как видим тут сразу появляется ряд проблем как обеспечить
доступ к данным в СУБД (если там могут использоваться другие метки
безопасности, отличные от тех которые передал пользователь
Web-browser'у/Web-серверу/иным средствам идентификации/аутентификации).
Встает вопрос как передавать ключевые данный, где они должны, и должны
ли, аккамулироваться и т.д.
- В ряде случае для ускорения работы Web-серверов используются
системы промежуточного хранения (cache) реализованных на различного
рода proxy-серверах (серверах посредниках). В которых могут быть свои
собственные средства аутентификации/идентификации. Дополнительно
использование данных proxy-серверов может ввнести проблему анонимности
обращений, так как proxy-сервера выступают в качестве посредников.
Помимо прочего часть передаваемой информации может "застревать" в
промежуточных устройствах хранения ("cache") и как следствие вызывать
"утечку" информации.
- Остается проблема использования различного рода средств
межпрограммного обмена (буффер обмена) в операционных системах, что
позволяет скопировать из одного приложения в другое всю информацию с
гарантированной потерей меток безопасности.
- Учитывая определенную децентрализованную структуру
Web-технологий, целевой документ запращиваемый Web-browser'ом может
содержать ссылки на другие ресурсы запросы к которым будут в
автоматическом режиме сформированны Web-browser'ом. Как видно объем
передаваемой ключевой информации (полномочия по доступу к ресурсам)
буду передаваться постоянно, если это осуществимо вообще. Дополнительно
встает вопрос об их сокрытии (шифрации).
- На текущий момент возможно решение только части представленных
выше проблем и в основном они касаются доступу к различным ресурсам
(Web-серверам, СУБД и т.д.), например с использование инфраструктур
развернутых с применением PKI. Однако они, на текущий момент, не
обеспечивают решение проблем по поддержки документов содержащих разделы
с разным уровнем конфиденциальности. Не могут контролировать
использование средств передачи информации между приложениями (буфферов
обмена) и т.д.
Как видно из выше перечисленного проблема безопасности организации
документооборота конфидециальной информации с использованием текущих
Web-технологий не имеет решения. Для решения данной проблемы необходимо
координально пересматривать все механизмы Web-взаимодействий.
5.6 Распределённые файловые системы с поддержкой мандатной модели
доступа
Первое же требование к распределённым файловым системам - это наличие
единой политики доступа в рамках как минимум той части АС, накоторую
эта
файловая система распространяется. Невозможно требовать никакой
безопасности от системы если на одном узле АС пользователь имеет доступ
к секретным данным, а на другом к совершенно секретным.
Принципиально возможны две модели работы распределённой файловой
системы:
- Когда пользователь пытается получить доступ к файлу, файл
скачивается на локальную машину и далее вся работа идёт с локальной
копией. Так работает например AFS.
- Работа полностью происходит на удалённой машине. Вся работа с
файлом происходит удалённо. Так например работает NFS, но с некоторыми
оговорками, поскольку для оптимизации применяется кеширование.
В обоих случаях существует одни и те же проблемы - всё что связано с
использованием клиент-серверной архитектуры. Во-первых, все
существующие
протоколы не приспособлены к передачи расширенных аттрибутов
безопасности. Во-вторых, серверные компоненты подобных систем вынуждены
иметь полный доступ ко всем файлам, а посему в случае "пролома"
злоумышленник получает доступ ко всем файлам.
Как уже говорилось в начале. единая политика доступа должна
распространятся на все без исключения узлы в системе, даже рабочие
станции. Это может быть реализовано либо с глобализацией всей системы:
пользователи, их права доступа, их идентификаторы должны быть
одинаковы.
Возможен и несколько другой подход, когда используется отдельное
множество идентификаторов, привязанное к некоторым пользователям. В
этом
случае нет необходимости иметь одних и тех же пользователей на всех
машинах - доступ получат только те кто имеют соответствующие ключи. Тем
не менее права доступа в распределённой файловой системе должны быть
сопряжены с правами доступа на локальной машине дабы избежать утечки
данных. Поэтому всё-равно не обойтись без централизованного
администрирования. Организация централизованного администрирования само
по себе очень не просто.
Итого: распределённые файловые системы вешь непростая, требует
обязательной переработки существующих протоколов, а также
централизованного администрирования.
Выводы и рекомендации
Итак, были рассмотрены практически все виды современных
автоматизированных систем, проанализированы типичные угрозы их
функционированию. Время подвести общие итоги и сделать выводы.
Первый момент. Со времени появления первых автоматизированных систем
мир изменился. Современные автоматизированные системы вышли за рамки
закрытых предприятий. Часто их маршрут стал пролегать через сети
публичного доступа. Интерфейс современных компьютерных технологий
упростился до такой степени, что стало возможным участие в качестве
пользователей практически всех людей планеты. Даже ученик 6-го класса
уже может иметь доступ к сети общего доступа и случайно "наткнуться" на
шлюз правительственной автоматизированной системы. Компьютерные сети
вышли за пределы государств и соответственно морально-этических норм.
Человек может теперь совершать преступления на территории одного
государства, физически находясь на территории другого. Законодательные
нормы же его собственного государства могут просто не предусматривать
никакого наказания за преступления в компьютерной сфере. Всё это делает
автоматизированные системы уязвимыми как никогда. А с учётом того что
на
них возлагаются всё более и более ответственные функции, зачастую
связанные с безопасностью жизнедеятельности. Это означает что цена
информации во много раз превышает стоимость оборудования на котором она
обрабатывается и последствия простой атаки могут стать просто
катастрофическими. Вывод, не надо жалеть средств и времени для
огранизации комплексной защиты автоматизированной системы, в противном
случае потом придётся заплатить больше. Есть ли выход из сложившейся
ситуации? Ответ однозначен - есть. Необходим комплескный и детальный
подход к проектированию автоматизированной системы. При проектировании
необходимо изначально учитывать высокие требования безопасности
актуальные для современного мира. Надо учитывать всё: начиная с
физической топологии сети, заканчивая выбором протоколов и программного
обеспечения.
Необходимой составляющей всех автоматизированных систем является
человек. Человек всегда являлся самым слабым звеном безопасности любой
системы. Тем не менее за много лет разработано множество
предупредительных мер административно-организационного характера. Все
они являются актуальными и по сей день, за одним исключением.
Необходимо
только учитывать самые современные технологии и модернизировать
соответствующие инструкции. Средства информационных технологий
совершенствуются день ото дня и то что ранее казалось невозможным,
сегодня запросто осуществляется детьми. Например 20 лет назад при
описании должностных инструкций для закрытых учреждений вряд ли
предполагали что будет возможно незаметно переносить огромные
количества
информации на компактных носителях.
Для проведения строго анализа необходима строгая нормативная база. Для
этих целей разработано множество стандартов. Самые последние стандарты
стараются учитывать все возможные ситуации и, главное, являются
международными. Но к стандартам тоже надо относится критически. Как
всякая административная мера они имеют свойство быстро устаревать. Если
сегодня вашу автоматизированную систему сертифицируют по высшему
классу,
это не значит, что через год она реально будет такой же защищённой.
Необходимо определить разумный период для проведения повторных
сертификаций. Слишком малый период будет раздражать пользователей и
мешать работе АС. Слишком большой - сделает сертификат пустышкой.
Аппаратные средства устаревают также быстро, поэтому можно привязать
этот срок к сроку пока аппаратные средства, участвующие в составе АС,
ещё могут считаться современными.
Одной из ключевых составляющих любой АС являются протоколы обмена
информации. Современные протоколы должны учитывать все последние
достижения теории информационной безопасности и быть устойчивыми к
атакам при прохождении через сети публичного доступа. Поскольку большие
сети сложно мгновенно перевести на новый протокол, а наиболее
распространённый в настоящее время протокол IP версии 4 совершенно
негоден в плане обеспечения безопасности, то надо в обязательном
порядке применять туннелирование, с непременным шифрованием информации.
Использование шифрования к сожалению ограничивается массой
административных препятствий ибо приравнивается к
оружию. Тем не менее без шифрования никак не обойтись
и любая АС, желающая получить хоть какой-то уровень защиты должна иметь
в своём составе средства криптографической защиты. Нельзя не упомянуть
здесь же, что криптография сама по себе ничем не поможет если не будет
жёсткого подкрепления административными и другими мерами.Также
необходимо помнить что шифрование существенно снижает пропускную
способность АС, поэтому в отдельных случаях предпочтительнее
использовать выделенные физические каналы информации.
Ничто не остаётся всегда актуальным в мире информационных технологий
как применение самых современных программно-аппаратных средств защиты.
По мере развития информационных технологий можно можно обновлять только
программное обеспечение, оставляя прежним аппаратное. Это экономически
выгодно и позволяет всегда держать защиту на должном уровне. Тем не
менее как ни удивительно ключевые методы программной защиты мало
изменились за последнее время, зато сильно поменялись отдельные детали.
Немаловажной деталью является и общая тенденция к использованию
максимально проанализированного программного обеспечения. В этом ключе
очень интересно такое явление как "Свободное программное обеспечение".
Создаваемое добровольцами со всего мира оно мало того что экономически
выгодно (зачастую стоимость программного обеспечения сравнима со
стоимостью носителя), но и имеет ряд неоспоримых преимуществ перед
"закрытым" коммерческим программным обсспечением. Как то:
- В силу того что код открыт, он проходит постоянный контроль
(аудит) со стороны огромного числа людей, которые как правило обладают
достаточно высокой квалификацией.
- Несмотря на "народность" движения существует чёткая и сложенная
система оповешения об обнаруженных уязвимостей. Скорость исправления
обнаруженных ошибок максимально возможная и просто недостижимая для
комерческого ПО
- В свете сильного лобби так называемых "копирайт-холдеров" (тех
кто купил право распространения данного ПО и зарабатывает на этом
огромные деньги) в ряде государств возникают законы защищающие права
последних, пусть и в ущерб безопасности пользователей (а одним из
пользователей может стать само государство). Благодаря этим законам
высококвалифицированные специалисты не сообщают об обнаруженных
уязвимостях под угрозой ареста. Как следствие, данную ошибку может
обнаружить и злоумышленник (например даже узнав у этого обиженного
специалиста) и нанести сокрушающий удар по АС. К "свободному"
программному обеспечению эти законы просто неприменимы, поэтому не
возможно утаивание уязвимостей или попытки скрытого исправления у
"привилегированных" заказчиков (привелегированность как правило
устанавливает тот же "копирайт-холдер", но даже не автор ПО)
- Большинство государств просто не в состоянии разработать
собственными силами сложное современное ПО. "Свободное" ПО не имеет
границ распространения и изначально поддерживает возможность учёта
национальных особенностей в своём интерфейсе.
Ещё важный момент - необходимо чётко понимать возможности
применения современных протоколов и служб. Большинство их
разрабатывалось в те времена когда проблемы информационной безопасности
не стояли так высоко. Поэтому буквальный перенос таких распространённых
служб как почта,печать,WWW не возможен без детальной переработки оных.
Почему так было подробно рассказано в соответствующих разделах. Гораздо
экономически выгодней разработка принципиально новых протоколов и
служб со сходными пользовательскими функциями.