Búsqueda de sitios web

Uso de PowerShell para administrar políticas de acceso condicional (CA)

Microsoft proporciona muchos métodos para administrar los datos y los usuarios de un inquilino. PowerShell es una poderosa herramienta para administrar recursos, incluidas las políticas de acceso condicional, mediante un conjunto de cmdlets en el módulo AzureAD. En este artículo, revisamos los ocho cmdlets de PowerShell y cómo usarlos.

**Tenga en cuenta que los módulos de PowerShell de AzureAD y AzureADPreview contienen estos cmdlets.

Políticas de PowerShell y CA

Primero, conéctese a Azure Active Directory mediante el módulo AzureAD o AzureADPreview:
Connect-AzureAD

Después de conectarnos, podemos obtener una lista de cmdlets de PowerShell disponibles usando estas dos frases ingeniosas:
Get-Command *conditional*
Get-Command *named*

Combinados obtenemos un total de ocho cmdlets que tratan con políticas de acceso condicional y políticas de ubicación de nombres:
Get-AzureADMSConditionalAccessPolicy
Nueva política de acceso condicional de AzureADMS
Eliminar política de acceso condicional de AzureADMS
Set-AzureADMSConditionalAccessPolicy

Get-AzureADMSNamedLocationPolicy
Nueva-AzureADMSNamedLocationPolicy< br>Remove-AzureADMSNamedLocationPolicy
Set-AzureADMSNamedLocationPolicy

Las políticas de acceso condicional establecen condiciones para determinar las condiciones bajo las cuales los usuarios reciben acceso a las aplicaciones. Estas condiciones pueden consistir en ubicaciones, uno o más usuarios, aplicaciones, plataformas y más.

En los siguientes ejemplos, examinamos estas condiciones para ver qué podemos configurar con PowerShell.

Crear una nueva política de acceso condicional

Un inquilino nuevo o nuevo no tiene políticas de acceso condicional. Para utilizar el acceso condicional, necesitamos crear sus condiciones. Si se requieren ubicaciones con nombre, primero debemos crear la ubicación con nombre. Repasemos este proceso usando un escenario de ejemplo.

Ubicaciones nombradas

Las políticas de acceso condicional pueden contener ubicaciones nombradas que corresponden a ubicaciones físicas en el entorno de una organización. Las ubicaciones con nombre pueden ser ubicaciones físicas con su correspondiente subred/rango de IP o un solo país/un conjunto de países. Podemos utilizar Ubicaciones con nombre para proporcionar una condición que controle dónde se solicita (o no se solicita) a los usuarios que realicen MFA u otras acciones opcionales. Incluido en el módulo Azure AD, vimos que hay cuatro cmdlets de PowerShell para administrar ubicaciones con nombre y ejecutar la gama típica de verbos Obtener, Nuevo, Eliminar y Establecer de PowerShell.

En un Azure AD nuevo o Greenfield, no hay ubicaciones con nombre que puedan usarse mediante acceso condicional y debemos crearlas en Azure AD o con PowerShell. Para crear una nueva política de ubicación con nombre, debemos usar el cmdlet New-AzureADMSNamedLocationPolicy.

Al crear una nueva ubicación con nombre, debemos tener en cuenta un par de cosas:

  • El nombre para mostrar es obligatorio
  • Es necesario elegir un rango de IP o una lista de países, ya que esto determina el tipo de ubicación con nombre que estamos creando.

Para la primera ubicación con nombre, podemos utilizar algunos criterios básicos: oficina de Chicago, rango de IP de 10.25.0.0 con una máscara de subred de 16 bits y marcaremos esta ubicación como una ubicación confiable. También se puede crear una segunda ubicación para una oficina de Nueva York, con un rango de IP de 10.26.0.0 y la misma máscara de subred de 16 bits. Se requiere PowerShell para crear la ubicación con nombre. Observe que hay un objeto MS Graph para la subred IP de la oficina en el siguiente ejemplo.

