What To Secure?

There are 5 Area of Interest

Users
Devices
Network
Applications
Data
Users

It's all about Identity and its verification. Microsoft Azure offers natively several tools and services to protect the user accounts, to ensure user identity, safeguard credentials, and detect any malicious login attempts. It is important to make sure, that the Right Person, has the Right Access, to Right Resources for the Right Time Duration.
Identity Governance gives you the ability to manage these configuration, and it contains 3 LifeCycles:

Identity LifeCycle

Azure AD Premium can be coupled with HR applications such as Workday and SuccessFactors for an automated maintenance of user-IDs for both AD DS and Azure AD.

Microsoft Identity Manager can be used ID records from HCM systems such as PeopleSoft or SAP HCM.

Azure AD B2B enables to share Company’s applications/services with guest users and/or external users form any other organizations.

Azure AD Entitlement Management enables to select users (internal and/or external), who is allowed to request access to applications and resources. The access can be set up with an expiration date!

Access LifeCycle

Dynamic Groups membership reduces the administrative overhead of adding and removing users to/from a security group. If any attributes of a user or device change, it evaluates the group memberships and triggers the necessary groups adds or removes.

Azure AD Access Review helps to manage effectively group memberships, applications’ access , and role assignments. Access assignments can be reviewed on a regular basis in form of an automated procedure. The unnecessary access permissions can be removed easily by Resource-Owner.

Azure AD Entitlement Management also enables to create Access-Packages containing users/user groups, application roles, and SharePoint Online roles.

Privileged Access LifeCycle

Azure AD Privileged Identity Management (PIM) provides additional controls to secure access permissions across resources, Azure AD, and other Microsoft Online Services.

Just-In-Time Access (JIT) grant elevated permission for a certain amount of time. When this time has been expired, the elevated permission will be automatically removed. Administrator don’t need elevated permission constantly.

Multi-Factor Authentication (MFA) added another layer of security to achieve elevated permission and include 3 factors: something you aresomething you know, and something you have.

Azure AD Conditional Access is a policy driven access control, that collects signals for making decisions (grant or deny access) and enforce organizational policies. Common signals are: User or group membership,  IP Location information, Device, Application, Real-time and calculated risk detection, and Microsoft Defender for Cloud Apps.

Please notice that services above may not be a complete list of all available services at the given time. You also may want to consider third-party solutions, if they are a better fit for your environment !

Devices

Similar to Users-, Groups-, or Application-Identity, Device-Identity object encompasses a specific set of attributes. These can be utilized for making access or configuration decisions. There are three common scenario for creating and managing a Device-Identity:

Azure AD Registration

It’s about utilization of End-User’s own devices (BYOD). An End-User is able to use his/her own device to access company’s resources. These kind of devices have an Azure AD account, but End-Users  need their own credential (Device local account, or Microsoft account) for sign in on their own devices.

Mobile Device Management tools such as Microsoft Intune or a Third-Party tool can be utilized to enforce company’s policies.

Some key characteristics are:
Device ownership: user or Company, SSO to cloud resources, conditional access via app protection policy and when enrolled into Intune.

Azure AD Joined

It allows you to join devices directly to Azure AD, and it requires an organizational user account for signing in to the device. Access control to resources occurs based on Azure AD account and Conditional Access Policies applied to devices. These devices are able to authenticate On-Prem resources such as File-, and Print-Servers or applications.

Some key characteristics are:
Device ownership: Company, SSO to both cloud-, and On-Prem resources. Active Directory Group Policies  are not supported in Azure AD Join devices.

Hybrid Azure AD Joined Devices

Having an existing On-Prem AD DS, you can benefit from Azure AD functionalities. In this case, devices are domain-joined and registered with your Azure AD. These kind of devices require periodically connection to your On-Prem Domain Controller, otherwise they become unusable. Users need an organizational user account for signing in to the device.

Some key characteristics are:
Device ownership: Company, SSO to both cloud-, and On-Prem resources. Device management via Group Policies, Microsoft Intune.

Network

Network security is about the operation of protecting resources from unauthorized access, as well as utilization of services to allow solely legitimate network traffic.
There are a wide array of security tools and capabilities available on Azure and I'd like to give an overview about some of those topics to be considered.

Azure Networking

