Защита от хакеров корпоративных сетей

Инструментарий и ловушки

Инкапсуляция против интеграции

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

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

Читателю необходимо понять, что проектирование систем безопасности на самом деле сильно отличается от проектирования других систем. В большинстве случаев код пишется для добавления каких-либо возможностей: визуализировать изображение, оживить его, напечатать документ. Напротив, код системы безопасности предназначен для запрещения возможностей: не позволить взломать систему, предотвратить пустую трату бумаги. Все, что предоставляет функциональность, безопасность забирает обратно. В большинстве случаев это касается не пользующихся доверием пользователей, то есть недоверяемых пользователей (untrusted user), но всегда что-то отнимается и от пользующихся доверием пользователей – доверяемых пользователей (trusted user). Точно так же, как многие газеты нашли успешную модель «Китайской стены» между редакционным отделом, который формирует круг читателей, и отделом рекламы, который перепродает сформированный редакционным отделом читательский спрос, протоколы безопасности извлекают выгоду из ограничения в доступе с одновременным расширением предоставляемых ими же возможностей. В рамках инкапсуляции предложено использовать так называемую «песочницу», реализующую механизм обеспечения безопасности подкачанных из сети или полученных по электронной почте программ. Этот механизм предусматривает изоляцию на время выполнения загружаемого кода в ограниченной среде-«песочнице». Иногда эта «песочница» может потребовать большего доверия, чем на самом деле предоставлено участникам обмена, но, по крайней мере, в нее заложен предел доверия, который не может быть превышен.

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