РИФ 2016, Заоблачная безопасность: как обойти чужие...

Post on 12-Jan-2017

75 Views

Category:

Business

3 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Заоблачная безопасность:как обойти чужие грабли

Александр Демидов«1С-Битрикс»

Руководитель направления арендных решений

Битрикс24

• Зарегистрировано компаний: 1 000 000+

• Активных компаний: 105 000+

• 3000 сотрудников в максимальной компании

• 35 000 000 программных страниц в день

• 99,99% доступность сервиса

конфиденциальность целостность доступность

Кто наши «заклятые друзья»?

Хакеры?

Кто наши «заклятые друзья»?

Пользователи

Разработчики

Системные администраторы

Провайдеры

Государство

Хакеры?

Утечки и потери данных

Пользователи

Обязательно HTTPS

Ограничение доступа по IP

OTP

Разработчики

Никакого доступа на «бой»!

Полная изоляция данных пользователей

Нет единого хранилища логинов и паролей

WAF (in / out)

Файловая система (кроме временных директорий) – read only

Аудит кода

Тестирование всех обновлений

Будьте осторожны с зависимостямиот сторонних библиотек

Доверяй, но проверяй

Даже там, где совсем не ждешь подвоха…

Системные администраторы

Firewall – закрыто все, кроме необходимого

Администрирование –только из офисных сетей

chroot

Real-time мониторинг изменений в FS

Real-time мониторингзагружаемых файлов

noexec на временных директориях

Мониторинг security updates

Тестирование всех обновлений

«Одноклассники» 4-6 апреля 2013

2.1 млрд. просмотров в сутки до сбоя

1.6 млрд. – в среднем в неделю сбоя

1.9 млрд. – после сбоя

http://corp.mail.ru/adv/price_odnoklassniki.htm

"Испорченный файл был выложен через централизованную систему управления серверами. В итоге это повлекло за собой необходимость перезапуска большой части наших серверов и переустановку операционной системы", — заявила пресс-секретарь "Одноклассников" Мария Лапук

Внутренний аудит

Внешний аудит

Целостность

Пользователи

Разработчики

Системные администраторы

Провайдеры

Все те же «враги»…

Общие принципы

Для разных сценариев сбоев – разные сценарии резервирования и бэкапов

Slave у БД – не бэкап, но тоже очень помогает

Нужно бэкапить и файлы, и базу данных

Это нужно делать постоянно, а не перед аварией

Нужно бэкапить конфиги и настройки серверов и софта

Нужно резервировать даже то, что уже зарезервировано (S3, например)

Полезно проводить учения по восстановлению системы

Нужно уметь восстанавливаться быстро и уверенно

Восстановление можно частично автоматизировать

Мониторинг целостности данных и успешного создания резервных копий

Кстати, правильный ли у вас бэкап?

Изолированность

Целостность

Версионность

Безопасность

Доступность

Не бывает «почти круглосуточно» -технические работы должны проходить незаметно для клиентов:

Сервисные работы

Замена оборудования

Обновления системного ПО

Обновления приложений

Посчитаем стоимость «новой ИТ-системы»

Оборот за 2012 год - $132 млн. (Digital Guru)

7 суток простоя – около $2.5 млн.

А что с поиском?

Резервируй это!

Если ваш сайт выглядит как живой... убедитесь, что он еще и здоровый.

Недоступность сайта…Вышел из строя дискКончилось место на дискеНе хватило ресурсов CPUНе хватило памятиНе хватило производительности дискаНе хватило каналаВышла из строя оперативная памятьВышла из строя материнская платаСгорел блок питанияDDoSВзлом - целевая атакаВзлом - нецелевая атакаРазделегирование доменаЗакончился срок действия SSL сертификатаВыход из строя маршрутизатора провайдераАвария на канале провайдераПотери пакетов у upstream провайдераАвария с электропитаниемВыход из строя вентиляции - перегревОшибки настройки сетиОшибки настройки веб-сервераОшибки настройки базы данныхОшибка разработкиПреднамеренное вредительство разработчикомОшибки на файловой системе

Попадание в реестр РоскомнадзораОшибки внешних систем (например, платежная система в интернет-магазине)Ошибка персонала хостераОшибка персонала upstream оператораНедоступность и авария DNSУдаленность хостинга от клиентовОшибки в системном ПО (segfault)Ошибки файловой системы после аварийной перезагрузкиОшибки БД после аварийной перезагрузкиСброс несохраненных настроек после перезагрузкиНеоплата хостингаНеоплата лицензий на ПОНесовместимость с клиентским ПООтсутствие ресурсов для масштабирования (не хватило серверов)Неготовность приложения к масштабированиюОтсутствие кэшированияВзаимодействие с внешними системами (нагрузка импортами)Нагрузка во время создания бэкапаОшибки после установки обновленийОшибочная блокировка браузерами (вирусы)Отсутствие обработки пользовательских данныхАвария на уровне датацентра (пожар, наводнение)Отсутствие бэкапа для восстановления«Битый» бэкап (не было учений по восстановлению)Несвоевременная реакция сисадмина

Real Time мониторинг – как узнавать о проблемах?

