Apparatus and method for providing a secure database access The application is related to providing a secure database ac ^¬ cess from a client device located in a first zone to a data ^¬ base located in a second zone which is outside of the first zone using a traditional database access application program ^¬ ming interface providing only weak authentication means.

Databases and data warehouses usually contain valuable busi ^¬ ness assets and shall thus be deployed in backend network zones in order to protect them from attacks from outside. In this case access is allowed indirectly through front-end ap- plications, i.e. via representational state transfer applica ^¬ tion protocol interfaces, in short REST APIs, e.g. the hyper ^¬ text transport protocol http, which can be protected by state-of-the-art strong authentication mechanism, like e.g. smartcard-based authentication.

Access authentication to websites is also discussed in US 2001/045451 Al which discloses a method for token based user access authentication enabling secure user access to a web server, however not particularly to a database. The work- station of the user is mutually authenticated with the access server using a digital certificate which is stored on a to ^¬ ken, e.g. a smart card. The certificate is validated against a database of the access server and a secure connection can be established with the web server.

Further on, CN101895513A discloses a log-in authentication system for a service website by using a subscriber identity module card which stores subscriber names and passwords re ^¬ ducing the risk that ID information is stolen by Trojans.

Open database connectivity, in short ODBC, is a well known and widely used traditional standard application programming interface, in short API, for accessing database management systems, which was developed during the early 1990 and became a widely used interface to access databases. Similar Java da ^¬ tabase connectivity, in short JDBC, is an application proto ^¬ col interface for the programming language Java, which de ^¬ fines how a client may access a database. It provides methods to query and update data in a database, especially relational databases like Structured Query Language (SQL) databases. A JDBC-to-ODBC-bridge enables connections to any ODBC- accessible data source in the Java virtual machine host envi ^¬ ronment. ODBC accomplishes data base management system inde ^¬ pendence by using an ODBC-driver as a translation layer be ^¬ tween the application and the database management system. An application uses ODBC-functions through an ODBC driver manag ^¬ er with which it is linked and the driver passes e.g. a query to the database management system. An ODBC driver can provide a standard set of functions for the application using and im ^¬ plementing database management systems specific functionali ^¬ ty. An application that can use ODBC is referred to as "ODBC- compliant " .

Direct ODBC/JDBC access to databases or data warehouses jeop ^¬ ardizes the security of databases as ODBC/JDBC only supports weak authentication based on username and password. Neverthe ^¬ less, direct ODBC/JDBC access is sometimes required for vari ^¬ ous reasons. E.g. data scientists use ODBC/JDBC and are not willing to change their work approach. Also legacy applica ^¬ tions usually connect to data sources via ODBC/JDBC. Switch ^¬ ing e.g. to http in order to connect to backend databases via a REST application program interface would require implemen ^¬ tation efforts which require time and money. Moreover, in many cases, applications cannot be simply redesigned because they are e.g. too old or in productive use.

Further on, traditional standard ODBC/JDBC drivers require database credentials, said already mentioned username and password, to be stored on client side. If an attacker gets access to these credentials, e.g. by an attack of the client device/application or via social engineering, he or she gets access to the database or data warehouse located in backend on a backend side. A further drawback of a traditional

ODBC/JDBC data base access lies in that a communication be ^¬ tween client and database is not always encrypted. If some of the clients do not support encryption, it might not be possi ^¬ ble to activate and deactivate encryption on backend side in a flexible way. In such a case protection of data in transit depends on the client and cannot be enforced on backend side. To provide a strong authentication to access the database proprietary solutions exist, but have a very limited area for application. Also applications with REST interfaces can be realized in order to access databases located in backend us ^¬ ing authentication standards for http communication like openID connect or security assertion markup language, SAML . However, such application protocol interfaces require pro ^¬ grammatic changes of the sequential query language SQL cli ^¬ ents, as communication takes place over http and not via ODBC/JDBC protocol messages.

