Molnleverantörers transparens
Den här säkerhetsbloggen har varit i molnet i ungefär 1,5 år nu. Molnet verkar vara, precis som Skynet, inevitable. Att köpa databehandling på samma sätt som man köper elektricitet, värme eller vatten attraherar många.
Den övergripande skillnaden är dock att du måste lita på din molnleverantör i mycket högre utsträckning. Visst, du måste också lita på att elleverantören inte tar betalt för mer el än de levererar och att vattenleverantören levererar rent vatten. Men om det skulle visa sig att de försöker blåsa dig så är ingen större skada skedd, be dem att fara åt skogen och byt till en ny leverantör. Mer eller mindre.
När en tredjepart sitter på dina hemligheter är det värre. Om de läcker så är den berömda katten ute ur säcken och går inte att stoppa tillbaka. Hur förtjänar du detta förtroende som molnleverantör?
Jag tror att svaret på det här är transparens. För att behålla förtroendet efter driftstörningar, intrång eller vad det kan röra sig om måste leverantören gå ut med detaljerad, sanningsenlig information till sina kunder. Ungefär som Amazon har gjort efter störningarna i EC2. Öppenheten borde inte heller begränsas till kunder, den borde riktas till allmänheten (eftersom de vill ha fler kunder). Ungefär som Amazon.
Nästa steg borde vara proaktiv transparens. "Så här fungerar vår tjänst, det är ingen hemlighet vad som gör oss bättre än konkurrenterna." Tänk om det kan bli slutet på glansiga whitepapers med svepande beskrivningar och varumärkesskyddade begrepp och början på meningsfulla, trovärdiga beskrivningar?
Från Amazons rapportering gillar jag särskilt:
The trigger for this event was a network configuration change. We will audit our change process and increase the automation to prevent this mistake from happening in the future. However, we focus on building software and services to survive failures. Much of the work that will come out of this event will be to further protect the EBS service in the face of a similar failure in the future. [betoning tillagd]
Det är ett enormt starkt koncept. En vis man sa: "do not make failure less likely, make failure less meaningful".
--
Stefan Pettersson
Den övergripande skillnaden är dock att du måste lita på din molnleverantör i mycket högre utsträckning. Visst, du måste också lita på att elleverantören inte tar betalt för mer el än de levererar och att vattenleverantören levererar rent vatten. Men om det skulle visa sig att de försöker blåsa dig så är ingen större skada skedd, be dem att fara åt skogen och byt till en ny leverantör. Mer eller mindre.
När en tredjepart sitter på dina hemligheter är det värre. Om de läcker så är den berömda katten ute ur säcken och går inte att stoppa tillbaka. Hur förtjänar du detta förtroende som molnleverantör?
Jag tror att svaret på det här är transparens. För att behålla förtroendet efter driftstörningar, intrång eller vad det kan röra sig om måste leverantören gå ut med detaljerad, sanningsenlig information till sina kunder. Ungefär som Amazon har gjort efter störningarna i EC2. Öppenheten borde inte heller begränsas till kunder, den borde riktas till allmänheten (eftersom de vill ha fler kunder). Ungefär som Amazon.
Nästa steg borde vara proaktiv transparens. "Så här fungerar vår tjänst, det är ingen hemlighet vad som gör oss bättre än konkurrenterna." Tänk om det kan bli slutet på glansiga whitepapers med svepande beskrivningar och varumärkesskyddade begrepp och början på meningsfulla, trovärdiga beskrivningar?
Från Amazons rapportering gillar jag särskilt:
The trigger for this event was a network configuration change. We will audit our change process and increase the automation to prevent this mistake from happening in the future. However, we focus on building software and services to survive failures. Much of the work that will come out of this event will be to further protect the EBS service in the face of a similar failure in the future. [betoning tillagd]
Det är ett enormt starkt koncept. En vis man sa: "do not make failure less likely, make failure less meaningful".
--
Stefan Pettersson
Kommentarer
Trackback
