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

1.1 Система обеспечения информационной безопасности

Целью реализации информационной безопасности какого-либо объекта является построение Системы обеспечения информационной безопасности данного объекта (СОИБ).

Для построения и эффективной эксплуатации СОИБ необходимо:

выявить требования защиты информации, специфические для данного объекта защиты;

учесть требования национального и международного Законодательства;

использовать наработанные практики (стандарты, методологии) построения подобных СОИБ;

определить подразделения, ответственные за реализацию и поддержку СОИБ;

распределить между подразделениями области ответственности в осуществлении требований СОИБ;

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

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

реализовать Систему менеджмента (управления) информационной безопасности (СМИБ);

используя СМИБ организовать регулярный контроль эффективности СОИБ и при необходимости пересмотр и корректировку СОИБ и СМИБ.

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

1.2 Организационно-технические и режимные меры и методы защиты информации

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

проверка целостности информации;

исключение несанкционированного доступа к ресурсам ПЭВМ и хранящимся в ней программам и данным (с целью сохранения трех основных свойств защищаемой информации: целостности, конфиденциальности, готовности);

исключение несанкционированного использования хранящихся в ПЭВМ программ (то есть защита программ от копирования).

Возможные каналы утечки информации, позволяющие нарушителю получить доступ к обрабатываемой или хранящейся в ПЭВМ информации, принято классифицировать на три группы, в зависимости от типа средства, являющегося основным при получении информации. Различают 3 типа средств: человек, аппаратура, программа [2, с. 138].

С первой группой, в которой основным средством является человек, связаны следующие основные возможные утечки:

чтение информации с экрана посторонним лицом;

расшифровка программой зашифрованной информации;

хищение носителей информации (магнитных дисков, дискет, лент и так далее).

Ко второй группе каналов, в которых основным средством является аппаратура, относятся следующие возможные каналы утечки:

подключение к ПЭВМ специально разработанных аппаратных средств, обеспечивающих доступ к информации;

использование специальных технических средств для перехвата электромагнитных излучений технических средств ПЭВМ.

несанкционированный доступ программы к информации;

расшифровка программой зашифрованной информации;

копирование программой информации с носителей.

Для описания технологии защиты информации конкретной информационной системы обычно строится так называемая Политика информационной безопасности.

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

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

Для построения Политики информационной безопасности рекомендуется отдельно рассматривать следующие направления защиты информационной системы:

Защита объектов информационной системы;

Защита процессов, процедур и программ обработки информации;

Защита каналов связи;

Подавление побочных электромагнитных излучений;

Управление системой защиты.

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

Определение информационных и технических ресурсов, подлежащих защите;

Выявление полного множества потенциально возможных угроз и каналов утечки информации;

Проведение оценки уязвимости и рисков информации при имеющемся множестве угроз и каналов утечки;

Определение требований к системе защиты;

Осуществление выбора средств защиты информации и их характеристик;

Внедрение и организация использования выбранных мер, способов и средств защиты;

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

Политика информационной безопасности оформляется в виде документированных требований на информационную систему. Документы обычно разделяют по уровням описания (детализации) процесса защиты.

Документы верхнего уровня Политики информационной безопасности отражают позицию организации к деятельности в области защиты информации, ее стремление соответствовать государственным, международным требованиям и стандартам в этой области. Подобные документы могут называться "Концепция ИБ", "Регламент управления ИБ", "Политика ИБ", "Технический стандарт ИБ" и т.п. Область распространения документов верхнего уровня обычно не ограничивается, однако данные документы могут выпускаться и в двух редакциях - для внешнего и внутреннего использования. Согласно ГОСТ Р ИСО/МЭК 17799-2005, на верхнем уровне Политики информационной безопасности должны быть оформлены следующие документы: "Концепция обеспечения ИБ", "Правила допустимого использования ресурсов информационной системы", "План обеспечения непрерывности бизнеса".

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

В политику информационной безопасности нижнего уровня входят регламенты работ, руководства по администрированию, инструкции по эксплуатации отдельных сервисов информационной безопасности [5, с. 69].

1.3 Программно-технические способы и средства обеспечения защиты информации

Рассмотрим следующую классификацию средств защиты информации:

средства защиты от несанкционированного доступа (НСД):

средства авторизации;

мандатное управление доступом;

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

управление доступом на основе ролей;

Журналирование (так же называется Аудит);

Системы анализа и моделирования информационных потоков Системы мониторинга сетей:

системы обнаружения и предотвращения вторжений (IDS/IPS);

анализаторы протоколов;

антивирусные средства;

межсетевые экраны;

Криптографические средства:

шифрование;

цифровая подпись;

системы резервного копирования;

Системы бесперебойного питания:

источники бесперебойного питания;

резервирование нагрузки;

генераторы напряжения;

Системы аутентификации:

пароль;

сертификат;

биометрия;

Средства предотвращения взлома корпусов и краж оборудования;

Средства контроля доступа в помещения;

Инструментальные средства анализа систем защиты:

мониторинговый программный продукт.

1.4 Средства защиты от несанкционированного доступа

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

Избирательное управление доступом - управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа.

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

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

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

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

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

