Operazione: Identificazione dei modelli di sicurezza
Durante l'architettura iniziale di un sistema Security Architect è responsabile dell'identificazione e la selezione dei modelli di sicurezza chiave che assicurano il livello di sicurezza richiesto dal sistema.
Scopo

Per fornire i meccanismi chiave per lo sviluppo di soluzioni sicure selezionando dai modelli predefiniti.

Relazioni
Descrizione principale

L'obiettivo di questa attività è di consentire agli architetti di identificare i modelli di sicurezza di alto livello appropriati per collegare agli elementi strutturali in risposta ai requisiti e alle politiche di sicurezza. Questi modelli sono quindi rifiniti con appropriati modelli dettagliati ad una tecnologia particolare e a scelte di piattaforma tramite un progetto di down-stream e attività di implementazione.

Per ulteriori informazioni sui modelli di sicurezza, consultareConcetto: Modelli di sicurezza.

Passi
Identificazione di requisiti di sicurezza

Durante questa fase il Ruolo: Architetto della sicurezza è responsabile della cattura dei requisiti di sicurezza ad alto livello per un progetto e per gli elementi strutturali  chiave di quel progetto. Questi requisiti sono riportati in Artefatto: Documento dell'architettura software eArtefatto: Specifiche supplementari e dove questi requisiti limitano in modo significativo l'architettura della soluzione allora questi dovrebbero essere inclusi in Artefatto: Architettura di riferimento. Il ruolo dell'architetto di sicurezza è di dedurre questi requisiti complessi dagli azionisti nel progetto e di riportarli in istruzioni semplici da capire.

Il motivo dell'enfasi sull'intento a questo punto è che in molti casi quando vengono fatte domande relative alla sicurezza in una sessione di raggruppamento dei requisiti (consultare Linea guida: Workshop sui requisiti) la maggior parte degli azionisti risponde che "ovviamente, tutto deve essere protetto", bene, se questo significa che tutto deve essere codificato, controllato e così via allora la risposta è "oh sì, per piacere". A questo punto l'architetto della sicurezza spiega le implicazioni di tale decisione, il costo, la complessità, ed il gruppo inizia ad avere una discussione sensata su quali modelli sono importanti per quali elementi nell'architettura. Sono questi modelli che esprimono l'intento del sistema relativo alla sicurezza, mentre i modelli del livello di progettazione esprimono i meccanismi per completare l'intento e infine i modelli di implementazione esprimono la tecnologia utilizzata per completare l'intento.

Identificazione dei limiti della sicurezza

