Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
ГЛАВА 15. КОНЦЕПЦИИ ЗАЩИТЫ ИНФОРМАЦИИ Защита информации не ограничивается только рамками базы данных и даже рамками информационной системы в целом. Решение этой задачи требует рассмотрения различных аспектов информационной безопасности всего про- граммно-аппаратного комплекса, включая использование операционных си- стем, сетевого оборудования, средств защиты сетевого трафика и, разумеется, средств разграничения доступа пользователей к объектам баз данных. Требования к уровню защищенности информационной системы обеспе- чиваются как соответствующими проектными решениями, так и действиями персонала сопровождения в процессе ее эксплуатации, в том числе и действия- ми администраторов баз данных, реализующих (а в ряде случаев и определяю- щих) политику информационной безопасности предприятия. Обеспечение информационной безопасности баз данных не является чи- сто технологической задачей, решаемой администраторами на стадии эксплуа- тации информационной системы. Многие проблемы с безопасностью «заклады- ваются» в систему на стадии ее проектирования и вызваны недостаточной ком- петентностью разработчиков, другая категория проблем связана с действиями пользователей, непреднамеренно или сознательно нарушающих установленные правила. При проектировании базы данных должны быть решены специфические задачи обеспечения защиты информации: классификация, группировка и опре- деление ролевых функций субъектов доступа, разграничение прав доступа субъектов к объектам, детальное описание способов доступа к информации и определение используемых для этой цели серверных и клиентских программ- ных приложений. При этом следует понимать, что обеспечение жесткого режима безопас- ности неизбежно снижает производительность информационной системы, уве- личивает трудоемкость ее администрирования, а также усложняет работу поль- зователей, «подталкивая» их к нарушениям установленных правил доступа к информации. Поэтому разработчики и администраторы баз данных сталкива- ются с проблемой, существенно более сложной, чем техническая реализация методов защиты данных, — это проблема выбора разумного компромисса меж- ду безопасностью и доступностью информации. Информационная безопасность базируется на трех основных концепциях защиты информации: целостность, доступность и конфиденциальность. 15.1. Целостность информации Целостность (integrity) определяется как способность сохранения неизменности информации в условиях ее случайного и/или преднамеренного искажения. В теории и технологии реляционных баз данных рассматриваются как минимум четыре аспекта целостности информации, каждый из которых связан с определенной проблемой, методами и инструментальными средствами, применяемыми для ее решения. 10 / 24 201 Нормализация базы данных В слабо нормализованной базе данных, обслуживающей OLTP-систему, ориентированную на интенсивное выполнение модифицирующих транзакций, могут проявляться аномалии включения, удаления и изменения данных. Реше- ние этой проблемы (или сведение к минимуму ее негативных проявлений) до- стигается при проектировании базы данных путем ее нормализации: в хорошо нормализованной базе данных каждая таблица приведена к одной из сильных нормальных форм путем ее декомпозиции на несколько взаимосвязанных таб- лиц. Заметим, что нормализация базы данных, решая задачу обеспечения це- лостности информации, может приводить и к негативным последствиям, сни- жая производительность выполнения запросов, связанных с поиском и чтением данных (вспомним процедурные планы выполнения запросов с соединением таблиц). Ссылочная целостность Обеспечение ссылочной целостности берет на себя сервер баз данных, контролируя соответствие типов данных и значений первичных и внешних ключей в строках связанных таблиц в процессе модификации соответствующих данных. Единственное, что должен сделать разработчик базы данных для обеспе- чения ссылочной целостности, — это явно определить ключевые поля таблиц, с помощью которых будут реализованы связи между ними, используя соответ- ствующие конструкции SQL-операторов Create/Alter Table: FOREIGN KEY REFERENCES <имя главной таблицы>(имя первичного ключа) Явные ограничения целостности Явные (checked — проверяемые) ограничения целостности могут быть определены для полей таблиц и отражают, по существу, семантические ограни- чения, накладываемые на значения атрибутов соответствующих сущностей предметной области. Простейшие ограничения этого типа — это ограничения типов данных и диапазонов допустимых значений полей, в более сложных слу- чаях такие ограничения могут содержать логические выражения и вложенные SQL-запросы. Серверы баз данных предоставляют несколько инструментов для работы с явными ограничениями целостности. Один из таких инструментов позволяет явно задать ограничение в процессе описания схемы таблицы SQL-операторами Create/Alter Table, используя конструкцию ADD/DROP Constraint. Сервер будет автоматически проверять выполнение ограничения при модификации данных таблицы и блокировать ввод некорректных значений. Листинг 1.3 содержит пример использования конструкции Constraint. Другая ситуация, требующая контроля выполнения явного ограничения целостности информации, возникает в случаях, когда существует зависимость между значениями полей нескольких таблиц базы данных. Классический при- мер: таблица «Студенты» содержит список всех студентов университета, 11 / 24 202 а связанная с ней таблица «Группы» содержит список всех студенческих групп, причем одно из полей этой таблицы — количество студентов в группе. Очевидно, что любая из типовых операций с контингентом студентов (зачисление, отчисле- ние или перевод) потребует внесения изменений в таблицу «Студенты» и, как следствие, перерасчета и изменения значения зависимого поля таблицы «Группы». Одно из возможных решений проблемы — включение этих двух опера- ций в одну транзакцию, что исключит возможность «одиночного» выполнения любой из них и, как следствие, сохранит непротиворечивость данных. Другое решение связано с использованием триггеров — специальных хранимых процедур, выполнение которых обусловлено наступлением опреде- ленных событий. В нашем примере триггер, обрабатывая таблицу «Студенты», должен рассчитывать количество студентов в каждой группе и записывать по- лученные значения в соответствующие строки таблицы «Группы». Если связать такой триггер с событиями модификации данных в таблице «Студенты», то логическая целостность базы данных будет надежно обеспечена. Физическая согласованность и надежность хранения данных Завершая обсуждение концепции целостности информации, рассмотрим задачу сохранения физической целостности базы данных в условиях, когда в процессе эксплуатации информационной системы происходят технические сбои в работе оборудования. Обычно рассматривают две категории таких сбо- ев: мягкий сбой, связанный с потерей данных, накопленных в оперативной па- мяти и еще не сохраненных в файлах базы данных, и жесткий сбой, связанный с потерей работоспособности внешних запоминающих устройств. Физическая целостность информации обеспечивается определенными действиями администраторов баз данных с использованием стандартных средств поддержки надежности, предоставляемых серверами баз данных. Жесткий сбой. Практически единственным способом борьбы с жесткими сбоями является регулярное резервное копирование баз данных с последующим их восстановлением из резервных копий. Администратор базы данных может создать определенный сценарий, задающий периодичность создания резервных копий и сохраняющий их на хорошо защищенных и надежных устройствах внешней памяти. Такой сценарий будет выполняться автоматически и не по- требует оперативного вмешательства администратора. Важнейшей проблемой резервного копирования баз данных является су- щественная длительность этой операции, причем на время ее выполнения сер- вер накладывает монопольную блокировку доступа клиентских приложений ко всем физическим объектам базы данных (экстентам файлов типа Data), затраги- ваемым процедурой резервного копирования. Острота этой проблемы частично снимается применением технологии со- здания разностных копий базы данных, согласно которой копируются не все объекты базы данных, а только те из них, в которых произошли изменения с момента последнего резервного копирования базы данных. MS SQL-Server опе- ративно сохраняет информацию о номерах измененных экстентов в специаль- ной файловой DCM-странице (Differential Changed Map, табл. 4.6). 12 / 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- 13 / 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 и успешно завершилась. Все операции этой транзакции были записаны в журнал транзакций, однако результаты их выполнения по каким-то причинам не были 14 / 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 Защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности 15 / 24 206 Пользователь информационной системы является важнейшим элементом системы разграничения доступа. По отношению к серверу баз данных пользо- вателей можно разделить на три категории: конечные пользователи, приклад- ные программисты и администраторы. Конечные пользователи, как правило, не имеют непосредственного до- ступа к серверу баз данных и получают доступ к базам данных через клиент- ские приложения, которые в этом случае получают статус «конечных пользова- телей». Права доступа конечных пользователей определяются их должностны- ми обязанностями в информационной системе. Прикладные программисты разрабатывают программы (клиентские и серверные приложения), использующие базы данных в интересах конечных пользователей. Прикладные программисты могут иметь права создания, моди- фикации и выполнения программных компонентов баз данных, однако они ли- шены прав модификации структуры компонентов данных и схем баз данных. Администраторы образуют особую категорию пользователей. Они наделяются правами создания баз данных и модификации их структуры, осу- ществляют контроль функционирования серверов баз данных и мониторинг ра- боты конечных пользователей, в необходимых случаях оказывают консульта- тивную помощь прикладным программистам. В обязанности администратора входит обеспечение высокой производительности работы системы, резервное копирование и восстановление работоспособности баз данных после сбоев обо- рудования, определение и контроль за соблюдением политики безопасности, а также регистрация пользователей и управление правами их доступа к данным. Система управления доступом пользователей к объектам баз данных, обеспечивающая разграничение доступа к конфиденциальной информации, имеет многоуровневую архитектуру: на уровне сервера баз данных производит- ся идентификация и аутентификация пользователей, контроль их принадлежно- сти определенным категориям, наделение их глобальными правами выполнения определенных операций с базами данных, управляемыми этим сервером; на уровне базы данных решаются локальные задачи управления доступом со сто- роны индивидуальных пользователей и/или их групп. 15.3. Дискреционная защита информации Технология дискреционного управления доступом (discretionary access control, от discretion — разделение, разграничение) обеспечивает так называе- мую логическую защиту данных путем разграничения прав доступа субъектов базы данных к поименованным объектам логического уровня. Информация о зарегистрированных субъектах доступа — пользователях или группах пользователей (иначе называемых ролями), как и информация о ло- гических объектах (таблицах, представлениях, процедурах и пр.), хранится в системном каталоге базы данных (например, MS SQL-Server хранит такую ин- формацию в системных таблицах SysUsers и SysObjects). Наделение субъекта правом доступа к логическому объекту — это, по существу, установление связи (порядка M:N) между экземплярами (строками) соответствующих системных 16 / 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-средствам прямого управле- ния доступом серверы баз данных предоставляют администраторам программ- ные компоненты, а также неязыковые средства экранного интерфейса. Дискреционная защита информации удовлетворяет потребностям боль- шинства коммерческих приложений, однако для систем повышенного уровня защищенности ее возможностей оказывается явно недостаточно. Завершая обзор методов дискреционного управления доступом, перечис- лим основные проблемы защиты конфиденциальной информации, которые ли- бо не решаются, либо решаются лишь частично в рамках этой технологии. Во-первых, дискреционная защита не позволяет надежно разграничить доступ к различным строкам одной таблицы. Частичное решение проблемы — запрет доступа к таблице и разрешение доступа к отдельным представлениям, 17 / 24 208 созданным на базе этой таблицы и содержащим различные условия выборки строк. Слабость такого решения очевидна: невозможно разграничить доступ к нескольким строкам таблицы, удовлетворяющим одному условию выборки. Во-вторых, разграничение доступа к различным столбцам одной таблицы также создает определенные проблемы. Защита, основанная на создании пред- ставления, не содержащего информации «секретных» столбцов таблицы, легко обходится средствами SQL. Более радикальное решение предполагает модифи- кацию схемы базы данных: защищаемые столбцы таблицы выделяются в от- дельную таблицу, связанную с исходной таблицей, в которой остается только общедоступная информация. Такое решение может оказаться достаточно надежным, однако оно приведет к снижению производительности системы (еще раз вспомним процедурные планы выполнения SQL-запросов с соединением таблиц). Третий (возможно, главный) недостаток дискреционного управления до- ступом — это отсутствие средств защиты от несанкционированного распро- странения конфиденциальной информации: ничто не препятствует пользовате- лю, легально получившему доступ (с правом чтения Select) к таблице с конфи- денциальной информацией, сделать эту информацию доступной другим поль- зователям путем вставки (Insert) этой информации в другую (например, вре- менную) общедоступную таблицу. И последнее: дискреционная защита не позволяет физически изолировать технического специалиста, выполняющего функции администратора базы дан- ных, от управления конфиденциальными данными (в том числе и от ознаком- ления с ними), что требует повышения меры ответственности администратора и вряд ли соответствует политике информационной безопасности, реализуемой в хорошо защищенной системе. Как видим, дискреционная логическая защита является довольно слабой, и основная причина такой «слабости» заключается в том, что информация о защите данных хранится отдельно от самих защищаемых данных. Существенно более высокий уровень защищенности информации обеспечивает так называе- мая мандатная, или физическая защита. 15.4. Мандатная защита информации Мандатное управление доступом (mandatory access control) основано на использовании «меток безопасности», присваиваемых экземплярам защищае- мых объектов базы данных, и официальном «мандате», выдаваемом субъекту и разрешающем ему доступ к информации с определенными метками безопас- ности. Классическая модель системы мандатного управления доступом впервые была описана Дэвидом Беллом и Леонардом Лападулойв 1975 г. Согласно этой модели каждому субъекту и каждому объекту доступа присваивается метка конфиденциальности: от самой высокой («особой важности») до самой низкой («несекретный» или «общедоступный»). 18 / 24 209 При этом субъект не может читать информацию объекта, метка конфи- денциальности которого выше его собственной, но также ему запрещена запись информации в объекты с более низким уровнем безопасности, что не позволит такому субъекту понизить уровень секретности информации, к которой он по- лучил легальный доступ. На рисунке 5.2 9 показана диаграмма информационных потоков модели Белла — Лападулы. Рис. 5.2 Диаграмма информационных потоков модели мандатной защиты информации Метка безопасности объекта (всей таблицы, отдельного ее столбца, строки или поля) может иметь сложную структуру, позволяющую определить группу принадлежности объекта, уровень его ценности и конфиденциальности, а также ряд других параметров, например уровень защищенности устройства, на котором хранится объект. Метка безопасности объекта неотделима от самого объекта, физически хранится вместе с ним (а не в системном каталоге, как это происходит при логической защите) и уничтожается только в момент уничто- жения объекта. Мандатная защита обеспечивается специализированными серверами баз данных, которые блокируют «обход» меток безопасности при получении до- ступа к информации и, кроме того, предоставляют средства аудита доступа субъектов к защищаемым объектам. В качестве примера рассмотрим систему мандатного управления досту- пом, реализованную сервером баз данных «Линтер», имеющим сертификат по второму классу защиты от несанкционированного доступа, что соответствует классу B3 американского национального стандарта. 9 Автор рисунка — М. Савельев. URL: https://ru.wikipedia.org/w/index.php?curid=2894287. 19 / 24 210 Группы принадлежности Субъекты доступа группируются (например, по отделам организации), при этом могут устанавливаться «доверительные отношения» между различ- ными группами принадлежности субъектов. Объекты доступа, независимо от иерархии в базе данных, также распределяются по группам принадлежности, причем объект может принадлежать только одной такой группе. Группы при- надлежности субъектов связываются с группами принадлежности объектов, при этом субъект получает права доступа только к объектам групп, связанных с группой этого субъекта, а также с группами, находящимися в доверительных отношениях с его группой. Уровни доступа Каждому объекту присваивается определенный уровень ценности (WAL — Write Access Level), ограничивающий возможность его модификации, и уровень конфиденциальности (RAL — Read Access Level), ограничивающий воз- можность просмотра (чтения) этого объекта. WAL- и RAL-уровни присваиваются также и субъектам доступа. По умолчанию объект наследует уровни того субъекта, который создал или изменил этот объект. Метки безопасности Метка безопасности объекта доступа включает компоненты: – группа принадлежности субъекта, создавшего объект; – RAL-уровень объекта; – WAL-уровень объекта. Метка безопасности субъекта доступа включает компоненты: – группа принадлежности субъекта; – RAL-уровень субъекта, равный максимальному RAL-уровню объекта, до- ступному для прочтения этим субъектом; – WAL-уровень субъекта, равный минимальному RAL-уровню объекта, до- ступному для модификации этим субъектом. Субъект не получит права чтения объекта доступа, RAL-уровень которого выше его собственного RAL-уровня, тем самым конфиденциальная информация будет защищена от несанкционированного прочтения. WAL-уровень субъекта доступа ограничивает его возможности по понижению уровня конфиденциаль- ности объекта: субъект не получит права модификации (изменения, удаления или вставки) объекта доступа, RAL-уровень которого выше WAL-уровня самого этого субъекта. Иными словами, пользователь не сможет сделать доступную ему информацию менее конфиденциальной, чем задано ее RAL-уровнем. 20 / 24 |