Seguridad en los modelos operativos de nube
•Descargar como PPTX, PDF•
0 recomendaciones•649 vistas
Slides del IV Encuentro de Seguridad de la información en entidades financieras. Una visión de como adoptar un modelo operativo de nube con la participación del CISO desde el inicio.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Seguridad en los modelos operativos de nube
Similar a Seguridad en los modelos operativos de nube (20)
Último
Último (20)
Seguridad en los modelos operativos de nube
- 1. La seguridad en la operación de la nube (El CISO saliendo del banco de suplentes) Daniel S. Levi Director de Servicios de Datacenter @danielslevi - dlevi@perceptiongrp.com http://dlevi.com/BlogTechie
- 2. La nube en un slide (recapitulamos) PersonalizableControl Elasticidad Basado en UsoAuto Servicio Recursos Compartidos …y si es privada:
- 4. ITaaS: Maduración de IT end-to-end Flexibilidad y Elasticidad Tecnologías heterogéneas: Hipervisores, Sistemas Operativos, Dispositivos (Tablets, Smartphones), SANs, swichtes, etc.
- 5. Identificar Proteger DetectarResponder Recuperar Framework de mejora de Seguridad para infraestructura crítica http://www.nist.gov/cyberframework/
- 6. Identificar Proteger DetectarResponder Recuperar Framework de mejora de Seguridad para infraestructura crítica EN LA NUBE http://www.nist.gov/cyberframework/
- 7. Mis datos en la nube. Mi operación (o parte) en la nube.
- 8. La diferencia está en el alcance SaaS PaaS IaaS On-Premise Data Governance & Administración de riesgo. Endpoints del cliente Administración de cuentas y accesos Infraestructura de identidades Aplicaciones Controles de Red Sistema Operativo Hosts físicos Red física Infraestructura física del Centro de datos. Cliente Proveedor Compartido
- 9. ¿Por dónde suelen comenzar los problemas? • Usualmente todo comienza en un cliente (o servidor) mal administrado (ej. ¿cómo están implementadas las políticas de pen drives en tu empresa?) • Entonces, el siguiente paso es utilizar credenciales legítimas para acceder a la información.
- 10. Verizon Data Breach Report 2014 - “85% de las brechas fueron detectadas por terceros”
- 11. Compliance en 2014 de acuerdo a PCI 205 Cantidad de días promedio que toma a una organización detector la brecha de seguridad 80% 29% 64% 80% 0% Compañías que estaban en clumpimiento al momento de una brecha de Seguridad (sobre 10 años) De las compañías fallan en la evaluación interna (problemas de sostenimiento de controles) De las compañías están en situación de cumplimiento a menos de un año de la validación De las brechas de datos causada por errores humanos y problemas de sistemas Del ciber espionaje es dado a través de sistemas internos Fuente: PCI SSC
- 12. Del lado del proveedor… 27018 Artículo 29 (Unión Europea) Y, por supuesto, SDLC • Privacidad de los datos • Compliance • Seguridad de la información (general) • Seguridad en el workflow de contenidos (media) • Seguridad transaccional • Remoción de datos borrados en forma segura
- 13. ¡Pero son tus datos! • Sos el dueño y tenés el control de los mismos. • Pero tu proveedor está a cargo del servicio y no puede desentenderse. Transparencia Seguridad inherente al modelo de servicios Privacidad desde el diseño Cumplimiento continuo
- 14. Y en la práctica, ¿qué tengo que exigirle a mi proveedor? (algunos ejemplos) SLA (¡obvio!) IntegraciónconITaaS Tráfico Cómputo Almacenamiento • VPN • Encripción fuerte SSL/TLS entre todos los nodos del servicio (on-premise, proveedor 1, proveedor 2) • Cerrado por defecto. Endpoints internos vs endpoints externos • Yo defino qué sale y qué no a Internet (en entornos multicapa) Encripción de las máquinas virtuales. ¡Que el mecanismo sea aplicable fuera de la nube! • Encripción • Replicación • Repositorio de certificados para las funciones de seguridad.
- 15. Protección en los accesos Aislación Personal Tecnología • Mínima intervención humana (por seguridad y por necesidad –escala-) • Automatización con base de conocimiento • Contenido aislado de las operaciones • Autenticación multifactor • Cero acceso por defecto. • Múltiples niveles de aprobación (inclusive del cliente según el caso –SaaS-). • Accesos de menor privilegio. • Acceso just-in- time • Acceso sólo suficiente • Limitado en el tiempo
- 16. Desde tu punto de vista • La nube como una extensión del datacenter • Notación, mantenimiento, procesos. • Accesos con scripts en forma preferente al portal • ¿Por qué no segregación de suscripciones? • La nube como parte del ejercicio del DRP • ¿Quién monitorea el gasto mensual? ¿Quién los desvíos?
- 17. Es hora de que el CISO se ponga creativo Key: 040F:38AB:A6B2:4039:9AB2 Key: 1391:34AB:381B:C539:0028 Key: 3572:35AB:A982:4129:8DEA Key: 789A:4594:7AB6:7BBB:6373 Key: 9B53:4B42:C4DA:6AB9:1168 Key: 8904:6ABB:B62A:7393:8BCA
- 18. La seguridad en la operación de la nube (El CISO saliendo del banco de suplentes) Daniel S. Levi Director de Servicios de Datacenter @danielslevi - dlevi@perceptiongrp.com http://dlevi.com/BlogTechie
Notas del editor
- Goal: Frame how System Center 2012 (and SP1) deliver unified management for the Cloud OS. Talking Points Let’s discuss the capabilities required to deliver on our promise of unified management: <click> First, you need a “simple” self-service experience to enable your App Owners to specify their requirements. For example, let’s suppose they want to provision a SharePoint service with the following specs: 3 tier .NET architecture Has a set of configuration and deployment parameters to conform with (e.g. perf thresholds, scale out rules, update domains) Needs 99.95% availability SLA Adheres to compliance/security controls around SOX/HIPAA Need on-demand reporting on key availability metrics that track against SLA <click> Next, you need a way to understand the topology and architecture of the application service in question. An application deployed in on an abstracted, or cloud computing model is called a “service”. This would necessitate a “service model” that accurately binds the application’s architecture to the underlying resources where it will be hosted. The “service model” would be comprised of: Service definition information, deployed as “roles”. Roles are like DLLs, i.e. a collection of code with an entry point that runs in its own virtual machine Front end: e.g. load-balanced stateless web servers Middle worker tier: e.g. order processing, encoding Backend storage: e.g. SQL tables or files Service Configuration information Update domains Availability domains Scale out rules <click> You will need a set of process automation capabilities to break down this application provisioning request into the enterprise change requests that need to be implemented. This could include setting up the underlying infra and then a set of app configuration/release requests that need to be tracked (and ideally implemented with orchestrated automation) <click> Next you need a set of provisioning tools that actually configure and deploy the infra and application layers. <click> the underlying datacenter resources could be physical, virtual, private or public cloud as per the requirements dictated by the application’s service model <click> once the underlying infrastructure and application service are deployed, they would immediately need to be “discovered” and monitored for reporting and health tracking <click> There you see how the System Center 2012 components offer these life cycle management capabilities in combination to help you deliver on the Microsoft promise of unified Cloud OS management: App Controller would offer that self-service experience that allows your application owners manage their apps across on-premises, service provider and Windows Azure environments. Service Manager offers the standardized self-service catalog that defines “templates” for your applications and infrastructure. App Controller, Virtual Machine Manager, Service Manager and Operations Manager work together to maintain the service model through the application service life cycle Orchestrator and Service Manager offer orchestrated automation for the process workflows required to drive your provisioning and monitoring tools Virtual Machine Manager and Configuration manager can provision physical, virtual and cloud environments Operations Manager (AVIcode capabilities will be built into Operations Manager) monitors your application services end to end and offers deep app insight to help you deliver predictable SLA Your datacenter resources could be deployed anywhere from on-premises, service provider and Windows Azure However, to get to this agile self-service end-state, you will have to start with abstracting your infrastructure and allocating it appropriately so that your business units can deploy and manage their applications on top. Transition: So, how does System Center 2012 get you to this point where you can deliver unified management across cloud? These can really be categorized into three buckets: Application Management: Deploying and operating your business applications Service Delivery & Automation: Standardizing and automating service and resource provisioning, managing change and access controls, etc. Infrastructure management: Deploying and operating all the underlying infrastructure on which your business applications and services run.
- http://azure.microsoft.com/en-us/support/trust-center/compliance/