Therefore it is the object of the present application to pro ^¬ vide a method or means to access a remote database located in a zone without direct control by traditional database access application programming interface like JDBC/ODBC in a secure way, especially using a strong authentication approach.

This object is solved by a method, an apparatus and a comput ^¬ er program product according to the independent claims.

Preferred embodiments are set out in the dependent claims.

The first aspect of the invention provides a method for a se ^¬ cure database access from an application program implemented on a client device located in a first zone to a database lo ^¬ cated in a second zone, which is outside the first zone, ap- plying an Open Database Connectivity ODBC or a JAVA Database Connectivity JDBC application programming interface as a tra ^¬ ditional database access application programming interface. In a first method step a database access driver is implement- ed on the client device and a database access proxy is imple ^¬ mented on a second zone which is connected to the database. In further steps an authentication of a user of the applica ^¬ tion program is performed via an authentication agent located on the database access driver and an authentication server. Then the authentication server delivers a credential to the database access driver in case of a successful authentica ^¬ tion. Then the credential is sent from the database access driver to the database access proxy. Database access will be granted to the application program, if the credential is ac ^¬ cepted by the database access proxy.

Implementing a database access driver on a client device and implementing an access protocol proxy connected to the data- base in the second zone allows the access of the database via a traditional database access application programming inter ^¬ face providing weak authentication. An authentication agent implemented on the database access driver which communicates to an external authentication server, separates an authenti- cation process from the database access process between data ^¬ base access driver and the database access proxy. The authen ^¬ tication performed between the authentication agent and the authentication server is preferably a strong authentication using e.g. certificates and /or integrating means of an Iden- tity and Access Management System. In addition the credential delivered by the authentication can be used to set up a se ^¬ cure connection between the client device and the database access proxy and preferably further to the database. There ^¬ fore a more sophisticated authentication of the client device or more precise the user of the application on the client de ^¬ vice can be performed without the drawbacks mentioned before and an encrypted connection can be established.

The credential can be an authentication token or an identity token or an authentication object.

In the further description the expression "access driver" is used as a synonym for "database access driver". The expres- sion "access proxy" is used as a synonym for "database access proxy" .

The user of an application program can be a person or a tech- nical device. The expression "first zone" is used synonymous ^¬ ly for "client zone", and "second zone" is used synonymously for "backend zone".

The database access application programming interface is a Java database connection JDBC or Open database connection ODBC, especially a JDBC Type 3.

This JDBC/ODBC API is a traditional, well known and often used to access databases. No programmatic changes of legacy applications are needed.

In a preferable embodiment of the method, the credential is a cryptographically secured credential. Using a cryptographically secured credential enables to vali ^¬ date the integrity of the credential and to authenticate the sender, i.e. the authentication server.

In a preferred embodiment the database access application programming interface messages are transmitted via a secure connection between the database access driver and the data ^¬ base access proxy.

The set up of a secure connection between the database access driver and the database access proxy can be performed using the provided credential e.g. to set up a secure connection according to the transport layer security TLS protocol.

In a further preferred embodiment the authentication server is located in the second zone or in a third zone other than the first or second zone, especially a central zone. The authentication server preferably provides an identity and access management service, which is available on the market based on state of the art standards like openID Connect /open authentication OAuth or according to security assertion markup language SAML . Such an authentication server can be deployed locally in the secure second zone or centrally or on-premises or in a cloud.

In a preferred embodiment the database access protocol inter- face is performed by at least one vendor-specific driver in the database access proxy.

With the use of these vendor-specific drivers no proprietary solution for specific kind of databases or data warehouses is required.

In a further preferable embodiment the access rights of a us ^¬ er requesting access to the database are checked on the data ^¬ base access proxy. This checking of the access rights on the access proxy does not request the transfer of any user access rights via the access driver and proxy between different zones of security.

In a further embodiment access rights of the user of the ap- plication program requesting access to the database are stored in the database access proxy and the access rights are updated by the authentication server.

The access rights of a user of the application program re- questing access to the database are administrated on the au ^¬ thentication server, especially in a repository connected to the authentication server.

