Appendix A. Guidelines for Model Designers (Appendice A. Linee guida per i progettisti di modelli)

Questa appendice fornisce linee guida per i progettisti di modelli di sicurezza, modelli di elaborazione dei messaggi, modelli di controllo degli accessi e applicazioni SNMP. Queste linee guida sono informative e sono destinate ad assistere gli implementatori nella creazione di componenti che funzionano correttamente all'interno dell'architettura SNMP.

A.1. Security Model Design Requirements (Requisiti di progettazione del modello di sicurezza)

Un modello di sicurezza deve fornire meccanismi per autenticazione, privacy e controllo della tempestività. Questa sezione descrive i requisiti per i modelli di sicurezza.

A.1.1. Threats (Minacce)

I modelli di sicurezza devono affrontare le seguenti minacce:

Modifica delle informazioni: Un'entità non autorizzata che altera i messaggi in transito
- Un modello di sicurezza deve fornire servizi di integrità dei dati per rilevare tale modifica
Mascheramento: Un'entità non autorizzata che assume l'identità di un'entità autorizzata
- Un modello di sicurezza deve fornire servizi di autenticazione per verificare l'identità
Modifica del flusso di messaggi: Riordino, ritardo o riproduzione di messaggi
- Un modello di sicurezza deve fornire controllo della tempestività per rilevare tali attacchi
Divulgazione: Rilascio dei contenuti dei messaggi a un'entità non autorizzata
- Un modello di sicurezza può opzionalmente fornire servizi di riservatezza attraverso la crittografia

A.1.2. Security Processing (Elaborazione della sicurezza)

Un modello di sicurezza deve implementare le seguenti primitive di servizio astratte:

generateRequestMsg: Applicare l'elaborazione di sicurezza ai messaggi di richiesta e notifica in uscita
- Input: scopedPDU, parametri di sicurezza
- Output: messaggio protetto pronto per la trasmissione
- Elaborazione:
  - Applicare autenticazione (se richiesto dal livello di sicurezza)
  - Applicare crittografia (se richiesto dal livello di sicurezza)
  - Aggiungere parametri di sicurezza al messaggio
  - Assicurarsi che il messaggio sia protetto secondo securityLevel
processIncomingMsg: Elaborare la sicurezza dei messaggi in entrata
- Input: messaggio ricevuto
- Output: scopedPDU estratta, parametri di sicurezza
- Elaborazione:
  - Verificare autenticazione (se il messaggio afferma di essere autenticato)
  - Decifrare il messaggio (se il messaggio è crittografato)
  - Controllare tempestività (per prevenire attacchi di replay)
  - Estrarre scopedPDU
  - Memorizzare nella cache lo stato di sicurezza se potrebbe essere necessaria una risposta
generateResponseMsg: Applicare l'elaborazione di sicurezza ai messaggi di risposta in uscita
- Input: scopedPDU, stato di sicurezza memorizzato nella cache
- Output: messaggio di risposta protetto
- Elaborazione:
  - Recuperare parametri di sicurezza dallo stato memorizzato nella cache
  - Applicare stesso livello di sicurezza della richiesta
  - Applicare autenticazione (se richiesto)
  - Applicare crittografia (se richiesto)

A.1.3. Validate the security-stamp in a received message (Validare il timbro di sicurezza in un messaggio ricevuto)

Un modello di sicurezza deve validare che:

L'autenticazione è valida: Se il messaggio afferma di essere autenticato, verificare il codice di autenticazione
- Utilizzare appropriata verifica crittografica (ad es., verifica HMAC)
- Rifiutare messaggi con autenticazione non valida
Il messaggio è tempestivo: Verificare che il messaggio non sia una riproduzione
- Controllare parametri di temporizzazione del messaggio
- Mantenere stato per rilevare riproduzioni
- Rifiutare messaggi fuori dalla finestra temporale
La privacy è applicata correttamente: Se il messaggio è crittografato, verificare che possa essere decifrato
- Tentare decifratura utilizzando chiavi appropriate
- Verificare che la decifratura sia riuscita
- Rifiutare messaggi che non possono essere decifrati
Il livello di sicurezza corrisponde ai requisiti: Verificare che la sicurezza effettivamente applicata corrisponda a quanto richiesto
- Verificare che i messaggi authNoPriv siano autenticati ma non crittografati
- Verificare che i messaggi authPriv siano sia autenticati che crittografati
- Verificare che i messaggi noAuthNoPriv non siano né autenticati né crittografati

