|
Wednesday November 7 2001 Network Security and Web Services Deployment Ideas for securing your services These days, building a secure network infrastructure involves much research and implementation planning. The fundamental strategy of building a secure environment involves letting subscribers access authorized resources without hindrances while ensuring that intruders fail to gain access. In this article we will be looking at one of the strategies and concepts involved in implementing the necessary security measures related to Web Services deployment. Fundamentally, securing a Web Service is very similar to securing any Web site. At a network level, the topics that we grapple with relate to the types of subscribers we want to gain access, what level of authentication we find necessary to protect our resources yet allow our subscribers access, determining subscribers rights, and securing the data that the Web Service needs to access itself so that subscribers can't directly get that data. From a programmatic standpoint, the difference in securing a Web Service is that not only will subscribers want to authenticate to our Web Service, but also applications will want access to our Web Service. After all, the concept behind Web Services is to expose our application to the world for integration with Web sites and other application services. In this article we will concentrate on subscriber authentication from a server standpoint, but we will briefly introduce some programmatic solutions to code access security. Looking at our first dilemma, we need to identify the types of subscribers we want to gain access to our Web Service. This is similar to identifying a target audience for any web site we wish to run, as we need to establish whether it is meant for a general - all Internet - audience, or just a specific group of subscribers on the Internet. The type of Web Service we choose to expose will often determine the profile of subscribers and level of access we need to make available. Web Services that are provided for a fee will have identifiable subscribers due to their very nature. In the case where you have identifiable subscribers you can use a firewall to limit access to the web server based on rules input by IP address. If you need the access to be to any subscriber independent of their IP address, as is the case if the Web Service is open to all Internet subscribers, then you need an authentication scheme to control who accesses the service. Network Infrastructure In either case mentioned above, there is a certain network infrastructure that needs to exist to secure the internal network structure and avoid having subscribers that access the Web Service access any other internal resources. The goal is to prevent access by any intruder. Getting through many layers of security is always more challenging to a potential intruder than if just one layer is presented. The Web server that contains the Web Service site usually lives in an area of the network called the DMZ, or demilitarized zone. This area is so called because it is open to the Internet and has less security enforced than an internal portion of a network usually would. Between the DMZ area and the internal corporate network there is placed a firewall mechanism to shield against subscribers who might try to gain access from the Web Site machine to internal network resources. The firewall usually directs the traffic coming from the Web Site machine directly to any internal resources, such as data servers, and prevents any other resources from being accessed by traffic coming from the Web Site machine. The DMZ and firewall concepts are illustrated in the diagram below.
In addition to implementing security in the corporate infrastructure, you must incorporate evaluation of the security implemented. Internal evaluation can include monitoring, auditing, and even periodic internal testing of the security to check for holes where it could fail. Many corporations also get an external security audit done which can expose additional security concerns and even provide recommendations on remediation of any such concerns.
The most popular methodology today is to create a custom authentication screen for a web site and employ an encryption methodology to protect the subscribers information. This has the lowest impact on the subscribers while creating a relatively secure environment. The last dilemma that we mentioned was to secure the internal resources from any subscriber that might independently attempt to access them. The solution we showed in our diagram above incorporated a firewall mechanism between our Web site server and our internal server. The firewall mechanism can do two things for us. It can limit the traffic coming from the Web site to a specific IP address within our internal structure, and it can limit the type of traffic. For instance, it could limit the traffic to data requests, refusing to respond to a request for another type of file. This protects other internal data that the Web site would not usually need access to. In addition to this methodology, the internal servers often have an authentication that is necessary for any subscriber to get to them. Many times there are special accounts on these servers for the Web server that are additionally limited, so if that account gets compromised it doesn't have as much power as an internal subscriber would. Other Considerations One final thing to mention in our article is the programmatic security that can be implemented within the code that constitutes a Web Service solution. One of the widely supported approaches to code access security is the use of a digital signature. Many of the newer programming platforms support the creation of a digital signature that can be shipped with code, and be used as a means to identify the origin and version of a program. There are also solutions in place which supplement the network security schemes by applying subscriber identification to a subscriber who is attempting to run a piece of code. The code can check and see if the subscriber is allowed to run it and take appropriate action based on the outcome of the inquiry. In addition code that is attempting to access and incorporate a Web Service can inquire as to the level of security required to perform the functions exposed in the Web Service and take appropriate action as well. Conclusion There are many security concerns evolving today, and as the Internet is more accessible to everyday computer subscribers these concerns will continue to mount. There is an ever-growing amount of resources targeting security, and many companies are building alliances with the security experts and leading anti-virus software manufacturers to provide integrated solutions to ongoing security problems. This article touched on some of the basics we need to keep in mind when designing our Web infrastructure such as subscriber identification, authentication and ensuring security limits are not exceeded during the use of the Web Service. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Or purchase the extended PDF version of this article
from: Adobe Acrobat format (PDF) - 490K |