Ok, that makes sense. Thanks for the response, I may contact you when we actually think about this in earnest.
Joe Heaton -----Original Message----- From: Kurt Buff [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 1:59 PM To: NT System Admin Issues Subject: Re: Best practices question The data on the SQLServer in the DMZ will be a read-only copy of a limited set of data in our production CRM system. We'll push updates to the DMZ from production about every 15 minutes. If, in the future, we need to pull data from the DMZ, we can do it over that port. On Feb 6, 2008 1:08 PM, Joe Heaton <[EMAIL PROTECTED]> wrote: > Kurt, > > Does the SQL database reside on the webserver, or internally? > Shouldn't databases reside inside the network, so they're protected? > So the webserver you're installing will be a standalone machine? Not > a part of the domain at all? Not trying to ask stupid questions, it > just ends up that way... > > > Joe Heaton > > -----Original Message----- > From: Kurt Buff [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 06, 2008 1:00 PM > To: NT System Admin Issues > Subject: Re: Best practices question > > > Not merely no, hell no. > > What is the architecture of the system? > > We'll (sometime before summer) be putting up a web site for customer > orders. > > They'll be able to check status of orders and so on. > > The system will be a web site with a SQLServer back end. > > It'll reside in the DMZ, and we'll be opening exactly two ports - 3389 > and 1433. The first is so we can TS into the machine, the second is so > that we can push read-only updates to the machine. > > Roach motel, baby. If we need further funcationality, we'll open ports > as needed - one-way. > > On 2/6/08, Joe Heaton <[EMAIL PROTECTED]> wrote: > > > > Our business involves customers (called contractors, as they sign > > contracts with us) accessing a couple of applications. The > > contractors come in, enter information, and have the ability to > > track this information, so that they can make any changes they need to make. > > > We're making some changes to our infrastructure, and I wanted to get > > some opinions about the "right" way of allowing outside customers > > access to our system. We don't have a DMZ at the moment, but we > > will be going to that soon, as soon as I get our new firewalls in. > > One of our developers here, who also has some networking experience > > has suggested that we setup another domain in the DMZ, and create > > trust relationships with the internal domain. The contracts > > typically last about 2 years, and the active contracts change on a > > monthly basis. My > > > concern would be knowing when contractors left, and need to be > > removed > from AD within the DMZ domain. > > > > My thoughts were to simply install the public webserver in the DMZ, > > and configure rights, etc. for the contractors to come into that > > server, and access the databases within the network. Isn't that the > "normal" model? > > > > Haven't dealt with this all that much, so I'm going to hit Google > > once > > > this is posted. Any tips/advice would be appreciated, as always. > > > > Joe Heaton > > AISA > > Employment Training Panel > > 1100 J Street, 4th Floor > > Sacramento, CA 95814 > > (916) 327-5276 > > [EMAIL PROTECTED] > > ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ > ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ > > ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ > ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ > ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