A.1.4. Security MIBs (MIB di sicurezza)

Un modello di sicurezza dovrebbe definire un modulo MIB che consenta:

Configurazione dei parametri di sicurezza: Utenti, chiavi, protocolli di autenticazione, protocolli di privacy
Monitoraggio della sicurezza: Contatori per fallimenti di autenticazione, errori di decrittografia, ecc.
Configurazione remota: Meccanismi sicuri per configurare la sicurezza remotamente

Il modello di sicurezza basato sull'utente (USM) definisce lo SNMP-USER-BASED-SM-MIB per questo scopo.

A.1.5. Cached Security Data (Dati di sicurezza memorizzati nella cache)

Quando si elabora una richiesta in entrata che potrebbe richiedere una risposta, un modello di sicurezza deve memorizzare nella cache informazioni sullo stato di sicurezza. Questi dati memorizzati nella cache consentono alla risposta di essere protetta utilizzando gli stessi parametri di sicurezza della richiesta.

I dati di sicurezza memorizzati nella cache tipicamente includono:

Parametri di sicurezza dalla richiesta
Chiavi utilizzate per l'autenticazione e/o la crittografia
Parametri di temporizzazione
Qualsiasi altro stato necessario per generare una risposta

Il modello di sicurezza deve:

Generare un securityStateReference: Un identificatore unico per lo stato memorizzato nella cache
Restituire il securityStateReference: Al modello di elaborazione dei messaggi
Recuperare lo stato memorizzato nella cache: Quando viene chiamato generateResponseMsg
Rilasciare lo stato memorizzato nella cache: Dopo la generazione della risposta o quando esplicitamente rilasciato

Lo stato memorizzato nella cache può essere implicitamente rilasciato quando:

Una risposta è stata generata con successo
Si verifica un errore e non verrà inviata alcuna risposta
Si verifica un timeout

Lo stato memorizzato nella cache può essere esplicitamente rilasciato utilizzando la primitiva stateRelease.

A.2. Message Processing Model Design Requirements (Requisiti di progettazione del modello di elaborazione dei messaggi)

Un modello di elaborazione dei messaggi definisce un formato di messaggio e le procedure per elaborare i messaggi in quel formato. Questa sezione descrive i requisiti per i modelli di elaborazione dei messaggi.

A.2.1. Receiving an SNMP Message from the Network (Ricezione di un messaggio SNMP dalla rete)

Quando un messaggio viene ricevuto dalla rete, il dispatcher determina quale modello di elaborazione dei messaggi dovrebbe elaborarlo (in base alla versione o al formato del messaggio). Il modello di elaborazione dei messaggi deve implementare la primitiva prepareDataElements.

Elaborazione prepareDataElements:

Analizzare il formato del messaggio: Estrarre i vari componenti dal messaggio
- Intestazione del messaggio
- Parametri di sicurezza
- Scoped PDU o payload
Determinare il modello di sicurezza: Identificare quale modello di sicurezza è stato utilizzato
- Solitamente indicato nell'intestazione del messaggio
Chiamare il modello di sicurezza: Invocare processIncomingMsg per:
- Verificare autenticazione
- Decifrare il messaggio
- Controllare tempestività
- Estrarre la scoped PDU
Analizzare la scoped PDU: Estrarre:
- contextEngineID
- contextName
- PDU
Memorizzare nella cache lo stato se necessario: Se questa è una richiesta che potrebbe richiedere una risposta:
- Memorizzare nella cache le informazioni necessarie per generare la risposta
- Generare una stateReference
- Associare la stateReference ai dati memorizzati nella cache
Restituire gli elementi dati estratti: Restituire tutte le informazioni necessarie al dispatcher:
- messageProcessingModel
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
- pduVersion
- PDU
- pduType
- maxSizeResponseScopedPDU
- stateReference
- statusInformation

Gestione degli errori:

Se un passaggio fallisce, restituire appropriate statusInformation di errore al dispatcher. Non passare messaggi malformati o non autenticati alle applicazioni.

A.2.2. Sending an SNMP Message to the Network (Invio di un messaggio SNMP alla rete)

Quando si invia un messaggio, il dispatcher chiama prepareOutgoingMessage (per richieste e notifiche) o prepareResponseMessage (per risposte). Il modello di elaborazione dei messaggi deve implementare queste primitive.

