We've all heard the phrase data is the new currency. Your data is your most valuable asset, but are you protecting it and meeting your legal obligations? Security and compliance are foundational pillars of data resilience. While high availability ensures your systems stay operational, security protects sensitive data from unauthorized access. And compliance ensures you meet regulatory requirements like GDPR, HIPAA, and SOC 2. Failing to address these concerns can result in legal penalties, revenue losses, and damaged customer trust. In this video, we'll explore how to secure your self managed MongoDB deployments while meeting regulatory compliance requirements. We'll explore how MongoDB achieves data sovereignty through geo-distributed clusters, security best practices, and access control strategies. Let's dive in. Data sovereignty requires that certain types of data must reside in specific geographic locations. For example, GDPR mandates that personally identifiable information about European citizens must be stored within the European Union. Similarly, HIPAA has requirements for where healthcare data can be stored in the United States. MongoDB enables data sovereignty through its sharded cluster architecture combined with zone based sharding. This approach allows you to place specific data in designated geographic regions while maintaining a unified database system. Zone based sharding allows you to control which shards store specific ranges of data. By tagging shards with zone names and defining ranges, MongoDB routes documents to appropriate geographic locations. To do so, we'd first deploy a sharded cluster with shards distributed across both regions. In our EU data center, we might deploy two shards tagged as EU. In our US data center, we deploy two additional shards tagged as US. Next, we configure zone ranges for our customer collection. For customers with addresses in EU countries, we create a zone range that maps to the EU tag. For customers in North America, we'd map their data to the US tag. Here's what the configuration would look like in the MongoDB shell (when connected to a mongos associated with the sharded cluster). To configure the shards in each zone, we use the "sh.addZoneToShard()" command. Then we specify the range of shard keys we want to go to that zone with the "sh.updateZoneKeyRange()" command. Since we want all documents in this zone, we use "MinKey" and "MaxKey" as the values for our "_id" field. Finally, we shard the collection via the "sh.shardCollection()" command on the "_id" field using hashed sharding. With this configuration, MongoDB automatically routes European customer data to EU shards and North American data to US shards, satisfying regulatory requirements while maintaining query performance across your global system. While zone based sharding allows you to store data according to residency requirements, a complete compliance strategy must also protect data against threats. Once your topology is established, you must turn your attention to hardening the cluster itself. A cluster that stays online during a regional failure is only truly resilient if its security remains intact. An available but unencrypted database is a liability, not a success. Implementing robust security measures protects sensitive data and ensures compliance with regulatory standards. MongoDB provides several security capabilities that you should prioritize in your self managed deployments. These capabilities include isolation, encryption, and access controls. Let's look at each in more detail. Workload isolation using dedicated clusters is your first line of defense. For sensitive data subject to strict regulations, create separate MongoDB clusters isolated from other workloads. For example, if you're storing medical records that must comply with HIPAA, deploy a dedicated cluster on separate nodes. This isolation prevents accidental data exposure and simplifies compliance audits. Next, encryption protects our data both in transit and at rest. MongoDB supports SSL/TLS encryption for connections between clients and servers, preventing interception of data as it moves across networks. To enable encrypted connections, you'll need to configure your MongoDB instances with TLS certificates. Here's an example of starting a MongoDB instance with TLS enabled. We pass the TLS mode flag ("--tlsMode") with the "requireTLS" argument. This makes the server use and accept only TLS encrypted connections. Then we pass the TLS certificate key file flag ("--tlsCertificationKeyFile") and provide the path to the .pem file that contains both the TLS certificate and key. Finally, we pass the TLS CA file flag ("--tlsCAFile") and provide the path to the .pem file that contains the root certificate chain from the certificate authority. SSL and TLS provide encryption for network traffic, but we want to also encrypt the data as it resides on our server. This is where encryption at rest is valuable. For encryption at rest, MongoDB enterprise supports native encryption, which we can configure during the MongoDB startup as seen here. We also have the option to configure operating system level disk encryption. Check out our skills on networking security and encryption at rest to learn more. Access controls with role based authentication restrict who can access your data and what operations they can perform. MongoDB's role based access control allows you to create users with varying permission levels. In the example seen here, we've created three different users with varying levels of permission. Our first user named, "reportingUser" only has read access. The "dbAdmin" user can manage database configurations, but cannot read actual customer data. And finally, our "superAdmin" user is a super user with full permissions for emergency situations. Check out our skills on authentication and authorization to learn more. The final piece of our security work involves infrastructure security. To harden our system, we should disable unnecessary ports, configure firewall rules to restrict access to MongoDB ports, typically 27017, and regularly audit software dependencies for vulnerabilities. We should also have runbooks to ensure our operating system and MongoDB versions receive timely security patches. Notably, tools like Ops Manager and Cloud Manager provide centralized access control management across distributed deployments and generate security compliance reports for audits, simplifying the administrative burden of maintaining secure systems. Runbooks should also require that we regularly test our failover processes to validate that recovery happens seamlessly during disruptions. There should be scheduled periodic failover drills where we intentionally shut down primary nodes and verify that our applications automatically reconnect to newly elected primaries without data loss. Well done. In this video, you learned how MongoDB supports data sovereignty through geographically distributed clusters and explored security best practices including isolation, encryption, and role based access controls. By implementing these security and compliance measures in your self managed MongoDB deployments, you'll protect sensitive data, meet regulatory requirements, and maintain customer trust as your systems scale.