La sicurezza è un aspetto chiave in tutte le soluzioni di sicurezza. La necessità della sicurezza si basa sulla premessa che due parti condividono un livello di sicurezza e che il livello può essere su una scala da "completamente sicuro" (quindi non c'è bisongo di sicurezza) a "completamente non sicuro" (dove la paranoia regna sovrana).

  1. Nessuna protezione ... protezione aka blind: Il provider potrebbe fornire un servizio pubblico e non ha bisogno di proteggere il sistema di richiamo. Il sistema di richiamo potrebbe inviare un'identità con nessuna prova e aspettare che il provider assuma l'identità quando elabora la richiesta. Potrebbero non essere state prese misure per evitare gli attacchi di persone.
  2. Protezione basata sulla configurazione di rete: Non esiste nessuna configurazione software che fornisce protezione. La rete è configurata, possibilmente tramite una suddivisione in sottoreti con firewall, in modo da limitare il numero di macchine che potrebbero trasmettere un messaggio al provider. Il caso degenerativo vedrebbe solo il sistema di richiamo designato ed il sistema del provider sulla sottorete. A volte le VPN sono utilizzate per limitare i possibili sistemi di richiamo.
  3. Protezione basata sull'infrastruttura: L'infrastruttura (ad esempio il protocollo di trasporto... possibilmente MA SSL, o SSL + BA) viene configurato per identificare il sistema di richiamo per convalidare che si tratta di un sistema sicuro. Non c'è niente nel messaggio dei servizi (SOAP) a parte l'identità del chiamante che il provider dovrebbe supporre quando elabora la richiesta.
  4. Protezione basata sul token: Protezione token point-to-point - Esiste un token nel messaggio che asserisce l'identità di un chiamante e che è stato probabilmente creato da un sistema di richiamo sicuro (ad esempio SAML, LTPA). Protezione token terze parti - Esiste un token nel messaggio che asserisce l'identità di un chiamante e che è stato probabilmente creato da KDC/STS del sistema sicuro di terze parti (ad esempio SAML, Kerberos).
  5. Protezione basata sul contesto token: Firma che copre il token ed il messaggio- Esiste una firma nel messaggio creato da un sistema di richiamo sicuro che copre il messaggio ed il token che asserisce l'identità del chiamante e che autentica il sistema di richiamo. Due token nel messaggio - Esiste un token nel messaggi che autentica il sistema di richiamo come un sistema sicuro ed un altro token che identifica il chiamante. È necessario che ci sia un meccanismo per collegare i due token tra di loro e con il messaggio, come ad esempio una firma.
  6. La parte finale della "protezione" è l'autenticazione. Il token che fornisce una prova elimina la necessità di un meccanismo supplementare il cui scopo è di stabilire la protezione.

Zone di protezione

Nelle grandi imprese è spesso efficace suddividere l'azienda in regioni amministrative e stabilire diverse zone di protezione. Tra diverse zone ci sono diversi sottotipi di rapporti di protezione che è possibile stabilire. Questi sono esempi si alcuni modi in cui due parti possono stabilire un rapporto di protezione quando solo una delle parti ha una relazione con l'utente finale.

  • Protezione diretta - Scambio token: Il dominio protezione 1 autentica l'utente finale e il dominio protezione q richiede un'identità o un identificativo (propagazione identità). In alcuni casi (ad esempio quando è richiesta solo la personalizzazione) l'autenticazione potrebbe non essere necessaria.
  • Protezione diretta - Convalida token: Il dominio di protezione 1 potrebbe creare una nuova asserzione (un'asserzione di identità) che offre la propria prova che ha autenticato l'utente finale. Il dominio di protezione 2, valuta che questa asserzione deriva da qualcuno che protegge (Dominio di protezione 1) e lo utilizza al posto dell'autenticazione del dominio stesso
  • Servizi token e ISP: A volte i rapporti di protezione sono stabiliti tra più parti e l'autenticazione dell'utente è separato in un servizio indipendente (provider del servizio entità). Questi provider del servizio identità hanno diversi gradi di funzionalità. Alcuni possono guardare la destinazione della richiesta e determinare se l'utente è stato autenticato e sapere se il token corrente deve essere scambiato per un secondo token e può reindirizzare questa richiesta alle parti appropriate.
  • Protezione indiretta: A volte le parti non hanno una relazione di protezione diretta, ma queste condividono una terza parte che entrambi proteggono per essere "broker" di uno scambio.
  • Delegazione: È possibile stabilire combinazioni di relazioni di protezione dirette e indirette
Identificazione dei modelli di sicurezza ad alto livello

I modelli di sicurezza ad alto livello identificati in questa attività sono i seguenti. Gli elementi dell' Architettura del sistema interessati ai requisiti di sicurezza (la sicurezza riguarda sia gli elementi software che hardware) potrebbero essere associati a uno o più modelli (preferibilmente documentati in Artefatto: Documento dell'architettura software) in modo tale che possano essere raffinati durante le attività del tempo di progettazione.

Identità e autenticazione

Un utente finale possiede un identificato (nome utente) e/o un insieme di identificativi (titoli, ruoli, alias) e prove (password), che conserva probabilmente su un sistema client come un laptop o un PDA. Per autenticare, l'utente presenta l'identificativo e la prova ad un'applicazione quando viene richiesto per identificarsi all'applicazione. Se l'applicazione convalida l'identificativo e la prova, l'utente ha correttamente "autenticato" e l'identità è ora un'"identità autenticata". Quando un'applicazione implementa la logica del business e rafforza le proprie politiche di sicurezza, è necessario conservare il repository dei dati/metadati (file system, database, ecc). Con l'avvento del Web, l'utente finale non dispone più solo del codice client dell'applicazione sul proprio sistema, ma spesso accedere alle applicazioni tramite un browser, e la rete trova un'applicazione tramite un URI (universal resource identifier) fornito dall'utente finale.

Single Sign-On

Quando un utente ha più applicazioni con identificativi e prove diverse , diventa a volte difficile gestire i dati ed i metadati d'identità per prendere le decisioni appropriate. SSO (Single Sign-On) è un termine applicato a diverse tecniche (umane e automatizzate) per ridurre questa complessità.

Le soluzioni per SSO possono essere basate sul client o sul server/servizio e possono essere fermamente o debolmente accoppiati alle applicazioni. Il SSO basato sul Web fa riferimento alle soluzioni basate sul browser e generalmente include i cookie. Negli SSO basati sul client e accoppiati fermamente, la responsabilità è dell'utente per registrare e sincronizzare più id e password che sono conservati in più repository di applicazione. Alcuni SSO si basano sull'"associazione di identità" altri forniscono "propagazione di identità" o "asserzioni di identità". Nuove iniziative negli SSO associati consentono ad un utente di registrare con un Provider del servizio di entità di terza parte che quindi gestisce le informazioni utente fornendo un'alternativa debolmente accoppiata. Nelle aziende, un SSO di backend può includere l'azienda che agisce come ISP. L'SSO di beckend include un repository comune per tutte le applicazioni e ogni applicazione/server viene riconfigurato per non utilizzare un repository locale. Gli SSO di backend conservano più repository per le informazioni utente e utilizzando un processo di gestione per forzare la sincronizzazione dei dati di entità in più repository. Quando più entità sono interessate, spesso i requisiti isolano le applicazioni in realm che spesso si correlano a domini amministrativi.

Identità digitali

Poiché le persone e le imprese sono diventate più dipendenti dalla tecnologia del computer, c'è stata una proliferazione di informazioni relative all'identità che sono state create. Con la consapevolezza del furto di identità, i governi legiferano sui requisiti per le aziende a proposito delle informazioni di identità per le quali loro sono custodi.

Soluzioni di identità digitale - Ci sono due strategie principali per la gestione delle identità digitali. Una è "incentrata sull'utente", e si basa su un utente che partecipa attivamente alla protezione dell'identità, "registrando" con provider di terze parti e quindi garantendo l'autorizzazione all'accesso dei propri dati e metadati di entità ai provider di cui si fidano. La Liberty Alliance è un consorzio che porta avanti questa strategia, ma c'è anche uno sforzo open source con l'iniziativa Higgins nella partnership con  Apache Foundation.

Il secondo è un modello incentrato sul business nel quale un business fornisce servizi di gestione dell'entità ai clienti, ai partner e agli impiegati. La tecnologia sottostante è la stessa per ogni approccio, ma l'autorità e la responsabilità per la fornitura della gestione identità è diversa. LE aziende hanno a che fare con diversi volumi di informazioni rispetto agli individui singoli e quindi hanno diversi requisiti di scala. Le aziende devono inoltre avere i propri sistemi per gestire l'accesso agli utenti in base ai ruoli di business e cambiare le condizioni di business (ad esempio, si è sempre "My Self", ma non si desidera lavorare sempre per la società xyz.)

Autorizzazione

Poiché le persone e le imprese sono diventate più dipendenti dalla tecnologia del computer, le regole relative a chi può accedere a quali risorse è diventata più codificata. Quando si progettano le applicazioni, la decisione di chi può accedere a quali informazioni potrebbe dipendere dalle informazioni del contesto aziendale o potrebbe essere esternalizzata all'applicazione e gestita da un insieme separato di middleware. La maggior parte dei prodotti e dei sistemi del computer hanno implementato un insieme di meccanismi di "controllo degli accessi", ma ognuno di solito mantiene la propria associazione di nomi utente autorizzati e questi sono chiamati "elenchi di controllo accessi".

Protezione del messaggio

Ci sono due tipi di base di protezione; protezione dell'integrità (prova che il messaggio non è stato modificato mentre era in transito) e riservatezza (applicazione di crittografia per assicurare che solo i destinatari autorizzati possano visualizzare il messaggio). Quando i messaggi vengono inviati su un protocollo ogni messaggio può essere firmato in modo digitale o codificato o il protocollo di rete può firmare/codificare tutto il traffico tra i due punti di ingresso. Quando il protocollo fornisce la protezione, spesso si dice che è "point to point" (ad esempio l'endpoint della rete all'endpoint della rete).

Proprietà
Predecessore
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Considerazioni chiave
I modelli di sicurezza identificati durante questa attività sono di alto livello e non dipendono da tecnologie particolari o da piattaforme;ognuno di questi modelli verrà supportato da un numero di tecnologie e modelli specifici della piattaforma. La definizione di questi modelli dettagliati deve essere disponibile all'implementatore per la tecnologia e la piattaforma scelta da un progetto.
Ulteriori informazioni