AWS動作検証【6】（作成済みEBSボリュームの暗号化）（2020年4月時点）

前回「[AWS動作検証【5】（AWS CLIによるサーバ停止・スナップショット取得・サーバ起動）](https://qiita.com/gomasa/items/464b5fc13c62208e8eb7)」の続きとなります。

#■■　筆者情報　■■
・AWSの資格試験はプロフェッショナルまで取得済。
・AWSの操作経験は初心者並み。
・理論は解っていても操作は解っていない状況。
※資格試験取得に興味のある方は[「AWS認定試験の勉強方法](https://qiita.com/gomasa/items/6ce860a2e11a620c92ae)」を参照ください。

#■■　この記事を読んでほしい対象　■■
・AWSの知識はある程度ついたので、AWS操作を一通り実施したい人。
・AWS公式ドキュメントをベースに手順を確認したい人。
※手順を簡単にまとめてくれているサイトも多々ありますが、可能な限りAWSの公式ドキュメントを読み解きながら確認を実施しています。その為、この記事のリンクの多くは公式ドキュメントに対して貼られており、どうしても公式ドキュメントのみだと解らない場合に、個人のHPを頼っています。

#■■　AWSのEC2インスタンスのEBSボリューム暗号化　■■
今回はEC2インスタンスの暗号化を検証します。ディスクの暗号化は本来はディスク装置の流出に備えて実施するものです。例えば近年問題となった[富士通リース及びブロードリンク社によるディスク転売事件](https://ja.wikipedia.org/wiki/2019年神奈川県HDD転売・情報流出事件)等が発生した場合に、暗号化したディスクであれば、流出しても中身が見えないので、一定のセキュリティ的な抑止となります。

一方、AWSに関しては物理的なディスク交換した際には工場内でディスクを切断する機材があり、きちんと処理されているとの話があります。その為、EBSボリュームの暗号化にどの程度の意味があるのかは検討が必要です。ただし、IaaS基盤の入札案件では「ディスクは暗号化すること」との要件があることが多く、そういう意味では、この機能は意味があります。

>EC2 インスタンスのブートボリュームとデータボリュームの両方を暗号化できます。暗号化された EBS ボリュームを作成し、サポートされるインスタンスタイプにアタッチする場合、以下のタイプのデータが暗号化されます。
・ボリューム内の保存データ
・ボリュームとインスタンスの間で移動されるすべてのデータ
・ボリュームから作成されたすべてのスナップショット
・それらのスナップショットから作成されたすべてのボリューム

上記がAWSのEBSボリュームの暗号化となります。

#■■　AWSのEC2インスタンスのEBSボリューム暗号化手順　■■
今回の動作検証はEC2インスタンスにアタッチされたEBSボリュームが非暗号化の場合に、暗号化したボリュームに差し替える手順となります。これはAWS試験でもアソシエイトレベルでよく質問される仕様になります。今回の処理の流れは以下の通りです。

|処理|説明| 
|:-----------------|:-----------------|
|暗号化キー作成|EBSボリュームを暗号化する為にはKMSでキーを作成する必要があります。まずは、その手順となります。|
|イメージの作成(AMI)|こちらはテストも含めイメージ作成(AMI+スナップショット)を実施しましたが、本来はスナップショットのみで問題ありません。念のためにAMIも含めたバックアップを取得した形です。なお、今回はコンソールとCLIの両方で実施してみました。| 
|EBSスナップショットの暗号化|取得したスナップショットをコピーする際に暗号化します。なお、ボリュームの作成時に暗号化することが可能なため、この手順はスキップすることも可能です。|
|EBS(暗号化)ボリュームの作成|暗号化したスナップショットからEBSボリュームを作成します。|
|EBS（非暗号化）のデタッチ|非暗号化のEBSボリュームをEC2インスタンスからデタッチします。|
|EBS（暗号化）のアタッチ|暗号化されたEBSボリュームをEC2インスタンスにアタッチします。|

なお、EC2インスタンスを新規に作成する場合は「ステップ４：ストレージの追加」で暗号化設定をすることで、最初から暗号化が可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/d486f467-c532-84fb-b131-cd4b4e562f30.png)


##[暗号化キー作成](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)（KMS）
暗号化するためにはKMSで暗号化キーを作成する必要があります。

>AWS のサービスで保存または管理するデータを暗号化するための CMK を作成する場合は、対称 CMK を作成します。AWS KMS と統合された AWS のサービスは、対称 CMK を使用してデータを暗号化します。これらのサービスは、非対称 CMK を使用した暗号化をサポートしていません。

暗号化には「対称CMK」と「非対象CMK」がありますが、上記記述の為に今回使用するのは「対称CMK」となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/dc593810-7234-ed38-a58d-67dbe5bc51c9.png)
あとは指示にしたがって作成できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/2e0af0f1-e004-d229-f188-5404f19c8090.png)


##[イメージの作成(AMI)(コンソール版)](https://docs.aws.amazon.com/ja_jp/toolkit-for-visual-studio/latest/user-guide/tkv-create-ami-from-instance.html)（EC2）
まずは、非暗号化のEC2インスタンス環境のイメージを作成します。下記画面に記載のある通り「暗号化なし」となっています。処理を実施するとOSが再起動し、AMIとSnapshotが作成されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/33594f5a-9ca2-9229-6b38-3206f094955d.png)

「再起動しない」に関しては以下の注意書きがあります。「ファイルシステムの完全性は保証できません」時点で、このバックアップはどんな場面で利用できるのか悩みます。運用次第ですが、本番環境で使用するのは難しそうです。今回は、チェックを入れずに再起動前提としました。「イメージの作成」を実施したとたん、OSのシャットダウンが走るので注意が必要です。処理としてはシャットダウンして静止状況でバックアップを取得して、まだOSを起動させる流れになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/52778472-60a4-91b2-18ae-da2304dbb31c.png)

