MongoDB：9-MongoDB的安全和认证

最新推荐文章于 2024-03-28 09:06:45 发布

琦彦

最新推荐文章于 2024-03-28 09:06:45 发布

阅读量1.2w

点赞数 1

分类专栏： MongoDB MongoDB-从基础到深入文章标签： MongoDB

本文链接：https://blog.csdn.net/fly910905/article/details/78210381

版权

MongoDB 同时被 2 个专栏收录

25 篇文章 2 订阅

订阅专栏

MongoDB-从基础到深入

25 篇文章 16 订阅

订阅专栏

  
  每个MongoDB实例中的数据库都可以有许多用户。
如果开启了安全性检查，则只有数据库认证用户才能执行读或者写操作。

在认证的上下文中，MongoDB会将普通的数据作为admin数据库处理。
admin数据库中的用户被视为超级用户(即管理员)。

在认证之后，管理员可以读写所有数据库，执行特定的管理命令，如listDatabases和shutdown。
在开启安全检查之前，一定要至少有一个管理员账号。

MongoDB 3.0 安全权限访问控制，在添加用户上面3.0版本和之前的版本有很大的区别，
这里就说明下3.0以上的添加用户的方法。

  
  注意：帐号是跟着库走的，所以在指定库里授权，必须也在指定库里验证(auth)。

   
   use admin
     
     switched to db admin
db.createUser(
   {
     user: "root",
     pwd: "root",
     roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
   }
 )
 
 
     
      Successfully added user: {
	"user" : "root",
	"roles" : [
		{
			"role" : "userAdminAnyDatabase",
			"db" : "admin"
		}
	]
}

user：用户名
pwd：密码
roles：指定用户的角色，可以用一个空数组给新用户设定空角色；在roles字段,可以指定内置角色和用户定义的角色。
role里的角色可以选：

   
   Built-In Roles（内置角色）：
    1. 数据库用户角色：read、readWrite;
    2. 数据库管理角色：dbAdmin、dbOwner、userAdmin；
    3. 集群管理角色：clusterAdmin、clusterManager、clusterMonitor、hostManager；
    4. 备份恢复角色：backup、restore；
    5. 所有数据库角色：readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、dbAdminAnyDatabase
    6. 超级用户角色：root  
    // 这里还有几个角色间接或直接提供了系统超级用户的访问（dbOwner 、userAdmin、userAdminAnyDatabase）
    7. 内部角色：__system

具体角色：

    
    Read：允许用户读取指定数据库
readWrite：允许用户读写指定数据库
dbAdmin：允许用户在指定数据库中执行管理函数，如索引创建、删除，查看统计或访问system.profile
userAdmin：允许用户向system.users集合写入，可以找指定数据库里创建、删除和管理用户
clusterAdmin：只在admin数据库中可用，赋予用户所有分片和复制集相关函数的管理权限。
readAnyDatabase：只在admin数据库中可用，赋予用户所有数据库的读权限
readWriteAnyDatabase：只在admin数据库中可用，赋予用户所有数据库的读写权限
userAdminAnyDatabase：只在admin数据库中可用，赋予用户所有数据库的userAdmin权限
dbAdminAnyDatabase：只在admin数据库中可用，赋予用户所有数据库的dbAdmin权限。
root：只在admin数据库中可用。超级账号，超级权限

刚建立了 userAdminAnyDatabase 角色，用来管理用户，可以通过这个角色来创建、删除用户。

验证：需要开启auth参数。【开启后，需要重启mongodb服务】

windows

         
         #在配置文件【mongod.cfg】，配置如下：
dbpath=D:\Java\MongoDB\data
logpath=D:\Java\MongoDB\log\mongo.log
logappend=true
directoryperdb=true
auth=true

linux

         
         mongod -f /etc/mongod.conf --fork --auth

          
          -f 是使用的配置文件  （--config）也可以
-fork 是 后台服务运行
-auth 必须认证才能操作

在test库里创建帐号
      
      
       
               
        db.createUser(
     {
       user: "read",
       pwd: "read",
       roles: [
          { role: "read", db: "mongotest" }   #只读账号
       ]
     }
 )
      
      
      
      
       
       
        
                 
         db.createUser(
     {
       user: "rw",
       pwd: "rw",
       roles: [
          { role: "readWrite", db: "mongotest" }    #读写帐号
       ]
     }
 )

