Is there a way to change the default location, including drive, of a SQL
isntall that was initially installed to the C drive?Space Junk wrote:
> Is there a way to change the default location, including drive, of a
> SQL isntall that was initially installed to the C drive?
By "default location", do you mean where the executables are installed?
Or do you mean where the data and log files are installed?
--
David Gugick
Imceda Software
www.imceda.com|||I mean where data and logs are installed by default. Sorry I thought I said
that.
Example, adding a bigger HDD to a system and needing new data bases to
default to the new drive.
"David Gugick" wrote:
> Space Junk wrote:
> > Is there a way to change the default location, including drive, of a
> > SQL isntall that was initially installed to the C drive?
> By "default location", do you mean where the executables are installed?
> Or do you mean where the data and log files are installed?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||Space Junk wrote:
> I mean where data and logs are installed by default. Sorry I thought
> I said that.
> Example, adding a bigger HDD to a system and needing new data bases to
> default to the new drive.
Just add a new data file on the database to the new drive. SQL Server
will fill the data files (or log files) proportionally. If you want to
actually move the data and log files, you can use sp_detachdb and
sp_attach_db / sp_attach_single_file_db to disconnect them and reconnect
once they are on the new drive.
--
David Gugick
Imceda Software
www.imceda.com|||You can specify the database default folders for data and log files from
Enterprise Manager under server properties --> database settings.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> Is there a way to change the default location, including drive, of a SQL
> isntall that was initially installed to the C drive?|||I know how to move a data base, and data base settings only shows the C
drive. I do not need to change the folder data bases are being stored in. I
need to change the DEFAULT drive.
It is looking like a re-installation.
"Dan Guzman" wrote:
> You can specify the database default folders for data and log files from
> Enterprise Manager under server properties --> database settings.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> > Is there a way to change the default location, including drive, of a SQL
> > isntall that was initially installed to the C drive?
>
>|||I tried a different physical HDD and then that new drive showed up under DB
Settings under DB properties. I am not sure why the other functioning drive
did not show up.
"Space Junk" wrote:
> I know how to move a data base, and data base settings only shows the C
> drive. I do not need to change the folder data bases are being stored in. I
> need to change the DEFAULT drive.
> It is looking like a re-installation.
> "Dan Guzman" wrote:
> > You can specify the database default folders for data and log files from
> > Enterprise Manager under server properties --> database settings.
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> > "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> > news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> > > Is there a way to change the default location, including drive, of a SQL
> > > isntall that was initially installed to the C drive?
> >
> >
> >|||Space Junk wrote:
You can easily default new database data and log files under the
database settings tab in SQL EM. Just change the Default Data and
Default Log locations.
David Gugick
Imceda Software
www.imceda.com|||I was trying that, however me previous second HDD was not showing up in
there, only drive C. Not sure why, the drive was functioning normally. I
put a new drive in, and check again, then I had the option to choose other
than the C drive.
"David Gugick" wrote:
> Space Junk wrote:
> You can easily default new database data and log files under the
> database settings tab in SQL EM. Just change the Default Data and
> Default Log locations.
>
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>sql
Showing posts with label including. Show all posts
Showing posts with label including. Show all posts
Tuesday, March 27, 2012
Default Drive for new DBs
Is there a way to change the default location, including drive, of a SQL
isntall that was initially installed to the C drive?
Space Junk wrote:
> Is there a way to change the default location, including drive, of a
> SQL isntall that was initially installed to the C drive?
By "default location", do you mean where the executables are installed?
Or do you mean where the data and log files are installed?
David Gugick
Imceda Software
www.imceda.com
|||I mean where data and logs are installed by default. Sorry I thought I said
that.
Example, adding a bigger HDD to a system and needing new data bases to
default to the new drive.
"David Gugick" wrote:
> Space Junk wrote:
> By "default location", do you mean where the executables are installed?
> Or do you mean where the data and log files are installed?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
|||Space Junk wrote:
> I mean where data and logs are installed by default. Sorry I thought
> I said that.
> Example, adding a bigger HDD to a system and needing new data bases to
> default to the new drive.
Just add a new data file on the database to the new drive. SQL Server
will fill the data files (or log files) proportionally. If you want to
actually move the data and log files, you can use sp_detachdb and
sp_attach_db / sp_attach_single_file_db to disconnect them and reconnect
once they are on the new drive.
David Gugick
Imceda Software
www.imceda.com
|||You can specify the database default folders for data and log files from
Enterprise Manager under server properties --> database settings.
Hope this helps.
Dan Guzman
SQL Server MVP
"Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> Is there a way to change the default location, including drive, of a SQL
> isntall that was initially installed to the C drive?
|||I know how to move a data base, and data base settings only shows the C
drive. I do not need to change the folder data bases are being stored in. I
need to change the DEFAULT drive.
It is looking like a re-installation.
"Dan Guzman" wrote:
> You can specify the database default folders for data and log files from
> Enterprise Manager under server properties --> database settings.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
>
>
|||I tried a different physical HDD and then that new drive showed up under DB
Settings under DB properties. I am not sure why the other functioning drive
did not show up.
"Space Junk" wrote:
[vbcol=seagreen]
> I know how to move a data base, and data base settings only shows the C
> drive. I do not need to change the folder data bases are being stored in. I
> need to change the DEFAULT drive.
> It is looking like a re-installation.
> "Dan Guzman" wrote:
|||Space Junk wrote:
You can easily default new database data and log files under the
database settings tab in SQL EM. Just change the Default Data and
Default Log locations.
David Gugick
Imceda Software
www.imceda.com
|||I was trying that, however me previous second HDD was not showing up in
there, only drive C. Not sure why, the drive was functioning normally. I
put a new drive in, and check again, then I had the option to choose other
than the C drive.
"David Gugick" wrote:
> Space Junk wrote:
> You can easily default new database data and log files under the
> database settings tab in SQL EM. Just change the Default Data and
> Default Log locations.
>
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
isntall that was initially installed to the C drive?
Space Junk wrote:
> Is there a way to change the default location, including drive, of a
> SQL isntall that was initially installed to the C drive?
By "default location", do you mean where the executables are installed?
Or do you mean where the data and log files are installed?
David Gugick
Imceda Software
www.imceda.com
|||I mean where data and logs are installed by default. Sorry I thought I said
that.
Example, adding a bigger HDD to a system and needing new data bases to
default to the new drive.
"David Gugick" wrote:
> Space Junk wrote:
> By "default location", do you mean where the executables are installed?
> Or do you mean where the data and log files are installed?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
|||Space Junk wrote:
> I mean where data and logs are installed by default. Sorry I thought
> I said that.
> Example, adding a bigger HDD to a system and needing new data bases to
> default to the new drive.
Just add a new data file on the database to the new drive. SQL Server
will fill the data files (or log files) proportionally. If you want to
actually move the data and log files, you can use sp_detachdb and
sp_attach_db / sp_attach_single_file_db to disconnect them and reconnect
once they are on the new drive.
David Gugick
Imceda Software
www.imceda.com
|||You can specify the database default folders for data and log files from
Enterprise Manager under server properties --> database settings.
Hope this helps.
Dan Guzman
SQL Server MVP
"Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> Is there a way to change the default location, including drive, of a SQL
> isntall that was initially installed to the C drive?
|||I know how to move a data base, and data base settings only shows the C
drive. I do not need to change the folder data bases are being stored in. I
need to change the DEFAULT drive.
It is looking like a re-installation.
"Dan Guzman" wrote:
> You can specify the database default folders for data and log files from
> Enterprise Manager under server properties --> database settings.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
>
>
|||I tried a different physical HDD and then that new drive showed up under DB
Settings under DB properties. I am not sure why the other functioning drive
did not show up.
"Space Junk" wrote:
[vbcol=seagreen]
> I know how to move a data base, and data base settings only shows the C
> drive. I do not need to change the folder data bases are being stored in. I
> need to change the DEFAULT drive.
> It is looking like a re-installation.
> "Dan Guzman" wrote:
|||Space Junk wrote:
You can easily default new database data and log files under the
database settings tab in SQL EM. Just change the Default Data and
Default Log locations.
David Gugick
Imceda Software
www.imceda.com
|||I was trying that, however me previous second HDD was not showing up in
there, only drive C. Not sure why, the drive was functioning normally. I
put a new drive in, and check again, then I had the option to choose other
than the C drive.
"David Gugick" wrote:
> Space Junk wrote:
> You can easily default new database data and log files under the
> database settings tab in SQL EM. Just change the Default Data and
> Default Log locations.
>
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
Default Drive for new DBs
Is there a way to change the default location, including drive, of a SQL
isntall that was initially installed to the C drive?Space Junk wrote:
> Is there a way to change the default location, including drive, of a
> SQL isntall that was initially installed to the C drive?
By "default location", do you mean where the executables are installed?
Or do you mean where the data and log files are installed?
David Gugick
Imceda Software
www.imceda.com|||I mean where data and logs are installed by default. Sorry I thought I said
that.
Example, adding a bigger HDD to a system and needing new data bases to
default to the new drive.
"David Gugick" wrote:
> Space Junk wrote:
> By "default location", do you mean where the executables are installed?
> Or do you mean where the data and log files are installed?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||Space Junk wrote:
> I mean where data and logs are installed by default. Sorry I thought
> I said that.
> Example, adding a bigger HDD to a system and needing new data bases to
> default to the new drive.
Just add a new data file on the database to the new drive. SQL Server
will fill the data files (or log files) proportionally. If you want to
actually move the data and log files, you can use sp_detachdb and
sp_attach_db / sp_attach_single_file_db to disconnect them and reconnect
once they are on the new drive.
David Gugick
Imceda Software
www.imceda.com|||You can specify the database default folders for data and log files from
Enterprise Manager under server properties --> database settings.
Hope this helps.
Dan Guzman
SQL Server MVP
"Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> Is there a way to change the default location, including drive, of a SQL
> isntall that was initially installed to the C drive?|||I know how to move a data base, and data base settings only shows the C
drive. I do not need to change the folder data bases are being stored in.
I
need to change the DEFAULT drive.
It is looking like a re-installation.
"Dan Guzman" wrote:
> You can specify the database default folders for data and log files from
> Enterprise Manager under server properties --> database settings.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
>
>|||I tried a different physical HDD and then that new drive showed up under DB
Settings under DB properties. I am not sure why the other functioning drive
did not show up.
"Space Junk" wrote:
[vbcol=seagreen]
> I know how to move a data base, and data base settings only shows the C
> drive. I do not need to change the folder data bases are being stored in.
I
> need to change the DEFAULT drive.
> It is looking like a re-installation.
> "Dan Guzman" wrote:
>|||Space Junk wrote:
You can easily default new database data and log files under the
database settings tab in SQL EM. Just change the Default Data and
Default Log locations.
David Gugick
Imceda Software
www.imceda.com|||I was trying that, however me previous second HDD was not showing up in
there, only drive C. Not sure why, the drive was functioning normally. I
put a new drive in, and check again, then I had the option to choose other
than the C drive.
"David Gugick" wrote:
> Space Junk wrote:
> You can easily default new database data and log files under the
> database settings tab in SQL EM. Just change the Default Data and
> Default Log locations.
>
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
isntall that was initially installed to the C drive?Space Junk wrote:
> Is there a way to change the default location, including drive, of a
> SQL isntall that was initially installed to the C drive?
By "default location", do you mean where the executables are installed?
Or do you mean where the data and log files are installed?
David Gugick
Imceda Software
www.imceda.com|||I mean where data and logs are installed by default. Sorry I thought I said
that.
Example, adding a bigger HDD to a system and needing new data bases to
default to the new drive.
"David Gugick" wrote:
> Space Junk wrote:
> By "default location", do you mean where the executables are installed?
> Or do you mean where the data and log files are installed?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||Space Junk wrote:
> I mean where data and logs are installed by default. Sorry I thought
> I said that.
> Example, adding a bigger HDD to a system and needing new data bases to
> default to the new drive.
Just add a new data file on the database to the new drive. SQL Server
will fill the data files (or log files) proportionally. If you want to
actually move the data and log files, you can use sp_detachdb and
sp_attach_db / sp_attach_single_file_db to disconnect them and reconnect
once they are on the new drive.
David Gugick
Imceda Software
www.imceda.com|||You can specify the database default folders for data and log files from
Enterprise Manager under server properties --> database settings.
Hope this helps.
Dan Guzman
SQL Server MVP
"Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
> Is there a way to change the default location, including drive, of a SQL
> isntall that was initially installed to the C drive?|||I know how to move a data base, and data base settings only shows the C
drive. I do not need to change the folder data bases are being stored in.
I
need to change the DEFAULT drive.
It is looking like a re-installation.
"Dan Guzman" wrote:
> You can specify the database default folders for data and log files from
> Enterprise Manager under server properties --> database settings.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Space Junk" <SpaceJunk@.discussions.microsoft.com> wrote in message
> news:A66E48D4-8B2B-4948-B349-F2BDA2EFA09A@.microsoft.com...
>
>|||I tried a different physical HDD and then that new drive showed up under DB
Settings under DB properties. I am not sure why the other functioning drive
did not show up.
"Space Junk" wrote:
[vbcol=seagreen]
> I know how to move a data base, and data base settings only shows the C
> drive. I do not need to change the folder data bases are being stored in.
I
> need to change the DEFAULT drive.
> It is looking like a re-installation.
> "Dan Guzman" wrote:
>|||Space Junk wrote:
You can easily default new database data and log files under the
database settings tab in SQL EM. Just change the Default Data and
Default Log locations.
David Gugick
Imceda Software
www.imceda.com|||I was trying that, however me previous second HDD was not showing up in
there, only drive C. Not sure why, the drive was functioning normally. I
put a new drive in, and check again, then I had the option to choose other
than the C drive.
"David Gugick" wrote:
> Space Junk wrote:
> You can easily default new database data and log files under the
> database settings tab in SQL EM. Just change the Default Data and
> Default Log locations.
>
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
Wednesday, March 21, 2012
Decryption within an application
I need to encrypt one column of data in a single table and I pretty much
have all the operations figured out, including maintaining both the
encrpyted data and a one way hash for searches. I have a view which
decrypts the data properly when the symmetric key has been opened (and
obviously returns null when the key is not open).
I want the view to return the decrypted data only when the user is accessing
the database from a single application. This application maintains a single
database connection per session. My thought was to open the key when the
database connection is established by the application and close it when the
application exits, thereby granting access only through the application. Is
that an acceptable practice?
If I do that, should I protect the key with a password that is then compiled
in the application so that I can open the key? This means that every
installation will have a key protected by the same password. Or is there a
better way to do that?
Thanks for any help."Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:uvmlanAmHHA.4852@.TK2MSFTNGP03.phx.gbl...
>I need to encrypt one column of data in a single table and I pretty much
>have all the operations figured out, including maintaining both the
>encrpyted data and a one way hash for searches. I have a view which
>decrypts the data properly when the symmetric key has been opened (and
>obviously returns null when the key is not open).
> I want the view to return the decrypted data only when the user is
> accessing the database from a single application. This application
> maintains a single database connection per session. My thought was to
> open the key when the database connection is established by the
> application and close it when the application exits, thereby granting
> access only through the application. Is that an acceptable practice?
> If I do that, should I protect the key with a password that is then
> compiled in the application so that I can open the key? This means that
> every installation will have a key protected by the same password. Or is
> there a better way to do that?
> Thanks for any help.
Well, when the key is opened it's specific to a session. So you could have
several sessions opening up the same key simultaneously and I wouldn't think
you'd encounter any problems. Of course you will probably want to do some
thorough testing to be sure, and also make sure you don't take a performance
hit there. I wouldn't recommend storing the key hard-coded in your
application. How about using the Automatic Key Management feature of SQL
2005? The only real downside to it is that all sysadmins can then decrypt
your data (if that's a concern for you - it is for some folks).|||I'm not neccesarily opposed to the sysadmin being able to decrypt the data,
but I don't want any other user outside of the application to have access to
the data. So what I can't figure out (even with SS key management) is how
to open the key only when connecting from the application, unless I compile
a password into the code.
Any thoughts on that would be helpful.
Thanks.
"Mike C#" <xyz@.xyz.com> wrote in message
news:uH0ftcPmHHA.4624@.TK2MSFTNGP04.phx.gbl...
> "Chuck Reif" <creif@.nomail.metopera.org> wrote in message
> news:uvmlanAmHHA.4852@.TK2MSFTNGP03.phx.gbl...
> Well, when the key is opened it's specific to a session. So you could
> have several sessions opening up the same key simultaneously and I
> wouldn't think you'd encounter any problems. Of course you will probably
> want to do some thorough testing to be sure, and also make sure you don't
> take a performance hit there. I wouldn't recommend storing the key
> hard-coded in your application. How about using the Automatic Key
> Management feature of SQL 2005? The only real downside to it is that all
> sysadmins can then decrypt your data (if that's a concern for you - it is
> for some folks).
>|||With automatic key management you should be able to connect to the
application and open the symmetric keys without a password. You can use
GRANT to grant permissions to users on your keys, certificates, etc. Here's
an article with some samples that demonstrate encryption/decryption without
passwords, thanks to automatic key management:
[url]http://www.sqlservercentral.com/columnists/mcoles/sql2005symmetricencryption.asp[/
url]
You might also want to look into the DecryptByKeyAutoAsymKey and
DecryptByKeyAutoCert functions that combine the DecryptBy... functions with
OPEN SYMMETRIC KEY automatically.
"Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:%23GeqmRWmHHA.596@.TK2MSFTNGP06.phx.gbl...
> I'm not neccesarily opposed to the sysadmin being able to decrypt the
> data, but I don't want any other user outside of the application to have
> access to the data. So what I can't figure out (even with SS key
> management) is how to open the key only when connecting from the
> application, unless I compile a password into the code.
> Any thoughts on that would be helpful.
> Thanks.
> "Mike C#" <xyz@.xyz.com> wrote in message
> news:uH0ftcPmHHA.4624@.TK2MSFTNGP04.phx.gbl...
>|||Thanks so much for your help, but I must be dense. If I grant permission to
the users or use automatic key management, then it seems to me that the data
can be encrypted outside of my application by a non-sa user. If I only want
the application to display the unencrypted data, I can't see how this
automatic approach works.
That is why I took the approach of having the application open the key.
Sort of like the old application-role security.
But I would love to find a better way.
"Mike C#" <xyz@.xyz.com> wrote in message
news:Od0T8%23amHHA.4772@.TK2MSFTNGP05.phx.gbl...
> With automatic key management you should be able to connect to the
> application and open the symmetric keys without a password. You can use
> GRANT to grant permissions to users on your keys, certificates, etc.
> Here's an article with some samples that demonstrate encryption/decryption
> without passwords, thanks to automatic key management:
> http://www.sqlservercentral.com/col...ion.asp
> You might also want to look into the DecryptByKeyAutoAsymKey and
> DecryptByKeyAutoCert functions that combine the DecryptBy... functions
> with OPEN SYMMETRIC KEY automatically.
> "Chuck Reif" <creif@.nomail.metopera.org> wrote in message
> news:%23GeqmRWmHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||"Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:%23C1qbs$mHHA.668@.TK2MSFTNGP05.phx.gbl...
> Thanks so much for your help, but I must be dense. If I grant permission
> to the users or use automatic key management, then it seems to me that the
> data can be encrypted outside of my application by a non-sa user. If I
> only want the application to display the unencrypted data, I can't see how
> this automatic approach works.
Anyone who has the username and password used by the application to log into
the database would have the ability to decrypt the encrypted data.
Alternatively, if a password is stored in the application, anyone with a hex
editor could decrypt the encrypted data outside of the application. The
only way I can think of to force decryption only through the application
would be to encrypt only in the application. But then you take on the
responsibility of encryption key management yourself. I don't know of any
magic bullet to ensure that data encrypted using SQL Server can only be
accessed via a specific front-end application interface.
> That is why I took the approach of having the application open the key.
> Sort of like the old application-role security.
Anyone with a hex editor could conceivably locate a password stored in an
application and use it to decrypt data. Linking it to a specific Windows
login puts the burden of encryption key management back on the operating
system. That's basically the main difference; do you want to manage your
own passwords, or do you want to let Windows and SQL Server manage your
passwords?
> But I would love to find a better way.
Biometrics?
have all the operations figured out, including maintaining both the
encrpyted data and a one way hash for searches. I have a view which
decrypts the data properly when the symmetric key has been opened (and
obviously returns null when the key is not open).
I want the view to return the decrypted data only when the user is accessing
the database from a single application. This application maintains a single
database connection per session. My thought was to open the key when the
database connection is established by the application and close it when the
application exits, thereby granting access only through the application. Is
that an acceptable practice?
If I do that, should I protect the key with a password that is then compiled
in the application so that I can open the key? This means that every
installation will have a key protected by the same password. Or is there a
better way to do that?
Thanks for any help."Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:uvmlanAmHHA.4852@.TK2MSFTNGP03.phx.gbl...
>I need to encrypt one column of data in a single table and I pretty much
>have all the operations figured out, including maintaining both the
>encrpyted data and a one way hash for searches. I have a view which
>decrypts the data properly when the symmetric key has been opened (and
>obviously returns null when the key is not open).
> I want the view to return the decrypted data only when the user is
> accessing the database from a single application. This application
> maintains a single database connection per session. My thought was to
> open the key when the database connection is established by the
> application and close it when the application exits, thereby granting
> access only through the application. Is that an acceptable practice?
> If I do that, should I protect the key with a password that is then
> compiled in the application so that I can open the key? This means that
> every installation will have a key protected by the same password. Or is
> there a better way to do that?
> Thanks for any help.
Well, when the key is opened it's specific to a session. So you could have
several sessions opening up the same key simultaneously and I wouldn't think
you'd encounter any problems. Of course you will probably want to do some
thorough testing to be sure, and also make sure you don't take a performance
hit there. I wouldn't recommend storing the key hard-coded in your
application. How about using the Automatic Key Management feature of SQL
2005? The only real downside to it is that all sysadmins can then decrypt
your data (if that's a concern for you - it is for some folks).|||I'm not neccesarily opposed to the sysadmin being able to decrypt the data,
but I don't want any other user outside of the application to have access to
the data. So what I can't figure out (even with SS key management) is how
to open the key only when connecting from the application, unless I compile
a password into the code.
Any thoughts on that would be helpful.
Thanks.
"Mike C#" <xyz@.xyz.com> wrote in message
news:uH0ftcPmHHA.4624@.TK2MSFTNGP04.phx.gbl...
> "Chuck Reif" <creif@.nomail.metopera.org> wrote in message
> news:uvmlanAmHHA.4852@.TK2MSFTNGP03.phx.gbl...
> Well, when the key is opened it's specific to a session. So you could
> have several sessions opening up the same key simultaneously and I
> wouldn't think you'd encounter any problems. Of course you will probably
> want to do some thorough testing to be sure, and also make sure you don't
> take a performance hit there. I wouldn't recommend storing the key
> hard-coded in your application. How about using the Automatic Key
> Management feature of SQL 2005? The only real downside to it is that all
> sysadmins can then decrypt your data (if that's a concern for you - it is
> for some folks).
>|||With automatic key management you should be able to connect to the
application and open the symmetric keys without a password. You can use
GRANT to grant permissions to users on your keys, certificates, etc. Here's
an article with some samples that demonstrate encryption/decryption without
passwords, thanks to automatic key management:
[url]http://www.sqlservercentral.com/columnists/mcoles/sql2005symmetricencryption.asp[/
url]
You might also want to look into the DecryptByKeyAutoAsymKey and
DecryptByKeyAutoCert functions that combine the DecryptBy... functions with
OPEN SYMMETRIC KEY automatically.
"Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:%23GeqmRWmHHA.596@.TK2MSFTNGP06.phx.gbl...
> I'm not neccesarily opposed to the sysadmin being able to decrypt the
> data, but I don't want any other user outside of the application to have
> access to the data. So what I can't figure out (even with SS key
> management) is how to open the key only when connecting from the
> application, unless I compile a password into the code.
> Any thoughts on that would be helpful.
> Thanks.
> "Mike C#" <xyz@.xyz.com> wrote in message
> news:uH0ftcPmHHA.4624@.TK2MSFTNGP04.phx.gbl...
>|||Thanks so much for your help, but I must be dense. If I grant permission to
the users or use automatic key management, then it seems to me that the data
can be encrypted outside of my application by a non-sa user. If I only want
the application to display the unencrypted data, I can't see how this
automatic approach works.
That is why I took the approach of having the application open the key.
Sort of like the old application-role security.
But I would love to find a better way.
"Mike C#" <xyz@.xyz.com> wrote in message
news:Od0T8%23amHHA.4772@.TK2MSFTNGP05.phx.gbl...
> With automatic key management you should be able to connect to the
> application and open the symmetric keys without a password. You can use
> GRANT to grant permissions to users on your keys, certificates, etc.
> Here's an article with some samples that demonstrate encryption/decryption
> without passwords, thanks to automatic key management:
> http://www.sqlservercentral.com/col...ion.asp
> You might also want to look into the DecryptByKeyAutoAsymKey and
> DecryptByKeyAutoCert functions that combine the DecryptBy... functions
> with OPEN SYMMETRIC KEY automatically.
> "Chuck Reif" <creif@.nomail.metopera.org> wrote in message
> news:%23GeqmRWmHHA.596@.TK2MSFTNGP06.phx.gbl...
>|||"Chuck Reif" <creif@.nomail.metopera.org> wrote in message
news:%23C1qbs$mHHA.668@.TK2MSFTNGP05.phx.gbl...
> Thanks so much for your help, but I must be dense. If I grant permission
> to the users or use automatic key management, then it seems to me that the
> data can be encrypted outside of my application by a non-sa user. If I
> only want the application to display the unencrypted data, I can't see how
> this automatic approach works.
Anyone who has the username and password used by the application to log into
the database would have the ability to decrypt the encrypted data.
Alternatively, if a password is stored in the application, anyone with a hex
editor could decrypt the encrypted data outside of the application. The
only way I can think of to force decryption only through the application
would be to encrypt only in the application. But then you take on the
responsibility of encryption key management yourself. I don't know of any
magic bullet to ensure that data encrypted using SQL Server can only be
accessed via a specific front-end application interface.
> That is why I took the approach of having the application open the key.
> Sort of like the old application-role security.
Anyone with a hex editor could conceivably locate a password stored in an
application and use it to decrypt data. Linking it to a specific Windows
login puts the burden of encryption key management back on the operating
system. That's basically the main difference; do you want to manage your
own passwords, or do you want to let Windows and SQL Server manage your
passwords?
> But I would love to find a better way.
Biometrics?
Labels:
application,
column,
database,
decryption,
encrypt,
figured,
including,
maintaining,
microsoft,
muchhave,
mysql,
operations,
oracle,
pretty,
server,
single,
sql,
table,
theencrpyted
Subscribe to:
Posts (Atom)