Patent Application
20050251865
The present invention relates to a system and method for privacy management of confidential and/or sensitive data.
Organizations store large amounts of confidential data about their employees, customers and partners. On the one hand, accessing and managing this data is fundamental for their business: confidential information is retrieved, analysed and exchanged between people (and applications) that have different roles within an organization (or across organizations) to enable the provision of services and transactions. On the other hand, data protection and privacy laws dictate increasingly strict constraints about how this data has to be protected, accessed and managed. Failure to comply with such privacy laws can have serious legal and business consequences. The reputation and brand of organizations that do not provide sufficient privacy protection for its data is likely to be negatively affected which in turn would have negative financial impacts. As discussed above, it is fundamental for an organization to use such sensitive data. However, this must be done in a way that is legally compliant.
Current data repositories, such as databases, typically include limited forms of access control mechanisms but offer little or no privacy management. For example, a database may offer user accounts so that access control policies can be implemented. The policies define actions the user associated with a respective account can perform in respect of the data repository. A normal user (typically a clerical employee) may be able to access, add and amend records but an administrator (for example a supervisor or IT technician) may be the only user permitted to delete records or change the structure of the database. In other cases, certain users may be given read only access to prevent unauthorised changes to data.
However, privacy management is not just a matter of authentication and authorization. When dealing with confidential (particularly personal) data, among other things, it is necessary to capture the purpose of data, convey the consensus of the data owners regarding acceptable use of their data and make decisions on access requests based on the requestors' intentions.
Privacy management is usually achieved using a privacy policy. In addition to the above requirements, privacy policies can dictate additional terms and conditions under which access to confidential data can be granted: this involves the satisfaction of constraints and obligations which might require the processing of credentials, trust verification and management of contextual information.
Organizations are responding to data privacy requirements by implementing privacy policies dictating how data can be used within the respective organization. However, most data repositories cannot intrinsically support these policies. Once data has been obtained from a repository by a user with credentials to satisfy the repository's access control system, the data can be used (or abused) however the user wishes.
Due to these limitations in data repositories, organizations have been forced to implement their policies at a personnel level, requiring their employees and management to be aware of, adhere to, and enforce the policy's requirements. Such implementations require an employee to be conscious of the policy when performing his or her duties and only perform an action if it is in accordance with the policy. Whilst some jobs can be changed to take policies into account, an employee typically has many policies, duties and other responsibilities to take into account in a typical day, some of which conflict leading to uncertainty and breach of policy.
In large organizations, people have different roles and skills. Business tasks are achieved thanks to collaboration among these people. The rigid enforcement of privacy policies might create disruptions in business practices and introduce unacceptable burdens. For example, confidential data can be stored in a variety of data repositories. In some cases, only technical specialists might have the right skills to retrieve data in a way that is meaningful for business people, marketing departments or strategists. Unfortunately, privacy policy constraints might dictate that these technical people must not access confidential data: in this case they would not be able to provide a service to the business people. As the business people themselves may not be able to retrieve meaningful data, time is likely to be lost and in extreme cases, adherence to the policies may prevent potentially lucrative uses of data. Similar observations apply for applications and services run by different organizations within an enterprise.
In an attempt to address data privacy within organizations, various computer systems for privacy management have been suggested. Most systems address data privacy purely from an access control perspective. This is inadequate because privacy is not just a matter of authorization, as additional aspects need to be taken in account such as trust management and dealing with ongoing privacy obligations dictated by legislation and an organization's guidelines.
Other systems attempt to implement privacy management by replacing a data repository with one that supports data access in dependence on an associated policy. Such policies are implemented at a system level, preventing a user from inadvertently overriding it. Such systems normally require rewriting of the data repository so that data can only be accessed via a specific driver or interface that supports and implements the respective policies. This is a very intrusive and expensive approach and can also be problematic for organizations having other applications that interface with the data repository as these must then be rewritten to communicate via the driver/interface. One example of this approach is the hippocratic database. In a hippocratic database, mechanisms are provided for preserving the privacy of the data by associating privacy metadata (i.e. privacy policies) with data stored in data repositories. Privacy metadata is added via additional database tables. Modified Java Database Connectivity (JDBC) data adaptors are used that deal with this privacy metadata and interact with external privacy engines. This approach requires customers to buy new versions of databases. In addition, it does not take into account that the management of privacy spans across database boundaries: such management has to be carried out within a broader context as it encompasses aspects such as the management of organization-wide privacy policies, obligations and application/service-based privacy policies.
Some systems, such as translucent databases, use data encryption to restrict access to confidential data when it is stored in data repositories. Most of these systems focus on the “confidentiality” and access control aspects: they commonly have little flexibility in providing policy-driven mechanisms encompassing aspects beyond authentication and authorization such as dealing with data purpose, matching the requesters' intentions against this purpose, enforcing obligations, etc.
Additional work has been carried out for privacy management in the area of data mining and statistical databases. In this context, the main goal is to prevent privacy violations when using data mining learning algorithms, data correlations and linking techniques. Current privacy management techniques in data mining use statistical approaches (i.e. information is not returned as it is but i is statistically modified, for example to reflect average values) and knowledge hiding.
According to a first aspect of the present invention, there is provided a data privacy management system comprising a data repository, a private data mediating system and a privacy manager,
According to another aspect of the present invention, there is provided a database system for managing data privacy comprising a database, a database application protocol interface and a data management system;
According to another aspect of the present invention, there is provided a data structure including a plurality of obfuscated private data items and privacy policy data associated with each obfuscated private data item, the privacy policy data being associated with conditions to be met-to for disclosure-of the private data item in a de-obfuscated form, wherein upon the conditions being met, the data structure being arranged to store the private data item in the de-obfuscated form for onward communication, the private data items being selectively de-obfuscated upon the respective conditions being met enabling onward communication of the data structure including obfuscated and de-obfuscated data items.
According to another aspect of the present invention, there is provided a method of managing privacy of a data item comprising:
According to another aspect of the present invention, there is provided a computer readable medium having computer readable code means embodied therein for managing privacy of data items and comprising:
According to another aspect of the present invention, there is provided a data privacy management system comprising a data repository, a private data mediating system and a privacy manager;
According to another aspect of the present invention, there is provided a data privacy management system comprising a data repository, a further data repository, a private data mediating system and a privacy manager;
According to another aspect of the present invention, there is provided a data privacy management system comprising a data repository, a private data mediating system and a privacy manager;
According to another aspect of the present invention, there is provided a data privacy management system comprising a data repository, a private data mediating system, a data gateway and a privacy manager,
In the context of the present invention, the term “obfuscated data” refers to data that is rendered unintelligible whilst “de-obfuscated data” refers to intelligible data (typically the original data). Examples of obfuscation processes include encryption, hashing, and reversible compression. A reversible compression algorithm may convert of data blocks to numbers or other codes. Reversing the compression would operate in reverse to the encoding process.
Data subject to privacy management controls is referred to as private data. It will be appreciated that this may include confidential data, personal data, sensitive data, data regulated by legislation or any other form of data subject to privacy control.
The present invention seeks to provide a system for privacy management of private data stored by organizations and other organizations. Data is stored in standard data repositories in such a way that sensitive or confidential items of data (referred to as private data) is obfuscated and associated with a privacy policy. Data structures containing private data can be extracted from the data repository and sent to other entities with the private data remaining obfuscated. Entities that try to access the obfuscated private data can be different from those entities that retrieve the private data items from the repository. Obfuscated data can be accessed via a private data mediating system that is arranged to communicate with a privacy manager which in turn is arranged to decide what is visible at a given time for each specific request for content. The visibility of (and in some embodiments, access to) the obfuscated data is adaptive, depending on the requester, the context and purpose. Hence multiple “views” on a data structure can be provided by our system.
The present invention seeks to provide a system in which privacy management and control is transparent to users and to the data repository itself. In this manner, the present invention can be used with existing data repositories and does not necessarily interfere with other applications accessing non-private data within the repository.
In embodiments of the present invention, privacy management policies can be applied to records or fields at any one of a number of levels of granularity. This means that different users or user roles can be provided with different levels of access permissions for different types of data within the repository. Privacy control is preferably implemented by obfuscation of private data fields and/or whole data records. De-obfuscation is subject to successful authorisation by the privacy manager.
In this manner, adaptive access to confidential information can be provided based on the satisfaction of privacy policies with a minimal impact on data repositories in terms of required technological changes. Little disruption and additional cost is experienced by the organization deploying the system.
In one embodiment of the present invention, an interface in the form of a private data mediating system is used by people and applications to access obfuscated data and mediates their interactions with data repositories as dictated by privacy policies; one or more Privacy managers (i.e. trust services run by organizations or trusted third parties) deals with the enforcement of privacy policies. The process of disclosing private data is adaptive to contextual information.
The present invention seeks to allow existing data repository technologies to be utilized whilst minimizing the impact on the data repositories and the organizations themselves. Interaction with data repositories can still happen as usual but with the additional guarantee that private data is now protected and contextually released, in a fine-grained way, based on the fulfillment of associated privacy policies.
Whilst implementing a system according to an embodiment of the present invention may require some changes in the logical definition of data structures of the data repository (i.e. different types of fields in tables, different LDAP classes' definitions, etc.) in order to store obfuscated data and the associated privacy policies, no technological changes are required for data repositories or the access/query language used.
In embodiments of the present invention, fine-grained privacy policies can be associated with individual data fields or items, forcing requesters to be compliant to these policies if they want to view the associated data. This can be achieved in a flexible way, without a priori preventing the various entities from interacting, as dictated by business processes.
a is a schematic diagram of a record of data fields prior to implementation of a data privacy management system according to an embodiment of the present invention;
b is a schematic diagram of the record of data fields of
a and 5b are views of a table of data including private data fields provided to users with different credentials by an embodiment of the present invention;
a and 9b are flow charts illustrating aspects of a method according to an embodiment of the present invention.
A data repository 10 stores data, at least some of which is private data, that is, data considered sensitive and/or confidential and is the subject of privacy control. The data repository 10 is a standard structured query language (SQL) relational database storing data in linked tables of records. Data stored by the data repository 10 can be accessed in a conventional manner, for example using an open database connectivity (ODBC) application program interface (API) or a Java database connectivity (JDBC) API 20.
The table 50 is formed from a number of data fields 51-54 (shown as columns). Records are illustrated as rows 50a-50e, each row 50a-50e having an entry in a respective data field 51-54. The first and third data fields 51, 53 hold private data whilst the remaining fields 52, 54 hold non-private data. Data in non-private data fields 52, 54 is stored in a non-obfuscated (clear) form that can be read by anyone having the access rights to access the table. Data in private data fields 51, 53 is stored in an obfuscated form. A user having access rights to access the table is able to access the private data fields, the content is not intelligible as it is obfuscated.
An example of an obfuscated data field is shown in
The data privacy management system includes an interface 30 and a privacy manager 40. The interface 30 includes a private data mediating system 35.
The private data mediating system 35 mediates interactions between the interface 30, the data repository 10 and the privacy manager 40. When private data is retrieved from the repository 10, the private data mediating system 35 can automatically attempt to de-obfuscate the private data. Alternatively, de-obfuscation can be requested by a user, either in reply to a prompt when the private data mediating system 35 detects retrieval of private data or alternatively via an appropriate user interface control.
When attempting to de-obfuscate data, the private data mediating system 35 extracts policy data from the policy sub-field 53a of the private data field and obtains contextual data required by the policy defined by the policy data. The private data mediating system 35 then establishes a secure communication link 36 to the privacy manager 40 and transmits the policy data and the obtained contextual data to the privacy manager 40.
Upon receipt of the policy data and contextual data, the privacy manager 40 determines whether the contextual data satisfies the policy defined by the policy data. If the policy is satisfied then the privacy manager 40 transmits de-obfuscation data via the secure communication link 36 to the private data mediating system 35 allowing it to de-obfuscate the data.
The decision made by the privacy manager 40 of whether to allow access to private data by an entity at a specific point in time takes into account the specific request, relevant privacy policies, intended use of the data and requestor's credentials.
An example application for an embodiment of the present invention is shown in the schematic diagram of
In this example, an airline maintains data on its customers in a customer table of its database. Prior to implementation of an embodiment of the present invention, each record 100 in the customer table had a format as shown in
The airline decides to implement a privacy policy that restricts viewing of the customer name field 102, customer address field 103 and credit card number field 104. A selection of the requirements defined by the policy includes:
During implementation of a system according to an embodiment of the present invention, the structure of the customer table 100 is not changed. Thus, any reports, SQL queries or the like that have been written for use with the database are not affected. During implementation, data in the data fields selected to be private (102, 103, 104) is replaced with an obfuscated version (102b, 103b, 104b) of the data preceded by policy data (102a, 103a, 104a) defining the criteria that must be satisfied to view the respective data, as is shown in
A basic form of privacy policy would consist of text describing a list of conditions and constraints (strings of characters). An example policy for the address field 103 could be:
The policy data preceding the obfuscated data (102b, 103b, 104b) may be the text of the policy itself, a link, such as a URL, to the policy text or an encoded version of the policy or some other value via which the private data mediating system can obtain the policy criteria (or at least details of data required for submission to the privacy manager to determine whether the policy is satisfied). The privacy manager or some other central entity may store the policy details.
Thus, when a member of the advertising department wishes to run a mail merge, she runs the SQL query:
select*from customer_table where customer_country=“uk” (1)
All data fields would be returned for those entries having a customer country “uk” but the credit card field 104 would be obfuscated (with no possibility of a member of the advertising department being able to de-obfuscate it) and the name and address fields 102, 103 would only be de-obfuscated if the respective data usage field 107 permitted.
If the airline decided to restructure its database in the future (for example moving the credit card number field 104 to a separate table indexed by unique customer ID 101, no change to the data privacy system would be needed.
Other scenarios where embodiments of the present invention may be applicable include:
a and 5b show an example where different “views” of private data are provided to different requestors. Private data can be retrieved by people and applications that have no rights to access its content (i.e. they do not satisfy privacy policies) but are in charge of querying data repositories on behalf of other people, as is shown in
This basic model can be extended and adapted to a variety of scenarios including intra-organizational and inter-organizational contexts. In particular the privacy manager can be provided by an organization for internal consumption or by one or more external trusted third parties, to enable multi-party interactions and at the same time increase the overall trust and accountability.
The content of an obfuscated field (for example in a database record) could be represented as:
If public key encryption is used, the privacy manager provides its public key to users. When obfuscating data, a symmetric key is generated and used to encrypt the data. The symmetric key and a hash value of the associated policies are encrypted as the privacy policy data in a package by using the public key. The overall information (encrypted private data, clear text policies and encrypted privacy policy data) is stored as the obfuscated field in the repository. The privacy manager is the only entity that can decrypt the above encrypted privacy policy data package. The hash contained in the package is used to check for the integrity of the associated policies. Once integrity has been ascertained, the policies can be checked for compliance and allowing disclosure of the symmetric key.
An alternative approach to obfuscation could use identifier-based encryption (IBE). Any kind of string (including text, pictures, terms and conditions, etc.) can be used as an IBE encryption key. Privacy policies are preferably used for this purpose. The correspondent IBE decryption key can only be generated by the privacy manager as it is the only entity that has the “secret” necessary for doing it. The privacy manager checks the compliance of a requestor with these policies. The generation of IBE decryption keys can be postponed in time i.e. until they are actually necessary for decryption purposes. Any tampering with the IBE encryption key will make impossible for the correct decryption key to be generated. In this situation, only the privacy policy data (which is itself the IBE encryption key) needs to be stored with the obfuscated private data. No encrypted private policy data is stored. To obtain de-obfuscation data, the privacy policy data and obtained contextual data is sent to the privacy manager. If the contextual data satisfies the policy defined by the privacy policy data then the privacy manager generates a decryption key from the privacy policy data and transmits this to the private data mediating system for use in de-obfuscating (decrypting) the obfuscated private data. If the privacy policy data has been in any way altered or tampered with, the decryption key generated will not be appropriate for decrypting the obfuscated private data, thereby ensuring integrity of the privacy policy data.
As the policy data may be quite large, IBE encryption of the private data may prove too computationally intensive, in which case a combination of PKE and IBE could also be used. In this embodiment, the obfuscated data includes:
As before, the privacy policy is in a clear readable from. The encrypted privacy policy data contains a symmetric key used to encrypt the private data and a hash of the privacy policy data. The difference to the above described embodiment is that the privacy policy data is encrypted using the privacy policy as an IBE encryption key. The hash need not be included in the encrypted policy data if storage space is at a premium as the IBE encryption ensures the integrity of the policy data.
It will be appreciated that other obfuscation mechanisms could be substituted in place of that discussed above. For example, instead of encryption, reversible compression, encoding, hashing or some other one way or two way obfuscation mechanism could be used.
In the case of hashing, a separate database of non-hashed data could be made accessible only by the privacy manager. An alternative embodiment of the present invention using hashing for obfuscation is illustrated in
Data within private data fields of a data repository 10 is hashed and associated with a respective privacy policy, as discussed above with reference to
In cases where obfuscation is by encoding or reversible compression, the same encoding/compression scheme is likely to be used for obfuscating more than one data item. It is therefore not desirable to disclose the encoding/compression scheme to a private data mediating system/user. In such a case, an implementation such as discussed above with reference to
The specific format used to represent privacy policies could be changed depending on the particular implementation. However, the format used to represent a policy should be flexible enough to express the following aspects:
Examples of policies follow below. They reflect a user's perspective and they are related to a scenario where customers' data is stored and accessed by members' of an organization. Policies from an organization's or employer's point of view could also be envisaged:
The above policies reflect customers' constraints and (for simplicity) they are expressed in natural language. Notice that constraints might require the fulfillment of actions involving the data owners, such as notifications or explicit requests for authorization. Different kind of policies can be used to express internal organization guidelines and privacy requirements.
Preferably, privacy policies are written in a formal language (via logical expressions and constraints) in a way that they can be programmatically interpreted. However, the implementation of policies and their format can be varied as is needed. Note that the policy data stored with the obfuscated data could be an encoded or compressed version of the actual policy. For example, the privacy manager may include a repository linking codes to actual policies. Similarly, the policy data may be a pointer to the actual policy stored elsewhere. In each case, the policies could be updated without needing to update the obfuscated data in the data repository 10. Where the actual policy is not discernible by the private data mediating system, an initial query would have to be made to a policy management system, which may be the privacy manager 40 or another entity responsible for maintaining the policy repository to determine the credentials etc needed for submission to the privacy manager 40 to obtain the de-obfuscation data.
Preferably, privacy policy data should stick with the encrypted data and this link should not be able to be broken. In preferred embodiments of the present invention, the stickiness of policies to identity information is obtained by obfuscating the identity information in a way that its de-obfuscation is a “function of” the associated policies. Any tampering with the policy data prevents the de-obfuscation of data.
Once retrieved, private data can be stored and/or represented via data structures that simplify their portability in case of their transmission. Such a data structure would contain any retrieved confidential information along with the associated privacy policies. One implementation of such a data structure would be in XML. A portion of an example XML data structure including a header section and a record section representing an example record extracted as the result of the SQL query (1) discussed above with reference to
The field privacymanager defines the IP address to be used to contact the privacy manager responsible for controlling access to obfuscated data. The mediator field points to a location where a Java application that functions as a private data mediating system can be downloaded. The customercreditcard field is obfuscated in the manner described above and includes the obfuscated data preceded by a URL to the policy held on a web server.
The data structure can be transmitted to other parties such that the entity that accesses the private data can be different to, and possibly in an organization remote from, the entity that retrieved it.
The representation of data via an explicit XML-based data structure allows a “transportable” representation: this can include data in clear, obfuscated data and the associated privacy policies. This data structure can be transmitted to other parties where private data may only be made intelligible via the mediation of a private data mediating system (if the associated privacy policies are satisfied). The XML data structure may include a URL or other instructions detailing where a version of the private data mediating system can be obtained to address the eventuality that the receiving system does not include this functionality. For example, the private data mediating system could be a Java applet that can be downloaded over the web, as illustrated above.
The private data mediating system 35 is preferably an extension of traditional data repository's API 30 used by users 200 and applications 210 to access the data repository 10. The API 30 includes functionality to pass or retrieve data along with privacy policies and the declared intention (i.e. the reason for making this request) to a designated privacy manager 40. Note however, this extension does not require changes to the data repository 10 itself.
In case of access to a relational database, two basic interactions can happen:
The private data mediating system 35 may also include:
The Privacy manager 40 is responsible for enforcing privacy policies associated with private data. As discussed above, private data can be retrieved by entities and applications in an obfuscated form without satisfying the privacy policy. However, access to the de-obfuscated data is subject to satisfying the privacy manager that the associated policy is satisfied.
The privacy manager 40 verifies that privacy policies are fulfilled before providing the keys for de-obfuscating private data. Any disclosure of keys is preferably audited and monitored.
The privacy manager preferably includes:
It will be appreciated that in embodiments of the present invention, the content of obfuscated data can be incrementally de-obfuscated, at different stages, by providing the privacy manager 40 with the required information (additional credentials, etc.). An example of this step-wise de-obfuscation is shown in
Requestor A interacts with its private data mediating system 35 to extract data from the table 50 of data repository 10. The data extracted is rows 51, 52 and 53, of which rows 51 and 53 are obfuscated. The data mediating system 35 transmits the policy data associated with each obfuscated row 51, 53 in message A1 to the privacy manager 40 along with any credentials or other data required to satisfy the policies. In this case, requester A does not satisfy the policy requirements for either of the obfuscated rows and the privacy manager sends message A2 declining to issue de-obfuscation data. Thus, the view of the extracted data available to requestor A merely consists of row 52 with rows 51 and 53 remaining unintelligible.
Requestor A then passes the extracted data to requestor B. Upon receipt, requestor B's private data mediating system 35 identifies that rows 51 and 53 are obfuscated and attempts to de-obfuscate them by transmitting the associated policy data along with necessary credentials etc in message B1 to the privacy manager 40. Upon receipt, the privacy manager 40 determines that requestor B satisfies the policy for row 51 but not for row 53. The privacy manager 40 therefore issues de-obfuscation data for row 51 in message B 2, allowing the private data mediating system 35 to de-obfuscate row 51 into intelligible data, shown in the Figure as 51′. Data in row 53 remains obfuscated. Requestor B's view of the data could be subsequently passed on to another requestor who may satisfy the policy requirements for row 53.
a and 9b are flow diagrams illustrating the steps performed by a private data mediating system and a privacy manager, respectively, to determine whether a requestor satisfies the requirements of a policy.
In step 500, a requestor's private data mediating system extracts data from a repository. In steps 510 to 650, each extracted data item (field, record or the like) is processed by the private data mediating system. In step 510 the data item is checked to see if it is obfuscated. If the data item is not obfuscated then processing proceeds to the next item (if there is one) in steps 640 and 650.
If the data item is obfuscated, the private data mediating system checks for a connection to the privacy manager in step 520. If there is no connection then a secure connection is established with the privacy manager in step 530. The private data mediating system then obtains the policy data from the obfuscated data item in step 540 and obtains any data (such as data on the requester, the requestor's computer system, context and/or purpose of the request etc.) required to be submitted for fulfilment of the policy in step 550. the obtained data, the policy data and the encrypted privacy policy data is then transmitted to the privacy manager in step 560.
Upon receipt of the obtained data, the policy data and the encrypted privacy policy data, the privacy manager extracts the symmetric key and hash from the encrypted privacy policy data in step 570, generates a hash of the received policy data in step 575 and compares the extracted hash to the generated has in step 580 to determine if the received policy data has been altered or tampered with (for example if the policy has been modified). If the integrity check on the policy data fails then a rejection message is returned to the private data mediating system in step 620. If the integrity check on the policy data is passed then the data provided on the requestor etc is checked against the policy in steps 590 and 600. If the policy is satisfied then the privacy manager provides the private data mediating system with the extracted symmetric key for de-obfuscating the private data in step 610, otherwise a rejection message is sent in step 620.
Upon receipt of the symmetric key, the private data mediating system de-obfuscates the obfuscated private data in step 630. If more data items exist then these are processed, otherwise, any connections to the privacy manager are terminated in step 660.
Depending on the privacy policy and other requirements of the organization/enterprise, restrictions may be put in place via the private data mediating systems and/or at data gateways such as email servers, web servers, firewalls and the like requiring that policies be re-validated before data is transmitted. In this manner, a user may be given permission to view private data but would be restricted from onward transmission of the de-obfuscated data to some or all recipients. For example, the private data mediating system could be arranged to re-obfuscate private data (with the same or a new symmetric key) upon saving or copying the data. Similarly, a process or system at data gateways could scan for policy data and re-submit the policy data to the privacy manager 40 prior to transmission. In some contexts, the policy may allow de-obfuscated data to be transmitted but in others, transmission of the data in any form may be prohibited or transmission of the data in de-obfuscated form may be prohibited. As with the policy discussion above, any number of different restrictions could be set depending on the recipient, requestor, context etc.
It will be appreciated that the disclosure process for de-obfuscation data is adaptive and driven both by privacy policies and contextual information. Contextual information can be very rich, including not only users' credentials and declared intents, but also system information, measures of trust of the requestors' platforms, historical information, etc. It is important to notice that the disclosure of confidential information can modify the current context and, as a consequence, enable/disable sets of privacy policies and influence future disclosures.
The privacy manager can be deployed as a server, computer system or software application such as a service running on a server or computer system. The privacy manager may be located either remotely or locally to the site where the data repository is located. It could also be provided by a trusted third party to enable multi-party interactions and ensure a consistent enforcement of privacy policies.
In a more advanced scenario, privacy policies can ask the private data mediating system to interact with multiple privacy managers (each having specific competences) in order to access obfuscated data.
Embodiments of the data privacy management system and method of the present invention can potentially be bypassed as requestors could try to access data by directly querying the data repositories or by accessing the content of files (if they have the basic access control rights). However, in this case, any obfuscated data is unintelligible. This forces the requestor to interact with the privacy manager as dictated by the associated privacy policies.
Lifecycle management of privacy policies associated to private data, including their renewal and modification can be implemented in embodiments of the present invention. The management of keys is strictly related to the management of policies as decryption keys will be issued based on policy fulfillment. By changing a policy, the associated encryption key could automatically be changed. Revocation of keys and one-time usage of keys could also be addressed in this context.
Encryption keys could also be changed upon successful disclosure of private data. This could be done via a combined interaction between the privacy manager and the private data mediating system. At disclosure time the privacy manager asks the private data mediating system to change the encryption keys related to the following disclosure. Example scenarios where an encryption key may be changed include:
It will be appreciated that it is preferable in the medium to long term for applications and services to be modified to be privacy-aware and to fully leverage embodiments of the data privacy management method and system of the present invention. This is particularly important for the storage of private data via the private data mediating system, as only in this way will data be stored according to privacy criteria (e.g. data obfuscation). However, it will also be appreciated that no immediate changes are needed to legacy applications and systems upon implementation of an embodiment according to the present invention. Indeed, even the obfuscation of private data and the addition of privacy policies could be implemented over time given that the approach taken by embodiments according to the present invention is complementary to and compatible with existing data repositories.
While the above embodiments have shown policies applied to whole rows of data, it will be appreciated that policies could be applied to particular data fields or records. In addition, more than one policy could apply to a data item —there may be a policy associated with the particular item, another associated with the whole record and perhaps another associated with the organization itself. In such situations, a hierarchy would have to be defined to avoid one policy conflicting with another. Most likely the policy associated with the data item would take precedence followed by that for the record followed by that for the organization.
Compared with traditional “views” on data (for example views on database tables), embodiments of the present invention reduce the need for defining a broad set views to accommodate multiple different cases. Depending on requesters' capabilities and clearance, access and privacy constraints are directly associated with data and dictate what can be seen at any point in time.
Privacy policies are strongly associated to data at least until the first disclosure happens. Disclosures are preferably audited along with the context in which the disclosure happened. Audit logs increase the accountability of the involved entities and can be used for forensic analysis in case of detected privacy violations. In the future, it is likely that further controls will be available: most notably, if the requestor's platform includes technologies such as security-enhanced operating systems (OS) and TCG technology, these could potentially be used to control the use and propogation of deobfuscated data, for example by OS-level checking over whether certain operations are allowed on specific (tagged) data and hardware-based control over the use of the data (such as only allowing it to be accessed within a trustworthy software state).
While embodiments of the present invention have been shown using relational databases as reporsitories (in particular SQL databases), it will be appreciated that embodiments of the present invention are applicable to any form Of data reporsitory, whether in the form of a database, file system or other system.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0410180.4 | May 2004 | GB | national |
