暗号化を使用してMongoDBデータを保護する方法

データベースのセキュリティは、財務レポートやヘルスレポートなどの機密性の高いデータを含むアプリケーションで考慮すべき重要な要素です。データ保護は、アプリケーション自体からデータを保持するファイルまで、さまざまなレベルで暗号化することで実現できます。

MongoDBは非リレーショナルデータベースであるため、データを挿入する前に列を定義する必要はありません。したがって、同じコレクション内のドキュメントは、互いに異なるフィールドを持つ可能性があります。

一方、SQL DBMSの場合、データの列を定義する必要があるため、すべての行に同じ列があります。データベースプロセスに関与する前に、個々の列、データベースファイル全体、またはアプリケーションからのデータを暗号化することを決定できます。

個々の列の暗号化は、より安価で暗号化されるデータが少ないため、待ち時間が改善されるため、最も推奨されます。一般に、暗号化の結果として全体的なパフォーマンスに影響があります。

ただし、NoSQL DBMSの場合、このアプローチは最適ではありません。すべてのドキュメントに暗号化で使用するすべてのフィールドが含まれているとは限らないことを考慮すると、列レベルの暗号化を実行することはできません。

アプリケーションレベルでのデータの暗号化は、非常にコストがかかり、実装が困難です。したがって、データベースレベルでデータを暗号化するオプションが残っています。

MongoDBは、機密データを保護するために追加のコストを支払う必要のないネイティブ暗号化を提供します。

MongoDBでのデータの暗号化

データベース操作には、これら2つのデータ形式、保存データまたは移動中のデータのいずれかが含まれます。

移動中のデータはあらゆる種類のネットワークを移動するデータのストリームですが、保存中のデータは静的であるため、どこにも移動しません。

これらの2つのデータ型はどちらも、暗号化が含まれていない限り、匿名ユーザーによる外部干渉を受けやすい傾向があります。暗号化プロセスには以下が含まれます：

データベース全体のマスターキーを生成する
データベースごとに一意のキーを生成する
生成したデータベースキーを使用してデータを暗号化する
マスターキーを使用してデータベース全体を暗号化する

転送中のデータの暗号化

データは、MongoDBとサーバーアプリケーションの間で、トランスポート層セキュリティ（TLS）とセキュアソケット層（SSL）の2つの方法で処理されます。

これら2つは、2つのシステム間で送受信されるデータを保護するために最もよく使用される暗号化プロトコルです。基本的に、概念は、ネットワークトラフィックが目的のクライアントによってのみ読み取られるように、mongodおよびmongosインスタンスへの接続を暗号化することです。

TLS / SSLは、認証局によって発行された、または自己署名証明書である可能性のあるPEMファイルとしていくつかの証明書とともにMongoDBで使用されます。後者には、通信チャネルが暗号化されていても、サーバーIDに対する検証が常に行われないため、途中で外部からの攻撃に対して脆弱であるという制限があります。したがって、MongoDBドライバーがサーバーIDも検証できるようにする信頼できる機関証明書を使用することをお勧めします。

暗号化に加えて、TLS / SSLは、クライアントの認証、および証明書を介したレプリカセットとシャードクラスターのメンバーの内部認証に使用できます。

クライアントのTLS/SSL構成

これらのプロトコルの構成で使用できるさまざまなTLS/SSLオプション設定があります。

たとえば、暗号化を使用してMongodインスタンスに接続する場合は、次のようにインスタンスを開始します。

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--sslはTLS/SSL接続を有効にします。

--sslCAFileは、mongodまたはmongosによって提示された証明書を検証するための認証局（CA）pemファイルを指定します。したがって、Mongoシェルは、mongodインスタンスによって発行された証明書を、指定されたCAファイルとホスト名に対して検証します。

クライアント証明書を必要とするMongoDBインスタンスに接続することもできます。以下のコードサンプルを使用します

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

オプション--sslPEMKeyFileは、mongoシェル証明書とmongodまたはmongosインスタンスに提示するキーを含む.pemファイルを指定します。接続プロセス中：

mongoシェルは、証明書が（--sslCAFile）である指定された認証局からのものであるかどうかを検証し、そうでない場合、シェルは接続に失敗します。

次に、シェルは、-hostオプションで指定されたホスト名がmongodまたはmongosによって提示された証明書のSAN/CNと一致するかどうかも確認します。このホスト名が2つのいずれにも一致しない場合、接続は失敗します。

自己署名証明書を使用したくない場合は、接続のネットワークが信頼されていることを確認する必要があります。

さらに、特にレプリカセット/シャードクラスターが関係している場合は、秘密鍵の公開を減らす必要があります。これは、さまざまなサーバーでさまざまな証明書を使用することで実現できます。

接続で使用できる追加のオプションは次のとおりです。

requireSSL：これにより、各サーバーがTLS/SSL暗号化接続のみを使用するように制限されます。

--sslAllowConnectionsWithoutCertificates：これにより、クライアントのみが証明書を提示する場合に検証が可能になります。そうでない場合、証明書がない場合でも、クライアントは暗号化モードで接続されます。例：

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols：このオプションは、サーバーが特定のプロトコルを使用する着信接続を受け入れないようにします。これは次の方法で実行できます：

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

保存データの暗号化

