поиск по сайту
Парадигма аппаратной защиты

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

Допустим, Вам предоставили программу, в которую встроены программные процедуры идентификации/аутентификации. Для того, чтобы использовать эту программу, её надо запустить. При запуске программа запрашивает Ваш идентификатор (login) и пароль (password). Вы вводите требуемые контрольные данные, они проверяются программой, и если все хорошо - программа начинает работать. Формально требования идентификации/аутентификации выполнены, но обеспечивают ли описанные процедуры сколь-нибудь надежную защиту? Скорее всего - нет. Чтобы в этом убедиться, рассмотрим другой вероятный ход событий.

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

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

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

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

1) установлена на компьютер;

2) запущена на исполнение.

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

Что же делать? Видимо, нужно согласиться с тем, что важно не только наличие и реализация контрольных процедур, но и условия их исполнения. А из нашего примера следует однозначный вывод - защитные механизмы должны активизироваться ДО ЗАГРУЗКИ ОПЕРАЦИОННОЙ СИСТЕМЫ.

Это фундаментальный вывод. Его правильность давно доказана с применением точного математического аппарата, а следует из этого вывода также и то, что должны быть специальные аппаратные средства защиты информации. ОБЕСПЕЧИТЬ НАДЕЖНУЮ ЗАЩИТУ БЕЗ ПРИМЕНЕНИЯ СПЕЦИАЛИЗИРОВАННЫХ АППАРАТНЫХ СРЕДСТВ НЕВОЗМОЖНО!

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

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

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

Конечно, получилось так потому, что перед запуском программы мы не проконтролировали, изменилась программа или нет. Если бы мы вычислили контрольную сумму программы и сравнили ее с эталонной контрольной суммой, мы бы заметили, что программа изменилась. Значит, если её меняли не мы, то приложил руку кто-то другой. Разумеется, в этом случае не стоит запускать программу, а нужно принять меры к расследованию того, кто, как и зачем модифицировал программу.

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

Но если для того чтобы контролировать целостность программы А, мы используем программу В, то кто нам даст гарантию, что программа В осталась неизменной?

Значит, нужна программа С, которая проконтролирует целостность программы В!

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

Сказка про белого бычка, дом, который построил Джек, попытка барона Мюнгхаузена вытащить самого себя за волосы из болота - эти сюжеты и схемы развития событий известны нам с детства, и каждый точно знает, что это сказочки, способ надуть прекрасную маркизу, не более. И при этом мы продолжаем верить, что с помощью одной программы можно проверить целостность другой! Это тяжелое техническое заболевание, состоящее в имитации мероприятий по защите без повышения уровня защищенности, получило название "Синдром Мюнгхаузена".

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

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

Таким образом, парадигма аппаратной защиты состоит в <материалистическом> ответе на <основной вопрос технической защиты информации>: <Что первично - Hard или soft?>.  Конечно, для Фон-Неймановской архитектуры ответ очевиден - надежная защита может строиться только на основе специальной аппаратуры.

О том, как выглядит эта специальная аппаратура защиты от несанкционированного доступа (НСД) и какими функциями она обладает, читайте в разделе СЗИ НСД "Аккорд-АМДЗ".


ЦеныЦены
Прайс-лист
ЗаказатьЗаказать
Купить наши изделия
proterminaly.ru
марш.рф
accord.ru
accord-v.ru
okbsapr.ru
prosecret.ru
trustedcloudcomputers.ru