4 added 62 characters in body
source | link

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. This help by giving you "security in depth".

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, your app could use different schemas & views or9or preferrably stored procs to limit or restrict what they can do. If your app can only use those features you are less exposed. The concept is to grant the minimal priviliges necessary. DO NOT give SA or DBO privs to an application/service or service acct. Ever.

The difficult bit will be that Azure requires a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perform specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than a select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. This help by giving you "security in depth".

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, your app could use different schemas & views or9 preferrably stored procs to limit or restrict what they can do. If your app can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure requires a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perform specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. This help by giving you "security in depth".

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, your app could use different schemas & views or preferrably stored procs to limit or restrict what they can do. If your app can only use those features you are less exposed. The concept is to grant the minimal priviliges necessary. DO NOT give SA or DBO privs to an application or service acct. Ever.

The difficult bit will be that Azure requires a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perform specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than a select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

3 added 6 characters in body
source | link

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. This help by giving you want security"security in depthdepth".

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, Youryour app could use different schemas & views oror9 preferrably stored procs to limit or restrict what they can do. If your app connects and can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure requirerequires a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perfromperform specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. you want security in depth.

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, Your app could use different schemas & views or preferrably stored procs to limit or restrict what they can do. If your app connects and can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure require a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perfrom specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. This help by giving you "security in depth".

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, your app could use different schemas & views or9 preferrably stored procs to limit or restrict what they can do. If your app can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure requires a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perform specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

2 added 259 characters in body
source | link

I will start buyby saying I agree that security is generally better handled by an application brokering between the client and database. you want security in depth. 

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, Your app could use different schemas & views or preferrably stored procs to limit or restrict what they can do. If your app connects and can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure require a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perfrom specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but I beleive you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

I will start buy saying I agree that security is generally better handled by an application brokering between the client and database.

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, Your app could use different schemas & views or preferrably stored procs to limit or restrict what they can do. If your app connects and can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure require a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perfrom specific functions. If you want users to have seperate logins and passwords this will become a maintenance overhead for you.

I'm not an expert with Azure, but I beleive you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

I will start by saying I agree that security is generally better handled by an application brokering between the client and database. you want security in depth. 

However I disagree with some of the previous answers. It is possible to limit or restrict the permissions and privileges users have at database level.

Aside from granting select, insert, update, delete privileges, Your app could use different schemas & views or preferrably stored procs to limit or restrict what they can do. If your app connects and can only use those features you are less exposed. DO NOT give SA or DBO privs to an application/service acct. Ever.

The difficult bit will be that Azure require a SQL login/password. If users share the same SQL login, that will limit your ability to change passwords, and your application will need to handle which users can perfrom specific functions. If you want users to have seperate logins and passwords at SQL level this will become a maintenance overhead for you.

I'm not an expert with Azure, but you can also limit/exclude connections by IP address/range. If your client sites can be identified by IP that could give you an added level of security.

But the sad reality is users can bring a db server to it's knees with nothing more than select query. So you do not want your users to ever know what that SQL login/password is, because if they can connect, they can select.

In a corporate environment this might be acceptable, but in the wild wild web.. this is hacker news waiting to happen.

I highly reccomend you go for security in depth, build some kind of middle tier/broker and keep users at arms-length from your db.

1
source | link