CP3Teslin.md 29 KB

Самостоятельная работа №3

Распределенные АС

Распределенные АС – это система управления технологическим процессом, отличающаяся построением распределённой системы ввода-вывода и децентрализацией обработки данных.

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

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

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

Любая система состоит из каких - либо компонент, называемых подсистемами.

Подсистема – это выделенное из системы по определенному правилу целенаправленное подмножество взаимосвязанных элементов любой природы.

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

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

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

Требования к современной РСА:

  • Отказоустойчивость и безопасность
  • Простота разработки и конфигурирования
  • Поддержка территориально распределённой архитектуры
  • Единая конфигурационная база данных
  • Развитый человеко-машинный интерфейс

Задачи РСА:

Распределенные вычислительные системы обладают следующими характеристиками.

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

  • Параллельная обработка: одну и ту же функцию могут одновременно обрабатывать несколько машин.

  • Масштабируемость: вычислительная мощность и производительность могут масштабироваться по мере необходимости при добавлении дополнительных машин.

  • Обнаружение ошибок: упрощается обнаружение отказов.

  • Прозрачность: узел может обращаться к другим узлам в системе и обмениваться с ними данными.

  • Соединение пользователей с ресурсами

В итоге РСУ имеет следующие характеристики, отличающие ее от сосредоточенной:

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

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

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

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

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

Вывод

Матрица доступа

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

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

Множество объектов и типов доступа к ним субъекта может изменяться в соответствии с некоторыми правилами, существующими в данной системе. Определение и изменение этих правил также является задачей МД.

При принятии решения о предоставлении доступа обычно анализируется следующая информация:

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

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

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

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

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

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

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

Ролевое управление доступом

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

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

Пользователи, объекты и роли.

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

Ролевой доступ развивается более 10 лет (сама идея ролей, разумеется, значительно старше) как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов.

Ролевое управление доступом оперирует следующими основными понятиями:

  • пользователь (человек, интеллектуальный автономный агент и т.п.);
  • сеанс работы пользователя ;
  • роль (обычно определяется в соответствии с организационной структурой);
  • объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД); *операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и т.п.; для таблиц СУБД – вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными);
  • право доступа (разрешение выполнять определенные операции над определенными объектами).

Вывод

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

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

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

(Заметим в скобках, что происхождение русскоязычного термина " аутентификация " не совсем понятно. Английское "authentication" скорее можно прочитать как "аутентикация"; трудно сказать, откуда в середине взялось еще "фи" – может, из идентификации? Тем не менее, термин устоялся, он закреплен в Руководящих документах Гостехкомиссии России, использован в многочисленных публикациях, поэтому исправить его уже невозможно.)

Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней ( взаимной ). Пример односторонней аутентификации – процедура входа пользователя в систему.

В сетевой среде, когда стороны идентификации / аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта:

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

  • нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.);

  • нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения);

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

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

Вывод

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