Главная страница
Навигация по странице:

  • Нормализация базы данных

  • Явные ограничения целостности

  • Физическая согласованность и надежность хранения данных

  • 15.2. Доступность и конфиденциальность информации

  • Терминология системы разграничения доступа Термины Определения

  • 15.3. Дискреционная защита информации

  • Категории прав доступа

  • INSERT — право вставлять в таблицу или представление новые строки; – UPDATE — право изменять данные в таблице или ее отдельных столб- цах; – DELETE

  • REFERENCES — право ссылаться на указанный объект, которое разреша- ет пользователю создавать внешние ключи в подчиненных таблицах без права доступа к главным таблицам; – EXECUTE

  • SQL-операторы управления правами доступа

  • 15.4. Мандатная защита информации

  • Рис. 5.2 Диаграмма информационных потоков модели мандатной защиты информации Метка безопасности объекта

  • Уровни доступа Каждому объекту

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


    Скачать 3.21 Mb.
    НазваниеПрактикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
    Дата10.01.2023
    Размер3.21 Mb.
    Формат файлаpdf
    Имя файлаВолк В. - Базы данных. Проектирование, программирование, управле.pdf
    ТипПрактикум
    #879390
    страница15 из 18
    1   ...   10   11   12   13   14   15   16   17   18
    ГЛАВА 15. КОНЦЕПЦИИ ЗАЩИТЫ ИНФОРМАЦИИ
    Защита информации не ограничивается только рамками базы данных и даже рамками информационной системы в целом. Решение этой задачи требует рассмотрения различных аспектов информационной безопасности всего про- граммно-аппаратного комплекса, включая использование операционных си- стем, сетевого оборудования, средств защиты сетевого трафика и, разумеется, средств разграничения доступа пользователей к объектам баз данных.
    Требования к уровню защищенности информационной системы обеспе- чиваются как соответствующими проектными решениями, так и действиями персонала сопровождения в процессе ее эксплуатации, в том числе и действия- ми администраторов баз данных, реализующих (а в ряде случаев и определяю- щих) политику информационной безопасности предприятия.
    Обеспечение информационной безопасности баз данных не является чи- сто технологической задачей, решаемой администраторами на стадии эксплуа- тации информационной системы. Многие проблемы с безопасностью «заклады- ваются» в систему на стадии ее проектирования и вызваны недостаточной ком- петентностью разработчиков, другая категория проблем связана с действиями пользователей, непреднамеренно или сознательно нарушающих установленные правила.
    При проектировании базы данных должны быть решены специфические задачи обеспечения защиты информации: классификация, группировка и опре- деление ролевых функций субъектов доступа, разграничение прав доступа субъектов к объектам, детальное описание способов доступа к информации и определение используемых для этой цели серверных и клиентских программ- ных приложений.
    При этом следует понимать, что обеспечение жесткого режима безопас- ности неизбежно снижает производительность информационной системы, уве- личивает трудоемкость ее администрирования, а также усложняет работу поль- зователей, «подталкивая» их к нарушениям установленных правил доступа к информации. Поэтому разработчики и администраторы баз данных сталкива- ются с проблемой, существенно более сложной, чем техническая реализация методов защиты данных, — это проблема выбора разумного компромисса меж- ду безопасностью и доступностью информации.
    Информационная безопасность базируется на трех основных концепциях защиты информации: целостность, доступность и конфиденциальность.
    15.1. Целостность информации
    Целостность (integrity) определяется как способность сохранения
    неизменности информации в условиях ее случайного и/или преднамеренного
    искажения. В теории и технологии реляционных баз данных рассматриваются как минимум четыре аспекта целостности информации, каждый из которых связан с определенной проблемой, методами и инструментальными средствами, применяемыми для ее решения.
    8 / 24

    201
    Нормализация базы данных
    В слабо нормализованной базе данных, обслуживающей OLTP-систему, ориентированную на интенсивное выполнение модифицирующих транзакций, могут проявляться аномалии включения, удаления и изменения данных. Реше- ние этой проблемы (или сведение к минимуму ее негативных проявлений) до- стигается при проектировании базы данных путем ее нормализации: в хорошо нормализованной базе данных каждая таблица приведена к одной из сильных нормальных форм путем ее декомпозиции на несколько взаимосвязанных таб- лиц.
    Заметим, что нормализация базы данных, решая задачу обеспечения це- лостности информации, может приводить и к негативным последствиям, сни- жая производительность выполнения запросов, связанных с поиском и чтением данных (вспомним процедурные планы выполнения запросов с соединением таблиц).
    Ссылочная целостность
    Обеспечение ссылочной целостности берет на себя сервер баз данных, контролируя соответствие типов данных и значений первичных и внешних ключей в строках связанных таблиц в процессе модификации соответствующих данных.
    Единственное, что должен сделать разработчик базы данных для обеспе- чения ссылочной целостности, — это явно определить ключевые поля таблиц, с помощью которых будут реализованы связи между ними, используя соответ- ствующие конструкции SQL-операторов Create/Alter Table:
    FOREIGN KEY
    REFERENCES <имя главной таблицы>(имя первичного ключа)
    Явные ограничения целостности
    Явные (checkedпроверяемые) ограничения целостности могут быть определены для полей таблиц и отражают, по существу, семантические ограни- чения, накладываемые на значения атрибутов соответствующих сущностей предметной области. Простейшие ограничения этого типа — это ограничения типов данных и диапазонов допустимых значений полей, в более сложных слу- чаях такие ограничения могут содержать логические выражения и вложенные
    SQL-запросы.
    Серверы баз данных предоставляют несколько инструментов для работы с явными ограничениями целостности. Один из таких инструментов позволяет явно задать ограничение в процессе описания схемы таблицы SQL-операторами
    Create/Alter Table, используя конструкцию ADD/DROP Constraint. Сервер будет автоматически проверять выполнение ограничения при модификации данных таблицы и блокировать ввод некорректных значений. Листинг 1.3 содержит пример использования конструкции Constraint.
    Другая ситуация, требующая контроля выполнения явного ограничения целостности информации, возникает в случаях, когда существует зависимость между значениями полей нескольких таблиц базы данных. Классический при- мер: таблица «Студенты» содержит список всех студентов университета,
    9 / 24

    202
    а связанная с ней таблица «Группы» содержит список всех студенческих групп, причем одно из полей этой таблицы — количество студентов в группе. Очевидно, что любая из типовых операций с контингентом студентов (зачисление, отчисле- ние или перевод) потребует внесения изменений в таблицу «Студенты» и, как следствие, перерасчета и изменения значения зависимого поля таблицы «Группы».
    Одно из возможных решений проблемы — включение этих двух опера- ций в одну транзакцию, что исключит возможность «одиночного» выполнения любой из них и, как следствие, сохранит непротиворечивость данных.
    Другое решение связано с использованием триггеров — специальных хранимых процедур, выполнение которых обусловлено наступлением опреде- ленных событий. В нашем примере триггер, обрабатывая таблицу «Студенты», должен рассчитывать количество студентов в каждой группе и записывать по- лученные значения в соответствующие строки таблицы «Группы». Если связать такой триггер с событиями модификации данных в таблице «Студенты», то логическая целостность базы данных будет надежно обеспечена.
    Физическая согласованность и надежность хранения данных
    Завершая обсуждение концепции целостности информации, рассмотрим задачу сохранения физической целостности базы данных в условиях, когда в процессе эксплуатации информационной системы происходят технические сбои в работе оборудования. Обычно рассматривают две категории таких сбо- ев: мягкий сбой, связанный с потерей данных, накопленных в оперативной па- мяти и еще не сохраненных в файлах базы данных, и жесткий сбой, связанный с потерей работоспособности внешних запоминающих устройств.
    Физическая целостность информации обеспечивается определенными действиями администраторов баз данных с использованием стандартных средств поддержки надежности, предоставляемых серверами баз данных.
    Жесткий сбой. Практически единственным способом борьбы с жесткими сбоями является регулярное резервное копирование баз данных с последующим их восстановлением из резервных копий. Администратор базы данных может создать определенный сценарий, задающий периодичность создания резервных копий и сохраняющий их на хорошо защищенных и надежных устройствах внешней памяти. Такой сценарий будет выполняться автоматически и не по- требует оперативного вмешательства администратора.
    Важнейшей проблемой резервного копирования баз данных является су- щественная длительность этой операции, причем на время ее выполнения сер- вер накладывает монопольную блокировку доступа клиентских приложений ко всем физическим объектам базы данных (экстентам файлов типа Data), затраги- ваемым процедурой резервного копирования.
    Острота этой проблемы частично снимается применением технологии со- здания разностных копий базы данных, согласно которой копируются не все объекты базы данных, а только те из них, в которых произошли изменения с момента последнего резервного копирования базы данных. MS SQL-Server опе- ративно сохраняет информацию о номерах измененных экстентов в специаль- ной файловой DCM-странице (Differential Changed Map, табл. 4.6).
    10 / 24

    203
    Мягкий сбой. Проблема потери данных в оперативной памяти решается путем сохранения в специальном журнале (Log-файле) информации обо всех транзакциях, изменивших состояние базы данных, в том числе и о транзакциях, содержащих операции резервного копирования базы данных. Журнал транзак- ций — это LOG-файл специального формата, который обычно размещается на хорошо защищенном и надежном устройстве внешней памяти и содержит хро- нологически упорядоченную последовательность записей, каждая из которых описывает активную операцию доступа к данным с указанием идентификатора транзакции, в составе которой была выполнена эта операция.
    Сервер баз данных формирует журнал транзакций в соответствии с про- токолом WAL, гарантирующим актуальность состояния журнала транзакций к моменту наступления мягкого сбоя. Ниже приведено описание процесса фор- мирования журнала транзакций и алгоритма его использования в процессе вос- становлении базы данных после мягкого сбоя.
    Если транзакция пытается изменить содержимое строк таблицы, удалить или вставить дополнительные строки в таблицу, то соответствующие файловые страницы считываются из файла в оперативную память и все необходимые из- менения производятся в виртуальных копиях этих страниц. Параллельно ин- формация обо всех таких изменениях оперативно регистрируется в сегменте журнала транзакций, также размещенном в буфере оперативной памяти.
    В соответствии с ACID-требованиями к реализации механизма транзак- ций, любая транзакция должна «получить» базу данных в согласованном со- стоянии и сохранить ее в согласованном состоянии после своего завершения
    (как успешного, так и прерванного), и при этом все изменения, произведенные в оперативной памяти операциями успешно завершенной транзакции, должны быть гарантированно зафиксированы (Commit) в базе данных, а операции пре- рванной транзакции, в том числе и уже зафиксированные в базе данных, долж- ны быть отменены путем отката (RollBack) транзакции.
    Из этого, в частности, следует, что если транзакция успешно завершилась оператором Commit, то все виртуальные страницы, измененные операциями этой транзакции, должны быть сохранены в файле типа DATA.
    Фактически все немного сложнее, так как SQL-код транзакции может со- держать специальные метки — промежуточные «точки сохранения» (save points), в которых гарантируется физическая согласованность данных и при до- стижении которых все промежуточные результаты еще не завершенной тран- закции должны быть сохранены в файле точно так же, как и при ее успешном завершении оператором Commit. При этом в журнале транзакций сохраняются и временны́е метки физической согласованности данных (так называемые
    TPC — Time of Physical Consistency), соответствующие промежуточным точкам сохранения транзакций.
    В соответствии с протоколом WAL (Write Ahead Log — прежде запиши в журнал), любой операции записи виртуальных страниц в файл типа DATA должна предшествовать операция записи в LOG-файл соответствующего вир- туального сегмента журнала транзакций. При соблюдении этого условия LOG-
    11 / 24

    204
    файл будет содержать записи обо всех транзакциях, как завершенных, так и прерванных в момент наступления мягкого сбоя и оставивших базу данных в рассогласованном состоянии, что позволяет реализовать процедуру восстанов- ления согласованного состояния базы данных.
    Рис. 5.1
    Иллюстрация алгоритма восстановления базы данных после мягкого сбоя:
    t — время фиксации записей в журнале транзакций; t
    1
    — последняя точка сохранения (t
    pc
    );
    t
    2
    — момент наступления мягкого сбоя.
    Рисунок 5.1 иллюстрирует пять типовых ситуаций, связанных с восста- новлением согласованного состояния базы данных после мягкого сбоя по жур- налу транзакций:
    – транзакция Т1 успешно завершилась и была зафиксирована в журнале транзакций и в базе данных до наступления момента мягкого сбоя — никаких действий по ее восстановлению не потребуется;
    – транзакция Т2 успешно завершилась до момента наступления мягкого сбоя, все ее операции были зафиксированы в журнале транзакций, но часть ре- зультатов их выполнения (на рисунке — правее последней точки сохранения t
    1
    ) по каким-то причинам не была зафиксирована в базе данных до момента наступ- ления сбоя. Для восстановления согласованности базы данных в этой ситуации потребуется повторно выполнить все операции (ReDo) этой транзакции, зареги- стрированные в журнале транзакций после последней точки сохранения t
    1
    ;
    – транзакция Т3 не успела завершиться до момента наступления сбоя, од- нако в момент t
    1
    (точка физической согласованности) часть результатов ее вы- полнения была сохранена в базе данных. Несмотря на то что транзакция не нарушила согласованного состояния базы данных, потребуется выполнить от- кат транзакции (UnDo) путем последовательного выполнения операций, «про- тивоположных» операциям, зафиксированным в журнале транзакций раньше последней точки сохранения t
    1
    ;
    – транзакция Т4 началась позднее последней точки сохранения t
    1
    и успешно завершилась. Все операции этой транзакции были записаны в журнал транзакций, однако результаты их выполнения по каким-то причинам не были
    12 / 24

    205
    зафиксированы в базе данных до наступления сбоя. Данная транзакция не нарушила целостность базы данных, однако для восстановления ее результатов потребуется повторно выполнить все операции, зарегистрированные в журнале от имени этой транзакции;
    – транзакция Т5 началась позднее последней точки сохранения t
    1
    и не успела завершиться до момента сбоя t
    2
    . Часть операций транзакции была зареги- стрирована в журнале транзакций, но результаты их выполнения не были зафик- сированы в базе данных. Эта транзакция не нарушила согласованного состояния базы данных, и никаких действий по ее восстановлению не потребуется.
    15.2. Доступность
    и конфиденциальность информации
    Терминология системы разграничения доступа приведена в таблице 5.1.
    Обеспечение доступа к информации легальным пользователям и защита кон- фиденциальной информации от несанкционированного доступа — две взаимо- связанные задачи, для решения которых могут использоваться различные мето- ды и средства, определяемые требованиями к уровню защищенности системы.
    Таблица 5.1
    Терминология системы разграничения доступа
    Термины
    Определения
    Доступ к инфор- мации
    Access to in- formation
    Ознакомление с информацией и/или ее обработка (ко- пирование, модификация, уничтожение)
    Объекты доступа Access objects,
    Securables
    Единицы информации, доступ к которым регламенти- руется правилами разграничения доступа
    Субъекты доступа Access subjects,
    Principals
    Пользователи, группы пользователей или процессы, действия которых регламентируются правилами раз- граничения доступа
    Права доступа
    (разрешения)
    Permissions
    Набор операций над объектом доступа, выполнение которых разрешено субъекту доступа
    Правила разграни- чения доступа
    Security policy Совокупность правил, регламентирующих права субъ- ектов доступа по отношению к объектам
    Идентификация
    Identification
    Присвоение объектам и субъектам доступа идентифи- катора и/или сравнение предъявляемого идентифика- тора с перечнем присвоенных идентификаторов
    Аутентификация
    Authentification Проверка принадлежности субъекту предъявленного им идентификатора, подтверждение подлинности
    Уровень полномо- чий субъекта
    Subject privilege
    Совокупность прав доступа (привилегий) субъекта доступа
    Метка конфиден- циальности
    Sensitivity label Информация, характеризующая уровень конфиденци- альности объекта доступа
    Дискреционная
    (логическая) за- щита
    Discretionary secure
    Разграничение доступа между поименованными субъ- ектами и поименованными объектами
    Мандатная (физи- ческая) защита
    Mandatory secure
    Защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности
    13 / 24

    206
    Пользователь информационной системы является важнейшим элементом системы разграничения доступа. По отношению к серверу баз данных пользо- вателей можно разделить на три категории: конечные пользователи, приклад- ные программисты и администраторы.
    Конечные пользователи, как правило, не имеют непосредственного до- ступа к серверу баз данных и получают доступ к базам данных через клиент- ские приложения, которые в этом случае получают статус «конечных пользова- телей». Права доступа конечных пользователей определяются их должностны- ми обязанностями в информационной системе.
    Прикладные программисты разрабатывают программы (клиентские и серверные приложения), использующие базы данных в интересах конечных пользователей. Прикладные программисты могут иметь права создания, моди- фикации и выполнения программных компонентов баз данных, однако они ли- шены прав модификации структуры компонентов данных и схем баз данных.
    Администраторы образуют особую категорию пользователей. Они наделяются правами создания баз данных и модификации их структуры, осу- ществляют контроль функционирования серверов баз данных и мониторинг ра- боты конечных пользователей, в необходимых случаях оказывают консульта- тивную помощь прикладным программистам. В обязанности администратора входит обеспечение высокой производительности работы системы, резервное копирование и восстановление работоспособности баз данных после сбоев обо- рудования, определение и контроль за соблюдением политики безопасности, а также регистрация пользователей и управление правами их доступа к данным.
    Система управления доступом пользователей к объектам баз данных, обеспечивающая разграничение доступа к конфиденциальной информации, имеет многоуровневую архитектуру: на уровне сервера баз данных производит- ся идентификация и аутентификация пользователей, контроль их принадлежно- сти определенным категориям, наделение их глобальными правами выполнения определенных операций с базами данных, управляемыми этим сервером; на уровне базы данных решаются локальные задачи управления доступом со сто- роны индивидуальных пользователей и/или их групп.
    15.3. Дискреционная защита информации
    Технология дискреционного управления доступом (discretionary access control, от discretion — разделение, разграничение) обеспечивает так называе- мую логическую защиту данных путем разграничения прав доступа субъектов
    базы данных к поименованным объектам логического уровня.
    Информация о зарегистрированных субъектах доступа — пользователях или группах пользователей (иначе называемых ролями), как и информация о ло- гических объектах (таблицах, представлениях, процедурах и пр.), хранится в системном каталоге базы данных (например, MS SQL-Server хранит такую ин- формацию в системных таблицах SysUsers и SysObjects). Наделение субъекта правом доступа к логическому объекту — это, по существу, установление связи
    (порядка M:N) между экземплярами (строками) соответствующих системных
    14 / 24

    207
    таблиц, а определение типа (наименования) права доступа — это присвоение соответствующего значения атрибуту такой связи. Таким образом, право до- ступа также является именованным логическим объектом базы данных.
    Язык SQL предоставляет функционально полный набор средств дискре- ционного управления доступом, состав и синтаксис которых могут несуще- ственно отличаться в различных реализациях. Ниже приведен краткий обзор таких языковых средств.
    Категории прав доступа:
    CREATE/ALTER — право создания/модификации объектов доступа: баз данных, таблиц, представлений, процедур, функций и др.;
    SELECT —
    право выборки (чтения) строк или отдельных столбцов таб- лицы или представления;
    INSERT —
    право вставлять в таблицу или представление новые строки;
    UPDATE —
    право изменять данные в таблице или ее отдельных столб- цах;
    DELETE —
    право удалять строки из таблицы или представления;
    REFERENCES —
    право ссылаться на указанный объект, которое разреша- ет пользователю создавать внешние ключи в подчиненных таблицах без права доступа к главным таблицам;
    EXECUTE —
    право выполнения хранимых процедур и функций.
    SQL-операторы управления правами доступа:
    CREATE USER … , CREATE ROLE … — создание субъектов доступа соответ- ствующих типов;
    GRANT <привилегия> ON <объект> TO <субъект> [WITH GRANT
    OPTION] — разрешение доступа: оператор предоставляет субъекту указанные права доступа («привилегии») к объекту (опционально — с правом передачи полученных прав другим субъектам);
    DENY <привилегия> ON <объект> TO <субъект> — запрет доступа: опе- ратор запрещает субъекту доступ к объекту с указанными правами («привиле- гиями»);
    REVOKE <привилегия> ON <объект> TO <субъект> — оператор отменяет действие выполненных ранее операторов GRANT или DENY.
    Дополнительно к перечисленным выше SQL-средствам прямого управле- ния доступом серверы баз данных предоставляют администраторам программ- ные компоненты, а также неязыковые средства экранного интерфейса.
    Дискреционная защита информации удовлетворяет потребностям боль- шинства коммерческих приложений, однако для систем повышенного уровня защищенности ее возможностей оказывается явно недостаточно.
    Завершая обзор методов дискреционного управления доступом, перечис- лим основные проблемы защиты конфиденциальной информации, которые ли- бо не решаются, либо решаются лишь частично в рамках этой технологии.
    Во-первых, дискреционная защита не позволяет надежно разграничить доступ к различным строкам одной таблицы. Частичное решение проблемы — запрет доступа к таблице и разрешение доступа к отдельным представлениям,
    15 / 24

    208
    созданным на базе этой таблицы и содержащим различные условия выборки строк. Слабость такого решения очевидна: невозможно разграничить доступ к нескольким строкам таблицы, удовлетворяющим одному условию выборки.
    Во-вторых, разграничение доступа к различным столбцам одной таблицы также создает определенные проблемы. Защита, основанная на создании пред- ставления, не содержащего информации «секретных» столбцов таблицы, легко обходится средствами SQL. Более радикальное решение предполагает модифи- кацию схемы базы данных: защищаемые столбцы таблицы выделяются в от- дельную таблицу, связанную с исходной таблицей, в которой остается только общедоступная информация. Такое решение может оказаться достаточно надежным, однако оно приведет к снижению производительности системы (еще раз вспомним процедурные планы выполнения SQL-запросов с соединением таблиц).
    Третий (возможно, главный) недостаток дискреционного управления до- ступом — это отсутствие средств защиты от несанкционированного распро-
    странения конфиденциальной информации: ничто не препятствует пользовате- лю, легально получившему доступ (с правом чтения Select) к таблице с конфи- денциальной информацией, сделать эту информацию доступной другим поль- зователям путем вставки (Insert) этой информации в другую (например, вре- менную) общедоступную таблицу.
    И последнее: дискреционная защита не позволяет физически изолировать технического специалиста, выполняющего функции администратора базы дан- ных, от управления конфиденциальными данными (в том числе и от ознаком- ления с ними), что требует повышения меры ответственности администратора и вряд ли соответствует политике информационной безопасности, реализуемой в хорошо защищенной системе.
    Как видим, дискреционная логическая защита является довольно слабой, и основная причина такой «слабости» заключается в том, что информация о защите данных хранится отдельно от самих защищаемых данных. Существенно более высокий уровень защищенности информации обеспечивает так называе- мая мандатная, или физическая защита.
    15.4. Мандатная защита информации
    Мандатное управление доступом (mandatory access control) основано на использовании «меток безопасности», присваиваемых экземплярам защищае- мых объектов базы данных, и официальном «мандате», выдаваемом субъекту и разрешающем ему доступ к информации с определенными метками безопас- ности.
    Классическая модель системы мандатного управления доступом впервые была описана Дэвидом Беллом и Леонардом Лападулойв 1975 г. Согласно этой модели каждому субъекту и каждому объекту доступа присваивается метка конфиденциальности: от самой высокой («особой важности») до самой низкой
    («несекретный» или «общедоступный»).
    16 / 24

    209
    При этом субъект не может читать информацию объекта, метка конфи- денциальности которого выше его собственной, но также ему запрещена запись информации в объекты с более низким уровнем безопасности, что не позволит такому субъекту понизить уровень секретности информации, к которой он по- лучил легальный доступ.
    На рисунке 5.2 9
    показана диаграмма информационных потоков модели
    Белла — Лападулы.
    Рис. 5.2
    Диаграмма информационных потоков модели мандатной защиты информации
    Метка безопасности объекта (всей таблицы, отдельного ее столбца, строки или поля) может иметь сложную структуру, позволяющую определить группу принадлежности объекта, уровень его ценности и конфиденциальности, а также ряд других параметров, например уровень защищенности устройства, на котором хранится объект. Метка безопасности объекта неотделима от самого объекта, физически хранится вместе с ним (а не в системном каталоге, как это происходит при логической защите) и уничтожается только в момент уничто- жения объекта.
    Мандатная защита обеспечивается специализированными серверами баз данных, которые блокируют «обход» меток безопасности при получении до- ступа к информации и, кроме того, предоставляют средства аудита доступа субъектов к защищаемым объектам.
    В качестве примера рассмотрим систему мандатного управления досту- пом, реализованную сервером баз данных «Линтер», имеющим сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 американского национального стандарта.
    9
    Автор рисунка — М. Савельев. URL: https://ru.wikipedia.org/w/index.php?curid=2894287.
    17 / 24

    210
    Группы принадлежности
    Субъекты доступа группируются (например, по отделам организации), при этом могут устанавливаться «доверительные отношения» между различ- ными группами принадлежности субъектов. Объекты доступа, независимо от иерархии в базе данных, также распределяются по группам принадлежности, причем объект может принадлежать только одной такой группе. Группы при- надлежности субъектов связываются с группами принадлежности объектов, при этом субъект получает права доступа только к объектам групп, связанных с группой этого субъекта, а также с группами, находящимися в доверительных отношениях с его группой.
    Уровни доступа
    Каждому объекту присваивается определенный уровень ценности
    (WAL — Write Access Level), ограничивающий возможность его модификации, и
    уровень конфиденциальности (RAL — Read Access Level), ограничивающий воз- можность просмотра (чтения) этого объекта. WAL- и RAL-уровни присваиваются также и субъектам доступа. По умолчанию объект наследует уровни того субъекта, который создал или изменил этот объект.
    Метки безопасности
    Метка безопасности объекта доступа включает компоненты:
    – группа принадлежности субъекта, создавшего объект;
    – RAL-уровень объекта;
    – WAL-уровень объекта.
    Метка безопасности субъекта доступа включает компоненты:
    – группа принадлежности субъекта;
    – RAL-уровень субъекта, равный максимальному RAL-уровню объекта, до- ступному для прочтения этим субъектом;
    – WAL-уровень субъекта, равный минимальному RAL-уровню объекта, до- ступному для модификации этим субъектом.
    Субъект не получит права чтения объекта доступа, RAL-уровень которого выше его собственного RAL-уровня, тем самым конфиденциальная информация будет защищена от несанкционированного прочтения. WAL-уровень субъекта доступа ограничивает его возможности по понижению уровня конфиденциаль- ности объекта: субъект не получит права модификации (изменения, удаления или вставки) объекта доступа, RAL-уровень которого выше WAL-уровня самого этого субъекта. Иными словами, пользователь не сможет сделать доступную ему информацию менее конфиденциальной, чем задано ее RAL-уровнем.
    18 / 24

    211
    1   ...   10   11   12   13   14   15   16   17   18


    написать администратору сайта