Amazon Web Services ブログ

AWS DMS および Baffle を使用して、アプリケーションに影響を与えることなくデータベースの列を暗号化する方法

AWS は、AWS Identity and Access Management (IAM) や AWS Key Management Service (AWS KMS)　などのインフラストラクチャおよびサービスを保護する、セキュリティ機能を豊富に提供しています。AWS Data Migration Service (AWS DMS) を使うと、既存のデータベースから Amazon RDS にデータを簡単に自動移行することができます。その一環として、AWS DMS はいくつかの AWS セキュリティ機能を使用し、お客様にサービスを提供しています。例えば、DMS は他のセキュリティ機能の中でも、AWS KMS キーを使用した、静止状態でのデータベース接続およびデータ暗号化のための Secure Socket Layer (SSL) 暗号化を、すでにサポートしています。

それでも、クラウド内のデータベースに移行する際に、付加的な法令遵守の義務や特定のセキュリティポリシーに遭遇する企業もあります。こうした企業は、クラウド責任共有モデルの中でも、適切なデータ保護手段を利用する必要があります。このようなユーザーに、Baffle は最も重要なデータを保護する、列レベルの暗号化メカニズムを提供しています。企業は、DMS の使用中でもアプリケーションの変更を行わず、このメカニズムを実装できます。

アプリケーションを変更せずに暗号化できるこの機能により、既存のアプリケーションや新しいアプリケーションにデータのプライバシーを追加することが可能となります。バックエンド管理者またはサードパーティがアプリケーションデータにアクセスできないようにするのです。このアプリケーションの透過性とプライバシー保護は、DMS がデータベース間でデータを移行するのに使用するツールにまで及びます。これらのツールを使用すると、データを Amazon RDS に移行する際にデータを暗号化することができます。DMS とのカスタム統合なしでデータを暗号化でき、AWS への移行中および移行後にデータが公開されるリスクはほとんどありません。

このブログ記事では、Baffle の Advanced Data Protection ソリューションを使用して、RDS に移行するデータベースを暗号化する方法について解説します。Baffle のアプローチだと、データがクラウド上にある間に、メモリ内であろうと静止状態であろうと、確実にデータが保護されるようにします。以下に示すように、実際上、標準の DMS 移行ワークフローにはほとんど変更がありません。

仕組みの説明

データの暗号化と復号化を行う主なコンポーネントは、BaffleShield SQL プロキシです。これは、AWS Marketplace の Baffle Advanced Data Protection ソリューションの一部です。Baffle (info@baffle.io) より、直接ライセンスを取得することもできます。

データを暗号化された形で RDS に移行するように、さらに BaffleShield をデプロイして、移行されるデータを BaffleShield 経由でルーティングするようにします。最終的に、データフローは次の図のようになります。システムの概要

デプロイと利用方法

Baffle Advanced Data Protection を使用して、データを RDS に移行する際に暗号化するには、次の前提条件が必要です。

  • ソースデータベースホスト上にある Java 1.8 ランタイム環境
  • ソースデータベースホスト上にデプロイした BaffleShield
  • DMS レプリケーションインスタンス

Baffle Advanced Data Protection を用いて DMS を移行するのに慣れるため、前出の前提条件を満たす AWS CloudFormation テンプレートを作成しました。このテンプレートには、次のものが含まれます。

  • サンプルの機密データを含む Amazon EC2 インスタンス上の MySQL 5.7 データベース
  • カスタマイズ可能な BaffleShield のインストール
  • 移行対象となる MySQL インスタンス用 RDS
  • 移行を実行する DMS レプリケーションインスタンス

GitHub にテンプレートを配置し、次のコマンドを使ってテンプレートをダウンロードし、強調表示された情報を自分のものに置き換えることができます。

git clone https://github.com/awslabs/aws-database-migration-tools

移行プロセスを開始する前に、まずソースデータベースにログインして、正しくセットアップされていることを確認します。EC2 インスタンスを特定するために、先ほど作成したばかりの CloudFormation スタックの [Resources] タブに移動します。それから、次のスクリーンショットのように、[SourceDatabase] の横にあるリンクをクリックします。[Resources] タブの [SourceDatabase] フィールドのスクリーンショット

リンクをクリックすると EC2 ダッシュボードが開き、CloudFormation が作成した新しい EC2 インスタンスの詳細が表示されます。このインスタンスのパブリック IP アドレスをコピーし、それを root に接続する MySQL Workbench のホスト名として貼り付けたいとします。接続先のユーザー名は root です。プロンプトが表示されたら、パスワードとして BaffleDMSDemo を使用します。データベースに接続する SQL Workbench のスクリーンショット

接続後、[select *]　コマンド (demo.billing テーブルに対する) を実行し、請求先の顧客に必要なクレジットカード取引情報を含んだ列を表示します。クレジットカード取引は通常、機密情報とみなされるのは言うまでもありません。Payment Card Industry Data Security Standard (PCI DSS) に準拠するには、このテーブルのほとんどの列を暗号化する必要があります。SQL Workbench でのクエリ実行のスクリーンショット

このデータベースを RDS に移行し、機密データ列が暗号化されていることを確認したいとしましょう。そのためには、BaffleShield を RDS のプロキシにする必要があります。そうすれば、BaffleShield は DMS から RDS に移行されるすべてのデータを暗号化できます。

