Best Security Practices for N-Tier Architectures
by Lindsey Vereen
Over the past few years, data security has been migrating from the database layer toward the application/business logic layer. In a two-tiered environment, the presentation layer uses the authentication and authorization mechanism of the DBMS. “But now, in most architectures, data security is not a database layer’s job, but rather that of one of the application layers, says Anis Siddiqy, president and CEO of Technosoft Solutions, an offshore software development company focused on the health-care and finance industry. He says that there is no simple solution to provide data access accountability and data integrity with n-tier architectures.
In a world of ubiquitous connectivity, everything is driven by data. Web sites and n-tier applications store their data in relational databases. Some Web sites log every user action and use this information to tailor responses to user needs. Businesses are responsible for maintaining the security of all of the data that they capture. They need to log all the access to collected data.
“One would think that in today’s security-conscious era, we will be bringing a more active logging mechanism to guard data access,” says Siddiqy, who has been in the software industry since 1990. “However, the industry is moving in a direction where accountability of data access is given to a layer that is far away from where data actually resides.” Data integrity and confidentiality responsibilities are moving away from the DBMS toward business or application layers. “Since this upper layer is away from data, it cannot truly provide complete and accurate data access and manipulation information,” he says.
With this architecture, the DBMS cannot do data access logging accurately and completely because the DBMS doesn’t know who is actually accessing data. “If data is dispensed at a lower level and logging is done on an upper level, then there is no way that a true log of data access can be provided,” says Siddiqy.
Second, Java and other application servers don’t yet have all the data security tools they need. In the past, the DBMS took care of data security so that application servers would be primarily concerned with providing application object security. However, application servers are now trying to provide data security services as well, Siddiqy says, but it will take time to reinvent comparable data security services. With n-tier architectures, database access is restricted to a few generic user names and passwords, usually only a single one. “So all a person needs is this user name and password to be able to compromise data integrity of all application data,” he says. “If an organization selects to stay with an existing n-tier framework, then we recommend following a few best practices to reduce data integrity risks.”
The practices that Siddiqy suggests are designed to help DBMS vendors, application developers and application server vendors build the right data security tool and improve data security with application servers.
First, he says, application developers must think through the trade-offs among scalability, security and code maintainability and pick the right mix for their environment. “The ideal solution may not be a piece of art, but it may be what environment needs.”
Second, developers need to build security measures into databases. They need to intertwine triggers and so forth in their solutions so that they don’t completely depend on object security. “They need to use more DBMS security for data,” he says.
Third, he suggests keeping passwords secure and applying all password-related generic good practices.
Fourth, he says to keep passwords encrypted in all places, including soft configuration files. “A low-level encryption algorithm like TEA is much better than plain text,” he says.
Siddiqy has several other best practices to improve data security in n-tier architectures. He offers a more thorough treatment of security in n-tier architectures in an upcoming issue of Software Test & Performance magazine.
Over the past few years, data security has been migrating from the database layer toward the application/business logic layer. In a two-tiered environment, the presentation layer uses the authentication and authorization mechanism of the DBMS. “But now, in most architectures, data security is not a database layer’s job, but rather that of one of the application layers, says Anis Siddiqy, president and CEO of Technosoft Solutions, an offshore software development company focused on the health-care and finance industry. He says that there is no simple solution to provide data access accountability and data integrity with n-tier architectures.
In a world of ubiquitous connectivity, everything is driven by data. Web sites and n-tier applications store their data in relational databases. Some Web sites log every user action and use this information to tailor responses to user needs. Businesses are responsible for maintaining the security of all of the data that they capture. They need to log all the access to collected data.
“One would think that in today’s security-conscious era, we will be bringing a more active logging mechanism to guard data access,” says Siddiqy, who has been in the software industry since 1990. “However, the industry is moving in a direction where accountability of data access is given to a layer that is far away from where data actually resides.” Data integrity and confidentiality responsibilities are moving away from the DBMS toward business or application layers. “Since this upper layer is away from data, it cannot truly provide complete and accurate data access and manipulation information,” he says.
With this architecture, the DBMS cannot do data access logging accurately and completely because the DBMS doesn’t know who is actually accessing data. “If data is dispensed at a lower level and logging is done on an upper level, then there is no way that a true log of data access can be provided,” says Siddiqy.
Second, Java and other application servers don’t yet have all the data security tools they need. In the past, the DBMS took care of data security so that application servers would be primarily concerned with providing application object security. However, application servers are now trying to provide data security services as well, Siddiqy says, but it will take time to reinvent comparable data security services. With n-tier architectures, database access is restricted to a few generic user names and passwords, usually only a single one. “So all a person needs is this user name and password to be able to compromise data integrity of all application data,” he says. “If an organization selects to stay with an existing n-tier framework, then we recommend following a few best practices to reduce data integrity risks.”
The practices that Siddiqy suggests are designed to help DBMS vendors, application developers and application server vendors build the right data security tool and improve data security with application servers.
First, he says, application developers must think through the trade-offs among scalability, security and code maintainability and pick the right mix for their environment. “The ideal solution may not be a piece of art, but it may be what environment needs.”
Second, developers need to build security measures into databases. They need to intertwine triggers and so forth in their solutions so that they don’t completely depend on object security. “They need to use more DBMS security for data,” he says.
Third, he suggests keeping passwords secure and applying all password-related generic good practices.
Fourth, he says to keep passwords encrypted in all places, including soft configuration files. “A low-level encryption algorithm like TEA is much better than plain text,” he says.
Siddiqy has several other best practices to improve data security in n-tier architectures. He offers a more thorough treatment of security in n-tier architectures in an upcoming issue of Software Test & Performance magazine.
posted by whoami at 1:04 AM
0 Comments:
Post a Comment
<< Home