14 Пара. Защита локальных и сетевых ресурсов в Windows и Unix

(слайд №1)

(слайд №2)

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

• Несанкционированного доступа

• Злонамеренной модификации или разрушения

• Случайного ввода неверной информации.

Защита ОС общем случае базируется на трех основных механизмах:

1) идентификации и аутентификация пользователя при входе в систему;

2) разграничении прав доступа к файловой системе, в основе которого лежит реализация дискреционной модели доступа;

3) аудит, т.е. регистрация событий.

ОС Windows поддерживает два различных формата разделов жестких дисков; FAT и NTFS. FAT – это более старая файловая система, которая использовалась с начала восьмидесятых годов. В силу своего возраста FAT представляет собой простую файловую систему и не поддерживает безопасность на уровне файлов. NTFS, напротив, была разработана с учетом безопасности. Вы можете применять безопасность на уровне файлов непосредственно к файлам и папкам, лежащим в разделе NTFS.

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

(слайд №3)

Списки контроля доступа являются основой систем с избирательным управлением доступом. На рисунке представлена схема дискреционной модели управления доступом. Субъект доступа «Пользователь № 1» имеет право доступа только к объекту доступа № 3, поэтому его запрос к объекту доступа № 2 отклоняется. Субъект "Пользователь «№ 2» имеет право доступа как к объекту доступа № 1, так и к объекту доступа № 2, поэтому его запросы к данным объектам не отклоняются.

Матрица доступа

(слайд №4)

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

Рис.10.2. Матрица доступа

Как видно из рисунка 10.2, в матрице присутствует избыточность - пустые клетки, так как некоторые объекты недоступны для некоторых субъектов. В многопользовательских системах же с большим количеством, как объектов, так и субъектов, во-первых, размер матрицы может быть чрезвычайно большим, во-вторых, сама матрица наверняка будет очень сильно разрежена. Поэтому матричное представление прав доступа является неэффективным. Матрица может быть представлена либо в виде списков привилегий (privileges list), либо в виде списков управления доступом (rights list). Списковые структуры позволяют экономить память за счет исключения из матрицы позиций с пустыми значениями доступа.

В первом случае в системе существует таблица субъектов, и с каждым элементом этой таблицы связывается список объектов, к которым субъект имеет доступ (рис.10.3).

Рис.10.3. Списки привилегий

Во втором случае имеется таблица объектов, с элементами которой связаны списки субъектов (рис.10.4).

Рис.10.4. Списки управления доступом

Последний вариант называют ACL (Access Control List - список контроля доступа)

ACL

(слайд №5)

ACL (Access Control List - список контроля доступа) - определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом.

В типичных ACL каждая запись определяет субъект воздействия и операцию: например, запись (Vasya, delete) в ACL для файла XYZ даёт возможность пользователю Vasya удалить файл XYZ.

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

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

Традиционные ACL системы назначают права индивидуальным пользователям, и со временем и ростом числа пользователей в системе списки доступа могут стать громоздкими. Вариантом решения этой проблемы является назначения прав группам пользователей, а не персонально. Другим вариантом решения этой проблемы является «Управление доступом на основе ролей», где функциональные подмножества прав к ряду объектов объединяются в «роли», и эти роли назначаются пользователям. Однако в первом варианте группы пользователей также часто называются ролями.

Из структуры дескриптора безопасности видно, что он содержит два поля, содержащих в своем названии 'ACL' (Access-Control List) - список контроля доступа . Таких списков два: Discretionary Access-Control List, (DACL) - список управления избирательным доступом и System Access-Control List (SACL) - системный список управления доступом. Их структура схожа, однако они выполняют совершенно разные функции. Именно DACL формирует правила, кому разрешить доступ к объекту, а кому - запретить. Поэтому все, что будет сказано о списках контроля доступа и его элементах, в большей степени относится именно к DACL. SACL позволяет лишь управлять аудитом.

Каждый список контроля доступа (ACL) представляет собой набор элементов контроля доступа (Access Control Entries, или ACE) . Чтобы не было путаницы в терминах, изобразим схематически (рисунок 3).

ACE бывает двух типов (разрешающий и запрещающий доступ) и обязательно содержит три поля:

• SID пользователя или группы, к которому применяется данное правило.

• Вид доступа, на которое распространяется данное правило.

• Тип ACE - разрешающий или запрещающий.

Система сопоставляет маркер доступа и дескриптор защиты не при каждом обращении к объекту, а только при получении его дескриптора (рисунок 4). Например, если имеется защищенный объект-мьютекс, система проверяет права только при вызове процессом функции OpenMutex. В этой же функции процесс сразу же указывает, какие виды доступа ему в дальнейшем потребуются. Если все указанные виды доступа разрешены - процесс получает дескриптор объекта и может его использовать сколь угодно долго в соответствии с запрошенными правами. Даже если DACL объекта изменится. После того как процесс получил дескриптор, система не сможет его забрать. Если же система принимает решение отказать в доступе, процесс просто не получит дескриптор объекта.

Рисунок 4. Запрос доступа к объекту.

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