Autorisierungsrichtlinie auf VM-Ebene

Berechtigungen auf VM-Ebene definieren Autorisierungsrichtlinien für die Kommunikation zwischen verschiedenen VMs im Software-Defined Vehicle (SDV)-Mesh-Netzwerk. Sie bieten eine mehrschichtige Sicherheit, falls eine VM kompromittiert wird.

Sie müssen sowohl Berechtigungen auf Dienstebene als auch auf VM-Ebene gewähren, um die VM-übergreifende Kommunikation zu ermöglichen.

Proto-Schema

Berechtigungen auf VM-Ebene werden mit einer einzelnen VmAuthzPolicy-Nachricht im Textproto-Format definiert.

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;
}

Autorisierungsentscheidung

Die Auswertung folgt einer strengen Rangfolge, wobei „Verweigern“ „Zulassen“ auf derselben Granularitätsebene überschreibt. Standardmäßig wird die gesamte VM-übergreifende Kommunikation verweigert.

Reihenfolge der Rangfolgenauswertung

Die Entscheidungslogik prüft Berechtigungen in der folgenden Reihenfolge:

  1. Detaillierte Verweigerung: Wenn eine bestimmte Instanz (Nachricht + Thema oder Dienst + Kanal) mit einer deny_ Regel übereinstimmt, wird sie explizit verweigert.
  2. Detaillierte Zulassung: Wenn eine bestimmte Instanz mit einer allow_-Regel übereinstimmt, ist sie zulässig.
  3. Verweigerung des Typs: Wenn ein ganzer Nachrichtentyp oder eine ganze Dienstschnittstelle mit einer deny_ Regel (topic: "*" oder channel: "*") übereinstimmt, wird sie explizit verweigert.
  4. Zulassung des Typs: Wenn ein ganzer Nachrichtentyp oder eine ganze Dienstschnittstelle mit einer allow_ Regel übereinstimmt (topic: "*" oder channel: "*"), ist sie zulässig.
  5. Pauschale Verweigerung: Wenn alle Nachrichtentypen oder Dienste verweigert werden (message: "*" oder service: "*"), wird explizit verweigert.
  6. Pauschale Zulassung: Wenn alle Nachrichtentypen oder Dienste zugelassen werden (message: "*" oder service: "*"), ist zulässig.
  7. Implizite Standardeinstellung: Wenn keine Regel übereinstimmt, wird implizit verweigert. Die Standardeinstellung des Systems ist, alles zu verweigern.

Beispiele

Die folgenden Beispiele veranschaulichen, wie die Autorisierungsrichtlinie ausgewertet wird.

Detaillierte Zulassung überschreibt Verweigerung des Typs

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

Verweigerung des Typs überschreibt pauschale Zulassung

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