Sistemas de Informação Redes de Computadores

Apresentação em tema: "Sistemas de Informação Redes de Computadores"— Transcrição da apresentação:

1

2 Sistemas de Informação Redes de Computadores
Análise e Desenvolvimento de Sistemas Administração de Banco de Dados 1º Semestre – 2011 Pedro Antonio Galvão Junior Fone: Versão – Fev/2011.

3 SEGURANÇA NO MICROSOFT SQL SERVER 2008

4 Oferecendo Segurança Políticas de senhas no login de SQL Server
Hierarquia dos escopos Separação de usuários do schema Limite de visualização dos metadados Execução pelo contexto Políticas de senhas Windows® logins or SQL Server logins, in the same manner used by previous versions of SQL Server. In this release of SQL Server, you can also apply password policies to SQL Server logins. These policies act similarly to how Windows enables password restrictions for Windows logins. Hierarquia dos escopos SQL Server 2005 provides a consistent model for securing objects at different scopes by using a hierarchical arrangement of principals, securables, and permissions. This new approach helps make security more manageable than in previous releases. Schema In previous releases of SQL Server, object namespaces were dictated by the object owner. In SQL Server 2005, object namespaces are determined by using schemas, independent of the object owner. This separation of owner from object namespace provides a more flexible and manageable framework. Limite da visualização dos metadados The introduction of catalog views in SQL Server 2005 results in limited visibility of metadata. By default, users can view metadata only for objects for which they have been granted permissions. Execução pelo contexto The execution context of programmable modules (such as stored procedures or functions) now can be set explicitly in the CREATE statement. This feature enables the object creator to specify the user account under which the object will execute, making it possible to control access to dependent objects without relying on ownership chains.

5

6 Seguro por default Serviços e features desligadas por padrão
Permite somente conexão local Usa o SAC para habilitar/desabilitar as features Windows Server 2003 SQL Server 2005 Upgrade preserva as configurações Serviços e Features novas desabilitadas Usa o SAC para habilitar/desabilitar as features Windows Server 2003 SQL Server 2000

7 MODELOS DE SEGURANÇA NO
MICROSOFT SQL SERVER 2008

8 Mecanismos de Segurança
Autenticação Usuário e senha Certificados Autorização Permissões Criptografia Chaves Simétricas Chaves Assimétricas 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. </SLIDESCRIPT> <SLIDETRANSITION> Let’s see how SQL Server limits access to data and functionality. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>

9 Componentes dE Segurança
Principals Windows Groups Domain account Local account SQL Server SQL account Server role Database User Database role Application role Group Securables Server Scope Logins Endpoints Databases Database Scope Users Assemblies Schemas Schema Scope Tables Procedures Views Permissions Grant/Revoke/Deny Create Alter Drop Control Connect Select Execute Update Delete Insert Existem 3 componentes que são usados para limitar o acesso às features e as funcionalidades do SQL: principals, securables and permissions. Principal é qualquer identidade autenticada que possa ser dada permissão para acessar algum objeto do SQL SERVER. Exemplos: Usuários Windows, Grupos, etc Securables são recursos. São objetos que recebem permissões Acesso 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 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. </SLIDESCRIPT> <SLIDETRANSITION> Let’s have a look at the process of a login accessing an object in the database. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> QUEM PODE ACESSAR O QUE

10 Processo de Acesso Seguro
Pedido de conexão pela rede / pre-login handshake Conexão ao servidor SQL Server Para ter sucesso na conexão com um banco de dados, você precisa primeiro localizar e conectar ao Servidor de SQL. A conexão é feita através de um endpoint. Um SQL Server pode ter multiplos endpoints, cada um identificado sobre qual login tem permissão de acessá-los A próxima etapa é acessar o Banco de dados. Para fazer isso o login de SQL Server deverá configurado (mapeado) a um user com as devidas permissões para acessar o banco Autenticação do Login no SQL Server Estabelecer login Acesso ao database Estabelecer acesso ao database Tentar realizar alguma ação Verificar as permissões para todas as ações

11 Política de Senhas Requer Windows Server 2003. Autenticação Windows:
Login de usuários Windows Respeita a política de senhas do Windows Autenticação SQL Server: Logins SQL Server Respeita a política de senhas da máquina local. Política de Domínio se estiver em um ambiente de Domínio sys.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.

12 Configuração da Politica de Senhas
Criando Logins 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. </SLIDESCRIPT> <SLIDETRANSITION> The Windows password policy can also be applied when using CREATE LOGIN. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> Configuração da Politica de Senhas

13 Configuração da Politica de Senhas
Criando Logins 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 Configuração da Politica de Senhas 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.

