• Cloud, Guide, Microsoft 365
• 17 Agosto 2020

Il Cloud porta il focus della collaborazione sull’utente, liberandolo da molte limitazioni tecnologiche rispetto alle infrastrutture on-premises quali ad esempio la necessità di tunnel VPN per accedere alle risorse od i frequenti cambi password su Active Directory permettendo quindi una collaborazione a 360°.

Così come lo spostamento verso il Cloud è vantaggioso per gli utenti, lo è anche per la vastissima rete di partner di Microsoft che sviluppano soluzioni tecnologiche in grado di estendere le funzionalità di Office 365 / Microsoft 365. Gli utenti possono installare autonomamente queste soluzioni tramite gli Store che sono onnipresenti all’interno dell’ecosistema
365.

In questo articolo cercheremo di dare una visione completa degli Store presenti all’interno della soluzione di produttività di Microsoft spiegandone l’utilità ed esplorandone le possibilità di gestione.

Self-Service Sign-Up

Il Self-Service Sign-Up permette agli utenti di una organizzazione di attivare i servizi cloud in autonomia, indipendentemente dal fatto che l’utente esista o meno in Azure Active Directory oppure che il tenant abbia acquistato le licenze per uno specifico prodotto. Questo scenario è reso possibile da due controlli in Azure AD:

• AllowEmailVerifiedUsers: permette ad Azure AD di creare utenti tramite un processo di verifica tramite e-mail
• AllowAdHocSubscriptions: permette ad Azure AD di assegnare licenze di prodotto agli utenti che non hanno quel prodotto assegnato.

Prendiamo ad esempio un utente che riceva un documento crittografato tramite Azure RMS (il motore di Azure Information Protection): per poter accedere a questo documento è necessaria una licenza base di Azure RMS ed una identità in Azure AD per eseguire l’autenticazione. Tramite il Self-Service Sign-Up l’utente viene creato in Azure AD e gli viene assegnata una licenza automaticamente al primo utilizzo di Azure RMS rendendo così più immediato l’utilizzo del servizio e sgravando il reparto IT di questa incombenza.

Non tutte le organizzazioni vorranno acconsentire alla creazione automatica degli utenti in Azure AD perché avranno già dei sistemi di provisioning così come verosimilmente molte organizzazioni avranno delle regole per attribuire le licenze agli utenti. È possibile gestire questa funzionalità tramite Windows PowerShell ed il modulo MSOnline.

Le interazioni tra le due impostazioni sono spiegate nel digramma di flusso in Figura 1, l’impostazione predefinita è quella riportata qui sopra.

Figura 1 – Self-Service Sign-Up flow

Attenzione: alcuni servizi richiedono il Self-Service Sign-Up, almeno per quanto riguarda il loro setup iniziale, un esempio è Enterprise State Roaming. La prima volta che il primo utente utilizza ESR viene assegnata al tenant, come parte del processo di provisioning del servizio, una licenza Azure RMS dedicata. Disabilitando il Self-Service Sign-Up questo processo fallisce: il modo più facile per completare con successo il deployment di ESR è quello di modificare temporaneamente il parametro AllowAdHocSubscriptions a $True, lasciare terminare il provisioning di ESR e reimpostarlo a $False.

Le licenze che vengono assegnate tramite il processo di Self-Service Sign-Up sono riconoscibili nell’Admin Portal perché marchiate come in Figura 2.

Figura 2 – Subscription attivata in Self-Service Sign-Up

Self-Service Purchases

Il Self-Service Purchase permette agli utenti finali di acquistare tramite carta di credito servizi cloud all’interno del tenant della propria organizzazione. Gli utenti che sfruttano le funzionalità di Self-Service Purchase hanno accesso ad un Admin Center limitato che permette l’assegnazione e la gestione delle licenze ad altri utenti, come ad esempio può fare un responsabile con i suoi collaboratori. I servizi attualmente acquistabili sono:

• Power Apps per user
  
• Power Automate per user
  
• Power BI Pro
  
• Project Plan 1
  
• Project Plan 3
  
• Visio Plan 1
  
• Visio Plan 2
  

È possibile selezionare quali prodotti gli utenti sono autorizzate a comprare tramite Windows PowerShell ed il modulo MSCommerce, ogni prodotto è identificato da un suo Product ID, come in Figura 3.

Figura 3 – Modulo MSCommerce

Office Store

