Securing Your Enterprise Web Apps with MongoDB Enterprise

Securing Your
Enterprise Web Apps with
MongoDB Enterprise

About: Tom Spitzer,
VP, Engineering, EC Wise
EC Wise builds/enables Complex Secure Solutions
Software Products / Service Delivery Platforms / Cyber Security
Key Practices: Security, Secure Software Development, Intelligent Systems, Data
Mature, International
Offices and customers: North and South America, Asia
~ 100 employees, senior experienced teams
Founded 1998
Prior to EC Wise I developed eCommerce and ERP systems

Challenges We Are Trying to Address
 We need ways to identify when attacks may be occurring
 When compromised, precise and efficient data restoration is essential
 MongoDB stores data in a form that could be compromised
 Within the Enterprise space, single sign on has been shown to be a better
solution for identity management than doling out user accounts on multiple
systems; it also enables centralized permission management
 We need tools for forensics and regulatory compliance
 We want to develop solutions for U.S. government agencies

Learning Objectives; you will learn how to
1. How to use MongoDB Enterprise Ops Manager to make your MongoDB
databases more secure
2. How to use the Encrypted Storage engine
3. The differences between Kerberos and LDAP authentication and how to set
them up
4. How to enable and manage auditing to support your security efforts
5. How to create a secure cluster configuration
6. What’s involved in setting up MongoDB in compliance with FIPS

OpsManager: Management and monitoring features
Interactively set deployment-wide authentication model
Monitor/set thresholds for resource usage
Unusual resource usage may indicate unusual activities
Continuous Backup and Backup encryption (v 3.4)
Automate version upgrades (and downgrades, if necessary)
Important since upgrades often include security enhancements
Log consolidation and management

Ops Manager Monitoring & Alerts

Ops Manager Backup Features
 Continuous back-up vs. interval based backup provided by MongoDump and
file system copies; Minimizes downtime, conserves resources
 Enables fast recovery in event of compromise
 Works with replica sets and sharded clusters
can convert standalone mongod to single member replica set
 Enables restore to specified point between snapshots
 Supports encrypted backup storage

Performs initial sync
to back up current
data.
•Includes each
shard and the
config servers.
Takes snapshots of
the data directory
based on specified
snapshot schedule
•then transfers the
snapshots to a
storage system
Monitors the oplog
constantly and adds
new database
operations to the
latest backup
•Ops Manager
maintains up to
date copy of
database.
The backup process:
Sharded Clusters also can
enable “checkpoints” to
permit restores at moments
between snapshots.
Maintains one
“head database”
per replica set

Set KMIP Server Configuration (req for encryption)
Navigate to the Backup
configuration tab.
1.Click Admin.
2.Click General.
3.Click Ops Manager Config.
4.Click Backup tab.

Configure Group to use KMIP and Storage Engine

Select Point-in-time;
Daemon applies
oplog entries to
closest PiT snapshot
Can restore to new
or different server
from source

MongoDB Storage Engine Encryption
Native encryption in Wired Tiger storage engine; single digit % overhead
Uses AES256 with choice of “mode of operation”
CBC: Cipher Block Chaining – tried and true (and MongoDB default)
G/CM: Galois Counter Mode – widely used for data packets
Key management – only master key is external to the server
two strategies for key rotation
Master Key per replica
Internal Key per database

Master key management
Only master key is external to the server
Two strategies for key rotation
Master Key per replica
Internal Key per database
Use third party key management appliance via the Key Management Interoperability
Protocol (KMIP). Recommended & typically required to meet regulatory reqs
e.g. Alliance Key Manager for MongoDB, Vormetric, Gemalto,
Open Source Python KMIP server
Local key management via a keyfile (generate with SSL)
openssl rand -base64 32 > mongodb-keyfile

Data at Rest Encryption with KMIP
3rd Party Key
Management
Appliance
Replica1 Host OS
DB 1 DB 2 DB 3
Replica1’s Master Key
CA Certificates File
DB 4
Internal Key Manager Keystore
(encrypted by Master Key)
DB 1 Key
DB 2 Key
DB 3 Key
DB 4 Key
Encrypts & Decrypts
Replica1 mongodReplica1 Key &
Certificate PEM
File

