1)
CREATE SYMMETRIC KEY SecureSymmetricKey
WITH ALGORITHM = DESX
ENCRYPTION BY PASSWORD = N'StrongPassword';
Estou tentando descobrir sobre a criptografia do SQL Server.
- depois de executar o código acima, existe alguma maneira de descobrir mais tarde qual é o valor da senha para o
SecureSymmetricKey
?
2)
Se agora estou fazendo isso com Certificates
: sou (o administrador) criado
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'DB Master key password!'
GO
só eu sei a senha.
mais tarde eu :
CREATE CERTIFICATE MyCertificate
WITH SUBJECT = 'My Certificate Subject'
CREATE SYMMETRIC KEY MySymetricKey
WITH ALGORITHM = TRIPLE_DES ENCRYPTION
BY CERTIFICATE MyCertificate
até agora, está tudo bem.
agora, quando um hacker chega ao computador, tudo o que ele precisa fazer é :
OPEN SYMMETRIC KEY MySymetricKey DECRYPTION
BY CERTIFICATE MyCertificate
e depois :
SELECT
convert( NVARCHAR(max), decryptbykey(namePAss))
FROM tbl1
então, onde está a proteção nos certificados? ninguém pediu uma senha a ele (como na criptografia de senha (como na minha primeira pergunta) ...? ele só precisava saber o nome do certificado
ABRIR CHAVE SIMÉTRICA MySymetricKey DECRIPTOGRAFIA POR CERTIFICADO MyCertificate
e não é um problema descobrir qual é o nome do certificado ... Então, onde está a proteção em decifrar dados do Hacker?
3)
quando estou usando
CREATE SYMMETRIC KEY SecureSymmetricKey
WITH ALGORITHM = DESX
ENCRYPTION BY PASSWORD = N'StrongPassword';
DECLARE @str NVARCHAR(100)
SET @str = 'lala';
OPEN SYMMETRIC KEY SecureSymmetricKey
DECRYPTION BY PASSWORD = N'StrongPassword';
De quem estou tentando proteger os dados? os dados sendo enviados do cliente para o servidor? (os dados estão sendo enviados por texto simples - não consigo ativar os comandos SQL antes de enviar os dados...) ou pessoas que tenham acesso ao servidor SQL?
Você está protegendo contra perda acidental de mídia (um laptop perdido com o banco de dados, sua unidade aparecendo em um mercado de pulgas com uma cópia do banco de dados ou de um backup) etc etc. Qualquer esquema no qual o próprio processamento (o mecanismo de banco de dados ou o aplicativo) requer acesso aos dados sem que o usuário forneça uma senha , apenas oferece acesso contra perda de mídia. A hierarquia da chave de criptografia tem como raiz a chave criptografada DPAPI do sistema, ou seja, a senha da conta de serviço. Esse cenário nunca protege contra um hacker que obtém acesso ao seu SQL Server e não se destina a protegê-lo.
A alternativa é pedir uma senha ao usuário toda vez que ele usar o aplicativo e usar essa senha para abrir a chave no topo da hierarquia de chaves de criptografia (geralmente um certificado no banco de dados). Esse esquema raramente é implantado em casos como alguns cenários de vários locatários, quando os locatários não confiam nas operações/administradores de hospedagem.
A proteção é que, se alguém obtiver uma cópia desse banco de dados (através do roubo do backup, fazendo um instantâneo SAN dos bancos de dados do usuário, roubando os discos rígidos dos bancos de dados do usuário, etc) e tentar anexá-los a outro SQL Server, eles não será capaz de fazê-lo.
Não protege tudo - é apenas uma parte da imagem. Para mais informações, confira o excelente livro Securing SQL Server de Denny Cherry:
http://www.amazon.com/Securing-SQL-Server-Protecting-Attackers/dp/1597496251/ref=sr_1_1?ie=UTF8&qid=1325431386&sr=8-1