AWS security groups equivalent in azure - azure

what is the AWS security groups equivalent in azure
if there is any in azure is this only for the PaaS services or also for IaaS ?

According to Amazon EC2 Documentation, a security group is just a single point for firewall settings applied to a given instance:
A security group acts as a firewall that controls the traffic allowed
to reach one or more instances. When you launch an instance, you
assign it one or more security groups. You add rules to each security
group that control traffic for the instance.
In Windows Azure you have to set these rules on a per-instance or per-service basis, there is no way to define some rules and apply them automatically to all instances.
But you can use PowerShell cmdlets for automating this task for your services.
Firewall rules apply mostly for PaaS: for your web/worker role services and for SQL Azure. In case of IaaS there are two sides: your VM with custom software firewall (depending upon your OS etc.) and the endpoints you create and manage in Azure Portal that relay in- and outbound traffic to your VM.

Azure Network security groups and other related improvements were announced today:
http://weblogs.asp.net/scottgu/azure-new-marketplace-network-improvements-new-batch-service-automation-service-more

Network Security group in Azure is the option you are looking for. But there is no option to create it directly. But can be created while creating Virtual Machines and can be associated with multiple Virtual Machines. For more detail,
http://tehcbase.com/aws-security-group-equivalent-in-microsoft-azure/

Related

Segmentation of Azure Subnet for applications

We manage big environments inside Azure with multiple customers, we are redesigning it and in it we wanted to manage traffic within multiple common subnets like app, web and db subnets.
So essentially no two different application inside any common subnet like db cannot communicate with each other.
By default, resources in the different subnets from the same VNet could communicate with each other. So you need to use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network or subnet.
Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. To learn more, see Application security groups.
For PaaS like Azure app service or Azure SQL database, you could use VNet Integration to access VNet resources in a private network or use virtual network service endpoints and rules for servers in Azure SQL Database.
For more information, you may know:
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-dmz
https://learn.microsoft.com/en-us/azure/networking/networking-overview

Azure AADDS multi region

Need some pointers on how one could achieve "true" multi region setup for AADDS.
As per Microsoft's documentation, AADDS is "designed" to be "single regioned". Although it provides some (arguably) redundancy by spinning up essentially 2 managed domain controllers, it does not take into account performance.
Microsoft recommends (and there isn't really any other way to do this) setting up VPN's or VNET peering in order to access your AADDS from other regions, but this has huge impact over performance, and also over actual redundancy (HA designs should be multi region imo, and AADDS should be HA).
We're deploying Windows VM's in (at the time of writing this question) 10 regions, with AADDS in West Europe. We're seeing huge penalties for our apps that require/rely on LDAP ( >10s in some regions) for even the most basic LDAP queries with quite the small return payload.
Was hoping someone figured out a way to mirror/cache AADDS in a new region, like maybe adding a new worker DC or some black magic, so that VMs and services would connect more locally?
Cheers!
Azure AADDS Multi-Region Support is already a requested feature and is under works currently. However, there is no ETA to share at the moment. You can follow What's new in Azure Active Directory? for updates.
The only option to achieve Geo-redundancy is by deploying ADDS across multiple regions via IaaS VMs, Vnet pairing, and VPN gateways.
Also, for high availability, each Azure AD Domain Services managed domain includes two domain controllers. You don't manage or connect to these domain controllers, they're part of the managed service. If you deploy Azure AD Domain Services into a region that supports Availability Zones, the domain controllers are distributed across zones. In regions that don't support Availability Zones, the domain controllers are distributed across Availability Sets. You have no configuration options or management control over this distribution.
According to Azure AADDS FAQ documentation, they do support a fail-over to another geo location.
You can follow this tutorial page in order to create a replica set for your AADDS deployment.

Azure SQL Server Add Virtual Network

Im trying to Add existing virtual network on the screenshot above in Azure, but when I select the Subscription, the virtual network I want to connect to does not show up.
I had a google but couldn't find much to help, can anyone help me understand why my azure vnet cannot be attached at the moment and what needs to be changed on it to allow me to add it?
Virtual Network Rule has some limitations, you need to make your environment does not contain any of the following:
You can only add virtual network which has the same geographic region with your Azure logical SQL server. For example, if my logical SQL server is in Southeast Asia but my virtual network in East US then I will not be able to see it listed when adding a rule.
Rule can only be applied with Azure Resource Manager.
Rules cannot be applied with S2S VPN or ExpressRoute.
Moreover, to fully utilize virtual network rule, you need to also enable Microsoft.SQL service endpoint on your subnet. Click Service endpoints > Add. Choose service and subnet you want to enable service endpoint. Currently (as of this answer) only Storage and Azure SQL are available. Note that this is not actually required to do here, when adding existing virtual network (from logical server) you are given an option to enable service endpoint.

How to add endpoint mapping to Azure IaaS VMs (new resource manager) via Portal?

Current guidelines to add an Endpoint mapping are way too complicated compared to the classic VMs model.
Is this the only way now to simply map a public port to an internal port?
https://azure.microsoft.com/pt-pt/documentation/articles/load-balancer-arm-powershell/
It's not the ultimate way to configure endpoints on IaaS VMs that use the ARM model. Actually - please note that it may change at the discretion of MS - each VM you create using the new portal will come by default with a network security group (NSG) with the same name as the VM, that you'll be able to search for later in the portal.
Then, you'll be able to edit those NSG to make them compliant with your requirements.

Secure RDP and other endpoints in Azure

So we are starting to move to the cloud and our biggest concern is security, as it should be. The thing that I am not sure about is how to secure the end points from public (interent) access? Is this even possible or is there something else we can do to keep the environments in Azure out of the public eye?
This question is likely better suited to server fault. But until then...
In Azure IaaS V1, you can specify IP based ACLs (access control lists) to restrict inbound traffic.
In both IaaS v2, you can leverage NSG (network security groups) to help restriction trick into and out of specific VMs or virtual network sub-nets.
If you are using Azure Express Route (a leased line into an Azure facility), the VMs can be addressed directly from within the virtual network connection and don't need to have publically exposed endpoint.
Then there's also all the usual options such as securing the connections on the VMs themselves. :)
If you are using Azure Resource Groups along with your VMs (which is available on the new portal) you cannot use endpoints because it's not available there, so you should do the following to open up the HTTP port or ANY other port:
(Sign in to your account on the new portal)
1- Select the VM that you want to manage ports on.
2- In settings, click on Network Interfaces and select your network.
3- Go to Network Security Group and select your group.
4- Add Inbound or Outbound security rules depending on what you need.

Resources