Our new Compliance group will be handling personally identifiable information for field technicians and vendors. We have a Windows file server with SMB shares, and BitLocker is already enabled on the storage. I'm looking for an additional layer of protection that encrypts specific directories or files, rather than only protecting the disks at rest.
The goal is to limit the damage if an otherwise authorized user account is compromised. Ideally, encryption keys would be managed on-premises or through a cloud service, with employees checking out keys through SSO and MFA when they need access. Key rotation would also be useful, although manual rotation could work. What software or architecture would be a good fit for this kind of file-level protection?
4 Answers
Volume encryption probably isn’t the right layer for this. BitLocker is still worthwhile because it protects the disks if the server or drives are stolen, but once Windows is running, users with valid share and NTFS permissions can generally read the files normally. Encryption at the volume level won’t protect against a compromised account that already has access.
Be careful with encrypted containers on a file server. They often depend on one mounted volume and a shared master key, which creates concurrency, recovery, and key-escrow problems for multiple users. A product that supports Windows file-level encryption, centralized key management, identity integration, auditing, and recovery testing would be a better fit. Have Compliance and Legal define the required controls first, then verify that the product protects files while they are being accessed—not just while the storage volume is offline.
If the encryption needs to follow individual files after they leave the server, look at an information-protection or rights-management platform rather than a traditional encrypted volume. File-level protection can enforce identity-based access, MFA or conditional access, auditing, expiration, and revocation even when a document is copied or shared with a vendor. Microsoft 365 sensitivity labels and rights management may be relevant if your organization already uses that ecosystem.
For the SMB server itself, focus on tightly scoped share and NTFS permissions, separate groups for vendors and employees, MFA where possible, privileged-access controls, access reviews, auditing, and fast account revocation. Those controls reduce exposure, although they do not stop a compromised account from using its authorized access. Also make sure there is a documented key-escrow and recovery process before deploying any encrypted filesystem or container.
That’s my concern. Permissions handle normal access, but I’m looking for protection if an attacker takes over an account that already has legitimate access to the PII.