Выбор оптимальных сетевых решений на базе многозадачных операционных систем для построения компьютерной сети вуза

. диспетчера ввода-вывода (I/O Manager);

. монитора безопасности (Security Reference Monitor). Монитор безопасности

совместно с процессом входа в систему (Logon) и защищенными подсистемами

реализует модель безопасности Windows NT.

Верхний уровень исполняющей системы называется системным сервисом (System

Services). Системный сервис представляет собой интерфейс между подсистемами

среды пользовательского режима и привилегированным режимом. Последующие

разделы описывают назначение каждой составляющей исполняющей системы.

Диспетчер объектов

Объектами являются отдельные элементы времени выполнения, имеющие объектный

тип; управление этими элементами могут производить процессы операционной

системы. Тип объекта включает определенный системой тип данных, список

операций, которые могут выполняться над ним (например, wait, create или

cancel), и набор атрибутов объекта. Диспетчер объектов является частью

исполняющей системы Windows NT и обеспечивает уннфицирован-ные правила

хранения, именования и безопасности объектов.

Прежде чем процесс сможет управлять объектом Windows NT, он должен получить

описатель объектов (object handle) через диспетчер объектов. Описатель

объектов включает информацию управления доступом и непосредственно

указатель на объект. Все описатели объектов создаются через диспетчер

объектов.

В связи с постоянным развитием и совершенствованием технологий, диспетчер

объектов, как и другие компоненты Windows NT, может быть расширен за счет

определения новых типов объектов.

Кроме того, диспетчер объектов управляет глобальным пространством имен

(namespace) для Windows NT и следит за созданием и использованием объектов

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

именованным объектам, которые содержатся в локальной компьютерной среде.

Ниже представлен список объектов, которые могут иметь имена:

. объекты каталога (directory objects);

. объекты типа объекта (object type objects):

. символические объекты связи (symbolic link objects);

. объекты семафора и события (semaphore objects, event objects);

. объекты процесса и нитей травления (process objects, thread objects);

. объекты раздела и сегмента (section objects, segment objects);

. объекты порта (port objects);

. объекты файла (File objects).

Пространство имен объектов по своей организации подобно иерархии файловой

системы, для которой имена каталога в пути отделяются обратной наклонной

чертой (\). Запись имени объекта в подобной форме можно наблюдать после

двойною щелчка кнопкой мыши па каком-либо элементе в Event Viewer.

Диспетчер процессов

Диспетчер процессов — компонент, который отслеживает два типа объектов;

объекты процесса и объекты нитей правления. Процесс определяется как

адресное пространство, набор доступных процессу объектов и совокупность

выполняемых в контексте процесса нитей управления. Нить управления (thread)

является основным управляемым элементом в системе. Она имеет собственный

набор регистров, собственный стек ядра, блок среды нити и стек пользователя

в адресном пространстве процесса.

Диспетчер процессов — компонент Windows NT, который управляй созданием и

завершением процессов. Он обеспечивает набор стандартных услуг по созданию

и использованию нитей управления и процессов в контексте специфической

среды подсистемы. Кроме того, диспетчер процессов в некоторой степени

диктует правка для нитей и процессов. Дополнительно, Windows NT позволяет

подсистемам среды определять для них специфические правота.

Диспетчер процессов не налагает каких-либо требований по иерархии или

группировке для процессов, а также не определяет отношений порожденности.

Модель процессов Windows NT работает совместно с моделью безопасности и

диспетчером виртуальной памяти для обеспечения безопасности процессов.

Каждому процессу назначается маркер безопасного доступа (security access

token), называемый первичным маркером процесса. Этот маркер используется

процедурами проверки правильности доступа Windows NT, когда нити управления

процесса ссылаются па защищенные объекты.

Диспетчер виртуальной памяти

Архитектура памяти для Windows NT основана на использовании подкачиваемой

по запросу виртуальной памяти системы и плоском, линейном адресном

пространстве с 32-разрядным доступом.

Виртуальная память (virtual memory) позволяет операционной системе

управлять большим объемом памяти, чем тот объем, который компьютер

