Мы думаем об использовании шифрования на уровне столбцов (ячеек) SQL Server для конфиденциальных данных. При первоначальном шифровании столбца проблем возникнуть не должно, но у нас есть требования, согласно которым ключ шифрования необходимо менять каждый год. Кажется, что это требование может быть проблемой.
Предположение: таблица, содержащая столбец с конфиденциальными данными, будет иметь 500 миллионов записей.
Ниже приведены шаги, которые мы подумали о реализации. В процессе шифрования / дешифрования данные находятся в сети, а также сколько времени этот процесс займет?
Вопрос: при расшифровке / шифровании столбца данные доступны в сети (доступны для запроса)? Предоставляет ли SQL Server функцию, позволяющую вносить ключевые изменения, пока данные находятся в оперативном режиме?
BarDev
Повторное шифрование неактивных данных будет недопустимым. 500 миллионов записей для обновления будут генерировать огромный журнал, много данных ввода-вывода, будут длиться часы, если не дни, в целом будет довольно разрушительно. Не говоря уже о том, что из-за операционной ошибки вся база данных может быть полностью зашифрована (т.е. без ключа для ее расшифровки).
Я бы порекомендовал повернуть ключи выше в иерархии ключей:
Подобные схемы часто используются крупными компаниями. Повторное шифрование всех данных выполняется редко, потому что это слишком сложно. Использование нескольких симметричных ключей и периодическая генерация новых уменьшит возможную потерю конфиденциальности в случае компрометации симметричного ключа. Ротация сертификата, используемого для расшифровки симметричных ключей, дает желаемое смягчение риска компрометации сертификата, поскольку скомпрометированный сертификат не сможет получить доступ к данным после ротации, даже если данные по-прежнему зашифрованы с использованием тех же старых симметричных ключей.
Это правда, что я могу представить себе атаку, при которой, если у меня есть доступ к сертификату, я могу извлечь весь материал симметричного ключа, а затем, когда сертификат вращается, я теоретически могу использовать сохраненный ключевой материал для расшифровки данных (используя другие средства. чем SQL Server). Но это ничем не отличается от утверждения, что «если у меня есть доступ к скомпрометированному сертификату до того, как он будет повернут, я могу расшифровать все данные и сохранить расшифрованные данные», и это ставит атаку в новом свете, поскольку никакое количество после Фактическая ротация ключей восстановит данные, которые уже были потеряны злоумышленником.
Вы, конечно, можете написать приложение для расшифровки / шифрования (SELECT данные, расшифруйте их, повторно зашифруйте с новым ключом и UPDATE его обратно - конфиденциальные данные никогда не будут храниться в незашифрованном виде таким образом), однако вы создаете огромный сумма накладных расходов на ежегодную ротацию ключей, которая будет только увеличиваться по мере роста вашей БД. Также существует проблема необходимости поддерживать два ключа столько времени, сколько требуется для танца повторного шифрования (может быть, час сейчас, может быть, несколько дней в следующем году, в зависимости от ваших темпов роста и сложности шифрования ...)
Возможно, вы захотите оценить бизнес-логику / логику безопасности, лежащую в основе требования к ежегодному изменению, и посмотреть, сможете ли вы получить эквивалентную безопасность, реализовав разумные средства управления ключами дешифрования и требование менять ключи «в случае компрометации или подозрения на компрометацию». ..