Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Thursday, March 22, 2012

Database Backup Security

Hi

We have developed and deployed a database which contanis very sensitive
information. Our client is now concerned about the security of the back
ups. In essense, if someone in the organization can get hold of the
backup of the database, he can simply restore it on any sql server in
the world with sa permission.

I know Microsoft provides flexibility of adding the "Password" in the
Backup t-sql statement but it wouldn't be of much use if the back up
task is saved as a script and password will be written inside the
script.

your suggestions are really appreciated!

Thanks<muzamil@.hotmail.com> wrote in message
news:1115055348.283887.64500@.z14g2000cwz.googlegro ups.com...
> Hi
> We have developed and deployed a database which contanis very sensitive
> information. Our client is now concerned about the security of the back
> ups. In essense, if someone in the organization can get hold of the
> backup of the database, he can simply restore it on any sql server in
> the world with sa permission.
> I know Microsoft provides flexibility of adding the "Password" in the
> Backup t-sql statement but it wouldn't be of much use if the back up
> task is saved as a script and password will be written inside the
> script.
> your suggestions are really appreciated!
> Thanks

If your client believes they cannot trust their own IT staff and/or cannot
secure their own backups, then I would suggest they have a number of serious
issues to address. On the technical side, they can implement a few standard
practices such as backing up to NTFS drives with appropriate ACLs, limiting
physical access to backup drives and tapes to a minimum number of trusted
staff, using OS-level auditing to see who accesses the files etc.
Ultimately, though, someone has to have access to backups, domain admin and
Exchange admin accounts etc., so they need to have people they can rely on,
and that probably isn't a problem you can or should try to solve for them -
it's really a human resources issue.

However, I appreciate that in reality, and especially in smaller companies,
these things may be not always be so easy. One possibility is to consider
encrypting the sensitive data using a key which is compiled into your
application. Your application can then encrypt/decrpyt the data when users
acess it, but if someone queries the tables directly then they only see the
encrypted data:

http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=22

Simonsql

Thursday, March 8, 2012

Database Admin Security Permissions

Hi,
We installed SQL 2000 Tools only (Enterprise manager) on
the database admins pc's, and now we want to setup
permissions for the database admins to only be able to do
database administration.
Should I use Windows authentication, (how do I setup just
enough permissions?) or SQL Authentication (how do I do
that?) Is there a whitepaper for this? What is the best
practice?
Thanks,
Judith
Hi,
What ever authentication, If you set the SYSTEM ADMIN role to DBA person, he
can do administration as well as any changes to databases .
Why should you restrict access to database administrators? Normally in all
enterprises he is the guy who is responsible
for your datbase server. So no need to protect the access from him
Thanks
Hari
MCDBA
"Judith" <anonymous@.discussions.microsoft.com> wrote in message
news:12b9801c44339$5cf78a20$a401280a@.phx.gbl...
> Hi,
> We installed SQL 2000 Tools only (Enterprise manager) on
> the database admins pc's, and now we want to setup
> permissions for the database admins to only be able to do
> database administration.
> Should I use Windows authentication, (how do I setup just
> enough permissions?) or SQL Authentication (how do I do
> that?) Is there a whitepaper for this? What is the best
> practice?
> Thanks,
> Judith
>
|||Well, I could think of this myself! But the question is
that that I want to restrict access for database admins,
because it's a different department and responsibility. So
our enterprise is a little different. Does anybody knows
more about this subject?
Thanks in advance!!!

>--Original Message--
>Hi,
>What ever authentication, If you set the SYSTEM ADMIN
role to DBA person, he
>can do administration as well as any changes to
databases .
>Why should you restrict access to database
administrators? Normally in all
>enterprises he is the guy who is responsible
>for your datbase server. So no need to protect the access
from him
>Thanks
>Hari
>MCDBA
>
>"Judith" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:12b9801c44339$5cf78a20$a401280a@.phx.gbl...
do[vbcol=seagreen]
just
>
>.
>

Database Access

I run several DTS Packages that load databases residing on two seperate
instances of SQL Server 2000 on the same server. For security reasons, I
need to be able to set the Databases on one instance to Read/Write access,
set the database access on the other instance to Read only, run the packages
on the first instance, and then reset the access to Read Only. The ideal
solution would be writing the logic in T-SQL in a stored procedure that is
already part of the Package or add a new stored procedure to the package. I
have not been able to find any reference to setting the Database access in
code. I would appreciate and welcome any advise on how to accomplish this
programming task. Thank you.
grp
Have a look at sp_dboption in bol.
You might be better off creating roles with the correct permissions and
moving the user between those roles.
"PGene2" wrote:

> I run several DTS Packages that load databases residing on two seperate
> instances of SQL Server 2000 on the same server. For security reasons, I
> need to be able to set the Databases on one instance to Read/Write access,
> set the database access on the other instance to Read only, run the packages
> on the first instance, and then reset the access to Read Only. The ideal
> solution would be writing the logic in T-SQL in a stored procedure that is
> already part of the Package or add a new stored procedure to the package. I
> have not been able to find any reference to setting the Database access in
> code. I would appreciate and welcome any advise on how to accomplish this
> programming task. Thank you.
> --
> grp
|||Thanks. This at least gives me a couple of directions to go in. I appreciate
the help.
grp
"Nigel Rivett" wrote:
[vbcol=seagreen]
> Have a look at sp_dboption in bol.
> You might be better off creating roles with the correct permissions and
> moving the user between those roles.
>
> "PGene2" wrote:

Wednesday, March 7, 2012

Database Access

I run several DTS Packages that load databases residing on two seperate
instances of SQL Server 2000 on the same server. For security reasons, I
need to be able to set the Databases on one instance to Read/Write access,
set the database access on the other instance to Read only, run the packages
on the first instance, and then reset the access to Read Only. The ideal
solution would be writing the logic in T-SQL in a stored procedure that is
already part of the Package or add a new stored procedure to the package. I
have not been able to find any reference to setting the Database access in
code. I would appreciate and welcome any advise on how to accomplish this
programming task. Thank you.
grpHave a look at sp_dboption in bol.
You might be better off creating roles with the correct permissions and
moving the user between those roles.
"PGene2" wrote:

> I run several DTS Packages that load databases residing on two seperate
> instances of SQL Server 2000 on the same server. For security reasons, I
> need to be able to set the Databases on one instance to Read/Write access,
> set the database access on the other instance to Read only, run the packag
es
> on the first instance, and then reset the access to Read Only. The ideal
> solution would be writing the logic in T-SQL in a stored procedure that is
> already part of the Package or add a new stored procedure to the package.
I
> have not been able to find any reference to setting the Database access in
> code. I would appreciate and welcome any advise on how to accomplish this
> programming task. Thank you.
> --
> grp|||Thanks. This at least gives me a couple of directions to go in. I appreciat
e
the help.
--
grp
"Nigel Rivett" wrote:
[vbcol=seagreen]
> Have a look at sp_dboption in bol.
> You might be better off creating roles with the correct permissions and
> moving the user between those roles.
>
> "PGene2" wrote:
>