Arquivo da categoria: DIVERSOS

DIVERSOS

GOVERNO CORTA NOMEAÇÕES E NOVOS CONCURSOS: E AGORA?

1 Comentário

Estou indicando aqui a leitura de um artigo muito bom e tranqüilizador para o pessoal que está estudando sério pra concursos.

O colega Cleber Olympio aborda de forma excelente essa questão lá no blog “Concurseiro Solitário”. Vale a pena conferir.

http://concurseirosolitario.blogspot.com/2011/02/governo-corta-nomeacoes-e-novos_15.html

Lembrando que o concurso da EsFCEX não é afetado por essa medida de contenção de gastos do governo.Por isso, siga valente no seu projeto de estudo.

Grande abraço, Emanuel Peixoto.

DIVERSOS

MONITORAÇÃO DE PROCESSOS UTILIZANDO O PROFILE.

2 Comentários

O profile é uma ferramenta muito boa para monitoramento de rotinas que estão sendo executadas pela engine do SQL Server.
APLICABILIDADE
Podemos utilizar o profiler para atender as seguintes necessidades:
– Verificação de queries lentas.
– Verificação de quantidade de recursos de processamento, memória e disco que estão sendo utilizados pelas rotinas que estão sendo executadas pela engine do SQL Server
– Audidoria de processos.
– Auditoria de conexões(Logins)
– Auditorias de Backup
– Monitoramento e detecção de erros internos do SQL Server
– Debug de rotinas.
– Monitoramento de crescimento de databases.
– Reprodução do resultado dos comandos capturados pelo profile em outro servidor, essa é uma alternativa bastante interessante quando desejamos realizar uma análise fiel em um ambiente de teste dos comandos capturados em produção.
A prática do recurso de reprodução dos comandos capturados pelo profile (salvos em tabela ou arquivo) é bastante utilizada em conjunto com o “DTA – Database Tuning Advisior” em um ambiente de teste.
COMO INICIAR O PROFILE PARA REALIZAR O MONITORAMENTO.
Existem várias formas de se chamar o profile, vejam abaixo:
1 – A partir do SQL Server Management Studio
No menu “tools” você encontra a opção “SQL Server Profiler”
2 – A partir do propt de comando, chamando o aplicativo, “PROFILER.EXE”( SQL 2000 ) ou “PROFILER90.EXE” ( SQL 2005 ).
3 – Através do atalho do programa existente nos menus dos programas instalados no windows.

Tela 1.0


Conhecendo as configurações o profiler
Na tela abaixo(Tela 1.1) você possue as seguintes opções:
1 – Definição do nome do profile
2 – Possui alguns templates de análise pré-definidos, esses templates são exemplos de contadores mais utilizados, ou seja, com finalizadas pré-definidas.
3 – Opção para definir um local para o armazenamento do arquivo de trace(Opcional).
4 – Opção para definir que o local de armazenamento possa ser uma tabela em um servidor SQL(Opcional).
5 – Configuração para informar até em que momento o profile estará executando.

Tela 1.1


Na tela aseguir (Tela 1.2), exploramos opções que personalizam quais contadores irão ser monitorados e de que forma serão apresentados.
Opções da tela:
5 – “Event selections” é a aba onde você irá informar os contadores e a forma de visualização dos eventos coletados.
6 – Permite mostrar para o usuário mais eventos que podem ser monitorados.
7 – Para cada evendo monitorado, você pode detalhar as informações sobre o evento, por exemplo, o evento”RPC:Completed” pode informar o computador que originou o comando, dentre outras informações.
8 – Permite filtrar os dados coletados, exemplo: só coletar dados de um determinado login, computador, etc… um filtro que é bastante utilizado é o duration, onde é possível que você determine por exemplo que só seja capturado comandos que tenham a duração maior que x segundos, no caso do filtro, você deve informar em milesegundos, exemplo: informe no filtro 2000, se desejar filtrar por 2 segundos.
9 – Nesta opção, poderá ordenar e agrupar os dados coletados.
Dica: se você está avaliando tempos, agrupe a sua coleta por duração”duration”, exemplo (Tela 1.2):

Tela 1.2

Tela 1.3
DIVERSOS

CONFIGURANDO AS CONTA DE SERVIÇO DO SQL SERVER

5 Comentários
 
CONFIGURANDO AS CONTA DE SERVIÇO DO SQL SERVER
 
Um dos pré-requisitos para se ter um ambiente seguro é configurar as conta de serviço do SQL Server com um usuário do windows que não possua privilégios administrativos nos servidores e sistemas de arquivos.
 
Não é necessário que o usuário de serviço seja incluído em nenhum grupo especial com poderes de administradores.
Em questão de segurança da conta de serviço do SQL Server, quanto menos privilégio a conta tiver, melhor será.
 
