|
|
| |
|
Microsoft® and Syteview® together provide you with the tools you need to design a web
publishing system that meets your needs. Whatever your needs: redundancy, scalability or security, ALWAYS
SECURITY, Syteview lets you do it your way. From a single server running your Progress database, Microsoft
SQL Server and your Microsoft IIS Server to a distributed network of SQL Servers connected via
Microsoft SQL Server Replication Services
each providing data to multiple Microsoft IIS web servers, Syteview lets you design it your way.
The following examples are provided in order to give you a good starting point in working out
the design of your system.
Design #1 – Simple and Quick
The easiest way to get Syteview up and publishing quickly is to run everything, Progress
database server, Microsoft SQL Server and Microsoft IIS Server, all on one computer. This simplifies setting
up the ODBC connections between the various parts of the system and the secure connection between the SQL Server and the
IIS Server. This design does put your Progress database at risk if you expose this system to the internet, but
for a quick and easy (but not secure) intranet or for setting up a test environment this is a good beginning configuration.
For this configuration you will start with a Progress database server in good working order
on a Windows NT or 2000 system. Install the IIS Server if it wasn’t installed
by default with your operating system and then install the SQL Server.
Syteview requires very few special configuration options, so choose the default options when installing these servers
unless you have your own reasons not to.
Once you have the SQL and IIS Servers installed you will need to install and configure the
Syteview components, see the Syteview Installation Guide. Next you need to
create the Syteview ODBC connections to the SQL Server and the
Progress database server. Aftering installing the SQL and IIS servers
and creating the ODBC connections to them, make sure to apply the latest service patches and security hotfixes.
At this point you should then be ready to open up your web browser and point it to your
Syteview web site and display some data. After you are done playing with a few of the Syteview data lookup web
pages you can take a look at the DataLinks and
DataGrabbers pages for information on keeping the SQL Server in-sync with your Progress database server.
Design # 2 – Protecting Your Progress Server
The first design example is simple, it’s quick, and it works, but it is not secure.
Since all three servers are running on the same computer your Progress database server and your SQL Server are exposed to
everyone and everything that has access to your IIS Server. Even on an small intranet this can be dangerous.
One of the first improvements you should consider making to your design is adding a second Progress server. This
will allow you to separate your production Progress server from the second Progress server that is pushing data out to the
SQL Server. This change has the added benefit of leaving your production Progress server completely untouched.
(see Figure 2)
At regular intervals (nightly, weekly, etc.) backup copies of the physical database files from your
production Progress server are copied over to the second Progress server (the one that is also hosting your SQL and IIS
Servers). You should copy your database files between the two Progress servers using a non-routable network
protocol, NetBEUI for example, and if you are exposing the IIS Server to the internet a properly configured firewall should
be placed between the two Progress servers. For those truly paranoid among us, consider removing the network
connection and use tapes or another form of removable media to copy the database files between the two Progress servers.
This will create a complete disconnect between your production Progress server and the outside world. In today’s
hacker and virus infested world, paranoia is not such a bad thing.
Design # 3 – Further Protection for Your Progress Server
The next design improvement you may wish to implement starts with the same configuration as
Design #2 above, except that the SQL Server and the IIS Server are no longer hosted on the same computer that hosts the
second Progress database server. The SQL and IIS Servers are moved onto a third computer. By putting
these two programs on a third computer you can setup a private IP subnet between the second and third computers that further
protects your secondary Progress server from any intrusion from the internet. (see
Figure 3)
Note: A private IP subnet is by definition disconnected from the internet (private IP numbers are not routed through internet routers) and any computer with only a private IP number will not be able to communicate through the internet.
Reference: Private IP Addresses
By configuring this private subnet with only the computer hosting the secondary Progress
server and the computer hosting the SQL/IIS Server as members your secondary Progress server will be isolated from the
internet.
The computer running the SQL Server and the IIS Server will need to have two IP numbers. One private
IP number that is used to communicate with your secondary Progress server and a second public IP number, assigned by your
Internet Service Provider, that allows the IIS Server to communicate on the internet or in the case of an intranet, a
second private IP number that allows your IIS Server to communicate with your internal network.
A further benefit of this design is that it allows you to place another firewall between
your secondary Progress server and the SQL/IIS Servers. A VLAN can also be configured to even further isolate these two
computers from the internet and from your internal network.
A VLAN is a Virtual LAN setup on a network switch that logically segments your network
into separate networks. If you setup one VLAN that includes your end users and the original Progress server
they will be able to access their usual Progress applications. If you setup a second VLAN that includes only
your two Progress servers you will be able to copy the physical database files from the original Progress server to the
second Progress server that Syteview uses. If you setup a third VLAN that includes only the second Progress
server and the computer running the SQL Server and the IIS Server they will be able to communicate. Finally,
if you setup a fourth VLAN that includes the computer running the SQL Server and the IIS Server and the router, hub,
switch, proxy server or firewall that connects to the internet the IIS Server will be able to talk on the internet.
Together these four VLANs will allow communications between each of the computers that need to communicate, but will
prevent any connection between your Progress servers and the internet.
Design # 4 – Protecting your SQL Server
This design is similar to Design # 3 with the additional improvement of moving the IIS
Server onto a fourth computer. A private IP subnet, or in certain configurations a non-routable network
connection, is used to connect the IIS Server and the SQL Server. A firewall and a VLAN can also be used
between these two computers to further isolate the SQL Server.
This configuration not only protects and isolates your SQL Server from the internet, but
it also provides an additional layer of defense between the internet and your Progress servers. A layered defense is
always a good idea. (see Figure 4)
Unfortunately there are several drawbacks associated with this configuration that need
to be addressed. First is the matter of performance. Separating the SQL Server and the IIS Server slows
down the communications between the two servers. Not as much as you might expect because of the addition of
a network connection between them, but mostly due to the necessity of authenticating each request for data twice.
The data request must be authenticated first by the IIS Server when it receives the original request from the end user’s
web browser and then the data request must be authenticated a second time by the SQL Server when it receives the request
from the IIS Server.
This necessity to authenticate the data request a second time by the SQL Server can,
depending on the level of security you require, lead to a complicated set of problems. If you are willing to
authenticate your users and their data requests only once on the IIS Server, and if you don’t need the fine grained
control of data access provided by the SQL Server then you can prevent the SQL Server from initiating the second
authentication request by setting up one local user account on the SQL Server that has the ability to run each of the
Syteview stored procedures and has the ability to retrieve data from each of the tables in the Syteview database.
This local user account must be matched by a local user account on the IIS Server of the exact same name that has been
setup to be the Anonymous User account (the account used by the IIS Server for anonymous access). You can then
create a non-trusted connection between the IIS Server and the SQL Server by disabling the default Named Pipes connection
and instead setting up a TCP/IP connection.
This configuration will allow you to restrict access to your data by using NTFS permissions
on the web pages on your IIS Server while allowing your SQL Server to fulfill all data requests from the IIS Server without
the second authentication process.
Unfortunately, not everyone is able to forego the SQL Server authentication. The
authentication that occurs on the IIS Server verifies that each user has the right to request a set of data (by allowing
them to open a particular web page on the IIS Server), but that data set may be derived from more than one database table.
This may not allow you to limit the access to your data to a sufficient degree and it also requires you to keep track of
exactly which web pages access which database tables. These problems are alleviated by the SQL Server’s ability to specify
access rights for each individual table and in some cases for individual records in a table.
Other reasons that might require you to authenticate data requests on the SQL Server include:
- the ability to restrict users to a particular set of records from a table (for example restricting a customer to
viewing only his own orders or restricting a user to only a particular set of ledger accounts).
- the ability to direct different users to different stored procedures (which return different records) depending upon
their username.
- the requirement to log users’ database access.
- the desire to provide another layer of protection for your data, separate from the protection provided by your
internet exposed IIS Server.
Authenticating data requests on the SQL Server when the SQL Server is not hosted on the
same computer as the IIS Server is unfortunately considerably more difficult to setup and administer than when the SQL
Server and the IIS Server are on the same computer. You have to either do it the Microsoft way which entails:
- Setting up and administering an Active Directory domain.
- Using SQL Server 2000 or above on a Windows 2000 Server.
- Using IIS Server 5.0 or above on a Windows 2000 Server.
- Using Digital Certificates or Microsoft’s Message Digest Authentication to authenticate users on the IIS Server.
Or you can do it the Syteview way which entails:
- Setting up a non-trusted (usually TCP/IP) connection between the IIS Server and the SQL Server instead of the
normal trusted (usually Named Pipes) connection.
- Using a special data control (ASP2SQLRemote.dll) which allows you to preserve each user’s name as a data request
is transferred from the IIS Server to the SQL Server.
- Using a special stored procedure (SyteCheck) which checks each user’s permission to access a database table or a
stored procedure before passing off the validated request to the proper stored procedure.
Design # 5 – Adding Scalability and Redundancy
This design uses the same basic configuration design as Design #4 above, but instead of
just one IIS Server pushing data out to the internet, multiple computers each hosting an IIS Server are connected to the
SQL Server. This gives you the same benefits as Design #4, ie. multiple layers of defense and the additional
processing power provided by putting the SQL Server on its own computer, but it also gives you the ability to add
processing power as you need it by adding additional IIS Servers. (see Figure 5)
After extensive lab and real-world testing, we have come up with a ball park figure of a
single SQL Server being able to support up to six IIS Servers. This is only a ball park figure and depends
greatly on how your users actually use the system. More data intensive lookups obviously put a heavier load
on the SQL Server and may limit your configuration to fewer IIS Servers per SQL Server, but we have identified the IIS
Server as being a bottleneck relative to the SQL Server and this configuration will allow you to alleviate this problem.
An additional benefit of this configuration is IIS Server redundancy. If one
IIS Server is down, the other IIS Servers will still be able to fulfill users’ requests.
This design has the same requirements as Design #4, ie. Active Directory, SQL Server 2000,
IIS Version 5, and Message Digest Authentication or Digital Certificates unless, of course, you use the Syteview’s special
data control (ASP2SQLRemote.dll) and stored procedure (SyteCheck).
Design #6 – Multiple SQL Servers
This design uses the same basic configuration as Design #5 above with the addition of
multiple SQL Servers. Each computer hosting an instance of SQL Server is isolated and protected from exposure
to the internet using the same techniques discussed above. Each SQL Server uses a copy of the same database
which can be kept synchronized by either Microsoft’s SQL Server Replication Services or by using Syteview’s DataGrabbers
and DataLinks. (see Figure 6)
You get the same benefits that you get with the previous design, ie. multiple layers of
defense and additional processing power. You also have the same drawback as above, ie. Active Directory, SQL
Server 2000 and IIS Version 5 are required unless you use Syteview’s special data control and stored procedure.
Additional benefits of this design include SQL Server redundancy and the ability to set up
a distributed data network with geographically remote SQL and IIS Servers using either Microsoft’s SQL Server Replication
Services or Syteview’s DataGrabbers and DataLinks.
One possible drawback that needs to be considered: a distributed data network using SQL
Server Replication Services will usually require professional design and installation services and a commitment to
ongoing management resources. Syteview’s DataGrabbers and DataLinks are also capable of powering a distributed
data network, but they may also require outside help during the design and installation phase.
Conclusion
Syteview gives you the tools you need to design a data publishing system that meets your
needs for performance, security, scalability, redundancy and location. Features from each of the basic designs
described above can be incorporated into your own design. Always make sure that you understand the security
ramifications of your design and test your design thoroughly before placing it on your network.
|
|
|
|
|
