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

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


Размещение серверов каталогов


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


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


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


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


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


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


Синхронизация часов


О значении службы времени и
соответствующих рекомендациях OSF можно
прочитать в руководстве "OSF DCE Administration Guide,
Core Components", которое входит в комплект
поставки DCE. В нем подробно описано, какие
службы времени нужны для ячеек при той или
иной конфигурации сети. Поскольку
небольшая ошибка в системных часах может
нарушить совместимость защищенных
приложений DCE, лучше всего обратиться в
службу точного времени.


Серверы лицензий


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


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


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


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


Подготовка персонала


От вас потребуется составить план и
выделить средства для найма и обучения
обслуживающего персонала. Предлагается
следовать рекомендациям, принятым для NetWare
и для других распределенных сред: на каждые
100 пользователей и серверов приложений
должен приходиться один администратор.


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


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



К содержанию
Вперед Назад






<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">





Обзор лицензирования






К содержанию
Вперед Назад



Обзор лицензирования


Общая концепция


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


Для лицензирования в AIX применяется
программный продукт iFOR/LS (Information For Operation and
Retrieval License System). Это программное обеспечение
управления лицензиями использует
стандартную промышленную распределенную
технологию Network Computing System (NCS) для вызова
удаленных процедур в модели клиент/сервер.


Цена на LPP для AIX и их поставка
осуществляется используя две модели
лицензирования: лицензия на пользователя
лицензия на сервер/неограниченное
количество пользователей


Используя зашифрованные ключи iFOR/LS
осуществляет мониторинг типов и количества
лицензий используемых в системе.


iFOR/LS


Пакет iFOR/LS является расширением системы
NetLS и его команды на 100% совместимы с
системой команд NetLS. Компания Hewlett-Packard
приобрела права на NetLS вместе с
приобретением компании Apollo Computers. В 1987 году
компания Gradient Technologies согласно соглашению с
HP перенесла этот продукт на AIX под новой тор-говой
маркой iFOR/LS.


Компонентами iFOR/LS являются:


NCS 1.5.1.

ARK

ADK iFOR/LS требует применения NCS 1.5.1.


NCS является отдельно устанавливаемым
пакетом bos.net.ncs.obj, содержащим комплект
инструментов для распределенных
вычислений.


iFOR/LS поставляется разделенным на две
части: ориентированной на поддержку
разработчиков программ и ориентированной
на поддержку администраторов.


Разработчикам программ понадобится
Application Developer's Kit (ADK). Для системных
администраторов предназначен пакет Administrator
Runtime Kit (ARK), предназначенный для установки и
управления сервером лицензирования, вместе
с инструментами создания отчётов.


Типы лицензий


Программный продукт iFOR/LS использует
несколько различных типов лицензий:


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


Concurrent use Конкурентное использование
лицензионного программного обеспечения
предоставляет возможность лицензиям на
использование программ "плавать" по
сети и при запросе любого пользователя,
если есть свободная лицензия, ему будет
разрешено запустить программу.


Use once Этот механизм использует счетчик
количества запусков лицензионного
программного продукта. И при установке
счетчика в 0 программу запустить больше
нельзя. Используется для целей
ознакомления пользователей с программой (try
and buy).


Compound Составная лицензия содержит в
себе пароль на создание большего числа
лицензий. Этот пароль сообщает вам
производитель программы при покупке вами у
него дополнительного количества лицензий.


Сервер лицензирования


Сервер (серверы) лицензий должен быть
запущен на высокодоступной, надежной и
контролируемой системе. Конечно,
желательно, чтобы он (они) размещался в той
же сети, где размещены и клиенты, требующие
лицензий.


Каждый сервер лицензирования действует
независимо друг от друга.


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


При запросе пользователя на
использование лицензионного программного
продукта iFOR/LS обращается с запросом на
лицензию к серверу лицензий, который
проверяет наличие лицензии в базе лицензий
и права доступа пользователя. При наличии
лицензии и достаточных прав пользователя
сервер лицензий возвращает утверждение
запроса iFOR/LS, который в свою очередь
предоставляет лицензию пользователю.


Политика лицензирования


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


Softstop Политика, когда при отсутствии
лицензии пользователю всё же разрешается
запустить программу, но об этом делается
запись в файле аудита


