Definizioni di base

Chiameremo il sistema operativo protetto , se fornisce mezzi di protezione contro le principali classi di minacce descritte al § 1.1. Un sistema operativo protetto deve contenere mezzi per delimitare l'accesso degli utenti alle proprie risorse, nonché mezzi per autenticare l'utente che inizia a lavorare con il sistema operativo. Inoltre, il sistema operativo protetto deve contenere un mezzo per contrastare l'inferenza accidentale o intenzionale. sistema operativo Fuori servizio.

Se il sistema operativo fornisce protezione non da tutte le principali classi di minacce, ma solo da alcune, verrà chiamato tale sistema operativo parzialmente protetto . Ad esempio, il sistema operativo MS-DOS con il pacchetto antivirus installato è un sistema parzialmente protetto: è protetto dai virus informatici.

chiameremo politica di sicurezza un insieme di norme, regole e pratiche che disciplinano l'archiviazione e l'elaborazione di informazioni preziose. Applicata al sistema operativo, la politica di sicurezza determina quali utenti possono lavorare con il sistema operativo, quali utenti hanno accesso a quali oggetti del sistema operativo, quali eventi devono essere registrati nei registri di sistema e così via.

Adeguata politica di sicurezza chiameremo tale politica di sicurezza che fornisce un livello di sicurezza sufficiente per il sistema operativo. Va sottolineato che una politica di sicurezza adeguata non è necessariamente una politica di sicurezza che raggiunga la massima sicurezza possibile del sistema.

Approcci all'edilizia protettasistemi operativi

Esistono due approcci principali alla creazione di sistemi operativi sicuri: frammentario e complesso.

In frammentario approccio, in primo luogo, viene organizzata la protezione da una minaccia, quindi da un'altra, ecc. Un esempio di approccio frammentato è una situazione in cui viene preso come base un sistema operativo non protetto (ad esempio Windows-95), un pacchetto antivirus, un sistema di crittografia, un sistema per la registrazione delle azioni dell'utente, ecc.

Il principale svantaggio dell'approccio frammentato è ovvio: quando si utilizza questo approccio, il sottosistema di protezione del sistema operativo è un insieme di prodotti software disparati, di norma, prodotti da diversi produttori. Questi strumenti software funzionano indipendentemente l'uno dall'altro, è quasi impossibile organizzare la loro stretta interazione. Inoltre, i singoli elementi di un tale sottosistema di protezione potrebbero non funzionare correttamente in presenza l'uno dell'altro, il che porta a una forte diminuzione dell'affidabilità del sistema. Poiché il sottosistema di protezione, creato sulla base di un approccio frammentato, non è parte integrante del sistema operativo, se determinate funzioni di protezione vengono disabilitate a seguito di azioni non autorizzate dell'utente in violazione, i restanti elementi del sistema operativo continuano a funzionare normalmente, il che riduce ulteriormente l'affidabilità della protezione.

In un integrato approccio all'organizzazione della protezione del sistema funzioni protettive vengono introdotti nel sistema operativo nella fase di progettazione dell'architettura del sistema operativo e ne sono parte integrante. I singoli elementi del sottosistema di protezione, creati sulla base di un approccio integrato, interagiscono strettamente tra loro nella risoluzione di vari problemi relativi all'organizzazione della protezione delle informazioni. Poiché il sottosistema di protezione è sviluppato e testato in modo aggregato, il conflitto tra i suoi componenti separati quasi impossibile. Il sottosistema di protezione, realizzato sulla base di un approccio integrato, può essere organizzato in modo tale che in caso di guasti fatali nel suo funzionamento elementi chiave provoca l'arresto anomalo del sistema operativo, impedendo a un utente malintenzionato di disabilitare le funzioni di protezione del sistema. Quando si utilizza un approccio frammentato, una tale organizzazione del sottosistema di protezione è impossibile.

Di norma, un sottosistema di protezione del sistema operativo, creato sulla base di un approccio integrato, è progettato in modo che i suoi singoli elementi siano sostituibili e i corrispondenti moduli software possano essere sostituiti da altri moduli che implementano l'interfaccia fornita per l'interazione del software corrispondente modulo con altri elementi del sottosistema di protezione.

Garanzie amministrative

L'organizzazione di una protezione efficace e affidabile del sistema operativo è impossibile con l'aiuto del solo software e hardware. Questi fondi devono essere integrati da misure di protezione amministrativa. Senza un costante supporto qualificato da parte dell'amministratore, anche la protezione software e hardware più affidabile si trasforma in finzione.

Il principale misure amministrative protezione.

1. Monitoraggio costante del corretto funzionamento del sistema operativo, in particolare del suo sottosistema di protezione. Questo controllo è organizzato in modo più conveniente se il sistema operativo supporta la registrazione degli eventi. In questo caso il sistema operativo registra automaticamente in un apposito log (o più log) gli eventi più importanti avvenuti durante il funzionamento del sistema.

2. Organizzazione e mantenimento di un'adeguata politica di sicurezza. La politica di sicurezza dovrebbe essere costantemente adattata, rispondendo prontamente ai cambiamenti nella configurazione del sistema operativo, installazione, rimozione e modifiche alla configurazione dell'applicazione prodotti software ed estensioni del sistema operativo, tentativi da parte di intrusi di superare la protezione del sistema operativo, ecc.

3. Istruire gli utenti del sistema operativo sulla necessità di rispettare le misure di sicurezza quando si lavora con il sistema operativo e monitorare il rispetto di tali misure.

4. Creazione e aggiornamento periodici di copie di backup di programmi e dati del sistema operativo.

5. Monitoraggio continuo delle modifiche ai dati di configurazione e alla politica di sicurezza del sistema operativo. È consigliabile archiviare le informazioni su queste modifiche su supporti non elettronici per rendere più difficile a un utente malintenzionato che ha superato la protezione del sistema operativo mascherare le sue azioni non autorizzate.

Adeguata politica di sicurezza

Il compito di selezionare e mantenere una politica di sicurezza adeguata è uno dei compiti più importanti di un amministratore di sistema operativo. Se la politica di sicurezza adottata nel sistema operativo è inadeguata, ciò può comportare l'accesso non autorizzato da parte di un utente malintenzionato alle risorse di sistema, nonché una diminuzione dell'affidabilità del sistema operativo. D'altro canto, non tutte le politiche di sicurezza adeguate sono applicabili nella pratica.

In generale vale la seguente affermazione: migliore è l'opera Il sistema di sicurezza è tanto più difficile è per gli utenti e gli amministratori lavorarci. Ciò è dovuto ai seguenti fattori.

1. Un sistema di sicurezza che non possiede intelligenza non è sempre in grado di determinare se una determinata azione dell'utente è dannosa. Pertanto, il sistema di protezione non sopprime alcuni tipi di accesso non autorizzato o vieta alcune azioni completamente legali degli utenti. Maggiore è la sicurezza del sistema, più ampia è la classe di quelle azioni legali degli utenti che sono considerate non autorizzate dal sottosistema di protezione. Ad esempio, se a un determinato utente è vietato creare file sul disco rigido, questo utente non sarà in grado di avviare alcun programma che necessiti di creare file temporanei per il normale funzionamento. Dal punto di vista della politica di sicurezza in esame, la creazione di un file temporaneo è un'azione non autorizzata e non c'è errore nel fatto che venga soppresso. È solo che in questa politica di sicurezza la classe di azioni non autorizzate è così ampia da interferire con il normale lavoro degli utenti con il sistema operativo.

2. Qualsiasi sistema che fornisce funzioni di sicurezza delle informazioni richiede agli amministratori di compiere determinati sforzi per mantenere una politica di sicurezza adeguata. Più funzioni protettive nel sistema operativo, più tempo e denaro è necessario spendere per mantenere la protezione.

3. Il sottosistema di protezione del sistema operativo, come qualsiasi altro pacchetto software, consuma le risorse hardware del computer. Più complesse sono le funzioni di protezione del sistema operativo, più tempo del processore, RAM e altre risorse hardware del computer vengono spese per mantenere il funzionamento del sottosistema di protezione e meno risorse rimangono per i programmi applicativi. In alcuni casi, ad esempio, se il sistema operativo supporta il controllo di accesso autorevole con il controllo dei flussi di informazioni, il sottosistema di protezione del sistema operativo può consumare più della metà delle risorse hardware del computer.

4 Mantenere una politica di sicurezza troppo rigida può influire negativamente sull'affidabilità del sistema operativo. Un esempio di tale politica di sicurezza è descritto nelle FAQ di Windows NT. Windows NT consente agli amministratori di limitare i diritti dei processi di sistema per accedere agli oggetti del sistema operativo. Se allo pseudo-utente SISTEM, per conto del quale vengono eseguiti i processi di sistema, viene negato l'accesso ai file eseguibili dei processi di sistema, il sistema operativo, come ci si aspetterebbe, non sarà in grado di avviarsi. In questo caso, una politica di sicurezza eccessivamente rigorosa porta a un arresto anomalo del sistema operativo, in altri casi, una tale politica di sicurezza può portare a errori e guasti difficili da rilevare nel processo di funzionamento del sistema operativo, che è persino più pericoloso.

Pertanto, quando si definisce una politica di sicurezza adeguata, non si dovrebbe cercare di raggiungere il livello più alto possibile di sicurezza del sistema operativo. Politica di sicurezza adeguata ottimale È una politica di sicurezza che non solo consente agli intrusi di eseguire azioni non autorizzate, ma non porta nemmeno agli effetti negativi sopra descritti.

Non esiste un'unica politica di sicurezza adeguata per tutte le occasioni. Quale politica di sicurezza sarà adeguata è determinata non solo dall'architettura del sistema operativo, ma anche dalla sua configurazione stabilita programmi applicativi eccetera. È probabile che una politica di sicurezza adeguata per un determinato sistema operativo sia inadeguata per un'altra istanza dello stesso sistema operativo. La maggior parte dei sistemi operativi moderni è abbastanza versatile e può essere utilizzata per risolvere un'ampia varietà di compiti. Lo stesso sistema operativo può essere utilizzato per garantire il funzionamento di un sistema bancario automatizzato, un server Web e un sistema di gestione elettronica dei documenti. Ovviamente le minacce alla sicurezza per tutte e tre le applicazioni del sistema operativo sono completamente diverse e, quindi, una policy di sicurezza adeguata in ogni caso sarà diversa.

