Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 21 (всего у книги 41 страниц)

Права доступа к объектам

К каждому объекту AS/400 может быть предоставлено восемь видов доступа, а именно:

•право на оперирование объектом разрешает просматривать описание объекта и использовать объект соответственно имеющимся у пользователя правам[ 57 ]57
  Пользователь не имеющий данного права не может даже знать о существовании этого объекта. – Прим. консультанта.


[Закрыть];

право на управление объектом разрешает определять защиту объекта, перемещать или переименовывать его, а также добавлять (но не удалять!) разделы в файлы баз данных;

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

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

право на чтение разрешает доступ к объекту;

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

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

право на обновление разрешает изменять записи объекта.

Эти восемь прав объединены OS/400 в четыре комбинации, чтобы их было легче применять. Конечные пользователи могут использовать и другие сочетания, но большинство все же предпочитает следующие стандартные комбинации:

«все» (all) – объединяет все восемь прав;

«изменение» (change) – объединяет права на оперирование объектом, чтение, добавление, удаление и обновление;

«использование» (use) – объединяет права на оперирование объектом и чтение;

«исключение» (exclude) – не дает никаких прав на использование объекта; перекрывает наличие общих или групповых в связи с порядком проверки прав доступа (рассматривается далее).

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

Каждый профиль пользователя содержит информацию о привилегированных командах и специальных правах пользователя. Некоторые привилегированные команды MI могут выполняться только теми пользователями, профили которых разрешают это делать. Например, профиль для начальника защиты создается с возможностью исполнять команду «PWRDWNSYS» (Power Down System), останавливающую работу машины. По очевидным причинам эта привилегированная команда не доступна обычным пользователям. Также есть набор специальных прав, которые могут быть предоставлены лишь избранным пользователям. Эти специальные права связаны с такими операциями, как подвешивание объектов, управление процессами, выполнение операций загрузки/дампа и использование низкоуровневых сервисных средств.

Хотя все привилегированные команды и специальные атрибуты могут быть заданы в профиле пользователя по отдельности, OS/400 объединяет команды и права в шесть групп специальных прав:

«все объекты» – разрешает доступ к любому системному ресурсу, независимо от того, оговорены ли особо права пользователя на такой доступ;

«администратор защиты» – разрешает создание и изменение профилей пользователя;

«сохранение системы» – разрешает сохранять, восстанавливать и освобождать память для любого объекта в системе, независимо от того, имеет ли пользователь право определять существование этого объекта;

«управление заданиями» – разрешает изменять, отображать, задерживать, возобновлять, отменять и удалять все задания, которые исполняются в системе, а также находятся в очередях заданий или в выходных очередях;

« обслуживание» – разрешает выполнять сервисные операции отображения/изменения/дампа.

«управление спулом» – разрешает удалять, отображать, задерживать и отпускать спул-файлы, владельцами которых являются другие пользователи.

Профиль пользователя – это сердце системы защиты AS/400. Он управляет доступом практически ко всем ресурсам системы. Но даже если профиль пользователя не дает последнему прав на некоторый объект или ресурс системы, такие права можно получить иными способами. Далее мы рассмотрим два способа получения дополнительных прав: заимствование прав программой и права группы.

Заимствование прав программой

Во время исполнения программы профиль пользователя – владельца программы может служить дополнительным источником прав. Возможность заимствования прав позволяет программе выполнять операции, требующие полномочий, которыми пользователь непосредственно не обладает. Вместо того, чтобы предоставлять дополнительные права пользователю, пользовательская прикладная программа вызывает другую программу, владелец которой имеет соответствующие права. Таким образом, заимствование прав программой требует использования концепции стека вызовов. Такое заимствование всегда аддитивно и никогда не уменьшает прав доступа. Заимствование – атрибут программы, задаваемый при ее создании. Если вызываемая программа допускает заимствование прав, то любая вызывающая программа может использовать права владельца во время выполнения вызываемой программы. Программы, работающие в системном состоянии, могут сами задать запрет на заимствование. Программа может также запретить дальнейшее распространение прав. Это означает, что вызывающая программа будет заимствовать права, но эти права не сохранятся для программ, расположенных дальше по цепи вызовов.

Ранее мы рассматривали только случаи, когда один пользователь имеет права на один объект. Однако, иногда нужно предоставить одинаковые права группе пользователей, или права на группу объектов.

