How to Access Non-Relational Azure Data
When you think of NoSQL, you most likely think of MongoDB. MongoDB has become synonymous with programmers as 'NoSQL,' but there are other kinds of NoSQL databases out there, too. For instance, Microsoft offers data lake services. Data lakes are giant pools of non-relational data, and they are perfect for 'big data.' As you might have guessed, though, accessing information stored in a data lake is different from querying MongoDB. So, how do you access non-relational data in Azure? We are going to discuss that today.
Though Microsoft offers more traditional NoSQL databases like MongoDB, data lakes are a different beast altogether. Non-relational data storage in Azure uses proprietary storage mechanisms and database engines. In addition, access to non-relational Azure data is built around the Microsoft IAM (identity and access management) systems. So non-relational data also uses the Microsoft storage system too.
If you are familiar with configuring other Azure services, creating a non-relational data store in Azure will be easy. If you are not, the process is not complex, but you need to understand how cloud services like Azure work.
Cloud services like Azure offer various services, but those services are based around central systems. Two of those systems are data storage and IAM services. Microsoft uses those services to build out other products such as Cosmos DB.
So, all the services that Azure offers are tied together in some way. For instance, all of Azure's services use IAM for user permissions. Those permissions state which users are allowed to use which services. Likewise, other Azure services use Azure's storage system to handle data storage.
We will go into more specific details about what non-relational Azure data systems need for you to be able to access them below.
An Overview of How to Access Non-Relational Azure Data [VIDEO]
In this video, CBT Nuggets trainer Ben Finkel covers how to secure and access non-relational data in Azure. There are steps to make sure your non-relational data are secure and available in Azure. Those steps are pretty similar for securing other resources with Azure. Watch and learn how to manage security and access through data encryption, user authentication, networking and firewalls — all in Azure.
NoSQL Azure Data is Encrypted at Rest and in Transit
First and foremost, all data stored in Azure is encrypted. Azure offers varying degrees of encryption and encryption management, but Azure still enforces a minimum level of security nonetheless.
One of those minimum levels of security is that all data is encrypted at rest in the database. That means any data stored in Azure data storage not being processed or transmitted is encrypted while it is simply sitting there. This protects data if someone gains access to it.
This has implications for developers, though. Organizations will need to manage encryption keys. If those keys are lost, data won't be accessible anymore. Microsoft gives companies the choice of managing keys themselves or letting Microsoft manage encryption keys for them.
Data in Azure non-relational databases is stored somewhere, and that somewhere is Azure's storage systems. Azure data storage is also capable of encrypting data. When configuring a non-relational database in Azure, you can choose what to encrypt in storage. For example, you can choose to only encrypt blobs and data files at rest.
You do have the option of encrypting the entire infrastructure. That decision must be made when first creating the database. It can't be changed later.
Finally, all connections made to Azure are made via HTTPS. That means all data is encrypted while in transit, too. This can't be turned off.
NoSQL Azure Data Can Be Restricted Through Role-Based Access Control
Traditional relational databases have their own built-in user management systems. These are primarily legacy features, so Microsoft supports this kind of access management. NoSQL databases in Azure use Azure IAM for access management instead, though.
IAM stands for identity and access management. It's a centralized system for Azure services to organize and manage user accounts and what those accounts are allowed to do. For example, many Azure services, including Cosmos DB, depend on IAM to control which users can access NoSQL databases and what permissions those users have to those databases.
Azure IAM services are roll-based. As such, Cosmos DB uses role-based access control. If you are familiar with Active Directory and Group Policy, you will be comfortable configuring accounts in IAM.
IAM has two individual pieces. Those pieces are individual user accounts and user roles. You combine both to describe what permissions each user has in Azure.
Individual user accounts are stored in Azure Active Directory. A user account consists of things like a user's ID and password. User accounts don't have permissions assigned to them directly. Instead, user accounts have roles attached to them.
Roles are definitions of what permissions or capabilities user accounts can have. For instance, you can create a specific role that allows access to a particular Cosmos DB instance. That role will also include information like the storage access keys for that database. Each user that has this role assigned to them can access that specific Cosmos DB instance. Updating this individual role will update all users that have this role assigned to them automatically.
How is this helpful?
It's an object-based system. Anyone familiar with object-oriented programming will immediately understand why this is so powerful.
Each role is an individual object. Each object is unique (or at least it should be). Roles can be assigned to multiple user accounts, and each user account can have various roles assigned to it.
For example, let's say that you have two roles. One role describes a human, while another role describes a construction worker. Of course, all people will be assigned the 'human' role, but not all people are construction workers. So, for that small subset of construction workers, they will be given both the 'human' and 'construction worker' roles.
Yes, that's a crude example of how roles might work. Nonetheless, it gets the point across, and you need to understand how roles work and why you use them.
One of the primary examples why is keeping storage access keys updated and cycled. It might be good practice for your organization to exchange storage access keys once every 6 months. If you exchange keys, though, each service that uses those storage access keys will be inoperable until you can update the key for it. Therefore, you could have two storage access keys generated at any given time.
When it's time to cycle your storage access keys, first update all the services using a storage access key to the secondary key. Both keys are still active during this time, so none of the services using them experience any downtime. After all services are updated, cycle the old key and replace it. Then, when it comes time to cycle storage access keys again, follow the same process.
By cycling storage access keys this way, other services depending on those keys don't experience downtime. Those keys are also stored in IAM roles. So, you can update individual roles as needed without editing each individual user, too. This makes the key cycling process quick and painless. It also helps prevent mistakes.
ACLs can be Created to Restrict Access to NoSQL Azure Data
Access to NoSQL databases can be restricted through network configurations in Azure, too. This will work conceptually like other networking services, so it should be easy to set up.
First, you can simply allow any IP address to connect to your database. Of course, there could be various reasons you would not want to restrict access to specific sources. Still, typically it is recommended to change this setting.
In that case, it is preferred to restrict access to your Cosmos DB instances to specific networks. For example, let's say that your Cosmos DB instance holds all the data for your web service, but you don't want anything but your web service to connect to it. So, you could set the ACLs for your Cosmos DB instance to only allow connections from the IP address for your web service. But, of course, doing this means you might lock yourself out of your database, so you might want to allow access from your home IP address as well.
If you have your own virtual network within Azure, you can also restrict access to that private network. This is typically only the case for organizations that might have more complicated cloud resource configurations. If you want to limit access to your Cosmos DB instance, though, but need a group of networked resources to access it, this is a good option.
Finally, you can create private endpoints for your Cosmos DB instance. These private endpoints can be used instead of an ACL.
Non-relational data in Azure is restricted through different mechanisms. One of those mechanisms is through user account permissions. User account permissions are created through Azure IAM. Azure IAM is a role-based access control system. User roles need to be configured with permissions for specific services. Those roles then need to be assigned to individual user accounts. If a user account doesn't have the proper role set, that user account can't access that service.
Data is also encrypted at rest and in transit in Azure. Data storage has access keys assigned to it. Those access keys need to be set in an IAM role before users can retrieve or store data.
Finally, NoSQL Azure data access can be restricted through networking services, too. This is done through an ACL. Individual IPs, entire subnets, or private Azure networks can be assigned in those ACLs. You can also create private endpoints to connect to as well.