What Does It All Mean, Anyway?
At a time when IP security devices are offered up as a cure to many legacy ills, it’s easy to get the impression that vendors are all basically talking about the same thing. The fact is, they’re not. And there is as much variation across IP-based security products as there was a across their non-networked forebears.
Take IP access control, for example. If you look at the market right now, and focus on general product architecture rather than specific features sets, you will find there are at least three different designs that qualify as “IP access control.” Yet, they are very different in terms of how they are deployed and used within an organization.
This observation then leads to several questions. Do they all work equally well? Are some of these product architectures better suited for some applications than others? Is there one type that works across the board? Do they all cost similar amounts to deploy and maintain?
The discussion these questions raise will occupy this blog for the next several weeks as we explore this topic and try to provide you with an overview of this emerging product space. In today’s entry, we simply identify the three IP access control architectures referred to earlier, and then look at each one in depth in subsequent blog entries.
What all IP access control products have in common—by definition—is that they use the IP protocol to communicate to one or more components of their overall system architecture. That’s about where the similarity ends.
The first—and simplest—architecture that meets the definition is one in which a control panel (or edge device) uses the IP protocol to communicate directly to the end user by way of a browser. Typically this is accomplished by embedding a Web server inside a control panel or edge device, enabling a browser to connect directly to a user interface that allows database modifications and event viewing. The database for the system resides directly on the control panel, as does the access control application itself. In future blog entries, we will call this the “Embedded” model, because the application and database are embedded directly in the control panel or edge device.
The second architecture for IP access control places a network appliance (or server) between the control panel (or edge device) and the end user, again providing a Web interface from this appliance to a browser on the end user’s computer. The purpose of this network appliance is to provide a range of services that may not be supportable within a single control panel, or to federate a group of control panels into a larger overarching system. The appliance typically maintains a common database across all control panels, as well as running the access control application itself. We will refer to this as the “Network Appliance” model for obvious reasons.
The third architecture for IP access control exploits the connectivity of the Internet to remove the application and data storage services required for access control from the local site. Instead, the servers and applications reside in a data center somewhere on the Web, where they can be shared across multiple control panel installations, and accessed from any browser with the proper permissions. This architecture is usually referred to as the “Web Hosted” model for access control, because the data and applications are hosted on large servers outside of the facilities for which security is being provided.
So, there we have it: Embedded, Network Appliance, and Web Hosted. Three different architectures for providing IP based access control, each with its own unique strengths and weaknesses, but all claiming to be “IP access control”. In our next post, we’ll take a deeper look at the first of these—the Embedded architecture—to see just what it has to offer to integrators and end users.
Posted by Steve Van Till on Jan 09, 2009