São inúmeros os motivos que nos direcionam a aumentar o nível de segurança nesse ponto. Alterar a conta de serviço do SQL Server é interessante para os seguintes ítens:
 
  • Diminuir as possibilidades execução de comandos não autorizados nos servidores.
  • Melhorar o controle das permissões de acesso ao servidor.
  • Limitar acessos desnecessários ao sistema de arquivo.
Para configurar os serviços do SQL Server para iniciar com uma conta sem privilégios, seja uma conta local ou de domínio, é necessário seguir algumas recomendações obrigatórias, abaixo, segue roteiro para essa configuração.
 
Os procedimentos são simples e eu garanto que mesmo os inexperientes conseguirão, em menos de 15 minutos, executar os procedimentos existentes nesse passo-a-passo. 
 
Então, deixemos de bla, bla, blá…e vamos logo ao que interessa:
 
1 – Crie uma conta local ou de domínio.
Crie uma conta local ou de domínio. Certifique-se de marcar a opção "A senha nunca expira" para evitar que essa conta entre em uma política de alteração de senha, pois, como não existirá um usuário fisicamente usando a conta, isso evitará que a senha expire e o SQL Server tenha problemas.
 
2 – Conceda a essa conta acesso total (full) aos diretórios de instalação.
Se o SQL Server foi instalado no local padrão, então o local é: "C:Arquivos de programasMicrosoft SQL Server"
Caso os arquivos de dados dos databases estejam em outro local, não se esqueça de conceder acesso full para essa conta de serviço.

 
3 – Adicione o login do usuário no SQL Server e adicione-o  na role sysadmin.
Uma das exigências de se configurar uma conta de serviço que não tenha privilégios desnecessários no windows é que a nível de SQL, o usuário necessita de acesso irrestrito, por isso, existe a necessidade de que o usuário seja adicionado a role sysadmin.
Para adicionar basta executar no query editor (SSMS ou QA) os comandos abaixo:
 
Caso um login para o usuário não exista crie:
Create login [nome_login] from windows
 
Adicione o login na role sysadmin:
sp_addsrvrolemember [nome_usuário],sysadmin
 
Dúvidas sobre esses comandos, recomendo consultar o BOL.
 
4 – Altere a conta de serviço para o usuário definido.
Utilizando o gerenciador de serviços("Services.msc"), altere a conta de serviço para o usuário definido para essa finalidade. 
 
5 – Conceda permissões nas diretivas locais.
Conceda à conta de serviço permissões para logon local, logon como serviço, criação de tokens e gerenciamento de memória.
Essas permissões são necessárias para que o usuário possa inicializar os serviços em background.
 
Utilize o MMC para iniciar o local policy (diretivas locais ou diretivas de grupo) no WINDOWS, adicione o usuário nas seguintes políticas:
 
* Create tokens
* Logon local
* Login as a service
* Lock page in memory
 
6 – Conceda permissão no registro.
Conceda ao usuário acesso full nas chaves citadas abaixo, isso para que o usuário de serviço tenha acesso a parâmetros que só seriam acessíveis se ele pertencesse a grupos com poderes administrativos no servidor.
 
Só são 04 chaves para dar acesso full:
 
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL Server
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServer
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSSQLSERVER
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSQLSERVERAGENT
 
Nota:
Observe que as últimas duas chaves apontam para caminhos que são para instalação de instância default, caso a instância seja nomeada, então, procure por MSSQL$SQL2000 ou SQLSERVERAGEN$SQL2000, onde $SQL2000 é um exemplo de uma instância nomeada, em resumo sempre será algo do tipo:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSSQL$[NOME_DA_INSTANCIA_NOMEADA]
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSQLSERVERAGENT$[NOME_DA_INSTANCIA_NOMEADA]
 
 
Pronto, esses são os passos para que você possa configurar uma conta de serviço sem privilégios administrativos.
Para mim, esses passos já estão no sangue, são procedimento bastantes simples e que não levam mais de 5 minutos para serem realizados.
Espero que os especialistas que utilizarem os procedimentos contidos nesse blog possam comentar e sugerir melhoramentos aos procedimentos, se acharem pertinentes.
 
Um grande abraço e até a próxima.
 
Emanuel Peixoto.
 

DIVERSOS

"CONFIGURANDO TRIGGERS DE LOGON"

Deixe um comentário
 
Estou de volta ao meu blog, após algumas semanas afastado… estou em meio há uns projetos que estão consumindo todo o meu tempo. Gostaria muito de ter mais tempo para poder me dedicar aos FÓRUNS MSDN E TECHNET BRASIL….
 
Irei abordar, hoje, um assunto bastante interesante que são as DDLs Trigers de logon.
Esse tópico no meu blog foi motivado por uma dúvida de um dos participantes dos fóruns Microsoft.
Abaixo o link da dúvida.
 
 
Em resumo, o participante desejava saber se existia alguma forma do SQL Server realizar a validação de um login que originasse a conexão de um host previamente "autorizado" pelo SQL Server.
 
