Эбберс М. Введение в современные мейнфреймы: основы z/OS

Подождите немного. Документ загружается.

492 Глава18

1873 Взаимодействие адресных пространств

При правильном управлении таблицей страниц со стороны операционной системы,

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

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

является взаимодействие адресных пространств (cross-memory communication).

При корректной настройке в операционной системе программа в одном стандар-

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

ресных пространствах. Существует множество возможностей взаимодействия адрес-

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

• возможность вызова программы, находящейся в другом адресном пространстве;

• возможность доступа (чтения, записи) к виртуальной памяти в другом адрес-

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

В первом случае используется инструкция вызова программы (program call, PC). Пос-

ле корректной настройки z/OS, для вызова программы, находящейся в другом адресном

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

привести DB2, основной продукт для управления базами данных компании IBM. Различ-

ные фрагменты DB2 занимают до четырех адресных пространств. С точки зрения DB2

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

ное программное обеспечение (например, веб-сервер). Когда эти пользователи переда-

ют SQL-инструкции для DB2, SQL-интерфейс приложения использует инструкцию вызов

программы для получения обслуживания в других адресных пространствах DB2.

Межпространственное программирование является достаточно сложным и должно

быть согласовано со средствами безопасности z/OS. На практике межпространственные

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

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

При стандартном программировании приложений редко затрагивается эта сфера.

Как аппаратная архитектура мэйнфрейма, так и внутренняя структура z/OS защища-

ют эти функции от некорректного использования, и не возникало серьезных про-

блем безопасности или целостности, связанных с возможностями межпространс-

твенной связи.

1874 Технологии брандмауэра z/OS

Традиционный брандмауэр выступает в качестве преграды между вашей интрасетью

(безопасной внутренней частной сетью) и другой (небезопасной) сетью в Интернете.

Назначение брандмауэра состоит в том, чтобы не допустить несанкционированной

входящей или исходящей связи в безопасной сети. Брандмауэр выполняет следующие

две функции:

• Он дает пользователям внутренней сети возможность использовать авторизо-

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

своей сети.

• Он не позволяет пользователям, находящимся за пределами сети, подключать-

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

 Безопасностьвz/OS 493

Брандмауэр может защищать сети несколькими способами. Он может осущест-

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

пользователя, имени узла и TCP/IP-протокола. Брандмауэр может также выполнять

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

пользователей. Он обеспечивает представление, что все взаимодействие между вашей

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

видеть структуру внутренней сети.

Для управления доступом между внутренней интрасетью и Интернетом с одно-

временным осуществлением авторизованных транзакций технологией брандмауэра

z/OS (z/OS Firewall Technologies) поддерживают три основных технологии: сетевые

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

188 Заключение

Обеспечение безопасности данных не только означает необходимость сделать кон-

фиденциальные данные недоступными для тех, кто их не должен видеть. Это также

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

даже не знать, как правильно обращаться с данными. Без знаний эффективных мето-

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

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

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

ций z/OS, обеспечивающих реализацию безопасности.

Средство авторизации системы (system authorization facility, SAF) является частью

операционной системы z/OS и предоставляет интерфейсы к вызываемым службам,

осуществляющим аутентификацию, авторизацию и ведение журналов.

Средства управления доступом к ресурсам (RACF) представляет собой компонент

Security Server для z/OS, управляющий доступом ко всем защищенным ресурсам z/OS.

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

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

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

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

программам z/OS, таким как TSO, CICS и DB2, проверять уровень доступа пользовате-

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

лений баз данных.

RACF позволяет организации определять пользователей и группы, использующие

систему, защищаемую RACF. Например, что касается секретаря организации, адми-

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

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

и прочую информацию.

Для достижения своих целей, RACF позволяет:

• осуществлять идентификацию и аутентификацию пользователей;

• осуществлять авторизацию пользователей для доступа к защищенным ресурсам;

• регистрировать и сообщать о попытках несанкционированного доступа к за-

щищенным ресурсам;

494 Глава18

• управлять средствами доступа к ресурсам.

Работа по управлению системой z/OS включает следующее:

• консольные операции, определяющие способ взаимодействия операторов с z/

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

нием;

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

тора с z/OS и основу автоматизации z/OS.

Управление системой z/OS включает управление оборудованием, в частности,

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

ем, в частности, операционной системой z/OS, подсистемой управления заданиями и

