【コラム】オープンソースDB、エンジンレベル、カラム暗号化、トータルソリューション

韓国と日本のITの現場は、一見似ているようで、まったく違う。主に使用するソフトウェアからもその差ははっきりしている。企業向けのソフトウェアの代表格であるデータベースだけを見ても、日本はMySQLやMariaDBそしてPostgreSQL等「オープンソースソフトウェア(Open Source Software)」の利用率が韓国に比べてはるかに高い。興味深い現象である。もう少し掘り下げてみましょう。

 

オープンソースデータベース

オープンソースソフトウェアは、長所がとても多い。誰でも無料でダウンロードし、自ら勉強しながら簡単に身につけることができる。だから、ユーザー層が厚い。一般企業では、このようなオープンソースソフトウェアの使える人材を簡単に採用することができるし、無料もしくは比較的に安い価格政策のおかげで、電算システムの構築費用を削減する効果も大きいとも言える。全世界数多くの開発者が自発的に参加する文化の産物であるため、最新技術の適用が速く、ソフトウェア自体の技術的な発展速度も早いということもまた大きな長所である。

ところが、韓国には何だか分からないけど「オープンソース」不信がある。「無料ソフトウェアを企業で使うのは、なんかちょっと不安じゃない？」と言い、値段の高い商用ソフトウェアを購入してしまうのだ。もちろん、商用ソフトウェアも長所が多い。オープンソースソフトウェアに比べて、より明確な開発ロードマップによって製品を開発して供給するため、急に生産終了になったり、アップグレードが中断される危険性が低い点だけでも、すでに十分な長所になる。しかし、純粋技術そのものだけを見てみると、オープンソースソフトウェアを選択する比率が高い日本の方が韓国に比べては「より技術的な理解に基づいて」意思決定をしていると考えても間違った解釈ではなさそうだ。 ところが、

「オープンソースデータベースは安全か?」

企業がソフトウェアを選択する基準は様々があるはずだが、その中でも最も重要な基準は、安全性ではないかと思う。特に、データベースの場合、安全性が不安なら性能が圧倒的に優れていると言っても絶対選択してはいけない。データベースは今日、企業の最も重要な資産であるデータを直接扱うソフトウェアだからである。韓国の企業が主に商用ソフトウェアを選択する最も大きな理由も安全性に対する漠然とした期待感があるからである。

こうしたデータベースやその中に入っているデータの安全性に影響を及ぼす様々な要素の中で最も重要なのは、暗号化である。暗号化は、データベースセキュリティの核心であり、本質である。その他にあらゆる道具は、暗号化の補助手段に過ぎない。今からは、データベース暗号化のあれこれを見ながら、OSSデータベースの安全性を考えてみよう。

 

データベース暗号化の種類

まずは、データベース暗号化の4つの方式を見てみよう。

1)アプリケーションAPI:アプリケーションソースの修正が必要
2)データベースAPI:データベースソースの修正が必要
3)暗号化プラグイン:DBサーバ内部に暗号化モジュール挿入
4)エンジンレベル暗号化:データベース内部に暗号化エンジン挿入、ソース修正は不要

1)から4)の順で暗号化を実現する位置が外部のアプリケーションからデータベースの内部に近くなる。よって、データベース内に直接暗号化エンジンを挿入する「エンジンレベル暗号化」は、アプリケーションやデータベースのソースの修正が不要なので、楽チンである。但し、エンジンレベルとなると、データベースのベンダーではない限り、難しく、これまではデータベースベンダーが独占してきた領域であった。他方、オープンソースデータベースは、ソース自体オープンであるため、エンジンレベル暗号化の開発が可能となるわけだ無論、開発のためには、高いレベルのセキュリティ技術は必須であることはいうまでもない。

 

そして、暗号化をする対象によって、暗号化の方式は３つに分けられる。

1)ディスク暗号化:データベースが保存されているディスク全体を暗号化
2)ファイル暗号化:データベースファイル全体を暗号化
3)カラム暗号化:データベース内部の特定カラムを指定して暗号化

1)から3)の順で、暗号化する対象のサイズが小さくなる。暗号化する対象のサイズが小さくなるということは、アクセス制御およびセキュリティ監査の効果、そしてセキュリティコントロール有効性(Security Control Granularity)が高くなる。すなわち、データ単位で細かくセキュリティ設定ができるという意味である。

技術的に論じる意味がないと言われているディスク暗号化は論外にしておいて、ファイル暗号化は、データベースファイルを丸ごと暗号化する方式である。ファイルの中に入ってあるどんな内容でも、閲覧するためにはファイル全体を復号しなければならないという意味である。他方、カラム暗号化は特定のデータを指定し、選択的に暗号化する方式である。それぞれメリット・デメリットはあるが、カラム暗号化は、必要なデータのみを選択的に暗号化ができ、そのデータ単位で細かくアクセス制御および監査の設定ができることからファイルを丸ごと暗号化するファイル暗号化に比べて業務プロセス負荷やセキュリティの面で有利な暗号化方式だと言えるでしょう。

かつてエンジンレベルの暗号化ソリューションは、カラム暗号化に対応できないと言われてきたが、進歩した技術よりエンジンレベルでの動作を確保しながらカラム単位の暗号化ができる製品が既に出てきている。

 

以上の暗号化方式は、それぞれ技術的なメリット・デメリットがあり、導入後、業務上体感するメリット・デメリットがある。技術的なメリット・デメリットももちろん導入時考慮しなければならない項目であるが、実質上、暗号化ソリューションは、導入による業務上負荷にて選定時大きく左右される。例えば、データーベースベンダーが大々的に広告しているエンジンレベルの「透過的(Transparent)暗号化」の訴求ポイントは、「ソースを修正する必要がないので楽な暗号化」というかたちになる。アプリケーションやデータベースのソースおよびクエリーを修正することなく、導入できるということは非常に魅力的である。

但し、暗号化ソリューションの導入を考えているのであれば、ひたすら利便性のみを重視してはいけなく、暗号化の本来の目的であるセキュリティの面からもちゃんと考慮しなければならない。利便性とセキュリティの両立を実現することはなかなか難しいことである。

 

「暗号化だけでは、セキュアではない」

暗号化だけでは、セキュアではない。暗号化だけではセキュアとは言えないということである。暗号化後、誰でもが復号できてしまったら、その暗号化はセキュアではなくなる。当然ながら権限のあるユーザのみが暗号化データを復号できるようにアクセス制御は必須である。そして、そのセキュリティシステムが正常に作動しているかを常に監視しなければならない。このように暗号化には、アクセス制御、そして監査は付き物である。

暗号化・アクセス制御、セキュリティ監査、そして、鍵管理でセキュアになれる。これは、暗号化を実現するにおいて、当たり前なことであり、基本中の基本である。業務によっては、セキュリティポリシー上必須機能はまだまだある。パスワード暗号化のための一方向暗号化、インデックスカラムのための部分暗号化、PCI-DSSの遵守のためのカード番号マスキング等データベース暗号化時の要素は、いくらでもある。市販のデータベース暗号化製品は、このような要素でセキュリティ設計がされているトータルソリューションとしてパッケージングされている。

開発者がOSS DBを無償でダウンロードし、インストールしたとして、セキュリティを実現するために上述の様々な要素を頑張って実装していくのも、できないわけではない。但し、費用対効果の問題が生じる。OSS DBに対しセキュリティを実現するために頑張ったコストは費用に高い。あとからのメンテナンスも懸念される。セキュリティは、専門家に任しておいて、ただただその製品を簡単に導入することでお互いハッピーになれるのである。セキュリティは、専門家に任しておくべきである。

 

それで、「オープンソースDB、エンジンレベル、カラム暗号化、トータルソリューション」

今まで見たデータベース暗号化のあれこれを総合してみると、「オープンソースDB、エンジンレベル、カラム暗号化、トータルソリューション」が必要だという結論に到達する。結論が理由なく長いわけではない。技術的、そして実務的な長所や短所を全て考えて、利便性やセキュリティ性を全て満たした結論である。それでは、また最初の質問に戻って、

「オープンソースデータベースは安全か？」

安全だ。オープンソースデータベースのエンジンレベルで動作しながら、カラム暗号化を支援して、アクセス制御やセキュリティ監査、鍵管理などのデータ暗号化の3代必須要素や一方向暗号化、部分暗号化、マスキングなど、必ず必要な機能までそろえた最新の暗号化トータルソリューションがあれば。

結論の核心は、いろいろな暗号化方式の中で「エンジンレベル暗号化」を通じて透明(Transparent)でありながらも「カラム暗号化」を支援することにより、データ単位で完璧なセキュリティ性を達成することがセキュリティ的には最も理想的な暗号化方式の組み合わせである。しかし、「透明性(Transparency)」と「セキュリティコントロール有効性(Security Control Granularity)」の中で一つだけを選択しなければならない状況であるなら、どんな場合でも絶対諦めてはいけない要素なので、セキュリティコントロール有効性を選択すべきである。

 

 

 

製品に関するお問い合わせ

E-Mail : japan@pentasecurity.com / TEL : 03-5361-8201