Service Endpoints allow you to secure Azure service resources to connect   those only to your Virtual Networks. It also allow you to use private IP   addresses without needing a public IP address on your vNet. Service Endpoints are generally available for several Azure services like: Azure Storage, Azure SQL Database, Azure Key Vault, Azure Service Bus and few more (for a complete list of services and regions please refer to Microsoft Azure documentations).
Service Endpoint Policy can also be utilized for more granular access control to Azure Storage when connecting over Service Endpoints. It allows you to filter egress vNet traffic and data exfiltration to only selected Azure Storage Accounts.

– Azure Private Link
– Network Security Group (NSG)
– Azure Firewall

Network Access control
content
Azure Firewall
content
Secure Remote Access and Cross Connectivity
content
Availability
content
Name Resolution (DNS)
content
DMZ
content
Azure DDoS
content
Azure Front Door / Traffic Manager
content

 

 

Applications
Data

Zero Trust Security

Comprehensive Security in 3 Steps

More and more organizations are moving away from traditional to a modern definition of security. It's because, employees are working from home and they may use their own devices, or because of hybrid Cloud-OnPrem IT infrastructure. Following blog is merely an idea to reflect, how I would approach this topic for a comprehensive design.

 

As far as I'm concerned, there are three major steps to be considered:

1.) The initial step is the definition of "Area of Interests". Before we can talk about tools and services to be used, it's crucial to know, which resources we are talking about. There are two reasons for this step: there are different set of tools for each area, and there are multiple teams involved.

2.) Once there is a well defined separation of "Area of interests" in place, it's way easier to pick out metrics/logs to be collected and monitored.

3.) Maybe the most significant part of a security concept is the definition and creation of procedures for the worst case scenario.

Step 1

What To Secure?

 

 

 

 

Step 2

What To Monitor?

 

 

Step 3

What if ...?

Azure AD Connect

It's all about Identity, Authentication, and Authorization. But one of the most significant aspect of AAD Connect is the seamless access of both, On-Prem and Azure-Cloud resources and services. Using only one UserName/PassWord for all resources, regardless where they are located, helps to improve the end user experience and acceptance.

There are too many documentations for installing and configuring out there, so I don't want to go through those steps one more time. Instead, I would like to point out some considerations and design aspects prior to the installation.

1. Topologies.

The first thing you need to determine is your On-Prem AD-Topology and to select an appropriate Sync-Topology. Followings are the common supported scenarios:

Single forest - Single Azure AD Tenant

Multi forest - Single Azure AD Tenant

- e.g. multiple forest, due to a company acquisition - All forests must be reachable by a single AAD Connect Sync-Server - All user objects must be represented only once in AAD - Each user has only one mailbox 

Mutli forest (separate topology) - Single Azure AD Tenant

No GALSync  between the forests. - Each forest treated as a separate entities or they are operating independently.

Mutli forest (match users/full mash) - Single Azure AD Tenant

- Two-Way trust between forests.  - Users and resources can be located in any forest.  - User's identity across all forests via mail attribute.

Mutli forest - Multi Azure AD Tenant

- When an isolation between Azure AD tenant instances by design is required.  - Users in one AAD instance don't see users in other instances.

Single Forest - Multi Azure AD Tenant

- Isolating domains or OUs for pointing to a separate ADD instance.  - AAD SyncServers need to be configured for filtering. - Users must have separate UPN suffixes.

2. Sign-In Options.

Choosing an accurate authentication method is the next significant design point. It helps end users to sign in to both Azure Cloud, like Office 365, SaaS applications etc. , and On-Prem with the same credential. Depending on  organization's infrastructure and requirements, following methods are available:

- Password Hash Synchronization with Seamless SSO - Pass-Through Authentication with Seamless SSO  - Federated SSO with AD FS - Federation with PingFederate 

2.1 Password Hash Sync

- Same password for On-Prem and Cloud resources - Recommended for all SaaS applications such as Office365  - Only Password hashes are synced and not the Password itself - Password write-back option allows end user to reset their password in AAD - Seamless SSO option works only on Domain-joined devices that are on the company's network.

2.2 Pass-Through authentication

- Users are authenticated against On-Prem Domain Controller - Password-hashes are not stored in AAD - Passwords getting validated in On-Prem AD - No port opening to the internet - Seamless SSO option works only on Domain-joined devices that are on the company's network.

2.3 Using new or existing farm with AD FS

- Users can sign into AAD by using their On-Prem credentials - Access to cloud based services without sign in for domain joined devices on corporate network - you can use existing 3. party Federation provider such as Okta