- •1 Основы и основные понятия корпорации и кис
- •2 Общие вопросы проектирования и внедрения кис
- •2.1 Что даёт внедрение кис?
- •2.2 Принципы построения кис
- •2.3 Этапы проектирования кис:
- •Классический жизненный цикл
- •Макетирование (прототипирование)
- •Стратегии разработки по
- •Инкрементная стратегия
- •Эволюционная стратегия разработки по
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •3 Классификация и характеристики кис
- •3.1 Классификация кис
- •3.2 Классификация автоматизированных систем
- •3.3 Характеристики кис
- •4 Архитектура кис
- •5 Требования, предъявляемые к кис
- •5. Гибкость
- •7. Эффективность
- •8. Безопасность
- •6 Выбор аппаратно-программной платформы кис
- •7 Международные стандарты планирования производственных процессов. Mrp/erp системы
- •7.1 Управление промышленными предприятиями в стандарте mrp II
- •7.2 Современная структура модели mrp/erp
- •7.2.1 Управление запасами
- •7.2.2 Управления снабжением
- •7.2.3 Управление сбытом
- •7.2.4 Управления производством
- •7.2.5 Планирование
- •7.2.6 Управление сервисным обслуживанием
- •7.2.7 Управление цепочками поставок
- •7.2.8 Управление финансами
- •8 Основные аспекты автоматизации деятельности предприятия на примере финансово-управленческих систем
- •9 Области применения и примеры реализации информационных технологий управления корпорацией
- •9.1 Бухгалтерский учет
- •9.2 Управление финансовыми потоками
- •9.3 Управление складом, ассортиментом, закупками
- •9.4 Управление производственным процессом
- •9.5 Управление маркетингом
- •9.6 Документооборот
- •9.7 Системы поддержки принятия решений, системы интеллектуального анализа данных
- •9.8 Предоставление информации о предприятии
- •10 Распределенные системы
- •10.1 Распределенные бд в Oracle и Oracle в распределенных бд
- •10.2 Администрирование распределенных систем на примере Oracle
- •11 Omg и её стандарт corba
- •11.1 История создания omg и стандарта corba
- •11.2 Брокер (посредник) объектных запросов orb (Object Request Broker)
- •11.3 Idl (Interface Definition Language - язык определения интерфейсов)
- •11.4 Object Services - объектные сервисы
- •11.5 Common Facilities - общие средства
- •11.6 Достоинства corba
- •11.7 Обзор протоколов giop и iiop
- •11.8 Безопасность в corba
- •11.8.1 Основные понятия corba Security Service
- •1. Принципал (principal)
- •2. Аутентификация (authentication)
- •3. Удостоверения (credentials)
- •4. Авторизация (authorization)
- •5. Делегирование (delegation)
- •6. Доверительные отношения (trust)
- •11.8.2 Структура corba Security Service
- •11.8.3 Делегирование в corba Security Service
- •11.8.4 Домены безопасности
- •11.8.5 Объектная модель обеспечения безопасности
- •11.8.5.1 Модель с точки зрения разработчика
- •11.8.5.2 Модель с точки зрения администратора
- •11.8.6 Основные политики безопасности
- •11.8.6.1 Управление политиками безопасности на уровне приложения
- •1. Доказательность (non-repudiation)
- •2. Интерфейс Current
- •12 Стандарт odbc
- •1. Назначение и отмена назначения
- •2. Соединение
- •13.1 Развитие сом-технологий
- •13.2 Терминология сом
- •14 Сравнительный анализ технологий corba и com
- •14.1 Концептуальный фундамент технологии
- •14.2 Комплексность системы
- •14.3 Используемые языки программирования
- •14.4 Уровень абстракции
- •14.5 Поддержка компонентной модели
- •14.6 Универсальный протокол обмена
- •14.7 Поддержка со стороны различных производителей и открытость
- •14.8 Развитость сервисной части
- •14.9 Самодокументирование системы
- •14.10 Технология и описание проекта
- •14.11 Виды объектов
- •14.12 Способы взаимодействия
- •14.13 Производительность
- •14.14 Масштабируемость
- •14.15 Устойчивость к сбоям
- •14.16 Управление транзакциями
- •14.17 Обеспечение безопасности
- •14.18 Взаимодействие с Internet
- •14.19 Скорость разработки систем
- •14.20 Простота использования
- •14.21 Взаимодействие с другими технологиями
- •14.22 Общие выводы
- •15 Обзор кис
- •15.1 Microsoft Business Solution Navision
- •15.2 Система SiteLine
- •15.3 Тб.Корпорация
- •15.4 Система Alfa
- •15.5 Система Парус
- •15.6 Прикладное решение для системы 1с:Предприятие 8.0 "Управление производственным предприятием"
- •15.7 Система "бэст-офис"
11.8.3 Делегирование в corba Security Service
Графически возможные (согласно спецификации) схемы делегирования можно выразить следующим образом:
Запрет делегирования.
Рисунок 11.1
Каждый промежуточный объект, участвующий в цепочке вызовов, выступает от «собственного имени» и использует свои атрибуты и привилегии.
Простое (simple) делегирование.
Рисунок 11.2
Клиент делегирует свои полномочия промежуточному серверу, который может использовать их как для разрешения (запрета) доступа к своим ресурсам, так и для передачи дальше, по цепочке вызовов. Каждый промежуточный (и конечный) сервер считает, что к нему обращается начальный клиент.
Комплексное (composite) делегирование.
Рисунок 11.3
Клиент позволяет делегировать свои полномочия дальше по цепочке вызовов, при этом промежуточный сервер может добавить к ним собственные привилегии. Если это необходимо, последующие сервера могут анализировать полученные по ORB привилегии независимо друг от друга.
Комбинированное (combined) делегирование.
Рисунок 11.4
Режим похож на предыдущий, за одним исключением: промежуточный объект создает обобщенные наборы атрибутов и привилегий, и последующий сервер (конечный сервер на приведенном рисунке) уже не может отличить, к какому из участвующих в цепочке вызовов объекту относятся отдельные привилегии.
Сервис Безопасности CORBA позволяет при делегировании вводить и другие ограничения. Например, клиенты и промежуточные сервера могут делегировать только часть своих полномочий; администратор или программист может задать период времени, в течение которого можно использовать делегирование и т.д.
Для приложений, которые непосредственно не обращаются к API Security Service (Level 1), режим делегирования задается по умолчанию с использованием политик безопасности, и промежуточные объекты не могут в процессе работы приложения менять указанный способ делегирования.
11.8.4 Домены безопасности
Одним из важных понятий спецификации Сервиса Безопасности является понятие «домена безопасности» (security domain). Доменная структура системы обеспечения безопасности оказывает непосредственное влияние и на совместимость, и на переносимость используемых программных средств, и на уровень сложности администрирования, и на эффективность работы приложений. Спецификация различает три вида доменов безопасности:
Технологический домен (security technology domain).
В один технологический домен входят приложения, использующие, например, единую систему аутентификации принципалов, одну технологию распространения ключей, одну систему шифрования и/или обеспечения целостности данных, одну систему принятия решения о предоставлении доступа, одну систему аудита и т.д. Решение задачи защищенного взаимодействия при наличии нескольких технологических доменов, как правило, связано с серьезными сложностями. Спецификация Сервиса Безопасности не формализует никаких правил обеспечения взаимодействия в этом случае.
Домен политик безопасности (security policy domain).
CORBA Security Service обладает очень развитой системой QoS (quality of service), т.е. средствами настройки системы с точки зрения ее оптимизации по различным критериям. Спецификация вводит большое количество политик безопасности. Поскольку в CORBA «единицей защиты» является объект, то на практике защищать каждый объект отдельно совершенно нереально. Вместо этого объекты объединяются в домены политик безопасности (этот подход используется в CORBA не только для политик безопасности, но и вообще для любых политик), и в каждом таком домене единый набор политик относится ко всем объектам данного домена. Как обычно, для управления политиками на уровне домена необходимо определить менеджера этих политик (Policy Manager). Применительно к доменам политик безопасности, такой менеджер часто называется «SecurityAuthority»
Поскольку домены политик безопасности ничем принципиально не отличаются от других доменов политик CORBA, поддерживаются иерархии доменов и объединения (федерации) доменов. Домены могут перекрываться –один и тот же объект может входить в различные домены политик, например, в один домен политик с точки зрения политик управления правами доступа и в другой – с точки зрения политик аудита.
Поскольку CORBA Security Service поддерживает два вида приложений с точки зрения их явного использования API Сервиса, то можно делить домены политик безопасности еще на две группы – домены системных политик безопасности и домены прикладных политик безопасности. Задание и использование системных политик безопасности выполняется силами ORB, Сервиса Безопасности и операционной системы, и приложения об этом может даже не знать,
Рисунок 11.5
Домен среды безопасности (security environment domain)
Понятие «домена среды безопасности» тесно связано с «доменом политик безопасности». Домен политик – это логическая область с заданным набором политик и их значений. Домен среды – это область, в которой используется некий единый подход, который обеспечивает защиту ресурсов в соответствии с заданными политиками.
Домен среды безопасности – понятие логическое, явно границы таких доменов не определены ни на уровне приложений, ни на уровне самого Сервиса Безопасности. Обычно домены среды безопасности появляются в связи с отказом от использования тех или иных методов защиты данных на уровне Сервиса Безопасности. Например, если шифрование данных используется на уровне транспортного протокола, то нет разумных причин возлагать решение этой задачи на приложение или ORB. Другой пример – отказ от избыточных операций аутентификации принципалов в случае, если между объектами в одном домене среды безопасности установлены доверительные отношения.
С точки зрения организации взаимодействия в защищенной гетерогенной среде, можно также принять во внимание отличия в реализации ORB’ов, введя тем самым, понятие «домена ORB».
Общая схема организации защищенного взаимодействия объектов с учетом наличия различных технологических доменов и доменов ORB может выглядеть так:
Рисунок 11.6