Мы понимали, что при переходе к клиент/серверным вычислениям, 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 появился в версии 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 была также устранена адресация на базе возможностей, а из системных указателей, предоставляемых пользователям, убраны все права доступа.

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

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

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

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

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

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

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

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

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

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

права на объекты — права доступа к объектам из вышеуказанного списка;

привилегированные команды и специальные права — информация о всех привилегированных командах и специальных правах пользователя;

пароль — код, обязательный для входа в систему при всех уровнях защиты, кроме 10;

текущая библиотека — место, куда по умолчанию помещается новый объект, созданный пользователем;

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

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

ограничение сессий для устройства — параметр, ограничивающий устройство пользователя одной сессией;

максимальный объем памяти — поле, задающее общий объем дискового пространства для объектов, которыми владеет пользователь;

максимальный приоритет — поле, задающее максимальный приоритет планировщика, который может применяться пользователем (более подробно будет обсуждаться в главе 9);