- •Содержание
- •Рекомендации
- •Введение
- •Модуль 1. Кис: терминология, цели создания, проблемы, стандарты и методологии Введение
- •Глава 1.1. Типы корпораций
- •§ 1.1.1. Индустриальные корпорации и их эволюционный путь.
- •§ 1.1.2. Классическая корпорация и пределы ее развития
- •§ 1.1.3. Этатистские корпорации и их ограниченность
- •§ 1.1.4. Креативная корпорация и ее перспективы
- •Глава 1.2. Структура корпорации Введение
- •§ 1.2.1. Основные характеристики современной корпорации
- •§ 1.2.2. Принципиальная организационная структура корпорации
- •Глава 1.3. Базовые стандарты управления корпорацией Введение
- •§ 1.3.1. Эволюция информационных систем управления предприятием
- •§ 1.3.2. Зарождение методологий mps и mrp
- •§ 1.3.3. Входные элементы и результаты работы mrp-программы
- •§ 1.3.4. Стандарт mrpii
- •§ 1.3.5. Иерархия планов в mrpii-системе
- •Глава 1.4. Механизм работы mrpii-системы
- •§ 1.4.1. Составление производственного плана и общего плана деятельности
- •§ 1.4.2. Составление плана потребностей в производственных мощностях
- •§ 1.4.3. Контроль выполнения производственного плана
- •§ 1.4.4. Формирование списков операций
- •§ 1.4.5. Обратная связь и её роль в mrpii-системе
- •Модуль 2. Стандарты erp, csrp и erpii Введение
- •Глава 2.1. Стандарт erp
- •§ 2.1.1. Переход от стандарта mrpii к erp
- •§ 2.1.2. Scm-стратегия
- •§ 2.1.3. Crm-стратегия
- •Глава 2.2. Планирование в erp-системе
- •§ 2.2.1. Разработка плана производства в erp–системе
- •§ 2.2.2. Определение групп изделий
- •§ 2.2.3. Базовые стратегии
- •§ 2.2.4. Гибридная стратегия
- •§ 2.2.5. Разработка плана производства запасов
- •1. Имеются ли у предприятия ресурсы для выполнения плана производ-
- •Глава 2.3. Новые стандарты csrp и erpii Введение
- •§ 2.3.1. Революционная концепция csrp
- •1. Продажа и Маркетинг
- •§ 2.3.2. Открытые технологии в csrp
- •§ 2.3.3.Концепция erpii
- •2.3.4 Новая концепция eas
- •Модуль 3. Корпоративные сети Введение
- •Глава 3.1. Корпоративные сети: основные понятия Введение
- •§ 3.1.1. Что такое корпоративная сеть?
- •§ 3.1.2. Роль Internet в корпоративных сетях
- •§ 3.1.3. Локальные сети и системы “клиент-сервер”
- •Глава 3.2. Intranet – как инструмент корпоративного управле-
- •§ 3.2.1. Основополагающие принципы Intranet Рассмотрим с разных сторон основные принципы Intranet. Во-первых, Intanet – это “интеллект” организации.
- •§ 3.2.2. Уникальность Intranet
- •§ 3.2.3. Архитектура Intranet
- •§ 3.2.4. Многоуровневый характер Intranet
- •Глава 3.3. Принципы построения корпоративных сетей передачи данных
- •§ 3.3.1. Особенности стека tcp/ip
- •§ 3.3.2. Виртуальные сети
- •§ 3.3.3. Сети на основе протокола X.25
- •§ 3.3.4. Сети Frame Relay
- •§ 3.3.5. Структура корпоративной сети
- •Глава 3.4. Проектирование и безопасность Intranet-сети
- •§ 3.4.1. Трудности создания Intranet
- •§ 3.4.2. Оценка исходного состояния организации
- •§ 3.4.3. Информационная безопасность в Intranet-сетях
- •§ 3.4.4. Сетевые аспекты политики безопасности
- •§ 3.4.4. Управление доступом путем фильтрации информации
- •§ 3.4.5. Безопасность программной среды
- •§ 3.4.6. Защита Web-серверов
- •§ 3.4.7. Аутентификация в открытых сетях
- •§ 3.4.8. Простота и однородность архитектуры
- •Глава 3.5. Оборудование корпоративных сетей
- •§ 3.5.1. Маршрутизаторы Cisco Systems
- •§ 3.5.2. Оборудование Motorola isg
- •§ 3.5.3. Решения Eicon Technology
- •§ 3.5.4. Критерии выбора корпоративной операционной системы
- •Модуль 4. Мировой рынок erp-систем Введение
- •Глава 4.1. Крупные и средние кис
- •§ 4.1.1. Производственные кис
- •§ 4.1.2. Крупные кис
- •§ 4.1.8. Средние кис
- •§ 4.1.13. Апрель
- •Глава 4.2. Малые и локальные кис
- •§ 4.2.1. Финансово-управленческие кис
- •§ 4.2.2. Малые кис
- •§ 4.2.5. Босс-Корпорация
- •§ 4.2.6. Галактика
- •§ 4.2.7. Парус
- •§ 4.2.8. Флагман
- •§ 4.2.9. Локальные кис
- •§ 4.2.11. Гепард
- •§ 4.2.12. Инфин-Управление
- •Глава 4.3. Внедрение кис на предприятиях
- •§ 4.3.1. Эффективность инвестиционных вложений в кис
- •§ 4.3.2. Внедрение кис за рубежом
- •§ 4.3.3. Внедрение кис в России
- •§ 4.3.4.Этапы внедрения кис в России
- •Особенности проектов внедрения управленческих информационных систем
- •О целях внедрения
- •Этапы проекта внедрения системы
- •Этап первый — определение стратегических целей и тактического плана проекта
- •Этап второй — обследование и описание деятельности предприятия
- •Этап третий — обучение специалистов проектной группы
- •Этап четвертый — разработка будущей модели деятельности предприятия
- •Этап пятый — разработка корпоративных стандартов
- •Этап шестой — настройка и тестирование системы
- •Этап седьмой — обучение конечных пользователей
- •Этап восьмой — опытная эксплуатация
- •Этап девятый — Окончательное документирование
- •Этап десятый — ввод системы в промышленную эксплуатацию
- •Ключевые факторы успеха внедрения управленческих информационных систем
- •Список рекомендуемой литературы
- •Глоссарий
§ 3.4.5. Безопасность программной среды
Идея сетей с так называемыми активными агентами, когда между ком- пьютерами передаются не только пассивные, но и активные исполняемые данные (то есть программы), разумеется, не нова. Первоначально цель со- стояла в том, чтобы уменьшить сетевой трафик, выполняя основную часть обработки там, где располагаются данные (приближение программ к дан- ным). На практике это означало перемещение программ на серверы. Класси-
ческий пример реализации подобного подхода - это хранимые процедуры в реляционных СУБД.
Для Web-серверов аналогом хранимых процедур являются программы, обслуживающие CGI (Common Gateway Interface - общий шлюзовый интер- фейс). CGI-процедуры располагаются на серверах и обычно используются для динамического порождения HTML-документов. Политика безопасности организации и процедурные меры должны определять, кто имеет право по- мещать на сервер CGI-процедуры. Жесткий контроль здесь необходим, по- скольку выполнение сервером некорректной программы может привести к сколь угодно тяжелым последствиям. Разумная мера технического характера состоит в минимизации привилегий пользователя, от имени которого выпол- няется Web-сервер.
В технологии Intranet, если заботиться о качестве и выразительной силе пользовательского интерфейса, возникает нужда в перемещении программ с Web-серверов на клиентские компьютеры - для создания анимации, выпол- нения семантического контроля при вводе данных и т.д. Вообще, активные агенты - неотъемлемая часть технологии Intranet.
В каком бы направлении ни перемещались программы по сети, эти действия представляют повышенную опасность, т.к. программа, полученная из ненадежного источника, может содержать непреднамеренно внесенные ошибки или целенаправленно созданный зловредный код. Такая программа потенциально угрожает всем основным аспектам информационной безопас- ности:
* доступности (программа может поглотить все наличные ресурсы);
* целостности (программа может удалить или повредить данные);
* конфиденциальности (программа может прочитать данные и передать их по сети).
Проблему ненадежных программ осознавали давно, но, пожалуй, толь- ко в рамках системы программирования Java впервые предложена целостная концепция ее решения.
Java предлагает три оборонительных рубежа:
* надежность языка;
* контроль при получении программ;
* контроль при выполнении программ.
Впрочем, существует еще одно, очень важное средство обеспечения информационной безопасности - беспрецедентная открытость Java-системы. Исходные тексты Java-компилятора и интерпретатора доступны для провер- ки, поэтому велика вероятность, что ошибки и недочеты первыми будут об- наруживать честные специалисты, а не злоумышленники.
В концептуальном плане наибольшие трудности представляет контро- лируемое выполнение программ, загруженных по сети. Прежде всего, необ- ходимо определить, какие действия считаются для таких программ допусти- мыми. Если исходить из того, что Java - это язык для написания клиентских частей приложений, одним из основных требований к которым является мо- бильность, загруженная программа может обслуживать только пользователь- ский интерфейс и осуществлять сетевое взаимодействие с сервером. Про- грамма не может работать с файлами хотя бы потому, что на Java-терминале их, возможно, не будет. Более содержательные действия должны произво- диться на серверной стороне или осуществляться программами, локальными для клиентской системы.
Интересный подход предлагают специалисты компании Sun Microsystems для обеспечения безопасного выполнения командных файлов. Речь идет о среде Safe-Tcl (Tool Comman Language - инструментальный ко- мандный язык). Sun предложила так называемую ячеечную модель интерпре- тации командных файлов. Существует главный интерпретатор, которому доступны все возможности языка. Если в процессе работы приложения необ- ходимо выполнить сомнительный командный файл, порождается подчинен- ный командный интерпретатор, обладающий ограниченной функционально- стью (например, из него могут быть удалены средства работы с файлами и сетевые возможности). В результате потенциально опасные программы ока-
зываются заключенными в ячейки, защищающие пользовательские системы от враждебных действий. Для выполнения действий, которые считаются при- вилегированными, подчиненный интерпретатор может обращаться с запро- сами к главному. Здесь, очевидно, просматривается аналогия с разделением адресных пространств операционной системы и пользовательских процессов и использованием последними системных вызовов. Подобная модель уже около 30 лет является стандартной для многопользовательских ОС.