バージョン3.2から、MongoDBはWiredTigerストレージエンジンにネイティブ暗号化オプションを導入しました。サードパーティによるこのストレージ内のデータへのアクセスは、データを読み取り可能な形式にデコードするための復号化キーを介してのみ実現できます。

MongoDBで一般的に使用される暗号化暗号アルゴリズムはAES256-GCMです。同じ秘密鍵を使用して、データの暗号化と復号化を行います。 FIPSモードを使用して暗号化をオンにできるため、暗号化が最高の基準とコンプライアンスを満たしていることが保証されます。

データベースファイル全体は、ストレージレベルで透過的データ暗号化（TDE）を使用して暗号化されます。

ファイルが暗号化されるたびに、一意の秘密暗号化キーが生成され、これらのキーがどのように管理および保存されるかを理解するのに役立ちます。その後、生成されたすべてのデータベースキーは、マスターキーで暗号化されます。

データベースキーとマスターキーの違いは、データベースキーは暗号化されたデータ自体と一緒に保存できることですが、マスターキーの場合、MongoDBは、サードパーティのエンタープライズキーなどの暗号化されたデータとは別のサーバーに保存することをお勧めします管理ソリューション。

複製されたデータでは、データがネットワーク上でネイティブに暗号化されていないため、暗号化基準は他のノードと共有されません。ノードに同じキーを再利用できますが、ベストプラクティスは、ノードごとに一意の個別のキーを使用することです。

暗号化キーの回転

機密データの復号化に使用される管理対象キーは、少なくとも年に1回はローテーションまたは交換する必要があります。ローテーションを実現するためのMongoDBには2つのオプションがあります。

KMIPマスターローテーション

この場合、外部で管理されているため、マスターキーのみが変更されます。キーを回転させるプロセスは以下のとおりです。

レプリカセットのセカンダリメンバーのマスターキーは、一度に1つずつローテーションされます。つまり
```
mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```
プロセスが完了すると、mongodが終了し、kmipRotateMasterKeyパラメーターなしでセカンダリを再起動する必要があります
```
mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```
レプリカセットのプライマリがステップダウンされます。
rs.stepDown（）メソッドを使用すると、プライマリが非アクティブ化されるため、新しいプライマリが強制的に選択されます。
rs.status（）メソッドを使用してノードのステータスを確認し、プライマリがステップダウンしたことを示している場合は、マスターキーを回転させます。 kmipRotateMasterKeyオプションを含むステップダウンされたメンバーを再起動します。
```
mongod --enableEncryption --kmipRotateMasterKey \
  --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```

ロギング

MongoDBは常にログファイルと連携して、さまざまな間隔でステータスや指定された情報を記録します。

ただし、ログファイルはストレージエンジンの一部として暗号化されていません。これは、ロギングで実行されているmongodインスタンスが、通常のロギングの一部として、潜在的に機密性の高いデータをログファイルに出力する可能性があるというリスクをもたらします。

MongoDBバージョン3.4から、潜在的に機密性の高いデータがmongodプロセスログに記録されるのを防ぐsecurity.redactClientLogData設定があります。ただし、このオプションはログ診断を複雑にする可能性があります。

SomeninesがMongoDBDBAになる-MongoDBを本番環境に導入MongoDBDownloadを無料でデプロイ、監視、管理、スケーリングするために知っておくべきことを学びましょう

MongoDBでの暗号化パフォーマンス

ある時点で暗号化すると、待ち時間が長くなり、データベースのパフォーマンスが低下します。これは通常、大量のドキュメントが関係している場合に当てはまります。

暗号化と復号化にはより多くのリソースが必要になるため、容量計画を適切に調整するには、この関係を理解することが重要です。

MongoDBテストに関して、暗号化されたストレージエンジンでは、最大負荷で10％から20％の遅延が発生します。これは、ユーザーがデータベースに大量のデータを書き込むためにパフォーマンスが低下する場合によくあります。読み取り操作の場合、パフォーマンスの低下はごくわずかで、約5〜10％です。

MongoDBでの暗号化の実践を改善するには、WiredTigerストレージエンジンがその高性能、セキュリティ、およびスケーラビリティのために最も好まれます。さらに、データベースファイルの暗号化をページレベルに最適化します。これは、ユーザーが暗号化されたデータベースに対してデータの読み取りまたは書き込みを行う場合、スループット操作がデータ全体ではなく、データが保存されているページにのみ適用されるという大きなメリットがあります。データベース。

これにより、単一のデータを処理するために暗号化および復号化する必要のあるデータの量が削減されます。

概要

機密情報のデータセキュリティは必須であり、データベースシステムのパフォーマンスを低下させることなく機密情報を保護する必要があります。

MongoDBは、データを保存中と移動中の両方で保護するのに役立つ堅牢なネイティブ暗号化手順を提供します。さらに、暗号化手順は、さまざまな組織によって設定された標準に準拠する必要があります。

高度なWiredTigerストレージエンジンは、高性能、スケーラビリティ、セキュリティなどの関連するメリットにより、より優れたオプションを提供します。レプリカセットのデータを暗号化するときは、少なくとも年に1回は変更する以外に、それぞれに異なるマスターキーを使用することをお勧めします。

ただし、サードパーティの暗号化オプションが利用できる場合でも、スケーラビリティの点で展開がそれらと一致するという保証はありません。したがって、データベースレベルの暗号化を採用することは非常に慎重です。