физически содержит. Каждый процесс размещается в уникальном виртуальном

адресном пространстве, которое представляет собой набор адресов, доступных

для использования нитями управления процесса. Это виртуальное адресное

пространство разделяется на равные блоки, или страницы (pages).

Каждый процесс может использовать до 4 Гб собственного виртуального

адресного пространства; из mix 2 Гб зарезервированы для нужд программы, а

оставшиеся 2 Гб - для системы. Windows NT может использован до 4 Гб

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

подобный объем. Лишь некоторые операционные системы позволяют работать с

памятью таких размеров. Например, MS OS/2 версии 1.3 может адресовать .тишь

16 Мб физической памяти.

Подачка по запросу (demand paging) используя метод, посредством которого

данные странично переносятся из физической памяти во временный страничный

файл на диске. В случае необходимости использования этих данных для

функционирования определенных процессов страничные данные переписываются

обратно в физическую память.

Диспетчер виртуальной памяти отображает виртуальные адреса в адресном

пространстве процесса на физические страницы в памяти компьютера. При этом

от нитей управления процесса скрывается физическая организация памяти. Это

гарантирует, что нить управления может обращаться, в случае необходимости,

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

Следовательно просмотр виртуальной памяти процесса нитью управления намного

упрощен по сравнению с реальным расположением страниц в физической памяти.

Вследствие того что каждый процесс имеет раздельное адресное пространство,

нити управления одного процесса не могут просматривать или изменять память

другого процесса без соответствующего разрешения.

Средства вызова локальных процедур

Приложения н подсистемы среды реализуют взаимоотношения типа «клиент-

сервер». Это означает, что клиент (приложение) обращается к серверу среды

(подсистеме) для удовлетворения запроса о предоставлении некоторого типа

сервиса системы. Для реализации взаимодействия «клиент-сервер» между

приложениями и подсистемами среды Windows NT обеспечивает механизм связи

между ними. Исполняющая система предоставляет средства прохождения

сообщении, которые называются средствами вызова локальных процедур (LPC —

Local Procedure Call). Они функционируют подобно вызовам удаленных процедур

(RPC), используемому для работы в сетевой среде (описаны в Networking

Guide, Chapter I, «Windows NT Networking Architecture»). Однако средства

LPC оптимизированы для процессов, выполняющихся на одном компьютере.

Прикладные программы взаимодействуют с подсистемами среды, передавая

сообщения через средства LPC. Процесс прохождения сообщения скрыт от

клиентского приложения функциональными заглушками (slubs); заглушки

представляют собой невыполняемые фрагменты, которые используются при

обращении к серверам среды. Заглушки реализованы в форме специальных

динамически связываемых библиотек (DLL).

Когда приложение производит обращение к интерфейсу прикладных программ (API

— application program interface) подсистемы среда, заглушка клиентского

процесса (приложения) упаковывает параметры для вызова и направляет их

серверному процессу (подсистеме), который осуществляет выполнение. Средства

LPC предусматривают, что после передачи данных серверу производится

ожидание ответа.

Рассмотрим, например, как этот процесс работает в подсистеме Win32. Когда

приложение Win32 загружено дня выполнения, оно связывается с DLL, которая

содержит заглушки для всех функций Win32 API. В случае, если приложение

осуществляет вызовы функции Win32 (в нашем примере, Win32-функции

CreateWindow), обращение обрабатывается следующим образом.

1. Клиентское приложение Win32 вызывает заглушку функции CreateWindow() из

DLL.

2. Заглушка формирует сообщение, которое содержит все данные, необходимые

для создания окна, и посылает это сообщение процессу сервера Win32

(подсистеме Win32).

3. Подсистема Win32 получает сообщение и вызывает реальную функцию

CreateWindow(). В результате этого создается окно.

4. Подсистема Win32 посылает сообщение, содержащее результаты выполнения

функции CreateWindow(), обратно заглушке в DLL,

5. Заглушка распаковывает сообщение сервера подсистемы и возвращает

результаты клиентскому приложению Win32.

Приложение воспринимает, что окно было создано функцией CreateWindow() из

