none
Best practice for external but secure access to internal data? RRS feed

  • Question

  • We need external customers/vendors/partners to access some of our company data (view/add/edit).  It’s not so easy as to segment out those databases/tables/records from other existing (and put separate database(s) in the DMZ where our server is).  Our current solution is to have a 1433 hole from web server into our database server.  The user credentials are not in any sort of web.config but rather compiled in our DLLs, and that SQL login has read/write access to a very limited number of databases.

    Our security group says this is still not secure, but how else are we to do it?  Even if a web service, there still has to be a hole in somewhere.  Any standard best practice for this?

    Thanks.
    Monday, April 20, 2015 11:35 PM

Answers

  • Security is mainly about mitigation rather than 100% secure, "We have unknown unknowns". The component needs to talk to SQL Server. You could continue to use http to talk to SQL Server, perhaps even get SOAP Transactions working but personally I'd have more worries about using such a 'less trodden' path since that is exactly the areas where more security problems are discovered. I don't know about your specific design issues so there might be even more ways to mitigate the risk but in general you're using a DMZ as a decent way to mitigate risk. I would recommend asking your security team what they'd deem acceptable.

    http://pauliom.wordpress.com

    • Marked as answer by fiverc Saturday, April 25, 2015 12:24 PM
    Thursday, April 23, 2015 7:59 AM

All replies

  • You could restrict the security access to the data via stored procedures and/or views. Then provide access to those projections from a component in the DMZ. If you can provide NT Authentication to your customers then use that, otherwise use some type of forms authentication to that component. Therefore only authenticated users gain access to the component, and the component only has restricted access to the data.


    http://pauliom.wordpress.com

    Tuesday, April 21, 2015 7:18 AM
  • We use Forms Authentication and the underlying SQL login has restricted access to only certain things (we don't use an underlying domain login -- although we could -- because our security guys say it makes the ACL vulnerable).

    But even with all we're doing, they say it's still not secure enough.  I'm not sure what else we're supposed to do.  I would assume it's normal to have an extranet get to internal data.

    Tuesday, April 21, 2015 2:58 PM
  • What are they saying isn't secure?

    http://pauliom.wordpress.com

    Wednesday, April 22, 2015 8:17 AM
  • That there's a hole though our firewall; that if somehow a hacker could take control of our web server, that somehow they could get through the hole and do damage.  I don't see how but then I don't know all the ways hackers can do things.
    Wednesday, April 22, 2015 4:19 PM
  • Security is mainly about mitigation rather than 100% secure, "We have unknown unknowns". The component needs to talk to SQL Server. You could continue to use http to talk to SQL Server, perhaps even get SOAP Transactions working but personally I'd have more worries about using such a 'less trodden' path since that is exactly the areas where more security problems are discovered. I don't know about your specific design issues so there might be even more ways to mitigate the risk but in general you're using a DMZ as a decent way to mitigate risk. I would recommend asking your security team what they'd deem acceptable.

    http://pauliom.wordpress.com

    • Marked as answer by fiverc Saturday, April 25, 2015 12:24 PM
    Thursday, April 23, 2015 7:59 AM