RBAC, Policy e Resource Lock: come si incastra la governance di Azure

Studiando per l'AZ-900, questi tre continuavano a confondersi tra loro per me. Riguardano tutti la restrizione di qualcosa, vengono tutti descritti come governance, e leggerne separatamente li faceva sembrare tre versioni della stessa feature.

Non lo sono. Ognuno risponde a una domanda diversa, e una volta chiare le domande, la distinzione ha smesso di confondermi.

RBAC risponde a "chi può fare questo?"

Il Role-Based Access Control riguarda l'identità. Una persona o un servizio riceve una role, quella role ha permessi, e si applica a uno scope particolare.

La parte dello scope era quella che inizialmente mi sfuggiva. Un'assegnazione di role non è globale, è attaccata a un livello: un management group, una subscription, un resource group, o una singola resource. Assegna a qualcuno il ruolo Contributor su un resource group e potrà fare cose da contributor su tutto ciò che c'è dentro, ma niente al di fuori.

Tre role integrate coprono la maggior parte di quello che ti aspetteresti:

• Owner può fare tutto, incluso concedere accesso ad altre persone
• Contributor può creare e gestire resource, ma non può concedere accesso
• Reader può guardare e non toccare

La distinzione tra Contributor e Owner è quella interessante. Poter gestire ogni resource in una subscription e poter passare quella capacità a qualcun altro sono poteri genuinamente diversi, e separarli è ciò che rende il least privilege effettivamente praticabile.

Azure Policy risponde a "questo ha il permesso di esistere?"

Policy non riguarda affatto le persone, ed è questo che alla fine l'ha separata da RBAC nella mia testa. Valuta le resource rispetto a delle regole indipendentemente da chi le sta creando.

Un Owner ha pieno permesso di creare resource. Una policy che dice "le virtual machine possono essere create solo in queste region" le fermerà comunque, perché la policy non controlla i permessi, controlla la resource stessa.

Esempi tipici: restringere quali region si possono usare, richiedere tag specifici sulle resource, bloccare dimensioni di VM costose, imporre che gli storage account richiedano encryption.

Policy può anche solo segnalare invece di bloccare. Una policy in modalità audit segnala resource non conformi senza impedirle, il che è come scopri quanto è messo male un ambiente esistente prima di iniziare a imporre qualcosa e rompere le cose.

I resource lock rispondono a "questo dovrebbe essere cancellabile?"

I lock sono i più semplici dei tre e quello che avrei scartato come poco importante. Esistono per gli incidenti, non per gli attaccanti.

Due tipi:

• CanNotDelete permette modifiche ma blocca la cancellazione
• ReadOnly blocca sia le modifiche sia la cancellazione

La cosa fondamentale è che un lock si applica a tutti, incluso un Owner. Qualcuno con permessi completi che lancia il comando di delete sbagliato viene comunque fermato. Il che è esattamente il punto, dato che la persona più capace di cancellare per errore un database di produzione è qualcuno con il permesso di cancellarlo.

Per cancellare davvero una resource bloccata devi prima rimuovere il lock, deliberatamente, come azione separata. Quel passo in più è l'intera feature.

Perché tutte e tre, e non solo una

Messe insieme, coprono fallimenti che le altre non possono coprire.

RBAC impedisce a qualcuno di fare qualcosa che non dovrebbe poter fare affatto. Non può impedire a una persona autorizzata di fare qualcosa di autorizzato ma sbagliato.

Policy blocca resource che non dovrebbero esistere nella forma in cui sono, indipendentemente da chi le crea. Non può impedire a qualcuno di cancellare qualcosa che esiste già ed è conforme.

I lock impediscono la distruzione accidentale da parte di persone che hanno davvero il permesso. Non limitano chi ha il permesso in primo luogo.

Ecco perché sono tre feature invece di una. Non sono strati della stessa restrizione, sono risposte a tre modi diversi in cui le cose vanno storte.

Dove questo si collega alla scrittura del codice

L'idea del least privilege è la stessa che applico già in un'applicazione, ed è ciò che ha fatto sembrare RBAC familiare invece che nuovo. Un account database a cui la mia API si connette non dovrebbe avere il permesso di droppare tabelle, per lo stesso motivo per cui uno sviluppatore non dovrebbe avere Owner su una subscription di produzione: non perché mi aspetti che ne abusino, ma perché il permesso stesso è ciò che rende possibile l'incidente.

Azure lo rende solo esplicito, con role e scope che puoi davvero ispezionare, invece che viva in una connection string che nessuno rivede.