データベース暗号化

Security and privacy measure

データベース暗号化は、一般的に、データベースに保存されたデータを、アルゴリズムを用いて「暗号文」に変換し、復号化しなければ理解できないプロセスと定義できます。^{[1]したがって、データベース}暗号化の目的は、データベースに保存されたデータを、潜在的に「悪意のある」意図を持つ個人によるアクセスから保護することであると言えます。 ^[2]また、データベースを暗号化する行為は、ハッカーがデータを取得するための手順を「意味のない」暗号化データに増やすことになるため、個人が前述のデータベースをハッキングする動機を低下させます。^[3]データベース暗号化には複数の手法とテクノロジーが利用可能ですが、その中で最も重要なものについて、この記事で詳しく説明します。

透過的/外部データベース暗号化

透過的データ暗号化（TDEと略されることが多い）は、データベース全体を暗号化するために使用されます^[2] 。つまり、これは「保存データ」の暗号化を伴います^[4] 。保存データとは、一般的に、現在編集されていない、またはネットワークを介してプッシュされていない「非アクティブ」なデータと定義できます^[5] 。例えば、コンピュータに保存されているテキストファイルは、開かれて編集されるまで「保存」されています。保存データは、テープやハードディスクドライブなどの物理的なストレージメディアソリューションに保存されます^[6] 。大量の機密データを物理的なストレージメディアに保存することは、当然のことながら、セキュリティと盗難の懸念を引き起こします。TDEは、物理的なストレージメディア上のデータが、盗もうとする悪意のある個人によって読み取られないことを保証します^[7]。読み取れないデータは価値がないため、盗難の動機が減少します。TDEの最も重要な強みは、おそらくその透明性です。TDEはすべてのデータを暗号化するため、TDEを正しく動作させるためにアプリケーションを変更する必要はないと言えます。^[8] TDEはデータベース全体だけでなく、データベースのバックアップも暗号化することに留意することが重要です。TDEの透過的な要素は、TDEが「ページレベル」で暗号化を行うという事実に関係しています。これは基本的に、データが保存時に暗号化され、システムのメモリに呼び出される際に復号されることを意味します。^[9]データベースの内容は、「データベース暗号化キー」と呼ばれる対称鍵を使用して暗号化されます。^[2]

列レベルの暗号化

列レベル暗号化を説明するには、基本的なデータベース構造を概説することが重要です。典型的なリレーショナルデータベースは、テーブルに分割され、テーブルは列に分割され、各列にはデータ行が含まれます。^[10] TDEは通常、データベース全体を暗号化しますが、列レベル暗号化では、データベース内の個々の列を暗号化できます。^[11]列レベル暗号化の粒度によって、データベース全体を暗号化する場合と比較して、特定の長所と短所が生じることを認識することが重要です。第一に、個々の列を暗号化できるため、TDEのようなデータベース全体を暗号化する暗号化システムと比較して、列レベル暗号化ははるかに柔軟です。第二に、データベース内の各列に完全に一意で個別の暗号化キーを使用できます。これにより、レインボーテーブルの生成が実質的に困難になり、各列に格納されたデータが紛失または漏洩する可能性が低くなります。列レベルデータベース暗号化の主な欠点は、速度、あるいはその低下です。同じデータベース内で異なる一意のキーを持つ別々の列を暗号化すると、データベースのパフォーマンスが低下する可能性があり、さらにデータベースの内容をインデックスしたり検索したりする速度も低下します。^[12]

フィールドレベルの暗号化^{[疑わしい–議論する]}

暗号化されたフィールドに対して、復号化することなくデータベース操作（検索や算術演算など）を実行できるようにする実験的な研究が進められています。^[13]強力な暗号化はランダム化される必要があり、毎回異なる結果が生成される必要があります。これは確率的暗号化と呼ばれます。フィールドレベルの暗号化はランダム化暗号化よりも弱いですが、ユーザーはデータを復号化することなく等価性を検証できます。^[14]

ファイルシステムレベルの暗号化

暗号化ファイルシステム（EFS）

従来のデータベース暗号化技術は通常、データベースの内容を暗号化および復号化する点に留意することが重要です。データベースは、既存のオペレーティングシステム（OS）上で動作する「データベース管理システム」（DBMS）によって管理されます。^[15]暗号化されたデータベースが、アクセス可能で潜在的に脆弱なオペレーティングシステム上で実行される可能性があるため、潜在的なセキュリティ上の懸念が生じます。EFSはデータベースシステムの一部ではないデータを暗号化できるため、データベースファイルの暗号化のみ可能なTDEなどのシステムと比較して、EFSの暗号化の範囲ははるかに広くなります。^[要出典] EFSは暗号化の範囲を広げますが、データベースのパフォーマンスを低下させ、システム管理者がEFSを使用するためにオペレーティングシステムへのアクセスを必要とするため、管理上の問題が発生する可能性があります。パフォーマンスに関する問題のため、EFSは通常、データベースへの頻繁な入出力を必要とするデータベースアプリケーションでは使用されません。パフォーマンスの問題を相殺するために、EFSシステムはユーザー数の少ない環境で使用することが推奨されることが多いです。^[16]

