MongoDBセキュリティガイド

好むと好まざるとにかかわらず、非リレーショナルオープンソースデータベースは、データストレージツールの既存のエコシステムの重要な部分を構成し、小規模および大規模なWebプロジェクトのあらゆる場所で使用されています。 皆さんの中には、実稼働環境でMongoDBに出会った人もいるでしょう。 データベースを外部攻撃から保護する機能は、操作を成功させるために必要なスキルです。 PG Day'17 のオープンデータベースセクションで、これと他の多くの問題についてお話します 。 それまでの間、MongoDBセキュリティに関する興味深い概要出版物の翻訳をご紹介します。







MongoDBには、データをそのまま保持するために必要なものがすべて揃っています。 必要なものとその構成方法を正確に説明します。



MongoDBセキュリティがニュースに戻ってきました。 最近、メディアはハッカーがどのようにMongoDBデータベースを押収し、ビットコインでの身代金を要求したかを伝える物語を殺到しました 。 Rapid7によると 、何万ものMongoDBインストールが侵害されています 。



私たちは皆、セキュリティを心配しています。 アプリケーション、ネットワーク、またはデータベースをサポートする場合、セキュリティが常に優先されます。 多くの企業が重要な企業データを保存するためにMongoDBなどのオープンソースソフトウェアに切り替えているため、セキュリティ問題はさらに重要になっています。 ビジネスによっては、政府（医療保険の携行性と責任に関する法律、HIPAAなど）またはビジネス（ペイメントカード業界データセキュリティ標準、またはPCI DSS）ネットワーク標準が異なる場合があります。あなたが従わなければならないセキュリティ。



MongoDBデータベースソフトウェアは安全ですか？ これらの基準を満たしていますか？ 簡単な答えはイエスです、それは安全です、そしてそうです！ 特定のインストールを構成、構成、および操作する方法を知る必要があります。



この記事では、MongoDBセキュリティについて説明します。 MongoDBは、何を検索し、どのように構成するかがわかっている場合に使用しても安全です。



最初に、MongoDBを操作するときに人々が犯す間違いをセキュリティの観点から見てみましょう。 MongoDBセキュリティに関して、ユーザーがつまずく重要なポイントがいくつかあります。

• デフォルトのポートを使用する
• すぐに認証を有効にしないでください（最も深刻な問題！）。
• 認証を使用する場合、全員および全員に幅広いアクセスを許可します。
• パスワードの変更を強制するためにLDAPを使用しないでください
• データベースでSSLの使用を主張しないでください。
• 既知のネットワークデバイス（アプリケーションホスト、ロードバランサーなど）のデータベースへのアクセスを制限しないでください。
• 接続がリッスンされるインターフェイスを制限しません（ただし、この項目はサポートされているバージョンには影響しません）。

MongoDBには5つの主要なセキュリティゾーンがあります。

• 認証 LDAP認証は、会社のディレクトリ内のアイテムを集中化します。
• 認可 認可は、ユーザーのロールに応じて、データベースが提供するアクセス権を決定します。
• 暗号化 暗号化は、保管中と転送中に分けることができます。 MongoDBセキュリティにとって重要です。
• 監査 監査には、データベースで誰が何をしたかを確認する機能が含まれます。
• 管理。 管理には、ドキュメントと機密データ（アカウント番号、パスワード、社会保障番号、生年月日など）の確認が含まれます。 これは、機密データが保存されている場所に関する知識と、システムへのデータの侵入を防ぐための両方に適用されます。

LDAP認証



MongoDBには、デフォルトで無効になっている組み込みのユーザーロールがあります。 ただし、パスワードの複雑さ、年齢のローテーション、利用可能な機能の異なるセットを持つユーザーロールの集中化と識別などの要素が欠けています。 これは、 PCI DSS準拠などの規制レビューにとって重要です。 たとえば、PCI DSSは、古くて簡単に解読されるパスワードの使用を禁止しており、ステータスが変わるたびに（たとえば、ユーザーが部門や会社を辞めるとき）ユーザーアクセスの変更を要求します。