Ejemplo:
TI quiere una política de acceso condicional para forzar la autenticación multifactor (MFA) para todas las aplicaciones en la nube, a menos que los usuarios accedan a las aplicaciones desde dos ubicaciones. Las ubicaciones son oficinas físicas en Chicago y Nueva York, con subredes de 10.25.0.0/16 y 10.26.0.0/16, respectivamente. Primero crearemos las dos ubicaciones con nombre usando New-AzureADMSNamedLocationPolicy y luego crearemos una nueva política de CA usando New-AzureADMSConditionalAccessPolicy para hacer referencia a las ubicaciones:
$CHISubnet=Nuevo objeto -TypeName Microsoft.Open.MSGraph.Model.IpRange
$CHISubnet.cidrAddress='10.25.0.0/16'
Nueva-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName 'Chicago Office' -IsTrusted $True -IpRanges $CHISubnet
$NYSubnet=New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$NYSubnet.cidrAddress='10.26.0.0/16'
New-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName 'New York Office' -IsTrusted $True -IpRanges $NYSubnet

Podemos validar las propiedades de las ubicaciones con el cmdlet Get-AzureADMSNamedLocationPolicy, que debemos hacer antes de continuar:

** Para ser justos, el mismo resultado también se genera al crear una ubicación con nombre, pero lo anterior ilustra lo que se puede ver con la parte Get-* de los cmdlets de ubicación con nombre.

Una vez creadas las ubicaciones con nombre, ahora podemos usarlas en una política de CA (tenga en cuenta que hay muchas configuraciones para una política de CA). Primero, necesitamos un objeto que contenga la condición de la política de CA (aplicaciones, usuarios y ubicaciones). El desglose de las condiciones disponibles en ConditionalAccessConditionSet se define aquí.
$CAConditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$CAConditions.Applications=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition
$CAConditions.Applications.IncludeApplications='Todos'

En esta sección, definimos los usuarios a los que aplicar la Política de acceso condicional (Users.ExcludeUsers), así como cualquier usuario que deseemos excluir (Users.ExcludeUsers). En este caso, el usuario excluido es una cuenta Break Glass que está excluida de cualquier política que definamos y se muestra a continuación como el GUID del objeto para el usuario en Azure AD. Los GUID de las ubicaciones se encuentran en el campo ID, como se ve en la Figura 2.
$CAConditions.Users=New-Object -TypeName Microsoft.Open.MSGraph .Model.ConditionalAccessUserCondition
$CAConditions.Users.IncludeUsers='Todos'
$CAConditions.Users.ExcludeUsers='22561a78-a72e-4d39-898d-cd7c57c84ca6'
$CAConditions.Locations=Nuevo-Objeto -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$CAConditions.Locations.IncludeLocations='0743ff81-cea0-40d2-b0f0-4028cdc1c61a','0f0c7a7f-4863-480e-9b71-d8f9eddb37e4′

** Tenga cuidado con las aplicaciones 'Todas' Y "Todas" las configuraciones de usuario, ya que esto también afecta el portal de Azure AD, lo que significa que podría quedar bloqueado del portal y no poder cambiar sus políticas de CA. Asegúrese de tener una cuenta Break Glass creada y excluida como se muestra aquí [Users.ExcludeUsers]. Para obtener más información sobre Break Glass Accounts, consulte esta publicación de blog.

A continuación, debemos configurar los controles de concesión para el requisito de MFA. Al igual que las condiciones anteriores, también necesitamos un objeto Graph y proporcionamos un operador ('Or'/'And'), así como el control, en nuestro caso MFA:
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“O ”
$CAControls.BuiltInControls=“Mfa”

** Puede encontrar una lista de controles incorporados disponibles aquí.

Resumen de la configuración de la política:

  • Se aplica a todas las aplicaciones en la nube
  • Aplicado a todos los usuarios de Azure AD
  • Excluido de aplicar a una cuenta
  • Aplica MFA para estos usuarios y estas aplicaciones.
  • Dos nombres de ubicaciones incluidas, donde no se aplicará la MFA

Ahora tenemos nuestro objeto $CAConditions y el objeto $CAControls completos con la configuración requerida y podemos usarlos para crear una Política de CA según nuestros requisitos iniciales:
Nuevo -AzureADMSConditionalAccessPolicy -DisplayName “CloudApps-MFA-CorpWide” -Estado “Habilitado” -Condiciones $CAConditions -GrantControls $CAControls

