ніх ЕЛЕМЕНТІВ. У 2003 р. прийнятя нова редакція цього стандарту. ARINC-653 в якості одного з основних вимог для ОСРВ в АВІАЦІЇ вводити архітектуру ізольованіх (partitioning) віртуальніх машин.
OSEK Стандарт OSEK/VDX є комбінацією стандартів, Які спочатку розробляліся в двох окрем консорціумах, Згідно злилася. OSEK бере свою Назву від німецького акронімі консорціуму, до складу Якого входили провідні Німецькі Виробники автомобилей - BMW, Bosch, Daimler Benz (тепер Daimler Chrysler), Opel, Siemens и Volkswagen, а такоже университет в Карлсруе (Німеччіна). Проект VDX (Vehicle Distributed eXecutive) розвівався спільнімі зусилля французьких компаний PSA и Renault. Команди OSEK и VDX злився в 1994р. p> Спочатку проект OSEK/VDX прізначався для розробки стандарту Відкритої архітектури ОС и стандартом API для систем, что застосовуються в автомобільній промісловості. Прото Розроблення стандарт Вийшов більш абстрактними и НЕ обмежується Використання Тільки в автомобільній індустрії. p> Стандарт OSEK/VDX Складається з трьох частин - стандарт для операційної системи (OS), комунікаційній стандарт (COM) i стандарт для мережевих менеджера (NM). На додаток до ціх стандартів візначається Якийсь реалізаційній мова (OIL). Дерло компонентом стандарту OSEK є стандарт для ОС, тому часто стандарт OSEK помилковості спріймається як стандарт ОСРВ. Хочай ОС и є велика Порція даного стандарту, Потужність его Полягає в інтеграції всех его компонент. p> У даній работе розглядається Тільки стандарт для операційної системи, и его описание наводитися у розділі 2.7.
Стандарти безпеки
У зв'язку до стандартів для ОСРВ Варто відзначіті широко відомій стандарт крітеріїв ОЦІНКИ прідатності комп'ютерних систем (Trusted Computer System Evaluation Criteria - TCSEC) [DoD85]. Цею стандарт розроблення Міністерством оборони США и відомій такоже под назви "Помаранчева книга" (Orange Book - через колір обкладинки). p> У ряді других країн були розроблені аналогічні КРИТЕРІЇ, на Основі якіх БУВ Створений міжнародний стандарт "Загальні КРИТЕРІЇ ОЦІНКИ безпеки ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ "(далі просто - Загальні КРИТЕРІЇ) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) [CC99]. p> У "Помаранчевої Книзі" перераховані сім рівнів захисту:
В· А1 - веріфікована розробка. Цею рівень вімагає, щоб захист секретної та іншої критичність ІНФОРМАЦІЇ засобой управління БЕЗПЕКА гарантувалі методи формальної веріфікації. p> В· В3 - домени безпеки. Цею рівень призначеня для захисту систем від досвідченіх програмістів. p> В· В2 - Структуровано захист. У систему з ЦІМ рівнем захисту НЕ можна допустити, проникнення хакерів. p> В· В1 - мандатна контроль доступу. Захист цього уровня, Можливо, вдасть подолати досвідченому хакеру, альо Ніяк НЕ Рядові Користувачи. p> В· С2 - діскреційній контроль доступу. Рівень С2 Забезпечує захист процедур входу, дозволяє Проводити контроль за подіямі, что мают відношення до безпеки, а такоже ізолюваті ресурси. p> В· С1 - виборча захист. Цею рівень Дає Користувач можлівість захістіті Особисті дані чг інформацію про проект, ВСТАНОВИВ засоби управління доступом. p> В· D - Мінімальна захист. Цею Нижній рівень захисту залишенню для систем, Які проходили тестування, альо НЕ змоглі задовольніті Вимогами більш високого класу. p> Що стосується загально крітеріїв, то в них введено Схожі вимоги забезпечення безпеки у вігляді оціночніх рівнів (Evaluation Assurance Levels - EAL). Їх такоже сім:
В· EAL7 - Найвищий рівень пріпускає формальність веріфікацію МОДЕЛІ об'єкта ОЦІНКИ. ВІН застосовній до систем Дуже високого ризику. p> В· EAL6 візначається, як напівформально Веріфікованій и протестованій. На Рівні EAL6 реалізація винна буті представлена ​​в структурованому вігляді, аналіз відповідності пошірюється на проект Нижнього уровня, проводитися суворий аналіз покриття, аналіз и тестування небезпечних станів. p> В· EAL5 візначається, як напівформально спроектованій и протестованій. ВІН передбачає создания напівформально функціональної спеціфікації та проекту високого уровня з демонстрацією відповідності между ними, формальної МОДЕЛІ політики безпеки, стандартізованої МОДЕЛІ життєвого циклу, а такоже проведення аналізу ПРИХОВАНЕ каналів. p> В· EAL4 візначається, як методично спроектованій, протестованій и переглянутися. ВІН пріпускає наявність автоматізації управління конфігурацією, повної спеціфікації інтерфейсів, Описова проекту Нижнього уровня, підмножіні реалізацій функцій безпеки, неформальної МОДЕЛІ політики безпеки, Моделі життєвого циклу, аналіз валідації, незалежний аналіз вразливостей. За всій імовірності, це Найвищий рівень, Якого можна досягті на даним етапі розвітку технології програмування з Прийнятних витратами. p> В· EAL3 візначається, як методично протестованій и перевіреній. На Рівні EAL3 здійснюється більш повне, ніж На Рівні EAL2, тестування покриття функцій безпеки, а такоже контроль середовища розробки й управління конфі...