Главная | Обратная связь | Поможем написать вашу работу!

Проектирование безопасных систем

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

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

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

Это не означает, что N-вариантное программирование бесполезно. Оно может уменьшать абсолютное число отказов системы. Если предположить, что общие ошибки будут обнаружены в различных версиях системы, то число отказов будет уменьшено. Кроме того, считается, что N-вариантное программирование увеличивает доверие к безотказности системы [40].

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

КЛЮЧЕВЫЕ ПОНЯТИЯ

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

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

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

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

• Безопасное программирование – это метод программирования, который объединяет проверку программ на наличие ошибок и их локализацию. Ошибки определяются ранее, чем они приведут к сбою системы.

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

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

Упражнения

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

18.2. Если рекурсия – конструкция, приводящая к ошибкам, спроектируйте класс объектов, реализующий двоичные деревья и работу с ними без использования рекурсии.

18.3. Опишите три метода безопасного программирования, которые уменьшают вероятность того, что ошибки ПО приведут к сбоям системы.

18.4. Кратко опишите стратегии прямого и обратного восстановления систем. Почему обратное восстановление используется чаще, чем прямое? Приведите два класса систем, где может использоваться обратное восстановление.

18.5. Какие предварительные условия должны соблюдаться, прежде чем может быть выполнено прямое восстановление отказоустойчивой системы? Возможно ли прямое восстановление в интерактивных системах?

18.6. Спроектируйте абстрактный тип данных или объектный класс RobustList (устойчивый список), который реализует прямое восстановление в связанном списке. Для этого используйте прямые и обратные ссылки между соседними элементами списка.

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

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

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

18.10. Обсудите проблемы разработки и сопровождения "безостановочных" систем типа программного обеспечения телефонной станции. Как можно использовать при разработке таких систем исключительные ситуации?

18.11. Использование методов разработки безопасного программного обеспечения, обсуждавшихся в этой главе, очевидно, требует значительных дополнительных затрат. Какие дополнительные затраты можно оправдать, если за 15-летний срок службы системы будут сохранены 100 жизней? Были бы оправданы те же самые затраты, если будут сохранены 10 жизней? Какова цена жизни? Правомочно и этично ли в таких ситуациях проводить оценку затрат?

⇐ Предыдущая 127 128 129 130 131132133 134 135 136 Следующая ⇒