Policy di autorizzazione a livello di VM

Le autorizzazioni a livello di VM definiscono le policy di autorizzazione per la comunicazione tra diverse VM nella rete mesh del veicolo definito dal software (SDV). Forniscono una sicurezza in profondità nel caso in cui una VM venga compromessa.

Devi concedere le autorizzazioni a livello di servizio e di VM per consentire la comunicazione tra le VM.

Schema proto

Le autorizzazioni a livello di VM vengono definite utilizzando un singolo messaggio VmAuthzPolicy in formato textproto.

message VmAuthzPolicy {
  repeated Publisher allow_publisher = 1;
  repeated Publisher deny_publisher = 2;
  repeated Subscriber allow_subscriber = 3;
  repeated Subscriber deny_subscriber = 4;
  repeated Server allow_server = 5;
  repeated Server deny_server = 6;
  repeated Client allow_client = 7;
  repeated Client deny_client = 8;
}

// Reuses the same Publisher message from AuthzPolicy, but uses "*" for
// wildcards.
message Publisher {
  string message = 1;
  repeated string topic = 2;
}

// Reuses the same Subscriber message from AuthzPolicy, but uses "*" for
// wildcards.
message Subscriber {
  string message = 1;
  repeated string topic = 2;
}

// Reuses the same Server message from AuthzPolicy, but uses "*" for
// wildcards.
message Server {
  string service = 1;
  repeated string channel = 2;
}

// Reuses the same Client message from AuthzPolicy, but uses "*" for
// wildcards.
message Client {
  string service = 1;
  repeated string channel = 2;
}

Decisione sull'autorizzazione

La valutazione segue un ordine di precedenza rigoroso, in cui Nega sostituisce Consenti alla stessa granularità. Per impostazione predefinita, tutta la comunicazione tra VM è negata.

Ordine di valutazione della precedenza

La logica decisionale controlla le autorizzazioni nel seguente ordine:

  1. Negazione granulare: se un'istanza specifica (Message+Topic o Service+Channel) corrisponde a una regola deny_, viene negata esplicitamente.
  2. Consenti granulare: se un'istanza specifica corrisponde a una regola allow_, è consentita.
  3. Tipo Nega: se un intero tipo di messaggio o interfaccia di servizio corrisponde a una regola deny_ (topic: "*" o channel: "*"), viene negato esplicitamente.
  4. Tipo Consenti: se un intero tipo di messaggio o un'interfaccia di servizio corrisponde a una regola allow_ (topic: "*" o channel: "*"), è consentito.
  5. Rifiuto generale: se tutti i tipi di messaggi o servizi vengono rifiutati (message: "*" o service: "*"), il rifiuto è esplicito.
  6. Consenti tutto: se tutti i tipi di messaggi o servizi sono consentiti (message: "*" o service: "*"), lo stato è Consentito.
  7. Predefinito implicito: se nessuna regola corrisponde, la richiesta viene rifiutata implicitamente. Il valore predefinito del sistema è di negare tutto.

Esempi

I seguenti esempi mostrano come viene valutata la policy di autorizzazione.

Nega tipo di override di autorizzazione granulare

# Deny door unlock publications by default...
deny_publisher {
  message: "com.sdv.security.UnlockDoors"
  topic: "*"
}

# ...but allow it for the driver door.
allow_publisher {
  message: "com.sdv.security.UnlockDoors"
  topic: "driver_door"
}

Il tipo nega ha la precedenza su Consenti generale

# Allow all client calls globally (blanket allow)...
allow_client {
  service: "*"
  channel: "*"
}

# ...except for the firmware update service (system-wide deny).
deny_client {
  service: "com.sdv.diagnostic.FirmwareUpdate"
  channel: "*"
}