14 Usa a API NetValidatePasswordPolicy() do Windows Server 2003
OPÇÕES DE LOGIN Opção Descrição HASHED Especifica que a senha já está criptografada MUST_CHANGE Avisa o usuário que precisa mudar a senha. Precisa de CHECK_EXPIRATION e CHECK_POLICY habilitado CHECK_EXPIRATION Expiração de senhas. Se estiver ON, as políticas são Aplicadas e requer que CHECK_POLICY esteja ON CHECK_POLICY Faz a checagem das políticas de senha Usa a API NetValidatePasswordPolicy() do Windows Server 2003

15 Gerenciando Logins Removendo um Login DROP LOGIN <Login_name>
Alterando um Login ALTER LOGIN <login_name> WITH PASSWORD = '3948wJ698FFF7'

16 Credenciais Alternativa aos logins.
Permitem conexão a recursos fora do SQL Server. CREATE CREDENCIAL <nome> WITH IDENTITY = ‘identity name’, SECRET = ‘secret’ Credencial é uma alternativa de login que contém informações necessárias para se conectar a recursos fora do SQL Server. Exemplo: Um usuário conectado ao SQL Server usando um login de SQL poderia executar uma stored procedure que acessa uma aplicação ASP.NET que é configurada com Windows Authentication. A Credencial irá mapear o Login de SQL com a conta Windowsatravés da Credencial.

17 SCHEMAS DE SEGURANÇA

18 Especifica o schema default
Default Schema Um schema default pode ser atribuido quando o usuário do banco de dados é criado. Nos padrões de definição ANSI SQL-92 Um Schema é um container para objetos Todo objeto pertence a um schema Todos os objetos de um schema tem o mesmo dono, que é o dono do schema As permissões podem ser atribuidas para schema Multiplos usuários podem ser donos do schema. Basta criar um grupo Windows ou roles a atribuir como donos do schema Excluir um usuário CREATE USER user_name [ FOR {LOGIN login_name | CERTIFICATE cert_name | ASYMMETRIC KEY asym_key_name } ] [ WITH DEFAULT_SCHEMA = schema_name ] Especifica o schema default

19 Gerenciando Schemas CREATE SCHEMA Cria um schema
Atribui um ownership para o schema Cria objetos de database como membros do schema ALTER SCHEMA Altera o ownership do schema Move objetos de database entre schemas DROP SCHEMA Remove um schema <SLIDETITLE>Managing Schemas.</SLIDETITLE> <KEYWORDS>Create schema; alter schema; drop schema.</KEYWORDS> <KEYMESSAGE> Explain the management of schemas. </KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> 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. </SLIDESCRIPT> <SLIDETRANSITION> Let's see how the object namespace is made up. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION>

20 Servidor.BancoDados.Schema.Objeto
Object Namespace 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 user’s default schema. Sales Customer LON-SQL-01 AdventureWorks Servidor.BancoDados.Schema.Objeto

21 Atribuindo Database Objects
Sales Customer SELECT * FROM Customer 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 failing If 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. </SLIDESCRIPT> <SLIDETRANSITION> Schemas also make dropping users easier than with earlier versions. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> SELECT * FROM JobCandidate dbo SELECT * FROM dbo.JobCandidate [ WITH DEFAULT_SCHEMA = Sales ] JobCandidate sys.database_principals catalog view sys.schemas catalog view

22 Application Compatibility
Propriedade de Celia Sales SELECT CustomerID FROM Sales.Customer App <SLIDETITLE>Application Compatibility with SQL Server 2005.</SLIDETITLE> <KEYWORDS>User schema separation; ownership.</KEYWORDS> <KEYMESSAGE> Explain the use of schema separation in SQL Server 2005. </KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> 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. </SLIDESCRIPT> <SLIDETRANSITION> Let's see a demonstration of schema separation. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> Customer Alterando o proprietário para Katia Sales SELECT CustomerID FROM Sales.Customer App Customer

23 USUÁRIOS

24 Usuários Acesso ao Banco de dados;
Pode ser mapeado para um login individual ou para um grupo Windows; e Pode 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 ]

25 Gerenciando Usuários Apagando um usuário: DROP USER <user_name>
Alternado configurações de um usuário: ALTER USER <user_name> WITH DEFAULT_SCHEMA = <nome_schema>

26 Componentes de Segurança e Permissões
Permissão Descrição CONTROL Atribui permissões de proprietário e garante todas as permissões ao principal no objeto ALTER Atribui permissões de alterar, criar ou excluir a qualquer securable, menos trocar o proprietário ALTER ANY Atribui permissão de alteração de qualquer securable do tipo especificado. IMPERSONATE Permissão de trocar o contexto de execução para o contexto de execução de outro usuário TAKE OWNERSHIP Atribui permissão ao usuário para assumir a propriedade do securable Control  Controla todos os objetos no Banco de dados Alter  Permite ao usuário CRIAR, ALTERAR e DROPAR um Securable e qualquer objeto que estão abaixo dele na hierárquia Alter Any  Permite alterar qualquer securable daquele tipo especificado Impersonate  Permite que um usuário passe suas permissões para outro Take Ownership  Permite dar um take ownership no objeto.

27 MÓDULOS DE EXECUÇÃO PELO CONTEXTO

28 INTRODUÇÃO Configura a execução pelo contexto de módulos;
Caller não requer permissões: Effective with broken ownership chain EXECUTE AS: Caller (Default) Username (requer permissão Impersonate) Self Owner Execução por contexto habilita um administrador de criar específicos contextos de segurança para executar o código no servidor O SQL Server usava o SETUSER que fazia essa mudança 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 segurança para executar a procedure. Quem chama a procedure, não precisa de permissão para cumprir as funções dela, EXECUTE AS CALLER  Executa a procedure com as permissões de quem está acessando no momento. EXECUTE AS USER  Utiliza a procedure no contexto de segurança do user X EXECUTE AS SELF  Utiliza a procedure no contexto do usuário que criou a procedure EXECUTE AS OWNER  Executa no contexto de quem é o dono

29 PROCESSO DE EXECUÇÃO PELO CONTEXTO
DENY SELECT ON sales.customer TO Bill GRANT SELECT ON sales.customer TO Jane 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 don’t 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. </SLIDESCRIPT> <SLIDETRANSITION> Let's see a demonstration of this process. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> CREATE PROCEDURE GetCusts WITH EXECUTE AS OWNER AS SELECT * FROM sales.customer Bill Jane sales.customer (Owner:John) Stored Procedure (Owner: Jane) sys.sql_modules catalog view

30 PERMISSÃO GRANULAR Securables organizados em uma hierarquia:
Herança de permissões. Todos os objetos tem permissões associadas. Principal de menor previlégio. Securables no SQL Server 2005 são agrupados em uma hirarquia: servidor  banco de dados  Schemas  Objeto Permissões que são atribuidas no mais alto nível da hierarquia são herdados por securables que estão abaixo. For example, permissões EXECUTE atribuidas no nível de bacno de dados, afeta todos os schemas, assumindo que a permissão não seja negada no nível mais baixo da hierarquia. As permissões hierarquicas no SQL Server 2005 são mais granulares do que em versões anteriores. Todos os objetos no sistema tem permissões associadas, fazendo com que a política de segurança seja mais flexível For example, você poderia atribuir CONTROL permission em todos os objetos LOGIN de um determinado departamento, podendo assim, delegar tarefas. No nível de bacno de dados, poderá atribuir permissões individuais em todos os objetos para usuários 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.

31 ESCOPOS DE PERMISSÕES Servidor:
O banco de dados Master deverá ter permissões Grant; e Permissões específias para cada securable. Database: Pode atribuir permissões específicas para roles customizadas; Permitir principals de executar tarefas no banco; e Permissões Grant deverão ser atribuidas ao banco que contém o securable que quer aplicar a permissão. Schema: Usado para agrupar objetos de database; e Atribuir permissões 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.

32 Escopo Server 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. <ITEM></ITEM> </ADDITIONALINFORMATION> GRANT CONTROL ON LOGIN::Tom TO Fred Control permission on individual login Permissão GRANT em securables individuais quando as permissões da server role default são inapropriadas. sys.server_permissions catalog view.

33 Escopo Banco de dados Permissões herdadas no banco de dados Sales
Sales.AddOrder Accounts <SLIDETITLE>Database Scope.</SLIDETITLE> <KEYWORDS>Permissions; Database scope.</KEYWORDS> <KEYMESSAGE>Explain permissions at the database scope.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> 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. </SLIDESCRIPT> <SLIDETRANSITION> Let's have a look at the schema scope. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> Accounts.AddAcct GRANT EXECUTE TO Jim HR Permissões herdadas no banco de dados HR.ViewEmps sys.database_permissions catalog view

34 GRANT SELECT ON SCHEMA::Sales TO Mary
Escopo Schema sales.customers Sales <SLIDETITLE>Schema Scope.</SLIDETITLE> <KEYWORDS>Permissions; Schema scope.</KEYWORDS> <KEYMESSAGE>Explain permissions at the schema scope.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> 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. </SLIDESCRIPT> <SLIDETRANSITION> Finally Let's have a look at the objects themselves. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> sales.accounts GRANT SELECT ON SCHEMA::Sales TO Mary Permissões herdadas no schema sales.figures

35 GRANT SELECT ON sales.accounts TO Joe
Objetos Individuais sales.customers <SLIDETITLE>Individual Objects.</SLIDETITLE> <KEYWORDS>Permissions; Database objects.</KEYWORDS> <KEYMESSAGE>Explain permissions for individual objects.</KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> <SLIDESCRIPT> 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. </SLIDESCRIPT> <SLIDETRANSITION> Let's see a demonstration of granular permissions. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM></ITEM> </ADDITIONALINFORMATION> sales.accounts GRANT SELECT ON sales.accounts TO Joe Sales.accounts Permissões somente para objetos específicos sales.figures

36