上面创建了2个帐号，现在验证下：验证前提需要一个集合

        
        db.users.insert({"a":1,"b":2})
unauthorized
#插入失败，没有权限，userAdminAnyDatabase 权限只是针对用户管理的，对其他是没有权

用创建的readWrite帐号进行写入
       
       
        
                 
          db.auth('rw','rw')
       
       
       
       
        
        
         
                   
          db.users.insert({"a":1,"b":2})
Inserted 1 record(s) in 5ms

有没有一个超级权限？不仅可以授权，而且也可以对集合进行任意操作？答案是肯定的，只是不建议使用。那就是role角色设置成root。

       
       db.auth('root','root') //先要切换到userAdminAnyDatabase角色的用户
db.createUser(
     {
       user: "admin",
       pwd: "admin",
       roles: [
          { role: "root", db: "admin" }     //超级root帐号
       ]
     }
 )

因为帐号都是在当前需要授权的数据库下授权的，那要是不在当前数据库下会怎么样？

       
       > db
admin
> db.createUser(
...  {
...    user: "dxy",
...    pwd: "dxy",
...    roles: [
...       { role: "readWrite", db: "test" },     #在当前库下创建其他库的帐号，在admin库下创建test、abc库的帐号
...       { role: "readWrite", db: "abc" }         
...    ]
...  }
... )
Successfully added user: {
    "user" : "dxy",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "test"
        },
        {
            "role" : "readWrite",
            "db" : "abc"
        }
    ]
}
> 
> show users;
{
    "_id" : "admin.dba",
    "user" : "dba",
    "db" : "admin",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}
{
    "_id" : "admin.zhoujinyi",
    "user" : "zhoujinyi",
    "db" : "admin",
    "roles" : [
        {
            "role" : "root",
            "db" : "admin"
        }
    ]
}
{
    "_id" : "admin.dxy",
    "user" : "dxy",
    "db" : "admin",
    "roles" : [
        {
            "role" : "readWrite",
            "db" : "test"
        },
        {
            "role" : "readWrite",
            "db" : "abc"
        }
    ]
}
> use test
switched to db test
> db.auth('dxy','dxy')          #在admin下创建的帐号，不能直接在其他库验证，
Error: 18 Authentication failed.
> use admin
switched to db admin            #只能在帐号创建库下认证，再去其他库进行操作。
> db.auth('dxy','dxy')
> use test
switched to db test
> db.abc.insert({"a":1111,"b":2222})
WriteResult({ "nInserted" : 1 })
> use abc
switched to db abc
> db.abc.insert({"a":1111,"b":2222})
WriteResult({ "nInserted" : 1 })

       
       上面更加进一步说明数据库帐号是跟着数据库来走的，哪里创建哪里认证。

查看用户

       
       db.auth('root','root') //先要切换到userAdminAnyDatabase角色的用户
show users

备份还原使用那个角色的帐号？之前创建的帐号zjy:test库读写权限；zjyr:test库读权限

       
       root@zhoujinyi:~# mongodump --port=27020 -uzjyr -pzjyr --db=test -o backup   #只要读权限就可以备份
2015-06-29T11:20:04.864-0400    writing test.abc to backup/test/abc.bson
2015-06-29T11:20:04.865-0400    writing test.abc metadata to backup/test/abc.metadata.json
2015-06-29T11:20:04.866-0400    done dumping test.abc
2015-06-29T11:20:04.867-0400    writing test.system.indexes to backup/test/system.indexes.bson
root@zhoujinyi:~# mongorestore --port=27020 -uzjy -pzjy --db=test backup/test/  #读写权限可以进行还原
2015-06-29T11:20:26.607-0400    building a list of collections to restore from backup/test/ dir
2015-06-29T11:20:26.609-0400    reading metadata file from backup/test/abc.metadata.json
2015-06-29T11:20:26.609-0400    restoring test.abc from file backup/test/abc.bson
2015-06-29T11:20:26.611-0400    error: E11000 duplicate key error index: test.abc.$_id_ dup key: { : ObjectId('559154efb78649ebd831685a') }
2015-06-29T11:20:26.611-0400    restoring indexes for collection test.abc from metadata
2015-06-29T11:20:26.612-0400    finished restoring test.abc
2015-06-29T11:20:26.612-0400    done