Elaborazione prepareOutgoingMessage:

Creare una scoped PDU: Combinare contextEngineID, contextName e PDU
Chiamare il modello di sicurezza: Invocare generateRequestMsg per:
- Applicare autenticazione (se richiesto)
- Applicare crittografia (se richiesto)
- Aggiungere parametri di sicurezza
Creare il messaggio: Avvolgere il payload protetto nel formato di messaggio appropriato
- Aggiungere intestazione del messaggio
- Aggiungere identificatore di versione o formato
- Aggiungere campi specifici del messaggio
Restituire il messaggio completo: Restituire il messaggio formattato pronto per la trasmissione:
- outgoingMessage
- outgoingMessageLength
- statusInformation

Elaborazione prepareResponseMessage:

Simile a prepareOutgoingMessage, ma:

Recuperare lo stato memorizzato nella cache: Utilizzare la stateReference per recuperare le informazioni memorizzate nella cache
Creare una scoped PDU: Combinare contextEngineID, contextName e PDU (dalla richiesta originale)
Chiamare il modello di sicurezza: Invocare generateResponseMsg con:
- La scoped PDU
- La securityStateReference (per utilizzare gli stessi parametri di sicurezza della richiesta)
Creare il messaggio di risposta: Avvolgere il payload protetto nel formato appropriato
Rilasciare lo stato memorizzato nella cache: Dopo aver creato con successo la risposta, rilasciare lo stato memorizzato nella cache
Restituire la risposta completa: Restituire il messaggio di risposta formattato

Gestione degli errori:

Se un passaggio fallisce, restituire appropriate statusInformation di errore. Se una risposta non può essere generata, assicurarsi che lo stato memorizzato nella cache sia rilasciato.

