Shon Harris. All In One CISSP Exam Guide
Почти без комментариев: крепкий Body of Knowledge, отдельный домен для Security Architecture and Engineering, ограниченный, но достаточный перечень моделей безопасности. Хорошее справочное руководство, рекомендую даже если совсем не собираетесь сдавать на сертификацию.
Почти без комментариев: крепкий Body of Knowledge, отдельный домен для Security Architecture and Engineering, ограниченный, но достаточный перечень моделей безопасности. Хорошее справочное руководство, рекомендую даже если совсем не собираетесь сдавать на сертификацию.
Книги по системной инженерии
INCOSE Systems Engineering Handbook. A Guide for System Life Cycle Processes and Activities
Профессиональное сообщество International Council on Systems Engineering (INCOSE) – знак качества. Книга с упором на определение и описание процессов жизненного цикла систем. Широко известна как SE Handbook. Является основой для многих международных стандартов. Предпоследнее издание обычно доступно в pdf
INCOSE Systems Engineering Handbook. A Guide for System Life Cycle Processes and Activities
Профессиональное сообщество International Council on Systems Engineering (INCOSE) – знак качества. Книга с упором на определение и описание процессов жизненного цикла систем. Широко известна как SE Handbook. Является основой для многих международных стандартов. Предпоследнее издание обычно доступно в pdf
👍1
M.Maier, E.Rechtin The Art of Systems Architecting
В сравнении с предыдущей книгой, дает более общий обзор процесса создания архитектуры систем, описывает ту часть, которая про «искусство» и как она стыкуется с наукой. Хороша для получения цельной картины вопросов, связанных с созданием сложных систем. Доступна тут
В сравнении с предыдущей книгой, дает более общий обзор процесса создания архитектуры систем, описывает ту часть, которая про «искусство» и как она стыкуется с наукой. Хороша для получения цельной картины вопросов, связанных с созданием сложных систем. Доступна тут
🔥1
SYSTEMS ARCHITECTING AND SOFTWARE INTEGRATION
Подстрочник семинара E.Rechtin, блестящий текст по системной инженерии. В дополнение в The Art of System Architecting.
Подстрочник семинара E.Rechtin, блестящий текст по системной инженерии. В дополнение в The Art of System Architecting.
Наконец, стандарты. ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description Международный стандарт на описание архитектур, согласующийся с упомянутыми книгами и используемый как основа при создании других международных стандартов. С ним вместе и на основе SE Handbook - ISO/IEC/IEEE 15288:2015 "Systems and software engineering - System life cycle processes" (наверняка вы его знаете)
Если хочется только на русском языке, то есть выжимка в виде адаптированного международного стандарта ГОСТ 57100 и ГОСТ 57193 тут
https://docs.cntd.ru/document/1200139542
https://docs.cntd.ru/document/1200141163
Если хочется только на русском языке, то есть выжимка в виде адаптированного международного стандарта ГОСТ 57100 и ГОСТ 57193 тут
https://docs.cntd.ru/document/1200139542
https://docs.cntd.ru/document/1200141163
Ключевые моменты лекции 1 /
Безопасность, доверие и благонадежность
Понятие доверия имеет сразу несколько интерпретаций. Первая и самая очевидная: необходимость и возможность полагаться в силу различных факторов на поведение аппаратного или программного обеспечения, или людей, то есть доверять им безусловно. В число таких факторов доверия для оборудования и ПО могут входить репутация поставщика, его происхождение и вероятная незаинтересованность в намеренной компрометации инфраструктуры. Для людей это моральная и материальная ответственность, ответственность в силу законодательства, достаточность квалификации и знаний для выполнения служебных обязанностей. По сути, такое доверие (с англ. trust) базируется на предположениях и является по большей части вынужденным.
В другой интерпретации, доверие к системе – это определенная и, как правило, достаточная степень уверенности в том, что система работает, как и ожидалось, в отношении набора характеристик. Эти характеристики включают в себя функциональную безопасность, защищенность от атак, конфиденциальность и целостность данных, надежность и отказоустойчивость системы перед лицом внешних воздействий, ошибок человека, системных сбоев и атак. Степень уверенности достигается через выполнение процедур по оценке доверия.
Доверие в этой интерпретации (trustworthiness) – это благонадежность системы. Оно не является безусловным и должно демонстрироваться процедурами оценки доверия, основанными на ряде предположений.
Безопасность, доверие и благонадежность
Понятие доверия имеет сразу несколько интерпретаций. Первая и самая очевидная: необходимость и возможность полагаться в силу различных факторов на поведение аппаратного или программного обеспечения, или людей, то есть доверять им безусловно. В число таких факторов доверия для оборудования и ПО могут входить репутация поставщика, его происхождение и вероятная незаинтересованность в намеренной компрометации инфраструктуры. Для людей это моральная и материальная ответственность, ответственность в силу законодательства, достаточность квалификации и знаний для выполнения служебных обязанностей. По сути, такое доверие (с англ. trust) базируется на предположениях и является по большей части вынужденным.
В другой интерпретации, доверие к системе – это определенная и, как правило, достаточная степень уверенности в том, что система работает, как и ожидалось, в отношении набора характеристик. Эти характеристики включают в себя функциональную безопасность, защищенность от атак, конфиденциальность и целостность данных, надежность и отказоустойчивость системы перед лицом внешних воздействий, ошибок человека, системных сбоев и атак. Степень уверенности достигается через выполнение процедур по оценке доверия.
Доверие в этой интерпретации (trustworthiness) – это благонадежность системы. Оно не является безусловным и должно демонстрироваться процедурами оценки доверия, основанными на ряде предположений.
Ключевые моменты лекции 1 /
Аспекты безопасности, свойства, -ilities
Однако какие аспекты мы можем оценивать, и самое главное, что именно предполагает оценка? Это не только известная триада CIA, в нее давно «не помещается» все многообразие аспектов, которые требуют от доверенной системы. В интерпретации Industrial IoT Consortium, доверие включает аспекты компьютерной безопасности, функциональной безопасности, надежности, устойчивости и приватности. Определения можно найти в публично доступных документах IIC. Раз, два, три
Интерпретировав эти понятия, мы понимаем, что это еще не предел для так называемых “-ilities” (свойств, условно относимых к качеству системы). Их катастрофически много. Предлагается следующий bullshit детектор: 1. Свойство должно быть доступно для интерпретации и моделирования с внятным объяснением того, что имеется в виду под этим свойством 2. Интерпретация должна проходить неформальную валидацию – все заинтересованные стороны должны понимать его одинаково 3. Должен существовать способ проверки или измерения свойства (верифицируемость свойства). Пример – демонстрация испытаний стула в IKEA.
Свойства также разделяются на два типа: свойство «формальной безопасности» (safety) - «можно показать, что при определенных условиях некоторое нежелательное событие не произойдет» и свойство «формальной живости» (liveness) - «можно показать, что при определенных условиях некоторое желательное событие обязательно произойдет». Тип свойства важен для определения того, является ли оно верифицируемым, и как его можно верифицировать (или нельзя). Из пятерки свойств IIC trustworthiness safety, security и reliability – это свойства «формальной безопасности», а resilience и privacy – свойства «формальной живости» (как минимум в том виде, в котором их определяют документы IIC, при другом определении это может поменяться).
Аспекты безопасности, свойства, -ilities
Однако какие аспекты мы можем оценивать, и самое главное, что именно предполагает оценка? Это не только известная триада CIA, в нее давно «не помещается» все многообразие аспектов, которые требуют от доверенной системы. В интерпретации Industrial IoT Consortium, доверие включает аспекты компьютерной безопасности, функциональной безопасности, надежности, устойчивости и приватности. Определения можно найти в публично доступных документах IIC. Раз, два, три
Интерпретировав эти понятия, мы понимаем, что это еще не предел для так называемых “-ilities” (свойств, условно относимых к качеству системы). Их катастрофически много. Предлагается следующий bullshit детектор: 1. Свойство должно быть доступно для интерпретации и моделирования с внятным объяснением того, что имеется в виду под этим свойством 2. Интерпретация должна проходить неформальную валидацию – все заинтересованные стороны должны понимать его одинаково 3. Должен существовать способ проверки или измерения свойства (верифицируемость свойства). Пример – демонстрация испытаний стула в IKEA.
Свойства также разделяются на два типа: свойство «формальной безопасности» (safety) - «можно показать, что при определенных условиях некоторое нежелательное событие не произойдет» и свойство «формальной живости» (liveness) - «можно показать, что при определенных условиях некоторое желательное событие обязательно произойдет». Тип свойства важен для определения того, является ли оно верифицируемым, и как его можно верифицировать (или нельзя). Из пятерки свойств IIC trustworthiness safety, security и reliability – это свойства «формальной безопасности», а resilience и privacy – свойства «формальной живости» (как минимум в том виде, в котором их определяют документы IIC, при другом определении это может поменяться).
Ключевые моменты лекции 1 /
Подходы к проектированию в системной инженерии
Чтобы перейти от абстрактных аспектов и их проверки к целям безопасности, давайте обсудим подходы, применяемые в проектировании (а создание целей безопасности из неструктурированного описания – это именно проектирование). Рехтин и Мэйер определяют 4 подхода: нормативный (normative), методический (rational, method-based), кооперационный (participative), эвристический (heuristic). На протяжении курса мы будем неоднократно возвращаться к этой классификации.
Нормативный подход заключается в применении к системе, ее элементам и процессам ЖЦ обязательных требований, включая требования законодательства, государственных и отраслевых регуляторов, но не ограничиваясь этими требованиями.
Методический подход заключается в применении к системе, ее элементам и процессам ЖЦ классического дедуктивного метода проектирования («сверху вниз») – моделей, шаблонов проектирования и разработки, а также формально определенных алгоритмов взаимодействия и протоколов, обеспечивающих передачу данных, контроль и управление, обладающие заданными свойствами.
Кооперационный подход заключается в совместной деятельности заинтересованных лиц – участников процессов ЖЦ системы, целью этой деятельности является учет всех интересов участников при реализации требований к системе. В том числе, кооперационный подход включает реализацию участниками требований к безопасной разработке системы, но не ограничивается им.
Эвристический подход заключается в применении системе принципов и «лучших практик», представляющих результаты извлеченных уроков из предыдущего опыта проектирования (подход «снизу вверх»).
Подходы разделены не строго, могут эволюционировать между собой и видоизменяться, будучи использованы вместе.
Подходы к проектированию в системной инженерии
Чтобы перейти от абстрактных аспектов и их проверки к целям безопасности, давайте обсудим подходы, применяемые в проектировании (а создание целей безопасности из неструктурированного описания – это именно проектирование). Рехтин и Мэйер определяют 4 подхода: нормативный (normative), методический (rational, method-based), кооперационный (participative), эвристический (heuristic). На протяжении курса мы будем неоднократно возвращаться к этой классификации.
Нормативный подход заключается в применении к системе, ее элементам и процессам ЖЦ обязательных требований, включая требования законодательства, государственных и отраслевых регуляторов, но не ограничиваясь этими требованиями.
Методический подход заключается в применении к системе, ее элементам и процессам ЖЦ классического дедуктивного метода проектирования («сверху вниз») – моделей, шаблонов проектирования и разработки, а также формально определенных алгоритмов взаимодействия и протоколов, обеспечивающих передачу данных, контроль и управление, обладающие заданными свойствами.
Кооперационный подход заключается в совместной деятельности заинтересованных лиц – участников процессов ЖЦ системы, целью этой деятельности является учет всех интересов участников при реализации требований к системе. В том числе, кооперационный подход включает реализацию участниками требований к безопасной разработке системы, но не ограничивается им.
Эвристический подход заключается в применении системе принципов и «лучших практик», представляющих результаты извлеченных уроков из предыдущего опыта проектирования (подход «снизу вверх»).
Подходы разделены не строго, могут эволюционировать между собой и видоизменяться, будучи использованы вместе.
👍1
Ключевые моменты лекции 1 /
Цели безопасности. Предположения безопасности
Исходя из всего вышесказанного, нам нужно научиться формулировать цели безопасности, обладающие следующими предпочтительными свойствами: 1. Сформулированы в объективной и конкретной манере 2. Желательно, чтобы они были описаны как инвариант, то есть для формулировок нужно использовать описательные выражения (например, описывающие, а не предписывающие эвристики).
Эти цели должны быть определены, исходя из неконсистентного, вероятно неполного перечня интересов, мотивов и побуждений к безопасности, действующего для заинтересованных сторон. При создании системы нередки ситуации конфликта интересов, отсутствия реальной мотивации к трате ресурсов на безопасность и т.п. Поэтому применяем доступные нам методы: лучше всего на первых этапах работают эвристики, неплохо подходит нормативная база, можно использовать кооперационные методы (брейнсторм, совместная работа). Методический подход к анализу конфликта интересов и анализу стратегий должен работать, но на фактически не используется: непрактично. В определении целей безопасности может быть несколько итераций уточнения.
Предположения безопасности как правило, касаются ряда определенных факторов, должны быть сформулированы однозначно и четко. Невысказанные предположения представляют собой риски безопасности или создают почву для рисков.
Цели безопасности. Предположения безопасности
Исходя из всего вышесказанного, нам нужно научиться формулировать цели безопасности, обладающие следующими предпочтительными свойствами: 1. Сформулированы в объективной и конкретной манере 2. Желательно, чтобы они были описаны как инвариант, то есть для формулировок нужно использовать описательные выражения (например, описывающие, а не предписывающие эвристики).
Эти цели должны быть определены, исходя из неконсистентного, вероятно неполного перечня интересов, мотивов и побуждений к безопасности, действующего для заинтересованных сторон. При создании системы нередки ситуации конфликта интересов, отсутствия реальной мотивации к трате ресурсов на безопасность и т.п. Поэтому применяем доступные нам методы: лучше всего на первых этапах работают эвристики, неплохо подходит нормативная база, можно использовать кооперационные методы (брейнсторм, совместная работа). Методический подход к анализу конфликта интересов и анализу стратегий должен работать, но на фактически не используется: непрактично. В определении целей безопасности может быть несколько итераций уточнения.
Предположения безопасности как правило, касаются ряда определенных факторов, должны быть сформулированы однозначно и четко. Невысказанные предположения представляют собой риски безопасности или создают почву для рисков.
👍1
Имея достаточно деталей о технологии и предполагаемой реализации системы, можно построить модель угроз для системы в целом и ее элементов. Цели безопасности нельзя «заужать», так как дополнительные ограничения еще поступят от реализации их механизмами безопасности. Методы гарантии безопасности применимы к механизмам, исходя из реализации этих механизмов. Тут хорошую службу сослужит правильная архитектура системы: доказательство безопасности может упроститься. Со своей стороны, отдельным интересом заинтересованных сторон может быть получение определенного уровня гарантий.
А вот включение требований к гарантиям безопасности в перечень целей безопасности не является хорошей практикой: лучше, чтобы цели безопасности были объектом валидации. Требование гарантий «внутри» списка целей приведет к «самоприменению» требования и неразрешимости задачи.
Также тонкий момент заключается в том, что, если заинтересованные лица выставляют требования непосредственно к механизмам безопасности в обход формулирования целей, это может привести к неадекватной или неполной реализации безопасности, перерасходу средств, так называемому «театру безопасности» и другим неприятностям. Поэтому формулирование (проектирование) перечня целей и предположений безопасности является обязательным этапом в создании систем secure by design.
А вот включение требований к гарантиям безопасности в перечень целей безопасности не является хорошей практикой: лучше, чтобы цели безопасности были объектом валидации. Требование гарантий «внутри» списка целей приведет к «самоприменению» требования и неразрешимости задачи.
Также тонкий момент заключается в том, что, если заинтересованные лица выставляют требования непосредственно к механизмам безопасности в обход формулирования целей, это может привести к неадекватной или неполной реализации безопасности, перерасходу средств, так называемому «театру безопасности» и другим неприятностям. Поэтому формулирование (проектирование) перечня целей и предположений безопасности является обязательным этапом в создании систем secure by design.
Надеюсь, краткое содержание и слайды будут полезны. А мне будет полезной ваша обратная связь. Задавайте вопросы (лучше в конкретном топике), здесь можно оставить общие комментарии к первому дню.
👍2
Ключевые моменты лекции 1 /
Методическая схема анализа безопасности
На основе Analytical framework из книги Росса Андерсона рассмотрим удобную схему, предназначенную для построения процесса анализа требований к безопасности системы. Отдельно рассматриваются субъективные параметры: мотивы, интересы, побуждения заинтересованных сторон, в числе которых рассматривается нарушитель. Можно построить модель нарушителя, указав его мотивы, интересы, технические и физические возможности и ограничения. Однако не стоит забывать о других заинтересованных сторонах, несовпадении их интересов, которые могут вызывать дополнительные риски. Стороны часто «играют в труса» и попадают в ситуацию «балансирования на грани», если говорить языком теории игр.
Учитывая все объективные описания субъективных интересов, и применяя методы проектирования, создается список целей безопасности и предположений безопасности.
Методическая схема анализа безопасности
На основе Analytical framework из книги Росса Андерсона рассмотрим удобную схему, предназначенную для построения процесса анализа требований к безопасности системы. Отдельно рассматриваются субъективные параметры: мотивы, интересы, побуждения заинтересованных сторон, в числе которых рассматривается нарушитель. Можно построить модель нарушителя, указав его мотивы, интересы, технические и физические возможности и ограничения. Однако не стоит забывать о других заинтересованных сторонах, несовпадении их интересов, которые могут вызывать дополнительные риски. Стороны часто «играют в труса» и попадают в ситуацию «балансирования на грани», если говорить языком теории игр.
Учитывая все объективные описания субъективных интересов, и применяя методы проектирования, создается список целей безопасности и предположений безопасности.
Доброе утро! Вчера поступило некоторое количество вопросов в чате Тимз, сегодня в начале нашей встречи отвечу на все. Обязательно продублирую самые интересные тут. Постараемся сегодня подхватывать вопросы из чата, чтобы отвечать оперативно. Всем хорошего!
Ключевые моменты лекции 2
Место методического подхода
Методический подход к компьютерной безопасности в проектировании систем должен быть встроен в нашу концепцию с целями безопасности и помогать реализовать интересы сторон, которые эти цели определяют. Лучше всего понять место методического подхода помогает схема, приведенная в стандарте ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. Нас этот стандарт переведен как ГОСТ 57100, можно пользоваться любой версией.
Место методического подхода
Методический подход к компьютерной безопасности в проектировании систем должен быть встроен в нашу концепцию с целями безопасности и помогать реализовать интересы сторон, которые эти цели определяют. Лучше всего понять место методического подхода помогает схема, приведенная в стандарте ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description. Нас этот стандарт переведен как ГОСТ 57100, можно пользоваться любой версией.
Архитектуру системы составляют так называемые архитектурные представления (views, например, представление безопасности), созданием которых управляют точки зрения (viewpoints) на архитектуру. Эти точки зрения могут, в том числе, включать относящиеся к безопасности – например, точку зрения на моделирование угроз. Задокументированная точка зрения на архитектуру (а это самый настоящий документ, вот шаблон) ссылается на один или несколько видов моделей (model kind). В свою очередь, модель архитектуры (architecture model), отнесенная к одному из таких описанных видов моделей, составляет часть архитектурного представления.
Computer security basics
Архитектуру системы составляют так называемые архитектурные представления (views, например, представление безопасности), созданием которых управляют точки зрения (viewpoints) на архитектуру. Эти точки зрения могут, в том числе, включать относящиеся к безопасности…
Архитектурный фреймворк по 42010 помогает понять, зачем нужны модели вообще. А вот зачем нужны модели безопасности? Часто модель имеет настолько существенные ограничения, что кажется, детали реализации (так мы называем уязвимости, например 😉) могут сделать ее неприменимой.
Модели безопасности применяются в основном для того, чтобы внятно и формально описать положения политики безопасности и, в конечном счете, определить, выполняется политика безопасности или нет. Хотя у моделей (не только безопасности) много других применений. Подробности можно найти например в книжке «Модельное мышление» - электронная она доступна в корпоративной библиотеке МИФ (не реклама).
Модели безопасности применяются в основном для того, чтобы внятно и формально описать положения политики безопасности и, в конечном счете, определить, выполняется политика безопасности или нет. Хотя у моделей (не только безопасности) много других применений. Подробности можно найти например в книжке «Модельное мышление» - электронная она доступна в корпоративной библиотеке МИФ (не реклама).
Ключевые моменты лекции 2 /
Политики безопасности и модели безопасности
Политики безопасности определяются разнообразнейшим образом. Самый простой – политика безопасности это директива, которая указывает что системе разрешено, а что нет. Самые внимательные слушатели обратили внимание, что определение может быть отнесено не только к security, но и к safety. В самом деле, не разрешено автомобилю ехать в направлении, противоположном движению руля, а химическому производству превышать определенный объем вредных выбросов в окружающую среду. Мы не будем обращать внимание на этот нюанс, тем более что рядом упоминается механизм безопасности – это то, что позволяет политику выполнять.
Модель безопасности – это формальное представление политики безопасности
Политики безопасности и модели безопасности
Политики безопасности определяются разнообразнейшим образом. Самый простой – политика безопасности это директива, которая указывает что системе разрешено, а что нет. Самые внимательные слушатели обратили внимание, что определение может быть отнесено не только к security, но и к safety. В самом деле, не разрешено автомобилю ехать в направлении, противоположном движению руля, а химическому производству превышать определенный объем вредных выбросов в окружающую среду. Мы не будем обращать внимание на этот нюанс, тем более что рядом упоминается механизм безопасности – это то, что позволяет политику выполнять.
Модель безопасности – это формальное представление политики безопасности
Ключевые моменты лекции 2 /
Моделирование контроля доступа
Мы рассматриваем модели контроля доступа, как самые распространенные, и самые актуальные на текущий момент. Модели контроля доступа часто используют матрицу доступа: определяется множество субъектов доступа, множество объектов (включая всех субъектов, которые также являются объектами) и множество прав доступа, субъекты и объекты представляют строки и столбцы матрицы, права содержатся в ячейках. Некоторые права являются базовыми правами доступа (чтение, запись, исполнение и т.п.), другие права – контрольные – они влияют на передачу прав доступа субъектам. Матрица доступа может описать любой вид доступа в системе.
Можно описать систему из шести примитивных команд: создание субъекта, создание объектоа, добавление права доступа в ячейку таблицы, удаление права из ячейки, удаление субъекта, удаление объекта. На основе примитивных команд и условного оператора можно определить операции в системе (например запуск процесса или удаление файла в операционной системе). Так моделируется работа системы с механизмом контроля доступа. Эта модель достаточно выразительна, чтобы описать, что происходит в ОС – и не только, можно описать взаимодействие в распределенных системах, работу межсетевого экрана и т.п.
Моделирование контроля доступа
Мы рассматриваем модели контроля доступа, как самые распространенные, и самые актуальные на текущий момент. Модели контроля доступа часто используют матрицу доступа: определяется множество субъектов доступа, множество объектов (включая всех субъектов, которые также являются объектами) и множество прав доступа, субъекты и объекты представляют строки и столбцы матрицы, права содержатся в ячейках. Некоторые права являются базовыми правами доступа (чтение, запись, исполнение и т.п.), другие права – контрольные – они влияют на передачу прав доступа субъектам. Матрица доступа может описать любой вид доступа в системе.
Можно описать систему из шести примитивных команд: создание субъекта, создание объектоа, добавление права доступа в ячейку таблицы, удаление права из ячейки, удаление субъекта, удаление объекта. На основе примитивных команд и условного оператора можно определить операции в системе (например запуск процесса или удаление файла в операционной системе). Так моделируется работа системы с механизмом контроля доступа. Эта модель достаточно выразительна, чтобы описать, что происходит в ОС – и не только, можно описать взаимодействие в распределенных системах, работу межсетевого экрана и т.п.
👍1
Ключевые моменты лекции 2/
Дискреционный и мандатный контроль доступа
Матрица доступа позволяет описать права доступа на объекты и привилегии субъектов, не зависящие от объекта применения: для привилегии нужно добавить право в ячейку доступа субъекта по отношению к самому себе.
Ранее мы упомянули контрольные права. Они дают ключ к разделению видов контроля доступа.
Дискреционный контроль доступа – это такой, в которой у субъектов внутри модели есть возможность влиять на распределение прав на объекты, в том числе передавать и отнимать права доступа.
Мандатный контроль доступа – у субъектов, вне зависимости от их прав и привилегий, нет возможности влиять на распределение прав на объекты.
Контроль доступа на основе уровней безопасности и т.п. – не является определяющим для мандатной модели! Определяющий фактор для вида контроля доступа – (не)возможность управлять доступом изнутри модели.
Это, кстати, является существенным ограничением для реализации мандатной модели в операционных системах. Для того, чтобы вынести управление доступом «вовне модели», необходимо так продумывать архитектуру системы, чтобы, например, у процессов, которые представляют субъекты, не было реальной возможности никак повлиять на процесс выделения прав и привилегий. Пример такой архитектуры – FLASK.
Дискреционный и мандатный контроль доступа
Матрица доступа позволяет описать права доступа на объекты и привилегии субъектов, не зависящие от объекта применения: для привилегии нужно добавить право в ячейку доступа субъекта по отношению к самому себе.
Ранее мы упомянули контрольные права. Они дают ключ к разделению видов контроля доступа.
Дискреционный контроль доступа – это такой, в которой у субъектов внутри модели есть возможность влиять на распределение прав на объекты, в том числе передавать и отнимать права доступа.
Мандатный контроль доступа – у субъектов, вне зависимости от их прав и привилегий, нет возможности влиять на распределение прав на объекты.
Контроль доступа на основе уровней безопасности и т.п. – не является определяющим для мандатной модели! Определяющий фактор для вида контроля доступа – (не)возможность управлять доступом изнутри модели.
Это, кстати, является существенным ограничением для реализации мандатной модели в операционных системах. Для того, чтобы вынести управление доступом «вовне модели», необходимо так продумывать архитектуру системы, чтобы, например, у процессов, которые представляют субъекты, не было реальной возможности никак повлиять на процесс выделения прав и привилегий. Пример такой архитектуры – FLASK.