Службы (сервисы) Интернет и архитектура клиент-сервер

Интернет вызывает интерес пользователей возможностями, заложенными в службах (сервисах) Интернет.

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

Cервер (server), предоставляет определенные ресурсы. Другая программа - клиент (client)- эти ресурсы использует.

FQDN (Fully Qualified Domain Name) – Имя хоста.имя домена, например: машина tom в домене foobar.com имеет FQDN tom.foobar.com

URL – Universal Resource Locator – общая форма представления адреса ресурса в Интернет

<имя протокола>://<FQDN или адрес хоста>{/<путь к ресурсу>}

"Ежемесячно по каналам Internet перемещается более 30 Тбит информации (по скромным подсчетам это около 30 млн. книг по 700 страниц каждая) между приблизительно 50 млн. пользователей." - INTERNET И ЭКОНОМИКА, Выпуск N 14, 6-12 апреля 1998 г.

Серверов Всемирной Паутины: 2.215.195. Их количество удвоилось за последние 8 месяцев (вспомните каррикатуру из Нью-Йорк Таймс).

Пользователей Интернет: можно только догадываться - приблизительно между 1.000.000 до 6.000.000.000 – хотя, может быть, и больше (one never knows if you're a dog on the Net). Порядок цифры – сотни миллионов.

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

8.1. Анализ и задание требований к безопасности

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

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

Основу анализа требований к безопасности составляют:

· рассмотрение необходимости обеспечения конфиденциальности, целостности и доступности информационных ресурсов;

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

В частности, при проведении такого анализа следует рассмотреть необходимость:

а) управления доступом к информации и сервисам, включая требования к разделению обязянностей и ресурсов;

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

в) проверки и обеспечения целостности жизненно важных данных на всех или избранных стадиях их обработки;

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

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

е) снятия резервных копий с критически важных производственных данных;

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

з) защиты систем от внесения несанкционированных дополнений и изменений;

и) предоставления возможности безопасного управления системами и их использования сотрудникам, не являющимся специалистами (но имеющих надлежащую подготовку);

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

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

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

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

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

Чтобы обеспечить правильный ввод данных в прикладные системы необходимо проверять их на достоверность. Предлагаются следующие средства контроля:

а) проверки с целью выявления следующих ошибок:

· превышенные верхние и нижние пределы на объем вводимых данных;

· несанкционированные или противоречивые управляющие данные;

б) периодический анализ содержания ключевых полей или файлов данных для подтверждения их достоверности и целостности;

в) осмотр печатной входной документации на предмет внесения несанкционированных изменений во входные данные (необходимо получить разрешение на внесение всех изменений во входные документы);

г) процедуры реагирования на ошибки, связанные с проверкой достоверности входных данных;

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

8.4. Проверка достоверности внутренней обработки данных

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

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

а) контроль сеанса связи и пакетной обработки для согласования файлов данных о платежном балансе после проведения операций с ними;

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

в) проверка достоверности данных, сгенерированных системой (см. Проверка достоверности входных данных);

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

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

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

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

Цель: Обеспечить надежную реализацию проектов разработки информационных систем и их поддержку.

Доступ к системным файлам необходимо контролировать.

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

8.7. Контроль рабочего программного обеспечения

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

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

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

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

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

д) Предыдущие версии программ следует сохранить — мера предосторожности при чрезвычайных ситуациях.

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

а) Процедуры управления доступом, которые применяются для рабочих прикладных систем, должны также применяться для тестируемых прикладных систем.

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

в) Реальные данные следует удалить из тестируемой прикладной системы сразу после завершения процесса тестирования.

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

8.9. Безопасность в среде разработки и рабочей среде

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

8.10. Процедуры управления процессом внесения изменений

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

а) регистрацию согласованных уровней полномочий, в том числе:

· служба приема запросов на внесение изменений группой, обслуживающей информационные системы;

· полномочия пользователей на подачу запросов на внесение изменений;

· уровни полномочий пользователей на принятие подробных предложений;

· полномочия пользователей на принятие вносимых изменений;

б) принятие изменений, предлагаемых только зарегистрированными пользователями;

в) проверку средств управления безопасностью и процедур обеспечения целостности на предмет их компрометации внесенными изменениями;

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

д) утверждение подробных предложений до начала работы;

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

ж) обновление системной документации по завершении процесса внесения каждого изменения, а также архивирование или уничтожение старой документации;

з) осуществление контроля над версиями всех обновляемых программ;

и) регистрацию всех запросов на внесение изменений в контрольном журнале.

8.11. Технический анализ изменений,
вносимых в операционную систему

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

а) проверка процедур контроля приложений и обеспечения их целостности на предмет компрометации вследствие внесения изменений в операционную систему;

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

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

8.12. Ограничения на внесение изменений в пакеты программ

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

