77. Захист інформації

Засоби захисту інформації вбудовані в NetWare на базових рівнях операційної системи, а не є надбудовою у вигляді якого-небудь додатку. Оскільки NetWare використовує на файл-сервері особливу структуру файлів, то користувачі не можуть отримати доступ до мережних файлів, навіть якщо вони отримають фізичний доступ до файла-сервера.

Операційні системи NetWare містять механізми захисту наступних рівнів:

• захист інформації про користувача;

• захист паролем;

• захист каталогів;

• захист файлів;

• міжмережний захист.

У 1983 році фірма Novell ввела в систему концепцій локальної мережі поняття імені користувача, пароля і характеристики користувача (user profile). Характеристика користувача містить перелік ресурсів, до яких користувач має доступ, і правий, якими він володіє при роботі з цими ресурсами. Адміністратор мережі може обмежити права користувача по входу в мережу датою, часом і конкретними робочими станціями. Засоби виявлення порушень захисту і блокування дій порушника сповіщають адміністратора мережі про спроби несанкціонованого доступу.

У версії NetWare 3.12 паролі зберігаються на сервері в зашифрованому вигляді. Пароль, що задається користувачем, передається по кабелю також в зашифрованому вигляді, що забезпечує захист від спроб дізнатися пароль шляхом "прослуховування" мережі.

У версії NetWare 4.x використана більш надійна схема ідентифікації користувача при логічному вході в мережу, заснована на використанні технології захисту RSA public key/private key. При використанні цієї технології пароль і особистий ключ користувача ніколи не передаються по кабелях, що повністю виключає можливість дізнатися чужий пароль. У службу каталогів NDS також введений новий рівень управління доступом, який може бути введений в дію адміністратором в будь-якій частині мережі.

З точки зору захисту ОС NetWare не робить відмінності між операційними системами робочих станцій. Станції, працюючі під управлінням DOS, Windows, OS/2, Macintosh і UnixWare, обслуговуються абсолютно однаково, і всі функції захисту застосовуються до всіх операційних систем, які можуть використовуватися в мережі NetWare.

78. Переносимість та совмісність програмного забезпечення ос

Переносимость

Вимога переносимості коду тісно пов'язана з розширюваністю. Розширюваність дозволяє покращувати операційну систему, тоді як переносимість дає можливість переміщати всю систему на машину, що базується на іншому процесорі або апаратній платформі, роблячи при цьому по можливості невеликі зміни в коді. Хоча ОС часто описуються або як переносимі, або як нестерпні, переносимість - це не бінарний стан. Питання не в тому, чи може бути система перенесена, а в тому, наскільки легко можна це зробити. Написання переносимій ОС аналогічно написанню будь-якого переносимого коду - потрібно слідувати деяким правилам.

По-перше, велика частина коду повинна бути написана на мові, яка є на всіх машинах, куди ви хочете переносити систему. Зазвичай це означає, що код повинен бути написаний на мові високого рівня, переважно стандартизованном, наприклад, на мові З. Програма, написана на асемблері, не є переносимою, якщо тільки ви не збираєтеся переносити її на машину, що володіє командною сумісністю з вашою.

По-друге, слід врахувати, в яке фізичне оточення програма повинна бути перенесена. Різна апаратура вимагає різних рішень при створенні ОС. Наприклад, ОС, побудована на 32-бітових адресах, не може бути перенесена на машину з 16-бітовими адресами (хіба що з величезними труднощами).

По-третє, важливо мінімізувати або, якщо можливо, виключити ті частини коду, які безпосередньо взаємодіють з апаратними засобами. Залежність від апаратури може мати багато форм. Деякі очевидні форми залежності включають пряме маніпулювання регістрами і іншими апаратними засобами.

По-четверте, якщо апаратний залежний код не може бути повністю виключений, то він повинен бути ізольований в декількох модулях, що добре локалізуються. Апаратно-залежний код не повинен бути розподілений по всій системі. Наприклад, можна заховати апаратно-залежну структуру в дані абстрактного типу, що програмно-задаються. Інші модулі системи працюватимуть з цими даними, а не з апаратурою, використовуючи набір деяких функцій. Коли ОС переноситься, то змінюються тільки ці дані і функції, які ними маніпулюють.

Для легкого перенесення ОС при її розробці повинні бути дотримані наступні вимоги:

• Переносима мова високого рівня. Більшість переносимих ОС написана на мові З (стандарт ANSI X3.159-1989). Розробники вибирають З тому, що він стандартизован, і тому, що С-компілятори широко доступні. Асемблер використовується тільки для тих частин системи, які повинні безпосередньо взаємодіяти з апаратурою (наприклад, обробник переривань) або для частин, які вимагають максимальної швидкості (наприклад, цілочисельна арифметика підвищеної точності). Проте нестерпний код повинен бути ретельно ізольований усередині тих компонентів, де він використовується.