La definizione e il mantenimento di un'adeguata politica di sicurezza del sistema operativo può essere generalmente suddivisa in una serie di fasi.

1. Analisi delle minacce. L'amministratore del sistema operativo considera possibili minacce alla sicurezza per questa istanza del sistema operativo. Tra le possibili minacce spiccano quelle più pericolose, protezione dalla quale è necessario dedicare il massimo di forze e risorse.

2. Formazione dei requisiti per la politica di sicurezza... L'amministratore determina quali strumenti e metodi verranno utilizzati per proteggersi da determinate minacce. Ad esempio, la protezione contro l'accesso non autorizzato ad alcuni oggetti del sistema operativo può essere risolta mediante il controllo degli accessi, oppure mezzi crittografici, o utilizzando una combinazione di questi mezzi. L'amministratore deve fare una scelta simile per ogni minaccia alla sicurezza del sistema operativo, scegliendo la migliore difesa contro ogni minaccia. Allo stesso tempo, l'amministratore analizza i possibili effetti collaterali delle varie opzioni della politica di sicurezza, valutando la misura in cui i fattori collaterali negativi appariranno in ciascuna opzione della politica di sicurezza. Di norma, l'amministratore deve fare un compromesso, rassegnandosi all'insufficiente protezione del sistema operativo dalle minacce individuali o a determinate difficoltà per gli utenti quando lavorano con il sistema.

3. Definizione formale della politica di sicurezza. L'amministratore definisce chiaramente come devono essere soddisfatti esattamente i requisiti formulati nel passaggio precedente. Decide se questi requisiti possono essere soddisfatti solo dagli strumenti integrati del sistema operativo o se è necessario installare pacchetti di protezione aggiuntivi. In quest'ultimo caso, viene selezionato il software richiesto. sono formulati requisiti necessari alla configurazione del sistema operativo, nonché ai requisiti per la configurazione di pacchetti di protezione aggiuntivi, qualora sia necessaria l'installazione di tali pacchetti. Inoltre, l'amministratore dovrebbe prevedere la procedura per apportare le modifiche necessarie alla politica di sicurezza in situazioni di emergenza, ad esempio, al rilevamento del fatto di un ingresso non autorizzato nel sistema di un utente malintenzionato. Il risultato di questa fase è un elenco dettagliato delle impostazioni di configurazione del sistema operativo e dei pacchetti di protezione aggiuntivi, che indicano in quali situazioni devono essere impostate le impostazioni.

4. Attuazione della politica di sicurezza. All'inizio di questa fase, l'amministratore del sistema operativo ha un'idea chiara di quale dovrebbe essere una politica di sicurezza adeguata. Il compito di questa fase è di portare la configurazione del sistema operativo e dei pacchetti di protezione aggiuntivi secondo la policy di sicurezza formalmente definita nella fase precedente.

5. Mantenimento e correzione della politica di sicurezza. In questa fase, il sistema operativo opera in conformità con la politica di sicurezza definita nella terza fase. Il compito dell'amministratore è monitorare la conformità con la politica di sicurezza e apportare le modifiche necessarie man mano che si verificano cambiamenti nel funzionamento del sistema operativo. Ad esempio, se un nuovo prodotto software è installato sul sistema operativo, potrebbe essere necessario regolare la politica di sicurezza in modo che il prodotto software possa funzionare normalmente.

Standard di sicurezza in sala operatoriasistemi

Non esistono standard di sicurezza specifici per i sistemi operativi. Per valutare la sicurezza dei sistemi operativi vengono utilizzati standard sviluppati per i sistemi informatici in genere.

Lo standard più famoso per la sicurezza dei sistemi informatici è il Trusted Computer System Evaluation Criteria, sviluppato dal Dipartimento della Difesa degli Stati Uniti nel 1983. Questo documento è meglio conosciuto informalmente come Orange Book. I sistemi informatici protetti sono divisi in sette classi da D1 ( protezione minima, praticamente nessuna protezione) ad A1 (protezione massima).I principali requisiti dell'Orange Book applicati ai sistemi operativi possono essere formulati come segue (molto semplificato).

Classe D1. Nessun requisito. Questa classe include tutti i sistemi operativi che non soddisfano i requisiti delle classi più alte.

Classe C1. Il sistema operativo supporta il controllo di accesso selettivo (discrezionale). L'utente che inizia a lavorare con il sistema deve confermare la propria identità (essere autenticato).

Classe C2. Tutti i requisiti della classe C1 sono soddisfatti. Tutti i soggetti e gli oggetti del sistema operativo hanno identificatori univoci. Sono vietate tutte le azioni di tutti i soggetti di accesso che non siano esplicitamente consentite. Gli eventi potenzialmente pericolosi per il mantenimento della sicurezza del sistema operativo vengono registrati in un apposito log (audit log), che può essere gestito solo da utenti privilegiati. Tutte le informazioni cancellate dalla RAM del computer o da supporti di memorizzazione esterni vengono cancellate fisicamente e non sono successivamente accessibili da alcun soggetto di accesso.

Classe B1. Tutti i requisiti della classe C2 sono soddisfatti. È supportata la differenziazione autorevole (obbligatoria) dell'accesso agli oggetti del sistema operativo. Etichettatura supportata delle informazioni esportate.

Classe B2. Tutti i requisiti della classe B1 sono soddisfatti. Il sottosistema di sicurezza del sistema operativo implementa un modello di sicurezza formalmente definito e ben documentato. Vengono monitorati i canali segreti di fuga di informazioni. L'interfaccia del sottosistema di protezione è chiaramente e formalmente definita, la sua architettura e implementazione sono completamente documentate. Vengono proposti requisiti più rigorosi per l'identificazione, l'autenticazione e il controllo degli accessi.

Molti noti sistemi operativi soddisfano i requisiti della classe C2: un certo numero di versioni UNIX, Windows NT, OS / 400, VAX / VMS e IBM MVS con pacchetto RACF. Esistono pochissimi sistemi operativi per personal computer che soddisfano i requisiti delle classi di protezione più elevate. Ciò è spiegato, da un lato, dall'elevato "consumo di risorse" dei sottosistemi di protezione che soddisfano i requisiti della classe B1 e superiori e, dall'altro, dalle difficoltà nel garantire il normale funzionamento del software comune in tali sistemi. Se i requisiti della classe C2 consentono l'utilizzo di software sviluppato per altri ambienti software in un sistema operativo protetto (ad esempio, Microsoft Office per Windows 95 può essere eseguito in Windows NT), i requisiti per le classi di protezione superiori sono così severi da interferire notevolmente con il funzionamento dei programmi applicativi sviluppati senza considerare questi requisiti. Ad esempio, un editor di testo Microsoft Word, avviato in un sistema operativo che soddisfa i requisiti della classe B1, non funzionerà correttamente quando si aprono contemporaneamente documenti con etichette di sicurezza diverse.

I principali svantaggi dell'Orange Book includono quanto segue:

I mezzi crittografici per proteggere le informazioni non sono considerati affatto;

I problemi di garantire la protezione del sistema da attacchi volti a disabilitare temporaneamente il sistema (attacchi della classe "denial of service") non sono praticamente considerati;

Non viene prestata la dovuta attenzione alle problematiche di protezione del sistema protetto dagli effetti negativi di bug software e virus informatici;

I problemi di interazione di più copie di sistemi protetti in una rete di computer locale o globale non sono considerati in dettaglio;

Requisiti di protezione dalle perdite informazioni confidenziali da un sistema protetto sono focalizzati sulla memorizzazione di informazioni riservate in database e non sono molto adatti per proteggere il flusso di documenti elettronici.

Standard di sicurezza e politica di sicurezza adeguata

Se un sistema operativo è certificato secondo una qualsiasi classe di sicurezza di un determinato sistema di standard, ciò non significa affatto che le informazioni archiviate ed elaborate in questo sistema siano protette secondo la classe corrispondente. La sicurezza di un sistema operativo è determinata non solo dalla sua architettura, ma anche dall'attuale politica di sicurezza.

Di norma, la certificazione di un sistema operativo per una determinata classe di protezione è accompagnata dalla predisposizione dei requisiti per un'adeguata politica di sicurezza, con rigoroso la cui implementazione la sicurezza di una specifica istanza del sistema operativo soddisferà i requisiti della classe di protezione corrispondente.

A titolo di esempio, consideriamo alcuni dei requisiti per la configurazione del sistema operativo Windows NT che devono essere soddisfatti per rispettare la classe di sicurezza del sistema operativo C2 dell'"Orange Book":

Sopra dischi fissi viene utilizzato solo il file system NTFS;

È vietato utilizzare password di lunghezza inferiore a sei caratteri;

L'emulazione OS/2 e POS1X è vietata;

L'accesso anonimo e agli ospiti è vietato;

È vietato avviare eventuali debugger;

L'interruttore di alimentazione e il pulsante RESET non sono accessibili agli utenti;

È vietato spegnere il sistema operativo senza che l'utente acceda al sistema;

La politica di sicurezza del controllo è progettata in modo tale che quando il registro di sicurezza trabocca, il sistema operativo smette di funzionare (si blocca). Successivamente, il ripristino delle prestazioni del sistema può essere eseguito solo dall'amministratore;

È vietata la condivisione di risorse multimediali rimovibili (dischi floppy, CD-ROM, ecc.) tra utenti;

La scrittura nella directory di sistema e nei file di inizializzazione del sistema operativo è consentita solo agli amministratori e ai processi di sistema.