всеми приложениями, выполняющимися в z/OS.

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

вводить операторы на своих консолях для мониторинга и управления z/OS. Настройка,

главным образом, выполняется в RACF и в разделе CONSOLxx библиотеки PARMLIB.

Основные термины в этой главе

Авторизованныебиблиотеки Средствоавторизациипрограмм(APF)

Шифрование

Брандмауэр Хакер Битзащитыстраницы

Пароль Средствауправлениядоступомкресурсам

(RACF)

Политикабезопасности

Разделениеобязанностей Целостностьсистемы Идентификаторпользователя

189 Контрольные вопросы

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

1. Истинно ли следующее утверждение?

Информация доступа в профилях ресурсов может устанавливаться только на

уровне группы. Это означает, что один пользователь не может иметь атрибут об-

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

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

2. В следующей ситуации, что произойдет с программой, если не использовать авто

ризованные SVC или специальные функции?

а) Программа компонуется с AC=0.

б) Запускается из APF-авторизованной библиотеки.

3. В следующем примере какие могут возникнуть проблемы в программе, запускае

мой из библиотеки SYS1.LINKLIB, расположенной на томе MPRES2?

D PROG,APF,ENTRY=1

CSV450I 05.24.55 PROG,APF DISPLAY 979

FORMAT=DYNAMIC

ENTRY VOLUME DSNAME

1 MPRES1 SYS1.LINKLIB?

 Безопасностьвz/OS 495

1810 Темы для дальнейшего обсуждения

1. Как осуществляется защита наборов данных или файлов на других платформах?

Существует ли способ не допустить выполнения определенного приложения?

2. RACF позволяет назначать пользователям атрибут администратора группы. В этом

случае можно реализовать децентрализованное администрирование. Обсудите

преимущества и недостатки.

1811 Упражнения

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

с IKJACCNT на IKJACCN1. Ожидаемое сообщение имеет следующий вид:

IKJ56483I THE PROCEDURE NAME IKJACCN1 HAS NOT BEEN AUTHORIZED

FOR THIS USERID

2. Используя свой идентификатор пользователя TSO (на этот раз используя задан-

ную по умолчанию процедуру входа IKJACCNT), попробуйте удалить набор дан-

ных ZPROF.JCL.NOT.DELETE, установленный стандартными заданиями в поставля-

емом JCL. Этот набор данных является защищенным, и вы можете только про-

смотреть его содержимое.

3. Выполните следующий образец JCL-кода, чтобы получить отчет утилиты DSMON

с текущей структурой групп RACF (доступен в образце JCL-кода как раздел

DSMON):

//DSMONRPT JOB (POK,999),'DSMONREPORT',MSGLEVEL=(1,1),MSGCLASS=X,

// CLASS=A,NOTIFY=&SYSUID

/*JOBPARM SYSAFF=*

//*

//* NOTE:

//* REMEMBER THAT ICHDSM00 MUST BE RUN BY A USER WITH

AUDITOR ATTRIBUTE

//*

//STEPNAME EXEC PGM=ICHDSM00

//SYSPRINT DD SYSOUT=A

//SYSUT2 DD SYSOUT=A

//SYSIN DD *

FUNCTION RACGRP

4. Проверьте, является ли библиотека SYS1.LINKLIB APF-авторизованной.

• Используя команду DISPLAY APF для вывода всего списка APF.

• Используя операнд ENTRY= команды DISPLAY APF.

• Используя операнд DSNAME= команды DISPLAY APF. Проверьте номер записи

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

5. Следующий пример JCL-кода можно использовать для вызова утилиты ADRDSSU

496 Глава18

и вывода сообщения WTOR на консоль. Команда WTOR позволяет вывести сообще-

ние ADR112A на системную консоль. Сообщение ADR112A требует, чтобы оператор

выполнил некоторое действие, после чего ввел ответ. Например, WTOR можно ис-

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

стабилизировать (quiesce) базу данных, перед тем как задание DFSMSdss продолжит

обработку (доступно в образце JCL-кода как раздел ADRDSSU).

//WTORTEST JOB (POK,999),'USER',MSGLEVEL=(1,1),MSGCLASS=X,

// CLASS=A,NOTIFY=&SYSUID

// EXEC PGM=ADRDSSU

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

WTOR ‘TEST’

DFSMSdss назначает сообщению WTOR следующий код перенаправления

1. Основное действие оператора

DFSMSdss назначает следующий код дескриптора сообщению WTOR:

2. Требуется немедленное действие.

На главном экране SDSF выберите опцию SR (system requests) и введите любой ответ.

 Сетевыесвязивz/OS 497

Сетевые связи в z/OS

ЦельПриработессетевымисвязямивz/OSвампотребуетсявзаимодействовать

сTCP/IP-иSNA-сетями

Вэтойглавемырассмотримследующиетемы:

• сравнениеразличныхмоделейкоммуникационныхсетей;

• программныекомпонентыпродуктаz/OSCommunicationsServer;

• сравнениетопологииподобластейSNAисетевойтопологииAPPN;

• использованиеIP-сетидляпередачиданныхмеждуSNA-приложениями;

• частоиспользуемыекомандыTCP/IPиVTAM

498 Глава19

191 Связь в z/OS

Сетевая связь имеет как программные, так и аппаратные аспекты, и разделение про-

граммных и аппаратных задач связи распространено на больших предприятиях. Од-

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

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

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

мание коммуникационного программного обеспечения z/OS в любой проект, предпола-

гающий работу с сетью компании. Хотя специалисты по сетевому оборудованию имеют

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

включает знание коммуникационного программного обеспечения z/OS. Когда, напри-

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

z/OS и специалисты по сетевому оборудованию должны согласовывать свои усилия.

Приложения

z/OS

APPC

Сокеты

RPC

SNA

RPC

Сокеты

APPC

TCP/IP

Рис 191 КоммуникационныйсерверIBM

z/OS включает полнофункциональный коммуникационный сервер с многопрото-

кольной сетевой обработкой. Эта глава начинается с обзора существующих сетевых

технологий в z/OS, после чего в разделе 19.3 «z/OS Communications Server» обсуждают-

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

192 Краткая история сетей данных

Разработанный в 1969 году, TCP/IP в действительности на пять лет старше, чем системная се-

тевая архитектура (System Network Architecture – SNA). Однако SNA стал сразу доступен обще-

ственности, тогда как TCP/IP сначала имел ограниченное использование в военных и иссле-

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

шественниках Интернета

 Сетевыесвязивz/OS 499

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

было в TCP/IP, через протокол SDLC (Synchronous Data Link Control). В 1980-х годах

протокол SNA имел широкое применение в крупных корпорациях, так как он позво-

лял ИТ-организациям использовать централизованные вычислительные возможнос-

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

Например, широкое использование SNA позволило отрасли розничной торговли

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

В 1983 году TCP/IP стал общедоступным с появлением Berkeley BSD UNIX. Уровень

развития TCP/IP, его приложения и уровень принятия росли посредством примене-

ния механизма Request-For-Comment (RFC), используемого комитетом по открытым

стандартам Internet Engineering Task Force (IETF).

Термин интерсеть (internet) используется как общий термин в сети TCP/IP, и его

не следует путать с Интернетом (Internet), состоящим из больших международных

магистральных сетей, связывающих все TCP/IP-хосты, имеющие подключение к ма-

гистрали Интернета.

TCP/IP разрабатывался для взаимосвязанных сетей (интерсетей) и был проще в

настройке, тогда как протокол SNA имел иерархическую структуру с «централизован-

ным» мэйнфреймом на вершине иерархии. Структура SNA включала управление се-

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

служивания» определенным рабочим нагрузкам.

Связь между автономными SNA-сетями стала доступна в 1983 году. До этого вре-

мени SNA-сети не могли с легкостью взаимодействовать друг с другом. Способность

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

сурсы называется межсетевым взаимодействием SNA (SNA Network Interconnect, SNI).

1921 SNA и TCP/IP в z/OS

Протокол SNA (System Network Architecture) был разработан компанией IBM. SNA

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

стране. Для этого SNA содержал такие средства, как Virtual Telecommunication Access

Method (VTAM), Network Control Program (NCP) и контроллеры терминалов, а также

протокол SDLC (Synchronous Data Link Control). То, чем TCP/IP и Интернет стал для

общества в 1990-х, тем SNA был для больших предприятий в 1980-х.

TCP/IP (Transmission Control Protocol/Internet Protocol) представляет собой непа-

тентованный набор коммуникационных протоколов, являющийся отраслевым стан-

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

мосвязанные сети различных типов. TCP/IP получил широкое распространение с раз-

витием сети Интернет, так как он позволял относительно дешево осуществлять доступ

к удаленным данным и обработку данных. TCP/IP и Интернет привели к распростране

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

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

Крупные предприятия, использующие SNA, увидели большой потенциал в том,

чтобы расширить доступ к данным и приложениям, доступным через SNA, для расту-

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

клиентов, небольших офисов и т. д.

500 Глава19

1922 Многоуровневые сетевые модели

TCP/IP и SNA представляют собой многоуровневые сетевые модели. Каждую из них

можно сопоставить с международной сетевой моделью OSI (Open Systems Intercon-

nect); (рис. 19.2).

Физический уровень

Канальный уровень

Управление каналом

IP ARP RARP ICMP

Сетевой уровень

Управление маршрутом

TCP UDP

Транспортный уровень

Управление передачей

Сеансовый уровень

Управление потоком данных

telnet, np, SNMP, SMTP

Уровень представления

данных

Прикладной уровень

Служба транзакций

Менеджер служб NAU

Управление функциями

Служба данных

TCP/IP

OSI

SNA

Многоуровневые сетевые модели

Рис 192 СетеваямодельOSI(OpenSystemsInterconnect)

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

ких элементов, осуществляющих межузловую передачу данных. Как показано на

рис. 19.2, между сетевой моделью OSI и протоколами SNA и TCP/IP есть много общего.

Хотя ни одна технология не имеет прямого соответствия сетевой модели OSI (TCP/IP

и SNA появились до того, как была формализована сетевая модель OSI), есть много

общего, так как определены уровни моделей.

Сетевая модель OSI разделена на семь уровней. Седьмой уровень модели OSI (при-

кладной) имеет непрямое соответствие верхним уровням стеков SNA и TCP/IP. Пер-

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

уровням стеков SNA и TCP/IP.

В одном стандартном сценарии два географически рассредоточенных програм-

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

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

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

мэйнфреймах, персональных компьютерах, кассовых устройствах, банкоматах, тер-

миналах или контроллерах принтеров. Конечные узлы в SNA называются логически-

ми устройствами (logical units, LU), тогда как в терминологии IP они называются

портами приложений (или просто портами).

 Сетевыесвязивz/OS 501

Рассмотрим, как эту модель можно использовать в сетевых коммуникациях в боль-

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

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

используется дважды:

• Приложение кассового устройства находится на верхнем уровне локального

многоуровневого сетевого стека.

• Приложение, записывающее сведения о покупке и авторизующее ее выполнение,

находится на верхнем уровне удаленного многоуровневого сетевого стека.

Локальный сетевой стек может работать на системе, отличной от мэйнфрейма,

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

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

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

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

но через сетевые стеки для завершения продажи.

Эта транзакционная модель часто называется запрос-серверным или клиент-сер-

верным отношением.

1923 Надежность и доступность сети

Что произойдет, если сеть или подключенный мэйнфрейм из нашего примера с се-

тью продуктовых магазинов по какой-то причине станет недоступным? Большинство

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

ции в интеллектуальном кассовом контроллере

или небольшом процессоре магази-

на. После устранения причины отключения, накопленные транзакции передаются на

мэйнфрейм одним пакетом.

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

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

торговой сети. Суммарный эффект от неточных записей может с легкостью развалить

бизнес. Поэтому надежность, доступность и удобство обслуживания (reliability, availabil-

ity, serviceability – RAS) для сети настолько же важны, как и для мэйнфрейма.

1924 Факторы, определяющие популярность SNA

Протокол SNA является стабильным и надежным протоколом, поддерживающим

критически важные бизнес-приложения по всему миру. Значительный объем корпо-

ративных данных в мире обслуживается SNA-приложениями под управлением z/OS

Отличительная особенность SNA состоит в том, что этот протокол является протоко-

лом на основе соединений, содержащим множество таймеров и механизмов управле-

ния, обеспечивающих надежную доставку данных.

ИТ-организации, использующие мэйнфреймы, часто скептически относятся к пе-

реходу с SNA на TCP/IP, несмотря на привлекательность TCP/IP и веб-коммерции.

Этот скептицизм часто оправдан. Переделка стабильных, хорошо отлаженных биз-

нес-приложений под использование TCP/IP-сокетов вместо программных интерфей-

сов SNA может отнять много времени и средств.

SNA-приложения, работающие под управлением z/OS, также называются VTAM-приложениями.