ARGUS

73 controlli

• ARG.ENT.001 Membri attivi senza accessi da oltre 90 giorni Entra ID Media

  Cosa controlla

  Account membro abilitati il cui ultimo accesso riuscito (interattivo o non interattivo) è più vecchio di 90 giorni, compresi gli account che non hanno mai effettuato l'accesso e sono stati creati più di 90 giorni fa. Usa signInActivity.lastSuccessfulSignInDateTime, con il fallback sull'ultimo tentativo di accesso per l'attività precedente a dicembre 2023.

  Perché conta

  Gli account che nessuno usa mantengono appartenenze ai gruppi, accessi alle app e licenze. Rivederli con regolarità è la base della governance del ciclo di vita delle identità.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.002 Utenti con licenza senza manager o reparto Entra ID Bassa

  Cosa controlla

  Utenti membro abilitati con almeno una licenza e con manager o department vuoto in Microsoft Entra ID (GET /users?$expand=manager). Gli account senza licenza (di servizio, condivisi, di emergenza) non vengono valutati; per gli account con licenza che non sono persone usa le esclusioni globali.

  Perché conta

  Manager e reparto guidano access review, flussi di approvazione, gruppi dinamici, organigramma e le persone che Copilot considera rilevanti. I valori mancanti di solito indicano che il provisioning dall'HR o il processo di ingresso ha saltato un passaggio, e rendono manuale ogni passo di governance successivo.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.003 Gli inviti ai guest sono limitati Entra ID Media

  Cosa controlla

  Legge chi può invitare guest (authorizationPolicy.allowInvitesFrom): none o adminsAndGuestInviters passano; adminsGuestInvitersAndAllMembers (tutti i membri possono invitare) va verificato; everyone (anche i guest possono invitare altri guest) fallisce.

  Perché conta

  Chi può portare persone esterne nel tenant è una decisione di governance. Lasciare che i guest invitino altri guest toglie quella decisione all'organizzazione.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.004 Guest che non hanno mai accettato l'invito (oltre 30 giorni) Entra ID Media

  Cosa controlla

  Account guest il cui externalUserState è ancora PendingAcceptance più di 30 giorni dopo l'invito (externalUserStateChangeDateTime, oppure createdDateTime se non impostato).

  Perché conta

  Gli inviti mai riscattati affollano la directory, sono spesso errori di battitura o collaborazioni abbandonate, e possono essere riscattati più avanti da chiunque controlli la casella di posta.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.005 Guest senza accessi da oltre 90 giorni Entra ID Media

  Cosa controlla

  Account guest abilitati che hanno accettato l'invito ma non accedono da 90 giorni, compresi i guest che non hanno mai effettuato l'accesso e sono stati aggiunti più di 90 giorni fa. I guest in attesa di accettazione sono coperti da ARG.ENT.004.

  Perché conta

  I guest conservano l'accesso a Teams, siti e file anche dopo la fine della collaborazione. Rimuovere i guest inattivi limita ciò che le persone esterne possono ancora raggiungere.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.006 Guest senza sponsor Entra ID Media

  Cosa controlla

  Utenti guest abilitati senza sponsor (GET /users?$expand=sponsors). Gli sponsor sono gli utenti o i gruppi responsabili dell'accesso e delle informazioni del guest; Microsoft Entra imposta chi invita come sponsor dei nuovi inviti, quindi i guest senza sponsor di solito sono stati invitati prima che gli sponsor esistessero, hanno perso uno sponsor che se n'è andato, o sono stati invitati condividendo un file SharePoint (un caso noto in cui lo sponsor non viene impostato). Skipped quando l'account non può leggere gli sponsor.

  Perché conta

  Senza sponsor nessuno risponde del guest: le access review non hanno un revisore e il guest resta anche dopo la fine della collaborazione. Uno sponsor (una persona o, meglio, un gruppo) rende possibili le decisioni sul ciclo di vita del guest.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.007 Almeno 2 account di accesso di emergenza (break-glass) Entra ID Alta

  Cosa controlla

  Cerca gli account di accesso di emergenza: quelli elencati nel parametro Accounts (UPN o object id) oppure, se la lista è vuota, gli utenti il cui UPN o nome visualizzato corrisponde a NamePatterns. Un account è conforme quando segue i requisiti di configurazione documentati da Microsoft: abilitato, membro, solo cloud (non sincronizzato), UPN su un dominio *.onmicrosoft.com e un'assegnazione attiva di Global Administrator fatta direttamente all'account (non solo eligible in PIM, non tramite un gruppo). Fallisce quando gli account conformi sono meno di 2. Metodi di autenticazione, esclusioni dal Conditional Access e avvisi sugli accessi fanno parte delle stesse indicazioni ma sono controlli di sicurezza fuori dal perimetro di ARGUS: vanno verificati a parte. Le esclusioni globali non si applicano.

  Perché conta

  Gli account di accesso di emergenza evitano che l'organizzazione resti chiusa fuori dal proprio tenant quando federazione, MFA o gli amministratori abituali non sono disponibili. Microsoft ne raccomanda due o più, solo cloud, con un'assegnazione Global Administrator attiva e permanente.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.008 Numero di Global Administrator fuori dall'intervallo 2–4 Entra ID Alta

  Cosa controlla

  Conta le persone distinte con il ruolo Global Administrator: assegnazioni attive e, con Entra ID P2, eligible (PIM). I membri dei gruppi assegnabili ai ruoli che hanno il ruolo vengono contati singolarmente. Fallisce quando il numero è sotto 2 o sopra 4. Le esclusioni globali non si applicano: gli account di emergenza vanno contati.

  Perché conta

  Troppo pochi Global Administrator rischiano di far perdere il controllo del tenant; troppi rendono difficile governare il ruolo più potente. Tieni due account di emergenza più pochi amministratori nominativi, e delega il resto a ruoli con privilegi minimi.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.009 Ruoli di directory assegnati a guest Entra ID Alta

  Cosa controlla

  Qualsiasi ruolo di directory di Microsoft Entra (attivo, o eligible con Entra ID P2) assegnato a un account guest, direttamente o tramite un gruppo assegnabile ai ruoli.

  Perché conta

  I ruoli amministrativi dovrebbero essere assegnati ad account che l'organizzazione controlla. Un account guest segue il ciclo di vita di un altro tenant: quando la persona lascia la sua azienda, qui nessuno viene avvisato.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.010 Gli utenti possono registrare applicazioni Entra ID Media

  Cosa controlla

  Legge authorizationPolicy.defaultUserRolePermissions.allowedToCreateApps ("Users can register applications" in User settings). Fallisce quando ogni utente può creare app registration.

  Perché conta

  Le app registration create da chiunque finiscono senza owner, senza scopo e senza una policy sulle credenziali. Limitare la creazione al ruolo Application Developer mantiene governabile il parco applicativo.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.011 Gli utenti possono creare tenant Entra ID Bassa

  Cosa controlla

  Legge authorizationPolicy.defaultUserRolePermissions.allowedToCreateTenants ("Restrict non-admin users from creating tenants" in User settings). Fallisce quando gli utenti non amministratori possono creare tenant Microsoft Entra.

  Perché conta

  Un tenant creato da un utente diventa una directory separata in cui quell'utente è Global Administrator, fuori dalla governance e dalla visibilità dell'organizzazione.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.012 Connessioni degli account LinkedIn disattivate Entra ID Bassa

  Cosa controlla

  L'impostazione LinkedIn account connections (Microsoft Entra admin center > Users > User settings) permette agli utenti di collegare l'account di lavoro a LinkedIn nelle app Microsoft. È attiva di default, tranne per le organizzazioni create in Germania o Francia. Microsoft Graph non ha un'API documentata per leggerla, quindi ARGUS non può valutarla: il risultato è sempre To review e l'impostazione va controllata a mano. Valore atteso: No (o Selected group, se un'esigenza di business è stata approvata).

  Perché conta

  Dopo il consenso dell'utente, le app Microsoft scambiano dati di profilo e collegamenti tra l'account di lavoro e LinkedIn. Se consentirlo è una decisione dell'organizzazione sulla condivisione di dati con un servizio di terze parti, e dovrebbe essere esplicita invece di restare al valore predefinito.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.013 Gruppi di sicurezza senza owner Entra ID Bassa

  Cosa controlla

  Gruppi di sicurezza cloud con membership assegnata e senza owner. Non vengono valutati i gruppi dinamici, quelli assegnabili ai ruoli, i gruppi di sicurezza abilitati alla posta (gestiti in Exchange) e quelli sincronizzati da Active Directory locale.

  Perché conta

  Senza un owner nessuno risponde di chi è nel gruppo e di quali accessi il gruppo concede.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.014 Dispositivi obsoleti (nessun accesso da oltre 180 giorni) Entra ID Bassa

  Cosa controlla

  Dispositivi con approximateLastSignInDateTime più vecchio di 180 giorni (o che non hanno mai effettuato l'accesso e sono stati registrati più di 180 giorni fa). Vengono elencati sia i dispositivi abilitati sia quelli disabilitati; questi ultimi di solito sono pronti per essere eliminati.

  Perché conta

  I dispositivi obsoleti rendono inaffidabili l'inventario dei dispositivi, i report del Conditional Access e il conteggio delle licenze.

  Dettagli tecnici e correzione su GitHub
• ARG.ENT.015 La sincronizzazione della directory è aggiornata Entra ID Media

  Cosa controlla

  Per i tenant ibridi (organization.onPremisesSyncEnabled = true), fallisce quando l'ultima sincronizzazione della directory (onPremisesLastSyncDateTime) è più vecchia di 24 ore. I tenant solo cloud vengono saltati.

  Perché conta

  Quando la sincronizzazione si ferma, le modifiche fatte on-premises (dipendenti usciti disabilitati, cambi nei gruppi) non arrivano più a Microsoft 365, e le decisioni di governance si basano su dati vecchi.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.001 App registration senza owner Applicazioni Media

  Cosa controlla

  App registration senza alcun owner. I risultati mostrano quanti secret e certificati ha ogni app: un'app senza owner ma con credenziali è la prima da rivedere.

  Perché conta

  Senza un owner nessuno risponde dei permessi, delle credenziali e del ciclo di vita dell'app, e nessuno si accorge quando non serve più.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.002 Client secret in scadenza entro 30 giorni Applicazioni Media

  Cosa controlla

  Client secret (passwordCredentials) delle app registration che scadono nei prossimi 30 giorni. Un secret conta come sostituito quando la stessa app ha già un altro secret valido oltre quella finestra: il check fallisce solo per i secret senza sostituto.

  Perché conta

  Un secret scaduto ferma l'integrazione che lo usa. Una rotazione pianificata, con un responsabile, evita i disservizi scoperti dagli utenti.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.003 Client secret scaduti ancora presenti Applicazioni Bassa

  Cosa controlla

  Client secret (passwordCredentials) con endDateTime nel passato ma ancora collegati all'app registration.

  Perché conta

  I secret scaduti sono disordine: nascondono quali credenziali sono davvero in uso e rendono più difficile la revisione delle credenziali.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.004 Client secret con durata oltre 24 mesi Applicazioni Bassa

  Cosa controlla

  Client secret validi la cui durata (endDateTime meno startDateTime) supera i 24 mesi. L'interfaccia di amministrazione limita i nuovi secret a 24 mesi, ma quelli creati via API o prima di quel limite possono durare molto di più. I secret scaduti sono coperti da ARG.APP.003.

  Perché conta

  I secret a lunga durata vengono ruotati di rado e sopravvivono alle persone e alla documentazione che li spiegano. Microsoft raccomanda meno di 12 mesi, oppure certificati e managed identity.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.005 Certificati in scadenza entro 30 giorni Applicazioni Media

  Cosa controlla

  Certificati (keyCredentials con uso Verify, con cui l'app si autentica) che scadono nei prossimi 30 giorni. Un certificato conta come sostituito quando la stessa app ha già un altro certificato valido oltre quella finestra: il check fallisce solo per i certificati senza sostituto.

  Perché conta

  Un certificato scaduto ferma le integrazioni app-only (automazioni, connettori, script). Un rinnovo pianificato evita i disservizi.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.006 Certificati scaduti ancora presenti Applicazioni Bassa

  Cosa controlla

  Certificati (keyCredentials, qualsiasi uso) con endDateTime nel passato ma ancora collegati all'app registration.

  Perché conta

  I certificati scaduti sono disordine: nascondono quali credenziali sono davvero in uso e rendono più difficile la revisione delle credenziali.

  Dettagli tecnici e correzione su GitHub
• ARG.APP.007 Certificati con durata oltre 180 giorni Applicazioni Bassa

  Cosa controlla

  Certificati di autenticazione validi (keyCredentials con uso Verify) la cui durata (endDateTime meno startDateTime) supera i 180 giorni. I certificati scaduti sono coperti da ARG.APP.006.

  Perché conta

  Microsoft raccomanda di limitare la durata dei certificati applicativi a 180 giorni e di automatizzarne il rinnovo. I certificati a lunga durata vengono ruotati di rado e restano validi molto dopo che chi li ha creati ha cambiato ruolo.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.001 Utenti disabilitati che hanno ancora licenze Licenze Alta

  Cosa controlla

  Account disabilitati (accountEnabled = false) con almeno una licenza. Shared mailbox, sale e risorse vengono escluse tramite Exchange Online (sono disabilitate per scelta e possono aver bisogno legittimamente di una licenza). Senza Exchange Online connesso non si possono distinguere, quindi il risultato è To review.

  Perché conta

  Una licenza su un account disabilitato si paga ma non si può usare. La causa più comune sono le persone uscite dall'azienda.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.002 Utenti abilitati con licenza inattivi da oltre 90 giorni Licenze Alta

  Cosa controlla

  Account membro abilitati con almeno una licenza che non accedono da 90 giorni (stessa logica di inattività di ARG.ENT.001: ultimo accesso riuscito, e per gli account che non hanno mai effettuato l'accesso si conta dalla data di creazione). I risultati elencano le licenze assegnate a ogni account.

  Perché conta

  Le licenze assegnate a persone che non le usano più sono un costo ricorrente senza valore per l'azienda, e gli account mantengono accessi che nessuno rivede.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.003 Licenze a pagamento assegnate a utenti guest Licenze Media

  Cosa controlla

  Utenti guest (userType = Guest) con almeno una licenza a pagamento. Gli SKU gratuiti, virali e di prova vengono ignorati (IgnoredSkus, abbonamenti di prova da /directory/subscriptions), come in ARG.LIC.006. Di norma i guest lavorano con le licenze della propria organizzazione o con la quota B2B; una licenza a pagamento su un guest di solito è un errore o un residuo.

  Perché conta

  Le licenze assegnate ai guest costano come un posto intero, vengono riviste di rado e spesso restano dopo la fine della collaborazione. Quando un guest ha davvero bisogno di una licenza, dovrebbe essere una decisione documentata con uno sponsor, non l'effetto collaterale di un'assegnazione tramite gruppo.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.004 Utenti con licenze sovrapposte Licenze Media

  Cosa controlla

  Utenti con due SKU a pagamento in cui ogni service plan di uno SKU è presente anche nell'altro (da subscribedSkus.servicePlans): di solito un prodotto singolo o una suite più vecchia accanto alla suite che lo include. Lo SKU contenuto è ridondante. Il confronto usa gli ID dei service plan, quindi non serve un elenco di nomi di SKU; gli SKU gratuiti, virali e di prova vengono ignorati come in ARG.LIC.006.

  Perché conta

  Le licenze sovrapposte nascono di solito da upgrade in cui il vecchio SKU non è mai stato rimosso, o da due gruppi di licenze che includono entrambi l'utente. Il posto contenuto si paga due volte e blocca una licenza che potrebbe andare a qualcun altro.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.005 Errori di assegnazione delle licenze Licenze Media

  Cosa controlla

  Utenti i cui licenseAssignmentStates contengono una voce nello stato Error (la licenza non è assegnata) o ActiveWithError (assegnata, ma in parte non riuscita). La colonna dell'errore mostra il motivo riportato da Microsoft Entra ID, per esempio CountViolation (posti insufficienti), MutuallyExclusiveViolation o ProhibitedInUsageLocationViolation. I nomi dei gruppi compaiono quando i gruppi sono leggibili.

  Perché conta

  Gli errori di assegnazione lasciano gli utenti senza i servizi che dovrebbero avere, e di solito passano inosservati quando le licenze sono assegnate tramite gruppi.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.006 Licenze inutilizzate per SKU Licenze Media

  Cosa controlla

  Confronta i posti acquistati (prepaidUnits.enabled) con quelli assegnati (consumedUnits) per ogni SKU attivo e assegnabile agli utenti (capabilityStatus = Enabled, appliesTo = User). Uno SKU fallisce quando più del 10% o più di 5 posti non sono usati. Vengono ignorati gli SKU gratuiti, virali e per sviluppatori (la lista IgnoredSkus), quelli con 10.000 posti o più (le offerte gratuite vengono attivate con quantità molto grandi) e quelli di prova (isTrial in /directory/subscriptions).

  Perché conta

  I posti inutilizzati sono un costo ricorrente senza valore per l'azienda. Rivederli prima di ogni rinnovo è il risparmio sulle licenze più semplice.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.007 Shared mailbox con licenza Licenze Bassa

  Cosa controlla

  Shared mailbox (Exchange Online) il cui oggetto utente ha licenze assegnate. Una shared mailbox ha bisogno di una licenza solo se supera i 50 GB, ha un archivio online o è in litigation hold o in un hold in-place. Le caselle che soddisfano una di queste condizioni (dimensione di 50 GB o più, archivio attivo, LitigationHoldEnabled, InPlaceHolds non vuoto) non vengono elencate; le altre sono da verificare (To review), perché le policy di conservazione a livello di organizzazione e altre esigenze non sono visibili a questo check.

  Perché conta

  Le shared mailbox hanno spesso una licenza perché una casella utente è stata convertita e la licenza non è mai stata tolta: un costo ricorrente senza alcun beneficio.

  Dettagli tecnici e correzione su GitHub
• ARG.LIC.008 Licenze a pagamento assegnate direttamente agli utenti Licenze Bassa

  Cosa controlla

  Utenti con almeno una licenza a pagamento assegnata direttamente (voce di licenseAssignmentStates senza assignedByGroup) invece che tramite il licensing basato sui gruppi. Non vengono contati gli SKU gratuiti, virali e per sviluppatori (la lista IgnoredSkus), quelli con 10.000 posti o più e quelli di prova (isTrial in /directory/subscriptions): di solito sono iscrizioni self-service. AlsoFromGroup elenca le licenze dirette che l'utente riceve anche da un gruppo, dove l'assegnazione diretta è ridondante.

  Perché conta

  Le assegnazioni dirette non dipendono dall'appartenenza ai gruppi: non vengono tolte quando una persona cambia ruolo o esce, e sono difficili da verificare su larga scala. Il licensing basato sui gruppi mantiene le licenze a pagamento coerenti con i processi di ingresso, cambio ruolo e uscita.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.001 La creazione di gruppi Microsoft 365 è limitata Gruppi e Teams Media

  Cosa controlla

  Legge EnableGroupCreation e GroupCreationAllowedGroupId nell'impostazione di directory Group.Unified a livello di tenant. Se l'impostazione non è mai stata creata, ogni utente può creare gruppi Microsoft 365 e Teams (predefinito). La creazione senza limiti è To review: per alcune organizzazioni è una scelta valida, purché ownership e scadenza siano governate.

  Perché conta

  Ogni nuovo Team o piano di Planner crea un gruppo Microsoft 365 con una casella e un sito SharePoint. Senza una policy di creazione, proliferazione e duplicati crescono in fretta; limitare la creazione agli utenti formati o aggiungere un processo di richiesta la mantiene governata.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.002 Policy di denominazione dei gruppi configurata Gruppi e Teams Bassa

  Cosa controlla

  Legge PrefixSuffixNamingRequirement e CustomBlockedWordsList nell'impostazione di directory Group.Unified a livello di tenant. Passa quando è configurata una regola di prefisso o suffisso o una lista di parole bloccate. La policy di denominazione richiede Microsoft Entra ID P1 per gli utenti a cui si applica.

  Perché conta

  Una convenzione di nomi (per esempio un prefisso GRP- o un attributo del reparto) rende gruppi e Teams facili da riconoscere in rubrica, in Teams e in SharePoint; le parole bloccate evitano nomi fuorvianti.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.003 Policy di scadenza dei gruppi configurata Gruppi e Teams Media

  Cosa controlla

  Legge groupLifecyclePolicies. Fallisce quando non esiste una policy di scadenza o quando non si applica a nessun gruppo (managedGroupTypes = None); una policy che si applica solo ad alcuni gruppi è To review. I gruppi con attività recente vengono rinnovati automaticamente, quindi gli owner attivi non vengono disturbati.

  Perché conta

  Senza una policy di scadenza, i gruppi Microsoft 365 e i Teams non più usati restano per sempre con contenuti, guest e permessi. La scadenza chiede agli owner di confermare che il gruppo serve ancora.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.004 Gruppi Microsoft 365 e Teams senza owner Gruppi e Teams Alta

  Cosa controlla

  Gruppi Microsoft 365 (Unified), compresi quelli collegati a Teams, senza owner.

  Perché conta

  Nessuno gestisce membri, guest o contenuti di un gruppo senza owner, nessuno riceve gli avvisi di scadenza e nessuno può approvare le richieste di accesso. Microsoft raccomanda almeno due owner per gruppo.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.005 Gruppi Microsoft 365 e Teams con un solo owner Gruppi e Teams Bassa

  Cosa controlla

  Gruppi Microsoft 365 (Unified), compresi i Teams, con esattamente un owner. La colonna Owner mostra chi è e OwnerEnabled se quell'account è ancora abilitato; i gruppi il cui unico owner è disabilitato sono elencati per primi.

  Perché conta

  Un solo owner è un singolo punto di rottura: quando quella persona esce o cambia ruolo il gruppo resta senza owner. Microsoft raccomanda almeno due owner.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.006 Teams con guest e senza owner Gruppi e Teams Alta

  Cosa controlla

  Teams (gruppi Microsoft 365 con un team) senza owner e con almeno un guest tra i membri. I membri dei Teams senza owner vengono letti con il JSON batching (GET /groups/<id>/members/microsoft.graph.user, primi 999 membri).

  Perché conta

  I guest in un team senza owner mantengono l'accesso a chat, file e sito, e nessuno li rivede o li rimuove. Tra i gruppi senza owner (ARG.GRP.004) sono i primi da sistemare.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.007 Gruppi Microsoft 365 pubblici Gruppi e Teams Media

  Cosa controlla

  Gruppi Microsoft 365 (Unified) con visibility = Public. Chiunque nell'organizzazione può unirsi a un gruppo pubblico, o al suo team, e leggerne conversazioni, file e sito senza approvazione. La colonna Team indica se è collegato un team.

  Perché conta

  I gruppi pubblici vanno bene per le community aziendali, ma progetti, reparti e attività per i clienti di solito contengono materiale da limitare ai membri. Rivederli mantiene la visibilità una scelta consapevole.

  Dettagli tecnici e correzione su GitHub
• ARG.GRP.008 Teams inattivi (oltre 180 giorni) Gruppi e Teams Bassa

  Cosa controlla

  Teams con Last Activity Date nel report di attività dei team (getTeamsTeamActivityDetail, periodo D180) più vecchia di 180 giorni, o vuota (nessuna attività registrata nel periodo). I team creati da meno di 180 giorni e quelli che non esistono più vengono ignorati quando i gruppi sono leggibili. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review.

  Perché conta

  I Teams inattivi conservano contenuti, guest e permessi che nessuno cura. Archiviarli o eliminarli mantiene significativi ricerca, spazio di archiviazione e access review.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.001 La creazione di siti SharePoint è limitata SharePoint e OneDrive Media

  Cosa controlla

  Legge admin/sharepoint/settings.isSiteCreationEnabled ("Users can create SharePoint sites" nello SharePoint admin center) e isSiteCreationUIEnabled. Quando gli utenti possono creare siti, chiunque può creare siti di comunicazione e siti del team senza gruppo, anche se la creazione di gruppi Microsoft 365 è limitata (ARG.GRP.001): To review, perché per alcune organizzazioni è una scelta valida.

  Perché conta

  I siti self-service si moltiplicano in fretta, spesso senza un owner chiaro, una classificazione o un ciclo di vita. Limitare la creazione, o farla passare da un processo di richiesta con un modello, mantiene governabile il parco siti e pulito l'indice di Copilot.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.002 Livello di condivisione esterna del tenant SharePoint e OneDrive Media

  Cosa controlla

  Legge l'impostazione di condivisione a livello di organizzazione per SharePoint e OneDrive (admin/sharepoint/settings.sharingCapability). Anyone (externalUserAndGuestSharing: link che non richiedono l'accesso) è To review; New and existing guests, Existing guests only e Only people in your organization passano. I risultati mostrano anche la modalità di restrizione dei domini e se i guest possono ricondividere. I singoli siti possono solo essere più restrittivi di questa impostazione.

  Perché conta

  I link Anyone possono essere inoltrati a persone esterne all'organizzazione senza alcuna traccia di chi li ha aperti. Molte organizzazioni li consentono di proposito per pochi siti; il livello del tenant dovrebbe essere una decisione consapevole, con restrizioni sui singoli siti dove serve.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.003 Il link di condivisione predefinito è limitato a persone specifiche SharePoint e OneDrive Media

  Cosa controlla

  Legge con PnP.PowerShell (Get-PnPTenant) il tipo di link predefinito della finestra di condivisione: CoreDefaultShareLinkScope per SharePoint e OneDriveDefaultShareLinkScope per OneDrive, con il fallback su DefaultSharingLinkType quando sono Uninitialized. Anyone come predefinito fallisce; People in your organization (o il link più ampio consentito) è To review; Specific people passa. Richiede Connect-Argus -Service SharePoint; altrimenti il check è Skipped.

  Perché conta

  La maggior parte delle persone accetta il link predefinito. Un predefinito Anyone o esteso a tutta l'organizzazione trasforma ogni condivisione veloce in un accesso ampio, la prima fonte dell'oversharing che Copilot poi fa emergere nelle risposte. Specific people come predefinito mantiene la condivisione intenzionale.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.004 I link Anyone scadono entro 30 giorni SharePoint e OneDrive Media

  Cosa controlla

  Quando l'organizzazione consente i link Anyone (sharingCapability = externalUserAndGuestSharing), legge RequireAnonymousLinksExpireInDays con PnP.PowerShell (Get-PnPTenant). Fallisce quando i link Anyone non scadono mai (0 o non impostato) o scadono dopo più di 30 giorni. Passa senza valutazione quando i link Anyone non sono consentiti. Richiede Connect-Argus -Service SharePoint; altrimenti il check è Skipped.

  Perché conta

  Un link Anyone funziona per chiunque lo abbia, finché esiste. Un limite di scadenza circoscrive per quanto tempo un link inoltrato o finito in mani sbagliate resta utilizzabile, senza vietare i link Anyone dove l'azienda ne ha bisogno.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.005 L'accesso dei guest a siti e file scade SharePoint e OneDrive Media

  Cosa controlla

  Legge ExternalUserExpirationRequired e ExternalUserExpireInDays con PnP.PowerShell (Get-PnPTenant): se i guest perdono l'accesso a siti e file dopo un certo numero di giorni, a meno che un owner del sito non lo rinnovi. Fallisce quando la policy è disattiva. Passa senza valutazione quando la condivisione esterna è disattivata (sharingCapability = disabled). Richiede Connect-Argus -Service SharePoint; altrimenti il check è Skipped.

  Perché conta

  I guest invitati per un progetto mantengono l'accesso molto dopo la sua fine. Una policy di scadenza fa confermare periodicamente agli owner dei siti chi ha ancora bisogno di accedere; completa le revisioni dei guest in Entra ID (ARG.ENT.005).

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.006 Siti che consentono i link Anyone SharePoint e OneDrive Bassa

  Cosa controlla

  Raccolte siti (PnP.PowerShell Get-PnPTenantSite, OneDrive escluso) la cui impostazione di condivisione è ExternalUserAndGuestSharing (Anyone). Elencati come To review: su alcuni siti i link Anyone possono essere voluti, ma ognuno va conosciuto. Passa senza valutazione quando l'organizzazione non consente i link Anyone. Richiede Connect-Argus -Service SharePoint; altrimenti il check è Skipped.

  Perché conta

  Il livello dell'organizzazione fissa il massimo; ogni sito lo eredita a meno che un amministratore non lo restringa. Sapere quali siti possono creare link Anyone permette di mantenere quella possibilità solo dove ha un responsabile e un motivo.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.007 Siti senza etichetta di riservatezza SharePoint e OneDrive Bassa

  Cosa controlla

  Raccolte siti (PnP.PowerShell Get-PnPTenantSite, esclusi OneDrive e siti di sistema) senza etichetta di riservatezza (SensitivityLabel vuoto). Quando nessun sito ha un'etichetta, probabilmente le etichette non sono usate per siti e gruppi: il risultato è To review invece di Failed. Richiede Connect-Argus -Service SharePoint; altrimenti il check è Skipped.

  Perché conta

  Un'etichetta di contenitore imposta in un unico punto privacy, condivisione esterna e accesso dei guest di un sito, e dice a utenti e Copilot quanto sono riservati i suoi contenuti. Quando le etichette sono in uso, i siti senza etichetta sono quelli che sfuggono a quei controlli e alla classificazione.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.008 Siti SharePoint orfani SharePoint e OneDrive Alta

  Cosa controlla

  Siti collegati a un gruppo il cui gruppo Microsoft 365 non ha owner (URL del sito letto con il JSON batching, GET /groups/<id>/sites/root). Quando SharePoint è connesso tramite PnP.PowerShell, vengono valutati anche i siti senza gruppo Microsoft 365 (siti del team classici, siti di comunicazione): un sito è orfano quando il suo amministratore principale della raccolta siti (Owner in Get-PnPTenantSite) è vuoto, disabilitato o non esiste più. Senza PnP quei siti non vengono valutati e il riepilogo lo segnala.

  Perché conta

  Nessuno gestisce permessi, condivisione o contenuti di un sito senza un responsabile, e le richieste di accesso restano senza risposta. I siti orfani sono anche i più difficili da ripulire in seguito.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.009 Siti SharePoint inattivi (oltre 180 giorni) SharePoint e OneDrive Bassa

  Cosa controlla

  Siti SharePoint con Last Activity Date nel report di utilizzo dei siti (getSharePointSiteUsageDetail, periodo D180) più vecchia di 180 giorni o vuota (nessuna attività nel periodo). Vengono ignorati i siti eliminati e quelli di sistema (ExcludedTemplates: centro di ricerca, centro criteri di conformità, sito fondamentale del tenant, catalogo app); gli account OneDrive non fanno parte di questo report. Quando il report lascia vuoto Site URL (un problema noto dei report di utilizzo), l'URL viene letto dal Site Id: prima dall'elenco dei siti PnP quando SharePoint è connesso (comprende i siti privati dei gruppi e dei canali), poi con GET /sites/<id>, che in modalità delegata legge solo i siti a cui l'account ha accesso; per l'owner si usa Owner Display Name, ed è "Not reported" quando il report non lo indica. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review.

  Perché conta

  I siti inattivi contengono materiale e permessi che nessuno cura, occupano spazio e compaiono nelle ricerche. Rivederli con regolarità mantiene pulita l'architettura delle informazioni.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.010 Siti vicini alla quota di archiviazione (oltre il 90%) SharePoint e OneDrive Bassa

  Cosa controlla

  Siti SharePoint il cui spazio usato supera il 90% di quello allocato, dal report di utilizzo dei siti (Storage Used (Byte) / Storage Allocated (Byte), periodo D180). I siti eliminati e quelli senza allocazione vengono ignorati. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review. Quando il report lascia vuoto Site URL (un problema noto dei report di utilizzo), l'URL viene letto dal Site Id: prima dall'elenco dei siti PnP quando SharePoint è connesso (comprende i siti privati dei gruppi e dei canali), poi con GET /sites/<id>, che in modalità delegata legge solo i siti a cui l'account ha accesso.

  Perché conta

  Un sito che raggiunge la quota diventa di sola lettura per i nuovi contenuti, e il lavoro si interrompe. Pianificare in anticipo aumenti di quota o pulizie lo evita.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.011 Il OneDrive degli utenti eliminati è conservato almeno 90 giorni SharePoint e OneDrive Bassa

  Cosa controlla

  Legge admin/sharepoint/settings.deletedUserPersonalSiteRetentionPeriodInDays: per quanto tempo il OneDrive di un utente eliminato viene conservato prima di essere cancellato (30 giorni di default, fino a 3650). Fallisce quando è inferiore a 90 giorni.

  Perché conta

  Dopo l'eliminazione di un utente, il manager ha solo questo periodo per trovare e spostare i file di lavoro dal OneDrive. Trenta giorni sono spesso meno del tempo necessario ad accorgersi che manca qualcosa, soprattutto quando il processo di uscita parte in ritardo.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.012 OneDrive di utenti eliminati o disabilitati con contenuti SharePoint e OneDrive Bassa

  Cosa controlla

  Account OneDrive del report di utilizzo di OneDrive (getOneDriveUsageAccountDetail, periodo D180) che contengono ancora file (Storage Used (Byte) > 0, non eliminati) mentre il proprietario è disabilitato o non esiste più in Microsoft Entra ID. Il OneDrive di un utente eliminato viene conservato per il periodo impostato nello SharePoint admin center (30 giorni di default) e poi cancellato. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review. Quando il report lascia vuoto Site URL (un problema noto dei report di utilizzo; questo report non ha un Site Id), l'URL viene dalla proprietà mySite dell'utente, o è ricavato dall'UPN con la convenzione di nomi di OneDrive quando l'utente non esiste più (colonna UrlSource).

  Perché conta

  I file di chi è uscito restano in OneDrive di cui nessuno si occupa, con i link di condivisione ancora attivi. Decidere cosa tenere e trasferirlo a un manager o a un sito fa parte del processo di uscita.

  Dettagli tecnici e correzione su GitHub
• ARG.SPO.013 OneDrive vicini alla quota di archiviazione (oltre il 90%) SharePoint e OneDrive Bassa

  Cosa controlla

  Account OneDrive del report di utilizzo di OneDrive (getOneDriveUsageAccountDetail, periodo D180) il cui Storage Used (Byte) supera il 90% di Storage Allocated (Byte). Gli account eliminati e quelli senza allocazione vengono ignorati. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review. Quando il report lascia vuoto Site URL (un problema noto dei report di utilizzo; questo report non ha un Site Id), l'URL viene dalla proprietà mySite dell'utente, o è ricavato dall'UPN con la convenzione di nomi di OneDrive quando l'utente non esiste più (colonna UrlSource).

  Perché conta

  Un OneDrive pieno smette di sincronizzare e salvare, e gli utenti iniziano a tenere i file sui dischi locali o su spazi personali. Gli account vicini al limite hanno bisogno di una pulizia, dello spostamento dei contenuti del team in SharePoint o di una quota più alta.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.001 Shared mailbox con accesso abilitato Exchange Online Media

  Cosa controlla

  Shared mailbox (Exchange Online) il cui account utente in Microsoft Entra ID è abilitato (accountEnabled = true). Le persone accedono alle shared mailbox con i propri account e i permessi sulla casella; l'account della shared mailbox in sé non ha bisogno di accedere.

  Perché conta

  Un account di shared mailbox abilitato ha una password che nessuno possiede, spesso è escluso dalle revisioni, e permette a chiunque conosca la password di accedere direttamente invece che tramite un accesso delegato e tracciato.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.002 Shared mailbox senza delegati Exchange Online Bassa

  Cosa controlla

  Shared mailbox senza alcun permesso FullAccess esplicito (Get-EXOMailboxPermission: non ereditato, non negato, NT AUTHORITY\SELF ignorato). I permessi Send As e Send on Behalf non vengono considerati: senza FullAccess nessuno può aprire la casella. Una chiamata a Exchange per ogni shared mailbox.

  Perché conta

  Una shared mailbox che nessuno può aprire continua a ricevere posta che nessuno legge, spesso da clienti o fornitori. Ogni shared mailbox dovrebbe avere persone responsabili con nome e cognome.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.003 Shared mailbox inattive (oltre 90 giorni) Exchange Online Bassa

  Cosa controlla

  Shared mailbox (Exchange Online) con Last Activity Date nel report di utilizzo delle caselle (getMailboxUsageDetail, periodo D180) più vecchia di 90 giorni, o vuota per le caselle create prima. Il report non indica il tipo di destinatario, quindi le shared mailbox vengono individuate tramite Exchange Online. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review.

  Perché conta

  Le shared mailbox create per progetti, eventi o vecchi processi sopravvivono al loro scopo. Quelle inutilizzate mantengono permessi, indirizzi e a volte licenze che nessuno rivede.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.004 Caselle utente inattive (oltre 90 giorni) Exchange Online Bassa

  Cosa controlla

  Caselle con Last Activity Date nel report di utilizzo delle caselle (getMailboxUsageDetail, periodo D180) più vecchia di 90 giorni, o vuota per le caselle create prima. Con Exchange Online connesso vengono valutate solo le caselle utente; altrimenti il report contiene anche le shared mailbox, e il riepilogo lo segnala. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review.

  Perché conta

  Una casella utente che nessuno usa di solito appartiene a chi ha lasciato l'azienda o a un account di test dimenticato: mantiene licenza, posta e permessi senza motivo.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.005 Caselle utente di account disabilitati Exchange Online Bassa

  Cosa controlla

  Caselle utente (RecipientTypeDetails = UserMailbox) il cui account Microsoft Entra è disabilitato (accountEnabled = false). Le caselle in litigation hold o con hold in-place sono considerate conservate di proposito e non vengono elencate. Shared mailbox, sale e risorse sono escluse (i loro account devono essere disabilitati).

  Perché conta

  Un utente disabilitato con una casella utente ancora attiva è un processo di uscita fermo a metà: la posta continua ad arrivare, nessuno la legge e la casella di solito mantiene una licenza. Convertirla in shared mailbox, delegarla o eliminarla chiude il processo.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.006 Caselle vicine alla quota (oltre il 90% della quota di avviso) Exchange Online Bassa

  Cosa controlla

  Caselle utente e shared mailbox del report di utilizzo (getMailboxUsageDetail, periodo D180) il cui Storage Used (Byte) supera il 90% di Issue Warning Quota (Byte) (la dimensione oltre la quale il proprietario inizia a ricevere avvisi; se non c'è una quota di avviso si usa Prohibit Send Quota). I risultati mostrano anche quanto manca a Prohibit Send. Con Exchange Online connesso viene indicato il tipo di casella (utente, condivisa, sala, risorsa). Le caselle eliminate e quelle senza quota vengono ignorate. Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review.

  Perché conta

  Gli utenti possono reagire agli avvisi di quota, le shared mailbox no: nessuno riceve i loro avvisi, e smettono di accettare posta senza preavviso quando arrivano al limite. Le caselle oltre o vicine alla quota di avviso hanno bisogno di un archivio, di una policy di conservazione, di una pulizia o, per le shared mailbox oltre i 50 GB, di una licenza.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.007 Caselle con inoltro configurato (inventario) Exchange Online Bassa

  Cosa controlla

  Inventario delle caselle con inoltro a livello di casella (ForwardingSmtpAddress o ForwardingAddress in Get-EXOMailbox). Un indirizzo SMTP di inoltro il cui dominio non è un dominio verificato del tenant viene segnato come External; ForwardingAddress punta a un destinatario della directory (che può essere un contatto di posta esterno all'organizzazione). Le regole della posta in arrivo non vengono valutate. Elencate come To review: l'inoltro è spesso legittimo, ma ognuno dovrebbe avere un responsabile e un motivo, e gli inoltri rimasti sulle caselle di chi è uscito vanno rimossi.

  Perché conta

  Un inoltro impostato anni fa continua a copiare la posta verso indirizzi che nessuno rivede, a volte fuori dall'organizzazione e dopo l'uscita del proprietario. Sapere dove viene inoltrata la posta, e perché, fa parte della governance del ciclo di vita delle caselle; bloccare l'inoltro automatico verso l'esterno è un controllo di sicurezza fuori dal perimetro di ARGUS.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.008 Caselle utente senza hold (informativo) Exchange Online Info

  Cosa controlla

  Conta le caselle utente con Litigation Hold (LitigationHoldEnabled) o con un hold in-place, eDiscovery o di conservazione elencato in InPlaceHolds, ed elenca quelle che non hanno né l'uno né l'altro. Le policy di conservazione di Microsoft Purview a livello di organizzazione non sono visibili ad ARGUS (richiedono la Security & Compliance PowerShell), quindi una casella senza hold potrebbe comunque essere conservata: il check è sempre To review quando ci sono caselle di questo tipo. Severità Info: non incide sul punteggio.

  Perché conta

  Se la posta va conservata, per quanto tempo e per chi, è una decisione di gestione documentale. Gli hold impostati casella per casella divergono nel tempo; sapere quali caselle ne hanno uno, e confermare che una policy di conservazione copra le altre, mantiene la strategia di conservazione coerente con gli obblighi di legge.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.009 Liste di distribuzione senza owner Exchange Online Bassa

  Cosa controlla

  Liste di distribuzione e gruppi di sicurezza abilitati alla posta (Exchange Online, Get-DistributionGroup) con la lista ManagedBy vuota, quindi gestibili solo dagli amministratori di Exchange.

  Perché conta

  Senza un owner, membri e restrizioni di consegna di una lista non vengono mantenuti, nessuno può approvare le richieste di iscrizione e la lista continua a mandare posta a chi è uscito o ha cambiato ruolo.

  Dettagli tecnici e correzione su GitHub
• ARG.EXO.010 Liste di distribuzione vuote Exchange Online Bassa

  Cosa controlla

  Liste di distribuzione e gruppi di sicurezza abilitati alla posta (Get-DistributionGroup) senza membri, letti tramite Microsoft Graph (GET /groups/<id>/members?$top=1, inviati in $batch). I gruppi di cui non è stato possibile leggere i membri restano fuori dalla valutazione. Le liste di distribuzione dinamiche non sono incluse.

  Perché conta

  Una lista vuota accetta ancora posta, che poi non arriva a nessuno, e affolla la rubrica. Di solito le liste vuote sono residui di progetti o riorganizzazioni e si possono rimuovere.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.001 Acquisto self-service e trial dei prodotti Copilot disattivati Copilot e agenti Media

  Cosa controlla

  Legge con il modulo MSCommerce (Get-MSCommerceProductPolicies) la policy AllowSelfServicePurchase di ogni prodotto il cui nome contiene "Copilot". Fallisce quando un prodotto Copilot è Enabled (gli utenti possono acquistarlo e avviare trial) o OnlyTrialsWithoutPaymentMethod (gli utenti possono avviare trial). MSCommerce richiede Connect-Argus -Service Commerce, accesso interattivo e Windows; altrimenti il check è Skipped.

  Perché conta

  Gli acquisti self-service creano licenze, fatture e impegni sul trattamento dei dati fuori dal processo IT e acquisti. Le licenze Copilot comprate dai singoli non rientrano nel piano di rilascio dell'organizzazione, nella preparazione (oversharing, etichette di riservatezza) né nel budget.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.002 Gli utenti non possono attivare trial self-service (Copilot Studio, Power Platform) Copilot e agenti Media

  Cosa controlla

  Legge authorizationPolicy.allowedToSignUpEmailBasedSubscriptions. Quando è true, gli utenti possono iscriversi da soli ad abbonamenti basati sull'email ("virali") come i trial di Copilot Studio e Power Apps, e iniziare a costruire agenti e app senza una licenza assegnata. allowEmailVerifiedUsersToJoinOrganization è mostrato come contesto.

  Perché conta

  Le iscrizioni self-service portano la creazione di agenti e app fuori da qualsiasi decisione su licenze, ambienti e policy sui dati. Gli agenti costruiti su licenze di prova sono difficili da censire e spesso smettono di funzionare, o continuano a girare, quando il trial finisce.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.003 Licenze Copilot inutilizzate da oltre 30 giorni Copilot e agenti Media

  Cosa controlla

  Utenti del report di utilizzo di Microsoft 365 Copilot (copilot/reports/getMicrosoft365CopilotUsageUserDetail, periodo D180), che elenca solo chi ha una licenza Microsoft 365 Copilot, con Last Activity Date più vecchia di 30 giorni o vuota (nessun uso di Copilot negli ultimi 180 giorni). Con i nomi oscurati nei report, o se il report non restituisce righe, il risultato è To review. Skipped quando non viene rilevata alcuna licenza Microsoft 365 Copilot.

  Perché conta

  Le licenze Copilot sono tra le più costose di Microsoft 365. Quelle non usate dovrebbero passare a chi è in lista d'attesa, oppure l'utente ha bisogno di supporto all'adozione: in entrambi i casi la decisione sulla licenza va rivista.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.004 Modelli Anthropic come subprocessor di Microsoft (verifica manuale) Copilot e agenti Info

  Cosa controlla

  L'impostazione "AI providers operating as Microsoft subprocessors" (Microsoft 365 admin center > Copilot > Settings) decide se i modelli Anthropic possono essere usati in Copilot, Researcher, Copilot Studio, Power Platform e Copilot nelle app Microsoft 365. Nessuna API Microsoft la espone, quindi il check è sempre To review: legge il paese del tenant (organization.countryLetterCode) e indica il valore predefinito che si applica. Anthropic è attivo di default nel cloud commerciale e disattivo di default in UE, EFTA e Regno Unito. Severità Info: non incide sul punteggio.

  Perché conta

  Come subprocessor di Microsoft, Anthropic è coperto dai Product Terms e dal DPA di Microsoft, ma i suoi modelli sono esclusi dall'EU Data Boundary e dagli impegni di trattamento nel paese. Per le organizzazioni soggette al GDPR è una decisione sul trasferimento dei dati da documentare (registro dei trattamenti, DPIA dove richiesta) e da limitare agli utenti autorizzati.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.005 Modelli Anthropic con Data Retention, processor indipendente (verifica manuale) Copilot e agenti Info

  Cosa controlla

  I "modelli Anthropic con Data Retention" (per esempio alcuni modelli di classe Fable e Mythos) sono offerti con i Commercial Terms e il Data Processing Addendum di Anthropic: Anthropic agisce come processor indipendente, fuori dai Product Terms e dal DPA di Microsoft, e conserva input e output. Sono disattivi di default in ogni regione e vanno abilitati esplicitamente nel Microsoft 365 admin center. Nessuna API Microsoft espone l'impostazione, quindi il check è sempre To review. Severità Info: non incide sul punteggio.

  Perché conta

  Con questi modelli prompt, file e risposte sono conservati da Anthropic (la maggior parte dei dati fino a 30 giorni, i contenuti segnalati più a lungo) secondo condizioni che l'organizzazione firma direttamente con Anthropic. È un rapporto di trattamento separato e, per le organizzazioni europee, un trasferimento internazionale che richiede una propria valutazione legale.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.006 La ricerca web in Copilot è una scelta consapevole Copilot e agenti Bassa

  Cosa controlla

  Legge l'impostazione Cloud Policy a livello di tenant "Allow web search in Copilot" (GET /beta/copilot/admin/policySettings/microsoft.copilot.allowwebsearch, solo con accesso delegato). Se la policy non è configurata, la ricerca web è disponibile in Copilot e Copilot Chat (salvo che le esperienze connesse opzionali siano disattivate): To review. Il significato di ogni valore configurato non è documentato, quindi un valore configurato è To review a meno che non sia elencato nel parametro DisabledValues dopo averlo verificato nel servizio Cloud Policy. Una policy limitata a un gruppo non è leggibile da questa API ed è anch'essa To review.

  Perché conta

  Con la ricerca web attiva, Copilot invia a Bing query derivate dai prompt (e a volte dai documenti aperti). Per quelle query Microsoft è titolare del trattamento: DPA, HIPAA ed EU Data Boundary non si applicano. Se sia accettabile è una decisione privacy che l'organizzazione dovrebbe prendere esplicitamente.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.007 La personalizzazione avanzata di Copilot (memoria) è una scelta consapevole Copilot e agenti Bassa

  Cosa controlla

  Legge il controllo di personalizzazione avanzata (GET /beta/copilot/settings/people/enhancedpersonalization). Quando isEnabledInOrganization è true e non è impostato disabledForGroup, la memoria e i suggerimenti personalizzati di Copilot sono attivi per tutti: To review. Passa quando il controllo è disattivo, o attivo con un gruppo escluso.

  Perché conta

  La personalizzazione avanzata permette a Copilot di usare chat di Teams, email, trascrizioni delle riunioni, segnali di utilizzo e profilo di ogni utente per ricordarne le preferenze tra una conversazione e l'altra. I dati restano nel perimetro dell'utente, ma è una nuova finalità di trattamento che informative privacy e accordi sindacali potrebbero dover coprire.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.008 Creazione e accesso agli agenti sono governati (verifica manuale) Copilot e agenti Info

  Cosa controlla

  Chi può usare e installare agenti (Agents > Settings > User access, e Agent and plugin access) si imposta nel Microsoft 365 admin center, e chi può costruire agenti in Copilot Studio si imposta per ogni ambiente Power Platform. Nessuna API Microsoft espone queste impostazioni a strumenti in sola lettura, quindi il check è sempre To review ed elenca cosa verificare. ARG.COP.002 copre l'iscrizione ai trial self-service. Severità Info: non incide sul punteggio.

  Perché conta

  Quando ogni utente può costruire e usare agenti, gli agenti si collegano a dati, connettori e servizi esterni più in fretta di quanto si riesca a censirli. Un percorso governato (maker approvati, tipi di agente approvati, un ambiente gestito) fa sì che gli agenti abbiano un owner e vengano rivisti e dismessi.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.009 Gli utenti possono registrare agent identity blueprint Copilot e agenti Media

  Cosa controlla

  Legge authorizationPolicy.defaultUserRolePermissions.allowedToCreateAgentIdentityBlueprints ("Users can register agent identity blueprints" in Entra ID > Users > User settings) dall'endpoint beta (GET /beta/policies/authorizationPolicy); la v1.0 non lo restituisce e Learn non lo documenta ancora. Fallisce quando ogni utente senza ruolo amministrativo può creare agent identity blueprint, il valore predefinito dal rilascio di novembre 2026. L'impostazione è indipendente da "Users can register applications" (ARG.ENT.010). Skipped quando il tenant non restituisce ancora la proprietà.

  Perché conta

  Un agent identity blueprint è il modello e il contenitore delle credenziali delle identità di agente create a partire da esso. I blueprint creati da qualsiasi utente non hanno owner, scopo né perimetro di permessi verificati, e ogni agente costruito sopra eredita quella lacuna. Limitare la creazione agli amministratori mantiene le identità di agente censite e governate.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.010 La condivisione degli agenti con tutta l'organizzazione è limitata (verifica manuale) Copilot e agenti Info

  Cosa controlla

  L'impostazione Sharing (Microsoft 365 admin center > Agents > Settings > Sharing) decide chi può condividere con tutta l'organizzazione gli agenti creati con Copilot Agent Builder (Copilot Studio lite): All users (predefinito), No users o Specific users. La condivisione con persone specifiche resta sempre possibile. Nessuna API Microsoft espone l'impostazione, quindi il check è sempre To review. Severità Info: non incide sul punteggio.

  Perché conta

  Un agente condiviso con tutti risponde, a chiunque lo apra, dalle fonti di conoscenza scelte da chi l'ha creato. Limitare la condivisione a pochi publisher mantiene curato il catalogo degli agenti ed evita che agenti duplicati o non verificati arrivino a tutta l'azienda.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.011 Agenti di publisher esterni disponibili a tutti gli utenti Copilot e agenti Bassa

  Cosa controlla

  Pacchetti del catalogo agenti (GET /copilot/admin/catalog/packages) con type = external (realizzati da partner), non bloccati e con availableTo = tutti gli utenti. Ognuno è To review: gli agenti esterni trattano i dati secondo le condizioni del publisher. Richiede una licenza Microsoft Agent 365; altrimenti il check è Skipped.

  Perché conta

  I dati trattati da agenti e plugin non Microsoft non sono coperti dagli accordi con Microsoft. Renderli disponibili a tutti dovrebbe seguire una verifica di come il publisher tratta i dati, possibilmente limitando l'accesso ai team che ne hanno bisogno.

  Dettagli tecnici e correzione su GitHub
• ARG.COP.012 Richieste di agenti in attesa da oltre 7 giorni Copilot e agenti Bassa

  Cosa controlla

  Pacchetti con una richiesta utente aperta (GET /copilot/admin/catalog/packages?$filter=requestStatus eq 'pending': pubblicazione, attivazione, accesso o aggiornamento) con lastModifiedDateTime più vecchio di 7 giorni. L'API espone l'ultima modifica del pacchetto, non la data della richiesta, quindi l'età è approssimativa. Richiede una licenza Microsoft Agent 365; altrimenti il check è Skipped.

  Perché conta

  Un processo di approvazione funziona solo se le richieste ricevono risposta. Le richieste lasciate aperte spingono gli utenti verso scorciatoie (agenti personali, strumenti ombra) e lasciano il catalogo non aggiornato.

  Dettagli tecnici e correzione su GitHub

Nessun controllo corrisponde alla ricerca.