DLL. От приложения скрыто, что работа фактически выполнялась процессом

сервера Win32 (подсистемой Win32), что для активизации этого процесса

посылалось сообщение, и даже что существует процесс сервера Win32. Кроме

тою, приложение не знает, что подсистема обращалась к одному или нескольким

серверам исполняющей системы для поддержки ее обращения к CreateWindow().

Диспетчер ввода-вывода

Диспетчер ввода-вывода является частью исполняющей системы Windows NT,

которая управляет всем вводом и выводом для операционной системы. Основное

назначение диспетчера ввода-вывода — управление связью между драйверами.

Диспетчер ввода-вывода поддерживает все драйверы файловой системы, драйверы

аппаратных средств, сетевые драйверы и обеспечивает для них гетерогенную

среду. Он предоставляет формальный интерфейс, доступный для вызовов всеми

драйверами. Этот однородный интерфейс позволяет диспетчеру ввода-вывода

одинаково взаимодействовать со всеми драйверами, без какой-либо информации

о фактическом управлении работой устройства. Диспетчер ввода-вывода также

содержит процедуры поддержки драйверов, специально разработанные для

драйверов файловой системы, драйверов аппаратных средств и сетевых

драйверов.

Модель ввода-вывода Windows NT использует многоуровневую архитектуру,

которая позволяет отдельным драйверам отвечать за логически законченный

уровень обработки ввода-вывода. Например, драйверы самого низкого уровня

управляют физическими устройствами компьютера (называются драйверами

устройств — device drivers). Другие драйверы являются надстройкой к

драйверам устройств. Драйверам более высокого уровня неизвестны любые

подробности работа физических устройств. С помощью диспетчера ввода-вывода

драйверы более высокого уровня просто передают запросы логического ввода-

вывода драйверам устройств, которые и обращаются к обслуживаемым ими

физическим устройствам. Устанавливаемые файловые системы Windows NT и

сетевые редиректоры (redirectors) — примеры работающих таким образом

драйверов высокого уровня.

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

системы и драйверов устройств. Кроме того, это позволяет быть активными

одновременно нескольким файловым системам и устройствам, так как они

адресуются через формальный интерфейс.

Драйверы взаимодействуют друг с другом, используя структуры данных,

называемые пакетами запроса ввода-вывода (I/O request packets). Драйверы

передают пакеты запроса ввода-вывода друг другу через диспетчер ввода-

вывода, который доставляет пакеты соответствующим целевым драйверам. Самый

простой способ выполнения операций ввода-вывода состоит в том, чтобы

синхронизировать выполнение приложений с завершением запрашиваемых ими

операций ввода-вывода (такой подход известен под названием синхронного

ввода-вывода — synchronous I/O). Когда подобное приложение выполняет

операцию ввода-вывода, функционирование собственно приложения блокировано.

После завершения операции ввода-вывода приложению разрешается продолжение

дальнейшего выполнения.

Одним из способов оптимизации эффективности приложении является применение

асинхронного ввода-вывода (asynchronous I/O); этот метод используется

многими процессами в Windows NT. Когда приложение инициализирует операцию

ввода-вывода, диспетчер ввода-вывода принимает запрос, но не блокирует

работу приложения в процессе выполнения ввода-вывода. Вместо этого

приложение продолжает свое функционирование. Большинство устройств ввода-

вывода очень медленно в сравнении с процессором компьютера; таким образом,

прикладная программа может выполнить множество операции в процессе ожидания

завершения операции ввода-вывода. Когда подсистема среды выдает асинхронный

запрос ввода-вывода, диспетчер ввода-вывода возвращается к подсистеме среды

немедленно после помещения запроса в очередь, без ожидания завершения

операции драйвером устройства. В это время отдельная нить управления

диспетчера ввода-вывода выполняет запросы из очереди наиболее эффективным

образом (не обязательно в порядке поступления)

По завершении любого запроса ввода-вывода диспетчер ввода-вывода уведомляет

об этом процесс, запросивший операцию.

Так как применение асинхронного ввода-вывода разрешает приложению

