MongoDBアクセス制御の使用方法

提供：Dev Guides
移動先:案内、検索

著者は、 Open Internet / Free Speech Fund を選択して、 Write forDOnationsプログラムの一環として寄付を受け取りました。

序章

最新のデータベースシステムは、大量のデータを保存および処理することができます。 このため、データベースの管理に関連するすべてのアクティビティの処理を1人のユーザーが単独で担当することは比較的まれです。 多くの場合、データベースユーザーごとに、データベースの特定の部分へのアクセスレベルが異なります。特定のデータベースのデータを読み取るだけでよいユーザーもいれば、新しいドキュメントを挿入したり既存のドキュメントを変更したりできるユーザーもいます。 同様に、アプリケーションには、機能する必要のあるデータベースの部分へのアクセスのみを許可する一意のアクセス許可が必要な場合があります。

MongoDB は、ロールベースアクセス制御（ RBAC ）と呼ばれるデータベースシステムへのアクセスと特権を制御するための堅牢なメカニズムを採用しています。 このチュートリアルでは、RBACがどのように機能するか、最小特権の原則の意味と目的、および実際にMongoDBのアクセス特権機能を使用する方法を学習します。

前提条件

このチュートリアルに従うには、次のものが必要です。

  • sudo権限を持つ通常の非rootユーザーと、UFWで構成されたファイアウォールを備えたサーバー。 この初期サーバーセットアップチュートリアルに従って、サーバーを準備できます。
  • サーバーにインストールされているMongoDB。 これを設定するには、 Ubuntu20.04にMongoDBをインストールする方法に関するチュートリアルに従ってください。
  • 認証を有効にして管理ユーザーを作成することにより、サーバーのMongoDBインスタンスを保護します。 このようにMongoDBを保護するには、 Ubuntu20.04でMongoDBを保護する方法に関するチュートリアルに従ってください。

注：サーバーの構成、MongoDBのインストール、およびセキュリティ保護の方法に関するチュートリアルの例は、Ubuntu20.04を参照しています。 このチュートリアルは、基盤となるオペレーティングシステムではなく、MongoDB自体に焦点を当てています。 通常、認証が有効になっている限り、オペレーティングシステムに関係なく、すべてのMongoDBインストールで機能します。


MongoDBがロールベースのアクセス制御でアクセスを制御する方法

アクセス制御— 承認とも呼ばれます—は、誰がどのリソースにアクセスできるかを決定することを含むセキュリティ技術です。

MongoDBのアクセス制御をよりよく理解するには、最初に、異なるが密接に関連する概念である認証と区別することが役立つ場合があります。 認証は、ユーザーまたはクライアントが実際に本人であるかどうかを確認するプロセスです。 一方、承認では、特定のユーザーまたはユーザーグループにルールを設定して、実行できるアクションとアクセスできるリソースを定義します。

次のサブセクションでは、MongoDBが認証と承認を処理する方法について詳しく説明します。

MongoDBでの認証

多くのデータベース管理システムでは、ユーザーはユーザー名とパスワードのペアだけで識別されます。 有効な資格情報を使用してデータベースに接続すると、ユーザーは認証され、そのユーザーに関連付けられたアクセスレベルが付与されます。 このようなアプローチでは、ユーザーディレクトリはフラットです。つまり、データベースサーバー全体で、各ユーザー名は一意である必要があります。

対照的に、MongoDBはより複雑なユーザーディレクトリ構造を採用しています。 MongoDBでは、ユーザーはユーザー名だけでなく、ユーザーが作成されたデータベースによっても識別されます。 ユーザーごとに、ユーザーが作成されたデータベースは、そのユーザーの認証データベースと呼ばれます。

つまり、MongoDBでは、異なる認証データベースで作成されている限り、同じユーザー名（ sammy など）を持つ複数のユーザーを持つことができます。 ユーザーとして認証するには、ユーザー名とパスワードだけでなく、そのユーザーに関連付けられている認証データベースの名前も指定する必要があります。

