Month: January 2017

Azure -Data Protection in Azure

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.

Data Protection

Azure Storage:

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.

SQL Database:

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.

Azure Storage:

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


Azure – Configure a Point-To-Site Connection to a Vnet using Azure Portal

A Point-To-Site(P2S) configuration lets you create a secure connection from an individual client computer to a virtual network. A P2S connection is useful when you want to connect to your VNET from a remote location, such as from home or a conference, or when you only have few clients that need to connect to virtual network.

P2S connections do not require a VPN device or a public-facing IP address to work. A VPN connection is established by starting the connection from client computer.

Below are the operating systems that we can use with Point-To-Site:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)

  • Windows 8 (32-bit and 64-bit)

  • Windows 8.1 (32-bit and 64-bit)

  • Windows Server 2012 (64-bit only)

  • Windows Server 2012 R2 (64-bit only)

  • Windows 10

This blog walks you through creating a Vnet with Point-To-Site connection in the Resource Manager deployment model using the Azure Portal.

This is a 9 step process:

PART 1 – Create Resource Group

PART 2 – Create Virtual Network

PART 3 – Create Virtual Network Gateway

PART 4 – Generate Certificates

PART 5 – Add The Client Address Pool

PART 6 – Upload the Root certificate .cer file

PART 7 – Download and install the VPN client configuration package

PART 8 – Connect To Azure

PART 9 – Verify your connection

Below are the values that we will use to configure the Point-To-Site connection:

  • Name: VNet1

  • Address space:
    For this example, we use only one address space. You can have more than one address space for your VNet.

  • Subnet name: FrontEnd

  • Subnet address range:

  • Subscription: If you have more than one subscription, verify that you are using the correct one.

  • Resource Group: TestRG

  • Location: East US

  • GatewaySubnet:

  • Virtual network gateway name: VNet1GW

  • Gateway type: VPN

  • VPN type: Route-based

  • Public IP address: VNet1GWpip

  • Connection type: Point-to-site

  • Client address pool:
    VPN clients that connect to the VNet using this Point-to-Site connection receive an IP address from the client address pool.

PART 1 – Create Resource Group

Click on “Resource Groups” from the side pane >> Click on “ADD” >> Fill in the details >> Click on “CREATE”


PART 2 – Create Virtual Network

  1. Click on “New” >> Search for “Virtual Network” >> Click on “Virtual Network” from the results.


  2. Select “Resource Manager” in the drop down >> Click on “Create”


  3. Fill in the details as below.


Name: Name of your Virtual Network.

Address Space: Address Space of your Virtual Network.

Subnet Name: Name of the default subnet (You can add more subnets later)

Subnet Address Range: The range of the subnet.

Subscription: If you have multiple subscriptions, you can select them from drop down list.

Resource Group: Select the Resource Group that you just created “TestRG”

Location: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will reside.

Add Additional Address Space (Optional)

Click on the Vnet >> under “Settings” click on “Address Space” >> Add the address space that you want to include >> Click on “Save”


Add Additional Subnets (Optional)


Create A Gateway Subnet

Before connecting your virtual network to gateway, we need to first create the gateway subnet for the virtual network to which you want to connect.

  1. Navigate to the virtual network to which you want to connect the gateway. “Vnet1” in our case.

  2. Select the Vnet “Vnet1” >> Under the “Settings” >> select “Subnets” >> In the next pane, click on “+Gateway Subnet” >>

  3. The Name for your subnet will be automatically filled with the value “GatewaySubnet”. This value is required in order for the Azure to recognize the subnet as Gateway Subnet. Fill in the address range that matches your configuration.

    GatewaySubnet: (In our case)

  4. Click “OK” to create the Gateway Subnet.

Specify A DNS Server (Optional)

You can either choose the Azure-DNS (default one) or your own custom DNS for the name resolution.

  1. Click the Virtual Network “Vnet1” >> Under the “Settings” >> Click on “DNS Server”

  2. You can see that we have two options, Select “Custom” if you have your own DNS server.

    But we will go ahead with the default one for our set-up


PART 3 – Create Virtual Network Gateway

