I need to allow an outside company to be able to pull some info from an Informix database on a Red Hat server on our LAN.

For trusted connections to the Informix DB, i.e., other machines on our LAN, we use Windows and ODBC.

Creating the port forward rule on our firewall is no problem as far as directing the connection from the IP of the outside company's server to the proper port on our inside server.

I've been told by the company that supports our REHL server and Informix DB that they can create a user/password for this outside company to use in ODBC such that they can only access the necessary tables in the DB, but when I press them for assurances that this outside company won't be able to do anything other than read those tables, i.e, that once they are connected to our inside server they can't potentially do things we don't want them to, I can't get any level of assurance whatsoever. I'm trying to get some measure of how much risk we'd be exposing ourselves to, and if there's anything that can be done to mitigate the risk of allowing them to establish said ODBC connection.

An alternative to allowing ODBC would be REST APIs that provide a response in JSON, I'm told by the company wanting access to the DB. Our support company will provide no assistance with APIs, and I'm pretty much in the dark about what would be involved in that. Would it require a major install on the same server as the Informix DB, or possibly a new server in order to provide the APIs? I'd be willing to consider a setting up a cloud server on Google Cloud Platform, Amazon, or Azure, if that made sense.

Any insights would be appreciated.

You cant port them through one of the other machines on the network instead of the server and create a ODBC read only user account for them?

I doubt that this will be very helpful, as I've not had any experience with Informix databases since IBM acquired them. However, I'm somewhat database savvy, so I think what I'm about to say is true, in a generic sense.

My expertise is in Oracle, if that makes any difference. I'm using concepts (and perhaps terms) that are used in Oracle database deployments.

There are several steps to grant access to a database. These are

• Create the User/Password, apply work spaces, quotas, password policies, etc.
• Create or apply roles to the user.
• Grant actual connection capability
• Define schema/table access and CRUD (create, read, update, delete) privileges.

ODBC is just the driver that connects software to the database. The application is configured to work through the ODBC driver to transact with the database. The database itself enforces access privileges and rules. The granularity of ACI (access control information) can be applied to the table level, and in some cases even to the column level (e.g., you can see payroll data but not salary information within the payroll table).

No database worth its salt allows access to tables, views and objects (system or user) without specifically being granted rights.

Bottom line: You should be able to create a specific service account within your Informix database, grant and deny access to whatever objects within it you wish, and allow your outside company to access only the data you want them to.

Typically, you create security to deny any/all access to the db/tables, then explicit allow groups for all your internal folks, and another group for specific tables and put the outside company user(s) in that group, effectivly denyine them any access to anything but those allowed tables.

Sometimes db/tables etc. are granted to permissive access because it is "easier" and "sovles" connectivity issues, and then connecting outside sources, the inherent trust leaves one's system vulnberable.

Not as bad as years ago, but still a problem, hence the many news reports of massive db comprmises.

Broad brushing, but hope that helps.

We never grant select permissions on db tables, execute only. That means that they will only be able to stored procedures. You will need to write the procs that they will need but their access will be very limited.

IANADBA, but if I read what you're saying correctly, you're trying to port forward traffic from your firewall such that it will enable direct access to the database on this server?

I can come up with about eleventy billion reasons why I wouldn't do that.


If(misunderstood){
disregard;
}

quote:

Originally posted by exx1976:
IANADBA, but if I read what you're saying correctly, you're trying to port forward traffic from your firewall such that it will enable direct access to the database on this server?

I can come up with about eleventy billion reasons why I wouldn't do that.


If(misunderstood){
disregard;
}

That is the request, yes. It would be restricted to a specific inbound IP address, but if it can't be done safely, we'll have to find another way.

VPN an option? That can solve remote access problem. Apply rules to VPN connection to only allow access to the DB.

My exp isn't informix but you should be able to create a user that has specific permissions to only retrieve and not alter data.