Speichern von CREATE EXTERNAL DATA SOURCE in einem SSDT-Projekt, ohne das Geheimnis von DATABASE SCOPED CREDENTIAL oder MASTER KEY preiszugeben;

Ich habe ein SSDT-Projekt, das in Azure SQL DB bereitgestellt wird. Kürzlich habe ich eine externe Tabelle hinzugefügt. Dies erforderte eine externe Datenquelle wie folgt:

CREATE EXTERNAL DATA SOURCE [data_warehouse]
    WITH (
    TYPE = RDBMS,
    LOCATION = N'mydb.database.windows.net',
    DATABASE_NAME = N'MainDW',
    CREDENTIAL = [dw_reader]
    );

Wenn ich dies in meine .sqlproj importiere, wird beschwert, dass der Berechtigungsnachweis nicht vorhanden ist, und wenn ich hinzufüge, dass der Hauptschlüssel nicht vorhanden ist. Das Problem ist, dass ich diese Geheimnisse nicht im SSDT-Projekt speichern möchte. Wie speichere ich Dummys oder Standardeinstellungen, die überschrieben und aus dem Azure-Keyvault oder einer anderen Methode zum Speichern von Geheimnissen in Azure Decops abgerufen werden können?

azure-sql-database ssdt

— Justin Dearing
quelle

Wie stellen Sie Datenbankänderungen bereit? Sie können auf eine SQL-Cmd-Variable verweisen und diese aus Ihrer Bereitstellungspipeline an die Veröffentlichung übergeben. Dies muss jedoch noch verwaltet werden, um sicherzustellen, dass das Veröffentlichungsskript in keiner Form ohne redigierte Geheimnisse gespeichert wird.

— Martin Smith

Nach dem Experimentieren scheint es, dass jede Art von Geheimnis in SSDT nur verwendet wird, wenn das Objekt erstellt und nicht aktualisiert wird.

Wenn ein SQL-Projekt enthält CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password A';und kein Hauptschlüssel vorhanden ist, wird der Hauptschlüssel mit diesem Kennwort erstellt. Wenn Sie jedoch später ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = 'dsjdkflJ435907NnmM#sX003';die Datenbank ausführen und dann das SQL-Projekt erneut in der Datenbank bereitstellen, wird der Hauptschlüssel nicht neu generiert.

— Justin Dearing
quelle