Id              : cb14d13f-6ecb-4113-b684-cb6ace507edd
DisplayName     : CloudApps-MFA-CorpWide
State           : enabled
Conditions      : class ConditionalAccessConditionSet {
                    Applications: class ConditionalAccessApplicationCondition {
                    IncludeApplications: System.Collections.Generic.List`1[System.String]
                    ExcludeApplications: System.Collections.Generic.List`1[System.String]
                    IncludeUserActions: System.Collections.Generic.List`1[System.String]
                    IncludeProtectionLevels:
                  }

                    Users: class ConditionalAccessUserCondition {
                    IncludeUsers: System.Collections.Generic.List`1[System.String]
                    ExcludeUsers: System.Collections.Generic.List`1[System.String]
                    IncludeGroups: System.Collections.Generic.List`1[System.String]
                    ExcludeGroups: System.Collections.Generic.List`1[System.String]
                    IncludeRoles: System.Collections.Generic.List`1[System.String]
                    ExcludeRoles: System.Collections.Generic.List`1[System.String]
                  }

                    Platforms:
                    Locations: class ConditionalAccessLocationCondition {
                    IncludeLocations: System.Collections.Generic.List`1[System.String]
                    ExcludeLocations: System.Collections.Generic.List`1[System.String]
                  }

                    UserRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    SignInRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    ClientAppTypes: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessClientApp]
                    Devices:
                  }

GrantControls   : class ConditionalAccessGrantControls {
                    _Operator: OR
                    BuiltInControls: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControl]
                    CustomAuthenticationFactors: System.Collections.Generic.List`1[System.String]
                    TermsOfUse: System.Collections.Generic.List`1[System.String]
                  }

SessionControls :
Figure: Output from New-AzureADMSConditionalAccessPolicy cmdlet.

Desafortunadamente, todas las configuraciones implementadas para esta Política de CA están ofuscadas por "System.Collections", ya que las propiedades contienen conjuntos de datos complejos. Para validar la configuración de la política de CA, debemos separar cada condición para ver qué está presente. Las Aplicaciones, los Usuarios y las Ubicaciones son todas subpropiedades de la propiedad Condiciones en una Política de CA; por lo tanto, podemos dividir cada una de estas secciones de la siguiente manera:
((Get-AzureADMSConditionalAccessPolicy).Conditions).Applications

IncludeApplications ExcludeApplications IncludeUserActions IncludeProtectionLevels
------------------- ------------------- ------------------ -----------------------
{All}               {}                  {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Users

IncludeUsers  : {All}
 ExcludeUsers  : {22561a78-a72e-4d39-898d-cd7c57c84ca6}
 IncludeGroups : {}
 ExcludeGroups : {}
 IncludeRoles  : {}
 ExcludeRoles  : {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations                                                             ExcludeLocations
----------------                                                             ----------------
{0743ff81-cea0-40d2-b0f0-4028cdc1c61a, 0f0c7a7f-4863-480e-9b71-d8f9eddb37e4} {}

En todos los casos, las Aplicaciones, Usuarios y Ubicaciones se enumeran en las Políticas de Acceso Condicional como ObjectIds. Si se generara un informe para la administración, se necesitarían consultas adicionales de PowerShell para convertir estos valores en nombres. Convertir los ObjectIds en nombres también ayudaría con la verificación o documentación/auditoría de las políticas de CA.

Modificación de una política de acceso condicional existente

Ahora que contamos con una política de CA, podemos usar PowerShell para actualizar aplicaciones, usuarios, ubicaciones y controles, así como otros elementos no configurados como plataformas y riesgo de inicio de sesión.

Cambiar la aplicación de una política de CA
Un cambio que podría implementarse es cambiar el estado de la política de CA. Las políticas de CA tienen tres estados: EnabledForReportingButNotEnforced, Enabled y Disabled. Por ejemplo, si existe una nueva política de CA y se solicita a los usuarios MFA cuando se encuentran dentro de una ubicación corporativa, entonces la política podría deshabilitarse o configurarse para informar solo hasta que se resuelva el problema:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -State Disabled
Set -AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -State EnabledForReportingButNotEnforced

Con la política efectivamente deshabilitada, TI ahora puede realizar cambios en la política, validarlos y luego volver a habilitarla:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -State Enabled

Cambio de controles de políticas de CA
En el ejemplo anterior, existe un requisito para un mensaje de MFA cuando usando una aplicación en la nube y conectándose desde fuera de las dos ubicaciones designadas. Estos controles también se pueden ajustar si se necesitan requisitos de seguridad adicionales o posibles alternativas (Azure AD Joined/Compliance). Los controles de las políticas de CA también se pueden combinar (Y) frente al control (O) que estaba en el ejemplo anterior.

Por ejemplo, si queremos agregar que cuando un usuario accede a una aplicación en la nube, mientras es externa, debe hacerlo desde un dispositivo compatible Y se le debe solicitar MFA, podemos hacerlo creando un nuevo objeto de Control y luego aplicar esto a la política de CA existente. Un dispositivo compatible es un dispositivo que cumple con una lista específica de criterios predefinidos como el nivel de versión del sistema operativo, sin jailbreak, etc. Primero, los controles:
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“AND”
$CAControls.BuiltInControls=“Mfa”,”CompliantDevice”

Observe que tenemos un operador AND, que declara que ambos controles deben ser verdaderos. Además, es de destacar que los controles configurados son MFA y un dispositivo compatible. Luego, estos controles se aplican a una política de CA existente, sobrescribiendo cualquier configuración existente:
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163s - Controles de concesión $CAControls

Antes :

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse
 
 OR        {Mfa}           {}                          {}

Después :

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse 

AND        {Mfa, CompliantDevice} {}                   {}

Ahora podemos colocar esto en una sola línea como esta:
Remove-AzureADMSConditionalAccessPolicy -PolicyId 7ac2fcee-d5bd-4003-ad10-5dfa838417da

No se proporciona ningún mensaje, así que tenga cuidado con la eliminación de políticas de CA.

Ubicaciones nombradas

Como se mencionó anteriormente, las políticas de acceso condicional utilizan el concepto de ubicaciones nombradas para corresponder a ubicaciones físicas en el entorno de una organización. Podemos usar Get-AzureADMSNamedLocationPolicy para comparar lo que se muestra en PowerShell y lo que se muestra en el portal de Azure AD para ubicaciones con nombre. Esto es útil para validar una configuración y comprender cualquier diferencia entre las dos pantallas:

Modificar la ubicación con nombre existente

Las organizaciones cambian con el tiempo, lo que podría significar que se necesiten cambios para las ubicaciones nombradas. Por ejemplo, es posible que necesite cambiar el nombre de las ubicaciones, agregar subredes, eliminar subredes, marcarlas como confiables o eliminar la confianza. Todos estos cambios se pueden realizar con el cmdlet Set-AzureADMSNamedLocationPolicy. Veamos qué se necesita para realizar cada uno de estos cambios:

Cambiar ubicación con nombre 'Nombre'
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -DisplayName 'Chicago Loop Office'
Cambiar rango de IP
$ipRanges=New-Object -TypeName Microsoft.Open .MSGraph.Model.IpRange
$ipRanges.cidrAddress='10.25.0.0/16'
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IpRanges $ipRanges -OdataType “#microsoft.graph.ipNamedLocation”
<Confiable
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $False
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $True

Eliminar una ubicación con nombre

Cuando las oficinas cierran o ya no son necesarias para una Política de acceso condicional, las Ubicaciones designadas se pueden eliminar si así se desea. Dejar atrás las ubicaciones nombradas no crea un riesgo de seguridad. Primero debemos determinar si existen políticas de acceso condicional que contengan la ubicación. Podemos seleccionarlos de la propiedad Condiciones de la Política de CA y observar la subpropiedad Ubicaciones, que almacena la ubicación como System.Collections.Generic.List:

Locations: class ConditionalAccessLocationCondition {
IncludeLocations: System.Collections.Generic.List`1[System.String] 
ExcludeLocations: System.Collections.Generic.List`1[System.String]

Podemos revelar el GUID:
((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations ExcludeLocations
---------------- ----------------
{088f361c-4103-43e1-a11d-0394018ab62b} {}

Supongamos que necesitamos eliminar nuestra oficina de Chicago, que es una ubicación designada:

OdataType : #microsoft.graph.ipNamedLocation
Id : 088f361c-4103-43e1-a11d-0394018ab62b
DisplayName : Chicago Office
IpRanges : {class IpRange {
CidrAddress: 10.25.0.0/16
}
}
IsTrusted : True
CountriesAndRegions :
IncludeUnknownCountriesAndRegions :

El valor 'Id' es lo que podemos usar para hacer coincidir el valor Locations.IncludeLocations en la CA. Para encontrar cualquier política de CA con esta ubicación con nombre, debemos hacer coincidir el valor de esta manera:
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Donde {$_ .DisplayName -eq 'Chicago office'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach ($CAPolicy in $CAPolicies) {
If ($OldNamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
Write-Host “Política de CA $ ($CAPolicy.Id) contiene la ubicación nombrada.”
}
}

Es posible que tengamos solo una ubicación o varias ubicaciones, pero se mostrarán todas las entradas coincidentes:
La política de CA 4e7dac6d-d471-483f-9677-46407acaa3f5 contiene la ubicación nombrada.
Podemos decidir eliminar la política o simplemente eliminar la ubicación nombrada. Si la ubicación nombrada es la única, entonces necesitaremos reemplazarla para mantener la política de CA. Para este ejemplo, reemplazaremos la ubicación con otra Ubicación con nombre. Primero, busque cualquier ubicación con nombre que no sea de Chicago Office:
Get-AzureADMSNamedLocationPolicy | Donde {$_.DisplayName -ne 'Oficina de Chicago'} | ft DisplayName,Id

DisplayName Id
----------- --
New York Office 0fae649d-a695-4761-9a83-cd20a96d0739

Luego usamos el ID de esta ubicación para reemplazar el que necesitamos eliminar:
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where {$_.DisplayName -eq 'Oficina de Chicago'}).Id
$NewNamedLocationId=(Get-AzureADMSNamedLocationPolicy | Donde {$_.DisplayName -eq ' LA Office Office'}).Id
$conditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$conditions.Locations=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$conditions.Locations.IncludeLocations=“$NewNamedLocationId”
Foreach ($CAPolicy en $CAPolicies) {
If ($OldNamedLocationId-eq ((($CAPolicy).Conditions).Locations).IncludeLocations) {
Set-AzureADMSConditionalAccessPolicy -PolicyId $ ($CAPolicy.ID) -Condiciones $Condiciones
< span class="crayon-inline lang:decodificación predeterminada:true">}
}

Ahora volvemos a ejecutar el mismo bloque de código que ejecutamos para encontrar las políticas de CA con la ubicación nombrada:
$NamedLocationId=(Get-AzureADMSNamedLocationPolicy | Where { $_.DisplayName -eq 'Chicago office'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach ($CAPolicy en $CAPolicies) {
If ( $NamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
Write-Host “Política de CA y #36 ($CAPolicy.ID) contiene la ubicación nombrada.”
}
}

Remove-AzureADMSNamedLocationPolicy -PolicyId $OldNamedLocationId

**Consejo: asegúrese de eliminar una ubicación con nombre de una política de acceso condicional
Si intentamos eliminar una ubicación con nombre que está definida en una política de acceso condicional, se genera un error. Esto se debe a que la ubicación designada está adjunta a la política de acceso condicional y debe eliminarse primero.

Pensamientos finales

En el artículo, podemos ver que Microsoft proporciona un conjunto de cmdlets de PowerShell que brindan un punto de acceso conveniente a las políticas de acceso condicional. Estas políticas de CA se pueden crear, modificar e incluso eliminar como con estos cmdlets. También tenemos cmdlets para crear ubicaciones con nombre, que, a su vez, pueden ser utilizadas por las políticas de acceso condicional. Los usos potenciales de estos cmdlets abarcan desde la creación y administración de políticas de CA hasta la documentación y auditoría de políticas para el personal/consultores de seguridad que necesitan verificar la postura de seguridad de una organización. Asegúrese de leer los enlaces de documentación proporcionados en este artículo, así como Obtener ayuda para los cmdlets, para obtener orientación sobre los valores que se utilizarán para las distintas partes móviles de una política: ubicaciones, plataformas, controles de concesión, controles de sesión y más.

Artículos relacionados