Microsoft - SC-100: Microsoft Cybersecurity Architect

Sample Questions

Explanation:

Azure Storage uses service-side encryption (SSE) to automatically encrypt your data when it's persisted to the cloud. Azure Storage encryption protects your data and helps you meet your organizational security and compliance commitments.

By default, a storage account is encrypted with a key that is scoped to the entire storage account. Encryption scopes for Blob storage enable you to manage encryption with a key that is scoped to a blob container or an individual blob. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers. Encryption scopes can use either Microsoft-managed keys or customer-managed keys.

All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share. Encryption at rest applies to both the SMB and NFS protocols.

References:

Azure Storage encryption for data at rest

Encryption scopes for Blob storage

SMB Azure file shares

• Prevent the deletion of backups and the vault used to store the backups.
• Prevent privilege escalation attacks against the backup solution.
• Prevent the modification of the backup retention period.

Explanation:

Azure Files shares can be backed up to a Recovery Services vault but not to a Backup vault.

Immutable vault can help you protect your backup data by blocking any operations that could lead to loss of recovery points. Further, you can lock the Immutable vault setting to make it irreversible and use WORM (write once read many) storage for backups to prevent any malicious actors from disabling immutability and deleting backups.

References:

Immutable vault for Azure Backup

Manage Azure Backup Immutable vault operations

Explanation:

The Application Gateway Ingress Controller (AGIC) is a Kubernetes application, which makes it possible for Azure Kubernetes Service (AKS) customers to leverage Azure's native Application Gateway L7 load-balancer to expose cloud software to the Internet. AGIC monitors the Kubernetes cluster it's hosted on and continuously updates an Application Gateway, so that selected services are exposed to the Internet.

The Ingress Controller runs in its own pod on the customer’s AKS. AGIC monitors a subset of Kubernetes Resources for changes. The state of the AKS cluster is translated to Application Gateway specific configuration and applied to the Azure Resource Manager (ARM).

Benefits of Application Gateway Ingress Controller

AGIC helps eliminate the need to have another load balancer/public IP address in front of the AKS cluster and avoids multiple hops in your datapath before requests reach the AKS cluster. Application Gateway talks to pods using their private IP address directly and doesn't require NodePort or KubeProxy services. This capability also brings better performance to your deployments.

Ingress Controller is supported exclusively by Standard_v2 and WAF_v2 SKUs, which also enable autoscaling benefits. Application Gateway can react in response to an increase or decrease in traffic load and scale accordingly, without consuming any resources from your AKS cluster.

Using Application Gateway in addition to AGIC also helps protect your AKS cluster by providing TLS policy and Web Application Firewall (WAF) functionality.

Reference: What is Application Gateway Ingress Controller?

• A traffic policy for all Microsoft 365 traffic.
• A linked Conditional Access policy that has the following configurations:
• Applies to all users.
• Performs compliant network checks.
• Allows Microsoft 365 traffic from compliant devices.
• An assignment to all devices.
• An assignment to the remote network associated with Office1.

Explanation:

With the Microsoft profile enabled, Microsoft Entra Internet Access acquires the traffic going to Microsoft services. The Microsoft profile manages the following policy groups:

• Exchange Online
• SharePoint Online and Microsoft OneDrive
• Microsoft Teams
• Microsoft 365 Common and Office Online

Conditional Access policies are created and applied to the traffic forwarding profile in the Conditional Access area of Microsoft Entra ID. For example, you can create a policy that requires compliant devices when users are establishing the network connection for services in the Microsoft traffic profile.

The Global Secure Access client allows organizations control over network traffic at the end-user computing device, giving organizations the ability to route specific traffic profiles through Microsoft Entra Internet Access and Microsoft Entra Private Access. Routing traffic in this method allows for more controls like continuous access evaluation (CAE), device compliance, or multifactor authentication to be required for resource access.

Traffic profiles can be assigned to remote networks, so that the network traffic is forwarded to Global Secure Access without having to install the client on end user devices. As long as the device is behind the customer premises equipment (CPE), the client isn't required. You must create a remote network before you can add it to the profile.

References:

Global Secure Access clients

How to enable and manage the Microsoft traffic forwarding profile

Explanation:

By default, Azure Storage automatically encrypts all data using 256-bit Advanced Encryption Standard encryption (AES 256). It's one of the strongest block ciphers available and is FIPS 140-2 compliant. The platform manages the encryption key, and it forms the first layer of data encryption. This encryption applies to both user and system databases, including the master database.

Enabling Transparent Data Encryption (TDE) can add a second layer of data encryption for dedicated SQL pools. It performs real-time I/O encryption and decryption of database files, transaction logs files, and backups at rest without requiring any changes to the application. By default, it uses AES 256.

By default, TDE protects the database encryption key (DEK) with a built-in server certificate (service managed). There's an option to bring your own key (BYOK) that can be securely stored in Azure Key Vault.

Azure Synapse SQL serverless pool and Apache Spark pool are analytic engines that work directly on Azure Data Lake Gen2 (ALDS Gen2) or Azure Blob Storage. These analytic runtimes don't have any permanent storage and rely on Azure Storage encryption technologies for data protection. By default, Azure Storage encrypts all data using server-side encryption (SSE). It's enabled for all storage types (including ADLS Gen2) and cannot be disabled. SSE encrypts and decrypts data transparently using AES 256.

There are two SSE encryption options:

• Microsoft-managed keys: Microsoft manages every aspect of the encryption key, including key storage, ownership, and rotations. It's entirely transparent to customers.
• Customer-managed keys: In this case, the symmetric key used to encrypt data in Azure Storage is encrypted using a customer-provided key. It supports RSA and RSA-HSM (Hardware Security Modules) keys of sizes 2048, 3072, and 4096. Keys can be securely stored in Azure Key Vault or Azure Key Vault Managed HSM. It provides fine grain access control of the key and its management, including storage, backup, and rotations.

Reference: Azure Synapse Analytics security white paper: Data protection