Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1089
  • Last Modified:

Setting up an extranet

we are looking to set up an extranet using Sharepoint foundation 2010. We currently have a WSS 3.0 server as our intranet (will be upgraded to foundation 2010 soon), this server pulls information from our SQL server (sql 2008 express), and then people connected to the network can see this information using either laptops, pcs or blackberry's.

We now need to put this information that the sharepoint server is publishing on to an extranet so that it can be accessed from any connection. I have attached a screenshot of a simple network diagram that i have designed for how i believe we would have to set it up. However money is an issue and we need to make this as cheap as possible.

In the picture i have 2 different domains, internal and DMZ, these will be 2 different forests with a trust relationship.
There are 2 different SQL servers, the internal one will be a copy of SQL 2008 std, working as a distributor and publisher, pushing the information we need displayed to a copy of sql 2008 express on the DMZ. The sharepoint server on the DMZ will be used to display the SQL information, and the sharepoint server on the internal server will continue to serve normally as the intranet.

We also need to collect information from the SQL server on the DMZ, and store it back on the SQL server in the internal domain which i am not sure how to do without risking security

So basically what i am looking for is
A - a way to accomplish what i am looking for.
B - Making sure that the internal domain is secure.
C - keeping costs down, we would prefer not to buy a copy of sql 2008 if it is not needed.

i appreciate any help on this and all suggestions will be looked at in detail.
domain.jpg
0
CaptainGiblets
Asked:
CaptainGiblets
  • 4
1 Solution
 
pwindellCommented:
The second Forest/Domain does not even need to exist. It is needless excessive over complexity.

Security is not going to be something that you "arrive at" and now you are "there", and sticking obstacles in the way of Layers1-4 communication isn't going to define the security,...because the traffic that you do allow for everything to function is going to be the attack channel.  Most of the security is going to come from the Applications being used,...primarily Sharepoint in this case. So if Sharepoint is an insecure product,...then security is impossible.  But I think Sharepoint is fine,...and that is where your security is going to come from.

The Domain would neither be insecure nor secure either way. It is almost not relevant.  Domains are secured (or insecured) based on what Security Objects (users groups, etc) are given or not given premission to.  The LAN is at Layers 1-4,...the Domain exists completely beyond the Layers,...apples & oranges,...two different things.

The DMZ does not even need to exist and the SQL and the Sharepoint can be used right from the Internal LAN by publishing the Sharepoint to the External using ISA2004.  The security comes from Sharepoint itself.

See....

The “De-perimeterization” of Networks
http://technet.microsoft.com/en-us/library/cc512604.aspx
0
 
pwindellCommented:
The Domain would neither be insecure nor secure either way. It is almost not relevant.  Domains are secured (or insecured) based on what Security Objects (users groups, etc) are given or not given premission to.  The LAN is at Layers 1-4,...the Domain exists completely beyond the Layers,...apples & oranges,...two different things.

To illustrate that futher.  A guest comes in,..say a Rep from another company. They bring a laptop and plug in into one of your wall jacks. The laptop now has full access to the LAN,...but absolutely zero access to the Domain because his laptop is not a member of your domain and he is not in possession of a Domain Level Security Object (aka a User Account).  Therefore your Domain is reasonably secure from him while the LAN at Layer 1-4 are open to him.

What idea I am trying to shoot down here is the common conception that: "I have no firewall,...therefore I am insecure",...along with the flip-side of that,..."I have a firewall,...therefore I am secure".   Both concepts are not correct.
0
 
pwindellCommented:
Share point:

A Fresh Look at Compliance in SharePoint Server 2007
http://technet.microsoft.com/en-us/library/cc512602.aspx
0
 
CaptainGibletsAuthor Commented:
i thought the whole idea of a DMZ was that if somebody *did* compromise your server, they are then not on a computer that is a member of your internal network, limiting what they can have access to, hiding your internal AD infrastructure, as the web server they will be using AD authentication.
0
 
pwindellCommented:
There is some amount of validity to that,..and you are right, that is the typical "Why".  But some of it falls into industry superstition.  Compromised can mean anything (or nothing),...most of the time it does not mean the guy has access to anything at all other than he may have damaged the OS or the software running on the one individual machine,...it rarely if ever means he suddenly has full "Terminal Server style" desktop control with full Domain Administrator privledges and can run willy-nilly around on the LAN and Domain as he wishes.

I'm not telling you to not have a DMZ and to not have what your diagram shows,...what your diagram suggests is legit.  I'm only saying that I think it is excessively complex and would not stop a successful attack anyway.

A successful attack would be an attack on Sharepoint and accomplishing that would provide him with all the data available to and via Sharepoint,...and that data reaches all the way back to the internal LAN & Domain,...so he gets what he came for and the DMZ would have meant nothing.  The attack "channel" is not kicking down the front door through the DMZ,...the attack channel is the data path Sharepoint uses to get data from the LAN, and you can't block that or Sharepoint becomes useless.  Hackers use the resources and tools you give them,...not the ones you don't give them.

So the bottom line here is that 99% of your security focus in this case needs to focus on Sharepoint itself and what information is allowed to be retrieved by Sharepoint and subsequently presented to the one "asking" for it.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now