CoLabora March 2022 - Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure
•Descargar como PPTX, PDF•
0 recomendaciones•80 vistas
Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure. Azure AD Enterprise Application Azure AD Application Registration https://www.meetup.com/CoLabora/events/284462324/
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a CoLabora March 2022 - Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure
Similar a CoLabora March 2022 - Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure (20)
Más de Peter Selch Dahl
Más de Peter Selch Dahl (9)
Último
Último (20)
CoLabora March 2022 - Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure
- 1. CoLabora User Group Meeting – March 2022 - Improve security posture by implementing new Azure AD Security features for better protection for M365 and Azure Peter Selch Dahl – Azure MVP – I’m ALL Cloud First
- 2. Microsoft MCSA: Cloud Platform - Certified 2018, Microsoft MCSA: Office 365 - Certified 2018, Microsoft MCSE: Cloud Platform and Infrastructure - Certified 2018 Microsoft MCSA: 2016 Windows Server 2016, Microsoft MCSA: 2012 Windows Server 2012, Microsoft MCITP: 2008 Server and Enterprise Administrator, Microsoft MCSA: 2008 Windows Server 2008, Microsoft MCSA/MCSE : 2003 Security, Microsoft MCSA/MCSE : 2000 Security, VMWare Certified Professional VI3/VI4/VI5, CompTIA A+, Network+, EC-Council: Certified Ethical Hacker (CEH v7), And more Peter Selch Dahl Azure MVP Twitter: @PeterSelchDahl www: www.peterdahl.net Blog : http://blog.peterdahl.net
- 3. • You understand admin consent! • You know how to provide API consent for applications • You know how to block end-user consent What’s new since 2018 ;)
- 5. What is Application Consent? Organizational data permissions Applications organizational data permissions application consent admin end user permissions end user admin developer
- 6. What is Application Consent?
- 7. What I will be talking about…. Protecting data!
- 8. Application Consent and Permissions (Bad) Sharing Portal Access’s any user’s SharePoint, then attaches a file as an email sent by the signed in user, to share externally. Developer(s) [internal or external] Tenant SharePoint Data Read items in all site collections (E.g., do something as the app) Admin must consent Exchange Data Send mail as a user (E.g, do something as the user) User Can Consent 1 2 End-User 3 Administrator 4 End-User 5 Administrator Manage consent policies and access over time 6
- 9. What is Application Consent? Users can consent to apps that access personal information only Admins must consent to apps that require broader permissions Admins can consent on behalf of all users in an organization
- 10. App types and permission types App type Permission type Who can consent Effective Permissions Get access on behalf of users Get access as a service Mobile, Web and Single page app Service and Daemon Users can consent for their data Admin can consent for them or for all users Only admin can consent App permission s User permission s App permission s Application permission Delegated permission (user permission)
- 11. Consent of principals @EWUGDK •Application permissions — are permissions given to the application itself. In this scenario, the resource given access to does not have any knowledge of the permissions of the end user. In earlier literature from Microsoft patterns and practices, this model is also referred to as the “trusted subsystem” model where the idea is that the API resource trust the caller system to do the proper authorization of end users. For example, for web applications this has “always” been the model used for calling an SQL server. •Delegated permissions — are permissions that the end-user delegates to the application for access to the user’s data/resources. For instance, the application can be given access to the end user’s mailbox. This is analogue to what in earlier literature is referred to as “impersonation”, meaning that the application impersonates the end user when calling the API resource. The application acts on behalf of the end user, for instance a third party application might post on your Twitter timeline.
- 12. Consent of principals @EWUGDK •Application permissions — are permissions given to the application itself. In this scenario, the resource given access to does not have any knowledge of the permissions of the end user. In earlier literature from Microsoft patterns and practices, this model is also referred to as the “trusted subsystem” model where the idea is that the API resource trust the caller system to do the proper authorization of end users. For example, for web applications this has “always” been the model used for calling an SQL server.
- 13. What I will be talking about…. KnowBe4's Chief Hacking Officer Kevin Mitnick called me with some chilling news. A white hat hacker friend of his developed a working "ransomcloud" strain, which encrypts cloud email accounts like Office 365 in real-time. My first thought was :"Holy $#!+". https://community.spiceworks.com/topic/2104688-heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video
- 14. What I will be talking about…. https://community.spiceworks.com/topic/2104688-heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video
- 15. Multi-Tenant / Single-Tenant Consent
- 16. Admin consent workflow @EWUGDK 16 • Users can request access when user consent is disabled • Users can request access when apps request permissions that require admin consent • Gives admins a secure way to receive and process access requests • Users are notified of admin action https://aka.ms/adminconsentworkflow/
- 18. Conditions Allow access or Block access Actions Enforce MFA per user/per app User, Group, App sensitivity Device state Location User NOTIFICATIONS, ANALYSIS, REMEDIATION, RISK-BASED POLICIES CLOUD APP DISCOVERY PRIVILEGED IDENTITY MANAGEMENT MFA IDENTITY PROTECTION Risk CLOUD-POWERED PROTECTION
- 19. Service principals – Identity Protection
- 20. Service principals – Conditional Access https://techcommunity.microsoft.com/t5/azure-active-directory-identity/extend-the-reach-of-azure-ad-identity-protection-into-workload/ba-p/2365666
- 21. Service principals – Export to SIEM https://techcommunity.microsoft.com/t5/azure-active-directory-identity/extend-the-reach-of-azure-ad-identity-protection-into-workload/ba-p/2365666
- 22. Service principals consent - Refresh Application Access
- 23. Service principals consent - Refresh Application Access Philippe Signoret – PM, Azure AD: https://gist.github.com/psignoret/9d73b00b377002456b24fcb808265c23
- 24. Service principals consent - Refresh https://portal.cloudappsecurity.com/#/app-permissions/ Delegated Access
- 25. Admin consent workflow • Users can request access when user consent is disabled • Users can request access when apps request permissions that require admin consent • Gives admins a secure way to receive and process access requests • Users are notified of admin action https://aka.ms/adminconsentworkflow/
- 26. Service principals monitoring - Refresh
- 28. Notes on V1 (ADAL) vs V2 Endpoint (MSAL) There are some key differences to be aware of with consent on V2: • Support for Dynamic/Incremental consent • New URL paths including separate admin consent endpoint • Applications registered at apps.dev.microsoft.com as opposed to portal.azure.com https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-compare https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-appmodel-v2-overview
- 29. We expose hard choices to developers BOTH MSA AAD Azure Office
- 30. Azure AD Applications • Single tenant application • App for users in a single organization • Admin or user registers app in directory tenant • Sign in at: https://login.windows.net/contoso.com/<protocol> • Multi-tenant application • App for users in multiple organizations • Admin or USER registers app in developer’s directory tenant • Admin configures application to be multi-tenant • Sign in at: https://login.windows.net/common/<protocol> • User prompted to consent based on permissions required by application • Consent registers application in user’s tenant
Notas del editor
- https://docs.microsoft.com/en-us/samples/azure-samples/active-directory-dotnetcore-daemon-v2/ms-identity-daemon/
- gives end users a way to request access to applications that require admin consent. Without an admin consent workflow, a user in a tenant where user consent is disabled will be blocked when they try to access any app that requires permissions to access organizational data. The user sees a generic error message that says they're unauthorized to access the app and they should ask their admin for help. But often, the user doesn't know who to contact, so they either give up or create a new local account in the application. Even when an admin is notified, there isn't always a streamlined process to help the admin grant access and notify their users. The admin consent workflow gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The request is sent via email to admins who have been designated as reviewers. A reviewer takes action on the request, and the user is notified of the action. To approve requests, a reviewer must be a global administrator, cloud application administrator, or application administrator. The reviewer must already have one of these admin roles assigned; simply designating them as a reviewer doesn't elevate their privileges. Select users to review admin consent requests. Select reviewers for this workflow from a set of users that have the global administrator, cloud application administrator, and application administrator roles. Selected users will receive email notifications for requests. Enable or disable email notifications to the reviewers when a request is made. Selected users will receive request expiration reminders. Enable or disable reminder email notifications to the reviewers when a request is about to expire. Consent request expires after (days). Specify how long requests stay valid.
- https://azure.microsoft.com/en-us/blog/managing-azure-secrets-on-github-repositories/
- https://techcommunity.microsoft.com/t5/azure-active-directory-identity/extend-the-reach-of-azure-ad-identity-protection-into-workload/ba-p/2365666
- https://techcommunity.microsoft.com/t5/azure-active-directory-identity/extend-the-reach-of-azure-ad-identity-protection-into-workload/ba-p/2365666
- gives end users a way to request access to applications that require admin consent. Without an admin consent workflow, a user in a tenant where user consent is disabled will be blocked when they try to access any app that requires permissions to access organizational data. The user sees a generic error message that says they're unauthorized to access the app and they should ask their admin for help. But often, the user doesn't know who to contact, so they either give up or create a new local account in the application. Even when an admin is notified, there isn't always a streamlined process to help the admin grant access and notify their users. The admin consent workflow gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, they can send a request for admin approval. The request is sent via email to admins who have been designated as reviewers. A reviewer takes action on the request, and the user is notified of the action. To approve requests, a reviewer must be a global administrator, cloud application administrator, or application administrator. The reviewer must already have one of these admin roles assigned; simply designating them as a reviewer doesn't elevate their privileges. Select users to review admin consent requests. Select reviewers for this workflow from a set of users that have the global administrator, cloud application administrator, and application administrator roles. Selected users will receive email notifications for requests. Enable or disable email notifications to the reviewers when a request is made. Selected users will receive request expiration reminders. Enable or disable reminder email notifications to the reviewers when a request is about to expire. Consent request expires after (days). Specify how long requests stay valid.