気になったので「インスタンス状態」と「再起動しない」のチェックを変更して、以下の4パターンのテストを実施しました。「running+無」の組み合わせのみ、私の想定と異なる動きをしました。

| インスタンス状態|「再起動しない」チェック|結果|安全度|
|:-----------------|:-----------------|:-----------------|:-----------------|
|running|無|処理登録後すぐにシャットダウン。OSが再起動される。|〇|
|stopped|有|OSが起動したままイメージ作成可能。ただし、AWSは「ファイルシステムの完全性は保証できません」としている。完全性が保証されないバックアップは意味があるのか？|×|
|running|無|「Stopped」でインスタンスが停止した状態でバックアップを取得。「再起動しない」のチェック無の為、OSが起動してくるかと思ったが、起動してこなかった。|〇|
|stopped|有|「Stopped」でインスタンスが停止した状態でバックアップを取得。|〇|

##[イメージの作成(AMI)(CLI版)](https://docs.aws.amazon.com/ja_jp/cli/latest/reference/ec2/create-image.html)（AWS CLI）
コンソールでも実施できますが、CLIでも実施できます。基本的にCLIで準備していた方がやりやすいものに関してはBATを作成するようにしています。

```DOS
aws ec2 create-image --instance-id インスタンスID --name "My server" --description "An AMI for my server"
```
なので、以下のようにBATファイル化して実行します。

```DOS
@rem  作成日2020/04/25

Set INSTANCE=インスタンスID
Set ACTION=EC2_create_image
Set TODAY=%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%
Set LOG=C:\log\awslog\%TODAY%\%INSTANCE%_awslog.log
Mkdir C:\log\awslog\%TODAY%

echo %ACTION% >> %LOG%
echo %date% %time% >> %LOG%
aws ec2 create-image --instance-id  %INSTANCE% --name "%INSTANCE%_%TODAY%" --description "An AMI for %INSTANCE%" >> %LOG%

echo %ACTION%_return_code >> %LOG%
echo %date% %time% >> %LOG%
echo %errorlevel% >>  %LOG%
```
実行結果の「%INSTANCE%_awslog.log」は以下の通りです。AMIのイメージIDが表示されます。また、AWSコンソール上ではAMIとSnapshotが作成されたことが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/0f0da0f2-6529-523f-71dd-29dbcb00bdd4.png)

##[EBSスナップショットの暗号化](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html#creating-encrypted-snapshots)（AWS EC2）
取得したEBSのスナップショットをコピーします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/b8ba87eb-044d-63f5-cba7-ad7d06ad1337.png)
この時に暗号化することでEBSの暗号化を実施できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/0e7cfa6e-be65-9904-2300-d85c004270d0.png)

##[EBS(暗号化)ボリュームの作成](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-restoring-volume.html#ebs-create-volume-from-snapshot)（AWS EC2）
コピーする際に暗号化したスナップショットからEBS(暗号化)ボリュームを作成します。この時に、スナップショットのコピーの時に暗号化するのではなくて、ボリューム作成時に暗号化すればよかったことに気付きました。1ステップ減らせます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/42b10e33-1c1c-eccd-b1ea-18cfa077c06c.png)

##[EBS（非暗号化）のデタッチ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-detaching-volume.html)（AWS EC2）
非暗号化のEBSボリュームをEC2インスタンスからデタッチします。
デタッチする前にルートデバイス・ブロックデバイスを記録しておきます。
EC2インスタンスの画面で確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/155974b4-fcb5-9fa4-0e0e-1bdb9385a249.png)
1度目のデタッチでは以下のエラーメッセージが出力しました。これは、テスト的にインスタンスを起動した状態で実施したためです。その後、インスタンスを停止してからデタッチを実施すると問題なくデタッチが実施できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/8ec432dc-1229-59c4-8741-de155362b1ce.png)
デタッチしたあとEC2インスタンスで対象のインスタンスを確認すると、以下のようにルートデバイス・ブロックデバイスが消えた状態となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/e079a84e-3984-4e2d-4d26-40b93e2bdacc.png)

##[EBS（暗号化）のアタッチ](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-attaching-volume.html)（AWS EC2）
暗号化したEBSボリュームをEC2インスタンスからアタッチします。
アタッチする際にはデバイスには「xvdf」が表示されますが、[デバイスの概念](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html#block-device-mapping-def)に記載の通り、デタッチした際のデバイスを設定する必要があります。デタッチする時に確認した通り今回は「/dev/sda1」のため、これを設定してアタッチします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/d5947ba6-6975-292d-f4f5-04a2bfc8e6ed.png)
アタッチしたあとEC2インスタンスで対象のインスタンスを確認すると、以下のようにルートデバイス・ブロックデバイスが表示された状態となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/561572/d6c73d06-5c62-140a-b522-545f3e69bdf8.png)

この後、EC2インスタンスを起動して、問題なく動作することを確認しました。

#■■　まとめ　■■
今回はEBSボリュームの暗号化について検証を実施しました。EBSボリュームに関しては暗号化する手順はありますが復号化した普通にボリュームに戻す方法はないので、一方向でああると思います。手順的にはKMSを利用するだけで、それほど難しい手順ではありません。AWSのEBSボリュームの暗号化にどれほどの意味があるのかは疑問ですが、導入の際の要件として「ディスクの暗号化」がある以上は、利用する場面は多いように思います。

以　　上