特定の認証データベースで作成されたユーザーは、その特定のデータベースでのみ使用可能なアクセス権限を持っていると思われるかもしれませんが、そうではありません。 各ユーザーは、作成された認証データベースに関係なく、異なるデータベースに割り当てられた特権を持つことができます。

MongoDB（ロールベースのアクセス制御）での承認

MongoDBでは、ロールベースのアクセス制御と呼ばれるメカニズムを介して、データベース上のどのリソースに誰がどの程度アクセスできるかを制御します。多くの場合、RBACと短縮されます。

ロールベースのアクセス制御では、データベースへの新しいドキュメントの挿入や特定のコレクションのクエリなど、リソースに対して直接アクションを実行するためのアクセス許可がユーザーに付与されません。 これにより、セキュリティポリシーの管理が困難になり、システム内の多くのユーザーとの一貫性が保たれます。 代わりに、特定のリソースに対するアクションを許可するルールがrolesに割り当てられます。

役割を特定のユーザーの仕事または責任の1つと考えると役立つ場合があります。 たとえば、マネージャーが会社のMongoDBインスタンス内のすべてのドキュメントへの読み取りおよび書き込みアクセス権を持っているのに対し、販売アナリストは販売レコードへの読み取り専用アクセス権を持っている場合があります。

ロールは、1つ以上の特権のセットで定義されます。 各特権は、アクション（新しいドキュメントの作成、ドキュメントからのデータの取得、ユーザーの作成と削除など）と、そのアクションを実行できるリソース（reportsという名前のデータベースまたはコレクションなど）で構成されます。 ordersと呼ばれます）。 企業に複数の責任を持つ多くのセールスアナリストや従業員がいる現実の世界と同じように、MongoDBでは、多くのユーザーに同じ役割を割り当て、1人のユーザーに多くの役割を付与することができます。

adminデータベースで作成されたものを除いて、各役割には独自のデータベースに適用される特権のみを含めることができるため、役割は役割名とデータベースの組み合わせで識別されます。 認証データベース以外のデータベースで定義されたユーザーロールを付与することにより、ユーザーに複数のデータベースを操作するための権限を付与できます。 ユーザーを作成するとき、またはその後いつでもロールを付与できます。 ロールメンバーシップの取り消しも自由に行うことができるため、ユーザー管理をアクセス権管理から簡単に切り離すことができます。

MongoDBは、読み取り専用アクセスを許可するread、読み取りと書き込みの両方のアクセス許可を付与するreadWrite、dbOwner特定のデータベースに対する完全な管理者権限を付与します。 より具体的なシナリオでは、ユーザー定義のロールをカスタムの権限セットを使用して作成することもできます。

注：MongoDBが提供するすべての組み込みロールの詳細については、MongoDBの公式ドキュメントの組み込みロールページを参照してください。


ロールベースのアクセス制御により、ユーザーは、それぞれのタスクで作業するために必要な最小限の正確なレベルのアクセス許可のみを割り当てることができます。 これは、最小特権の原則として知られる重要なセキュリティ慣行です。

このガイドに従って、サンプルデータベース環境を構築し、いくつかのサンプルデータベースとユーザーを作成します。それぞれに異なるレベルのアクセス権が付与され、ロールベースのアクセス制御が実際に動作していることを示します。

ステップ1—サンプルシナリオの概要とサンプルデータベースの準備

ロールベースのアクセス制御（略してRBAC）が実際にどのように機能するかを説明するために、このガイドでは、2つのデータベースを使用するSammySalesという架空の販売会社のシナリオ例に従います。

最初のデータベース（salesと呼ばれる）は、顧客の個人データ用のcustomersと注文の詳細用のordersの2つの別々のコレクションで、会社のショップでの顧客の注文に関するデータを格納します。

2番目のデータベース（これはreportsと呼ばれます）は、月間売上に関する集計レポートを格納します。 このデータベースには、reportsという名前の単一のコレクションが含まれます。

会社には2人の従業員しかいませんが、どちらも最小特権のアプローチに従うレベルのデータベースアクセスを持っています。

  • 営業担当者のSammyは、salesデータベースの両方のコレクションに完全にアクセスする必要がありますが、reportsデータベースを操作する必要はありません。
  • セールスアナリストのジョーは、レポートを作成するためにreportsデータベースへの書き込みアクセス権と、データを取得するためのsalesデータベースへの読み取り専用アクセス権を必要とします。

要件を次の図に示します。

これらのサンプルデータベースを作成するには、MongoDBをインストールしたサーバーで次のようなコマンドを使用してMongoDBシェルを開き、プロセスで管理ユーザーとして認証されていることを確認します。 この例は、前提条件 Ubuntu 20.04でMongoDBを保護する方法チュートリアルで確立された規則に従います。このチュートリアルでは、管理MongoDBユーザーの名前はAdminSammyです。 異なる場合は、必ずAdminSammyを自分の管理ユーザーのユーザー名に置き換えてください。 

mongo -u AdminSammy -p --authenticationDatabase admin

プロンプトが表示されたら、インストール中に設定したパスワードを入力して、シェルにアクセスします。

show dbsコマンドを発行することで、MongoDBインスタンス全体にアクセスできることを確認できます。 

show dbs

これにより、現在利用可能なすべてのデータベースのリストが返されます。 

Outputadmin   0.000GB
config  0.000GB
local   0.000GB

これらのデータベースにアクセスできることを確認したら、salesデータベースに切り替えます。 

use sales

シェルは短い確認で応答します 

Outputswitched to db sales

MongoDBには、データベースを作成するための明示的なアクションはありません。 データベースは、少なくとも1つのドキュメントを格納している場合にのみ作成されます。 このことを念頭に置いて、このガイド全体の例で使用されているデータベースとコレクションを準備するために、いくつかのサンプルドキュメントを挿入する必要があります。

これでsalesデータベースにアクセスできますが、何かを挿入するまで実際には存在しません。

sales内にcustomersという名前のコレクションを作成し、同時に次の操作で新しいドキュメントを挿入します。 

db.customers.insert({name: 'Sammy'})

このサンプルドキュメントには、値が'Sammy'のnameフィールドのみが含まれています。 データ自体は、アクセス権が実際にどのように機能するかを示すことには関係がないことに注意してください。したがって、この手順では、模擬データの例のみを含むデータベースドキュメントを作成する方法の概要を説明します。

MongoDBは挿入を次のように確認します： 

OutputWriteResult({ "nInserted" : 1 })

このプロセスを繰り返しますが、今回はordersという名前のコレクションを作成します。 これを行うには、次のコマンドを実行します。 今回は、ドキュメントの唯一のフィールドはtotalであり、値は100です。 

db.orders.insert({total: 100})

MongoDBは、ドキュメントが正しく挿入されたことをもう一度確認します。

2つのデータベースで作業するため、reportsデータベースも準備する必要があります。 これを行うには、最初にreportsデータベースに切り替えます。 

use reports

そして、今度はreportsコレクションに別のドキュメントを挿入します。 

db.reports.insert({orders: 1})

両方のデータベースが正しく準備されていることを確認するには、show dbsコマンドをもう一度発行します。 

show dbs

このコマンドを2回実行すると、結果には、新しく作成されたデータベースの2つの新しいエントリが表示されます。 これらのデータベースは、各データベース内に最初のドキュメントを作成した後にのみ存続しました。 

Outputadmin    0.000GB
config   0.000GB
local    0.000GB
reports  0.000GB
sales    0.000GB

これでサンプルデータベースの準備が整いました。 これで、このシナリオ例に必要な、新しく作成されたデータベースへのアクセス権限が最も少ないユーザーのペアを作成できます。

ステップ2—最初のユーザーを作成する

