EKMuser1 EKMuser1@ekmgrp1 ekmgrp1
EKMuser2 EKMuser2@ekmgrp2 ekmgrp2 EKMadmin EKMadmin@ekmgrp1 ekmgrp*
Table 3: Example SQL server credentials and identities
An SQL Server account bound to credential EKMuser1 is logged into CryptoServer as
EKMuser1 . New keys are generated in CXI group ekmgrp1 and only keys in that group can be accessed. Similarly, an SQL Server account bound to credential EKMuser2 is logged in as user EKMuser2 , and new keys are generated in CXI group ekmgrp2 . Unsurprisingly, an account bound to credential EKMadmin is logged into CryptoServer as EKMadmin . New keys are now generated in CXI group ekmgrp1 since this value is taken from the credential’s identity. However, this user can also use keys generated by user EKMuser2 in group ekmgrp2 since the CXI_GROUP attribute grants access to these keys as well. This works since SQL Server commands refer to a key by an SQL Server name, which is bound internally to an EKM provider key name defined in the CREATE … KEY statement, and the actual access is done using an identifier stored together with the SQL Server name. This identifier is also used when the key is deleted inside the provider.
Note that the CXI group from the credential’s identity is also used when a key inside the CryptoServer is searched by name. This happens when a new SQL Server key is created from an existing CryptoServer key. Currently, supplying a different CXI group in the CREATE … KEY statement than the one given in the credential is not supported. Moreover, there would be no way to explicitly specify the CXI group when viewing all the keys from the SQLEKM provider.
Using the Provider