использовать процессор компьютера во время операций ввода-вывода, это

затрудняет для приложения определение завершения операции ввода-вывода.

Некоторые приложения применяют функцию повторного вызова (АРС), которая

вызывается после завершения асинхронной операции ввода-вывода. Другие

приложения используют объекты синхронизации, типа событий или описателей

фактов, которые система ввода-вывода приводит в соответствующее состояние

после выполнения ввода — вывода.

Диспетчер кэша

Архитектура ввода-вывода содержит единственный диспетчер кэша (Cache

Manager), который осуществляет кэширование ддя всей системы ввода-вывода.

Кэширование (caching) — метод, используемый файловой системой для

увеличения эффективности. Вместо непосредственной записи и считывания с

диска, часто используемые файлы временно сохраняются в кэш-памяти; таким

образом, работа с этими файлами выполняется в памяти. Операции с данными,

находящимися в памяти, производятся значительно быстрее операции с данными

на диске.

Диспетчер кэша использует модель отображения файла, которая интегрирована с

диспетчером виртуальной памяти Windows NT. Диспетчер кэша обеспечивает

службу кэширования для всех файловых систем и сетевых компонентов,

функционирующих под управлением диспетчера ввода-вывода. В зависимости от

объема доступной оперативной памяти диспетчер кэша может динамически

увеличивать или уменьшать размер кэша. Когда процесс открывает файл,

который уже находятся в кэше, диспетчер кэша просто копирует данные из кэша

в виртуальное адресное пространство,

Диспетчер кэша поддерживает службы типа ленивой записи (lazy write) и

ленивой фиксации (lazy commit), которые могут значительно увеличил)

эффективность файловой системы. В процессе ленивой записи изменения

регистрируются в кэше файловой структуры, обеспечивающем более быстрый

доступ. Позднее, когда загрузка центрального процессора снижена, диспетчер

кэша заносит изменения на диск. Ленивая фиксация подобна ленивой записи.

Вместо немедленной маркировки транзакции как успешно завершившейся,

переданная информация кэшируется и позднее в фоновом режиме записывается в

журнал файловой системы.

Драйверы файловой системы

В архитектуре ввода-вывода Windows NT управление драйверами файловой

системы осуществляет диспетчер ввода-вывода. Windows NT допускает

использование множества файловых систем, включая существующие файловые

системы типа FAT. Для обеспечения совместимости снизу вверх с операционными

системами MS-DOS, Windows З.х и OS/2, Windows NT поддерживает файловые

системы FAT и HPFS.

Редиректоры и серверы функционируют как драйверы файловой системы и

выполняются на уровне интерфейса поставщика или ниже, где находятся NetBIOS

и Windows-сокет.

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

уровень, называемый интерфейсом транспортного драйвера (TDI — Transport

Driver Interface). Windows NT включает следующие транспортные средства:

• Протокол управления передачей/межсетевой протокол TCP/IP, который

обеспечивает возможность работы с широким диапазоном существующих сетей.

• NBF, потомок расширенного интерфейса пользователя NetBIOS (NetBEUI),

который обеспечивает совместимость с существующими локальными

вычислительными сетями на базе LAN Manager, LAN Server и MS-Net.

• Управление передачей данных (DLC — Data Link Control), которое

обеспечивает интерфейс дня доступа к мэйнфреймам и подключенным к сети

принтерам,

• NWLink, реализация IPX/SPX, обеспечивающая связь с Novell NetWare.

В нижней части сетевой архитектуры находится драйвер платы сетевого

адаптера. Windows NT в настоящее время поддерживает драйверы устройств,

выполненные и соответствии со спецификацией NDIS (Network Device Interface

Specilication) версии 3.0. NDIS предоставляет гибкую среду обмена данными

между транспортными протоколами и сетевыми адаптерами. NDIS 3.0 позволяет

отдельному компьютеру иметь несколько установленных в нем плат сетевого

адаптера. В свою очередь, каждая плата сетевого адаптера может поддерживать

несколько транспортных протоколов для доступа к различным типам сетевых

станций.

3.2 Файловая система NTFS