Point-To-Site connection require the following settings:

  • Gateway Type: VPN

  • VPN Type: Route-Based

  1. In the Azure portal >> Click on “+” (New) >> Search for “Virtual Network Gateway” from the market place >> Select the “Virtual Network Gateway” from the list. >> Click on “Create” Button.

  2. Provide the Virtual Gateway Name. VNet1GW in our case.


    Name: Virtual Gateway name (Vnet1GW)

    Gateway Type: VPN

    VPN Type: Route-Based

    SKU: Standard

    Virtual Network: The Vnet to which this Gateway has to be attached,

    Public IP Address: Public IP to the Virtual Gateway. This will be dynamically assigned.

    Subscription: Select the correct subscription.

    Resource Group: Select the correct resource group. (TestRG in our case)

    Location: Adjust the location, where your Vnet is located.

  3. Connect this Virtual Gateway to our Virtual Network.


  4. Associate a public IP address to the Virtual Gateway

    Click on the “Public IP Address” >> Click on “Create New” >> Provide a name for your Public IP. >> Click on “OK”


  5. The settings will be validated. Creating a gateway can take upto 45 minutes. You may have to refresh the portal to see the complete status.

  6. After the gateway has been created, you can view the IP assigned to it by looking at the virtual network in the portal. The gateway will appear as a connected device.


PART 4 – Generate Certificates

Certificates are used by Azure to authenticate VPN clients for Point-To-Site VPNs. You export the public certificate data (not the private key) as a Base-64 encoded X.509.cer file from either a root certificate generated by an enterprise certificate solution, or a self signed root certificate. You then import the public certificate data from the root certificate to Azure. Additionally, you need to generate a client certificate from the root certificate for clients. Each client that wants to connect to the virtual network using a P2S connection must have a client certificate installed that was generated from the root certificate.

Create a self-signed certificate

  1. Install the Windows Software Development Kit

    Windows 10 →

    Windows 7 → (.NET 4) → (.NET 3.5 SP1)

  2. After installation, you can find the makecert.exe utility under the path: C:\Program Files (x86)\Windows Kits\10\bin\x64

  3. Create and install a certificate in the Personal certificate store on your computer. The following example creates a corresponding .cer file that you upload to Azure when configuring P2S. Run the following command, as administrator. Replace ARMP2SRootCert and ARMP2SRootCert.cer with the name that you want to use for the certificate.
makecert -sky exchange -r -n "CN=ARMP2SRootCert" -pe -a sha1 -len 2048 -ss My "ARMP2SRootCert.cer"

The certificate will be located in your certificates – Current User\Personal\Certificates.

I am using Windows 7, so the “makecert.exe” is stored in → C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin


cd ‘C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin’

PS C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin> .\makecert.exe -sky exchange -r -n “CN=P2SRootCert” -pe -a sha1 -len 2048 -ss My “P2SRootCert.cer”

Open “Run” and enter certmgr.msc, this will open the Certificate Manager Tool, If you can browse into the “Personal” >> “Certificates”, you can see your self-signed certificate.


Obtain the Public Key

As part of the VPN Gateway configuration for Point-To-Site connections, the public key for the root certificate is uploaded to Azure.

  1. To obtain the .cer file from the certificate, open certmgr.msc. Right click the self-signed root certificate, click “all tasks”, and then click export. This opens the Certificate Export Wizard.
  2. In the Wizard, click Next, select No, do not export the private key,  and then click Next.
  3. On the Export File Format page, select Base-64 encoded X.509 (.CER). Then, click Next.


  4. On the File to Export, Browse to the location to which you want to export the certificate. For File name, name the certificate file. Then click Next.
  5. Click Finish to export the certificate.

You can see that the certificate file is now exported to the destination folder.


Create and install client certificates

Part A – Generate a client certificate from a self-signed certificate

The following steps walk you through one way to generate a client certificate from a self-signed certificate. You may generate multiple client certificates from the same certificate. Each client certificate can then be exported and installed on the client computer.

1. On the same computer that you used to create the self signed certificate, open Powershell / Command prompt as administrator.

2. In this example, “ARMP2SRootCert” refers to the self-signed certificate that you generated.

  • Change “ARMP2SRootCert” to the name of the self-signed root that you are generating the client certificate from.
  • Change ClientCertificateName to the name you want to generate a client certificate to be.

Modify and run the sample to generate a client certificate. If you run the following example without modifying it, the result is a client certificate named ClientCertificateName in your Personal certificate store that was generated from root certificate ARMP2SRootCert.

makecert.exe -n “CN=ClientCertificateName” -pe -sky exchange -m 96 -ss My -in “ARMP2SRootCert” -is my -a sha1
Our Command:
makecert.exe -n “CN=myClientCertificate” -pe -sky exchange -m 96 -ss My -in “P2SRootCert” -is my -a sha1