• Ізоляція процесора. Деякі низькорівневі частини ОС повинні мати доступ до процесорний-залежних структур даних і регістрів. Проте код, який робить це, повинен міститися в невеликих модулях, які можуть бути замінені аналогічними модулями для інших процесорів.

• Ізоляція платформи. Залежність від платформи полягає у відмінностях між робочими станціями різних виробників, побудованими на одному і тому ж процесорі (наприклад, MIPS R4000). Повинен бути введений програмний рівень, що абстрагує апаратуру (кеші, контроллери переривань введення-висновку і т. п.) разом з шаром низькорівневих програм так, щоб високорівневий код не потребував зміни при перенесенні з однієї платформи на іншу.

• Сумісність

Одним з аспектів сумісності є здатність ОС виконувати програми, написані для інших ОС або для раніших версій даної операційної системи, а також для іншої апаратної платформи.

Необхідно розділяти питання двійкової сумісності і сумісності на рівні початкових текстів застосувань. Двійкова сумісність досягається у тому випадку, коли можна узяти виконувану програму і запустити її на виконання на іншій ОС. Для цього необхідні: сумісність на рівні команд процесора, сумісність на рівні системних викликів і навіть на рівні бібліотечних викликів, якщо вони є динамічно зв'язуваними.

Сумісність на рівні початкових текстів вимагає наявність відповідного компілятора у складі програмного забезпечення, а також сумісності на рівні бібліотек і системних викликів. При цьому необхідна перекомпіляція наявних початкових текстів в новий виконуваний модуль.

Сумісність на рівні початкових текстів важлива в основному для розробників застосувань, у розпорядженні яких ці початкові тексти завжди є. Але для кінцевих користувачів практичне значення має тільки двійкова сумісність, оскільки тільки в цьому випадку вони можуть використовувати один і той же комерційний продукт, що поставляється у вигляді двійкового виконуваного коду, в різних операційних середовищах і на різних машинах.

Чи володіє нова ОС двійковою сумісністю або сумісністю початкових текстів з існуючими системами, залежить від багатьох чинників. Найголовніший з них - архітектура процесора, на якому працює нова ОС. Якщо процесор, на який переноситься ОС, використовує той же набір команд (можливо з деякими додаваннями) і той же діапазон адрес, тоді двійкова сумісність може бути досягнута досить просто.

Набагато складніше досягти двійкової сумісності між процесорами, заснованими на різній архітектурі. Для того, щоб один комп'ютер виконував програми іншого (наприклад, DOS-програму на Mac), цей комп'ютер повинен працювати з машинними командами, які йому спочатку незрозумілі. Наприклад, процесор типу 680x0 на Mac повинен виконувати двійковий код, призначений для процесора 80x86 в РС. Процесор 80x86 має свої власні дешифратор команд, регістри і внутрішню архітектуру. Процесор 680x0 не розуміє двійковий код 80x86, тому він повинен вибрати кожну команду, декодувати її, щоб визначити, для чого вона призначена, а потім виконати еквівалентну підпрограму, написану для 680x0. Оскільки до того ж у 680x0 немає в точності таких же регістрів, прапорів і внутрішнього арифметико-логічного устрою, як в 80x86, він повинен імітувати всі ці елементи з використанням своїх регістрів або пам'яті. І він повинен ретельно відтворювати результати кожної команди, що вимагає спеціально написаних підпрограм для 680x0, що гарантують, що стан емульованих регістрів і прапорів після виконання кожної команди буде в точності таким же, як і на реальному 80x86.

Це проста, але дуже повільна робота, оскільки мікрокод усередині процесора 80x86 виконується на значно більш швидкодіючому рівні, ніж що емулюють його зовнішні команди 680x0. За час виконання однієї команди 80x86 на 680x0, реальний 80x86 може виконати десятки команд. Отже, якщо процесор, що проводить емуляцію, не настільки швидкий, щоб компенсувати всі втрати при емуляції, то програми, що виконуються під емуляцією, будуть дуже повільними.

Виходом в таких випадках є використання так званих прикладних середовищ. Враховуючи, що основну частину програми, як правило, складають виклики бібліотечних функцій, прикладне середовище імітує бібліотечні функції цілком, використовуючи наперед написану бібліотеку функцій аналогічного призначення, а решту команд емулює кожну окремо.

Відповідність стандартам POSIX також є засобом забезпечення сумісності програмних і призначених для користувача інтерфейсів. У другій половині 80-х урядові агентства США почали розробляти POSIX як стандарти на устаткування, що поставлялося, при укладенні урядових контрактів в комп'ютерній області. POSIX - це "інтерфейс переносимої ОС, що базується на UNIX". POSIX - збори міжнародних стандартів інтерфейсів ОС в стилі UNIX. Використання стандарту POSIX (IEEE стандарт 1003.1 - 1988) дозволяє створювати програми стилі UNIX, які можуть легко переноситися з однієї системи в іншу.