はじめに

データを暗号化する目的として、ネットワーク経路やウィルスによるデータ盗聴・盗難に対策を行うために用いる。
AWSのEC2においては、インスタンスを作成する時やEBSサービスからボリュームを作成する際に選択可能な「このボリュームを暗号化する」オプションを利用してEBSボリュームの暗号化を行うことになる。
EBSボリュームの暗号化を有効化することで何が暗号化されるのか、何の対策になるのかを整理する。

EBSの暗号化対象

EBSの暗号化オプションを有効にした場合に何が暗号化されるのかは以下の通り。

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

イメージ図としては以下のようになる。

EBSボリュームがEC2インスタンスが実行されている物理サーバとは別のストレージ装置にあり、
VMware vSphereで言うところのvmdkのようなファイルだとして(公式資料はないため想像)、
EC2インスタンスとストレージ装置間のデータ通信と仮想ボリューム自体の暗号化がされるという認識になる。

これにより、EBSボリューム自体を不正に取得された場合でも容易には復号できず、
また、EC2インスタンスとEBSボリューム間の通信をNW的に傍受可能な状態であっても、
通信が暗号化されているので簡単には傍受できないという対策になる。

しかし、たとえEBS暗号化を有効にした場合でも、OS上から見えるデータは暗号化されない。
EC2インスタンス自体に不正アクセスされた場合はファイルとしてデータを盗聴・盗難されるリスクは依然として存在する。

非機能要求グレードの暗号化要件

インフラの非機能要件として「データを暗号化して保存すること」という要件があった場合、
EBSの暗号化オプションを有効化することでこの要件を満たすことができるかを考える。

要件定義フェーズで非機能要件定義の指標となる非機能要件グレードの中で、
データ暗号化に関する要件は以下の2点が挙げられている。
(各メトリクスで一番厳格なレベルの説明を抜粋)

1. 非機能要求グレード項番: E.6.1.1 伝送データの暗号化有無

ローカルネットワーク経由で重要情報を送付する場合においても、特に重要な情報については、盗聴等の脅威に対抗するために、伝送データを暗号化する必要がある。
（伝送データを暗号化することにより、性能が低下する可能性がある）
[-] 専用線を用いる等の物理的な対策が実施されている場合/ローカルネットワーク上での盗聴の脅威については許容する場合/機密性は求められないが完全性が求められる重要情報を扱う場合

2. 非機能要求グレード項番: E.6.1.2 蓄積データの暗号化有無

データベースやバックアップテープ等に格納されている個人情報等やパスワード等の重要情報の漏洩の脅威に対抗するために、蓄積データを暗号化する必要がある。
（蓄積データを暗号化することにより、性能に影響する可能性がある）
[-] 耐タンパデバイスの利用、認証対策、運用対策等の他の複数の対策により、安全性が確保されている場合/機密性は求められないが完全性が求められる重要情報を扱う場合

これら要件に対応するため、EBSボリュームの暗号化を実施することで解決とするのは、
嘘にはならないと思っている。
実際EBSボリュームの暗号化を有効にすることで、EC2インスタンスとEBSボリューム間の通信は暗号化され、BitLockerのようにボリューム自体を暗号化するため、蓄積データも暗号化されていると言える。
もちろん前述したリスクが存在しているため万全とは言えない。
システム開発期間と予算の兼ね合いでリスクについて説明したうえで
明確に顧客と合意を形成することが大切である。

OS内でのファイル暗号化

では、EBSボリューム暗号化だけでは対策ができない、OS内への侵入&ファイル取得に対して、
どのようなアプローチが可能なのか。2案考えうち1案を検証した。

1つはファイル暗号化に特化したミドルウェアを導入することでファイルを保護する手法である。
日立の秘文 File Encryptionのようなファイル暗号化用のミドルウェアを用いることで、
ファイル自体を暗号化して別途復号プロセスを踏まないとファイルを読めなくすることができる。

もう1つはOpenSSLによるファイル暗号化である。

公開鍵暗号方式(共通鍵暗号や2つの併用も可能)を利用してファイルを暗号化・復号する。
前者と比較してOS上のコマンドで完結しているため、シェルやジョブに組み込み易いという点で
今回はこの手法について検証を行った。

OpenSSLによるファイル暗号化・復号検証

環境・事前準備

OS: AmazonLinux 2023
暗号化対象となるファイル名はencrypt_test.txtとする
暗号方式は公開鍵暗号方式を利用する(RSA + AESのハイブリッドと比較してファイルサイズに制限あり)

暗号化・複合化実行

# 暗号化前ファイル内容
$ cat encrypt_test.txt
secure data 01
secure data 02

# RSA秘密鍵の生成
$ openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

$ ls -l
total 8
-rw-r--r--. 1 ec2-user ec2-user   30 Apr 29 19:03 encrypt_test.txt
-rw-------. 1 ec2-user ec2-user 1704 Apr 29 19:05 private.pem

# RSA公開鍵の生成
$ openssl rsa -pubout -in private.pem -out public.pem

$ ls -l
total 12
-rw-r--r--. 1 ec2-user ec2-user   30 Apr 29 19:03 encrypt_test.txt
-rw-------. 1 ec2-user ec2-user 1704 Apr 29 19:05 private.pem
-rw-r--r--. 1 ec2-user ec2-user  451 Apr 29 19:07 public.pem

# 公開鍵を利用してファイル暗号化
$ openssl pkeyutl -encrypt -pubin -inkey public.pem -in encrypt_test.txt -out encrypt_test.enc

$ ls -l
total 16
-rw-r--r--. 1 ec2-user ec2-user  256 Apr 29 19:07 encrypt_test.enc
-rw-r--r--. 1 ec2-user ec2-user   30 Apr 29 19:03 encrypt_test.txt
-rw-------. 1 ec2-user ec2-user 1704 Apr 29 19:05 private.pem
-rw-r--r--. 1 ec2-user ec2-user  451 Apr 29 19:07 public.pem

$ cat encrypt_test.enc
(バイナリファイルを開いた時のような文字化けした文字列が出力される)

# 秘密鍵を利用してファイル復号("decrypted_test.txt"として復号)
$ openssl pkeyutl -decrypt -inkey private.pem -in encrypt_test.enc -out decrypted_test.txt

$ ls -l
total 20
-rw-r--r--. 1 ec2-user ec2-user   30 Apr 29 19:10 decrypted_test.txt
-rw-r--r--. 1 ec2-user ec2-user  256 Apr 29 19:07 encrypt_test.enc
-rw-r--r--. 1 ec2-user ec2-user   30 Apr 29 19:03 encrypt_test.txt
-rw-------. 1 ec2-user ec2-user 1704 Apr 29 19:05 private.pem
-rw-r--r--. 1 ec2-user ec2-user  451 Apr 29 19:07 public.pem

# 復号後ファイル内容
$ cat decrypted_test.txt
secure data 01
secure data 02

まとめ

EBSのボリューム暗号化オプションを有効化した場合、何が暗号化され、どういう脅威の対策になるのか整理を行った。
EFSやRDSにも同様の暗号化オプションは存在するが、攻撃者がサーバに不正に侵入された場合は
データがそのまま見えてしまう点では変わらない。
これに対策するためには、AWS機能としての暗号化オプションに加えて、ファイル単位での暗号化や、
データをハッシュしてデータベースへ格納する方法の検討が必要である。
AWSの責任共有モデルとしてもデータ暗号化はお客様責任範囲となってる。