Защита ресурсов (уровень 30)

Минимальным рекомендуемым уровнем защиты является уровень 30. На этом уровне, так же как и на уровне 20, для входа в систему пользователь должен быть зарегистрирован и знать правильный пароль. После входа в систему проверяется, обладает ли пользователь правами доступа к системным ресурсам; несанкционированный доступ не разрешается. На уровне 30 пользователь также может быть зарегистрирован с ограниченными возможностями.

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

Уровень защиты 30 был наивысшим в System/38. Но на нем не различаются пользовательские объекты и объекты, используемые только ОС. В связи с доступностью на System/38 ассемблера MI и наличия определенной информации о внутренней структуре объектов возникла серьезная проблема. ISV стали писать прикладные пакеты, зависящие от внутренней структуры объектов, что нарушало технологическую независимость MI.

В первых моделях AS/400 использовались те же самые уровни защиты. Хотя в AS/400 не было ассемблера MI, и мы не публиковали информацию о внутренних структурах, специалисты довольно скоро поняли, что AS/400 — это System/38. Поэтому программы, зависимые от внутренней структуры объектов, работали и на AS/400.

Мы понимали, что при переходе к клиент/серверным вычислениям, AS/400 нужна более надежная защита, блокирующая доступ к большинству внутренних объектов. В связи с переходом на RISC-процессоры изменениям подверглась и внутренняя структура. Но если бы мы просто реализовали новый, повышенный, уровень зашиты, то программы, зависимые от внутренней структуры объектов, перестали бы работать, что вызвало бы недовольство заказчиков.

Мы объявили о том, что собираемся встроить в V1R3 новый уровень защиты, и что на этом уровне доступа к внутренним объектам не будет. Мы также начали искать тех ISV, кто использовал внутренние объекты, чтобы предоставить им стандартные системные API, с информацией, необходимой для их программ.

Большая часть таких программ были утилитами, использовавшими информацию некоторых полей внутри системного объекта. Например, системе управления магнитной лентой могли понадобиться некоторые данные о заголовке ленты. Такую информацию можно было получить единственным способом — проникнув в системный объект. Мы создали сотни API для предоставления подобной информации через MI (по сути дела, эти API были новыми командами MI) и гарантировали, что они будут работать во всех последующих версиях ОС. Таким образом мы развязали себе руки и начали вносить изменения во внутренние структуры.

С защитой связана еще одна серьезная тема: тема открытости AS/400. Довольно долго многие ISV не только использовали внутренние объекты, но и настаивали, что бы IBM сделала внутреннее устройство ОС открытым и дала тем самым "зеленый свет" разработчикам ПО. В ответ IBM утверждала, что при неправильном использовании команд MI велика вероятность программных сбоев, за которые она не может нести ответственность. Компромисс (управляемая открытость через API) был достигнут, частично в результате серии заседаний группы COMMON, начатых по инициативе ISV и других пользователей. Работу с ISV и определение новых API возглавил Рон Фесс (Ron Fess) — один из основных разработчиков ПО с большим опытом работ по CPF и OS/400. Результат это работы — реализация на AS/400 Single UNIX Specification и других стандартных API. AS/400 стала более открытой для пользователей.

Защита ОС (уровень 40)

Уровень 40 появился в версии V1R3 OS/400. Сегодня все новые AS/400 поставляют ся именно с этим уровнем защиты, а не 10, как ранее. Но старые версии OS/400 и при модернизации сохраняют текущий уровень, установленный заказчиком. Теперь пароль начальника защиты (пользователь, обладающий правами доступа наивысшего уровня) становится недействительным после первого ввода в систему и он должен его изменить. Ранее заказчики AS/400 часто не утруждали себя изменением пароля, установленного в системе по умолчанию, что создавало явную "дыру" в защите.

При уровне 40 пользователь AS/400 также должен быть зарегистрирован, должен знать правильный пароль для входа в систему и иметь права на доступ к системным ресурсам. Впрочем, пользователи с ограниченными возможностями при этом уровне защиты тоже поддерживаются.

В отличие от уровней 10–30, при уровне защиты 40 доступ к нестандартным интерфейсам блокирован. Пользователю теперь доступны далеко не все команды MI, а лишь их разрешенный набор, включая сотни API, разработанных для ISV. Остальные же команды блокированы, то есть система не будет исполнять их в пользовательской программе.

Тем не менее, команды из блокированного набора попрежнему доступны OS/400. Для различия программ OS/400 и пользовательских, были введены понятия системного и пользовательского состояния, к которым можно отнести любой процесс на AS/400. Использование заблокированных команд и доступ, таким образом, к некоторым объектам системы разрешены только в системном состоянии.

Для большей надежности защиты в V1R3 была также устранена адресация на базе возможностей, а из системных указателей, предоставляемых пользователям, убраны все права доступа.