Группирование прав

На AS/400 есть три метода группирования прав. Списки прав и профили групп упрощают администрирование защиты, устраняют необходимость индивидуального подхода к пользователям или объектам. Держатели прав (authority holders) были введены IBM еще в среде System/36.

Список прав позволяет назначать права на множество объектов нескольким пользователям. Кроме того, каждый пользователь может иметь различные права доступа ко всем объектам в списке. Список прав с тремя пользователями и тремя объектами показан на рисунке 7.1. Каждый из трех пользователей имеет права на все три объекта в списке; но во всех случаях – разные. Для добавления, удаления или изменения пользователей и их прав в списке требуется право на управление списком прав, описанное выше. На уровне MI список прав реализован как системный объект.

Профили групп дают пользователям возможность применять общий профиль в дополнение к своим собственным. Пользователи – члены группы (например, сотрудники отдела предприятия) могут работать с общими объектами. Управление правами доступа всех членов группы может выполняться посредством профиля группы.

Рисунок 7.1. Пример списка прав

Доступ к профилю группы осуществляется через профили отдельных пользователей. Если профиль пользователя дает ему права на объект, то эти явные права переопределяют права группы. Это позволяет предоставлять отдельным членам группы меньшие или большие права по сравнению с остальными.

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

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

Для поддержки прав доступа к несуществующим файлам в среде System/36 на AS/ 400 были добавлены держатели прав, нужные только для миграции. Их использование ограничено несколькими типами программно-описанных файлов; для других типов файлов и объектов держатели прав не поддерживаются. В связи с этим, ни в MI, ни в OS/400 нет объекта типа «держатель прав».

Алгоритм поиска прав

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

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

Алгоритм поиска прав выполняется SLIC при первом обращении пользователя к объекту. Это часть операции разрешения указателя, рассмотренной в главе 5. Работа алгоритма останавливается при обнаружении запрошенных прав на объект. Если информации о правах не найдено, доступ не предоставляется.

Рисунок 7.2. Алгоритм поиска прав

Последовательность алгоритма поиска запрошенных прав показана на рисунке 7.2.

Предположим, что мы запрашиваем право на изменение (change) для некоторого объекта в системе. Порядок поиска таков[ 58 ]58
  На самом деле, приведенный ниже алгоритм сильно упрощен для того, чтобы облегчить читателю понимание общих принципов проверки наличия прав. Описание полного алгоритма предназначено только для «гурманов» и занимает около 20 страниц. Оно содержится в книге OS/400 Security – Reference, SC41-4302, входящей в комплект эксплуатационной документации. – Прим. консультанта.


[Закрыть]:

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

специального права на все объекты, или

права на объект (владельца и явного), или

права из списка, если объект присутствует в этом списке (явного права).

Доступ к объекту разрешен, если данный пользователь имеет специальное право на все объекты или, по крайней мере, право на изменение (change) для объекта в профиле пользователя (право владельца или явное право на объект) или в списке прав. Если найденное право меньше, чем право на изменение (change) – например, «использование» (use) или «исключение» (exclude), – то алгоритм переходит к поиску заимствованного права. Если право не обнаружено, то проверяются профили групп.

2.В профиле группы ведется поиск:

специального права на все объекты, или

права первичной группы, или

права на объект для других групп (явного права), или

права из списка, если объект присутствует в этом списке (явного права).

Доступ к объекту разрешен, если группа имеет специальное право на все объекты или, по крайней мере, право на изменение (change) для объекта в первичной группе, других группах или в списке прав. Если найденное право меньше, чем право на изменение (change) – например, «использование» (use) или «исключение» (exclude), – то алгоритм переходит к поиску заимствованного права. Если право не обнаружено, то проверяются общие права.

3.В общих правах ведется поиск:

специального права на все объекты, или

права из списка, если объект присутствует в этом списке (явного права).

Доступ к объекту разрешен, если имеется, по крайней мере, общее право на изменение (change) либо в объекте, либо в списке прав. Если найденное право меньше, чем право на изменение (change) – например, «использование» (use) или «исключение» (exclude), – то алгоритм переходит к поиску заимствованного права.

4.В заимствованном профиле ведется поиск.

Доступ к объекту разрешен, если в заимствованном профиле пользователя имеется, по крайней мере, право на изменение (change). В противном случае доступ запрещается.

