Mikhail Kader - Можно ли обеспечить безопасность облачных вычислений? #uisgcon9
1 like915 views
Документ обсуждает безопасность облачных вычислений, описывая различные типы облаков (публичные, гибридные, частные) и связанные с ними риски и меры безопасности. Основное внимание уделяется информационной безопасности, включая сохранение конфиденциальности, целостности и доступности данных, а также важным аспектам compliance и правовым требованиям. В заключение предлагаются стратегии оценки и выбора облачного провайдера с акцентом на управление рисками и обеспечение непрерывности бизнеса.
Mikhail Kader - Можно ли обеспечить безопасность облачных вычислений? #uisgcon9
- 1. Можно ли обеспечить безопасность облачных вычислений? Михаил Кадер, mkader@cisco.com
- 2. У меня нет задачи остановить переход к облачным облакам – мы сами их используем повсеместно Cisco является одним из крупнейших в мире пользователей облачных услуг Число CSP (400+) Sales Finance Manfacturing C&C Platform CDO Consumer IT Customer Service HR Acquisitions 2
- 4. Три основных типа облака Публичное Гибридное Частное
- 5. Составные части любого типа облака Арендаторы Энергоснабжение Сервисы Сеть Потребители Сервисы Сервисы IaaS PaaS SaaS Согласование (orchestration) Хранение Сервисы Облачные сервисы Облачные вычисления Виртуализция Железо ПО 5
- 6. SaaS - наиболее популярная облачная модель IaaS • Хранение • Вычисления • Управление сервисами • Сеть, безопасность… PaaS • Бизнес-аналитика • Интеграция • Разработка и тестирование • Базы данных SaaS • • • • • • • • • • • Биллинг Финансы Продажи CRM Продуктивность сотрудников HRM Управление контентом Унифицированные коммуникации Социальные сети Резервные копии Управление документами
- 7. Ключевые риски при переходе к облакам • • • • • • • • Сетевая доступность Жизнеспособность (устойчивость) Непрерывность бизнеса и восстановление после сбоев Инциденты безопасности Прозрачность облачного провайдера Потеря физического контроля Новые риски и уязвимости Соответствие требованиям
- 9. Что такое информационная безопасность? • Сохранение конфиденциальности, целостности и доступности информации. Кроме того, также могут быть включены другие свойства, такие как аутентичность, подотчетность, неотказуемость и надежность – ГОСТ Р ИСО/МЭК 27002 • Цель информационной безопасности заключается в защите информации и информационных систем от несанкционированного доступа, использования, раскрытия, перебоев, изменения или уничтожения
- 10. За счет чего достигается информационная безопасность? • Информационная безопасность включает в себя – – – – – – – – – – – Политика в области защиты Организация защиты информации Менеджмент активов Защита человеческих ресурсов Физическая безопасность и безопасность окружения Управление средствами связи и операциями Управление доступом Приобретение, разработка и поддержание в рабочем состоянии ИС Управление инцидентами Менеджмент непрерывности Соответствие требованиям
- 12. На каком уровне вы способны обеспечивать безопасность в своей корпоративной сети уже сейчас? • Вы можете гарантировать отсутствие закладок на аппаратном уровне? • Вы защищаете и внутреннюю сеть или только периметр? • Как у вас обстоит дело с защитой виртуализации? А SDN вы не внедряли еще? • Вы знаете механизмы защиты своих операционных систем? А вы их используете? • А механизмы защиты своих приложений вы знаете? А используете? • А данные у вас классифицированы?
- 13. Разные возможности по реализации системы защиты для разных сервисных моделей Провайдер Данные ОС/Приложения Данные Заказчик Заказчик Приложения VMs/Containers Провайдер Провайдер IaaS PaaS SaaS • В зависимости от архитектуры облака часть функций защиты может решать сам потребитель самостоятельно
- 14. Типы облачных моделей и средства защиты IaaS • Заказчик облачных услуг может использовать любые средства защиты, устанавливаемые на предоставляемую аппаратную платформу PaaS • Заказчик облачных услуг привязан к предоставляемой платформе • Выбор СЗИ (особенно сертифицированных) ограничен и, как правило, лежит на облачном провайдере • Заказчик может настраивать функции защиты приложений • Компромисс между средствами защиты и облачными услугами SaaS • Заказчик облачных услуг не имеет возможности по выбору средств и механизмов защиты облака • Выбор лежит на облачном провайдере
- 15. Особенности защиты IaaS Защитная мера Нюансы реализации (з / о) Политика в области защиты 50 / 50 Организация защиты информации 50 / 50 Менеджмент активов 50 / 50 Защита человеческих ресурсов 30 / 70 Физическая безопасность и безопасность окружения 0 / 100 Управление средствами связи и операциями 35 / 65 Управление доступом 60 / 40 Приобретение, разработка и поддержание в рабочем состоянии ИС 60 / 40 Управление инцидентами 60 / 40 Менеджмент непрерывности 30 / 70 Соответствие требованиям 70 / 30
- 16. Защита IaaS: обратите внимание • Ограничения на установку определенных средств защиты в инфраструктуру облачного провайдера • Возможность установки собственных средств шифрования • Экспорт/Импорт средств шифрования • Обслуживание (замена) вышедших из строя средств защиты, особенно средств шифрования • Защита данных при доступе с мобильных устройств – Особенно в контексте шифрования трафика
- 17. Особенности защиты PaaS Защитная мера Нюансы реализации (з / о) Политика в области защиты 30 / 70 Организация защиты информации 30 / 70 Менеджмент активов 30 / 70 Защита человеческих ресурсов 20 / 80 Физическая безопасность и безопасность окружения 0 / 100 Управление средствами связи и операциями 20 / 80 Управление доступом 30 / 70 Приобретение, разработка и поддержание в рабочем состоянии ИС 50 / 50 Управление инцидентами 45 / 55 Менеджмент непрерывности 20 / 80 Соответствие требованиям 55 / 45
- 18. Защита PaaS: обратите внимание • Насколько модель угроз и стандарты защиты облачного провайдера соответствуют вашим? – Возможно ли привести их к общему знаменателю?
- 19. Особенности защиты SaaS Защитная мера Нюансы реализации (з / о) Политика в области защиты 10 / 90 Организация защиты информации 5 / 95 Менеджмент активов 5 / 95 Защита человеческих ресурсов 5 / 95 Физическая безопасность и безопасность окружения 0 / 100 Управление средствами связи и операциями 0 / 100 Управление доступом 5 / 95 Приобретение, разработка и поддержание в рабочем состоянии ИС 0 / 100 Управление инцидентами 5 / 95 Менеджмент непрерывности 0 / 100 Соответствие требованиям 5 / 95
- 20. Защита SaaS: обратите внимание • Насколько модель угроз и стандарты защиты облачного провайдера соответствуют вашим? – Возможно ли привести их к общему знаменателю? • Как вообще вы можете повлиять на реализацию и эксплуатацию системы ИБ у облачного провайдера?
- 21. Типы облаков с точки зрения ИБ и compliance Частное • Управляется организацией или третьим лицом • Обеспечение безопасности легко реализуемо • Вопросы законодательного регулирования легко решаемы Публичное (локальное) • Управляется одним юридическим лицом • Обеспечение безопасности реализуемо средними усилиями • Вопросы законодательного регулирования решаемы средними усилиями Публичное (глобальное) • Управляется множеством юридических лиц • Требования по безопасности различаются в разных странах • Законодательные требования различаются в разных странах
- 23. Возможности по контролю изменчивы Инсорсинг Гибридное Внешнее Публичное Внутреннее Аутсорсинг Возможности по контролю меняются в зависимости от вида эксплуатации, расположения и типа облака Сообщество Частное 23
- 24. В публичном облаке меньше контроля Частное облако Публичное облако Соответствие Предприятие Облачный провайдер Governance Предприятие Облачный провайдер Безопасность Предприятие Облачный провайдер Эксплуатация Предприятие Облачный провайдер Риски Предприятие Распределены между предприятием и облачным провайдером Владелец облака Предприятие или арендодатель Облачный провайдер Использование ограничено Предприятием Ничем 24
- 25. НЕ ЗАБУДЬТЕ И ПРО ДРУГИЕ ВОПРОСЫ
- 26. Обратите внимание и на другие вопросы • Облачный провайдер обязан предоставить доступ спецслужбам, правоохранительным и судебным органам по мотивированному (или немотивированному) запросу – А иногда облачный провайдер и не будет знать, что такой доступ имеется – А вас он не обязан ставить в известность о таком доступе • Контроль облачного провайдера – Вам придется переориентироваться с собственной защиты на контроль чужой защиты – На каком языке вы будете общаться с зарубежным облачным провайдером? • Предоставление услуг по защите информации – это лицензируемый вид деятельности – У облачного провайдера есть лицензии на деятельность по защите информации?
- 27. Изменение парадигмы ИБ регуляторов при переходе в публичное облако Один объект = один субъект Один объект = множество субъектов • Защищать надо не только отдельных субъектов, но и взаимодействие между ними • С учетом отсутствия контролируемой зоны и динамической модели предоставления сервиса
- 28. ТАК ЧТО ЖЕ ВСЕ-ТАКИ ДЕЛАТЬ?
- 29. Если вы решились (или решили за вас) • Стратегия безопасности облачных вычислений – – – – – – – – Пересмотрите свой взгляд на понятие «периметра ИБ» Оцените риски – стратегические, операционные, юридические Сформируйте модель угроз Сформулируйте требования по безопасности Пересмотрите собственные процессы обеспечения ИБ Проведите обучение пользователей Продумайте процедуры контроля облачного провайдера Юридическая проработка взаимодействия с облачным провайдером • Стратегия выбора аутсорсера – Чеклист оценки ИБ облачного провайдера
- 30. Cisco Cloud Risk Assessment Framework R1: Data Risk and Accountability R2: User Identity R3: Regulatory Compliance R4: Business Continuity & Resiliency R5: User Privacy & Secondary Usage of Data R6: Service & Data Integration R7: Multitenancy & Physical Security R8: Incident Analysis & Forensics R9: Infrastructure Security R10: Nonproduction Environment Exposure 30
- 31. Чеклист выбора облачного провайдера с точки зрения ИБ • • • • • • • • • • • • • Защита данных и обеспечение privacy Управление уязвимостями Управление identity Объектовая охрана и персонал Доступность и производительность Безопасность приложений Управление инцидентами Непрерывность бизнеса и восстановление после катастроф Ведение журналов регистрации (eDiscovery) Сompliance Финансовые гарантии Завершение контракта Интеллектуальная собственность
- 32. Защита данных: вопрос №1 • Как мои данные отделены от данных других клиентов? • Где хранятся мои данные? • Как обеспечивается конфиденциальность и целостность моих данных? • Как осуществляется контроль доступа к моим данным? • Как данные защищаются при передаче от меня к облачному провайдеру? • Как данные защищаются при передаче от одной площадки облачного провайдера до другой? • Реализованы ли меры по контролю утечек данных? • Может ли третья сторона получить доступ к моим данным? Как? – Оператор связи, аутсорсер облачного провайдера, силовики • Все ли мои данные удаляются по завершении предоставления сервиса?
- 33. Пример Cisco: Какие данные и куда вы хотите передавать? Данные Cisco или клиентов? Чьи данные передаются? Cisco или клиентов/партнеров? Данные какой классификации (грифов) Классификация данных будут отдаваться в облако? Размещение данных Где физически/географически будут размещены данные в облаке? Потоки данных Использование схем потоков данных (если нужно) Регуляторика Передаваемые данные (например, ПДн) подпадают под регуляторные требования? Данные клиентов Тоже самое для данных клиентов 33
- 34. Privacy • Обезличивание критичных данных и предоставление к ним доступа только авторизованному персоналу • Какие данные собираются о заказчике? – Где хранятся? Как? Как долго? • Какие условия передачи данных клиента третьим лицам? – Законодательство о правоохранительных органах, адвокатские запросы и т.п. • Гарантии нераскрытия информации третьим лицам и третьими лицами?
- 35. Доступность • Обеспечиваемый уровень доступности в SLA – Сколько девяток? • Какие меры обеспечения доступности используются для защиты от угроз и ошибок? – Резервный оператор связи – Резервная площадка – Защита от DDoS • Какие доказательства высокой доступности облачного провайдера могут быть представлены? – Результаты независимого аудита • План действий во время простоя • Пиковые нагрузки и возможность облачного провайдера справляться с ними • Уровень сертификации ЦОД облачного провайдера
- 37. Что такое 99,95% доступности? • • • • • • • 365 дней = 8760 часов 100% = 0 часов простоя 99,999% ≈ 7 минут простоя 99,99% ≈ 55 минут простоя 99,95% ≈ 4,4 часа простоя 99,9% ≈ 9 часов простоя 99% ≈ 87 часов простоя • Просто умножьте время простоя на ваши доходы – Это приемлемо? • Уточните, провайдер учитывает только простой или еще время восстановления
- 38. Пример Cisco: уровни критичности сервисов C-Level Term Impact Description C1 Mission Imperative Any outage results in immediate cessation of a primary function, equivalent to immediate and critical impact to revenue generation, brand name and/or customer satisfaction; no downtime is acceptable under any circumstances C2 Mission Critical Any outage results in immediate cessation of a primary function, equivalent to major impact to revenue generation, brand name and/or customer satisfaction C3 Business Critical Any outage results in cessation over time or an immediate reduction of a primary function, equivalent to minor impact to revenue generation, brand name and/or customer satisfaction C4 Business Operational A sustained outage results in cessation or reduction of a primary function C5 Business Administrative A sustained outage has little to no impact on a primary function 38
- 39. Пример Cisco: матрица доступности сервисов по уровням критичности Criticality Classification Matrix v3.0 Operational Continuity (Planned and Unplanned Downtime) Adjusted Availabilit y Ceiling Planned Downtime Acceptabl e? Acceptable Recovery Time (ART, hours) Up to 99.999% N ~0 Disaster Recovery Reduced Acceptable Performance Data Loss Acceptable (ADL, (Single DC Hours) Loss)? ~0 N Recovery Time Objective (RTO, in Hours) Recovery Point Objective (RPO, in Hours) Reduced Performance Acceptable (Large-Scale Disaster)? Criticalit y Level n/a** n/a n/a C1 Distrib -ution < 5% Up to 99.995% N 1 0 N 4 1 N C2 Up to 99.99% Y 4 0 N 24 1 Y C3 ~10% Up to 99.9% Y 24 1 Y 48 24 Y C4 > 60% Up to 99.9% Y Best Effort 24 Y Best Effort 1 wk Y C5 < 25% • ART = Maximum downtime following incidents (up to and including one DC in Metro down) • ADL = Maximum data loss following incidents (up to and including one DC in Metro down) • RTO = Maximum downtime for applications following large-scale disaster (multiple Tier-III DCs in Metro down, highly unlikely) • RPO = Maximum data loss following large-scale disaster (multiple Tier-III DCs in Metro down, highly unlikely) ** Targeting distributed architectures (active/active over large distance) to meet service continuity requirements without DR invocation 39
- 40. Непрерывность бизнеса • План обеспечения непрерывности бизнеса и восстановления после катастроф • Есть ли у вас резервный ЦОД, если облачный провайдер уйдет в небытие? – Или вы решите не продлевать с ним договор на оказание облачных услуг – Или к облачному провайдеру нагрянут «маски-шоу» • Проходил ли облачный провайдер внешний аудит по непрерывности бизнеса? – Есть ли сертифицированные сотрудники по непрерывности бизнеса?
- 41. Управление identity • Возможна ли интеграция с моим каталогом учетных записей? Каким образом? • Если у облачного провайдера собственная база учетных записей, то – Как она защищается? – Как осуществляется управление учетными записями? • Поддерживается ли SSO? Какой стандарт? • Поддерживается ли федеративная система аутентификации? Какой стандарт?
- 42. Пример Cisco: идентификация и аутентификация пользователей SAML Решение 1. Federated Identity 2. OAuth для интеграции с backend API Identity Federation 42
- 43. Безопасность приложений • Исполнение рекомендаций OWASP при разработке приложений • Процедура тестирования для внешних приложений и исходного кода – По ряду нормативных актов это может стать обязательной нормой • Существуют ли приложения третьих фирм при оказании сервиса? • Используемые меры защиты приложений – Web Application Firewall – Database Firewall – Аудит БД
- 44. Управление уязвимостями • Как часто сканируется сеть и приложения? – Попадает ли облачный провайдер под требования PCI DSS и ежеквартального сканирования со стороны ASV? • Может ли заказчик осуществить внешнее сканирование сети облачного провайдера с целью контроля его защищенности? На каких условиях? • Каков процесс (и SLA) устранения уязвимостей?
- 45. Управление инцидентами • План реагирования на инциденты – Включая метрики оценки эффективности • Взаимосвязь вашей политики управления инцидентами и облачного провайдера – Особенно для зарубежных облачных провайдеров, находящихся в другом часовом поясе • Сотрудники облачного провайдера говорят на вашем родном языке? – При оперативном реагировании на инциденты времени искать переводчика не будет
- 46. Журналы регистрации • Как облачный провайдер обеспечивает сбор доказательств несанкционированной деятельности? • Как долго облачный провайдер хранит логи? Возможно ли увеличение этого срока? • Можно ли организовать хранение логов во внешнем хранилище? Как?
- 47. Объектовая охрана и персонал • Контроль доступа на территорию облачного провайдера осуществляется в режиме 24х7? • Выделенная инфраструктура или разделяемая с другими компаниями? • Регистрируется ли доступ персонала к данным клиентов? • Есть ли результаты оценки внешнего аудита? • Какова процедура набора персонала?
- 48. Законодательный compliance: пока есть вопросы • Защита конфиденциальной информации – – – – Обеспечение конфиденциальности Уведомление о фактах утечки Оказание услуг в области шифрования Деятельность по технической защите конфиденциальной информации – Обеспечение безопасности • • • • • Защита прав субъектов персональных данных Защита государственных информационных ресурсов Защита банковской тайны Обеспечение СОРМ Сбор и хранение данных для судебных разбирательств (eDiscovery) • Юрисдикция и ответственность
- 49. Виды защищаемой информации • 65 видов тайн в российском законодательстве • Персональные данные • Коммерческая тайна • Банковская тайна • Тайна переписки • Инсайдерская информация • …
- 50. Юрисдикция или кому подчиняется ваше облако? • Американские компании, действующие на территории других стран остаются подотчетными американскому законодательству и требованиям американских регуляторов – Американские регуляторы могут затребовать любые данные у американского облачного провайдера (Google, Oracle, Microsoft/Skype и т.д.) без согласования с пользователем облачных услуг
- 51. Кому будут принадлежать права на информационные ресурсы? • Кому принадлежат права на информацию, переданную облачному провайдеру? – – – – А на резервные копии? А на реплицированные данные? А на логи? А на приложения? • Удостоверьтесь, что ваш контракт не приводит к потере прав на информацию и иные ресурсы, переданные облачному провайдеру
- 52. Интеллектуальная собственность • Какие виды интеллектуальной собственности могут обрабатываться в облаке? – – – – – Приложения (программы для ЭВМ) и базы данных Телевизионное вещание (IPTV) Секреты производства (ноу-хау) Промышленная собственность (изобретения и т.п.) Средства индивидуализации (товарные знаки и т.п.) • Что с защитой интеллектуальной собственности? – А она у вас оценена? • Введен ли режим коммерческой тайны для секретов производства? – Если режим защиты КТ сложно ввести у себя на предприятии, то как его ввести на чужом предприятии?
- 53. Финансовые гарантии • Какая компенсация подразумевается в случае инцидента безопасности или нарушения SLA? – – – – Процент от упущенной выгоды Процент от заработка за время простоя Процент от стоимости утекшей информации Процент от суммы договора на оказание облачных услуг
- 54. Ключевой вопрос: как контролировать облачного провайдера? • Как проконтролировать выполнение защитных мер в облаке? – Заказчик вынужден требовать от исполнителя некоторых гарантий, которые позволят ему выполнять свои обязанности в части внутреннего контроля над информационными потоками • Кто у заказчика будет осуществлять мониторинг и контроль облачного провайдера? • Есть ли регламенты, процедуры и инструменты? • Как получить доступ и проверить провайдера облачных услуг, находящегося заграницей?
- 55. И НЕМНОГО О ТЕХНИКЕ …
- 56. Что может существовать для защиты облака? Облачные сетевые сервисы Виртуализованный / облачный ЦОД Виртуальный маршрутизато Citrix р Cloud NetScaler Services Router VPX 1000V Серверы Маршрутизат ор WAN Пользователь А Виртуальный Облачный шлюз МодульМСЭ ASA 1000V безопасности Cloud анализа Cisco VCG Firewall сети Imperva SecureSphere WAF (vNAM) vWAAS Коммутаторы Зона A Зона B Физическая инфраструктура vPath Nexus 1000V VXLAN Поддержка нескольких гипервизоров (VMware, Microsoft*, RedHat*, Citrix*) Nexus 1000V (Рспр. виртуальный коммутатор) VSG vWAAS ASA 1000V (МСЭ на основе зон) (Облачный МСЭ) • Распределенный коммутатор • Управление уровня ВМ • Согласованность NX-OS • МСЭ на основе зон • МСЭ периметра, VPN • Анализ протоколов (Оптимизация глобальных беспроводных сетей) CSR 1000V Модуль vNAM (маршрутизатор Cloud Router) • Оптимизация WAN • Шлюз WAN уровня 3 • Трафик приложений • Маршрутизация и VPN Сервисы экосистемы (аналитика сети) • Мониторинг приложений (уровень 2–7) • Виртуальный экземпляр ADC Citrix NetScaler VPX • Оверлейная аналитика (OTV, VXLAN, FP**) • Веб-приложение МСЭ Imperva
- 57. ПОДВОДЯ ИТОГИ
- 58. Что все это значит для вас?! • Технически облако может быть эффективно защищено с помощью существующих технологий – Если вы знаете, что требовать • В настоящий момент вопросы законодательного регулирования облачных вычислений находятся только в начале своего развития – Если для вас это риски, то не закрывайте на них глаза – роль регуляторики в области ИБ возрастает очень сильно • При переходе в облака важна не сама защита (ее обеспечиваете не вы), а контроль • Ключевой вопрос – что прописано в договоре?!
- 59. security-request@cisco.com Благодарю вас за внимание BRKSEC-1065 © Cisco и (или) дочерние компании, 2011 г. Все права защищены. Общедоступная информация Cisco 59
Editor's Notes
- #37: http://aws.amazon.com/ec2-sla/
- #39: Cisco’s Resiliency Framework is a methodology for prioritizing IT Services and Applications for fail-over / recovery purposes.This framework is defined by 5 Criticality Levels – each describing the impact to the business when a service or application is not behaving as expected.In essence the criticality matrix consists of 5 tiers, starting with the most important or “mission imperative”, C1 business processes all the way down to non-mission critical “business adminstrative” C5 business processes. C1, C2 and C3 all have varying levels of revenue, brand and/or customer satisfaction impact, while C4 and C5 typically do not impact revenue, brand or customer satisfaction.The appropriate criticalities are assigned to each business process by the process owner(s) via a Business Impact Analysis (BIA). In addition to identifying the criticality of the business process, the BIA also lists the process dependencies, which include IT services or applications.
- #43: SAML – Security Assertion Markup LanguageSecurty makes people happy since the SSOExample: Recent LR
- #57: Transcript: So we're tracking that and what we're trying to bring to market to be able to enable our customers to be able to take advantage of these capabilities that virtualization gives us with over subscription and being able to reuse the capital investment. We need to be able to mimic the capabilities, like the visibility from the NAM or optimization services and protections that we have. And it's also an interesting problem as well because of the fact that we're not just-- it's a good point to bring this up to everyone now because we're now not just supporting VMware going forward in the very near future or virtualization, we're going to be supporting additional hypervisors, Microsoft Hyper-v, OpenStack and some of the other Red Hat Virtualization as well. So it's really important to make sure that we're up to speed in understanding the capability that we're bringing to the market to support the whole ecosystem and mimic the services in the virtual world and be able to offer a similar experience in the virtual world. Author's Original Notes: