Progettazione affidabile

Tags:
Categories:

Architettura e principi di progettazione della sicurezza

Tre elementi della sicurezza e principi di progettazione della sicurezza

  • Integrità (Integrity)
  • Disponibilità (Availability)
  • Riservatezza (Confidentiality)

Principio di progettazione aperta

Open Design

  • Il design non dovrebbe essere un segreto; un design aperto è più sicuro.
  • La sicurezza non dipende dal mantenimento del segreto.

Principio di fallimento-sicuro per default

Fail-safe defaults

  • Le decisioni di accesso si basano su “consentire”, non su “rifiutare”.
  • Per impostazione predefinita, l’accesso non è consentito; i meccanismi di protezione sono usati solo per identificare i casi in cui l’accesso è consentito.
  • Sicurezza in caso di fallimento: qualsiasi sistema complesso dovrebbe avere un meccanismo di sicurezza di emergenza in caso di malfunzionamento, e inoltre bisogna fare attenzione ai messaggi di errore e ai log per prevenire fughe di informazioni.
  • Sicurezza per default: il sistema, nello stato iniziale, ha una configurazione predefinita sicura, fornendo la massima sicurezza utilizzando il minor numero possibile di sistemi e servizi.

Principio di separazione dei privilegi

Separation of Privilege

  • Un meccanismo di protezione che richiede due chiavi per essere sbloccato è più robusto e flessibile di uno che ne richiede una sola.
  • Scopo della separazione dei privilegi
  • Prevenire conflitti di interesse e abusi di potere individuali
  • Decomporre un’autorità importante in più autorità, rendendo più difficile ottenere illegalmente l’oggetto da proteggere, aumentando così la sicurezza.
  • Separare le responsabilità e i compiti tra diversi processi

Il sistema può impostare per default 3 ruoli, i cui account di sistema hanno privilegi indipendenti e separati compiti:

  • Amministratore di sistema: responsabile della gestione quotidiana degli utenti e della configurazione del sistema.
  • Amministratore della sicurezza: responsabile dell’attivazione e disattivazione degli utenti e delle configurazioni di sicurezza.
  • Auditore della sicurezza: responsabile dell’audit delle operazioni dei precedenti due, con privilegi di esportazione dei log, garantendo la tracciabilità di tutte le operazioni degli utenti del sistema.

Principio del privilegio minimo

Least Privilege

  • Ogni utente e ogni programma del sistema dovrebbero utilizzare il set minimo e necessario di privilegi per svolgere il proprio lavoro.
  • Assicurarsi che le applicazioni vengano eseguite con i privilegi minimi.
  • Prestare attenzione all’account con i privilegi minimi per far girare o connettere i vari programmi degli utenti, come database e server web, non dovrebbe essere l’account con i privilegi massimi del sistema.
  • Quando si crea un nuovo account, assegnare per default il ruolo con i privilegi minimi.

Principio di economia dei meccanismi

Economy of Mechanism

  • Mantenere il design del sistema e il codice il più semplice e compatto possibile.
  • Più un software è complesso, maggiore è la probabilità di bug nel codice; se il design è il più possibile elegante, la probabilità di problemi di sicurezza è minore.
  • Eliminare codice ridondante e moduli funzionali non necessari; mantenere tale codice aumenta solo la superficie di attacco del sistema.
  • Progettare componenti riutilizzabili per ridurre il codice ridondante.
  • Economicità e praticità: semplice, elegante, modulare.
  • Non progettare eccessivamente

Principio di minimizzazione della condivisione

Least Common Mechanism

  • Evitare per quanto possibile scenari in cui più oggetti condividono la stessa risorsa; il numero e l’uso delle risorse condivise tra gli utenti del sistema dovrebbero essere minimizzati.
  • Gli oggetti condivisi forniscono potenziali canali di flusso di informazioni e interazioni involontarie, quindi si dovrebbe evitare per quanto possibile scenari in cui più oggetti condividono la stessa risorsa.
  • Se uno o più oggetti non sono soddisfatti del servizio fornito dal meccanismo di condivisione, possono scegliere di non utilizzare affatto il meccanismo di condivisione, evitando così attacchi indiretti da bug di altri oggetti.
  • Minimizzare la memoria condivisa
  • Minimizzare il binding delle porte
  • Ridurre le connessioni, difendendosi dagli attacchi DoS

Principio di mediazione completa

Complete Mediation

  • Il principio di mediazione completa richiede che ogni accesso a ogni oggetto sia sottoposto a verifica di sicurezza.
  • Quando un soggetto tenta di accedere a un oggetto, il sistema verifica ogni volta se il soggetto possiede tale autorizzazione.
  • Ogni decisione di controllo degli accessi dovrebbe essere presa, se possibile, dal proprietario della risorsa; ad esempio, se si tratta di un URL, il controllo dovrebbe essere effettuato dal server backend, non dal frontend.
  • Fare particolare attenzione all’uso e al controllo della cache, non è possibile garantire che le informazioni nella cache non siano state manomesse da hacker durante ogni accesso. es. Spoofing della cache DNS.

Principio di accettabilità psicologica

Psychological Acceptability

  • I meccanismi di sicurezza possono aggiungere oneri aggiuntivi agli utenti, ma questi oneri devono essere minimi e ragionevoli.
  • I meccanismi di sicurezza dovrebbero essere il più possibile amichevoli per gli utenti del sistema, facilitando l’uso e la comprensione del sistema.
  • Se il metodo di configurazione è troppo complesso e laborioso, l’amministratore di sistema potrebbe accidentalmente configurare un’opzione errata, rendendo il sistema meno sicuro.
  • Questo principio è generalmente correlato all’interazione uomo-macchina e all’interfaccia utente centrata sull’utente (UCD).

Principio di difesa in profondità

Defense in Depth La difesa in profondità è un principio di difesa che richiede un’elevata integrazione; generalmente richiede che l’architetto del sistema utilizzi in modo completo tutti gli altri principi di progettazione della sicurezza, adottando meccanismi di verifica della sicurezza multipli e multipli, e considerando in modo olistico i meccanismi di difesa della sicurezza a livello di architettura del sistema, piuttosto che dipendere da un singolo meccanismo di sicurezza.