Hardstop Политика, когда при отсутствии
лицензии пользователю не разрешается
запустить программу. Интерактивные
приложения при отсутствии свободной
лицензии могут предложить пользователю
следующие варианты:


Wait Перейти в режим ожидания. Когда
лицензия освободиться другим
пользователем, требуемая программа
запустится.


Quit Выход.


List Показать список систем
использующих лицензии в настоящее время.


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


Различные прикладные программы
используют различное время удержания
лицензий (время повторного опроса сервера
лицензий на предмет наличия свободных
лицензий). Длинные интервалы удержания
минимизируют сетевой трафик. Короткие
периоды позволяют быстрее предоставлять
свободные лицензии нуждающимся в них
пользователям. Можно изменять
одноминутными интервалами. Рекомендуется:
5-10 минут. Для программы входа в систему AIX BOS
login это время составляет 15 минут.


Установка сервера "плавающих"
лицензий


Установка сервера "плавающих"
лицензий состоит из трех процедур:


1. Установка программного обеспечения iFOR/LS


2. Конфигурирование NCS и iFOR/LS


3. Запуск серверных демонов (фоновые
процессы) llbd dlbd netlsd


В директории /usr/lib/netls/conf содержится
командный файл netls_config, который
автоматизирует процедуру установки.



К содержанию
Вперед Назад






<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">





Common Desktop Environment (CDE)






К содержанию
Вперед Назад



Common Desktop Environment (CDE)



Что такое CDE?



Common Desktop Environment (CDE) desktop - интерактивный
графический интерфейс пользователя,
совместно разработанный компаниями IBM, HP, Sun,
и Novell для открытых систем. Desktop - богатый и
интуитивный интерфейс пользователя,
основанный на X11 release 5 и OSF/Motif 1.2. Этот
интерфейс разработан для применения в
информационных системах масштаба
предприятия и на различных платформах и
обращен к широкому диапазону пользователей
от новичка до эксперта.



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



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



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



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



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



Рабочий стол также поддерживает
существующие прикладные программы X Window,
OSF/MOTIF и OPENLOOK.



Почему CDE?



Преимущества CDE



Широкое применение в индустрии



CDE широко применяется в индустрии UNIX,
многими независимыми поставщиками
программного обеспечения и разработчики
прикладных программ.



Обширная система интерактивной справки



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



Богатый набор инструментальных средств
для производительной работы



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



Множественные рабочие области



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



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



Основан на стандартах



CDE основан на промышленных стандартах X-OPEN,
X11 release 5, OSF/MOTIF 1.2 и Spec 1170.



Интуитивность



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



Краткое описание рабочего стола AIX CDE



Управление окнами / лицевая панель



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



Администратор окон основан на стандартах
OSF/MOTIF 1.2 и включает в себя расширения для
поддержки множественных рабочих областей (дополнительные
области экранного пространства).



Лицевая панель обеспечивает доступ к
часто используемыми пиктограммам. Имеется
также удобные пиктограммы блокировки
экрана и выхода из системы. Лицевая панель
настраивается через простые меню;
пользователи могут добавлять, удалять или
переименовывать рабочие области, создавать
субпанели и управлять ими. Опытные
пользователи могут редактировать файлы
конфигурации лицевой панели. Эти файлы
могут изменять лицевую панель так, чтобы
поддерживать специфические потребности
заказчика, например, изменение размеров
лицевой панели, размещения её на экране, а
также замены или добавления пиктограмм.



Администратор файлов



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



Администратор файлов позволяет создавать,
перемещать, копировать и удалять объекты, а
также изменять их свойства. Большинство
этих действий может быть выполнено или
через прямое манипулирование (методом drag and
drop) или через меню.



Администратор стиля



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



Интерактивная справка CDE



Desktop обеспечивает интерактивную систему
контекстно-чувствительной справки, которая
включает просмотр и поддержку гипертекста
для информации основанной на SGML.
Администратор справки включает API которые
позволяют прикладным программам
представлять их собственные контекстно-чувствительные
окна помощи. Эти API позволяют разработчикам
прикладных программ сэкономить время для
создания системы помощи.



Инструментальные средства пользователя



CDE Desktop предлагает набор графических
инструментов для просмотра и
редактирования данных и для связи с другими
пользователями. В состав этих инструментов
входят текстовый редактор, редактор
пиктограмм, клиент электронной почты,
календарь и инструменты печати. Эти
прикладные программы сильно интегрированы
друг с другом и с услугами desktop. Также
стандартно поставляются программы
графического калькулятора, часов, просмотр
man-страниц и т.п.



