アプリケーションが組織を実行するために広い地理的領域を必要とする場合、多くの場合、データをクラウドに保存する必要があります。 MongoDBで構築されたアプリケーションも、この概念の例外ではありません。機密データの保護に失敗すると、評判の低下、データの不整合、経済的損失、場合によっては完全なデータ損失など、ビジネスに深刻な挫折を引き起こす可能性があります。
クラウドに保存されたデータは、犯罪要素からの関心を引く傾向があります。データベースのセキュリティを確保するための標準的な手順が設定されていない場合、悪意のある人はより簡単にアクセスできます。これらの標準以下の手順には、次のものが含まれます...
- 不十分なパスワード管理：一部の開発者は、プロジェクトのソースファイルにパスワードをハードコーディングすることになります。そのため、ハッカーがアプリケーションを逆コンパイルすると、コンテンツを簡単に取得できます。
- たとえば、暗号化された復号化キーを使用していない、またはセキュリティプロトコルをまったく使用していない、標準以下のデータベース構成。
データベース攻撃は日々増加しています（そしてこの傾向は続くと予想されます）が、適切なセキュリティ上の考慮事項を採用しない限り、被害に遭うことはありません。この記事では、クラウドへのMongoDBのインストールで確認できる手順のいくつかについて説明します。それらすべてを適用する必要はありませんが、少なくとも、回避した場合にデータが悲惨な状況に陥る可能性のあるものを選択するように最善を尽くしてください。
MongoDBの本番前のセキュリティに関する考慮事項
これらは、MongoDBを本番環境にデプロイするときに適切に構成されていることを確認する必要がある考慮事項です。含まれるもの：
- MongoDBのセキュリティ修正で更新されます
1。アクセス制御のための認証の有効化と実施
MongoDBではデフォルトでアクセス制御が有効になっていませんが、これは、このオプションを有効にせずにデータベースをデプロイすることを意味するものではありません。実際、Bitnamiなどの一部のデータベースパッケージでは、データベースを使用する前にアクセス制御を設定する必要があります。そうしないと、誰でもデータベースにアクセスできるため、非常に機密性の高いデータにさえさらされる可能性があります。接続するクライアントがデータベースに接続する前に有効な資格情報を提供する必要があるように、SCRAMなどの認証メカニズムを指定します。
mongodb://[username:[email protected]]host[:port1][/[defaultauthdb]and not just
mongodb://host[:port1]/[defaultauthdb]2。ロールベースのアクセス制御を構成する
管理者権限を持つユーザーを追加した後、役割ベースのアクセス制御（RBAC）を使用して、これらのユーザーに割り当てられる役割を制限します。ユーザーが持つことができる役割には、特定のコレクションまたはすべてのコレクションに対する読み取り、書き込み、またはその両方が含まれます。したがって、ユーザーは自分に割り当てられていない役割を実行したり、割り当てられたコレクションに対してのみ操作を実行したりすることはできません。
ユーザー管理者が最初に作成され、次に追加のユーザーが作成されます。ユーザーが異なるデータベース間で特権を持っている場合、異なるデータベースでユーザーを複数回作成する代わりに、該当するデータベース特権を付与する役割を持つ単一のユーザーを作成できます。
データベースにアクセスするユーザーを少数にして、ユーザーがユーザーまたはクライアントアプリケーションになるようにすることをお勧めします。
MongoDBで特定のロールのユーザー権限を作成して付与するには、mongoシェルでこの例を使用できます
use finance
db.createUser(
{
user: "manager",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "read", db: "loans" },
{ role: "read", db: "interests" },
{ role: "read", db: "useraccounts" },
{ role: "readWrite", db: "wages" }
]
}
)また、LDAPやKerberosなどの外部認証オプションを選択します。
3。ネットワークの露出を制限する
データベースをホストするネットワークトポロジは、広範囲に保護する必要があり、最も重要なのは、ローカルホストインターフェイスのみをリッスンすることです。これは、MongoDBの古いバージョンの場合のように、外部接続からの露出を回避するためです。 MongoDBが、セキュリティファイアウォールが有効になっている信頼できるネットワーク環境で実行されていることを確認します。他のインスタンスでは使用できないセキュリティグループを使用して、インバウンドおよびアウトバウンドのトラフィックを制御します。 IPホワイトリストを使用して、信頼できるIPアドレスからのアクセスを許可します。したがって、信頼できるクライアントのみからのネットワークインターフェースとポートを使用してMongoDBインスタンスへの接続を許可します。
さらに、SSHルートへの直接アクセスを無効にします。
4。通信の暗号化
MongoDB構成では、着信接続と発信接続をTLS/SSLのみに制限する必要があります。 TLS / SSLは、MongoDBデプロイメントのmongodおよびmongosコンポーネントと、それに接続されているすべてのアプリケーション間の通信を暗号化します。
本番環境では、MongoDBのデプロイでは、単一の認証局によって生成および署名された有効な証明書を使用する必要があります。
5。データを暗号化する
データベースデータには、保存中のデータと転送中のデータの2つの形式があります。転送中のデータは、クライアント側のフィールドレベル暗号化を使用して保護できますが、バージョン4.2でのみ使用できます。 TLS / SSL暗号化は、転送中のデータも処理します。
6。監査システムの活動
これは、データおよびデータベース構成に対するすべての変更を追跡できるエンタープライズオプションです。イベントはsyslog接続またはログファイルに書き込まれます。ログには、送信元IPアドレスを含むDB認証の試行を含めることができます。この情報は、ファイアウォールによってデータベースへのアクセスをブロックする必要があるホストを特定するのに役立ちます。その上、どのイベントをログに記録するかを細かく評価することができます。
この監査ログは、一般に、管理者がフォレンジック分析を実行し、標準のセキュリティ制御を設定するのに役立ちます。
7。専用ユーザーを使用してMongoDBを実行する
MongoDBプロセスは、アクセス許可が有効になっている専用のオペレーティングシステムユーザーアカウントで実行する必要があります。
8。公式および更新されたMongoDBパッケージを利用する
パッケージの信頼性チェックに合格して、MongoDBの公式パッケージであることを確認します。最新のMongoDBドライバーと最新バージョンのデータベース自体を使用すると、以前のバージョンよりもセキュリティの安定性が向上します。たとえば、バージョン4.2は、クライアント側のフィールドレベルの暗号化を提供します。したがって、必ず最新バージョンのMongoDBに移行してください。
9.不要な場合はJavascriptの実行を無効にする
mapReduceと$whereは、MongoDB内の実行可能なJavaScriptコードの一部であり、適切に管理されていない場合、不要なデータの不整合が発生したり、データに間接的にアクセスして変更を適用したりする可能性があります。 。
一般に、このJavaScriptコードは外部からの挿入を許可するため、検証されていないデータがデータベースに入力されます。また、mongooseなどのパッケージを使用して、データベースを検証して接続することもできます。 JavaScript式の代わりにMongoDB演算子を使用してください。
10。 MongoDBのセキュリティ修正で更新される
セキュリティプロトコルは、時間の経過とともに攻撃者によって破壊される可能性があるため、高度な手順を必要とします。 MongoDBリリースノートの最新のセキュリティアップデートとバグ修正を常に最新の状態に保つことは非常に重要です。 MongoDBアラートページは基本的にそのような目的で作成されました。
可能であれば、セキュリティ技術実装ガイドをリクエストし、導入がセキュリティ標準に準拠していることを確認してください。
本番環境のデータベースはセキュリティ攻撃を受けやすいため、機密データの保護に多額の投資を行う必要があります。セキュリティ手順は、転送中のデータ、保存中のデータ、および接続されたクライアントアプリケーションにまで及びます。上記の慣行に加えて、サーバー強化の取り組みは、データ保護の別の層を提供します。
バージョンに関連する最新のセキュリティとバグ修正に遅れずについていくことに加えて、MongoDBとプラグインの最新バージョンを使用することが重要です。