Enable encryption with new KMIP key
mongod --enableEncryption --kmipServerName <KMIP Server HostName>
--kmipPort <KMIP server port> --kmipServerCAFile <path to ca.pem>
--kmipClientCertificateFile <path to client.pem>
Enable encryption with keyfile
mongod --enableEncryption --kmipServerName <KMIP Server HostName>
--kmipPort <KMIP server port> --kmipServerCAFile <path to ca.pem>
--kmipClientCertificateFile <path to client.pem> --kmipKeyIdentifier <UID>
Enable encryption with existing key
// create key file, e.g. using OpenSSL
mongod –enableEncryption --encryptionKeyFile mongodb-keyfile

Key rotation (annual recommended)
KMIP – rotate master key
With the new master key, the internal keystore will be re-encrypted but the database keys will be
otherwise left unchanged. This obviates the need to re-encrypt the entire data set.
Rotate the master key for the secondary members of the replica set one at a time.
mongod --enableEncryption --kmipRotateMasterKey
--kmipServerName <KMIP Server HostName>
--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
Step down master to replica and rotate master key on it last
If using key file, recommendation is to replace and retire encypted replicas

Log Redaction (3.4 Enterprise)
Redacts Client Data Shown in System Log Files
• All potentially sensitive user data omitted from logs
Trade-off:
• Harder to diagnose system & performance issues
• If you don’t use, manage logs “carefully”
Vs

Enterprise Authentication models
Remote
Directory
Server
Username /
Password
(1)
(2)
(3)
Pre-
Established
Trust with
KDC
Key
Distribution
Center (KDC)
1. LDAP (inc. Active Directory)
2. Kerberos

Client Authentication Comparisons
Authentication Method Clear Text Password Identity Location
LDAP Yes * External
Kerberos
No (KDC generated session
key encrypted with
password)
External
* Can be protected via a transport-level security
mechanism

Using Kerberos with MongoDB
“Kerberos” a “tried and true” industry standard authentication protocol for large
client/server systems.
For organizations with in-place Kerberos infrastructure - Enterprise MongoDB and
applications use existing Kerberos authentication infrastructure and processes
Mutual authentication model mediated by Key Distribution Center
Must add Kerberos user and service principals to MongoDB $external database
User principals can represent actual users or applications
Service principals represent your MongoDB servers (use FQDNs)

Setting up LDAP between MongoDB and AD
• Set up Users and Groups in Active Directory
• Map AD Users to Mongo DB Groups
• Ensure AD Server has TLS/SSL enabled
• Work with your IT Dept
• Generate Certs and install on MongoDB Server
• Create LDAP configuration file on MongoDB Server
• See next slide
• Use LDAP query during login to determine user’s AD group
• Map to local role based on group membership
Usually
Domain
ControllerCommon
Scenario, and its
Fairly Complex,
so we posted
documentation

LDAP Authentication – Config file entries
security:
authorization: "enabled"
ldap:
servers: "cdcorpwindc01.ecwise.local"
userToDNMapping:
'[
{
match: "(.+)",
ldapQuery: "CN=Users,dc=ecwise,dc=local??sub?(sAMAccountName={0})"
}
]'
authz:
queryTemplate: "OU=Groups,OU=EC Wise
Users,DC=ecwise,DC=local??sub?(&(objectClass=group)(member={USER}))"
bind:
queryUser: "duke"
queryPassword: "ecwise@123"
setParameter:
authenticationMechanisms: 'PLAIN'

Client Authentication Examples
LDAP
Kerberos
FQDN

Enabling and using Auditing
 Track schema operations
 Track replica set reconfiguration events
 Track authentication and authorization activities
 How to filter
 How to specify destinations

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

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"]}}‘
Auditing - Filters Are Key

FIPS and MongoDB Overview
Requirements and standards for cryptographic modules used by departments and
agencies of the U.S. government
Addresses both hardware and software components
Four Levels, addressing security in eleven areas
MongoDB’s FIPS support covers the way that MongoDB uses OpenSSL for
network encryption, SCRAM-SHA-1 authentication, and x.509 authentication
If you use Kerberos or LDAP authentication, its on you to ensure that you are
using FIPS-compliant libraries