Authentication servers usually provide access to a repository storing access rights. So this repository can be reused to store the database access rights and no separate unit for storing the access rights is required. Alternatively access rights for entire user groups can be provided by the database itself. In this case the database requires information on the user group a user is belonging to.

In a preferred embodiment the application program is regis- tered at the authentication server during application deploy ^¬ ment on the client device.

The application program which uses the authentication agent is handled as additional application for which an identity and access management is provided by an identity and access management system.

In a preferable embodiment operations performed by the data ^¬ base access proxy are logged by a logging unit.

This enables monitoring by logging requests at the access proxy without depending on logging functionalities of the da ^¬ tabase or data warehouse.

In a preferred embodiment data is transmitted on a secure se- cond connection between the access proxy and the database.

This secure second connection provides also the last section of the connection to be encrypted and therefore protected from manipulation.

A further aspect of the present invention is a system provid ^¬ ing a secure database access from an application program im ^¬ plemented on a client device in a first zone to a database located in a second zone different from the first zone, ap- plying an Open Database Connectivity ODBC or a JAVA Database Connectivity JDBC application programming Interface as a tra ^¬ ditional database access application programming interface, comprising

- a database access protocol interface driver including an authentication agent, the database access driver being imple ^¬ mented on the client device in the first zone,

- a database access proxy being connected to a database and located in the second zone, wherein the database access protocol driver and the database access proxy are implemented for

Performing an authentication of a user of an applica ^¬ tion program via an authentication agent located on the data- base access protocol interface driver and an authentication server,

Delivering a credential from the authentication server to the database access protocol interface driver in case of a successful authentication,

- Sending the credential from the database access driver to the database access proxy,

and

Enabling database access to the user of the application program if the credential is accepted by the database access proxy.

The access driver and access proxy are implemented to perform a method according the previously described method. Furthermore, a computer program product is suggested which is loadable in the internal memory of a digital computer com ^¬ prising software code portions for performing the steps of the method as described herein and when said product is run on a computer. The computer program product may be in the form of a USB-stick, a CD-ROM, a DVD or a downloadable file which can be transferred wireless or wired via communication network .

The invention will be explained in more detail by reference to the accompanying figures.

Figure 1 shows a schematic view of network scenario applying the inventive system for accessing a database; Figure 2 shows a flow diagram of an embodiment of the in ^¬ ventive method; Figure 3 shows a sequence diagram for an embodiment of the inventive method authenticating a user of a appli ^¬ cation implemented on the client device; and Figure 4 shows a sequence diagram of an embodiment of an in ^¬ ventive database query after authentication accord ^¬ ing to Figure 3.

Figure 1 shows a network scenario in which an application performs a database access using a database access protocol interface e.g. to query data from a database or data ware ^¬ house according the inventive method and using an embodiment of the inventive system. The application 14 is implemented on a client device 11 located in a first zone 10, e.g. a comput- er located in a private or public network. A database 23 providing data is located in a second zone 20, which is phys ^¬ ically separated from the client device 11 in zone 10. The database 23 may comprise several logically separate parti ^¬ tions or several physically separated databases as shown in Figure 1. The database 23 is located in a backend service zone comprising of servers providing various services and connected via external connections, e.g. 30 and 31, to the first zone 10. In the further description the first zone com ^¬ prising the client device is also called client zone, the se- cond zone 20 comprising an access protocol proxy 22 and the database is also called backend zone.

Using traditional database access application programming in ^¬ terfaces, in short database called access APIs, like open da- tabase connectivity ODBC or Java database connectivity proto ^¬ cols JDBC, in such a scenario, where a client device 11 and database 23 are located remotely from each other and connect ^¬ ed via external connections 30, shows following drawbacks: Security functions of traditional database access APIs, e.g. ODBC JDBC, are based on security information consisting of username and password pair. An ODBC/JDBC driver located in a client device 11 requires such security information to be stored on the client's side. If an attacker gets access to these information pairs, e.g. by an attack of the client de ^¬ vice 11, the attacker gets access to the database 23. Further on, an encryption of the data communication from the database 23 to the client device 11 cannot be enforced by the backend side 20. If the client device 11 does not support en ^¬ cryption it might not be possible to activate and deactivate encryption on the backend side 20 in a flexible way.