3. All certificates are stored in your ‘Certificates – Current User\Personal\Certificates’ store on your computer. You can generate as many client certificates as needed based on this procedure.

Part B – Export a Client Certificate

  1. To export a client certificate, open certmgr.msc. Right-click the client certificate that you want to export, click all tasks, and then click export. This opens the Certificate Export Wizard.


  2. In the Wizard, click Next, then select Yes, export the private key, and then click Next.


  3. On the Export File Format page, you can leave the defaults selected. Then click Next.


  4. On the Security page, you must protect the private key. If you select to use a password, make sure to record or remember the password that you set for this certificate. Then click Next.


  5. On the File to Export, Browse to the location to which you want to export the certificate. For File name, name the certificate file. Then click Next.


  6. Click Finish to export the certificate.


Part C – Install a client certificate

Each client that you want to connect to your virtual network by using a Point-to-Site connection must have a client certificate installed. This certificate is in addition to the required VPN configuration package. The following steps walk you through installing the client certificate manually.

  1. Locate and copy the .pfx file to the client computer. On the client computer, double-click the .pfx file to install. Leave the Store Location as Current User, then click Next.


  2. On the File to import page, don’t make any changes. Click Next.


  3. On the Private key protection page, input the password for the certificate if you used one, or verify that the security principal that is installing the certificate is correct, then click Next.


  4. On the Certificate Store page, leave the default location, and then click Next.


  5. Click Finish. On the Security Warning for the certificate installation, click Yes. The certificate is now successfully imported.


PART 5 – Add The Client Address Pool

1. Once the virtual network gateway has been created, navigate to the Settings section of the virtual network gateway blade. In the Settings section, click Point-to-site configuration to open the Configuration blade.

2. Address pool is the pool of IP addresses from which clients that connect will receive an IP address. Add the address pool, and then click Save.
Here I am using as my Address Pool, which is the public IP address of my laptop / network


PART 6 – Upload the Root certificate .cer file

After the gateway has been created, you can upload the .cer file for a trusted root certificate to Azure. You can upload files for up to 20 root certificates. You do not upload the private key for the root certificate to Azure. Once the .cer file is uploaded, Azure uses it to authenticate clients that connect to the virtual network.

  1. Navigate to the Point-to-site configuration blade. You will add the .cer files in the Root certificate section of this blade.
  2. Make sure that you exported the root certificate as a Base-64 encoded X.509 (.cer) file. You need to export it in this format so that you can open the certificate with text editor.
    (Best way to do this is to create a copy of the root certificate to a temp location and change the file type to .txt, so you can easily open the file with notepad)


  3. Open the certificate with a text editor, such as Notepad. Copy only the following section:


  4. Paste the certificate data into the Public Certificate Data section of the portal. Put the name of the certificate in the Name space, and then click Save. You can add up to 20 trusted root certificates.


PART 7 – Download and install the VPN client configuration package

Clients connecting to Azure using P2S must have both a client certificate, and a VPN client configuration package installed. VPN client configuration packages are available for Windows clients.
The VPN client package contains information to configure the VPN client software that is built into Windows. The configuration is specific to the VPN that you want to connect to. The package does not install additional software.

  1. On the Point-to-site configuration blade, click Download VPN client to open the Download VPN client blade.


  2. Select the correct package for your client, then click Download. For 64-bit clients, select AMD64. For 32-bit clients, select x86.
  3. Install the package on the client computer. If you get a SmartScreen popup, click More info, then Run anyway in order to install the package.
    Click on Close, if any antivirus pops-up. Then click on Yes, to continue the installation of VPN Client.



  4. On the client computer, navigate to Network Settings and click VPN. You will see the connection listed. It will show the name of the virtual network that it will connect to and looks similar to this example:


PART 8 – Connect To Azure

  1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may appear that refers to using the certificate. If this happens, click Continue to use elevated privileges.


  2. On the Connection status page, click Connect to start the connection. If you see a Select Certificate screen, verify that the client certificate showing is the one that you want to use to connect. If it is not, use the drop-down arrow to select the correct certificate, and then click OK.




  3. Your connection should now be established.


PART 9 – Verify your connection

  1. To verify that your VPN connection is active, open an elevated command prompt, and run ipconfig/all.
  2. View the results. Notice that the IP address you received is one of the addresses within the Point-to-Site VPN Client Address Pool that you specified in your configuration. The results should be something similar to this: