Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

PowerBI – Coloration conditionnel – Exemple avancé

par | 20 Jan 2023 | ,

Derrière le terme un peu technique « Coloration conditionnel » se cache simplement le fait, dans un dashboard PowerBI d’afficher un changement de couleur dans le champ d’un tableau, en fonction de condition.

En plus des fonctions natives de mise en forme dans PowerBI Desktop, il est possible de creer une mesure (code DAX) , avec des conditions, que l’on va utiliser pour afficher une valeur dans un champ. Et cette valeur peut etre un code couleur.

Dans l’exemple du code ci-dessous, on a une application « MyApp » pour laquelle, dans PowerBI nous avons trois datasets (deux correspondrait par exemple a deux tables de la base de donnée associée a « MyApp », et un troisième qui est une connexion vers un outil qui reference la criticité de mes machines (ex: outil de gestion des asset ou cmdb)):

– MyAppAgents, qui contiens des infos sur les agents de mon application

– MyAppVersions, qui contiens un historique des numeros de version de mon application

–  MyServers qui est donc la table qui liste la criticité des mes serveurs.

Objectif: On veux dans un dashboard, colorer un champ en rouge ou jaune (exemple, le nom du serveur), pour lequel la version ((MyAppAgents[MyApp_agent_version]) serai differente de la dernière version, ET dont le serveur serait un serveur de Production ou de test.

 

<pre class="wp-block-syntaxhighlighter-code">Color_MyApp_agent = 

   VAR Result1 = SELECTEDVALUE(MyAppAgents[MyApp_agent_version])
   VAR Result2 = SELECTEDVALUE(MyAppVersions[MyApp_Last_version_available])
   VAR Result3 = SELECTEDVALUE(MyServers[Server_Criticity])

-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity = "PROD" alors on renvoi "CRITICAL"
   VAR Critical = IF(AND(Result1<>Result2, Result3="PROD"),"CRITICAL")
   
-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity <> "TEST" alors on renvoi "WARNING"  
   VAR Warning = IF(AND(Result1<>Result2, Result3<>"TEST"),"WARNING")
   
-- SI MyApp_agent EST EGALE A MyApp_Last_version_available   
   VAR OK = IF(Result1=Result2,"OK")

   
 -- SELON LE CAS ON RENVOI UN CODE COULEUR DIFFERENT
RETURN
SWITCH(
True(),
 Critical="CRITICAL" , "#FEA19E",
Warning="WARNING" , "#F9FF28",
 OK="OK" , "#96FF93" 
)
</pre>

 

On crée donc une mesure (measure) dans laquelle on va coller le code ci-dessus

Apres validation la mesure apparait dans le dataset ou elle a été crée

On selectionne ensuite le champ que l’on veut colorer puis Conditional formatting/Background color

 

On selectionne Format by « Field Value », et on va venir selectionner notre mesure (Color_MyApp_agent)

 

Apres validation, Les valeurs de la colonne seront formatée selon la condition rencontrée (Les code couleurs ‘#FEA19E‘ peuvent bien sur etre modifié dans le code pour choisir une autre coloration):

 

Azure – Utiliser la localisation GPS avec l’accès conditionnel Azure

par | 30 Déc 2022 |

L’accès conditionnel d’Azure ou Conditional Access (CA) est un service Azure qui permet d’autoriser les connexions vers des applications ou services Azure selon des conditions tels que la plage IP publique d’accès, le type de device ou le niveau de risque de l’utilisateur. Avec la popularisation des VPN, il est difficile de réellement restreindre les connexions depuis un pays donné. Une fonctionnalité récente sortie en 2021 permet dorénavant de demander les coordonnés GPS d’un utilisateur lorsqu’une CA est configurée.

 

Prérequis pour utiliser la localisation GPS avec l’accès conditionnel Azure

  • Chaque utilisateur qui utilise un accès conditionnel doit avoir une licence Azure AD Premium P1
  • Le compte qui configure l’accès conditionnel doit avoir un de ces rôles : Security Administrator, Conditional Access Administrator ou Global Administrator
  • Les utilisateurs doivent avoir l’application Microsoft Authenticator installée et configurée avec leur compte Azure AD

Créer un emplacement nommé basé sur la localisation GPS

Un emplacement nommé ou name location est un groupement d’IP ou de pays qui sera consommé par une CA pour appliquer une restriction d’accès.

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Named locations > + Countries location

3. Dans la blade (fenêtre Azure) qui s’est ouverte :

  • Dans le champs Name choisir un nom à donner à cette named location
  • Dans le deuxième champs dont la valeur par défaut est Determine location by IP address (IPv4 only) choisir Determine location by GPS coordinates

4. Il est possible de cocher l’option Include unknown countries/regions, cela permet d’inclure les plages IP qui n’appartiennent à aucun pays et les IPv6 qui ne sont pas incluses par défaut.

5. Dans cet exemple, on souhaite configurer la named location en France, scroller jusqu’à trouver France et cocher la checkbox associée puis cliquer sur Create

 

Créer un accès conditionnel basé sur la localisation GPS

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Conditional Access > Policies > + New policy

3. Dans le champs Name entrer le nom de la CA puis cliquer successivement sur Conditions > Locations > Configure > Include > Selected locations

4. Dans la blade qui est apparue à droite, entrer le nom de la named location précédemment entrée et cocher la checkox associé puis cliquer sur Select

5. Il est ensuite possible d’utiliser les différentes options pour choisir les éléments qui doivent être bloqués, par exemple :

  • Users or workload identites permet de choisir si la CA doit s’appliquer à l’ensemble des utilisateur ou à un groupe d’utilisateur spécifique
  • Cloud apps or actions permet de choisir l’application Azure à conditionner
  • Grant permet de configurer la CA en tant qu’autorisation ou réfutation

6. Une fois les éléments de configuration de la CA choisis, il est possible de la configurer en Report-only pour ne pas qu’elle s’applique réellement, mais pour pouvoir avoir un aperçu de ses effets au travers des Sign-in logs des utilisateurs.

Module Powershell SecretStore – Exemple avec API Crowdstrike

par | 19 Déc 2022 | , ,

SecretStore est un module Powershell permettant de facilement stocker et gérér des Credentials.

Dans l’exemple ci-dessous nous le mettons en place et l’utilisons pour demander, dans cet exemple, un token d’acces au cloud de l’EDR Crowdstrike.

NB : Le module SecretStore requiert l’installation du module SecretManagement

Comme tout module Powershell, si ils ne peut pas être directement téléchargé en ligne sur un repository avec la commande Install-Module, il est possible de le(s) récupérer sur Github ou encore sur Powershell Galery

(https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretStore)

(https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretManagement)

Une fois les module décompressé et stocké dans un des dossier contenant en standard des modules (ex : «C:\Program Files\WindowsPowerShell\Modules»)

NB : Si le module n’est pas stocké dans un chemin déclaré dans la variable $env:PSModulePath, son chemin complet devra être renseigné lors de l’import. Ceci peut être problématique aussi après l’import, dans le cadre de certaines commandes du module. Pour cela il est préférable qu’il soit stocké dans un chemin reconnu par la variable $env:PSModulePath

NB : Pour qu’un module soit correctement reconnu par Powershell, le nom du dossier le contenant doit être identique au nom du fichier psd1 ou psm1 :

 C:\Program Files\WindowsPowerShell\Modules \microsoft.powershell.secretstore

Dans une fenêtre powershell, exécuter Import-module en spécifiant le chemin d’accès aux fichiers indiqué ci-dessous

*****

Import-module microsoft.powershell.secretmanagement

Import-module microsoft.powershell.secretstore

*****

Par défaut le module SecretStore requiert un password pour accéder a chaque au coffre-fort de mot passe. La commande suivante permet de spécifier que l’authentification ne sera pas demandée , uniquement pour l’utilisation actuel (CurrentUser)

 

Set-SecretStoreConfiguration -Scope CurrentUser -Authentication None -Interaction None

La commande demande un password qui ne sera pas redemandé

La commande suivante permet de créer le coffre-fort (vault). Indiquer un nom explicite pour l’usage de ce coffre. (La commande requiert d’indiquer le module SecretStore)

Register-SecretVault -ModuleName microsoft.powershell.secretstore -Name MyVault

A présent que le coffre est créé, nous allons y stocker les informations requise, dans cet exemple, pour récupérer un token Crowdstrike.

Dans une variable de type hashtable ($ApiClient) On renseigne le Client Id, Le Client Secret, et le Hostname (url de l’api). On ‘range’  ($ApiClient) dans le coffre MYVault. (Set-secret)

$ApiClient = @{
    ClientId     = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    ClientSecret = ' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    Hostname     = 'https://api.eu-1.crowdstrike.com'
}

Set-Secret -Name MyApiClient -Secret $ApiClient -Vault MyVault

On peut tester a présent que le credential peut être récupéré :

Get-Secret -Name MyApiClient -Vault MyVault -AsPlainText

Et dans notre exemple, on peut maintenant récupérer notre token Crowdstrike

Get-Secret -Name MyApiClient -Vault MyVault -AsPlainText | ForEach-Object { Request-FalconToken @_ }

Notre token doit etre valable

$(Test-FalconToken).token

Les cmdlets du module PSFalcon peuvent maintenant être exécutées, par exemple :

Get-FalconHost -All -Detailed

NB : Les modules powershell SecretStore et SecretManagement peuvent même etre supprimé (Remove-Module). Le coffre crée sera toujours accessible par le compte l’ayant crée.

Derniers articles

Catégories

Archives

Auteurs/Autrices