Griglie & Sicurezza. Introduzione a GSI Grid Security Infrastructure

Transcript

1 Griglie & Sicurezza Introduzione a GSI Grid Security Infrastructure Lorenzo Falciani 11/05/

2 Indice Parte 1. Griglie Computazionali (richiamo) Parte 2. Sicurezza (definizione ed obbiettivi) Parte 3. GSI: Grid Security Infrastructure Parte 4. Globus: un implementazione open

3 Parte 1 Griglie Computazionali Un richiamo

4 Griglie, un esempio operativo

5 Definizione di griglia Infrastruttura per una condivisione flessibile, coordinata e sicura di risorse tra gruppi dinamici di individui e istituzioni detti Virtual Organization (VO).

6 Grid Protocol Architecture (modello hourglass) Applicazioni utente Protocolli e servizi globali (collector ) e quelli coinvolti nelle interazioni tra gruppi di risorse ex: Resource Discovery, Brokering & System Monitoring Protocolli per la negoziazione ed il controllo delle operazioni di condivisione su risorse individuali Protocolli per l autenticazione e la comunicazione usati per le transazioni delle griglie ex: Transport, routing, naming Le risorse condivise tramite la griglia ex: Risorse computazionali, Database, Risorse di rete, Sensori,

7 Scenario multi-vo

8 Parte 2 Sicurezza: definizione ed obiettivi

9 Sicurezza: proprietà sistemica, strutturale e supplementare Si occupa di garantire: Disponibilità delle risorse fisiche Disponibilità delle risorse logiche Integrità Confidenzialità Cioè che un sistema informatico non possa essere controllato da altri

10 2 categorie di attacchi Attacchi basati su debolezze strutturali Specifiche non corrette Specifiche corrette ma vulnerabili Attacchi basati su errori Codifica non corretta Configurazione non corretta

11 La sicurezza dipende dalla robustezza, non dalla correttezza Correttezza discreta, 0 o 1 Robustezza continua [0,1) La robustezza può solamente tendere ad uno asintoticamente È inversamente proporzionale alle ipotesi necessarie

12 Regola fondamentale per la sicurezza: KISS KEEP IT SIMPLE STUPID 2 Approcci per aumentare la robustezza: Single point of failure Proactive sistem

13 Primo principio di Denning La matrice di protezione deve definire un ambiente di cooperazione chiuso default deny (diritti funzionali SI, gerarchici NO) il security kernel deve garantire una mediazione completa

14 Secondo principio di Denning least privilege i privilegi devono essere dinamici la matrice di protezione deve essere dinamica

15 Terzo principio di Denning Verifica delle risorse indipendente da errori un soggetto opera su un oggetto solamente tramite le operazioni specificate dalla matrice di protezione non deve essere possibile violare la matrice di protezione operando ad un livello di astrazione diverso

16 Quarto principio di Denning Verifica delle decisioni indipendente da errori anche i controlli sono soggetti ad attacchi ripetendo i controlli diminuisce la probabilità di un attacco ai controlli

17 Parte 3 G.S.I. Grid Security Infrastructure

18 Sicurezza delle Griglie: Fattori 1. I programmi vengono eseguiti su più nodi (anche in differenti domini amministrativi) 2. Le risorse sono cotrollate da domini amministrativi diversi 3. Allocazione e rilascio dinamici delle risorse 4. Delega dei permessi tra soggetti 5. Collaborazioni su scala variabile

19 Requisiti di Sicurezza 1. Autenticazione unica ( single sign on ) e delega 2. Protezione delle credenziali 3. Interoperabilità con le policy di sicurezza ( e le leggi ) locali 4. Infrastruttura uniforme per la gestione delle credenziali/certificazioni 5. Supporto per la comunicazione sicura tra gruppi (di processi) 6. Supporto per architetture hardware/software diverse 7. Supporto per privilegi fine-grained: autenticazione user-to-resource, resource-to-user, process-to-resource, process-to-process

20 Caratteristiche dell autenticazione Si devono risolvere due problemi solitamente non presi in considerazione dalle tecnologie di autenticazione più comuni: 1. Supporto per la local heterogeneity 2. Supporto per contesti di sicurezza N-way per la creazione di relazioni di sicurezza tra processi qualsiasi ( purchè parte di una computazione )