Инструменты разработок программ



Desktop стандартно включает в себя два
инструментальных средства, которые
поддерживают быстродействующие
прототипирование и разработку графических
интерфейсов. Эти инструментальные средства
- Application Builder и dtscript.



Dtscript - графический интерфейс создания
диалогов и сценариев, основанный на
технологии Windowing Korn Shell.



Application Builder - дополнительный простой
инструмент разработки, который
поддерживает новые widgets CDE.



Оба из этих инструмента позволяют
пользователю создавать графический
интерфейс, используя технику drag and drop.



Интернационализация



Desktop доступен на многих различных языках (в
том числе и на русском). Реализация
поддерживает независимость от кодовой
таблицы и также позволяет пользователю
выбирать язык при входе в систему.



К содержанию
Вперед Назад






<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">





Приложения






К содержанию
Вперед Назад



Приложения



Планирование безопасности



ОС
AIX - полностью "открытая система". Эта
ОС сама по себе не имеет никакой эффективной
защиты, но она обеспечивает администратора
инструментальными средствами для создания
безопасной системы.



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



1. ОС AIX;



2. Сетевая среда;



3.
Среда NFS (и NIS, если используется).



При
начальной установке



1. Установите TCB.



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



3. Установите
следующие ограничения пароля в заданной по
умолчанию станзе файла /etc/security/user:



pw_restrictions:
maxage = 12 (force change after 12 weeks)
maxrepeat = 3 (max three repeated characters)
minalpha = 1 (at least 1 alpha character)
mindiff = 3 (at least 3 different from last time)
minother = 1 (at least 1 nonalpha character)
maxexpired = 4 (allow logon 4 weeks after expired)
histexpire = 26 (prohibit reuse for 26 weeks)
histsize = 8 (prohibit reusing last 8 passwords)
pwdwarntime = 14 (start warning 14 days before expire)


4. Определите
значение блокировки по времени. Поместите
его в файл /etc/profile, если значение блокировки
по времени должно быть единым для всех
пользователей:



TMOUT=1800 (for Korn shell)
TIMEOUT=1800 (for Borne shell)
export TIMEOUT TMOUT


Значение блокировки по
времени выражено в секундах. Например,
значение 1800 означает, что оболочка должна
блокировка по времени, если не производится
никакого действия в течение 30 минут.
Установите, и TMOUT и TIMEOUT, если ваши пользователи
могут использовать любую оболочку.



5. Модифицируйте подсказку оболочки.



6. Переназначьте вывод
skulker и подобных ему отчетов в один файл,
например, /tmp/dailyreport - это сделает проще
ежедневный контроль действий системы и её
состояния.



7. Команда securetcpip отключает
некоторые сетевые сервисные демоны. Если не
требуется применение команды rlogin и
связанных с нею, то используйте эту команду.




8. В директории /var/adm/cron, используйте файлы
cron.allow, cron.deny, at.allow, и at.deny для управления
доступом к функциям cron.



9. Измените
сообщение при входе в систему, которое
идентифицирует вашу ОС.



10. Узнайте, как
изменить сообщение дня.



11. Назначьте
различные пароли root для различных машин.
Администратор должен гарантировать, что
для различных машин пароли root отличаются
друг от друга. Можно позволить обычным
пользователям иметь те же самые пароли на
различных машинах, но никогда делайте
этого для пользователя root.



12. Продумайте
план мероприятий чрезвычайных мер. В том
случае, когда администратор не сможет быть
при аварии, другой уполномоченный человек
должен иметь доступ к необходимому паролю.
Использование этой процедуры должно
регистрироваться и пароль должен быть
изменен немедленно после его использования
в чрезвычайной ситуации.



13. Рассмотрите
необходимость отключения всех удаленных и
dial-in терминалов в конце рабочего дня.
Разрешите им доступ утром.



14. Тщательно
проверьте все в заданных по умолчанию
параметрах станзы файла /etc/security/user.
Установите соответствующие значения по
умолчанию прежде созда-ния пользователей.
Это позволит не определять большиноство
параметров для вновь создаваемых
пользователей.



