データベースの暗号化

データベース暗号化は、一般的に、データベースに保存されているデータを、最初に復号化しなければ理解できない「暗号文」に変換するアルゴリズムを使用するプロセスとして定義できます。 ^[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]

従来のデータベース暗号化技術は、通常、データベースの内容を暗号化および復号化することに注意することが重要です。データベースは、既存のオペレーティングシステム (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]ハッシュは一意であるため、両方のハッシュが一致した場合、ユーザーは正しいパスワードを入力したとみなされます。一般的なハッシュ関数の1つの例はSHA-256です。^[30]

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

一部のシステムでは、ハッシュ システムにソルトに加えて「ペッパー」が組み込まれています。ペッパー システムは議論の的となっていますが、その使用法を説明する必要があります。^[31]ペッパーは、ソルトが加えられたハッシュ パスワードに追加される値です。^[34]このペッパーは、多くの場合、1 つの Web サイトまたはサービスに固有のものであり、データベースに保存されているすべてのパスワードに同じペッパーが追加されることに注意してください。^[35]理論的には、ペッパーのシステム レベルの特異性を考えると、パスワード ハッシュ システムにペッパーを含めると、レインボー (入力: ハッシュ) テーブルのリスクが軽減される可能性がありますが、ペッパーの実装の実際の利点については、かなり議論されています。^[34]

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

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

アプリケーションレベルの暗号化の最も重要な利点の 1 つは、アプリケーションレベルの暗号化によって、企業が使用する暗号化プロセスが簡素化される可能性があることです。アプリケーションがデータベースから書き込み/変更するデータを暗号化する場合、二次的な暗号化ツールをシステムに統合する必要はありません。2 つ目の主な利点は、盗難という包括的なテーマに関連しています。データはサーバーに書き込まれる前に暗号化されるため、ハッカーが機密データを復号化するには、データベースの内容だけでなく、データベースの内容を暗号化および復号化するために使用されたアプリケーションにもアクセスする必要があります。^[37]

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

データベース暗号化について議論する際には、そのプロセスに伴うリスクを認識しておくことが不可欠です。最初のリスクはキー管理に関するものです。秘密キーが「隔離されたシステム」で管理されていない場合、悪意のあるシステム管理者がアクセスできるキーを使用して機密データを復号化できる可能性があります。キーの基本原則は、潜在的に壊滅的なリスクも生み出します。キーを紛失すると、暗号化されたデータも基本的に失われます。キーなしでの復号化はほぼ不可能だからです。^[38]

暗号化は、アルゴリズムを使用して情報を読み取り不可能な形式に変換することで、データベースに保存されているデータのセキュリティを強化するために使用できます。暗号化されたデータは、復号化キーを使用してのみアクセスおよび復号化できるため、データベースが侵害された場合でも、情報の機密性が確保されます。

パスワード、財務記録、個人情報などの機密データを暗号化することで、組織は不正アクセスやデータ侵害からデータを保護できます。このプロセスにより、データ盗難のリスクが軽減され、データ保護規制への準拠が保証されます。

データベースに暗号化を実装するには、Advanced Encryption Standard (AES) や Transport Layer Security (TLS) などの暗号化技術を利用する必要があります。暗号化キーは、データの不正な復号化を防ぐために安全に管理する必要があります。^[39]