Sistemas de InformaoRedes de ComputadoresAnlise e Desenvolvimento de Sistemas

Administrao de Banco de Dados1 Semestre 2011

Pedro Antonio Galvo JuniorE-mail: pedrogalvaojunior@gmail.com Fone: 9531-7555pedro.galvao@aes.edu.br

Verso 1.11.02 Fev/2011.

*

SEGURANA NO MICROSOFT SQL SERVER 2008

OFERECENDO SEGURANAPolticas de senhas no login de SQL ServerHierarquia dos escoposSeparao de usurios do schema Limite de visualizao dos metadadosExecuo pelo contexto

Polticas de senhasWindows logins or SQL Server logins, in the same manner used by previousversions of SQL Server. In this release of SQL Server, you can also applypassword policies to SQL Server logins. These policies act similarly to howWindows enables password restrictions for Windows logins.

Hierarquia dos escoposSQL Server 2005 provides a consistent model for securing objects at differentscopes by using a hierarchical arrangement of principals, securables, andpermissions. This new approach helps make security more manageable than inprevious releases.

SchemaIn previous releases of SQL Server, object namespaces were dictated by theobject owner. In SQL Server 2005, object namespaces are determined by usingschemas, independent of the object owner. This separation of owner from objectnamespace provides a more flexible and manageable framework.

Limite da visualizao dos metadadosThe introduction of catalog views in SQL Server 2005 results in limitedvisibility of metadata. By default, users can view metadata only for objects forwhich they have been granted permissions.

Execuo pelo contextoThe execution context of programmable modules (such as stored procedures orfunctions) now can be set explicitly in the CREATE statement. This featureenables the object creator to specify the user account under which the objectwill execute, making it possible to control access to dependent objects withoutrelying on ownership chains.

SEGURO POR DEFAULTServios e features desligadas por padroPermite somente conexo localUsa o SAC para habilitar/desabilitar as features

Upgrade preserva as configuraesServios e Features novas desabilitadasUsa o SAC para habilitar/desabilitar as features

Windows Server 2003 SQL Server 2005Windows Server 2003 SQL Server 2000

MODELOS DE SEGURANA NOMICROSOFT SQL SERVER 2008

MECANISMOS DE SEGURANAAutenticaoUsurio e senhaCertificadosAutorizaoPermissesCriptografiaChaves SimtricasChaves Assimtricas

SQL Server utilizes familiar security mechanisms to create a secure environment.Authentication identifies the principal who is attempting to access, change or delete the data. SQL Server supports authentications by username and password and certificate. Certificates will be covered in more depth in the fifth part of these Webcasts. SQL Server has integrated support for Windows password policies. The policy can be used to enforce password lengths and complexity. We will look at this more closely later in this session.Authorization is the process of allowing or denying the principal, once they are authenticated, access to data. SQL Server 2005 provides improved granularity of permissions enabling an administrator to be specific about the permissions that are being assigned. We will also look at permissions later in this session.SQL Server also uses cryptography. This is the process of encryption and decryption to protect the data. Cryptography will also be covered in the fifth part of these Webcasts.

Lets see how SQL Server limits access to data and functionality.

COMPONENTES DE SEGURANAPrincipalsWindowsGroupsDomain accountLocal accountSQL ServerSQL accountServer roleDatabaseUserDatabase roleApplication roleGroup

Securables

Server ScopeLoginsEndpointsDatabases

Database ScopeUsersAssembliesSchemas

Schema ScopeTablesProceduresViews

Permissions

Grant/Revoke/DenyCreateAlterDropControlConnectSelectExecuteUpdateDeleteInsert

QUEM PODE ACESSARO QUE

Existem 3 componentes que so usados para limitar o acesso s features e as funcionalidades do SQL: principals, securables and permissions.

Principal qualquer identidade autenticada que possa ser dada permisso para acessar algum objeto do SQL SERVER. Exemplos: Usurios Windows, Grupos, etc

Securables so recursos. So objetos que recebem permissesAcesso ao Securable controlado.

Securables in SQL Server include databases, assemblies, tables, and other objects.