а) риск компрометации встроенных средств контроля и процессов обеспечения целостности;

б) необходимость получения согласия поставщика;

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

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

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

1. Интеллектуальные системы в химической технологии и инженерном образовании: Нефтехимические процессы на Pt-катализаторах/ А.В. Кравцов, Э.Д. Иванчина. – Новосибирск: Наука. Сибирская издательская фирма РАН, 1996. – 200с.

2. Фигурнов В.Э. IBM PC для пользователя. Изд. 5-е, исправл. и доп. – Уфа, ПК «Дегтярев и сын», НПО «Информатика и компьютеры», 1993. –352 с.

3. Фаронов, Валерий Васильевич. Турбо Паскаль: учебное пособие / В. В. Фаронов. — 7-е изд., перераб. — М.: Нолидж, 2001. — 575 с.

4. Моргун, Александр Николаевич. Программирование на языке Паскаль. Основы обработки структур данных / А. Н. Моргун, И. А. Кривель. — М.: Вильямс, 2006. — 567 с.

5. Фаронов, Валерий Васильевич. Программирование баз данных в Delphi 7 / В. В. Фаронов. — СПб.: Питер, 2004. — 459 с.

6. Фаненштих Клаус, Хаселир Райнер. Текстовый процессор Word 6.0 для Windows. – Изд. 2-е, исправл. и доп.: Практ. Пособ./ Пер. с нем. – М.: ЭКОМ., 1995. – 352 с.

10. Кириллов В.В. Структурированный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

12. "Эффективная работа с Microsoft Access 7.0" Питер, Санкт-Петербург, 1997

13. Гершберг А.Ф., Безручко О.А. Автоматизация производства ООО «ПО «Киришинефтеоргсинтез». Применение современных информационных технологий // Нефтепереработка и нефтехимия. – 2006. – № 2. – С. 45–49.

14. Единая тематическая витрина данных. Руководство оператора

1. ОБЩАЯ ХАРАКТЕРИСТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ.. 6

2. ОСНОВЫ ПРОГРАММИРОВАНИЯ НА ЯЗЫКЕ TURBO PASCAL. 8

2.3. Программирование разветвляющихся алгоритмов. Условный оператор 13

2.5. Программирование циклических алгоритмов. 19

3.2.1. Модуль Сrt. Работа с экраном в текстовом режиме. 43

3.2.2. Модуль Graph. Работа с экраном в графическом режиме. 43

4. РЕШЕНИЕ ФУНКЦИОНАЛЬНЫХ И ВЫЧИСЛИТЕЛЬНЫХ ЗАДАЧ ХИМИЧЕСКОЙ ТЕХНОЛОГИИ.. 51

4.2. Итерационные методы решения нелинейных уравнений. 54

4.3. Приближенное решение обыкновенных дифференциальных уравнений первого порядка. 59

5.2. Построение графиков с использованием Microsoft Excel 85

6.2. Основы визуального программирования в среде Delphi 95

6.2.2.2. Динамическое изменение свойств компонента. 102

6.3. Использование компонентов общего назначения. 104

6.3.3. TPopupMenu - вспомогательное (локальное) меню.. 111

6.3.11. TComboBox – раскрывающийся список выбора. 120

6.3.12. TScrollBar - управление значением величины.. 121

6.3.14. TRadioGroup - группа зависимых переключателей. 122

7. БАЗЫ ДАННЫХ И БАЗЫ ЗНАНИЙ. СЕТЬ ИНТЕРНЕТ. 126

7.1. Системы сбора, хранения и обработки информации о протекании промышленного процесса. 126

7.1.1 Общая характеристика систем управления базами данных. 126

7.1.5 Среда быстрой разработки приложений Delphi 133

7.1.6 Язык SQL как стандартный язык реляционных БД.. 137

7.1.7 Базы данных на нефтеперерабатывающих заводах. Единая тематическая витрина данных на ООО «ПО «Киришинефтеоргсинтез». 142

7.2.3 Интернет - компьютерные сети и сетевые протоколы.Семейство протоколов TCP/IP. 151

7.2.4 Службы (сервисы) Интернет и архитектура клиент-сервер. 154

8.1. Анализ и задание требований к безопасности. 157

8.3 Проверка достоверности входных данных. 159

8.4. Проверка достоверности внутренней обработки данных. 159

8.7. Контроль рабочего программного обеспечения. 161

8.9. Безопасность в среде разработки и рабочей среде. 162

8.10. Процедуры управления процессом внесения изменений. 162

8.11. Технический анализ изменений, вносимых в операционную систему 163

8.12. Ограничения на внесение изменений в пакеты программ. 163

Проблемно-ориентированная
информатика химико-технологических процессов

Научный редактор
доктор технических наук,
профессор А.В. Кравцов

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: