ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    データベースの暗号化

    このエントリーを含むはてなブックマーク はてなブックマーク - データベースの暗号化 あとで読む
    昨今、企業の個人情報漏洩が問題になっています。
    サーバーをクラックされて、データベースのデータが漏洩した場合でも、解読不可能となるように、データベースを暗号化しておくことは重要でしょう。

    最新のMySQLには、簡易の暗号化機能が実装されました。
    新機能にはバグが残っているかもしれないので、安定してから導入すれば良いかも?

    ●MySQL InnoDB Tablespace Encryption
    ・透過型のブロック暗号

    MySQL :: MySQL 5.7 Reference Manual :: 15.5.10 InnoDB Tablespace Encryption

    15.5.10 InnoDB Tablespace Encryption

    InnoDB supports data encryption for InnoDB tables stored in file-per-table tablespaces. This feature provides at-rest encryption for physical tablespace data files.



    UCO-Tech(InnoDB Tablespace Encryption) – UCOブログ

    このMySQL 5.7.11で、なんと新機能が搭載されました。
    新機能は、「InnoDB Tablespace Encryption」です。
    MySQLに格納されているデータは、ibdataファイル、もしくは、初期化パラメータ「innodb_file_per_table」がONの場合は、(テーブル名).ibdファイルという形で実ファイルで保持されています。
    しかし、このファイルは暗号化されていないため、OS上から直接中身を見ることができます。
    これを暗号化しよう、というのが、このInnoDB Tablespace Encryptionという機能です。



    MySQL商用版では、MySQL Enterprise Encryption, MySQL Enterprise Audit, MySQL Enterprise Firewallなど、セキュリティ系の製品が次々とリリースされています。
    これらの流れからみても、MySQLもセキュリティに力を入れ始めている(もしくは入れざるを得ない)という事情があるのかな、と言えるのではないでしょうか。



    MySQLの透過暗号化対応版が遂にリリース、ただし注意書き有り。 | Server-GENERAL

    大きく目立つように注意書きが添えられています。
    「これは法規制のコンプライアンスソリューションとして意図されていない。」
    「セキュリティ基準を満たすには鍵管理システムの利用が必須」
    と明記されています。

    読者の方はお分かりと思いますが、これは非常に重要なメッセージです。
    MySQLほど広く普及しているデータベースが透過型暗号に正式に対応したとなれば、セキュリティ技術に詳しく無い人も多く利用することになるでしょう。
    その中で暗号鍵の管理の重要性について理解していない人が安易な暗号化を採用しないように釘を差したとも言えます。


    マニュアルを見ると鍵管理はプラグイン化されているようなので、今後、商用版のリリースの中で本格的なMySQLの暗号化の鍵管理システムが提供されていくのではないかと思います。
    それでも暗号化されるのはInnoDBだけですので、まだまだ機能的には不十分です。



    暗号鍵をクラックされないように、保護しておく必要がありますね?

    ●MariaDB Encryption
    MySQLから派生したMariaDBも、データの暗号化機能を提供しています。

    MariaDB 10.1.7がリリースされました | スマートスタイル

    MariaDB10.1には、以下のような特徴があります。

    ・安全なマルチマスタ構成を実現するクラスタソフト「Galera Cluster」が、手軽に利用可能
    ・テーブル、またはテーブルスペースの暗号化機能
    ・InnoDBのページ圧縮機能
    ・GISデータ(地理データ)に対応
    ・新しいクエリ文法の実装、既存クエリの性能改善
    ・新たなサーバパラメータ変数、ステータス変数の追加



    Data at Rest Encryption - MariaDB Knowledge Base

    Encryption of tables and tablespaces was added in MariaDB 10.1.3. There were substantial changes made in MariaDB 10.1.4, and the description below applies only to MariaDB 10.1.4 and later



    MariaDB encryption is fully supported for the XtraDB and InnoDB storage engines. Additionally, encryption is supported for the Aria storage engine, but only for tables created with ROW_FORMAT=PAGE (the default).

    MariaDB allows the user to configure flexibly what to encrypt. In XtraDB or InnoDB, one can choose to encrypt:
    ・everything — all tablespaces (with all tables)
    ・individual tables
    ・everything, excluding individual tables
    Additionally, one can choose to encrypt XtraDB/InnoDB log files (recommended).



    Table and tablespace encryption on MariaDB 10.1.3 - MariaDB.org

    Performance Impact
    Encrypting the tables or tablespaces naturally have some effect on overall performance of the system. Naturally, the amount of performance effect encryption has is dependent on used hardware, workload and used encryption method.



    MariaDB Encryption Performance Impact

    処理速度は若干落ちますが、上記グラフはプロットがゼロ基準ではないので、それほど遜色はないでしょう。
    速度よりも安全性が重要な場面で利用すべきでしょう。

    ●段階的な暗号化
    暗号化を施す段階には、様々なレベルがあります。

    MySQLの保存データ暗号化(Percona Data Performance Blogより) | Yakst

    保存データ暗号化を行うためには主に3つの方法があります。

    ・フルディスク暗号化
    ・データベース(テーブル)レベル暗号化
    ・アプリケーションレベル暗号化。データがデータベースに挿入される前に暗号化されます。

    フルディスク暗号化は、誰かがディスクをサーバー上から物理的に持ち去るケースしか防ぐことしかできないため、最も強度の弱い方法です。
    一方で、アプリケーションレベルの暗号化は最善の方法です。ほとんどオーバーヘッドを発生させることなく伝送中のデータの暗号化も含め柔軟に行えるためです。
    残念なことに、アプリケーションのソースコードはアプリケーションレベルの暗号化を行うため常に変更できるとは限らないため、データベースレベル暗号化は非常に重要な代替手段となりえます。



    MariaDBのチーフアーキテクトであるSergei Golubchik氏はPercona Live Amsterdamのセッションでデータベース暗号化の長所、短所について次のように述べています。

    長所
     ・DBMSの全機能が利用できる
     ・実装しやすい
     ・データベースからのみデータが閲覧できる
     ・テーブル毎の暗号化、テーブル毎の鍵の設定ができる

    短所
     ・ユーザーごとに実施できない
     ・悪意あるrootユーザーから保護できない



    現在のところ、データベースレベルで保存データ暗号化を行う方法は2つあります。

    MariaDB 10.1.3以降がサポートする暗号化 (Googleのパッチを利用)
    MySQL 5.7.11以降(およびPercona Server 5.7.11)のInnoDBのテーブルスペースレベル暗号化

    MariaDBの実装はMySQL 5.7.11とは異なるものです。



    無償で使える他のRDBは、データの暗号化に対応しているのでしょうか?
    PostgreSQL データ 暗号化 - Google検索
    SQLite データ 暗号化 - Google検索
    どちらも、データを暗号化する方法が用意されているようでした。

    データベースレベルの暗号化には次の2つの弱点があります。

    1. rootおよびMySQLのユーザーはキーリングファイルを読み出し可能でこれは目的からすると大きな問題です。しかしながら、キーをマウントされたドライブ上に置きMySQL起動後にアンマウントする(これはスクリプト化可能)ことは可能です。しかし、MySQLがクラッシュした際に自動で再起動されず、人の介在が必要となってしまう問題があります。

    2. MariaDBのバージョンとMySQLのバージョンはディスクに書いたデータのみを暗号化しRAM上のデータは暗号化しないので、rootユーザーはMySQLにgdb/straceあるいは他のツールをMySQLにアタッチしてサーバー上のメモリを読むことができます。



    メモリ上のデータが暗号化されていないことは、確かに盲点ですね。
    メモリ上のデータまで保護しないといけないなら、データベース以前の話として、そもそもはサーバーをクラックされないようにするしかないのでしょう。

    ●参考

    MySQLおじさんの逆襲 from yoku0825


    SQLite の暗号化 from Akihiro Matsuura


    スマホアプリの制作でも、データストレージにRDBを利用している場合、データ暗号化は必須ですね?

    MariaDB&MySQL全機能バイブル
    鈴木 啓修 / 山田 奈緒子
    技術評論社
    2014-12-18
    ¥ 3,780

    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/1385-fb6f0c06

    FC2Ad