Beyond the Basics 4 MongoDB Security and Authentication
•
4 likes•1,583 views
Sichern Sie Ihre Daten lokal und in der Cloud Schützen Sie die wichtigsten Ressourcen Ihres Unternehmens
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Beyond the Basics 4 MongoDB Security and Authentication
Similar to Beyond the Basics 4 MongoDB Security and Authentication (20)
More from MongoDB
More from MongoDB (20)
Beyond the Basics 4 MongoDB Security and Authentication
- 2. Beyond The Basics : Part 4 Securing Your MongoDB Cluster -Authentication and Authorisation Benjamin Lorenz Senior Solutions Architect V1.4
- 3. Complexity is the Enemy of Security Security holes resulting from misconfiguration? Under ‘time-to-market’ pressures, neglecting to apply a security layer due to complexity?
- 4. Need Clearer Path To [Secure] Success • Technologies need to keep things simple – Especially around Security • MongoDB’s security features are orthogonal yet complimentary – Using one feature doesn’t require learning and configuring all other features
- 5. MongoDB DB-level Security Standards-based Minimal inter-dependencies – Authorization mandates Authentication, to identify roles – Certificate-based Authentication mandates In-Flight Encryption (TLS) – Client Authentication mandates Internal Authentication Authentication At-Rest Encryption In-Flight Encryption AuthorizationAuditing
- 6. 6 The Basic Stuff • Simple Security –Run on a different port to 27017 –Use –bind_ip to lock down local instances –Use IP tables or similar to control access to clients –Run with auth: mongod --auth
- 7. Quick reminder.... https://docs.mongodb.com/manual/administration/security-checklist/ Ensure you consult MongoDB’s Security Checklist Remember: • Apply security in layers, for defence in depth – Many of these layers are not MongoDB specific
- 8. MongoSecurityPlaypen GithubProject NOT PRODUCTION SECURE For learning/demoing purposes only https://github.com/pkdone/MongoSecurityPlaypen
- 10. Client Authentication Options 1. Challenge/Response (SCRAM-SHA-1) 2. LDAP (inc. Active Directory) 3. x.509 Certificate 4. Kerberos Remote Directory Server Username / Password Username / Password (1) (2) Ticket Pre- Established Trust with KDC Local CA Certificates File Key Distribution Center (KDC) Certificate
- 11. 11 SCRAM • Salted Challenge Response Authentication Mechanism – https://tools.ietf.org/html/rfc5802 • Supported Drivers: – https://docs.mongodb.com/manual/release-notes/3.0-scram/#considerations-scram-sha-1-drivers • Requires TLS • Upgrading to SCRAM-SHA-1 from MONGODB-CR is not reversible (2.6 to 3.0)
- 12. Client Authentication Examples SCRAM-SHA-1 LDAP x.509 Certificate Kerberos FQDNs
- 13. 13 LDAPAuthentication Options LDAP Integration MongoDB Versions Operating Systems External Dependencies Proxy 2. 6 + Linux Simple Authentication & Security Layer (SASL) Direct 3. 4 + Linux & Windows n/a DB Host Directory Host Directory Servermongod saslauthd proxy direct
- 14. Internal Authentication Options MongoD Replica Host OS Keyfile MongoD Replica Keyfile MongoD Replica Keyfile Key Challenge / Response Key Challenge / Response Key Challenge / Response MongoD Replica Key+ Cert MongoD Replica MongoD Replica Host OS Host OS x.509 Certificates Host OS Host OS Host OS CA Certs CA Certs CA Certs Key+ Cert Key+ Cert Key Files (SCRAM-SHA-1)
- 15. Authorization (Role Based Access Control)
- 16. Role Based Access Control Built-in roles • read, readWrite, dbAdmin, clusterAdmin, root, etc.. User-defined roles • Based on actions that can be defined for a resource
- 17. Defining & Using a Custom Role Example: “Append-only” role Define The Role & User Try Inserting & Querying Data
- 18. 18 LDAPAuthorization* MongoDB Roles Mapped toLDAPGroups * New in 3.4 Role membership is fluid & managed dynamically in the LDAP Directory (rather than granting roles to users in MongoDB) LDAP Authorization is an optional feature, if LDAP Direct Authentication is enabled
- 19. 19 Read-Only Views* + Roles For Record-levelAccess Control Define a View (uses Agg Fwk) Lock Down User to Only the View * New in 3.4
- 21. TLS (aka SSL) CRUD API calls over TLS Internal Traffic over TLS DriverClient Machine CA Certificates File CA Certificates File Server Key & Certificate PEM File CA Certificates File Server Key & Certificate PEM File CA Certificates File Server Key & Certificate PEM File
- 22. TLS • Can apply to client traffic or internal traffic or both • Supported on all Drivers and MongoDB Tools • Client Certificate authentication not mandated – Any client and internal authentication methods can be used – Can even have authentication / authorization completely disabled
- 24. Encrypted Storage Engine • Native encryption inside the database – Single-digit % overhead – Based on WiredTiger • Two Key Types for easy key rotation – Master Key per replica – Internal Key per database • Options for sourcing Master Key: – Via 3rd Party Key Management Appliance using KMIP (Key Management Interoperability Protocol) – Keyfile on local file-system (not recommended for Production)
- 25. Encryption-at-Rest with KMIP 3rd Party Key Management Appliance Replica1 Host OS DBa DBb DBc Replica1’s Master Key Replica2’s Master Key Replica3’s Master Key CA Certificates File DBd Internal Key Manager Keystore (encrypted by Master Key) DBa Key DBb Key DBc Key DBd Key Encrypts & Decrypts Replica1 mongod Replica1 Key & Certificate PEM File
- 26. MongoDB Encryption-at-Rest Symmetric Keys • Same key to encrypt & decrypt • AES256-CBC (256-bit AES Cipher Block Chaining mode) • AES256-GCM (256-bit AES Galois/Counter Mode) • FIPS 140-2 encryption option Encryption Alternatives • Partner solution for file & OS level encryption (eg. Vormetric) • Application code performs field-level encryption DEFAULT BUT HOW TO INDEX?
- 27. Auditing
- 29. Auditing Event Types System Events CRUD Events Default (when enabled) Enabling Config Parameter auditLog - destination setParameter – auditAuthorizationSuccess Event Types DDL Auth failures Users & Roles config Replication &Sharding config Server Lifecycle actions Inserts Updates Removes Finds Aggregations
- 30. Auditing Filters Are Key • Filter on attributes of captured audit documents – In config, set ‘auditFilter’ to a query expression – Filter on: Action, User, Role, Command, Database, Collection, etc • Examples: filter: '{atype: {$in: ["createCollection", "dropCollection"]}}‘ filter: ‘{roles: {role: "readWrite", db: "test“}}‘ filter: '{atype: "authCheck", "param.command": {$in: ["find", "insert"]}}‘
- 31. Atlas Security
- 32. Atlas & Security • SCRAM-SHA-1 authentication enforced • TLS/SSL enforced • Pre-defined roles against each database • IP white-listing enforced • VPC Peering option with application tier • 2FA authentication for admin console • Option for encrypted data volumes
- 33. Summary
- 34. Summary • MongoDB keeps things simple – Clearly separates out different security concerns • Reduce complexity – Decreases risk of security holes • Remember to Consult the MongoDB Security Checklist!
Editor's Notes
- Ever gone live with a Security Exception in place?
- Otherwise an attacker could try to masquerade as a DB node to by-pass authentication
- The Kerberos ticket contains that a random key + user's name, encrypted with the service's longterm key.
- In 3.4, for x.509 Certificate authentication passing the ‘user’ field to auth() is not necessary as it is implied by the subject name in the client certificate file. Driver support : https://docs.mongodb.com/manual/release-notes/3.0-scram/#considerations-scram-sha-1-drivers
- Authorization flag applies to ALL Users – cluster-wide Who is authorized? Client Applications Tools Nodes in a MongoDB cluster
- A user role may have been defined in a different database, hence need to define db in createRole()
- How MongoDB is mapped to roles, is defined in mongod.conf. Eg. security: ldap: authz: queryTemplate: "ou=Groups,dc=Acme,dc=com??sub?(&(objectClass=groupOfNames)(member={USER}))"
- Use FQDNs and ensure used hostname matches certificate CN PEM: Privacy Enhancement Mail container format (base64 encoded format) "SSL cipher selection": non-documented flag "--sslCipherConfig" see: https://jira.mongodb.org/browse/SERVER-16073 net.ssl.mode: disabled | allowSSL | preferSSL | requireSSL
- Without Client Auth sometimes referred to as “one-way-SSL” (poor name) With Client Auth sometimes referred to as “two-way-SSL” (poor name)
- Why 2 levels of keys: Allow easy rotation of Master key (eg. once per year) without having to de-crypt and re-encrypt all data (could be time consuming and hurt performance) – new master key just de-crypts and re-encrypts keystore containing DB keys (which don’t need to change). No need to rotate DB keys as not accessible to administrators/users. Some customers have security compliance item to encrypt each DB separately (eg. due to “multi-tenant” DBs) In future could provide option to only encrypt select DBs for performance for DB’s not requiring encryption Replication is independent of Encryption. Rotating replicas with emptied data files that initial sync is the way to enable re-encryption of DBs
- AES = Advanced Encryption Standard Tested KMIP Appliances Vormetric DSM Safenet Keysecure Master key uuid is stored in WT metadata file WiredTiger.basecfg For DB encryption, encrypts at page level. HSMs: KMIP Appliances often use a hardware security module (HSM), which is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Typically have with cryptographic acceleration. HSMs and/or the cryptographic modules they employ are typically certified to internationally recognized standards such as Common Criteria or FIPS 140 to provide users with independent assurance that the design and implementation of the product and cryptographic algorithms are sound. The highest level of FIPS 140 security certification attainable is Security Level 4 (Overall), to which very few HSMs have been successfully validated.
- The auditing system writes every audit event to an in-memory buffer of audit events. MongoDB writes this buffer to disk periodically. If an audit event entry corresponds to an operation that affects the durable state of the database, such as a modification to data, MongoDB will always write the audit event to disk before writing to the journal for that entry. Stdout is the output option called Console
- MongoDB Atlas users to directly peer virtual private clouds (VPCs) in user’s AWS accounts with the MongoDB Atlas VPC created for your MongoDB clusters. Essentially enables creation of an extended, private network connecting your application servers and backend databases.