NTFS обеспечивает комбинацию эффективности, надежности и совместимости,

отсутствующую в FAT или HPFS. Она разработана дня быстрого выполнения

стандартных файловых операций типа чтения, записи и поиска, а также

улучшенных операций типа восстановления файловой системы на очень больших

жестких дисках.

NTFS также включает возможности безопасности, требуемые для файловых

серверов и высококачественных персональных компьютеров в корпоративной

среде. NTFS поддерживает управление доступом к данным и привилегии

владельца, что является важным для целостности корпоративных данных. В то

время как каталогам, разделяемым при помощи Windows NT Server, назначаются

специфические разрешения, файлам и каталогам NTFS могут назначаться

разрешения вне зависимости, разделены они иди нет. NTFS - единственная

файловая система в Windows NT, которая позволяет назначить разрешения для

отдельных файлов.

NTFS является простой, но очень мощной разработкой. Для этой перспективной

файловой системы вся информация на томе NTFS является файлом им часшо

файла. Каждый распределенный на томе NTFS сектор принадлежит некоторому

файлу. Даже метаданные (metadata) файловой системы (информация, которая

описывает непосредственно файловую систему) являются частью файла.

Эта основанная на атрибутах файловая система поддерживает объектно-

ориентированные приложения, обрабатывая все файлы как объекты, которые

имеют определяемые пользователем и системой атрибуты.

Главная файловая таблица

Каждый файл на томе NTFS представлен записью в специальном файле,

называемом главной файловой таблицей (MFA — master file table). NTFS

резервирует первые 16 записей таблицы для специальной информации. Первая

запись этой таблицы описывает непосредственно главную файловую таблицу; за

ней следует зеркальная запись (mirror record) MFT. Если первая запись MFT

разрушена, то NTFS читает вторую запись для отыскания зеркального фата MFT,

первая запись которого идентична первой записи MFT. Местоположения

сегментов данных MFT и зеркального файла MFT записаны в секторе начальной

загрузки. Дубликат сектора начальной загрузки находится в логическом центре

диска.

Третья запись MFT — файл регистрации (log file); используется для

восстановления файлов. Файл регистрации подробно описан в настоящей главе

ниже. Семнадцатая и последующие записи главной файловой таблицы

используются собственно файлами и каталогами (также рассматриваются как

файлы NTFS) на томе.

Главная файловая таблица отводит определенное количество пространства для

каждой записи файла. Атрибуты файла записываются в распределенное

пространство MFT. Небольшие файлы и каталоги (обычно до 1500 байт или

меньше) могут полностью содержаться внутри записи главной файловой таблицы.

Подобный подход обеспечивает очень быстрый доступ к файлам. Рассмотрим,

например, файловую систему FAT, которая использует таблицу размещения

файлов, в которой перечисляются имена и адрес каждого файла. Элементы

каталога FAT содержат индекс в таблице размещения файла. В случае если

необходимо просмотреть содержимое файла, FAT сначала читает таблицу

размещения файлов и убеждается в существовании файла. Далее FAT

восстанавливает файл, ища цепочку распределенных блоков, относящихся к

этому файлу. В NTFS поиск файла производится только для непосредственного

его использования.

Записи каталога помещены внутри главной файловой таблицы так же, как записи

файла. Вместо данных каталоги содержат индексную информацию. Небольшие

записи каталогов находятся полностью внутри структуры MFT. Большие каталоги

организованы в B-tree, имея записи с указателями на внешние кластеры,

содержащие элементы каталога, которые не могли быть записаны внутри

структуры MFT.

Атрибуты файла NTFS

NTFS просматривает каждый файл (или каталог) как набор атрибутов файла.

Такие элемента, как имя файла, информация защиты и даже данные - все это

атрибуты файла. Каждый атрибут идентифицирован кодом типа атрибута и,

необязательно, именем атрибута.

Если атрибуты файла могут находится внутри записи файла MFT, они называются

резидентными (resident) атрибутами. Например, информация типа имени файла и

отметки времени всегда включается в запись файла MFT. Если файл слишком

