Добавлен: 14.06.2023
Просмотров: 286
Скачиваний: 2
СОДЕРЖАНИЕ
ГЛАВА 1. ВОПРОСЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
1.2 Скрытые воздействия на информационные системы
1.4 Меры усиления политики безопасности
ГЛАВА 2. ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ФИНАНСОВЫХ ПРЕДПРИЯТИЙ
2.1. Применение механизма меток безопасности
2.2. Методы анализа состояния защиты
Разделение доступа к информации тоже может быть описана в базе данных через ограничения, а информация об этом хранится в ее системном каталоге. Часто дополнительная информация запрашивается из операционной системы, в окружении которой работает сервер баз данных и клиент, который к ней обращается.
Мандатное управление доступом (mandatoryaccesscontrol) — это средства управления доступом и слежения за передачей информации. Обычные средства произвольного управления доступом, к сожалению, не мешают авторизованному пользователю сделать информацию доступной для других, неавторизованных, пользователей, поскольку привилегии существуют отдельно от данных. В случае работы реляционной СУБД некоторые данные обезличиваются, и потому могут быть переданы кому угодно средствами самой системой.
Использования системы управления базой данных с ресурсом мандатной защиты позволяют разграничивать доступ к данным информационной системы от доступа к именованным объектам данных. Единицей защиты в этом случае может быть каждая запись в таблице, представлении. Пользователь никогда не сможет обойти метку конфиденциальности.
Существует реализация, которая позволяет разграничить доступ вплоть до конкретного значения конкретного атрибута в конкретной строке конкретной таблицы. Дело может быть неограниченным в значении по значению метки конфиденциальности –как правило, сама метка представляет собой набор значений, которые отражают, например, уровень защищенности устройства, хранящем таблицу, уровень защищенности самой таблицы, уровень защищенности атрибута и уровень защищенности конкретного кортежа.
За исключением атрибута собственности (логическая защита), разбивающего данные (таблицы) на собственные (принадлежащие данному субъекту) и чужие, физическая защита разбивает данные более тонко. Но можно ли обойтись без физической защиты или, по крайней мере, попытаться, реализовав, например, сложный набор хранимых процедур.
Некое подобие защиты может быть реализовано в случае, когда метка добавляется в таблицу дополнительным атрибутом, доступ к таблицам запрещается вообще и ни одно приложение не может выполнить интерактивный SQL-запрос, а только хранимую процедуру и т.п. Некоторые реализации подобного уровня защиты используют вызов набора хранимых процедур с весьма абстрактными именами.
Системы реализации защиты информации в таких случаях являются сложными, они предполагают определенный уровень доверия к администратору безопасности, поскольку он имеет право вносить изменения в структуру базы данных, а значит, и хранимые процедуры, представления. Физически же администратор безопасности в данном случае не изолирован от управления секретными данными.
Кроме того, защищенные системы управления базами данных позволяют разграничить доступ к информационной системе с тех или иных рабочих станций для тех или иных зарегистрированных пользователей, определить режимы работы, наложить ограничения по времени работы тех или иных пользователей с тех или иных рабочих станций.
В случае реализации данных опций на прикладном уровне задача, как правило, сводится к созданию сервера приложений, который занимается отслеживанием. Применяют также отдельный комплекс серверных приложений, обычно это хранимые процедуры на случай отсутствия мандатной защиты.
В «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности описан механизм меток безопасности.
Метка объекта включает следующее:
1. Группа субъекта, внесшего данный объект.
2. Уровень доступа на чтение — RAL (ReadAccessLevel).
3. Уровень доступа на запись — WAL (WriteAccessLevel).
Метка субъекта выглядит аналогично:
1. Группа принадлежности субъекта.
2. RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации.
3. WAL-уровень субъекта, то есть минимальный RAL-уровень объекта, который может быть создан этим субъектом.
Все пользователи базы данных разбиты на отдельные группы, которые между собой не пересекаются. Каждая из них определяет области доступных пользователям данных. Для каждой группы определен администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователям одной группы не доступны данные, принадлежащие пользователям другой группы.
В этом плане у СУБД имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне [1-250]. Группа 0 — группа администратора системы. Только администратор системы может создать пользователя в группе. Все данные, созданные от имени пользователя, помечаются его группой.
Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:
Для пользователя (субъекта):
- RAL — уровень доступа; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного уровня доступа;
- WAL — уровень доверия на понижение уровня конфиденциальности; пользователь не может вносить информацию с уровнем доступа (RAL-уровнем) более низким, чем данный WAL-уровень пользователя. Иными словами, пользователь не может понизить уровень конфиденциальности информации.
Для информации:
- RAL — уровень чтения; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного RAL-уровня;
- WAL — уровень ценности или уровень доступа на запись (модификацию, удаление); пользователь может модифицировать (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.
Создать пользователя с произвольными уровнями может только администратор системы. Остальные администраторы (DBA) могут создавать пользователей (или изменять уровень пользователям) лишь в пределах отведенных им уровней[1].
Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни доступа для соответствующих записей и полей (при выполнении операторов INSERT или UPDATE). По умолчанию вносимые данные наследуют уровни пользователя, вносящего/изменяющего данные. Защищаемые объекты: пользователи, таблицы, столбцы, записи (вносится при выполнении INSERT), поля записей (изменяются при выполнении UPDATE). Уровни, как и группы, нельзя использовать в случае, если они не созданы специальными запросами.
Конфигурация, к которой имеет доступ хотя бы один программист, не может считаться безопасной. Поэтому обеспечение информационной безопасности баз данных - дело весьма сложное, и во многом вследствие самой природы реляционных баз данных[10].
Помимо систематического применения арсенала средств, описанных выше, необходимо использовать административные и процедурные меры, в частности регулярное изменение паролей пользователей, предотвращение доступа к физическим носителям информации и т.п.
2.2. Методы анализа состояния защиты
Активное развитие глобальной сети способствует росту нарушений безопасности систем во всем мире. Такая глобализация позволяет злоумышленникам практически из любой точки земного шара, где есть глобальная компьютерная сеть, осуществлять нападение на любую корпоративную сеть.
Современные методы накопления, обработки и передачи информации способствовали появлению угроз, связанных с возможностью потери, искажения и раскрытия данных, адресованных или принадлежащих конечным пользователям. Так, в банковской сфере почти все преступления связаны с использованием автоматизированных систем обработки информации.
Под угрозой безопасности понимается возможная потенциальная или реально существующая опасность совершения какого-либо деяния. Такие действия или бездействия могут быть направленны против информационных ресурсов. Таким образом, наносится ущерб собственнику или пользователю, когда проявляются искажения, раскрытие или потеря информации.
Анализ мировой статистики, проведенный SHALB, показывает постоянный рост количества попыток взлома сайтов и, к сожалению, все большее количество их удачных реализаций. С появлением новых технологий и всеобщей информатизации появляется все больше хакерских групп, которые находят все новые уязвимости в наиболее популярных технологиях и, пользуясь ими, наносят ущерб достаточно успешным банковским проектам.
В настоящее время имеется большое разнообразие методов анализа и управления рисками и реализующих их программных средств. Аудит безопасности систем, представляемый компанией SHALB, проводится по уникальной схеме, которая разработана согласно стандарту ISO27001. Данная услуга позволяет специалистам финансовых учреждений выявить “слабые” места ВЕБ - приложений, наличие которых может нанести непоправимый ущерб информации клиентов, позволив третьим лицам получать доступ к закрытым данным [2].
Инструментальная система CRAMM позволяет помимо анализа рисков, решать также и ряд других аудиторских задач:
- проведение обследования информационной системы;
- проведение аудита;
- разработка политики безопасности и плана обеспечения непрерывности бизнеса.
В основе метода CRAMM лежит комплексный подход к оценкам рисков, в сочетании количественных и качественных методов анализа. Метод является универсальным, версии программного продукта CRAMM ориентированы на различные типы организаций и отличаются между собой базами знаний (profiles) [4].
Например, для коммерческих организаций предназначена коммерческая версия (CommercialProfile), для правительственных организаций – правительственный профиль (Governmentprofile).
Рисунок 5 - Обследование по методу CRAMM
Сама процедура проверки в методе CRAMM формализована. Каждый этап генерирует достаточное количество промежуточных и результирующих отчетов.
Так, на первом этапе создаются следующие виды отчетов:
• Модель ресурсов, которая содержит описания ресурсов, которые попадают в границы исследования, и их взаимосвязей;
• Оценки критичности ресурсов;
• Итоговый отчет по результатам первого этапа аудита рисков, суммирующий результаты обследований.
Второй этап формирует следующие отчеты:
• Итоговая ведомость уровня угроз и уязвимостей;
• Итоговая ведомость оценки величин рисков;
• Итоговый отчет по второму этапу анализа рисков.
По результатам третьего этапа обследования формируются отчеты:
• Рекомендуемые контрмеры;
• Детальная спецификация безопасности;
• Оценка стоимостей контрмер;
• Список мер по приоритетам;
• Итоговый отчет третьего этапа обследования;
• Политики безопасности, которые включают описание требований стратегической безопасности и принципы защиты информационной системы;
• Список мероприятий по обеспечению безопасности.
Следует заметить, что грамотное применение метода CRAMM возможно при наличии специалиста с высокой квалификацией, который прошел специальное обучение. В противном случае необходимо приглашать аудиторские фирмы, которые располагают практическими специалистами с опытом применения возможностей CRAMM[5].
Обобщая практический опыт использования метода CRAMM при проведении проверки безопасности, можно сделать следующие выводы, относительно сильных и слабых сторон этого метода:
К сильным сторонам метода CRAMM относится следующее:
• CRAMM хорошо структурировани широко опробован методами анализа рисков, которые позволяют получить реальные практические результаты;
• Программный инструмент CRAMM может быть использован на всех этапах проведения аудита безопасности ИС;
• Основой программного продукта является большая база знаний по контрмерам в области предотвращения информационных угроз, которые базируются на рекомендациях стандарта BS 7799;
• Благодаря гибкости и универсальности метод используется для аудита информационных систем любой сложности и назначения;
• Система CRAMM используется как инструмент для разработки плана непрерывности бизнеса и политик информационной безопасности организации;
• CRAMM используется как средство документирования механизмов безопасности ИС.
Недостатками метода CRAMM являются:
•Обязательность специальной подготовки и наличие высококвалифицированных аудиторов;
• CRAMM в гораздо большей степени подходит для аудита уже существующих ИС, находящихся на стадии эксплуатации, нежели чем для ИС, находящихся на стадии разработки;
• Аудит по методу CRAMM – процесс достаточно трудоемкий и может потребовать месяцев непрерывной работы аудитора;
• Программный инструментарий CRAMM генерирует большое количество бумажной документации, которая не всегда оказывается полезной на практике;
• CRAMM не позволяет создавать собственные шаблоны отчетов или модифицировать имеющиеся.