Best practise on Database security

Hi All,
In our development server, everyone (Developers) are member of system
administrator (SA).
So on development server, anyone can do all database access.
In our production server, there are only two type of account which are
SA and Public Account.
SA can do all database access i.e.: creating the database, tables, and
security accounts, performing backups, and tuning the database.
Public account (used by application. passwd is created by SA and
encrypted on app setting), they can not execute query directly to
sqlserver, they can only run stored procedure provided.
Now, i want to develop new procedure to manage account and authority
on database.
Can anyone tell me, a best practise on this? (Database security)
I mean, what account should be provided in development and production
svr,
and what can each type of account do?
Rgds
HFIs it SQL Server 2000/2005?
<harifajri@.gmail.com> wrote in message
news:1176777055.132452.30140@.n59g2000hsh.googlegroups.com...
> Hi All,
> In our development server, everyone (Developers) are member of system
> administrator (SA).
> So on development server, anyone can do all database access.
> In our production server, there are only two type of account which are
> SA and Public Account.
> SA can do all database access i.e.: creating the database, tables, and
> security accounts, performing backups, and tuning the database.
> Public account (used by application. passwd is created by SA and
> encrypted on app setting), they can not execute query directly to
> sqlserver, they can only run stored procedure provided.
> Now, i want to develop new procedure to manage account and authority
> on database.
> Can anyone tell me, a best practise on this? (Database security)
> I mean, what account should be provided in development and production
> svr,
> and what can each type of account do?
> Rgds
> HF
>|||On Apr 17, 12:56 pm, "Uri Dimant" <u...@.iscar.co.il> wrote:
> Is it SQL Server 2000/2005?
> <harifa...@.gmail.com> wrote in message
> news:1176777055.132452.30140@.n59g2000hsh.googlegroups.com...
>
> > Hi All,
> > In our development server, everyone (Developers) are member of system
> > administrator (SA).
> > So on development server, anyone can do all database access.
> > In our production server, there are only two type of account which are
> > SA and Public Account.
> > SA can do all database access i.e.: creating the database, tables, and
> > security accounts, performing backups, and tuning the database.
> > Public account (used by application. passwd is created by SA and
> > encrypted on app setting), they can not execute query directly to
> > sqlserver, they can only run stored procedure provided.
> > Now, i want to develop new procedure to manage account and authority
> > on database.
> > Can anyone tell me, a best practise on this? (Database security)
> > I mean, what account should be provided in development and production
> > svr,
> > and what can each type of account do?
> > Rgds
> > HF- Hide quoted text -
> - Show quoted text -
We are using SQL Server 2000|||Hi
Use ROLEs to secure the data. Make sure that the users have an EXECUTE
permission only to run stored procedure and /or GRANT SELECT on VIEW...
http://vyaskn.tripod.com/sql_server_security_best_practices.htm --security
best practices
<harifajri@.gmail.com> wrote in message
news:1176862709.039446.313880@.n59g2000hsh.googlegroups.com...
> On Apr 17, 12:56 pm, "Uri Dimant" <u...@.iscar.co.il> wrote:
>> Is it SQL Server 2000/2005?
>> <harifa...@.gmail.com> wrote in message
>> news:1176777055.132452.30140@.n59g2000hsh.googlegroups.com...
>>
>> > Hi All,
>> > In our development server, everyone (Developers) are member of system
>> > administrator (SA).
>> > So on development server, anyone can do all database access.
>> > In our production server, there are only two type of account which are
>> > SA and Public Account.
>> > SA can do all database access i.e.: creating the database, tables, and
>> > security accounts, performing backups, and tuning the database.
>> > Public account (used by application. passwd is created by SA and
>> > encrypted on app setting), they can not execute query directly to
>> > sqlserver, they can only run stored procedure provided.
>> > Now, i want to develop new procedure to manage account and authority
>> > on database.
>> > Can anyone tell me, a best practise on this? (Database security)
>> > I mean, what account should be provided in development and production
>> > svr,
>> > and what can each type of account do?
>> > Rgds
>> > HF- Hide quoted text -
>> - Show quoted text -
> We are using SQL Server 2000
>

Best Practices for Large DB

Hi All,

My question is what are the best practices for administering large
DBs. (My coworker is the DB administrator. I'm more of the
developer. But slowly being sucked in.) My main concern is that we
have some DBs that take approx 3 hrs a night just to rebuild the
indexes. I know that with MSSQL 2000, I can use partitioned views to
break out the table(s) into smaller databases and tables. But we also
have an older server that runs MSSQL 7. Lastly how do you handle
drive space issues? Do you spread out the DB across multiple MDF
files on different drives? Thanks in advance.louisducnguyen@.hotmail.com (louis nguyen) wrote in message news:<b0e9d53.0312120911.29e65f55@.posting.google.com>...
> Hi All,
> My question is what are the best practices for administering large
> DBs. (My coworker is the DB administrator. I'm more of the
> developer. But slowly being sucked in.) My main concern is that we
> have some DBs that take approx 3 hrs a night just to rebuild the
> indexes. I know that with MSSQL 2000, I can use partitioned views to
> break out the table(s) into smaller databases and tables. But we also
> have an older server that runs MSSQL 7. Lastly how do you handle
> drive space issues? Do you spread out the DB across multiple MDF
> files on different drives? Thanks in advance.

Large databases can be spread using multiple filegroups. Each
filegroup can be placed on a different drive. The extension for the
..mdf file on the new filegroup(s) wil be .ndf. So on the original
filegroup you will have for example pubs.mdf and on the new filegroup
you will have pubs.ndf. What you can do is add a new filegroup (on a
new drive) and (re)build all of the indexes on that new filegroup.
This way your tables and indexes will be spread on different drives,
which also speeds up inserts on the database.