Infrastructure Services are definitely undergoing a major transformation. How does one navigate the web of emerging technology trends and stay ahead of the game? Read on to learn more on our Infra Matters blog.

« June 2010 | Main | December 2010 »

October 22, 2010

Securing Virtual Desktop Environment - Part 2

As outlined in my previous blog, securing a VDI environment needs focused attention.

 

One of the key advantages to desktop virtualization is the ability to create on-demand dynamic desktops specific to the user's role within the organisation. The users are authenticated and connected to desktop sessions via a software component called Connection broker.

 

The way in which IT departments manage user identities, authenticate systems and enforce access policies across the corporate network, all need to be thought through in the context of a new VDI environment. Having a centralised point of management for user identities, access rights, IT policies and auditing is vitally important.

 

The connection broker controls the access permissions to specific desktop and applications. Organizations should have the capability to ensure that the Connection broker is not compromised, by making use of strong authentication factors, such as biometrics authentication, password or token, etc. This ensures that the employee logging in has the rights and permissions to access the virtual desktop.

 

Have you come across or defined any specific strategies for identify management for VDI.? Share your thoughts on this...

October 11, 2010

Too many cooks need a good head chef!

Let us imagine!

Imagine that you own a mall with a food court in it. Imagine that there are about 50 different stores catering to (no pun intended) different cuisines and a seating space of around 1500 people. Now let's look at a simple example: Imagine that each store has its own set of cutlery! Now let's look at the ramifications because of this simple example.

Each store will have to manage its own set of cutlery, whereas the seating space is shared between all the 50 stores! I will pause for a minute while you ponder about this scenario. (or should I say, a minute in silence!)

This is a perfect recipe (again, no pun intendedJ) for disaster. Each store would need to get its cutlery back, whereas the people could be seated in any of those 1500 available seats. This would basically mean that the food court would be littered with at least two people for each store, running around and collecting their respective cutlery and getting it back. I hope you get the flavor of the issue that I am talking about here! Since you are imagining, just imagine some 100 people running around with cutlery... I would say, also imagine one of them tripping and hitting another of them... Phew!

After all that commotion, let's imagine another scenario. What if you tell these stores that you will provide the cutlery and all these 50 stores should share the cutlery? There will be one washing area instead of 50, there would be one group of people going around, collecting the cutlery instead of 50 groups. The important point is not about having just one group instead of 50, it is that you can manage the food court and leave only the aspect of preparation of food to the stores.

What do you imagine? I can imagine a very well managed food court with customers satisfied with food as well as service. Isn't it what every organization strives for - Performance from its vendors and satisfaction to its customers?

Let's snap out of our reverie and think from an ITSM point of view. The above analogy is almost similar to what you can find in most organizations today. IT Services talk to multiple vendors for various parts of their Service delivery and operations. The biggest issue is - how to manage service levels of each of these vendors when each vendor would have separate set of parameters on which they would be basing their operations.

Given this 'food for thought' (you know that I don't intend puns!), we will discuss further on one of the solutions for these kinds of multi-vendor scenarios.