Багаторівнева безпека — застосування комп'ютерної системи для обробки інформації з несумісними класифікаціями (тобто з різними рівнями безпеки), надання доступу користувачам з різними дозволами безпеки та потреби знати, а також запобігання користувачам від отримання доступу до інформації, на яку вони не мають дозволу. Існує два контексти використання багаторівневої безпеки. Одне з них — це система, яка є адекватною для захисту від підривної діяльності та має надійні механізми відокремлення інформаційних доменів, тобто заслуговує на довіру. Інший контекст — це посилання на програму комп'ютера, яка вимагає, щоб комп'ютер був достатньо потужним, щоб захистити себе від підривної діяльності та володіти адекватними механізмами для розділення інформаційних доменів, тобто системи, якій ми повинні довіряти. Ця відмінність є важливою, оскільки системи, яким потрібно довіряти, не обов'язково заслуговують довіри.
Надійні операційні системи Операційне середовище MLS часто потребує високонадійної системи обробки інформації, яка часто побудована на операційній системі MLS (ОС), але не обов'язково. Більшість функціональних можливостей MLS може підтримуватися системою, яка повністю складається з ненадійних комп'ютерів, хоча для цього потрібні кілька незалежних комп'ютерів, пов'язаних за допомогою каналів, що відповідають вимогам безпеки (див. розділ B.6.2 Інтерпретації довірених мереж, NCSC-TG-005). Прикладом апаратного забезпечення MLS є асиметрична ізоляція. Якщо один комп'ютер використовується в режимі MLS, то цей комп'ютер повинен використовувати надійну операційну систему (ОС). Оскільки вся інформація в середовищі MLS є фізично доступною для ОС, повинні існувати сильні логічні засоби контролю, щоб забезпечити суворий контроль доступу до інформації. Зазвичай це передбачає обов'язковий контроль доступу, який використовує мітки безпеки, такі як наприклад модель Бела–ЛаПадули.
Клієнти, які встановлюють надійні операційні системи, зазвичай вимагають, щоб продукт завершив офіційну оцінку безпеки комп'ютера. Оцінка є суворішою для більш широкого діапазону безпеки, який є найнижчим і найвищим рівнями класифікації, які може обробляти система. Критерії оцінки надійної комп'ютерної системи (TCSEC) були першими критеріями оцінки, розробленими для оцінки MLS в комп'ютерних системах. Відповідно до цих критеріїв існувало чітке уніфіковане зіставлення між вимогами безпеки та широтою діапазону безпеки MLSCSC-STD-004-85: Computer Security Requirements — Guidance For Applying The Department Of Defense Trusted Computer System Evaluation Criteria In Specific Environments (25 червня 1985). Історично невелика кількість реалізацій було сертифіковано для обробки MLS з діапазоном безпеки від Несекретно через Цілком таємно. Серед них були Honeywell SCOMP, USAF SACDIN, NSA Blacker і Boeing MLS LAN, всі під TCSEC, 1980-х років і на основі Intel 80386 . Наразі продукти MLS оцінюються за Загальними критеріями . Наприкінці 2008 року перша операційна система (докладніше нижче) була сертифікована на високий рівень гарантії оцінки: Evaluation Assurance Level (EAL) — EAL 6+ / High Robustness, під егідою урядової програми США, яка вимагає багаторівневої безпеки в умовах високої загрози. середовище. Хоча цей рівень впевненості має багато подібності зі старою Orange Book A1 (наприклад, формальні методи), функціональні вимоги зосереджені на принциповій ізоляції та політиці потоку інформації, а не на політиці вищого рівня, як-от Bell-La Padula. Оскільки Загальні критерії відокремлювали поєднання впевненості (EAL) і функціональності (Профіль захисту), чітке уніфіковане відображення між вимогами безпеки та можливостями діапазону безпеки MLS, задокументовані в CSC-STD-004-85, було значною мірою втрачено, коли Загальні критерії замінили Серія Веселка .
Вільно доступні операційні системи з деякими функціями, які підтримують MLS, включають Linux з увімкненою функцією Security-Enhanced Linux і FreeBSD. Раніше вважалося, що оцінка безпеки є проблемою для цих безкоштовних реалізацій MLS з трьох причин:
Завжди дуже важко реалізувати стратегію самозахисту ядра з точністю, необхідною для довіри MLS, і ці приклади не були розроблені або не сертифіковані для профілю захисту MLS, тому вони можуть не забезпечувати самозахист, необхідний для підтримки MLS. Окрім рівнів EAL, у Загальних критеріях відсутній перелік відповідних профілів захисту високої впевненості, які визначають надійність, необхідну для роботи в режимі MLS. Навіть якщо (1) і (2) виконано, процес оцінки є дуже дорогим і накладає спеціальні обмеження на контроль конфігурації оцінюваного програмного забезпечення.
Незважаючи на такі припущення, Red Hat Enterprise Linux 5 був сертифікований відповідно до LSPP, RBACPP та CAPP на EAL4+ у червні 2007 року Він використовує Security-Enhanced Linux для впровадження MLS і був першою сертифікацією Common Criteria для забезпечення властивостей безпеки TOE з Security-Enhanced Linux.
Стратегії сертифікації постачальників можуть ввести в оману неспеціалістів. Звичайна стратегія використовує надмірну увагу неспеціалістів на рівні EAL із надмірною сертифікацією, як-от сертифікація профілю захисту EAL 3 (наприклад, CAPP) на підвищених рівнях, наприклад EAL 4 або EAL 5. Іншим є додавання та сертифікація функцій підтримки MLS (таких як профіль захисту контролю доступу на основі ролей (RBACPP) і позначений профіль захисту безпеки (LSPP)) до ядра, яке не оцінюється як профіль захисту, що підтримує MLS. Ці типи функцій є службами, які працюють на ядрі і залежать від ядра, щоб захистити їх від пошкодження та підривної діяльності. Якщо ядро не оцінено як профіль захисту, що підтримує MLS, функціям MLS не можна довіряти, незалежно від того, наскільки вражаюче виглядає демонстрація. Особливо варто відзначити, що CAPP спеціально не є профілем MLS, оскільки він спеціально виключає можливості самозахисту, критичні для MLS.
General Dynamics пропонує PitBull, надійну операційну систему MLS. Наразі PitBull пропонується лише як розширена версія Red Hat Enterprise Linux, але попередні версії існували для Sun Microsystems Solaris, IBM AIX та SVR4 Unix. PitBull надає механізм безпеки Bell LaPadula, механізм цілісності Biba, заміну привілеїв для суперкористувача та багато інших функцій. PitBull має базу безпеки для продукту General Dynamics Trusted Network Environment (TNE) з 2009 року. TNE забезпечує багаторівневий обмін інформацією та доступ для користувачів у Міністерстві оборони та розвідувальних спільнотах, які працюють на різних рівнях класифікації. Це також основа для багаторівневої коаліції, розширеної системи збору та експлуатації інформації Battlefield (BICES-X).
Sun Microsystems, тепер Oracle Corporation, пропонує Solaris Trusted Extensions як інтегровану функцію комерційних ОС Solaris і OpenSolaris . На додаток до профілю захисту контрольованого доступу (CAPP) і профілів захисту доступу на основі ролей (RBAC), довірені розширення також були сертифіковані в EAL4 на маркований профіль захисту безпеки (LSPP). Ціль безпеки включає як настільні, так і мережеві функції. LSPP передбачає, що користувачі не мають права замінювати політику маркування, яка застосовується ядром і X Window System (сервер X11). Оцінка не включає аналіз прихованого каналу . Оскільки ці сертифікати залежать від CAPP, жодні сертифікати Common Criteria не свідчать про те, що цей продукт є надійним для MLS.
BAE Systems пропонує з «високою впевненістю» комерційну систему XTS-400, яка підтримує MLS. Попередні продукти (включаючи XTS-300) були оцінені на рівні TCSEC B3, який підтримує MLS. XTS-400 був оцінений за загальними критеріями на EAL5+ щодо профілів захисту CAPP та LSPP. CAPP і LSPP обидва є профілями захисту EAL3, які за своєю суттю не підтримують MLS, але ціль безпеки для оцінки цього продукту за загальними критеріями містить розширений набір функцій безпеки, які забезпечують можливість MLS.
Проблемні зони Проблемною зоною для систем MLS є дезінфекція. Системи, які реалізують обмеження MLS, як ті, які визначені моделлю Белла–ЛаПадули, дозволяють ділитися лише тоді, коли це явно не порушує обмеження безпеки. Користувачі з меншими дозволами можуть легко поділитися своєю роботою з користувачами, які мають більший дозвіл, але не навпаки. Не існує ефективного та надійного механізму, за допомогою якого користувач із цілковито секретним доступом може редагувати файл із абсолютним секретом, видаляти всю таємну інформацію, а потім доставляти її користувачам із секретними або меншими дозволами. На практиці системи MLS обходять цю проблему за допомогою привілейованих функцій, які дозволяють надійному користувачеві обійти механізм MLS і змінити класифікацію безпеки файлу. Однак методика не є надійною .
Приховані канали створюють ще одну проблему для систем MLS. Щоб система MLS ідеально зберігала секрети, не повинно бути жодного можливого способу для процесу «Совершенно таємно» передавати будь-які сигнали до секретного або нижчого процесу. Це включає побічні ефекти, такі як зміни доступної пам'яті або дискового простору, або зміни часу процесу. Коли процес використовує такий побічний ефект для передачі даних, він використовує прихований канал. Закрити всі приховані канали в практичній обчислювальній системі надзвичайно важко, а на практиці це може бути неможливо. Процес виявлення всіх прихованих каналів сам по собі є складним. Більшість комерційно доступних систем MLS не намагаються закрити всі приховані канали, навіть незважаючи на те, що це робить непрактичним їх використання в програмах високої безпеки.
Обхід є проблематичним, якщо він вводиться як засіб для обробки високого об'єкта системи, як ніби він довірений MLS. Поширеним прикладом є вилучення даних із секретного системного об'єкта високого рівня для надсилання до несекретного місця призначення, посилаючись на деякі властивості даних як надійний доказ того, що вони «справді» несекретні (наприклад, «суворий» формат). Системі високого рівня не можна довіряти, щоб зберегти будь-які довірені докази, і в результаті відкривається відкритий шлях даних без логічного способу безпечного посередництва. Обхід може бути ризикованим, оскільки, на відміну від прихованих каналів із вузькою пропускною здатністю, які важко використовувати, обхід може спричинити великий, легковикористаний відкритий витік у системі. Обхід часто виникає через невикористання надійного операційного середовища для підтримки безперервного розділення доменів безпеки на всьому шляху до їх походження. Якщо це джерело лежить за межами системи, може бути неможливим підтвердити надійне розділення з джерелом. У цьому випадку ризик байпасу може бути неминучим, якщо потік дійсно є важливим.
Поширеним прикладом неминучого обходу є суб'єктна система, яка зобов'язана приймати секретні IP-пакети від ненадійного джерела, шифрувати секретні дані користувача, і передавати результат у ненадійну мережу. Джерело лежить поза сферою впливу предметної системи. Хоча джерело є ненадійним (наприклад, високим рівнем системи), йому довіряють так, ніби це MLS, оскільки воно надає пакети, які мають некласифіковані заголовки та секретні відкриті текстові дані користувача, конструкцію даних MLS. Оскільки джерело не є надійним, воно може бути пошкодженим і помістити секрети в заголовок некласифікованого пакета. Пошкоджені заголовки пакетів можуть бути безглуздими, але суб'єктна система не може визначити це з будь-якою розумною надійністю. Пакетні дані користувача криптографічно добре захищені, але заголовок пакета може містити секрети, які можна читати. Якщо суб'єктна система передає пошкоджені пакети в недовірену мережу, вони можуть бути недоступними для маршрутизації, але якийсь взаємодіючий пошкоджений процес у мережі може захопити пакети та підтвердити їх, і суб'єктна система може не виявити витік. Це може бути великий явний витік, який важко виявити. Перегляд секретних пакетів з некласифікованими заголовками як структур високої системи замість структур MLS, якими вони насправді є, є дуже поширеною, але серйозною загрозою.