Пожалуй, писать о том, что такое безопасность, сродни объяснению взрослым таблицы умножения.
Действительно, о безопасности в последнее время написано много, и кажется, что даже домохозяйки уже неплохо в ней разбираются.
Но, по моему опыту, в этой области до сих пор существует много мифов и заблуждений.
Одним из таких мифов является представление о безопасности как об определенной функции программы.
Пример №1. Серьезная компания, занимающаяся разработкой программного обеспечения, причем в сфере, где требования к безопасности очень высоки.
Сотрудники говорят: «Безопасность — конкурентное преимущество».
Но когда начинаешь с ними об этом говорить подробнее, они перечисляют функции, которые они реализовали в продуктах, что-то вроде «весь трафик шифруется», «мы делаем аутентификацию по токенам».
Они больше ничего не делают для обеспечения безопасности своей продукции.
При этом они очень и очень умные люди даже по меркам программистов.
Пример №2. Серьезная компания, специализирующаяся на информационной безопасности, в том числе на разработке требований безопасности к информационным системам и программным продуктам.
Глава департамента.
Мы начали разговаривать.
Когда я говорю «безопасная программа», он снова спрашивает: «Программа с функциями безопасностиЭ» Пример №3. Большой серьезный банк.
Требования безопасности к приобретаемому программному обеспечению.
Требования формулируются исключительно как описание требуемого функционала.
Более того, видно, что они хорошие специалисты, что они чувствуют – но не понимают – ограниченность такого подхода, что необходимо выходить за эти ограничения.
То тут, то там есть дополнения, попытки сформулировать что-то другое.
Но они остаются в рамках функционального подхода, и это их ограничивает. Но разве безопасность не связана с функциональностью? Начнем с довольно традиционного определения безопасности (я предполагаю, что безопасность и защищенность являются синонимами), данного Майклом Ховардом и Дэвидом Лебланом в их книге [1]:
Безопасное программное обеспечение — это программа, обеспечивающая конфиденциальность, целостность и доступность клиентской информации, а также целостность и доступность вычислительных ресурсов, управляемых владельцем системы или системным администратором.Определение практически из учебника; такие же или очень похожие можно найти и в других книгах.
И это правильно, думаю, никто не будет оспаривать его правильность.
Это вопрос интерпретации.
Это определение легко понять вполне традиционно, «функционально»: для того, чтобы программа была защищена необходимое и достаточное встроить в него механизмы обеспечения конфиденциальности, целостности и доступности.
И, как показывают примеры, приведенные в начале статьи, зачастую именно так трактуются подобные определения.
Обратите внимание, что в этом определении нет никаких указаний на функциональность безопасности.
При этом многие эксперты совершенно четко заявляют, что безопасность — это нефункциональное свойство программного обеспечения.
Так Джон Вьега и Гарри МакГрат в своей книге [2] пишут:
Является ли безопасность функцией, которую можно добавить в существующую систему? Является ли это статическим свойством программного обеспечения, которое остается неизменным независимо от того, в какой среде находится код? Ответ на эти вопросы категорический: нет. Встроить безопасность в существующую систему — просто плохая идея.Итак, безопасность — это не функция программного обеспечения, а его свойство.Безопасность — это не функция, которую вы добавляете в систему в любое время.
Безопасность подобна безопасности, надежности, надежности или любой другой способности.
Каждая способность представляет собой возникающее общесистемное свойство, требующее предварительного планирования и тщательного проектирования.
Безопасность — это поведенческое свойство всей системы в конкретной среде.
И природа этого свойства весьма интересна.
Что особенного в безопасности? Давайте подробнее рассмотрим определение защищенного программного обеспечения, которое я дал в начале предыдущей части.
Раскрывая концепции, на которых оно основано, мы видим, что безопасность заключается не в том, что программное обеспечение должно делать, а в том, что программное обеспечение не должно делать.
Действительно, конфиденциальность означает, что информация не будет Доступен тем, для кого он не предназначен.
Целостность означает, что информация не будет модифицируются теми, кому это не разрешено, и теми, кому это разрешено они не смогут изменить его несанкционированным способом.
Наконец, доступность в контексте информационной безопасности означает, что системные ресурсы не будет используются посторонними, и что посторонние не могу управлять системой.
То есть все они определяются не с точки зрения того, «что система должна делать», а с точки зрения того, «чего система не должна делать».
Можно, конечно, возразить, что именно для этого и предназначены «функции безопасности».
Именно они обеспечивают защиту и не позволяют «неправильным» получить доступ к системе.
Да.
И нет. Допустим, мы хотим предотвратить изменение информации, записанной на жестком диске, обеспечив тем самым ее целостность.
Если никто не должен иметь возможность записи на диск, давайте просто перережем дорожку на контроллере диска, отвечающем за передачу команды записи.
Диск вообще не пишет. Мы добились своей цели: ни у кого нет возможности производить запись на диск и целостность информации будет сохранена.
Убрали функцию — «безопасность» повысилась.
Многие из читателей сами могут привести массу подобных примеров.
С другой стороны, если бы все пользователи имели абсолютно одинаковые права по отношению ко всем объектам в системе, функции безопасности, опять же, не могли бы быть реализованы.
Но чаще всего нам нужно, чтобы одни пользователи могли выполнить операцию, а другие — нет. Вот тут-то и приходят на помощь «функции безопасности».
Их задача — отобрать у «неправильных» пользователей возможность использовать те или иные полезные возможности программы.
В некотором смысле функции безопасности являются антифункциями.
То есть в определенной ситуации функции безопасности являются необходимым средством обеспечения безопасности программы.
Но их присутствия недостаточно.
Помимо того, что есть функция, отбирающая возможность выполнения операции с использованием какого-либо механизма, имеющегося в программе, ее необходимо обеспечить отсутствие возможности достижения тех же целей с использованием любых других механизмов, имеющихся в программе.
Очень хорошая аналогия здесь — здание, доступ к которому должен быть открыт для одних людей, но закрыт для других.
Дверной проем в данном случае является средством входа.
Дверь с замком – это механизм, позволяющий войти любому, у кого есть соответствующий ключ, и запрещающий вход всем остальным.
Но кроме простого наличия этого механизма необходимо обеспечить невозможность проникнуть внутрь помещения через незакрытые окна, через крышу, возможность подобрать ключ, взломать дверь, проделать дыру в стене.
и многое, многое другое должно быть исключено.
Безопасность здания зависит как от качества двери и замка, так и от качества проектирования и реализации всего здания.
Все те же соображения применимы и при разработке программного обеспечения.
Для обеспечения ее безопасности необходимо создать систему безопасности как свойство программы в целом.
Как это влияет на процесс разработки? До сих пор все, что было написано, было похоже на упражнение по философии.
Функции – антифункции, дают возможности – отнимают возможности.
Ну это не функция, а свойство, качество, и что? Здесь стоит отметить, что пожелания пользователей, их ожидания относительно безопасности программного продукта описываются в негативном ключе.
И это принципиально.
Пользователь ожидает, что программа не позволит постороннему лицу выполнить определенные операции.
И при создании программного продукта мы должны учитывать именно это ожидание.
Но в каждом учебнике по разработке программного обеспечения говорится, что требования к программному обеспечению должны быть выражены в позитивных терминах.
Требования, выраженные в отрицательных терминах, некорректны: они двусмысленны и непроверяемы.
Но, занимаясь безопасностью, разработчику приходится работать с негативными ожиданиями и решать ряд проблем.
Во-первых, поняв ожидания пользователя, необходимо разработать соответствующую спецификацию.
Чтобы спецификация была правильной, она должна быть написана в позитивных терминах.
Уже здесь возникает задача перевода негативных ожиданий в позитивные формулировки.
Они явно не будут эквивалентными.
И разработчику нужно будет искать вместе с заказчиком именно те формулировки, которые бы, с одной стороны, позволили создать программу в условиях ограниченности ресурсов, а с другой стороны, обеспечили бы приемлемый уровень безопасности.
.
Во-вторых, продукт должен быть спроектирован и реализован так, чтобы соответствовать этим ожиданиям.
С одной стороны, кажется, для этого достаточно, чтобы продукт удовлетворял той спецификации, которая была разработана на первом этапе.
Но мы все понимаем, что спецификация, как бы тщательно она ни была разработана, может неточно отражать ожидания пользователей, даже при формулировании функциональных, позитивно сформулированных ожиданий (см.
, например, [3]).
Поэтому на всех этапах проектирования и реализации программы необходимо контролировать ее соответствие как спецификации, так и непосредственно требованиям, выраженным в отрицательных выражениях.
И в-третьих, необходимо доказать клиенту, что мы создали программу, которая удовлетворит его потребности, в том числе и в безопасности.
Конечно, можно сказать, что если программа соответствует техническим характеристикам, то претензий у заказчика быть не должно.
Формально это так.
На практике на этом этапе желательно представить клиенту аргументы, доказывающие, что программа не содержит уязвимостей – функциональных возможностей, нарушающих требования безопасности в их отрицательной формулировке.
Если этого не сделать, то клиент, формально приняв программу, может отказаться от дальнейшего сотрудничества.
Таким образом, свойство «безопасности» программного обеспечения требует специальных мер на всех этапах разработки.
Для обсуждения этих мер, хотя бы вкратце, объема одной статьи совершенно недостаточно.
Еще одно соображение Очевидно, что программное обеспечение приобретается ради его функциональности, ради того, что оно делает. Именно функциональность интересует клиента в первую очередь.
Никто не купит программу, если она не делает что-то, что облегчает бизнес клиента, или не помогает хорошо провести время, как это делают, например, различные «игрушки».
Безопасность – второстепенная характеристика.
Более того, безопасность часто противоречит функциональности (помните, функции безопасности — это антифункции?).
Конечно, никто не станет покупать безопасный, но бесполезный продукт. Поэтому при разработке программного обеспечения, к которому предъявляются требования безопасности, важной задачей является создание не просто безопасного, а сбалансированного продукта.
И понимание природы безопасности, ее взаимосвязи с функциональностью продукта для успешного решения этой задачи играет важную роль в наборе знаний, необходимых разработчику.
Литература 1. Майкл Ховард, Дэвид Леблан «Безопасный код» Microsoft Press, русское издание 2005 г.
, ISBN 5-7502-0238-0, с.
2 2. Джон Вьега, Гэри МакГроу «Создание безопасного программного обеспечения.
Как правильно избегать проблем безопасности», Addison-Wesley 2005, ISBN 0-201-72152-X, стр.
13 3. Майерс Г.
«Надежность программного обеспечения», Мир, 1980 г.
Теги: #безопасность #разработка программного обеспечения #информационная безопасность
-
Особенности Дисков В Облаке
19 Oct, 24 -
Фразеология
19 Oct, 24 -
Nginx И Странные Числа Раньше
19 Oct, 24 -
Autocad Architecture: Первый Проект
19 Oct, 24