Quando si definisce una politica di sicurezza adeguata, l'amministratore del sistema operativo dovrebbe concentrarsi principalmente sulla protezione del sistema operativo da minacce specifiche alla sua sicurezza. Sfortunatamente, al giorno d'oggi, si verifica spesso una situazione in cui un amministratore forma i requisiti per una politica di sicurezza basata non su un insieme di minacce, dalle quali è necessario proteggersi, ma su alcune raccomandazioni astratte per mantenere la sicurezza di un particolare sistema operativo. Molto spesso, i requisiti di vari standard di sicurezza per i sistemi informatici sono presi come tali raccomandazioni: i più "popolari" sono gli standard Orange Book. Di conseguenza, è possibile che un sistema operativo certificato per una classe di protezione molto elevata diventi vulnerabile ad alcune minacce anche se la policy di sicurezza soddisfa i requisiti della classe di protezione corrispondente.

introduzione

Due sono gli approcci principali all'interpretazione del concetto di protetto sistema automatizzato applicabile ai sistemi operativi (OS). Il primo approccio implica che la sicurezza del sistema operativo sia garantita implementando alcuni dei requisiti di sicurezza inizialmente specificati, inclusa la presenza di un certo insieme di meccanismi di protezione, verificando l'assenza di un elenco predefinito di vulnerabilità, ecc. Nel secondo approccio, la possibilità di utilizzare il sistema operativo come parte di un sistema automatizzato (AS) è considerata critica e pertanto il sistema operativo deve fornire un insieme di strumenti di protezione adeguati alle minacce alla sicurezza di questi particolari sistemi. A prima vista, questi due approcci non si contraddicono, poiché è improbabile che i relatori critici utilizzino soluzioni che non implementano almeno requisiti minimi per sicurezza. Allo stesso tempo, il sistema operativo, quando tutti i requisiti di sicurezza sono soddisfatti, può essere controllato dall'esterno, ad esempio, dal suo sviluppatore. V condizioni specificate il secondo approccio implica che per soluzioni protette si intendono soluzioni che nella letteratura anglosassone sono indicate con il termine trusted o, nell'interpretazione domestica, trusted.

Pertanto, è consigliabile considerare un sistema operativo protetto (affidabile) che non solo implementi i requisiti di sicurezza fissati a priori, ma sia anche adeguato alle minacce alla sicurezza specifiche dei sistemi automatizzati domestici, anche per i quali non vi è possibilità di influenza non autorizzata sul suo lavoro dall'esterno, mentre il proprietario (utente) di un sistema operativo protetto deve avere un'idea univoca dell'algoritmo per il funzionamento dei suoi meccanismi di protezione in tutte le modalità operative.

Questa esigenza sta diventando sempre più urgente in l'anno scorso. Aggiornamento automatico, notifica automatica degli sviluppatori sugli errori del software, una varietà di servizi online aumenta significativamente le qualità del consumatore dell'applicazione e del software di sistema del sistema operativo, ma, d'altra parte, crea tutto più possibilità per i produttori di software e, compreso il sistema operativo, per monitorare le azioni dell'utente. Per una serie di applicazioni di sistemi operativi protetti, la questione della fiducia nel suo sviluppatore risulta essere più significativa della questione del volume e della qualità dell'implementazione dei meccanismi di sicurezza standard in questo sistema operativo.

Sono queste considerazioni che possono spiegare la crescita di interesse per i sistemi operativi protetti domestici, che è stata recentemente rilevata nella Federazione Russa da parte di enti governativi e imprese industriali. Un ulteriore incentivo in questo settore è stata la decisione presa dal governo della Federazione Russa di vietare l'ammissione di software provenienti da paesi stranieri allo scopo di effettuare acquisti per soddisfare le esigenze statali e comunali. Si prevede che se il Programma per lo sviluppo del segmento russo di Internet sarà approvato e adottato, "entro il 2025, tutte le agenzie governative e le imprese strategiche saranno dotate di computer in Russia". elemento base con un sistema operativo domestico a bordo."

In condizioni moderne, un promettente sistema operativo domestico protetto deve soddisfare i seguenti requisiti:

• soddisfare i requisiti per garantire l'indipendenza tecnologica (sostituzione delle importazioni) della Federazione Russa nelle aree più importanti dell'informatizzazione, delle telecomunicazioni e delle comunicazioni;
• essere idonei al funzionamento in reti informatiche, sia isolate che connesse ad Internet (o ad altre reti di telecomunicazioni), comprese quelle orientate al trattamento di informazioni classificate come segreti di Stato o dati personali;
• implementare meccanismi moderni per garantire la sicurezza delle informazioni, tenendo conto della possibilità di elaborare informazioni classificate come segreti di Stato in questo sistema operativo, sia in termini di rispetto dei requisiti formali dei documenti e standard normativi pertinenti, sia in termini di protezione reale contro la sicurezza attuale minacce.

Lo sviluppatore di un tale sistema operativo deve disporre di un'infrastruttura ben sviluppata per lo sviluppo e la manutenzione della sua applicazione e del software di sistema. Devono essere implementati meccanismi per garantire la fiducia nello sviluppatore del sistema operativo, la possibilità di fondatezza scientifica della sicurezza delle soluzioni software e hardware implementate in esso.

Domande di studio (parte principale):

1. Panoramica dei sistemi operativi protetti Famiglia Linux

Si ritiene che il sistema operativo Linux (più precisamente GNU / Linux) sia stato creato nel 1991 dal programmatore finlandese di 21 anni Linus Torvalds. In effetti, L. Torvalds ha riscritto da zero il kernel del sistema operativo Minix, un "clone" insignificante del sistema operativo UNIX.

Per molto tempo, l'unico vantaggio di Linux rispetto ad altri sistemi UNIX era la purezza della licenza codice programma Sistema operativo Linux, che consente di distribuire un'ampia varietà di sistemi informativi sulla sua base senza preoccuparsi di potenziali difficoltà con le licenze. Fino al 2000 circa, Linux non si distingueva dagli altri sistemi operativi UNIX, significativamente inferiore a molti di loro in termini di prestazioni e affidabilità.

Per molto tempo, l'apertura del codice del programma del sistema operativo Linux è rimasto l'unico fattore che ha reso questo sistema operativo attraente per gli sviluppatori di software applicativo. Tuttavia, nel tempo, la varietà di software adattati per il sistema operativo Linux ha raggiunto una certa "massa critica" e la situazione è cambiata. Poiché il sistema operativo Linux è diventato lo standard de facto nel mondo dei sistemi operativi UNIX, sempre più programmatori hanno sviluppato applicazioni e software di sistema progettati per eseguire il sistema operativo Linux e i componenti del sistema operativo sono stati sottoposti a test e ottimizzazione sempre più rigorosi . Da un certo punto in poi, l'aumento della popolarità di Linux è diventato un processo autosufficiente e ora questi sistemi operativi costituiscono oltre il 90% dei sistemi operativi della famiglia UNIX.

Quando si confronta il sistema operativo della famiglia Linux con il sistema operativo più popolare delle famiglie Microsoft Windows o Mac OS, colpisce una caratteristica dei sistemi Linux: inizialmente erano più concentrati su utenti professionisti altamente qualificati. Una parte notevole delle azioni necessarie per configurare il sistema e, in alcuni casi, per portarlo in condizioni di lavoro, è eseguita da modifica manuale file di configurazione, modificando o scrivendo da zero vari script, ecc. Per questo motivo, le prime versioni del sistema operativo Linux erano praticamente inaccessibili all'utente generale, ora questo inconveniente è stato ampiamente superato, le versioni moderne del sistema operativo Linux richiedono solo formazione minima.

Spesso gli utenti non sanno nemmeno che stanno lavorando con un sistema operativo di questa famiglia, ad esempio il popolare sistema operativo mobile Android è in realtà un pacchetto di software di sistema distribuito su una piattaforma di un sistema operativo della famiglia Linux.

