🔐

AWS S3の暗号化とデータ保護について

2021/02/27に公開

概要

S3にデータを保存する機能を扱っている際に、暗号化をどこまでやるべきか、どのようにすべきか、そもそもどのようなメリットがあり、暗号化しないとどんな問題が生じるのか、などデータ保護の観点で割と多くの疑問が浮かんだので調べて分かったことを書いた。

S3のサーバーサイド暗号化を利用すると、オブジェクトをディスクに保存する前に暗号化し、オブジェクトをダウンロードするときに復号してくれる。

気をつけるべきは、オブジェクトへのアクセス権限さえあれば、データが参照できてしまうこと。

バケットの設定ミスでパブリックアクセスを許可したり、アクセスキーが流出したりすると、サーバーサイド暗号化はデータ保護になんの役割も果たさない。

ではなんのために暗号化するのか。それは、ディスクの中身を参照できるAWS内部の人や、ディスクを盗んだ悪人などにデータを参照させないためである。

ただ、AWS内部の人は信頼すべき相手なので問題はなく、悪人は巨大なAWSのデータセンターから目的のディスクをどのように見つけ出し、どのように盗むというのか。そのような事件が起こらない限り、暗号化しておらずともデータは保護される。

とはいえ、S3は設定のみでサーバーサイド暗号化をよしなにやってくれるので、設定しておいて損はない（個人的には、設定せずとも全バケットに対して勝手に暗号化してくれれば良いのに、とも思う）。

クライアントサイドでデータを暗号化した上で、S3にデータを送信し保存する。オブジェクトへのアクセス権限があったとしても、ダウンロードすると暗号化されたデータしか参照できない。元データを参照するには、クライアントサイドで復号する必要がある。

クライアントとは、殆どはS3にアクセスするアプリケーション（フロントエンド、バックエンド両方あり得る）になると思う（CLIの場合はターミナルなど）。

つまり、SDKなどを使って独自実装する必要がある。また、クライアントへの公開鍵の配布、秘密鍵の管理などやや複雑な仕組みの構築も不可欠だ。

サービス管理者側も簡単に見えてはいけないようなデータを保護したり、誤ってバケットをパブリック設定にしたとしても、暗号化されたデータしか流失しないので安心できる。

ただし、秘密鍵も漏洩した場合はその限りではないので、データ保護の根本的な解決にはならないということは覚えておかなければならない。

基本的にはIAMやバケットポリシーなどでアクセス権限を管理することでデータを保護する。実際、AWSは誤ったアクセス設定を行わないような仕組みを作っているし、アクセス権限で管理することを推奨している。

サーバーサイド暗号化は特にリソースコストも管理コストもかからないのでONにしておいて良い。

その上でプラスアルファでデータ保護を必要とする場合は、仕組みの構築や運用がやや大変だが、クライアントサイドによる暗号化を行うと良いだろう。