21 GSI GSI implementa l autenticazione single sign-on, la delega delle credenziali utente ai programmi applicativi e il controllo locale sulle autorizzazioni GSI è implementata sulle specifiche delle GSS-API ( Generic Security Services application programming interface )

22 GSS-API Definiscono una procedura standard ed una API per l acquisizione delle credenziali (passwords o certificati), per la mutua autenticazione (client e server) e per la crittazione/decrittazione dei messaggi, supportano il single sign-on ed utilizzano l ITU X.509. Sono indipendenti sia dal mezzo di trasporto che dai meccanismi necessari a realizzare le operazioni definite

23 Grid Security Policy 1/2 1. La griglia è costituita da più trust domains 2. Operazioni confinate in un singolo trust domain sono soggette solamente alle policy di sicurezza locale 3. Esistono sia soggetti locali che globali. Per ogni trust domain c è una mappatura parziale dei soggetti da globale a locale 4. Le operazioni tra entità locate in trust domain diversi richiedono la mutua autenticazione

24 Grid Security Policy 2/2 5. Un soggetto globale mappato in uno locale è considerato autenticato nella stessa maniera di un soggetto locale 6. Tutte le decisioni dei controlli di accesso sono fatte localmente sulle basi dei soggetti locali 7. Un programma o processo è abilitato ad operare per un utente e ad avere delegati un subset dei diritti dell utente 8. I processi in esecuzione per lo stesso soggetto all interno dello stesso trust domain possono condividere un singolo set di credenziali

25 Pericoli 1) Attacchi ai servizi di rete della Griglia 2) Codice utente vulnerabile, escalation dei privilegi di utenti autenticati, Accessi non autenticati guadagnati tramite i jobs o codice errato 3) Commodity code vulnerabile (servizi, librerie): httpd, ftpd, SOAP, sshd, LDAP, SSL, etc.. 4) Utilizzo degli account alla Griglia non autorizzato o non autenticato

26 Contromisure 1) No logins in chiaro, No logins anonimi, Logging and audit di tutte le transazioni 2) Stack e heap non-eseguibili nell OS, librerie wrappate e/o sandboxing, No percorsi verso shell/exec, Controlli su comportamenti anomali 3) Identificazione ed analisi dei protocolli

27 Grid Security Architecture 1/2 Un architettura è determinata specificando soggetti, oggetti e i protocolli usati quando i soggetti e gli oggetti interagiscono Soggetti: utenti, processi [U], [P] Oggetti: qualsiasi risorsa disponibile Un user proxy è un processo session manager che ha ricevuto in delega i permessi dell utente (creato localmente) [UP] Un resource proxy è un agente usato per trasporre le operazioni di sicurezza globali (interdomain) nei meccanismi locali (intradomain) [RP]

28 Grid Security Architecture 2/2 Si devono definire i protocolli per controllare le seguenti interazioni: U-UP - per creare un User Proxy (ex: per loggarsi nella Griglia) UP-RP - usato nella comunicazione tra Proxy (ex: per allocare risorse) P-RP - per dialogare direttamente con il Resource Proxy (ex: per allocare risorse addizionali direttamente) P-P - per la comunicazione processo-processo (ex: usato per mappare un soggetto da globale a locale)

29 Relazione tra GSS-API e GSP

30 GSP in azione

31 Protocol 1 (U-UP) User proxy creation 1. L utente si logga sul computer sul quale sarà creato l user proxy, usando il meccanismo di autenticazione locale 2. L utente cre le credenziali per l user proxy (Cup) usando le sue (Cu) per firmare una tupla contenente le informazioni richieste dal protocollo di autenticazione usato per implementare l architettura per esempio: Cup = {user-id,host,start-time,end-time,auth-info,...} 3. Viene creato un processo user proxy con a disposizione Cup. A questo punto è compito delle policy di sicurezza locali proteggere l integrità di Cup

32 5. Il resource proxy manda in maniera sicura le RESOURCE-CREDENTIALS all user proxy Protocol 2 (UP-RP) Resource Allocation Protocol 1/2 1. L user proxy ed il resource proxy si autenticano l un l altro usando Cup e Crp 2. L user proxy manda al resource proxy una richiesta firmata della forma: SIGup{allocation specification} 3. Il resource proxy controlla la firma SIG con la policy locale 4. Se la richiesta può essere soddisfatta il resource proxy crea una tupla RESOURCE-CREDENTIALS contenente l username dell utente richiedente, il nome della risorsa, etc...

33 Protocol 2 (UP-RP) Resource Allocation Protocol 2/2 6. L user proxy esamina la richiesta RESOURCE-CREDENTIALS e (se la approva) firma la tupla e produce Cp, una credenziale per richiedere la risorsa 7. L user proxy manda Cp al resource proxy in maniera sicura 8. Il resource proxy alloca la risorsa e passa Cp al/i nuovo/i processo/i

34 Protocol 3 (P-RP) Resource Allocation from a Process Protocol 1. Il processo e l user proxy si autenticano l un l altro con Cp e Cup 2. Il processo man da una richiesta firmata al proxy nella forma: SIGp { "allocate", allocation request parameters... } 3. Se l user proxy decide di soddisfare la richiesta, manda una richiesta di allocazione risorse al resource proxy specifico usando il protocollo 2 4. L handle del processo risultante viene quindi firmato dall user proxy e rimandato al processo richiedente

35 Protocol 4 (P-P) Mapping Registration Protocol 1/2 Global auth: 1.a L user proxy si autentica con il resource proxy. 1.b L user proxy invia una richiesta MAP-SUBJECT-UP firmata al resource proxy, includendo come argomenti il suo nome globale e quello della risorsa richiesta Resources auth: 2.a L utente si logga alla risorsa usando il metodo di autenticazione della risorsa ed inizia un processo di tipo map registration 2.b Il processo map registration invia una richiesta MAP-SUBJECT-P al resource proxy, aggiungendo come argomenti il nome globale e quello della risorsa

36 Protocol 4 (P-P) Mapping Registration Protocol 2/2 1. Il resource proxy aspetta delle richieste MAP-SUBJECT-UP e MAP-SUBJECT-P con argomenti giusti 2. Il resource proxy si assicura che il processo map registration sia associato al soggetto specificato nella richiesta di mappatura 3. Se viene trovata una corrispondenza, il resource proxy mappa la risorsa ed invia un acknowledgment sia al processo map registration che all user proxy 4. Se entro MAP-TIMEOUT non viene trovata una corrispondenza, il resource proxy scarta la richiesta e manda una acknowledgment all entità in attesa 5. Se non viene ricevuto alcun acknowledgment entro MAP-TIMEOUT, la richiesta è considerata fallita

37 Parte 4 Globus e GT3-GSI

38 What is Globus? Globus è un AWARE (Adaptive Wide Area Resource Environment), un set integrato di servizi ad alto livello che rendono possibile alle applicazioni di adattarsi a strutture di metacomputing eterogenee e dinamiche

39 Globus Security Policy Autenticazione La mutua autenticazione è basata sulla crittografia a chiave pubblica ed utilizza dei certificati 509.v3 per mantenere e gestire le chiavi pubbliche nell MDS (accessibili via LDAP) to do: support for N-way security contexts and P->RP auth. Confidenzialità/Privacy Garantita tramite la crittazione dei contenuti dei messaggi grazie all applicazione di algoritmi di cifratura come DES, 3-DES, RC2 o RC4. Integrità dei dati Assicurata dall applicazione di un sicuro (one-way) algoritmo di hashing come MD2, MD4, MD5 or SHA-1 che produce un hash di dimensione fissa in seguito crittato con la chiave privata del mandante usando un algoritmo di firma digitale come DSA Autorizzazione Basata su i principali attributi come ruolo, identità, gruppo e permessi

40 GT3-GSI in action

41 GT3-GSI steps 1/2 1. The user generates a job instantiation request with a description of the job to be started. The user then signs this request with their GSI proxy credentials and sends the signed request to the Master Managed Job Factory Service (MMJFS) on the resource. 2. The MMJFS verifies the signature on the request and establishes the identity of the user who sent it. It then determines the local account in which the job should be run. Currently this is done by using the grid-mapfile and user's grid identity. 3. Assuming the user does not already have a Local Managed Job Factory Service (LMJFS) running in their account, the MMJFS invokes the setuid starter process to start one. The setuid starter is a setuid program that has the sole function of starting LMJFS in user's account.

