Access 12 Security Model
In last week’s post, I talked at a high-level about some engine-level changes we’ve made to Access. This week, I’ll talk about changes to the security model that sits on top of that engine, and crosses into the UI as well. Starting next week, I’ll be going into the UI changes and all the other new stuff we’ve done in the product.
Fewer modal prompts on boot (by default) and disabled mode
In Access 11 based on the configuration of the machine when a user opened a database, he or she encountered 3 to 4 modal startup prompts which, to say the least, was cumbersome. In Access 12 we've been able to weed out most of these startup prompts by improving the application's trust evaluation model (improvements to the Office Macro security model) and making core improvements to the client. When a user opens a database, Access 12 will assess the trust around this database by using the following pieces of evidence:
o Location of the database file: Using the Office trust center, users can denote certain folders (local or remote) as trusted locations. This is an easy way to tell the application that the Office file within this folder is trusted and hence is safe to launch.
o Code signatures: The good old signature model still exists. A user can digitally sign a database with his or her code certificate and share such a signed database with other users. Users who trust the certificate can then launch any Office file with a valid signature as a trusted file.
By examining these pieces of evidence associated with a database, the Access client then makes a decision to trust the database or not. If trusted, the database will launch fully enabled. If the database is not trusted, Access will still open the database, but components like VB code, macros, pass through queries and the like will be disabled. This disabled state of the database will allow the user to examine the file, without the fear of code execution. If the user decides the file is trustable after examining it, she can choose to trust it and thereby enable all code, etc. This trust model is shared across the Office suite, so will be familiar to all Office users.
Safe Macros
When in disabled mode, any set of custom logic even in simple and potentially safe cases like navigating to another Access object (hmm … isn't this the switchboard scenario) would be disabled. Access 12 has created a sandboxed coding mechanism for cases like this using the Access Macro language. Macros have been part of access since version 1, but are rarely used by developers today, since they’re essentially a subset of VBA. In Access 12, however, we’ve been able to use that subset to our advantage by marking many of the macro actions as “safe”. These safe macro actions can then be stitched together to provide logical components that still function if the database is opened in disabled mode. This subset of safe macros is not meant to completely replace the need for code, but to provide basic and safe operations within disabled mode.
Improved encryption with database passwords
In previous versions Access depended on JET's ability to encode a database with its proprietary encoding scheme. Though the scheme served its purpose when it was first released, the current market provides better and tougher encryptions algorithms that can be used. The same goes with the "Database password" feature, JET would allow only users that knew the password to open the database, but would do little to encrypt the file when a password was set. In Access 12 (by improving the new engine), we've combined the two features into "Encrypt with database password" for new file formats (for backwards compatibility reasons the old file formats would still support the old proprietary scheme). This feature allows users to encrypt a database using one the many Office supported algorithms, bringing encryption in Access on par with the new encryption models for other Office applications.
User level security
Since JET is a file based database system where users need physical access to the file to operate on their data, the concept of user level security in Jet to assign different levels of user access to the data within the same file was not recommended. To have multiple people use the database but with different data access privileges, the recommended practice was to move this data to a centralized service like SQL server or SharePoint lists. However, Jet has had this feature for some time and it has worked OK for usability and custom navigation scenarios but isn’t recommended for actual security. To help promote using truly secure user-level security, ACE will no longer support the JET concept of user level security for new file formats (for backwards compatibility reasons ACE will continue to support JET user level security for old file formats). To help maintain the scenarios around custom navigation the Access UI (including the NavPane) will allow solution creators to completely customize the navigation experience.
We believe that the security work in Access 12 will both make the product more secure through things like the improved encryption and clearer user-level security, and will make security easier to manage through the new trust model and “safe” macros. In the next post, I’ll start talking about the feature changes we’ve made to the product by describing how report design has changed.