15. Рассмотрите
необходимость отключения возможности
входа в систему под именем root на любой
системе, на которой более чем один человек
знает пароль root. Такое отключение вынудит
пользователей входить в систему под их
собственным userid и затем выполнять команду su
root. Средства аудита и/или записи в файле/var/adm/sulog
будут контролировать этих пользователей.



16.
Отредактируйте файл mkuser.default.



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



Продолжение действий



1. Делайте копии.
Храните архивы. Убедитесь, что ещё кто-то
кроме вас знает, как восстановить файлы с
самой свежей копии.



2. Остерегайтесь "свободно
распространяемого программного
обеспечения", "ПО общего пользования"
или файлов, полученных с анонимного ftp-сервера.
Никогда не запускайте общий файл при
работе в системе с полномочиями root, если вы
не исследовали этот файл и полностью не
доверяете ему.



Выполнение этого требования
может быть трудным делом. Пользователь (или
даже ваш начальник) может прийти к вам с "замечательной"
программой, которая ему срочно необходима.
При этом она была получена "откуда-то"
(из не очень доверенного источника) и
различными способами передачи файла (с
помощью не очень доверенного канала) и
должна быть установлена с полномочиями root.



3. Новый пользователь, созданный через SMIT, не
способен работать в системе, пока его
пароль не создан (с помощью SMIT или командой
passwd). Вы можете создавать новых
пользователей прежде, чем они необходимы и
временно не создавать для них пароли, пока
этим пользователям не требуется доступ к
системе.



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




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

4.2. Объясните вашу стратегию относительно
автоматических терминалов и операции
блокировки по времени.

4.3. Дайте новому
пользователю письменную копию стратегии
безопасности вашей организации.

4.4.
Попросите нового пользователя войти в
систему. ОС попросит нового пользователя
изменить пароль. Убедитесь, что он изменяет
пароль.

4.5. Убедитесь, что пользователь
знает где хранить его файлы (например, в
директории /u/userid) - и где не хранить их (например
в директории /tmp).

4.6. Проинструктируйте его
по поводу опасности раскрытия (или дачи "взаймы")
его пароля любому другому человеку.




5. Не
позволите пользователям совместно
использовать userid (совместно используя
пароль) или UID (устанавливая несколько
счетов с тем же самым UID).



6. При оказании
помощи пользователю, не делайте su root из его
сеанса. Если вы делаете это, вы используете
его среду (с его PATH) и это открывает большое
количество дефектов безопасности. Если вы
всё же делаете su root из сеанса пользователя,
то используйте полные имена пути для всех
команд, которые вы используете при выполнении
их как root.



7. Остерегайтесь пользователей,
которые изменяют IFS (входной разделитель
полей) в своих профилях. Не позволяйте им
изменять файл /etc/profile. Хорошо осведомленный
пользователь может проигрывать много умных
приемов терминала с IFS и вызывать
бесконечные проблемы.



8. Не поместите
текущую директорию в PATH для root. Для отмены
заданного по умолчанию PATH в заданном по
умолчанию профиле (в файле /etc/profile) вы должны
создать файл a.profile для root. a.profile находится в
исходном каталоге пользователя.



9. Значение
umask должно быть установлено для
пользователей. Значение umask по умолчанию -
022, хотя значение 027 (отключает любой доступ
"остальным") может быть лучше.
Специфические значения umask могут быть
помещены в индивидуальные файлы настроек
пользователей $HOME/.profile (не забудьте, что
пользователь может изменять его
собственное значение umask в любое время).



10.
Если Вы активизировали любые функции
ревизии, Вы должны проверить их вывод по
крайней мере ежедневно, при поиске
необычных событий. Необычные события могут
включать в себя действия в нерабочие часы,
повторенные отказы входа в систему,
повторенные отказы с командой su, и т.д.



11.
Используйте tcbck ежедневно или по крайней
мере еженедельно.



12. Модифицируйте профиль
tcbck, когда важные файлы (из точки зрения
защиты) или программы suid добавлены к
системе.



13. Проверяйте файл /tmp/dailyreport
ежедневно, если он существует.



Дополнительная аутентификация AIX позволяет
Вам определять дополнительные первичные
опознавательные шаги ("методы") и
вторичные опознавательные шаги. В
терминологии AIX, первичный опознавательный
метод может отклонять вход в систему
пользователя; вторичный опознавательный
метод не может отклонять вход в систему.



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