Tra molti utenti del sistema operativo Linux, c'è un'opinione secondo cui questo sistema operativo si distingue per un sottosistema di protezione insolitamente potente e praticamente invulnerabile. Gli argomenti a sostegno di questa visione sono generalmente citati come aventi meccanismi discrezionali di base di controllo dell'accesso, autenticazione e auditing che sono simili o addirittura inferiori a quelli di altri sistemi operativi. C'è anche un argomento che l'assenza quasi completa di software dannoso per i sistemi operativi Linux è una conseguenza del fatto che questo sistema è molto meglio protetto contro attacchi di virus rispetto, ad esempio, a un sistema operativo della famiglia Microsoft Windows. Questo è completamente sbagliato. In effetti, i virus per i sistemi operativi Linux non si trovano praticamente "nella natura" della comunità degli hacker, ma ciò non è affatto dovuto all'elevata sicurezza di questi sistemi operativi. Nonèdifficile per un programmatore medio assicurarsi che scrivere un virus informatico o un altro programma dannoso per un sistema operativo Linux non sia piùdifficile (con l'eccezione di alcune classi ristrette malware) piuttosto che scrivere un programma simile, ad esempio, per un sistema operativo della famiglia Microsoft Windows. Il numero insignificante di virus Linux è dovuto principalmente al fatto che gli sviluppatori di malware preferiscono prendere di mira le piattaforme software più popolari, per le quali le attività illegali dei criminali informatici generano il maggior reddito.

Le funzionalità di sicurezza di base del sistema operativo Linux sono ereditate dalle prime versioni del sistema operativo UNIX sviluppate nei primi anni '70 del secolo scorso. In base ai requisiti per la compatibilità con le versioni precedenti, il sistema operativo Linux continua a supportare una serie di meccanismi e concetti di sicurezza obsoleti. In particolare, nei sottosistemi di protezione della maggior parte di questi sistemi operativi sono presenti i seguenti "anacronismi":

• tutti gli oggetti di accesso (entità) devono essere interpretati come oggetti file, gli attributi di sicurezza di altri tipi di oggetti non possono essere descritti correttamente mezzi regolari sistema operativo;
• gli identificatori di account utente univoci globali non sono supportati, tutti gli identificatori di utenti e gruppi sono univoci solo all'interno di un'istanza del sistema operativo:
• l'insieme dei diritti di accesso dei soggetti (processi) alle entità (file, directory) è molto limitato, sono supportati solo tre diritti di accesso: lettura, scrittura ed esecuzione e viene specificato anche il proprietario di ciascuna entità;
• i privilegi di superutente root sono praticamente illimitati;
• non esistono meccanismi per l'assegnazione automatica degli attributi di sicurezza alle entità appena create in base agli attributi di sicurezza dei contenitori (cataloghi) in cui vengono create tali entità;
• viene utilizzato un meccanismo SUID/SGID scomodo e potenzialmente pericoloso per modificare dinamicamente l'autorità dei soggetti di accesso;
• non sono supportati meccanismi di impersonificazione di soggetti di accesso che forniscono l'accesso client al processo server;
• non supportato generazione automatica messaggi di audit quando determinate entità fanno riferimento a determinate entità;
• i mezzi supportati per ridurre al minimo i diritti utente sono estremamente primitivi;
• Il controllo dell'integrità obbligatorio non è supportato;
• non supportato isolato ambiente software, anche parzialmente.

Separatamente, vale la pena notare i problemi di sicurezza dell'interfaccia grafica del sistema X Window, che viene utilizzata nelle versioni moderne del sistema operativo Linux per interagire con i processi utente. Gli appassionati di Linux amano criticare Microsoft Windows per la mancanza di sicurezza del suo sottosistema grafico, ad esempio: “In Microsoft Windows NT, qualsiasi processo, indipendentemente dal suo livello di privilegio, può inviare un messaggio alla finestra di un altro processo (incluso un processo più privilegiato uno!), E non c'è modo di stabilire il mittente del messaggio!... Troviamo una finestra di qualche applicazione privilegiata (e abbiamo una tale opportunità), otteniamo l'handle dell'elemento di controllo che ci interessa (pulsanti , voci di menu, righe di modifica) e ... emuliamo l'input dell'utente !!! Il processo privilegiato farà tutto per noi senza sospettare nulla!"

In effetti, questo problema è tipico non solo dei sistemi operativi della famiglia Microsoft Windows. Nel 1994, R. Braaten in un post sensazionale alla conferenza comp.security. Unix ha formulato la minaccia dell'applicazione grafica X Window System che ruba informazioni riservate indirizzate a un altro applicazione grafica... Nel sistema operativo della famiglia Microsoft Windows, a partire dal sistema operativo Windows Vista, è stato introdotto il controllo obbligatorio dell'integrità delle entità grafiche, che ha aumentato notevolmente la sicurezza del sottosistema grafico, ma nulla di simile è accaduto nell'X Window System.

I tentativi di costruire un sistema operativo protetto sulla base di un sistema operativo della famiglia Linux sono stati fatti più volte sia in Russia che all'estero. Storicamente, si può considerare che il primo progetto in questa direzione sia il sistema operativo Linux-Mandrake Russian Edition, sviluppato da un gruppo di appassionati nel 1999-2000. e in seguito "è cresciuto" nel progetto del sistema operativo ALT Linux, supportato da Alt Linux. Dal 2005, la distribuzione del sistema operativo ALT Linux è completamente indipendente. Il sottosistema di sicurezza del sistema operativo ALT Linux presenta diverse interessanti innovazioni (archiviazione separata dei dati di autenticazione utenti diversi, riducendo al minimo il numero di programmi SUID e SGID), che, tuttavia, non influiscono in modo significativo sulla sicurezza complessiva del sistema operativo. Sulla base di ciò, si può presumere che gli sviluppatori del sistema operativo ALT Linux siano guidati dall'uso di questo sistema operativo principalmente in quelle organizzazioni in cui non vi sono requisiti elevati per la sicurezza delle informazioni archiviate ed elaborate (ad esempio, nelle scuole, nelle università , eccetera.).

Suid, setuid e setgid (abbreviazione di "imposta ID utente all'esecuzione" e "imposta ID gruppo all'esecuzione", rispettivamente) sono flag di autorizzazione Unix che consentono agli utenti di eseguire file eseguibili, rispettivamente, con i diritti del proprietario o del gruppo di il file eseguibile.

Sui sistemi Unix-like, l'applicazione viene avviata con i diritti dell'utente che ha chiamato applicazione specificata... Ciò fornisce ulteriore sicurezza, poiché un processo con privilegi utente non sarà in grado di accedere all'accesso in scrittura a file di sistema critici, come / etc / passwd, che è di proprietà del superutente root. Se il bit suid è impostato su un file eseguibile, durante l'esecuzione questo programma cambia automaticamente "userID effettivo" con l'identificativo dell'utente proprietario di questo file. Cioè, indipendentemente da chi avvia questo programma, quando viene eseguito, ha i diritti del proprietario di questo file.

Il bit suid è stato inventato da Dennis Ritchie e brevettato negli USA da AT&T nel 1979. Successivamente, il brevetto 4135240 "Protezione del contenuto dei file di dati" è stato reso disponibile al pubblico.

Un programma con il bit suid impostato è "potenzialmente pericoloso". In un caso "normale", lei non permetterà utente ordinario fare qualcosa che va oltre la sua autorità (ad esempio, il programma passwd consentirà solo all'utente di modificare la propria password). Ma anche un errore minore in un tale programma può portare al fatto che un utente malintenzionato sarà in grado di costringerlo a eseguire alcune altre azioni non fornite dall'autore del programma.

Il primo tentativo di creare un sistema operativo altamente sicuro sulla base di un sistema operativo basato su Linux è stato apparentemente il sistema operativo Phoenix, sviluppato presso la St. Petersburg State Polytechnic University dal 2001. Questo sistema operativo è stato utilizzato in misura limitata presso Jet Infosystems.

Per un certo periodo, il sistema operativo russo più sicuro della famiglia Linux è stato il Sistema mobile delle forze armate (MSVS), sviluppato per ordine del Ministero della Difesa russo dall'Istituto di ricerca panrusso per l'automazione del controllo nel settore non industriale Sphere (VNIINS) basato sul sistema operativo Red Hat Enterprise Linux. Il sistema operativo WSWS è stato adottato per rifornire le forze armate nel 2002. Per molti anni è stato ampiamente utilizzato in una varietà di sistemi informatici militari e a doppio scopo; esistono versioni desktop e server progettate per funzionare su sistemi convenzionali computer domestici... L'ultima versione del WSWS 5.0 ad oggi, certificata nel 2011, contiene il kernel Versione Linux 2.6.32 e glibc versione 2.5 della build del 2006.

glibc è la libreria GNU C. Glibc è una libreria C che fornisce chiamate di sistema e funzioni di base come open, malloc, printf, ecc. La libreria C è usata per tutti i programmi collegati dinamicamente. È scritto dalla Free Software Foundation per i sistemi operativi GNU. glibc è rilasciato sotto licenza GNU LGPL.

L'installazione di software aggiuntivo nel WSWS è molto difficile.

Nel 2006, la Cina ha iniziato a fornire alle agenzie militari e governative il sistema operativo Kylin, sviluppato dalla Chinese National University of Defense Technologies basato sul sistema operativo FreeBSD. Il nome OS significa un animale mitico che è spesso menzionato nel folklore cinese insieme al drago e alla fenice. Il kit di distribuzione del sistema operativo Kylin è disponibile per il download da tempo, secondo gli esperti, questo sistema operativo non contiene alcun meccanismo di sicurezza eccezionale, nessuno menziona il supporto per il controllo dell'accesso obbligatorio, il controllo dell'integrità obbligatorio, il sandboxing, ecc. Nel 2013 Ubuntu Kylin Il progetto OS è stato lanciato ufficialmente, apparentemente non avendo nulla a che fare con il sistema operativo Kylin, tranne che per il nome. Ubuntu Kylin è una versione completamente supportata di Ubuntu Linux Cinese e molti applicazioni preinstallate specifici per la Cina (calendario lunare, facile accesso ai social network cinesi, fornitori di musica cinesi, ecc.).

Il kit di distribuzione è disponibile su www.ubuntukylin.com.

Ci sono prove che una normale distribuzione Ubuntu può essere facilmente convertita nel sistema operativo Ubuntu Kylin come risultato dell'installazione di diversi pacchetti software aggiuntivi. Non ci sono informazioni che il sottosistema di sicurezza di questo sistema operativo sia in alcun modo diverso dal sottosistema di sicurezza del sistema operativo Ubuntu Linux.

La famiglia di sistemi operativi domestici ROSA è stata prodotta dal 2009 dal gruppo di aziende ROSA basato sul sistema operativo Mandriva Linux, ed è attualmente il suo ultimo ramo supportato. La famiglia ROSA OS include OS protetti certificati ROSA Chrome e ROSA Nickel, (è dichiarato il supporto per il controllo di accesso obbligatorio), ROSA Cobalt, nonché diverse distribuzioni gratuite, le cui qualità di consumo sono molto apprezzate dagli utenti. Nella primavera del 2015, STC IT ROSA è diventata una delle cinque società russe che hanno richiesto il sostegno statale per i prodotti software nazionali.

Nel 2010, la famosa ricercatrice polacca sulla sicurezza dei sistemi operativi Joanna Rutkowska ha annunciato che stava sviluppando un sistema operativo sicuro Qubes, basato sul sistema operativo Fedora Linux... Ulteriori strumenti di protezione per questo sistema operativo si basano sull'incapsulamento di applicazioni e programmi di sistema in macchine virtuali separate, la cui interazione è implementata tramite l'hypervisor Xen.

Un hypervisor (eng. Hypervisor; dal greco antico. che esegue più sistemi operativi sullo stesso computer host. L'hypervisor fornisce anche l'isolamento del sistema operativo l'uno dall'altro, protezione e sicurezza, condivisione delle risorse tra diversi sistemi operativi in ​​esecuzione e gestione delle risorse.

L'hypervisor può anche (e deve) fornire i mezzi di comunicazione e interazione tra loro (ad esempio, attraverso lo scambio di file o le connessioni di rete) come se questi sistemi operativi fossero in esecuzione su computer fisici diversi.

L'hypervisor stesso è in qualche modo un sistema operativo minimo (microkernel o nanokernel). Fornisce ai sistemi operativi in ​​esecuzione sotto il suo controllo un servizio di macchina virtuale, virtualizzando o emulando un reale (fisico) Hardware macchina specifica. E gestisce queste macchine virtuali, allocando e liberando risorse per loro. L'hypervisor consente l'"accensione", il riavvio e lo "spegnimento" indipendenti di qualsiasi macchina virtuale con un particolare sistema operativo. Tuttavia, un sistema operativo in esecuzione in una macchina virtuale sotto il controllo di un hypervisor può, ma non deve, "sapere" che è in esecuzione in una macchina virtuale e non su hardware reale.

Il trasferimento dei dati tra le macchine virtuali nel sistema operativo Qubes si basa su una politica di sicurezza a livello di sistema che può potenzialmente supportare il controllo dell'accesso obbligatorio, il controllo dell'integrità obbligatorio, il sandboxing, ecc. La presenza di questa politica diventa evidente all'utente solo se tenta di violare, altrimenti il ​​lavoro dell'utente viene eseguito come in un normale sistema operativo Fedora Linux. Le finestre dei programmi appartenenti a macchine virtuali diverse vengono eseguite su un desktop comune, come se nel software fosse abilitata la modalità seamless Scatola virtuale(nella localizzazione russa questa modalità è chiamata "Modalità di integrazione dello schermo").

Successivamente, un'idea simile è stata implementata dalla società nazionale "NeoBIT", che ha prodotto un sistema operativo ibrido "Linux over Febos", in cui i programmi applicativi vengono eseguiti nelle macchine virtuali del sistema operativo Linux, che, a loro volta, fungono da programmi applicativi per il sistema operativo "Febos" - auto-sviluppato"NeoBIT", che non ha nulla a che fare con la famiglia del sistema operativo Linux. Infatti, il sistema operativo "Febos", per quanto si può giudicare dalle descrizioni disponibili, non contiene nulla se non un microkernel, un hypervisor e un monitor di sicurezza, tutte le interfacce applicative sono collocate nelle macchine virtuali del sistema operativo Linux.

Il sistema operativo "Zarya" è stato sviluppato da JSC "Central Research Institute of Economics of Informatics and Control Systems" (TsNII EISU) per ordine del Ministero della Difesa della Russia nel 2013. Questo sistema operativo è basato su OS CentOS Linux, i suoi schemi di architettura disponibili su Internet non contiene caratteristiche uniche, distinguendolo significativamente dagli altri sistemi operativi della famiglia Linux. Alcune fonti posizionano il sistema operativo "Zarya" come la prossima generazione di OS MSVS. Zarya OS è compatibile con i pacchetti software Libre Office, GIMP e Chromium; esistono versioni del sistema operativo per desktop, server e sistemi embedded.

Nel 2013-2014 dalla società "Red Soft" su ordinazione Servizio federale gli ufficiali giudiziari della Russia hanno sviluppato il sistema operativo "GosLinux", anch'esso basato su OS CentOS, che si posiziona come un sistema operativo sicuro con funzioni che consentono "agli ufficiali giudiziari di elaborare i dati personali di debitori e richiedenti senza fondi aggiuntivi protezione delle informazioni, nonché applicare firma elettronica per la pubblicazione di documenti in in formato elettronico". Il sito web ufficiale della FSSP della Russia afferma che "i principali miglioramenti apportati dal contraente riguardavano il sottosistema crittografico e la preconfigurazione degli strumenti di sicurezza delle informazioni integrati".

In generale, nonostante le ovvie falle di sicurezza del sistema operativo Linux, vasta gamma sviluppi non sempre riusciti di sistemi operativi protetti basati su di essi, attualmente i sistemi operativi di questa famiglia sono ancora quasi una piattaforma ideale per creare un sistema operativo protetto domestico. I meccanismi di protezione a volte primitivi e obsoleti utilizzati nel sistema operativo della famiglia Linux consentono, senza rielaborazioni cardinali, bloccando o tenendo conto delle loro peculiarità, di implementare nel sistema operativo moderni meccanismi di controllo degli accessi obbligatorio e basato sui ruoli, controllo obbligatorio dell'integrità e raggiungere una rigida giustificazione teorica per la sicurezza e la verifica della soluzione risultante. Pertanto, la combinazione di alta affidabilità, qualità accettabili del consumatore, codice open source e possibilità di modifica relativamente semplice dei meccanismi di protezione del sistema operativo Linux consentono di costruire sulla base un sistema operativo domestico altamente sicuro a un costo significativamente inferiore sforzo che se fosse stato creato da zero o costruito su altre piattaforme.

2.Architettura, scopo e aree di applicazione del sistema operativo per scopi speciali Astra Linux Special Edition

2.1. Nomina di OSSN

Quando si costruiscono promettenti e si modernizzano centrali nucleari esistenti, un compito urgente è usare soluzioni standard, standardizzazione e unificazione di piattaforme hardware e software, inclusi OS, ambienti di sviluppo software, sistemi e complessi software applicativi per supportare il funzionamento degli attuali servizi informativi del sistema automatizzato. Tale approccio, prima di tutto, è associato alla riduzione dei costi di implementazione e amministrazione dei componenti AU, riducendo i tempi di sviluppo e/o porting del software necessario per il loro funzionamento, aumentando l'efficienza del processo di formazione per il personale che amministra e opera loro infrastruttura informativa.

Un ulteriore aspetto rilevante per le condizioni moderne sono le questioni relative alla limitazione dell'uso di prodotti fabbricati all'estero all'interno dell'UA (principalmente quelli che funzionano nell'interesse delle autorità statali), per i quali esistono analoghi nazionali. In particolare, le modifiche apportate alle leggi federali "Sull'informazione, le tecnologie dell'informazione e la protezione delle informazioni" e "Sul sistema contrattuale nell'approvvigionamento di beni, lavori, servizi per soddisfare le esigenze statali e comunali" sono direttamente correlate al tasso di sostituzione delle importazioni sulla base delle tendenze di sviluppo del mercato del software russo.

Inoltre, nel corso della risoluzione di questo problema fattore importanteè la stretta conformità di tali sviluppi con gli standard nazionali nel campo della sicurezza delle informazioni, ad esempio, per ASZI è GOST 51583-2014 "Sicurezza delle informazioni. La procedura per la creazione di sistemi automatizzati in versione protetta. Disposizioni generali ", e i requisiti dei sistemi di certificazione nazionali per gli strumenti di sicurezza delle informazioni per i requisiti di sicurezza delle informazioni.

In questo senso, l'OSSN tiene sufficientemente conto della maggior parte degli aspetti discussi sopra. Secondo documentazione tecnica lo scopo fondamentale dell'OSSN è costruire, sulla sua base, Sistemi Automatizzati in Esecuzione Protetta (ASZI), elaborando informazioni contenenti informazioni che costituiscono segreto di stato con un timbro non superiore a "top secret". In generale, insieme alla protezione di tali informazioni, AS implementato utilizzando OSSN può fornire protezione dei seguenti tipi di informazioni:

• informazioni confidenziali;
• segreto commerciale;
• Informazione personale.

Le capacità specificate dell'OSSN sono confermate dai seguenti certificati di conformità dei partecipanti ai sistemi di certificazione nazionali per i prodotti per la sicurezza delle informazioni in conformità con i requisiti di sicurezza delle informazioni (Tabella 2.1).

Tabella 2.1.

Questi certificati danno motivo di utilizzare l'OSSN come parte dell'AS di varie classi di sicurezza contro l'accesso non autorizzato alle informazioni (NSD) e livelli di controllo dell'assenza di capacità non dichiarate (NDV) come parte dei componenti del sistema (Tabella 2.2).

Da tavola. 2.2 ne consegue che OSSN, nel caso estremo, è certificato per l'utilizzo in AS multiutenza, i cui utenti hanno differenti poteri di accesso alle informazioni trattate (classe 1B), secondo la classe 3 di protezione contro l'accesso non autorizzato e il livello 2 di controllo delle l'assenza di NDV.

Pertanto, attualmente, OSSN è un sistema operativo certificato in tutti e tre i sistemi di certificazione degli strumenti di sicurezza delle informazioni per i requisiti di sicurezza delle informazioni.

2.2. Architettura OSSN

La base architetturale di OSSN è il progetto Debian GNU/Linux - un'associazione di sviluppatori di software libero, la cui base è il sistema operativo della famiglia GNU/Linux basato su Kernel Linux nocciolo.

A questo proposito, in generale, l'architettura dell'OSSN corrisponde alle soluzioni architetturali di GNU/Linux (Fig. 2.1).

Allo stesso tempo, le caratteristiche di implementazione corrispondono alle caratteristiche di implementazione del sistema operativo del progetto Debian GNU/Linux, in particolare:

• supporto attivo per le ultime versioni degli standard all'interno dei progetti Linux FSH e LSB;
• la presenza di più di undici porte ufficiali (porte) per varie architetture di processori;
• la presenza di un sistema di gestione dei pacchetti software APT (Advanced Packaging Tool) con una politica rigorosa in relazione al software sviluppato, supporto per una vasta rete di repository e un meccanismo standard per la scelta del software preferito tra diverse opzioni (alternative);
• un gran numero (più di 40 mila) pacchetti di software applicativo compatibile;
• sistema avanzato di eliminazione degli errori, fornendo alta qualità codice driver, servizi di sistema e mantiene un'elevata stabilità del sistema operativo basato sul progetto Debian GNU/Linux.

A causa della portabilità della distribuzione del progetto Debian GNU/Linux su varie architetture di processori, OSSN supporta anche il porting sulle seguenti architetture:

• amd64 - Processori Intel e AMD con micro architettura del processore a, 86-64;
• armel / armhf- 32 e 64 bit core del processore sviluppo da parte di ARM Limited;
• s390.r - Spazio utente a 64 bit per mainframe IBM System z.

Le versioni esistenti del kit di distribuzione OSSN si basano su queste porte. Le loro designazioni differiscono per l'edizione del kit di distribuzione e il numero di versione. L'edizione di rilascio del kit di distribuzione determina le specifiche del kit di distribuzione: la porta supportata (piattaforma hardware) e l'ambito. Numero di versione - due o tre cifre, che identifica la versione del kit di distribuzione OSSN.

Nel kit di distribuzione OSSN installato, la designazione completa della versione del kit di distribuzione nel file /etc/astra-veision è memorizzata nel seguente formato:

EDIZIONE V.U.Y (nome)

dove si usa la seguente notazione:

EDITION - l'edizione del kit di distribuzione (per OSSN è “SE”);

V è la prima cifra del numero di release associata al suo nome;

U è il numero della versione di rilascio;

Y - il numero dell'aggiornamento all'interno della versione di rilascio (se non ci fossero tali aggiornamenti, il numero di aggiornamento è assente);

(nome) - il nome del rilascio del kit di distribuzione in alfabeto latino (associato alla sua edizione e alla prima cifra del numero di versione), di norma vengono utilizzati i nomi delle città eroiche della Federazione Russa .

Rilasci del kit di distribuzione OSSN e loro designazioni per la versione 1.4 sono presentati in tabella. 2.3.

La versione attuale è la 1.5.

La versione "Smolensk" del sistema operativo per scopi speciali Astra Linux Special Edition è progettata per funzionare sui fondi tecnologia informatica con architettura del processore x86-64.

La versione Novorossiysk è destinata al funzionamento su computer mobili e embedded con architettura del processore ARM.

L'architettura ARM (dall'inglese Advanced RISC Machine - una macchina RISC avanzata; a volte - Acorn RISC Machine) è una famiglia di core di microprocessori a 32 e 64 bit con licenza sviluppati da ARM Limited.

RISC (computer con set di istruzioni ridotto) è un'architettura del processore in cui le prestazioni vengono aumentate semplificando le istruzioni in modo che la loro decodifica sia più semplice e il tempo di esecuzione sia più breve. I primi processori RISC non avevano nemmeno istruzioni di moltiplicazione e divisione. Semplifica inoltre l'overclocking e rende più efficiente il superscalare (istruzioni di parallelizzazione su più unità di esecuzione).

La versione Murmansk è progettata per essere eseguita su mainframe IBM System Z.

IBM System z (precedentemente noto come IBM eServer zSeries) è un marchio creato da IBM per indicare una linea di mainframe.

La lettera Z deriva da "zero down time", che significa "zero down time", che consente di mantenere il server in funzione 24 ore al giorno, 7 giorni alla settimana, 365 giorni all'anno.

La versione Sevastopol è un kit di distribuzione Astra Linux Special Edition progettato per funzionare su computer desktop, mobili e embedded con architettura di processore MIPS.

MIPS (Microprocessor without Interlocked Pipeline Stages) è un microprocessore sviluppato da MIPS Computer Systems (ora MIPS Technologies) in conformità con il concetto di progettazione dei processori RISC (ovvero per processori con un set di istruzioni semplificato). I primi modelli di processore avevano una struttura a 32 bit, sono apparse versioni successive a 64 bit.

La versione Kerch è un kit di distribuzione Astra Linux Special Edition progettato per funzionare su server ad alte prestazioni basati su piattaforme di architettura del processore POWER.

POWER è un'architettura a microprocessore con set di istruzioni limitato (RISC) progettata e sviluppata da IBM. Il nome è stato successivamente trascritto come Performance Optimization With Enhanced RISC (ottimizzazione delle prestazioni basata sull'architettura RISC avanzata). Questa parola si riferisce anche a una serie di microprocessori che utilizzano il set di istruzioni specificato. Sono utilizzati come unità di elaborazione centrale in molti microcomputer, sistemi embedded, workstation, mainframe e supercomputer.

In futuro (se non è specificamente indicato nel testo), quando si considera l'OSSN come una versione di distribuzione, viene utilizzata la versione "Smolensk" versione 1.4. Questa versione è basata sulla distribuzione Debian GNU / Linux 7.0 (Wheezy). I dettagli della sua architettura relativa all'architettura generica GNU/Linux (Fig. 2.1) sono mostrati in Fig. 2.2.

Mostrato in Fig. 2.2 componenti di base, librerie e strumenti di sviluppo come parte del kit di distribuzione OSSN implementano le seguenti funzioni di base:

• avviare programmi, caricarli nella RAM e gestirne l'esecuzione;
• supporto multitasking preventivo;
• smistamento di risorse hardware del computer tra programmi in esecuzione;
• comunicazione tra processi;
• organizzazione del meccanismo della memoria virtuale;
• Supporto I/O e organizzazione logica dispositivi di memoria ( dischi fissi, unità SSD, unità ottiche, unità USB);
• supporto del file system;
• supporto per input/output su periferiche;
• supporto per stack di protocolli di rete;
• fornire una modalità di funzionamento multiutente;
• fornire una riga di comando dell'interfaccia utente CLI (Command Line Interface);
• fornire una GUI (Graphical User Interface) per un'interfaccia utente grafica, anche per computer dotati di touch screen che supportano l'input multipunto;
• supporto per lo sviluppo e il debug di software applicativo con interfaccia utente CLI e GUI.

Per organizzare un'infrastruttura di rete di dominio distribuita sulla base di OSSN, il suo kit di distribuzione include OpenLDAP, un'implementazione open source del protocollo LDAP. Per generare chiavi di crittografia, certificati a chiave pubblica ed eseguire la crittografia dei dati per le connessioni SSL/TLS, il kit di distribuzione OSSN include il pacchetto crittografico OpenSSL.

Il supporto per OpenLDAP e OpenSSL fornisce l'implementazione della funzione Unified User Space (EPP) all'interno dell'infrastruttura di dominio Astra Linux Directory (ALD) con supporto per controller di dominio ridondanti e stabilendo relazioni di fiducia tra di loro.

Oltre ai componenti di base, alle librerie e agli strumenti di sviluppo, il kit di distribuzione OSSN include un software generale che implementa le seguenti funzioni:

• elaborazione di informazioni documentarie (testo, editor di fogli di calcolo e strumenti per la creazione di materiali di presentazione e accesso a database relazionali dati);
• scansione, stampa e trasmissione d'informazioni documentarie;
• accesso alle informazioni archiviate in database relazionali, incluso il supporto per software 1C e software per lavorare con siti geografici PostGIS;

Tabella 2.5. Il nome e le versioni del software generale del distributore OSSN.

accesso alle informazioni tramite un server di elaborazione dati ipertestuali (server e client HTTP);

• messaggistica e-mail (server e client SMTP/IMAP);
• lavorare con la grafica e la multimedialità (audio, video).

Il nome e le versioni dei tipi di software elencati sono presentati nella tabella. 2.5.

Una caratteristica fondamentale del kit di distribuzione OSSN è che include un sistema di sicurezza delle informazioni che fornisce le seguenti funzioni:

• autenticazione dell'utente utilizzando l'infrastruttura PAM (Pluggable Authentication Modules) localmente e all'interno dell'EPP, autenticazione a due fattori basata su firma digitale e infrastruttura a chiave pubblica supportata dal supporto esterno di informazioni di autenticazione "Rutoken";
• identificazione dell'utente tramite l'ambiente modulare NSS (Name Service Switch) localmente e all'interno dell'EPP;
• controllo discrezionale dell'accesso dei processi (soggetto-sessioni) alle risorse (entità) con supporto agli standard Minimal ACL e Extended ACL - modello DP di ruolo - modello DP di MROSL, i cui elementi di base saranno discussi nelle prossime lezioni);

Invece del sistema di controllo degli accessi obbligatorio SELinux, Astra Linux Special Edition utilizza un modello DP basato sul ruolo dell'entità obbligatorio brevettato per il controllo dell'accesso e dei flussi di informazioni (modello MROSL DP)

• basato sul modello MROSL DP, controllo obbligatorio dell'accesso dei processi alle risorse, la cui implementazione in OSSN viene eseguita ai livelli del meccanismo di comunicazione interprocesso, inclusi i file system rtos e tmpfs, il TCP / IP (IPv4) stack di protocollo, a livello virtuale file system(VFS) e nei file system della famiglia extfs (Ext2, Ext3, Ext4);
• isolamento degli spazi di indirizzamento dei processi;
• registrazione (logging) e audit degli eventi, implementato come sistema centralizzato con la funzione di notificare all'amministratore della sicurezza i tentativi di manomissione;
• pulizia della RAM e delle aree dati liberate su supporti con file system Ext2, Ext3, Ext4:
• controllo normativo dell'integrità delle entità del file system, inclusa l'invariabilità dei file eseguibili e la conformità con la distribuzione di riferimento OSSN, basata sulla libreria libgost, che implementa la funzione di hashing in conformità con GOST R 34.11-94, e il controllo dell'integrità obbligatorio, che impedisce ai soggetti compromessi di accedere alle informazioni protette dopo l'intercettazione del controllo e l'escalation dei privilegi (gli elementi del controllo di integrità obbligatorio sono specificati anche all'interno del modello MROSL DP e sono discussi nel capitolo 2);
• basato sul controllo di integrità obbligatorio, un ambiente software chiuso che consente di definire per ogni account utente un elenco individuale di software consentito per l'uso, con la possibilità di scaricare portachiavi gerarchici per la verifica della firma digitale dei file eseguibili dell'ELF (Eseguibili e Linkable Format) formato, implementato in conformità con GOST R 34.10-2001;
• contrassegnare i documenti con livelli di riservatezza durante la stampa;
• garantire un ripristino affidabile di OSSN dopo i guasti;
• implementazione di regole per il controllo dell'accesso ai media esterni (per questo, le entità con etichette indirette sono specificate all'interno del modello MROSL DP);
• fornire l'accesso a banche dati relazionali nel rispetto dei requisiti per la gestione dell'accesso alle informazioni contenenti informazioni costituenti segreto di Stato con timbro non superiore a "top secret", compatibile con il controllo obbligatorio degli accessi e il controllo obbligatorio dell'integrità implementato in OSSN (a tal fine, MROSL DP- il modello è stato esteso per l'utilizzo con il DBMS PostgreSQL standard per OSSN);
• fornitura dell'accesso alle informazioni tramite un server informatico ipertestuale, scambio di messaggi di posta elettronica in conformità ai requisiti per la gestione dell'accesso alle informazioni contenenti informazioni costituenti segreto di Stato con timbro non superiore a "top secret". Inoltre, al kernel di distribuzione OSSN è stato aggiunto un pacchetto aggiuntivo per il modulo PaX (uno strumento per limitare i diritti di accesso alle pagine di memoria), che garantisce l'esecuzione del software in modalità con privilegi minimi e la protezione dallo sfruttamento di vari vulnerabilità in esso da:
• vietare la scrittura nell'area di memoria contrassegnata come eseguibile;
• vietare la creazione di aree di memoria eseguibili;
• vietare la circolazione del segmento di codice;
• vietare la creazione di uno stack eseguibile;
• allocazione casuale dello spazio degli indirizzi del processo. Un componente importante di OSSN è il sottosistema di sicurezza PARSEC, che estende il sistema Linux standard di privilegi progettato per trasferire agli utenti i diritti per eseguire le funzioni di un amministratore OSSN con il supporto per il controllo di accesso obbligatorio e il controllo di integrità obbligatorio. Il sottosistema PARSEC supporta i seguenti privilegi estesi:
• inviare segnali ai processi, ignorando le regole discrezionali e obbligatorie di controllo degli accessi;
• modificare i livelli di accesso (tag obbligatori) degli account utente e impostare altri privilegi;
• modificare i livelli di riservatezza (tag obbligatori) riservatezza dei file;
• gestire la politica di audit;
• ignorare le regole del controllo di accesso obbligatorio durante la lettura e la ricerca di file (esclusa la funzione di scrittura);

