Enhanced storage что это
Microsoft Enhanced Storage
Сегодня компании нуждаются в том, чтобы перед подключением переносных устройств к компьютеру происходила проверка подлинности. Потребителям необходим аналогичный подход, для гарантий, что их личной информацией не воспользуются посторонние люди, а так же, что неавторизованные устройства не смогут быть подключены к их компьютерам.
На текущий момент на рынке распространены как различные устройства с повышенным уровнем безопасности, например, накопители со сканером отпечатков пальцев или с поддержкой аппаратного шифрования данных, так и ПО для шифрования, которое поддерживает работу с любыми внешними устройствами хранения данных или позволяет использовать шифрованные файл-контейнеры, которые могут храниться на них. Но их использование возможно только с “фирменным” ПО или с предварительной установкой специального драйвера или программного обеспечения на компьютер, к которому будут подключаться устройства с повышенным уровнем безопасности, что не всегда возможно, а это означает ограниченную совместимость. Чтобы решить этот вопрос, необходим единый стандарт.
По этому не удивительно, что Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers – IEEE) взялся за этот вопрос, создав рабочую группу, которая разработала “Стандартный протокол аутентификации при подключении съемных устройств хранения данных” – 1667 (IEEE 1667-“Standard Protocol for Authentication in Host Attachments of Transient Storage Devices”). IEEE 1667 – это платформенно-независимый стандарт, в котором описаны требования взаимной идентификации между устройствами и компьютером для создания безопасной области, что позволяет доверенным устройствам свободно взаимодействовать друг с другом.
На текущий момент корпорация Microsoft является одним из активных участников по продвижению нового стандарта и уже реализовала его поддержку, определив его Enhanced Storage. Enhanced Storage является встроенной системой безопасности в новых операционных системах Windows 7 и Windows 2008 R2, в которых обеспечивается поддержка функции защиты паролем и проверкой подлинности на основе сертификатов для USB-накопителей, совместимых со стандартом IEEE 1667.
Существенным отличим работы Enhanced Storage, от технологии BitLocker To Go, которая позволяет защищать съёмные USB-устройства хранения данных с помощью BitLocker, ограничивая доступ по паролю, является то, что она не зависима от версии использования операционной системы Windows 7, будь то Начальная или Профессиональная. Теперь защищенные паролем устройства можно будет просто подключать к любому компьютеру, не заботясь о предварительной установке и настройке чего-либо.
Если рассмотреть с практической точки зрения работу с Enhanced Storage, в самом востребованном случае, когда нужно установить пароль для доступа к информации на съёмном носителе, то она выглядит следующим образом.
Тут еще нужно обратить внимание на то, что съемные накопители (будто USB флэш-диск или портативные диск) с поддержкой IEEE 1667 существенным образом не отличается от обычных, их так же можно использовать в открытом состоянии с операционными системами, у которых отсутствует поддержка устройств совместимых с IEEE 1667.
При подключении устройств Enhanced Storage происходит установка как стандартных драйверов для переносных устройств, так и расширенных: IEEE 1667 ACT, Драйвер пароля Microsoft WPD Enhanced Storage, универсальный приемник команд IEEE 1667.
После определения устройства Enhanced Storage в системе, будет предложено установить пароль для доступа к съёмному носителю. Если при первом подключении в этом необходимости нет, то это можно будет сделать потом, через контекстное меню подключенного USB-устройства, выбрав нужный пункт. Если пароль не установить, то информация будет доступна на всех системах, включая те, у которых нет поддержки IEEE 1667, как и в случае c использованием обычного съемного устройства.
Процедура установки пароля, для каких вещей стандартная: ввести пароль, подтвердить его и, при необходимости, ввести слово или фразу, используемую в качестве подсказки. После этого уже можно использовать съемный носитель, доступ к которому осуществляется по паролю. Тут стоит отметить, что система не требует установки сложного пароля.
Заблокировать накопитель можно в ручном режиме, выбрав через контекстное меню подключенного USB-устройства нужный пункт, или это произойдет в автоматическом режиме – при выключении ПК, переходе в спящий режим, отключении накопителя от компьютера, а так же при блокировке компьютера по Ctrl+Alt+Delete. В заблокированном состоянии, данные (как то: размер диска, свободное место, тип файловой системы) не отображаются.
Для Enhanced Storage предусмотрен механизм зашиты от подбора пароля методом грубой силы. Можно ввести не более 50 неверных паролей, после чего возможен только сброс устройства, в ходе которого происходит удаление всех данных и восстановление установленных производителем параметров по умолчанию (происходит очистка установленного пользователем пароля).
Конечно, использование Enhanced Storage не ограничено схемой по установке пароля на съемные устройства с поддержкой IEEE 1667, различные варианты взаимодействия с компьютером можно задать через свои настройки, используя политики безопасности, настройки которых находятся в Конфигурация компьютера \ Административный шаблоны \ Система \ Доступ к устройствам Enhanced Storage.
Хотя стандарт IEEE 1667 являются новым и последняя спецификация – 1.1 была утверждена только в 2009 году, производители съёмных носителей уже предоставляют на рынок продукцию с поддержкой этого стандарта, и по цене она не отличается от обычных съёмных носителей.
Microsoft Enhanced Storage
Сегодня компании нуждаются в том, чтобы перед подключением переносных устройств к компьютеру происходила проверка подлинности. Потребителям необходим аналогичный подход, для гарантий, что их личной информацией не воспользуются посторонние люди, а так же, что неавторизованные устройства не смогут быть подключены к их компьютерам.
На текущий момент на рынке распространены как различные устройства с повышенным уровнем безопасности, например, накопители со сканером отпечатков пальцев или с поддержкой аппаратного шифрования данных, так и ПО для шифрования, которое поддерживает работу с любыми внешними устройствами хранения данных или позволяет использовать шифрованные файл-контейнеры, которые могут храниться на них. Но их использование возможно только с “фирменным” ПО или с предварительной установкой специального драйвера или программного обеспечения на компьютер, к которому будут подключаться устройства с повышенным уровнем безопасности, что не всегда возможно, а это означает ограниченную совместимость. Чтобы решить этот вопрос, необходим единый стандарт.
По этому не удивительно, что Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers – IEEE) взялся за этот вопрос, создав рабочую группу, которая разработала “Стандартный протокол аутентификации при подключении съемных устройств хранения данных” – 1667 (IEEE 1667-“Standard Protocol for Authentication in Host Attachments of Transient Storage Devices”). IEEE 1667 – это платформенно-независимый стандарт, в котором описаны требования взаимной идентификации между устройствами и компьютером для создания безопасной области, что позволяет доверенным устройствам свободно взаимодействовать друг с другом.
На текущий момент корпорация Microsoft является одним из активных участников по продвижению нового стандарта и уже реализовала его поддержку, определив его Enhanced Storage. Enhanced Storage является встроенной системой безопасности в новых операционных системах Windows 7 и Windows 2008 R2, в которых обеспечивается поддержка функции защиты паролем и проверкой подлинности на основе сертификатов для USB-накопителей, совместимых со стандартом IEEE 1667.
Существенным отличим работы Enhanced Storage, от технологии BitLocker To Go, которая позволяет защищать съёмные USB-устройства хранения данных с помощью BitLocker, ограничивая доступ по паролю, является то, что она не зависима от версии использования операционной системы Windows 7, будь то Начальная или Профессиональная. Теперь защищенные паролем устройства можно будет просто подключать к любому компьютеру, не заботясь о предварительной установке и настройке чего-либо.
Если рассмотреть с практической точки зрения работу с Enhanced Storage, в самом востребованном случае, когда нужно установить пароль для доступа к информации на съёмном носителе, то она выглядит следующим образом.
Тут еще нужно обратить внимание на то, что съемные накопители (будто USB флэш-диск или портативные диск) с поддержкой IEEE 1667 существенным образом не отличается от обычных, их так же можно использовать в открытом состоянии с операционными системами, у которых отсутствует поддержка устройств совместимых с IEEE 1667.
При подключении устройств Enhanced Storage происходит установка как стандартных драйверов для переносных устройств, так и расширенных: IEEE 1667 ACT, Драйвер пароля Microsoft WPD Enhanced Storage, универсальный приемник команд IEEE 1667.
После определения устройства Enhanced Storage в системе, будет предложено установить пароль для доступа к съёмному носителю. Если при первом подключении в этом необходимости нет, то это можно будет сделать потом, через контекстное меню подключенного USB-устройства, выбрав нужный пункт. Если пароль не установить, то информация будет доступна на всех системах, включая те, у которых нет поддержки IEEE 1667, как и в случае c использованием обычного съемного устройства.
Процедура установки пароля, для каких вещей стандартная: ввести пароль, подтвердить его и, при необходимости, ввести слово или фразу, используемую в качестве подсказки. После этого уже можно использовать съемный носитель, доступ к которому осуществляется по паролю. Тут стоит отметить, что система не требует установки сложного пароля.
Заблокировать накопитель можно в ручном режиме, выбрав через контекстное меню подключенного USB-устройства нужный пункт, или это произойдет в автоматическом режиме – при выключении ПК, переходе в спящий режим, отключении накопителя от компьютера, а так же при блокировке компьютера по Ctrl+Alt+Delete. В заблокированном состоянии, данные (как то: размер диска, свободное место, тип файловой системы) не отображаются.
Для Enhanced Storage предусмотрен механизм зашиты от подбора пароля методом грубой силы. Можно ввести не более 50 неверных паролей, после чего возможен только сброс устройства, в ходе которого происходит удаление всех данных и восстановление установленных производителем параметров по умолчанию (происходит очистка установленного пользователем пароля).
Конечно, использование Enhanced Storage не ограничено схемой по установке пароля на съемные устройства с поддержкой IEEE 1667, различные варианты взаимодействия с компьютером можно задать через свои настройки, используя политики безопасности, настройки которых находятся в Конфигурация компьютера \ Административный шаблоны \ Система \ Доступ к устройствам Enhanced Storage.
Хотя стандарт IEEE 1667 являются новым и последняя спецификация – 1.1 была утверждена только в 2009 году, производители съёмных носителей уже предоставляют на рынок продукцию с поддержкой этого стандарта, и по цене она не отличается от обычных съёмных носителей.
This is an ADMX-backed policy and requires a special SyncML format to enable or disable. For details, see Understanding ADMX-backed policies.
The payload of the SyncML must be XML-encoded; for this XML encoding, there are a variety of online encoders that you can use. To avoid encoding the payload, you can use CDATA if your MDM supports it. For more information, see CDATA Sections.
ADMX_EnhancedStorage policies
ADMX_EnhancedStorage/ApprovedEnStorDevices
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting allows you to configure a list of Enhanced Storage devices by manufacturer and product ID that are usable on your computer.
If you enable this policy setting, only Enhanced Storage devices that contain a manufacturer and product ID specified in this policy are usable on your computer.
If you disable or do not configure this policy setting, all Enhanced Storage devices are usable on your computer.
ADMX_EnhancedStorage/ApprovedSilos
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting allows you to create a list of IEEE 1667 silos, compliant with the Institute of Electrical and Electronics Engineers, Inc. (IEEE) 1667 specification, that are usable on your computer.
If you enable this policy setting, only IEEE 1667 silos that match a silo type identifier specified in this policy are usable on your computer.
If you disable or do not configure this policy setting, all IEEE 1667 silos on Enhanced Storage devices are usable on your computer.
ADMX_EnhancedStorage/DisablePasswordAuthentication
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting configures whether or not a password can be used to unlock an Enhanced Storage device.
If you enable this policy setting, a password cannot be used to unlock an Enhanced Storage device.
If you disable or do not configure this policy setting, a password can be used to unlock an Enhanced Storage device.
ADMX_EnhancedStorage/DisallowLegacyDiskDevices
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting configures whether or not non-Enhanced Storage removable devices are allowed on your computer.
If you enable this policy setting, non-Enhanced Storage removable devices are not allowed on your computer.
If you disable or do not configure this policy setting, non-Enhanced Storage removable devices are allowed on your computer.
ADMX_EnhancedStorage/LockDeviceOnMachineLock
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting locks Enhanced Storage devices when the computer is locked.
This policy setting is supported in Windows Server SKUs only.
If you enable this policy setting, the Enhanced Storage device remains locked when the computer is locked.
If you disable or do not configure this policy setting, the Enhanced Storage device state is not changed when the computer is locked.
ADMX_EnhancedStorage/RootHubConnectedEnStorDevices
| Edition | Windows 10 | Windows 11 |
|---|---|---|
| Home | No | No |
| Pro | No | No |
| Business | No | No |
| Enterprise | Yes | Yes |
| Education | Yes | Yes |
This policy setting configures whether or not only USB root hub connected Enhanced Storage devices are allowed. Allowing only root hub connected Enhanced Storage devices minimizes the risk of an unauthorized USB device reading data on an Enhanced Storage device.
If you enable this policy setting, only USB root hub connected Enhanced Storage devices are allowed.
If you disable or do not configure this policy setting, USB Enhanced Storage devices connected to both USB root hubs and non-root hubs will be allowed.
Enhanced Storage 6.0.4
A quality of life mod which improves the whole storage system of Starbound.
Enhanced Storage is a quality of life mod which improves the whole storage system of Starbound.
On the one hand it adds a lot of new features to the usablity of containers, and on the other it adds many new content concerning storage and containers.
If you want to use the addon just copy both pak files from the extracted archive.
If you want to deactivate this mod in the future be careful with more items in storage containers than the vanilla ones! They will be gone after deinstallation of this mod if you don’t backup them before.
Do you have a problem with the usage or the installation of this mod?
Do you want to report a bug or do you have other any questions?
Please let me know it and use the Discussion Thread, not the reviews!
Android Storage: Internal, External, Removable. Часть 1/3
Всем, кто, несмотря ни на что, сумел сделать правильный выбор.
Это перевод серии статей от Mark Murphy из CommonsWare, широко известного на stackoverflow, а так же автора книг “The Busy Coder’s Guide to Android Development”, “Android’s Architecture Components”. Некоторые термины оставлены не переведенными специально.
Internal Storage
Существует много путаницы в отношении модели хранилища Android. Путаницы стало значительно больше с изменениями Android 4.4 в Storage Model, и с тех пор ситуация не улучшилась. Есть бесчисленное множество вопросов на Stack Overflow и тому подобных ресурсах, где люди явно не совсем разбираются в различных моделях хранилищ Android.
То, что пользователи считают Internal Storage
Пользователь думает, что вся встроенная флешка — это «внутреннее хранилище» (Internal Storage). К счастью, Google начал менять этот термин с Android 8.0, перейдя к «general storage» вместо «internal storage».
Тем не менее, пользователи могут по-прежнему видеть «внутреннее хранилище» в таких местах, как окно проводника в Windows, когда их устройство подключено через USB.
Что Google считает Internal Storage
Увы, то, что видят пользователи это не то же самое, что Android SDK считает «внутренним хранилищем», что приводит к некоторой путанице. Если вы читали документацию на Android по внутреннему хранилищу, то это описание … как минимум туманно (прим. текст изменился со времени написания статьи):
Вы можете сохранять файлы непосредственно во внутренней памяти устройства. По умолчанию файлы, сохраненные во внутреннем хранилище, являются приватными для вашего приложения, и другие приложения не могут получить к ним доступ (также как и пользователь). Когда пользователь удаляет приложение, эти файлы удаляются.
По правде говоря, Android SDK определяет «внутреннее хранилище» как особый каталог, уникальный для вашего приложения, где ваше приложение может размещать файлы. Как было предложено в документации, эти файлы по умолчанию предназначены для чтения и записи для вашего приложения и запрещены для любого другого приложения (исключение: пользователи, работающие с файловыми менеджерами с привилегиями суперпользователя на rooted устройствах могут получить доступ ко всему).
В Context есть несколько базовых методов, которые предоставляют вам доступ к внутреннему хранилищу, в том числе:
Где хранится Internal Storage … Иногда
Где хранится Internal Storage … Остальное время
Однако не всегда внутреннее хранилище вашего приложения находится в указанном месте. Для разработчиков есть одно правило, которое вы должны усвоить из этой серии сообщений в блоге, это:
NEVER HARDCODE PATHS.
Время от времени я вижу, что разработчики делают что-то вроде этого:
File f=new File(«/data/data/their.app.package.name/files/foo.txt»);
Это не преступление, это хуже, это — ошибка.
Правильный ход, да и писать меньше:
File f=new File(getFilesDir(), «foo.txt»);
Что еще более важно, внутреннее хранилище не всегда находится в одном месте. Примечательно, что у нас есть понятие отдельных профилей пользователей (separate user profiles), начиная с Android 4.2 для планшетов и Android 5.0 для телефонов. Каждый пользователь получает свое собственное «внутреннее хранилище». Хотя вышеупомянутый каталог по-прежнему используется для основного пользователя, не гарантируется, что он же будет использоваться для вторичных учетных записей.
Исследуем Internal Storage
Device File Explorer tool в Android Studio 3.0+ может просматривать все внутренние хранилища на эмуляторе, а также внутреннее хранилище отлаживаемых приложений на продакшн устройствах.
Например, чтобы загрузить базу данных из внутреннего хранилища основного пользователя на вашу девелоперскую машину, вы можете использовать:
adb shell ‘run-as your.application.package.name cp /data/data/your.application.package.name/databases/dbname.db /sdcard’
Обратите внимание, что:
Ограничения внутреннего хранилища
На старых устройствах Android 1.x и 2.x внутреннее хранилище обычно находилось в выделенном разделе файловой системы, и этот раздел обычно был довольно крошечным. HTC Dream (a.k.a., T-Mobile G1), оригинальное Android-устройство, обладал огромными 70 МБ встроенной памяти для использования всеми приложениями (это не опечатка, в то время мы измеряли память в мегабайтах).
К тому времени, когда вышли 2.3 устройства, внутреннее хранилище могло быть размером 1 ГБ.
Android 3.0 изменил модель хранилища, так как внутреннее хранилище стало больше объемом. У устройств, которые рекламируют как имеющее 4 ГБ, 8 ГБ, 16 ГБ и т.д. пространства для хранения, обычно имелось все это (минус существующее содержимое) доступное для внутреннего хранилища. Мы рассмотрим, что изменилось в Android 3.0 и его влияние на модель хранилища в следующих постах про внешнее хранилище.
Для Android 1.x и 2.x внутреннее хранилище было действительно только для небольших файлов, и вам нужно было использовать внешнее хранилище для всего остального. Android 3.0+ означает, что для большинства устройств и большинства пользователей внутреннее хранилище отлично подходит для файлов, которые не предназначены для обычного использования другими приложениями или доступны пользователю независимо от вашего приложения. Однако некоторые опытные пользователи обнаруживают, что даже on-board flash недостаточна для того, что они хотят хранить, поэтому они переходят на съемные хранилища… которые представляют собой банку с червями (прим. имеются в виду ἕλμινς) — источник многих непредсказуемых и сложных проблем.
F.A.Q. по Internal Storage
Должен ли я делать файлы во внутреннем хранилище World-Readable или World-Writeable?
android: sharedUserId — это атрибут, который вы можете поместить в манифест, который указывает логический идентификатор пользователя, который будет использоваться для вашего приложения. Любое другое приложение, которое установлено, которое подписывается одним и тем же ключом подписи и запрашивает тот же android:sharedUserId будет использовать одного и того же пользователя Linux с точки зрения безопасности. Эффект заключается в том, что эти два приложения смогут безнаказанно работать с файлами друг друга, так как эти файлы принадлежат одному и тому же пользователю Linux.
Этот атрибут реально предназначен для предварительно установленных приложений, таких как software suite предварительно загруженный производителем устройства, мобильным оператором или разработчиком модифицированной ROM прошивки. В частности, как только вы единожды установите свое приложение, вы не сможете затем безболезненно изменить свое значение android:sharedUserId не заблокировав при этом доступ пользователю к любым существующим файлам… поскольку Android не изменяет права владельца на существующие файлы при изменении учетной записи пользователя Linux, под которой запускается приложение.
Существуют различные риски при одновременном доступе нескольких процессов к файлам. Некоторые подсистемы, такие как SQLite, имеют встроенную логику для решения этой проблемы. Но если вы сами организуете свой собственный доступ к файлу (например, через File и Java I/O), вам нужно что-то делать с одновременным доступом, а это сложно.
Вам также нужно обрабатывать ситуацию, когда одно приложение деинсталлируется, удаляя файлы, которые использовало другое приложение. В модели hub-and-spoke, например, с приложением и набором плагинов, возможно, это не так рискованно. В других моделях, где приложения более равноправны, вы не можете позволить себе потерять данные своего приложения только потому, что пользователь решил удалить какое-то отдельное приложение.
Как запретить пользователям rooted устройств доступ к моим файлам во внутреннем хранилище?
Просто не помещайте файлы во внутреннее хранилище. Пользователи rooted устройств могут получить доступ к тому, что им нужно на устройстве, поэтому единственный способ предотвратить их доступ к вашим данным — не иметь их на устройстве.
Некоторые разработчики попытаются зашифровать свои файлы с помощью жестко запрограммированного пароля, чтобы пользователи rooted устройств не могли использовать эти файлы. Это создаст эффект «лежачего полицейского» на короткое время. Все, что требуется, — это один заинтересованный в реверс-инжиниринге вашего приложения человек, определивший, как расшифровать эти файлы, а затем написавший сообщение в блоге или форуме о том, как это сделать.
В целом, относительно мало людей с rooted устройствами — я оцениваю их на уровне менее 1%. ИМХО, вы преуспеете больше, сосредоточив свою инженерную работу на написании лучшего приложения, вместо того, чтобы тратить время на защиту от рутованных устройств.