There’s an exciting movement happening in the world of cloud computing and the rate of adoption by various federal, tribal, and State and local Government organizations. More than ever, customers large and small are looking for ways they can leverage different Microsoft cloud technologies to break free from the chains of maintaining on-premises hardware and storage. The other half to that argument is the ever growing desire to enable a mobile workforce, employees want flexibility and access to their data from locations other than their desktop.
Of course no roads are paved without first carefully planning and mitigating concerns and risks, about said road, or parking garage if that’s a better analogy to your cloud space. There’s no question that security is at the forefront of this transitional period, and rightfully so.
I wanted to outline a few of the huge steps Microsoft has taken in their recently released Azure Government platform.
- Isolation – All aspects of Azure Government’s infrastructure is completely isolated, meaning the physical datacenter, hardware, software, and the network. This includes all physical, logical, and network components of the service.
- Community – Restricted to federal, state, local, tribal, and the Department of Defense, including their service providers.
- Screened Personnel – All operational and support employees are US citizens, who have been through a rigorous background screening process.
- Location of Data – All customer data, content, both in transit and at rest, resides in the Continental United States. This includes all Azure Government infrastructure, i.e. hardware, software, networking etc..
- Business Continuity– Customers can enable geo-replication of data to another datacenter at least 500 miles away to provide business continuity in the event of a disaster.
- East coast region – Location on the east cost due to proximity of Government customers, and another location about 1000 miles west of that.
Certifications? Azure Governments got those too. Microsoft is committed to achieving certifications and accreditation that Government customers often require and request, including: CJIS, FedRAMP, DISA, ECSB, ITAR, HIPAA, IRS 1075, and FDA. For a complete list and more details, see the General Availability of Azure G announcement.
Technical features & practices
There are tons of questions that are to be raised when adopting a foreign technology like managed services, or Infrastructure as a service. Using Azure is no different, often these questions revolve around more technical aspects such as access to control network traffic, Intrusion prevention, role based access controls, and general high availability of the servers and services running in Azure. While it is most certainly true that by design, some security precautions are put into the hands of Microsoft, you do have some controls and features you can leverage to better fit your organizations compliance and security requirements.
Network Security Groups
Network security groups (NSG’s) were announced in November of 2014, and were highly anticipated by those already using the Azure IaaS platform. NSG’s can be assigned to specific subnets within your Azure Virtual Network, to specific groups of VM’S, or even a combination of both. Once grouped, you then have the granularity to configure the access control lists between NSG’s, much like you would on your conventional firewall on-premises. You can see HERE an article I wrote on this feature and how I leverage it in Azure ADFS implementations for use with Office 365. Here’s a screenshot of what the ACL controls look like through PowerShell, which is currently the only method for implementing NSG’s. This feature is available in Azure Government today.
Internal Load Balancers
The ease in which you can create internal load balancers is quite impressive, albeit you still need to use the Azure PowerShell modules to accomplish this task. The importance of this feature is in contrast to the load balanced sets you can create for VM’s in the same Cloud Service, which are automatically assigned a public virtual IP address (VIP). VM’s not in the perimeter of your Azure network, or don’t need to be accessible from the internet, don’t need a publicly routable IP address. You can find out more about internal load balancers and configurations HERE.
Forced Tunneling
Forced Tunneling is when you configure specific VM’s or subnets in your Azure Virtual Network to traverse the site-to-site VPN and on-premises infrastructure for internet bound traffic, as opposed to using the Azure default route straight to the internet. This feature allows for organizations that have such a compliance requirement control over the http/https traffic originating from these servers. Your VPN Gateway must be configured as a dynamic routing gateway to take advantage of this feature, for more information check out the page HERE.
Multi-Factor Authentication
Multi-Factor authentication is built right into the Azure web portal and can be enabled on a per-user basis. This is most typically requested and required for Administrators and Co-Administrators accessing their Azure tenant for operational tasks.
Operational Logs
Logs can be queried based on time-frame and type of action within the Azure portal, additional audit logs can be requested for items not accessible or visible in the portal.
Role Based Access Control
As of right now there is no RBAC in Azure Government, however they are constantly updating the platform with features already implemented in its counterpart, for information about RBAC in Azure, check out this article about Azure Resource Groups HERE.
These are just a few of the items that have been leveraged or asked about by customers evaluating or implementing an Azure solution in their organization, hopefully one or two of them pointed you in the right direction.
Kyle Green 