幸いなことに、LDAPを使用してこれらのギャップのほとんどを埋めることができます。 多くのコネクタでは、Windows Active Directory（AD）を使用してLDAPと対話できます。

注 ：LDAPサポートは、MongoDB Enterpriseでのみ利用可能です。 コミュニティ版ではありません。 ただし、MongoDB用のPercona Serverなど、MongoDBの他のオープンソースバージョンで使用できます。

MongoDB 3.2はユーザーをLDAPに保存しますが、ロールは保存しません（現在は個々のマシンに保存されています）。 MongoDB 3.4 Enterprise は 、集中アクセスのためにLDAPにロールを保存する機能を提供する必要があります。 （役割については後で説明します）。





図 1. SASL認証の手順（簡易認証およびセキュリティレイヤー）。



LDAPとADを使用して、ユーザーを会社のディレクトリに関連付けることができます。 役割を変更したり会社を辞めたりすると、人事スタッフはデータベース内のグループからそれらを削除できます。 したがって、手動でデータを操作するアクセス権を付与したい人だけがそれを受け取り、誤ってデータが失われることのない自動システムがあります。



MongoでのLDAPの操作は非常に簡単です。 MongoDBには、外部LDAPデータベースをチェックするよう指示する特別なコマンド$ externalがあります。



LDAPを使用する場合の注意点がいくつかあります。

• 通常どおり.createUserを使用してユーザーを作成しますが、db / collectionリソースタグを必ず追加してください。
• さらに、LDAP認証にはさらに2つのフィールドが必要です。
  • メカニズム：「プレーン」
  • digestPassword：false

ユーザー役割



ロールベースのアクセス制御（RBAC）は、MongoDBの中心です。 組み込みの役割は、バージョン2.6以降で使用可能です。 特定のユーザーが実行できるアクションを正確に書き留めることで、独自のロールを作成できます。 この機能はMongoDBのコアに組み込まれており、オープンソースソフトウェアのほとんどすべての商用バージョンで利用できます。



知っておくべき5つの基本的なMongoDBの組み込みロール ：

• 読む ：
  
  
  • 通常、ほとんどのユーザーに与えられる読み取りアクセス。
• readWrite ：
  
  
  • readWriteアクセスにより、データを編集できます。
  • readWriteには読み取り許可が含まれます。
• dbOwner ：
  
  
  • readWrite、dbAdmin、userAdmin（データベース用）が含まれます。 userAdminには、ユーザーの追加と削除、ユーザーへの権限の付与、ロールの作成が含まれます。 これらの権限は、1つの特定のデータベースサーバーにのみ割り当てられます。
• dbAdminAnyDatabase ：
  
  
  • すべてのデータベースでdbAdminを作成しますが、ユーザーの管理（たとえば、作成と削除）は許可しません。 インデックスの作成、データ圧縮手順の呼び出しなどができます。 ここでは個別のアクセスは提供されていません。
• ルート ：
  
  
  • これはスーパーユーザーですが、制限があります。
  • ほとんどのアクションを実行できますが、すべてではありません。
    
    
    • システムコレクションを変更できません。
    • この役割の一部のコマンドは、バージョンによっては使用できません。 たとえば、MongoDB 3.2のルートロールでは、oplogまたはプロファイラーのサイズを変更できません。また、MongoDB 3.4では、現在のビューを読み取りません。

ワイルドカードデータベースとコレクション



ワイルドカードとは、サーバー上のデータベースまたはコレクション（またはその両方）の大きなグループへのアクセスを提供することを意味します。 nullに設定すると、すべてのデータベースまたはコレクションを一度に指定でき、 dbAdminAnyDatabaseロールを回避できます。 これにより、選択したユーザーは、管理者機能を含むすべての権限を持つことができます。



これは危険です。



ワイルドカードを使用して、多くの特別な権限を付与し、次の攻撃可能なパスを開くことを知っておく必要があります。

• readWriteAnyDatabase権限は非常に広範囲であり、アプリケーションユーザーを介した潜在的な攻撃に対してユーザー名とその役割を公開します。
• テンプレートの使用は、特定のアプリケーションを特定のデータベースに限定しないことを意味します。
• ワイルドカードでは、多くのデータベースでマルチテナンシーを使用できません。
• 新しいデータベースへのアクセスは自動的に許可されません。

カスタムロールを作成する



MongoDBの役割の力は、独自の役割を作成できることにあります。 カスタムロールでは、特定のユーザーに対してリソース上のアクションを設定できるように指定できます。 このレベルの詳細を使用すると、MongoDB環境で誰が何を実行できるかを詳細に制御できます。



カスタムロールの定義に関しては、4種類のリソースがあります。

• db データベースを示します。 名前に文字列を使用するか、「any」（パターンなし）に「」を使用できます。
• コレクション 。 一連のドキュメントを指定します。 名前に文字列を使用するか、「any」（パターンなし）に「」を使用できます。
• クラスター 影付きクラスターまたはその他のメタデータソースを示します。 true / falseのブール値です。
• anyResource 。 あらゆる場所へのアクセスを意味します。 true / falseのブール値です。

どのロールも別のロールのプロパティを継承できます。 「ロール」と呼ばれる配列があり、新しいロールを追加できます。 指定されたロールのプロパティを継承します。



createRoleを使用して、役割をアレイに追加します。



ユーザーまたはロールに新規または既存のデータベースを追加できます。 たとえば、データベースをロールにアタッチすることにより、データベースへの読み取りおよび書き込みアクセスを追加できます。



grantPrivilegesToRoleコマンドを使用して、既存のロールに新しいリソースを追加します。



以下は、新しいスーパーユーザーロールを作成する例です。 繰り返しますが、この役割は、MongoDB環境が制限なしで1人のユーザーを持つために必要です（予期しない状況の場合）。

db = db.geSiblingDB(“admin”); db.createRole({ role: “superRoot”, privileges:[{ resource: {anyResource:true}, actions: ['anyAction'] }] roles:[] }); db.createUser({ user: “comanyDBA”, pwd: “EWqeeFpUt9*8zq”, roles: [“superRoot”] })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのコマンドは、 geSiblingDBデータベースにsuperRootという新しいロールを作成し、このロールにリソースとアクションを割り当てます。 次に、同じデータベースに新しいcompanyDBAユーザー（パスワード付き）を作成し、新しいsuperRootロールを割り当てます。



すべてにSSLを使用する



SSLは、安全でないネットワーク上のデータを保護するのに役立ちます。 インターネットと対話するデータベースを使用する場合は、SSLを使用する必要があります。



SSLを使用してMongoDBを保護する2つの非常に良い理由があります：プライバシーと認証。 SSLを使用しない場合、違法または悪意のある目的でデータにアクセス、コピー、使用できます。 認証を使用すると、セキュリティの層が追加されます。 SSL秘密鍵インフラストラクチャ（PKI）は、正しいCA証明書を持つユーザーのみがMongoDBにアクセスできるようにします。



SSLサポートはかなり前からMongoDBに存在していましたが、最近のバージョンでは大幅に改善されています。 以前は、SSLを使用する場合、それをダウンロードし、MongoDBコミュニティのバージョンで手動でコンパイルする必要がありました。 MongoDB 3.0以降、SSLはデフォルトでソフトウェアでコンパイルされます。



MongoDBの古いバージョンにもホスト検証がありませんでした。 接続からのSSL要求を満たす構成ファイルをチェックインできるフラグにすぎません。



MongoDBのSSLの最近のバージョンには、次の主要な機能が含まれています。

• ホスト検証（オプション）;
• 使用する特定のセットアップ.keyを指定する機能。
• 自己署名証明書および代替サブスクライバー用のカスタム認証局（CA）。
• allowSSL 、 preferSSL 、 requireSSLモード 。SSLの使用の粒度を選択できます（安全性の低いものから高いものへ）。

SSL：カスタムCAの使用



MongoDBの最新のSSLバージョンでは、独自のCAを使用できます。 これにより、SSLの使用方法を柔軟に決定できますが、いくつかの注意事項があります。 接続を保護しようとしているだけなら、 sslAllowInvalidCertficatesを選択したくなるかもしれません。 ただし、これは通常、いくつかの理由で悪い考えです。

• 証明書が失効または期限切れになった場合でも接続を許可します。
• 特定のホスト名に制限を設けません。
• 思っているほど保護されていません。

この問題を解決するには、 net.ssl.CAFileを構成します。MongoDBはキーとCAファイルの両方を使用します（これはクライアントで実行する必要があります）。



ただし、SSLの使用には、パフォーマンスという既知の問題があります。 SSLを使用すると、間違いなく減少します。



ディスク暗号化



データは送信中または保存中のいずれかであり、MongoDBでそれらの一方または両方を暗号化できます。 転送データ暗号化（SSL）について説明しました。 次に、保存されているデータを見てみましょう。



保存データは、ディスクに保存されるデータです。 このようなデータを暗号化するには、通常、暗号化されたストレージに保存する必要があります。 これは、物理的な盗難を防止するとともに、サードパーティに読みにくい方法で保存されるバックアップを作成するためです。 これには実際的な制限があります。 それらの最大のものは、システム管理者への信頼と、ハッカーがシステムへの管理アクセスを獲得しなかったという自信です。



この問題は、MongoDBに固有のものではありません。 他のシステムで使用される予防措置もここで機能します。 これらには、LUKSやcryptfsなどの暗号化ツール、またはLDAP、スマートカード、RSAトークンを使用した暗号化キーの署名など​​、さらに安全な方法が含まれます。



このレベルの暗号化を実行するときは、ディスクの自動パーティション化と復号化などの要因を考慮する必要があります。 しかし、これはシステム管理者にとって新しいことではありません。 ネットワークの他の部分と同様に、この要件を管理できます。 追加の利点は、単一のストレージ暗号化手順であり、特定の機能で使用される各テクノロジーごとではありません。



保存データ暗号化は、次のいずれかの方法で実装することも、一度にすべて実装することもできます。

• ディスク全体を暗号化します。
• データベースファイルのみを暗号化します。
• アプリケーションで暗号化します。

最初のオプションは、ファイルシステムでディスク暗号化を使用して実装できます。 LUKSとdm-cryptを使用して簡単に設定できます。 PCI DSSおよびその他の認証要件に準拠するには、最初と2番目のオプションのみが必要です。



監査



優れたセキュリティシステムアーキテクチャの中心となるのは、データベースでどのユーザーがどのアクションを実行したかを追跡する機能です（実際のサーバーの管理方法と同様）。 監査を使用すると、特定のユーザー、データベース、コレクション、またはソースの場所の出力をフィルタリングできます。 これにより、セキュリティインシデントをチェックするログが作成されます。 さらに重要なことは、侵入からデータベースを保護し、これが発生した場合の侵入の深さを理解するために適切な措置を講じたセキュリティ監査員を示しています。



監査を使用すると、環境内の攻撃者のアクションを完全に監視できます。

注 ：監査はMongoDB Enterpriseでのみ利用可能です。 コミュニティ版ではありません。 ただし、MongoDB用のPercona Serverなど、MongoDBの他のオープンソースバージョンで使用できます。