большой, чтобы содержать все атрибуты в записи фата MFT, часть атрибутов

является нерезидентной (nonresident). Нерезидентные атрибуты занимают один

или несколько пробегов (run) дискового пространства в другом месте тома

(пробег дискового пространства — неприрывная линейная область на диске).

Вообще, все атрибуты могут быть вызваны как поток байтов независимо от

того, являются ли они резидентными или нерезидентными.

Длинные и короткие имена файлов

Подобно HPFS, NTFS поддерживает имена файла до 255 символов. Имена файла

N'I'FS используют набор символов Unicode с 16 битами; однако вопрос доступа

из MS-DOS решен. NTFS автоматически генерирует поддерживаемое MS-DOS имя

(восемь плюс три символа) для каждого файла. Таким образом, файлы NTFS

могут использоваться через сеть операционными системами MS-DOS и OS/2. Это

особенно важно для файловых серверов организации, которая использует

персональные компьютеры с двумя или всеми тремя этими операционными

системами.

Создавая имена файла «восемь плюс три», NTFS также позволяет приложениям MS-

DOS и Windows З.х работать с файлами, имеющими длинные имена NTFS. Кроме

того, при сохранении файла приложениями MS-DOS или Windows З.х на томе NTFS

сохраняются и имя файла «восемь плюс три» и длинное имя NTFS.

Если длинное имя файла или каталога на томе NTFS содержит пробелы, следует

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

путл в Program Manager для значков приложений. Например, предположим, что

Word for Windows установлен в D:\WORD FOR WINDOWS. Командная строка Program

Item Properties должна быть установлена в D:\WORD FOR WINDOWS\WINWORD.EXE.

При отсутствии кавычек будет отображено сообщение об ошибке «The path

D:\Word is invalid» (Путь D:\Word недопустим).

При работе с Windows NT файлы, созданные или переименованные в разделах

FAT, могут иметь связанные дтинные имена. Правила управления длинными

именами фата на томе NTFS также относятся к длинным именам файла на

разделах FAT; отличие заключается в том, что имена файла на FAT не могут

содержать расширенные символы. Дополнительную информацию о поддержке

длинных имен файлов для разделов FAT можно найти в разделе «Файловая

система FAT».

Генерация короткого имени файла

Поскольку NTFS использует набор символов Unicode для имен файлов,

существует возможность задействования нескольких «запрещенных» символов,

которые MS-DOS не может читать в имени файла. Для генерации короткого имени

файла в стиле MS-DOS, NTFS удаляет все эти символы и любые пробелы из

длинного имени файла. Так как имя файла в MS-DOS может иметь только одну

точку, NTFS также удаляет все дополнительные точки из имени файла. Далее, в

случае необходимости NTFS усекает имя файла до шести символов и добавляет

тильду (~) и номер. Например, к каждому недублированному имени файла

добавляется ~1. Повторяющиеся имена файлов заканчиваются символами ~2, ~3 и

т. д. Расширение имени файла усекается до трех или меньшего количества

символов. Наконец, при отображении имени файла в командной строке NTFS

транслирует все символы в имени файла и расширении к верхнему регистру

(File Manager отображает эти имена файла в нижнем регистре).

Windows NT использует несколько другой метод для создания коротких имен

файлов для случая, когда имеется пять или более файлов, которые привели бы

к двойным коротким именам файла. Для пятого и последующих файлов Windows NT

использует только первые два символа от длинного имени файла и далее

специальной математической операцией (функция от длинного имени) генерирует

следующие уникальные четыре символа короткого имени файла; после этою к

результату добавляется ~5 (или другой номер в случае необходимости

избежания двойного имени файла). Такой метод обеспечивает в основном

повышенную эффективность для случая, когда Windows NT должна создавать

короткие имена файлов для большого количества файлов с похожими длинными

именами. Windows NT использует этот метод создания коротких имен для томов

FAT и NTFS.

По умолчанию, Windows NT поддерживает имена файлов в формате MS-DOS на всех

томах NTFS. Для повышения эффективности работы на томах с большим

количеством длинных похожих имен можно запретить эту возможность для всех

