MongoDB Security Tutorial

シーケンス
今週はGDPR(General Data Protection Regulation)MongoDBに関するシリーズを書こうとしたが、昨日(2017.09.05)には2.6 Wを超えるMongoDBノードがハイジャックされたことが明らかになった.だからその場で卦を変えて、MongoDBの安全に関する文章を書くことにしました.
どんな心理がDeveloper&DBA erの皆さんにこのような大きなビットコインの脅迫事件が発生した後、やはり裸で走ることができますか?データが重要ではなく、バックアップがあると思っても、セキュリティに対する意識から、セキュリティ対策を使うべきではないでしょうか.
現状
私の投稿前(2017.09.06朝7時)まで、現在のMongoDBノードが裸で走っていることを再検証しましたが、状況は非常に楽観的ではありません.SHODANを見ると、現在5 W以上のノードのMongoDBがデフォルトポート27017を使用していることがわかりました.そのうち、老米と中国が半分を占めています.
最初のページでは裸で走るノードを見ました
データ量は大きくありません.ノードの有効性を検証するために、ここでは論証の参考として、ノードに何の影響も与えません.
図から、この機械は明らかにhackerの攻撃を逃れていないことがわかります.hackerたちがMongoDBのノードを攻撃した後、あなたのデータをバックアップし、すべてのデータを削除し、journalログを削除します.これでEnterpriseバージョンでも監査できません.
ハッカーの攻撃方法は非常に簡単で、以下のステップに簡単に分けることができます.

SHODANのようなWebサイト(ZoomEyeなど)が提供するAPIを介してフルネットワークスキャンを行い、MongoDBは27017ポート

をスキャンする.

IPを取得後、嗅覚

を行う.

ログイン情報を取得できる場合は、スクリプト(フルライブラリのバックアップ、journalのクリーンアップ、入金アカウント情報の残り)

を実行します.
具体的には、ここではあまり説明しないで、MongoDBを攻略するために教育するのではなく、みんなに警鐘を鳴らすためです.
防犯
以上より,基本的な防犯措置さえすれば裸で走らない限り,ハッカーはそんなに簡単にDBに入ることはないことが明らかになった.
強調する必要があるのは、MongoDB政府がdeveloperの迅速な環境構築を容易にするためにデフォルトの暗号化されていない構成を提供しているが、このようにオンラインになるわけではないことだ.
そのため、オンラインになる前に、MongoDBの公式に与えられたCheckListと照らし合わせて一度チェックする必要があります.
Enable Access Control and Enforce Authentication
まず私たちのauthenticationを開くに違いありません.
開く方法は簡単です.

adminデータベースで、adminユーザ

を作成する.

use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "abc123",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

は、起動項目に--authを加えるか、プロファイルにsecurity.authorization: enabledを加える.mongod --auth --port 27017 --dbpath /data/db1

以前に作成するmyUserAdminユーザを使用してmongo mongo --port 27017 -u "myUserAdmin" -p "abc123" --authenticationDatabase "admin"

にログインする.

アプリケーションライブラリに読み書き権限を持つアプリケーションアカウントを作成します.(注意:MongoDBでは、アカウントはデータベースに従います.つまり、どのデータベースの下で作成されたのか、そのアカウントはどのライブラリに属しているのか)

use test
db.createUser(
  {
    user: "myTester",
    pwd: "xyz123",
    roles: [ { role: "readWrite", db: "test" },
             { role: "read", db: "reporting" } ]
  }
)

Configure Role-Based Access Control
ここで明確にする必要があるのは、MongoDBの基本的なセキュリティは2つに分けられ、1つは認証であり、1つは認証である.実は英語が話せるのはもっと分かります:authorization,authentication.
認証は、MySQLのroot/passwordのようなユーザーとしてログインするアカウントパスワードチェックです.ほとんどのアプリケーションでは、接続(接続プール用)を作成すると、接続は一度しかできないので、認証によるオーバーヘッドを心配する必要はありません.
認証は、MySQLのprivilegeのようなデータベース内のアカウントが持つ権限を認証します.
Encrypt Communication
MongoDBのTLS/SSlの配置を開けて、コミュニティ版は1つのSSLバージョンをダウンロードする必要があって、あるいはコミュニティ版からアップグレードのステップを通じてSSlバージョンにアップグレードすることができて、企業版はSSLを持参します.
SSLは、MongoDBのすべての接続(入出力の接続)が暗号化されていることを保証します.
Encrypt and Protect Data
MongoDB 3.2 WTエンジンは、エンタープライズ版のみで物理データファイルを暗号化できる新しい暗号化機能を発表しました.開かない場合は、デフォルトでシステムを通じてファイルを暗号化します.
Limit Network Exposure bindIpを指定し、MongoDBのHttpインタフェースをライン上でオフにすることで、ネットワーク輸入のセキュリティ問題を回避します.
Audit System Activity
MongoDBエンタープライズ版は、監査機能を提供し、ユーザーが自分のデータベースをよりよく巡回することを支援します.
Run MongoDB with a Dedicated User mongodbユーザーを使用して、rootユーザーではなくMongoDBを起動します.
に続く
2回のモンゴDB強盗を経て、警戒心を高めてほしい.自分の生産ノードを全部チェックします.同じ悲劇が起こるのを避ける.
上海小太り[MiracleYoung]オリジナルアドレス:https://segmentfault.com/u/shanghaixiaopang/articles
大神様のコメントを歓迎します.
毎週5日、楽しみにしていてください、上海小太り[MiracleYoung]独更.
もし夏雨荷がまだ大明湖畔で待っていたら、私はもっとしません.

は、デフォルトのポート27017を使用して公開され、ファイアウォール対策が行われず、認証と認証のMongoDBデータベースが開かれていないと説明しています.↩