By i-confidential Technical Delivery Team
Creating a website has never been simpler, and we are bombarded with enticing offers:
“Build fast!”
“Build cheaper!”
“Scale with ease!”
“Migrate your application!”
And all done in this magical place called The Cloud…
Some of these messages reach colleagues who are responsible for building and deploying hosted applications – they need some of the ‘cheaper and faster’ features. Put off by less agile internal project practices, they will be tempted to jump ship and build something hosted elsewhere.
The functionality and design of web-based applications come in all shapes and sizes. For example, they may service mission-critical customer transactions, or offer back-office functions to do information ‘heavy lifting’. What they all have in common is that some employees will need privileged access to the data. This access may be for customer support, managing the application configuration, or for manipulating the data in some way. The management of this access is important because it can get very messy!
Just how messy depends on the way an application is built, its user access model, and its capability. Ideally, access will always be granted and managed from the client side, using client credentials on client infrastructure. This might mean some sort of federated or single sign-on access, where the client credentials are trusted by the hosted application. Such an approach ensures client data loss controls, such as end-point security, will always be present.
It gets messy, however (and often quietly buried away), when access to applications and data is granted via the host’s user access model. Staff will be provisioned with third-party credentials that are only as good as that third party’s access management and joiners, movers, and leavers (JML) process.
You lose control at this point.
It may well be that access is also possible from any device, including personal ones. Scary things can then happen. Staff might access data from their own device outside your network, and retain that access after leaving the organisation because nobody realised they had it in the first place.
So, if a third-party solution can’t integrate data access using your organisation’s existing process, make sure you work with them to build and integrate the key controls.
It all starts with a JML process that should cover the basic mapping of roles to the access required. To get this right, the third party will need a feed of the users you want set up and managed.
Recertification will ensure there is a regular review of the access an employee needs to the website and associated data.
Finally, monitoring must be designed, specified, and implemented by the third party. This is to ensure management information (MI) and alerts are provided to detect and address unusual access and activity. It’s important to note that these last two requirements are traditionally hard for the commissioning organisation to understand and implement effectively. Fixing this in retrospect, however, is beyond painful!
Creating the functionality to provide user access data and MI will inevitably increase costs, as will adding to business processes on the client side. It is therefore vital to build these requirements into the overall business case.
This is absolutely a price worth paying in the long run. The alternative is remediating these gaps in the future, which is a hard lesson to learn, and not one any organisation would likely wish to repeat.
תגובות