データベース（DB）は、企業のIT資産の中で最も事業的な価値のある情報システムで、事業に関わる顧客情報、財務データ、取引記録などが保管されている非常に重要な資産です。このようなDBを保護する重要性はますます高まっていますが、これを実行に移すことは想像以上に難しく、特に暗号化を実装する場合はなおさらです。事業の中核を担うDBは、悪意ある攻撃者にとっての明白なターゲットであり、予期し得ない攻撃によって事業情報が流出すれば、関連組織の財政や企業イメージに多大なダメージを与えることは明らかです。
今日では、マスコミでたびたび報じられている消費者取引記録やクレジットカード番号等の個人情報の流出にまつわる事故は、企業に新しい規約やDBセキュリティに関する法的要件を強いることになり、結局、企業はこうしたコンプライアンスや法令対応をきっかけとして、DBセキュリティのさらなる対策を強いられることが予想されます。この記事では、このような要件に合わせてDBセキュリティの根幹となるDB暗号化の多様な方式と特徴について説明します。
DBに対する攻撃の脅威は、ファイアウォールの外の外部ネットワークから始まるのが一般的ですが、今日の現実は、外部攻撃の脅威と同じくらい、認可された内部者による流出事故が頻繁に発生しています。これにより、ファイアウォール、侵入検知システムなどの伝統的な外部脅威を防ぐセキュリティインフラストラクチャーだけでなく、内部脅威を防ぐ戦略も必要になりました。
特に、DBは企業の重要な情報を集約して保管しており、ITインフラのさまざまなシステムからアクセスするため、それだけ複雑で脆弱な部分が露呈しやすい構造です。前述のように、単純にハッカーだけが攻撃の脅威の主体ではなく、ファイアウォールや侵入検知システムによって制御されない内部者による情報収集がより危険な状況であるため、DBで管理される機密情報を保護するための別の対策を求められることになり、この時に必要なのがDBセキュリティといえます。
DBセキュリティの主なポイントとしては、第一に暗号化を通じたDBセキュリティであり、第二に厳格な暗号鍵管理を通じて暗号化されたデータを保護することです。強力なデータ暗号化だけでなく、安全な暗号鍵管理の運用が実施されていることが、暗号化されたデータが流出してもデータを復号する手段がないように、暗号鍵の記録と少数の認可者によるアクセスのみを許可することが最終的なDBセキュリティの完成といえます。
DB暗号化時に考慮すべき事項
暗号化要件の分析
機密情報のセキュリティ性を高めるには、暗号化された形でデータを保存して管理するDB暗号化が最善の選択です。DB暗号化の目的は、非認可者によるデータの誤用を防止するためのもので、異常なデータ流出が発生した場合、復号を困難にすることです。暗号鍵は暗号化だけでなく、復号する際にも使用するため、暗号鍵は非常に慎重に管理しなければならず、高いbit数の暗号鍵によって暗号化されたデータは、ハッカーによる復号を困難にする利点があります。
DB暗号化によって機密データのセキュリティが強化されることは間違いありませんが、暗号化によるデータサイズの増加や性能低下などは、暗号化前に必ず考慮しなければならない事項です。システム性能に及ぼす影響は、アプリケーションの初期設計からDB暗号化を考慮すればよい結果をもたらすことができますが、現時点で使用しているシステムにDB暗号化を適用する際には、どのようなデータを暗号化するかを決定し、データサイズの増減に対する予測、そして暗号化データが使用される業務アプリケーションを分析すれば、現在運用しているシステムに最も効率的なDB暗号化方式を選択することができ、暗号化を実装したDBシステムを効率的に完成することができるでしょう。
例えば、カード番号全体を暗号化するのか、それとも部分的な暗号化を行うのか、暗号化を行う位置をDB内で行うのか、DB外部で行うのか、などの事前分析と決定を行います。DB外部で行うのか？などの事前分析と決定を通じて、適用しようとするDB暗号化方式を選択することが、この先のDB暗号化システム全体の性能と構造を決定することになります。
特に、DB暗号化時には、インデックス（Index）を持つカラムに対する暗号化後の性能に対する保証が難しい場合がありますが、導入しようとするDB暗号化ソリューションが、インデックスカラムの暗号化時にインデックス検索をサポートするかどうかは、重要な選定ファクターとなるでしょう。もし、インデックス検索をサポートしないDB暗号化ソリューションを導入する場合、暗号化後にインデックスを活用することができないため、特定のレコード値を探すために膨大な復号処理の負荷の発生と応答時間の低下が発生します。DB暗号化の対象カラムは、インデックスを持つ場合も多いため、事前に暗号化時にインデックス検索をサポートするDB暗号化ソリューションかどうかも必ず確認しなければなりません。
データフロー分析
DB暗号化を実行する前に、ITインフラ内のデータがどのように流れていて、どのシステムがそのデータを使用しているのかを把握することが非常に重要です。
一度DBが暗号化されると、それ自体でデータセキュリティを強化することができますが、暗号化後、アプリケーションサーバと通信する場合、そのアプリケーションサーバが復号されたデータを処理する過程で内部的にキャッシュを使用して一時保存すれば、このような復号された一時保存データを他の連携システムに転送し、中間処理過程で復号された平文データが存在する可能性があります。このように複雑なシステムが蜘蛛の巣のように絡み合っているシステム構成では、データフロー分析を通じて接続されたすべてのシステムで復号されたデータが存在せず、暗号化されたデータ状態で一貫して処理されるようにデータフロー分析が必ず必要になります。
暗号鍵の管理方法
DB暗号化の最も重要な要素の一つは、暗号鍵に対する管理であり、暗号鍵をどのように安全に保護するかが非常に重要です。暗号鍵管理の2つの側面としては、「どこに暗号鍵を保存するのか」と「誰がその暗号鍵にアクセスできるのか」を挙げることができ、安全な暗号鍵管理はDBセキュリティ戦略の非常に重要な要素といえます。
- どのくらいの暗号鍵を持つべきか？
- どのように暗号鍵を管理するのか？
- 暗号鍵はどこに保存されるのか？
- 暗号鍵のためのアクセスポリシーをどのようにするのか？
- 暗号鍵に対する使用履歴を管理しているか？
- 暗号鍵の紛失に対する対策はどのように立てているか？
暗号鍵の管理は非常に難しいですが、DB暗号化の際に必ず解決しなければならない事項です。
ひとつの暗号鍵でDB暗号化をする場合、構築は非常に簡単にできますが、その鍵が流出した場合、非常に危険な状況に陥る可能性があるという欠点があります。企業内には数多くのシステムがあり、それぞれのビジネスを処理するために暗号化されたデータを復号する暗号鍵を使用することになりますが、この場合、ひとつの暗号鍵で構成されたDB内のデータはデータ保護領域がなくなり、暗号化の意味を失うことになります。したがって、業務の範囲やシステムの役割に応じて暗号鍵を分離し、それに伴う暗号鍵のアクセス制御政策が必ず伴わなければなりません。つまり、暗号鍵管理の不便さを解消すると同時に、ひとつではなく少数の暗号鍵を分離して適用することが、セキュリティ強度を高めるよい戦略といえます。
次に決めなければならないことは、「どこに暗号鍵を保存し、管理するのか」です。別途の鍵管理システムがなければ、一般的に暗号化されたデータと同じ空間に暗号鍵が保存され、管理されるでしょう。しかし、このような管理は、DB管理者（DBA）がアクセス権限を持つことができ、暗号化されたデータにアクセスできる権限がある人は、暗号鍵にもアクセスできる場合がほとんどなので、暗号鍵流出に非常に危険な場合があります。したがって、DBサーバとは別の独立した場所（鍵管理システム）に暗号鍵を管理することが最も望ましい暗号鍵管理方法です。このように、暗号化データと分離されたアクセス制御が可能な安全な空間で管理される暗号鍵は、システム上のアクセス制御はもちろん、強力な認証と物理ファイルへのアクセス制限などの強力なセキュリティ措置を通じ、最も安全な暗号鍵管理を行うことにより、管理者や任意のユーザーによる最悪の暗号鍵流出事故も未然に防ぐことができます。
DB暗号化方式および暗号鍵の管理方法の選定
DB暗号化方式の効率的な選定は、まず「どこで暗号化を行うか」を決めることです。
DBサーバ内で暗号化
まず、DBサーバ内で暗号化を実行する場合には、現在使用しているアプリケーションへの影響を最小化しながらDB暗号化を適用することができるという利点があります。特に、システム設計時に暗号化に対する考慮がなく、システム運用中に暗号化を適用しなければならないシステムでは、既存のアプリケーションへの影響度が暗号化適用に最も重要な課題となり、この場合には、DBサーバ内で暗号化を実行するPlug-In方式（Oracle、MS-SQL Server）、Engine方式（MySQL、MariaDB）が最も効率的な暗号化方式といえます。
Plug-In、Engine方式は、DBサーバ内でカラム単位の暗号化を行いながら、DBMSユーザーに対する暗号化カラムのアクセス制御を行う方式です。このようにDBサーバ内で暗号化を行う方式は、アプリケーションへの影響が最小化されるという利点がありますが、予期せぬ性能低下により、暗号化適用後の追加メンテナンスが必要になる可能性があるという欠点も存在します。しかし、現在運用中のシステムに既存のアプリケーションの影響を最小限に抑えながら、暗号化インデックスまでサポートできるDB暗号化として最も一般的な方式といえます。
DBサーバ外部で暗号化
次に、DBサーバではなく、別のアプリケーションサーバやWebサーバで暗号化を行う方式です。API方式と呼ばれ、DBサーバではなく、アプリケーションサーバやWASサーバで暗号化されたデータを復号して処理する方式です。
現在運用中のシステムに暗号化を適用する場合と違い、新規システム構築や次世代システム設計時に多く検討される方式で、先に説明したPlug-In、Engine方式とは異なり、アプリケーションの内部に入出力するデータ暗号化と復号処理を実装します。
長所はやはりアプリケーション側での入出力による処理効率に優れた暗号化性能と暗号化によるデータベースへの追加的なシステム負荷を最小化できることであり、短所は暗号化導入時に必ず現在のアプリケーションの修正が必要であるということです。
システムの性能と信頼が最も重要視される金融業界で好まれる暗号化方式であり、初期構築費用はかかるかもしれませんが、暗号化構築後の運用およびメンテナンスでは最も信頼性の高い暗号化方式です。
ファイルの暗号化
もうひとつの方式としては、Kernel方式（Windows OS）が存在します。Windows OSのカーネルでファイル単位の自動暗号化を行う方式で、先に説明したカラム単位の方式とは違って物理的なファイルに対する暗号化を行う方式です。
流出に敏感な個人情報や機密情報のデータは、必ずしもDB内にのみ存在するのではなく、文書や画像、写真ファイルに存在する可能性があるため、物理ファイルを暗号化する際に使用できる方式です。特に、OSカーネルで暗号化動作する方式で、既存のアプリケーションの改修等がなく、暗号化導入時のシステム性能低下も1%未満という導入のハードルが極めて小さいという利点があります。
特に、Kernel方式を使用してOracle、MS-SQL ServerなどのDBMSのデータファイル（テーブルスペースファイル）を暗号化すれば、Plug-In、API方式と同じように、DBを暗号化するための選択の中で最も容易な手段となります。
この方式は医療業界で多く使用されており、X-RAY写真、整形外科の整形前/後の写真などの個人情報や機密情報を含むファイルを暗号化して記録・保持する場合に優れています。
暗号鍵の管理
PCI-DSS 4.0などのさまざまなセキュリティ認証では、厳格な暗号鍵管理と分離の原則を勧告しており、色々なところで暗号鍵は必ず暗号化データとは分離された別の安全な空間で管理するーという指針が存在します。このように、DB内の暗号文と復号のための手段となる暗号鍵が分離されて管理することは、セキュリティ上では必要な要件となり、ここに認可されたユーザーだけが暗号鍵にアクセスできる、すなわち暗号鍵に対するアクセス制御が実行されることによって、安全な暗号鍵管理ということができます。このように分離された安全な空間で管理される暗号鍵は、強力なアクセス制御と暗号鍵の使用履歴に対する監査ログを備えていることにより、暗号データが流出しても暗号鍵は保護され、流出した暗号データがハッカーによって復号されるような最悪の状況を防ぐためのリスク管理となります。
まとめ
DB暗号化を適用する際には、まず現在運用しているシステム環境を分析し、そして暗号化対象とするデータを最小限に、正しく選定することが重要です。これにより、最も安全で効率的な暗号化方式を選定することが、目的とするDB暗号化システムを完成するための最短距離となります。そして、もうひとつの重要な安全性の基準である暗号鍵をデータと分離して管理するようにし、暗号化データが流出する万一のリスクに備えなければなりません。
データ暗号化プラットフォーム「D'Amo」は、最も好まれるPlug-In方式からAPI方式、Engine方式、Kernel方式まで、現存するすべての暗号化方式をサポートしており、強力な暗号化機能とともに、暗号化インデックス検索のサポート、多様なアクセス制御機能まで、暗号化で要求されているすべてのセキュリティ機能を満たすDB暗号化ソリューションです。また、別途の暗号鍵管理システムを併用することにより、暗号化されたデータとは区分された安全な空間で暗号鍵を管理することは、多くのコンプライアンス等のセキュリティ要件に対応することを意味します。
現在運用中のシステムに対しても、最適な暗号化方式を提供し、安全な暗号鍵管理機能を持つD'Amoは、DB暗号化プロジェクトの成功への近道をお約束します。
