Управление доставкой динамического содержимого в Silverlight - Принципы изолированного хранилища
ОГЛАВЛЕНИЕ
Принципы изолированного хранилища
Изолированное хранилище не было создано специально для Silverlight. Изолированное хранилище входит в Microsoft .NET Framework, начиная с версии 1.0. Предназначенное для частично проверенных приложений, изолированное хранилище дает возможность таким приложениям хранить данные на локальном компьютере, соблюдая при этом все действующие политики безопасности. У классического приложения .NET, обладающего полным доверием, вообще не возникает необходимости проходить через слой изолированного хранилища для сохранения своих данных, но для частично проверенного приложения изолированное хранилище является единственной возможностью сохранить данные на клиенте.
С точки зрения Silverlight изолированное хранилище является мощным инструментом. Кроме того, это единственно возможный способ хранения относительно больших фрагментов данных независимо от вида браузера и без каких бы то ни было ограничений, которые накладываются, например, на файлы Cookie HTTP. Важно понимать, что в Silverlight изолированное хранилище является единственной возможностью кэшировать данные на локальной машине. Если приложению Silverlight необходимо сохранить данные (любого типа) на локальной машине, это можно сделать только с помощью изолированного хранилища. Кроме этого, при наличии изолированного хранилища каждое приложение может хранить свои данные изолированно от любых других приложений или даже от любых других приложений за пределами веб-сайта.
Для получения общего, ориентированного на технологию .NET представления об изолированном хранилище и наиболее распространенных вариантах его применения следует прочесть Руководство разработчика .NET Framework по изолированному хранилищу. В статье упоминается пара ситуаций, для которых использование изолированного хранилища является неподходящих выбором. В частности, изолированное хранилище не рекомендуется использовать для хранения конфиденциальных данных, кода или параметров настройки (кроме параметров пользователей). Эти рекомендации являются следствием общих соображений относительно безопасности и не обязательно подразумевают какие либо опасности, присущие использованию изолированного хранилища.
Итак, можно ли безопасно хранить пакеты XAP, загруженные в изолированное хранилище Silverlight? В Silverlight, в отличие от настольной CLR, любая часть исполняемого кода по умолчанию считается непроверенной, и ей не позволено вызывать критические методы или повышать привилегии стека вызывающей программы. В Silverlight любой код, сохраненный для последующего выполнения, не в состоянии выполнить никаких опасных действий. Это ничуть не более опасно, чем выполнение любого другого фрагмента кода Silverlight. Создавая постоянный кэш пакетов Silverlight, вы организуете локальное хранение сегмента приложения Silverlight, который вы сознательно запускаете на выполнение.
В Silverlight роль изолированного хранилища подобна (постольку, поскольку это касается постоянства) роли файлов Сookies HTTP в классических веб-приложениях. Изолированное хранилище в Silverlight следует рассматривать как набор больших файлов Сookie, в которых могут содержаться данные любого типа, включая исполняемый код. В этом случае, однако, защиту обеспечивает базовая среда CLR Silverlight. В действительности, в соответствии с моделью безопасности Silverlight, базовая среда CLR создает исключение каждый раз, когда код приложения собирается выполнить критический метод. В отличие от файлов Сookie HTTP, изолированное хранилище в Silverlight не связано с сетевым вводом-выводом, и с запросами не передается никакое содержимое.
Данные в изолированном хранилище изолируются приложением, и никакое другое приложение Silverlight не может получить доступ к хранилищу. Тем не менее, данные хранятся в локальной файловой системе, поэтому администратор машины наверняка имеет к ним доступ.
И снова модель в целом не слишком отличается от того, что происходит с файлами Сookie HTTP. У администратора всегда имеется возможность найти и даже изменить содержимое файлов Сookie. Если в вашем контексте это целесообразно, для добавления еще одного уровня защиты данных можно использовать шифрование.
Если вы все еще беспокоитесь по поводу некоторого загруженного исполняемого кода, находящегося на вашем компьютере, следует освежить свое понимание модели безопасности Silverlight. Вкратце, базовая среда CLR в Silverlight создает исключение каждый раз, когда код приложения пытается выполнить критический метод. В библиотеке Silverlight BCL (Base Class Library) методы и классы, выполняющие операции, требующие привилегий высокого уровня, помечаются специальным атрибутом SecurityCritical. Отмечу, что это характерно для большей части содержимого пространства имен System.IO.
В модели безопасности Silverlight признается, что некоторым классам платформы могут потребоваться безопасные вызовы критических методов. Такие классы и методы помечаются атрибутом SecuritySafeCritical. Это именно так для классов в интерфейсе System.IO.IsolatedStorage API (см. рис. 1). Важнейший момент модели безопасности Silverlight заключается в том, что никакая часть кода приложения никогда не может быть помечена атрибутом SecurityCritical или SecuritySafeCritical. Этот атрибут зарезервирован для классов в сборках, имеющих цифровую подпись корпорации Майкрософтft и загруженных в память из установочного каталога Silverlight.
Рис. 1 Обзор внутренней структуры интерфейса API изолированного хранилища
Видно, что даже в самых неудачных (и маловероятных) обстоятельствах, когда какой-то злоумышленник проникает в ваш компьютер и заменяет загруженное содержимое Silverlight, ущерб ограничивается обычными операциями, выполняемыми в «прозрачном» режиме.