BaffleShield をプロキシにする

このプロセスの最初の手順は、RDS インスタンスのホスト情報を取得することです。ここでも、CloudFormation が作成した RDS インスタンスは、スタックの [Resources] タブの中にあります。別の方法として、RDS コンソールに直接移動することも可能です。そこでは、スタックを作成したときに指定した名前と一致する DB インスタンスを見つけることができます。いずれの方法を使用しても、RDS インスタンスの接続情報に移動してホスト名をコピーできます。RDS インスタンスの詳細のスクリーンショット

この RDS ホスト名を start_bs スクリプトに貼り付けます。そこでは、MYSQL_SERVER_HOST 変数が定義されている必要があります。これを行うには、CloudFormation スタックの作成時に指定したキーペアを使用するよう設定してある Secure Shell (SSH) クライアントを使用します。クライアントを使用して、ソースデータベースインスタンスの IP アドレスに接続します。ユーザー名は centos である必要があります。ソースデータベースインスタンスに接続したら、/home/centos/baffle/baffle-manager ディレクトリに移動し、start_bs ファイルを編集して RDS ホスト名を設定します。

変更した start_bs スクリプトを保存した後、暗号化する列も定義する必要があります。通常は、BafflePrivacySchema ファイルを変更して行います。このデモンストレーションでは、BafflePrivacySchema ファイルは TxnID および OrderDate を除いて、請求テーブルのすべての列を暗号化するようすでに設定してあります。これらを除くすべての列には、1 つ以上のコンプライアンス要件によって機密扱いとみなされるデータが含まれています。エディタでファイルを開くと、設定を表示できます。

列が暗号化されていない場合でも、BafflePrivacySchema にテーブルのすべての列を定義する必要があることに注意しましょう。暗号化されていない列は、列名の後の値 -1 で識別されます。スキーマ構造のスクリーンショット

これで、start_bs シェルスクリプトを実行すると、BaffleShield を起動できるようになりました。

次に、BaffleShield を実行しながら、BaffleShield を介して DMS 移行プロセスをルーティングし、データが RDS に移行される際に暗号化されるようにします。それには、BaffleShield を移行先のエンドポイントにします。BaffleShield は RDS インスタンスをプロキシするため、BaffleShield に挿入されるデータはすべて BaffleShield によって RDS インスタンスに送信されますが、暗号化された形式で送信されます。

これを理解するために、ワークフロー全体を見てみましょう。まず、ソースエンドポイントを通常の DMS に設定します。スタックの一部として作成されたレプリケーションインスタンスを指定してください。インスタンス名は、bafflemigrationdemodms で始まる必要があります。DMS のエンドポイントペインの作成のスクリーンショット

次に、宛先エンドポイントを設定します。ここで、RDS サーバー名とポートを指定する代わりに、BaffleShield ホスト名とポートを指定します。ソース DB ホストに BaffleShield を導入したことを思い出してください。サーバー名は同じですが、ポートは現在 8444 です。(ファイアウォールルールにより、DMS インスタンスがポート 8444 に接続できることを確認してください)。このポートは BaffleShield のデフォルトですが、必要に応じて設定ファイルで変更することができます。BaffleShield は RDS をプロキシしているため、ユーザー名とパスワードは RDS インスタンス用に作成したものにする必要があります。DMS のエンドポイントペイン作成のスクリーンショット

両方のエンドポイントを作成したら、DMS コンソールのエンドポイントセクションに以下が表示されます。DMSエンドポイントのリストのスクリーンショット

ソースと宛先エンドポイントを指定した後、DMS タスクを作成してデータを移行することができます。次のスクリーンショットに示すように、他の DMS 移行タスクを作成するのと同じ方法で行います。DMS 移行タスクを作成する

タスクを作成すると、DMS は他の移行と同様、移行プロセスを開始します。現在の DMS タスクのスクリーンショット

このプロセスが完了したら、RDS インスタンスに接続して、データが実際に移行され、暗号化されていることを確認できます。このケースでは、MySQL Workbench を使用して RDS インスタンスへの接続を確立し、テーブルをダンプしました。TxnID 列と OrderDate 列以外のすべての列が、暗号化されていることが分かります。MySQL Workbench のスクリーンショット

できました! 冒頭に言ったとおり、標準の DMS ワークフローにはほとんど変更がありません。元のターゲット RDS インスタンスのプロキシに BaffleShield を設定し、それを DMS タスクの宛先エンドポイントとして指定した後は、他のすべてが以前と同じように動作します。唯一の違いは、すべての機密データが RDS インスタンスで暗号化されていることです。

Baffle は、クラウド移行計画の一環として、データの保護に役立ちます。Baffle は、オンプレミスシステムのセキュリティに対する心構えを改善するのにも役立ちます。これらの機能の詳細については、info@baffle.io までお問い合わせください。

著者について

Min-Hank Ho は、Baffle 社でエンジニアリング部門を統率しています。Baffleに入社する前は、Transparent Data Encryption を含む Oracle データベースのあらゆる暗号化ベースの機能の開発を担当し、データベースセキュリティの分野で 7 件の特許を取得しました。