4. History
• Security features within mongoDB before 2.4
were limited
• 2.4 offers a much better story around security
• This is something we are investing in very
heavily right now.
Securing your MongoDB Implementation, Spencer Brody
5. The Three A’s
Authentication
– Who are you?
Authorization
– What can you do?
Auditing
– What have you done?
Securing your MongoDB Implementation, Spencer Brody
8. Password Authentication
• This is the only authentication mechanism
available in MongoDB version 2.2 and prior
• Still the only version available in the free product
• In 2.4+ this mechanism is called MONGODB-
CR
Securing your MongoDB Implementation, Spencer Brody
9. Password Authentication
• Use one-way function F
mongod
I am “username”, let me in
Prove it, here is a random # N
Here is
F(N, hash(<mypwd>))
Nobody else could know
that, welcome back!
Knows
only my
passwor
d hash
Hash never
transmitted
over the
network!
Securing your MongoDB Implementation, Spencer Brody
10. External Authentication
Use common / standardized authentication
SASL: Simple Authentication and Security Layer
– Framework for building authentication
– MongoDB uses the Cyrus sasl2 library
Kerberos (available in the Enterprise Edition)
– GSSAPI
– driver support in python, java, C#, Node.js, perl
Securing your MongoDB Implementation, Spencer Brody
11. Authentication with Kerberos
KDC
1. I am
“username@EXAMPLE.COM”,
help me prove it to mongod
(UDP:88)
2. Here is a TGT
Mongod
3. TCP:27017
Here is a
Kerberos
TGT
4.
Welcome, he
re is a
Service
Ticket!
{
user: ”username@EXAMPLE.COM",
roles: ["readWrite"],
userSource: "$external"
}
Securing your MongoDB Implementation, Spencer Brody
Keytab
14. Authorization
Once MongoDB has established “who” you
are, authorization is about determining
“what” you are allowed to do.
Securing your MongoDB Implementation, Spencer Brody
16. Authorization Roles in 2.4
– read
– readWrite
– dbAdmin
– userAdmin
– readAnyDatabase
– readWriteAnyDatabase
– dbAdminAnyDatabase
– userAdminAnyDatabase
– clusterAdmin
The roles that are bold can only be granted in the
admin database.
Securing your MongoDB Implementation, Spencer Brody
17. userAdmin
The userAdmin role on database “foo” lets you grant
any db-level role to any user from the “foo” database
(including yourself).
The userAdminAnyDatabase role lets you grant any
role in the system to any user (including yourself).
This means they can be used to grant yourself roles
you didn’t previously have!
This makes userAdmin effectively a super-user
Access to these roles should be carefully controlled!
Securing your MongoDB Implementation, Spencer Brody
18. Example
Securing your MongoDB Implementation, Spencer Brody
User Role Database(s)
appUser readWrite app
dba dbAdmin app
seniorDBA dbAdminAnyDatabase,
clusterAdmin
admin
readWrite config
CTO userAdminAnyDatabas
e
admin
20. Securing your MongoDB Implementation, Spencer Brody
Auditing
Monitor user activity:
– userID added to standard output in 2.4
– No separate audit log
– Much more coming in 2.6
22. Transport Encryption - SSL
http://docs.mongodb.org/manual/administration/ssl/
Application
SSL encryption
for client
connection
SSL encryption
for inter-server
traffic
Primary Secondary
Data Files Data Files
Securing your MongoDB Implementation, Spencer Brody
24. Securing your MongoDB Implementation, Spencer Brody
Outside MongoDB
Firewalls
– iptables & netsh
– Ports, Addresses, Times, Throttle etc.
File system
– Encrypt (Gazzang) [HIPAA, PCI, SOX]
Best Practices
– Internal Policies (Password Reuse, Scan etc.)
25. Securing your MongoDB Implementation, Spencer Brody
MongoDB Partners with
Gazzang
• File System Encryption
• 5% performance hit with HDD, 10-15% with
SSD
File System – All contents encrypted
OS Gazzang
Gazzang
Key Mgmt
27. MongoDB Secure Development
Lifecycle
• All contributions to the open source project are
reviewed and tested by a member of the Core Server
team
• Peer code reviews of all commits
• Automated functional and unit tests
• Active monitoring of best practices and advisories for
third party code
• Static code analysis with Coverity run nightly against
the Core Server and applicable driver projects
Securing your MongoDB Implementation, Spencer Brody
32. Disclaimer
Statements about future releases, availability
dates, and feature content reflect plans only, and
10gen is under no obligation to include, develop
or make available, commercially or
otherwise, specific feature discussed a future
MongoDB build. Information is provided for
general understanding only, and is subject to
change at the sole discretion of 10gen in
response to changing market conditions, delivery
schedules, customer requirements, and/or other
factors.
Securing your MongoDB Implementation, Spencer Brody
33. Future
• User-defined roles
• Collection level access control
• Field level access control
• Auditing
• X.509 authentication, for both user and intra-
cluster authentication.
• External configuration of user’s roles (LDAP)
Securing your MongoDB Implementation, Spencer Brody
35. Conclusion
• 2.2 had rudimentary security support
• 2.4 is much better & Enterprise-Level
• Authentication & Authorization
• Within & Outside
Securing your MongoDB Implementation, Spencer Brody
37. Securing your MongoDB Implementation, Spencer Brody
Next Sessions at 11:00
5th Floor:
West Side Ballroom 3&4: Schema Design
West Side Ballroom 1&2 (this room): Data Processing and
Aggregation Options
Juilliard Complex: Business Track: Fireside Chat: IBM and
MongoDB Set the Standard for Web and Mobile Development
Lyceum Complex: Ask the Experts
7th Floor:
Empire Complex: Performance Tuning and Monitoring Using
MMS
SoHo Complex: 10gen Polyglot Spatial with MongoDB
Editor's Notes
I assume you have some security background, are familiar with industry standard security tech like SSL and Kerberos, are familiar with access control in RDBMS
SDL = Secure Development Lifecycle
Security before 2.4 was weakMost of our customers were small startups, we didn’t have much demand for security featuresOnce we got bigger customers who cared about security, we delivered.
In 2.2 security was handled outside MongoDBWe want to enable anyone to build apps on MongoDB, even if they have strict security guidelines. We were finding that big orgs couldn’t use it b/c of their internal policies.
GSSAPI = Generic Security Services Application Program InterfaceMeta protocol for negotiating authentication protocol
MongoD never sees your password or even password hashYou can centralize your authentication serviceKDC = Key Distribution CenterIntra-cluster auth still uses MONGODB-CR!!!
No separation of administrative operationsUse case: performance tuning dba who can profile, build indexes, dbStats, but not read data.
Best practice is to have 1 user with userAdminAnyDatabase and no other roles, and use it for all user administration.userAdmin is *effectively* (but not actually) a super-user.
readWrite on configdb necessary for some sharding admin tasks (like stopping/starting the balancer)This is only one example – different companies will do this differently.
New in 2.4 – certificate validation, windows support2.2 was a partial implementation, 2.4 is now fully implementedProvided encryption but not authentication. Keyfilestill used for intra-cluster authentication. SSL (with CA validation) ensures that the hosts are who they say they are, but that’s separate from user authentication within MongoDB
Defense in Depth
Netsh = network configuration tool for windowsDefense in Depth
With SSD, as the time spent processing data between OS and disk gets proportionally larger since SSD's are so much faster, it means the pert hit is 15%. You still get a major upgrade in speed, but encrypting and decrypting take a larger share.
