Вращающиеся ключи и реактивное шифрование данных

Я думал, что добавлю некоторые конкретные примеры специально для контроллера вида. Многие объяснения, а не только здесь, о переполнении стека, действительно хороши, но я лучше работаю с примерами реального мира (на самом деле у @drewag было хорошее начало):

  • Если у вас есть закрытие для обработки ответа от сетевых запросов используйте weak, поскольку они долговечны. Контроллер вида может закрыться до завершения запроса, поэтому self больше не указывает на действительный объект при вызове закрытия.
  • Если у вас есть закрытие, которое обрабатывает событие на кнопке. Это может быть unowned, поскольку, как только контроллер просмотра уйдет, кнопка и любые другие элементы, которые она может ссылаться на self, уходят одновременно. Блок блокировки также уйдет в одно и то же время.
    class MyViewController: UIViewController {
          @IBOutlet weak var myButton: UIButton!
          let networkManager = NetworkManager()
          let buttonPressClosure: () -> Void // closure must be held in this class. 
    
          override func viewDidLoad() {
              // use unowned here
              buttonPressClosure = { [unowned self] in
                  self.changeDisplayViewMode() // won't happen after vc closes. 
              }
              // use weak here
              networkManager.fetch(query: query) { [weak self] (results, error) in
                  self?.updateUI() // could be called any time after vc closes
              }
          }
          @IBAction func buttonPress(self: Any) {
             buttonPressClosure()
          }
    
          // rest of class below.
     }
    
0
задан Aleksander Orchowski 20 March 2019 в 13:28
поделиться

2 ответа

На данный момент лучшее, что вы можете сделать, это написать что-то, что опрашивает GetCryptoKey через регулярные промежутки времени, проверяет, изменилась ли основная версия, а затем расшифровывает и перешифрует, если она есть.

Мы определенно понимаем стремление к событиям на основе ключевых изменений жизненного цикла, и мы думали о том, как наилучшим образом добиться этого в будущем. У нас пока нет планов делиться.

0
ответ дан bdhess 20 March 2019 в 13:28
поделиться

Когда вы поворачиваете ключ шифрования (или когда вы включаете запланированное вращение на ключе), Cloud KMS автоматически не удаляет материал версии старого ключа. Вы все еще можете расшифровать данные, ранее зашифрованные старым ключом, если вы не отключите / не уничтожите версию ключа вручную. Подробнее об этом можно прочитать в документации по ротации ключей KMS Cloud .

Несмотря на то, что у вас могут быть бизнес-требования, облачное KMS не требует повторного шифрования старых данных с использованием материала новой версии ключа.

  • Новые данные будут зашифрованы новым ключом
  • Старые данные будут расшифрованы старым ключом

На момент написания этой статьи Cloud KMS не опубликовать событие, когда ключ повернут. Если у вас есть бизнес-требование перешифровать все существующие данные с помощью нового ключа, вы можете сделать одно из следующих действий:

Использовать планировщик облака

Написать функцию облака [111 ] подключен к Cloud Scheduler , который вызывается на периодической основе. Например, если ваши ключи вращаются каждые 72 часа, вы можете запланировать запуск облачной функции каждые 24 часа. Рад предоставить пример кода, если это поможет, но ОП специально не запрашивал код.

Long-poll

Напишите долговременную функцию, которая опрашивает API-интерфейс KMS, чтобы проверить, изменился ли первичный ключ шифрования, и инициирует повторное шифрование при обнаружении изменения.

0
ответ дан sethvargo 20 March 2019 в 13:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: