Chapter 4: Access control Flashcards
(21 cards)
Quando viene creato un file su Unix comʼè fatto il suo inode?
Quabdo viene creato un file il suo inode avrà i seguenti metadati:
- Tipo di file
- Permessi di accesso
- Owner e group ID
- Timestamp
- Dimensione del file
- Numero di link (hard link)
- Puntatori ai blocchi di dati
Un inode per i permessi è composto da 9 bit che rappresentano a coppie di 3: read write execute
I primi 3 sono i permessi che ha lʼutente che ha creato il file, poi il group appartentente e poi other.
Di base viene sempre garantita la lettura e all’utente la scrittura.
Cosʼè il Consolidate Model nella Role Based Access Control?
È il modello in cui il modello base della Role Based Access Control viene arricchito con il modello che supporta i Constraint e il modello che supporta la Role Hierarchy.
È noto anche come RBAC3 perché va a fondere le versioni precedenti, garantendo:
- Flessibilità
- Sicurezza migliorata
- Scalabilità
- Conformità normativa
Il Consolidated Model (RBAC3) rappresenta l’approccio più completo e robusto al controllo degli accessi basato sui ruoli.
A cosa servono i Constraint nella Role Based Access Control?
I constraint (vincoli) sono regole che limitano o condizionano l’assegnazione e l’attivazione dei ruoli, al fine di rafforzare la sicurezza e garantire il rispetto delle politiche organizzative. Alcuni dei più comuni sono ad esempio:
- Un utente può solo essere assegnato a un solo ruolo del set di ruoli (che sia per una sola sessione o sempre)
- Un permesso specifico può essere assegnato a un solo ruolo.
Cosʼè un utente superuser nellʼambiente Unix?
È lʼutente amministratore del sistema. Può fare tutto, non ha vincoli sulle autorizzazioni. Questo account è comunemente chiamato root e ha un identificatore utente (UID) pari a 0, che conferisce il massimo livello di autorizzazione all’interno del sistema.
Cosʼè una ACL (Access Control List)? In che policy di Access Control viene utilizzata?
Una Access Control List ACL è un meccanismo di sicurezza informatica che definisce quali utenti o processi possono accedere a una risorsa specifica e quali operazioni possono eseguire su di essa. Ogni voce in un’ACL, chiamata Access Control Entry (ACE), specifica un soggetto (utente o gruppo) e i relativi permessi, come lettura,
scrittura o esecuzione.
Le ACL sono comunemente associate al modello DAC Discretionary Access Control), in cui il proprietario di una
risorsa ha la facoltà di definire le autorizzazioni di accesso per altri utenti.
Tuttavia, le ACL possono essere impiegate anche in altri modelli di controllo degli accessi, come il MAC o RBAC
Cosa significa Role Hierarchy? Perché è utile? A cosa serve?
Si tratta del modello di base del Role Based Access Control a cui vengono aggiunti meccanismi particolari per quanto riguarda la gerarchia dei ruoli. In unʼorganizzazione tipicamente ci sono posizioni più in alto nella scala gerarchica che hanno più permessi di chi sta più in basso. Tramite la role hierarchy è possibile creare un nuovo ruolo che ne estende un altro. Questo nuovo ruolo avrà già di base i permessi che ha quellʼaltro, ma si possono overridare e crearne di nuovi.
Che differenza cʼè tra authentication, authorization e audit?
Authentication → verificare che le credenziali fornite dallʼutente per accedere al sistema siano valide
Authorization → dopo essere autorizzati da un sistema per poter maneggiare un determinato asset, serve l’authorization per capire chi è autorizzato a fare cosa
Audit → consiste nel monitorare e registrare le attività degli utenti all’interno del sistema, fondamentali per
registrare le attività, rilevare comportamenti anomali e garantire conformità, i log generati durante l’audit sono
strumenti essenziali per la sicurezza e la gestione del sistema.
Cosa sono soggetto, oggetto e diritto di accesso nellʼAccess Control?
- Soggetto: Unʼentità capace di accedere ad oggetti. Si può suddividere in Owner, Group, Others (“il resto del mondoˮ).
- Oggetto: Una risorsa il cui accesso è controllato. Generalmente un oggetto rappresenta unʼentità in grado di contenere, ricevere e mostrare informazioni.
- Access Right: Un access right descrive il modo in cui dei soggetti accedono agli oggetti. Posso includere cose come read, write , ecc.
Cosʼè una matrice degli accessi? In che policy viene utilizzata? Cosa sta sulle righe? Cosa sulle colonne?
Una matrice degli accessi (Access Control Matrix) è un modello teorico utilizzato nei sistemi di sicurezza informatica per rappresentare e gestire i diritti di accesso degli utenti (soggetti) alle risorse del sistema (oggetti). La matrice è organizzata come segue:
- Righe: corrispondono ai soggetti, ovvero entità attive come utenti, processi o ruoli che richiedono accesso alle risorse.
- Colonne: rappresentano gli oggetti, cioè le risorse del sistema come file, database, dispositivi o servizi.
- Celle: ogni cella nella matrice specifica i diritti di accesso che un soggetto ha su un oggetto.
La matrice degli accessi è un modello fondamentale nelle politiche di controllo degli accessi, in particolare:
- DAC (Discretionary Access Control)
- MAC Mandatory Access Control)
- RBAC Role-Based Access Control)
Sebbene la matrice degli accessi sia un modello teorico, nella pratica vengono utilizzate strutture derivate per gestire le autorizzazioni in modo più efficiente:
- Access Control Lists ACLs): per ogni oggetto, viene mantenuta una lista di soggetti e i relativi permessi.
- Capability Lists: per ogni soggetto, viene mantenuta una lista di oggetti e i relativi permessi. Questo è utile quando ci sono molti soggetti e relativamente pochi oggetti.
Cosʼè una Authorization Table? È una buona struttura dati per rimpiazzare ACL e Capability Ticket? Come funziona?
Un authorization table contiene una riga per ogni user access right a una determinata risorsa del sistema.
Ordinare o accedere per soggetto ha lo stesso peso delle capability list. Accedere per oggetti ha lo stesso peso delle ACL. Quindi sì, è un buon compromesso, veramente figa e pure semplice.
La Authorization Table, essendo una lista di triple, permette di effettuare query efficienti sia per soggetto che per oggetto, offrendo quindi una maggiore flessibilità.
Che policy possono essere applicate per lʼAccess Control?
Esistono diversi modelli per implementare le Access Control Policies, ciascuno con caratteristiche specifiche:
- DAC (Discretionary Access Control)
- MAC (Mandatory Access Control)
- RBAC (Role-Based Access Control)
- ABAC (Attribute-Based Access Control)
Cosʼè un Capability Ticket? In che policy di Access Control viene utilizzato?
Un Capability Ticket è un token o una struttura dati che conferisce al suo possessore il diritto di accedere a un
oggetto specifico con determinati permessi
Un Capability Ticket è una forma di autorizzazione che combina due elementi principali:
- Identificatore dell’oggetto
- Diritti di accesso
Qual è il problema del tradizionale approccio Unix dellʼAccess Control?
Il tradizionale modello di controllo degli accessi in Unix, basato su permessi di lettura, scrittura ed esecuzione per proprietario, gruppo e altri utenti, presenta diverse limitazioni che possono compromettere la sicurezza e la flessibilità del sistema:
- Privilegi illimitati del superuser (root)
- Controllo discrezionale degli accessi (DAC): non fornisce un controllo centralizzato o obbligatorio, rendendo difficile l’applicazione coerente
delle policy di sicurezza in ambienti complessi.
- Permessi limitati e rigidi
- Difficoltà nella separazione dei compiti, mancanza di un controllo degli accessi basato sui ruoli (RBAC)
- Gestione complessa dei gruppi, Ogni file può avere un solo gruppo associato.
- Mancanza di tracciabilità e auditing.
Quante matrici ci sono nella Role Based Access Control? Quali sono? Come sono fatte?
Sono 2, la matrice dei ruoli assegnati agli utenti e la matrice delle autorizzazioni assegnate ai ruoli. La prima ha gli utenti sulle righe e i ruoli sulle colonne. Nella seconda matrice sulle righe ci sono i ruoli, sulle colonne le risorse.
Unix supporta le ACL? Se sì come funzionano?
Alcune versioni di UNIX supportano le ACL, come per esempio OpenBSD e FreeBSD. Non è tuttavia un meccanismo esistente in tutte le versioni di UNIX. È comunque implementabile ovunque. Funzionano come le ACL.
Per utilizzare le ACL, è necessario che il file system supporti questa funzionalità e che sia montato con l’opzione “acl”. Ad esempio, i file system ext3, ext4 e XFS supportano le ACL, ma potrebbe essere necessario abilitare esplicitamente questa opzione nel file “/etc/fstab” o durante il montaggio del file system.
Perché utilizzare tante ACL e non solo una semplice matrice per gestire gli accessi? Cosa invece è sconveniente utilizzando una ACL?
La matrice degli accessi è una rappresentazione teorica che associa ogni soggetto (utente o processo) a ogni oggetto (risorsa) con i relativi permessi. Tuttavia, in sistemi reali con numerosi utenti e risorse, questa matrice diventa rapidamente enorme e in gran parte vuota, rendendola inefficiente da memorizzare e gestire. Per affrontare questo problema, si adottano implementazioni più pratiche come:
- Access Control List (ACL): associa a ogni oggetto una lista di soggetti autorizzati e i relativi permessi.
- Capability List: associa a ogni soggetto una lista di oggetti a cui può accedere e i relativi permessi.
Utilizzare molte ACL, una per ogni risorsa, consente di gestire i permessi in modo più efficiente e scalabile, evitando la necessità di mantenere una matrice completa e spesso sparsamente popolata. Nonostante i vantaggi, le ACL presentano alcune limitazioni:
- Gestione complessa in ambienti dinamici: in sistemi con frequenti cambiamenti di utenti e ruoli, mantenere aggiornate tutte le ACL può diventare oneroso.
- Mancanza di visione centralizzata: poiché le ACL sono distribuite tra le risorse, è difficile ottenere una panoramica completa dei permessi di un utente su tutte le risorse.
- Difficoltà nell’implementare politiche basate su attributi o ruoli: le ACL non si adattano facilmente a modelli di controllo degli accessi più avanzati come RBAC (Role-Based Access Control) o ABAC (Attribute-Based Access Control).
Cosʼè un ruolo nella Role Based Access Control?
Un ruolo è definito come una funzione di lavoro allʼinterno di una organizzazione. In questa Policy i permessi vengono assegnati ai ruoli invece che agli utenti. Agli utenti vengono invece assegnati dei ruoli e assumono autorizzazioni in base al ruolo.
Perché utilizzare dei Capability Ticket e non solo una semplice matrice per gestire gli accessi ai file? Cosa invece è sconveniente utilizzando un Capability Ticket?
Vantaggi:
- Decentralizzazione: riduce la necessità di una gestione centralizzata dei permessi.
- Efficienza: la verifica dell’accesso è rapida, basandosi sul possesso della capability.
- Flessibilità: facilita la delega dei diritti di accesso tra soggetti.
Svantaggi:
- Gestione delle revoche: revocare una capability può essere complesso, specialmente se è stata delegata.
- Sicurezza: è essenziale proteggere le capability da accessi non autorizzati o duplicazioni.
Cosʼè una Access Control Policy?
Una Access Control Policy è un insieme di regole e criteri che definiscono chi può accedere a determinate risorse digitali o fisiche, in quali circostanze e con quali privilegi.
Le politiche di controllo degli accessi mirano a:
- Proteggere le informazioni sensibili: Evitando accessi non autorizzati a dati riservati.
- Garantire la conformità normativa: Assicurando che l’organizzazione rispetti leggi e regolamenti sulla protezione dei dati.
- Prevenire minacce interne ed esterne: Limitando le possibilità di accesso non autorizzato da parte di
dipendenti o attaccanti esterni.
- Facilitare la gestione degli accessi Attraverso l’automazione e la standardizzazione delle autorizzazioni.
Cosʼè un inode su Unix? A cosa serve una inode table?
Un inode (index node) è una struttura dati utilizzata dai sistemi Unix e Unix-like per rappresentare le informazioni metadati di un file e i puntatori al disco dove sono salvati i suoi contenuti.
Gli attributi di un
file così come i permessi e altre informazioni di controllo sono contenute nellʼinode. Sul disco è presente una
inode table o una inode list che contiene tutti gli inode di tutti i file del sistema. Quando un file viene acceduto
lʼinode corrispondente viene caricato in memoria temporanea in una struttura apposita per poter essere utilizzato
(IMPORTANTE per capire) Nel contesto Unix:
- Un file è un nome in una directory che punta a un inode all’interno della ino0de table.
- L’inode è ciò che rappresenta veramente il contenuto del file (metadati + puntatori ai dati).
Quali caratteristiche deve avere un ruolo(Role Based Access Control)?
- Definizione basata sul compito: Un ruolo è associato a un insieme di responsabilità lavorative. Ad esempio, un “Contabile” avrà accesso ai sistemi finanziari, mentre un “Sviluppatore” avrà accesso agli ambienti di sviluppo.
- Assegnazione di permessi: I permessi (ad esempio, leggere, scrivere, modificare) sono assegnati ai ruoli, non direttamente agli utenti. Quando un utente riceve un ruolo, acquisisce automaticamente i permessi associati a quel ruolo.
- Separazione dei compiti: Il modello RBAC supporta la separazione dei compiti, assicurando che nessun individuo possa eseguire operazioni critiche senza supervisione. Ad esempio, una persona non dovrebbe essere in grado di creare un account e autorizzare la creazione dello stesso account.
- Gerarchia dei ruoli: I ruoli possono essere organizzati in una gerarchia, dove i ruoli di livello superiore ereditano i permessi dei ruoli inferiori. Ad esempio, un “Manager” potrebbe avere tutti i permessi di un “Dipendente” più ulteriori privilegi.
- Gestione centralizzata: RBAC consente una gestione centralizzata degli accessi. Modifiche ai permessi di un ruolo si riflettono automaticamente su tutti gli utenti assegnati a quel ruolo, semplificando l’amministrazione.
- Conformità e auditabilità: Il modello facilita la conformità a normative e standard di sicurezza, poiché offre una chiara tracciabilità delle autorizzazioni e delle modifiche agli accessi.
