设计一个包含三层的app实例

日期: 2008-05-27 作者:Michèle Leroux Bustamante 来源:TechTarget中国

问:我现在正在设计一个包含三层的app实例:Web 浏览器,.NET应用程序和数据库服务器。我相信(如果我说错了请纠正)只要每个个体用户都没有直接连接到SQL服务器上(除了管理员等),那么可以做到使用适当的权限为IIS创建一个登陆来连接到服务器或者是创建一个注册用户来连接到当前的数据库。.NET应用程序将使用ADO.NET连接到数据库(DB)。这是正确的么,或者是我攻击错了目标?   答:让我们首先阐明你在这儿所描述的实体层。

Web浏览器处在用户层,但是实际上它并不参与服务器端的应用程序所在层的描述。用户通过浏览器提供凭证,最终由IIS认证或者通过到ASP.NET的用户认证。我假设.NET应用……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

问:我现在正在设计一个包含三层的app实例:Web 浏览器,.NET应用程序和数据库服务器。我相信(如果我说错了请纠正)只要每个个体用户都没有直接连接到SQL服务器上(除了管理员等),那么可以做到使用适当的权限为IIS创建一个登陆来连接到服务器或者是创建一个注册用户来连接到当前的数据库。.NET应用程序将使用ADO.NET连接到数据库(DB)。这是正确的么,或者是我攻击错了目标?

  答:让我们首先阐明你在这儿所描述的实体层。Web浏览器处在用户层,但是实际上它并不参与服务器端的应用程序所在层的描述。用户通过浏览器提供凭证,最终由IIS认证或者通过到ASP.NET的用户认证。我假设.NET应用程序连同IIS一起在Web服务器的实体层上运行。数据库服务器实体层可能正在运行数据库应用程序。那么服务器端就存在两个实体层。如果这是基于内联网(intranet)的应用程序,网站可能配置成在IIS中的Windows认证,也就是说,IIS将在Windows域中验证用户。已批准的请求将被送到ASP.NET运行时进行处理,如果应用程序配置成启用模拟用户,那么应用程序代码将取决于模拟用户被授权可以做什么。

  identity impersonate="true"

  例如,如果登陆用户被授权对数据库进行存取(这实际上的意义是:无论哪个数据库对象都允许该用户进行存取,而且是任何形式的存取方式,类似db_datareader, dbdatawriter)那么存取数据库的函数功能将会无异常地执行。但是正像你所说的,这并不现实。这意味着试图对数据库进行存取的代码必须首先模拟一个有适当权限对数据库对象进行存取的帐户。如果是内联网(intranet)应用程序来模拟登陆用户,那么会非常匆忙地处理这个模拟并且会发生重复,从而导致已登陆的用户再次使用同一身份登陆,并执行遗留的请求线程。

  如果应用程序不模拟登陆用户,ASP.NET应用程序需求将和在machine.config字段中配置的 ASP.NET identity一同被执行。这通常使用有权限限制的NETWORKSERVICE帐户(特意设置的)。理论上,你可以创建一个应用程序来为所有的需求模拟一个拥有高级特权的帐户,当然它也可以对适当的数据库对象进行存取。但是-不要这样做!这是懒人获得可使用的保护资源的解决办法,显然它严重危及到应用程序的安全。如果黑客企图访问内部工作进程的执行线程,他们就可以获得该线程的所有存取权限。缺省情况下,我们更倾向于使用NETWORKSERVICE帐户,或者使用内联网(intranet)应用程序已登陆用户的帐户。

  那么,这样做的解决方法呢?

  · 要么模拟登陆用户,要么在NETWORKSERVICE帐户下运行应用程序

  · 对于数据库调用,要么在运行时模拟一个特权用户,要么使用企业服务(EnterpriseServices)调用一个服务组件,该服务组件是和所需帐户一同运行使用数据库特权(更好)。这样做减弱了所需帐户从代码访问数据库,允许它根据需要修改成为

  你需要什么样的帐户?

  同时拥有一个帐户对数据库只读(对于适当的对象的db_datareader特权),和另外一个帐户对数据库可读可写(db_datareader 和db_datawriter特权)是有用的。这样的话,在读操作中你不会轻易地受到写操作的攻击。

相关推荐