42 6. The user then connects to the MJS. The user and MJS then perform mutual authentication, the user using their proxy and the MJS using the credentials acquired from GRIM. The MJS authorizes the user as a valid user to access the local account it is running in. The user authorizes the MJS as having a credential issued from a appropriate host credential and containing a Grid identity matching it's own, thus verifying the MJS it is talking to is running not only on the right host, but in an appropriate account. The user would then delegate GSI credentials to the MJS for the job to use and start the job running GT3-GSI steps 2/2 1. Once the LMJFS starts up, it uses the Grid Resource Identity Mapper (GRIM) to acquire a set of credentials. GRIM is a setuid program that accesses the local host credentials and from them generates a proxy for the LMJFS. This proxy credential has embedded in it the user's Grid identity, local account name and local policy about the user. 2. The MMJFS then forwards the signed job instantiation request from the user to the LMJFS. The LMJFS verifies the signature on the request to make sure it has not been tampered with and to make sure it was created by a user that is authorized to run in the local user account. Once these checks are successfully completed, the LMJFS invokes a Managed Job Service (MJS) with the request and returns the address of the MJS to the user.

43 GT3 GSI Improvements Proxy Certificates format Added support for both impersonation and independent proxy certificates. Web Services Protocol SSL-based authentication over standard SOAP messages, which in turn allows for the use of the W3C Web Services security specification for message protection (XML-Encyption and XML-Signature). Resource security model GT3 services do not run with any special privileges: they use two specific setuid programs to perform the actions requiring privileges.

44 Acronimi CAS: Community Authorization Service GASS: Global Access to Secondary Storage GIIS: Grid Information Index Service GIS: Grid Information Services GRAM: Globus Resource Allocation and Management GRIM: Grid Resource Identity Mapper GRIS: Grid Resource Information Service GSI: Grid Security Infrastructure GSP: Grid Security Protocol GSS: Globus Security Service GSS-API: Generic Security Service API HBM: Heartbeat Monitor LMJFS: Local Managed Job Factory Service MMJFS: Master Managed Job Factory Service MJS: Managed Job Service MDS: Metacomputing Directory Service // if Globus related: Monitoring and Discovery Service OGSA: Open Grid Services Architecture OGSI: Open Grid Services Infrastructure PAC: Privilege Attribute Certificate RGMS: Reliable Grid Monitoring Services SPKM: Simple Public-Key Mechanism

45 Bibliografia 1. I. Foster & C. Kesselman, The Grid: Blueprint for a New Computing Infrastructure; Eds., Morgan Kaufmann A. Chervenak, I. Foster, C. Kesselman, C. Salisbury, S. Tuecke, The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Datasets; I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling Scalable Virtual Organizations; J. Homann, S. Cetin, Anatomy of "The Grid"; I. Foster, J. Geisler, B. Nickless, W. Smith, S. Tuecke, Software Infrastructure for the I-WAY High-Performance Distributed Computing Experiment; I. Foster, C. Kesselman, Globus: A Metacomputing Infrastructure Toolkit; I. Foster, W. Allock, S. Tuecke, Protocols and Services for Distributed Data-Intensive Science; 2001.

46 8. I. Foster, J. Gawor, P. Lane, N. Rehn, M. Russell, G. von Laszewski, Designing Grid-based Problem Solving Environments and Portals; I. Foster,C. Kesselman, The Globus Project:A Status Report; K. Keahey, V. Welch, Fine-Grain Authorization for Resource Management in the Grid Environment; C. Kesselman, I. Foster, J. M. Nick, S. Tuecke, Grid Services for Distributed System Integration; I. Foster, C. Kesselman, G. Tsudik, S. Tuecke, A Security Architecture for Computational Grids; V. Welch, F. Siebenlist, GT3 Grid Security Infrastructure Overview; V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman, S. Tuecke, Security for Grid Services; J. Novotny, S. Tuecke, V. Welch, An Online Credential Repository for the Grid: MyProxy; 2001

47 Puntatori Internet