Azure 解决方案：Azure Active Directory的审计和安全监控

Azure 解决方案：Azure Active Directory的审计和安全监控

51CTO 博客地址：Active Directory作为终端用户提供身份机制，还有很多企业将Azure AD与B2C结合使用，为消费者提供对其服务的访问，并将Azure AD作为一种机制，为运营商提供对基于Azure的服务的安全访问，然而这些企业并没有对Azure AD 配置基本的审计策略，对异常用户活动的监控较少，所以，本文将给大家介绍一下如何审计Azure Active Directory的异常流量和活动以及如何收集数据?首先，我们先介绍一下Azure Active Directory，如下图所示，当用户通过Azure AD身份验证来访问某个服务时，将会有一个针对Azure AD的认证，评估用户是否在指定的租户内或者是否将用户路由到正确的目录租户中，然后再验证组织成员关系和密码，所有身份验证都将被记录，若设置了条件访问策略，也会纳入验证范围，以确定在授权用户访问权限之前设置了什么setting，是否应该阻止用户访问。```html/xml

在Azure Active Directory中有一些不同的审计日志，默认存储在本地Azure AD数据库中，Azure AD登录日志的日志条目如下所示：“userDisplayName”: “Nancy”,“userPrincipalName”: “Nancy0527@contoso.com”,“userId”: “2das4c20-fd85-40c5-a6ac-c88baf8ca396”, (User GUID)“appId”: “2012a258-227b-4e31-a9cf-717495945fc2” (App GUID)“appDisplayName”: “Microsoft Azure PowerShell”, (App Displayed in Azure)“ipAddress”: “8.8.8.8”, (IP Address of the user that tried to sign-in)“clientAppUsed”: “Mobile Apps and Desktop clients”, (Identifies the legacy client used for sign-in activity)“conditionalAccessStatus”: “notApplied”, (If any Conditional Access policies applied)“isInteractive”: true, (Indicates if a sign-in is interactive or not.)“riskDetail”: “hidden”, (Provides the ‘reason’ behind a specific state of a risky user, sign-in or a risk event)“riskLevelAggregated”: “hidden”,“riskLevelDuringSignIn”: “hidden”,“riskState”: “none”,“riskEventTypes”: [],“riskEventTypes_v2”: [],“resourceDisplayName”: “Windows Azure Active Directory”,“resourceId”: “00000002-0000-0000-c000-000000000000”,“status”: { (Sign-in status. Includes the error code and description of the error (in case of a sign-in failure))“errorCode”: 0, (Error code if any, 0 indicates successfull authentication attempt“failureReason”: “Other.”,“additionalDetails”: null},“deviceDetail”: {“deviceId”: “”,“displayName”: “”,“operatingSystem”: “Windows 10”,“browser”: “”,“isCompliant”: false,“isManaged”: false,“trustType”: “”},“location”: {“city”: “Amsterdam”,“state”: “Noord-Holland”,“countryOrRegion”: “NL”,“geoCoordinates”: {“altitude”: null,“latitude”: 52.35,“longitude”: 4.917}},“appliedConditionalAccessPolicies”: [{“id”: “b9a01886-57fe-47af-861b-bc979bcdbb2b”,“displayName”: “Example Policy”,“enforcedGrantControls”: [],“enforcedSessionControls”: [],“result”: “notEnabled”

从上述日志中可以看出一个特定的用户使用Azure Powershell客户端登录到Azure，并且没有应用任何条件访问策略。 **说明：如果你需要导出数据，需要确保定语有Azure AD P1或者P2 License，另外不同的Log source记录不同数据集：** • AuditLogs • SigninLogs • NonInteractiveUserSignInLogs • ServicePrincipalSigninLogs • ManagedIdentitySigninLogs • ProvisioningLogs • ADFSSigninLogs 如果你使用Sentinel将日志移动到Log Analytics，我们还可以创建分析查询，在可疑行为出现时自动触发警报。 **说明：你可以选择将数据导出到Azure Storage Account和Azure Event Hub，比如将定义多个export flow，以便将数据发送到多个Workspace。** 那么，当Azure AD 日志中出现日常行为时，我们应该如何锁定问题呢？ 一旦配置了诊断并准备好了日志数据，那么就可以借助Log Analytics和Azure Sentinel使用Kusto查询来分析数据。 Kusto是一种只读查询语言，但是作为门户的一部分，它还提供了一个非常好的可视化工具。  当然，我们也可以创造不同的规则：Hunting Rules和analytics Rules。 **我通常使用的是Hunting Rules，可以简单的从我们登录中确定登录位置的规则。** ```html/xml SigninLogs | summarize count() by Location

另一个示例是显示对Azure AD的登录尝试失败，错误代码是50126或者50020```html/xmlSigninLogs// 50126 - Invalid username or password, or invalid on-premises username or password.// 50020? - The user doesn't exist in the tenant.| where ResultType in ( "50126" , "50020")| extend OS = DeviceDetail.operatingSystem, Browser = DeviceDetail.browser| extend StatusCode = tostring(Status.errorCode), StatusDetails = tostring(Status.additionalDetails)| extend State = tostring(LocationDetails.state), City = tostring(LocationDetails.city)| summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated), IPAddresses = makeset(IPAddress), DistinctIPCount = dcount(IPAddress), makeset(OS), makeset(Browser), makeset(City), AttemptCount = count() by UserDisplayName, UserPrincipalName, AppDisplayName, ResultType, ResultDescription, StatusCode, StatusDetails, Location, State| extend timestamp = StartTime, AccountCustomEntity = UserPrincipalName| sort by AttemptCount

**第三个示例是查看MFA身份验证尝试失败的用户。** ```html/xml SigninLogs | where TimeGenerated >= ago(31d) | where ResultType == "50074"

第四个示例是查看外部用户和对条件访问策略所做的更改。```html/xmlAuditLogs| where Category == "UserManagement"| where OperationName == "Invite external user" or OperationName == "Redeem external user invite"AuditLogs | where Category == "Policy" |project ActivityDateTime, ActivityDisplayName , TargetResources[0].displayName, InitiatedBy.user.userPrincipalName

上述这些示例对监视Azure AD Active是非常有帮助的，希望大家可以灵活掌握

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。