GTM-MML4VXJ
Skip to main content
  1. ホーム >
  2. 製品 >
  3. ソフトウェア >
  4. ライブラリー >
  5. 特集>
  6. 情報漏えいに備えよ!PostgreSQLで透過的暗号化を実現(2/2)

富士通の技術者に聞く!PostgreSQL最新技術
情報漏えいに備えよ!PostgreSQLで透過的暗号化を実現(2/2)
PostgreSQLインサイド

富士通の技術者に聞く!PostgreSQL最新技術情報漏えいに備えよ!PostgreSQLで透過的暗号化を実現(2/2)

前へ

  • 1
  • 2

暗号化へのこだわり

―暗号化というと性能への影響が少なからずあると思います。先程「暗号化による性能への影響を極小化した」と伺いましたが詳しく説明していただけますか?

綱川

データベースの暗号化は性能への影響が大きいのでは?と心配されるお客様も多いと思います。
事実pgcryptoは、SQL文を実行するたびにデータベースキャッシュにあるデータを暗号化・復号するので、オーバーヘッドが大きくなります。
この点、私たちの開発したTDEでは、ストレージにデータを読み書きする時だけ暗号化・復号するので、データがデータベースキャッシュに載っている場合にはオーバーヘッドがありません。

―しかし、必ず全てのデータがデータベースキャッシュに載る訳ではないですよね?ストレージへの読み書き時に発生するオーバーヘッドは大丈夫なのでしょうか?

綱川

確かに、TDEでもストレージへデータを読み書きする際に発生するオーバーヘッドは存在します。しかし、ここはCPUの専用命令を活用して暗号化・復号を高速化することによって解決しました。
サーバなどに用いられるIntel Xeon プロセッサーの5600番台(開発コード名:Westmere-EP)以降には、AES-NI(Advanced Encryption Standard New Instructions)と呼ばれるAES 暗号化・復号処理をハードウェアで高速化するためのアクセラレーション機能が搭載されています。
AESは暗号強度が高い分、アルゴリズムが複雑で負荷が大きいと言われますが、暗号化機能のデファクトスタンダードとしてCPUに専用命令が搭載されているのです。
また、データベースのチューニングでも通常は可能な限りキャッシュヒット率を上げるのが碇石です。これらのことから、オーバーヘッドを気にせずアプリケーションで扱う全てのデータを暗号化できるようになっています。

―性能への影響は具体的にどのくらいになるのでしょうか?

綱川

実際にpgbenchを用いた更新の多いOLTPベンチマークで計測したところ、暗号化によるオーバーヘッドは3%未満でした。一方、ディスクへの読み書きが多いバッチ処理とロードでは、暗号化のオーバーヘッドがやや目立ちます。それでも、AES-NIがあると暗号化によるオーバーヘッドは10%未満に抑えられます。
詳細な測定環境や測定方法、データについては私が「PostgreSQLカンファレンス2013」で講演した際の資料に詳しく書かれていますので、興味がありましたらご覧ください。

「PostgreSQLカンファレンス2013」での講演資料
PostgreSQLにおける透過的データ暗号化の実装 (977 KB)(27ページ)

―性能のオーバーヘッドを極力無くすためにさまざまな努力を行なっているのですね。ここまで暗号化にこだわるのには何があるのでしょうか?

綱川

そもそも「PostgreSQLにTDEを実装してみたい」という技術者としての思いがありました。
TDEは商用データベースでもメジャーな製品にしか実装されておらず、オープンソースデータベースでは実装例がほとんどありません。そこに“やりがい”を感じました。

―TDEの実装に強い思いがあったのですね。開発の際に苦労もあったのではないでしょうか?

綱川

WALの暗号化はとても苦労しました。
データベースを暗号化するロジックは比較的単純なのです。なぜなら、ページ単位でストレージから読み書きするときに、暗号化・復号するだけでよいからです。テーブル空間単位に暗号化の有無を指定するので、中身を意識することなくページ全体を暗号化・復号すればよいのです。
でもWALはそうはいきません。ページ単位でストレージから読み書きするという点では、WALもデータベースと同じです。しかしWALの各ページには、異なるテーブル空間のデータに対する更新ログが混在する可能性があります。そのため、どの暗号化キーでページを暗号化・復号するかを決めることができないのです。

―WALは複雑なのですね。どのように解決されたのですか?

綱川

正攻法ですが、WALレコード毎に暗号化しています。1つのWALレコードに対し、更新対象となるデータが含まれているテーブル空間用の暗号化キーで暗号化します。さらに、暗号化処理のオーバーヘッドを最小化するために、WALレコード内のユーザーデータのみを暗号化するよう工夫しました。
大変だったのは、多数あるWALレコードの“どの部分がユーザーデータか?”を見極めて、その暗号化処理と復号処理を1つ1つ作り込んでいったことです。そういう努力をしたからこそ低いオーバーヘッドを実現できたと思います。

WALの暗号化の図

【WALの暗号化】

クラウドへの発展

―1つ1つを作り込む・・・ですか。オーバーヘッドを最小限に抑える裏には地道な努力があったのですね。ところで、情報の預け先として「クラウド」がますます増えていくと思いますが、クラウド上での情報漏えい対策について開発当初から何か念頭におかれていましたか?

