¿Cielos despejados o alerta meteorológica para los negocios?

1. Cloud Computing:¿Cielos despejados o alerta meteorológica para los negocios? Gabriel Marcos Product Manager – Datacenter, Security & Outsourcing Global Crossing Latin America

3. Public Cloud

4. Private Cloud

5. Modelos de Servicio

6. IaaS

7. PaaS

8. SaaS

9. Seguridad en lasnubes

10. Gestión del Riesgo

11. Desafíos

14. No existe un standard que lo defina. Las características son:

15. Escalabilidad sobre demanda

16. Infraestructura compartida (“multi-tenant”) :

17. Virtualización / Grid Computing / Clusters

18. Independencia de ubicaciones físicas

19. Precio por consumo

20. Delivery inmediato / Auto-provisioning

21. Reliability (“Confianza”) = Redundancia + Disponibilidad

27. F5 Networks: Cloud Computing Survey: June - July 2009

28. Resultados:

29. Public Cloud:

30. 51%: actualmente utilizándolo.

31. 18%: en implementación.

32. Principal interés: Eficiencia (77%)

33. Private Cloud:

34. 45%: actualmente utilizándolo.

35. 22%: en implementación.

36. Principal interés: Reducción de costos (63%)69% de adopción 67% de adopción

37. © 2009 – Global Crossing MODELOS DE Servicio

39. Aparecen también otros conceptos, como evolución o mezcla de los anteriores:

40. DaaS: Data as a Service

41. IPMaaS: Identity & Policy Management as a Service

42. NaaS: Network as a ServiceSaaS Software as a Service PaaS Platform as a Service IaaS Infrastructure as a Service

44. $0 CAPEX: sin infraestructura propia

45. Salaries&Wages: sin recursos humanos para administrar la infraestructura, sí para las aplicaciones, desarrollo y soporte

46. Se paga por el uso de la infraestructura: CPU, Memoria, Disco, Backup, Monitoreo, Seguridad, etc.

47. Ejemplos:

48. Virtual Hosting (www.globalcrossing.com)

49. GoGrid

50. CloudWorksCloud Enabler

52. $0 OPEX: sin licencias de software de base

53. Salaries&Wages: sin recursos humanos para administrar la infraestructura y las aplicaciones, sí para el desarrollo y el soporte

54. Se paga por el uso de la plataforma: requerimientos de hardware y software.

55. Ejemplos:

56. Force.com

57. Windows AzureCloud Enabler

59. $0 CAPEX: sin infraestructura propia

60. $0 OPEX: sin licencias

61. $0 Salaries&Wages: sin recursos humanos, excepto para el soporte

62. “Pay as you go”: se paga por el uso del software (cantidad de usuarios, transacciones)

63. Ejemplos:

64. Salesforce.com

65. Microsoft Live MeetingCloud Provider

66. Modelos de ServicioResumen Proveedor Proveedor Proveedor Cliente Cliente Cliente Proveedor Cliente Proveedor Cliente Hard. & Soft. Middleware Desarrollo Servicio Conectividad Protocolos Delivery Soporte SaaS: Software as a Service Proveedor Cliente PaaS: Platform as a Service Proveedor Cliente IaaS: Infrastructure as a Service Proveedor Cliente

67. © 2009 – Global Crossing SEGURIDAD EN LAS NUBES

69. No conocemos los procesos de gestión del proveedor

70. No tenemos acceso a la infraestructura

71. No podemos auditar el código

72. No analizamos logs de autenticación / autorización

73. No estamos monitoreando ningún componente de base

74. No conocemos a todos los usuarios

75. Resumiendo:

78. Cloud Computing:Identificar activos Los activos no son conocidos, solamente las interfases Identificar Amenazas Identificar Vulnerabilidades Medir riesgo Implementar controles

80. Cloud Computing:Los activos no son conocidos, solamente las interfaces Identificar activos Identificar Amenazas No se conocen ni se tiene acceso a la infraestructura ni a las ubicaciones físicas Identificar Vulnerabilidades Medir riesgo Implementar controles

82. Cloud Computing:Identificar activos Los activos no son conocidos, solamente las interfaces No se conocen ni se tiene acceso a la infraestructura ni a las ubicaciones físicas Identificar Amenazas Identificar Vulnerabilidades Solamente a través de las interfases, tanto las públicas como las privadas Medir riesgo Implementar controles

84. Cloud Computing:Identificar activos Los activos no son conocidos, solamente las interfaces Identificar Amenazas No se conocen ni se tiene acceso a la infraestructura ni a las ubicaciones físicas Identificar Vulnerabilidades Solamente a través de las interfases, tanto las públicas como las privadas Medir riesgo Desde el punto de vista del negocio, analizando el impacto de cada servicio Implementar controles

86. Cloud Computing:Identificar activos Los activos no son conocidos, solamente las interfaces Identificar Amenazas No se conocen ni se tiene acceso a la infraestructura ni a las ubicaciones físicas Identificar Vulnerabilidades Solamente a través de las interfases, tanto las públicas como las privadas Medir riesgo Desde el punto de vista del negocio, analizando el impacto de cada servicio Implementar controles Necesidad de nuevas metodologías…

87. © 2009 – Global Crossing DESAFIOS

89. (1) Amenazas y vulnerabilidades

90. (2) Aspectos regulatorios

91. (3) Confidencialidad

92. (4) Integridad

93. (5) Disponibilidad

94. (6) Evidencias de auditoriaNecesidad de delegar en el proveedor parte del proceso de Gestión del Riesgo.

96. PaaS: solicitud de registros de Auditoria Interna, Certificaciones, etc.

97. SaaS: evaluación recurrente de vulnerabilidades en las interfases.

98. Evaluación independiente de vulnerabilidades (Auditoria Interna): infraestructura, código fuente, interfases.

100. (1) Amenazas y vulnerabilidades

101. (2) Aspectos regulatorios

102. (3) Confidencialidad

103. (4) Integridad

104. (5) Disponibilidad

105. (6) Evidencias de auditoriaLeyes de protección de datos, locales a cada país, regulan los servicios de IT y compiten con el concepto de “ubicuidad”.

107. PaaS: independencia de la ubicación en el desarrollo, pero no en el procesamiento.

108. SaaS: integración del modelo de software del proveedor con la infraestructura local propia del cliente.

109. Interconectividad para soportar múltiples orígenes de datos.

110. Locación física de activos en cumplimiento con regulaciones locales.

112. (1) Amenazas y vulnerabilidades

113. (2) Aspectos regulatorios

114. (3) Confidencialidad

115. (4) Integridad

116. (5) Disponibilidad

117. (6) Evidencias de auditoria¿Quién tiene acceso a la información, y cómo se controla?

119. PaaS: mitigación de los riesgos a través de NDAs (acuerdos de confidencialidad) y seguros.

120. SaaS: utilización del modelo de servicios para aplicaciones no críticas.

121. Certificación de normas internacionales para aumentar el nivel de control y confianza.

122. Gestión integral del riesgo, incluyendo a clientes, empleados y terceros.

124. (1) Amenazas y vulnerabilidades

125. (2) Aspectos regulatorios

126. (3) Confidencialidad

127. (4) Integridad

128. (5) Disponibilidad

129. (6) Evidencias de auditoria¿Qué procesos y personas, desconocidas para el cliente, pueden modificar la información, y qué registros quedan?

131. PaaS: separación de ambientes y pruebas de concepto.

132. SaaS: análisis detallado de la integración de los servicios con la información crítica.

133. Implementación de herramientas centralizadas y mejores prácticas para control de acceso.

134. Reportes a medida para trazabilidad de accesos.

136. (1) Amenazas y vulnerabilidades

137. (2) Aspectos regulatorios

138. (3) Confidencialidad

139. (4) Integridad

140. (5) Disponibilidad

141. (6) Evidencias de auditoriaInfraestructura siempre disponible, entre muchas locaciones físicas.

143. PaaS: garantía de escalabilidad del software y del middleware.

144. SaaS: SLA con los principales parámetros de disponibilidad necesarios para el negocio.

145. Concepto “N+1” aplicado a todos los componentes de la arquitectura.

146. Formalización de las métricas de Disponibilidad en los SLAs.

148. (1) Amenazas y vulnerabilidades

149. (2) Aspectos regulatorios

150. (3) Confidencialidad

151. (4) Integridad

152. (5) Disponibilidad

153. (6) Evidencias de auditoria¿Cómo almacenar, filtrar y distribuir el gran volumen de información necesario para el cumplimiento regulatorio, de una infraestructura que no es propia?

155. PaaS: separación de ambientes de análisis y recolección de evidencias con la prestación del servicio.

156. SaaS: planificación de auditorias externas periódicas pautadas en el SLA.

157. Análisis detallado de la información necesaria para cada cliente, documentado en los SLA.

158. Dimensionamiento de la capacidad necesaria, bajo el mismo modelo de servicio.

161. Yankee Group Anywhere Enterprise: 2009 U.S. Transforming Infrastructure and Transforming Applications Survey

162. Resultados:

163. Principales motivaciones para usar SaaS:

164. 43%: ahorro de costos en infraestructura.

165. 29%: manejo eficiente de capacidades.

166. 23%: DisasterRecovery / Business Continuity.

167. Asignación del 50% del presupuesto en Cloud Computing:

168. Próximos 12 meses: 2% de Grandes Empresas / 7% PYMES

170. Mayor foco en el negocio de la organización (“Core Business”)

171. Generalmente, el proveedoresmásseguroque los clientes

172. Disminución del riesgo a través de SLAs “másrobustos”

173. Reducción de costoscomprobada

174. Amenazas:

175. Eliminación de la información: pocas garantías…

176. Inversión en certificaciones: riesgo de pérdida de valor

177. Governance: riesgo de ceder demasiado (“exceso de confianza”)