Securing database-to-database communications - Implementing Database Security and Auditing - page 233

8

Securing database-to-database communications

Databases are often not islands that are completely disconnected from other
databases. In fact, in a world where most databases are deployed on UNIX,
Windows, and Linux servers as part of a distributed data architecture, one
database will often use other databases to create better working environ-
ments for developers and better data repositories for business users. This
chapter focuses on such database-to-database relationships and how they
affect the need to secure and monitor databases.
As you'll see throughout this chapter, database-to-database communica-
tions add challenges to good security. Although you can sometimes address
these distributed data environments as simply another client making a con-
nection to a server, usually these connections look and act differently. In
these situations the issues and questions you need to address will be differ-
ent from those you have seen in previous chapters. Such differences can
result from the need to replicate data in advance so that it is always available
rather than getting the data from a remote database when needed. Other
differences involve login IDs and privileges and the question of whether the
remote request should impersonate the original login and how you manage
users on the remote database. Fortunately, distributed data architectures
have been around for quite a while and enough features, functions, and best
practices exist for you to lean on.

8.1 Monitor and limit outbound communications

In Section 3.6.1 you learned about SQL Slammer (or the Saphire worm).

The SQL Slammer worm used a vulnerability of SQL Server, but the attack
was on the network and was based on saturating the network with packets.
Interestingly enough, one of the ways that network administrators quickly
contained the worm was by adding egress filtering (filtering of outbound