Amazon Web Services ブログ
Amazon RDS および Amazon Aurora のデータベースエンジンに適切な暗号化オプションを選ぶ
AWS クラウドのデータベースやデータストアの暗号化をデフォルトで選択するお客様の数は、ますます増えています。この流れは、さまざまな規制の枠組みにおいて機密データ (個人特定可能な情報 [PII、Personally Identifiable Information] など) の意味が発展していくのにともなって、勢いを増すばかりです。最新のデータベース暗号化の中から、パフォーマンスや各製品での迅速な反復を維持したまま最適なものを選ぶ方法について教えてほしい、というお客様からの要望も AWS に寄せられています。
そこで今回の記事では、Amazon RDS MySQL、MariaDB、Amazon Aurora MySQL の各データベースエンジンで使用できる、暗号化の方法をご紹介します。この記事は、ワークロードやビジネスのニーズに最も適した暗号化の方法を見つける一助となることを目指しています。なお簡略化のため、上記のエンジンをここでは “RDS MySQL 関連” のエンジン、または “MySQL 関連” のエンジンと呼びます。
概要
RDS で利用できる暗号化の方法は、次の 3 つのカテゴリーに分けることができます。
- 保存時のデータの暗号化。これには、プラットフォーム全般の機能およびデータベースエンジンそれ自体の機能が含まれます。
- 送信中のデータの暗号化。これは、データベースとクライアント間のネットワークを移動するデータを確実に保護する方法です。
- レプリケーション中に送信されるデータの暗号化。ひとつ前のカテゴリーと大きな違いはありませんが、こちらはデータベースサーバー間のデータレプリケーションのトラフィックに用いられる方法です。
次に、それぞれのカテゴリーを詳しく見ていき、ニーズに合わせて最も効果的に実装する方法をご紹介します。
保存時のデータの暗号化
RDS MySQL 関連のデータベースエンジンを使用している AWS の多くのお客様は、RDS リソースの暗号化に依存しています。RDS により暗号化されたリソースを使うと、データは保存時に、データベース (DB、Database) インスタンスの基盤となるストレージ、その自動バックアップ、リードレプリカ、スナップショットを含めて暗号化されます。この機能は、データの暗号化にオープン標準の AES-256 暗号化アルゴリズムを使用しています。このアルゴリズムはデータベースエンジンに対して透過的です。
Amazon EBS では、RDS MySQL と MariaDB 向けに、基盤となるストレージとスナップショット機能が提供されます。Aurora では、専用の、分散されたログ構造のストレージサービスが使用されています。暗号化された Aurora DB クラスターを使うと、ストレージサービスが保存したデータを、Amazon S3 に保存された関連のバックアップと一緒に永続的に暗号化することができます。
この暗号化は、物理的な流出や、DB インスタンスを回避したアクセスからデータを保護する方法です。したがって、不正アクセスを軽減するために、暗号化キーの効果的な管理やデータベース認証情報の管理の実践で、暗号化リソースを補完することが重要になります。さもなければ、認証情報の漏洩または不十分なキーの保護によって、権限のないユーザーがデータベースエンジンを介してプレーンテキストデータに直接アクセスすることを許してしまうおそれがあります。
暗号化キーの管理は、AWS KMS を使って行われます。AWS KMS を使うと、暗号化キーの作成や、キーの使用を制御するポリシーの定義が行えます。RDS MySQL 関連のエンジンでは 2 種類のキーを使用することができます。
- デフォルトキー
- AWS KMS カスタマーマスターキー (CMK、Customer Master Key)
デフォルトキーは、各 AWS アカウントで使用でき、1 回の操作で RDS リソースの暗号化が行えます。使い方は簡単ですが、ローテーション、失効、削除といった認証管理上の高度なアクションは実行できません。デフォルトキーは、キー管理を AWS に任せて、自分はその負担を負いたくないとお考えのお客様に最適です。
それに対し CMK は、暗号化キーのライフサイクル、アクセス制御、監査機能をすべて制御できます。その分、ユーザー側の管理負担も増えます。
暗号化リソースにより、バックアップやスナップショットのセキュリティにレイヤーが追加されます。一方で、スナップショットを共有したり、暗号化されたスナップショットから DB インスタンスやクラスターを復元したり、あるいは別のリージョンにスナップショットをコピーしたりする際に追加の作業が必要になる場合があります。例えば、デフォルトキーを使用しているスナップショットは、他の AWS アカウントと直接共有することはできません。まずスナップショットをコピーし、次にキーを CMK に変更します。
CMK で暗号化されたスナップショットを共有するときは、そのスナップショットが使用している CMK に、共有先の AWS アカウントへのアクセスを許可することも必要になります。RDS にはエンベロープ暗号化が採用されているので、コピーの実行中はデータは暗号化されたままとなります。エンベロープ暗号化では、データを物理的に暗号化している個々のデータキーは、指定された KMS キーを使って自らを暗号化します。
暗号化リソースでは、最新の CPU (AES-NI 以降の命令セットのバージョン) で提供されているハードウェアアクセラレーションが活用されています。ストレージレベルで実装することで、暗号化の有効化によって生じるパフォーマンスのオーバーヘッドは無視できるほど小さくなります。
以下のグラフは、r4.16xlarge サイズのシングルノードの Aurora MySQL DB クラスターで、2,000 件の同時接続を使用して、sysbench の OLTP の読み取り/書き込みのベンチマークを実行したときの影響を示したものです。平均実行時間は 1 時間超で、KMS で暗号化したデータベースクラスターと、暗号化していないデータベースクラスターの、Select Latency (読み取り) と DML Latency (書き込み) の Amazon CloudWatch メトリクスを追跡したグラフです。
平均的なクエリレイテンシーの差はごくわずかです。書き込みのレイテンシーは、このテストでは暗号化クラスターの方が約 0.027 ミリ秒遅くなっています。読み取りにおける暗号化の同様の影響は、通常は減少するか、バッファプールのページキャッシュによって不明確になります。このテストでは、100% に近い高いバッファプールのヒット率により、読み取りの遅延は 0.001 ミリ秒でした。これはあくまで合成テストです。結果は、多くの要因によって、個々のワークロードで異なる場合があります。
RDS 暗号化リソースは一般的な方法ですが、保存時のデータ暗号化を実装する唯一の方法ではありません。ユースケースによっては、例えば異なるユーザー間でデータへのアクセスを制限するなどして、論理レイヤーで暗号化を実装することが必要になります。多くのお客様は両方を実装しています。役割がそれぞれ異なるためです。それらを実行する方法は 2 通りあります。
- 暗号化機能を使用したフィールドでのデータ暗号化
- データベースサーバーに送信する前のクライアント側のデータ暗号化
RDS MySQL 関連のデータベースエンジンには、暗号化キーの管理機能が一切組み込まれていません。したがって、暗号化機能を持つキーの管理が実装の際の懸念として浮上します。キーはデータベースエンジンに渡されるので、SQL ステートメント、ログ、エンジンのプロセスリスト、またはその他監視機能などで漏洩するリスクが高まります。データベースへのクライアント接続が暗号化されていたとしても、このリスクは残ります。したがって、この方法では、お客様に適用されるすべてのデータ保護要件を満たすことはできません。
一方、クライアント側で暗号化を実行すると、データベースエンジンのログ記録機能や監視機能でキーが意図せず漏洩するリスクを防ぐことができます。さらに、クライアント側での暗号化は、暗号化/復号化の作業を実行する負担をすべてデータベースエンジンから取り除きます。
データを論理的に暗号化するどちらの方法を用いても、データのインデクサビリティとサーチャビリティには制限がもたらされます。データベースエンジンでは、プレーンテキストの値が暗号化されたフィールドに保存されません。暗号化テキストの値を使用したインデックスの構築は、インデックスの順序とカーディナリティに影響を及ぼします。暗号化テキストのインデックス作成は、実行プランの判断、つまりパフォーマンスに影響する場合があります。同様に、データベースエンジンが暗号化フィールドを評価できるのは、せいぜい “equal to” または “not equal to” 述語の観点からです。その他の評価は、データを暗号化した後に行わねばなりません。
こうした事情から、論理的なデータ暗号化は、一般に、ユーザーデータテーブルにおける個人の社会保障番号 (SSN、Social Security Number) の暗号化など狭いユースケースでしか実装されてきませんでした。その場合、論理的な暗号化により、必要なキーを持っているユーザーのみに SSN へのアクセスが制限されます。しかし、データベースの検索クエリも、実質的には特定の SSN のみを持つユーザーを特定することに制限されています。
RDS では tablespace の暗号化はサポートされていません。
送信中のデータの暗号化
RDS MySQL 関連のデータベースエンジンを使うと、データベースエンジンと Transport Layer Security (TLS) 暗号化接続を確立することができます。この接続は、しばしば Secure Sockets Layer (SSL) 暗号化と呼ばれることもありますが、この呼び方は、現在は非推奨の、TLS に先行する暗号プロトコルを特に指しています。RDS では該当のプロトコルはサポートされていません。
RDS は SSL 証明書を作成し、RDS がインスタンスをプロビジョンする際に、この証明書を DB インスタンスにインストールします。そして、認証機関がこれらの証明書に署名します。SSL 証明書には、スプーフィング攻撃を防止するため、SSL 証明書のコモンネーム (CN、Common Name) として DB インスタンスのエンドポイントが記載されています。
Aurora MySQL の DB クラスターでも、サブジェクトの別名 (SAN、Subject Alternative Name) としてクラスターエンドポイントが証明書に記載されています。クラスターデータベースのエンドポイントを Aurora との暗号化接続に使用し、サーバーの証明書またはアイデンティティを検証できるようにするには、データベースドライバーまたはクライアントが SAN をサポートしている必要があります。
サーバー側の観点から見ると、MySQL ベースのエンジンは、データベースユーザーのレベルで SSL 接続を使用するという要件を強制しています。したがって、リモート接続を採用しているユーザーアカウントは、必ず SSL を使用しなければなりません。具体的なコマンドはエンジンのバージョンによって異なり、それぞれのエンジンのドキュメントで確認できます。
クライアントが SSL 接続の使用を要求することもできます。AWS では、意図していないサーバーエンドポイントに接続するリスクを避けるため、ssl_mode = VERIFY_IDENTITY オプション (旧バージョンの場合は ‘ssl-verify-server-cert’) を使用してサーバーアイデンティティを検証することを推奨しています。
TLS 暗号プロトコルのバージョンも、データベースエンジンのバージョンによって異なります。RDS MySQL 5.6、MariaDB 10.0 と 10.1 の旧バージョン、および Aurora MySQL 5.6 がサポートしているのは TLS 1.0 のみです。さらに、RDS が使用している暗号ライブラリが変更され、新しいバージョンのデータベースエンジンにより yaSSL から OpenSSL へ移行しました。OpenSSL を使用している新しいバージョンは TLS 1.2 もサポートしています。詳細および最新の TLS サポート情報は、以下のトピックを参照してください。
TLS の複数のバージョンをサポートしている RDS MySQL 関連のエンジンのバージョン (MySQL 8.0 など) では、DB インスタンスのパラメータグループで tls_version パラメータを使用して、許可されたプロトコルバージョンを表示することができます。同様のクライアントパラメータは、ほとんどのクライアントツールまたはデータベースドライバーに存在します。データベースエンジンは、既定では、サーバーとクライアント設定の両方が許可している最新の TLS プロトコルバージョンを使用しようと試みます。
暗号化されたデータベース接続を確立しようとすると、コンピューティングリソースと、最初のクエリに対する応答レイテンシーの両方でオーバーヘッドが発生します。しかし、OpenSSL 暗号ライブラリを使用している新しいエンジンのバージョンでは、オーバーヘッドは低減されます。
暗号ライブラリに加味されている SSL 接続のオーバーヘッドの影響を例示するため、128 のクライアントスレッドを使って 100,000 件の個々の接続を確立するテストを実行しました。一般的な ‘SELECT 1’ クエリを実行して、接続が確立した時点からクライアントのレイテンシーを測定します。使用したインスタンスのクラスは r4.16xlarge です。RDS MySQL 5.7、MariaDB 10.2、Aurora MySQL 5.7 でそれぞれ 3 回ずつテストを実施し、結果を平均化しました (グラフが短い方が良い)。
このように、暗号化接続では接続レイテンシーは 2 倍以上高くなっています。また、yaSSL 暗号ライブラリにバンドルされている古いバージョンのエンジンへの暗号化接続における接続レイテンシーは、OpenSSL を使用する最新バージョンと比べ 3 倍高くなっています。これはあくまで合成テストです。結果は、同時実行、接続数、インスタンスクラス、その他要因に基づいて、ワークロードによって異なる場合があります。
以下の種類のアプリケーションでは、暗号化のオーバーヘッドが原因で非常に大きな影響が出る場合があります。
- 接続プールを活用できないアプリケーション。
- 接続プールの頻繁なドレインを必要とするアプリケーション。
- クエリへの応答レイテンシーが特定のしきい値を超えたとき積極的に再接続を試みるアプリケーション。
こうした動作の中にはベストプラクティスに従っていないものもあります。しかし多くの場合、レガシーアプリケーションは変更が困難です。こうしたユースケース向けに SSL 接続を実装するときは、接続リクエストのスパイクに対応できるだけの、十分なコンピューティング性能をテストし計画します。また、DB インスタンスのパラメータグループで、max_connections と max_user_connections パラメータを適正な値に設定します。すなわち、これらの値を、同時接続時の予測されるピークより少し上、ただし安全装置として十分機能できる低さに設定し、ランナウェイプロセスで接続リクエストがデータベースに一気に集中することを防ぎます。
レプリケーション中に送信されるデータの暗号化
RDS MySQL 関連のデータベースエンジンは、バイナリログ (binlog) を使用して、進行中の論理データレプリケーションを可能にします。レプリカサーバーは、他の MySQL クライアントと同様にマスター (ソース) に接続し、マスターに binlog をリクエストするコマンドを発行します。RDS MySQL 関連のエンジンでは、binlog ベースのレプリケーションは 2 つの形式で使用できます。
- ともに同じリージョン (同じデータベースサブネットグループ) 内にある、RDS が管理するリードレプリカ。またはクロスリージョンリードレプリカ。
- 手動の、外部で設定された binlog レプリケーション。
RDS が管理するリードレプリカは、読み取りスケーリング、およびクロスリージョンの DR ユースケースを可能にします。この機能により、レプリケーションは AWS が管理および監視します。データは、ソース DB インスタンスとリードレプリカの間の安全な通信チャネルを使って、リージョンを横断してレプリケーションされます。
RDS は、安全なチャネルを可能にするために必要な AWS のセキュリティ設定を確立します。例えばセキュリティグループのエントリを追加するなどです。Aurora MySQL の場合は、異なるメカニズムを使って、特定のリージョンの同じデータベースクラスターに読み取り可能なレプリカを提供します。binlog には依存しません。ただし、binlog ベースのリードレプリカクラスターを異なるリージョンに作成する機能は用意されています。
手動の、外部で設定された binlog レプリケーションの場合、binlog レプリケーションの設定、管理、監視に加え、レプリケーショントポロジーに関与するさまざまなサーバー間のネットワーク接続は、ユーザー側が担当します。
Aurora MySQL 5.6 では、Aurora MySQL レプリカから、オンプレミスでホストされているまたは Amazon EC2 にデプロイされている外部の MySQL マスターへの、レプリケーションのための SSL 暗号化接続を確立できます。この機能は、Aurora クラスターで MySQL マスターサーバーから SSL キーマテリアルをインポートすることを可能にする、サービスにより提供されるストアドプロシージャを使って有効化されています。
この機能は、RDS MySQL または MariaDB では利用できません。また、ユーザーは RDS または Aurora で実行しているマスターのキーマテリアルにアクセスできません。そのため、上記以外のユースケースでは SSL で暗号化された binlog レプリケーションの使用は制限されます。
多くのケースでは、暗号化されていない binlog トラフィックを VPN 接続を介して送信すればこの制限を回避できます。あるいは、レプリケーショントラフィックの完全なエンドツーエンドの暗号化が必要な場合は、AWS DMS で実行可能な代替案がみつかる場合があります。AWS DMS では、ソースとターゲットの両方のエンドポイントに暗号化接続を提供しています。
Aurora MySQL でも、論理レプリケーションや binlog から独立したデータレプリケーションのメカニズムを提供しています。Aurora Global Database で利用できるこの機能は、AWS リージョンの REDO ログストリームの物理レイヤーにおけるレプリケーションに依存しています。この技術は、より高い変更のスループットに対応でき、レプリケーションラグがより低く、かつより予測可能な、優れたレプリケーション体験を提供します。
Aurora Global Database は、専用のインフラストラクチャを使ってデータのレプリケーションを行うので、データベースのリソースはすべてアプリケーションワークロードに使用することができます。また、この専用のインフラストラクチャは、リージョン間のネットワークトラフィックを自動で暗号化し、ユーザーのデータを保護します。
まとめ
今回の記事では、MySQL および MariaDB が管理するデータベースエンジン、ならびに Aurora データベースエンジンで、保存時と送信中のデータを暗号化する RDS の機能を解説しました。また、暗号化リソースの実装、管理、パフォーマンスに関して考慮すべき重要な点にも焦点を当てました。
著者について
Vlad Vlasceanu はアマゾン ウェブ サービスのスペシャリストソリューションアーキテクトです。 お客様と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。