MongoDB FIPS Support
OpenSSL “FIPS Object Module”
Certified component optionally used via OpenSSL (must have certified version)
Ensures source code not tampered with
(checks signature against original certified version)
MongoDB configurable option
FIPSMode: true
Also applies to Encryption-at-Rest

Securing a Cluster
Router
Single Public Access
Shard + Replication set
Configure Server
Replication Set
Application
Mongo DB Cluster
Internal Network behind firewall
Authentication with account & password
Internal Authentication between nodes of cluster
With Key File (or X.509 certification)
VPN Access
Maintenance
Admin user
VPN Authentication

Cluster: Access via router; databases behind firewall
 Cluster should be invisible to public users, router the only access point.
 For System Admin user, setup a specific maintenance entrance or VPN access
for entry into the cluster network.
 Each mongo instance in cluster should use the key file as the Internal
Authentication (or X.509 certification)
 key file configuration easier than x.509, sufficient for many scenarios, but x.509 worth
exploring when managing sensitive data in production

Security configuration for Shard
Similar to simple configuration, start with mongod running without AUTH
bin/mongo --port 10000 (10001,10002,10003) – shard ports
db.createUser(
{
user: "<super user name>",
pwd: "<super user password>",
roles:[
"clusterAdmin",
"userAdminAnyDatabase",
"dbAdminAnyDatabase",
"readWriteAnyDatabase" ]

With the super user account,
 Configure server root account
We can use this account to manage the accounts of users who would visit
this Mongo DB cluster to read | write data.
With the Server Root Account,
 Create users and roles assign users to roles
 Shard Server root account
This is the Shard Local Administrative User, who would do database
maintenance or other admin tasks.
We can’t use this account for the regular visit from router

#file: mongod_db1.conf DB shard
systemLog:
destination: file
path: "/usr/local/mongodb-3.4.3/log/mongod_db2.log"
logAppend: true
storage:
dbPath: "/usr/local/mongodb-3.4.3/db/db2"
engine: wiredTiger
journal:
enabled: true
processManagement:
fork: true
net:
port: 10002
setParameter:
enableLocalhostAuthBypass: false
replication:
replSetName: rs_db2
sharding:
clusterRole: shardsvr
security:
authorization: enabled
clusterAuthMode: keyFile
keyFile: "/usr/local/mongodb-3.4.3/mongodb.key"
#file: mongod_cs.conf CSRS Config server
systemLog:
destination: file
path: "/usr/local/mongodb-3.4.3/log/mongod_cs.log"
logAppend: true
storage:
dbPath: "/usr/local/mongodb-3.4.3/db/db_conf"
engine: wiredTiger
journal:
enabled: true
processManagement:
fork: true
net:
port: 10000
setParameter:
enableLocalhostAuthBypass: false
sharding:
clusterRole: configsvr
replication:
replSetName: rs_cs
security:
authorization: enabled
clusterAuthMode: keyFile
keyFile: "/usr/local/mongodb-3.4.3/mongodb.key"

Generate
key file
• openssl rand -base64 500 > mongodb.key
• copy this into all servers of cluster
• chmod 600 mongodb.key
Add the security
settings into
each property file
• Configure server
• Shard replications
• Router
Update property
files in all servers
and restart each
instance
Internal Authentication among instances of cluster

Securing Your Enterprise
Stay current with MongoDB, and get the Enterprise version!
Encrypt data at rest as well as in transit
Integrate with Enterprise identity/authentication/authorization systems
Consider how to secure log files
Use auditing wisely, and in conjunction with OS and device auditing
You should be able to secure clusters

Securing Your Enterprise Web Apps with MongoDB Enterprise

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Securing Your Enterprise Web Apps with MongoDB Enterprise

Similaire à Securing Your Enterprise Web Apps with MongoDB Enterprise (20)

Plus de MongoDB

Plus de MongoDB (20)

Dernier

Dernier (20)

Securing Your Enterprise Web Apps with MongoDB Enterprise

Notes de l'éditeur