この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
初めに
先月のアップデートとはなりますが
S3作製時に暗号化の無効選択肢がなくなり必ず暗号化されるようになりました。
[アップデート] Amazon S3でオブジェクト保存時に必ず暗号化が行われるようになります
意識せずとも暗号化がされ安全性が高まるのは非常に良いことですが、
全く意識をしないと誤った設定をしてしまうので注意しましょう。
例えば以下はAmazon Kinesis Firehoseの暗号化設定画面ですが、
選択肢として暗号化しないかCMKによる暗号化の選択肢となっております。
仕組みをわかってる方であれば迷うことはないのですが、
触り始めだと同じ鍵を使うからS3の設定と同じ鍵を指定しよう！ということや、
S3-SSEを利用しているけどその鍵の指定は？となることもあるかと思います。
今回はこのFirehoseの選択肢を例に改めて見つめ直して見ましょう。
「暗号化なし」の選択はバケット側の設定を利用する
上記のFirehoseの例として「暗号化なし」を選択した場合
厳密には暗号化なしで保存するのではなく「暗号化ヘッダなし」での保存となります。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/default-bucket-encryption.html
- PUT リクエストヘッダーに暗号化情報が含まれていない場合、Amazon S3 はオブジェクトを暗号化するために、バケットのデフォルトの暗号化設定を使用します。
- PUT リクエストヘッダーに暗号化情報が含まれている場合、Amazon S3 は PUT リクエストの暗号化情報を使用してオブジェクトを Amazon S3 に保存する前に暗号化します。
S3のデフォルト暗号化の挙動としてはこののような形となり、
Firehoseで「暗号化なし」を選択した場合は前者の挙動となります。
現時点ではS3のデフォルト暗号化の無効の選択肢はないため、
「暗号化しない」というのは実質的にバケットの設定を利用して暗号化という選択に等しくなります。
送信元の暗号化指定はバケットの設定と違う鍵が必要な時に使う
CMKを指定し暗号化を行った場合は暗号化情報を含めS3にリクエストを行うことになります。
そのためS3の設定ではなくFirehose側の設定を用いて暗号化をします。
明示的にバケット設定と異なるキーを使いたい時はこちらの選択肢は問題ありませんが、
同じ鍵を使うから問題ないと思って設定すると意図しない鍵による暗号化リスクが出ます。
そのため常にバケットの鍵と同じ鍵で暗号化をしたい場合は、
Firehose側の指定は「暗号化しない」を選んで暗号化するのが好ましい対応になると考えます。
手動キーローテーションによる差し替えミスによる食い違い
KMSのキーのARNの指定としてはエイリアスとキーIDの２種類があります。
キーIDによる指定: arn:aws:kms:ap-northeast-1:xxxxx:key/xxxxx
エイリアスによる指定: arn:aws:kms:ap-northeast-1:xxxxx:alias/xxxxx
エイリアスでARNを指定している場合
鍵の入れ替え時はKMS側でエイリアスの更新のみで入れ替えは完了となり、
エイリアスのARNを指定しているサービス側での鍵の入れ替え設定は不要となります。
一方でキーIDによる指定の場合は鍵を再生成した上で、
キーのARNの指定元の設定も入れ替えが必要となります。
鍵を再生成し入れ替えるケースはどのようなものがあるか？
という点ですが例として手動での鍵ローテーションがあります。
キーIDでの指定を行っている場合、
S3のみキーIDを変更しました！Firehoseの変更漏れありました！キーが両方有効のままでした！
となるとローテーション前のキーで暗号化し格納され続けるといったような可能性が出てきます。
エイリアスを指定することでこの問題は軽減できますが、
もしエイリアス自体を差し替えるようなことがもしあれば類似するリスクはあるかと思います。
こういったケースは最初から送信元で暗号化しない選択を取ることで悩まずに済むため、
バケット側に指定されている鍵で暗号化して問題ない場合は送信元のサービスでは強い意志を持って「暗号化しない」を選択しましょう。
終わりに
実は久々にマネコンで「暗号化しない」という選択肢を見てバケットの設定で暗号化されるはずなんだけど本当？
となったのがこの記事の始まりとなります。
暗号化強制アップデート前はバケットの暗号化設定がない場合、
設定次第で確かに暗号化されない可能性がありました。
しかし暗号化が強制化された今ではそのようなリスクもないので
大丈夫？と不安にならずに自信を持ってこの選択肢を選びましょう。
とはいえ要件次第では別の鍵を指定する場面は出てきますので、
常に暗号化しないを選ぶのではなく要件はしっかり確認の上選択してください。
備考: キーIDによる指定箇所がある状態でエイリアスを変更する
記事を書きながらエイリアス差し替え時にキーID指定の箇所の設定が変わらないか不安になったので念のため確認しました。
鍵は入れ替え前後の2つを用意します。
base-keyが入れ替え前の鍵でchange-after-keyがエイリアス入れ替え後の鍵です。
この状態で現時点でbase-keyとなる5fから始まるキーをFirehoseに割り当てます。
base-keyをchange-after-keyに割り当てたいため、
change-before-keyというエイリアスをbase-key側に割り当てます。
エイリアスの割り当て直しの設定がマネコン上だと見当足りませんでした。
なので一度削除して割り当てるという形になりそうだったのでCLIで再割り当てを行います。
$ aws kms update-alias --alias-name alias/base-key --target-key-id arn:aws:kms:ap-northeast-1:xxxxxx:key/32a3d6a5-xxxxx※コマンドの出力結果は空です
実行後base-keyのエイリアスがchange-after-key側のリソース側についていることがわかります。
割当たってるのを確認後Firehose側の画面を確認しましたがキーIDは当然変わらず
エイリアスを割り当て直したからといって差し代わるわけではなくキーIDによる参照が行われることがわかります。
少し話はそれますが実際のFirehoseの画面では注記的な部分ににエイリアスの記載がなく、
流れのまま入れてしまうとキーIDで入れてしまいそうになります。
（参照で入力する場合もキーIDによる指定となる)
ただ実際にエイリアスを入力し設定を行うとその値で設定が可能です。
キーの指定が必要な場合は差し替え等を考慮しエイリアスで指定する方が便利かもしれません。
2