A.3. Application Design Requirements (Requisiti di progettazione dell'applicazione)

Le applicazioni SNMP utilizzano i servizi del motore SNMP per eseguire funzioni di gestione. Questa sezione descrive requisiti e linee guida per la progettazione delle applicazioni.

A.3.1. Applications that Initiate Messages (Applicazioni che avviano messaggi)

Le applicazioni che avviano messaggi (Command Generator, Notification Originator) devono:

Determinare la destinazione: Identificare il motore SNMP di destinazione
- transportDomain
- transportAddress
- contextEngineID
Determinare i parametri di sicurezza:
- securityModel
- securityName
- securityLevel
Creare il PDU: Costruire l'unità dati di protocollo con l'operazione e le variabili desiderate
Chiamare sendPdu: Invocare la primitiva sendPdu del dispatcher con:
- Informazioni di destinazione
- Parametri di sicurezza
- contextEngineID e contextName
- PDU
- Flag expectResponse
- sendPduHandle (per correlare la risposta successiva)
Gestire la risposta: Se expectResponse era TRUE, implementare processResponsePdu per ricevere la risposta

Linee guida:

Configurare le destinazioni: Utilizzare meccanismi di configurazione (ad es., SNMP-TARGET-MIB) per gestire le informazioni di destinazione
Configurare la sicurezza: Utilizzare meccanismi di configurazione (ad es., SNMP-USER-BASED-SM-MIB) per gestire i parametri di sicurezza
Gestire gli errori: Gestire correttamente gli errori statusInformation da sendPdu
Implementare timeout: Se non viene ricevuta risposta entro un tempo ragionevole, gestire il timeout
Implementare tentativi: Considerare la ritrasmissione se non viene ricevuta risposta

A.3.2. Applications that Receive Responses (Applicazioni che ricevono risposte)

Le applicazioni che ricevono risposte devono implementare la primitiva processResponsePdu.

Implementazione processResponsePdu:

Correlare la risposta: Utilizzare il sendPduHandle per abbinare la risposta alla richiesta originale
Controllare statusInformation: Verificare che l'elaborazione del messaggio sia riuscita
Elaborare il PDU: Estrarre ed elaborare i dati di risposta
- Controllare error-status e error-index
- Estrarre variable binding
- Eseguire elaborazione specifica dell'applicazione

Linee guida:

Gestire gli errori: Controllare errori SNMP (ad es., noSuchName, tooBig, genErr)
Gestire le eccezioni: Controllare valori di eccezione (noSuchObject, noSuchInstance, endOfMibView)
Gestire errori di sicurezza: Essere preparati per fallimenti di autenticazione o privacy
Pulire lo stato: Rilasciare eventuali risorse associate alla richiesta

A.3.3. Applications that Receive Asynchronous Messages (Applicazioni che ricevono messaggi asincroni)

Le applicazioni che ricevono messaggi asincroni (Command Responder, Notification Receiver) devono:

Registrarsi con il dispatcher: Chiamare registerContextEngineID per registrarsi per:
- Valori contextEngineID specifici
- Tipi di PDU specifici
Implementare processPdu: Ricevere ed elaborare PDU in entrata
- Validare contextEngineID e contextName
- Elaborare la PDU secondo la semantica dell'applicazione
- Generare risposta (se richiesto)

Implementazione processPdu:

Validare il contesto: Assicurarsi che questa applicazione sia responsabile per il contextEngineID e contextName
Controllare il controllo degli accessi (se appropriato): Chiamare isAccessAllowed per ogni variabile nella PDU
Elaborare la richiesta: Eseguire l'operazione richiesta
- Per GET: recuperare valori delle variabili
- Per SET: modificare valori delle variabili
- Per GETNEXT: trovare la variabile lessicograficamente successiva
- Per GETBULK: recuperare più variabili in modo efficiente
Costruire PDU di risposta (se richiesto): Creare una PDU di risposta con i risultati
Chiamare returnResponsePdu (se richiesto): Inviare la risposta al richiedente

Linee guida:

Validare l'input: Validare attentamente tutti gli input per prevenire vulnerabilità di sicurezza
Implementare il controllo degli accessi: Applicare appropriato controllo degli accessi a tutte le operazioni
Gestire gli errori con eleganza: Restituire appropriate risposte di errore per richieste non valide
Rispettare maxSizeResponseScopedPDU: Assicurarsi che la risposta non superi il limite di dimensione
Utilizzare stateReference: Passare la stateReference da processPdu a returnResponsePdu senza modifiche

A.3.4. Applications that Send Responses (Applicazioni che inviano risposte)

Le applicazioni che inviano risposte devono utilizzare la primitiva returnResponsePdu.

Utilizzo di returnResponsePdu:

Utilizzare i parametri da processPdu: Passare:
- messageProcessingModel
- securityModel
- securityName
- securityLevel
- contextEngineID
- contextName
- pduVersion
- maxSizeResponseScopedPDU
- stateReference
Creare PDU di risposta: Costruire la PDU contenente i risultati
Chiamare returnResponsePdu: Invocare la primitiva returnResponsePdu del dispatcher

Linee guida:

Non modificare i parametri di sicurezza: Utilizzare gli stessi parametri di sicurezza della richiesta
Rispettare i limiti di dimensione: Assicurarsi che la risposta rientri in maxSizeResponseScopedPDU
Gestire gli errori: Se la risposta non può essere inviata, gestire l'errore appropriatamente
Rilasciare lo stato: La stateReference verrà rilasciata dal dispatcher dopo l'invio della risposta

A.4. Access Control Model Design Requirements (Requisiti di progettazione del modello di controllo degli accessi)

Un modello di controllo degli accessi determina se l'accesso a un oggetto gestito dovrebbe essere consentito. Questa sezione descrive i requisiti per i modelli di controllo degli accessi.

Un modello di controllo degli accessi deve implementare la primitiva isAccessAllowed.

Implementazione isAccessAllowed:

Determinare il principal: Identificare chi sta tentando l'accesso
- Utilizzare securityModel e securityName
Determinare il tipo di accesso: Identificare quale tipo di accesso viene richiesto
- read: GET, GETNEXT, GETBULK
- write: SET
- notify: TRAP, INFORM
Determinare il target: Identificare quale oggetto viene accessibile
- variableName (OID)
- contextName
Applicare la politica di controllo degli accessi: In base alla politica configurata, determinare se l'accesso dovrebbe essere consentito
Restituire il risultato: Restituire consentito o negato

Linee guida:

Definire una MIB: Definire un modulo MIB per configurare la politica di controllo degli accessi
Supportare la configurazione remota: Consentire la configurazione della politica tramite SNMP
Negazione predefinita: Se nessuna politica esplicita consente l'accesso, negare per impostazione predefinita
Implementazione efficiente: Il controllo degli accessi può essere chiamato molte volte per richiesta; implementare in modo efficiente
Politica coerente: Garantire che la politica sia applicata in modo coerente

Il modello di controllo degli accessi basato su viste (VACM) definito in RFC 3415 è un'implementazione di esempio.