2012-11-06 9 views
5

Sto lavorando alla crittografia delle stored procedure nel progetto aziendale. Abbiamo un sacco di SP che dovrebbero essere protetti sulla produzione.
Nessun problema per impostare il parametro WITH ENCRYPTION in ogni SP che si trova in sqlproj. Ma voglio rendere questa direttiva opzionale: se sto costruendo un progetto in modalità debug - non applicare questa opzione, altrimenti - usalo. In realtà l'obiettivo principale qui è quello di ottenere database per gli sviluppatori senza crittografia, ma in produzione - SP crittografati.
Utilizzo dello script PowerShell nell'attività di compilazione È possibile modificare il file sql generato e come risultato ottenere lo script con il parametro di crittografia, ma mi chiedo come funzionerebbe con dacpac.
Qualche suggerimento?Procedura memorizzata Opzione di COLLEGAMENTO in base alla modalità di build

Aggiornamento:

Dopo qualche tempo trascorso a giocare con msbuild. Ho deciso di smettere (almeno per ora) sulla soluzione compito PowerShell script dopo SqlCore obiettivo:

<Import Project="$(ExtensionTasksPath)MSBuild.ExtensionPack.tasks" Condition="Exists('$(ExtensionTasksPath)MSBuild.ExtensionPack.dll')" /> 
    <UsingTask TaskFactory="PowershellTaskFactory" TaskName="CreateDecryptedScript" AssemblyFile="$(PowerShellTaskAssembly)" Condition="Exists('$(PowerShellTaskAssembly)')"> 
    <ParameterGroup> 
     <File Required="true" ParameterType="System.String" /> 
     <ResultFile Required="true" ParameterType="System.String" /> 
    </ParameterGroup> 
    <Task> 
     <![CDATA[  
     (Get-Content $file) | Foreach-Object {$_ -replace 'WITH ENCRYPTION', '--WITH ENCRYPTION'} | Set-Content $resultfile  
    ]]> 
    </Task> 
    </UsingTask> 
<Target Name="CreateDecryptedScript" AfterTargets="SqlCore"> 
    <CreateDecryptedScript File="$(OutputPath)$(CreateScriptFileName)" ResultFile="$(OutputPath)$(DecryptedScriptName)" Condition="Exists('$(PowerShellTaskAssembly)')" /> 
</Target> 

Di conseguenza, dopo la ricostruzione del progetto che abbiamo scritto per la creazione del database senza crittografia.

Ma il numero publish invocato dal progetto non impone l'esecuzione di tali elementi e modificheremo tutti gli SP con la crittografia.

+0

Uno script di distribuzione post per modificare gli SP può fare il trucco. –

+0

@ aclear16 Sì, ci stavo pensando ma non ho trovato alcuna soluzione ragionevole. –

+0

L'aggiunta di una variabile a livello di progetto al posto di "WITH ENCRYPTION" potrebbe essere un'opzione. Per i tuoi ambienti di sviluppo, aggiungi questo come una stringa vuota o una riga commentata. Per gli ambienti che devono essere crittografati, utilizzare "WITH ENCRYPTION" per il valore. Imposta quelli nei tuoi profili di pubblicazione. –

risposta

2

È facile decodificare le stored procedure "crittografate". Ti suggerisco di non preoccuparti di crittografarli.

Se li si deve crittografare, mi suggeriscono una fase di post-implementazione in DEV, che decifra ogni stored procedure crittografata, uno per uno. È possibile creare facilmente questo passaggio utilizzando sp_execsql e le informazioni ai collegamenti.

+0

Sì, è così che potrebbe funzionare, ma sto ancora cercando una soluzione flessibile che non richieda manipolazioni su SP sull'ambiente dev. –

+1

Penso che tu mi abbia frainteso. Voglio dire non criptarli affatto - è una perdita di tempo. – Ben

+0

Ohh .. Capisco. Ma questa non è una mia decisione. E sfortunatamente ho ancora bisogno di crittografare gli SP. Ma grazie per aver indicato. +1) –