SQL Server objects are arranged in a hierarchy of three scopes; server, database and schema.

The server scope contains objects such as logins, endpoints, certificates and databases. The database scope contains objects such as users, roles, assemblies and schemas. The schema scope contains objects such as tables, views, functions and procedures.Permissions define the access that a principal has on a securable. The range of permissions that can be applied has been extended in SQL Server 2005. Each permission can be granted; assigning the permission to a principal that does not have it, revoked; removing the permission from a principal, or denied; disallowing a principal from obtaining a permission.

To govern the SQL Server environment, principals should be assigned the most restrictive permission to a securable that still allows them the access they require.

Lets have a look at the process of a login accessing an object in the database.

Processo de Acesso SeguroPedido de conexo pela rede / pre-login handshakeAutenticao do Login no SQL ServerAcesso ao databaseTentar realizar alguma ao

Para ter sucesso na conexo com um banco de dados, voc precisa primeiro localizar e conectar ao Servidor de SQL. A conexo feita atravs de um endpoint.Um SQL Server pode ter multiplos endpoints, cada um identificado sobre qual login tem permisso de acess-los

A prxima etapa acessar o Banco de dados. Para fazer isso o login de SQL Server dever configurado (mapeado) a um user com as devidas permisses para acessar o banco

POLTICA DE SENHASRequer Windows Server 2003.Autenticao Windows:Login de usurios WindowsRespeita a poltica de senhas do Windows

Autenticao SQL Server:Logins SQL Server Respeita a poltica de senhas da mquina local.Poltica de Domnio se estiver em um ambiente de Domniosys.sql_logins catalog view

When a Windows user is created, a password for that user must be configured. To maintain security Windows enables the configuration of a policy governing password acceptability. The major features of the policy are the required length of a password, password complexity and password expiration.

SQL Server 2005 can use the Windows password policy of the local machine, or in a domain the domain policy, and enforce the same requirements for SQL Server logins.The sys.sql_logins catalog view enables an administrator to check that all passwords being used meet the policy requirements.

CRIANDO LOGINSConfigurao da Politica de Senhas

New logins can be created in the SQL Server Management Studio.

The administrator can create a new login and choose to apply the Windows password policy. If the Enforce password expiration option is enabled, the Enforce password policy option must also be enabled.

The Windows password policy can also be applied when using CREATE LOGIN.

CREATE LOGIN login_name { WITH < option_list1 > | FROM < sources > }< sources >::= WINDOWS [ WITH windows_options [,...] ] | CERTIFICATE certname | ASYMMETRIC KEY asym_key_name< option_list1 >::= PASSWORD = ' password ' [ HASHED ] [ MUST_CHANGE ] [ , option_list2 [ ,... ] ]< option_list2 >::= SID = sid | DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language | CHECK_EXPIRATION = { ON | OFF} | CHECK_POLICY = { ON | OFF} [ CREDENTIAL = credential_name ]< windows_options >::= DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language Configurao da Politica de SenhasCRIANDO LOGINS

The CREATE LOGIN statement is new to SQL Server 2005, and replaces the sp_addlogin and sp_grantlogin stored procedures in previous releases.

It has two parameters that enable the use of the Windows password policy.CHECK_EXPIRATION and CHECK_POLICY can both have values of ON or OFF. If CHECK_EXPIRATION is set to ON then CHECK_POLICY must also be set to ON.

OPES DE LOGINUsa a API NetValidatePasswordPolicy() do Windows Server 2003

OpoDescrioHASHEDEspecifica que a senha j est criptografadaMUST_CHANGEAvisa o usurio que precisa mudar a senha. Precisa de CHECK_EXPIRATION e CHECK_POLICY habilitadoCHECK_EXPIRATIONExpirao de senhas. Se estiver ON, as polticas so Aplicadas e requer que CHECK_POLICY esteja ONCHECK_POLICYFaz a checagem das polticas de senha

GERENCIANDO LOGINSRemovendo um LoginDROP LOGIN

