The last post described the limitations of syncing Bitlocker-protected virtual disk images to the cloud. While the design achieves the stated goal of keeping data safe from any prying eyes– including the cloud storage provider– it is not very practical. There is contention between Windows operating system treating the VHD as mounted drive, and local synchronization agent trying to upload that file to the cloud. Note that even if concurrent access could be supported, it would not necessarily help. Because the sync agent does not know when the virtual filesystem completed updates to the disk image, it could end up uploading a corrupted image– similar to what would happen if a USB drive is suddenly yanked out when the machine is still trying to write to it.
What is needed is some way of addressing the virtual disk in the cloud at block level. This is where iSCSI comes in. SCSI stands for Small Computer System Interface, a popular standard for connecting high-end disk drives since 1980s. iSCSI follows the convention of adding the magical “i” in front of technologies when they are updated for the Internet. While SCSI connections spanned a few inches from a disk drive inside the chassis to the motherboard, iSCSI allows the underlying protocol to run over an IP connection. This allows treating servers halfway around the world as if they were local disks, with low-level access to underlying disks.
That last property is critical since NFS, SMB and many other file sharing protocols exist to present a view of remote storage organized into directories and files. iSCSI operates at a much lower and allows addressing storage at block level. That also happens to be the level where Bitlocker operates. Starting with Windows Server 2008 and Windows 8, it is possible to enable Bitlocker on iSCSI targets as they are called in SCSI terminology. (This is a new development; Windows 7 did not support encryption on iSCSI volumes.)
That suggests a different plan of attack on using cloud services as glorified remote disk, without giving service provider any visibility into our private data:
- Place iSCSI volume in the cloud.
- Mount that iSCSI target as local drive. This can be done from any machine where we plan to access data
- Apply Bitlocker-To-Go full disk encryption with smart card to that drive
- Use the locally mapped disk as one would use any other removable storage to store our files
Steps #3 and #4 are straightforward, because they work in exactly the same way as previous VHD-based private backup solution. (Both the one-time initialization process to encrypt the volume and subsequent “unlocking” operations to access that data work same way.) So we focus on first two problems unique to iSCSI.
iSCSI targets in the cloud
The first challenge is finding an off-the-shelf service provider that offers storage presented as iSCSI target. This is not surprising. iSCSI is very much an enterprise technology designed to operate inside corporate networks and datacenters. There is no advantage for Dropbox or other consumer-grade services to present their storage across the Internet this way. Second is the problem of OS/device compatibility. As usual Windows leads the way here: both Windows 7 & 8 can access iSCSI targets, by acting as an iSCSI initiator. No such luck with OS X or mobile platforms such as Android. Even enterprise focused cloud storage services such as Box gravitate towards least-common denominator and have little incentive to support niche protocols. There is a plethora of network attached storage (NAS) hardware offerings with iSCSI functionality, but few hosted services with pay-as-you-go model. (Purchasing hardware and getting dedicated hosting does not count as “leveraging existing cloud services.”)
Luckily there is a simpler– but not free– solution based on existing services. In addition to acting as iSCSI client, Windows Server boxes can also function as iSCSI targets. Originally available as separately installed component called MSFT iSCSI Software Target for Server 2008 R2, the feature was later incorporated into Server 2012.
[continued: virtual iSCSI targets]