[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml-dev] Database data access control using XACML
BiTKOO provides database protection for SQL Server. We are actively developing the same functionality for Oracle, DB-2 and MySQL. Here is how DB-Wall protects SQL Server (SQL Server Azure, SQL Server 2005, SQL Server 2008, 2008-R2). SQL Server exposes a protocol called the Tabular Data Stream (TDS for short). Clients of any kind (DB-Client, ODBC, JDBC, etc.) communicate with the SQL Server database over TCP/IP using TDS. DB-Wall is essentially a TDS-Proxy. All traffic to the database is routed through DB-Wall. The actual SQL Server may be placed behind a physical firewall so that the only host allowed TCP/IP traffic to the database server is DB-Wall (physical separation). In addition, all user accounts may be removed from the database. Instead, a single account - the system identity for DB-Wall is used. Best practice is to use Windows Authentication, although SQL Authentication is supported as well. By isolating the database behind a firewall and/or removing/disabling all user identities in the database both logical and physical protection is achieved. Any calling process transmitting SQL commands communicates to DB-Wall "thinking" it is communicating to the SQL Server database directly. There are several ways to route all traffic to DB-Wall instead of the actual database. Some of the ways are listed below (without getting into pros/cons of each approach): Change the application's configuration file where the connection string resides. Point the connection string to the DB-Wall host instead of the database host. Change the database host IP address to a different IP address and assign the original IP address to the DB-Wall host. Change the client's HOSTS file. Change the DNS entry so that the database's name is pointing to the DB-Wall host IP address. Change the database IP port number and deploy DB-Wall on the same host as the database and assign the database's original IP to the DB-Wall instance. User identity is conveyed to DB-Wall in one of three ways: Windows (Kerberos) authentication token. SQL Server (username, password) authentication token. SQL Server comment (--) identity conveyance. Once DB-Wall infers the identity of the caller it retrieves the user’s applicable attributes through the Keystone context handler and parses the SQL to determine which resources the user is attempting to access and the type of access being requested (Read, Insert, Update, Delete, Execute). Artifacts include tables, views, stored procedures, functions, databases and database schemas. Within tables and views rows and columns may be protected. A very simple use case is described in English below: A user is allowed to view rows in the Customer table where the Customer.State == User.State. The user can only view the Balance column from the Customer table for customers where Customer.SalesRep == User.UserID. Of course, DB-Wall and Keystone supports much more complex use cases where the user’s attributes are inferred by complex operations such as querying other data sources such as databases (Oracle, DB-2, etc.) or web services. We see many cases where there’s a hierarchy and the rule is based on this hierarchy. Consider the following example: A user can view all customers where the sales rep reports up to the user but the user can only view the balance columns for those customers who are either directly assigned to the user or who are assigned to the user’s direct reports. The “secret sauce” of DB-Wall is its inference of database schema and its ability to very rapidly (2ms) parse any SQL query, no matter how complex and apply all the rules that will emit the appropriate SQL that is actually transmitted to the real database. Using DB-Wall there’s no need to retrieve a million records and then filter them out in-memory. DB-Wall uses the smarts and indexes of the database engine itself to perform incredibly fast. As the most simple, canonical example, consider the following original query: SELECT * FROM CUSTOMER There might be a DB-Wall rule that states that a user with a Department attribute == “Finance” can only see the Name, City, Balance columns. There might be another rule that states that a user with an attribute called Country == “USA” can see only customer with country equal to USA. Here’s the actually query that will get emitted by DB-Wall: Select Name, City, Balance from CUSTOMER where country = ‘USA’ Of course, I am making these samples easy. The rules are expressed in XACML 3.0 but the database doesn’t need to know anything about XACML because it speaks the language that it understands – SQL. When XACML policy enforcement is done as a SQL proxy, the performance is phenomenal. DB-Wall handles connection pooling, SSL from the client to itself and from itself to SQL Server. MARS (Multiple Active Result Sets). It supports any client, including the Entity Framework, WCF RIA services, SQL Server Management Studio as well as any DBClient, ODBC, JDBC based clients. DB-Wall can be deployed from the cloud to protect SQL Server Azure edition, or it can be deployed in the local data center. It is a very fast row, column and cell level protection mechanism that is very scalable. The added latency of any complex query is approx. 2ms! My wife is yelling at me to come eat. I will write more later. Doron Grinstein CEO BiTKOO 818-985-4700 Ext. 31 www.bitkoo.com -----Original Message----- Yes. BiTKOO has a database proxy called DB-Wall that modified inbound SQL requests based on xacml policy. I'll send you examples when I'm back in town. I'm on the road today. Doron Grinstein CEO BiTKOO On Aug 11, 2011, at 2:03 PM, "Security Developer" <security.developer22@gmail.com> wrote: > Hi all, > > Is it possible to control access to database data using XACML standard? If yes, could any body please provide the sample XACML policy and XACML request context. > > Thanks for your time. > > Best Regards --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]