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

2. автоматическая система (АС) (защита от MSD информации, классификация АС и требования по защите информации). Все АС делятся на 3 группы. В каждой существует своя иерархия.

Группа 3 – однопользовательские системы.

Делятся на 2 класса.

Класс 3Б – осуществляется проверка подлинности доступа при входе в систему, регистрация входа и выхода, учет используемых носителей (диски и т.д.)

Класс 3А – выполняются все требования класса 3Б + регистрация распечатки документов и физиче­ская очистка очищаемой аппаратной области и внешней памяти.

Группа 2:

Класс 2В – многопользовательские системы, в которых пользователи имеют равные права.

Класс 2Б – проверка подлинности пользователей, регистрация и т.д. (как в 3Б).

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

Группа 1 – многопользовательские системы, в которых пользователи имеют различные полномочия доступа информации.

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

Класс 1Г – предыдущие + избирательные разграничения доступа, регистрация событий, потенци­ально опасных для поддержания безопасности, и физическая очистка очищаемой аппаратной области и внешней памяти.

Класс 1В – предыдущие + полномочные разграничения доступа, усилены требования для поддержа­ния опасных для поддержания защищенности системы, интерактивное оповещение администратора системы о попытках несанкционированного доступа.

Класс 1Б – предыдущие + наличие подсистемы шифрования конфиденциальной информации и ис­пользование сертифицированных алгоритмов.

Класс 1А – предыдущие + различные субъекты доступа используют различные ключи.

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

Сертификация ОС по некоторому классу защиты, как правило, сопровождается составлением требо­ваний к адекватной политике безопасности при неукоснительном выполнении которой защищенность ОС будет соответствовать требованиям защищенности класса защиты.

Вопрос 55: Определение и основные особенности операционных систем реального времени.

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

Система реального времени – это система, в которой успешность работы любой программы зависит не только от её логиче­ской правильности, но и от времени, за которое получен результат. Если временные ограничения не удовлетворены, то фиксируется сбой. Данные требования заставляют систему быть прогнозируемой, т.е. в независимости от своего текущего состояния и загруженно­сти выдавать нужный результат за требуемое время.

Принцип построения:

Различают сильные hart и слабые soft требования реального времени. Если запаз­дывание программы приводит к полному на­рушению работы управляющей системы, то говорят о сильном реальном времени. Если это ведет только к потере производительности, то говорят о слабом реальном времени.

Стандарт POSIX 1003:1 описывает требования:

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

- Обычные компьютеры – служат как терминалы для взаимодействия с промышлен­ными компьютерами и непосредст­венно для управления промыш­ленным или иным оборудованием не используются.

- Промышленные компьютеры – состоят из одной платы, на которой размещены процессор, память, контроллеры шины, разъемы для подключения внешних устройств. VME или компакт PCI – в качестве шины. Отсутствует жесткий диск, в качестве памяти ОЗУ или flash. Плата в специализированном корпусе, в котором блок питания, подводят контакты шины. Используется для управления промышленным оборудованием. Нет клавиатуры и монитора.

- Встраиваемая система – устанавливается внутри оборудования, которым управ­ляет.

Типы задач:

§ Циклические задачи (для процессов управления)

§ Периодические задачи

§ Импульсные задачи

Типы архитектур:

· Монолитная

· Модульная

· Объектная

Монолитную архитектуру можно представить в виде прикладного уровня, состоя­щего из системного уровня, который пред­ставляется монолитным ядром, в котором выде­ляется интерфейс между приложением и ядром, непосредственно ядром, ядром и оболоч­кой. Интерфейс управляет взаимодействием прикладных процессов и систем, обеспечи­вает непрерывность выполнения кода системы, т.е. отсутствия переключения задач во время выполнения кода системы, иначе выполнение запроса неограниченное количе­ство времени. Достоинство состоит в относительной быстроте работы по сравнению с другими архитектурами за счет разработки сис­темы на ASSEMBLER. Недостатки в том, что ядро не может быть прервано пользовательской задачей (невытесняющая многозадач­ность), и сложность переноса на новые архитектуры процессора.

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

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

Системы реального времени делятся на 3 слоя:

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

2. система управления, которая содержит ядро и дополнительные сервисы, рас­ширяющие возможности ядра, – файло­вая система, взаимодействие сис­темы и управляющего оборудования.

3. система управления и набор дополнительных утилитов, таких как средства разработки, отладки, визуализации и т.д.

Критерии выбора:

· производительность

· надежность

· круглосуточная готовность

· поддержка различных типов процессора

· поддержка многопроцессорности

· наличие средств разработки на различных языках

· 67аличние механизмов реального времени

· Поддержка файловой системы

Роль управляющей системы ОСРВ:

