Can URL redirect be used to restrict access to ServiceNow based upon IP Address and/or domain?

[curtisrowell]

I have a client who is worried about someone hacking the ServiceNow network and gaining access to the server instances.

I was going to suggest they turn on IP Address Access Control; however, they are installing the HR module and will need to have this available to dependents who are on the public cloud.

Is it possible to script a URL redirect such that if a browser request is coming from the public cloud, it is automatically forwarded to the HR Portal or blocked and if they are coming from a customer IP address, allow access to the requested portal.

[Jeff Currier]

As to the "gap", it would be good to understand their specific concern(s).  Then we can address those.  Keeping in mind that if they want anyone to log in via the public internet, as opposed to their company intranet or VPN, they will have some form of authentication exposed to the internet.  

Another idea might be to collaborate with the ServiceNow Sales consultant assigned to that client.  He/She may be able to pull additional information from the field security team to help this client or join you in meeting with the client to discuss options.

[James209]

If the main concern is a custom probe the best solution would be a series of notifications and reports which will allow management to see all the existing probes. Whatever is built though can be circumvented - this applies to any system, ServiceNow or otherwise - and does not replace good security practices of frequent password changes and restricted access on the production instance. It is possible to request ServiceNow specifically lock-down a custom script or notification (they will put the 'maint' role against it. So anything you custom build for notification or reporting can be guarded against changes. It will, however, prevent you from making the changes as well.

The main issue I see you having is with the HR module and allowing access there, from IPs but preventing it on other areas. Unfortunately, that's not something that's easy because IP Access control is system not component specific; which is really how it should be. If HR requires a truly open portal, but the remainder of the platform requires a locked down environment it would be best to separate the two instances. Have HR on its own, separated instance and create integration where required.