Règle d'autorisation au niveau de la VM

Les autorisations au niveau de la VM définissent les règles d'autorisation pour la communication entre différentes VM du réseau maillé du véhicule défini par logiciel (SDV). Ils offrent une sécurité en profondeur en cas de compromission d'une VM.

Vous devez accorder des autorisations au niveau du service et de la VM pour autoriser la communication entre les VM.

Schéma proto

Les autorisations au niveau de la VM sont définies à l'aide d'un seul message VmAuthzPolicy au format 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;
}

Décision d'autorisation

L'évaluation suit un ordre de priorité strict, où "Refuser" remplace "Autoriser" à la même granularité. Par défaut, toutes les communications entre les VM sont refusées.

Ordre d'évaluation de la priorité

La logique de décision vérifie les autorisations dans l'ordre suivant :

  1. Refus précis : si une instance spécifique (Message+Topic ou Service+Channel) correspond à une règle deny_, elle est refusée explicitement.
  2. Autorisation précise : si une instance spécifique correspond à une règle allow_, elle est autorisée.
  3. Type "Refuser" : si un type de message ou une interface de service entiers correspondent à une règle deny_ (topic: "*" ou channel: "*"), ils sont refusés de manière explicite.
  4. Type "Autoriser" : si un type de message ou une interface de service entiers correspondent à une règle allow_ (topic: "*" ou channel: "*"), ils sont autorisés.
  5. Refus général : si tous les types de messages ou services sont refusés (message: "*" ou service: "*"), ils sont explicitement refusés.
  6. Autorisation générale : si tous les types de messages ou services sont autorisés (message: "*" ou service: "*"), l'état est Autorisé.
  7. Refus implicite par défaut : si aucune règle ne correspond, la requête est refusée de manière implicite. Par défaut, le système refuse tout.

Exemples

Les exemples suivants montrent comment la règle d'autorisation est évaluée.

Les autorisations précises remplacent les refus

# 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"
}

Le type "Refuser" remplace l'autorisation globale

# 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: "*"
}