Planning part is also big security issue for many organization. The organizations usually enable the service and give everyone full access which every team member can do anything. Also, creating and applying policies must be considered in planning because wrong configuration or implementing wrong policies will waste money and money.
To take full advantage of Security Center, it is important to understand how different individuals or teams in your organization use the service to meet secure development and operations, monitoring, governance, and incident response needs. The key areas to consider when planning to use Security Center are:
- Security Roles and Access Controls
- Security Policies and Recommendations
- Data Collection and Storage
- Ongoing Security Monitoring
- Incident Response
Let’s start with permission. As you guess, Security Center uses RBAC (Role Based Access Control), whcih provides built-in roles that can be given to your users. We have a health check team which are given only Security Reader access. They can only view Security center which includes recommendations, alerts, policy, and health. However, they can’t make any changes on the environment.
Below is the built-in roles and you find more information in Microsoft documentation (https://docs.microsoft.com/en-us/azure/security-center/security-center-permissions.
Edit security policy
Apply security recommendations for a resource
Dismiss alerts and recommendations
View alerts and recommendations
|Resource Group Owner||—||X||—||X|
|Resource Group Contributor||—||X||—||X|
Now we have a better understanding of permissions and let’s look at what is supported by Azure Security Center.
Basically, Security Center supports Classic and Resource Manager resources such as;
Windows Server 2008 and above
Ubuntu 12.04 and above
Debian 7 and 8
CentOS 6.* and 7.*
RedHat 6.* and 7.*
SUSE 11 SP4 and above
Oracle Linux 6.* and 7.*