このステップでは、2人のMongoDBユーザーのうち最初のユーザーを作成します。 この最初のユーザーは、会社の営業担当者であるサミーです。 このアカウントには、salesデータベースへのフルアクセスが必要ですが、reportsデータベースへのアクセスは一切必要ありません。

このために、組み込みのreadWriteロールを使用して、salesデータベース内のリソースへの読み取りアクセスと書き込みアクセスの両方を許可します。 サミーは営業担当者であるため、新しく作成したユーザーの認証データベースとしてsalesデータベースも使用します。

まず、salesデータベースに切り替えます。 

use sales

シェルは、選択したデータベースを使用しているという確認を返します。 

Outputswitched to db sales

サミーは営業部門で働いているため、MongoDBユーザーアカウントはsalesを認証データベースとして作成されます。

次のメソッドを実行して、sammyユーザーを作成します。 

db.createUser(
  {
    user: "sammy",
    pwd: passwordPrompt(),
    roles: [
      { role: "readWrite", db: "sales" }
    ]
  }
)

このcreateUserメソッドには、次のオブジェクトが含まれています。

  • userはユーザー名を表し、この例ではsammyです。
  • pwdはパスワードを表します。 passwordPrompt()を使用すると、入力するコマンドを実行するときにMongoDBシェルがパスワードを要求するようになります。
  • rolesは、付与された役割のリストです。 この例では、 sammy にreadWriteの役割を割り当て、salesデータベースへの読み取りおよび書き込みアクセスを許可します。 現在、 sammy には他の役割が割り当てられていません。つまり、このユーザーは、作成直後に追加のアクセス権を持ちません。

注： MongoDB を保護する方法の前提条件チュートリアルで説明したように、passwordPrompt()メソッドはMongoDBバージョン4.2以降とのみ互換性があります。 古いバージョンのMongoを使用している場合は、ユーザー名を書き出すのと同じように、このユーザーのパスワードをクリアテキストで書き出す必要があります。 

. . .
    pwd: "password",
. . .

このメソッドが成功すると、次のような確認メッセージがMongoDBシェルから返されます。 

OutputSuccessfully added user: {
    "user" : "sammy",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "sales"
        }
    ]
}

これで、新しいユーザーがデータベースにログインできること、および指定したアクセス権が適切に適用されているかどうかを確認できます。

後で使用できるように、管理ユーザーがログインした状態で現在のMongoDBシェルを開いたままにするため、別のサーバーセッションを開きます。

新しいサーバーセッションから、MongoDBシェルを開きます。 今回は、ユーザーとして sammy を指定し、認証データベースとしてsalesを指定します。 

mongo -u sammy -p --authenticationDatabase sales

sammyユーザーを作成するときに設定したパスワードを入力します。 シェルプロンプトにアクセスした後、show dbsコマンドを実行して、使用可能なデータベースを一覧表示します。 

show dbs

管理者アカウントとは対照的に、[X143X] データベースへのアクセスのみを許可しているため、sammyには1つのデータベースのみが表示されます。 

Outputsales  0.000GB

次に、sammyがsalesデータベースの両方のコレクションからオブジェクトを取得できるかどうかを確認します。 salesデータベースに切り替えます。 

use sales

次に、すべての顧客を取得してみます。 

db.customers.find()

このfindコマンドは、ステップ1でこのコレクションで作成したドキュメントを返します。 

Output{ "_id" : ObjectId("60d888946ae8ac2c9120ec40"), "name" : "Sammy" }

2番目のコレクションordersが意図したとおりに利用可能であることを確認することもできます。 

db.orders.find()

Output{ "_id" : ObjectId("60d890730d31cc50dedea6ff"), "total" : 100 }

salesデータベースのアクセス権が適切に構成されていることを確認するために、sammyが新しいドキュメントも挿入できるかどうかを確認できます。 新しい顧客を挿入してみてください： 

db.customers.insert({name: 'Ellie'})

