Как безопасно хранить временные файлы в Windows, особенно с приложениями Security Intrusion Prevention, блокирующими каталог TEMP

В прошлом многие приложения хранили временные файлы в каталоге Temp / Tmp; либо для Системы, либо для конкретного пользователя. Однако в последнее время у нас было много пользователей на предприятиях, где использование каталогов Temp заблокировано из-за инструментов сканирования на вирусы или инструментов и политик Host Intrusion Prevention, не разрешающих использование этих местоположений. Я думаю, здесь есть опасения, что несколько приложений могут читать и писать из этого места, и поэтому мошенническое приложение может негативно повлиять на другое приложение или его временно сохраненные данные. Это кажется правильным и более безопасным способом работы, поэтому я не могу просить людей позволить себе повышенный риск.

Тогда мой вопрос: как и где (физически) безопасно хранить пользовательские, специфичные для приложения, но временные файлы.

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

В частности, я сосредоточен на использовании .NET 4.0+, C # и Windows 7+, но этот вопрос должен быть применим и к другим языкам, используемым в Windows.

Похожие, но более старые и недостаточно конкретные темы

Ответ 1 о шифровании содержимого и имени файла не кажется оптимальным решением и все равно будет заблокирован системой предотвращения вторжений хоста.


windows java c# security temp
person Gary Plattenburg    schedule 17.02.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

Windows использует ACL для предоставления / ограничения разрешений для каталогов файловой системы. ACL специфичны для пользователя, группы или набора пользователей / групп. Нет специфических для приложений. Предположим, конкретный пользователь, Art, запускает приложение Papp, а Papp хранит свои данные в C:\Users\Art\AppData\Roaming\Papp. Если Art запускает Qapp, тогда Qapp (если он не запущен от имени другого пользователя) имеет доступ к Papp's файлам.

Обратите внимание, что по умолчанию переменные среды TMP и TEMP находятся под AppData, поэтому с точки зрения безопасности специальная папка ApplicationData не лучше и не хуже. (Хотя лучше, чем C:\temp и c:\tmp).

Если пользователь Бетти запускает Qapp, то по умолчанию Qapp не будет иметь доступа к Papp файлам Арта, если они находятся под его AppData. Поэтому, если проблема безопасности заключается в том, чтобы предотвратить доступ других пользователей, запускающих Qapp, к Papp файлам Art, то любой каталог в AppData будет работать.

Но если проблема в том, что Art работает Qapp (что может быть вредоносной программой и может быть чем-то, что Art не запускал намеренно), то некоторые решения: 1) Используйте программу белого списка, которая позволяет запускать только авторизованные программы, 2) Используйте программа из черного списка (то есть традиционный антивирус), которая пытается остановить вредоносные программы, такие как Qapp 3) гибридный подход, когда доверенные программы работают как Art, а ненадежные программы - от имени другого, менее привилегированного пользователя или запускаются в изолированной программной среде.

person Χpẘ    schedule 17.02.2016

arrow_upward
2
arrow_downward

Вам следует использовать специальную папку, обычно называемую AppData. Доступ к нему можно получить в C #, вызвав Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData).

Описание ApplicationData в MSDN выглядит следующим образом:

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

Я создал ряд приложений для клиентов финансовых услуг (т. Е. Строго ограниченных и заблокированных корпоративных настольных сред), которые используют это местоположение, и у меня не было никаких проблем с созданием там временных файлов.

MSDN: Environment.SpecialFolder

person toadflakz    schedule 17.02.2016