翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ロールベースのアクセスコントロールを使用したデータベースへのアクセス
Amazon DocumentDB (MongoDB 互換) の ロールベースアクセス制御 (RBAC)を使用して、ユーザーがデータベースで実行できるアクションへのアクセスを制限できます。RBAC は、1 つ以上のロールをユーザーに付与することで機能します。これらのロールは、ユーザーがデータベースリソースに対して実行できるオペレーションを決定します。Amazon DocumentDB は、現在、read、readWrite、readAnyDatabase、clusterAdmin のようなデータベースレベルを対象とする組み込みロール、および要件に基づいて特定のアクションと詳細なリソースの両方をサポートしています。
RBAC の一般的ユースケースには、クラスター内のデータベースへの読み取り専用アクセス権を持つユーザーを作成して最小特権を強制したり、クラスター内の特定のデータベースにアクセスすることを単一のユーザーに許可するマルチテナントアプリケーションを設計したりすることが含まれます。
注記
2020 年 3 月 26 日 より前に作成されたすべての新規ユーザーには dbAdminAnyDatabase、readWriteAnyDatabase、および clusterAdmin のロールが付与されています。すべての既存ユーザーを再評価し、必要に応じてロールを変更してクラスターに最小特権を適用することをお勧めします。
トピック
RBAC の概念
ロールベースのアクセスコントロールに関連する重要な用語と概念を以下に示します。Amazon DocumentDB ユーザーの詳細については、Amazon DocumentDB イベントの管理 を参照してください。
-
ユーザー - データベースに対して認証し、オペレーションを実行できる個別のエンティティ。
-
パスワード - ユーザーの認証に使用されるシークレット。
-
ロール - 1 つ以上のデータベースに対してアクションを実行することをユーザーに許可します。
-
管理データベース - ユーザーを保存して認証する先のデータベース。
-
データベース (
db) - ドキュメントを保存するためのコレクションを含むクラスター内の名前空間。
次のコマンドは、sample-user というユーザーを作成します。
db.createUser({user: "sample-user", pwd: "abc123", roles: [{role: "read", db: "sample-database"}]})
この例では、以下のようになっています。
-
user: "sample-user"- ユーザー名を示します。 -
pwd: "abc123"- ユーザーのパスワードを示します。 -
role: "read", "db: "sample-database"- ユーザーsample-userにsample-databaseへの読み取り許可を付与することを示します。
次の例は、db.getUser(sample-user) を使用してユーザー sample-user を取得した後の出力を示しています。この例では、ユーザー sample-user は admin データベース内に存在しますが、データベース sample-database の読み取りロールを持っています。
ユーザーの作成時に、db フィールドを省略してロールを指定すると、Amazon DocumentDB は接続の発行先であるデータベースに暗黙でロールを帰属させます。たとえば、データベース sample-database に対して接続を発行し、次のコマンドを実行すると、ユーザー sample-user が admin データベース内に作成され、データベース sample-database への readWrite アクセス許可が付与されます。
db.createUser({user: "sample-user", pwd: "abc123", roles: ["readWrite"]})
このオペレーションによる出力は、次のようになります。
{
"user":"sample-user",
"roles":[
{
"db":"sample-database",
"role":"readWrite"
}
]
}すべてのデータベースを対象とするロール (readAnyDatabase など) を持つユーザーを作成するには、ユーザーの作成時に admin データベースのコンテキストで操作をしているか、ユーザーの作成時にロールのデータベースを明示的に指定する必要があります。admin データベースに対してコマンドを発行するには、コマンド use admin を使用します。詳細については、「一般的なコマンド」を参照してください。
RBAC 組み込みロールの開始方法
ロールベースのアクセスコントロールの使用を簡単に開始できるように、このセクションでは、異なるジョブ機能を持つ 3 人のユーザーのロールを作成して最小特権を強制するシナリオの例を示します。
-
user1は、クラスター内のすべてのデータベースの表示とアクセスを必要とする新しいマネージャーです。 -
user2は、同じクラスター内の 1 つのデータベース (sample-database-1) にのみアクセスする必要がある新しい従業員です。 -
user3は、同じクラスター内の、以前はアクセスできなかった別のデータベース (sample-database-2) の表示とアクセを必要とする既存の従業員です。
後で、user1 と user2 が退職し、この両方のユーザーのアクセス権を取り消す必要があります。
ユーザーを作成してロールを付与する場合、クラスターに対して認証を行うユーザーには、createUser と grantRole のアクションを実行できるロールが関連付けられている必要があります。たとえば、admin ロールと userAdminAnyDatabase ロールは両方とも、該当するアクションのアクセス許可を付与できます。ロール別のアクションについては、「ロールベースのアクセスコントロールを使用したデータベースへのアクセス」を参照してください。
注記
Amazon DocumentDB では、create データベースに対してコマンドを発行するかどうかにかかわらず、ユーザーおよびロールのすべてのオペレーション (get、drop、grant、revoke、admin など) が admin データベース内で暗黙で実行されます。
まず、クラスター内の現在のユーザーとロールを確認するために、次の例に示すように show users コマンドを実行します。クラスター内の 2 人のユーザー、serviceadmin、およびマスターユーザーが表示されます。これらの 2 人のユーザーは常に存在し、削除することはできません。詳細については、「Amazon DocumentDB イベントの管理」を参照してください。
show users
user1 に対して、次のコマンドを使用し、クラスター全体のすべてのデータベースに対する読み取りおよび書き込みアクセス権を持つロールを作成します。
db.createUser({user: "user1", pwd: "abc123", roles: [{role: "readWriteAnyDatabase", db: "admin"}]})
このオペレーションによる出力は、次のようになります。
{
"user":"user1",
"roles":[
{
"role":"readWriteAnyDatabase",
"db":"admin"
}
]
}user2 に対して、次のコマンドを使用し、データベース sample-database-1 への読み取り専用アクセス権を持つロールを作成します。
db.createUser({user: "user2", pwd: "abc123", roles: [{role: "read", db: "sample-database-1"}]})
このオペレーションによる出力は、次のようになります。
{
"user":"user2",
"roles":[
{
"role":"read",
"db":"sample-database-1"
}
]
}user3 を既存のユーザーとするシナリオをシミュレートするには、まずユーザー user3 を作成し、次に user3 新しいロールを割り当てます。
db.createUser({user: "user3", pwd: "abc123", roles: [{role: "readWrite", db: "sample-database-1"}]})
このオペレーションによる出力は、次のようになります。
{ "user":"user3", "roles":[ { "role":"readWrite", "db":"sample-database-1" } ] }
ユーザー user3 を作成したので、この user3 に対して sample-database-2 の read ロールを割り当てます。
db.grantRolesToUser("user3", [{role: "read", db: "sample-database-2"}])
最後に、user1 と user2 が退職し、この両ユーザーのクラスターに対するアクセス権を取り消す必要があります。これを行うには、次のようにユーザーを削除します。
db.dropUser("user1") db.dropUser("user2")
すべてのユーザーが適切なロールを持っていることを確認するには、次のコマンドを使用してすべてのユーザーを一覧表示します。
show users
このオペレーションによる出力は、次のようになります。
{
"_id":"serviceadmin",
"user":"serviceadmin",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"master-user",
"user":"master-user",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"user3",
"user":"user3",
"db":"admin",
"roles":[
{
"db":"sample-database-2",
"role":"read"
},
{
"db":"sample-database-1",
"role":"readWrite"
}
]
}RBAC ユーザー定義ロールの開始方法
このセクションでは、ユーザー定義の役割を開始するのに役立つように、ジョブ機能が異なる 3 人のユーザーにロールを作成して最小特権を適用するシナリオの例について説明します。
この例では、以下が適用されます。
-
user1は、クラスター内のすべてのデータベースの表示とアクセスを必要とする新しいマネージャーです。 -
user2は、同じクラスター内の 1 つのデータベースsample-database-1にのみアクセスする必要がある新しい従業員です。 -
user3は、同じクラスター内で以前はアクセスできなかったsample-database-2、別のデータベースの col2 という特定のコレクションを表示してアクセスする必要がある既存の従業員です。 -
user1に対して、次のコマンドを使用し、クラスター全体のすべてのデータベースに対する読み取りおよび書き込みアクセス権を持つロールを作成します。
db.createUser( { user: "user1", pwd: "abc123", roles: [{role: "readWriteAnyDatabase", db: "admin"}] } )
このオペレーションによる出力は、次のようになります。
{ "user":"user1", "roles":[ { "role":"readWriteAnyDatabase", "db":"admin" } ] }
user2 の場合、次のコマンドを使用して、データベース sample-database-1 内のすべてのコレクションに対する「検索」権限を持つロールを作成します。このロールは、関連付けられたすべてのユーザーが検索クエリのみを実行できるようにすることに注意してください。
db.createRole( { role: "findRole", privileges: [ { resource: {db: "sample-database-1", collection: ""}, actions: ["find"] }], roles: [] } )
このオペレーションによる出力は、次のようになります。
{ "role":"findRole", "privileges":[ { "resource":{ "db":"sample-database-1", "collection":"" }, "actions":[ "find" ] } ], "roles":[ ] }
次に、ユーザー (user2) を作成し、最近作成したロール findRole をユーザーに接続します。
db.createUser( { user: "user2", pwd: "abc123", roles: [] }) db.grantRolesToUser("user2",["findRole"])
user3 を既存のユーザーとするシナリオをシミュレートするには、まずユーザー user3 を作成し、次のステップで user3 に割り当てる collectionRole という新しいロールを作成します。
そして、新しいロールを user3 に割り当てることができます。この新しいロールにより、user3 の 1 つの特定のコレクション col2 へのアクセスを挿入、更新、削除、および検索できる sample-database-2 を許可します。
db.createUser( { user: "user3", pwd: "abc123", roles: [] }) db.createRole( { role: "collectionRole", privileges: [ { resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
このオペレーションによる出力は、次のようになります。
{ "role":"collectionRole", "privileges":[ { "resource":{ "db":"sample-database-2", "collection":"col2" }, "actions":[ "find", "update", "insert", "remove" ] } ], "roles":[ ] }
ユーザー user3 を作成したので、user3 にロール collectionFind を付与できます。
db.grantRolesToUser("user3",["collectionRole"])
最後に、user1 と user2 が退職し、この両ユーザーのクラスターに対するアクセス権を取り消す必要があります。これを行うには、次のようにユーザーを削除します。
db.dropUser("user1") db.dropUser("user2")
すべてのユーザーが適切なロールを持っていることを確認するには、次のコマンドを使用してすべてのユーザーを一覧表示します。
show users
このオペレーションによる出力は、次のようになります。
{ "_id":"serviceadmin", "user":"serviceadmin", "db":"admin", "roles":[ { "db":"admin", "role":"root" } ] } { "_id":"master-user", "user":"master-user", "db":"admin", "roles":[ { "db":"admin", "role":"root" } ] } { "_id":"user3", "user":"user3", "db":"admin", "roles":[ { "db":"admin", "role":"collectionRole" } ] }
ユーザーとして Amazon DocumentDB に接続する
Amazon DocumentDB クラスターに接続するときは、特定のデータベースのコンテキストで接続します。デフォルトでは、接続文字列でデータベースを指定しない場合、test データベースのコンテキストでクラスターに自動的に接続されます。insert や find などのすべてのコレクションレベルのコマンドは、test データベース内のコレクションに対して発行されます。
コンテキスト内にあるデータベース、つまりコマンドの発行を確認するには、以下のように、mongo シェル内の db コマンドを実行します。
クエリ:
db
出力:
testデフォルトの接続が test データベースのコンテキストに存在する場合でも、この接続に関連付けられているユーザーが test データベースに対するアクションの実行を許可されているとは限りません。前のシナリオ例で、sample-database-1 データベースに対する readWrite ロールを持つユーザー user3 として認証する場合、接続のデフォルトのコンテキストは test データベースです。ただし、test データベースのコレクションにドキュメントを挿入しようとすると、認証の失敗エラーメッセージが表示されます。これは、このコマンドをデータベースに対して実行する権限がユーザーに許可されていないことが原因です。
クエリ:
db
出力:
testクエリ:
db.col.insert({x:1})
出力:
WriteCommandError({ "ok" : 0, "code" : 13, "errmsg" : "Authorization failure" })接続のコンテキストを sample-database-1 データベースに変更すると、ユーザーが書き込み権限を持つコレクションに書き込むことができます。
クエリ:
use sample-database-1
出力:
switched to db sample-database-1クエリ:
db.col.insert({x:1})
出力:
WriteResult({ "nInserted" : 1})特定のユーザーとしてクラスターに対して認証を行う場合は、接続文字列でデータベースを指定することもできます。これにより、ユーザーが admin データベースに対して認証された後で use コマンドを実行する必要がなくなります。
次の接続文字列では、admin データベースに対してユーザーを認証しますが、接続のコンテキストは sample-database-1 データベースになります。
mongo "mongodb://user3:abc123@sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/sample-database-2"
一般的なコマンド
このセクションでは、Amazon DocumentDB でロールベースのアクセスコントロールを使用する一般的なコマンドの例を示します。ユーザーとロールを作成および変更するには、admin データベースのコンテキストで操作する必要があります。use admin コマンドを使用して、admin データベースに切り替えることができます。
注記
ユーザーおよびロールに対する変更は、admin データベース内で暗黙で実行されます。すべてのデータベースを対象とするロール (readAnyDatabase など) を持つユーザーを作成するには、ユーザーの作成時に admin データベース (use
admin) のコンテキストで操作をしているか、ユーザーの作成時にロールのデータベースを明示的に指定する必要があります (このセクションの例 2 を参照)。
例 1: データベース read 用の foo ロールを持つユーザーを作成します。
db.createUser({user: "readInFooBar", pwd: "abc123", roles: [{role: "read", db: "foo"}]})
このオペレーションによる出力は、次のようになります。
{
"user":"readInFooBar",
"roles":[
{
"role":"read",
"db":"foo"
}
]
}例 2: すべてのデータベースへの読み取りアクセス権を持つユーザーを作成します。
db.createUser({user: "readAllDBs", pwd: "abc123", roles: [{role: "readAnyDatabase", db: "admin"}]})
このオペレーションによる出力は、次のようになります。
{
"user":"readAllDBs",
"roles":[
{
"role":"readAnyDatabase",
"db":"admin"
}
]
}例 3: 新しいデータベースの既存のユーザーに read ロールを付与します。
db.grantRolesToUser("readInFooBar", [{role: "read", db: "bar"}])
例 4: ユーザーのロールを更新します。
db.updateUser("readInFooBar", {roles: [{role: "read", db: "foo"}, {role: "read", db: "baz"}]})
例 5: ユーザーのデータベースへのアクセスを取り消します。
db.revokeRolesFromUser("readInFooBar", [{role: "read", db: "baz"}])
例 6: 組み込みロールを説明します。
db.getRole("read", {showPrivileges:true})
このオペレーションによる出力は、次のようになります。
{
"role":"read",
"db":"sample-database-1",
"isBuiltin":true,
"roles":[
],
"inheritedRoles":[
],
"privileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
],
"inheritedPrivileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
}例 7: クラスターからユーザーを削除します。
db.dropUser("readInFooBar")
このオペレーションによる出力は、次のようになります。
true例 8: 特定のコレクションに対する読み取りおよび書き込みアクセス権を持つロールを作成する
db.createRole( { role: "collectionRole", privileges: [ { resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
このオペレーションによる出力は、次のようになります。
{ "role":"collectionRole", "privileges":[ { "resource":{ "db":"sample-database-2", "collection":"col2" }, "actions":[ "find", "update", "insert", "remove" ] } ], "roles":[ ] }
例 9: ユーザーを作成し、ユーザー定義ロールを割り当てる
db.createUser( { user: "user3", pwd: "abc123", roles: [] }) db.grantRolesToUser("user3",["collectionRole"])
例 10: ユーザー定義ロールに追加権限を付与する
db.grantPrivilegesToRole( "collectionRole", [ { resource: { db: "sample-database-1", collection: "col1" }, actions: ["find", "update", "insert", "remove"] } ] )
例 11: ユーザー定義ロールから権限を削除する
db.revokePrivilegesFromRole( "collectionRole", [ { resource: { db: "sample-database-1", collection: "col2" }, actions: ["find", "update", "insert", "remove"] } ] )
例 12: 既存のユーザー定義ロールを更新する
db.updateRole( "collectionRole", { privileges: [ { resource: {db: "sample-database-3", collection: "sample-collection-3"}, actions: ["find", "update", "insert", "remove"] }], roles: [] } )
機能的な違い
Amazon DocumentDB では、ユーザーとロールの定義が admin データベースに保存され、ユーザーは admin データベースに対して認証されます。この機能は MongoDB Community Edition とは異なりますが、MongoDB Atlas と一貫しています。
Amazon DocumentDB は、変更ストリームもサポートしています。変更ストリームは、クラスターのコレクション内で発生する変更イベントの時系列シーケンスを提供します。listChangeStreams アクションは、クラスターレベル (つまり、すべてのデータベースを対象に) 適用されます。modifyChangeStreams アクションは、データベースレベルで適用されます。
制限
次のテーブルは Amazon DocumentDB におけるロールベースアクセスコントロールの制限を含む
| 説明 | 制限 |
|---|---|
| クラスターあたりのユーザー数 | 1,000 |
| ユーザーに関連付けられているロールの数 | 1,000 |
| ユーザー定義ロールの数 | 100 |
| 権限に関連付けられているリソースの数 | 100 |
ロールベースのアクセスコントロールを使用したデータベースへのアクセス
ロールベースのアクセスコントロールでは、ユーザーを作成して 1 つ以上のロールを付与し、ユーザーがデータベースやクラスターで実行できるオペレーションを指定できます。
Amazon DocumentDB で現在サポートされている組み込みロールは次のとおりです。
注記
Amazon DocumentDB 4.0 と 5.0 では、それぞれ ListCollection および ListDatabase コマンドでは、オプションで authorizedCollections および authorizedDatabases パラメータを使用して、ユーザーが権限を持っているコレクションとデータベースを一覧表示し、listCollections および listDatabase ロールを要求するアクセスをします。また、ユーザーは KillCursor ロールを要求すねことなく、自分のカーソルを強制終了できるようになりました。