томов.

Windows NT не генерирует коротких имен для файлов, созданных приложениями

POSIX в разделе NTFS. Это означает, что приложения MS-DOS и Windows З.х не

смогут работать с подобными именами, если эти имена не удовлетворяют

условию «восемь плюс три». В случае необходимости работы из приложении MS-

DOS или Windows с файлами, которые созданы приложениями POSIX, следует

убедиться, что использованы стандартные имена MS-DOS.

Согласованность с POSIX

Согласованность с POSIX позволяет переносить приложения UNIX в среду

Windows NT. Windows NT полностью согласована со стандартом 1003.1 института

IEEE, который определяет присвоение имен и идентификацию файлов.

Следующие возможности POSIX включены в NTFS;

• Чувствительные к регистру имена. Для POSIX файлы README.TXT, Readme.txt и

readme.txt являются различными.

• Жесткие связи (hard links). Файлу может быть присвоено несколько имен.

Это позволяет двум файлам с различными именами, которые могут быть

размещены в различных каталогах, содержать одни и те же данные.

• дополнительные отметки времени. Показывают, когда файл был последний раз

использован или изменен.

Возможности NTFS, используемые Macintosh Services Clients

Сервис для Macintosh входит в состав Windows NT Server. Этот сервис

предоставляет пользователям Macintosh возможность доступа к фактам,

находящимся на Windows NT Server; т. к. эти файлы доступны сетевым

пользователям Windows NT, файловый сервер может быть легко использован для

общего доступа с различных аппаратных платформ.

При разрешения сервиса для Macintoch следует сделать доступным раздел NTFS,

если требуется автоматическое создание тома модуля аутентификации

пользователя (User Authentification Module) для клиентов Macintosh (Network

Control Panel использует первый раздел NTFS для создания этих томов по

умолчанию).

Клиенты Macintosh могут использовать только файлы на томах NTFS. Ветвления

ресурсов Macintosh и информация Finger для каждого файла Macintosh

сохраняются как потоки NTFS. Поскольку NTFS поддерживает длинные имена,

большинство имен файлов Macintosh сохраняются.

Сервис для Macintosh сохраняет привилегии папки (File Sharing folder) как

разрешения Windows NT; это означает, что существует только один набор

разрешений для папки или файла, который предписан н пользователям Windows

NT и пользователям Macintosh. Однако пользователи Macintosh не смогут

видеть разрешения файла, так как AppleShare поддерживает только разрешения

папки.

3.3 Защита данных в ОС Windows NT AS

Модель безопасности Windows NT представлена монитором безопасности

(Security Reference Monitor), а также двумя другими компонентами: процессом

входа в систему (Logon Process) и безопасными защищенными подсистемами. В

многозадачной операционной системе, каковой является Windows NT, приложения

совместно используют ряд ресурсов системы, включая память компьютера,

устройства ввода-вывода, файлы и процессор(ы) системы. Windows NT включает

набор компонентов безопасности, которые гарантируют, что приложения не

смогут обратиться к этbм ресурсам без соответствующего разрешения.

Монитор безопасности отвечает за проведение в жизнь политики проверки

правильности доступа и контроля, определенной локальной подсистемой

безопасности. Монитор безопасности обеспечивает услуга по подтверждению

доступа к объектам, проверке привилегий пользователя н генерации сообщений

как для привилегированного режима, так и для режима пользователя. Монитор

безопасности, подобно другим частям операционной системы, выполняется в

привилегированном режиме.

Процесс входа в систему (в пользовательском режиме) и безопасные защищенные

подсистемы - два других компонента модели безопасности Windows NT.

Подсистема безопасности известна также как интегральная подсистема (в

отличие от подсистем среды), т. к. она воздействует на всю операционную

систему Windows NT.

Ядро и исполняющая система Windows NT основаны на обьектно-ориентированной

модели, которая обеспечивает непротиворечивый и унифицированный просмотр

беопасности и прав вплоть до фундаментальных объектов, которые составляют

основу операционной системы. Это означает, что Windows NT использует

одинаковые процедуры для проверки правильности доступа и контроля всех

