Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 47 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
47
Dung lượng
766,43 KB
Nội dung
the level of auditing, the more overhead you will have to create in the application. This overhead generally increases the complexity of maintain- ing the process. Use the more complicated options only when they are a requirement of your business system. In most cases, application auditing can be simple and used to store the most recent change information. Fol- lowing are the three levels of auditing: New record tracking. You may only need to know the user who added a record to the table, which would make this level of auditing appropriate. Modification tracking. In addition to knowing the user who added a record, you may need to track the user who made the last change. If this is your desired level of auditing, you should determine how detailed this level of tracking should be. You will need to know the answers to the following two questions: ■■ After a record is modified, do you still need to know the user who added the record? ■■ When a record is modified, do you need to be able to track all modifications or just the most previous change? Deletion tracking. At this level, you need to determine if you want to track a record that has been deleted. If you want to track the deleted records, you also need to determine if you want to store the original new record tracking and modification tracking information. The following sections describe the changes that need to occur within your database to support these levels of application auditing. New Record Tracking New record tracking is the easiest level of application auditing to imple- ment. You will want to be able to track the user who performed the opera- tion that added the new record. On the tables that you want to audit, you will need to add a column that stores the username of the user who created the record. For the new column you need to create a default that uses the user- name() function. If the column is not supplied by the INSERT statement, then the username() function fills in the value. The username() function supplies the current username value. Defaults are applied only at insert time, so this process is an effective method of tracking the new record and will not change as users make modifications to the record. To add the 342 Chapter 14 username() function default to a table in your database, perform the fol- lowing steps: 1. Open Enterprise Manager. 2. Click to expand your server group. 3. Click to expand the server that you want to alter. 4. Click to expand the Databases container. 5. Click to expand your database. 6. Double-click on the Tables container. 7. From the Details pane, right-click on the table you want to audit and select Design. 8. From the Design Table dialogue box, add a column that will be used for auditing (in our example the column is named Iusername), as shown in Figure 14.7. The Data Type should be a character type that allows for the current username to be added. More information on the character data types can be found in SQL Server Books Online. 9. Click on the column you created in step 8, and in the lower pane in the Default Value field type username(). 10. Click the Save icon on the Toolbar to save the changes you have made. Figure 14.7 You can create a column within your table to store the username of a user who adds a record. Creating an Audit Policy 343 Modification Tracking With modification tracking you first have to determine whether or not you need to track all changes that are made to the record. You also need to determine whether you want to store the name of the original creator of the record or just the name of the user who made the most current change. In this section the following three scenarios are described: ■■ The user who made the most recent modification is stored. ■■ The user who made the most recent modification is stored along with the original creator of the record. ■■ All modifications are stored. The User Who Made the Most Recent Modification This implementation is similar to new record tracking. You should imple- ment this type of auditing when you need to track the user who performed the most recent modification, not just the creator of the record. When a new record is added, you want the user who added the record to be stored with the record. After a change is modified, you want to store only the user who made the most recent modification. Perform the following steps to main- tain this level of auditing: 1. New record tracking has to be configured as described in the proce- dure in the preceding New Record Tracking section. 2. When a record is modified, you should perform one of the following actions within a transaction. The first option is to create a transac- tion that is a combination of an INSERT and a DELETE statement instead of an UPDATE statement. The old value is deleted and the new value is inserted as a new record. This process makes it possible for the username() function to work as it did for a new record. Your second option is to update the column you previously created for auditing whenever you update another column. This procedure should be performed with a trigger to ensure that every UPDATE statement includes the modification of the auditing column. The trigger should be set on the table and should be configured on UPDATE. The trigger should set the audit column to the current username by using the username() function. More information on triggers can be found in SQL Server Books Online. 344 Chapter 14 The User Who Made the Most Recent Modification Is Stored with the Creator of the Record In some cases it is useful to store the name of the user who originally cre- ated the record along with the user who performed the most recent update. In this case you need to perform the following steps to meet your auditing requirements: ■■ New record tracking has to be configured by following the proce- dure presented in the New Record Tracking section. ■■ A second column has to be created in the table for auditing purposes to hold the name of the user who most recently updated the column. Use your naming conventions to guarantee consistency throughout your database. The second column should also be configured with the username() function as the default. When a record is added, both columns should contain the username of the user who added the record. ■■ A trigger should be added to update the column you created in step 2 whenever the record is modified. The trigger should be set on the table and configured on the update action. Whenever an update occurs to any of the columns in the table, you want the trigger to update the newly added audit column. With these options set, you can maintain the name of the user who created the record in the first audit column you created and the name of the user who performed the most recent modification in the second audit column you created in step 2. All Modifications Are Stored In this scenario the process starts to get a little more complicated. This method of auditing should be configured only when the requirements of your system require a full audit trail of all of the modifications that are made to your database. As changes are made to the table in question, you will delete an old record and insert a new record into the original table. You will then take the deleted value and write it to your new auditing table. This is a very complete method of auditing, but it does not account for deletions. You should perform the following steps to make sure that you are able to keep track of all modifications that are made to the record: Creating an Audit Policy 345 1. New record tracking has to be configured on the table you want to audit. This feature should be configured as described by the proce- dure in the section New Record Tracking. 2. You also need to configure an additional column within your audited table to track the date and time that a record was added. Because every modification performed while you are in this mode of auditing deletes the old record and inserts a new record, the value of this column is always the date and time of the last modification. You should create a default for this column, similar to the username() default. In this case, however, you will want to use the GetDate() function. The GetDate() function returns the current date and time. This functions stores the date and time that the action occurred. 3. You then need to create an additional table to store the historical information needed to maintain the full audit trail. This table should have a column structure that is identical to that of the table that it is storing information for. The only difference should be the primary key. The primary key should be a composite of your existing unique identifier and the date and time column you created. This change to your primary key allows you to store the same column from your original table multiple times. Storing the column multiple times is necessary to track the entire life of the record. New record tracking should not be configured on your new table. It should receive both the username and the date and time columns from the original table. 4. You then need to write a trigger for the original table. The trigger should be assigned to the DELETE action. When a record is deleted from the original table, the trigger should take the values and insert them into the new audit table you created in step 3. 5. All modifications should be written as transactions. The transactions should be written as a combination of an INSERT and a DELETE instead of an UPDATE statement. When you modify a record, the old value is deleted from the table and written to the audit table by the trigger. The new value is inserted into your original table. 6. If you want to retrieve all of the iterations of a record, you will need to JOIN the original table with the auditing table to show all of the changes to the record. 346 Chapter 14 Deletion Tracking In many cases you will not need to keep track of deletions. You will need to evaluate your requirements to determine if a record has to be tracked after it has been deleted. In some databases data is not actually deleted when the user hits the Delete button in the application. The most com- mon form of dealing with this issue is to create a history table. For instance, a customers table may require creating a customer history table to track customer records that otherwise would have been deleted. This concept could be applied to orders, inventory, employees, and many other items. To set up deletion tracking effectively, perform the follow- ing steps: 1. Create a history table that has the same table structure as the original table. 2. Create an additional column in the history table to track the user who performed the deletion. This column should be given a default that uses the username() function. 3. Create a trigger that is assigned to the original table. The trigger should be associated with the DELETE action. The trigger should take the record that was deleted and write it to the new history table. When the record is written, the username() function identifies the user who performed the deletion. NOTE Triggers are advanced Transact-SQL statements and can be associated with the INSERT, DELETE, and UPDATE actions. When records are deleted or inserted, the values are temporarily stored in inserted and deleted tables in RAM on the server. When your trigger statements need to retrieve the values that were previously inserted in or deleted from the table, they should do so from these tables that are in RAM. Your statements will not always work right if you try to retrieve the values from the original table. By using these RAM tables, you will increase performance and guarantee accurate results. More information on inserted and deleted tables can be found in SQL Server Books Online. Creating an Audit Policy 347 Best Practices ■■ Use server auditing to audit the successful and failed login attempts when you suspect an unauthorized user is attempting to access your data. ■■ Only use C2-Mode auditing when your business system requires that you track all access to database objects. ■■ Use the SQL Profiler utility to track security configuration changes. Tracking these changes is useful for keeping a handle on changes to authentication modes and audit levels. ■■ Use the SQL Profiler utility to track Transact-SQL statements. This kind of tracking is beneficial in troubleshooting failed SQL state- ments. It is also helpful in tracking statements that are performing actions that are not authorized. ■■ Practice using the SQL Profiler utility. It can be a very complex tool. You will be more effective in tracking security violations to your sys- tem if you know how to take advantage of the SQL Profiler features. ■■ Use the SQL Profiler utility to track the Windows user account. SQL Profiler is the best tool for tracking an action back to the Windows account that performed the action. Most other SQL Server tools view all members of a group as the same login and database user. SQL Profiler allows you to retrieve information at both the Windows 2000 and SQL Server levels. ■■ Implement application auditing only at the level required by your business process. The more detailed your application auditing requirements are, the more complex the implementation of the solu- tion will be. ■■ Use the username() and GetDate() functions to assist with applica- tion auditing. ■■ Use triggers to help maintain audit information that has to be stored across multiple tables. 348 Chapter 14 Creating an Audit Policy 349 REVIEW QUESTIONS 1. What is C2-Mode security? 2. What is a SQL Trace? 3. What are the SQL Profiler templates used for? 4. What templates are geared toward security auditing? 5. How can you limit the amount of information captured by SQL Profiler? 6. What is the purpose of the username() function? 351 Whenever the Internet becomes involved, security becomes a concern. As the Internet has developed over the last couple of years, the functionality provided to the common Web user has continued to increase. SQL Server has grown in functionality over the same period of time, and inevitably there are organizations that want to view their data over a Web medium. There are also several Web-based applications that use SQL Server as a backend database product. While organizations strive to make more data available on the Internet, they also have to address a whole new scope of security issues. The data has to be secure and possibly encrypted as it is transmitted, the database server needs to be protected from hackers who will try to expose the data, and firewalls and proxy servers add additional layers of filtering for which applications have to account. As data has become more accessible with the growth of the Internet, the concern arises that your data will also be more accessible to millions of other users. Your organization will need to develop a security strategy that allows your data to be accessed over the Internet only by the users who need to see the data, while still providing as much functionality to the users as possible. Managing Internet Security CHAPTER 15 [...]... the database engine of SQL Server to provide native support for XML Integration with Other Products SQL Server 2000 works with other products to form a stable and secure data store for Internet and intranet networks SQL Server 2000 works with Microsoft Windows 2000 Server and Microsoft Windows NT Server security and encryption facilities to implement secure data storage SQL Server uses Windows Authentication,... using JDBC to access SQL Server 363 364 Chapter 15 IISServer Other Server Java Server ASP Scripting Servlets ADO Various JDBC API OLEDB ODBC JDBC OLEDB Provider ODBC Driver JDBC Driver SQL Server Figure 15.5 Connection methods are available to SQL Server from variety of Web servers Using Active Data Objects with Active Server Pages When working with database servers such as SQL Server, your application... functionality for data retrieval and storage SQL Server2 000 includes many features that support XML’s functionality The combination of these features makes SQL Server 2000 an XMLenabled database server The following features in SQL Server 2000 support XML functionality: II The ability to access SQL Server through the Hypertext Transport Protocol (HTTP) (See the Accessing SQL Server Using HTTP section later in... information that IIS will use when connecting to SQL Server XML for SQL Server 2000 Figure A.3 From the New Virtual Directory Properties dialogue box, you can allow URL queries, template queries, and XPATH queries, after you have configured XML support for SQL Server Accessing SQL Server Using HTTP You can access SQL Server 2000 using HTTP The HTTP access to SQL Server allows you to access data through the... connect to IIS, which authenticates the user, and IIS then connects to SQL Server to retrieve the data for Managing Internet Security the application interface With this configuration the security model is a combination of SQL Server security and IIS security I I SQL Server 2000 can be used with Application Center Server and Commerce Server to build and maintain large, sophisticated e-commerce Web sites... within IIS II XML documents can be added to SQL Server 2000 databases The OPENXML function can expose the data from an XML document in a rowset, which can be referenced by Transact -SQL statements, such as SELECT, INSERT, or UPDATE Managing Internet Security Connections to SQL Server from the Internet You can connect to an instance of Microsoft SQL Server over the Internet using SQL Query Analyzer... schemas in XPath queries to build XML documents and populate data for the user This process will create a view of your SQL Server database schema XPath queries are defined in Appendix A, “XML for SQL Server 2000. ” II The SQL Server 2000 includes a data-link library (DLL) that allows you to define virtual roots in Microsoft IIS associated with an instance of SQL Server 2000 Internet applications can then... Windows 2000 The Windows 2000 Secure Sockets Layer (SSL) features can also be used to create secure, encrypted connections from the Internet to SQL Server More information on SSL is found later in this chapter in the section titled Connecting to SQL Server through a Web Server II SQL Server 2000 forms a high-performance data storage service for Web applications running under Internet Information Server. .. XML, SQL Server data can be passed over the Internet using port 80 This connection allows the data to be easily passed through secured environments, which include proxy servers and firewalls when necessary The following set of options is available when you are integrating SQL Server with XML More information on configuring XML support in SQL Server 2000 can be found in Appendix A, “XML for SQL Server 2000. ”... discusses a direct connection to SQL Server The section then describes the factors to consider when you connect to the Internet through a proxy server or firewall Finally this section addresses connection issues when the browser first connects to IIS, and IIS connects to SQL Server to retrieve the data A Direct Connection to SQL Server SQL Server supports direct connections to SQL Server over the Internet . integrating SQL Server with XML. More informa- tion on configuring XML support in SQL Server 2000 can be found in Appendix A, “XML for SQL Server 2000. ” ■■ Transact -SQL results can be returned as XML documents. to SQL Server to retrieve the data for 352 Chapter 15 the application interface. With this configuration the security model is a combination of SQL Server security and IIS security. ■■ SQL Server. intranet networks. SQL Server 2000 works with Microsoft Windows 2000 Server and Microsoft Windows NT Server secu- rity and encryption facilities to implement secure data storage. SQL Server uses Windows