Вы не можете и не должны скрывать зашифрованную информацию от пользователя, который ее фактически сохранил. Более реалистичный сценарий состоит в том, что обычные пользователи могут шифровать и дешифровать свои собственные данные, в то время как привилегированные пользователи могут дешифровать данные всех пользователей.
Для этого вам нужно сделать следующее:
- данные шифруются симметричным ключом (это всегда так)
- каждый пользователь использует другой симметричный ключ
- симметричные ключи зашифрованы сертификатом, принадлежащим пользователю, этот сертификат зашифрован паролем
- при использовании приложения пользователи вводят свой пароль для расшифровки сертификата, и приложение открывает сертификат в своем сеансе, предоставляя таким образом доступ для дешифрования симметричного ключа и, таким образом, позволяя сеансу шифровать новые данные и дешифровать свои собственные данные
- важная часть : все симметричные ключи также шифруются одним сертификатом администратора, а этот сертификат администратора - паролем
- только пароль администратора может знать только привилегированный пользователь
- когда администраторы используют приложение, они вводят пароль сертификата администратора и, таким образом, получают доступ к всем симметричным ключам и могут дешифровать все данные
Большая проблема, которую вы обнаружите, - это предоставление симметричного ключа, поскольку он должен быть зашифрован как сертификатом пользователя, так и сертификатом администратора. Это означает, что либо администраторы знают пароли всех сертификатов пользователей (и это обычно не дает покоя по понятным причинам), либо ваше приложение должно реализовать довольно сложную процедуру для развертывания симметричных ключей. Правильный подход к этой процедуре невероятно сложен. Это очень помогает, если у вас есть ключ условного депонирования (очень привилегированный ключ, обычно хранящийся в аппаратном обеспечении для упрощения подготовки симметричного ключа), потому что система может использовать условный ключ, чтобы открыть симметричный ключ и добавить как пользователя, так и администратора шифрование сертификата к ключу.
Этот сценарий позволяет разделить доступ к данным криптографическими средствами, и, как вы видите, очень сложен.
Альтернативой является разделение доступа средствами авторизации. Это просто подразумевает, что доступ к используемым ключам регулируется списками контроля доступа GRANT / DENY / REVOKE, и пользователи могут шифровать и дешифровать данные на основе доступа к ключам, но ключи дешифруются для всех (например, они шифруются с помощью главный ключ базы данных и главный ключ службы). Но это намного, намного слабее, чем криптографическое разделение. Вы можете достичь точно такого же эффекта, используя Transparent Database Encryption и контролируя доступ к данным через GDR, для небольшой части сложности.
И, наконец, есть путь, по которому вы не должны идти: вставляйте пароли в приложение. Например. иметь хранимые процедуры, которые открывают ключи, сохраняют данные, затем закрывают ключи с паролями доступа к сертификатам, встроенными в них, а затем шифруют процедуру. Это даст вам просто иллюзию безопасности, и это все, что я скажу об этом.