At any point of time, we will have data in three phases: Data in rest, Data in Transit and Data in Use. Data protection involves protecting the data in all the three phases.
Data in rest refers to the data saved in hardware media. Data in Transit refers to the data that is traveling via network, usually between Server and Client or between two Azure components. Data in Use refers to the data that is currently being used, usually by CPU/memory.
At the data center level, Microsoft deploys ISO-compliant safeguards.
Microsoft also uses a “Just-In-Time” access policy. This ensures that even Microsoft employees do not have complete access to all resources at all the time. This is specially helpful for auditing.
Azure stores data in two forms – Structured and non-structured. Azure storage is used to store the non-structured data in the form of Blobs, tables, queues and files. Azure SQL is a PaaS offering which is used to store structured data.
Azure Storage does not provide out-of-box encryption for Azure Storage. Instead you can bring your own encryption solutions.
At the application level, you can encrypt data by using the SDKs provided by on-premise Active Directory Rights Management Services (AD RMS) or Azure Rights Management Services (RMS).
At the platform level, you can use Azure StorSimple, which provides primary storage, archive and disaster recovery. When configuring StorSimple, you can specify a data-at-rest
encryption key for data encryption. StorSimple uses AES-256 with Cipher Block Chaining (CBC), which is the strongest commercially available encryption.
At the system level, you can use Windows features such as Encrypting File System (EFS), Bit-locker drive encryption etc.,
Azure provides an Import/Export service by which you can transmit your data to Azure by shipping physical data drives. Bit-locker is mandatory when you are using this service. While Importing, you have to enable Bit-locker before sending the data drives to Azure. And the bit-locker key is transmitted separately. While Exporting, you need to send drives to Azure and then encrypt the data before shipping the data back.
We have two options, First one is the Azure SQL which is a PaaS offering. Because database instances are managed by Azure, we do not have to worry about database availability or low-level data protection. Second one is your own SQL Server instance on top of Azure VM.
SQL Server Transparent Data Encryption (TDE) provides protection for at-rest data by performing real-time I/O encryption and decryption of the data and log files. For a more granular encryption, you can use SQL Server Column-Level Encryption (CLE). CLE ensures that data remains encrypted until it is used.
Implementing effective Access control policies:
Access control ensures that only authorized users can access data. Azure employs multiple levels of access controls over customer data.
First, customer data is segmented by Azure subscriptions so that data from one customer cannot be intentionally or accidentally accessed by another customer. Within a subscription, Azure Storage provides container-level and Blob-level access controls for Blob storage, and table-level and row-level access controls for Table storage. Each Azure Storage account has two associated keys: a primary key and a secondary key. Having two keys means that you can perform planned and unplanned (such as when the primary key is compromised) key rotations as needed.
In addition, Azure Storage also supports URL-based access with Shared Access Signatures (SAS). Using SAS, you can grant direct access to storage entities (containers, Blobs, queues, tables, or table rows) with a specified set of permissions during a specified time frame. For example, when you share a file, instead of sharing your storage account key, you can create an SAS signature with read privilege that allows users to read the specific file within a specified span of time. You don’t need to revoke the access, because the SAS address automatically becomes invalid upon expiration of the predefined time frame.
Azure SQL Database:
Azure SQL Database uses an access security model that is very similar to on-premises SQL Server. Because Azure SQL Database instances are not domain-joined, only standard SQL authentication by user ID and password is supported. For SQL Server instances running on Azure Virtual Machines, they can also authenticate by using Kerberos tokens if the virtual machines (VMs) are domain-joined.
Reference Book: 70-534 Architecting Microsoft Azure Solutions