È possibile includere all’interno delle applicazioni Office degli Add-In in grado di estendere capacità dei client. Questi componenti possono essere scritti sia da Microsoft che da partner ed in virtù della loro capacità di interagire con il contenuto dei documenti in alcune realtà il loro uso deve essere regolamentato ai fini di compliance.

È importante notare che gli Add-In sono differenti dai componenti Visual Studio Tools for Office (VSTO) in quanto i VSTO sono disponibili solo per Windows e necessitano di una installazione locale mentre gli Add-Ins sono multipiattaforma e sono scritti in linguaggi web il cui supporto è universale.

Figura 4 – Add-Ins in Office

Per impostazione predefinita gli utenti possono visitare l’Office
Store da un qualsiasi client Office premendo sulla Ribbon Insert  Add-Ins

Figura 5 – Aggiunta Add-In

Oppure tramite Appsource

Figura 6 – Appsource

Per impedire agli utenti l’acquisizione di Add-Ins è necessario portarsi sull’Admin Center https://admin.microsoft.com e andare su Settings -> Org settings -> User owned apps and services e togliere il segno di spunta a “Let users access the Office Store” e premere su Save

Figura 7 – Inibire Office Store

Una volta inibito l’accesso all’Office Store i client Office visualizzeranno solamente gli Add-Ins approvati dall’Organizzazione

Figura 8 – Ristretto accesso all’Office Store

ed ogni tentativo di aggiunta dall’Appsource fallirà.

Figura 9 – Appsource ristretto

È possibile per gli amministratori distribuire gli Add-Ins tramite una funzione chiamata Centralized Deployment: è disponibile nell’Admin Center alla voce Add-ins la funzionalità per renderli disponibili nello Store aziendale oppure forzarne l’installazione.

Figura 10 – Centralized Deployment

Premendo su “Deploy Add-In” si aprirà un wizard nel quale sarà possibile scegliere un Add-In dal Office Store oppure caricarne uno sviluppato internamente.

Figura 11 – Aggiunta Add-In

Una volta scelto l’Add-In desiderato premere su Add

Figura 12 – Scelta Add-In

Per completarne la distribuzione è sufficiente scegliere gli utenti al quale distribuire l’Add-In e se deve essere installato obbligatoriamente.

Figura 13 – Inizio distribuzione Add-In

Ci possono volere fino a sei ore prima che l’Add-In appaia in tutti i client supportati dal componente.

Add-Ins per Outlook

Gli Add-Ins per Outlook sono governati da un processo differente, per essi è necessario modificare la Roles Assignement Policy in Exchange Online e rimuovere i ruoli:

• My Marketplace Apps: per disabilitare il download dall’Office Store
• My Custom Apps: per disabilitare la possibilità di eseguire l’upload di un plugin sviluppato personalmente (o scaricato da Internet)
• My ReadWriteMailbox Apps: per inibire i plugin con la capacità di manipolare il contenuto della mailbox

Per fare ciò è sufficiente collegarsi al Exchange Online Admin Center https://outlook.office.com/ecp e selezionare la policy da modificare portandosi su permissions -> user roles

Figura 14 – Roles Assignment Policy

E modificare la policy come desiderato

Figura 15 – Policy modificata

Per Outlook è disponibile un Group Policy Object per nascondere il pulsante Office Store dalla Ribbon: portandosi su User Configuration -> Microsoft Outlook 2016 -> Outlook Options -> Other ->Hide the Office Store button sarà possibile scegliere di nascondere il bottone agli utenti. È in ogni caso necessario modificare la Role Assignment Policy in quanto è ancora possibile installare gli Add-Ins da Outlook On the Web.

Figura 16 – GPO per disabilitare Office Store in Outlook

App Catalog di SharePoint Online

Uno dei punti di forza di SharePoint Online è quello di avere accesso ad un ecosistema di partner immenso che negli anni hanno sviluppato una quantità impressionante di applicazioni integrabili all’interno dei Siti di SharePoint. Per impostazione predefinita qualsiasi utente può integrare applicazioni di terze parti all’interno delle Site Collection in SharePoint Online, questa scelta è voluta per dar maggior risalto all’ecosistema ed abilitare gli utenti a svolgere il loro lavoro con gli strumenti che li sono più congeniali. Alcune organizzazioni per motivi di compliance devono però essere in grado di limitare questa possibilità, per questo SharePoint Online permette di istituire un catalogo aziendale delle Apps tramite il quale gli utenti possono richiedere le applicazioni che preferiscono lasciando al reparto IT la scelta se approvarle oppure no.

Per creare l’App Catalog è necessario andare sullo SharePoint Online Admin Center e premere su More Features -> Apps

Figura 17 – SharePoint Online Admin Center

Selezionare quindi App Catalog

Figura 18 – Picker opzioni App Catalog

Selezionare l’opzione “Create a new app catalog site” per procedere alla creazione di un nuovo App Catalog

Figura 19 – Creazione nuovo App Catalog

Fornire i dettagli richiesti per la creazione dell’App Catalog e premere su OK

Figura 20 – Dettagli App Catalog

Dopo qualche istante, per il quale si dovrà pazientare senza premere OK nuovamente, si verrà rediretti al sito appena creato.

Figura 21 – App Catalog creato

Una volta creato l’App Catalog è necessario attendere circa 30 minuti prima che le altre opzioni nella pagina Apps in Figura 18 siano configurabili. Dalla pagina Apps portarsi quindi su “Configure Store Settings” e disabilitare l’acquisto di App da parte degli utenti

Figura 22 – Opzioni acquisto App

A questo punto se un utente prova ad acquistare un App sarà soggetto all’approvazione da parte dell’amministratore

Figura 23 – Richiesta nuova App

Il quale potrà decidere se confermarla oppure negarla

Figura 24 – Triage richiesta App

Apps in Microsoft Teams

Anche in Microsoft Teams è possibile inserire delle applicazioni all’interno dei Team creati dagli utenti, molte delle quali sono integrazioni esterne a Microsoft 365. Benché questo sia un grosso punto di forza della piattaforma è una funzionalità che va regolamentata in maniera puntuale in quanto l’applicazione esterna può avere accesso ai contenuti del Gruppo di Microsoft 365 sottostante al Team.

Portandosi sull’Admin Center di Microsoft Teams https://admin.teams.microsoft.com e andando su Teams apps -> Permission policies e selezionando la policy desiderata

Figura 25 – Teams permission policy

È possibile restringere le Apps disponibili per l’integrazione con i Teams: come regola generale le Apps Microsoft sono integrazioni con il resto di Office 365 pertanto è consigliato tenerle abilitate per la massima funzionalità mentre le Apps di terze parti vanno abilitate se nell’Organizzazione vengono utilizzati prodotti di un fornitore terzo che beneficiano dell’integrazione con Microsoft Teams. Le Custom apps sono Apps sviluppate internamente.

Figura 26 – Modifica permission policy

Il risultato è che l’utente finale è in grado di visualizzare ed aggiungere al Team solo le Apps permesse

Figura 27 – Gallery ristretta

Office 365 Groups Connectors

I connettori dei Gruppi di Office 365 non sono propriamente delle Apps ma meritano una menzione particolare in quanto poco conosciuti, nonostante siano presenti fin dal 2016.

Nella loro implementazione originale gli ora Microsoft 365 Groups si chiamavano Groups in Outlook e il centro della collaborazione non era Microsoft Teams (che non esisteva ancora) ma bensì Outlook. È ancora oggi possibile creare un Microsoft 365 Group partendo da Outlook ed in questo modo tramite il client di posta si avrà accesso alla cassetta postale condivisa sottostante al gruppo. È anche possibile ottenere questo risultato modificando un qualsiasi gruppo tramite PowerShell (la cassetta postale condivisa viene sempre creata per ragioni di compliance, anche quando è nascosta).

Figura 28 – Connettori nei Gruppi di Office 365

Utilizzando Outlook On the Web è possibile agganciare a questa cassetta postale un connettore in grado di, ad esempio, leggere un Feed RSS e per ogni nuovo elemento creare un post all’interno del Gruppo.

Figura 29 – Aggiunta connettore

Per quanto riguarda i connettori l’unica gestione possibile è la loro disabilitazione per Microsoft 365 Groups specifici oppure per l’intera Organizzazione.

Siccome la loro funzione è quella di integrare informazioni nei Gruppi da sistemi terzi, essi non esportano informazioni all’esterno del Gruppo quindi non rappresentano un rischio maggiore dal punto di vista della compliance.

Conclusioni

Le integrazioni con applicazioni esterne sono una componente interessante per la suite Microsoft 365 ma rappresentano una sfida per i reparti IT nel mantenere il controllo del loro ambiente.

In questo articolo abbiamo visto come è possibile gestire queste integrazioni, permettendo quelle approvate dal reparto IT.

È possibile utilizzare Microsoft Cloud App Security per ottenere una visibilità superiore nelle applicazioni SaaS, ne abbiamo parlato nell’articolo Controllare l’adozione del Cloud tramite Microsoft Cloud App Security.