„Dafür ist Live-TV ab der heimischen Satellitenschüssel rund doppelt so sparsam wie Streamen über Mobilfunk oder einen DSL-Anschluss…“ Damit sollte es später statt „Also: Streamen über Glasfaser auf das Handy oder Tablet ist vorbildlich.“ zusätzlich heissen: „…vorbildlich, wenn es nicht via Satellit geht.“ Ich verwende tatsächlich Satelliten-TV und -Radio. Ich frage mich, ob der extrem niedrige Wert für die Übertragung von 0,2 Wh/h (also 0,2 W pro Gerät) die Energie berücksichtigt, die für die Platzierung der Satelliten aufgewendet wurde. Bei mir kommt jedoch für Empfänger und TV wesentlich mehr als die angegebenen 10 W zusammen, nämlich ca. 100 W mit kleinem und einigen Hundert W mit grossem TV. (Leider hilft die sonst sehr gute Quelle (Fraunhofer Fokus) hier nicht weiter da die Watt-Skalen bei mir fehlen.)

Herzlichen Dank, liebe Christine!

Ein beliebter Mechanismus ist die Nutzung von „Customer-Managed (Encryption) Keys“, abgekürzt CMK (Microsoft) oder CMEK (Google). Da werden die Schlüssel im Auftrag des Kunden oder durch den Kunden erzeugt (und können auch vom Nutzer jederzeit geändert werden), also „selbst generiert und verwaltet“. Sie liegen aber trotzdem in der Infrastruktur des Cloudproviders (durch Software oder Hardware geschützt) und der Cloudprovider kann sie bzw. daraus abgeleitete Schlüssel jederzeit auslesen, was auch zum korrekten Funktionieren nötig ist.

Zusätzlich gibt es noch die Funktion „Bring Your Own Key“ (BYOK), bei der der Kunde den Schlüssel selbst erzeugt und in Hardware des Cloudproviders importiert. Bei anderen Providern kann man auch sein eigenes Hardware Security Module (HSM) zur Schlüsselverwaltung einbinden. Aber auch in diesen Fällen kann der Cloudprovider jederzeit auf die Schlüssel zugreifen, die zur Ver- und Entschlüsselung der eigentlichen Daten notwendig sind.

Welche dieser Methoden gewählt wurde, verrät das BABS nicht. Aber ja, das könnte man vielleicht etwas klarer beschreiben. Aber dafür ist auch schon seit längerem ein eigener DNIP-Artikel geplant, der aber noch geschrieben werden muss. In der Zwischenzeit findet man z.B. hier mehr Informationen.

In solchen Projekten ist der Speicher, bzw. „wo die Daten abgelegt sind“ nur eine Facette des ganzen Unterfangens.
Es geht vorallem auch darum, wo die ausgewählte Applikation läuft. Azure, AWS und co. sind sehr stark auf diesen Aspekt optimiert. Es ist dort vergleichsweise einfach eine Applikation mit hoher Redundanz und mit viel Leistung zu betreiben. (Eine Applikation ist heutzutage meistens eine „Website“ oder der Server einer App.)

D. h. die Daten würden somit auch in Azure verarbeitet, nicht, wie das mit pCloud der Fall zu sein scheint (ich kenn’s nicht), auf dem eigenen Notebook und danach in die Cloud gesynct.

Die Medienstelle sagt:
“ Zudem verfügt das System über ein eigenes Key-Management. Die kryptographischen Schlüssel werden vom BABS selbst generiert und verwaltet.”

Später schreiben Sie aber:
“ Wir erfahren nicht, ob die Schlüssel beim BABS liegen oder allein von Microsoft verwaltet werden.”

pCloud gibt sich sehr bedeckt, was seine Eigentümer und Sicherheitsmassnahmen betrifft. Es ist ganz viel „Trust me!“ dabei. Für eine IT-Sicherheitslösung, der ich vertrauen soll, muss dieses Vertrauen auch geschaffen werden. Typische Mechanismen sind Transparenz und Verantwortungsübernahme. Beides war mangelhaft, als ich pCloud 2023 unter die Lupe nahm.

Falls sich da was geändert hat, wäre ich um Informationen froh.

Woher die Hardware kommt, ist relativ egal. Je nach Software auch. Also, wenn die Software gekauft ist und nicht nur mit einer restriktiven Mietlizenz (und regelmässigem „Call-Home“) kommt, sollte sie auch gut weiterbetreibbar sein, wenn es den Hersteller nicht mehr gibt oder er nicht mehr willig ist.