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

投稿日: 2022-04-20 2022-10-23
タグ: Databases, MongoDB, Security

序章

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

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

前提条件

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

通常のroot以外のユーザーがいるサーバー sudo 特権と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）2つの別々のコレクションを使用して、顧客の注文に関するデータを会社のショップに保存します。 customers 顧客の個人データと orders 注文の詳細については。

2番目のデータベース（これは reports）月間売上に関する集計レポートを保存します。このデータベースには、 reports.

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

営業担当者のサミーは、 sales データベースですが、 reports データベース。
セールスアナリストのジョーは、 reports レポートを作成するためのデータベースと、 sales データを取得するためのデータベース。

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

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

mongo -u AdminSammy -p --authenticationDatabase admin

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

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

show dbs

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

Outputadmin   0.000GB
config  0.000GB
local   0.000GB

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

use sales

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

Outputswitched to db sales

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

あなたは今にいます sales データベースですが、何かを挿入するまで実際には存在しません。

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

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

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

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

管理者アカウントとは対照的に、 sammy には、アクセスを許可したデータベースが1つだけ表示されます。 sales データベース。

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"
}

The 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"
})

The 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 データベースを作成し、その直後にその許可を取り消します。

管理シェルから、 sales ユーザーsammyが作成されたデータベース：

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

そして、 find のコマンド reports コレクション：

db.reports.find()

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

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

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

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

The 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 データベース、前のデータベースを再実行してみてください find sammy がログインしているシェルのコマンド：

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ドキュメントで詳細に説明されているこれらおよびその他のロールベースのアクセス制御機能について詳しく知ることをお勧めします。

getdocs

13036