Что происходит с CMK Key1 при ротации / истечении срока действия / удалении, и если мы используем псевдоним CMK для этого CMK Key1: перекрестная учетная запись или даже ссылки на одну и ту же учетную запись?

Что происходит с активами или объектами, зашифрованными с помощью «CMK Key1»?

  • когда этот ключ повернут / истек / удален и
  • когда мы прикрепляем «CMK ALIAS-xyz» к этому «CMK Key1» (перекрестная учетная запись или даже ссылки на одну и ту же учетную запись)

  1. Можно ли использовать новый «CMK Key2», который также присоединен к псевдониму CMK Key1 «CMK ALIAS-xyz», для повторного шифрования уже существующих объектов данных активов, которые были зашифрованы с помощью «CMK Key1», без какого-либо DOWNTIME / Изменения кода?

  2. Когда мы вращаем псевдонимы ключей, что происходит с прямыми ссылками на CMK в коде?

<ПОЖАЛУЙСТА, ПОДЕЛИТЬСЯ СВОИМ ПРАКТИЧЕСКИМ ОПЫТОМ - НЕ ТОЛЬКО ТЕОРЕТИЧЕСКОЙ ДОКУМЕНТАЦИЕЙ>

ИЗОБРАЖЕНИЕ - Наглядное изображение вышеуказанных вопросов

Мои текущие наблюдения:

ПОДДЕРЖИВАЮЩИЕ НИКНЕЙМЫ / Пункты, подтверждающие, что это возможно:

  • Удаление псевдонима не влияет на связанный CMK.
  • Использование нескольких аккаунтов: Да. Чтобы выполнить эту операцию с CMK в другой учетной записи AWS, укажите ключ ARN или «псевдоним ARN» в значении параметра KeyId. Таким образом, это означает, что Alias ​​имеет собственное ARN, которое не зависит от фактического CMK.
  • Руководители, у которых есть разрешение на управление тегами и псевдонимами, также могут контролировать доступ к CMK. Дополнительные сведения см. В разделе Использование ABAC для AWS KMS.
  • AWS KMS поддерживает ABAC, позволяя контролировать доступ к главным ключам клиента (CMK) на основе тегов и псевдонимов, связанных с CMK.

ОПАСНОСТИ / Пункты, указывающие на то, что это невозможно:

  • Эти функции не позволяют идентифицировать CMK с помощью псевдонима в элементе ресурса заявления политики. Когда псевдоним является значением элемента ресурса, политика применяется к ресурсу псевдонима, а не к любому CMK, который может быть с ним связан.
  • Мы столкнулись со случаем, когда псевдонимы кросс-аккаунтов не работали, и нам нужно было использовать фактический arn с этим активом данных внешних клиентов. Единственное изменение, которое сделали наши клиенты, - это занести в белый список arn вместо псевдонимов на своей стороне, и они получили доступ.

Источники, на которые ссылаются:

  • https://docs.aws.amazon.com/kms/latest/developerguide/alias-authorization.html

  • https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-use

  • https://docs.aws.amazon.com/kms/latest/developerguide/alias-access.html

  • https://docs.amazonaws.cn/en_us/kms/latest/developerguide/abac.html

  • (Пожалуйста, проигнорируйте это, если хотите). С другой стороны, если CMK импортировал ключевой материал, вы не можете автоматизировать ротацию ключей: «Вы не можете автоматически вращать асимметричные CMK, CMK с импортированным ключевым материалом или CMK в пользовательских хранилищах ключей. Однако , вы можете повернуть их вручную. " «Когда вы начнете использовать новый CMK, убедитесь, что исходный CMK включен, чтобы AWS KMS мог расшифровать данные, зашифрованные исходным CMK. При расшифровке данных KMS идентифицирует CMK, который использовался для шифрования данных, и использует один и тот же CMK для расшифровки данных. Пока включены как исходный, так и новый CMK, AWS KMS может расшифровать любые данные, зашифрованные с помощью любого из этих CMK ».

Источник

0 ответов

Другие вопросы по тегам