sammy にreadWriteの役割を付与したため、このデータベースに新しいドキュメントを書き込むことが許可されます。 MongoDBは、挿入が正常に完了したことを確認します。 

OutputWriteResult({ "nInserted" : 1 })

最後に、sammyがreportsデータベースにアクセスできるかどうかを確認します。 割り当てられた役割を介したアクセスを許可しなかったため、このデータベースのデータを読み書きできなくなります。

reportsデータベースに切り替えます。 

use reports

このuseコマンドは、それ自体ではエラーになりません。 次の手順を実行して、手順1で挿入したドキュメントにアクセスしてみてください。 

db.reports.find()

これで、MongoDBはオブジェクトを返す代わりにエラーメッセージをスローします。 

OutputError: error: {
  "ok" : 0,
  "errmsg" : "not authorized on reports to execute command { find: \"reports\", filter: {}, lsid: { id: UUID(\"cca9e905-89f8-4903-ae12-46f23b43b967\") }, $db: \"reports\" }",
  "code" : 13,
  "codeName" : "Unauthorized"
}

Unauthorizedエラーメッセージは、sammyにreportsデータベースのデータと対話するための十分なアクセス権がないことを示しています。

これまでに、権限が制限された最初のデータベースユーザーを作成し、アクセス権が適切に適用されていることを確認しました。 次に、異なる権限を持つ2番目のユーザーを作成します。

ステップ3—2番目のユーザーを作成する

営業担当者であるSammyのsammy MongoDBユーザーを作成した後も、会社の営業アナリストであるJoeのアカウントが必要です。 シナリオの例から、Joeの職務にはデータベースに対して異なる特権のセットが必要であることを思い出してください。

この新しいユーザーアカウントを作成するプロセスは、sammyユーザーを作成するために実行したプロセスと似ています。

管理ユーザーがMongoDBシェルにログインしているサーバーセッションに戻ります。 そこから、reportsデータベースに切り替えます。 

use reports

Joeはレポート部門で働いているため、MongoDBユーザーアカウントはreportsを認証データベースとして作成されます。

次のコマンドを使用して、新しいjoeユーザーを作成します。 

db.createUser(
  {
    user: "joe",
    pwd: passwordPrompt(),
    roles: [
      { role: "readWrite", db: "reports" },
      { role: "read", db: "sales" }
    ]
  }
)

joe の作成に使用した方法と、前の手順でsammyの作成に使用した方法の違いに注意してください。 今回は、2つの別々の役割を割り当てます。

  • readWriteがreportsデータベースに適用されるということは、joeがこのデータベースに対して販売レポートデータを読み書きできることを意味します。
  • readをsalesデータベースに適用すると、 joe は販売データにアクセスできますが、そのデータベースにドキュメントを書き込むことはできなくなります。

これらの役割は両方とも、組み込みのMongoDB役割です。

このコマンドは、次のような確認メッセージを返します。 

OutputSuccessfully added user: {
    "user" : "joe",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "reports"
        },
        {
            "role" : "read",
            "db" : "sales"
        }
    ]
}

次に、新しいユーザーの権限が適切に適用されていることを確認します。

もう一度、別のサーバーセッションを開きます。これは、後の手順で管理MongoDBユーザーとsammyユーザーの両方を利用するためです。

MongoDBシェルを開きます。今回は、ユーザーとして joe を指定し、認証データベースとしてreportsを指定します。 

mongo -u joe -p --authenticationDatabase reports

プロンプトが表示されたら、joeユーザーの作成時に設定したパスワードを入力します。 シェルプロンプトにアクセスできるようになったら、show dbsコマンドを実行して、joeで使用可能なデータベースを一覧表示します。 

show dbs

joeはsalesデータベースとreportsデータベースの両方を使用できるため、これら2つのデータベースが出力に表示されます。 

Outputreports  0.000GB
sales    0.000GB

これで、joeがsalesデータベースからオブジェクトを取得できるかどうかを確認できます。

salesに切り替えます： 

