Adm. Banco de Dados - Aula 03 - 17 de Fevereiro

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
E-mail: [email protected] Fone: 9531-7555
[email protected]
Versão 1.11.02 – Fev/2011.
SEGURANÇA NO
MICROSOFT SQL SERVER 2008
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
SEGURO POR DEFAULT
Windows Server 2003
SQL Server 2005
Windows Server 2003
SQL Server 2000
•
Serviços e features desligadas por padrão
•
Permite somente conexão local
•
Usa o SAC para habilitar/desabilitar as features
•
Upgrade preserva as configurações
•
Serviços e Features novas desabilitadas
•
Usa o SAC para habilitar/desabilitar as features
MODELOS DE SEGURANÇA NO
MICROSOFT SQL SERVER 2008
MECANISMOS DE SEGURANÇA
• Autenticação
– Usuário e senha
– Certificados
• Autorização
– Permissões
• Criptografia
– Chaves Simétricas
– Chaves Assimétricas
COMPONENTES DE SEGURANÇA
Principals
• Windows
– Groups
– Domain account
– Local account
•
SQL Server
– SQL account
– Server role
•
Database
–
–
–
–
User
Database role
Application role
Group
Permissions
Grant/Revoke/Deny
–
–
–
–
–
–
–
–
–
–
Create
Alter
Drop
Control
Connect
Select
Execute
Update
Delete
Insert
Securables
Server Scope
– Logins
– Endpoints
– Databases
Database Scope
– Users
– Assemblies
– Schemas
Schema Scope
– Tables
– Procedures
– Views
Processo de Acesso Seguro
Pedido de conexão pela rede / pre-login handshake
Conexão ao servidor SQL Server
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
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
CRIANDO LOGINS
Configuração
da Politica de
Senhas
CRIANDO LOGINS
CREATE LOGIN login_name { WITH < option_list1 > | FROM < sources > }
< sources >::=
WINDOWS [ WITH windows_options [,...] ]
Configuração
| CERTIFICATE certname
da Politica de
| ASYMMETRIC KEY asym_key_name
< option_list1 >::=
Senhas
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
OPÇÕES DE LOGIN
Opção
HASHED
Descrição
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
GERENCIANDO LOGINS
Removendo um Login
DROP LOGIN <Login_name>
Alterando um Login
ALTER LOGIN <login_name> WITH
PASSWORD = '3948wJ698FFF7'
CREDENCIAIS
• Alternativa aos logins.
• Permitem conexão a recursos fora do SQL Server.
CREATE CREDENCIAL <nome> WITH IDENTITY = ‘identity name’, SECRET = ‘secret’
SCHEMAS DE SEGURANÇA
DEFAULT SCHEMA
• Um schema default pode ser atribuido quando o usuário do banco de dados é
criado.
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
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
OBJECT NAMESPACE
Sales
Customer
LON-SQL-01
AdventureWorks
Servidor.BancoDados.Schema.Objeto
ATRIBUINDO DATABASE OBJECTS
Sales
SELECT * FROM Customer
SELECT * FROM JobCandidate
SELECT * FROM
dbo.JobCandidate
Customer
dbo
[ WITH DEFAULT_SCHEMA = Sales ]
JobCandidate
•
sys.database_principals catalog view
•
sys.schemas catalog view
APPLICATION COMPATIBILITY
Propriedade de Celia
Sales
App
SELECT CustomerID FROM
Sales.Customer
Customer
Alterando o proprietário para Katia
Sales
App
SELECT CustomerID FROM
Sales.Customer
Customer
USUÁRIOS
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 ]
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>
Componentes de Segurança
e Permissões
Permissão
CONTROL
ALTER
ALTER ANY
IMPERSONATE
Descrição
Atribui permissões de proprietário e garante todas as
permissões ao principal no objeto
Atribui permissões de alterar, criar ou excluir a
qualquer
securable, menos trocar o proprietário
Atribui permissão de alteração de qualquer securable
do tipo especificado.
Permissão de trocar o contexto de execução para o
contexto de execução de outro usuário
Atribui permissão ao usuário para assumir a
TAKE OWNERSHIP
propriedade do securable
MÓDULOS DE EXECUÇÃO
PELO CONTEXTO
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
PROCESSO DE EXECUÇÃO PELO
CONTEXTO
DENY SELECT ON
sales.customer TO
Bill
Bill
CREATE PROCEDURE GetCusts
WITH EXECUTE AS OWNER
AS
SELECT *
FROM sales.customer
Stored Procedure
(Owner: Jane)
•
sys.sql_modules catalog view
GRANT SELECT ON
sales.customer TO
Jane
Jane
sales.customer
(Owner:John)
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.
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.
ESCOPO SERVER
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.
ESCOPO BANCO DE DADOS
Sales
Sales.AddOrder
Accounts
Accounts.AddAcct
GRANT EXECUTE
TO Jim
HR
Permissões herdadas
no banco de dados
•
sys.database_permissions catalog view
HR.ViewEmps
ESCOPO SCHEMA
sales.customers
Sales
sales.accounts
GRANT SELECT ON
SCHEMA::Sales TO Mary
Permissões herdadas no schema
sales.figures
OBJETOS INDIVIDUAIS
sales.customers
sales.accounts
Sales.accounts
GRANT SELECT ON
sales.accounts TO Joe
Permissões somente para
objetos específicos
sales.figures