フルディスク暗号化

BitLockerにはEFSに関連するようなパフォーマンス上の懸念はありません。^[16]

対称および非対称データベース暗号化

対称データベース暗号化

データベース暗号化における対称暗号化では、データベースに保存され、データベースから呼び出されるデータに秘密鍵が適用されます。この秘密鍵は、データを復号化しなければ読み取れないようにデータを変更します。^[17]データは保存時に暗号化され、ユーザーが秘密鍵を知っている限り、開く際に復号化されます。したがって、データをデータベースを介して共有する場合、受信側は送信者が使用した秘密鍵のコピーを持っていなければ、データを復号化して表示できません。^[18]対称暗号化の明らかな欠点は、秘密鍵がデータにアクセスすべきでない個人に拡散した場合、機密データが漏洩する可能性があることです。^[17]しかし、暗号化プロセスには1つの鍵しか使用されないことを考えると、一般的に速度は対称暗号化の利点と言えるでしょう。^[19]

非対称データベース暗号化

非対称暗号化は、対称暗号化を拡張したもので、暗号化方式に秘密鍵と公開鍵という2種類の鍵を組み込んでいます。^[20]公開鍵は誰でもアクセスでき、1人のユーザーに固有のものです。一方、秘密鍵は1人のユーザーのみが知っている秘密鍵です。^[21]ほとんどの場合、公開鍵が暗号化鍵で、秘密鍵が復号化鍵です。例えば、個人Aが非対称暗号化を使用して個人Bにメッセージを送信する場合、個人Bの公開鍵を使用してメッセージを暗号化し、暗号化バージョンを送信します。個人Bは自分の秘密鍵を使用してメッセージを復号化できます。個人Cは個人Aのメッセージを復号化できません。なぜなら、個人Cの秘密鍵は個人Bの秘密鍵と同じではないからです。^[22]非対称暗号化は、2つの別々の鍵で暗号化と復号化のプロセスを処理するため秘密鍵を共有する必要がないため、対称データベース暗号化と比較してより安全であるとよく説明されます。^[23]パフォーマンス上の理由から、通常は対称暗号化で行われるデータの暗号化ではなく、非対称暗号化がキー管理に使用されます。

鍵管理

対称鍵と非対称鍵データベース暗号化のセクションでは、ユーザーが鍵を交換する基本的な例を用いて、公開鍵と秘密鍵の概念を紹介しました。多くの異なるユーザーが互いに通信する必要がある場合、鍵の交換はロジスティクスの観点から現実的ではありません。データベース暗号化では、システムが鍵の保管と交換を処理します。このプロセスは鍵管理と呼ばれます。暗号化鍵が適切に管理・保管されていない場合、機密性の高いデータが漏洩する可能性があります。さらに、鍵管理システムが鍵を削除または紛失した場合、その鍵で暗号化された情報も実質的に「失われた」状態になります。鍵管理ロジスティクスの複雑さも考慮すべき点です。企業が使用するアプリケーションの数が増えるにつれて、保管・管理する必要がある鍵の数も増加します。したがって、すべてのアプリケーションの鍵を単一のチャネルで管理できる方法を確立する必要があります。これはエンタープライズ鍵管理とも呼ばれます。^[24]エンタープライズ鍵管理ソリューションは、テクノロジー業界の多くのサプライヤーによって販売されています。これらのシステムは本質的に集中型の鍵管理ソリューションを提供し、管理者はシステム内のすべての鍵を1つのハブから管理することができます。^[25]したがって、エンタープライズ鍵管理ソリューションの導入は、データベース暗号化における鍵管理に伴うリスクを軽減するだけでなく、多くの個人が手動で鍵を共有しようとする際に発生する物流上のトラブルを軽減する可能性があると言えます。^[24]

ハッシュ

ハッシュは、データベースシステムにおいて、パスワードなどの機密データを保護する方法として使用されていますが、データベース参照の効率を向上させるためにも使用されています。^[26]入力データはハッシュアルゴリズムによって操作されます。ハッシュアルゴリズムは、入力データを固定長の文字列に変換し、データベースに格納します。ハッシュシステムには、ここで概説する2つの極めて重要な特性があります。第一に、ハッシュは「一意かつ反復可能」であるということです。例えば、「cat」という単語を同じハッシュアルゴリズムに複数回通すと、常に同じハッシュが生成されますが、「cat」と同じハッシュを返す単語を見つけるのは非常に困難です。^[27]第二に、ハッシュアルゴリズムは可逆ではありません。上記の例に当てはめると、ハッシュアルゴリズムの出力を元の入力である「cat」に戻すことはほぼ不可能です。^[28]データベース暗号化の文脈では、ハッシュはパスワードシステムでよく使用されます。ユーザーが最初にパスワードを作成すると、ハッシュアルゴリズムが実行され、ハッシュとして保存されます。ユーザーがウェブサイトに再度ログインすると、入力したパスワードがハッシュアルゴリズムにかけられ、保存されているハッシュと比較されます。^[29]ハッシュは一意であるため、両方のハッシュが一致すれば、ユーザーは正しいパスワードを入力したと判断されます。一般的なハッシュ関数の一例として、 SHA-256が挙げられます。^[30]

