"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.

Was trying to bring .net core on freeBSD on the fly - it is to early for this. 

On an actual VM 11.2 from MS the load of zip containers from open repository during the build fails, because unknown zip format ?? Need more investigation. Yes you must compile the hal by your self ;)

But another check on a raspi3 was again showing the immense performance to light, amazing!!

Now i was found this instruction https://github.com/dotnet/corefx/wiki/Building-.NET-Core-3.x-on-FreeBSD for the next core, will give them a try.

Nice to read: Depending of the day and moon phase ..

42.