Systems and methods for securing customer data in a multi-tenant environment

• US 8,069,153 B2
• Filed: 10/23/2006
• Issued: 11/29/2011
• Est. Priority Date: 12/02/2005
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Nakada, Paul, McKinnon, Todd, Moellenhoff, Dave, Chan, Eric, Weissman, Craig
• Primary Examiner(s): Vital; Pierre
• Assistant Examiner(s): OBISESAN, AUGUSTINE KUNLE
• Application Number:
  US11/585,527
• Publication Number:
  US 20070130130A1
• Time in Patent Office: 1,863 Days
• Field of Search: None
• US Class Current: 707/691
• CPC Class Codes: G06F 16/2455 Query execution
• CPC Class Codes: G06F 16/24575 using context
• CPC Class Codes: G06F 21/554 involving event detection and direct action
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002

Abstract

Network security is enhanced in a multi-tenant database network environment using a query plan detection module to continually poll the database system to locate and raise an alert for suspect query plans. Security also can be enhanced using a firewall system sitting between the application servers and the client systems that records user and organization information for each client request received, compares this with information included in a response from an application server, and verifies that the response is being sent to the appropriate user. Security also can be enhanced using a client-side firewall system with logic executing on the client system that verifies whether a response from an application server is being sent to the appropriate user system by comparing user and organization id information stored at the client with similar information in the response.

Claims

1. A system for securing customer data in a multi-tenant environment, the system comprising:

one or more processors configured to;

monitor query plans of a multi-tenant database system to determine whether any query plans may be at least one of;

a query plan that should never occur in a multi-tenant database system or a query plan that should only occur in a small number of identified circumstances in a multi-tenant database system; and

take an action to secure customer data in the multi-tenant environment in the event that a query plan is determined to be suspect, wherein determining whether the query plan is suspect includes determining whether the query plan satisfies one or more first criteria, wherein the first criteria includes at least one of;

a query plan that should never occur in a multi-tenant database system or a query plan that should only occur in a small number of identified circumstances in a multi-tenant database system;

determine whether the suspect query plan satisfies one or more second criteria, the second criteria including whether the suspect query plan is a member of an exception class of suspect query plans;

permit the suspect query plan to be executed without raising an alert when the suspect query plan is found to satisfy the second criteria; and

raise an alert when the suspect query plan does not satisfy the second criteria.

2. The system of claim 1, further comprising:

the database system to store data for each of multiple tenants;

an application server communicably coupled to the database system and to a network, the application server including a processor and memory, the application server to provide network access to the database system for each of the multiple tenants,

wherein the application server is adapted to generate queries in response to requests from the tenants and to send the queries to the database system, and wherein the database system is adapted to generate one or more query plans from one or more queries received from the application server, a query plan being used to access data for one or more requests from a tenant; and

a query plan detection module adapted to;

poll the database system for one or more query plans that the database system has generated,

receive the query plans from the database system,

analyze the query plans received from the database system to determine whether a query plan was likely generated in error, and

when the query plan is determined to likely be generated in error, identify the query plan as suspect of an error in the database system.

3. A system according to claim 2, wherein the query plan detection module prevents execution of a suspect query plan.

4. A system according to claim 2, wherein the query plan detection module logs query plan information if a query plan is suspect.

5. A system according to claim 2, wherein the query plan detection module runs during production and development.

6. A system according to claim 2, wherein the query plan detection module determines that a query plan is suspect when the query plan includes a merge join Cartesian that reads all the data from two tables into a memory.

7. A system according to claim 2, wherein the data of each tenant is stored in a respective partition of the database, wherein the query plan detection module determines that a query plan is suspect when the query plan includes a partition hash all that reads an entire partition into memory.

8. A system according to claim 2, wherein the query plan detection module determines that a query plan is suspect when the query plan includes a query that is missing a filter for a tenant.

9. A system according to claim 2, wherein the query plan detection module performs the polling on a periodic basis.

10. A system according to claim 2, wherein a query plan is generated in error when it is not consistent with access rules that specify which data is accessible to a user or tenant of the multi-tenant database system.

11. A system according to claim 2, wherein the query plan detection module runs independently of the database system.

12. A system according to claim 1, wherein an exception is where the query plan is executing system housekeeping tasks.

13. The system of claim 1, wherein raising an alert includes preventing the particular query plan from proceeding.

14. A method for securing customer data in a multi-tenant environment, comprising:

monitoring query plans of a multi-tenant database system to determine whether any query plans may be at least one of;

a query plan that should never occur in a multi-tenant database system or a query plan that should only occur in a small number of identified circumstances in a multi-tenant database system; and

taking an action to secure customer data in the multi-tenant environment in the event that a query plan is determined to be suspect, wherein determining whether the query plan is suspect includes determining whether the query plan satisfies one or more first criteria, wherein the first criteria includes at least one of;

a query plan that should never occur in a multi-tenant database system or a query plan that should only occur in a small number of identified circumstances in a multi-tenant database system;

determining whether the suspect query plan satisfies one or more second criteria, the second criteria including whether the suspect query plan is a member of an exception class of suspect query plans;

permitting the suspect query plan to be executed without raising an alert when the suspect query plan is found to satisfy the second criteria; and

raising an alert when the suspect query plan does not satisfy the second criteria.

15. The method of claim 14,

if the suspect query plan does not satisfy the second criteria, further comprising:

at least one selected from a group consisting of logging an audit message, discarding the query plan, and postponing execution of the query plan.

16. The method of claim 14, further comprising:

transmitting a first code that when executed causes one or more processors to;

poll the multi-tenant database system for one or more query plans that the multi-tenant database system has generated from one or more queries, a query plan being used to access data for one or more requests from a tenant;

receive the query plans from the multi-tenant database system; and

determine whether any query plans are suspect by analyzing the query plans to determine whether a query plan was likely generated in error; and

transmitting a second code that when executed causes one or more processors to take an action to secure customer data in the multi-tenant environment in the event that a query plan is determined to be suspect.

17. The method of claim 16, wherein the first code determines that a query plan is suspect when the query plan includes a merge join Cartesian that reads all the data from two tables into a memory.

18. The method of claim 16, wherein the data of each tenant is stored in a respective partition of the database, wherein the first code determines that a query plan is suspect when the query plan includes a partition hash all that reads an entire partition into memory.

19. The method of claim 16, wherein the first code determines that a query plan is suspect when the query plan includes a query that is missing a filter for a tenant.

20. The method of claim 14, wherein an exception is where the particular query plan is executing system housekeeping tasks.

21. The method of claim 14, wherein raising an alert includes preventing the particular query plan from proceeding.