To use a traditional database access API and support stronger authentication using more sophisticated credentials and cryp ^¬ tographic functions an access driver 12 is implemented on the client device 11 in the first zone. In the second zone 20 a secure access proxy 22 is implemented on the server's side in a second zone. Access driver 12 and access proxy 22 are both e.g. JDBC Type 3 client and server components. The access proxy 22 communicates with vendor-specific access drivers 24 which provide the access to the database 23. The access proxy 22 and vendor-specific access drivers 24 are preferably im ^¬ plemented on one device, e.g. a backend server 26. A database 23 can comprise several database components as shown or may comprise only one database. The database can also be a data warehouse comprising data from different sources and being used for reporting and data analysis.

To provide authentication by more sophisticated authentica ^¬ tion methods, e.g. based on a public key infrastructure using certificates an authentication agent 13 is implemented in the access driver 12 on the client side which communicates with an authentication server 21 providing strong authentication means, especially identity and access management functions. The authentication server 21 can be located in the second zone 20, but it can also be located in a third zone, e.g. a central zone, which is different from the first zone 10 and the second zone 20. The authentication server 21 is connected to a repository 25 in which the database roles for users reg ^¬ istered by the authentication server 21 are stored. The au- thentication server preferably provides identity and access management services to protect the access to the secure JDBC driver 12 on the client side 10. These are presentation- oriented and service-oriented web applications that implement the complex identification and access management processing tasks in the authentication server 21 such as identity man ^¬ agement, initial authentication, facilitation of single-sign- on and integration of enterprise security infrastructure. Such identification and access management, in short IAM, ser- vices are available on the market based on state-of-the-art standards like openID Connect /OAuth or SAML . In such ser ^¬ vices, strong authentication can be implemented as part of the solution, e.g. based on a native smartcard driver or one ^¬ time-passwords or it can integrate external identity provid- ers, e.g. entitlement services.

The access driver 12 and access proxy 22 use e.g. JDBC type 3 client and server components communicating via http protocol. The access proxy 22 shall only setup a connection 30 to the access driver 12, if the access proxy 22 receives a valid credential, e.g. an IAM-token generated by the IAM services after successful authentication of the user. If the user of the application 14 has the required role to access the data ^¬ base 23 the access proxy 22 establishes a native access con- nection, e.g. a JDBC connection, to the database 23 and for ^¬ wards queries to the database 23. The access proxy 22 uses vendor-specific JDBC drivers 26 and does not need to imple ^¬ ment access functionalities itself. The flow diagram in figure 2 shows the main method steps to provide a secure database access from a client device 11, which is located in a first zone 10 to a database 23 located in the second zone 20 which is outside the first zone. As a first step 1 an access driver 12 is implemented on the client device 11 and an access proxy 22 is implemented in the second zone wherein the access proxy 22 is connected to the database 23. The user of an application 14 which is implemented on said client device 11 wants to access data on the database 23 requests the access driver 12 to open an access connection. In step 2 an authentication of a user of the application 14 is performed via an authentication agent 13 located on the access driver 12 and the authentication server 21. As already mentioned before, the authentication server 21 provides iden ^¬ tity and access management tasks.

In case of a successful authentication a credential from the authentication server 21 is delivered to the access driver 12 in step 3. A credential can be an authentication token or an identity token or an authentication object, e.g. a digital certificate or a onetime password. Preferably the credential is cryptographically secured, e.g. it is digitally signed or hashed by a key of a symmetric or asymmetric cryptographic function. The user of the application 14 is allowed to access the database, if the credential is accepted by the access protocol proxy 22, see step 4.