Так как индивидуальный профиль пользователя просматривается первым и всегда выбирается первое встретившееся право на объект, пользователю могут быть предоставлены большие или меньшие права на объект по сравнению с общими правами и правами профиля группы. Если поместить право на исключение (exclude) в профиль индивидуального пользователя, а право на изменение (change) в заимствованный профиль, то доступ к объекту данному пользователю будет заблокирован. Однако, пользователь по-прежнему сможет выполнять над объектом операции изменения с помощью заимствованных прав, приобретаемых при выполнении соответствующей программы. Такой способ наиболее распространен для ограничения доступа к системному объекту.

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

Дополнительная защита в сетевом мире

Давайте кратко рассмотрим вопросы защиты, возникающие при подключении к AS/400 любой незащищенной системы, будь это ПК на ЛВС или другой компьютер через Интернет (подробнее о переходе к сетевым вычислениям и связанными с этим изменениями в AS/400 – в главе 11). Надеюсь, это поможет Вам лучше использовать защиту AS/400 для сохранения своих информационных ресурсов.

Мы начнем с рассмотрения клиент/серверных приложений и подключения ПК к AS/400.

Подключение ПК к AS/400

Многие организации и фирмы используют клиент/серверные приложения, или собственные, или приобретенные у ISV. Часто при этом ПК подключаются к AS/400 через ЛВС, а приложение разбивается между ПК и AS/400. Очень часто пользователи полагают, что в подобных клиент/серверных средах их данные на AS/400 защищены от несанкционированного доступа. К сожалению, это не всегда так. Защита данных зависит от того, как написано приложение и как защищена система.

Той части клиент/серверного приложения, которая работает на ПК, необходим способ доступа к базе данных AS/400. Обычно, для этого используется доступ на уровне файлов. Весьма распространенный подход при этом – использование интерфейсов ODBC (Open Database Connectivity). Но если на ПК исполняется приложение ODBC, то на AS/400 дополнительное приложение не нужно. Следовательно, невозможно использовать для защиты файлов базы данных такие средства, как заимствование прав программой. Вместо этого программа на ПК получает непосредственный доступ к файлам базы данных посредством общих, групповых или явных прав. Но вот проблема: как быть, если конечный пользователь ПК не должен иметь полного доступа к базе данных? Ограничение доступа пользователя возлагается на приложение ПК, где оно, обычно, не работает и в системе защиты возникает брешь.

ПК, как и многие другие, подключенные к AS/400, системы, никак не защищены. И я утверждаю, что нельзя полагаться ни на какой код, предназначенный для ограничения доступа к AS/400, если он выполняется на незащищенной системе. Вот что я имею в виду. Например, любое ПО на ПК, включая ПО ОС Windows 95 и Windows NT Workstation, может быть легко изменено достаточно компетентным пользователем, после чего будет работать не так, как изначально предполагалось. Это означает, что ни одна прикладная программа на ПК не может обеспечить какой-либо серьезной защиты данных на AS/400, да и данных на самом ПК.

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

ODBC не единственный потенциально опасный (с точки зрения защиты информации) интерфейс, который можно использовать для работы с AS/400. TCP/IP FTP (File Transfer Protocol), передача файлов с помощью Client Access и DDM – вот лишь несколько примеров удаленных интерфейсов к AS/400, использование которых может вызывать те же проблемы защиты. Многие клиент/серверные приложения, включая написанные ISV, создаются без должной защиты данных.

Ключевой момент защиты данных AS/400 – обеспечить, чтобы любой код, отвечающий за контроль доступа, выполнялся на защищенной системе. Для пользователей AS/400 это обычно означает установку защиты, предусматривающей, по меньшей мере, защиту ресурсов (уровень 30), а также осторожность при разработке или приобретении клиент/серверных приложений.

В последнее время многие клиенты AS/400 стали подумывать об использовании вместо ПК СК (сетевых компьютеров; подробно мы рассмотрим их в главе 11). СК обладает многими преимуществами ПК, может похвастаться отсутствием некоторых потенциальных проблем последнего, да и дешевле. СК также обеспечивает лучшую защищенность.

Вирусы, черви, троянские кони и другие мерзкие твари

