Depuis le 5 février, un filtre anti-phishing trop zélé d'Exchange Online paralyse les échanges professionnels en bloquant massivement des courriels légitimes en quarantaine.
Cet article Exchange Online : pourquoi vos e-mails importants finissent en quarantaine est apparu en premier sur Linformatique.org.
Une licence vous manque… et aucune autre ne peut être assignée.
Michelin s’est trouvé dans cette situation avec les logiciels Microsoft. En toile de fond, la mise en place d’un nouveau processus d’attribution des licences, basé sur des groupes Active Directory.
Lorsque l’entreprise avait adopté Office 365 il y a une dizaine d’années, l’attribution était directe, via le centre d’administration ou via des scripts PowerShell. Elle reposait sur des bundles de licences correspondant à des profils de travailleurs.
Pour stocker ces profils, il fut décidé d’exploiter les attributs d’extension d’Active Directory – sinon utilisés notamment pour la synchronisation de boîtes Exchange locales. Ces attributs étaient synchronisés vers Azure Active Directory.
Le script principal, exécuté sur site de manière périodique, détectait les nouveaux utilisateurs, lisait les attributs associés et assignait les licences correspondantes.
Dans le cadre des recrutements, les attributs étaient définis par les systèmes RH, dans AD (initialement de façon indirecte, en passant par l’annuaire interne). Dans les autres cas (freelances, mobilité interne, comptes spécifiques…), ils l’étaient via un portail de provisionnement interne.
Ce système présentait des limites. Parmi elles, la complexification progressive du script principal (ajout/modification de profils, altération de la logique métier sous-jacente). Par ailleurs, ce dernier étant planifié et non orienté événements, il existait toujours un décalage vis-à-vis des outils amont, amplifié par l’intervalle de synchronisation de 30 minutes d’AAD Connect.
Cette approche n’empêchait plus globalement pas les admins d’attribuer n’importe quelle licence à un utilisateur, au-delà ce celles dont il était censé bénéficier.
Dans ce contexte, Michelin a entrepris de basculer vers une approche basée sur les groupes, à l’échelle de son locataire (aujourd’hui quelque 120 000 sièges). Il en faisait déjà usage pour quelques services comme Copilot.
L’idée initiale était de créer un groupe dynamique dans AAD pour chaque profil. Le groupe « Knowledge Worker », par exemple, serait défini par la formule (user.extensionAttribute13 – eq « Knowledge Worker »). Chaque groupe se verrait ensuite assigner les licences correspondant au profil. L’ensemble pourrait alors remplacer progressivement les licences assignées directement.
Quelques jours après la mise en production, il fut constaté que l’absence d’un type de licence suffisait à bloquer l’attribution des autres au sein d’un groupe. Un problème non identifié lors des tests… et non documenté, à la connaissance de Michelin.
L’approche « un groupe par profil » fut par conséquent abandonnée, au profit d’un système plus modulaire associant un groupe à chaque combinaison « profil(s) + type de licence ».
Chaque groupe comprend donc une licence et l’ensemble des profils censés en bénéficier. Par exemple, GP-AAD-USR-LICENSE-E1_SDFA, qui associe les profils « Standard » (SD) et « Functional Account » (FA) à la licence Office 365 E1.
Dix profils ont été définis :
| Profils | Licences |
| Production Machine | Microsoft 365 F1 EMS E3 Defender for Endpoint P2 |
| Production Worker | Microsoft 365 F3 Defender for Endpoint P2 |
| Light Knowledge Worker | Office 365 E1 EMS E3 Defender for Endpoint P2 SharePoint Online Plan 2 Office 365 DLP Windows 10/11 Enterprise E3 Audioconférence Teams |
| Standard | Office 365 E1 |
| Functional Account | Office 365 E1 |
| Knowledge Worker | Microsoft 365 E3 Defender for Endpoint P2 Audioconférence Teams |
| E3 Subsidiary | Office 365 E3 |
| E1 Subsidiary | Office 365 E1 |
| VDI External Application | EMS E3 Windows 10/11 Enterprise E3 |
| VDI External Desktop | EMS E3 Windows 10/11 Enterprise E3 Defender for Endpoint P2 |
L’ensemble est en production depuis quelques mois. Reste à traiter certains cas problématiques comme les comptes cloud-only.
Illustration générée par IA
The post Comment Michelin a modernisé la gestion de ses licences Microsoft appeared first on Silicon.fr.
Pour les données sensibles, le SaaS n’est pas admissible, à moins d’apporter ses propres clés de chiffrement.
L’association suisse privatim – qui réunit des autorités de surveillance en matière de protection des données des organes publics – a récemment communiqué cette position. Elle vise plus précisément les solutions de « grands fournisseurs internationaux […], comme […] Microsoft 365 ». Un raisonnement qui tient entre autres à l’existence du CLOUD Act… et aux perspectives d’accès à des données par les autorités américaines sans respect des règles de l’entraide judiciaire internationale.
La plupart des solutions SaaS n’offrent pas encore de véritable chiffrement de bout en bout, fait également remarquer privatim. Qui dénonce aussi une transparence insuffisante des « entreprises opérant à l’échelle mondiale » pour que les autorités suisses puissent vérifier le respect des obligations contractuelles en matière de protection des données. Ce constat, poursuit l’association, vaut autant pour la mise en œuvre de mesures techniques et la gestion des changements, que pour l’engagement et le contrôle des collaborateurs et des sous-traitants.
Microsoft 365 fournit un chiffrement de base au niveau du volume via BitLocker et DKM (Distributed Key Manager, techno côté client qui utilise un ensemble de clés secrètes). Depuis octobre 2023, c’est de l’AES256-CBC par défaut.
La voie principale pour apporter ses propres clés est l’option Customer Key de Purview. Elle fonctionne avec les licences suivantes :
Purview Customer Key s’appuie sur le service Azure Key Vault. Au niveau Standard, les clés – générées dans le coffre-fort ou importées – sont protégées par logiciel. Au niveau Premium, elles sont stockées dans des HSM (modules de sécurité matériels). Il existe une option monolocataire dite Managed HSM.
Autre possibilité : le chiffrement à double clé : une sous le contrôle du client, l’autre stockée dans Azure. Une solution à réserver aux données très sensibles, selon Microsoft. Elle condamne effectivement l’accès à des fonctionnalités comme l’eDiscovery, la recherche et l’indexation, les web apps Office, les règles antimalware/antispam qui exigent une visibilité sur les pièces jointes… et Copilot.
Même avec l’option Customer Key, Microsoft conserve une clé maître (« clé de disponibilité », que le client peut demander à activer en cas de perte de ses propres clés.
Illustration principale © Andrei Kholmov – Shutterstock
The post SaaS et chiffrement : Microsoft 365 ciblé par un appel à la vigilance appeared first on Silicon.fr.
Panne Microsoft en cours ce mercredi, Azure et Microsoft 365 connaissent des accès dégradés, avec une piste DNS évoquée et plus de 11 000 signalements.
Cet article Panne Microsoft sur Azure et Microsoft 365 avec plus de 11 000 signalements est apparu en premier sur Linformatique.org.
Connexion