EBSボリュームの暗号化についてまとめてみた

投稿者: | 2018/04/10

AWSではデフォルト状態ではEBSやRDS、Redshiftなどストレージ部分が暗号化されていません。セキュリティが厳しい企業ではストレージの盗難時のデータ漏えいを防ぐために暗号化を要求されているかと思います。
EBSボリュームの暗号化を行う機会があり調べたり検証したりして得られた知見をまとめてみました。

何に対して暗号化されるのか

ドキュメントには以下のタイプが暗号化されると書いています。

  • ボリューム内の保存データ
  • ボリュームとインスタンスの間で移動されるすべてのデータ
  • ボリュームから作成されたすべてのスナップショット
  • それらのスナップショットから作成されたすべてのボリューム
     
    Amazon EBS Encryption – Amazon Elastic Compute Cloud
    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSEncryption.html

ボリューム内のデータが暗号化されるからといって、リモートログイン後にファイルアクセスするには復号しなければならないかというとそうではありません。暗号化と復号は透過的に処理されるため、リモート接続後は復号するためのコマンドや処理は必要ありません。 EBSボリュームの暗号化 = AWSデータセンターに設置されている物理サーバのストレージの暗号化 といえます。AWSデータセンターからストレージが万が一盗まれたり、データセンターに侵入して直接サーバにログインされた場合に備えた対策といえます。なので、万が一サーバにSSHなどでリモートから侵入された場合、EBSボリュームが暗号化されたとしてもデータは抜き取ることができてしまいます。

AWSのデータセンターは設置場所等は公開されておらず見学もできませんが、データセンターのページを見ますと強固なセキュリティを誇っていることがわかります。「暗号化をやる意味あるのかな・・・?」と思う方もいるかもしれません(私もその一人です)が、セキュリティ要件として要求されているかつ、AWSから機能を提供されている以上は対策しなければならないのです(辛いところです)。

暗号化による影響

EBSボリュームを暗号化することによって変わるもの、変わらないものをまとめてみました。

EC2インスタンス上で動作するアプリケーション

先ほど述べたとおり、暗号化と復号は透過的に処理されるため、EC2インスタンスにおける作業に変更はなく、アプリケーションの設定変更等は必要ありません。ハードウェア(AWS側)で暗号化処理がおこなわれるため、パフォーマンスはほぼ影響しないとのことです。が、I/Oが多くかかるサーバは影響が出る可能性があるため事前検証を行うことをオススメします。

AMI、EBSスナップショット作成

暗号化されたEBSボリュームを含んだAMIを作成し、AWSアカウント間で共有する際は注意が必要です。
AMI作成(正確にはEBSスナップショットの暗号化)時に暗号化するキーを指定する必要があります。見落としがちなのが、 デフォルトの暗号化キー(aws/ebs)だと他のAWSアカウントにEBSスナップショットを共有できないため、カスタムで作成したKMS暗号化キーを指定する必要がある 点です。
重要なのが、暗号化されたEBSスナップショットを含んだAMIは他のAWSアカウントと共有できません。他AWSアカウントに移したい場合は、EBSスナップショットをぞれぞれ共有・コピーし、コピー先のAWSアカウント上でEBSスナップショットからAMIを作る必要があります。

ebs-encryption-ami-not-shared.png

AMIを共有しようとすると上のように UnsupportedOperation エラーになってしまいます。

EC2インスタンスの起動

暗号化されたEBSボリュームがアタッチされているEC2インスタンスを起動する際に、以下のようにKMSの権限が必要になります。権限が不足していると起動してもすぐに停止状態になってしまうので注意が必要です。権限が足りない状態で起動させると Client.InternalError: Client error on launch となります。

サポートされるインスタンスタイプ

現在使っているインスタンスタイプはサポートされているので問題ないといえます。
サポートされるインスタンスタイプ

料金

  • EBS: 追加料金は発生しません
  • KMS:
    • CMK(暗号化キー) 1つにつき $ 1.00/月
    • 10,000 リクエストあたり $ 0.03 (毎月 20,000 リクエストまでは無料枠)
    • 暗号化されたEBSボリュームを作成する度に1リクエストとして加算

既存のEBSボリュームを暗号化する方法

暗号化されていないEBSボリュームがEC2インスタンスにアタッチされている状態で暗号化する方法は2つあります。
EBS-Backend AMIであることが条件です。

① AMIのコピー時に暗号化

  1. 既存のEC2インスタンスからAMIを作成する
  2. 1で作成したAMIをコピーする。この時に暗号化オプションを指定する
  3. 2で作成したAMIからEC2インスタンスを作成し、既存のEC2インスタンスと入れ替える
    3.1. WebサーバなどELBにアタッチされている場合は、ELBに付け替える
    3.2. EIPがアタッチされている場合は、EIPを付け替える

メリット

  • 作成した暗号化済AMIは他のインスタンスにも使える
  • うまくやれば無停止で切り替え可能

デメリット

  • AMIを2度作成することになるため時間がかかる
  • サーバ内に常にデータを溜めておくような(状態を持っている)EC2インスタンスには不向き

② EBSスナップショットのコピー時に暗号化

  1. 既存のEC2インスタンスにアタッチされているEBSボリュームを特定する
  2. 1のEBSボリュームからEBSスナップショットを作成する
  3. 2で作成したEBSスナップショットをコピーする。この時に暗号化オプションを指定する
  4. 暗号化したEBSスナップショットからEBSボリュームを作成する
  5. 4のEBSボリュームをEC2インスタンスにアタッチする(既存EBSボリュームはデタッチするか、デバイス名を変えるかは要件によって異なる)

メリット

  • EC2インスタンスを作り直さなくても良い。インスタンスIDやプライベートIPアドレス、ホスト名が変わらない

デメリット

  • ブートボリューム(Linux: /dev/sda1、Windows: Cドライブ)の場合は、EC2インスタンスを停止する必要がある

AMIの暗号化

KMSの暗号化キーを作成(初回のみ)

暗号化する際に必要な暗号化キーをKMSから作成します。デフォルトのKMS(aws/ebs)を暗号化キーとして使えるのですが、AWSアカウント間の共有ができませんので作成した暗号化キーを使用するようにした方が良いです。

ebs-encryption1.png

共有先のAWSアカウントIDを許可しておくことで、共有先アカウントでEBSスナップショットを使用することができます。

ebs-encryption2.png

AMIコピー

暗号化したいAMIを選択し、「AMIのコピー」をクリックします。

ebs-encryption3.png

リージョン、AMI名を指定し、暗号化にチェックを入れます。マスターキーは先ほど作成したKMSキーを選択します。しばらくすれば暗号化されたAMIが作成されます。

ebs-encryption4.png

EBSスナップショットの暗号化

共有したEBSスナップショットを選択し、「コピー」をクリックします。

ebs-encryption5.png

AMIのときと同様、デフォルトのKMS(aws/ebs)ではなく、さきほど作成した暗号化キーを指定します。しばらくすれば暗号化されたEBSスナップショットが作成されます。

ebs-encryption6.png

最後に

EBSボリュームの暗号化について、概要や注意点、方法などをまとめてみました。暗号化によってAMI作成作業の複雑さが増すので、できることなら暗号化しないで済むのが一番ですが、要件によっては必須になることもありえます。その際に当記事が参考になれば幸いです。
聞いた話では、GCPはすべてのサービスがデフォルトで暗号化されているらしく、AWSもそうなってくれば嬉しいのになぁと思います。

参考

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください