ほとんどのデータベース管理システムには、部外者や許可されていない人物やアプリケーションからデータを保護するためのいくつかの手法があります。この手法により、ユーザーの許可なしにデータが読み取られたりコピーされたりするのを防ぐことができます。
MongoDBにはいくつかの不安定なレベルがあるため、違いはありません。このブログ投稿では、MongoDBのセキュリティレベルと、MongoDBのインストールを保護できるようにそれらを回避する方法について説明します。
MongoDBの安全性とセキュリティのために、厳密に考慮すべき主要なセキュリティ対策のいくつかを以下に示します。
-
ユーザー接続の認証。
-
承認/役割ベースのアクセス制御。
-
ネットワーク暗号化/トランスポート暗号化。
-
ストレージの暗号化/保存時の暗号化
-
監査。
この記事では、認証と承認に重点を置いて、上記のセキュリティ対策について詳しく説明します。
認証と承認は、同時にアクティブ化する必要があります。ただし、これらは互いに独立して使用できます。認証は、データベースサーバーへのネットワークアクセス権を持つ未知の人物へのアクセスがデータベースデータをコピーまたは損傷するのを防ぎます。認証では、すべてのクライアントとサーバーがシステムに接続する前に、有効な資格情報を提供する必要があります。一方、承認は、アプリケーションまたはユーザーが想定外のデータを読み取ったり、変更したり、削除したりすることを防ぎます。
-
最初にユーザー管理者を作成します。
-
追加のユーザーを作成します。
-
次に、システムにアクセスするユーザー/アプリケーションごとに一意のMongoDBユーザーを作成します。
-
最小特権の原則に従うことにより、セットに必要な正確なアクセス権を定義するロールを作成する必要がありますユーザーの数。
-
次に、操作で実行する必要のある役割のみをユーザーに割り当てます。ユーザーは、クライアントアプリケーションまたは個人にすることができます。
ユーザーは、異なるデータベースまたは複数のデータベース間で特権を持つことができることに注意してください。そのシナリオでは、異なるデータベースでユーザーを複数回作成する代わりに、該当するデータベース権限を付与する役割を持つ単一のユーザーを作成します。
多くの場合、これら2つのセキュリティ対策は同じことを意味すると混同される可能性があります。いくつかのシナリオでは、それらは互いに類似していますが、それらも異なります。
-
認証を有効にすると、承認が自動的に有効になるため、どちらもある程度単一のユニットです。認証は認証と一致して有効になるため、不明なユーザーからの接続にはデータベースデータにアクセスする権限がありません。また、承認では、接続の要求にどの特権が適用されるかを知るために、認証によってユーザー名を確認する必要があります。したがって、他とは独立して有効にすることもできません。
-
これらは、残念ながら、従来の構成オプションの命名でも似ています。認証の構成ファイルオプションは、予想されるセキュリティ認証ではなく、security.authorizationです。ただし、このコマンドを使用すると、認証が最初に有効になり、承認は後遺症としてのみ有効になります。 「-auth」は、認証を有効にするためのコマンドライン引数であり、認証も自動的にオンにします。
-
これら2つは、機能が異なるソフトウェアの2つの部分であるため、異なります。
認証==クレデンシャルチェックによるユーザーID。
承認==DBオブジェクトとDBコマンドのアクセス許可の割り当てと適用。
-
初期設定中、ローカルホスト接続の認証は無効になっています。これは簡単ですが、最初のユーザーを作成する機会が1つあると、例外（一緒に認証と承認のルール）特権が削除されます。
MongoDBの最初のバージョンでは、デフォルトで「-auth」がオフに設定されており、これは悪い動きと広く見なされています。バージョン4.0でも、デフォルトではオフのままでした。空白の構成は、起動の警告があり、ローカルホストがMongoDB v3.6で唯一のデフォルトにバインドされたネットワークデバイスになるなど、さまざまな露出の削減があるにもかかわらず、認証がオフになっていることと同じです。
認証を使用していないか、mongod構成ファイルで認証が有効になっていない場合：
-
security.authorizationを「有効」に設定します。
-
security.keyfileを含めます。
-
認証を強制的にオンにするsecurity.clusterAuthMode設定を含めます。
認証と承認が有効になっているかどうかを再確認するには、このクイックmongoシェルワンライナー（ユーザー資格情報の引数が設定されていない）を試すことができます：
mongo --host
名前が示すように、外部認証とは、ユーザーが外部サービスで認証されることを許可することです。例外として、内部のmongodb __システムユーザーには使用できませんが、実際の人間のユーザーまたはクライアントアプリケーションサービスアカウントに使用することは完全に適しています。
単純に、外部認証サービスはKerberos KDC、またはActiveDirectoryまたはOpenLDAPサーバーになります。外部認証を使用しても、通常のMongoDBユーザーアカウントを同時に持つことができなくなるわけではないことに注意してください。
逆に、MongoDBの内部認証は、外部認証の反対を意味するものではありません。これは、認証を有効にして実行されているmongodノードは、TCPピアが別の、別のmongodまたはmongosノードであるとは信頼しないためです。むしろ、共有秘密の証明によってピアが認証する必要があります。
MongoDBには、2種類の内部認証メカニズムがあります。
-
キーファイルの内部認証。
-
SCRAMまたはx.509内部認証。
これは、MongoDBのデフォルトの内部認証メカニズムです。 「キー」という用語は非対称暗号化キーを示しますが、実際には、どのように生成したかに関係なく、単なるパスワードです。キーファイルは、クラスター内の各mongodおよびmongosノードに配布される同一のファイルに保存されます。パスワードが正常に使用されるシナリオでは、mongodノードは、認証されたピアからのコマンドを「__system」スーパーユーザーとして実行することを許可します。
誰かがキーファイルのコピーを持っている場合は、キーファイルから制御文字と非印刷文字を削除して、「__システム」ユーザーとして接続できるパスワード文字列を作成できます。
ただし、それが発生し、MongoDBサーバーの1つでmongod（またはroot）ユーザーとして以下のコマンドを実行して成功した場合、誤って読み取り特権がリークすることはないため、心配する必要はありません。 。これは、キーファイルが400（または600）のファイルパーミッションモード以外の場合、mongodが起動時に中止されるためです。
mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"ただし、誤って誰でも読み取り可能なソース管理にキーファイルを保存すると、DBAではないユーザー（またはrootを持つサーバー管理者）がキーファイルのコピーを読み取る可能性があります。これはセキュリティ障害と見なされます。
キーファイルが、「mongod」や他のDBAチームが所有するUNIXユーザーではなく、アプリケーションチームのUNIXユーザーの1つとして所有および実行されるmongosノードで配布されると、極端なリスクが高まります。
SCRAMまたはx.509内部認証
x.509内部認証メカニズムは、実際には非対称の秘密鍵または公開鍵を使用するため、TLS/SSLと組み合わせて使用する必要があります。このメカニズムは、クライアント接続と内部認証に使用できます。
x.509またはSCRAMメカニズムは、キーファイルメカニズムよりも優れています。これは、x.509メカニズムでは、mongodおよびmongosノードでデプロイされたキーの1つが悪用される可能性が低いためです。それのコピーを取得する侵入者。ただし、これはx.509証明書がどの程度厳密に設定されているかによって異なります。このメカニズムから最大限のセキュリティを享受するには、x.509の概念とベストプラクティスを理解している専用のセキュリティチームが必要です。これらのベストプラクティスには、作業するホストを厳しくすることや、証明書を取り消してロールオーバーできるようにすることが含まれます。
ネットワーク暗号化は、2台のサーバー間のどこかにネットワークリンクを介して転送されているデータを誰かがコピーするのを防ぎます。ネットワーク暗号化は、それを使用するかどうかを決定する際に、ほとんどまたはまったく考える必要がありません。ただし、たとえば、MongoDBクラスターとそのすべてのクライアントが、ファイアウォールに穴がなく、他のアプリからの特権昇格のリスクがないと思われる仮想プライベートネットワーク内にある場合は、ネットワーク暗号化は必要ありません。
ネットワーク暗号化の場合、すべての発信接続と着信接続にTLS/SSLを使用するようにMongoDBを構成する必要があります。 TLS / SSLを使用して、MOngoDBデプロイメントのmongodコンポーネントとmongosコンポーネント間、およびすべてのアプリケーションとMongoDB間の通信を暗号化します。
-
Windows-セキュリティで保護されたチャネル（Schannel）。
-
Linux/BSD-OpenSSL。
-
macOS-安全なトランスポート。
MongoDBが信頼できるネットワーク環境で実行されていることを確認し、MongoDBインスタンスのインバウンドトラフィックとアウトバウンドトラフィックを制御するようにファイアウォールまたはセキュリティグループを構成する必要があります。さらに、信頼できるクライアントがMongoDBインスタンスが利用可能なネットワークインターフェイスとポートにのみアクセスできるように構成します。たとえば、IPホワイトリストを使用して、信頼できるIPアドレスからのアクセスを許可します。
MongoDBは、次のサーバー側操作の実行JavaScriptコードをサポートしています。
-
mapReduce。
-
$where。
-
$accumulator。
-
$function。
上記の操作を使用しない場合は、コマンドラインで--noscriptingオプションを使用して、サーバー側のスクリプトを無効にします。 MongoDBは、net.wireObjectCheck設定を介してデフォルトで入力検証を有効にしますが、入力検証を有効のままにします。これにより、mongodintsanceによって保存されたすべてのドキュメントが有効なBSONであることが保証されます。
MongoDBストレージの暗号化/保存時の暗号化
ストレージの暗号化により、基盤となるデータベースファイルのコピーを取得できなくなります。これは、誰かがデータセンターに侵入してサーバーのハードディスクを盗んだときに発生する可能性があります。 MongoDBデータには、データファイル、構成ファイル、監査ログ、およびキーファイルが含まれます。
MongoDB Enterprise 3.2以降、WiredTigerストレージエンジンのネイティブの暗号化保存機能を使用して、ストレージレイヤーのデータを暗号化できます。 WiredTigerの保存時の暗号化を使用しない場合は、ファイルシステム、デバイス、または物理暗号化を使用して、MongoDBデータを各ホストで暗号化する必要があります。また、これらのログには送信元IPアドレスを含むDB認証の試行が含まれているため、中央のログストアにログを収集する必要があります。ただし、ストレージの暗号化にはわずかなパフォーマンスコストがかかります。
監査は、データベースデータを変更または変更した後、自分のトラックを隠す方法を知っているデータベースユーザーを追跡するのに役立ちます。基本的に、監査はデータベース構成とデータへのアクセスと変更を追跡します。 MongoDB Enterpriseには、MongoDBインスタンスでのユーザー操作や接続イベントなどのシステムイベントを記録できる監査システム機能があります。
これらの監査記録は、フォレンジック分析に役立ち、管理者が適切な管理を検証できるようにします。監査は一部のユーザーにとって非常に価値がありますが、他の特定のリスクが排除された場合にのみそうすることができます。たとえば、攻撃者は、ライブのmongodノードを実行している間はサーバー上でUnixルートアクセスを取得できません。