塩漬け

データベース暗号化の文脈において、パスワード管理にハッシュ化を用いる際に生じる問題の一つは、悪意のあるユーザーが、システムが使用する特定のハッシュ化アルゴリズムに対応するレインボーテーブル^[31]を悪用する可能性があることです。これにより、悪意のあるユーザーはハッシュを復号化し、保存されているパスワードにアクセスできるようになります。^[32]この問題の解決策の一つは、ハッシュに「ソルト」を加えることです。ソルトとは、データベース内のパスワード以外の情報も暗号化するプロセスです。ハッシュ化される文字列に追加される情報が多いほど、レインボーテーブルの照合は困難になります。例えば、システムはユーザーのメールアドレスとパスワードを単一のハッシュに結合することがあります。ハッシュの複雑さが増すということは、レインボーテーブルの生成がはるかに困難になり、生成の可能性も低くなることを意味します。これは当然のことながら、ハッシュにソルトを加えることで機密データの損失の脅威を最小限に抑えられることを意味します。^[33]

ペッパー

一部のシステムでは、ハッシュシステムにソルトに加えて「ペッパー」を組み込んでいます。ペッパーシステムは議論の的となっていますが、その用途を説明することは依然として必要です。^[31]ペッパーとは、ソルトが付加されたハッシュ化されたパスワードに追加される値です。^[34]このペッパーは、多くの場合、1つのウェブサイトまたはサービスに固有のものであり、データベースに保存されているすべてのパスワードに同じペッパーが追加されることに注意することが重要です。^[35]理論的には、ペッパーのシステムレベルの特異性を考慮すると、パスワードハッシュシステムにペッパーを組み込むことで、レインボー（入力：ハッシュ）テーブルのリスクを軽減できる可能性がありますが、ペッパーの実装が実際にどのようなメリットをもたらすかについては、多くの議論があります。^[34]

アプリケーションレベルの暗号化

アプリケーションレベルの暗号化では、暗号化対象となるデータの生成または変更に使用されたアプリケーションによってデータの暗号化プロセスが完了します。これは基本的に、データがデータベースに書き込まれる前に暗号化されることを意味します。この独自の暗号化アプローチにより、アプリケーションがユーザーについて知っている情報（権限やロールなど）に基づいて、各ユーザーに合わせて暗号化プロセスをカスタマイズすることが可能になります。^[35]

ユージン・ピリャンケビッチによれば、「アプリケーションレベルの暗号化は、セキュリティ要件が高まり、境界のない、より露出度の高いクラウドシステムへの一般的な流れが進む中で、システムにとって良い方法になりつつある」とのことです。^[36]

アプリケーションレベルの暗号化の利点

アプリケーションレベル暗号化の最も重要な利点の一つは、企業が使用する暗号化プロセスを簡素化できる可能性があることです。アプリケーションがデータベースに書き込み/変更するデータを暗号化すれば、二次的な暗号化ツールをシステムに統合する必要がなくなります。二つ目の大きな利点は、盗難という根本的な問題に関係しています。データはサーバーに書き込まれる前に暗号化されるため、ハッカーが機密データを復号するには、データベースの内容だけでなく、データベースの内容を暗号化・復号するために使用されたアプリケーションにもアクセスする必要があります。^[37]

アプリケーションレベルの暗号化の欠点

アプリケーションレベル暗号化の第一の重要な欠点は、企業が使用するアプリケーション自体をデータ暗号化のために変更する必要があることです。これは、多大な時間とその他のリソースを消費する可能性があります。機会費用の性質を考えると、企業はアプリケーションレベル暗号化への投資に見合う価値があるとは考えないかもしれません。さらに、アプリケーションレベル暗号化はデータベースのパフォーマンスに限界的な影響を及ぼす可能性があります。データベース上のすべてのデータが多数の異なるアプリケーションによって暗号化されると、データベース上のデータのインデックス作成や検索が不可能になります。これを現実的な例として示すと、30の言語で書かれた書籍の用語集を1つの言語で作成することは不可能です。最後に、複数の異なるアプリケーションがデータを暗号化してデータベースに書き込むための権限とアクセス権を持つ必要があるため、鍵管理の複雑さが増します。^[37]