защищенных объектов. Таким образом, как в случае попытки доступа к файлу на

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

правильности доступа будет использован один компонент в системе, вне

зависимости от типа объекта.

Процесс входа в систему в Windows NT предусматривает обязательный вход в

систему для идентификации пользователя. Каждый пользователь должен иметь

бюджет и должен использовать пароль для обращения к этому бюджету.

Прежде чем пользователь сможет к любому ресурсу компьютера с Windows NT, он

должен войти в систему через процесс входа в систему для того, чтобы

подсистема безопасности могла распознать имя пользователя и пароль. После

успешного установлены подлинности, всякий раз при обращении пользователя к

защищенному объекту, монтор безопасности выполняет процедуру проверки

правильности доступа для определения права пользователя на обращение к

этому объекту.

Модель безопасности также предусматривает контроль доступа, при котором

владелец ресурса может разрешить пользователям или группам обращение к

ресурсам и назначитъ им типы доступа (например, read, write и delete),

Защищенность ресурсов - одна из особенностей, предоставляемая моделью

безопасности. Задачи не могут обращаться к чужим ресурсам (типа памяти)

иначе, чем через применение специальных механизмов совместного

использовании. Такой подход позволяет производить маскировку объектов.

Windows NT также предоставляет средства контроля, которые позволяют

администратору фиксировать действия пользователя.

Предоставьляя возможности, модель безопасности Windows NT предотвращает

получение приложением преднамеренного или непреднамеренного

несанкционированного доступа к ресурсам других приложении или операционной

системы.

Модель безопасности Windows NT разработана в соответствии с уровнем С2,

определенным Министерством обороны США. Наиболее важные требования уровня

безопасности С2 перечислены ниже.

. Владелец ресурса (например, файла) должен иметь возможность управлять

доступом к ресурсу.

. Операционная система должна защищать объекты от несанкционированного

использования другими процессами. Например, система должна защищать

память так, чтобы ее содержимое не могло читаться после освобождения

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

. Перед получением доступа к системе каждый пользователь должен

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

Система должна быть способна использовать эту уникальную идентификацию

для контроля действий пользователя.

. Администратор системы должен иметь возможность контроля связанных с

безопасностью событий (audit security-related events). Доступ к эта

контрольным данным должен быть ограничен администратором.

. Система должна защищать себя от внешнего вмешательства типа модификации

выполняющейся системы или хранимых на диске системных файлов.

3.4 Работа в сетях Windows NT AS

Серверы баз данных Microsoft SQL Server в Centura SQLBase

Базы данных – неотъемлемая часть любой информационной системы. Старые СУБД

(dBase, Paradox и др.) абсолютно не удовлетворяют требованиям сегодняшнего

дня. Им присущи следующие недостатки: при одновременной работе с БД с

нескольких рабочих мест значительно возрастает нагрузка на сеть; они не

обеспечивают эффективной работы с базами данных, измеряемыми сотнями

мегабайт и более; отсутствуют гибкие механизмы разграничения доступа к

информации; сложности в реализации процедур поддержки целостности и

восстановления в случае сбоев аппаратуры или неправильной обработки и

многое другое.

Существует ряд способов решения этих проблем, например применение SQL-

серверов. В двух словах – SQL-сервер представляет собой программу, которая

принимает все запросы клиентов к БД и возвращает им только результат

поиска.

Одним из довольно мощных SQL-серверов, предназначенных для совместной

работы с Windows NT, является SQL Server компании Microsoft. Он обладает

неплохой масштабируемостью: с его помощью можно создавать приложения как

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

имеет мощный механизм репликаций, позволяющий синхронизировать информацию,

расположенную в различных узлах сети, что необходимо при построении

распределенных информационных систем.

Немаловажное достоинство SQL Server – эффективное использование ресурсов

многопроцессорных систем. Развитые интерактивные средства администрирования

и мониторинга делают контроль за работой PCOIQ сервера очень простым. При

помощи программы администратора можно запрограммировать алгоритм действий в

Страницы: 1, 2, 3, 4, 5, 6