- Управление взаимным исключением и взаимодействием задач

- Предоставляет приложению основные возможности по управлению временем, устройствами, взаимодействию с операто­ром.

- Предоставляет набор библиотечных функций для доступа к возможностям сис­темы

- Занимается планированием задачи

Синхронизация и взаимодействие процессов:

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

Ø Безопасное взаимодействие, когда обмен данными осуществляется посредством объектов взаимодействия, предоставляе­мые системой, т.е. целость информации обеспечивает сама ОСРВ.

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

Все ОСРВ предоставляют приложениям определенный набор объектов синхрони­зации:

POSIX 1003: В определяет объекты синхронизации (должны присутствовать семафоры, очереди сообще­ний и разделяемая память).

POSIX 1003: С определяет объект синхронизации, которые присутствуют в систе­мах, использующие задачи: MUTEX, COUDVAR.

Объект MUTEX представляет собой развитие семафоров, которые состоят из се­мафоров и идентификатора задач, который определяет текущего владельца. Для доступа к MUTEX три операции:

1. lock – блокировать MUTEX. Если он заблокирован другой задачей, то эта опе­рация переводит в состояние ожида­ния разблокирования.

2. unlock – разблокировать объект.

3. try lock – попробовать блокировать MUTEX, если MUTEX не заблокирован, то она эквивалентна lock.

Объекты MUTEX:

ü Локальные и доступные для синхронизации между потоками одного про­цесса.

ü Глобальные и доступные для синхронизации между потоками различных про­цессов.

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

Планирования задач (алгоритмы FIFO и т.д.) и прерывания и т.д. смотреть за 4 се­местр.

Встроенные ОС (ВОС)

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

Принцип создания:

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

2. ВОС должна быть пригодна для переноса на другие аппаратные платформы. Достигается за счет разделения ОС на ап­паратно-зависимую и аппаратно-независимую части. Аппаратно-зависимая часть пишется на assembler и при пе­реносе на другую платформу полностью переписывается. Результатом стремления сделать эту часть как можно меньше стало микроядро. Аппаратно-независимая часть пишется на Си и включает выполнение алгоритмических функциях.

3. ВОС должна представлять собой унифицированный и стандартный интерфейс для прикладных программ (напри­мер, POSIX).

4. ВОС должна быть ОС реального времени.

5. ВОС должна быть многозадачной (эффективные методы выполнения параллельно работающих программ).

6. ВОС должна обеспечивать механизм отладки как самой себя, так и прикладных программ.

7. ВОС должна поддерживать механизм коммуникативности и взаимодействия с другими системы, поддерживаю­щие определенные сетевые протоколы.

8. ВОС должна иметь малый объем ядра.

Механизмы:

1) Начальная загрузка

2) Управление процессами (2 стандарта – вытесняющая многозадачность либо разделение по времени)

3) Механизм межпроцессорного взаимодействия (сообщения, сигналы, каналы и т.д.)

4) Управление памятью

5) Обработка прерываний

6) Доступ к периферическим устройствам (поддержка специализированного интерфейса, посредством ввода-вы­вода, порты ввода-вывода)

7) Поддержка различных коммуникативных протоколов (должны поддерживать стандартные коммуникативные прото­колы (изернет, Win 32, USB)

Архитектура:

APP

Пользовательский уровень

микроядро

ОС

Аппаратура

APP – приложение пользователя

1 – механизм межпроцессорного взаимодействия

2 – планировщик выполнения задач

3 –управление памятью

4 – коммуникативные протоколы

5 – драйверы устройств

6 – начальный загрузчик

7 – обработчик прерываний

8 –подсистема ввода – вывода

Вопрос 56: Sels / Hosted и Host / Target ОСРВ. Основные характеристики.

Обзор ОС реального времени

По способу разработки программного обеспечения:

1. Sell – HOSTED

2. HOST – TARGET

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

HOST – TARGET – это системы, в которых ОС или компьютер, на котором разра­батываются приложения, и ОС и компьютер, на котором запускаются приложения, раз­личны.

В качестве HOST выступают обычные компьютеры Windows NT, а в качестве TARGET – промышленные ком­пьютеры или встраиваемые компьютеры под управлением ОСРВ.

В зависимости от происхождения ОСРВ:

ü Обычные ОС, использующие в качестве ОСРВ (к обычным ОС добавляются модули, осуществляю­щие взаимодействие со специализированным оборудованием, и добавляется драйвер для работы с данным уст­ройством). Может использоваться алгоритм планирования задач. Взяли NT, взяли приложение, использующее реаль­ное время, из NT сделали приложение реального времени.

ü Собственно специализированная ОСРВ (host и т.д.)

ü ОСРВ, разработанная для конкретного микроконтроллера.

Примеры систем