Alterando um LoginALTER LOGIN WITHPASSWORD = '3948wJ698FFF7'

CREDENCIAISAlternativa aos logins.Permitem conexo a recursos fora do SQL Server.

CREATE CREDENCIAL WITH IDENTITY = identity name, SECRET = secret

Credencial uma alternativa de login que contm informaes necessrias para se conectar a recursos fora do SQL Server.

Exemplo: Um usurio conectado ao SQL Server usando um login de SQL poderia executar uma stored procedure que acessa uma aplicao ASP.NET que configurada com Windows Authentication.

A Credencial ir mapear o Login de SQL com a conta Windowsatravs da Credencial.

SCHEMAS DE SEGURANA

DEFAULT SCHEMACREATE USER user_name[ FOR {LOGIN login_name| CERTIFICATE cert_name| ASYMMETRIC KEY asym_key_name}][ WITH DEFAULT_SCHEMA = schema_name ]Um schema default pode ser atribuido quando o usurio do banco de dados criado.

Especifica o schema default

Nos padres de definio ANSI SQL-92

Um Schema um container para objetosTodo objeto pertence a um schemaTodos os objetos de um schema tem o mesmo dono, que o dono do schemaAs permisses podem ser atribuidas para schema

Multiplos usurios podem ser donos do schema. Basta criar um grupo Windows ou roles a atribuir como donos do schema

Excluir um usurio

GERENCIANDO SCHEMASCREATE SCHEMACria um schemaAtribui um ownership para o schemaCria objetos de database como membros do schema ALTER SCHEMAAltera o ownership do schemaMove objetos de database entre schemas

DROP SCHEMARemove um schema

Managing Schemas.Create schema; alter schema; drop schema.

Explain the management of schemas.

0

There are a number of SQL statements that can be used to manage schemas:CREATE SCHEMA is used to create schemas and assign ownership. When you use the statement you can also create database objects and include them as schema members.ALTER SCHEMA is used to change schema ownership and also to move database objects between schemas.DROP SCHEMA is used to remove a schema.

Let's see how the object namespace is made up.

OBJECT NAMESPACE

SalesCustomerAdventureWorksLON-SQL-01

The object namespace includes four levels; server, database, schema, object. When defined in a request, each level is written separated by dot as shown on the slide. The search process automatically uses the default schema that is configured for the user, falling back to the built-in dbo schema if the object is not found in the users default schema.

ATRIBUINDO DATABASE OBJECTS

dboJobCandidate[ WITH DEFAULT_SCHEMA = Sales ]SELECT * FROM dbo.JobCandidateSELECT * FROM JobCandidateSELECT * FROM Customersys.database_principals catalog viewsys.schemas catalog view

When you make a request for data, it must include the namespace path to the object you require. The namespace path up to your default schema is automatically assumed by default. Therefore, if you request a table that is a member of your default schema you need only specify the table name. If the table is not found in the users default schema, SQL server 2005 will always search the built-in dbo schema before failingIf you request a table in another schema but still in your default database you must specify the schema and table name.If the object is not in your default database you must specify the database name as well.Sys.database_principals and sys.schemas catalog views return information regard schema owners and default schemas.

Schemas also make dropping users easier than with earlier versions.

APPLICATION COMPATIBILITY

Propriedade de CeliaCustomer

AppAlterando o proprietrio para KatiaSELECT CustomerID FROM Sales.Customer

AppSELECT CustomerID FROM Sales.CustomerSales

CustomerSales

Application Compatibility with SQL Server 2005.User schema separation; ownership.

Explain the use of schema separation in SQL Server 2005.

0

SQL Server 2005 does not use the name of the object owner in the objects namespace. The object namespace remains the same irrespective of changes in ownership maintaining application compatibility.

Let's see a demonstration of schema separation.

USURIOS

USURIOSAcesso ao Banco de dados;Pode ser mapeado para um login individual ou para um grupo Windows; ePode ser criado pelo SSMS ou por T-SQL.

