Política de autorización a nivel de la VM

Los permisos a nivel de la VM definen las políticas de autorización para la comunicación entre diferentes VMs en la red en malla del vehículo definido por software (SDV). Proporcionan seguridad de defensa en profundidad en caso de que una VM se vea comprometida.

Debes otorgar permisos a nivel de servicio y de VM para permitir la comunicación entre VMs.

Esquema de Proto

Los permisos a nivel de la VM se definen con un solo mensaje VmAuthzPolicy en 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;
}

Decisión de autorización

La evaluación sigue un orden de prioridad estricto, en el que Deny anula Allow con la misma granularidad. De forma predeterminada, se rechaza toda la comunicación entre VMs.

Orden de evaluación de prioridad

La lógica de decisión verifica los permisos en el siguiente orden:

  1. Denegación detallada: Si una instancia específica (Message+Topic o Service+Channel) coincide con una regla deny_, se rechaza de forma explícita.
  2. Permiso detallado: Si una instancia específica coincide con una regla allow_, se permite.
  3. Denegación de tipo: Si un tipo de mensaje o una interfaz de servicio completa coincide con una regla deny_ (topic: "*" o channel: "*"), se rechaza de forma explícita.
  4. Permiso de tipo: Si un tipo de mensaje o una interfaz de servicio completa coincide con una regla allow_ (topic: "*" o channel: "*"), se permite.
  5. Denegación general: Si se rechazan todos los tipos de mensajes o servicios (message: "*" o service: "*"), se rechaza de forma explícita.
  6. Permiso general: Si se permiten todos los tipos de mensajes o servicios (message: "*" o service: "*"), se permite.
  7. Valor predeterminado implícito: Si no coincide con ninguna regla, se rechaza de forma implícita. El valor predeterminado del sistema es rechazar todo.

Ejemplos

En los siguientes ejemplos, se muestra cómo se evalúa la política de autorización.

El permiso detallado anula la denegación de tipo

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

La denegación de tipo anula el permiso general

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