субъект с определенным правом доступа может передать это право любому другому субъекту.

Возможны и смешанные варианты построения, когда одновременно в системе присутствуют как владельцы, устанавливающие права доступа к своим объектам, так и суперпользователь, имеющий возможность изменения прав для любого объекта и (или) изменения его владельца. Именно такой смешанный вариант реализован в большинстве операционных систем, например, в классических UNIX-системах или в системах Windows семейства NT.

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

Управление доступом на основе ролей - развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли.

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

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

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

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

Мандатное управление доступом - разграничение доступа субъектов к объектам, основанное на назначении метки конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности. Так же иногда переводится как Принудительный контроль доступа. Это способ, сочетающий защиту и ограничение прав, применяемый по отношению к компьютерным процессам, данным и системным устройствам и предназначенный для предотвращения их нежелательного использования.

Мандатная модель управления доступом, помимо дискреционной и ролевой, является основой реализации разграничительной политики доступа к ресурсам при защите секретной информации. При этом данная модель доступа практически не используется «в чистом виде», обычно на практике она дополняется элементами других моделей доступа.

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

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

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

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

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

1.5 Средства обеспечения безопасности Windows

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

API(Attachment Programming Interface) определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API - это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать.

Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию - высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.

По такому принципу построены протоколы передачи данных по Internet. Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню.

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

API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

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

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

Например, в языке программирования Си++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.

В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип значения в сигнатуре не участвует.

Семантика функции - это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.

Практически все операционные системы (Unix, Windows, Mac OS, и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем - это множество системных вызовов.

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

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности - написание «промежуточных» API (API графических интерфейсов Qt, Gtk, и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin, и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написания интерпретируемых языков, реализуемых на разных платформах (sh, python, perl, php, tcl, Java, и т.д.).

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

Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML-документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);

Потеря функциональности при переходе с более низкого уровня на более высокий.

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

1.8 Пакетный файл

Пакетный файл (англ. batch file) - текстовый файл в MS-DOS, OS/2 или Windows, содержащий последовательность команд, предназначенных для исполнения командным интерпретатором. После запуска пакетного файла, программа - интерпретатор (как правило COMMAND.COM или CMD.EXE) читает его строка за строкой и последовательно исполняет команды. Пакетный файл - аналог shell script в Unix-подобных операционных системах.

Пакетные файлы полезны для автоматического запуска приложений. Основная область применения - автоматизация наиболее рутинных операций, что регулярно приходится совершать пользователю компьютера. Примерами таких операций могут служить - обработка текстовых файлов; копирование, перемещение, переименование, удаление файлов; работа с папками; архивация; создание резервных копий баз данных и т. п. Пакетные файлы поддерживают операторы if и goto (а в системах семейства Windows NT и расширенный оператор for), что позволяет обрабатывать результаты выполнения предыдущих команд или приложений и в зависимости от этого выполнять дальше тот или иной блок команд (как правило, в случае удачного завершения приложение возвращает 0 в переменной errorlevel; в случае неудачного - 1 или большее значение).

Пакетные файлы в DOS имеют расширение.bat; для других операционных систем они могут иметь другие расширения - например,.CMD в Windows NT и OS/2, или.BTM в 4DOS или подобных оболочках.

Пакетные файлы могут содержать как внутренние команды, обрабатываемые непосредственно COMMAND.COM или CMD.EXE, так и обращения к внешним утилитам, существующим в виде отдельных программ (.EXE файлов). Данные программы значительно расширяют возможности пакетных файлов.

Программирование пакетных файлов появилось в MS-DOS и Windows с самого зарождения этих операционных систем. Командные интерпретаторы этих систем предлагают два режима работы: интерактивный режим (когда пользователь непосредственно вводит команды в командной строке и немедленно их исполняет) и пакетный режим (когда пользователь запускает предварительно записанную последовательность команд). Концепция обоих режимов была почерпнута из различных Unix-оболочек, равно как и из других текстовых интерфейсов командной строки начала 1980-х годов, таких как CP/M.

Командный интерпретатор в MS-DOS имеет название COMMAND.COM. Эволюция этой ветви пакетного программирования прошла через различные версии MS-DOS к Windows 95, Windows 98 и, наконец, к Windows Me. Наиболее известным пакетным файлом в этих системах является AUTOEXEC.BAT, специальный пакетный файл, который исполняется во время загрузки операционной системы.

Новые версии Windows - Windows 2000, XP и Vista основаны не на MS-DOS, а на Windows NT. NT-подобные системы включают интерпретатор cmd.exe, который частично совместим с COMMAND.COM. Некоторые старые возможности MS-DOS недоступны, однако вместо них появились дополнительные возможности и команды. COMMAND.COM до сих пор включается в NT-подобные системы для обеспечения лучшей обратной совместимости.

Существуют различные другие командные интерпретаторы, разработанные не компанией Microsoft и предоставляющие расширенный синтаксис команд для пакетного программирования. Примером может служить 4DOS.

Также имеются различные компиляторы пакетных файлов, превращающие пакетные файлы в исполняемые программы.

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

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

2. Разработка программного продукта