Защита C2 (уровень 50)

Уровень 40 обеспечивает системе достаточную степень защищенности в большинстве случаев. Однако, некоторым фирмам, выполняющим государственные заказы, необходим уровень защиты, сертифицированный правительством США. Таких сертификатов несколько, включая, так называемый, уровень С2. Они включают такие положения, как защита ресурсов пользователя от других пользователей и предотвращение захвата одним пользователем всех системных ресурсов, например, памяти. Кстати, подобные требования сейчас применяются и во многих неправительственных организациях.

Для заказчиков, нуждающихся в правительственных сертификатах, мы дополнили уровень защиты 40 на AS/400 до соответствия упомянутому уровню С2. Так в версии V2R3 появилась защита уровня 50.

Но прежде чем система будет признана соответствующей стандарту С2, она должна пройти всеобъемлющую проверку. В настоящее время такая проверка идет.

Уровень 50 включает все возможности защиты уровня 40, хотя некоторые интерфейсы были изменены под государственный стандарт. Кроме того, добавлена возможность аудита.

Министерство обороны США определяет уровень защиты класса С2, как обеспечивающий "селективную защиту и, путем включения возможностей аудита, ответственность субъектов за их действия"¹⁾. Иначе говоря, при этом уровне защиты владелец ресурса вычислительной системы должен иметь право решать, кому предоставить доступ к данному ресурсу. Нужно также, чтобы система "помнила", кто и когда обращался к ресурсу. Средства аудита, задаваемые системным параметром QAUDJRL, позволяют администратору анализировать собранную информацию.

Правительством США определены уровни защиты от А до D, где А — наивысший уровень защиты, а D – самый низкий. Классы B и С имеют несколько подуровней. Уровень защиты С2 — уровень, наивысший из обычно используемых в бизнесе. В будущем, если возникнет такая необходимость, мы сможем включить в AS/400 поддержку и более высоких уровней защиты.

Профили пользователей

Профиль пользователя это и объект OS/400, и системный объект MI, служащий для идентификации пользователя в системе. Профиль должен быть у каждого пользователя, хотя и не обязательно уникальный: как мы скоро увидим, профили могут быть разделяемыми. Даже при отключенной защите (уровень 10), если у пользователя нет профиля, то система его создаст. Профили пользователя содержат информацию относящуюся к защите, они применяются и компонентами защиты OS/400, и компонентами контроля за доступом SLIC. Упомянутые компоненты управляют использованием объектов, ресурсов, некоторых команд и атрибутов машины.

Профиль пользователя определяет следующие параметры:

• класс пользователя — категорию, в зависимости от принадлежности к которой пользователь имеет особые права;
• принадлежащие и доступные объекты — список объектов, которыми пользователь владеет и к которым имеет доступ;
• права на объекты — права доступа к объектам из вышеуказанного списка;
• привилегированные команды и специальные права — информация о всех привилегированных командах и специальных правах пользователя;
• пароль — код, обязательный для входа в систему при всех уровнях защиты, кроме 10;
• текущая библиотека — место, куда по умолчанию помещается новый объект, созданный пользователем;
• начальная программа и меню — поле, задающее программу и меню, активизируемые сразу после входа пользователя в систему;
• ограничение возможностей — параметр, запрещающий пользователю ввод команд и ограничивающий его возможности выбором пунктов меню;
• ограничение сессий для устройства — параметр, ограничивающий устройство пользователя одной сессией;
• максимальный объем памяти — поле, задающее общий объем дискового пространства для объектов, которыми владеет пользователь;
• максимальный приоритет — поле, задающее максимальный приоритет планировщика, который может применяться пользователем (более подробно будет обсуждаться в лекции 9);
• специальная среда — поле, задающее среду, в которой будет работать пользователь (например, System/36).

Назначение большинства приведенных атрибутов очевидно, но первые четыре требуют некоторых пояснений.

Класс пользователя

Какой именно уровень доступа к системе разрешен пользователю, определяют пять классов пользователей. От класса зависит, какие функции пользователь может выполнять, какие пункты меню и привилегированные команды ему доступны. Перечислим все пять классов, начиная с максимального уровня доступа:

• начальник защиты — наивысший уровень пользователя системы; его обладатель выполняет все операции, связанные с защитой, включая разграничение других пользователей на классы;
• администратор защиты отвечает за регистрацию пользователей и защиту системных ресурсов;
• системный программист разрабатывает приложения для системы;
• системный оператор выполняет функции обслуживания системы, например резервное копирование;
• пользователь рабочей станции — пользователь прикладных программ, имеющий минимальный доступ к системе.

В новой AS/400 для каждого класса пользователей имеется по одному профилю. Заказчик сам решает, кто в его организации будет отвечать за каждой из участков работы. Очевидно, что один и тот же человек может совмещать несколько обязанностей.