Showing posts with label SLA. Show all posts
Showing posts with label SLA. Show all posts

Friday, 7 December 2012

Security – in, from and with the Cloud

My post Security – in, from and with the Cloud on ITBusinessCloud

----------

Security – in, from and with the Cloud

Security is one of the hottest topics when it comes to obstacles of adopting cloud services. Maybe we theatrically should “tear this wall down”, de-dramatize it, without tearing the importance of good security down – because it is important!

One type?

No, there are several different types of security services related to cloud. Examples:

  1. Security within a cloud service which has another purpose than delivering security, for instance an email service. The security in this type of services is to protect your data from other people or systems, not being harmed by malware, backed up and the ability to be restored etc.
  2. Security as a Service delivered as a cloud service which you can adopt to your existing on-premise solution. Examples:
    • Encryption
    • SPAM and Malware protection
    • Firewalls
  3. Audit tools/services who will audit the vulnerability within, to and around your cloud service (No. 1 & 2 above).
  4. Consulting audit services. Pretty much like No. 3 but performed by humans and normally gives you a report how to act on a problem given by No. 3. 
This is on a high level what security in the cloud is about. No. 2, 3 and 4 normally works fine. People don’t fear security in services delivered from well-known security services providers. No. 2 might be a bit problematic to adapt to services delivered from other vendors but API’s, integration services and true co-op between CSP’s (Cloud Service Provider) will solve this better in the future. No. 1 is the wall needed to be de-dramatized and torn down…

Fear = out of your control

The highest obstacle to pass is

Friday, 15 June 2012

An SLA thread

I've mentioned this comment thread in an earlier post. @sarojkar (not a Twitter account) and I took it another round. The origin post is about how to write/offer a great SLA model to cloud services.

@sarojkar's answer to my Q; whether or not he/she meant a service chain SLA or full SLA for a service incl underlying parts/functions:
"What I mean say is that these items need to be discussed and put in paper as part of SLA. You don’t want to be in a situation where your provider is pointing a finger at the infrastructure issue or outage and saying it wasn’t their fault. Incorporate SLA terms that indicate how your company will perform based on these resources. What does it mean to your operations if the cloud is down?