A princípio, o SQL Server não possui um recurso que possa realizar esse tipo de validação, pois, o que o servidor faz é validar o login e suas permissões no nível de servidor ou do database.
 
Para a solução desse problema, sugeri a utilização de "TRIGGERS DE LOGON", que é um recurso destinado a execução de procedimento no momento que são disparados eventos de logon no SQL Server.
 
Abaixo, irei introduzir o conceito básico das DDLs e, também, postar um exemplo de "DDL TRIGGERS DE LOGON".
 
DDL TRIGGERS OVERVIEW
 
A DDL trigger é um dos inúmeros recursos criados pela Microsoft e disponibilizados a partir do SQL 2005 para disparar qualquer rotina no momento que é detectada a execução de comandos DDL(Data Definition Language). Os comandos DDLs mais comuns são: create, drop, alter.
 
 
QUANDO USAR DDLs TRIGGERS:
 
  • Evitar alteração nos esquemas de objetos.
  • Auditar eventos relacionados a DDLs
  • Disparar alertas quando detectado comandos DDLs
  • Implementar eventos subsequentes a DDLs
No nosso cenário de exemplo, um DBA deseja criar um mecanismo de controle de acesso, onde um determinado login só poderá realizar uma conexão com um servidor SQL Server 2005/2008 caso o login esteja autorizado a connectar-se a partir de um host pré-determinado.
 
No exemplo a seguir, foi criada uma tabela de controle onde podemos cadastrar os logins e os computadores aos quais podem realizar conexões.
Basta seguir o script abaixo para reproduzir o teste que realizei.
 

— Tabela de controle de permissões

use master
go
create

table logins_computadores

(

codlogin int identity,

nomeLogin

varchar(30),

nomeComputador

varchar(30))

go
 

–Inserção dos logins e computadores permitidos para os logins.

use master
go
insert

into logins_computadores values(‘Emanuel’,‘D001SQL01’)

insert

into logins_computadores values(‘Emanuel’,‘D001SQL02’)

insert

into logins_computadores values(‘Emanuel’,‘D001SQL03’)

insert

into logins_computadores values(‘BUILTINAdministradores’,‘ALL’)

/*
Caso o login Emanuel tente realizar uma conexão a partir dos computadores D001SQL01,D001SQL01 ou D001SQL01 a conexão será realizada com sucesso.
se o login Emanuel tentar realizar a conexão a partir de outro computador a trigger irá bloquear o acesso.
O login "SA" não entra nessa rotina, ou seja, de qualquer computador é possível se conectar através desse login.
Caso você deseje que um determinado login tenha acesso a partir de qualquer computador, adicione o login na tabela de controle informando o valor ‘ALL’ para "nomeComputador".
*/

go
 
–Trigger de exemplo.

use master
go

CREATE

TRIGGER [Tr_DDL_Seguranca]

ON

ALL SERVER

FOR

LOGON

AS
BEGIN
declare

@ori_login varchar(40)

declare

@computador varchar(40)

set

@ori_login= ORIGINAL_LOGIN()

set

@computador = host_name()

IF

ORIGINAL_LOGIN() <> ‘sa’

  IF not exists (select 1 from logins_computadores where NomeLogin = @ori_login and nomecomputador=‘ALL’)

    IF not exists (select 1 from logins_computadores where nomeLogin = @ori_login and nomecomputador=@computador)

ROLLBACK;

END

GO

— HABILITA TRIGGER

ENABLE

TRIGGER [Tr_DDL_Seguranca] ON ALL SERVER

 
— DESABILITA TRIGGER
–DISABLE TRIGGER [Tr_DDL_Seguranca] ON ALL SERVER

go
 
 
 
AUMENTANDO A SEGURANÇA.
 
Caso exista a necessidade de realizar uma configuração mais rígida, podemos forçar que o SQL Server use uma trigger para que nenhum login possa ter acesso, caso o computador não esteja devidamente AUTORIZADO, com excessão de conexões originadas a partir do próprio servidor.
Esse modelo é ideal para garantir a segurança em ambientes onde o servidor pode estar exposto a tentativas de invasão, como por exemplo a WEB.
 
CREATE TRIGGER [Tr_DDL_Seguranca]

ON

ALL SERVER

FOR

LOGON

AS
BEGIN
declare

@ori_login varchar(40)

set

@ori_login= ORIGINAL_LOGIN()

IF

HOST_NAME() <> @@servername

  IF not exists (select 1 from logins_computadores where NomeLogin = @ori_login and nomecomputador=‘ALL’)

    IF not exists (select 1 from logins_computadores where nomeLogin = @ori_login and nomecomputador=HOST_NAME())

ROLLBACK;

END

 
 
Bem, os exemplos acabam aqui, espero que seja util para os que desejarem implementar um nível de segurança mais refinado utilizando triggers DDL.
Na próxima, falarei sobre segurança SSL no SQL Server.
 
Um grande abraço, Emanuel Peixoto.