• creare un socket privilegiato e modificarne il livello di privacy;
• modificare il tempo di accesso al file;
• ignorare il controllo di accesso obbligatorio per livelli di riservatezza e categorie non gerarchiche;
• impostare i privilegi dei file;
• impostare un insieme coerente di privilegi per il processo selezionato;
• modificare il livello di privacy del punto di connessione di rete.

Il sottosistema di sicurezza PARSEC implementa questi privilegi estesi utilizzando un meccanismo di intercettazione delle chiamate di sistema (hook), che intercetta e analizza gli argomenti della richiesta di processo e li consente o li nega in conformità con le regole stabilite del controllo obbligatorio degli accessi. Pertanto, nell'OSSN, il contesto obbligatorio (i livelli di riservatezza, accesso e integrità utilizzati nella richiesta) viene letto durante l'esecuzione di ciascuna richiesta in locale o in remoto (all'interno dell'EPP) del processo in esecuzione.

Una caratteristica unica del sottosistema di sicurezza PARSEC è la sua implementazione come modulo XPARSEC che estende le funzionalità del server X.Org e del gestore di finestre Fly-wm. Grazie a questo modulo, il server X.Org è in grado di determinare i privilegi del client X.Org (programma con interfaccia GUI) e trasferirli utilizzando il protocollo X modificato al window manager Fly-wm, che esegue operazioni privilegiate durante il lancio del client X.Org con vari contesti obbligatori. In questo caso, sul desktop Fly viene visualizzato quanto segue:

