Protecting Data Stored in Context
The context object holds the data, which is shared by all hosted applications in a session. Each customer contact (usually a call) is assigned a session. Multiple calls are handled by multiple sessions, and each session has its own private context.
The context is a name-value object that contains data about the customer contact, such as the name, phone number, account ID, and so on. It can also include any data that applications need to share.
During a customer call, a Web service records the context in a database. While this is useful for producing call center activity reports, it also means that anything stored in the context can later be read in reports. For example, a credit card number might be placed in the context. This would then be copied to the database.
Database reports can be written to exclude sensitive data from the context. However, you should avoid placing confidential data in the context to begin with, or you should use other methods to secure the context data. Some methods to alleviate risks associated with saving data in context are:
- Do not write the context information in the database.
- Encrypt the context information in the database. You can do this at the database level or at the Web service level.
- Do not write any sensitive information in the context.
One acceptable technique is to set stringent database rights access. The database could be configured so that only those who are required to view the data have access to it. However, this might not be sufficient to protect the database if you have a rogue employee. The safest method is to never write sensitive information in the context.
A second recommendation is to disable saving the context in a database if you are not generating any reports that use the Context table. You can disable context storing in the ID (ApplicationHost.cs) and in the Context Web service.