use sales

次のfindコマンドを実行して、すべての注文を取得してみてください。 

db.orders.find()

権限を正しく設定した場合、このコマンドは、手順1でこのコレクションに作成した唯一のドキュメントを返します。 

Output{ "_id" : ObjectId("60d890730d31cc50dedea6ff"), "total" : 100 }

次に、ordersコレクションに新しいドキュメントを挿入してみてください。 

db.orders.insert({total: 50})

このデータベースにはjoeにreadの役割のみを割り当てたため、このinsertコマンドは失敗してエラーメッセージが表示されます。 

OutputWriteCommandError({
  "ok" : 0,
  "errmsg" : "not authorized on sales to execute command { insert: \"orders\", ordered: true, lsid: { id: UUID(\"ebbe853b-e269-463f-a1d4-2c5a5accb966\") }, $db: \"sales\" }",
  "code" : 13,
  "codeName" : "Unauthorized"
})

Unauthorizedメッセージは、失敗の背後にある理由を示しています— joeが持っているアクセス権は新しいドキュメントを挿入するのに十分ではありません。

次に、joeがreportsデータベースのデータを読み書きできるかどうかを確認します。

reportsに切り替えます： 

use reports

次に、findコマンドを使用してその中のデータにアクセスしてみてください。 

db.reports.find()

joe はデータベースからの読み取りが許可されているため、MongoDBは、このコレクションで現在利用可能なドキュメントのリストで応答します。 

Output{ "_id" : ObjectId("60d8897d6ae8ac2c9120ec41"), "orders" : 1 }

次に、次のコマンドを実行して、新しいレポートを挿入してみてください。 

db.reports.insert({orders: 2})

このコマンドも、次のような出力メッセージで成功します。 

OutputWriteResult({ "nInserted" : 1 })

これで、権限が制限された2番目のデータベースユーザーを作成しましたが、今回は2つの別々のデータベースに役割を付与しました。 また、それらのアクセス権がデータベースサーバーによって適切に適用されていることを確認しました。 次に、既存のユーザーの1人に追加の権限を付与してから取り消します。

ステップ4—既存のユーザーの役割の付与と取り消し

手順2と3では、新しいユーザーを作成し、作成プロセス中にそれらを役割に割り当てました。 実際には、データベース管理者は、システムですでに作成されているユーザーに対して、取り消したり、新しい特権を付与したりする必要があることがよくあります。 このステップでは、 sammy ユーザーに新しい役割を付与して、reportsデータベースにアクセスし、その直後にそのアクセス許可を取り消すことができるようにします。

管理シェルから、ユーザーsammyが作成されたsalesデータベースに切り替えます。 

use sales

ユーザーsammyがそこにいることを確認するには、show usersコマンドを実行します。 

show users

このコマンドは、このデータベース内のすべてのユーザーとそれぞれの役割のリストを返します。 

Output{
    "_id" : "sales.sammy",
    "userId" : UUID("cbc8ac18-37d8-4531-a52b-e7574044abcd"),
    "user" : "sammy",
    "db" : "sales",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "sales"
        }
    ],
    "mechanisms" : [
        "SCRAM-SHA-1",
        "SCRAM-SHA-256"
    ]
}

このユーザーに新しい役割を割り当てるには、grantRolesToUserメソッドを使用できます。 このメソッドは、ユーザーの名前と、新しいユーザーを作成するときに使用されるのと同じ構文で付与されるロールのリストを受け入れます。

このステップの目標は、 sammyにreportsデータベースの読み取り専用権限を付与することです。したがって、そのデータベースにreadロールを割り当てます。 

db.grantRolesToUser("sammy", [{role: "read", db: "reports"}])

エラーが発生しない限り、コマンドは出力を生成しないため、メッセージがないことは予想される動作です。 show usersコマンドを再度実行すると、コマンドが有効になったことを確認できます。 

show users

このコマンドは、次のような出力を返します。 