• il contesto obbligatorio della sessione utente nell'area di notifica sulla barra delle applicazioni;
• livello obbligatorio di riservatezza e integrità di ciascuna finestra;
• livello di privacy della finestra per locale e remoto applicazione in esecuzione(cornice colore - cornice della finestra dell'applicazione);
• livello obbligatorio e integrità di tutte le applicazioni che si trovano sul desktop Fly.

2.3. Applicazioni di OSSN

Le caratteristiche architetturali considerate dell'OSSN, come l'implementazione dell'EPP basata sull'infrastruttura di rete di dominio ALD, e il complesso DSS integrato nel kit di distribuzione dell'OSSN, determinano i suoi principali ambiti di applicazione, che nel caso generale sono fissati dallo sviluppatore nelle seguenti aree di complessi software e hardware e complessi di strumenti di automazione;

• reti informatiche locali (aziendali);
• relatori geograficamente distribuiti.

Attualmente, sulla base del kit di distribuzione OSSN, sono stati implementati numerosi progetti ASZI in ministeri e dipartimenti: l'FSB della Russia, l'UST della Russia, il Ministero della Difesa della Russia, l'SVR della Russia, il Federal Drug Servizio di controllo della Russia, Servizio penitenziario federale della Russia, Servizio fiscale federale della Russia, Direzione unitaria statale della Federazione Russa, Ministero della salute della Russia, Ministero dell'istruzione e della scienza della Russia, le truppe interne del Ministero degli affari interni della Russia; corporazioni e agenzie statali: Rosatom, Roskosmos, Rostekhnologii, un certo numero di imprese del complesso militare-industriale; nell'ambito interdipartimentale sistema informativo sistema automatizzato di stato dell'ordine di difesa dello stato (GAS GOZ).

Nella fig. 2.3 presenta una variante dell'implementazione di una rete locale sicura aziendale (ZLAN), che supporta un sistema di comunicazione multiservizio, che fornisce l'implementazione di servizi sicuri:

• videoconferenze;
• telefonia IP;
• un portale informativo basato su un web server;
• server di banca dati;
• server email.

Questi servizi sono implementati sulla base di piattaforme server, che operano nella versione server dell'installazione della versione OSSN "Smolensk". Come computer client tali ZLVS sono:

• computer fissi o mobili con architettura di processore Intel x86-64, operanti nella versione client dell'installazione OSSN della versione Smolensk;
• computer tablet con architettura di processore ARM operanti nella versione client dell'installazione OSSN della versione Novorossiysk.

Nella fig. 2.3 mostra che per gli abbonati a una ZLAN aziendale, un EPP è organizzato sulla base del dominio dell'infrastruttura di rete ALD con un controller di dominio dedicato che opera nella versione server dell'installazione OSSN della versione di Smolensk. Inoltre, nell'ambito di tale ZLVS, può essere implementato un servizio di cloud privato (Private Cloud), implementato utilizzando le tecnologie di virtualizzazione OSSN della versione di Smolensk (Fig. 2.4).

Nel contesto dell'accesso remoto alle risorse discusso in fig. 2.3 ZLVS attraverso canali di comunicazione affittati da un fornitore di servizi di telecomunicazione, le AWP mobili di abbonati ZLVS remoti possono connettersi ai server ZLVS utilizzando, ad esempio, meccanismi VPN / MPLS. Allo stesso tempo, al confine del segmento aziendale della ZLAN, è installato un cripto-router di confine: un firewall, che può funzionare sulla base della versione OSSN "Tula". Un esempio di uno schema per tale implementazione di accesso remoto a uno ZLVS è mostrato in Fig. 2.5.

Pertanto, l'insieme delle versioni OSSN offre la possibilità di creare sia ASZI su varie piattaforme software e hardware, sia varie configurazioni di reti di computer, comprese le tecnologie cloud e i meccanismi di accesso remoto sicuro.

INTRODUZIONE

Sala operatoria Sistema Linux ha ereditato il sistema di sicurezza Unix, sviluppato negli anni '70, avanzato al momento della creazione, ma oggi chiaramente insufficiente. Ogni utente ha piena libertà di azione entro i limiti della sua autorità su base tutto o niente. Ciò porta al fatto che per eseguire alcune attività, all'utente vengono spesso concessi molti più diritti di quelli realmente necessari. Pertanto, un utente che ha ottenuto l'accesso con i diritti di un account di sistema può praticamente ottenere controllo completo sopra il sistema.

Nel corso del funzionamento di qualsiasi applicazione, possono verificarsi varie deviazioni, che portano, di conseguenza, alla sua esecuzione anormale. Questi possono essere sia errori di sistema, errori di programmazione che situazioni causate artificialmente. Un hacker, avendo scoperto che in determinate condizioni è possibile influenzare l'esecuzione del programma, naturalmente, cercherà di trarne vantaggio. È quasi impossibile prevedere il comportamento di un programma in modalità freelance. Un esempio di ciò sono gli antivirus, che lavorano sempre a un ritmo di "recupero", non fornendo protezione contro i cosiddetti attacchi zero-day. Tuttavia, il comportamento normale di un programma può essere descritto utilizzando regole relativamente semplici. Di conseguenza, sono emersi diversi progetti che implementano il concetto di protezione proattiva.

Lo scopo di questo tesinaè lo studio di prodotti software volti a rafforzare la sicurezza del sistema operativo, analisi comparativa le loro caratteristiche principali, nonché riassumere i risultati del lavoro svolto e giustificare la loro applicazione pratica.

DEFINIZIONE DI SISTEMA OPERATIVO PROTETTO. SELINUX

Concetto di sistema operativo protetto

Sistema operativo- un pacchetto software che fornisce il controllo dell'hardware del computer, organizza il lavoro con i file e l'esecuzione di programmi applicativi e fornisce input e output di dati.

Calcolare il "sistema operativo più sicuro" non è così facile come sembra a prima vista. Criterio principale Il numero di vulnerabilità identificate è il numero di vulnerabilità che guidano gli utenti che non hanno familiarità con gli standard di sicurezza. Tuttavia, il minimo di scappatoie riscontrate nel sistema non è ancora un motivo per considerarlo protetto in modo affidabile. Ci sono una serie di fattori da considerare quando si parla di sicurezza, tra cui:

- se viene verificata la qualità del codice sorgente del sistema operativo;

- cosa viene dato impostazioni standard sicurezza;

- con quanta rapidità ed efficienza vengono rilasciate le correzioni;

- come funziona il sistema di distribuzione dei poteri e molto altro.

Quando si sceglie un sistema operativo sicuro, Linux dovrebbe essere assolutamente considerato.

Innanzitutto, il sistema operativo Windows non è mai stato progettato direttamente per garantire la sicurezza del sistema, è stato sempre chiuso agli occhi esterni: tutto il codice di Windows è crittografato. In teoria, Windows può essere preparato per un uso sicuro, ma ciò non è ancora stato fatto poiché richiederebbe una quantità enorme di tempo. Linux, in virtù della sua apertura, permette di lavorare con il codice sorgente del sistema operativo. Sono già state rilasciate versioni speciali di Linux, che sono completamente sicure.

In secondo luogo, la tecnologia Live CD - Linux "può" avviarsi e distribuire molto rapidamente senza installare su disco fisso... Un sistema operativo così sicuro può essere scritto su un disco ottico o un'unità USB e averlo sempre con te. "In un batter d'occhio" è possibile ottenere un sistema operativo con un desktop già pronto e relative applicazioni per lavorare su Internet, indipendentemente dal sistema operativo principale installato nel computer da utilizzare.

Il kernel è il componente centrale del sistema operativo. È responsabile della gestione delle risorse di sistema, della comunicazione tra hardware e software e della sicurezza. Il kernel svolge un ruolo fondamentale nel mantenere la sicurezza a livelli più elevati.

Come indicato in precedenza, ci sono una serie di importanti patch del kernel Linux per aiutare a mantenere sicuro il tuo sistema. Le loro differenze significative riguardano principalmente il modo in cui vengono amministrati e il modo in cui si integrano in un sistema esistente. Inoltre, le patch forniscono il controllo dell'accesso tra processi e oggetti, processi e altri processi, oggetti e altri oggetti.

Il sistema operativo si chiama protetto, se fornisce mezzi di protezione contro le principali classi di minacce. Un sistema operativo protetto deve necessariamente contenere mezzi per delimitare l'accesso dell'utente alle proprie risorse, nonché mezzi per autenticare l'utente che inizia a lavorare con il sistema operativo. Inoltre, il sistema operativo protetto deve contenere mezzi per contrastare la disattivazione accidentale o deliberata del sistema operativo.

Se il sistema operativo fornisce protezione non da tutte le principali classi di minacce, ma solo da alcune, viene chiamato tale sistema operativo parzialmente protetto .

Approcci alla creazione di sistemi operativi sicuri

Esistono due approcci principali alla creazione di sistemi operativi sicuri: frammentati e complessi. In frammentario approccio, in primo luogo, la protezione è organizzata contro una minaccia, poi contro un'altra, ecc. ecc.

Quando si utilizza l'approccio frammentato, il sottosistema di protezione del sistema operativo è un insieme di prodotti software disparati, di norma, di produttori diversi. Questi strumenti software funzionano indipendentemente l'uno dall'altro, mentre è quasi impossibile organizzare la loro stretta interazione. Inoltre, i singoli elementi di un tale sottosistema di protezione potrebbero non funzionare correttamente in presenza l'uno dell'altro, il che porta a una forte diminuzione dell'affidabilità del sistema.

In un integrato approccio, le funzioni di protezione vengono introdotte nel sistema operativo nella fase di progettazione dell'architettura del sistema operativo e ne sono parte integrante. I singoli elementi del sottosistema di protezione, creati sulla base di un approccio integrato, interagiscono strettamente tra loro nella risoluzione di vari problemi relativi all'organizzazione della protezione delle informazioni, pertanto i conflitti tra i suoi singoli componenti sono praticamente impossibili. Il sottosistema di protezione, creato sulla base di un approccio integrato, può essere progettato in modo tale che in caso di guasti irreversibili nel funzionamento dei suoi elementi chiave, provochi il crash del sistema operativo, il che non consente a un utente malintenzionato di disabilitare le funzioni protettive del sistema. Con un approccio frammentato, una tale organizzazione del sottosistema di protezione è impossibile.

Di norma, il sottosistema di protezione del sistema operativo, creato sulla base di un approccio integrato, è progettato in modo che i suoi singoli elementi siano sostituibili. I moduli software corrispondenti possono essere sostituiti da altri moduli.

Garanzie amministrative

L'hardware e il software di protezione del sistema operativo devono essere integrati con misure di protezione amministrativa. Anche una protezione hardware e software affidabile può fallire senza un costante supporto qualificato da parte dell'amministratore. Elenchiamo le principali misure di tutela amministrativa.

• 1. Monitoraggio continuo del corretto funzionamento del sistema operativo, in particolare il suo sottosistema di protezione. È conveniente organizzare tale controllo se il sistema operativo supporta la registrazione automatica del più eventi importanti (registrazione eventi) in un giornale speciale.
• 2. Organizzazione e mantenimento di un'adeguata politica di sicurezza. La politica di sicurezza del sistema operativo deve essere costantemente adattata, rispondendo prontamente ai tentativi degli intrusi di superare la protezione del sistema operativo, nonché alle modifiche alla configurazione del sistema operativo, all'installazione e alla rimozione dei programmi applicativi.
• 3. Istruire gli utenti del sistema operativo su la necessità di rispettare le misure di sicurezza quando si lavora con il sistema operativo e il monitoraggio del rispetto di tali misure.
• 4. Creazione e aggiornamento regolari dei backup programmi e dati del sistema operativo.
• 5. Monitoraggio continuo delle modifiche ai dati di configurazione e alla politica di sicurezza del sistema operativo.È consigliabile archiviare le informazioni su queste modifiche su supporti di memorizzazione non elettronici, in modo che sia più difficile per un utente malintenzionato che ha superato la protezione del sistema operativo mascherare le proprie azioni non autorizzate.

Sistemi operativi specifici possono richiedere altre misure amministrative per proteggere le informazioni.

Adeguata politica di sicurezza

La selezione e il mantenimento di una politica di sicurezza adeguata è uno dei compiti più importanti di un amministratore del sistema operativo. Se la politica di sicurezza adottata nel sistema operativo è inadeguata, ciò può comportare l'accesso non autorizzato di un intruso alle risorse di sistema e una diminuzione dell'affidabilità del sistema operativo.

È un'affermazione ben nota: più è protetto il sistema operativo, più è difficile per gli utenti e gli amministratori lavorarci. Ciò è dovuto ai seguenti fattori:

• il sistema di sicurezza non è sempre in grado di determinare se alcune azioni dell'utente sono dannose. Pertanto, il sistema di protezione non sopprime alcuni tipi di attacchi non autorizzati o vieta alcune azioni completamente legali degli utenti. Maggiore è la sicurezza del sistema, più ampia è la classe di quelle azioni legali degli utenti che sono considerate dal sottosistema di protezione come non autorizzate;
• qualsiasi sistema in cui vengono fornite funzioni di sicurezza delle informazioni richiede determinati sforzi da parte degli amministratori per mantenere una politica di sicurezza adeguata. Più funzioni protettive nel sistema operativo, più tempo e denaro devi spendere per mantenere la protezione;
• Il sottosistema di protezione del sistema operativo, come qualsiasi altro pacchetto software, consuma risorse hardware del computer. Più complesse sono le funzioni di protezione del sistema operativo, più risorse del computer (tempo del processore, RAM, ecc.) vengono spese per la manutenzione del sottosistema di protezione e meno risorse rimangono per i programmi applicativi;
• il mantenimento di una politica di sicurezza troppo rigorosa può influire negativamente sull'affidabilità del sistema operativo. Una politica di sicurezza eccessivamente rigorosa può portare a errori e guasti difficili da rilevare nel processo di funzionamento del sistema operativo e persino al suo collasso.

Politica di sicurezza adeguata ottimale - questa è una politica di sicurezza che non solo impedisce agli intrusi di eseguire azioni non autorizzate, ma non porta nemmeno agli effetti negativi sopra descritti.

Un'adeguata politica di sicurezza è determinata non solo dall'architettura del sistema operativo, ma anche dalla sua configurazione, dai programmi applicativi installati, ecc. La formazione e il mantenimento di un'adeguata politica di sicurezza del sistema operativo può essere suddivisa in una serie di fasi.

• 1. Analisi delle minacce. L'amministratore del sistema operativo considera possibili minacce alla sicurezza per questa istanza del sistema operativo. Tra le possibili minacce, vengono evidenziate le più pericolose, la protezione dalla quale è necessario dedicare il massimo dei fondi.
• 2. Formazione dei requisiti per la politica di sicurezza. L'amministratore determina quali strumenti e metodi verranno utilizzati per proteggersi da determinate minacce. Ad esempio, la protezione dalla manomissione di un determinato oggetto del sistema operativo può essere risolta mediante il controllo dell'accesso o mediante mezzi crittografici o utilizzando una combinazione di questi mezzi.
• 3. Definizione formale della politica di sicurezza. L'amministratore determina esattamente come devono essere soddisfatti i requisiti formulati nella fase precedente. Vengono formulati i requisiti necessari per la configurazione del sistema operativo, nonché i requisiti per la configurazione di pacchetti di protezione aggiuntivi, se è necessaria l'installazione di tali pacchetti. Il risultato di questa fase è un elenco dettagliato delle impostazioni di configurazione del sistema operativo e dei pacchetti di protezione aggiuntivi, che indica in quali situazioni e quali impostazioni devono essere installate.
• 4. Attuazione della politica di sicurezza. Il compito di questa fase è portare la configurazione del sistema operativo e i pacchetti di protezione aggiuntivi in ​​conformità con la politica di sicurezza definita formalmente nella fase precedente.
• 5. Mantenimento e correzione della politica di sicurezza. Il compito dell'amministratore in questa fase è controllare la conformità con la politica di sicurezza e apportare le modifiche necessarie non appena si verificano modifiche nel funzionamento del sistema operativo.

Non esistono standard di sicurezza specifici del sistema operativo. Per valutare la sicurezza di un sistema operativo vengono utilizzati standard sviluppati per i sistemi informatici in genere. Di norma, la certificazione di un SO per una determinata classe di protezione è accompagnata dalla predisposizione dei requisiti per un'adeguata politica di sicurezza, la cui attuazione incondizionata un'istanza specifica Il sistema operativo soddisferà i requisiti della classe di protezione corrispondente.

Quando si definisce una politica di sicurezza adeguata, l'amministratore del sistema operativo dovrebbe concentrarsi principalmente sulla protezione del sistema operativo da minacce specifiche alla sua sicurezza.