04-07-2014 01:08 PM
We are planning to encyrpt our data in SAS 9.2 for both SAS data at rest and in transit.
Are there any performance metrics available for any of the following encryption types?
04-08-2014 03:45 AM
I haven't heard of any official metrics.
Similar to compression, each site has it's own specifics - which in the area of encryption includes CPU capability and the data profile.
It sounds like you have a SAS license already, so the best way to found out is to test - SAS Proprietary is included in Base SAS. For SAS/Secure (if you don't have that licensed at the moment), talk to your SAS sales representative and discuss the possibilities to set up a trial license for testing purposes.
Requirements wise, if there is a requirement for encryption, I should suspect that requirement need decide which encryption method you should chose. Decide that first, then look at the implementation.
My gut feeling is that compression comes with a similar CPU penalty to uncompressing compressed data.
04-08-2014 05:16 AM
To encrypt the data at rest you are limited to SAS datasets in table format. This is the encrypt dataset option.
All other types of data are not applicable for encrypting (catalogs output logs etc.).
To encrypt data over the wire (transmission) data you can use SAS/Secure for most clients. For the SAS/Connect and Share you are needing the SSL setup.
The more higher encryption level is needed the more overhead is involved. No real metrics are available.
As you are planning encryption I am expecting you already have a well designed OS layers control in effect. The default roll out of SAS is insufficient in this aspect.
Al lot of adjustments to OS layer controls is mentioned in: Bisecag (security admin guide EIP), Bound libraries guide, VA admin guide. You would be one the first when you did follow that.
The encryption of SAS datasets comes with some logical penalties, those are:
- encrypted datasets are not supported when you would like to use update in place options (ADD rows). That is for example the EGuide table editor.
- The read password serves as an additional seed. By that you need to use that dataset-option always. As seed it may be published public as in that case your intention is not protecting it by a password. The real protection of the data should come from a different approach. That is: OS layers.
04-08-2014 10:12 AM
Thanks for the detailed responses. I agree the only way to analyze the performance impact is to implement the solutions.
We are in the process of evaluating the exact requirements before diving deeper into SASProprietary or SAS/Secure
I am concerned with the AES option in SAS/Secure can significantly impact the performance which will not be well received by our users.
We already use very expensive disk to get them the best performance, but it may not be sufficient.
Thanks again !