CREATE USER user_name [{{ FOR | FROM } { LOGIN login_name | CERTIFICATE cert_name | ASYMMETRIC KEY asym_key_name } | WITHOUT LOGIN ] [ WITH DEFAULT_SCHEMA = schema_name ]

GERENCIANDO USURIOSApagando um usurio:DROP USER

Alternado configuraes de um usurio:ALTER USER WITHDEFAULT_SCHEMA =

Componentes de Segurana e Permisses

PermissoDescrioCONTROLAtribui permisses de proprietrio e garante todas aspermisses ao principal no objetoALTERAtribui permisses de alterar, criar ou excluir a qualquersecurable, menos trocar o proprietrioALTER ANYAtribui permisso de alterao de qualquer securable do tipo especificado.IMPERSONATEPermisso de trocar o contexto de execuo para ocontexto de execuo de outro usurioTAKE OWNERSHIPAtribui permisso ao usurio para assumir a propriedade do securable

Control Controla todos os objetos no Banco de dados

Alter Permite ao usurio CRIAR, ALTERAR e DROPAR um Securable e qualquer objeto que esto abaixo dele na hierrquia

Alter Any Permite alterar qualquer securable daquele tipo especificado

Impersonate Permite que um usurio passe suas permisses para outro

Take Ownership Permite dar um take ownership no objeto.

MDULOS DE EXECUO PELO CONTEXTO

INTRODUOConfigura a execuo pelo contexto de mdulos;

Caller no requer permisses:Effective with broken ownership chain

EXECUTE AS:Caller (Default)Username (requer permisso Impersonate)SelfOwner

Execuo por contexto habilita um administrador de criar especficos contextos de segurana para executar o cdigo no servidor

O SQL Server usava o SETUSER que fazia essa mudana de contexto na execu ode uma batch . S os membros das roles SysAdmin e db_owner poderiam utilizar esse comando.

Por exemplo, o administrador pode criar uma procedure que leia e grave em uma tabela e configura o contexto de segurana para executar a procedure.

Quem chama a procedure, no precisa de permisso para cumprir as funes dela,

EXECUTE AS CALLER Executa a procedure com as permisses de quem est acessando no momento.

EXECUTE AS USER Utiliza a procedure no contexto de segurana do user X

EXECUTE AS SELF Utiliza a procedure no contexto do usurio que criou a procedure

EXECUTE AS OWNER Executa no contexto de quem o dono

GRANT SELECT ON sales.customer TO JanePROCESSO DE EXECUO PELO CONTEXTOStored Procedure(Owner: Jane)Billsales.customer(Owner:John)CREATE PROCEDURE GetCustsWITH EXECUTE AS OWNERASSELECT *FROM sales.customersys.sql_modules catalog view

JaneDENY SELECT ON sales.customer TO Bill

A user has EXECUTE permissions on a procedure. The procedure executes and accesses a table in a database that the calling user does not have access to. Because the procedure has been configured to execute with a specific execution context, the table is accessed as the principal configured for the procedure, enabling the user to return the data without being given permissions, even when the ownership chain is broken.In the example shown here, John owns a table called sales.customer. Jane has been granted SELECT permission on this table, but Bill has been denied SELECT permission. Jane owns a stored procedure called GetCusts, which is configured to execute as OWNER. When Bill tries to query the sales.customer table directly, he is denied access. However, when he executes the GetCusts stored procedure, the procedures executes as Jane, returning the data to Bill.This approach does not allow an administrator to audit who is accessing the data as the security context is always the one configured for the procedure, but it can be a useful way to control access to data when you dont want to grant permissions on base tables and views and you have broken ownership chains.The sys.sql_modules catalog view returns information about the security context of procedures.

Let's see a demonstration of this process.

PERMISSO GRANULAR

Securables organizados em uma hierarquia:Herana de permisses.

Todos os objetos tem permisses associadas.

Principal de menor previlgio.

Securables no SQL Server 2005 so agrupados em uma hirarquia:servidor banco de dados Schemas Objeto

Permisses que so atribuidas no mais alto nvel da hierarquia so herdados por securables que esto abaixo.

For example, permisses EXECUTE atribuidas no nvel de bacno de dados, afeta todos os schemas, assumindo que a permisso no seja negada no nvel mais baixo da hierarquia.

As permisses hierarquicas no SQL Server 2005 so mais granulares do que em verses anteriores. Todos os objetos no sistema tem permisses associadas, fazendo com que a poltica de segurana seja mais flexvel

For example, voc poderia atribuir CONTROL permission em todos os objetos LOGIN de um determinado departamento, podendo assim, delegar tarefas.

No nvel de bacno de dados, poder atribuir permisses individuais em todos os objetos para usurios ou roles.

The granular permissions hierarchy in SQL Server 2005 enables administrators to follow the principal of least privilege; assigning only the permissions necessary for each principal to carry out their role.

ESCOPOS DE PERMISSESServidor:O banco de dados Master dever ter permisses Grant; ePermisses especfias para cada securable.

Database:Pode atribuir permisses especficas para roles customizadas;Permitir principals de executar tarefas no banco; ePermisses Grant devero ser atribuidas ao banco que contm o securable que quer aplicar a permisso.

Schema:Usado para agrupar objetos de database; eAtribuir permisses para o schema afeta os membros do Schema.

Permission scopes separate the SQL Server environment into different, configurable areas of access. Each scope contains securables specific to that scope.

The highest level is the server scope. The server scope contains securables that effect the server as a whole, such as; logins, HTTP endpoints, certificates, event notifications and databases. Any permissions that are granted at the server scope must be assigned in the Master database.

The server scope contains the database scope. Permissions at the database scope allow principals to execute tasks within the database. Permissions must be assigned in the database to which the permissions apply and the principals must be database users. Securables at the database level include; users, roles, assemblies, full-text catalogs and schemas.The database scope contains the schema scope. The schema scope contains the database objects. Some permissions, such as SELECT, assigned at the schema level effect the objects contained by the schema. Securables at the schema level include; tables, views, functions, procedures, queues and types. Relevant permissions can be inherited from scope to scope. For example SELECT assigned at the database scope will imply SELECT at schema scope which will, in turn, imply SELECT on all database objects. To change this inheritance process specific permissions can be assigned on the schema or object.The implementation of these permission scopes enables an administrator to implement a secure, robust environment where permissions are specific to the requirement of the principal.

ESCOPO SERVERGRANT CONTROL ON LOGIN::Tom TO FredPermisso GRANT em securables individuais quando as permisses da server role default so inapropriadas.sys.server_permissions catalog view.

Control permission on individual login

Specific permissions can be assigned to principals for specific objects., allowing them to carry out their assigned tasks. This removes the need to assign default server roles, such as sysadmin, that provide additional permissions that are not required.Server permissions can be viewed in the sys.server_permissions catalog view.

ESCOPO BANCO DE DADOSGRANT EXECUTE TO Jim Accounts.AddAcctHR.ViewEmpsSales.AddOrdersys.database_permissions catalog view

Permisses herdadas no banco de dados

Database Scope.Permissions; Database scope.Explain permissions at the database scope.0

Permissions assigned at the database scope can be specific to an object within the scope or assigned on the database. Permissions assigned on the database can affect all schema objects within the database.Database permissions can be viewed in the sys.database_permissions catalog view.

Let's have a look at the schema scope.

ESCOPO SCHEMAGRANT SELECT ON SCHEMA::Sales TO MaryPermisses herdadas no schemasales.accountssales.figuressales.customers

Schema Scope.Permissions; Schema scope.Explain permissions at the schema scope.0

Permissions assigned at the schema scope can be specific to an object within the scope or assigned on the schema. Permissions assigned at the schema level can effect all relevant member objects.

Finally Let's have a look at the objects themselves.

OBJETOS INDIVIDUAISGRANT SELECT ON sales.accounts TO Joesales.accountssales.figuressales.customersPermisses somente para objetos especficosSales.accounts

Individual Objects.Permissions; Database objects.Explain permissions for individual objects.0

Permissions assigned to the individual objects are specific to that object. If a permission is assigned to an object, the permission is enabled at the database and schema scope unless there is a specific deny assigned at either level.

Let's see a demonstration of granular permissions.

*

Polticas de senhasWindows logins or SQL Server logins, in the same manner used by previousversions of SQL Server. In this release of SQL Server, you can also applypassword policies to SQL Server logins. These policies act similarly to howWindows enables password restrictions for Windows logins.

Hierarquia dos escoposSQL Server 2005 provides a consistent model for securing objects at differentscopes by using a hierarchical arrangement of principals, securables, andpermissions. This new approach helps make security more manageable than inprevious releases.

SchemaIn previous releases of SQL Server, object namespaces were dictated by theobject owner. In SQL Server 2005, object namespaces are determined by usingschemas, independent of the object owner. This separation of owner from objectnamespace provides a more flexible and manageable framework.

Limite da visualizao dos metadadosThe introduction of catalog views in SQL Server 2005 results in limitedvisibility of metadata. By default, users can view metadata only for objects forwhich they have been granted permissions.

Execuo pelo contextoThe execution context of programmable modules (such as stored procedures orfunctions) now can be set explicitly in the CREATE statement. This featureenables the object creator to specify the user account under which the objectwill execute, making it possible to control access to dependent objects withoutrelying on ownership chains.SQL Server utilizes familiar security mechanisms to create a secure environment.Authentication identifies the principal who is attempting to access, change or delete the data. SQL Server supports authentications by username and password and certificate. Certificates will be covered in more depth in the fifth part of these Webcasts. SQL Server has integrated support for Windows password policies. The policy can be used to enforce password lengths and complexity. We will look at this more closely later in this session.Authorization is the process of allowing or denying the principal, once they are authenticated, access to data. SQL Server 2005 provides improved granularity of permissions enabling an administrator to be specific about the permissions that are being assigned. We will also look at permissions later in this session.SQL Server also uses cryptography. This is the process of encryption and decryption to protect the data. Cryptography will also be covered in the fifth part of these Webcasts.

Lets see how SQL Server limits access to data and functionality.

Existem 3 componentes que so usados para limitar o acesso s features e as funcionalidades do SQL: principals, securables and permissions.

Principal qualquer identidade autenticada que possa ser dada permisso para acessar algum objeto do SQL SERVER. Exemplos: Usurios Windows, Grupos, etc

Securables so recursos. So objetos que recebem permissesAcesso ao Securable controlado.

Securables in SQL Server include databases, assemblies, tables, and other objects.

SQL Server objects are arranged in a hierarchy of three scopes; server, database and schema.

The server scope contains objects such as logins, endpoints, certificates and databases. The database scope contains objects such as users, roles, assemblies and schemas. The schema scope contains objects such as tables, views, functions and procedures.Permissions define the access that a principal has on a securable. The range of permissions that can be applied has been extended in SQL Server 2005. Each permission can be granted; assigning the permission to a principal that does not have it, revoked; removing the permission from a principal, or denied; disallowing a principal from obtaining a permission.

To govern the SQL Server environment, principals should be assigned the most restrictive permission to a securable that still allows them the access they require.

Lets have a look at the process of a login accessing an object in the database.

Para ter sucesso na conexo com um banco de dados, voc precisa primeiro localizar e conectar ao Servidor de SQL. A conexo feita atravs de um endpoint.Um SQL Server pode ter multiplos endpoints, cada um identificado sobre qual login tem permisso de acess-los

A prxima etapa acessar o Banco de dados. Para fazer isso o login de SQL Server dever configurado (mapeado) a um user com as devidas permisses para acessar o banco

When a Windows user is created, a password for that user must be configured. To maintain security Windows enables the configuration of a policy governing password acceptability. The major features of the policy are the required length of a password, password complexity and password expiration.

SQL Server 2005 can use the Windows password policy of the local machine, or in a domain the domain policy, and enforce the same requirements for SQL Server logins.The sys.sql_logins catalog view enables an administrator to check that all passwords being used meet the policy requirements.

New logins can be created in the SQL Server Management Studio.

The administrator can create a new login and choose to apply the Windows password policy. If the Enforce password expiration option is enabled, the Enforce password policy option must also be enabled.

The Windows password policy can also be applied when using CREATE LOGIN.

The CREATE LOGIN statement is new to SQL Server 2005, and replaces the sp_addlogin and sp_grantlogin stored procedures in previous releases.

It has two parameters that enable the use of the Windows password policy.CHECK_EXPIRATION and CHECK_POLICY can both have values of ON or OFF. If CHECK_EXPIRATION is set to ON then CHECK_POLICY must also be set to ON.

Credencial uma alternativa de login que contm informaes necessrias para se conectar a recursos fora do SQL Server.

Exemplo: Um usurio conectado ao SQL Server usando um login de SQL poderia executar uma stored procedure que acessa uma aplicao ASP.NET que configurada com Windows Authentication.

A Credencial ir mapear o Login de SQL com a conta Windowsatravs da Credencial. Nos padres de definio ANSI SQL-92

Um Schema um container para objetosTodo objeto pertence a um schemaTodos os objetos de um schema tem o mesmo dono, que o dono do schemaAs permisses podem ser atribuidas para schema

Multiplos usurios podem ser donos do schema. Basta criar um grupo Windows ou roles a atribuir como donos do schema

Excluir um usurio

Managing Schemas.Create schema; alter schema; drop schema.

Explain the management of schemas.

0

There are a number of SQL statements that can be used to manage schemas:CREATE SCHEMA is used to create schemas and assign ownership. When you use the statement you can also create database objects and include them as schema members.ALTER SCHEMA is used to change schema ownership and also to move database objects between schemas.DROP SCHEMA is used to remove a schema.

Let's see how the object namespace is made up.

The object namespace includes four levels; server, database, schema, object. When defined in a request, each level is written separated by dot as shown on the slide. The search process automatically uses the default schema that is configured for the user, falling back to the built-in dbo schema if the object is not found in the users default schema.

When you make a request for data, it must include the namespace path to the object you require. The namespace path up to your default schema is automatically assumed by default. Therefore, if you request a table that is a member of your default schema you need only specify the table name. If the table is not found in the users default schema, SQL server 2005 will always search the built-in dbo schema before failingIf you request a table in another schema but still in your default database you must specify the schema and table name.If the object is not in your default database you must specify the database name as well.Sys.database_principals and sys.schemas catalog views return information regard schema owners and default schemas.

Schemas also make dropping users easier than with earlier versions.

Application Compatibility with SQL Server 2005.User schema separation; ownership.

Explain the use of schema separation in SQL Server 2005.

0

SQL Server 2005 does not use the name of the object owner in the objects namespace. The object namespace remains the same irrespective of changes in ownership maintaining application compatibility.

Let's see a demonstration of schema separation.

Control Controla todos os objetos no Banco de dados

Alter Permite ao usurio CRIAR, ALTERAR e DROPAR um Securable e qualquer objeto que esto abaixo dele na hierrquia

Alter Any Permite alterar qualquer securable daquele tipo especificado

Impersonate Permite que um usurio passe suas permisses para outro

Take Ownership Permite dar um take ownership no objeto.

Execuo por contexto habilita um administrador de criar especficos contextos de segurana para executar o cdigo no servidor

O SQL Server usava o SETUSER que fazia essa mudana de contexto na execu ode uma batch . S os membros das roles SysAdmin e db_owner poderiam utilizar esse comando.

Por exemplo, o administrador pode criar uma procedure que leia e grave em uma tabela e configura o contexto de segurana para executar a procedure.

Quem chama a procedure, no precisa de permisso para cumprir as funes dela,

EXECUTE AS CALLER Executa a procedure com as permisses de quem est acessando no momento.

EXECUTE AS USER Utiliza a procedure no contexto de segurana do user X

EXECUTE AS SELF Utiliza a procedure no contexto do usurio que criou a procedure

EXECUTE AS OWNER Executa no contexto de quem o donoA user has EXECUTE permissions on a procedure. The procedure executes and accesses a table in a database that the calling user does not have access to. Because the procedure has been configured to execute with a specific execution context, the table is accessed as the principal configured for the procedure, enabling the user to return the data without being given permissions, even when the ownership chain is broken.In the example shown here, John owns a table called sales.customer. Jane has been granted SELECT permission on this table, but Bill has been denied SELECT permission. Jane owns a stored procedure called GetCusts, which is configured to execute as OWNER. When Bill tries to query the sales.customer table directly, he is denied access. However, when he executes the GetCusts stored procedure, the procedures executes as Jane, returning the data to Bill.This approach does not allow an administrator to audit who is accessing the data as the security context is always the one configured for the procedure, but it can be a useful way to control access to data when you dont want to grant permissions on base tables and views and you have broken ownership chains.The sys.sql_modules catalog view returns information about the security context of procedures.

Let's see a demonstration of this process.

Securables no SQL Server 2005 so agrupados em uma hirarquia:servidor banco de dados Schemas Objeto

Permisses que so atribuidas no mais alto nvel da hierarquia so herdados por securables que esto abaixo.

For example, permisses EXECUTE atribuidas no nvel de bacno de dados, afeta todos os schemas, assumindo que a permisso no seja negada no nvel mais baixo da hierarquia.

As permisses hierarquicas no SQL Server 2005 so mais granulares do que em verses anteriores. Todos os objetos no sistema tem permisses associadas, fazendo com que a poltica de segurana seja mais flexvel

For example, voc poderia atribuir CONTROL permission em todos os objetos LOGIN de um determinado departamento, podendo assim, delegar tarefas.

No nvel de bacno de dados, poder atribuir permisses individuais em todos os objetos para usurios ou roles.

The granular permissions hierarchy in SQL Server 2005 enables administrators to follow the principal of least privilege; assigning only the permissions necessary for each principal to carry out their role.Permission scopes separate the SQL Server environment into different, configurable areas of access. Each scope contains securables specific to that scope.

The highest level is the server scope. The server scope contains securables that effect the server as a whole, such as; logins, HTTP endpoints, certificates, event notifications and databases. Any permissions that are granted at the server scope must be assigned in the Master database.

The server scope contains the database scope. Permissions at the database scope allow principals to execute tasks within the database. Permissions must be assigned in the database to which the permissions apply and the principals must be database users. Securables at the database level include; users, roles, assemblies, full-text catalogs and schemas.The database scope contains the schema scope. The schema scope contains the database objects. Some permissions, such as SELECT, assigned at the schema level effect the objects contained by the schema. Securables at the schema level include; tables, views, functions, procedures, queues and types. Relevant permissions can be inherited from scope to scope. For example SELECT assigned at the database scope will imply SELECT at schema scope which will, in turn, imply SELECT on all database objects. To change this inheritance process specific permissions can be assigned on the schema or object.The implementation of these permission scopes enables an administrator to implement a secure, robust environment where permissions are specific to the requirement of the principal.Specific permissions can be assigned to principals for specific objects., allowing them to carry out their assigned tasks. This removes the need to assign default server roles, such as sysadmin, that provide additional permissions that are not required.Server permissions can be viewed in the sys.server_permissions catalog view.

Database Scope.Permissions; Database scope.Explain permissions at the database scope.0

Permissions assigned at the database scope can be specific to an object within the scope or assigned on the database. Permissions assigned on the database can affect all schema objects within the database.Database permissions can be viewed in the sys.database_permissions catalog view.

Let's have a look at the schema scope.

Schema Scope.Permissions; Schema scope.Explain permissions at the schema scope.0

Permissions assigned at the schema scope can be specific to an object within the scope or assigned on the schema. Permissions assigned at the schema level can effect all relevant member objects.

Finally Let's have a look at the objects themselves.

Individual Objects.Permissions; Database objects.Explain permissions for individual objects.0

Permissions assigned to the individual objects are specific to that object. If a permission is assigned to an object, the permission is enabled at the database and schema scope unless there is a specific deny assigned at either level.

Let's see a demonstration of granular permissions.