Я создаю базу данных, в которой хранятся сведения о сотрудниках, включая данные банковского счета. Данные банковского счета хранятся таким образом, что мы можем проверить текущий или прошлый штат с помощью нашей компании, что в нашем случае может быть причиной того, что вас беспокоит мошенничество. Я читал на SQL Server 2008 R2 Encrption и дешифрование на MSDN и в других местах и придумали следующий образец сценария:Сравните данные зашифрованных банковских счетов без полного дешифрования
IF NOT EXISTS(SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'BankDetai!5'
GO
CREATE CERTIFICATE Employees_01 WITH SUBJECT = 'Employee Bank Account Details'
GO
CREATE SYMMETRIC KEY AccountNos_01
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE Employees_01
GO
CREATE TABLE #Bank_Accounts
(Id INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_BankAccount_Id PRIMARY KEY CLUSTERED (Id ASC)
,AccountNumber VARBINARY(128) NOT NULL
,BankName NVARCHAR(255) NOT NULL
,CountryCode VARCHAR(2) NOT NULL
,CreateDate DATETIME2(0) NOT NULL
,EmployeeId INT NOT NULL
,IsActive BIT NOT NULL
,SortCode VARBINARY(128) NOT NULL
);
OPEN SYMMETRIC KEY AccountNos_01
DECRYPTION BY CERTIFICATE Employees_01;
CREATE TABLE #SampleBankAccounts
(Id INT IDENTITY(1,1)
,AccountNumber VARCHAR(255)
,BankName NVARCHAR(255)
,CountryCode VARCHAR(2)
,EmployeeId INT NOT NULL
,IsActive BIT
,SortCode VARCHAR(255))
INSERT #SampleBankAccounts
SELECT * FROM
( SELECT
'123456789' AccountNo
,'Barclays' BankName
,'US' Country
,1 Employee
,1 IsActive
,'12-34-56' SortCode
UNION
SELECT
''
,'Barclays'
,'US'
,1
,0
,'12-34-56'
UNION
SELECT
'111111111111'
,'HSBC'
,'UK'
,2
,1
,'222222'
UNION
SELECT
'IBAN 123 456 9875 3215'
,'Nationwide'
,'ES'
,3
,1
,'00_gn321654'
)AS Samples
ORDER BY Employee
MERGE #Bank_Accounts AS Target
USING #SampleBankAccounts AS Source ON Target.EmployeeId = Source.EmployeeId
AND Source.AccountNumber = Target.AccountNumber
AND Source.BankName = Target.BankName
AND Source.CountryCode = Target.CountryCode
AND Source.SortCode = Target.SortCode
WHEN NOT MATCHED
THEN INSERT (AccountNumber, BankName,CountryCode,CreateDate,EmployeeId,IsActive,SortCode)
VALUES (
ENCRYPTBYKEY(KEY_GUID('AccountNos_01'),Source.AccountNumber)
,Source.BankName
,Source.CountryCode
,GETDATE()
,Source.EmployeeId
,Source.IsActive
,ENCRYPTBYKEY(KEY_GUID('AccountNos_01'),Source.SortCode));
GO
DROP TABLE #SampleBankAccounts
Это, кажется, работает хорошо, но сейчас мне нужно взять переменную, например, @AccountNo
и посмотреть, соответствует ли он любому из банковских счетов, которые мы сохранили (я буду использовать хранимую процедуру по всей вероятности). Я предпочел бы избежать расшифровку в любом сценарии, если это возможно, так что я подумал, что можно было шифровать переменную @AccountNo
, а затем сравнить его, чтобы мы могли увидеть матч:
DECLARE @MyTestBankAccount NVARCHAR(255) = '123456789'
DECLARE @MyEncryptedTestBankAccount VARBINARY(128)
OPEN SYMMETRIC KEY AccountNos_01
DECRYPTION BY CERTIFICATE Employees_01;
SELECT @MyEncryptedTestBankAccount = ENCRYPTBYKEY(KEY_GUID('AccountNos_01'),@MyTestBankAccount)
SELECT
AccountNumber
,EmployeeId
FROM Bank_Accounts
WHERE
@MyEncryptedTestBankAccount = AccountNumber
Это не работает; как вы можете видеть, я использую номер учетной записи, который должен присутствовать в таблице, но результаты не возвращаются. Я попытался расшифровать столбец номера счета и сравнить его с переменной, но я получаю загрузку китайских символов (как и в this question), и они не соответствуют символам, созданным путем шифрования и дешифрования переменной, так что не работает для соответствия либо ...
Так почему же следующий запрос (используя данные выше) не дает мне зашифрованных и дешифрованных значений для данных учетной записи? Могу ли я использовать этот метод для поиска банковских счетов сотрудников на данном банковском счете?
OPEN SYMMETRIC KEY AccountNos_01
DECRYPTION BY CERTIFICATE Employees_01;
SELECT
AccountNumber AS Encrypted_AccountNo
,EmployeeId AS EmployeeId
,CONVERT(NVARCHAR,DECRYPTBYKEY(AccountNumber)) AS Decrypted_AccountNo
FROM Bank_Accounts
хранит номер счета в виде обычного текста действительно неправильно вещь? Если я клиент, и я знаю номер своего счета, я, вероятно, могу предположить другое без особых трудностей, верно? Если сохранение зашифрованной учетной записи является обязательным, то как насчет добавления еще одного столбца с хэшей учетной записи #, большую часть времени хешированная учетная запись # будет уникальной в базе данных, но вы можете столкнуться с сценарием, в котором вам нужно будет загружать сопоставление хэшей, пока вы не найдете правильную учетную запись. – UnhandledExcepSean
Я думаю, что этот вопрос принадлежит сайту SE Security Security, потому что он действительно имеет дело с лучшей практикой, а не с кодом. – UnhandledExcepSean
Для шифрования номеров учетных записей необходимо, к сожалению, это значит, что для меня это проблема кода, так как я не смог получить зашифрованную информацию о банковской учетной записи из базы данных для использования, явно ли она в виде обычного текста или в некоторой зашифрованной форме. Из статьи MSDN выглядит так, как будто это должно произойти, но мой скрипт терпит неудачу. –