Вирусы настолько распространены, что сегодня серьезный бизнес может опираться на ПК только при использовании какого-либо антивирусного ПО. Новые вирусы создаются каждый день, поэтому и программы проверки должны постоянно обновляться. Вирусам подвержены системы Unix и даже мэйнфреймы, что связано с наличием в них определенных возможностей системного программирования. Ведь чтобы заразить систему, код вируса должен присоединиться к некоторому исполняемому коду на двоичном машинном уровне. Так как в AS/400 видима лишь незначительная часть внутренних компонентов, внедрение вируса в нее маловероятно. И все же, это может произойти, если система не защищена надлежащим образом.

Наилучший способ предохранения от вирусов на AS/400 – защита объектов-программ и команд. Например, пользователь может изменить команду с помощью команды «CHGCMD» (Change Command) только в том случае, если у него есть право управлять объектами. Дополнительную страховку обеспечивает команда «RVKOBJAUT» (Revoke Object Authority): с ее помощью Вы можете отозвать, или, по крайней мере, отследить, чрезмерный доступ к командам, в том числе и к самой команде «CHGCMD». Кроме того, в AS/400 хакер может использовать для модификации или создания исполняемых программ лишь несколько средств и команд. Следовательно, доступ к ним нужно ограничить. Таким образом, если устранить возможность несанкционированного создания программ и изменения объектов-программ, то возможность внедрения вируса равна нулю. Средства аудита, отслеживая, кто именно использует такие изменяющие программы команды, не позволяют злоумышленнику остаться необнаруженным.

Черви похожи на вирусы, но в отличие от них не заражают другие программы. Вместо этого, червь постоянно дублируется и оттягивает на себя системные ресурсы. Например, программа-червь для AS/400 могла бы постоянно посылать себя на выполнение как новое задание. Это не вызовет повреждений, но может сильно снизить общую производительность системы. Чтобы предотвратить такую узурпацию большей части ресурсов, следует ограничить доступ к командам, изменяющим задание или его класс, и установить лимиты очереди заданий для ограничения числа параллельно исполняющихся заданий (задания, очереди заданий и классы мы рассмотрим в главе 9). С этой целью IBM изменила в V3R7 установку по умолчанию общего права на большинство таких команд с «использование» (use) на «исключение» (exclude). Общее право на многие описания заданий также было переназначено с «изменение» (change) или «использование» (use) на «исключение» (exclude).

Компьютерные троянские кони пытаются пробраться в Вашу систему незаметно, подобно античным грекам, вошедшим в Трою, скрыв своих солдат в огромном подарке – деревянном коне. Обычно, имя «троянской» программы совпадает с именем «хорошей» программы. Пользователь может поместить «троянского коня» в такое место системы, что при ее выполнении он получит более высокий уровень прав, чем имеет при исполнении «законной» программы. Проще всего поместить «троянскую» программу в библиотеку.

В главе 5 мы говорили, что система просматривает библиотеки в списке одну за другой, пока не будет найден нужный объект. Если кто-то поместит «троянскую» программу в библиотеку, предшествующую библиотеке, содержащей «хорошую» программу с тем же именем, то «троянская» программа будет найдена первой и ее автор сможет (потенциально) получить более высокую степень доступа к системе.

В качестве примера рассмотрим предоставляемую IBM библиотеку QUSRSYS, которая поставляется вместе с системой. Допустим, QUSRSYS имеет общее право доступа «изменение» (change). Эта библиотека просматривается системой перед просмотром других пользовательских библиотек в списке задания. Обращение к пользовательской библиотеке вызвало бы одноименную «троянскую» программу, предварительно помещенную хакером в QUSRSYS. Обратите внимание, на слово «допустим», с которого начинается вторая фраза этого абзаца. Именно для страховки от «троянских коней» с версии V3R7 QUSRSYS и другие библиотеки IBM поставляются с общим правом «использование» (use). Тогда же и с той же целью —.повысить защищенность системы и затруднить несанкционированный доступ к системным ресурсам – в специальные права для различных классов пользователей были внесены и другие изменения.

В отличие от ПК и систем Unix средства для защиты AS/400 от тварей, которых мы только что рассмотрели, уже присутствуют в самой системе. Как я уже сказал, в последних версиях были изменены значения параметров по умолчанию, что делает защиту системы еще надежней. И все же пользователь по-прежнему должен предпринять определенные действия по активизации всех этих форм защиты. Немного предусмотрительности – и Ваша AS/400 станет абсолютно непроницаемой для вирусов и прочей нечисти!