How to implement security around company-wide web services

Question

A topic has recently appeared regarding the security of web services. Not necessarily the bits in WSE 3.0 that you might be thinking about, but more about providing services within the company.

For instance. We discussed the possibility of providing certain functions of an entire company through one or more endpoints of a web service. The problem boils down to who can access the web services. I see that they are available in three ways:

• On the website. This website may or may not impersonate a user accessing the site, so calls to the web service can be made as a real user, an IIS service account, or another service account that we may impersonate for other reasons.
• Batch program. Also works on the server, but usually works as a service account
• Windows application on the user's desktop, in this case the user credentials will be used

Now, in theory, it can leave web services open to everyone. Ignorance is bliss, right? But the problem is that if an attacker gains access to our network and discovers web services, he will have carte blanche for intellectual property. So open is not good.

We could block them using some complicated home scheme to check IP addresses, usernames, etc. But it looks like it will be an administrative nightmare.

Any thoughts? We throw a couple of ideas, but I wanted to see if anyone can solve this problem already.

thanks

Answer 1

At my company, we use X509 certificates with an encrypted signature. This provides maximum security for your service. To restrict access to your service, you can only allow public certificates of your customers. This, of course, means that your customers must also have their own certificates. If your customers do not have their own certificates, you can create your own using OpenSSL. I myself used this application and created legal certificates that can be used for encryption or a handshake. In addition, I believe that you can create your own policies for each of your customers and restrict access to your service functions using the policy attribute for each function (maybe a lie, but I think I came across this somewhere) . Hope this helps.

Answer 2

If you plan to open endpoints for internal use, this is one thing, but how many likely internal clients do you have?

If endpoints collect Excel spreadsheets or BI data cubes that need dynamic data and can be used by a wide range of people, then you will need to carefully consider security. Perhaps you could publish the daily generated API key to a prominent page on the corporate intranet - so that internal data users would have a slight inconvenience if they wanted to use endpoints, but this would not be an unpleasant task for serving IT professionals.

If the endpoints will be consumed by several custom applications, I would suggest tightly linking the security in the applications themselves (hardcoded in the configuration file and then encrypted). Thus, access can be widely used, but not widely known.

Obviously, allow only GET (and make sure that GETs are not hidden by POST or PUT) and document each endpoint for start control. If top management is satisfied with the risks of providing access to data, then this is really just a discussion about how you block it.