Is your business intelligence environment ready for safe, reliable, scalable accessibility via the Internet? How are you addressing this challenge?
Typically, business intelligence (BI) environments are constructed and deployed initially to internal clients across the corporate local area network or Intranet. Data Warehouse managers and architects have a reasonable sense of security knowing that their data, the corporate knowledge base, is located many levels away from outside access protected by various network security mechanisms. An evaluation of BI access components is made with a focus on performance, scalability, and reliability. Very few initial BI architectures take into account the possibility of making the data warehouse accessible and secure for Internet accessibility. This lack of foresight often results in changes to the network architecture or replacement of the BI access tools due to incompatibility with Internet deployment security needs.
Questions for Web-based Business Intelligence
These questions, or group of questions, should be used in a feasibility assessment of a BI access environment, whether in existence or being evaluated for purchase, to determine possible risks. These questions are not all-encompassing, but when answered together they should provide a good sense of whether the BI access environment is ready for Internet deployment. Note, the assumption here is that the user is accessing the BI environment across the Internet through a web browser on their client personal computer.
- What are the hardware and software requirements for installation and administration of the BI access product on an infrastructure consisting of web server, application server, and database server?
In this first question, determination can be made whether the product is compatible with hardware and software standards for the organization. Are the hardware platforms supported by the vendor recommended for the internal infrastructure and by the network administration? In some cases, hardware platforms acceptable for internal LAN use may not be acceptable for Internet use by these administrators due to security and/or other concerns. The operating systems (versions & patches), web server applications, application engines, and databases supported by the vendor must be supported for Internet use by the internal technical administrators.
Look for any requirement that mandates installation of the web server, BI access application, or database on the same physical server. This may limit the network security options for deployment of firewalls and demilitarized zones (DMZ). Typically, the web, application, and database server components are physically separate (see figure 1). A firewall is a hardware or software system designed to prevent unauthorized access to or from a private network. A DMZ is a combination of two or more firewalls that sits between the Internet and an internal network.
Finally, look for the requirement for any third party applications (e.g., infrastructure management application, framework application, other) that may be recommended by the vendor to support this type of Internet infrastructure. The purpose for these products in the solution should be thoroughly explained and understood by the internal technical administrators to determine applicability in the environment.
- Does the product use leading industry database management systems (DBMS)? Is connectivity achieved through ODBC or native drivers?
In this question, look for the requirement for any proprietary, non-industry leading database requirements. These databases are usually used in conjunction with the product’s metadata repository. They are usually described as “low to zero” maintenance, and are transparent from an administration and maintenance standpoint. Use of these proprietary databases means the technical administrators have scant documentation on their operation, have no means of performing backups or optimizing performance. These databases usually are characterized by having to be installed physically on the same server as the application, which may limit flexibility in the architecture.
Finally, look for support of native database drivers versus Open DataBase Connectivity (ODBC) standard for database connectivity. Database performance through ODBC typically is slower than native drivers, due to the addition of a middle layer that translates application queries into commands that the database can perform.
- Does the BI access product interface seamlessly with industry leading enterprise information portal products?
This question is optional, based on the use of an enterprise information portal (EIP) to present content beyond BI access (e.g., news, collaboration, community, content, other) or the need to integrate other applications. Look for the BI access product to have the capability to communicate the content of its directory or BI portal seamlessly to the EIP through some interface method. This product capability will mean that a single user experience method will be used to present content to the user, regardless of whether it originated from the BI access product or other means. If this capability does not exist, the BI access product will be launched through a URL on the EIP. In this case, the user experience through the browser will vary, depending on which product is launched from the EIP.
- Does the BI access product integrate with single sign-on products?
This question is also optional depending on whether the infrastructure is using a single sign-on (SSO) product to automate access to all web and enterprise applications. Once the user is authenticated against an entitlement store (e.g., LDAP, ADSI, NT, NDS) by the SSO product, their credentials are saved for the duration of the session, making re-authentication by the user for access to subsequent applications unnecessary. Look for support by the BI access product with the preferred SSO product and entitlement store authentication method. In some cases, the BI access product’s native security method may be sufficient for security needs without requiring interface with an SSO product.
- Is any software other than industry leading browser required to be loaded on client PC (e.g., plug-in, applets, other) in order to access full capabilities of the product?
In this question, look for any requirement for software to be installed on the client PC beyond the native browser. Typically, these software plug-ins or applets are needed on the client PC to provide enhanced graphical, printing or product functionality capabilities. While the organization’s internal policy may permit download of plug-ins or applets from the Internet, external clients’, partners’, or other users’ own network security may prevent this type of transfer to occur to their internal PC’s. Additionally, the size and the amount of time to download the plug-in or applet should also be examined.
- Can the product components (web server, application server, database server, administration) be configured to use specific ports through a firewall?
Response to this question will indicate whether the BI access product was designed with the intention of being deployed on an Internet. If access through a firewall cannot be limited to a specific port or range of ports, many of the security advantages of having a firewall are diminished. Additionally, monitoring of firewall activity becomes more problematic.
- What levels of security are available through the BI access product?
In this question, it is important to determine whether the product’s security access levels are sufficient to meet the organization’s business and administration needs. For example, if the product will be deployed across the, the ability to delegate some level of administration authority to selected users in various business groups or departments may be a requirement for the BI product. This type of administrative delegation should be controlled by the central administrator or main super-user. This main administrator should be capable of controlling the amount of administrative rights each group administrator has available to them. The group administrator should be capable of controlling access for users in their specific groups(s) or department(s) only.
Additionally, the BI access product should provide security access not only at a user or group level but also down to row level. Unlike user or group security, which controls what content, reports or groups of reports a user can see through the BI access product, row level security allows control of what data is presented through the same report for two different users. Typically this is accomplished through information stored in the security metadata layer of the BI product which is used to customize the WHERE clause in the SQL that is generated to run the report for the specific user. For example, managers A & B run the same report option through the BI access product, but with row level security the information provided to each manager is specific to them because the data was filtered to meet their security profile.
- What methods are available with the product to manage migration of projects, groups or reports, or single reports through development life cycles (development, quality assurance, user acceptance test, and production)?
This question addresses an area that is typically lacking in most BI products areas, migration. Has the vendor provided utilities, products, or methods for migrating source components across environments? Do any of the vendor’s migration methods involve use of file transfer protocol (FTP)? Many companies use secure copy (SCP) to replace FTP. What are the vendor’s best practices for migration of entire builds, projects, group of reports, or single reports through the development lifecycle? Can the organization’s software migration product work with the BI product? Has the vendor considered migration of source components between environments, or simply left this to the administrator to determine? These are just some of the considerations to examine when reviewing the vendor’s response to this question. Administration of source components through a BI access tool can be very labor-intensive and costly if it has not been addressed adequately by the product’s vendor.
Another related question: can multiple copies of the product be installed on the same server? This type of scenario is most typical when establishing development and quality assurance (QA) environments. Budget constraints may require both these environments be located on the same server. Ensure that two or more copies of the product can be easily and successfully installed on the same server, not just the ability to separate development and QA environments. This distinction is important for when new releases or patches of the product are released. This will allow testing of the vendor’s new software against development, or maybe another test environment, before committing to QA.
- How does the BI access product support failover if an application server for the product goes down?
This question is optional, and depends on whether business requirements dictate a high availability due to criticality of the information, client business needs, or to meet other service level agreements. This question assumes an infrastructure is supporting redundant web servers, application servers, DBMS servers and possibly load balancers to support high availability (See figure 1). The vendor’s response to this question will provide an indication of how well the product was designed for Internet deployment for mission critical information.
Some considerations to examine in the vendor’s response include the method for session re-establishment after failover to another application server. Does the user need to re-authenticate and start their session over from the beginning? How is session information (customizations, file saving, views, etc.) shared between the BI access product’s application servers? In some company’s installations, the administrator for network security may not accept the method of information sharing between application servers due to perceived risk in security. For example, UNIX application servers sometimes use a file sharing method called network file system/remote procedure call (NFS/RPC) to synchronize files/directories between servers. Many network administrators consider RPC a security risk in an Internet environment due to its perceived vulnerability to be hacked. If the vendor’s solution for file sharing between application servers includes use of RPC and company’s polices restrict its use, alternative file sharing methods may need to be explored to deploy the product.
Finally, the BI access product may require installation of software on each of the web servers in order to facilitate failover. The functionality of the software installed on each of the web servers must be evaluated from a security perspective to ensure compliance with the company’s Internet polices. Also, review what, if any, persistent data is populated on the web servers for security or confidentially risk. Any data that is stored on the web servers should be considered compromised due to its close proximity to the Internet.
- How does the BI access product support load balancing in an Internet environment?*
This question is optional, based on business needs that require support of high scalability and performance. Considerations include if and then how the product supports balancing of requests across multiple application servers during periods of increased traffic. The methods used for load balancing must be reviewed for compatibility with security, communication, middleware, web server, and application server standards. Requirements for a particular web server’s applications or application servers may make the product incompatible.
The BI access product may require installation of software on each of the web servers to facilitate load balancing. The functionality of the software installed on each of the web servers must be evaluated from an Internet security perspective.
- What single points of failure exist with the BI access product when deployed for failover?
In this question, look for potential point of failures in deployment of the product that may not be covered under a failover implementation, or may require a hardware solution such as clustering. Look at each component in the implementation to make sure it is covered during a failover operation (e.g., proprietary DBMS, file system sharing, content directory, user personalization setting, etc.). The objective would be to have an automatic failover that is as seamless and undisruptive to the user as possible.
- What data encryption methods are available through the product offering for authentication and component communication?
Response to this question will indicate whether the BI access product was designed with the intention of being deployed through the Internet. Typically, BI access products support Secure Socket Layer (SSL), which is a common encryption protocol for transmitting confidential information across the Internet. Beyond authentication, product support encryption of information between its components should also be determined to review any potential risks.
Use of these twelve questions when evaluating a BI access product for Internet deployment can help avoid many costly obstacles and commonly encountered issues.