Database Reference
In-Depth Information
new server equipment and network adapters, and you can benefit from technology
upgrades completely in a nondisruptive manner.
With the security policy applied on individual virtual machines or logical groups, VMs
can be mobile and move anywhere while retaining the same consistent security policy.
You will no longer be reliant on IP addresses as the means of security policy
enforcement. The same consistent security policy can be enforced regardless of whether
the VMs or virtual applications are running in a primary or disaster recovery data
center. Security policy can be tested nondisruptively in production during DR testing.
Creating a policy to allow applications servers to access SQL Server is as easy as
“Source: Application A Server Group, Destination: SQL Server A, TCP:1443, Allow”
while everything else is denied. The processing required to enforce the policy is
completely distributed throughout the environment, thus eliminating infrastructure that
would have previously become a performance chokepoint. More importantly, security
policy can be applied automatically when your SQL Server databases or virtual
applications are provisioned from your service catalog, thus removing any risk of
manual security configuration errors and the weeks of delays that can often follow.
Figure 8.26
shows a logical architecture with virtualized network security between the
application servers and database servers that ensure that production application servers
can only access production SQL databases and that test and dev application servers can
only access test and dev SQL databases.
Figure 8.26
Application and database server virtualized security zones.
Figure 8.27
shows the logical network architecture of a traditional three-tier application
with completely virtualized networking and security services.
