Implementing Database Security and Auditing phần 7 pdf

246 8.5 Secure replication mechanisms EXEC sp_addlinkedsrvlogin 'FALCON', 'false', NULL, 'sa', 'guardium' sp_addlinkedserver 'FALCON' sp_setnetname 'FALCON', '192.168.2.2' EXEC sp_addlinkedsrvlogin 'FALCON', 'false', NULL, 'sa', 'n546jkh' and then use the link to request the following data: SELECT * FROM FALCON.northwind.dbo.orders you will get a completely different set of calls from database A to database B. This is all based on a proprietary RPC protocol that Microsoft uses between databases, creating a much more efficient data flow. The RPC calls you would see would be to the following stored procedures: sp_getschemalock sp_provider_types_rowset [northwind] sp_tables_info_rowset sp_reset_connection sp_releaseschemalock sp_unprepare These calls are within an RPC protocol, so it is easy to identify cross- link calls and monitor them. Finally, you must remember that even if you have multiple clients con- nected to database A, using the link you will only see a single session going from database A to database B carrying all of these requests. 8.5 Secure replication mechanisms Replication is the process of copying and maintaining database objects in multiple databases. Replication is used in environments that include dis- tributed databases, environments that require high-availability and fault- tolerance, environments that implement a disaster recovery and/or business continuity initiative, and much more. Replication is one of the most com- mon advanced features in any database environment, and all major plat- forms support replication—even open source databases such as MySQL, which included it in version 4.1.x. By definition, replication includes the copying of data and/or operations from one database environment to another. Many mechanisms are used to 8.5 Secure replication mechanisms 247 Chapter 8 implement replication, and you’ll see some of these in this section. In all cases the replica database is processing requests that originally come from the master database or that were processed by the master database (I use the term master database here to mean the database which is the master of record for replication; it has nothing to do with the master database in SQL Server). Replication is often considered to be a “core datacenter operation” and is therefore often overlooked in terms of security and auditing, but in fact it is often one of the busiest and most valuable data streams. This addi- tional database stream, like any stream, should be secured and audited, and so must be the mechanics that govern this stream. In securing and auditing replication, you need to consider two main aspects. The first is the security of the mechanics of replication. In every database, you can control what gets replicated, how often, where to, and so on. This is done using a set of tools or through commands that you can invoke through SQL or a SQL-based interface. These mechanisms should be secured, and you need to audit any changes to these definitions. For example, you need to ensure that an attacker cannot bring down your busi- ness continuity operations by halting replication. You also need to ensure that attackers cannot define a new replication task that copies all sensitive information from your database directly into a fake instance they have set up for that purpose. The second aspect of replication is the communications and files that are used by the replication mechanisms. Replication agents and processes communicate with each other and pass information such as data that needs to be copied to the replica database or commands that need to be per- formed within the replica database. These can be intercepted and/or altered, forming another type of attack; therefore, you must make sure that the entire replication architecture is secure and auditable. Each of the database vendors has slightly different terminologies and implements replication differently, but from a security standpoint the issues that you need to watch for are identical. The terminology used throughout the next section is closest to the SQL Server terminology, but the require- ments for security and auditing of replication apply to all database products. 8.5.1 Replication options There are several replication types, so let’s start with a brief overview. Snap- shot replication or data replication is the simplest form of replication and involves extracting data from the master database (master in this context is the “main” database and not SQL Server's master database) and then read- 248 8.5 Secure replication mechanisms ing it into the replica database. As its name implies, snapshot replication makes a copy at a single point in time—a snapshot. This type of replication is useful when data is fairly static and/or when the amount of data that needs to be replicated is fairly small. It is also used to bootstrap other repli- cation options and is useful for highly distributed environments that do not have a constant high-throughput communication link, and in which each site works autonomously most of the time. In Oracle this is often called simple read-only replication. Transaction replication involves copying the transactions applied on data sets and applying them in the replica database. The replication is at an operation level rather than a data level and can be efficient if there are large data sets but where changes are a much smaller fraction. Transaction repli- cation is based on the replica database being initially in-sync with the mas- ter database (through a copy or a one-time snapshot replication), after which synchronization is maintained by applying the same transactions in both databases. Merge replication is an advanced function that allows changes made in the replica to reflect back to the master database by merging changes and dealing with conflicts. Oracle advanced replication has a robust architec- ture for two-sided update replication, including multimaster replication with many functions that allow you to control conflict resolution in a granular manner. Back to SQL Server, replication is based on a publish/subscribe meta- phor. The model is based on publishers, distributors, subscribers, publica- tions, articles, and subscriptions. A publisher is a server that makes data available for replication to other servers and is responsible for preparing the data that will be replicated. A publication is a logically related set of data that is created by a publisher. A publication can include many arti- cles, each of which is a table of data, a partition of data, or a database of objects that is specified for replication. An article is the smallest unit of data that can be replicated. A distributor is a server that hosts a database that stores information about the distribution of replication files along with metadata and is responsible for actually moving the data. A distribu- tor can be the same as the publisher or a separate database. Subscribers are servers that receive the replicated data by subscribing to publications; they are responsible for reading the data into the replica database. Registering interest is done through subscriptions, which are requests for getting pub- lications. A subscription can be fulfilled by the publisher (a push subscrip- tion) or by the subscriber (a pull subscription). 8.5 Secure replication mechanisms 249 Chapter 8 Figure 8.8 shows the SQL Server snapshot replication model. The snap- shot agent runs as part of the distributor’s SQL Server Agent and attaches to the master database (the publisher) to create a schema and data files. It records synchronization information in the distribution database and places the data within the snapshot folder. The distribution agent runs as part of the distributor when using push subscription (as shown in Figure 8.8). It uses the information in the distribution database to decide where the data needs to be replicated to and communicates with the subscriber to finish the replication. If you use pull subscription, then the distribution agent will be running on the subscriber. 8.5.2 Secure replication files and folders There are numerous aspects to securing replication. When your replication scheme involves the creation of files, you must secure the folder where repli- cation files are stored. For example, when you set up the snapshot agent and the distribution agent in SQL Server, you specify which folder to use, as shown in Figure 8.9. This is a network share, and by default it is an insecure folder. You should change the share path and configure NTFS permissions so that only the SQL Server Agent services on your SQL Server nodes can access and modify this folder. In addition, you might want to consider using Windows 2000 EFS to encrypt these replication files. These security guidelines should be followed for all types of replication within all database environments on all operating systems—with the appro- priate adaptations. Not every scheme uses external files. For example, in Oracle all replica- tion schemes use internal queues within the database, eliminating the need for you to worry about the security at a file system level. Figure 8.10 shows Figure 8.8 SQL Server snapshot replication. 250 8.5 Secure replication mechanisms an Oracle asynchronous replication scheme for transaction replication using an internal queue. DB2 UDB replication will also not require you to secure files (with one small caveat mentioned in the next paragraph). DB2 replication has two components: the capture component and the apply component. The cap- ture component runs on the master database, which reads the log file look- ing for data modifications and stores these modifications into control tables on the master database. The apply component runs on the replica database and pulls the data from the control tables to a local copy. These are then applied to the replica database. Like Oracle, this scheme is fully contained within the database and does not require you to deal with external files and folder permissions. The scheme is actually clearly described in the first screen of the Replication Center Launchpad (shown in Figure 8.11), acces- sible from the Tools menu in the Control Center. As shown in Figure 8.11, the entire scheme is based on moving data between tables in the various UDB instances. The caveat to the previous paragraph is that the capture program does write external diagnostics files in the CAPTURE_PATH directory, and you should secure this directory appropriately. Figure 8.9 Specifying the snapshot folder in SQL Server. 8.5 Secure replication mechanisms 251 Chapter 8 One additional option is often used as a means to implement replication. An option called log shipping involves copying the redo logs (transaction logs) to the replica machine. This option will certainly require you to deal with file security. Log shipping is not formally a replication option (at least not in DB2 and Oracle), although many people use it as the simplest form of repli- cation, and it is similar to transaction replication in SQL Server (albeit with less automation). Log shipping is discussed further in Section 8.6. Figure 8.10 Oracle transaction replication using queues. Figure 8.11 DB2 UDB replication overview as displayed by the Replication Center Launchpad. 252 8.5 Secure replication mechanisms 8.5.3 Secure and monitor replication users and connections Because replication involves a complex architecture, many of the vendors use multiple connections and multiple user accounts to manage and per- form replication. As an example, when you configure SQL Server replica- tion with a distributor that is separate from the publisher, you need to configure a remoter distributor password. When you do this, a new SQL Server user with System Administrator privileges is created with a password that you assign within the publishing and distribution property editor, as shown in Figure 8.12. The bottom line is that you now have a new user with elevated privileges and additional servers connecting to your server that you need to closely monitor and track. Figure 8.12 Setting the password for remote connections to the distributor. 8.5 Secure replication mechanisms 253 Chapter 8 An Oracle advanced replication environment requires several unique database user accounts, including replication administrators, propagators, and receivers. Most people just use a single account for all purposes, but there is a security trade-off. If you use a single account, you have less control and less possibility to audit and monitor for misuse. If you select to have distinct accounts for each replication configuration, and you choose differ- ent accounts for replication administrators, propagators, and receivers, you will have more to monitor and administer, but you can better track data and transaction movements. In DB2 UDB, the user IDs you use to set up replication need to have at least the following privileges:  Connect permissions to both the master and replica servers, and to the capture connect apply control and monitor control servers.  Select permissions from catalog tables on the master, replica, capture control, and monitor control servers.  Create table/view permissions on the master, capture control, and apply control servers.  Tablespace creation permissions on the master, capture control, and apply control servers.  Create package and bind plan permissions on the master, replica, monitor control, and apply control servers.  Create non-SQL/PL procedures (i.e., using a shared library) per- missions. In addition, the user running the capture program needs to have DBADM or SYSADM authority and write privileges to the capture path directory. Finally—and perhaps the most important note in UDB replication security—you must properly secure the password file used by the apply pro- gram so as not to create an additional security vulnerability. Because the file is created using the asnpwd utility, the contents are encrypted, but you still must take great care in securing this file. 254 8.5 Secure replication mechanisms 8.5.4 Monitor commands that affect replication Replication metadata is stored in the database. In SQL Server, publications, articles, schedules, subscriptions, and more are maintained in the distribu- tion database. Replication status is also stored inside the database. You can set replication up using the vendor tools, but under the covers these all cre- ate SQL statements that travel over database connections. Therefore, an attacker may try to affect replication by connecting and making changes using these SQL commands. You therefore need to monitor the appropriate objects and commands so that someone doesn’t exploit functions such as push subscriptions to steal data. Continuing with the SQL Server example, Figure 8.13 shows the repli- cation tables you should monitor in the msdb database, and Figure 8.14 shows the replication tables in the distribution database. You should moni- tor these tables closely by logging all SQL that reference these tables and fil- ter out agents that connect as part of true replication operations. As an example, when the snapshot agent runs, it appends rows to the MSrepl_commands that indicate the location of the synchronization set and references to any specified precreation scripts. It also adds records to the MSrepl_transactions that reflect the subscriber synchronization task. These are later read by the distribution agent, which applies the schema and commands to the subscription database. Obviously, if attackers can inject or alter definitions in these tables, they can affect the replication process and even get access to data they are not authorized to see. You should consider setting up alerts that fire whenever anything diverges from a normal baseline; replication tends to be predictable and constant, so there is little risk that you will be swamped with false alarms. In Figure 8.13 Replication tables in SQL Server’s msdb schema. 8.5 Secure replication mechanisms 255 Chapter 8 Figure 8.14 Replication tables in the SQL Server distribution database. Figure 8.15 Replication tables in SQL Server publishing and subscribing databases. [...]... of the commands and system procedures that you think are risky and can be used to inject a Trojan If your security and audit system allows you to Figure 9.4 Building a tailored group for matching commands and system procedures that can be used to inject a Trojan 9.3 Control creation of and changes to procedures and triggers 273 Figure 9.5 Basing the rule on the Trojan-specific group of commands build... these terminals and the back-end servers, including private radio networks, cellular companies, mainstream data communication providers, satellite communications, and even hotspots in airports and Starbucks cafés Mobility is a broad domain, and security for mobile computing devices and applications is too and certainly not within the scope of this book However, one aspect of database security is especially... document and monitor all of these data paths into your database, because this is certainly a “back-door” type access into your core database 8 .7 Summary In this chapter you learned that securing database access means more than monitoring “front-door” connections You learned that many database environments implement distributed data and that numerous architectures support replication, log shipping, and database. .. 260 8.6 Map and secure all data sources and sinks Figure 8.16 DB2 tables used for replication on the master database 8.6 Map and secure all data sources and sinks Figure 8. 17 261 DB2 tables used for replication on the replica database Chapter 8 262 8.6 Map and secure all data sources and sinks which user IDs are being used, what monitoring you can put in place, and how to implement techniques learned... command group Chapter 9 272 9.3 Control creation of and changes to procedures and triggers Figure 9.3 Basing the rule condition on commands that can be used to inject a Trojan ymous blocks, you will get too many false alarms, and even a baseline will be difficult to use In fact, a baseline might make the entire policy too permissive and will not trap a real injection The second method to combat type 3 and. .. to the monitoring system, how that system is secured, and who is auditing access to that system If you go one step further to audit and save this access data (and normally you will), then you will be keeping this data in a database or data repository If you don’t use a scrubbed format, then you are saving values and this database needs its own security layers; you can easily create an infinite loop... traces and event monitors Every database has features for creating monitors and trace events that occur in the system Some of these features are part of the database auditing features, and some are additional features that you can use in an audit initiative but that are also used for other purposes—e.g., performance tuning and functional enhancements to existing applications These monitors and events... repository—usually a database All of the main vendors have databases that were specifically built to run on small-footprint devices and be optimized for embedding within the applications This includes IBM’s Cloudscape (which has been donated to Apache as an open source database) , Oracle Lite, SQL Server for Windows CE, and Sybase Anywhere In some application environments the local database can be a full-blown database. .. database server and an application server on every laptop, and the only difference is that there is less data on each unit The application on the 8.6 Map and secure all data sources and sinks 265 Figure 8.19 Mobile application architecture using a local database on the mobile unit mobile client can work autonomously (at least for certain periods) because the application is using data in the local database. .. you can use the following commands: On the master database: CREATE MATERIALIZED VIEW LOG ON TABLE T1; 8.5 Secure replication mechanisms 2 57 On the replica database: CREATE MATERIALIZED VIEW T1 REFRESH FAST WITH PRIMARY KEY START WITH SYSDATE NEXT SYSDATE + 1/1440 AS (SELECT * FROM T1) You should monitor such DDL statements closely (and especially the commands on the master database) because they will . datacenter operation” and is therefore often overlooked in terms of security and auditing, but in fact it is often one of the busiest and most valuable data streams. This addi- tional database stream,. simplest form of replication and involves extracting data from the master database (master in this context is the “main” database and not SQL Server's master database) and then read- 248 8.5 . environment and review how data is stored, 260 8.6 Map and secure all data sources and sinks Figure 8.16 DB2 tables used for replication on the master database. 8.6 Map and secure all data sources and