綱川

はい、ありました。
TDEを開発した当時は、データベースやストレージのPaaSで暗号化が提供され始めていました。この状況を見て私は、『いずれどのPaaS/SaaSも自動的に全ての格納データを暗号化するのが当たり前になるだろう』と考えました。
事実、商用データベースを利用したDBaaSでは、既にOracle Database Cloud ServiceやAmazon RDS for Oracleが、TDEを利用して全データを自動的に暗号化しています。
ストレージサービスでは、Amazon S3がAPIでデータを書き込む時に、データ単位で暗号化の有無を指定できるようになっています。さらにGoogle Cloud Storageでは、暗号化の有無を指定することなく自動的に全てのデータが暗号化されます。
こうした中、オープンソースデータベースをクラウドで利用したいというニーズは必ず来るだろうと思い、このため『できるだけ早くTDEをサポートしたPostgreSQLをDBaaSで提供しなくては』と考えたのです。

―ただTDEに対応するのではなく、どのように活用されるかも視野に入れて実装したのですね。

綱川

そうです。現在ではPostgreSQLの人気が高まってきたことに伴いクラウドベンダー各社がDBaaSで提供しているのですが、当社のDBaaSだけが唯一TDEを提供しているのです。

―常にお客様のニーズを先読みして提供しているのですね。今後強化したい点はありますか?

綱川

いくつかありますが1つは、「HSM(Hardware Security Module)」による暗号化キーの堅牢な管理です。HSMとは鍵(暗号化キー)を守る金庫のような機能を持ったハードウェアです。高度なセキュリティが要求される金融機関などでは、HSMで暗号化キーを管理しているところもあります。
先程説明しましたが、TDEでは暗号化キーをキーストアというファイルに保存しています。もちろんキーストアは暗号化されているので安全ですが、攻撃者の手が届くところに“鍵”があるのは不安だというお客様もいらっしゃいます。
この点、HSMはデータベースから独立したハードウェアであり、かつ耐タンパー性に優れており、暗号化キーを一切外に取り出さずに暗号化・復号ができるので安心というわけです。

―専用のハードウェアによって更なる強固なセキュリティを実現するのですね。しかしハードウェアですと利用に制限があるのではないでしょうか?

綱川

HSMは1台数百万円と高価なため簡単に導入という訳にはいきませんし、ハードウェア装置のためパブリッククラウドでは使えませんでした。
しかし、AmazonがAWSクラウド上で利用できるHSMを「AWS CloudHSM」というサービスとして提供を始めましたし、2014年には新しい暗号化キー管理サービス「AWS Key Management Service」を発表したことから見ても、クラウドでの暗号化キー管理が一般的になってきそうです。
これらサービスとTDEの連携が実現できたら、パブリッククラウドでもTDEを利用しやすくなるかなと思っています。

―より高信頼な暗号化キーの管理がクラウドにまで発展するかもしれないのですね。

綱川

そうなるかもしれません。
もう一つは「TPM(Trusted Platform Module)」による暗号化キーの堅牢な管理です。
TPMというのは、コンピューターに搭載されているセキュリティチップです。身近なところでは、Microsoft Windows Vista以降に搭載されている「BitLockerドライブ暗号化機能」がTPMを利用したストレージの暗号化を行なえます。
TPMはコンピューターのマザーボードなどに直付けされており、チップ内での暗号化・復号やデジタル署名の生成・検証などができ、さらに少量のデータを保存できます。このTPMにマスター暗号化キーを格納できたら安全な管理ができるのではと思っています。
ただし、TPMはコンピューターに搭載されたセキュリティチップに依存するので、仮想環境ではどうするのかという問題があります。しかしこの問題を解決するために、「仮想TPM」と呼ばれるものが開発されているようですので、とても期待しています。

―今後は暗号化キーの管理をいかに強固なものにしていくのか?というのが文字通り“鍵”となるのですね!TDEの発展がますます楽しみです。

こちらもおすすめ

前へ

  • 1
  • 2

技術者からのコメント

富士通株式会社
ミドルウェア事業本部 データマネジメント・ミドルウェア事業部
綱川 貴之

入社以来、永年に渡り、データベース管理システム(Symfoware、PowerGres Plus、Interstage Shunsaku)の開発・保守・サポートに従事してきました。 また、富士通の各種ミドルウェアで利用されるPostgreSQLの技術サポートも単独で担当し、PostgreSQLカンファレンスで講演したり、社内の教育講座で講師を務めたりもしてきました。
私はオープンソース・コミュニティの力を強く信じています。オープンなPostgreSQLとともに、Symfowareがイノベーティブな進化をしていくのを楽しみにしています。


本ページに記載された内容は、掲載日現在のものです。その後予告なしに変更されることがあります。あらかじめご了承ください。

富士通のPostgreSQLに関する情報がここに「PostgreSQL インサイド」

製品情報

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

入力フォームはこちらから

当社はセキュリティ保護の観点からSSL技術を使用しております。

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)0120-933-200

受付時間 9時~17時30分
(土曜・日曜・祝日・当社指定の休業日を除く)