Output{
    "_id" : "sales.sammy",
    "userId" : UUID("cbc8ac18-37d8-4531-a52b-e7574044abcd"),
    "user" : "sammy",
    "db" : "sales",
    "roles" : [
        {
            "role" : "read",
            "db" : "reports"
        },
        {
            "role" : "readWrite",
            "db" : "sales"
        }
    ],
    "mechanisms" : [
        "SCRAM-SHA-1",
        "SCRAM-SHA-256"
    ]
}

rolesセクションに新しく追加された役割に注目してください。

これで、変更後にsammyが実際にreportsデータベースにアクセスできるかどうかを確認できます。 sammy がログインした状態でターミナルウィンドウに切り替えて、レポートにもう一度アクセスしてみてください。

reportsデータベースに切り替えます。 

use reports

次に、reportsコレクションでfindコマンドを実行します。 

db.reports.find()

前回、コマンドはエラーメッセージで失敗しました。 ただし、今回はreportsデータベース内のドキュメントのリストを返します。 

Output{ "_id" : ObjectId("60d8897d6ae8ac2c9120ec41"), "orders" : 1 }
{ "_id" : ObjectId("60d899cafe3d26bf80e947fd"), "orders" : 2 }

しばらくすると、sammyユーザーのレポートへのアクセス機能を取り消すことができます。 これを説明するために、管理コンソールに戻り、次のコマンドを実行します。これにより、reportsデータベースに対するsammyユーザーのread特権が取り消されます。 ： 

db.revokeRolesFromUser("sammy", [{role: "read", db: "reports"}])

revokeRolesFromUserメソッドは、grantRolesToUserと同じ引数のセットを取りますが、代わりに指定された役割を削除します。

もう一度、show usersで役割が使用できなくなったことを確認できます。 

Output{
    "_id" : "sales.sammy",
    "userId" : UUID("cbc8ac18-37d8-4531-a52b-e7574044abcd"),
    "user" : "sammy",
    "db" : "sales",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "sales"
        }
    ],
    "mechanisms" : [
        "SCRAM-SHA-1",
        "SCRAM-SHA-256"
    ]
}

sammyがreportsデータベースから読み取れなくなったことを再確認するには、sammyがログに記録された状態でシェルで前のfindコマンドを再実行してみてくださいの： 

db.reports.find()

今回は、コマンドはUnauthorizedエラーで再び失敗します。 

OutputError: error: {
  "ok" : 0,
  "errmsg" : "not authorized on reports to execute command { find: \"reports\", filter: {}, lsid: { id: UUID(\"2c86fba2-7615-40ae-9c3b-2dfdac2ed288\") }, $db: \"reports\" }",
  "code" : 13,
  "codeName" : "Unauthorized"
}

これは、sammyユーザーのreadロールの取り消しが成功したことを示しています。

結論

この記事では、データベースへのアクセスが制限されたユーザーを作成し、役割ベースのアクセス制御を使用してデータベースに最小特権の原則を適用し、ユーザーに必要最小限の特権セットのみを付与する方法を学習しました。 また、既存のユーザーに役割を付与および取り消す方法、必要なアクセス許可が時間の経過とともに変更されたときに稼働中のデータベースサーバーでアクセス権を管理する方法、および変更がすぐに有効になることを確認する方法についても学びました。

MongoDBのロールベースのアクセス制御では、ユーザー定義の役割などの機能を使用して正確なアクセスレベルを定義したり、組み込みの役割では不十分な場合にカスタムの役割を作成したり、管理者が特定のコレクションに対する特権をユーザーに付与できるコレクションレベルのアクセス制御を使用したりできます。データベース全体ではなく。 公式のMongoDBドキュメントで詳細に説明されているこれらおよびその他のロールベースのアクセス制御機能について詳しく知ることをお勧めします。

「https://www.finddevguides.com/index.php?title=MongoDBアクセス制御の使用方法&oldid=107186」から取得
Powered by MediaWiki