mastering sql server 2000 security PHẦN 7 doc

1. Run sp_change_primary_role on the instance of SQL Server marked as the current primary server. The example shows how to make the primary database stop being the primary database. current_primary_ dbname is the name of the current primary database. EXEC sp_change_primary_role @db_name = ‘current_primary_dbname’, @backup_log = 1, @terminate = 0, @final_state = 2, @access_level = 1 GO 2. Run sp_change_secondary_role on the instance of SQL Server marked as the current secondary server. The example shows how to make the secondary database the primary database. current_ secondary_dbname is the name of the current secondary database. EXEC sp_change_secondary_role @db_name = ‘current_secondary_dbname’, @do_load = 1, @force_load = 1, @final_state = 1, @access_level = 1, @terminate = 1, @stopat = NULL GO 3. Run sp_change_monitor_role on the instance of SQL Server marked as the monitor. The example shows how to change the monitor to reflect the new primary database. new_source_directory is the path to the location where the primary server dumps the transaction logs. EXEC sp_change_monitor_role @primary_server = ‘current_primary_server_name’, @secondary_server = ‘current_secondary_server_name’, @database = ‘current_secondary_dbname’, @new_source = ‘new_source_directory’ GO The former secondary server is now the current primary server and is ready to assume the function of a primary server. The former primary is now not a member of the log shipping pair. You will need to configure the original primary as a secondary server to the new primary if you want it to participate in the log shipping process. 248 Chapter 10 Federated SQL Server 2000 Servers Microsoft SQL Server 2000 databases can be spread across a group of data- base servers capable of supporting the processing growth requirements of the largest Web sites and enterprise data processing systems built with Microsoft Windows. SQL Server 2000 supports updateable distributed par- titioned views used to transparently partition data horizontally across a group of servers. Although these servers cooperate in managing the parti- tioned data, they operate and are managed separately from each other. A group of servers that cooperate to process a workload is known as a fed- eration. Although SQL Server 2000 delivers impressive performance when scaled up on servers with eight or more processors, it can support huge pro- cessing loads when partitioned across a federation. The federation depends on all machines involved in order to make them work together to act as a single database. They need very similar security settings to make sure that users can interact with all machines involved in the federation. Although the user sees one view of the data, security is configured separately for each server. This process will be easy to configure if the user setting up the fed- eration is a system administrator. A federated database tier can achieve extremely high levels of perfor- mance only if the application sends each SQL statement to the member server that has most of the data required by the statement. This is called col- locating the SQL statement with the data required by the statement. Collo- cating SQL statements with the required data is not a requirement unique to federated servers. It is also required in clustered systems. Although a federation of servers presents the same image to the applica- tions as a single database server, there are internal differences in how the database services tier is implemented. Table 10.2 identifies the differ- ences between a single server application and a federated server-tiered application. Table 10.2 Single Server Applications versus Federated Database Servers SINGLE SERVER FEDERATED SERVERS Only one instance of SQL Server One instance required for each member of the needed. federation. Production data is physically Each member has a database and the data is stored in a single database. spread across the servers. (continues) Managing Distributed Data Security 249 Table 10.2 Single Server Applications versus Federated Database Servers (Continued) SINGLE SERVER FEDERATED SERVERS Each table is singular. The table from the original database is horizontally partitioned into tables on each of the member servers. Distributed partitioned views are used to make it appear as though the data is in a single location. Connection is made to a The application layer must be able to collocate single server. SQL statements to ensure that the server that has most of the data receives the request. While the goal is to design a federation of database servers to handle a complete workload, you do this by designing a set of distributed parti- tioned views that spread the data across the different servers. If the design is not solid in the beginning, the performance of your queries will suffer as the servers try to build the result sets required by the queries. This section discusses the details of configuring the distributed parti- tioned view. Thereafter, the considerations for updating, inserting, and deleting data are introduced. Finally, this section addresses the security concerns related to Federated Database Servers. Creating a Partitioned View A partitioned view joins horizontally partitioned data from a set of member tables across one or more servers, making the data appear as if from one table. SQL Server knows the difference between local views and distrib- uted partitioned views. In a local partitioned view, all participating tables and the view reside on the same instance of SQL Server. In a distributed partitioned view, at least one of the participating tables resides on a different server. In addition, SQL Server differentiates between partitioned views that are updateable and views that are read-only copies of the underlying tables. Although the view that is created may be updateable, the user that interacts with the view must still be given permission to update the dis- tributed view. The permissions for these partitioned views are similar to regular views; you just have to configure the permission on each server ref- erenced in the partitioned view. More information on setting permission for views is found in Chapter 5, “Managing Object Security.” Before implementing a partitioned view, you must first partition a table horizontally. The original table is replaced with several smaller member 250 Chapter 10 tables. Each member table has the same number of columns and the same configuration as the original table. If you are creating a distributed parti- tioned view, each member table is stored on a separate member server. The name of the member databases should be the same on each member server. This is not a requirement, but will help eliminate confusion. You design the member tables so that each table stores a horizontal slice of the original table based on a range of key values. The ranges are based on the data values in a partitioning column. The range of values in each member table is enforced by a CHECK constraint on the partitioning col- umn, and ranges cannot overlap. For example, you cannot have one table with a range from 1 through 200000, and another with a range from 150000 through 300000, because it would not be clear which table contains the values from 150000 through 200000. For example, if you are partitioning a Customer table into three tables, the CHECK constraint for these tables could appear as follows: On Server1: CREATE TABLE Customer_33 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 1 AND 32999), Additional column definitions) On Server2: CREATE TABLE Customer_66 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 33000 AND 65999), Additional column definitions) On Server3: CREATE TABLE Customer_99 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 66000 AND 99999), Additional column definitions) NOTE You need to have the permission to create tables on all servers involved in the federation. After creating the member tables, you define a distributed partitioned view on each member server. The view name should also be the same on each server. This allows queries referencing the distributed partitioned view name to run on any of the member servers. The system operates as if a copy of the original table is on each member server, but each server has only a member table and a distributed partitioned view. The location of the data is transparent to the application. Managing Distributed Data Security 251 Creating distributed partitioned views requires several steps, which must be configured. To perform the necessary configuration options, you should perform the following three steps: 1. Each member server has to be configured as a linked server on every other member server. This is necessary to allow every server to run a query and access the other servers when necessary. The security settings of the linked servers must be configured to allow all users to authenticate against all servers. 2. Set the lazy schema validation option, using sp_serveroption, for each linked server definition used in distributed partitioned views. This tells the query optimizer not to request meta data from the remote table until it actually needs data from the remote table. This optimizes the execution of the query and may prevent unnecessary retrieval of meta data. You need to be a member of the system administrators (sysadmin) role to set this value. 3. Create a distributed partitioned view on each member server. The views use distributed SELECT statements to access data from the linked member servers and merge the distributed rows with rows from the local member table. To complete this step, you must have the permission to create views on all servers. The following example demonstrates a distributed partitioned view. The SELECT statement must be performed against all servers involved in the federation. CREATE VIEW Customers AS SELECT * FROM CompanyDatabase.TableOwner.Customers_33 UNION ALL SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66 UNION ALL SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99 Updateable Partitioned Views If a local or distributed partitioned view is not updateable, it can serve only as a read-only copy of the original table. An updateable partitioned view can exhibit all the capabilities of the original table. This can be an excellent option for security. If you want the users to be able to view the data but not update it, this option should be used. This is beneficial if your data is being loaded from a source other than the user who is analyzing the data. A view is considered an updateable partitioned view if the view is a set of SELECT statements whose individual result sets are combined into one using the UNION ALL statement. Each individual SELECT statement 252 Chapter 10 references one SQL Server base table. For the view to be updateable, the additional rules discussed in the following sections must be met. Table Rules Member tables are defined in the FROM clause in each SELECT statement in the view definition. Each member table must adhere to the following standards: ■■ Member tables cannot be referenced more than once in the view. ■■ Member tables cannot have indexes created on any computed columns. ■■ Member tables must have all PRIMARY KEY constraints on an identical number of columns. ■■ Member tables must have the same ANSI padding setting. Column Rules Columns are defined in the select list of each SELECT statement in the view definition. The columns must follow these rules: ■■ All columns in each member table must be included in the select list. ■■ Columns cannot be referenced more than once in the select list. ■■ The columns from all servers involved in the federation must be in the same ordinal position in the select list. ■■ The columns in the select list of each SELECT statement must be of the same type (including data type, precision, scale, and collation). Partitioning Column Rules A partitioning column exists on each member table and, through CHECK constraints, identifies the data available in that specific table. Partitioning columns must adhere to these rules: ■■ Each base table has a partitioning column whose key values are enforced by CHECK constraints. ■■ The key ranges of the CHECK constraints in each table do not overlap with the ranges of any other table. ■■ Any given value of the partitioning column must map to only one table. Managing Distributed Data Security 253 ■■ The CHECK constraints can only use these operators: BETWEEN, AND, OR, <, <=, >, >=, =. ■■ The partitioning column must be in the same ordinal location in the select list of each SELECT statement in the view. For example, the partitioning column is always the same column (such as first column) in each select list. ■■ Partitioning columns cannot allow nulls. ■■ Partitioning columns must be a part of the primary key of the table. ■■ Partitioning columns cannot be computed columns. ■■ There must be only one constraint on the partitioning column. If there is more than one constraint, SQL Server ignores all the constraints and will not consider them when determining whether or not the view is a partitioned view. Distributed Partition View Rules In addition to the rules defined for partitioned views, distributed partition views have these additional conditions: ■■ A distributed transaction will be started to ensure atomicity across all nodes affected by the update. ■■ The XACT_ABORT SET option must be set to ON. ■■ The smallmoney and smalldatetime columns in remote tables are mapped as money and datetime, respectively. Consequently, the corresponding columns in the local tables should also be money and datetime. ■■ Any linked server cannot be a loopback linked server, that is, a linked server that points to the same instance of SQL Server. ■■ A view that references partitioned tables without following all these rules may still be updateable if there is an INSTEAD OF trigger on the view. The query optimizer, however, may not always be able to build execution plans for a view with an INSTEAD OF trigger that are as efficient as the plans for a partitioned view that follows all of the rules. Data Modification In addition to the rules defined for updateable partitioned views, data modification statements referencing the view must adhere to the rules 254 Chapter 10 defined for INSERT, UPDATE, and DELETE statements, as described in the sections that follow. The permission to perform these statements is han- dled at each server. To aid in troubleshooting, all of the servers should have an identical security configuration for the database used in the federation. For instance, if a user needs permission to perform the INSERT statement, it must be given at all servers. INSERT Statements INSERT statements add data to the member tables through the partitioned view. The INSERT statements must adhere to the following standards: ■■ All columns must be included in the INSERT statement even if the column can be NULL in the base table or has a DEFAULT constraint defined in the base table. ■■ The DEFAULT keyword cannot be specified in the VALUES clause of the INSERT statement. ■■ INSERT statements must supply a value that satisfies the logic of the CHECK constraint defined on the partitioning column for one of the member tables. ■■ INSERT statements are not allowed if a member table contains a column with an identity property. ■■ INSERT statements are not allowed if a member table contains a timestamp column. ■■ INSERT statements are not allowed if there is a self-join with the same view or any of the member tables. UPDATE Statements UPDATE statements modify data in one or more of the member tables through the partitioned view. The UPDATE statements must adhere to the following guidelines: ■■ UPDATE statements cannot specify the DEFAULT keyword as a value in the SET clause even if the column has a DEFAULT value defined in the corresponding member table. ■■ The value of a column with an identity property cannot be changed; however, the other columns can be updated. ■■ The value of a PRIMARY KEY cannot be changed if the column con- tains text, image, or ntext data. Managing Distributed Data Security 255 ■■ Updates are not allowed if a base table contains a timestamp column. ■■ Updates are not allowed if there is a self-join with the same view or any of the member tables. ■■ The DEFAULT keyword cannot be specified in the SET clause of the UPDATE statement. DELETE Statements DELETE statements remove data in one or more of the member tables through the partitioned view. DELETE statements are not allowed if there is a self-join with the same view or any of the member tables. Security Considerations for Federated Servers The following security suggestions can make the management of Feder- ated Database Servers lighter. The configuration of Federated Database Servers is very procedural and if security is not configured correctly, you will not get the intended results. ■■ The individual configuring the federation should be a system administrator on all servers. This is technically not required for each step, but it will make all configurations possible from a single login. ■■ The Distributed Partitioned Views do not have to be updateable. If it is inappropriate for users to make modifications to the data, don’t allow the view to be modified. ■■ The databases at each server are configured separately, although they appear to the user as a single entity. You should remember this as you troubleshoot failed statements. If the security across the servers is not similar, you will need to check security settings at each server individually. ■■ The startup account for the SQL Server and SQL Server Agent service should be the same across all servers and should be a local administrator on all machines. ■■ All logins that need to execute queries against the federation should be created on all servers. ■■ The database users and roles on all servers should be identical for the distributed database. 256 Chapter 10 ■■ All users who need to perform queries against the federation will need permission to the view. The permission must be equivalent to the action the users need to perform. For instance, if you need a user to insert into the view, that user must have INSERT permission to the view definition at each server. ■■ Configure security account delegation to allow the servers to pass Windows Authentication information to each other. If you want to use the Windows account information, you need to allow the servers to pass the user information on behalf of the users. Best Practices ■■ Set up linked servers to allow for distributed transactions. Without linked servers, transactional consistency cannot be maintained across servers. ■■ Configure security account delegation to integrate Windows Authentication with linked servers. ■■ Use the same startup account for the SQL Server service and the SQL Server Agent service for all services that need distributed data support. ■■ Verify that the service account is a local administrator on all servers that participate in the distributed data options. ■■ Use the Database Maintenance Plan Wizard to configure log shipping. The process is very procedural in nature, and the wizard will make sure you complete all the necessary steps. ■■ Use Federated Database Servers for large enterprise applications and Web farms. It is only beneficial for very large database solutions. Managing Distributed Data Security 257 [...]... tackles the security concerns of Analysis Server This product has its own security model, which is different from the model we have introduced for SQL Server so far The security model of Analysis Server is not complicated, but because it is different from the rest of SQL Server security, it often adds some complication Analysis Server Analysis Server is the service component of SQL Server 2000 Analysis... owner of the SQL Server Agent job who runs the package does not have permission to access the paths pointed to or connections made in the package For example, the owner of the job may only have local server access If this problem arises, view the security context of the job in SQL Server Enterprise Manager and log out of that instance of SQL Server Then log back in to that same instance of SQL Server using... is the advantage to storing packages as a Visual Basic file? CHAPTER 12 Exploring Analysis Services Security Analysis Server is used in conjunction with SQL Server 2000 Technically, it is not part of SQL Server; it is a separate product Analysis Server extends the normal relational functionality of SQL Server to help optimize the analytical nature of a data warehouse The purpose of the product is to... architecture is built on top of SQL Server, you have to first account for the security infrastructure of the data that you are transferring to Analysis Server Then you have to account for the data as it is stored in the OLAP databases The focus of this book is on security If you are just starting out with SQL Server Analysis Services, you should refer to Microsoft SQL Server 2000 Analysis Services Step... Windows 2000 account, the job runs under the security context of the account that started SQL Server Agent This should be your SQL Server service account that was created on the domain If the job is owned by a login belonging to the sysadmin fixed server role, the security context of the package defaults to the account used to start the local SQL Server Agent If the server is registered using Windows Authentication,... OLE DB data source (for example, a Microsoft Access 2000 database) into SQL Server Alternatively, data can be exported from SQL Server to an OLE DB data destination (for example, a Microsoft Excel 2000 spreadsheet) DTS also allows high-speed data loading from text files into SQL Server tables When importing and exporting data, you are limited to the security of the data sources and data destinations... updated Analysis Server allows you to separate the two processes Your transactional system can be optimized for modifications, while your reports and analysis work are performed against the data stored in Analysis Server databases 279 280 Chapter 12 Analysis Server has its own security model, which is separate from that of SQL Server Analysis Server depends on Windows Authentication, and the security configuration... linked server? 2 Why should I consider the log shipping feature? 3 What are the necessary steps for promoting a secondary server to a primary server when using log shipping? 4 Which of the distributed database features depend on the Enterprise Edition of Microsoft’s SQL Server 2000? 5 What is horizontal partitioning? 6 What is the purpose of a distributed partitioned view? 7 How can Federated Database Servers... access to the security credentials used for connection to a database server When you use Windows Authentication, the user information is not stored with the file 277 278 Chapter 11 REVIEW QUESTIONS 1 What are the core components of a DTS package? 2 What are the management tools available to create and modify packages? 3 What are the security concerns related to scheduling packages as SQL Server jobs?... Agent If the server is registered using Windows Authentication, the owner of the job is the account of the SQL Server Agent If the server is registered using SQL Server Authentication, the owner of the job is the SQL Server login If the job is owned by a login that is not a member of the sysadmin fixed server role, by default the package that is scheduled as a job step will not run If the proxy account . primary as a secondary server to the new primary if you want it to participate in the log shipping process. 248 Chapter 10 Federated SQL Server 2000 Servers Microsoft SQL Server 2000 databases can. single server application and a federated server- tiered application. Table 10.2 Single Server Applications versus Federated Database Servers SINGLE SERVER FEDERATED SERVERS Only one instance of SQL. you will need to check security settings at each server individually. ■■ The startup account for the SQL Server and SQL Server Agent service should be the same across all servers and should be