The credential can already be used to set up a secure connec- tion 30 between the access driver 12 and the access proxy 22 e.g. by establishing a connection according a transport layer security protocol TLS . The connection between the authentica ^¬ tion agent 13 and the authentication server 21 can be estab ^¬ lished by a REST application protocol interface e.g. using an http connection.

Figure 3 shows the authentication step 2 performed between an authentication agent 13 in the access driver 12 in the first zone 10 and an authentication server 21 located in the second zone 20. During the implementation the application 14 regis ^¬ ters at the authentication server 21 in order to enable the authentication server 21 to provide IAM services for the ap ^¬ plication 14. The authentication agent 13 needs to be configured to input security data e.g. by registering a card reader operation system to input identification information of the user of the application. A user of the application 14 and in consequence also of the database 23 can be a human or a technical device. This action is depicted in Figure 3 by the arrow labeled with the reference sign 100. On the backend side 20 user accounts, group assignments, and role assigned to the user are synchro- nized, e.g. periodically, between the authentication server 21 and the access proxy 22, see reference sign 110. User ac ^¬ counts, group assignments, and roles of each user accessing the database 23 can be administrated and stored in the repos ^¬ itory 25 and provided to the authentication server 21. Such an IAM repository 25 can be implemented as an LDAP server, or it could also be a database of different structure.

In the depicted example it is assumed that the user identi ^¬ fies itself by a credential, e.g. a digital user certificate UCert, stored on a smartcard and secured by a password or personal identification number PIN. On a access request sent from an application 14 to the access protocol driver 12 the user is requested to input a password to provide access to the user certificate stored in the smartcard. A handshake is performed between authentication agent 13 using information provided by the smartcard and the authentication server 21. This is indicated in figure 3 by arrow 120. Subsequently a login request including the user certificate UCert is sent from the authentication agent 13 to the authentication server 21 which responds sending a session identifier S_ID used to set up a secure connection for database access. Further an authorization request is sent from the authentication agent 13 to the authentication server 21. The authentication server 21 responds by sending a credential Cred and roles of the us- er to the authentication agent who passes them forward to the application protocol driver 12. The access driver 12 informs the application 14 by a response message, see Access Resp in Figure 3, about a setup of a JDBC/ODBC connection. Figure 4 illustrates a database access by the application 14 to the database 23 after the connection has been established as described in Figure 3. The application 14 requests to exe ^¬ cute a database query to the access driver 12. The access driver 12 sends an SQL query and the credential Cred in a http request to the access proxy 22. The access proxy 22 checks the validity of the credential Cred and the user' s role indicated. Optionally the access request is logged by storing the sent message in a logging unit 27. According to the access rights and role of the user, the request to exe ^¬ cute the SQL query is sent from the access proxy 21 to the database 23. The result of the query, e.g. retrieved data, is delivered from the database 23 to the access proxy 22. The data may optionally be serialized and zipped, refer to 210, and forwarded to the access driver 12 on the client device 14 in the first zone 10. Here the data is unzipped and de ^¬ serialized, see 220, and forwarded as query result to the ap ^¬ plication 14.

The described method and system provides high protection of databases or data warehouses by strong authentication of hu ^¬ man or technical users. No database security credentials are required to be stored on the client side. Further on the data transferred between the second zone 20 and the first zone 10 is protected by establishing a secure connection, e.g. by en ^¬ cryption of the communication 30, between the access driver 12 and the access proxy 21. In case the database 23 does not support encrypted communication, unencrypted communication only takes place locally in the second zone 20 between ven ^¬ dor-specific drivers 26 and the database 23 on the connec ^¬ tions 28. With this solution legacy applications using tradi ^¬ tional database access APIs like JDBC/ODBC do not require any programmatic change as only the access driver 12 is needed on the client side. The access driver 12 just replaces the ven ^¬ dor-specific JDBC driver used previously by the application. The access proxy 22 provides better monitoring by logging da ^¬ tabase requests without depending on logging functionalities of the database.

The invention is not limited to the described examples. The invention also comprises all combinations of any of the de ^¬ scribed or depicted features.