Should the admin interface of a public-facing webapp be accessible externally?

Question

I am working on an application right now that needs a way for employees to log in to the back-end of the public facing application for some basic reporting. If you were creating this, would you put the admin interface on the public side or on the intranet side?

Update: It is the back-end of our eCommerce application. I am logging all of the transactions with the CC processor (NOT the sent data, just the response from the processor) and the processed transactions to aide in us being able to troubleshoot when a customer has a problem. Kind of a one-stop-shop instead of looking up in multiple places. They should be in the office when doing this.

This is an ASP.NET MVC project if that matters.

Answer 1

It depends on where employees will be logging in from. Do they need to have access to this when they are out of the office? Do you have a company VPN? Do your employees ever work from home? How sensitive is the data?

Edit

So it seems basically that your backened will be accessed in your office and contains order information for an eCommerce system. Even though you don't log the information sent to the credit card provider, if you have no reason to access this data outside your company network (i.e. in the office) then I'd put it on the Intranet personally.

You never know if you'll need to log more [sensitive] information in future after client requests or new features you add.

That's not to say that making it internet facing is unsafe though, because you can of course secure it on the internet as well, but the risk is always going to be slightly greater.

Answer 2

I've done this both ways.

For a CMS system, admins could access it from anywhere. This was essential for marketing and sales people who needed to update press releases and so forth on the road, often from mobile devices.

For an ecommerce system, all admin was on the internal office network, only accessible remotely by VPN secured by RSA SecurID. These admin apps were desktop apps (older ones WinForms, newer ones WPF) although they did use some of the same web service based business objects that the consumer ecommerce website used.

Answer 3

@AndyC has some good points about accessibility.

Dig deeper on what the users expect from the site. If they're going to be running reports and wanting to dump things into a spreadsheet, make sure you can get these things to even work on a website and with how much trouble.

For basic viewing and data entry, keep it on the web.

Answer 4

Assuming you never have bug and never making an error….

Now in the real world,

• As you don’t need access over the web, don’t provide it, just use a VPN when working from home.

• Ideally you web facing machines will only have rights to access the stored procedures (or tables) it needs, so limiting the damage if (when) it is broken into.

• Your internal admin app (internet or even WPF/Winforms) can run on a different machine with a database connections that have more rights.

Answer 5

SSL over HTTP is a given, I shouldn't have to reiterate the importance of that. Furthermore I am assuming you have a strong authentication scheme (mandatory strong passwords, account lockout after so many failed attempts, etc...) Even if the page is hidden, security through obscurity is no security at all.

What you need to concern yourself with is the possibility of whether public facing accounts could have access to information from your payment processor and how that affects PCI compliance. PCI compliance is not just a standard that your payment processor is held to, there are certain security obligations on your end and making such functionality public-facing like you suggest may affect PCI compliance. Many payment processors require their merchants to be PCI compliant anymore and they may charge you additional fees if you are not.

On a side note I would like to add that you may be incompliant with PCI Standards just by logging transaction information with your payment processor.