Zasady autoryzacji na poziomie maszyny wirtualnej

Uprawnienia na poziomie maszyny wirtualnej określają zasady autoryzacji komunikacji między różnymi maszynami wirtualnymi w sieci typu mesh pojazdu zdefiniowanego programowo (SDV). Zapewniają one wielowarstwową ochronę na wypadek przejęcia kontroli nad jedną z maszyn wirtualnych.

Aby zezwolić na komunikację między maszynami wirtualnymi, musisz przyznać uprawnienia zarówno na poziomie usługi, jak i na poziomie maszyny wirtualnej.

Schemat proto

Uprawnienia na poziomie maszyny wirtualnej są definiowane za pomocą pojedynczego komunikatu VmAuthzPolicy w formacie 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;
}

Decyzja o autoryzacji

Ocena jest przeprowadzana w ścisłej kolejności, w której odmowa zastępuje zezwolenie na tym samym poziomie szczegółowości. Domyślnie cała komunikacja między maszynami wirtualnymi jest zabroniona.

Kolejność oceny

Logika decyzyjna sprawdza uprawnienia w tej kolejności:

  1. Szczegółowa odmowa: jeśli konkretna instancja (komunikat + temat lub usługa + kanał) pasuje do reguły deny_, jest wyraźnie odrzucana.
  2. Szczegółowe zezwolenie: jeśli konkretna instancja pasuje do reguły allow_, jest dozwolona.
  3. Odmowa typu: jeśli cały typ komunikatu lub interfejs usługi pasuje do reguły deny_ (topic: "*" lub channel: "*"), jest wyraźnie odrzucany.
  4. Zezwolenie typu: jeśli cały typ komunikatu lub interfejs usługi pasuje do reguły allow_ (topic: "*" lub channel: "*"), jest dozwolony.
  5. Odmowa ogólna: jeśli wszystkie typy komunikatów lub usługi są odrzucane (message: "*" lub service: "*"), jest wyraźnie odrzucana.
  6. Zezwolenie ogólne: jeśli wszystkie typy komunikatów lub usługi są dozwolone (message: "*" lub service: "*"), jest dozwolona.
  7. Domyślne zezwolenie: jeśli żadna reguła nie pasuje, jest domyślnie odrzucana. Domyślnie system odrzuca wszystko.

Przykłady

Poniższe przykłady pokazują, jak oceniana jest zasada autoryzacji.

Szczegółowe zezwolenie zastępuje odmowę typu

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

Odmowa typu zastępuje zezwolenie ogólne

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