Можно – так…

Real Time мониторинг – как узнавать о проблемах?

Или – так…

Как при этом не взорвать мозг?

Доступность «Битрикс24» и облачных сервисов «1С-Битрикс» - 99.99%

3200+ проверок в двух системах мониторинга

Организация системы мониторинга

Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные.

Дежурная смена и/или мгновенные уведомления.

Мониторить – всё. В том числе – нетипичные и нетехнические

характеристики

Но – аккуратно. Тысячи уведомлений будут бесполезны.

Автоматизация типовых реакций.

Мониторить систему мониторинга.

В идеальном мире – распределенная система мониторинга.

Мониторинг нетипичных характеристик

Наличие бэкапов

Срок делегирования доменов

Баланс у провайдера смс-уведомлений

Срок действия SSL сертификатов (а без него Google ранжирует хуже)

ulmart.ru – 18 февраля 2013

Оборот за 2012 год -$379 млн. (Digital Guru)

До суток простоя –более $1 млн.

Уведомления

Опрашиваем список проблем

Шлем «дайджест» проблем, а не по одному

сообщению на каждое событие

Несколько уровней критичности событий

Разные списки адресатов на разные события

Повтор (через 15 минут, через 2 часа), чтобы не

«потерять» уведомление

ОК – если все стало хорошо

Автоматизация типовых реакций

Рост / падение LA – автоматическое масштабирование вверх / вниз

Автоматический рестарт «сбойных» сервисов

Автоматическое «удаление» проблемных машин

Автоматическое восстановление репликации

Автоматическое переключение траффика в случае аварии на уровне целого ДЦ

242-ФЗ вступил в силу на территории России 1 сентября 2015 г.

Закон: №242-ФЗ «О внесении изменений в отдельные законодательные акты РФ в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях» от 21 июля 2014 года.

Суть: с 1 сентября 2015 года компании обяжут хранить персональные данные в базах данных, расположенных только на территории РФ. О месте хранения таких баз данных нужно уведомлять Роскомнадзор.• При этом не запрещается трансграничная передача данных при условии,

что первичный сбор и хранение данных осуществляется на территории России.

• В законе предусмотрены исключения. К примеру, персональные данные россиян могут обрабатываться на территории иностранных государств в целях исполнения правосудия, исполнения полномочий органов государственной власти и местного самоуправления, для достижения целей, предусмотренных международным договором. (Роскомнадзор, rkn.gov.ru, 13 февраля 2015 г.)

242-ФЗ

Государство начинает регулировать

интернет.

Но есть ли в этом что-то необычное?

Когда какая-то сфера бизнеса

становится важной для государства,

граждан - государство начинает

регулировать ее.

Избегайте эмоциональной оценки в

этом вопросе.

Почему нужно регулировать интернет с

точки зрения государства?

• Растет количество преступлений, потеря

персональных данных, похищение банковских

данных, промышленный и государственный

шпионаж.

• Интернет стал обязательной частью работы

государственных структур, социнститутов,

функционирования бизнеса.

• Регулировать интернет проблематично, но

необходимо, и государство будет искать способ, как

его отрегулировать.

• Граждане плохо реагируют на ограничение

интернета, но легко соглашаются после терактов или

больших скандалов с потерей персональной

информации.

• Так происходит не только у нас, а во всем мире.

Доброе слово и пистолет делают

больше, чем просто доброе слово…

• В законе много неясностей с

формулировками, но это не так важно.

• Важно то, что сказано по смыслу - вы

должны перевезти серверы в Россию.

В качестве аргумента выбрали

персональные данные.

В Китае заблокированы:

• 20 апреля 1994 года было создано первое кабельное интернет-соединение из Китая в Северную Америку и Европу.

• Спустя несколько лет китайское правительство начало работу над ограничением этого нового вида связи.

• В конце 2003 знаменитый Великий Китайский Фаервол начал свою работу, за последние десять лет система контроля разрослась до невиданных масштабов.

Twitter, Facebook, Instagram, Google+, YouTube, Google Play, поисковик Google, Microsoft OneDrive, Dropbox, Slideshare, Google Drive, Google Docs, Gmail, Google Translate, Google Calendar, Flickr и многое другое.

Риски: Великий Китайский Фаервол

http://habrahabr.ru/

http://www.ted.com/talks/michael_anti_behind_the_great_firewall_of_china

Стоимость хостинга плохо прогнозируема

Риски: стоимость хостинга зависит от курсов валют

Варианты:

1. Забить.

2. А давайте попробуем всех обмануть

Сделаем туннель/прокси: возьмем

российский IP, сделаем прокси к западным

серверам и там оставим персональные

данные.

3. Деперсонализировать

Разместим часть данных в России, а не

перс. данные могут остаться и не в РФ.

4. Полностью переехать.

Предпосылки к переезду: технические

«Облачная» безопасность

Вы все еще не верите в «облачную» безопасность и не любите «облако»? Возможно, вы просто неправильно его «готовите».

Спасибо за внимание!Вопросы?

Александр Демидов

demidov@1c-bitrix.ru

demidov

Demidov.Alexander

top related