5

I have been involved in a discussion about the use of a standard user name and password within a development environment and would appreciate comments:

The single development server holds a number of linux-based database and Web servers - one pair per customer project. There's a single instance of PostgreSQL holding multiple customer tables, and a single Web server (Apache or NGINX) hosting multiple Web front-ends. The data in each customer database table is obfuscated and anonymised and the Web front ends for each customer are associated with a specific database table to make up a working site. This entire setup is only available to in-house devs and also to a third-party testing company via a secure VPN. At the end of development, the site database structure and Web customisation is moved to a separate customer-facing platform and loaded with real data for the customer to test. These new platforms are always built from scratch and no development user names or passwords are transferred.

On the in-house development platform, the devs want to use a common user login/password for the Web sites, and ditto for the database accounts and linux root user, arguing that this makes life easier as they move from site-to-site during development and there is no customer-sensitive data anyway.

At a simple level, having one set of accounts for everything makes life easier, but how would this go down against formal (UK) infosec standards, and other standards such as ISO27001? Can the use case and environment make this acceptable, or would this go against the grain of formal or informal guidelines that you should have unique account details for all accounts you manage and never share passwords?

In other words, how would this setup be viewed by a formal security audit?

Thanks

Linker3000
  • 151
  • 3

1 Answers1

1

While they may be difficult to avoid, shared accounts are generally a bad idea for information security and are not looked kindly on by ISO27001 or security auditors.

Shared accounts make it difficult to create a proper audit trail, as actions cannot be directly linked with a real person. There are, however, ways to get around this, for example by implementing a tool to manage and track the use of the credentials.