https://mobile.codeguru.com/csharp/.net/net_security/making-a-guid-creator-in-.net.html

Zufällig bin ich hier rüber gestolpert. Weitergelesen habe ich eigentlich nur, weil mir in der Einleitung mitgeteilt wurde, dass man Dinge auch vergessen kann mit dem Alter, wie ich eine neue GUID erzeuge weiss ich schon noch;) Ich hatte halt die Hoffnung in die Interna der Erzeugung eingeweiht zu werden. 

Dies war leider Fehlanzeige, also werde ich dies demnächst Mal aus dem source extrahieren. Wichtig ist hierbei, dass diese Art der ID ihrem Namen alle Ehre macht.

So ähnlich wie wenn beim Herrn Schwartz dran steht: Wir backen mehrmals täglich frisch für sie.

Ursprünglich war diese einmal von MS als wirklich global einzigartig postuliert beschrieben, MS hat das später mit v4 etwas eingeschränkt in Bezug zu ihrer Zufälligkeit. 

https://www.sohamkamani.com/blog/2016/10/05/uuid1-vs-uuid4/

So momentan genieße ich die 'kalte' Sonne und kann nicht in den nightly source schauen :)

und nun mho wird dieser code nur auf winOS tun: https://referencesource.microsoft.com/#mscorlib/system/guid.cs,b7fae6994c22c22e, weil die GUID oder UUID ja schon immer in der WinRegistry benutzt wurde, dorten im OS also eine Methode (CoCreateGuid) zum erzeugen derselben vorhanden ist.

Und ja so ist es: https://github.com/dotnet/coreclr/blob/32f0f9721afb584b4a14d69135bea7ddc129f755/src/pal/src/misc/miscpalapi.cpp#L355 im core code wird hier entweder die bsd version 1 benutzt oder unter MacOs && Linux die version 4 zum Erzeugen von UUID's.

Und dieser kleine Unterschied ist es auch, der alle, welche noch nicht das .net fw v5 aka .net Core im Blickfeld haben, dies Mal etwas mehr in den Fokus zu nehmen.

einmal aus dem bsd v1 fundus: https://www.freebsd.org/cgi/man.cgi?query=uuid_create
und dem v4: https://linux.die.net/man/3/uuid_generate_random

"An automated process, designed to trigger when custom keys are removed from KeyVault, inadvertently caused these TDE databases to be dropped.

We are in the process of restoring a copy of these SQL DBs from a recovery point in time of less than 5 minutes before the database was dropped. These restored databases … are located on the same server as the original database."

https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-azure-sql

Dieser Text ist Grundlage meiner Überlegungen zum Thema.

Das Wiederherstellen der Daten aus dem Backup erfolgt also auf demselben Server, mit der selben master DB, in welcher das Zertifikat zum entschlüsseln mit Hilfe des verschlüsselten Entschlüsselungs-Schlüssel aus dem DB / Log / Backup -File erfolgen sollte. Dazu wird der private Schlüssel aus dem KeyValt benötigt.

Dies obige war also die Nachricht vorgestern Nacht zu gestern. Und der Vorgang als solcher ist richtig, da ohne Schlüssel die Db'en (oder Bit Speicherbelegungen) vollkommen wertlos sind?

Dazu gibt es nun solche Betroffenen die sagen: ja neue DB existiert aber eben fünf Minuten alt und mit id-suffix im Namen, so dass eigentliche App nicht wirklich tut.

Andere berichten von dieser neuen DB, welche wiederholt leer sei.

Dies bringt mich zu der grundlegenden Frage: das scheinbar innerhalb von 5 Minuten gezogene DB Backup wird wie verschlüsselt, wenn die DB selber transparent verschlüsselt wird, so wie im White-Paper ausgeführt?

Der eigentliche vorangegangene Vorfall hier ist nach Informationslage, dass die Schlüssel wegen DNS Problemen, in den Tagen davor, gelöscht werden mussten. Ergo müssten alle wiederhergestellten db'en leer sein, da auch das Backup von diesem jeweiligen Schlüssel  abhängig sein sollte, immer unter der Annahme, dass der private Schlüssel zum Zertifikat der master DB nicht irgendwie anders noch existiert. Eventuell waren die Schlüssel aber nur wegen den vorrangegangenen DNS Problemen nur nicht erreichbar, die DB'en sind vom Automat zwar gelöscht wurden nach 24h Fehlen des Schlüssels, jetzt sich die Schlüssel allerdings wieder erreichbar und damit ein Restore aus der Zeit vor den 24h wäre erfolgreich.

Entweder liegt hier in der Informationskette noch etwas im Dunkel, oder aber das Backup ist wohlweislich nicht verschlüsselt, was eigentlich nicht sein kann, allerdings könnte es auch nicht auf Konsistenz geprüft sein.

(Hieraus ergibt sich das rechtlich relevante Problem: mit eingeschaltetem TDE soll der Missbrauch der Daten durch Dritte rechtskonform verhindert werden, was das Backup mho an erste Stelle stellt.) Meine Beobachtung zeigt, mehr als 90% der DB oder VM admins tun dies so, ohne Konsistenzprüfung. Die Hardware ist heute auf einem Stabilitätslevel, sodass jüngere Menschen das FAIL nicht erlebt haben, den kostenintensiven Schritt darum wie selbstverständlich nicht sehen.

Insgesamt ist dies wieder Nahrung für die cloud basher, aber auch ich bin frustriert, weil ich annahm, dass hier mit wesentlich mehr Tests der worst case abgesichert sei.

Und ja der erste zitierte Text ist bestimmt kein Schnellschuss, sondern von Volljuristen abgesegnet, genauso wie der folgende.

"We sincerely apologize for the impact on your service. Azure usage fees are waived for all restored databases for 2 months and for all original databases for 3 months. We are continuously taking steps to improve the Microsoft Azure platform and our processes to ensure that such incidents do not occur again in the future."

Wichtiger ist naturgemäß der zweite Teil! Ok bin kein BWL'er;)

PS. MS hat nun bekanntgegeben, dass ein nicht namentlich genannter DNS Provider (Comcast war die ganze Zeit dunkel) ursächlich ist, bzw. ein routinemaessiges Update dorten.