MongoDBのフィールドレベルの暗号化は、DBAからでもプライベートデータを保護します。

2019年12月、人気のドキュメントデータベースMongoDBは、プラットフォームにかなり革新的な新機能「フィールドレベルのデータベース暗号化」を追加しました。一見すると、保存時のストレージ暗号化や転送中のデータ暗号化が既に存在する中で、これが果たして意味のある機能なのか疑問に思うかもしれません。しかし、もう少し詳しく分析してみると、答えは「イエス」です。

MongoDBの新技術を最初に導入した顧客の一つが、2,000を超える病院と約200万人の患者の機密データを扱うベンダーであるApervitaです。Apervitaは、この技術の開発と改良においてMongoDBと緊密に連携してきました。

この技術は、12 月に一般提供が開始されて以来、大手の薬局や保険会社を含む複数の政府機関やフォーチュン 50 企業にも採用されています。

フィールドレベル暗号化とは

MongoDBのフィールドレベル暗号化（FLE）は、ドキュメントストア内のデータの特定の部分を暗号化して保存する機能を提供します。MongoDBのコミュニティ版（無料版）では、クライアント側アプリケーションでフィールドを明示的に暗号化できます。

MongoDBのエンタープライズ版（およびMongoのクラウドベースのDatabase-as-a-ServiceであるAtlas）も自動暗号化をサポートしています。MongoDB EnterpriseとAtlasは、保護されたフィールドに対してサーバー側で暗号化を強制できるため、知識の浅いアプリケーション開発者が誤って機密データを平文で保存してしまうことを防ぎます。暗号化されたフィールドは、アプリケーションがキーを所有している場合、無料版でもエンタープライズ版でも読み取り時に自動的に復号化されます。

自動暗号化データベースの設定は、ここでコードで詳しく説明するには少々複雑すぎます。しかし、暗号化がどのように、いつ行われるかを理解するには、明示的に暗号化された単一のMongoDB挿入を実行するPythonコードを簡単に見てみると役立つかもしれません。

# フィールドを明示的に暗号化します:
encrypted_field = client_encryption.encrypt( "123456789", Algorithm.AEAD_AES_256_CBC_HMAC_SHA_512_Deterministic, key_id=data_key_id) coll.insert_one({"encryptedField": encrypted_field})

ここでの明示的な呼び出しから、何が起こっているかは明らかです。データはクライアントアプリケーション側で暗号化され、その後MongoDBサーバーインスタンスに送信され、そこで保存されます。これにより、転送中暗号化と保存時暗号化の両方の利点を最大限に活用できますが、ここでは、すぐには気づかないかもしれない別の防御層も提供されています。

システム管理者の問題を詳しく見る

システム管理者、そしてデータベース管理者は、データ機密性に関する最も厄介な問題の一つを担っています。コンピュータには、サービスの開始、停止、保守、監視に必要なすべての権限を持つ人間のオペレーターが必要です。つまり、システム管理者は、システム上に保存されている、あるいはシステムによって処理されるあらゆるデータに実質的にアクセスできることになります。

同様に、データベース、特に大規模データベースにはデータベース管理者が必要です。DBAはシステム管理者のような低レベルのルート権限は持ちませんが、データベース自体の内部動作にはアクセスできます。データベースの初期構造を設計するだけでなく、DBAは実行中のデータベースエンジンのログを記録し、監視することで、データの「ホットスポット」を特定できる必要があります。

これらのホットスポットでは、パフォーマンスの問題が発生した場合、構造の再構築やインデックス作成によってパフォーマンスの問題を軽減する必要があるかもしれません。また、適切なトラブルシューティングを行うには、DBAが問題のあるクエリを再現し、DBAによる変更がパフォーマンスにプラスの影響を及ぼしたかマイナスの影響を及ぼしたかを確認する必要があることも少なくありません。

保存時の暗号化は、システム管理者の問題やDBAの問題の解決にはほとんど役立ちません。システム管理者はシステムのRAWディスクをクローン化しても意味のあるデータを取得することはできませんが、ストレージのロックを解除すれば、稼働中のシステムから暗号化されていないデータを簡単にコピーできます。

ストレージ暗号化キーがハードウェア内に存在する場合（例えば、Trusted Platform Module（TPM）に組み込まれている場合）、システム管理者は稼働中のシステムにアクセスできるため、システム管理者の問題を軽減することはほとんど、あるいは全くできません。ApervitaのCTOであるマイケル・オルトマン氏は、「AWSデータセンターから誰かがサーバーを持ち去ってしまうような事態は心配していません」と述べています。

リモートオペレーターが起動時に提供されるキーを使用してストレージのロックを解除する必要がある保存時暗号化システムは、この問題をある程度軽減します。しかし、ローカルシステム管理者が稼働中のマシンに侵入する機会は依然として存在する可能性があります。また、リモートキーオペレーターが利用できないと、再起動を伴うメンテナンスウィンドウ後にサービスが自動的に復旧しないため、可用性に影響が出る可能性があります。

システム管理者やデータベース管理者から個人データを保護できないため、機密性を侵害することなく大規模な操作を拡張することが困難になり、コストも高くなります。

フィールドレベルの暗号化によりアクセスをセグメント化して拡張が可能

システム管理者の課題を理解したところで、フィールドレベル暗号化がどのようにその問題を軽減するかを見てみましょう。FLEでは、アプリケーションはデータをデータベースに送信する前に暗号化し、データベースはそれをそのまま保存します。同様に、暗号化されたデータに対してクエリを実行すると、データは暗号化されたまま取得され、アプリケーションに返されます。サーバーレベルでは復号化は行われず、実際、サーバーは 復号化に必要な鍵にアクセスできません。

データがデータベースに送信される前に安全に暗号化され、 データベースから返されるまで復号化されないため、システム管理者の問題は、システム管理者であれDBAであれ、ほぼ解決されます。ローカルルートアクセスを持つシステム管理者は、データにアクセスすることなく、サービスを停止、開始、アップグレードできます。また、データベース管理者は、プライベートなコンテンツを見ることなく、実行中のクエリを表示および再生できます。

公平を期すために言うと、この問題はまだ少し先送りしただけです。本番環境の アプリケーションサーバーにアクセスできるシステム管理者や開発者は、本来見るべきではないデータを閲覧できてしまうのです。結局のところ、生データはアプリケーション自体が処理する必要があるのですから。

しかし、セグメンテーションは依然として意味があります。MongoDBのAtlasのような、自動プロビジョニングされ、サードパーティによって監視されるサービスの利用を可能にするからです。フィールドレベルの暗号化がなければ、保護された医療情報をサードパーティが管理するクラウドサービスに保存しようとするベンダーは、HIPAA（医療保険の携行性と責任に関する法律）の適用を厳しく受けることになるでしょう。

しかし、FLEでは、アプリケーションのデータベース側は機密情報ではないとみなされます。これにより、データを管理するベンダーは、データベース・アズ・ア・サービス・プロバイダー（DBaaS）の高度な専門知識を活用できるようになります。また、ベンダーは、高額なHIPAA（またはその他の規制法）の物理的およびネットワークセキュリティ規則の対象となるシステムおよび機器の範囲を縮小できます。