Quando le persone parlano di "politica di sicurezza", potrebbero riferirsi a due diversi tipi di politica di sicurezza.
Uno di loro sono quelli ad alto livello, generalmente definiti da direzioni. I principali lettori di questa politica di sicurezza sono umani. È un documento che definisce l'obiettivo, il contesto, le aspettative e i requisiti di sicurezza nella mente del management.Le lingue utilizzate all'interno di questa politica potrebbero essere vaghe, ma è la "legge" elementare della sicurezza nel contesto applicativo. Tutti i soggetti coinvolti dovrebbero seguire tale politica.
1) Il risultato di tale politica è i requisiti di sicurezza chiaramente definiti dalla direzione. Con queste politiche, tutte le persone coinvolte possono comprendere le aspettative della direzione e, se necessario, emettere un giudizio relativo alla sicurezza.
2) Poiché i principali lettori di tali politiche di sicurezza sono umane e le dichiarazioni sono in genere molto generali, potrebbe non essere in una forma leggibile dal computer. Tuttavia, potrebbero esserci un paio di documenti definiti in base alla politica, ovvero linee guida, procedure e manuali di sicurezza. Sono nell'ordine del livello crescente di dettagli su come la sicurezza dovrebbe essere effettivamente implementata. Ad esempio, i requisiti definiti nella politica di sicurezza possono essere realizzati in manuali di tempra per diversi sistemi operativi, in modo che Amministratori e Ingegneri possano eseguire efficientemente le attività di indurimento senza spendere troppo tempo a interpretare le riflessioni della direzione. I manuali di indurimento possono quindi essere trasformati in un insieme di configurazioni leggibili dalla macchina (ad esempio, lunghezza minima della password, numero massimo di accessi falliti prima del blocco dell'account, ecc.) Che automatizzano le attività di indurimento.
3) Il documento deve essere reso accessibile a tutti i soggetti coinvolti e regolarmente rivisto dalla direzione.
4) Praticamente potrebbe essere difficile fare tali riferimenti. Le politiche di sicurezza potrebbero essere aggiornate di volta in volta e probabilmente non si desidera ricompilare il programma se le modifiche apportate ai criteri influiscono solo su alcuni parametri. Tuttavia, è bello fare riferimento alla politica nei documenti di sviluppo come design sepc.
Un altro tipo di "politica di sicurezza" potrebbe semplicemente riferirsi a quei gruppi di parametri che sono i programmi di sicurezza. Ho scoperto che alcuni programmi di sicurezza amano davvero usare la parola "policy" per rendere le loro configurazioni più organizzate e strutturate. Ma in ogni caso, queste "politiche di sicurezza" sono in realtà solo valori e/o istruzioni per i programmi di sicurezza da seguire. Ad esempio, Windows ha il proprio set di "politiche di sicurezza" per l'utente per configurare le registrazioni di controllo, i diritti utente, ecc. Questo tipo di "politiche di sicurezza" (parametri per programmi) viene effettivamente definito in base al 1 ° tipo di "politiche di sicurezza" (requisiti della direzione) come menzionato sopra.
Potrei scrivere troppo su questo. Spero che sia d'aiuto.
Questo non sembra riguardare la programmazione. Dato che apparentemente si tratta di sicurezza a livello aziendale, vota la migrazione a Server Fault. –
@David: non sono assolutamente d'accordo. Quando si progetta un sistema con implicazioni di sicurezza, i meccanismi che implementa devono supportare la gamma di potenziali politiche. – Novelocrat
@Novelocrat: Certamente, e la programmazione di detti meccanismi è completamente in discussione qui. Tuttavia, si tratta di stabilire una sorta di regole che verranno implementate in vari modi, alcune probabilmente coinvolgono la programmazione, e che non è in argomento su SO. –