Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
This might be more appropriate for the UX.SE site. –  user25791 Oct 11 '11 at 13:20
    
I wasn't sure which site it belonged in. I felt it was more technical side than user side. –  Mike Wills Oct 11 '11 at 13:33
2  
@MikeWills - If you cannot think of a single reason that it should be on the internet, then make it so you can only access it from the local network, of course you should do EVERYTHING you would do if it was accessible from the internet. Be sure you authenticate and logged all access to this admin website. –  Ramhound Oct 11 '11 at 15:52

5 Answers 5

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.

share|improve this answer

@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.

share|improve this answer
    
This would be basic for payment troubleshooting and then exporting the previous day's transactions in case of problems with the automated system. –  Mike Wills Oct 11 '11 at 14:11
    
Do you log customer data? Or just information about a particular order (i.e. items bought and their prices). –  AndrewC Oct 11 '11 at 14:13
    
Customer data is billing contact (address, email, phone). That is all. –  Mike Wills Oct 11 '11 at 14:32

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.

share|improve this answer
    
Hmm... we'll have to research what we can and can't store then. –  Mike Wills Oct 11 '11 at 14:09
    
+1 for mentioning PCI compliance, though this of course depends on the type of data that he is viewing / storing in this backend. –  AndrewC Oct 11 '11 at 14:09
    
@MikeWills I think as long as you aren't logging ANY information the user passes for a credit card transaction then you are probably fine. You are allowed to store the transaction token however. If you have doubts about this then try just calling your payment processor. They were very helpful in providing internal scanning tools and other assistance to help us meet PCI compliance. –  maple_shaft Oct 11 '11 at 14:19
    
The only identifying information in that table is the Order Id and Transaction Id. No actual credit card information. We don't even store the last 4 digits of the CC number. We then log the customer name and contact info (address, email, phone) for reporting purposes to bring that information internal for our financial systems. We use First Data. What they return back in their web service is what we store. Saving us from looking up that information in their web portal and on our side to see what went wrong. Hopefully. –  Mike Wills Oct 11 '11 at 14:30
1  
From day 1 when we started eCommerce, we set the rule. "We do not store credit card numbers." –  Mike Wills Oct 11 '11 at 16:04

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.

share|improve this answer

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.

share|improve this answer
    
I updated the question for some more details. –  Mike Wills Oct 11 '11 at 13:32
    
True, my other concern is those that explore and how to better hide the admin. But moving it internal would fix that. –  Mike Wills Oct 11 '11 at 13:38
2  
@Mike Wills Security by obscurity isn't obscurity. Who cares who can find the admin tools, as long as they can't authenticate as an admin user and use the tools. –  Thomas Owens Oct 11 '11 at 15:25
    
@ThomasOwens Good point. It's just come to the fore in the security community. Have you read about this whitepaper refuting Kerckhoffs Principle written by a Royal Holloway University Professor: theregister.co.uk/2011/10/05/security_by_obscurity ? –  StuperUser Oct 11 '11 at 15:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.