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

1. Заоблачная безопасность:
как обойти чужие грабли
Александр Демидов
«1С-Битрикс»
Руководитель направления арендных решений

2. Битрикс24
• Зарегистрировано компаний: 1 000 000+
• Активных компаний: 105 000+
• 3000 сотрудников в максимальной компании
• 35 000 000 программных страниц в день
• 99,99% доступность сервиса

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

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

7. Кто наши «заклятые друзья»?
Пользователи
Разработчики
Системные
администраторы
Провайдеры
Государство
Хакеры?

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

9. Пользователи
Обязательно HTTPS
Ограничение доступа по IP
OTP

10. Разработчики
Никакого доступа на «бой»!
Полная изоляция данных пользователей
Нет единого хранилища логинов и
паролей
WAF (in / out)
Файловая система (кроме временных
директорий) – read only
Аудит кода
Тестирование всех обновлений

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

12. Доверяй, но проверяй
Даже там, где
совсем не ждешь
подвоха…

13. Системные администраторы
Firewall – закрыто все,
кроме необходимого
Администрирование –
только из офисных сетей
chroot
Real-time мониторинг
изменений в FS
Real-time мониторинг
загружаемых файлов
noexec на временных
директориях
Мониторинг security
updates
Тестирование всех
обновлений

14. «Одноклассники» 4-6 апреля 2013
2.1 млрд. просмотров в сутки до сбоя
1.6 млрд. – в среднем в неделю сбоя
1.9 млрд. – после сбоя
http://corp.mail.ru/adv/price_odnoklassniki.htm
"Испорченный файл был выложен через
централизованную систему управления серверами.
В итоге это повлекло за собой необходимость
перезапуска большой части наших серверов и
переустановку операционной системы", — заявила
пресс-секретарь "Одноклассников" Мария Лапук

15. Внутренний аудит
Внешний аудит

16. Целостность
Пользователи
Разработчики
Системные
администраторы
Провайдеры
Все те же «враги»…

17. Общие принципы
Для разных сценариев сбоев – разные сценарии резервирования и бэкапов
Slave у БД – не бэкап, но тоже очень помогает
Нужно бэкапить и файлы, и базу данных
Это нужно делать постоянно, а не перед аварией 
Нужно бэкапить конфиги и настройки серверов и софта
Нужно резервировать даже то, что уже зарезервировано (S3, например)
Полезно проводить учения по восстановлению системы
Нужно уметь восстанавливаться быстро и уверенно
Восстановление можно частично автоматизировать
Мониторинг целостности данных и успешного создания резервных копий

18. Кстати, правильный ли у вас бэкап?
Изолированность
Целостность
Версионность
Безопасность

19. Доступность
Не бывает «почти круглосуточно» -
технические работы должны
проходить незаметно для клиентов:
Сервисные работы
Замена оборудования
Обновления системного ПО
Обновления приложений

20. Посчитаем стоимость «новой ИТ-системы»
Оборот за 2012 год - $132 млн.
(Digital Guru)
7 суток простоя – около $2.5 млн.
А что с поиском?

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

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

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

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

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

26. Как при этом не взорвать мозг?
Доступность «Битрикс24»
и облачных сервисов
«1С-Битрикс» - 99.99%
3200+ проверок в двух
системах мониторинга

27. Организация системы мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё. В том числе – нетипичные и нетехнические
характеристики
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Автоматизация типовых реакций.
Мониторить систему мониторинга.
В идеальном мире – распределенная система мониторинга.

28. Мониторинг нетипичных характеристик
Наличие бэкапов
Срок делегирования доменов
Баланс у провайдера смс-уведомлений
Срок действия SSL сертификатов (а без него Google ранжирует хуже)

29. ulmart.ru – 18 февраля 2013
Оборот за 2012 год -
$379 млн. (Digital Guru)
До суток простоя –
более $1 млн.

30. Уведомления
Опрашиваем список проблем
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Несколько уровней критичности событий
Разные списки адресатов на разные события
Повтор (через 15 минут, через 2 часа), чтобы не
«потерять» уведомление
ОК – если все стало хорошо

31. Автоматизация типовых реакций
Рост / падение LA – автоматическое масштабирование вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение траффика в случае аварии на
уровне целого ДЦ

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

33. Закон: №242-ФЗ «О внесении изменений в отдельные
законодательные акты РФ в части уточнения порядка обработки
персональных данных в информационно-телекоммуникационных
сетях» от 21 июля 2014 года.
Суть: с 1 сентября 2015 года компании обяжут хранить
персональные данные в базах данных, расположенных только на
территории РФ. О месте хранения таких баз данных нужно
уведомлять Роскомнадзор.
• При этом не запрещается трансграничная передача данных при условии,
что первичный сбор и хранение данных осуществляется на территории
России.
• В законе предусмотрены исключения. К примеру, персональные данные
россиян могут обрабатываться на территории иностранных государств в
целях исполнения правосудия, исполнения полномочий органов
государственной власти и местного самоуправления, для достижения
целей, предусмотренных международным договором. (Роскомнадзор,
rkn.gov.ru, 13 февраля 2015 г.)
242-ФЗ

34. Государство начинает регулировать
интернет.
Но есть ли в этом что-то необычное?
Когда какая-то сфера бизнеса
становится важной для государства,
граждан - государство начинает
регулировать ее.
Избегайте эмоциональной оценки в
этом вопросе.

35. Почему нужно регулировать интернет с
точки зрения государства?
• Растет количество преступлений, потеря
персональных данных, похищение банковских
данных, промышленный и государственный
шпионаж.
• Интернет стал обязательной частью работы
государственных структур, социнститутов,
функционирования бизнеса.
• Регулировать интернет проблематично, но
необходимо, и государство будет искать способ, как
его отрегулировать.
• Граждане плохо реагируют на ограничение
интернета, но легко соглашаются после терактов или
больших скандалов с потерей персональной
информации.
• Так происходит не только у нас, а во всем мире.

36. Доброе слово и пистолет делают
больше, чем просто доброе слово…
• В законе много неясностей с
формулировками, но это не так важно.
• Важно то, что сказано по смыслу - вы
должны перевезти серверы в Россию.
В качестве аргумента выбрали
персональные данные.

37. В Китае заблокированы:
• 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

38. Стоимость хостинга плохо
прогнозируема
Риски: стоимость хостинга зависит от курсов валют

39. Варианты:
1. Забить.
2. А давайте попробуем всех обмануть 
Сделаем туннель/прокси: возьмем
российский IP, сделаем прокси к западным
серверам и там оставим персональные
данные.
3. Деперсонализировать
Разместим часть данных в России, а не
перс. данные могут остаться и не в РФ.
4. Полностью переехать.

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

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

42. Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
demidov
Demidov.Alexander