さらに、データベースに保存する形式を誰かが変更すると開発者コードが機能しない可能性があるため、DBAの従業員がスキーマを適切にチェックした場合にのみスキーマの変更が行われるようにすることができます。 これにより、MongoDBの動的な生産スキームに追加の制御層がもたらされます（必要なくても、何でも保存できます）。



運営管理



管理には、データの挿入と更新が含まれます。 また、「bday」、「birthday」、「ssn」、「social」などのフィールド名が定義されているかどうかを確認するのにも役立ちます。 簡単に言えば、管理とは、ドキュメント検証を通じてMongoDBシステムに複雑な標準を実装する機能です。



ドキュメントの検証により、ドキュメントのどの領域が特定のコレクションに有効であるかを判断できます。 パラメーターを設定してキーと値を検索し、それらが事前定義された標準を満たしていることを確認できます。 たとえば、キーが存在するかどうか、およびキーのタイプが正しいかどうかを確認できます。



主なドキュメント検証チームは次のとおりです。

• collMod 。 検証するキーを定義します。
• バリデーター 。 チェックするパラメーターを定義します。
• validationLevel 。 バリデーターの重大度を設定します（validationActionに応じて、それがオンになる頻度とアクションが実行される重大度）。
• validationAction 。 何かがテストに合格しない場合に手順を確立します。

特定のキーとキー値に限定されません。 正規表現文字列を使用することもできます。 正規表現を使用して、クレジットカード番号などの文字列のチェックを実行できます： ^ d {4} -d {4} -d {4} -d {4} $ 。 正規表現を使用すると、ユーザーID、生年月日、社会保障番号なども確認できます。



これらは、データベース管理者とセキュリティアーキテクトが開発者を会社に追加のリスクを与えないようにする方法の例です。



ネットワークの攻撃エリアを削減する



ネットワークの攻撃領域を減らすことは、認証されていないユーザーがアクセスできるネットワークのハードウェアとソフトウェアのすべての脆弱性を制御することを意味します。



MongoDBのドキュメントでは、各アプリケーションホストにMongoインスタンスを配置することが推奨されています。 この提案は、（ネットワークホップを制限することにより）データベース環境の遅延を減らすために確かに当てはまります。 しかし、パフォーマンスには良い一方で、セキュリティには非常に悪いです。



各Mongoインスタンスは以下にアクセスできる必要があります。

• 各プライマリノード。
• 各セカンダリノード。
• 各構成サーバーに。

セキュリティにとって悪夢であることが想像できます。 mongoの各インスタンスには、ネットワークにまたがるx個の接続があります。 これは、攻撃者が使用できるx個以上の接続です。



代わりに、他のシステムへのアクセスを許可するアプリケーションの隣にMongoDBサーバーのグループを置くのが最善です。 アプリケーションにロードバランサー（または同様のもの）をセットアップし、アプリケーションがMongoDBサーバーのみにアクセスできるようにします。 これにより、ネットワーク上で開かれる接続が多すぎることを防ぐスマートDMZタイプの設定が提供されます。





図 2.ロードバランサーとともに展開されたMongoDB。



デフォルト設定のストークデータベース



一般にオープンソースデータベース、特にMongoDBには、データの保護を保証するために必要なすべてのセキュリティ設定があります（企業バージョンを購入する必要はありません）。



オープンソースデータベースでのセキュリティの仕組みを理解します。 デフォルト設定を保存することは、災害への正しい道です。 上記の問題を理解して解決することにより、すべてのセキュリティニーズ（安全規制要件の遵守を含む）を満たし、合理的でよく知られた方法を使用して会社を保護できます。







MongoDBの運用とプロジェクトのセキュリティの問題に関連するすべての人は、来るべきPG Day'17からいくつかのレポートを提出できます。MongoDBの Henrik Ingo へのレプリケーション Novikovと、開発者がデータベースセキュリティについて知りたいと思っていたが、 Ilya Verbitsky に尋ねることを恐れていたすべてのもの。 今すぐ参加しよう！